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 ├── 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) ├── modules/ -> Modules of the SW platform. [wp__platform_arch] ├── 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_releases/ -> [wp__platform_sw_release_note] ├── 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] ├── verification_report/ -> Platform verification report (reporting all platform feature's verifications) │ [wp__verification_platform_ver_report] └── 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
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]
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.)
showcases/ -> S-CORE wide showcases deployed into images
score_starter -> Launcher script to select and run an integration scenario
tooling/ -> Single point of interaction with all tooling artifacts
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. However if there are good reasons the structure can be adapted.
See also module template repository for more details on the folder structure of a module.
<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]