Safety Manual#

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

doc__logging_safety_manual		Generic Document

Introduction/Scope#

This safety manual covers the module logging and additionally the component logging_frontend which is part of the module baselibs (for the reasoning for this deployment look into Logging Architecture (doc__logging_module_architecture))

Assumed Platform Safety Requirements#

For the Logging feature the following safety related stakeholder requirements are assumed to define the top level functionality (purpose) of LOgging. I.e. from these all the feature and component requirements implemented are derived.

stkh_req__functional_req__safe_comput

Additionally the following stakeholder requirements need to be fulfilled only in QM quality:

This means that you can rely on the logging feature not to interfere with the safe execution of the using application, but not on the output of the logging feature.

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. The platform-wide AoUs are collected in doc__platform_assumptions

To support aou_req__platform__safety_matching: no need for safe libc/libcxx calls as the functionality can be QM.

List of additional AoUs expected from the environment the module runs on:

No needs passed the filters

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.

No needs passed the filters

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#

The safety concept of the Logging Module is to avoid errors by using a development process as if the component’s requirements would be all ASIL_B.

Safety Anomalies#

ToDo: 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#