Skip to content

add example for auto generated module verification report #166

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
masc2023 merged 7 commits into from
Sep 11, 2026
Merged

add example for auto generated module verification report #166

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
29c4093
add example for auto generated module verifiaction report
RolandJentschETAS Sep 1, 2026
1dd74ec
udpate rules lint version
RolandJentschETAS Sep 1, 2026
fda2384
Update docs/verification_report/module_verification_report.rst
RolandJentschETAS Sep 1, 2026
40d6c62
fix link name
RolandJentschETAS Sep 1, 2026
5b639e9
add link to report from process
RolandJentschETAS Sep 1, 2026
7fe9d97
Merge branch 'main' into improvement_generated_mod_verification_report
AlexanderLanin Sep 9, 2026
e03d4b4
Merge branch 'main' into improvement_generated_mod_verification_report
masc2023 Sep 11, 2026
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
2 changes: 1 addition & 1 deletion MODULE.bazel
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -69,7 +69,7 @@ register_toolchains("@llvm_toolchain//:all")

# tooling
bazel_dep(name = "score_tooling", version = "1.2.0", dev_dependency = True)
bazel_dep(name = "aspect_rules_lint", version = "1.10.2", dev_dependency = True)
bazel_dep(name = "aspect_rules_lint", version = "2.3.0", dev_dependency = True)

@AlexanderLanin AlexanderLanin Sep 1, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

why touch aspect rules?

@RolandJentschETAS RolandJentschETAS Sep 1, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

There was a warning regards to that... If I made a PR I can fix that together.

@AlexanderLanin AlexanderLanin Sep 1, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

@copilot which module updated aspect_rules_lint?

Copilot AI Sep 1, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

aspect_rules_lint was set directly by this template’s MODULE.bazel in 1dd74ec (bazel_dep(..., version = "2.3.0")). The resolved lockfile also shows aspect_tools_telemetry 0.2.8 requesting 2.3.0; no separate module update caused it.

@AlexanderLanin AlexanderLanin Sep 1, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

@copilot yeah, but this was done only to resolve a warning. So what other module did the update?

Copilot AI Sep 1, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

It was score_bazel_cpp_toolchains 1.0.3. Its MODULE.bazel declares aspect_rules_lint 2.3.0 (alongside score_tooling 1.1.2), while score_tooling 1.2.0 itself requests 1.5.3.

@AlexanderLanin AlexanderLanin Sep 11, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

its a dev dependency, should not be an issue

@MaximilianSoerenPollak MaximilianSoerenPollak Sep 9, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I don't know if this should be upgraded in the same PR.
Did it error otherwise?

@AlexanderLanin AlexanderLanin Sep 11, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

its a dev dependency, should not be an issue

bazel_dep(name = "buildifier_prebuilt", version = "8.5.1.2", dev_dependency = True)

#docs-as-code
Expand Down
2 changes: 0 additions & 2 deletions MODULE.bazel.lock
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

145 changes: 92 additions & 53 deletions docs/verification_report/module_verification_report.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -18,80 +18,119 @@ Verification Report
.. note:: Document header

.. document:: [Module Name] Verification Report
:id: doc__mod_temp_module_name_verification_report
:status: draft
:version: 1
:safety: ASIL_B
:security: NO
:realizes: wp__verification_module_ver_report
:tags: template
:id: doc__mod_temp_module_name_verification_report
Comment thread
RolandJentschETAS marked this conversation as resolved.
Outdated
:status: draft
:version: 1
:safety: ASIL_B
:security: NO
:realizes: wp__verification_module_ver_report
:tags: template
Comment thread
RolandJentschETAS marked this conversation as resolved.

.. attention::
In a module the above directive must be replaced by the following directive.

.. code-block:: rst

.. document:: {module pretty name} Module Verification Report
:id: doc__{module formal name = same as in ..mod}_verification_report
:post_template: module_verification_report
:status: valid
:safety: QM
:security: NO
:realizes: wp__verification_module_ver_report
:version: 1

.. attention::

The above directive must be updated according to your Module.

- Modify ``Your Module Name`` to be your Module Name
- Modify ``id`` to be your Module Name in upper snake case preceded by ``doc_`` and succeeded by ``verification_report``
- Modify ``module pretty name`` to be your Module Name
- Modify ``module formal name`` to be your Module Name in lower case
- Adjust ``status`` to be ``valid``
- Adjust ``safety`` and ``tags`` according to your needs

This verification report is based on the :need:`gd_temp__verification_plan`.
It covers all the components of the above stated module.
.. note::

The verification report is generated automatically by the codeblock above by the tools and contains all the needed information for the module verification. The report is based on the module verification plan and covers all the components of the module.

