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. It will also introduce some issues I've personally experienced during audits and assessments of proof test procedures in the process industry sector.
What is "proof testing" and why is it needed?
The term "proof testing", in the context of safety instrumented systems, was first introduced in the IEC 61511  standard when it was first published back in 2003. The idea of a proof test comes from the assumed fact 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, those failures may not be apparent (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 still take time and require people to do 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 intended 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 even take an entire 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 process dormant (offline testing), or running (online testing).
Offline testing is highly preferable for a few important reasons. Firstly, the process is not running so there should be less of a hazard, or even no hazard, when the test is actually conducted. Secondly, if it results in a failed test then an offline system can be fixed before the process runs again with the hazard present.
Online testing is much more challenging. If the system 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 by its nature more hazardous. 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.
Proof test and inspection procedures
During an independent audit of an end user's proof test procedures, I've experienced a supervising engineer argue that test technician competence is the main requirement for proof testing. 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 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 been judged as competent at a task before.
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."
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  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.
 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.
 HSE: Proof testing of Safety Instrumented Systems in the Onshore Chemical/Specialist industry. Extract from Appendix 1.
 EN 62382:2013 - Control systems in the process industry - Electrical and Instrumentation Loop Check.