Can SIS be integrated but separate?

From papers presented to the ISA meeting in Calgary 2005, Spartan Controls discuss the history of Safety Instrumented System and the new DeltaV architecture that is now available

Merry Spooner and Trevor MacDougall, Technical Sales Specialists at Spartan Controls, Alberta presented the follwing paper to an ISA Conference in Calgary in 2005.

The paper discusses the history of the Safety Instrumented System (SIS) and the new DeltaV architecture that is now available.

The SIS has become more important in recent years due to accidents in the process industries.

These incidents led engineering organizations to develop best practices and standards.

These standards suggested that a separate system needed to be implemented for safety functions away from the basic process control system (BPCS).

A separate SIS minimised the risk of common cause 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 and networking considerations between the SIS and BPCS.

Additional hardware gateways and muxes add complexity and additional possible points of failure.

Two completely separate systems add maintenance and training costs.

The spare parts inventory needed increases and change management can become a nightmare.

Through a new architecture, utilising device diagnostics through the HART protocol, that is separate but integrated, the difficulties with SIS have been reduced.

This review paper discusses the new architecture as it relates to the current industry standards and how it reduces common SIS difficulties.

INTRODUCTION.

Why has there been so much interest in the Safety Instrumented System (SIS) market recently? Safety is something that everyone considers important but it has received an increasing amount of focus and press lately.

Serious accidents in industry are one of the reasons.

The accident at a Union Carbide Chemical plant in Bhopal, India is one of the first to come to mind.

An explosion at the plant led to the death of 2,000 people and the injury of over 50,000 people.

Accidents such as this require the process industry to take a hard look at current practices such as maintenance, management of change, process design, etc.

It also leads insurers of process plants to enforce more stringent policies around risk mitigation.

Worldwide engineering organizations have developed standards for the engineering of process safety.

Recently IEC released two standards IEC 61508 aimed at the suppliers of process safety equipment and IEC 61511 aimed at the end users of process safety equipment.

These standards are already widely accepted in the European community.

In the United States, S84 has been the accepted process safety standard.

In 2004, S84 2004 was released which is almost identical to IEC 61511.

So what does all this mean? A focus on process safety and Safety Instrumented Systems is here to stay.

While all countries do not have a governing body that forces the use of standards, many require the use of "good engineering practice" which is normally defined as the use of a widely accepted industry standard.

The Basic Process Control System (BPCS) is the lowest layer of protection and is responsible for the normal operation of the plant.

If this system fails or is incapable of maintaining control then the second layer (Operator Intervention) attempts to resolve the problem.

If the operator cannot maintain control within certain limits then the Safety System Layer must attempt to bring the plant to a safe condition.

For this hierarchy to be effective it is critical that each layer be independent or separate.

This means that the two layers (BPCS and SIS) must not contain common components that in the event of a failure would actually prevent the SIS layer from protecting the facility/people when the BPCS layer experiences a problem.

There would be little value is using a single transmitter connected to the BPCS and the Safety System.

If this transmitter caused the failure by giving false information to the BPCS it could not be relied upon to give accurate information to the safety system.

This idea of eliminating common cause faults has lead to many discussions about separation.

For this reason the end devices and the logic solvers in each system need to be separate from the BPCS.

Therefore responsible designers and governing bodies have made standards that enforce this separation.

A short review of some safety terminology will help as we move forward.

The Safety Instrumented System (SIS) is a set of components such as sensors, logic solvers, and final control elements arranged for the purpose of taking the process to a safe state when predetermined conditions are violated.

Another view is that it is a collection of Safety Instrumented Functions (SIF).

A SIF is a loop composed of one or more transmitters and one or more valves linked together for the purpose 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 SIL of their plant.

Often SIL 3 was considered a "worse case" and plants were designed around this rating.

This led to over engineering and expensive systems.

Current standards require that each SIF in a Safety Instrumented System 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 and SIL 0 SIFs.

After each SIF has been assigned a SIL level, a Risk Reduction Factor (RRF) must be determined.

The RRF is the reduction in risk that has to be achieved to meet the tolerable risk for a specific situation.

Traditionally, when looking at ways to reduce risk in order to achieve the correct RRF the focus has been on the SIS logic solver.

The logic solver was the most complex part of the SIF.

This complexity required the people who configured it to be highly skilled in the safety system programming.