The generated report should contain the following parts:
Comment thread
RolandJentschETAS marked this conversation as resolved.
Outdated

.. code-block:: rst

Verification Report contains:
This verification report is based on the :need:`gd_temp__verification_plan`.
It covers all the components of the above stated module.

**1. Verification Coverage**
Verification Report contains:

**1.1. on Requirements**
- Lists of component requirements (incl. AoU satisfied by the component) tested by which test case, passed/failed and completeness verdict
(this shall be generated by tools and accompanied by progress charts to be usable also for project steering)
- For external component Assumptions of Use: coverage by platform safety manual or feature/components incl. test case, passed/failed and completeness verdict
- This is split in a list of QM requirements tested and a separate list of tests for ASIL rated requirements.
- List of component requirements (ASIL rated) linked to inspection checklist and verdict (derived from PR export)
**1. Verification Coverage**

**1.2. on Architecture**
- List of component architecture tags tested by which test case, passed/failed and completeness verdict
(this shall be generated by tools and accompanied by progress charts to be usable also for project steering)
- This is split in a list of QM components tested and a separate list of tests for ASIL rated components.
- List of component architecture tags (ASIL rated) linked to inspection checklist and verdict (derived from PR export)
**1.1. on Requirements**
- Lists of component requirements (incl. AoU satisfied by the component) tested by which test
case, passed/failed and completeness verdict
- (this shall be generated by tools and accompanied by progress charts to be usable also for
project steering)
- For external component Assumptions of Use: coverage by platform safety manual or
feature/components incl. test case, passed/failed and completeness verdict
- This is split in a list of QM requirements tested and a separate list of tests for ASIL
rated requirements.
- List of component requirements (ASIL rated) linked to inspection checklist and verdict
(derived from PR export)

**1.3. on Detailed Design**
- List of detailed design tags tested by which test case, passed/failed and completeness verdict
(this shall be generated by tools and accompanied by progress charts to be usable also for project steering)
- This is split in a list of QM components tested and a separate list of tests for ASIL rated components.
- List of detailed design tags (ASIL rated) linked to inspection checklist and verdict (derived from PR export)
**1.2. on Architecture**
- List of component architecture tags tested by which test case, passed/failed and completeness
verdict
- (this shall be generated by tools and accompanied by progress charts to be usable also for
project steering)
- This is split in a list of QM components tested and a separate list of tests for ASIL rated
components.
- List of component architecture tags (ASIL rated) linked to inspection checklist and verdict
(derived from PR export)

- The lists may also contain other verification methods like "Analysis" - process tbd
**1.3. on Detailed Design**
- List of detailed design tags tested by which test case, passed/failed and completeness verdict
- (this shall be generated by tools and accompanied by progress charts to be usable also for
project steering)
- This is split in a list of QM components tested and a separate list of tests for ASIL rated
components.
- List of detailed design tags (ASIL rated) linked to inspection checklist and verdict (derived
from PR export)
- The lists may also contain other verification methods like "Analysis" - for example
by :need:`doc__mod_temp_component_name_impl_inspection`

**2. DFA Report**
- List of the performed component DFA, pass/fail with open mitigations
**2. DFA Report**
- List of the performed component DFA, pass/fail with open mitigations

**3. Safety Analysis Report**
- List of the performed component Safety Analysis, pass/fail with open mitigations
**3. Safety Analysis Report**
- List of the performed component Safety Analysis, pass/fail with open mitigations

**4. Unit Verification Coverage**
**4. Unit Verification Coverage**

**4.1. Structural Coverage**
- List of the units with C0(line) and C1(branch) coverage absolute and percentage
(this shall be generated by tools and accompanied by progress charts to be usable also for project steering)
- List includes a column for the safety rating of each unit.
**4.1. Structural Coverage**
- List of the units with C0(line) and C1(branch) coverage absolute and percentage
- (this shall be generated by tools and accompanied by progress charts to be usable also for
project steering)
- List includes a column for the safety rating of each unit.

**4.2. Static Code Analysis**
- List of the units with compiler warning numbers and coding rule violation numbers
(this shall be generated by tools and accompanied by progress charts to be usable also for project steering)
- List includes a column for the safety rating of each unit.
**4.2. Static Code Analysis**
- List of the units with compiler warning numbers and coding rule violation numbers
- (this shall be generated by tools and accompanied by progress charts to be usable also for
project steering)
- List includes a column for the safety rating of each unit.

**4.3. Manual Code Inspection**
- List of components (ASIL rated) linked to inspection checklist and verdict (derived from PR export)
**4.3. Manual Code Inspection**
- List of components (ASIL rated) linked to inspection checklist and verdict (derived from PR
export)

