Interested in linking to "The evolution of plant automation"?
You may use the Headline, Deck, Byline and URL of this article on your Web site. To link to this article, select and copy the HTML code below and paste it on your own Web site.
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:
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|
Angela Summers, PhD, PE, is a member of the IEC 61511 and 61508 committees and chairs ISA’s TR84.02 and TR84.04 committees. Reach Dr. Summers at email@example.com. She is profiled in the cover story as an inductee of the Hall of Fame.
ControlGlobal.com is exclusively dedicated to the global process automation market. We report on developing industry trends, illustrate successful industry applications, and update the basic skills and knowledge base that provide the profession's foundation.