Roadblocks to Approving SIS Equipment by Prior Use Joseph F. Siebert exida Prepared For ISA EXPO 2006/Texas A&M Instrumentation Symposium Houston, TX/College Station, TX October 18, 2006/ January 24, 2007 Keywords: SIS, Prior Use, SIS Equipment Abstract: Both IEC 61508 and ISA84.01-2004 (IEC 61511 Mod.) have clauses describing Prior Use requirements. This paper will discuss particular roadblocks found at the plant site in trying to meet Prior Use guidelines. Introduction: Prior Use (Proven In Use in 61508) equipment is when a documented assessment has shown that there is appropriate evidence, based on the previous use of the component, that the component is suitable for use in a particular application of a safety instrumented system at a given integrity level. There are two dimensions to this issue, suitability of a component to meet application requirements and sufficient integrity for safety critical functions. Joseph F. Siebert Page 1
Both international functional safety standards, IEC 61508 and ISA84.01-2004 (IEC 61511 MOD.) have clauses describing Prior Use requirements. One should also refer to TR84.00.04 for additional information on Prior Use. This paper will discuss some of the particular roadblocks found at the plant site in trying to meet Prior Use guidelines in the ISA84.01-2004 (IEC 61511 MOD.) standard. This paper will not discuss the process for assessing the equipment. Where are we in the Safety Lifecycle Phase? A project team has completed the hazard and risk assessment and they have allocated the safety functions to protective layers. If the project team decided a Safety Interlock System (SIS) was required to reduce the hazards to an acceptable level then they have completed the SIS safety requirement specifications for the hardware and the software, i.e. the analysis phase of ISA84.01-2004 (IEC 61511 MOD.) has been completed. The project is ready to begin the design phase of the SIS. One of the things the designers will need is a list of approved components or subsystems to be used for the SIS. ISA84.01-2004 (IEC 61511 MOD.) provides two choices of how to populate that list. Components selected for use as part of a safety instrumented system for SIL 1 to SIL 3 applications shall either be in accordance with IEC 61508-2 and IEC 61508-3, i.e. certified for use (by a third party expert certification agent) [more than this is required to make the users approved list]; or they shall be in accordance with 11.5.3 to 11.5.6 Prior Use. In actual practice it seems both techniques must be used. The manufacturer should provide IEC 61508 certified equipment but this alone is not enough. The end user has some overlapping responsibilities and must evaluate the applicability of a component for a particular application. Manufacturer and end user must provide mutually beneficial information to each other. While this sounds good, why is it so hard to do in reality? ROADBLOCK 1: Why are we doing this now? We ve never had an approved list of components in the past. Let s look back at two examples encountered that speak to this roadblock. Both examples point out the particular difficult problems we face because of the ubiquitous use of software in today s instrumentation. Example 1: In 1978 a system was designed that used the DCS system for both process control and as the SIS. Operations were specifically concerned about using this new technology called DCS to protect the lives of individuals. A new engineer for this company was assigned the task to investigate the design. He had little experience in either DCS or Safety Instrumented Systems. Luckily, the plant had a standard dealing with Safety Instrumented Systems. This standard specifically prohibited the use of a softwired system for safety protection. A hardwired safety instrumented system was designed and installed. Joseph F. Siebert Page 2
The DCS was programmed as a backup. Both systems seemed to be working perfectly. However about ten years after installation of the hardwired SIS and DCS it was discovered that a fatal, dangerous, and hidden flaw was found in the DCS system. An astute operator was looking over the control system and discovered that the analog inputs for these now backup DCS safety control functions were not updating. The operator discovered this systematic design flaw. The programming by the manufacturer allowed so much time to scan all of the analog inputs. When the scan time was over the limit, the system stopped scanning any additional analog inputs and went about performing other tasks. When it returned to the task of scanning the analog inputs it began all over again, i.e. it didn t begin where it left off. These particular analog inputs were never being scanned! The original system, if not corrected, would not have had the independence or integrity required for safety systems due to a systematic fault in the software. It took many years of actual usage to discover the problem. Example 2: In 2004 an instrument technician required assistance in troubleshooting a problem. In his rounds he discovered a stand alone interlock module had indicated a failure via its red fault annunciation light. This system was about eight years old. We paged through the modules display and could find nothing wrong. We called the manufacturer and ask for their assistance. The response we got was to reset the module and see if it happened again. Again, it appears that this particular stand alone safety module didn t have the required level of safety integrity because of a transient systematic software fault. My point is that equipment today is quite complex and there are many opportunities to make mistakes especially with software. The problems caused by the faults require special techniques to uncover and correct. Even after 26 years, potential software problems are still being designed into components today. To avoid them we must carefully track field failures and report them back to the manufacturer. We must keep a list of approved equipment that does not appear to have these problems to help us provide the required safety. ROADBLOCK 2: Our designs are fail safe so why should we do all of this work of recording this data for safe failures? This concept of fail-safe design being the Holy Grail is seen in many different discussions and decisions. We need to be very careful on how we use this concept of fail safe. It does not mean that failures need not be recorded. For example: A plant is presented with the problem of deciding if an incident investigation should be held because the unit interlocked. The plant decides that since it was a safe failure we don t need to have an investigation because we have fail-safe designs. The plant may not understand the application or the failure mode... just that it was a safe failure and we have fail safe designs so everything must be O.K. Joseph F. Siebert Page 3
It is not suggested that all safe failures need to be investigated. It is suggested that more information is required than just was it safe or dangerous to make this decision. A safe failure of the wire came off the transmitter may not need to be investigated because we design for those modes of failures. However, the instrument failed high and it was a high interlock may need to be investigated. It failed safe not by design but because of the particular application. We must at least record all component failures not just what is deemed a dangerous failure. ROADBLOCK 3: Why record this failure? Let s fix it and get on with running the plant. While this mentality is common it ignores the benefits of having failure data. Unfortunately this mentality applies both when the unit has interlocked down because of an instrument failure and also when we are running periodic tests. Let me explain three distinct types of maintenance activities and how they must be kept in front of the plant organization. The first activity is repair work. We have a problem and we need to get it fixed. This is how much of the work is categorized. Sometimes this is how all of the work is categorized. Repair work is performed to fix revealed faults. Since they are revealed faults our activities must be dedicated to repairing these faults quickly and recording the repair information associated with the fault. The second activity is the maintenance activity of running periodic tests. Periodic tests are performed to detect unrevealed faults; faults that could have existed since the last periodic test. This maintenance work is looking back in time and trying to verify that we have been operating with the safety protection provided by the SIS. It is not looking forward which is the thought behind let s just fix it and get up and running. It is not understood that we must record and analyze the important data from periodic tests. We need to have this data to both verify our assumptions and insure continuous improvement as we go forward. Let me give an example of this organizational behavior. Recently a review of periodic test data was initiated to decide if it was justified to extend periodic test intervals. This review was being undertaken because it was felt that the test intervals could be lengthened. Each group of tests required a unit shutdown. This particular unit has around 150 SIFs. Proof test records were requested for the last ten years. Unfortunately there was not one periodic test failure recorded for those ten years. That was astonishing. How can this be explained? Certainly many failures had been witnessed. While the culture of the site was to never return the unit to operation with SIFs that were not completely functional, two key issues remain. First, the belief that recording the failure was bad. Second, the belief that all that was important was to leave the SIF without any failures. The plant required as found data and as left data and as left data, but the only data being recorded was the as left data. Joseph F. Siebert Page 4
The third activity is preventative maintenance. Preventative maintenance is performed because our past experience says we must overhaul equipment or replace equipment to insure safe operation over the expected life time of the instruments. The preventative maintenance schedule is based on our collective information provided by the manufacturer, the periodic test and repair recorded data. Again, all component failures need to be recorded. ROADBLOCK 4: Why don t we just use certified equipment going forward and don t worry about recording failure data? There are many problems with this concept. Certifying agencies make assumptions as to: installation practices performance of supplied utilities the maintenance employed application error or abuse the integration of all the components The end user must consider these factors at design and during maintenance activities to insure system integrity. Suitability of a component for a particular application must be determined by the end user. Failure data is needed to make that determination. ROADBLOCK 5: Our equipment may not be certified. All of the complexity of programmable components makes full user certification of components impractical if not impossible. So the manufacturer and the end user together must certify the equipment I believe that getting an approved list at the plant site can t be effectively done today. You not only face the problem of not having equipment certified by an agency but you probably don t have good data to support your integrity claim nor have you statistically analyzed the data. There isn t a quick solution to getting an approved list of equipment. It will take time for you to develop the required maintenance data collecting systems and then record the appropriate data. Roadblock 6: There are not many true reliability engineers on-site. I have found very few engineers disciplined in the science of reliability engineering. This is not to say that we don t have a lot of engineers at the plants looking at the cause of poor equipment reliability. However, I don t think we have those that are trained in what is required to do field failure rate reliability analysis. Joseph F. Siebert Page 5
It is important to know that more information is required than just collecting the fail-safe or fail dangerous mode. Prior use needs a sound mechanical reporting and analyzing program. The data needs to be collected and analyzed so that we can determine if the failure was due to random stress or due to a systematic design fault. Further we should understand if the systematic design fault came from the manufacturer or from a bad application of the component by the end user. This quality of data is necessary to estimate installed random failure rates. Too often failure rate calculations are done when only a portion of field failures are recorded. This results in failure rates that can be orders of magnitude too low. If this data is used to increase proof test intervals, safety is compromised. Fortunately this roadblock can be solved via outside help. Several companies have programs available to help set up quality data recording systems. One of the first steps to being able to get your list of acceptable equipment is to begin recording your data. We now have the capability to gather the data and we should begin today. The CCPS task called PERD can assist you in the approach to setting up your data collection tools. CONCLUSIONS All of the complexity of programmable components makes full user justification of components for high integrity safety applications impractical if not impossible. Getting an approved list of SIS equipment at the plant site can not be effectively done by most end users today. Experience tells us that systematic failures may not become apparent until a piece of equipment is used for many years. However the standard requires all the appropriate evidence shall be available that the components and subsystems are suitable for use in the safety instrumented system [ISA84.01-2004 (IEC 61511 MOD.), Part 1, 11.5.3.1]. There is not a quick solution to achieving this requirement of the standard. Fortunately manufacturers are quickly getting their products certified per IEC 61508. The list of certified equipment today includes pressure transmitters, temperature transmitters, logic solvers, solenoid valves, actuators, and large valves of many types. This is good. But remember that the end user still has the responsibility to qualify equipment for particular applications. Good field failure data is required for this. It will take time to develop the required maintenance data collecting systems. Good field failure data will require the coordination of many people: an E&I engineer, a reliability engineer, E&I mechanics, and certainly managers to insure systems are in place. Also remember: The list of approved equipment must be updated and monitored regularly Field devices are only added when sufficient operating experience has been obtained Joseph F. Siebert Page 6
The maintenance records must include the detailed information Field devices are removed when they show a history of not performing in a satisfactory manner So why are we doing all this? So that: 1. We build safer systems that do not experience as many of the problems of the past. 2. We build more cost effective systems that match design with risk. 3. We provide a global framework for consistent correct integrity designs. REFERENCES: 1. IEC 61508, Functional safety of electrical/electronic/ programmable electronic safetyrelated systems, Geneva, Switzerland, 2000. 2. ANSI/ISA SP84.00.01 2004 (IEC 61511 Mod.), Application of Safety Instrumented Systems for the Process Industries, Raleigh, NC, ISA, 2004. 3. W. M. Goble and Harry Cheddie, Safety Instrumented Systems Verification: Practical Probabilistic Calculations, ISA, NC: Research Triangle Park, 2005. 4. Guidelines for Process Equipment Reliability Data, Center for Chemical Process Safety, American Institute of Chemical Engineers, 1989. Joseph F. Siebert Page 7