Control resolved

HSE research, published in their book 'Out of Control', shows that 60% of all process industry accidents can be traced back to errors in the design and specification. Too many companies fail to specify what the control system is supposed to do.
Being aware of this critical situation in the process control documentation, ISA, after numerous reviews and additions, finally issued in 2007 a new standard ANSI/ISA-5.06.01-2007 Functional Requirements Documentation for Control Software Applications.
Initially Piman intended to use this standard as a formal basis for the control interface development. Unfortunately it turned out to be half-cooked:

• ambiguous terminology and lack of definitions,
• offering database design not rooted into modern data structure theory and information modeling,
• lack of practical guidelines for emergency situations, alarms and warnings

Wired items (WI) include: instrument, limit and proximity switches, instruments, valves and electrical drives. Any WI has its own set of logic events and states. For example, flow meter has abnormal "Fault" state described by digital input and normal "Value" state described by the analog input. DOL-started motor has much more individual states and events – "Start/Stop", "Fault", "Running", "Field Ready", "Start From Field", "MCC Ready" and others.

States: 1. Running 2. Ready 3. Not Ready 4. Fault Actions: 5. to run 6. to stop

The Running, Ready, and Not Ready states are normal allowable reversible transition states. Transitions between them are controllable. The Fault state is abnormal and risk-associated one. Any transition to it is unidirectional and irreversible.

Equipment Group (EG) is a group of identical EMs mostly connected in parallel. The main reasoning behind any EG is that EM alone, having standard functional interface, may not meet the process requirements such as dependability and performance flexibility. For example, to pump seawater with dependability of 100% and flow ranging from 20% to 100% at least 3 intake pumps (and 3 EMs respectively) are needed as usually for the turbine type pumps the allowable minimum flow rate is around 40%.
The abovementioned intake station EG with 100% dependability for 100% capacity has no internally caused Fault and Not Ready states. This EG is defined as No-Fault EG. Also it has no To Start and To Stop actions as transition from Ready to Running state has no time attribute (i.e. instantaneous). Running state turns into AutoRun when EG becomes a member of a control loop. For example, the intake pump capacity is controlled by setting the rotation speed via VFD.

• Transition from Ready to Running triggers EM to start from Ready state.
• Revoking to Ready causes EM to stop and move to Not Ready state.
• EG continuous Ready causes EM to move from Not Ready to Ready.

Operation module (OM). Robust control design necessarily includes the plant partitioning into the modules which may be running independently of the successive (downstream) EGs or EMs. Let’s consider intake pumps EG connected to flocculators & filters EG. To turn these groups into operation modules the feed overflow has to be arranged in the feed distribution channel of the gravity dual media filters. The overflow allows the intake pumps operate independently of the filters status. Another important attribute of OM is that it effectively limits the propagation of Fault state upstream by the boundary of operation module itself. Plant partitioning into OMs substantially decreases the revenue losses due to the emergency outages.

• It defines the control flow direction from the process engineer perspective – important process information not shown on the P&ID diagrams.
• It allows easy tracking of state change propagation (Running and Ready - downstream, Not Ready and Fault - upstream).
• It readily identifies control “bottlenecks” and "short circuits" – major control deficiencies and causes for the plant prolonged commissioning.
• It is an input to the plant dependability and HAZOP analysis.
• It contains basic information for HMI and SCADA development.

Interlock describes a system response requirement to predetermined conditions caused by the system malfunctioning (safety interlock) or the process sequencing (process interlock). Interlock may initiate the timed action as well. Safety interlocks may bring about the plant or the operation modules group shutdown. Such interlocks are compound in nature - they are executed after the OM reset (terminating batch and hazardous processes, closing valves, stopping auxiliary systems, etc...).
By ANSI/ISA-5.06.01-2007 the interlock is a single cause-and-effect link between initiating and control devices. This approach to the interlock definition (when requirements are not separated from implementation) is not applicable to the multi-hierarchy control systems - current standard for the big water treatment plants.
The Piman implementation of the interlock interface offers to the user the unmatched flexibility - faults and actions may be single, sequential or compound and be rooted into WI, EM, EG or OM. The example of the compound operational interlock transferring the dual-media filter from the normal operation to the backwash mode is shown below. This interlock logic includes the Boolean math, is physically clear and cannot be modeled by a group of simple interlocks.
Recipe fault is an example of a compound fault and is described by a function including one or more monitoring parameters. The typical functions are minimum and maximum flowrates of the pump with variable speed drive, the resultant vibration of the pump summing up horizontal and vertical readings, reverse osmosis maximum working pressure depending on the recovery ratio, etc...

