safety instrumented systems: can they be integrated but separate

SAFETY INSTRUMENTED SYSTEMS: CAN THEYBE INTEGRATED BUT SEPARATE?Merry SpoonerTechnical Sales SpecialistSpartan ControlsCalgary, AlbertaTrevor MacDougallTechnical Sales SpecialistSpartan ControlsCalgary, AlbertaKEYWORDSSafety Instrumented Systems, Safety Functions, Safety Instrumented SystemStandards, IEC 61511, IEC 61508, S84 2004ABSTRACTThis paper will discuss the history of the Safety Instrumented System (SIS) and anew architecture that is now available.The SIS has become more important in recent years due to accidents in theprocess industries. These incidents led engineering organizations to developbest practices and standards. These standards suggested that a separatesystem needed to be implemented for safety functions away from the basicprocess control system (BPCS). A separate SIS minimized the risk of commoncause failures. This separation has become an industry standard.Though separation allows for safer operations, it is not without its difficulties.Configuration of the SIS can be a tedious process with data mapping andnetworking considerations between the SIS and BPCS. Additional hardwaregateways and muxes add complexity and additional possible points of failure.Two completely separate systems add maintenance and training costs. Thespare parts inventory needed increases and change management can become anightmare.Through a new architecture, utilizing device diagnostics through the HARTprotocol, that is separate but integrated, the difficulties with SIS have been

A short review of some safety terminology will help as we move forward. TheSafety Instrumented System (SIS) is a set of components such as sensors, logicsolvers, and final control elements arranged for the purpose of taking the processto a safe state when predetermined conditions are violated. Another view is that itis a collection of Safety Instrumented Functions (SIF). A SIF is a loop composedof one or more transmitters and one or more valves linked together for thepurpose of preventing hazards. Each SIF is rated as a Safety Integrity Level(SIL) based upon the consequence and frequency of occurrence. In the past,process plants used different methods to define the Safety Integrity Level or SILof their plant. Often SIL 3 was considered a “worse case” and plants weredesigned around this rating. This led to over engineering and expensivesystems. Current standards require that each SIF in a Safety InstrumentedSystem be considered separately. This means that there are no “SIL 3 plants”.There are process plants that may be a combination of SIL 3, SIL 2, SIL 1 andSIL 0 SIFs. After each SIF has been assigned a SIL level, a Risk ReductionFactor (RRF) must be determined. The RRF is the reduction in risk that has tobe achieved to meet the tolerable risk for a specific situation.Traditionally, when looking at ways to reduce risk in order to achieve the correctRRF the focus has been on the SIS logic solver. The logic solver was the mostcomplex part of the SIF. This complexity required the people who configured it tobe highly skilled in the safety system programming. These people rarely lookedoutside the logic solver to see how the end devices affected the risk reductionfactor assumed. Research compiled in the OREDA Offshore ReliabilityDatabase shows that only 8% of SIS failures are a result of a problem in the logicsolver. The measurement device causes 42% of the failures and 50% arecaused by the final element. It is important to note that we will now focus on thelogic solver that in reality is only 8% of the problem.So why weren’t the end devices taken into account? One reason is thathistorically it has been very difficult to get information from the end devices usedby the SIS. Even if “smart” devices with HART diagnostics were used, to get theHART signal required HART multiplexers to strip off the HART signal and send itthe Asset Management System (AMS) where it then had to be re-connected withthe data from the SIS devices. This made it very difficult to determine the statusof the devices or use this data to make any informed decisions.The theoretical reason for separation of BPCS and SIS systems has beenintroduced but in reality these systems need to be integrated at some level toprovide an effective interface for plant personnel. There is no such thing ascompletely SEPARATE only how INTEGRATED should they be?

Each logic solver contains a redundant set of CPUs, which handle all processingfor the SIS system. The I/O for the SIS is integrated into the Logic Solver. Noexternal I/O cards are used. Logic solvers can communicate with one anotherover a peer-to-peer SIS ring network. The SIS network is not accessible by anycomponents of the BPCS. The BPCS controllers receive information from thelogic solvers via a different bus to allow SIS information to be viewed by plantoperators. The BPCS controllers are also used to write configuration changes tothe SIS logic solvers when security allows. No SIS configuration is run in theBPCS controller.At first glance this may seem to violate some basic principles of separation butit’s believed that these issues can be discussed while at the same time thetremendous benefits that become available can be explained.For this totally integrated system it makes sense to look at what is the same,what is different, and then what is improved.As was mentioned previously, the only new component being discussed is a newlogic solver and therefore all the field components including sensors, wiring, andcontrol elements are separate and can be identical for all SIS systemimplementations. Within the SIS system the following is separate from the BPCSsystem:- Logic processors and Terminal Blocks- I/O cards- Power- Communications- Operating System in the Logic SolverIt is possible to mount both BPCS modules and SIS logic solver modules on thesame backplane and meet IEC standards for SIL 3. This feature is probably themost difficult to grasp and in many applications these modules are installed onseparate backplane carriers and sometimes in separate cabinets to provide for aphysical separation to mitigate human error during maintenance and operation.The new (scaleable) logic solvers have a capacity of 16 configurable I/O and canbe configured on an individual basis to closely match the SIF functions beingprotected. This is very different both in physical layout and configuration ascompared to the historical SIS approach.Separation is great for safety but not so great for engineering, operations, andmaintenance. From an operational and maintenance point of view it is importantto understand what is happening in the opposite system and present thatinformation to the operations and maintenance staff in a single and cohesivemanner.

