Module Verification Reports

This page lists the per-module verification reports.

Reports built into this site

These reports are generated from the respective module’s own needs data using the module verification report template introduced by docs-as-code.

• Baselibs

• Lifecycle

• Logging

• Persistency

Reports generated outside docs-as-code

Communication does not describe its safety case with docs-as-code. It uses the dependable_element rule from eclipse-score/tooling, which generates a self-contained multi-page report per dependable element — architecture, components, units, assumed system and a L.O.B.S.T.E.R. traceability report over feature requirements, failure modes, control measures and root causes.

Those pages are produced by Communication’s own documentation job and published to its GitHub Pages site, so they are linked here rather than mounted.

Dependable element	Report	Traceability
mw_com (LoLa)	Dependable element: mw_com	L.O.B.S.T.E.R. report (mw_com)
message_passing	Dependable element: message_passing	L.O.B.S.T.E.R. report (message_passing)

Note

The links above point at Communication’s latest documentation, which tracks its main branch. They are therefore not pinned to the Communication revision recorded in known_good.json.

Note

Mounting these reports into this site is currently not possible. The generated documentation targets are testonly, and a non-testonly target such as this site’s documentation cannot depend on them.

dependable_element only defaults to testonly = True, but passing testonly = False does not help: the deps of a dependable element reference the <name> target of other dependable elements, and that target is declared as a Bazel test rule — which is unconditionally testonly. For message_passing the point is moot anyway, since it declares real test dependencies. Resolving this therefore requires a change in eclipse-score/tooling.