Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Empty file added bazel/rules/score_module/BUILD
Empty file.
52 changes: 52 additions & 0 deletions bazel/rules/score_module/docs/conf.py
Original file line number Diff line number Diff line change
@@ -0,0 +1,52 @@
# *******************************************************************************
# Copyright (c) 2024 Contributors to the Eclipse Foundation
#
# See the NOTICE file(s) distributed with this work for additional
# information regarding copyright ownership.
#
# This program and the accompanying materials are made available under the
# terms of the Apache License Version 2.0 which is available at
# https://www.apache.org/licenses/LICENSE-2.0
#
# SPDX-License-Identifier: Apache-2.0
# *******************************************************************************

# Configuration file for the Sphinx documentation builder.
#
# For the full list of built-in configuration values, see the documentation:
# https://www.sphinx-doc.org/en/master/usage/configuration.html


# -- Project information -----------------------------------------------------
# https://www.sphinx-doc.org/en/master/usage/configuration.html#project-information

project = "SCORE MODULE API"
project_url = "https://eclipse-score.github.io/module_template/"
project_prefix = "MODULE_TEMPLATE_"
author = "S-CORE"
version = "0.1"

# -- General configuration ---------------------------------------------------
# https://www.sphinx-doc.org/en/master/usage/configuration.html#general-configuration


extensions = [
"sphinx_design",
"sphinx_needs",
"sphinxcontrib.plantuml",
"score_plantuml",
"score_metamodel",
"score_draw_uml_funcs",
"score_source_code_linker",
"score_layout",
]

exclude_patterns = [
"bazel-*",
".venv_docs",
]

templates_path = ["templates"]

# Enable numref
numfig = True
331 changes: 331 additions & 0 deletions bazel/rules/score_module/docs/index.rst
Original file line number Diff line number Diff line change
@@ -0,0 +1,331 @@
SCORE Module Bazel Rules
=========================

This directory contains Bazel rules for defining and building SCORE safety modules.

.. contents:: Table of Contents
:depth: 2
:local:


Overview
--------

The ``score_module`` package provides Bazel build rules to structure,
validate, and document safety-critical software modules. These rules
integrate with Sphinx documentation generation to produce comprehensive
safety documentation.

.. uml::

@startuml
[SEooC] as SEooC
[bazel module] as bzlmod
Artifact "Assumptions of Use" as AoU
Artifact "(Assumed) Component Requirements" as CR <<document>>
Artifact "Architecture Design" as AD <<document>>
Artifact "Safety Analysis" as SA <<document>>
Card "Implementation" as Impl <<target>>
Card "Testsuite" as Test <<target>>



bzlmod "1" *-- "*" SEooC : contains
SEooC ..> SEooC : depends on
SEooC "1" *-- "1" AoU : has
SEooC "1" *-- "1" CR : has
SEooC "1" *-- "1" AD : has
SEooC "1" *-- "1" Impl : has
SEooC "1" *-- "1" Test : has
SEooC "1" *-- "1" SA : has

note right of bzlmod
A score_module can contain
one or more Safety Elements
out of Context (SEooC)
end note

@enduml





Rules and Macros
----------------

safety_element_out_of_context
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

**File:** ``score_module.bzl``

**Purpose:** Main macro for defining a Safety Element out of Context
(SEooC) module with integrated documentation generation following ISO 26262
standards.

**Usage:**

.. code-block:: python

safety_element_out_of_context(
name = "my_module",
assumptions_of_use = ":assumptions",
component_requirements = ":requirements",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 :)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

architectural_design = ":architecture",
safety_analysis = ":safety_analysis",
implementations = [":my_lib", ":my_component"],
tests = [":my_lib_test", ":my_integration_test"],
visibility = ["//visibility:public"]
)

**Parameters:**

- ``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
Copy link
Member

@AlexanderLanin AlexanderLanin Dec 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