This evolutionary system is really only integrated at the HMI level. Theengineering and operations functionality is isolated from the actual logic solverusing a safety write protection layer of software. This layer protects the logicsolver from receiving unsolicited data from elements in the BPCS system.Although the engineering/configuration environment appears to be identical tothe BPCS and utilizes a common format there are significant differences in theactual operation. The safety system configuration tools require a completelydifferent level of security for access and use. When an individual logs on, he/shemust have Safety security clearance to be allowed into the safety configurationenvironment. Once in the safety configuration mode a completely different andunique set of TUV approved function blocks are available that can be configuredand downloaded to a safety logic solver. Safety blocks cannot be downloaded toa BPCS controller and BPCS function blocks and code cannot be downloaded toa SIS module.The HMI layer combines data in the event summaries, historical data base, etc.and allows the BPCS access to all the information from the SIS but does notallow the BPCS to write to the SIS. This feature eliminates the need for the datamapping and buses previously needed to integrate these elements. Each tag isdefined one time in the system as either an SIS or BPCS tag. It is then availablefor trending, display on graphics, historization, etc.The BPCS and SIS systems share a common Alarm Summary Screen. SISAlarms are shown in a different category from process alarms. SIS events arealso integrated into the BPCS Event Chronicle. This allows for SIS events to besorted separately from the BPCS events or sorted by time to see process andSIS reactions to a certain event. The SIS Network is integrated into theDiagnostics Explorer as well for easy viewing of SIS network and hardwarediagnostics.AMS ADVANTAGESThe architecture discussed above is an integrated SIS system that takes intoaccount the HART diagnostics from the end devices in the SIF. This system wasdesigned to comply with IEC 61508 and to make it easier for end user’s tocomply with IEC 61511.Using intelligent field devices communicating using the HART protocol providesimproved safety and significant cost reductions in operations and maintenance.These savings result from extensive diagnostics allowing longer test intervals.HART data is used within the SIS to determine the data integrity of point beforethe SIS reacts to it. This improves plant availability by lowering the number ofspurious trips caused by malfunctioning devices.By eliminating the need for muxes there are fewer third party componentsneeded within your BPCS and SIS systems. It also allows for a seamless

interface for both systems without the need for serial or OPC hardware andsoftware links.Moving the focus back to the SIF as a whole, it is important to look at the finalelement and risks traditionally associated with it in an SIS system. The finalcontrol element (valve) in an SIF has a very simple job. When an event occurs, itneeds to go to a safe position to mitigate the risk of injury to plant personnel.This seems simple enough, but in reality these valves are rarely used so withouttesting there is no way to ensure that the valve will go to a safe position whencalled upon to do so. Because of these concerns, good engineering practicerequires the testing of the final control element at regular intervals to be able toclaim a certain RRF. This testing, while simple in nature, can introduce risk intothe plant environment. Many plants have installed bypass valves, double blockand bleed valves and expensive pneumatic panels to be able to test the final SIScontrol elements without shutting down the plant. Manual installation ofmechanical valve interlocks (pins, etc) can put operations and maintenancepersonnel in hazardous areas of the plant during installation and removal ofthese devices. If the devices fail to be removed after testing, they can preventthe final element from closing during a safety event.Using HART and automated partial stroke testing allows for the extension of thetime intervals between full-stroke testing on plant final control elements. This canhave a significant positive effect on plant shutdowns and turnarounds. Assumingthe valve used has diagnostic capabilities and it is integrated with an assetmanagement package that supports this functionality, pneumatic supply, actuatorpressure, and valve position are tested to verify that the components will performin an actual event. Since this testing is done automatically by the device itself, itreduces human error, risks to operations and maintenance personnel and leadsto better maintenance practices. Partial stroke testing can also be scheduled torun automatically on a set time interval. The testing and the results will becaptured in the Event Chronicle, which can be used as documentation to provethat the test was performed.SIS ADVANTAGESThe combination of integration and separation will allow this system to achieve arating of SIL 3 with a single simplex logic solver. A redundant logic solverconfiguration is also available to increase availability but is not required for a SIL3 rating. The integration of the SIS and BPCS will also reduce maintenancecosts by providing a common operator interface for SIS and BPCS functions,managing bypasses during start up sequences, synchronizing time and collectingevents between both systems and by performing continuous diagnostic testing ofsensors and final control elements. Since the same vendor supplies bothsystems, it also minimizes the number of people to contact to get the support andanswers needed if there is a problem. Training and maintenance costs can also

e reduced because of the common engineering platform and commoncomponents between the two systems.CONCLUSIONIn review of this evolutionary SIS architecture hopefully it is now clear thatalthough the system appears to be totally integrated that in reality the SIS systemis a separate system and will provide the common cause fault elimination. Thesystem’s integration at the HMI level provides significant benefits while extrasecurity and a write protect layer prevents any inappropriate communication.The HART muxes, extra field wiring and buses historically needed have beeneliminated but the use of diagnostic and maintenance information has beenseamlessly incorporated into the safe and efficient operation of the SIS system.This combination of a SIL 3 rated SIS system and the Basic Process ControlSystem has significant advantages over the historical approach. Theseadvantages will lead to significant reductions in both Total Installed Cost (TIC)and longer term Total Operational Costs (TOC) through the use of an approvedSIS system with improved availability, reduced costs, and integrated use of theHART protocol and AMS functionality.

REFERENCESOffshore Reliability Data for Worldwide Oil Company Operations, from Phase VIIand Phase VIII 2000-2004 (accessed and searched several times during 2004,through membership) [Online] Available: OREDA project, managed by SINTEFIndustrial Management. http://www.sintef.no/static/tl/projects/oreda/