Click to play AN INTRO VIDEO

What is proof testing?

Proof testing is a term that was first coined in the original IEC 61511 standard (functional safety - safety instrumented systems for the process industry sector). Unlike regular testing to see if a system performs as required by a specification, a SIF proof test should be designed to reveal otherwise unrevealed faults.

Background to what is proof testing

In the process industry sector, a safety instrumented system (SIS) is often designed to be operating in low demand, where each safety instrumented function (SIF) final element is effectively dormant until it is needed to act.

Consider a simple SIF to detect the level in a vessel and close a shut-off valve on the vessel inlet to avoid overflow. Between demands, the shut-off valve is open and there is no way of knowing that it will definitely close without actually closing it.

We expect the likelihood of valve closure to be very high if the system has just been fully validation tested. The validation happens at the site acceptance test (SAT) or commissioning stage, to check that the system meets specification before it is first put into service. For a safety instrumented system with Safety Integrity Level (SIL) requirements, this validation test should comprise a very stringent and documented inspection and test procedure.

On day one of operation, we expect the likelihood of valve closure (if a high-level demand occurs) to be very high. However, if there are no further demands, what is the likelihood that the valve will close on day 365 (after 1 year) or day 3650 (after 10 years). That is a very difficult question to answer. However, we can all relate to the possibility that without further inspection, testing and maintenance, the likelihood of there being an undesired fault simply increases with time.

SIS inspection, SIF proof testing and maintenance are crucial activities to ensure systems remain safe over their lifetime. But what is involved?

The following steps are explained in more depth in our online SIS course. In a live plant situation, the steps below will only begin once authorisation via a "permit-to-work" has been issued by operations.

Dynamically link the SRS to the Proof Test Procedures

Rather than producing "flat file" PDF procedure documents, we recommend that proof test procedures get produced from a dynamic database. PDF and other formats of flat file documents tend to get conflicting information if they have not been well controlled, especially in older systems.

The best way to control proof test procedures is to adopt a fully digitalized database that links the Safety Requirements Specification (SRS) data to the Proof Test Procedure (PTP). We have found aeShield is the best available tool to develop PTP templates and then embed live fields in the PTP that link the SRS data directly to the testing documents.

Imagine some time after a SIS project has been completed, there needs to be an update to a critical setting such as the tripping point of a SIF. The team follow company change management processes, and this will require implementing updates to the SRS, Cause & effects, and PTPs, and possibly more documents. If a tool like aeShield has been used, the data is changed once, in one place in the database, and then all reports such as SRS, PTP, C&E will be up to date from that time onwards.

eFunctionalSafety has an online course with self-paced video modules on how to use the aeShield tool. Click this link to access the aeShield online course.

Documentation - the "As-built" record

Inspection and proof testing a safety instrumented system should not begin without an extensive check of the available documentation.

For SIS/SIF it is crucial that the "As-built" documents are available. This may include numerous different documents, but the principle sources are likely to be the following:

  • Piping and Instrumentation Diagrams
  • Cause and Effects Diagrams
  • Safety Requirements Specification
  • Proof test procedure
  • Previous Proof Test Records

Inspection First - "As-found"

The condition of equipment has to be established first. Often, problems can be anticipated in advance of failures, and physical SIS inspection is the way to get that pre-warning. Below are a few inspection examples for safety-related equipment that do not require any physical test:

  • Inspect for obvious damage or signs of corrosion
  • Check equipment tags / SIF identification
  • Check software and/or firmare revisions match document records
  • Check for wiring, cable or termination issues
  • Look for kinks or damage to impulse lines
  • Check for poorly supported tubing or pipework
  • Cabinet security from unauthorised access
  • Signs of moisture/water ingress where it should not be
  • Leaks from piping or actuator gaskets
  • Valve stem corrosion

The above list is not exhaustive. The equipment supplier should give additional advice in their installation, operation/maintenance manual, so that's an important source to check.

At the completion of inspection, the "As-found" status of the equipment should be recorded BEFORE any test or rectification of problems takes place. This is to ensure that systematic causes of problems are captured prior to problems being fixed.

SIF Proof Test to the "As-left" Condition

A function check, or safety instrumented function proof test is also often called a "loop check". The goal is to exercise every active device in the safety loop (or SIF), whether that is completed in one step or multiple steps. In a way, this is a subset or repeat of many of the steps that should have occurred at the original validation test.

Although already noted above, the "As-found" status still applies to this step. For example, if a different trip or alarm setting is noted during the testing step, it is important to record this before making any adjustments.

SIF proof testing is best completed off-line, when the equipment is not in service protecting against a real hazard. If on-line testing is required for reasons of continued production, this has to be even more closely controlled and monitored.

An article like this cannot go into every nuance and step involved in testing types of equipment, so here's a list of what I think a good proof test procedure and template should include:

  • Document name, unique number, issue date, author and revision information
  • A list of documentation that must be reviewed before the test takes place
  • Information on who is qualified to use the procedure and perform each task
  • Special tools, access requirements or equipment needed for the test
  • Instruction & fields to record tags, SIF loop identifier, software and firmware, where applicable
  • Specific instruction and fields to record the "As-found" condition of each active SIF device
  • Detail of the hazard and consequences of failure, with mitigating measures for on-line tests
  • Detailed step-by-step task instructions for the test
  • Pass / Fail criteria per step, with room for comments
  • Space to record the "As-left" condition of each device
  • Space to record the tester name, signature and date(s) of the test 

Summary

We recommend proof test procedures are developed from a linked database that comes from the same source of data as the safety requirements. Any update in procedures or requirements from a "single source of truth" will ensure complete consistency.

To achieve this kind of consistency between SRS, SIL Calcs and Proof Test Procedures, we recommend aeShield as the best software solution.

About the author

Jon Keswick, CFSE

Jon Keswick is a Certified Functional Safety Expert (CFSE) and founder of eFunctionalSafety. Feel free to make contact via LinkedIn.

>
Success message!
Warning message!
Error message!