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..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 @@ -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 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 abc931eb80b..ab361304459 100644 --- a/docs/safety/platform_safety_manual.rst +++ b/docs/safety/platform_safety_manual.rst @@ -34,6 +34,17 @@ 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, 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 +safety lifecycle and shall be developed, verified, and released according to +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. + Assumed Platform Safety Requirements ------------------------------------ @@ -93,6 +104,23 @@ 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. +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 ----------------