Last updated on August 19, 2022
For the third blog of this series, the focus is on proof testing. This article will look at what proof testing is, why it's needed, and give some outline examples of proof test procedure requirements.
What is "proof testing" and why is it needed?
The term "proof testing" was first introduced in the IEC 61511 [1] standard when it was first published back in 2003.
The idea of a proof test stems from the assumption that a safety function which is rarely needed (low demand) must be exercised at some frequency to check for "undetected" faults.
There's already quite a lot of detail in the above statement that needs some explaining.
Firstly, safety instrumented systems do experience random hardware failures just like any other system.
Secondly, failures may not be obvious (revealed) until there is a demand for action. The standards call these failures "undetected".
Thirdly, it might be years between real demands. The need for proof testing therefore comes from an infrequent demand and the possibility of undetected failure over time.
When should proof testing be done?
A proof test must be conducted often enough to be effective. That sounds like an obvious statement, but it has been known for companies to try and push out proof tests to extremely long intervals.
The reason for this is very clear - proof testing costs money. If proof tests are conducted offline, that is without the process running, then they are easier to do.
However, they proof tests take time and usually require people to comlete them. If testing is conducted online, with the process running, then the cost of design and maintenance goes up significantly due to the requirement for built-in redundancy in the system architecture.
Either way, it is not an inexpensive exercise when seen over the lifetime of a system which may be built to last 20 years or more.
The technical way of deciding on proof test frequency has been written about and discussed a lot - perhaps even too much.
You can take a week-long course to learn how to calculate the average probability of failure (PFDavg) to determine the required frequency of a safety function proof test.
Don't engineers just love to get into the weeds of numbers! Instead, watch the short video above. It's an extract from one of our online courses.
PFDavg can be calculated to meet a target safety integrity level - SIL. Depending on the outcome of the calculation a "proof test frequency" can be set to ensure the required integrity is met.
However, setting the frequency is actually the easy part, despite what certain safety consultants will tell you. The hard part is determining actually HOW the system will be tested.
How should proof testing be done?
I've already outlined the fact that proof testing can be done with the hazard not present, or with a live plant running.
Offline testing is highly prefrred for a few crucial reasons.
Firstly, if the process is not running there should be less of a hazard, or even no hazard, when the test is actually conducted.
Secondly, if the test fails, then an offline system can be fixed before the process runs again with the hazard in play.
Online testing is much more challenging.
If the system being tested has not been appropriately designed then it might not even be possible. However, assuming the design has accommodated the requirement for online tests, it is still much more hazardous.
For instance, the process may be in one of several different states, meaning the test must only be conducted under strict pre-conditions.
The test procedure will also have to account for "what happens next" if the test fails. As a test could fail for many reasons, it really is hard to know whether a procedure could really cover all eventualities.
So, accepting the fact that testing can be done either offline (preferable) or online (eek!), we really need to look closer at the "HOW" part.
Inspection and proof test procedures
During a functional safety assessment of proof test procedures, I once experienced a supervising manager argue that test procedures did not need to be detailed as his test technicians were highly trained.
The company concerned had what were described to me as "generic" proof test procedures. Generic in this case meant that certain standard steps for collecting together drawings and following permit-to-work requirements were covered.
The equipment tags were uniquely identified for each piece of equipment to be tested, but the step by step work procedure for each test was identical. It relied heavily on the technician having personal competence with how to test each piece of installed equipment.
While I agree that competence of technicians doing tests is absolutely crucial, I completely disagree that any proof test procedure which is going to be effective can be generic in this way. Any of us can have a bad day and forget critical steps, even if we have previously been judged as competent at a task.
The Health & Safety Executive (HSE) gives the guidance that "proof test procedures should be designed to minimise human error, for example using tick boxes to help prevent missing steps, sign-offs and/or cross-checking for critical steps and where possible structuring the test so that errors that could be introduced are revealed by subsequent test steps."[2]
So, proof test procedures must be specifically designed for the actual equipment being tested, and they should include detailed steps and checklists relating to how to test that equipment. This sounds simple enough, but as ever, there is "devil in the detail".
Developing sound proof test procedures is not a trivial task. The first step starts with identifying good sources.
In my experience the best sources for developing detailed equipment proof test procedures are as follows:
- The equipment manufacturer's recommendations. For SIS devices, this should include a review of the functional safety manual and/or installation, operation and maintenance manuals. Detailed test steps are often described and must form part of the detailed steps in the proof test procedure.
- The safety requirements specification and validation records for the SIS and each SIF. These may or may not exist, depending on when the system was designed and installed. However, if the installed system has previously been fully validation tested (not just factory tested), then the validation record is a great starting point. A proof test procedure can often follow many of the same steps.
- General guidance from standards. There is some guidance in IEC 61511 edition 2, part 2 which was not there in edition 1 of the standard. This new guidance lists the conditions that should be looked for, which could be used as checklist when creating a procedure. EN 62382:2013 [3] is another possible source. While not specifically aimed at proof testing of safety functions, there is good general advice on how loop checking should be conducted which may help improve test procedures.
REFERENCES:
[1] IEC 61511: Functional safety of safety instrumented systems for the process industry sector. This standard is now variously known as IEC 61511 edition 2:2016 or BS EN 61511:2017 in UK and ISA 61511 in the USA.
[2] HSE: Proof testing of Safety Instrumented Systems in the Onshore Chemical/Specialist industry. Extract from Appendix 1.
[3] EN 62382:2013 - Control systems in the process industry - Electrical and Instrumentation Loop Check.
Well written.
It would be nice to include the contents of a proof test procedure.
Thanks for your comment Kishore. I’ll try to post an example in a coming blog.
Hi John, one of the guiding principles of the HSE’s research report 428/2002 for proof testing SIS in the chemical industry is that … ‘the proof test of a SIS should reflect real operating conditions as accurately as possible. If reasonably practicable, the SIS should be initiated by manipulation of the process variable without driving the process into the demand condition’. … in my experience of this is not something that is easy to implement, potentially hazardous and I suspect looked on by many with little enthusiasm !
Hi Ian, I completely agree. I don’t think that manipulating the process variable for proof test purposes is a sound piece of advice. Perhaps it should be fed back to the HSE that this guidance is still in the public domain. Hiding behind “if reasonably practicable” as a caveat is not that helpful.