Safety Analysis Process Requirements#

Note

Safety Analysis is used as a umbrella term for the methods DFA (Dependent Failure Analysis) and FMEA (Failure Mode and Effects Analysis).

Safety Analysis Structure
status: valid
tags: done_automation, safety_analysis

Safety Analysis (FMEA and DFA) shall be hierarchically grouped into different levels.

Following levels are defined:

  • Platform DFA

  • Feature DFA/FMEA

  • Component DFA/FMEA

Process Safety Analysis Attributes#

Safety Analysis attribute: UID
status: valid
tags: done_automation, attribute, mandatory, safety_analysis

Each Safety Analysis shall have a unique ID. It shall be in a format which is also human readable and consists of

  • Type of Safety Analysis (DFA or FMEA)

  • Name of analysed structural element (e.g. Persistency, FEO, etc.)

  • Element descriptor (e.g. KVS__Open KVS or KVS__GetKeyValue)

The naming convention shall be defined in the project and shall be used consistently.

Safety Analysis attribute: title
status: valid
tags: done_automation, attribute, mandatory, safety_analysis

The title of the Safety Analysis shall provide a short summary of the description

Safety Analysis attribute: mitigated by
status: valid

Each violation shall have an associated mitigation (e.g. prevention, detection or mitigation) or AoU. If mitigation has not yet been implemented, do not use this option. If status == valid then mitigated_by is mandatory.

Safety Analysis attribute: mitigation issue
status: valid

If a new mitigation (e.g. prevention, detection or mitigation) is needed link to the issue and keep status invalid until mitigation is sufficient.

Safety Analysis attribute: sufficient
status: valid

The mitigation(s) (e.g. prevention, detection or mitigation) shall be rated as sufficient with <yes> or <no>. A mitigation can only be sufficient if a mitigation is linked via the attribute mitigation.

Safety Analysis content: argument
status: valid

The argument shall describe why the mitigation (e.g. prevention, detection or mitigation) is sufficient or not. If it is not sufficient, the argument shall describe how the mitigation can be improved to achieve sufficiency. The argument shall be written in the content.

Safety Analysis attribute: status
status: valid

Each Safety Analysis shall have the status invalid until the analysis is finished. The status shall be set to valid if the analysis is finished and all issues are closed.

Safety Analysis attribute: failure effect
status: valid
tags: done_automation, attribute, mandatory, safety_analysis

Every Safety Analysis shall have a short description of the failure effect (e.g. failure lead to an unintended actuation of the analysed element)

Safety Analysis Linkage#

Safety Analysis Linkage check
status: valid

Safety Analysis shall be linked to the architecture view on the corresponding level via the attribute violates.

Safety Analysis Linkage
status: valid

Each Safety Analysis shall be automatically linked (inverse direction) to the corresponding architecture view via the “violates by” linkage.

Safety Analysis attribute: check Requirements linkage
status: valid

Safety Analysis shall be linked to a requirement on the corresponding level via the attribute “mitigated by”.

Safety Analysis attribute: Requirements linkage
status: valid

Each Safety Analysis shall be automatically linked to the corresponding Safety Requirement via the mitigates linkage.

Safety Analysis attribute: link to Aou
status: valid
tags: done_automation, attribute, automated, safety_analysis

It shall be possible to link Aou.

Safety Analysis attribute: versioning
status: valid
tags: prio_2_automation, attribute, automated, safety_analysis

It shall be possible to detect any differences in mandatory attributes compared to the versioning: Safety Analysis mandatory a... (gd_req__saf_attr_mandatory)

Safety Analysis Linkage status check
status: valid

It shall be checked that Safety Analysis can only be linked against valid safety elements (architecture view, requirement, AoU). A valid safety element has the attribute ‘status == valid’ and safety != QM.

Safety Analysis Checks#

Safety Analysis mandatory attributes provided
status: valid

It shall be checked if all mandatory attributes for each Safety Analysis are provided by the user. For all Safety Analysis following attributes shall be mandatory:

Overview mandatory Safety Analysis attributes#

Title

Safety Analysis content: argument

DFA attribute: failure ID

FMEA attribute: fault ID

Safety Analysis attribute: failure effect

Safety Analysis attribute: status

Safety Analysis attribute: sufficient

Safety Analysis attribute: title

Safety Analysis attribute: UID

Safety Analysis linkage safety
status: valid
tags: prio_2_automation, attribute, check, safety_analysis

It shall be checked that Safety Analysis (DFA and FMEA) can only be linked via mitigate_by against <Feature | Component | AoU> Requirements with at least one Requirement with the same ASIL or with a higher ASIL as the corresponding ASIL of the Feature or Component that is analysed and linked via violates.

Safety Analysis finalization check
status: valid

It shall be checked if all artifacts of the analysis are “valid” and “sufficient”.

DFA Process Requirements#

DFA attribute: failure ID
status: valid
tags: done_automation, attribute, mandatory, safety_analysis

Each DFA shall have a failure ID. The failure ID is used to identify the related fault <DFA failure initiators (gd_guidl__dfa_failure_initiators)>. The failure ID links to the corresponding failure initiator which describes how a potential violation can occur.

FMEA Process Requirements#

FMEA attribute: fault ID
status: valid
tags: done_automation, attribute, mandatory, safety_analysis

Each FMEA shall have a fault ID. The fault ID is used to identify the related fault <FMEA Fault Models (gd_guidl__fault_models)>. The fault ID links to the corresponding fault which describes how a potential violation can occur.