Folder Structure#
Platform Folder Structure#
The following shows the folder structure of the platform repository (ordered alphabetically). The ordering of the documentation in the rendered documentation can be in a different order.
docs/ -> Global documentation of the platform ├── architecture/ -> Platform architecture description [wp__platform_arch] ├── contribute/ -> Description on how to contribute │ [wp__sw_development_plan], │ [wp__training_path] ├── design_decision/ -> Design decisions on platform level ├── features/ -> All features of the platform. [wp__platform_arch] │ └── <feature_name>/ -> Features including feature id, logical interfaces and feature │ │ (change) request [wp__feat_request] and belonging sub-folders │ ├── architecture/ -> Feature architecture [wp__feature_arch] │ │ only feature id and logical interface definition │ │ (static and dynamic architecture only if the feature is not yet │ │ implemented by one module, otherwise the static and dynamic │ │ architecture is defined in the module repository) │ └── requirements/ -> Feature requirements [wp__requirements_feat] ├── glossary/ -> Glossary of abbreviations used in the platform context ├── handbook/ -> Background, scope, high-level architecture of the platform features │ and handbook for the platform [wp__platform_handbook], │ (e.g., onboarding, development guidelines, etc.) ├── manuals/ -> User and integration manual(s) of the platform, │ may refer in the reference integration repository to the manuals for the modules. ├── platform_management_plan/ -> Overall Platform Management Plan [wp__platform_mgmt] │ containing: [wp__project_mgt], [wp__platform_safety_plan], │ [wp__platform_security_plan], [wp__qms_plan], │ [wp__config_mgt_plan], [wp__tlm_plan], │ [wp__platform_sw_release_plan], [wp__prm_plan], │ [wp__chm_plan], │ [wp__verification_plan], [wp__document_mgt_plan], │ [wp__issue_track_system] (mentioned), │ [wp__policies], [wp__tailoring_work_products] │ [wp__safety_tailoring] │ also mention [wp__process_description] and [wp__process_strategy] ├── quality/ -> Quality documentation on platform level: [wp__qms_report], │ [wp__process_impr_report] ├── requirements/ -> Requirements on platform level │ ├── stakeholder/ -> Stakeholder requirements [wp__requirements_stkh] │ ├── tool/ -> Tool requirements (not covered in tool repositories) │ │ [wp__requirements_proc_tool] │ └── platform_assumptions/ -> Assumptions of use on platform level [wp__requirements_sw_platform_aou] ├── safety/ -> Safety documentation on platform level (SEooC): │ [wp__platform_dfa], [wp__platform_safety_manual], │ [wp__platform_safety_package], [wp__fdr_reports], │ [wp__audit_report] ├── score_tools/ -> Tool list and [wp__tool_verification_report] ├── security/ -> Security documentation on platform level: │ [wp__platform_security_manual], [wp__platform_security_package], │ [wp__sw_platform_sbom], [wp__platform_security_analysis], │ [wp__audit_report_security] └── tools/ -> Platform tools (not covered in tool repositories) └── decision_records/ -> Design decision records for tools on platform level README.md -> Entrypoint of the repository
Reference Integration Repository Folder Structure#
The reference integration repository (see reference_integration) integrates multiple Eclipse S-CORE modules into a single Bazel build environment to validate cross-repository builds and detect integration issues early in the development cycle.
bazel_common/ -> Common Bazel functionalities shared across images:
toolchain setups, common tooling deps,
common S-CORE module deps, common .bzl extensions
ci/ -> CI configuration and scripts
cli/ -> CLI tool running on the target to guide users through examples
docs/ -> Documentation of the reference integration
├── score_releases/ -> [wp__platform_sw_release_note]
└── verification_report/ -> Platform verification report (reporting all platform feature's verifications)
[wp__verification_platform_ver_report]
images/ -> Concrete images for each target platform as Bazel modules.
Each platform has its own folder named platform_arch,
e.g. qnx_aarch64, autosd_x86_64, ebclfsa_aarch64,
linux_x86_64. Each image deploys all showcases and
contains platform-specific code.
known_good.json -> Pinned versions of all integrated S-CORE modules
patches/ -> Patches applied during the build
platform_integration_tests/ -> Integration tests on reference hardware verifying stakeholder requirements.
[wp__verification_platform_int_test]
A further subfolder structuring (for example by feature or stakeholder area) is possible.
runners/ -> Thin logic to reuse runners (e.g. docker runner) between images
rust_coverage/ -> Rust coverage configuration
scripts/ -> Internal tooling scripts (known_good management,
│ workspace metadata generation, etc.)
└── tooling/ -> Single point of interaction with all tooling artifacts
showcases/ -> S-CORE wide showcases deployed into images
score_starter -> Launcher script to select and run an integration scenario
MODULE.bazel -> Bazel module definition
README.md -> Entrypoint of the repository
Module Folder Structure#
The modules and components shall follow the folder structure which was presented. This is confirmed by Module Folder Structure (dec_rec__platform__module_folder_structure).
For more details on the folder structure of a module see module template repository .
<module_name>/ -> Folder containing all artifacts corresponding to one module. │ As folder optional if the repository only contains a single module. ├── .github/ -> GitHub configuration │ └── workflows/ -> CI/CD pipelines ├── 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], [wp__requirements_feat_aou] │ │ ├── safety_planning/ -> Feature specific safety workproducts planning │ │ │ [wp__platform_safety_plan] │ │ ├── security_analysis/ -> Security analysis on feature level │ │ │ [wp__feature_security_analysis], [wp__requirements_feat_aou] │ │ └── security_planning/ -> Feature specific security workproducts planning │ │ [wp__platform_security_plan] │ ├── module/ -> Module documentation │ | ├── 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]. │ │ | │ -> Additional optional user centric documentation (e.g. configuration guide, │ │ | │ examples user guide, APIs & usage, performance analysis) │ │ | ├── config/ -> Configuration guide (optional) │ │ | ├── examples/ -> Examples user guide (optional) │ │ | ├── api_description/ -> API detail description (optional) │ │ | └── performance/ -> Performance analysis (optional) │ | ├── 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. │ │ | -> Source files of the component consisting of │ │ | Include and source Files [wp__sw_implementation] │ │ | Unit tests [wp__verification_sw_unit_test] │ │ ├── <lower_level_comp>/ -> lower level component following <component_name> folder structure │ │ ├── docs/ -> Documentation of the component │ │ │ ├── architecture/ -> Component architecture (only if lower level components exist) │ │ │ │ [wp__component_arch], [wp__sw_arch_verification]. │ │ │ ├── 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) │ │ │ │ (could contain optional subfolders for configuration guide, │ │ │ │ examples user guide, APIs & usage, performance analysis, see module manual folder) │ │ │ ├── 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], [wp__requirements_comp_aou] │ │ │ │ component classification [wp__sw_component_class] for pre-existing software │ │ │ └── security_analysis/ -> Security analysis on component level (only if component architecture exists) │ │ │ [wp__sw_component_security_analysis], [wp__requirements_comp_aou] │ │ └── tests/ -> Component-level tests (e.g., integration tests) │ │ [wp__verification_comp_int_test] │ └── tests/ -> Module-level tests (e.g., feature integration tests, system tests) │ [wp__verification_feat_int_test] ├── MODULE.bazel -> Bazel module definition ├── BUILD -> Root build rules ├── project_config.bzl -> Project metadata used by Bazel macros └── README.md -> Entry point of the repository
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 still advised for similar documentation structure.
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. ├── .github/ -> GitHub configuration │ └── workflows/ -> CI/CD pipelines ├── docs/ -> Documentation of the module │ ├── features/ -> Feature folder parts for each feature which should be in module documentation │ | ├── architecture/ -> Feature architecture │ | │ [wp__feature_arch], [wp__sw_arch_verification] │ | ├── safety_analysis/ -> Safety analysis on feature level │ | │ [wp__feature_fmea], [wp__feature_dfa], [wp__requirements_feat_aou] │ | ├── safety_planning/ -> Feature specific safety workproducts planning │ | │ [wp__platform_safety_plan] │ | ├── security_analysis/ -> Security analysis on feature level │ | │ [wp__feature_security_analysis], [wp__requirements_feat_aou] │ | └── security_planning/ -> Feature specific security workproducts planning │ │ [wp__platform_security_plan] │ ├── module/ -> Module documentation │ | ├── 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]. │ │ | │ -> Additional optional user centric documentation (e.g. configuration guide, │ │ | │ examples user guide, APIs & usage, performance analysis) │ │ | ├── config/ -> Configuration guide (optional) │ │ | ├── examples/ -> Examples user guide (optional) │ │ | ├── api_description/ -> API detail description (optional) │ │ | └── performance/ -> Performance analysis (optional) │ | ├── 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. │ │ | -> Source files of the component consisting of │ │ | Include and source Files [wp__sw_implementation] │ │ | Unit tests [wp__verification_sw_unit_test] │ │ ├── <lower_level_comp>/ -> lower level component following <component_name> folder structure │ │ ├── docs/ -> Documentation of the component │ │ │ ├── architecture/ -> Component architecture (only if lower level components exist) │ │ │ │ [wp__component_arch], [wp__sw_arch_verification]. │ │ │ ├── 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) │ │ │ │ (could contain optional subfolders for configuration guide, │ │ │ │ examples user guide, APIs & usage, performance analysis, see module manual folder) │ │ │ ├── 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], [wp__requirements_comp_aou] │ │ │ │ component classification [wp__sw_component_class] for pre-existing software │ │ │ └── security_analysis/ -> Security analysis on component level (only if component architecture exists) │ │ │ [wp__sw_component_security_analysis], [wp__requirements_comp_aou] │ │ └── tests/ -> Component-level tests (e.g. integration tests) │ │ [wp__verification_comp_int_test] │ └── tests/ -> Module-level tests (e.g. feature integration test) │ [wp__verification_feat_int_test] ├── MODULE.bazel -> Bazel module definition ├── BUILD -> Root build rules ├── project_config.bzl -> Project metadata used by Bazel macros └── README.md -> Entry point of the repository