Chemical plants treat safety as a top priority and install a variety of safety equipment and systems. However, changes in technology as well as new standards suggest that plants take a fresh look at their safety systems. Many facilities may be missing an opportunity to improve safety via a fieldbus. The majority of fieldbus protocols now have an approved safety bus. In addition, many automation vendors today favor integrating the safety instrumented system (SIS) with the process control system.
Figuring out what makes sense for your plant requires an understanding of fieldbuses (see "Take Advantage of Fieldbus") and of the pros and cons of the various fieldbus safety approaches, including integration. Using fieldbuses for safety and integrating the safety system with process control systems are relatively new concepts in the chemical industry — so, many operating companies remain wary of both. Hopefully this article will shed some light on some of the tradeoffs to help you make an informed decision consistent with your-risk management practices.
Conventional fieldbus networks aren't suitable for safety-related controls. Additional error detection and avoidance mechanisms are required for the communications between devices to detect connection or device failures and to implement necessary emergency shutdown action to avoid danger.
The majority of fieldbus systems use a "black channel" approach to their safety communications bus. This basically means the physical layer is the same as their "regular" bus, but with extra checks and balances to meet additional protections and features required of a safety system. These enhancements make the bus a "safety bus" and, in many cases, allow sharing infrastructure between that safety bus and conventional control communications. Despite being able to do so, few if any users will mix their control and safety systems at the physical layer.
When fieldbus organizations say their fieldbus safety devices comply with their appropriate safety standard, it means the device is compliant and consistent with IEC 61508 and verified by TÜV or some other safety organization. Devices and hosts/logic solvers therefore require two sets of safety approvals now — one for the safety fieldbus or communications and a second for the associated safety integrity level (SIL) rating. After obtaining approval for the communications/fieldbus part of its device, a manufacturer must obtain SIL certification from an appropriate organization. Most safety fieldbus specifications are designed so devices can achieve a minimum SIL-2 rating, although many buses are certified to SIL 3.
Figure 1 shows how a combination of changes to both the function blocks (circles in the devices) and communications layer (rectangles) are needed to meet the requirements of IEC 61508 to obtain the SIL rating necessary for a safety bus implementation. The function block changes add the necessary safeguards to the traditional function blocks used for control while the communication layer changes perform additional checks on the messages themselves.
The two international standards applicable to the process industries are IEC 61508 and IEC 61511. The IEC 61508 standard is most relevant to safety device manufacturers as it defines the requirements and criteria upon which a device's reliability and, hence, SIL rating are based. IEC 61511 is the more important standard for end users as it defines how systems are to be designed, installed and operated. ANSI/ISA-84.00.01-2004 is the ANSI-approved and OSHA-referenced version of this document and the one to which systems in the United States must comply. The most recent release includes statements permitting use of fieldbus communications as part of safety systems and removes the requirement that SIS and process control systems must be separate. As a result of this change, ISA has issued a technical report, ISA–TR84.00.06 "Safety Fieldbus Design Considerations for Process Industry Sector Applications," that describes the requirements for using fieldbus in safety applications.
The June 2009 release of the ISA18.2 standard has accelerated the pace of convergence of control and safety systems and is leading practitioners to take steps to treat the two holistically. However, some see that approach as counter to the principles of safety systems. A debate is raging about the wisdom of combining these two systems in a single environment.
Results of a 2009 online CP poll about SIS preference (www.ChemicalProcessing.com/articles/2009/134.html) show how polarized positions are. More respondents (63%) chose "separate from the control system" than "integrated with the control system" (37%). Not a single person selected "no preference" or "don't know."
As Figure 2 indicates, safety systems are one part of the "layers of protection" strategy used to keep a process from entering unsafe conditions. The process design itself is where the principles of safe design must begin. Safety systems serve as the final automation-based step to control a plant disruption before mechanical protection must take over. So, safety systems must have the highest levels of reliability — this involves removing or at least markedly reducing possible single points of failure of the system and of course minimizing the impact of any failure that should occur.
Careful design is crucial for a combined system — with these being new, finding people who know how to do a design correctly can be a challenge. Otherwise the resulting system could lead to lower overall reliability not only of the safety system but the control system as well. This often is part of the price of compromise.
Today, four approaches are available:
The first is the traditional route of providing two separate and unconnected systems from the same or different vendors. This is the highest cost option, both in terms of upfront expenditures and ongoing outlays for operations and maintenance.
The second option is top-level integration of the human/machine interface (HMI) function. This relies on a single supplier providing separate controllers that are both connected to one HMI via a network. Because the controllers are separate and different, controller programming requires two engineering workstations. Costs are lower than with two distinct systems because common hardware is used at the HMI level.
The third uses two HMIs, two controllers and two networks, like the first option, but features two controllers from the same vendor. This allows programming of both controllers from the same engineering workstation. Because the equipment is all configured and operated from the same operating system and development environment, this approach cuts training and maintenance time.
The fourth option, which is the most integrated one, uses common HMIs and two controllers from the same family of a single vendor's products. Both controllers are connected to the HMIs via a single network and, in some cases, can reside on the same backplane. This is the lowest-cost choice because common HMIs and common engineering workstations are employed.
However, the economics of safety systems involve more than just "dollars and cents." So, let's look a little further at the economic side of the equation.
As noted before, the trend — at least from the perspective of distributed control system (DCS) suppliers — is to incorporate the logic solver into the DCS hardware so all components are part of a single environment. One of the biggest benefits of this is that the end user now only has a single configuration and maintenance environment and HMI interface for all data points.
Another significant impact of using the integrated approach is removal of a third party interface (connection to a different system). Integrating different systems is always the most difficult part of a control system to implement and maintain because, in many cases, this requires mapping of parameters across gateways and protocols. In addition, typically when something goes wrong at least two vendors are involved — it's always the other supplier's fault, with you, the customer, being stuck in the middle with the unresolved problem.
One advantage of having separate safety and control systems is that changes (addition or removal of new hardware, system software updates, network changes, etc.) to one system don't directly affect the other. Therefore, when it's necessary to do this sort of work or even to conduct the mandated periodic testing of the full safety loop (input, logic solver and output), there's no risk of inadvertently introducing a disturbance to the regulatory control environment.
Regulations increasingly are mandating use of safety systems in smaller facilities for such applications as burner management of furnaces and boilers. This may make a combined system a better fit for such sites, which often have limited staff — because the people responsible for the plant's automation systems will only have to work in a single integrated environment instead of having to learn how to maintain two different systems.
One of the key considerations in obtaining a desirable SIL rating is the time between maintenance and testing (proof test interval); devices that fail more often require increased testing (less time between intervals) to compensate. Diagnostics enable continuously monitoring the health of all components in the system that can communicate digitally with each other including smart field devices.
The majority of smart devices today use HART communications. The safety system logic solver uses the analog signal while the digital signal, which contains maintenance and diagnostic information, normally goes to a separate system linked to asset management software. (HART has limited support for discrete devices and thus only provides sparse information for these types of instruments and output devices.) Because a dedicated asset-management system interprets the diagnostic information, including device status, another link back to the safety system is required for the instrument status — unless the device has been configured to fail high (>20 mA) or low (typically 3.8 mA).
Being all digital, fieldbuses can communicate field device status every update cycle and normally not only indicate OOS (out of service or failed) but also measurement deterioration or uncertainty. Integrated host systems typically share this type of information more easily than standalone designs.
Buses, especially Foundation Fieldbus, have limited support for discrete input/output (solenoids and contact inputs). Foundation Fieldbus was designed for continuous processes, so discrete processes aren't its core strength. It does support several discrete output (on/off) process valves, though. The Fieldbus Foundation recently released a new transducer block for analog output devices (control valves) to enable partial stroke testing — in part because such testing is a critical component of the testing of safety control loops.
In the end, it's still a case-by-case decision, somewhat like deciding whether to use a multipurpose tool like a Swiss army knife or a suite of dedicated tools for each task. Both will get the job done but there are tradeoffs. Only you can decide what level of risk is acceptable in your facility and what approach will work best in your situation.
IAN VERHAPPEN is director and principal consultant of Industrial Automation Networks Inc., Wainwright, AB. E-mail him at firstname.lastname@example.org.