Integrating multiple control systems
Control system integration: Very few plants have one monolithic controller running everything. Instead, many have subsystems which need to be interconnected for maximum effectiveness.
When considering the control system running a process unit or an entire plant, it's easy to picture it as a single thing, one distributed control system (DCS), controlling everything. Although there is probably a DCS or large-scale programmable logic controller (PLC)/ programmable automation controller (PAC) controlling the process, there are additional control systems running smaller operations within the facility, process units, and auxiliary systems.
This kind of approach has been in use for a long time. After all, the "D" in DCS stands for distributed, which suggests control functions spread out with a high degree of autonomy but tied back to one, central place. In fact, there can be quite a few autonomous control functions, depending on the nature and overall complexity of the process itself. For example, here are a few processes and systems, each which might be monitored by the DCS but have independent control mechanisms:
- Hot water
- Chilled water
- Fired heaters
- Power distribution
- Fire and gas detection systems
- Skidded equipment (chemical injection, incinerators, etc.)
- Water supplies (soft, filtered, reverse osmosis, water for injection)
- Clean-in-place systems
- Compressed air
- Emergency power.
Theoretically, one DCS could control any of these, and it is possible to control every aspect of a plant from a central point. However, in most plants it isn't practical and would cause unnecessary complexity. Safety instrumented systems (SISs) would be the first thing off the list because they function independently. Similar functional considerations also influence other decisions.
Some decisions of when to break free of the DCS are based on functionality. A DCS is, at its heart, an analog system. It is designed to support control loops driven by sensors with scalar, analog output, and control scalar, analog actuated devices. It can work with discrete devices and functions, but they are not its best application. For the purposes of this discussion, discrete means a device with simple on/off functionality such as a motor starter, pressure switch, or quarter-turn valve.
Process units have many discrete control functions. Pumps have to be turned on and off, alarms may need to be activated, and so on. A DCS could handle those, but when there are many related things which must work together, it's best to split them off and control them with one or more PLCs or other controllers more suited for those operations. It may also be cheaper because DCS platforms are often priced based on the number of tags. Increasing the number of discrete tags can add to the cost without any meaningful benefit. The input/output (I/O) also tends to be more expensive in a DCS compared to a PLC. Supplementary PLCs can communicate with the DCS while controlling these local functions.
Operators in the control room will need to know what the secondary systems are doing, so the function will be incorporated into the normal control graphics, but the DCS will only be passing information and commands without performing any real-time control itself.
Safety and regulatory choices
As mentioned earlier, safety functions and systems are separated from the DCS. These fall under various regulations, but the common denominator is the need for independent functionality. If a system needs to shut down some part of the unit and move to a safe state, for example when pressure in a reactor exceeds a set limit, it must be able to execute the function regardless of what the DCS is doing and without human intervention.
In some cases, a safety function may depend on something as basic as a pressure switch sending a signal to a logic solver controlling a relief valve. The logic solver can open the valve without any assistance from the DCS or operator. It will probably send a signal to the DCS saying it has done its task and triggering an alarm, but the communication is strictly one way.
As a more complex example, a paper mill has a recovery boiler system to support the paper making process and supply steam to turbines used to generate electricity, sending the exhaust to heat paper drying rollers. The boiler has two main functional systems: combustion control to determine how much steam it's putting out, plus a burner management system (BMS) to ensure it is running properly with a stable flame and no residual unburned fuel. In this case, the primary fuel is black liquor supported by fuel oil or gas. Since steam output is a process variable based on the needs of the paper machine and the amount of power the generators are producing, it is controlled by the DCS. It tells the boiler how much steam to put out, and it does it by controlling fuel flow (black liquor) and combustion air for the necessary amount of fired heat, along with feedwater to keep up with steam output.
The BMS, on the other hand, is a more discrete function. It turns the fuel on and off. If there is a problem, it shuts down. It needs to be able to execute such a shutdown even if the DCS is calling for steam. The BMS is governed by a variety of safety regulations, including National Fire Protection Association (NFPA) regulations, which define how it has to function. The operators in the control room may not realize it, but they are working with both systems. They tell the combustion control how much steam they need. It says how much heat it is putting out, and there are two instruments (pressure and flow) on the steam output line to indicate steam production. The BMS will verify the boiler is on and has a stable flame, but that's it. The operators can probably shut the boiler down via the DCS, but they cannot interfere with the BMS safety functions.
Communication method fit for purpose
All of the subsystems have to be tied together so operators can monitor and control all the elements from one place. Even if a chemical injection skid is fully capable of working on its own, operators will want to be able to turn it on and off and know what its settings are without having to hike out to wherever it is. Nothing exists in total isolation.
The nature of the inter-system connections depends on the functionality and speed (see Figure 1). If there is a strong safety element, the subsystem will probably be hard-wired, I/O to I/O. Something less critical can communicate via Modbus or some other serial network, or increasingly, via an Ethernet protocol. Direct serial links are being replaced by more conventional Ethernet networking strategies as IT practices move onto the plant floor.
Larger networks are particularly useful where a subsystem has to connect to multiple DCS platforms, such as where a plant utility might have to serve more than one process unit. The subsystem has to be sophisticated enough to balance those demands and adjust itself accordingly. A steam boiler serving two or three continuous process units may find its output fairly constant, whereas multiple batch processes operating simultaneously could call for drastically different volumes as they move through production phases.