FUNCTIONAL DESIGN

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 control design and specification. Being aware of this critical situation in the process control, 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.
This standard has not been accepted by industry presumably due to ambiguous terminology and vague definitions (concerning plant partitioning into blocks), lack of practical guidelines for handling emergency situation, and offering database design not rooted into modern data structure theory and modeling.

CP resolved this situation by introducing its own framework for setting, processing, validation and reporting the project functional requirements - primary context in which all other flavors of engineering data shall be handled to attain robust control, requested operation flexibility and reliability of the plant.
This framework expands each PFD node (declaration) into Equipment Module (implementation) - a combination of P&ID items providing requested functionality. It is described by such simple verbs as "to filter", "to pump", "to clean", "to mix", etc.   Besides process functionality, any Equipment Module (EM) shall implement the CP standard set of logic states and actions (Table 3). They shall be defined for all EM modes of operation (like duty, standby, online test, backwash, etc.). This approach makes All EM entities identical in externally-visible behavior from the control logic perspective. It may be said that EMs are bricks of the CP plant control design.
Table 3: EM/PFD node states and actions

States Pseudo states Actions
1. Fault
2. Not Ready
3. Ready
4. Running
5. Not healthy
1. Starting
2. Stopping
 
1. To run
2. To stop
Fig.2 Equipment module allowable states, actions and transitions

EM/PFD node is filtering/pumping/mixing/etc. only in Running state. The Running, Ready, and Not Ready states are reversible (Fig. 2). Finite-time transitions between them are controllable and triggered by Actions. The Fault state is abnormal and risk-associated one. Any transition to it is unidirectional and irreversible. The Not Ready state means that EM is not available for requested task but it may be in higher level state (Ready or Running) for other modes of operation. For example, the dual-media filter has 3 main modes: Duty, Backwash and Air scouring. It is simultaneously in Running state for backwash and Not Ready state for main filtering process.
CP differentiates between EM useful functionality (to pump, to filter, etc.) and EM externally visible behavior. The former traditionally lies in the process domain, the latter in the control domain and a compound result of the P&ID Wired Items (WI) behavior.
By CP, WI is the P&ID item that may be remotely communicated (through some input/output data streams). Examples are limit and proximity switches, instruments, actuated valves and electrical drives. Any WI has its own set of logic events and states - part of the purchase order scope. 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.
Equipment Group (EG) is a group of identical EMs mostly connected in parallel. The main reason of introducing EG is that EM alone may not meet the process requirements such as dependability and performance flexibility. For example, to pump seawater with dependability of 100% and a flow ranging from 25% to 100% at least 3 intake vertical pumps (and 3 EMs respectively) are needed as usually for the turbine type pumps the allowable minimum flow rate is around 50%.
The above-mentioned intake station EG with 100% dependability for 100% capacity has no externally visible Fault and Not Ready states. This EG is defined by CP as No-Fault EG. The plant may be considered highly reliable if it is composed of No-Fault EG groups only. Running state turns into AutoRun when EG becomes a member of a control loop. For example, the intake pump capacity may be controlled by setting the rotation speed via variable speed drive (VSD).
If the intake station EG is equipped with only 2 pumps it has 100% dependability for 50% capacity, and behavior of this group is different – the Fault status for the pump EM triggers resetting the production rates for the whole plant. In other words, this 50% dependable EG turns into the plant controller and it is called Controller EG. In such a situation to avoid the plant shutdown all EGs and EMs downstream shall have turndown ratio not less than 50%. At the plant load of 50% Controller EG is identical to No-Fault EG.
WI and EM (represented by No-Fault EG and Controller EG) are first two layers of the CP model of the plant control hierarchy. EM entities are further consolidated into Operation Modules (OM). By CP definition, each upstream OM may run independently of the successive (downstream) OM. Chained OMs form a path for Fault state propagation (upstream) and Ready and Running state propagation (downstream).

Fig.3 Intake & pretreatment OM groups

OM entities are created by adding the process fluid overflow points to P&ID and PL (Plant Layout) mentioned previously. Let’s consider intake pumps (EG1) connected to flocculators (EG2) installed before dual-media filters (EG3) (Fig.3). To create OM out of EG1 and EG2 groups, the feed overflow has to be arranged before the feed distribution to EG3. The overflow point allows the intake pumps (and OM accordingly) operate independently of the filters status. Plant partitioning into OMs substantially decreases the revenue losses due to the emergency outages.

