Choosing between centralized and distributed control system designs
Engineers must strike the right balance on the centralized/distributed control system design spectrum.
How much to centralize or distribute a system is an issue that control engineers have grappled with since the birth of automation systems. Getting the answer right can be a lot more complicated than you think, and can challenge even the most experienced engineer. This article presents engineering best practices for designing your systems and dealing with issues you may encounter along the way.
The central question
How much to centralize or distribute really has two aspects to sort out: the control itself and the I/O subsystems. When establishing your design, start with the overall control system and then work down to the I/O. Before discussing the particulars, let's start with some basics.
Centralized or distributed control is a core design aspect of your system, which defines on a very basic level the degree to which your controlled objects and operations are intertwined with the control system itself. This degree of comingling is reflected in all the physical and logical components of your system. It should not be confused with the selection of a control system platform. These design criteria should drive that selection, not the other way around.
In an extremely centralized design, all of the aspects of your system are concentrated in a single entity. A single process controller operates all aspects of your process (see Figure 1). A highly distributed design is just the opposite. The physical and logical components of your system are spread across a variety of operational and physical areas.
With this basic working definition of centralized and distributed control, we can examine the same concept as it applies to I/O systems. A highly centralized I/O system is characterized by concentrated I/O hardware in a single entity, with network or hardwired connections extending from that location. A highly distributed I/O system has the I/O hardware distributed across many operational and physical areas, with localized network or hardwired connections extending from these remote locations.
It is important to note that as with control, centralized or distributed I/O is a design concept independent of the I/O platform type. You can have something intrinsically distributed, such as a group of point I/O devices, connected back to a common I/O adapter or network switch. In this event, the common connection creates some centralized characteristics in an otherwise distributed system. Similar examples abound for centralized I/O systems with some distributed aspects.
When examined closely, most systems of any substance are generally not completely centralized or distributed in terms of either control or I/O. While the control design imposes some limits on the degree in which you can centralize or distribute I/O systems, these limits could be narrow or quite wide. As system designers, we need to strike the right balance on this spectrum. Let's examine some of the factors that can affect how we put this all together.
Let your process do the talking
The first step in your design process starts with an examination of the process equipment you are controlling. You must consider both the operational aspects of the equipment and the physical location of the controlled objects and sensors.
From an operational standpoint, equipment groups that operate reasonably independently from other processes are good candidates for distributed control. Equipment or processes with highly intertwined operations are generally good candidates for centralized control. In either case the I/O subsystem can be centralized or distributed to varying degrees, based on the physical layout of the equipment in your system.
When designing your system, you should centralize or distribute control and I/O only to the degree that your process equipment allows. Forcing a scheme where it does not belong can create added layers of complication and risk to your system.
Let's examine a candidate for centralized control with a simplified process example. You might have a liquid ingredient receiving area that delivers raw material through a valve cluster to a storage area. There are three main process areas your system must control: the receiving area (see Figure 2, the valve matrix, and the storage area (see Figure 3). You need all three areas to perform any one receiving/storage unit operation. You could distribute control to each of these areas, or centralize it across all three. A distributed system has three points of failure, as a failure of any of the three controllers would cause a fault across the entire system. By comparison, a centralized system has only a single point of failure.
Each area in the distributed system would need to exchange status data with the others to ensure safe operations. This requires connecting media between the systems and associated hardware. This increases the complexity of the system and introduces additional points of failure compared to a centralized system.
A candidate for distributed control might be found further downstream. You could find three product processing lines, each completely independent from the others. In a centralized system, a controller failure will fault all three processing lines, as the controls for each are intertwined. In a distributed system, a failure in one controller will leave the other two lines unaffected. Unlike the receiving/storage example where equipment operations are tightly coupled, operationally independent areas can benefit from distributed control.
In the aforementioned examples, each of the areas could be physically close or in different sections of the facility. Regardless of centralized or distributed control, it usually makes sense to distribute I/O according to the degree that the process equipment is physically separated.
The installation factor
In addition to the equipment itself, your site installation plan for this equipment can influence the control system requirements. If the equipment is installed all at once, this will be the simplest situation to deal with. The process equipment in its final operational state is all you need to concern yourself with when developing your control system design. If installation is done in phases, things get a bit more complicated. You will need to sort out the requirements during each phase, and between each phase.
For the I/O systems, the physical location of the process equipment is no longer the sole determining factor in how much to centralize or distribute the I/O. You must also consider how the equipment is phased into operation. Even if equipment is being installed in a common physical area, if it is installed over time in multiple phases, it may make sense to distribute the I/O per phase. This decision will be driven in part by how much the equipment in the new phase can affect the operation of equipment in a previous phase. Distributing the I/O will be the least disruptive to existing equipment.
From a control standpoint, it all comes down to the operational expectations. Let's return to our receiving and storage example. Phasing the installation of each of the three process areas would not impose any additional need to distribute control. All three areas are required to do a single unit operation. Electrical and mechanical testing of each area could be done per phase, but operational testing would have to wait until the installation of all three areas was complete.
It gets more interesting when you install an inherently centralized process in phases, and expect it to run in some temporary manner as you do so. To illustrate this, assume the receiving and storage areas are installed in an initial phase with a temporary mechanical transfer plate in place of the valve matrix. The valve matrix will be installed later, but you need to run at the end of the first phase.
The receiving area and storage area are tightly coupled; both are needed for any single unit operation. They remain good candidates for a centralized control system. After it is installed, the valve matrix could either be incorporated into the centralized control system or distributed with its own controls. The centralized system will have less failure points and a simpler structure after it is up and running, but a distributed design could potentially be installed much more quickly. If your downtime installation window is very tight, it might be a trade-off worth considering.
In the centralized approach, you must write or modify the control system software for each unit operation to properly operate the valve matrix. After the valve matrix is installed, each unit operation must be thoroughly retested to ensure safe operation of both the existing and the new equipment.
In a distributed design, much of this testing could be done in advance. The valve matrix could be assembled, programmed, and tested at the supplier's factory, operating on predefined routing messages easily emulated at the factory. Likewise, the corresponding routing message signals in the running plant system could be tested in normal operation without risk to production. This approach can significantly reduce overall installation time in such circumstances, and should be considered if your installation window is tight.
A final consideration is how your equipment might change over time. In the production line example, the system might initially be installed with a single line. Additional lines might be considered later if business can justify it, but there are no plans for certain. While you could centralize control of the entire system at a lower upfront cost, it might make more sense to distribute control of the processing line if the premium is not too high. Tightly coupling the control upfront could present more challenges and costs if you add more lines in the future. Understanding these issues can help you determine the best design for the entire lifecycle of the equipment.