the component requirements specification, defining functional and safety
requirements.
- ``architectural_design``: Label to a ``.rst`` or ``.md`` file containing
the architectural design specification, describing the software architecture
and design decisions as required by ISO 26262-6 clause 7.
- ``safety_analysis``: Label to a ``.rst`` or ``.md`` file 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.
- ``implementations``: List of labels to Bazel targets representing the actual
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

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.)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ISO 26262 assumes verifications. Tests is only one part of verification. Just my 2 cents, I expect safety/process experts to comment on this further.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ISO 26262 assumes verifications. Tests is only one part of verification. Just my 2 cents, I expect safety/process experts to comment on this further.

I comment already, ISO things should be removed, S-CORE process is compliant to Safety, Security and QM, we follow not only SAFETY standards, by the way Quality standard is the ground for Safety

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, and same argument: I assume our process talks about "verification". "Tests" is only one part of "verification".

that verify the implementation against requirements. Includes unit tests and
integration tests as required by ISO 26262-6 clause 9 for software unit
verification.
- ``visibility``: Bazel visibility specification for the generated SEooC
target. Controls which other packages can depend on this safety element.

**Generated Targets:**

This macro creates multiple targets automatically:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


1. ``<name>_index``: Generates index.rst and conf.py files for the module
documentation
2. ``<name>_seooc_index_lib``: Sphinx documentation library for the
generated index
3. ``<name>``: The main SEooC target that aggregates all documentation
4. ``<name>.html``: Convenience target to build HTML documentation

**Implementation Details:**

The macro orchestrates several internal rules to:

- Generate a documentation index with a structured table of contents
- Organize documentation files under ``docs/safety_elements/<module_name>/``
- Integrate assumptions of use and component requirements into a unified documentation structure
- Provide Sphinx-compatible output for HTML generation

Private Rules
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These should probably be documented in the bazel files. External documentation will become async rather quickly.

-------------

seooc
~~~~~

**File:** ``private/seooc.bzl``

**Purpose:** Internal rule that aggregates safety documentation artifacts
into a Sphinx-compatible structure.

**Implementation:** ``_seooc_build_impl``

**Functionality:**

- Collects documentation from ``assumptions_of_use`` and
``component_requirements`` dependencies
- Reorganizes file paths to place artifacts under
``docs/safety_elements/<module_name>/``
- Merges the generated index with artifact documentation
- Returns a ``SphinxDocsLibraryInfo`` provider for downstream consumption

**Attributes:**

- ``assumptions_of_use``: Label to assumptions of use documentation (mandatory)
- ``component_requirements``: Label to component requirements documentation (mandatory)
- ``index``: Label to the generated index file (mandatory)

**Output:**

Returns a ``SphinxDocsLibraryInfo`` provider containing:

- ``transitive``: Depset of documentation file structs with relocated paths
- ``files``: Empty list (files are in transitive dependencies)

seooc_sphinx_environment
~~~~~~~~~~~~~~~~~~~~~~~~

**File:** ``private/seooc_index.bzl``

**Purpose:** Generates the Sphinx environment files (index.rst and conf.py)
for a safety module.

**Implementation:** ``_seooc_sphinx_environment_impl``

**Functionality:**

- Creates a module-specific ``index.rst`` with:

- Module name as header (uppercase with underline)
- Table of contents (toctree) linking to all safety artifacts
- References to assumptions of use and component requirements index files

- Generates a ``conf.py`` configuration file (currently placeholder content)

**Attributes:**

- ``module_name``: String name of the module (used for header generation)
- ``assumptions_of_use``: Label to assumptions documentation
- ``component_requirements``: Label to requirements documentation

**Generated Content Example:**
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where is the "normal documentation"? Those are just the safety artifacts, but modules (hopefully) also have a documentation. This was a challenge for us so far, how to integrate normal documentation and generated documentation.

