Introducing consequential hazards, the long lost and forgotten sibling.

All those involved in risk assessment are aware of hazards.? These ar the origin of an expected harm or the initiating factor in a risk (alongside severity, frequency and exposure).? We aim to contain, mitigate and ideally eliminate hazards and risks from automation systems.

However as has been observed many times a small change can have larger consequential effects.? These we calculate are positive but there can be introduced negative effects which are often ignored.

Take as an example a pipeline shutoff valve.? The hazard is that this supplies fuel? as a potential source of fire in the case of a leak.? In the event of a fire the logical answer is to shut this valve as fast as possible.

However, shutting a large valve quickly can induce a pressure wave back up the pipeline which damages upstream components or bursts a seal leading to an uncontrolled leakage upstream and a second source of fuel.?

Risk Balance

What can be seen from above is that there may be a balance to be stuck between the risk presented by the main (primary) hazard and the consequential (secondary) hazard.? This is of course assuming that one, the other or both cannot be eliminated by another means.

This can be delt with in two ways:

1. Risk Trade off.? A trade off looks at the relationship between the two risks and where the lowest overall risk point lays.? This by nature is a compromise and may introduce a dependency where a change in one scenario now directly affects the other
2. Additional measures.? The other approach is to take additional measures to mitigate the secondary risk.? This leads to greater complexity in the system and potentially greater cost and downtime.

Tolerable Risk

When looking at the most appropriate method the maximum tolerable risk has to be considered.? This forms a limit on what is deemed acceptable.? In many cases these limits are not clear and seemingly arbitrary.? The determination of maximum tolerable risk however is a subject for another time…

Be conscious that tolerable risk applies at two levels:

• Component or subsystem.? This is the maximum risk that each constituent part can pose.
• System.? This is the overall level of risk posed by the system as a whole.? This is the sum of the components plus the additional factors for operation , integration etc.

What is important to not is maximum.? This must not be exceeded.? It is key though to look at this as an overall system and not individually.? At the individual level option 1 (trade off) is likely to be within the tolerable risk, however it is inevitable that each trade off increases the overall risk level by a small amount.? Quickly therefore a number of trade offs can see the overall system tolerable risk level be exceeded.?

Working down

There are many approaches to managing the compromises involved in ensuring that a system is? safe.? There are though a few indicators to keep in mind.

The first is to avoid a right first time approach.? It is tempting to try to find the overall solutions in the first iteration of the design.? This is tempting as it saves time, effort and money.? However, there is here a potential risk that a particular approach becomes set into the design and the resulting conflicts causes result in compromises to the tolerable risk score.

The second is to over-specify the tolerable risk.? In the early stages of a concept where there are a lot of unknowns it is tempting to err on the side of caution and set the tolerable risk threshold high.? As the project progresses this may then be revised down.? The note of caution here is that this is not a controlled process, and the lower limit of tolerable risk is now not known.

Lastly there is the issue of the unknown.? It is tempting to try to answer as many questions as possibly up front.? In this there is the possibility of making too many false assumptions.? Only answer what is essential as that stage.? Make as few assumptions as possible and ensure where possible that the assumptions are testable later on.

The general approach therefore should be a start simple and work up.? In all cases build the most simplistic case and system which matches the requirements.? Then add complexity systematically and only as required.? The aim is to add robustness to all elements as the system evolves and not remove it.