Project: Biopharmaceutical filtration automation August 2, 2005
August 2, 2005
A good interlock design is one of the most crucial parts of any project as it provides protection of a company's most valuable assets--personnel, product and plant equipment. There are a few rules that we follow to make the interlock implementation easy to design, implement, and troubleshoot.
Rule 1 – Interlocks are implemented at the control module layer between control modules. Since interlocking logic is designed to prevent unsafe equipment operation, it makes sense to implement them on the software that performs equipment control.
Rule 2 – Device I/O points are monitored and manipulated exclusively through control modules. Equipment modules, phases, or other logic will never write directly to or read directly from an I/O point. Other code modules will interface with process equipment through the interfaces provided by control modules. For example, if a phase is to open a valve, it does so by commanding the appropriate valve control module to open-- if the valve is currently used by an operator or interlocked close, the phase is unable to open the valve. Interlock integrity is essential to safe plant operations.
Rule 3 – Interlocking logic is based upon control module states, not the actual I/O point. This is important for providing plant operations and maintenance personnel with the tools necessary to operate the plant safely when process instrumentation is not functioning properly. For example, a failed valvelimit switch may falsely indicate a valve to be closed when it is actually open. This state may interlock other valves or motors. By providing a switch failure override within a valve control module, users can override the failed switch and continue normal operations if interlocks are based upon a control module logical state determined by limit switch position or a user override. This design distributes override functionality inside each control module (at the source) instead of adding it to the interlock logic (often after the fact).
Interlock logic is notorious for confusing operators because it is designed to prevent or permit equipment operation; yet this logic is seldom displayed to operators. To make interlocks easier to understand, we have modularized interlocks and developed a faceplate interface so they are accessible by operators. Each control module type includes an input permissive parameter whose value must be True to permit operation of the control module. An interlock control module performs the interlocking logic and generates a single bit that is passed to the device control module's permissive input. For example, an interlock control module has been created for feed pump PMP-012-02. The interlock control module tag is PMP-012-02-I. The “-I” suffix identifies the module as containing interlock logic for control module PMP-012-02--the feed pump variable speed motor controller.
Anyone can find the interlocking logic for a device if all they need to look for is the device tag followed by “-I”. But how does this help the operator? The key to helping the operator is an easily accessible display (the control module faceplate) and a way to translate the logic into descriptive text. For an operator, it is not important to know the details of the complete logic but the conditions that are preventing equipment operation. Conceptually any interlock looks something like this diagram.
Since any condition could prevent equipment operation, we present each condition to the operator with a text description that is backlit either in green (this condition is OK) or in red (this one prevents equipment operation).
When a device is interlocked, an icon is displayed next to the device on the graphic.
The faceplate opens when an operator clicks on this icon, thereby making it obvious what prevents equipment operation.
Next week we’ll cover simulating the process.