[module api] Initial version #95

ramceb · 2025-12-17T10:53:46Z

This commit introduces the initial implementation of the score_module
Bazel rules for handling SEOOC (Safety Element Out Of Context) modules.

Key additions:

Core rules in score_module.bzl and private/seooc.bzl
Test infrastructure with fixtures covering architecture design,
assumptions of use, component requirements, and safety analysis

masc2023

Why not follow process description, that will cover also other standards, Safety is based on Quality, and defined folder structures?

bazel/rules/score_module/docs/index.rst

bazel/rules/score_module/test/fixtures/architecture_design.rst

ramceb · 2025-12-18T16:23:57Z

Why not follow process description, that will cover also other standards, Safety is based on Quality, and defined folder structures?

The concept behind the module API is to enforce that modules follow the score processes.

This commit introduces the initial implementation of the score_module Bazel rules for handling SEOOC (Safety Element Out Of Context) modules. Key additions: - Core rules in score_module.bzl and private/seooc.bzl - Test infrastructure with fixtures covering architecture design, assumptions of use, component requirements, and safety analysis

AlexanderLanin

Very good start! I feel using baselibs as an example is not ideal. We should try to apply this to a component that has existing documentation.

AlexanderLanin · 2025-12-18T20:19:56Z

bazel/rules/score_module/docs/index.rst

+   safety_element_out_of_context(
+       name = "my_module",
+       assumptions_of_use = ":assumptions",
+       component_requirements = ":requirements",


That would be seooc_requirements... but since seeoc is redundant we can also just say requirements? But that again is confusing. Is it maybe assumed requirements? Or what is it? Probably a question for the process experts :)

IMHO, we have feature requirements and component requirements. Conceptually, its important that these requirements are verified with the targets from tests. So that we can compute a meaningful requirements coverage.

That would be seooc_requirements... but since seeoc is redundant we can also just say requirements? But that again is confusing. Is it maybe assumed requirements? Or what is it? Probably a question for the process experts :)

Process defines assumptions of use and requirementes, e.g.Platform
https://eclipse-score.github.io/score/main/requirements/index.html

AlexanderLanin · 2025-12-18T20:20:26Z

bazel/rules/score_module/docs/index.rst

+
+- ``name``: The name of the safety element module. Used as the base name
+  for all generated targets.
+- ``assumptions_of_use``: Label to a ``.rst`` or ``.md`` file containing the


I imagine that this may not be a single file. And what exactly is a file here? filegroup?

Valid point. Technically it can be anything which returns a SphinxDocsLibraryProvider, which of course can contain rst, md, svg files etc.

AlexanderLanin · 2025-12-18T20:21:40Z

bazel/rules/score_module/docs/index.rst

+  safety analysis, including FMEA, FMEDA, FTA, or other safety analysis
+  results as required by ISO 26262-9 clause 8. Documents hazard analysis and
+  safety measures.
+- ``implementations``: List of labels to Bazel targets representing the actual


bazel targets would be treated as transitive?! So why do we even need multiple labels here?

You are right. We could hide this behind a single target. But this is what the rule already does. The idea was a different one: Behind each of these targets is an api, provided to the user. E.g. the hdrs attribute of a cc_library provide the header files published by that library. We should also use this information to enhance the documentation with API docs generated from the code.

AlexanderLanin · 2025-12-18T20:22:28Z

bazel/rules/score_module/docs/index.rst

+  software implementation (cc_library, cc_binary, etc.) that realizes the
+  component requirements. This is the source code that implements the safety
+  functions as required by ISO 26262-6 clause 8.
+- ``tests``: List of labels to Bazel test targets (cc_test, py_test, etc.)


Remark for the future: we'll need to split this to slow tests and fast tests, or the old unit test and integration test split.

I agree. But then we should differentiate between "integration tests" and "unit tests" according to the test lavels.

AlexanderLanin · 2025-12-18T20:23:53Z

bazel/rules/score_module/docs/index.rst

+
+**Generated Targets:**
+
+This macro creates multiple targets automatically:


These are all docu related. Where are implementation and tests?

AlexanderLanin · 2025-12-18T20:40:20Z

bazel/rules/score_module/docs/index.rst

+- ``assumptions_of_use``: Label to a ``.rst`` or ``.md`` file containing the
+  Assumptions of Use, which define the safety-relevant operating conditions
+  and constraints for the SEooC as required by ISO 26262-10 clause 5.4.4.
+- ``component_requirements``: Label to a ``.rst`` or ``.md`` file containing


SEOOC would contain only safety requirements AFAIK. Do we want to include all requirements here?

Yes. A limitation to safety requirements does not make sense. The safety_element_out_of_context shall be a self contained unit.

Just to avoid here misunderstanding, Process covers NOT only Safety, also QM and Security, and we define here Modules, containing everything, Module can be seen as SEooC, but compare Handbook and Safety Plan, we do not deliver SEooC, there will be no safey argumentation, integrator can take it to make a SEooC out it.

