Platform Safety Manual#

Platform Safety Manual
status: draft
security: NO
safety: ASIL_B

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.

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:

  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:

Title

ID

Status

Avoidance of Exceptions

aou_req__platform__no_exceptions

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

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.

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