Choosing between centralized and distributed control system designs
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.
The power of the purse
There are upfront and long-term costs to consider with either a centralized or distributed design. From a control perspective, there are hardware costs of the controllers and the start-up costs of the control system. From an I/O perspective, there are hardware costs of the I/O platform and the installation costs to physically connect this hardware to the field devices. For both control network and fieldbus network installations, there may be additional third-party network certification costs.
Centralized control systems tend to have lower control hardware costs compared to distributed systems. This is simply due to fewer controllers in centralized systems. Centralized control system start-up costs are more complicated to determine. As noted in the previous example, installation phasing and operational expectations can impact these costs. It is import to determine upfront to what extent this might be the case, as it can have a big impact on the total lifecycle cost of your system.
From an I/O standpoint, centralized systems tend to achieve economy of scale on hardware components. To illustrate this, consider the I/O modules in a traditional hardwired I/O system. Assume a module controls 16 devices, and you have 200 devices to control. In a centralized system, you would need 13 I/O modules. If the same 200 points are distributed evenly across 10 process areas, you would need 20 I/O modules to meet the same requirement. The same principle applies in varying degrees to all the physical hardware in your I/O system. The more remote I/O areas in your system, the more I/O hardware you will tend to need for that system.
Counterbalancing this are labor and material installation costs. The more physically spread out the controlled equipment and sensors are from the I/O hardware, the higher these installation costs will be. Centralized I/O systems magnify these costs; distributed I/O systems mitigate them.
Your selection of I/O platform could have a large influence on the installation costs. Traditional hardwired I/O platforms require a separate wiring run between each field device and some I/O module. Network platforms may allow you to wire from device to device without the need for individualized runs back to the I/O system. You will tend to pay more for I/O hardware and cabling media, but your overall installation costs could be significantly lower.
On the fieldbus side, recent trends have been away from some of the open platforms, such as ControlNet, an open industrial network protocol for industrial automation applications. In that case, trending has been toward industrial Ethernet solutions. Alternatively, the AS-Interface is growing in acceptance and installations, and plays nicely as a partner network with higher level fieldbus platforms including those using industrial Ethernet.
There are a few things to consider from a systems integration standpoint-physical and functional. The controllers in your system will often have to communicate with other process, visualization, and business systems. If your budget permits, a common broadband industrial network platform between these items will simplify configuration and maintenance over the life of your system, and allow for the most efficient communications between all systems.
The control, I/O, and components of your system will likely use some network features to a greater or lesser degree. Your network will only be as good as your cabling, connection, and switches. Industrial networks are often electrically noisy places. They are subject to electromagnetic interference, temperature ranges, dust, and humidity not found in office environments. Make sure you have the right cable for the job, with all of your network hardware properly installed and configured.
Older legacy systems usually contain low-speed and/or proprietary networks. If your control system is composed of these elements or must integrate with such a system, there is more to consider. Because of the slower speed of the network and communication protocols in this environment, special handling must be placed on how information is exchanged with other systems.
If there is process-critical real-time status that needs to be exchanged with other process systems, old-school hardwired signal exchange might still be appropriate under such circumstances. For other data, specialty network adapters can be found that convert between these proprietary platforms and more modern network protocols.
If there is a large amount of data to exchange with a host system, concentrating the data in a single location might be an option to consider. This will often yield the most efficient communication method under such circumstances. The trade-off is communication performance versus a single point failure. In a centralized system, it is relatively easy to concentrate the data. In a distributed system, you will need to select a controller to host and manually message the data from the other controllers in the system.
From our past, toward our future
The question of how much to centralize or distribute a control system has been around for a long time. It pertains to both the control and I/O aspects of the system. While certain hardware platforms may lean toward one direction or the other, it is a design concept independent of these platforms. Systems of any substance are rarely completely centralized or distributed. The best solution on this spectrum is driven by a variety of factors.
The normal operation of your equipment has a large influence on the degree to which you should centralize or distribute your system. You have to examine both the operational aspects and the physical layout of your equipment. How this equipment is installed over time, and how likely it is to change are also factors to consider.
Centralized systems tend to have lower hardware costs than distributed solutions, but often have higher installation costs. The opposite is true for distributed solutions. When putting it all together, remember to consider the system integration issues between your system and others.
This question will continue to be with us in the foreseeable future. As devices continue to get smarter, fieldbus and industrial network installations become more prevalent, and control platforms continue to evolve, the question of how to group or distribute these items remains. Understanding the core principles involved will help you develop the right design for your control system-now and in the future.
David McCarthy is president and CEO of TriCore Inc., a national systems integration firm based in Racine, Wis., with offices in Glendale, Calif., and Mesa, Ariz. Before he founded TriCore in 1991, McCarthy served in various capacities at Alfa Laval/Tetra Pak, including manager of engineering for its U.S.-based food engineering company. McCarthy, who has more than 30 years of experience in automation, is a computer scientist from Rochester Institute of Technology.