Within the process industry, control functions are used to achieve production and product quality targets, reduce manpower requirements, reduce human errors and improve process uptime.
Today we have digital “open” control systems that are far more robust and capable in terms of performance and diagnostics than their DCS predecessors, but that doesn’t mean they can be relied on to perform control and safety functions.
Understand the Differences
The control system may be implemented as part of a basic process control system (BPCS), which is separate and independent of the safety instrumented system (SIS). The BPCS may execute control and safety functions when it is designed and managed to achieve the assumed risk reduction or hazard rate. A BPCS may not execute a safety instrumented function with a SIL ≥ 1 (see ISA 84.01/IEC 61511, clause 3.2.3).
Use of the BPCS to perform a safety function is highly restricted, since a dangerous failure somewhere within the system may lead to the loss of control and potentially to a hazardous event. Control functions are often configured to continue plant operation on detected failure rather than failing to a safe state. The dangerous failure rate of a BPCS that places a demand on a protection layer cannot be assumed to be better than 10-5 per hour (see ISA 84.01/IEC 6151l, clause 8.2.2).
The use of the BPCS to perform a safety function should be approved by a hazard and risk analysis team. The risk reduction factor for a BPCS used as a protection layer must be assumed to be below 10 (see ISA 84.01/IEC 61511, clause 9.4.2).
When the SIS is independent of the BPCS, it generally operates as a dormant system that takes action only in response to operation outside the normal operating envelope. These process demands are often caused by failures within the BPCS. The SIS is designed and managed to ISA 84.01/IEC 61511 to achieve a specified safety integrity level (SIL). Most SIS’s are designed to fail to the safe state on loss of power or other support systems. SIS devices are also configured to fail to the safe state on detected failure, unless compensating measures are available to reduce the risk equivalently to the failed device.
Independence is a fundamental principle in the design of the SIS, regardless of the capability of the BPCS. The systems should be sufficiently independent so that one system can suffer a complete system collapse while the other system remains fully functional. If this criterion cannot be met, the entire system–BPCS and SIS–must be designed and managed as a SIS under the rigors of ISA 84.01/IEC 61511.
Maintaining such rigor dramatically increases the cost of BPCS ownership and significantly restricts BPCS flexibility. However, applying the ISA 84.01/IEC 61511 life cycle and its associated quality management system to the BPCS can add significant benefits, because better managed systems tend to operate more reliably.
As technology has evolved, emphasis continues to be placed on maintaining the independence and separation of the BPCS and SIS functions. When separation is not provided, the potential for human error increases as system components are accessed more frequently. The approximate ratio of BPCS-to-SIS input and output signals is more than 90% BPCS to less than 10% SIS. When these systems are combined, the need for access significantly increases. Increased system access results in a greater potential for inadvertent and unintentional changes resulting in an increased need for a more rigorous management system. Finally, when the BPCS and SIS are combined into a single SIS, the logic solver likely operates in a continuous mode because a dangerous failure within the logic solver may cause a simultaneous loss of control and safety functions.
Understanding the BPCS
Over time, the BPCS evolved into programmable logic controllers (PLC) and distributed control systems (DCS), which are based on programmable electronic (PE) technology.
PE technology brought an increased ability to execute more control functions on a single platform. This processing capability allowed the implementation of statistical process control, predictive control algorithms and other advanced control techniques, resulting in tremendous productivity and quality improvements.
Today, most process units are highly dependent on automated control systems. Operators rely on the BPCS and its operator interface for process information during normal operation, for alarms during process excursions and for troubleshooting process control problems.
BPCS technology provides significant benefits with its capabilities and flexibility, but it also introduces new and more complex failures. This creates an environment where, if administrative controls are not in place, the BPCS exists in an almost endless state of flux, where control loops are routinely placed in manual mode, alarms are disabled or reset by operators based on personal choice and process control specialists implement the newest in control algorithms while the process unit is in operation.
Understanding the SIS
At a minimum, an SIS consists of a sensor, a logic solver, a final element and a support system. The SIS includes a combination of hardware and software elements that work in unison to detect process hazards and take defined actions to achieve or maintain a safe state. Historically, SIS’s were implemented using process switches, hardwired electrical systems and final elements, such as motor control circuits or solenoid-operated block valves. Since the SIS was physically separate and diverse from the BPCS, functional independence of the SIS and the BPCS was easily evaluated. The BPCS and SIS were designed and maintained by diverse personnel and departments. The two systems shared few, if any, components, technology or personnel support.
When programmable electronic system (PES) technology became available, there was hesitation concerning its use in safety applications. Incidents were reported in which input and output points stuck in position without warning or the main processor halted.
Following years of use in control applications, owner/operators learned the nature of PES failure and how to detect it through diagnostics. PES’s were “safety configured” to detect known failures, including the configuration of input and output signal and main processor diagnostics. Output signals are often pulsed to detect stuck points, and watchdog timer circuits are commonly used to detect misbehaving microprocessors.
Improvements in safety PES performance have been gained through implementation of extensive self-diagnostics. For SIS applications, the diagnostics are configured to take failed components and/or a single output channel to predefined safe states. This philosophy supports safe operation, but results in impact to plant uptime, resulting from possible spurious trips.
When SIS reliability is paramount, designs will likely employ redundant channels with appropriate voting and enhanced diagnostics, such as channel value comparisons.
Eventually, complex functions migrated into safety PES, while simple functions remained in electrical systems such as relays or trip amplifiers. For low input/output (I/O) applications, electrical systems are very cost-effective and easily implemented. Large I/O signal requirements often make a safety PES more cost-effective than a comparable electrical system, but larger safety PES’s also increase the number of potential failures in the hardware and software, making analysis and design more costly.
A dedicated safety PES engineering interface should be used to facilitate administrative control of SIS logic and to reduce the potential impact of routine BPCS changes on the SIS. Software modifications should be controlled through a software management of change (MOC) procedure with version tracking. Access security should include:
- Restricting access to the engineering interface, such as placing the engineering interface computer in a locked cabinet;
- Applying robust password administration policy within the programming interface;
- Restricting hardware access in order to prevent unauthorized downloads of a new or revised application program to the safety PES.
To reduce the potential for data corruption, communication between the BPCS and SIS should be highly restricted. In most cases read-only communication should be applied, with the BPCS allowed only to read information from the SIS. If communication from the BPCS to the SIS is absolutely necessary, the communication technique must be evaluated for potential failures and steps must be applied that reduce the potential that a communication failure will result in an SIS failure.
Most owner/operators continue the practice of implementing separate, and often diverse, platforms for the BPCS and SIS following the well-proven, “defense in depth” strategy that supports both safety and reliability. With a physically separate BPCS controller and SIS logic solver, independence is easier to assess and manage over the process equipment lifetime. Independence also allows the owner/operator to implement a less rigorous management system for the BPCS.
Within the process industry, control functions have always existed to help achieve production and product quality targets, reduce manpower requirements, reduce human errors and improve process uptime. Those are the duties of the BPCS. The duties of the SIS are to protect the people, environment and assets against unsafe conditions.
| About the Author |
