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.