Legal information

Copyright DB Netz AG, licensed under CC-BY SA 3.0 DE (see full text in CC-BY-SA-3.0-DE)

ARCH.028 Define operational safety measures

SM-2764 - Populate Confluence page for activity definition: ARCH.028 Define operational safety measures Finished

GoalSpecify how operational safety risks will be managed down to an acceptable level - identify operational requirements needed for safety risk mitigation
Requirements met by this process step

CSM-SMS guidance 3.1.1.1 c)

ISO 15288 (2015) para 6.4.3.3 b) 3

Inputs

AMOD-030 Accident and hazard state model

AMOD-031 Unified risk model

AMOD-028 Operational activities and interaction definitions (single operational capability) 

Outputs

AMOD-031 Unified risk model (updated)

AMOD-028 Operational activities and interaction definitions (single operational capability) (updated)

Methodology

This step must be done jointly between system and RAMS architect.

Identify every safety risk state models related to the operational capability where risk reduction is necesary to meet the accident state target (as a result of ARCH.027).  The aim of this step is then to define how to achieve the necesary risk reduction for each of those risk state models

Where in the risk state model to insert a risk reduction measure 

There are multiple points in the risk model where it is possible to reduce risk the accident risk. These points are always related to the deviations (safety condition) considered in the safety risk model, and there is an order of preference for these.

They are listed below in order of highest to lowest preference: 

  • Reduce the probability of a hazardous state transition occurring (i.e., reduce the probability of the transition from safe state to hazardous state) (this is the same as increasing the probability that the safe state persists); - "Risk Prevention Measure".
  • Reduce the probability of a accident state transition occurring (i.e., reduce the probability of the transition from hazardous state to accident state) (this is the same as increasing the probability of hazardous state recovery to the safe state). - "Risk Mitigation Measure"
  • Reduce the severity of the accident state(s), this results in reducing the accident probability target. This option  - implying there is a relevant barrier allowing to alleviate the severity level (e.g. crashworthiness for collision at a moderate speed) - is to be disregarded as far as possible since it generates   conditions to be exported and fulfilled, constraining/restricting the applicability of the risk model. This option  should thus be preferably  managed as part of  a "variant" risk state model with a different severity for the accident state. 

There are two possible ways for reducing the probability with respect to the two first points above :

1. either by constraining the occurence of a deviation in the risk model identified at ARCH.020 Identify & classify operational deviations with a lower occurence probability target

2. or by adding an additional risk control measure (as a new operational activity or possibly as a new operational capabiliy extension) with a maximum  (wrong-side)  failure probability target assigned to it. The failure of that mitigation measure (and its success as a complementary) shall be added as a new condition/deviation for transitions in the risk state model. If the measure is a risk prevention measure then its failure shall be represented in the transition between safe state and hazardous state. If the measure is a risk mitigation measure then its failure shall be represented in the transition between  hazardous state and accident state. 


It is permissible to define more than one risk reduction measure for any one possible deviation. When doing so, the "Swiss cheese" model should be considered: that each measure has weaknesses, and so any set of measures should when taken together not have any common weaknesses.

The decision on how best risk reduction should be achieved and how to define risk control measures must be taken by the Sytems architects with support from the RAMS architects. 

Defining risk reduction measures in the operational activities model

Risk reduction measures in the operational layer of the model are always operational activities or a set of operational activities. 

Where risk reduction is to be achieved by contraining a deviation (option 1 above), this means a corresponding operational activity already exists in the model. It is then sufficient simply to asign the maximum allowable failure probability as non functional requirement to that activity (or/and asign it to the relevant outgoing interaction of that activity), following the modelling rules for that type of non-functional need.

Where risk reduction is to be achieved by adding a risk control measure (option 2 above), this means that no suitable operational activity exists in the model which corresponds to this risk control measure.  A new operational activity (or an extension of an operational capability  if the risk control measure is too broad to be modelled as a single activity)  shall then be created in the operational capability model and the maximum allowable  failure probability target of the measure shall be asigned as a non functional requirment to this new  activity (or/and to the corresponding outgoing interaction from this activity  in the updated model).  

Refer to ARCH.033 Update operational activities and interactions for instructions on updating or defining new operational activities.

If there exists more than one type of wrong-side failure for any activity, each wrong-side failure probhability is added to one outgoing interaction of that activity.

Instructions for updating the model to reflect the risk reduction measures can be found under the process steps of group ARCH.904 - it is recommended to run these process steps in parallel with the risk assessment and mitigation process steps.

Tools and non-human resourcesTeam for Capella
CardinalityOnce per operational capability
Completion criteria

There exists a set of risk reduction measures in the model for each possible safety-affecting deviation to the current operational capability.

Rationales have been recorded for each risk reduction.

Design review

ARCH.R.1 Operational capability review

ARCH.R.2 Operational review - consolidated

Step done by (Responsible)

System architect

RAMS architect

Provides input to/assists (Contributes)Operational concept architect
Uses outputs (Informed)None identified