Delayed fault is a workhorse of the mission-critical processes. It unconditionally triggers some corrective action followed by a time delay needed for trouble-shooting to take place. For instance, high bearing temperatures and vibrations may be caused by the pump overloading (high rotation speed and/or high flow rates). In this situation the pump unloading is much better solution than the whole plant shutdown. The same is true for the "micronic" filter fault - highest pressure differential across the filter cartridge.
Another typical example of delayed fault is the fault generated from within the Control loop. Here the corrective action is applied to the malfunctioning PID controller by restoring its initial conditions.
Very often the time delay is wrongly treated as fault-maturing time: fault as a synonym of "high-high" conditions is already a matured phase of "high" conditions.
Operation sequences. Current practice adopted in many companies for the operation (start/stop) sequences mostly deals with the normal course of events and leaves many “what if” questions unanswered. This practice wrongly encourages the operation sequences development (bringing up the functional requirements specification) after placement of order for instruments (stand-alone ones or part of the turn-key package) which may not meet the said specification.
Piman allows the instruments to be ordered only after the functional requirements have been set and found to be consistent. It offers unique tool for the operation sequences development which is rooted in the following protocol.
Operation sequence is considered a chain of the action steps and response steps. An action step is an unordered collection of actions like ‘to open a valve’ or ‘to start a motor’. By analogy the response step is an unordered collection of responses such as ‘valve is open’ or ‘motor is running’. Inside the step the order of items – actions or responses - is irrelevant: swapping items produces the same result.
The step failure may be triggered by the action failure, the wrong action, the missed response or the wrong response. On the step failure two scenarios are possible:

1. the normal sequence is stopped and the failure sequence begins.
2. the safety interlock is activated and breaks the normal procedure.

Piman automates the control requirements specification through auto-generation of instrumentation index and IO point list, the list of equipment standard faults and actions (VFD over-temperature, the motor high torque, the valve seizure while it’s closing or opening, the actuator overload, etc...), quick navigation between P&ID items and the control documents, and design interfaces for interlocks, control loops, controllers and sequence matrices. Let me give some example. For SWRO project of 150,000 m3/day the IO point list includes approximately 4500 entries. To prepare drawings for PLC IO interface modules the control engineer requires 40 days. Such a drawing shows the wiring between instruments and motors and the remote IO card terminals. To do the same job Piman needs only 2 minutes. Below is the sample output.

• Piman PLC IO interface module scheme (MS .excel format, 29kB)

Piman simplifies HMI development. Piman austere drawing style helps solving another formidable task of the P&ID detailed design phase - HMI development. Current practice is to redraw P&ID drawings according to the subcontractor company internal graphic standards. As a rule they simplify the P&ID (on/off, drainage and root valves and tags being dropped off) and often introduce another set of symbols remotely resembling those used in P&ID. Not seldom such HMIs are developed by the PLC programmers having no sufficient skills in graphical design. Unsatisfactory quality of HMI eventually adds up to the operator errors. Another type of frequent error is splitting the equipment module between a number of the HMI screens. Piman module-bounded drawings already stripped off of all written words and numbers may be directly used for HMI. In fact its basic elements are already there.
Instrument hookups. Current practice is to put all information about the hookup items (tubing, elbows, connectors, and others) into the AutoCAD drawing. This information may refer to the assembly and manufacturing drawings, the manufacturer catalog datasheets and the project specification of instrumentation and shall be verified before submitting the hookup drawings to the subcontractor. By the author estimate, about 50% of all the 'as-made' hookup drawings (already used more than once) contain errors or misprints.
Piman not only auto-generates the hookup BOM (bill of materials) and the hookup specifications with all relevant information on demand, but also checks the applicability of the hookup drawing to the specific instrument, the fluid conditions and the materials.