Safety Manual#

Rust Base Libraries Safety Manual
status: draft
security: NO
safety: ASIL_B
tags: baselibs_rust

Introduction/Scope#

This manual covers Rust Base Libraries module.

Assumed Platform Safety Requirements#

For the Rust Base Libraries the following safety related stakeholder requirements are assumed to define the top level functionality (purpose) of the Rust Base Libraries.
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.>

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 module runs on:

Title

ID

Status

Application deadlock

valid

Application execution

valid

Persistency Error handling

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 case.
Additionally the components of the platform may have additional specific assumptions how they are used. These are part of every module documentation: Module Documents. 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

Access control

valid

aragen not safe

valid

bazel tooling

valid

bug fixing

valid

bug interface

valid

Check for nullptr on Allocate()

valid

Checking for possible message overflow

valid

Config on a safe filesystem

valid

Correctly configured ASIL Level

valid

Correctly configured events/fields per service type

valid

Correctly configured maximum number of maximum elements per subscriber

valid

Correctly Configured Maximum Number of Subscribers

valid

Different user for ASIL and QM processes

valid

Error Domain Implementation

valid

Event or Field reception via GenericProxy needs specific care

valid

Event Subscription active while holding SamplePtr

valid

FEO something

valid

FEO something

valid

integration assistance

valid

integration levels

valid

integration manual

valid

Integrator safety anomaly reporting

valid

JSON data integrity

valid

LoLa Memory only accessed through LoLa

valid

LoLa specific QNX Messaging End-Points only accessed through LoLa

valid

Monotonic Semi-Dynamic Memory Allocation

valid

Next Title

invalid

No APIs from Implementation Namespace

valid

No Copy-Send() while holding AllocateePtr.

valid

No guarantee in availability of services

valid

No guarantee on execution time

valid

No guarantees for notifications

valid

No notification on termination of producer

valid

No shared memory allocation in namespace lola

valid

No static context support

valid

Non-Terminating callbacks

valid

None reentrant methods per event instance

valid

on_target_crates

invalid

One producer only one AllocateePtr

valid

Only LoLa supported types

valid

OS safety anomaly reporting

valid

Quality of data is dependent on producer

valid

Resource Lifetime

valid

Result Value Handling

valid

rust_core_lib

valid

rust_std_lib_modules

invalid

safety AoU

valid

safety functions

valid

safety integration

valid

safety matching

valid

Same compiler settings for provider and consumer side

valid

Skeleton alive while its AllocateePtr being used

valid

Some Other Title

invalid

SW platform integration bug reporting

valid

SW platform testing

valid

Thread Safety

valid

unsupported data-types

valid

Usage of configuration "oversubscription"

valid

Valid callbacks while proxy alive

valid

Validity of pointer on LoLa pointer

valid

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>