Safety Manual

Note

Document header

[Your Module Name] Safety Manual		status: draft security: YES safety: ASIL_B
tags: template version: 1 realizes: wp__module_safety_manual
doc__mod_temp_module_name_safety_manual		Generic Document

Attention

The above directive must be updated according to your Module.

• Modify Your Module Name to be your Module Name or put “Platform”

• Modify id to be your Module Name in upper snake case preceded by doc__ and succeeded by safety_manual

• Adjust status to be valid

• Adjust safety and tags according to your needs

Introduction/Scope

<Describe here which module (or the platform) is covered by this manual.>

Assumed Platform Safety Requirements

For the <Project platform / module name> the following safety related stakeholder requirements are assumed to define the top level functionality (purpose) of the <Project platform / module name>. I.e. from these all the feature and component requirements implemented are derived.

<List here all the stakeholder requirements, with safety not equal to QM, the module’s components requirements are derived from. For the platform all are relevant.>

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 resp. module expects to be safe.>

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

Title	ID	Status
Another Title	aou_req__mod_temp_crypto__sec_another	invalid
Build environment supports Rust 2021	aou_req__iav_primula__rust2021_build_env	valid
Crypto Environmental Requirement Example	aou_req__crypto__crypto_env_req_ex	invalid
External Health Management	aou_req__platform__external_health_management	valid
OS safety functions	aou_req__platform__os_safety_functions	valid
pkcs11_dynload: Integrity and authenticity of the pkcs11 module	aou_req__crypto__sec_integ_auth_pkcs11_mod	valid
pkcs11_dynload: No use of ALLOW_PKCS11_LIB_OVERRIDE	aou_req__crypto__sec_no_pkcs11_lib_override	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

Attention

Make sure these AoU are here for a safety reason, i.e. every one “mitigates” a safety analysis entry.

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 or the module of this safety manual:

Note: Platform safety manual collects all platform wide AoU (have to be fulfilled by the user for any feature). Module safety manual collects all AoUs specific to a feature and its realizing components. This means for every feature the user selects, the platform safety manual and the related module manual has to be considered.

Title	ID	Status
aragen not safe	aou_req__communication__27	valid
Avoidance of Exceptions	aou_req__platform__no_exceptions	valid
Avoidance of heap allocations after initialization	aou_req__platform__no_heap_alloc_after_init	valid
Bazel tooling	aou_req__platform__bazel_tooling	valid
Bug fixing	aou_req__platform__bug_fixing	valid
Bug interface	aou_req__platform__bug_interface	valid
C++ Library Preference	aou_req__os__cxx_preference	valid
Check for nullptr on Allocate()	aou_req__communication__14	valid
Checking for possible message overflow	aou_req__communication__8	valid
Config on a safe filesystem	aou_req__communication__10	valid
Correctly configured ASIL Level	aou_req__communication__4	valid
Correctly configured events/fields per service type	aou_req__communication__34	valid
Correctly configured maximum number of maximum elements per subscriber	aou_req__communication__3	valid
Correctly Configured Maximum Number of Subscribers	aou_req__communication__2	valid
Crypto AoU Requirement Example	aou_req__crypto_aou__next_title	valid
Different user for ASIL and QM processes	aou_req__communication__9	valid
Error Reaction	aou_req__platform__error_reaction	valid
Event or Field reception via GenericProxy needs specific care	aou_req__communication__32	valid
Event Subscription active while holding SamplePtr	aou_req__communication__19	valid
FEO something	aou_req__component_feo__anything	invalid
FEO something	aou_req__feature_feo__something	invalid
Integrate as Rust library API	aou_req__iav_primula__rust_lib_api	valid
Integration assistance	aou_req__platform__integration_assistance	valid
Integration levels	aou_req__platform__levels	valid
Integration manual	aou_req__platform__os_integration_manual	valid
Integrator safety anomaly reporting	aou_req__platform__integration_safety_anomaly	valid
LoLa Memory only accessed through LoLa	aou_req__communication__24	valid
LoLa specific QNX Messaging End-Points only accessed through LoLa	aou_req__communication__26	valid
Minimal Process Privileges	aou_req__os__minimal_privileges	valid
Monotonic Semi-Dynamic Memory Allocation	aou_req__communication__1	valid
Next Title	aou_req__mod_temp_crypto__sec_next_title	invalid
No APIs from Implementation Namespace	aou_req__communication__6	valid
No Copy-Send() while holding AllocateePtr.	aou_req__communication__16	valid
No guarantee in availability of services	aou_req__communication__12	valid
No guarantee on execution time	aou_req__communication__29	valid
No guarantees for notifications	aou_req__communication__7	valid
No mixed ASIL	aou_req__platform__no_mixed_asil	valid
No notification on termination of producer	aou_req__communication__13	valid
No Root Privileges	aou_req__os__nonroot	valid
No shared memory allocation in namespace lola	aou_req__communication__25	valid
No static context support	aou_req__communication__11	valid
Non-Terminating callbacks	aou_req__communication__20	valid
None reentrant methods per event instance	aou_req__communication__17	valid
on_target_crates	aou_req__feo__on_target_crates	invalid
One producer only one AllocateePtr	aou_req__communication__15	valid
Only LoLa supported types	aou_req__communication__5	valid
OS Public API Use	aou_req__os__public_api	valid
pkcs11_dynload: pkcs11.h compatiblity	aou_req__crypto__sec_pkcs11_h_compatibility	valid
Program Flow Monitoring	aou_req__platform__flow_monitoring	valid
Quality of data is dependent on producer	aou_req__communication__22	valid
RST-0001	aou_req__os__rst0001	valid
RST-0002	aou_req__os__rst0002	invalid
rust_core_lib	aou_req__feo__rust_core_lib	valid
rust_std_lib_modules	aou_req__feo__rust_std_lib_modules	invalid
Safe OS Function Use	aou_req__os__safe_fctn_use	valid
Safety anomaly reporting	aou_req__platform__safety_anomaly	valid
Safety AoU	aou_req__platform__safety_aou	valid
Safety functions	aou_req__platform__safety_functions	valid
Safety integration	aou_req__platform__safety_integration	valid
Safety matching	aou_req__platform__safety_matching	valid
Same compiler settings for provider and consumer side	aou_req__communication__31	valid
Skeleton alive while its AllocateePtr being used	aou_req__communication__18	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
unsupported data-types	aou_req__communication__28	valid
Usage of configuration "oversubscription"	aou_req__communication__30	valid
Valid callbacks while proxy alive	aou_req__communication__21	valid
Validity of pointer on LoLa pointer	aou_req__communication__23	valid

Attention

Make sure these AoU are here for a safety reason, i.e. every one “mitigates” a safety analysis entry.

Safety concept of the SEooC

<Describe here the safety concept incl. which faults are taken care of, reactions of the implemented functions under anomalous operating conditions … if this is not already documented sufficiently in the feature documentation “safety impact” section of all the features the module is used in.>

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

<link to the user manual>

<other links>