From 7739198470fc89aed3f8a4ca4d0b8a5981d00b48 Mon Sep 17 00:00:00 2001 From: "Negm Adham (ETAS-ECM/ESY3)" Date: Thu, 23 Jul 2026 14:19:47 +0200 Subject: [PATCH 1/7] Add FFI approach to platform safety manual --- docs/safety/platform_safety_manual.rst | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/docs/safety/platform_safety_manual.rst b/docs/safety/platform_safety_manual.rst index abc931eb80b..a01f5435d8a 100644 --- a/docs/safety/platform_safety_manual.rst +++ b/docs/safety/platform_safety_manual.rst @@ -34,6 +34,15 @@ 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. +A platform module may contain both ASIL-relevant and non-ASIL components. A component is in scope +of the ASIL safety lifecycle if it is intended to be executed from within an ASIL component. Such +components shall be developed, verified, and released according to the applicable ASIL safety +process. Components that are not intended to be executed from within an ASIL component may be +developed to QM, provided that freedom from interference with the safety context is justified in +the respective module safety manual. The logging module is an example: its +``mw::log`` frontend is linked into the caller and runs in the safety context ASIL_B, whereas its +``datarouter`` daemon runs as a separate process and is classified QM. + Assumed Platform Safety Requirements ------------------------------------ @@ -93,6 +102,14 @@ The S-CORE SW platform has no safety concept additional to its module's safety c 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. +A platform module may contain both ASIL-relevant and QM components. The ASIL classification is +determined at component level based on the execution context rather than at module level. +Components executing within a safety context are developed according to the applicable ASIL +process, while components outside the safety context may remain QM, provided that freedom from +interference is ensured and justified in the module safety manual. For example, the mw::log +frontend executes within the ASIL-B application and is therefore treated as ASIL-B, whereas the +datarouter daemon executes as a separate process and remains QM. + Safety Anomalies ---------------- From 92758d71a766c317d69018ed57d21b4f5155611a Mon Sep 17 00:00:00 2001 From: "Negm Adham (ETAS-ECM/ESY3)" Date: Wed, 29 Jul 2026 18:52:10 +0200 Subject: [PATCH 2/7] Update FFI Approach --- docs/safety/platform_safety_manual.rst | 39 ++++++++++++++++---------- 1 file changed, 24 insertions(+), 15 deletions(-) diff --git a/docs/safety/platform_safety_manual.rst b/docs/safety/platform_safety_manual.rst index a01f5435d8a..6a2f40a0f94 100644 --- a/docs/safety/platform_safety_manual.rst +++ b/docs/safety/platform_safety_manual.rst @@ -34,14 +34,14 @@ 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. -A platform module may contain both ASIL-relevant and non-ASIL components. A component is in scope -of the ASIL safety lifecycle if it is intended to be executed from within an ASIL component. Such -components shall be developed, verified, and released according to the applicable ASIL safety -process. Components that are not intended to be executed from within an ASIL component may be -developed to QM, provided that freedom from interference with the safety context is justified in -the respective module safety manual. The logging module is an example: its -``mw::log`` frontend is linked into the caller and runs in the safety context ASIL_B, whereas its -``datarouter`` daemon runs as a separate process and is classified QM. +A platform module may contain both ASIL-relevant and QM components. The +classification is performed at component level and depends on the intended +execution context rather than on the module as a whole. Components that are +intended to execute within an ASIL context are in scope of the applicable ASIL +safety lifecycle and shall be developed, verified, and released according to +the corresponding ASIL process. Components that are not intended to execute +within an ASIL context may remain QM, provided that freedom from interference +with the safety context is justified in the respective module safety manual. Assumed Platform Safety Requirements ------------------------------------ @@ -102,13 +102,22 @@ The S-CORE SW platform has no safety concept additional to its module's safety c 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. -A platform module may contain both ASIL-relevant and QM components. The ASIL classification is -determined at component level based on the execution context rather than at module level. -Components executing within a safety context are developed according to the applicable ASIL -process, while components outside the safety context may remain QM, provided that freedom from -interference is ensured and justified in the module safety manual. For example, the mw::log -frontend executes within the ASIL-B application and is therefore treated as ASIL-B, whereas the -datarouter daemon executes as a separate process and remains QM. +The platform allows ASIL and QM components to coexist within the same module. +Where components executing in an ASIL context depend on functionality that has +no direct safety purpose, freedom from interference shall be ensured between +the safety-relevant and non-safety-relevant parts. This may require additional +safety requirements to be allocated to components that otherwise only provide +QM functionality. Such requirements exist to preserve the integrity of the +safety context and are applied in addition to the component's functional +requirements. + +For example, the ``mw::log`` frontend is linked into and executed within an +ASIL-B application. Although logging functionality itself may only provide QM +services, the frontend forms part of the ASIL execution context and therefore +must fulfil additional safety requirements derived from the need to maintain +freedom from interference. In contrast, the ``datarouter`` daemon executes as a +separate process and may remain QM, provided that the required freedom from +interference is justified in the module safety manual. Safety Anomalies From 422afeae02bf8c30373401292bca02971812ce89 Mon Sep 17 00:00:00 2001 From: "Negm Adham (ETAS-ECM/ESY3)" Date: Thu, 30 Jul 2026 14:41:48 +0200 Subject: [PATCH 3/7] Add reference to No Mixed ASIL stakeholder requirement --- docs/safety/platform_safety_manual.rst | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/docs/safety/platform_safety_manual.rst b/docs/safety/platform_safety_manual.rst index 6a2f40a0f94..a4f34a643d8 100644 --- a/docs/safety/platform_safety_manual.rst +++ b/docs/safety/platform_safety_manual.rst @@ -39,9 +39,10 @@ classification is performed at component level and depends on the intended execution context rather than on the module as a whole. Components that are intended to execute within an ASIL context are in scope of the applicable ASIL safety lifecycle and shall be developed, verified, and released according to -the corresponding ASIL process. Components that are not intended to execute -within an ASIL context may remain QM, provided that freedom from interference -with the safety context is justified in the respective module safety manual. +the corresponding ASIL process, see :ref:`stkh_req__dependability__no_mixed_asil`. +Components that are not intended to executewithin an ASIL context may remain QM, +provided that freedom from interference with the safety context is justified in +the respective module safety manual. Assumed Platform Safety Requirements ------------------------------------ From 8772719f1a6346e58817ecf1b8b8fc6cc509e4e3 Mon Sep 17 00:00:00 2001 From: "Negm Adham (ETAS-ECM/ESY3)" Date: Thu, 30 Jul 2026 15:02:26 +0200 Subject: [PATCH 4/7] Add reference to ASIL/QM verification methods --- docs/safety/platform_safety_manual.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/safety/platform_safety_manual.rst b/docs/safety/platform_safety_manual.rst index a4f34a643d8..95e64311720 100644 --- a/docs/safety/platform_safety_manual.rst +++ b/docs/safety/platform_safety_manual.rst @@ -34,7 +34,8 @@ 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. -A platform module may contain both ASIL-relevant and QM components. The +A platform module may contain both ASIL-relevant and QM components, see :ref:`verification-methods` +for an overview of what is required for ASIL and QM components. The classification is performed at component level and depends on the intended execution context rather than on the module as a whole. Components that are intended to execute within an ASIL context are in scope of the applicable ASIL From 545128b93ada2b249e3204af5c414af01cb668d3 Mon Sep 17 00:00:00 2001 From: "Negm Adham (ETAS-ECM/ESY3)" Date: Thu, 30 Jul 2026 16:30:05 +0200 Subject: [PATCH 5/7] Fix Build Build Warnings --- .../lifecycle/architecture/launch_manager.rst | 2 +- docs/features/lifecycle/requirements/index.rst | 16 ++++++++-------- docs/modules/lifecycle/index.rst | 2 +- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/docs/features/lifecycle/architecture/launch_manager.rst b/docs/features/lifecycle/architecture/launch_manager.rst index 9c25f4cc101..386e82dc456 100644 --- a/docs/features/lifecycle/architecture/launch_manager.rst +++ b/docs/features/lifecycle/architecture/launch_manager.rst @@ -362,7 +362,7 @@ Dynamic architecture :status: valid :version: 1 :safety: ASIL_B - :fulfils: feat_req__lifecycle__monitoring_processes[version==1], feat_req__lifecycle__polling_interval[version==1], , feat_req__lifecycle__failure_detect[version==1] + :fulfils: feat_req__lifecycle__monitoring_processes[version==1], feat_req__lifecycle__polling_interval[version==1], feat_req__lifecycle__failure_detect[version==1] :includes: :belongs_to: feat__lifecycle[version==1] diff --git a/docs/features/lifecycle/requirements/index.rst b/docs/features/lifecycle/requirements/index.rst index b2618c36265..52a9a9e8c8d 100644 --- a/docs/features/lifecycle/requirements/index.rst +++ b/docs/features/lifecycle/requirements/index.rst @@ -384,7 +384,7 @@ Conditional Launching :security: NO :safety: ASIL_B :derived_from: stkh_req__execution_model__processes[version==1] - :status: invalid + :status: valid :version: 1 :valid_from: v1.0.0 @@ -650,7 +650,7 @@ Run targets :security: NO :safety: ASIL_B :derived_from: stkh_req__execution_model__processes[version==1] - :status: invalid + :status: valid :version: 1 :valid_from: v1.0.0 @@ -662,7 +662,7 @@ Run targets :security: NO :safety: ASIL_B :derived_from: stkh_req__execution_model__processes[version==1] - :status: invalid + :status: valid :version: 1 :valid_from: v1.0.0 @@ -802,7 +802,7 @@ Control Interface :security: NO :safety: ASIL_B :derived_from: stkh_req__execution_model__processes[version==1] - :status: invalid + :status: valid :version: 1 :valid_from: v1.0.0 @@ -844,7 +844,7 @@ Control Interface :security: NO :safety: ASIL_B :derived_from: stkh_req__execution_model__processes[version==1] - :status: invalid + :status: valid :version: 1 :valid_from: v1.0.0 @@ -942,7 +942,7 @@ Monitoring, Notification and Recovery :security: NO :safety: ASIL_B :derived_from: stkh_req__execution_model__processes[version==1] - :status: invalid + :status: valid :version: 1 :valid_from: v1.0.0 @@ -955,7 +955,7 @@ Monitoring, Notification and Recovery :security: NO :safety: ASIL_B :derived_from: stkh_req__execution_model__processes[version==1] - :status: invalid + :status: valid :version: 1 :valid_from: v1.0.0 @@ -968,7 +968,7 @@ Monitoring, Notification and Recovery :security: NO :safety: ASIL_B :derived_from: stkh_req__execution_model__processes[version==1] - :status: invalid + :status: valid :version: 1 :valid_from: v1.0.0 diff --git a/docs/modules/lifecycle/index.rst b/docs/modules/lifecycle/index.rst index 128b583a0e2..e8626688905 100644 --- a/docs/modules/lifecycle/index.rst +++ b/docs/modules/lifecycle/index.rst @@ -29,7 +29,7 @@ Lifecycle .. comp_req:: Lifecycle :id: comp_req__lifecycle__launch :reqtype: Functional - :status: invalid + :status: valid :version: 1 :security: NO :safety: ASIL_B From 48b2ae7be9a705c7cad6d27b985f4a5e784f93ce Mon Sep 17 00:00:00 2001 From: "Negm Adham (ETAS-ECM/ESY3)" Date: Thu, 30 Jul 2026 16:40:24 +0200 Subject: [PATCH 6/7] Fix Build Build Warning --- docs/features/lifecycle/requirements/index.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/features/lifecycle/requirements/index.rst b/docs/features/lifecycle/requirements/index.rst index 52a9a9e8c8d..b00eea0af65 100644 --- a/docs/features/lifecycle/requirements/index.rst +++ b/docs/features/lifecycle/requirements/index.rst @@ -24,7 +24,7 @@ Launching Processes :security: NO :safety: ASIL_B :derived_from: stkh_req__execution_model__processes[version==1] - :status: invalid + :status: valid :version: 1 :valid_from: v1.0.0 From 6915802e55074036853ad7b086a1d99b772d4ca1 Mon Sep 17 00:00:00 2001 From: "Negm Adham (ETAS-ECM/ESY3)" Date: Thu, 30 Jul 2026 17:27:25 +0200 Subject: [PATCH 7/7] Fix Broken references --- docs/platform_management_plan/software_verification.rst | 2 ++ docs/safety/platform_safety_manual.rst | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/platform_management_plan/software_verification.rst b/docs/platform_management_plan/software_verification.rst index a887ac8d669..5a99921df78 100644 --- a/docs/platform_management_plan/software_verification.rst +++ b/docs/platform_management_plan/software_verification.rst @@ -149,6 +149,8 @@ There are the following different levels of integration and verification defined Practically, this means S-CORE will implement Platform Integration Tests for stakeholder requirements for demonstration, but these are not intended to completely covering all stakeholder requirements. +.. _verification-methods: + Verification Methods -------------------- diff --git a/docs/safety/platform_safety_manual.rst b/docs/safety/platform_safety_manual.rst index 95e64311720..ab361304459 100644 --- a/docs/safety/platform_safety_manual.rst +++ b/docs/safety/platform_safety_manual.rst @@ -40,7 +40,7 @@ classification is performed at component level and depends on the intended execution context rather than on the module as a whole. Components that are intended to execute within an ASIL context are in scope of the applicable ASIL safety lifecycle and shall be developed, verified, and released according to -the corresponding ASIL process, see :ref:`stkh_req__dependability__no_mixed_asil`. +the corresponding ASIL process, see :need:`stkh_req__dependability__no_mixed_asil`. Components that are not intended to executewithin an ASIL context may remain QM, provided that freedom from interference with the safety context is justified in the respective module safety manual.