Control Systems: Centralised vs. Distributed

12 Jun , 2019  

It is a question every designer of industrial machinery must face. Should control of the equipment’s various moving parts be centralised in an all-powerful PLC, or should it be distributed across the parts, in individual drives located close to the motors?

In order to answer the question, a variety of factors needs to be taken into consideration. In some cases, a centralised control architecture will recommend itself; in others, decentralised will be preferable. On the whole, though, and thanks to recent advances in the power of servo drive technology, there is an observable trend towards models of distributed control.

Fifty years ago or so, when it was first developed, centralised control was a revolutionary concept. Back in the early days of hardwired industrial machines, engineers needing to modify or troubleshoot operations would have to pick their way through switchboards and relay walls massed with cables and wires, one for every function. These would become both more untidy and less reliable with every intervention.

The birth of the Programmable logic controller (PLC)

The rise of computing power relegated these rats’ nests to history. With the birth of the PLC came the ability to control complex machinery digitally, from one vantage point, managing huge arrays of inputs and outputs in real time. And, by and large, PLCs have stood the test of time: they are fast, versatile, custom coded for precise suitability, and straightforward to troubleshoot.

Putting a controller together with drives and a power supply in a single, central location is these days standard practice – and still the preferred arrangement for complex systems with highly intertwined operations where the motors are reasonably close together.

The following drawbacks, however, should be noted: significant amounts of cabling (both for power and for feedback) may still be required to link the drives to the motors; a cabinet – potentially bulky – is necessary to house the control components; the cabinet needs effective air conditioning because of the concentration of generated heat; and, again because of the concentration, electromagnetic compatibility behaviour may be erratic.

Decentralised control, where it is feasible, eliminates or minimises these problems. The reduced amount of wiring required by distributed drive architecture is especially striking: in the case of a machine with, say, eight axes and motors anything between one and five metres apart from each other, connecting up a central control cabinet might require well over 200 metres of cable; relocating the drives from the cabinet to the motors themselves could cut total cabling to under 50 metres.


Less wiring means less that can go wrong: fewer connection points; fewer vulnerabilities; less electrical interference; less heat; less maintenance. Speed can be an issue too. The faster response time achieved by having a dedicated controller close to the motor and its axis, even if it is only fractional, may be important. And a single central controller running a lengthy program can be problematically slow for some processes.

The benefits of a decentralised control system

There are, of course, limits to how far control can, or should, be decentralised. It is not always safe, practical or indeed necessary to spread controllers around a system, particularly where there is limited mounting space within the machine or in locations where added heat generation might present a problem. Furthermore, where sets of processes always work tightly together, distributing control across them can create needless complexity. Generally speaking, the more physically dispersed process equipment is, and the more operationally independent of each other the processes are, the more sense it makes to distribute control.

A well-designed distributed control system should be relatively easy to maintain and update. Adding a new process to a centralised set-up, for example, usually requires system-wide downtime while the program is modified and the result tested to iron out unwanted effects on the whole. If a new process comes with its own controller, on the other hand, much of the functionality can be tested and established prior to connection, with downtime – and risk to the complete system – accordingly minimised.

Of course, the simplicity of this experience can be lost if engineers are having to cope with too many different kinds of devices from different manufacturers. In practice, multiplying problems such as spare part availability and specialist software knowledge could all too easily annul the efficiency gains intended by a decentralised architecture. Where possible, therefore, standardisation of materials should be no less important to these designs than it naturally is to a centralised system.

In fact, the current generation of smart drives offers strong possibilities in this area. Flexible drives, capable of performing both centralised and decentralised operations, have the potential to simplify a manufacturer’s stocking and programming requirements significantly; as well, of course, as expediting the design and commissioning process.

Freedom of design for the engineer is perhaps the greatest dividend offered by distributed control technology. Modularisation, in particular, becomes available as the natural mode of coordinating and extending machine processes when overall control ceases to be tethered to a central monolith. And the adaptability of modular design is increasingly called for by the demands of an ever more diverse and changeable marketplace.

Indeed the concepts of distribution and modularity have in recent times emerged as prominent themes in various industrial contexts: from distributed manufacturing to modular construction, and from modular software programming to distributed ledger technology. In all of these fields, designers are finding that systems are more scalable, more stable and more resilient when not built entirely around a single focal point. Such is the thinking, too, behind distributed system control.

, , ,

Leave a Reply

Your e-mail address will not be published. Required fields are marked *

Alex Byles

Alex Byles