These people rarely looked outside the logic solver to see how the end devices affected the risk reduction factor assumed.

Research compiled in the OREDA Offshore Reliability Database shows that only 8% of SIS failures are a result of a problem in the logic solver.

The measurement device causes 42% of the failures and 50% are caused by the final element.

It is important to note that we will now focus on the logic solver that in reality is only 8% of the problem.

So why weren't the end devices taken into account? One reason is that historically it has been very difficult to get information from the end devices used by the SIS.

Even if "smart" devices with HART diagnostics were used, to get the HART signal required HART multiplexers to strip off the HART signal and send it the Asset Management System (AMS) where it then had to be re-connected with the data from the SIS devices.

This made it very difficult to determine the status of the devices or use this data to make any informed decisions.

The theoretical reason for separation of BPCS and SIS systems has been introduced but in reality these systems need to be integrated at some level to provide an effective interface for plant personnel.

There is no such thing as completely SEPARATE, only how INTEGRATED should they be? The two systems have to be programmed for their unique operation and I/O, and then need to be integrated in one form or another to exchange data so that operator and maintenance staff can manage the plant operation.

This integration involves significant physical wiring and data mapping traditionally done using serial and/or OPC.

This integration also brings with it new risks of error or component failure due to the wiring and data mapping.

A strict management of change process must be used to ensure that any changes made to the BPCS or SIS do not affect the integration of the two systems.

Field devices have evolved into intelligent data servers and can now provide considerable data on the device and process status and health, which is valuable for safety decisions.

This data has historically been directly available only to the BPCS using the HART protocol.

In many instances, HART strippers, additional wiring, AMS software and hardware, and then additional data mapping was required to take advantage of this information.

It has been documented in many projects that the cost of integration/combination is more than two times the cost of the base SIS system software and configuration.

The basis of this paper is to present a new alternative using a truly integrated system.

For the DeltaV SIS system this involves new scalable TUV approved SIL 3 logic solvers communicating on a separate communication network but being programmed and operated from a common (BPCS) control network.

Each logic solver contains a redundant set of CPUs, which handle all processing for the SIS system.

The I/O for the SIS is integrated into the Logic Solver.

No external I/O cards are used.

Logic solvers can communicate with one another over a peer-to-peer SIS ring network.

The SIS network is not accessible by any components of the BPCS.

The BPCS controllers receive information from the logic solvers via a different bus to allow SIS information to be viewed by plant operators.

The BPCS controllers are also used to write configuration changes to the SIS logic solvers when security allows.

No SIS configuration is run in the BPCS controller.

At first glance this may seem to violate some basic principles of separation but it is believed that these issues can be discussed while at the same time the tremendous 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 new logic solver and therefore all the field components including sensors, wiring, and control elements are separate and can be identical for all SIS system implementations.

Within the SIS system the following is separate from the BPCS system: - Logic processors and Terminal Blocks - I/O cards - Power - Communications - Operating System in the Logic Solver It is possible to mount both BPCS modules and SIS logic solver modules on the same backplane and meet IEC standards for SIL 3.

This feature is probably the most difficult to grasp and in many applications these modules are installed on separate backplane carriers and sometimes in separate cabinets to provide for a physical separation to mitigate human error during maintenance and operation.

The new (scaleable) logic solvers have a capacity of 16 configurable I/O and can be configured on an individual basis to closely match the SIF functions being protected.

This is very different both in physical layout and configuration as compared to the historical SIS approach.

Separation is great for safety but not so great for engineering, operations, and maintenance.

From an operational and maintenance point of view it is important to understand what is happening in the opposite system and present that information to the operations and maintenance staff in a single and cohesive manner.

This evolutionary system is really only integrated at the HMI level.

The engineering and operations functionality is isolated from the actual logic solver using a safety write protection layer of software.

This layer protects the logic solver from receiving unsolicited data from elements in the BPCS system.

Although the engineering/configuration environment appears to be identical to the BPCS and utilizes a common format there are significant differences in the actual operation.

The safety system configuration tools require a completely different level of security for access and use.

When an individual logs on, he/she must have Safety security clearance to be allowed into the safety configuration environment.

Once in the safety configuration mode a completely different and unique set of TUV approved function blocks are available that can be configured and downloaded to a safety logic solver.