**5. Software component qualification verification report**
- Contains the needed verification results if for some components a qualification of pre-developed SW is performed.
**5. Software component qualification verification report**
- Contains the needed verification results if for some components a qualification of pre-developed
SW is performed.

**6. Test results**
- Test result per test case with status passed/failed/not_run
**6. Test results**
- Test result per test case with status passed/failed/not_run

**7. Test logs**
- Test log per test case with status passed/failed/not_run
**7. Test logs**
- Test log per test case with status passed/failed/not_run

**Note1:** The verification report is valid for the module version tagged together with the report
**Note1:** The verification report is valid for the module version tagged together with the report

**Note2:** All the above lists are generated automatically
**Note2:** All the above lists are generated automatically
29 changes: 27 additions & 2 deletions examples/docs/architecture_modeling_example.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -24,6 +24,8 @@ Feature Architecture File

.. note:: The feature and the logical interfaces are normally defined in the platform repo (`features folder <https://eclipse-score.github.io/score/main/features/index.html>`_) and imported from there as sphinx needs objects. In this example it is defined here only, to hold the example consistent.

.. Logical Interface Operations and Module Mapping

.. feat:: Feature 1
:id: feat__mtef
:security: YES
Expand Down Expand Up @@ -66,6 +68,9 @@ Feature Architecture File

{{ draw_interface(need(), needs) }}

Logical Interface 1 provides the primary control and communication interface for the feature.
It is implemented by sub-component 1 which handles the core functionality.


.. logic_arc_int:: Logical Interface 2
:id: logic_arc_int__example_feature__if_2
Expand All @@ -82,6 +87,9 @@ Feature Architecture File

{{ draw_interface(need(), needs) }}

Logical Interface 2 provides support for data processing and communication between sub-components.
It is implemented by sub-component 2 which handles data flow and processing operations.


.. logic_arc_int:: Logical Interface 3
:id: logic_arc_int__example_feature__if_3
Expand All @@ -92,6 +100,7 @@ Feature Architecture File
:included_by: feat__mtef
:fulfils: feat_req__example_feature__example_req

Logical Interface 3 provides additional support and monitoring capabilities for the feature.

.. Logical Interface Operation

Expand Down Expand Up @@ -169,9 +178,11 @@ Module View File
:safety: ASIL_B
:status: valid
:version: 1
:includes: comp__mod_temp_component_example_1, comp__mod_temp_component_example_2
:includes: comp__mod_temp_component_example_1, comp__mod_temp_component_example_2, comp__mod_temp_archex_sub_component_1, comp__mod_temp_archex_sub_component_2

This is Module 1.
This module describes the mapping and implementation of logical interfaces through their implementing components and sub-components.
Logical Interface 1 is implemented by Component 1 and Sub-Component 1 (core control logic, operations 1 and 2).
Logical Interface 2 is implemented by Component 2 and Sub-Component 2 (data flow and processing, operations 3 and 4).

.. mod_view_sta:: Module 1 Static View
:id: mod_view_sta__example_feature__1
Expand All @@ -192,6 +203,8 @@ Module View File
:version: 1
:includes: comp__mod_temp_component_example_3

This module contains Component 3 which implements Logical Interface 3 with support and monitoring capabilities.

This is Module 2.

.. mod_view_sta:: Module 2 Static View
Expand Down Expand Up @@ -269,6 +282,11 @@ Feature or Component Architecture File(s)
:implements: logic_arc_int__example_feature__if_1
:belongs_to: feat__mtef

Sub-Component 1 implements Logical Interface 1 and provides the core control logic.

This module handles the primary operations required by the feature interface and coordinates
with other sub-components through Logical Interface 2 for data exchange and synchronization.

.. comp:: Component 1_2
:id: comp__mod_temp_archex_sub_component_2
:status: valid
Expand All @@ -279,6 +297,11 @@ Feature or Component Architecture File(s)
:implements: logic_arc_int__example_feature__if_2
:belongs_to: feat__mtef

Sub-Component 2 implements Logical Interface 2 and provides data processing capabilities.

This module manages data flow, processing, and communication services required by the feature.
It ensures proper data handling and supports the operations defined in the logical interfaces.

.. comp:: Component 1_3
:id: comp__mod_temp_archex_sub_component_3
:status: valid
Expand All @@ -287,6 +310,8 @@ Feature or Component Architecture File(s)
:security: NO
:belongs_to: feat__mtef

Example Sub-Component 3 description as part of Component 1.


Requirements for the Example
=============================
Expand Down
Loading