https://eclipse-score.github.io/process_description/main/general_concepts/score_building_blocks_concept.html
https://eclipse-score.github.io/process_description/main/general_concepts/score_building_blocks_concept.html
https://eclipse-score.github.io/process_description/main/process_areas/safety_management/safety_management_workproducts.html#wp__platform_safety_package

So the basic naming is wrong here? It should not be "safety_element_out_of_context" but just "score_module"?

AlexanderLanin · 2025-12-18T20:45:53Z

bazel/rules/score_module/private/seooc.bzl

+    "assumptions_of_use": attr.label(
+        providers = [SphinxDocsLibraryInfo],
+        mandatory = True,
+        doc = "Label to a sphinx_docs_library target containing the Assumptions of Use, which define the safety-relevant operating conditions and constraints for the SEooC as required by ISO 26262-10 clause 5.4.4.",


Ah, this doesn't quite match docu where it says this needs to point to an rst/md file.

Fair. the documentation needs to be updated.

AlexanderLanin · 2025-12-18T20:47:38Z

bazel/rules/score_module/private/seooc.bzl

+    all_files = []
+    for artifact in seooc_artifacts:
+        dep = getattr(ctx.attr, artifact)
+        for t in dep[SphinxDocsLibraryInfo].transitive.to_list():


This assembles all the artifacts into a standard file structure. So I have wo wonder, whether it would be easier to collect only a single SphinxDocsLibraryInfo, instead of collecting multiple and internally assembling a single one.

yes. This is intenionally like this. The rule shall provide an abstract api, which always provides you a valid SpinxDocsLibrary.

AlexanderLanin · 2025-12-18T20:59:40Z

bazel/rules/score_module/private/seooc.bzl

+        mandatory = True,
+        doc = "Label to a sphinx_docs_library target containing the safety analysis, including FMEA, FMEDA, FTA, or other safety analysis results as required by ISO 26262-9 clause 8. Documents hazard analysis and safety measures.",
+    ),
+}


Having everything in separate SphinxDocsLibraryInfo targets means the generated index file will differ from the original index file. So module docu will look different than seeoc docu of the same module. Correct?

AlexanderLanin · 2025-12-18T21:07:26Z

bazel/rules/score_module/test/BUILD

+package(default_visibility = ["//visibility:public"])
+
+# Test fixtures for seooc tests
+sphinx_docs_library(


This would currently only provide the raw .rst files? Specifically no prebuild json data?

ramceb

Very good start! I feel using baselibs as an example is not ideal. We should try to apply this to a component that has existing documentation.

Thx. Baselibs was chosen on purpose as it provides several seoocs. Anyhow, we can also use any other module, which comes with more documentation in the module repository. Any suggestions?

masc2023 · 2025-12-19T07:13:32Z

Very good start! I feel using baselibs as an example is not ideal. We should try to apply this to a component that has existing documentation.

Thx. Baselibs was chosen on purpose as it provides several seoocs. Anyhow, we can also use any other module, which comes with more documentation in the module repository. Any suggestions?

Persistency?

github-project-automation bot added this to Infrastructure Dec 17, 2025

github-project-automation bot moved this to Draft in Infrastructure Dec 17, 2025

ramceb force-pushed the mb_module_api branch from 9088c76 to a455217 Compare December 17, 2025 11:00

masc2023 requested changes Dec 17, 2025

View reviewed changes

bazel/rules/score_module/docs/index.rst Outdated Show resolved Hide resolved

bazel/rules/score_module/docs/index.rst Outdated Show resolved Hide resolved

masc2023 reviewed Dec 17, 2025

View reviewed changes

bazel/rules/score_module/test/fixtures/architecture_design.rst Outdated Show resolved Hide resolved

ramceb force-pushed the mb_module_api branch 2 times, most recently from 0f3a3f4 to 74365d5 Compare December 17, 2025 13:24

ramceb marked this pull request as draft December 17, 2025 13:24

ramceb force-pushed the mb_module_api branch 3 times, most recently from 8421a28 to ae85726 Compare December 17, 2025 13:54

ramceb added 2 commits December 18, 2025 17:24

Incorporated first feedback

04fe3f6

ramceb force-pushed the mb_module_api branch from 1744747 to 04fe3f6 Compare December 18, 2025 16:25

AlexanderLanin reviewed Dec 18, 2025

View reviewed changes

ramceb commented Dec 19, 2025

View reviewed changes


		Generated Targets:

		This macro creates multiple targets automatically:

[module api] Initial version #95

Are you sure you want to change the base?

[module api] Initial version #95

Uh oh!

Conversation

ramceb commented Dec 17, 2025

Uh oh!

masc2023 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ramceb commented Dec 18, 2025

Uh oh!

AlexanderLanin left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AlexanderLanin Dec 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ramceb left a comment

Choose a reason for hiding this comment

Uh oh!

masc2023 commented Dec 19, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

AlexanderLanin Dec 18, 2025 •

edited

Loading