Safety blocks cannot be downloaded to a BPCS controller and BPCS function blocks and code cannot be downloaded to a 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 not allow the BPCS to write to the SIS.

This feature eliminates the need for the data mapping and buses previously needed to integrate these elements.

Each tag is defined one time in the system as either an SIS or BPCS tag.

It is then available for trending, display on graphics, historization, etc The BPCS and SIS systems share a common Alarm Summary Screen.

SIS Alarms are shown in a different category from process alarms.

SIS events are also integrated into the BPCS Event Chronicle.

This allows for SIS events to be sorted separately from the BPCS events or sorted by time to see process and SIS reactions to a certain event.

The SIS Network is integrated into the Diagnostics Explorer as well for easy viewing of SIS network and hardware diagnostics.

AMS ADVANTAGES.

The architecture discussed above is an integrated SIS system that takes into account the HART diagnostics from the end devices in the SIF.

This system was designed to comply with IEC 61508 and to make it easier for end user's to comply with IEC 61511.

Using intelligent field devices communicating using the HART protocol provides improved 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 before the SIS reacts to it.

This improves plant availability by lowering the number of spurious trips caused by malfunctioning devices.

By eliminating the need for muxes there are fewer third party components needed within your BPCS and SIS systems.

It also allows for a seamless interface for both systems without the need for serial or OPC hardware and software links.

Moving the focus back to the SIF as a whole, it is important to look at the final element and risks traditionally associated with it in an SIS system.

The final control element (valve) in an SIF has a very simple job.

When an event occurs, it needs 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 without testing there is no way to ensure that the valve will go to a safe position when called upon to do so.

Because of these concerns, good engineering practice requires the testing of the final control element at regular intervals to be able to claim a certain RRF.

This testing, while simple in nature, can introduce risk into the plant environment.

Many plants have installed bypass valves, double block and bleed valves and expensive pneumatic panels to be able to test the final SIS control elements without shutting down the plant.

Manual installation of mechanical valve interlocks (pins, etc) can put operations and maintenance personnel in hazardous areas of the plant during installation and removal of these devices.

If the devices fail to be removed after testing, they can prevent the final element from closing during a safety event.

Using HART and automated partial stroke testing allows for the extension of the time intervals between full-stroke testing on plant final control elements.

This can have a significant positive effect on plant shutdowns and turnarounds.

Assuming the valve used has diagnostic capabilities and it is integrated with an asset management package that supports this functionality, pneumatic supply, actuator pressure, and valve position are tested to verify that the components will perform in an actual event.

Since this testing is done automatically by the device itself, it reduces human error, risks to operations and maintenance personnel and leads to better maintenance practices.

Partial stroke testing can also be scheduled to run automatically on a set time interval.

The testing and the results will be captured in the Event Chronicle, which can be used as documentation to prove that the test was performed.

SIS ADVANTAGES.

The combination of integration and separation will allow this system to achieve a rating of SIL 3 with a single simplex logic solver.

A redundant logic solver configuration is also available to increase availability but is not required for a SIL 3 rating.

The integration of the SIS and BPCS will also reduce maintenance costs by providing a common operator interface for SIS and BPCS functions, managing bypasses during start up sequences, synchronizing time and collecting events between both systems and by performing continuous diagnostic testing of sensors and final control elements.

Since the same vendor supplies both systems, it also minimizes the number of people to contact to get the support and answers needed if there is a problem.

Training and maintenance costs can also be reduced because of the common engineering platform and common components between the two systems.

CONCLUSION.

In review of this evolutionary SIS architecture hopefully it is now clear that although the system appears to be totally integrated that in reality the SIS system is a separate system and will provide the common cause fault elimination.

The system's integration at the HMI level provides significant benefits while extra security and a write protect layer prevents any inappropriate communication.

The HART muxes, extra field wiring and buses historically needed have been eliminated but the use of diagnostic and maintenance information has been seamlessly incorporated into the safe and efficient operation of the SIS system.

This combination of a SIL 3 rated SIS system and the Basic Process Control System has significant advantages over the historical approach.

These advantages will lead to significant reductions in both Total Installed Cost (TIC) and longer term Total Operational Costs (TOC) through the use of an approved SIS system with improved availability, reduced costs, and integrated use of the HART protocol and AMS functionality.

Back to top