How to ‘close the loop’ on testing safety critical equipment
In a previous white paper authored by my colleague, Mike Scott focused on five key tenants to achieve sustainable, cost effective compliance with IEC 61511/ ISA-84. The purpose of this blog is to focus on testing and how to leverage aeShield for maximum value add regarding test procedure development, monitoring testing intervals, and collecting failure data for future analysis. In future blogs, I will explore the other four tenants outlined by Mike.
To set the stage, aeShield is an enterprise-level process safety lifecycle management software application. Used with its companion tool aeFacilitator, users have a single source of truth for safety critical information. This includes PHA/LOPA, SIL calculations and verification, safety requirements specification (SRS), non-SIF IPL datasheets, cause and effect matrices, functional test procedures, test results and failure classification, failure rate analysis, and leading indicators based on monitoring IPL performance.
So, onto testing… Here are three significant benefits of using aeShield to support functional testing:
- Creating and managing template procedures for device types
- Monitoring test intervals vs design basis
- Collecting failures to ultimately develop proven-in-use failure rates
#1: Managing Template Procedures
How many test procedures do you currently manage? aeShield was designed to minimize the number of test procedure templates making it simpler to optimize the task and steps necessary to properly test each device. Rather than generating thousands of individual test plans that need to be updated per management of change, simply create a template per unique device type targeting 50-100 procedures. As procedures for a device type are optimized over time, you simply manage the procedure in one place instead of searching for test plan that uses the task and steps for the device type.
Do your test plans contain specific device data that require updating as things change? Users can incorporate “merge codes” within each template such that the up-to-date information is pulled into the test plan on demand when the test is required. By having merge codes in place, only AsBuilt data is pulled, and your technicians won’t need to chase down numerous forms of documentation to test one device or function.
What is your testing philosophy? aeShield supports both device-level testing and full functional testing. Users can save “preferences” per device or function such that the test plan can be run the same way each time without having to manipulate any of the selection criteria.
#2: Monitoring Test Intervals
Are you confident that you are testing devices at the interval identified in the SIL calculation? Test interval is a first-order parameter within a SIL calculation. Therefore, if you do not test the devices per the design basis, you are degrading system performance and subjecting your facility to risk. aeShield allows users to interface with a computerized maintenance management system (CMMS) and/or manually enter test dates to ensure on time testing. A stoplight style health meter is provided to identify the devices that have been tested on time, devices that require testing in the near future, and devices that have not been tested based on the required test interval. Since aeShield is equipped with a SIL calculation engine, RRFs (or PFDs if preferred) can be calculated on-demand to see the rate of degradation.
When you defer testing, are you aware of the risk you are subjecting your facility to? If so, can you identify this risk in a timely manner? Being able to associate a device to an IPL that represents a mitigation to a hazardous scenario with a risk ranking, you now have the information at your fingertips to quickly understand the relevance of deferring a test plan or having a test plan slip through the cracks.
#3: Collecting Failure Data
Are your technicians recording results either as found as left, calibration required, or device failures? And regarding failures, do you have SIS-type engineers further annotating failure events such as method of detection? aeShield enables users to interface with other databases such as CMMSs to directly pull test results for further classification. If this information isn’t being collected, technicians can enter the data directly into aeShield. By flagging failure data, SIS-type engineers can further annotate the failures. Overtime, these failures can be used to generate proven in use failure rates required for SIL calculations.
What source are you using for your failure rates? aeShield can manage multiple sets of failure rates. If your original calculations were performed with generic information, you can compare those calculations to new calculations with failures rates generated from real data. In some cases, this may increase the function’s performance, which may enable you to increase the test interval to save costs. In other cases, the real data may identify a gap that requires additional mitigation to prevent the consequence of the hazardous scenario.
Having a single database solution―aeShield―to manage your process safety lifecycle makes testing simple. I’ve focused on three key benefits that will save time, effort, and money and provide leading indicators to ensure proper risk reduction. Look for future blogs on using aeShield to support the four other tenants in Mike’s white paper: capital project execution, evergreen PHA, organization readiness, and SIS grandfathering documentation.