Yesterday I viewed a webinar on proof testing1 organised by IChemE.
The presentation was a good overview and went at a decent pace for following along but was too fast for me to take any decent notes.
Below is a quick writeup of what I took from the session.
Proof tests will generally spot most of the faults in the system, better than diagnostics, but there may still be some faults that go undetected and the only way to fix them is with a complete overhaul.
Proof testing is set up to detect random hardware failures however it can also detect system failures as well.
Generally speaking, you can't use genuine trips as proof tests, as they are function tests. A proof test needs to fully test the component in question. Not just "does the value close" but "is that valve gas tight". This can be much harder to test outside of a shutdown.
Also in trip situations, it may not be possible to tell if each component actually worked as intended. This is particularly true in situations with multiple inputs (1oo2 voting) - did both instruments work or just one?
It was driven home how important it is to carry out the checks at the documented frequency to be able to achieve the required risk reduction factors. It was also pointed out that these frequencies should be checked during the design phase that they are reasonable.
The order of applying risk reduction factors is reversed from how I normally think of them.
In a LOPA, I am used to looking at:
- Demand rate (from failures in the basic process control system)
- Then the risk reduction from Other Risk Reduction Measures (relief valves/NRVs etc)
- Then the risk reduction from Conditional Modifiers (Occupancy etc)
After these have been combined, then look at the residual risk and compare it to the target risk. The remaining cap will need to be covered by a SIF with a particular SIL rating.
However once this SIF hand been setup, it should be considered before the Other Risk Reduction Measures and Conditional Modifiers. This makes sense because it is the order that you would expect them to be used.
The presenter also mentioned the need to accurately record the failure rates for each component to ensure that the assumptions made during the design phase. It occurred to me that it would probably be a good idea to record the number of demands to check that they are also correct. It is no good having a perfectly complient SIS if the control system causes an order of magnitude more demands than predicted.
- IChemE: The institute of chemical engineers
- SIS: Safety Instrumented System
- SIF: Safety Instrumented Function
- SIL: Safety Instrumented Level
- LOPA: Layers Of Protection Analysis
- NRV: Non Return Valve
- Proof Testing for Safety Instrumented Systems...what you need to know! by Ron Bell. 2018-07-12 09:00 ↩