Module Template Documentation#
This documentation describes the structure, usage and configuration of the Bazel-based C++/Rust module template according to the SCORE module folder structure and the SCORE building blocks concept.
Overview#
This repository provides a standardized setup for projects using C++ or Rust and Bazel as a build system. It integrates best practices for build, test, CI/CD and documentation. It also provides an example of modeling architecture in Sphinx Needs in Example model of architectural design. It also provides the component architecture template snippets in Component Architecture Template. It also provides an example of documenting detailed design in Example: Detailed Design.
Module Layout#
The module template includes the following top-level structure:
<module_name>/ -> Folder containing all artifacts corresponding to one module. │ As folder optional if the repository only contains a single module. ├── docs/ -> Documentation of the module │ ├── features/ -> All features of the module. │ │ └── <feature_name>/ -> Features including sub-folders and feature/component (change) request │ │ │ [wp__feat_request], [wp__cmpt_request] │ │ ├── architecture/ -> Feature architecture │ │ │ [wp__feature_arch], [wp__sw_arch_verification] │ │ ├── safety_analysis/ -> Safety analysis on feature level │ │ │ [wp__feature_fmea], [wp__feature_dfa] │ │ ├── safety_planning/ -> Feature specific safety workproducts planning │ │ │ [wp__platform_safety_plan] │ │ ├── security_analysis/ -> Security analysis on feature level │ │ │ [wp__feature_security_analysis] │ │ └── security_planning/ -> Feature specific security workproducts planning │ │ [wp__platform_security_plan] │ ├── manuals/ -> Module manual, e.g. integration manual, assumptions of use, │ │ safety manual [wp__requirements_comp_aou], │ │ [wp__requirements_feat_aou], │ │ [wp__module_safety_manual], │ │ security_manual [wp__module_security_manual]. │ ├── release/ -> Module release note [wp__module_sw_release_note], │ │ module release plan [wp__module_sw_release_plan], │ ├── safety_mgt/ -> Module safety plan [wp__module_safety_plan], │ │ module safety package [wp__module_safety_package], │ │ formal documents reviews [wp__fdr_reports], │ │ safety analysis formal reviews [wp__fdr_reports], │ │ safety tailoring [wp__safety_tailoring] │ │ safety component classification [wp__sw_component_class] │ ├── security_mgt/ -> Module security plan [wp__module_security_plan], │ │ module security package [wp__module_security_package], │ │ formal documents reviews [wp__fdr_reports_security], │ │ module SW bill of material [wp__sw_module_sbom] │ └── verification_report/ -> Module verification report │ module verifications [wp__verification_module_ver_report], └── score/ -> Folder containing all artifacts corresponding to the components of the module. ├── <component_name>/ -> Components of the module. │ │ Folder containing all artifacts corresponding to one component. │ ├── docs/ -> Documentation of the component │ │ ├── architecture/ -> Component architecture (only if lower level components exist) │ │ │ [wp__component_arch]. │ │ ├── detailed_design/ -> Detailed Design [wp__sw_implementation] and │ │ │ Detail design + code inspection [wp__sw_implementation_inspection], │ │ ├── manuals/ -> User documentation of a single component │ │ │ (e.g., user manual of a library, optional) │ │ ├── requirements/ -> Component requirements [wp__requirements_comp], │ │ │ requirements inspection [wp__requirements_inspect] │ │ ├── safety_analysis/ -> Safety analysis on component level (only if component architecture exists) │ │ │ [wp__sw_component_fmea], [wp__sw_component_dfa] │ │ └── security_analysis/ -> Security analysis on component level (only if component architecture exists) │ └── src/ -> Source files of the component consisting of │ │ Include and source Files [wp__sw_implementation] │ │ Test doubles │ │ Unit tests [wp__verification_sw_unit_test] │ ├── <lower_level_comp>/ -> lower level component following <component_name> folder structure │ └── tests/ -> Component-level tests (e.g., unit tests) │ [wp__verification_sw_unit_test] └── tests/ -> Module-level tests (e.g., feature integration tests, system tests) [wp__verification_comp_int_test] Feature Integration tests [wp__verification_feat_int_test]
Note
The feature-specific subfolder under docs/features/<feature_name>/ is only necessary
if more than one feature is implemented in the module.
Module Folder Structure (Single-Feature Variant)#
The following variant keeps the same structure but removes the additional
feature-name nesting under docs/features/. In this case, the features/
subfolder is optional and omitted. This variant is intended for modules that only implement a single feature, to avoid unnecessary nesting.
For identification of the single feature, the repository name or module name should be replicate the feature name.
<module_name>/ -> Folder containing all artifacts corresponding to one module. │ As folder optional if the repository only contains a single module. ├── docs/ -> Documentation of the module │ ├── architecture/ -> Feature architecture │ │ [wp__feature_arch], [wp__sw_arch_verification] │ ├── safety_analysis/ -> Safety analysis on feature level │ │ [wp__feature_fmea], [wp__feature_dfa] │ ├── safety_planning/ -> Feature specific safety workproducts planning │ │ [wp__platform_safety_plan] │ ├── security_analysis/ -> Security analysis on feature level │ │ [wp__feature_security_analysis] │ ├── security_planning/ -> Feature specific security workproducts planning │ │ [wp__platform_security_plan] │ ├── manuals/ -> Module manual, e.g. integration manual, assumptions of use, │ │ safety manual [wp__requirements_comp_aou], │ │ [wp__requirements_feat_aou], │ │ [wp__module_safety_manual], │ │ security_manual [wp__module_security_manual]. │ ├── release/ -> Module release note [wp__module_sw_release_note], │ │ module release plan [wp__module_sw_release_plan], │ ├── safety_mgt/ -> Module safety plan [wp__module_safety_plan], │ │ module safety package [wp__module_safety_package], │ │ formal documents reviews [wp__fdr_reports], │ │ safety analysis formal reviews [wp__fdr_reports], │ │ safety tailoring [wp__safety_tailoring] │ │ safety component classification [wp__sw_component_class] │ ├── security_mgt/ -> Module security plan [wp__module_security_plan], │ │ module security package [wp__module_security_package], │ │ formal documents reviews [wp__fdr_reports_security], │ │ module SW bill of material [wp__sw_module_sbom] │ └── verification_report/ -> Module verification report │ module verifications [wp__verification_module_ver_report], └── score/ -> Folder containing all artifacts corresponding to the components of the module. ├── <component_name>/ -> Components of the module. │ │ Folder containing all artifacts corresponding to one component. │ ├── docs/ -> Documentation of the component │ │ ├── architecture/ -> Component architecture (only if lower level components exist) │ │ │ [wp__component_arch]. │ │ ├── detailed_design/ -> Detailed Design [wp__sw_implementation] and │ │ │ Detail design + code inspection [wp__sw_implementation_inspection], │ │ ├── manuals/ -> User documentation of a single component │ │ │ (e.g., user manual of a library, optional) │ │ ├── requirements/ -> Component requirements [wp__requirements_comp], │ │ │ requirements inspection [wp__requirements_inspect] │ │ ├── safety_analysis/ -> Safety analysis on component level (only if component architecture exists) │ │ │ [wp__sw_component_fmea], [wp__sw_component_dfa] │ │ └── security_analysis/ -> Security analysis on component level (only if component architecture exists) │ └── src/ -> Source files of the component consisting of │ │ Include and source Files [wp__sw_implementation] │ │ Test doubles │ │ Unit tests [wp__verification_sw_unit_test] │ ├── <lower_level_comp>/ -> lower level component following <component_name> folder structure │ └── tests/ -> Component-level tests (e.g., unit tests) │ [wp__verification_sw_unit_test] └── tests/ -> Module-level tests (e.g., feature integration tests, system tests) [wp__verification_comp_int_test] Feature Integration tests [wp__verification_feat_int_test]
Module / Feature Documentation#
Component documentation#
Examples#
Quick Start#
To build the module:
bazel build //src/...
To run all tests:
bazel test //...
To run Unit Tests:
bazel test //src/...
To run Component / Feature Integration Tests:
bazel test //tests/...
Module Configuration#
The project_config.bzl file defines metadata used by Bazel macros.
Example:
PROJECT_CONFIG = {
"asil_level": "QM",
"source_code": ["cpp", "rust"]
}
This enables conditional behavior (e.g., choosing clang-tidy for C++ or clippy for Rust).