CP auto-generates Control Flow Diagram (CFD) by overlaying each PFD node with respective Controller EG or No-Fault EG data and adding OM boundaries. CFD gives an instant picture of the plant reliability design goodness, and identifies the weakest points.
The plant safety and reliability substantially depend on how the plant control system reacts to the EM Fault state, in other words, on how safety interlocks are implemented. They describe the plant/system/subsystem response to predetermined conditions caused by EM malfunctioning. By ANSI/ISA-5.06.01-2007, the interlock is a single cause-and-effect link between initiating and control devices. This trivial approach to the interlock definition is not applicable to the multi-layered control hierarchy - current standard for the big water treatment and desalination plants. To illustrate this point, let’s consider an operation of two pumps connected in series to feed the SWRO membrane array with seawater at 70 Barg. It is obvious that any fault of the booster pump shall first trigger “soft” stop of the second much larger pump to avoid mechanical damage of membranes and piping. In reality, this simple requirement is not always followed.
Besides trivial interlock type, CP offers interface for creating higher level ones - faults and actions may use Boolean math or custom functions, be single, sequential or compound and be rooted into WI, EM, or OM. Higher level interlocks may first implement soft shutdown of OM groups downstream of the faulty OM, or may trigger some corrective action followed by a time delay needed for trouble-shooting to take place.

Pseudo-states Starting and Stopping are actually sequences of actions. Current practice adopted in many companies for the start/stop sequences mostly deals with the normal course of events and leaves many ldquo;what if” questions unanswered (due to severe impact of this time-consuming work on the project schedule and budget). To shorten the engineering phase, this practice wrongly encourages the operation sequences development after P&ID approval for detail design (that follows engineering) and placement of order for instruments.

CP offers unique interface for start/stop sequences rapid development, 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. (In most cases it mirrors the normal one)
  2. The safety interlock is activated and breaks the normal procedure.

The failure sequence may be started by the failed action or the missed response. The wrong action or response is handled by the safety interlock. The wrong action interlock prevents jumping over the response step to the next action step. If all expected normal responses are registered, all the actions of the next action step are moved from the “locked” to “unlocked” status.

The afore-mentioned protocal builds the bridge to automation of SCADA development. At present, it is affected by the following problems, which eventually add up to the plant operator errors.

  1. HMI “screens” are usually developed by the PLC programmers having no sufficient skills in graphical design, and the low quality graphics dominates in the screen design.
  2. HMI screens introduce graphical symbols remotely resembling those used in P&ID.
  3. Splitting the EM group between a number of the HMI screens make navigation more difficult.
  4. Abridged start/stop sequences increase the risk of the operator wrong decision.

CP introduces the user interface for the selection and storage of the control loop PID controller settings. In practice they are stored in SCADA files not accessible for re-use by the project team.
Functional design shall define the scope of the data acquisition (as part of HMI & SCADA package). It should be sufficient to make the plant operation safe, controllable, reliable, and efficient (in terms of meeting the guaranteed values). Despite the criticality of the data acquisition, its requirements and scope are rarely set in the desalination tenders. (For example, the feed pumps of above 2 MW may require not only constant monitoring but trend analysis as well as it is a very expensive and critical piece of equipment. Both tasks may be implemented, for instance, with GE Bently Nevada 3500 monitoring system, which is not yet discovered by the desalination consultants.) As a result, the data acquisition is traditionally implemented after the detail design completion by the control engineer having different (from the process engineer) view of the plant design priorities. Low redundancy, low accuracy of the energy input metering, missed guaranteed HMI inputs (like filtration rates in the multi-media filters, the fluxes in the reverse osmosis membranes, and fluid velocities in the piping, etc.) are in abundance in the desalination plants.
CP makes the data acquisition design inseparable from the P&ID item specification. The process engineer shall define which input to obtain, scan rate, relationships between the guaranteed figures and the installed instrumentation, which data to store in the database and which to email to the stakeholders.
To build the control auditing mechanism, CP sets standard communication protocol. It defines the contents of the data streaming downward (from Plant to WI) and the data streaming upward (in reverse direction) between layers of Control Hierarchy (WI, EM, OM, and Plant). As minimum downstream data should include Service Request and Production Set Point, and upstream data – the Predecessor State.