Platform Safety Manual#

Platform Safety Manual		status: draft security: NO safety: ASIL_B
version: 1 realizes: wp__module_safety_manual

doc__score_platform_safety_manual		Generic Document

Introduction/Scope#

This safety manual applies to the S-CORE SW platform, defined by its modules, see 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.

A platform module may contain both ASIL-relevant and QM components, see 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 No mixed ASIL (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#

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.

Assumed Platform Safety Requirements#
Title	ID	Status	Safety
Support for Safety-Critical ML	stkh_req__ai_platform__safety_critical	valid	ASIL_B
Support for Time-based Architectures	stkh_req__app_architectures__support_time	valid	ASIL_B
Safe Communication	stkh_req__communication__safe	valid	ASIL_B
Automotive Safety Integrity Level	stkh_req__dependability__automotive_safety	valid	ASIL_B
SW-platform error reaction	stkh_req__dependability__error_reaction	valid	ASIL_B
Error report timing	stkh_req__dependability__error_report_timing	valid	ASIL_B
Program Flow Monitoring	stkh_req__dependability__flow_monitoring	valid	ASIL_B
No mixed ASIL	stkh_req__dependability__no_mixed_asil	valid	ASIL_B
Safe SW-platform state	stkh_req__dependability__safe_state	valid	ASIL_B
Health Management	stkh_req__dependability__safety_features_1	valid	ASIL_B
External Supervision	stkh_req__dependability__safety_features_10	valid	ASIL_B
Safe Mode Switch	stkh_req__dependability__safety_features_11	valid	ASIL_B
E2E Protection	stkh_req__dependability__safety_features_2	valid	ASIL_B
HW Self-Test	stkh_req__dependability__safety_features_3	valid	ASIL_B
Safe Startup and Reset	stkh_req__dependability__safety_features_4	valid	ASIL_B
DMA Protection	stkh_req__dependability__safety_features_5	valid	ASIL_B
Memory Protection	stkh_req__dependability__safety_features_6	valid	ASIL_B
Cache Protection	stkh_req__dependability__safety_features_7	valid	ASIL_B
Memory Error Correction	stkh_req__dependability__safety_features_8	valid	ASIL_B
SW Lockstep	stkh_req__dependability__safety_features_9	valid	ASIL_B
Safe Computation	stkh_req__functional_req__safe_comput	valid	ASIL_B
Safe Configuration	stkh_req__functional_req__safe_config	valid	ASIL_B
Support of safe Key/Value store	stkh_req__functional_req__support_of_store	valid	ASIL_B
Action Safety and Governance	stkh_req__gen_ai__safety_filter	valid	ASIL_B
Seamless Integration with Vehicle Systems	stkh_req__gen_ai__vehicle_com	valid	ASIL_B

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 here all the OS calls the project platform expects to be safe.>

List of AoUs expected from the environment the platform runs on:

Title	ID	Status
External Health Management	aou_req__platform__external_health_management	valid
OS safety functions	aou_req__platform__os_safety_functions	valid
POSIX Operating System	aou_req__platform__posix_operating_system	valid
Process Isolation	aou_req__platform__process_isolation	valid
Safe HW platform	aou_req__platform__hardware_safety	valid

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: <link to add>. Assumptions from components to their users can be fulfilled in two ways:

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”.
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:

Title	ID	Status
Avoidance of Exceptions	aou_req__platform__no_exceptions	valid
Avoidance of heap allocations after initialization	aou_req__platform__no_heap_alloc_after_init	valid
Error Reaction	aou_req__platform__error_reaction	valid
Integration levels	aou_req__platform__levels	valid
Integrator safety anomaly reporting	aou_req__platform__integration_safety_anomaly	valid
No mixed ASIL	aou_req__platform__no_mixed_asil	valid
Program Flow Monitoring	aou_req__platform__flow_monitoring	valid
Safety integration	aou_req__platform__safety_integration	valid
Safety matching	aou_req__platform__safety_matching	valid
Success Expected	aou_req__platform__success_expected	valid
SW-platform integration bug reporting	aou_req__platform__bug_report	valid
SW-platform test completion	aou_req__platform__test_completion	valid
SW-platform testing	aou_req__platform__testing	valid

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.

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#

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 <add link to release note>.

References#

Handbook (doc__platform_handbook)

Baselibs Safety Manual

IPC Safety Manual

FEO Safety Manual

KVS Safety Manual

Orchestrator Safety Manual