Choosing between centralized and distributed control system designs

Engineers must strike the right balance on the centralized/distributed control system design spectrum.


In an extremely centralized design, a single process controller operates all aspects of the process. Courtesy: TriCore Inc.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.

Figure 1: In an extremely centralized design, a single process controller operates all aspects of the process. Courtesy: TriCore Inc.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.

Figure 2: This screen shot shows a typical receiving bay and tanker load-out bay. Courtesy: TriCore Inc.

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.

Figure 3: This screen shot shows raw skim storage silos with receiving and transfer routing valve clusters. Courtesy: TriCore Inc.

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.

<< First < Previous 1 2 Next > Last >>

Ravi Prakash , AE, India, 07/30/14 12:29 AM:

It is indeed refreshing to get into titbits of centralised and distributed control system after a long time.
Whatever said by author is true and my 30 years of experience in automation do confirm the same .
The bottomline is no system is fully centralised or fully distributed.
Anonymous , 07/30/14 02:25 AM:

I/O subsystem like I/O cards etc. has to be protected against rain, dust, other contaminant, humidity, high temperature, low temperature, or corrosive atmosphere etc. Therefore traditional I/O cards are usually kept indoor in local equipment room or field auxiliary room / satellite rack room etc. Personally I see a trend to towards using digitally networked sensors and actuators instead of traditional hardwired 4-20 mA and on-off signals. That is, a trend to eliminate I/O cards by networking field instrumented instead: bus or wireless.

I personally agree that using fieldbus for field instruments removes the need for individualized wire runs back to the I/O system for each signal of each device. This dramatically reduces the overall installation cost.

Keep in mind that 1 device is not 1 signal. Therefore a 16 channel I/O card cannot handle 16 devices. Simple devices like pressure and temperature transmitters have only 1 signal, but Valve positioner (limit switch feedback) has 3 signals, Valve positioner (position transmitter feedback) has 2 signals, Electric actuators (motor operated valve, MOV) has up to 16 signals, On-Off valve has 3 signals, Coriolis mass-flowmeter has 3 signals, Magnetic flowmeter has up to 4 signals, Gas chromatograph has up to 25 signals, pH analyzer has 2 signals, Guided wave radar level transmitter has 2 signals, and Process gas analyzer has 5 signals. That is, on average devices have 3 signals each – more if you want to use their full capability. That is, 16 devices require more like 48 I/O, or 16 I/O is 5-6 devices. This is where running digital networking all the way from the very first meter from the sensors/transmitters and positioner/actuator/valve becomes so powerful because you can run all these device signals over the same two wires. For instance, a bus with 10 field instruments with an average 3 signals each takes the place of 30 signals: 30 pairs of wires. This dramatically reduces the amount of device wiring, reduces I/O cards, eliminates marshalling, and reduces cabinet footprint.

Footprint is particularly reduced if the fieldbus power is built into the interface card:

For remote-I/O cards in field cabinets may depending on the ambient conditions have issues with rain, dust, other contaminant, humidity, high temperature, low temperature, or corrosive atmosphere etc. Therefore remote-I/O is rare in outdoor plants.

I agree that only “registered” network cable that meet the noise shielding requirements should be used, and only “registered” couplers (junction box terminals) that are encapsulated able to handle the humidity and dust like you say. These are readily available.

Use standard protocols like FOUNDATION fieldbus (FF), not proprietary protocols found in some electric actuators / motor operated valves (MOV) and tank gauging systems etc. FF protocol is now available in all kinds of devices so there is no need to use proprietary protocols.

I personally agree that devices continue to get smarter and that fieldbus installations are becoming more prevalent. We are seeing more diagnostics in fieldbus devices including diagnostics in on-off valves and continuous diagnostics in control valves as well as more diagnostics in temperature transmitters. We are seeing 8 input temperature transmitters taking the place of 8 regular temperature transmitters as well as their 8 pairs of wires, 8 safety barriers, and 8 input card channels and so on. These things would not be possible with 4-20 mA. We see fieldbus devices with more computational capability allowing remote seals to be eliminated and so on. It is pretty amazing what can be achieved when you run digital communication all the way from the sensors and actuators at the very first meter.
The Engineers' Choice Awards highlight some of the best new control, instrumentation and automation products as chosen by...
The System Integrator Giants program lists the top 100 system integrators among companies listed in CFE Media's Global System Integrator Database.
The Engineering Leaders Under 40 program identifies and gives recognition to young engineers who...
This eGuide illustrates solutions, applications and benefits of machine vision systems.
Learn how to increase device reliability in harsh environments and decrease unplanned system downtime.
This eGuide contains a series of articles and videos that considers theoretical and practical; immediate needs and a look into the future.
Robot advances in connectivity, collaboration, and programming; Advanced process control; Industrial wireless developments; Multiplatform system integration
Sensor-to-cloud interoperability; PID and digital control efficiency; Alarm management system design; Automotive industry advances
Make Big Data and Industrial Internet of Things work for you, 2017 Engineers' Choice Finalists, Avoid control design pitfalls, Managing IIoT processes
This article collection contains several articles on the Industrial Internet of Things (IIoT) and how it is transforming manufacturing.

Find and connect with the most suitable service provider for your unique application. Start searching the Global System Integrator Database Now!

Big Data and bigger solutions; Tablet technologies; SCADA developments
SCADA at the junction, Managing risk through maintenance, Moving at the speed of data
Flexible offshore fire protection; Big Data's impact on operations; Bridging the skills gap; Identifying security risks
click me