The artefacts mentioned here would end up in some internal/process sub directory in usual documentations?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually on second thought the question is whether seeoc_module includes everything we expect from a module, or is there a second non_seeoc_artefact_list for each module? And no, I don't know that that could be 😆 Documentation is just one example that comes to mind, e.g. I would expect every module to have something like an Arc42 documentation.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Module,


.. code-block:: rst

MY_MODULE
=========

.. toctree::
:maxdepth: 2
:caption: Contents:

assumptions_of_use/index
component_requirements/index
architectural_design/index
safety_analysis/index

**Output:**

Returns ``DefaultInfo`` with generated ``index.rst`` files.

Documentation Structure
-----------------------

When using these rules, documentation is organized in the Bazel sandbox as
follows::

docs/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this docs inside bazel-bin or where is it? I'm confused how this relates to bazel-bin mentioned just below.

└── safety_elements/
└── <module_name>/
├── index.rst (generated)
├── conf.py (generated)
├── assumptions_of_use/
│ └── (user-provided documentation)
├── component_requirements/
│ └── (user-provided documentation)
├── architectural_design/
│ └── (user-provided documentation)
└── safety_analysis/
└── (user-provided documentation)

bazel-bin/
└── <module_name>/
└── _sources/
└── (generated documentation sources)

This structure reflects the file organization created in the Bazel sandbox
during the documentation generation process. The generated ``index.rst`` file
includes a table of contents that references all provided artifacts.

Integration with Sphinx
------------------------

The rules generate ``SphinxDocsLibraryInfo`` providers that are compatible
with ``@rules_python//sphinxdocs``. This enables:

- Automatic discovery of documentation files by Sphinx
- Proper path relocation for modular documentation
- Transitive dependency handling across multiple safety modules
- HTML, PDF, and other Sphinx output formats

Usage Example
-------------

Complete example in a BUILD file:

.. code-block:: python

load("@baselibs//bazel/score_module:score_module.bzl",
"safety_element_out_of_context")

# Documentation artifacts
sphinx_docs_library(
name = "assumptions",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
name = "assumptions",
name = "assumptions", // use any internal label here. It won't be public. ??

srcs = ["docs/assumptions_of_use.rst"],
)

sphinx_docs_library(
name = "requirements",
srcs = ["docs/component_requirements.rst"],
)

sphinx_docs_library(
name = "architecture",
srcs = ["docs/architectural_design.rst"],
)

sphinx_docs_library(
name = "safety",
srcs = ["docs/safety_analysis.rst"],
)

# Implementation targets
cc_library(
name = "lifecycle_lib",
srcs = ["lifecycle_manager.cpp"],
hdrs = ["lifecycle_manager.h"],
)

# Test targets
cc_test(
name = "lifecycle_test",
srcs = ["lifecycle_manager_test.cpp"],
deps = [":lifecycle_lib"],
)

# Safety Element out of Context
safety_element_out_of_context(
name = "lifecycle_manager_seooc",
assumptions_of_use = ":assumptions",
component_requirements = ":requirements",
architectural_design = ":architecture",
safety_analysis = ":safety",
implementations = [":lifecycle_lib"],
tests = [":lifecycle_test"],
visibility = ["//visibility:public"],
)

Then build the documentation:

.. code-block:: bash

# Build the SEooC target
bazel build //:lifecycle_manager_seooc


Dependencies
------------

- ``@rules_python//sphinxdocs``: Sphinx documentation build rules
- ``SphinxDocsLibraryInfo``: Provider for documentation artifacts

Design Rationale
----------------

These rules enforce a structured approach to safety documentation by:

1. **Standardization**: All safety modules follow the same documentation
structure
2. **Traceability**: Build system ensures all required artifacts are present
3. **Modularity**: Documentation can be composed from multiple sources
4. **Automation**: Index generation and path management are automated
5. **Integration**: Seamless integration with existing Sphinx workflows
Empty file.
Loading
Loading