Centralized vs. Decentralized System Architecture

A post by our colleague Robert Persch, Development “Systems Software”

Biased by the World Wide Web and common Ethernet structures there is a tendency to promote a completely decentralized architecture for IP-based industrial communication systems.

The term “decentralized“ can refer to the location of the individual communication devices in the network, but usually it is more about the functional organization or in other words the way these devices interact when a function is executed.

As long as only basic functions have to be considered, e.g. push-to-talk communication between two subscribers or broadcasting of simple announcements, the corresponding terminal devices can easily manage the communication without the need of a coordinating central control unit.

More complex functions which require the management of several stations mostly need a central unit. Examples are the management of speech direction in half-duplex conferences or the provision of conference channels in full-duplex conferences.

Or consider the following example: On large company sites, there is often an intercom station installed at each gateway for the registration of visitors. Calls from these intercom stations are accepted by the operators of a control room. For this purpose, the control room can have several operator stations and calls are indicated at all intercom stations at the same time. If a call is accepted, the indication at the other intercom stations is cleared or the next incoming call is indicated. To now prevent that calls are simultaneously accepted at two operator stations, you actually need a centralized control unit which decides on the final assignment of the calls and redirects them to the corresponding intercom stations.

In a decentralized system it is difficult to compensate the lack of a control unit. Here, the call is indicated at both intercom stations and in the worst case also accepted by both operators. So how can this conflict be resolved? The system should select one station which manages the call and should ensure that the call is terminated at all other operator intercom stations except from one. But does that really work in a completely decentralized system? If there are other incoming calls waiting, things can get even more complicated. Hence control errors are very likely. Just like in real life: For coordination tasks you require someone who takes the lead.

The need of central control units is even more obvious if you want to use the system for broadcasting of warnings and alarms. Here, there must be at least one central logical entity for the control of each warning or alarm sequence. If there is an interface to a fire & gas system, you will also require a central point to operate the interface.

The list of system functions which require centralized control can be easily extended. Just think of:

  • System failure reporting
  • Maintenance tasks including the upload of a new configuration file
  • Interfacing of external systems such as telephone or control room systems.

Conclusion: For many functions, which are state-of the art in industrial communication, so called “decentralized” systems need one or more logical central entities. If a system does not have any central control unit at all, this means that the functional range and the reliability of the system are quite limited. It is a matter of fact that complex functions cannot be implemented reliably in a completely decentralized system.

2 thoughts to “Centralized vs. Decentralized System Architecture

  • Mukesh Shah

    Interesting to know and very logical that there has to be a leader in any organization who will lead the rest of the team. Similar analogy is just perfect for the industrial control system too.
    However would this also mean that there are some systems on the market claiming to be perfectly decentralized – with distributed intelligence if studied closely has positively some centralized architecture hidden or the system is not a reliable one?

    • Simone Musch

      Dear Mukesh,

      Thanks for your comment.

      There are indeed competitors on the market which strongly promote the completely decentralized structure of their systems. The question is how these systems ensure that all of their components are always on the same information level and come to the same decisions. The problem lies with the “internal” states or in other words the type of information the system must remember. The example stated in the blog article describes this problem with reference to the list of incoming calls at the gate intercom stations and the subsequent assignment to the individual intercom stations in the control room.

      In completely decentralized systems this information is literally somewhere “up in the cloud”, as there is no explanation what kind of mechanism ensures the consistency of the whole system. If I were a customer, I wouldn’t be very satisfied with such a weak and general statement. I would ask for more details.

      I hope this helps to better understand the idea behind my article.

      Best regards,



Leave a comment

Your email address will not be published. Required fields are marked *