Good practice for mitigating identified hazards
As system safety engineers, our aim must be to ensure and assure the safety of the system under analysis. Fundamental to that aim is the careful management of system safety requirements through life, and this activity often starts with the act of elicitation.
By ‘elicitation’ I mean “the discovery of requirements through consultation with stakeholders, from system documents, domain knowledge and market studies” [1]. The system document we’ll consider in this article is the output from a deviation-based analysis undertaken to identify hazardous, or unsafe events (or UCAs in STPA-terms). There are many techniques which can be deployed to identify hazardous or unsafe events, each with their own merits and weaknesses. We’ll put aside the merits or otherwise of differing deviation-based analysis for now, and start from the point where such unsafe events have been identified.
Having identified these unsafe events, as safety engineers we need to elicit safety requirements which are complete and correct. The attributes of completeness and correctness are measures of the safety requirements in terms of the successful mitigation of the undesirable event (should the safety requirements be correctly instantiated).
Experience assessing the output of deviation-based analyses suggests that the resulting safety requirements which are elicited in mitigation of the unsafe event are often neither complete, nor correct. Let me explicate by a typical example. Regardless of the technique or method employed, ‘guide words’ of some form are often used to determine the types of events which could lead to an undesirable (unsafe) outcome:
- Ommission (x didn’t happen)
- Commission (x happened when not commanded)
- Early (x happened before the correct time)*
- Before (x happened before the correct part of a sequence in a chain of events)
- Late (x happened after the required time)
- After (x happened after the correct part of a sequence in a chain of events)
- Value (x is returned as result of computation of some sort, and it is either:
- Incorrect and credible (x is returned, and it is believable)
- Incorrect and incredible (x is returned, and it is unbelievable))
- (Others I’m sure you could add to this list).
*Early and Before (and Late and After) are often assumed incorrectly to be synonymous*
Not all of these events will be applicable in all cases, as they won’t provide any meaningful returns. All should be considered and documented as such, however. The next step of the analysis should be (but often isn’t) to assess whether these events are detected and detectable.
For each unsafe event identified, it is incumbent on the safety engineer to elicit safety requirements in mitigation. A regular failing I observe in my assessments concerns an uncommanded event (identified considering ‘commission’ or similar) – which is too often considered mitigated through a requirement to ‘provide an alternative means of providing function y’. Naturally, a diverse or redundant means of providing a function offers no mitigation against an uncommanded event. Other examples of failings include requiring a system to detect something which is either outside the possibility of physics or technology (or both!), or not considering negative safety requirements (i.e. what the system should NOT do – sometimes referred to as ‘constraints’).
So how do we fix this?
The safety engineer, in eliciting complete and correct safety requirements should consider four different types of requirements:
- Prevent. Prevent requirements aim to stop an unsafe event from ever manifesting.
- Protect. With protect requirements, we start from the position that the prevent requirement(s) has failed, and need to protect the system from entering a hazardous state.
- Recover. If we haven’t prevented the unsafe from occurring, and a hazardous state has manifest despite the protect requirement(s), recover requirements seek to recover the system to its pre-hazardous state.
- Mitigate. Here we assume that the hazard is progressing – potentially towards a consequence, and mitigate requirements seek to minimise the impact of the consequence.
As with guide words used in deviation-based analysis, not every type of safety requirement will always be meaningful, but as safety engineers we must ensure we have considered each type and assure that we have done so through robust evidentiary artefacts.
For safety requirements to be complete and correct, they must be relevant to the identified unsafe events, and effective in mitigating them.
Reference
- Kotonya and Sommerville I. Requirements Engineering Processes and Tech-niques. Wiley, Chichester, 1998
