From c18c39a9566c709426b1cb8dfb0736e3975a4528 Mon Sep 17 00:00:00 2001 From: aschemmel-git Date: Wed, 25 Mar 2026 13:43:11 +0100 Subject: [PATCH] Platform Safety Manual Updates Resolves: #2715 --- .../safety_management.rst | 25 ++++--- .../platform_assumptions/index.rst | 38 +++++++--- docs/safety/platform_safety_manual.rst | 75 ++++++++++++------- 3 files changed, 88 insertions(+), 50 deletions(-) diff --git a/docs/platform_management_plan/safety_management.rst b/docs/platform_management_plan/safety_management.rst index af660e1a3f0..233435cfeaa 100644 --- a/docs/platform_management_plan/safety_management.rst +++ b/docs/platform_management_plan/safety_management.rst @@ -357,7 +357,7 @@ Functional Safety/Security Management SW Platform Work Products * - :need:`wp__process_description` - :ndf:`copy('status', need_id='wf__def_app_process_description')` - `Process description `_ - - Maturity Level 1 + - Maturity Level 1-2 * - :need:`wp__process_impr_report` - :ndf:`copy('status', need_id='wf__mon_imp_process_description')` @@ -366,7 +366,7 @@ Functional Safety/Security Management SW Platform Work Products * - :need:`wp__process_strategy` - :ndf:`copy('status', need_id='wf__cr_mt_process_mgt_strategy')` - - `Process community planning `_ + - `Process development community planning `_ - see planning board * - :need:`wp__platform_handbook` @@ -382,7 +382,7 @@ Functional Safety/Security Management SW Platform Work Products * - :need:`wp__verification_platform_ver_report` - :ndf:`copy('status', need_id='wf__verification_platform_ver_report')` - :need:`doc__score_platform_verification_report` - - draft + - :ndf:`copy('status', need_id='doc__score_platform_verification_report')` * - :need:`wp__requirements_stkh` - :ndf:`copy('status', need_id='wf__req_stkh_req')` @@ -406,8 +406,8 @@ Functional Safety/Security Management SW Platform Work Products * - :need:`wp__tool_verification_report` - :ndf:`copy('status', need_id='wf__tool_create_tool_verification_report')` - - :ref:`tools` - - see WP link + - :need:`doc__tool_evaluation_list` + - :ndf:`copy('status', need_id='doc__tool_evaluation_list')` Functional Safety Specific SW Platform Work Products @@ -434,40 +434,41 @@ Functional Safety Specific SW Platform Work Products * - :need:`wp__fdr_reports` (platform Safety Plan) - :ndf:`copy('status', need_id='wf__p_formal_rv')` - :need:`doc__score_platform_safety_plan_fdr` - - draft + - :ndf:`copy('status', need_id='doc__score_platform_safety_plan_fdr')` * - :need:`wp__fdr_reports` (platform Safety Package) - :ndf:`copy('status', need_id='wf__p_formal_rv')` - :need:`doc__score_platform_safety_package_fdr` - - draft + - :ndf:`copy('status', need_id='doc__score_platform_safety_package_fdr')` * - :need:`wp__fdr_reports` (feature's Safety Analyses & DFA) - :ndf:`copy('status', need_id='wf__p_formal_rv')` - :need:`doc__score_platform_safety_analysis_fdr` - - draft + - :ndf:`copy('status', need_id='doc__score_platform_safety_analysis_fdr')` * - :need:`wp__audit_report` - performed by external experts - - + - `Audit findings `_ - intermediate * - :need:`wp__platform_dfa` - :ndf:`copy('status', need_id='wf__analyse_platform_featarch')` - :need:`doc__platform_dfa` - - draft + - :ndf:`copy('status', need_id='doc__platform_dfa')` * - :need:`wp__platform_safety_manual` - :ndf:`copy('status', need_id='wf__cr_mt_safety_manual')` - :need:`doc__score_platform_safety_manual` - - draft + - :ndf:`copy('status', need_id='doc__score_platform_safety_manual')` * - :need:`wp__safety_tailoring` (generic) - :ndf:`copy('status', need_id='wf__def_app_process_description')` - :need:`wp__tailoring_work_products` & :need:`doc__score_platform_safety_plan` - - valid + - :ndf:`copy('status', need_id='wp__tailoring_work_products')` Process status: Status of the workflow which "outputs" the work product, derived from the docs it "has" and guidances it "contains". +Link to project planning: `Platform safety work product issue for V1.0 `_ Platform Management Plan - Feature Work Product Lists ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/docs/requirements/platform_assumptions/index.rst b/docs/requirements/platform_assumptions/index.rst index 51554d28adb..04635b380fb 100644 --- a/docs/requirements/platform_assumptions/index.rst +++ b/docs/requirements/platform_assumptions/index.rst @@ -45,6 +45,7 @@ Note that the "supplier" AoUs were created with an OS supplier in mind but are r :security: NO :safety: QM :status: valid + :tags: environment The system integrator shall use an operating system compliant with IEEE Std 1003.1 (2004 Edition or newer) @@ -61,7 +62,7 @@ It also contains expectations towards an supplier which can be used as criteria by the system integrator. Building and running of external SW element is enabled, but no pro-active support from S-CORE is provided for e.g. build or test problems. No guarantees that S-CORE builds or runs with the external SW element. -.. aou_req:: integration assistance +.. aou_req:: Integration assistance :id: aou_req__platform__integration_assistance :reqtype: Non-Functional :security: YES @@ -70,7 +71,7 @@ is provided for e.g. build or test problems. No guarantees that S-CORE builds or The supplier shall provide a contact point for integration assistance. -.. aou_req:: integration manual +.. aou_req:: Integration manual :id: aou_req__platform__os_integration_manual :reqtype: Non-Functional :security: YES @@ -79,7 +80,7 @@ is provided for e.g. build or test problems. No guarantees that S-CORE builds or The supplier shall provide an integration manual. -.. aou_req:: bug interface +.. aou_req:: Bug interface :id: aou_req__platform__bug_interface :reqtype: Non-Functional :security: YES @@ -99,7 +100,7 @@ Functional Level This is the middle level of integraton, the higher level will build on this. It is the level where the S-CORE SW-platform will functionally "work" with the external SW element. -.. aou_req:: bazel tooling +.. aou_req:: Bazel tooling :id: aou_req__platform__bazel_tooling :reqtype: Non-Functional :security: YES @@ -109,7 +110,7 @@ It is the level where the S-CORE SW-platform will functionally "work" with the e The supplier shall provide tools for Bazel to be able to build the S-CORE SW-platform with the external SW element and support the run and test of the S-CORE SW-platform. -.. aou_req:: bug fixing +.. aou_req:: Bug fixing :id: aou_req__platform__bug_fixing :reqtype: Non-Functional :security: YES @@ -126,6 +127,7 @@ It is the level where the S-CORE SW-platform will functionally "work" with the e :security: YES :safety: QM :status: valid + :tags: user The system integrator shall run the tests provided by S-CORE (platform, feature, component and Unit level for their selected S-CORE modules) on their selected OS/Hypervisor/HW combination, or provide equivalent argumentation. @@ -140,6 +142,7 @@ It is the level where the S-CORE SW-platform will functionally "work" with the e :security: YES :safety: QM :status: valid + :tags: user The system integrator shall report the bugs found during integration of the S-CORE SW-platform on their selected OS/Hypervisor/HW combination to the external SW element supplier and S-CORE for analysis. @@ -148,18 +151,19 @@ Certifiable Level This is the highest level of integraton. This is the level where the S-CORE SW-platform will be certifiable with an external SW element. -.. aou_req:: integration levels +.. aou_req:: Integration levels :id: aou_req__platform__levels :reqtype: Non-Functional :security: YES :safety: ASIL_B :status: valid + :tags: user The supplier and system integrator shall fulfill all the levels AoUs in a safe way (i.e. the "safety" attribute will be raised to the level in this AoU). Note: This includes for example :need:`aou_req__platform__bazel_tooling`, :need:`aou_req__platform__bug_fixing` -.. aou_req:: safety AoU +.. aou_req:: Safety AoU :id: aou_req__platform__safety_aou :reqtype: Non-Functional :security: YES @@ -170,7 +174,7 @@ This is the highest level of integraton. This is the level where the S-CORE SW-p Note: This may be part of an external SW element's safety manual. -.. aou_req:: safety functions +.. aou_req:: Safety functions :id: aou_req__platform__safety_functions :reqtype: Non-Functional :security: YES @@ -179,7 +183,7 @@ This is the highest level of integraton. This is the level where the S-CORE SW-p The supplier shall provide a list of safe external SW element functions. -.. aou_req:: safety anomaly reporting +.. aou_req:: Safety anomaly reporting :id: aou_req__platform__safety_anomaly :reqtype: Non-Functional :security: YES @@ -190,12 +194,13 @@ This is the highest level of integraton. This is the level where the S-CORE SW-p Note: This could be fulfilled by listing per release version all known and user reported bugs which affect the safe external SW element functions. -.. aou_req:: safety matching +.. aou_req:: Safety matching :id: aou_req__platform__safety_matching :reqtype: Non-Functional :security: YES :safety: ASIL_B :status: valid + :tags: user If the system using the SW-platform has safety goals, the system integrator shall integrate the SW-platform with external SW elements providing safety functions. This includes to make sure that the safety functions S-CORE SW-platform requires match with the ones provided by these external SW elements (as in :need:`aou_req__platform__safety_functions`). @@ -206,12 +211,13 @@ This is the highest level of integraton. This is the level where the S-CORE SW-p Note3: This applies also if the system integrator would replace a S-CORE SW-platform element with another SW element which is external to S-CORE. -.. aou_req:: safety integration +.. aou_req:: Safety integration :id: aou_req__platform__safety_integration :reqtype: Non-Functional :security: YES :safety: ASIL_B :status: valid + :tags: user If the system using the SW-platform has safety goals, the system integrator shall make sure that the AoUs relevant for external SW element safety functions (as in :need:`aou_req__platform__safety_aou`) are fulfilled by the S-CORE SW-platform. @@ -227,6 +233,7 @@ This is the highest level of integraton. This is the level where the S-CORE SW-p :security: YES :safety: ASIL_B :status: valid + :tags: user If the system using the SW-platform has safety goals, the system integrator shall check for correctness and completeness of SW-platform testing and add verification where needed. @@ -239,6 +246,7 @@ This is the highest level of integraton. This is the level where the S-CORE SW-p :security: YES :safety: ASIL_B :status: valid + :tags: user If the system using the SW-platform has safety goals, the system integrator shall perform safety anomaly reporting taking into account also the reporting of all the components they integrate. @@ -257,6 +265,7 @@ In this section assumptions are described which need to be fulfilled by the appl :security: YES :safety: ASIL_B :status: valid + :tags: user All applications using the SW-platform shall not handle exceptions. @@ -269,6 +278,7 @@ In this section assumptions are described which need to be fulfilled by the appl :security: YES :safety: ASIL_B :status: valid + :tags: user Safety applications using the SW-platform shall read error information from the requested S-CORE functions and perform an appropriate reaction. @@ -281,6 +291,7 @@ In this section assumptions are described which need to be fulfilled by the appl :security: YES :safety: ASIL_B :status: valid + :tags: user Safety application components running in one POSIX process shall implement the highest ASIL of their assigned requirements. @@ -290,6 +301,7 @@ In this section assumptions are described which need to be fulfilled by the appl :security: YES :safety: ASIL_B :status: valid + :tags: user Safety applications using the SW-platform shall use program flow monitoring to detect run time errors or explain in their safety concept why they do not need this. @@ -309,6 +321,7 @@ In this section assumptions are described which need to be fulfilled by the syst :security: YES :safety: ASIL_B :status: valid + :tags: environment If the system using the SW-platform has safety goals, the system shall provide state-of-the art hardware safety mechanisms, namely @@ -328,6 +341,7 @@ In this section assumptions are described which need to be fulfilled by the syst :security: YES :safety: ASIL_B :status: valid + :tags: environment If the system using the SW-platform has safety goals, the system shall provide an external health management element which is able to initiate a safe system state. @@ -339,6 +353,7 @@ In this section assumptions are described which need to be fulfilled by the syst :security: YES :safety: ASIL_B :status: valid + :tags: environment If the system using the SW-platform has safety goals, the used operating system shall offer POSIX processes isolation. This shall cover memory isolation. Timing isolation may be covered. @@ -349,6 +364,7 @@ In this section assumptions are described which need to be fulfilled by the syst :security: YES :safety: ASIL_B :status: valid + :tags: environment If the system using the SW-platform has safety goals, the used os module shall offer the following safety related functions: diff --git a/docs/safety/platform_safety_manual.rst b/docs/safety/platform_safety_manual.rst index 03ba5170ce6..cdde6e3d2a3 100644 --- a/docs/safety/platform_safety_manual.rst +++ b/docs/safety/platform_safety_manual.rst @@ -22,70 +22,91 @@ Platform Safety Manual :safety: ASIL_B :security: NO :realizes: wp__module_safety_manual - :tags: Introduction/Scope ------------------ -| This Safety Manual applies to the S-CORE Platform + +This safety manual applies to the S-CORE SW platform, defined by its modules, see :ref:`modules` +It covers all assumed (Technical) Safety Requirements of the S-CORE SW platform and all general +Assumptions of Use which are relevant for all users of any platform module. +The specific Assumptions of Use relevant only for the users of a specific module are documented in the module's safety manual. +That means that the platform safety manual always has to be read together with all its modules safety manuals. Assumed Platform Safety Requirements ------------------------------------ -| For the S-CORE Platformhe following safety related stakeholder requirements are assumed to define the top level functionality (purpose) of the S-CORE Platform. I.e. from these all the feature and component requirements implemented are derived. -| **** + +For the S-CORE Platform the following functional safety related stakeholder requirements are assumed to define the top level functionality (purpose) of the S-CORE Platform. I.e. from these all the feature and component requirements implemented are derived. + +.. needtable:: Assumed Platform Safety Requirements + :filter: type == "stkh_req" and is_external == False and safety == "ASIL_B" and reqtype == "Functional" + :style: table + :columns: title; id; status; safety + :colwidths: 30,30,15,15 Assumptions of Use ------------------ Assumptions on the Environment ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -| Generally the assumption of the project platform SEooC is that it is integrated in a safe system, i.e. the POSIX OS it runs on is qualified and also the HW related failures are taken into account by the system integrator, if not otherwise stated in the module's safety concept. -| **** -List of AoUs expected from the environment the platform / module runs on: +Generally the assumption of the project platform SEooC is that it is integrated in a safe system, i.e. the POSIX OS it runs on is qualified and also the HW related failures are taken into account by the system integrator, if not otherwise stated in the module's safety concept. + +**** + +List of AoUs expected from the environment the platform runs on: .. needtable:: + :filter: docname is not None and "platform" in docname and "assumptions" in docname :style: table + :types: aou_req + :tags: environment :columns: title;id;status :colwidths: 25,25,25 :sort: title - results = [] - - for need in needs.filter_types(["aou_req"]): - if need and "environment" in need["tags"]: - results.append(need) - Assumptions on the User ^^^^^^^^^^^^^^^^^^^^^^^ -| As there is no assumption on which specific OS and HW is used, the integration testing of the stakeholder and feature requirements is expected to be performed by the user of the platform SEooC. Tests covering all stakeholder and feature requirements performed on a reference platform (tbd link to reference platform specification), reviewed and passed are included in the platform SEooC safety package. -| Additionally the components of the platform may have additional specific assumptions how they are used. These are part of every module documentation: . Assumptions from components to their users can be fulfilled in two ways: -| 1. There are assumption which need to be fulfilled by all SW components, e.g. "every user of an IPC mechanism needs to make sure that he provides correct data (including appropriate ASIL level)" - in this case the AoU is marked as "platform". -| 2. There are assumption which can be fulfilled by a safety mechanism realized by some other project platform component and are therefore not relevant for an user who uses the whole platform. But those are relevant if you chose to use the module SEooC stand-alone - in this case the AoU is marked as "module". An example would be the "JSON read" which requires "The user shall provide a string as input which is not corrupted due to HW or QM SW errors." - which is covered when using together with safe project platform persistency feature. + +As there is no assumption on which specific OS and HW is used, the integration testing of the stakeholder and feature requirements is expected to be performed by the user of the platform SEooC. Tests covering all stakeholder and feature requirements performed on a reference platform (tbd link to reference platform specification), reviewed and passed are included in the platform SEooC safety package. +Additionally the components of the platform may have additional specific assumptions how they are used. These are part of every module documentation: . Assumptions from components to their users can be fulfilled in two ways: + +1. There are assumption which need to be fulfilled by all SW components, e.g. "every user of an IPC mechanism needs to make sure that he provides correct data (including appropriate ASIL level)" - in this case the AoU is marked as "platform". +2. There are assumption which can be fulfilled by a safety mechanism realized by some other project platform component and are therefore not relevant for an user who uses the whole platform. But those are relevant if you chose to use the module SEooC stand-alone - in this case the AoU is marked as "module". An example would be the "JSON read" which requires "The user shall provide a string as input which is not corrupted due to HW or QM SW errors." - which is covered when using together with safe project platform persistency feature. List of AoUs on the user of the platform features or the module of this safety manual: .. needtable:: + :filter: docname is not None and "platform" in docname and "assumptions" in docname :style: table + :types: aou_req + :tags: user :columns: title;id;status :colwidths: 25,25,25 :sort: title - results = [] - - for need in needs.filter_types(["aou_req"]): - if need and "environment" not in need["tags"]: - results.append(need) - Safety concept of the SEooC --------------------------- -| **** + +The S-CORE SW platform has no safety concept additional to its module's safety concept, as it does not implement additional functionality. +The expectations towards the execution environment are described in the respective AoU, this is mainly that a safe posix operating system +integrated into a target hardware which includes safety mechanisms which cover hardware related errors. + Safety Anomalies ---------------- -| Anomalies (bugs in ASIL SW, detected by testing or by users, which could not be fixed) known before release are documented in the platform/module release notes . + +Anomalies (bugs in ASIL SW, detected by testing or by users, which could not be fixed) known before release are documented in the platform/module release notes . References ---------- -| **** -| **** + +:need:`doc__platform_handbook` + +`Baselibs Safety Manual `_ + +`IPC Safety Manual `_ + +`FEO Safety Manual `_ + +`KVS Safety Manual `_