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.
By Tim Gellner July 6, 2016

Figure 1: An architecture diagram shows connection options, input/output (I/O) to I/O versus networks. Some system-to-system connections need to be hard-wired to support the fastest possible data exchange while more conventional networking provides greateWhen 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
  • Steam
  • Fired heaters
  • Power distribution
  • Analyzers
  • Fire and gas detection systems
  • Skidded equipment (chemical injection, incinerators, etc.)
  • Communications
  • Water supplies (soft, filtered, reverse osmosis, water for injection)
  • Clean-in-place systems
  • HVAC
  • Wastewater
  • Compressed air
  • Refrigeration
  • Environmental
  • 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. 

Functionality

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. 

Figure 2: An architecture diagram shows how connectivity to subsystems can create vulnerabilities. The same cybersecurity defense strategies appropriate for conventional networks also should be used in this context. In this example, a technician added anCybersecurity

As networks grow in size and complexity, the attack surface for intrusions by criminals also grows. Adding a pump skid with its own small control system does not have to create another entry point, but it certainly can do so, often with good reason (see Figure 2). Say the pump skid builder realizes it may be necessary to access the skid at some future point to gather diagnostic information or troubleshoot a problem. The engineer adds a cellular modem or a Wi-Fi router to the control cabinet so the technician can access the device. This connectivity was not specified by the customer—the builder did it for its own convenience. If a hacker can access this device, it can serve as an entry to the larger system. The customer needs to be very specific as to what communication capabilities are permissible and which are definitely not.

When multiple systems are connected by a network, appropriate isolation and segmentation should be observed. For example, say someone within the company decides it is important to monitor the performance of a skidded subsystem for whatever reason. The individual might ask for access to the desired data via the DCS. If such an approach is too slow or might not be fulfilled at all, another tactic might involve extending the enterprise network directly to the skid. The connection can be established, but if not protected adequately, it becomes another possible vulnerability.

Vulnerabilities arising from these kinds of situations are becoming increasingly rare as users gain a greater understanding of cybersecurity and safe networking methods. Communication channels added as quickie solutions to solve some immediate problems are no longer permitted, and many companies have banned them. The kind of network inventory performed as a cybersecurity assessment project should unearth these lurking dangers, hopefully before an unwanted intruder does. 

Remote access

The growth in remote access has extended the reach of all sorts of control systems. In most cases, the main DCSs are what remote users are interested in; however the subsystems may also be of interest. There may be individuals concerned about energy consumption wanting to see what that multiple-unit steam boiler is doing because it is the largest energy user in a facility.

These systems don’t normally extend the control platforms since they are not adding new control functionality and are generally for monitoring only. Some platforms provide the ability for remote control capabilities inside the plant and out. Walk-around HMIs using a tablet are useful for in-plant use to help operators with troubleshooting or enabling them to watch something happen from outside the control room, but so far there seems to be little interest in long-distance control options. Such capabilities carry interesting and, frankly, unsettling possibilities. The idea of operators in the control room watching setpoints change, moved by some unseen individual in a different area, can certainly raise issues.

As control strategies continue to evolve, the practice of separating small functional areas from a larger overarching system to create truly distributed control systems will continue. As networking gets easier, so do the mechanics of connecting these distributed systems in a far more modular fashion. This coincides with higher intelligence at the device level, permitting more components to think and act for themselves without the need for a large central processor to carry out calculations. Centralized control systems will continue to be used to gather data and serve as a mechanism to display and set process variables, but less real-time control will be happening within the central processor.

This integration effort uses a variety of communication protocols depending on the specific situation and type of communication. Courtesy: Maverick TechnologiesA typical multi-system integration strategy

Maverick Technologies is currently designing an installation at a petrochemical plant to bring its fire and gas detection systems into the DCS. This project is particularly interesting because it works with many different types of systems with varying degrees of regulated functionality.

Since fire and gas detection systems have safety functions and are regulated by NFPA, their operation has to be fully independent. However, concern about operator situational awareness has driven the company to gather information from those systems in the central control room on one screen. If there is a fire in the plant, this screen will indicate its location immediately without interfering with the other HMI screens. All the fire panels deployed under NFPA 70: National Electrical Code and NFPA 72: National Fire Alarm and Signaling Code will send data to the DCS via Modbus for display on the new screen.

The new system will also gather information from lower-level safety functions such as emergency showers, eyewash stations, fire pulls, and even a weather station. Operators will now be able to know immediately if there is escaping gas or a fire, or if someone has used an eyewash station anywhere in the facility. 

Tim Gellner is a senior consultant for Maverick Technologies, a CFE Media content partner. Edited by Emily Guenther, associate content manager, CFE Media, Control Engineering, eguenther@cfemedia.com.

MORE ADVICE

Key Concepts

  • Learn when to integrate multiple control systems.
  • Safety functions and systems work independently from the DCS.
  • Smaller functions may work independently from a centralized control system. 

Consider this

When multiple control systems are used, what does this mean for energy efficiency?

ONLINE extra

See related stories linked below.

Want this article on your website? Click here to sign up for a free account in ContentStream® and make that happen.