Centralized vs. distributed control

Assembly lines are familiar entities characterized by a modular structure. The structure consists of modules for the different manufacturing stages, such as pick-and-place units, robots, welding stations and, of course, a logistics unit that transports individual parts between modules and controls the supply of assembly parts.

By Josef Papenfort July 1, 2005

Related reading

Assembly lines are familiar entities characterized by a modular structure. The structure consists of modules for the different manufacturing stages, such as pick-and-place units, robots, welding stations and, of course, a logistics unit that transports individual parts between modules and controls the supply of assembly parts.

An assembly line can be automated with centralized or decentralized control technology. Faced with such a decision, what are the reasons for choosing one control architecture over the other?

Distributed version control system

Let’s begin by examining options presented in a distributed architecture.

Hardware

In distributed control architectures, the number and quality of CPUs used is determined by the number of modules. Each module has a controller, and the system usually features a central master PLC, which deals with tasks such as logistics, parts tracking, and statistics. The module PLCs automate their respective areas and usually have no visualization or operation facilities.

Decentralized architecture includes master PC for HMI, PLC per module connected to I/O points via fieldbus, communication via fieldbus, intelligent drives with their own positioning control, and synchronization methods.
Centralized architecture includes master PC running HMI and centrally controlling I/O points of each module, thereby coordinating control positioning of drives.

The master PLC handles visualization and operation of the complete plant. Since the scope of the control tasks executed in the modules is small compared with the overall automation task, a relatively low-performance and, therefore, low-cost PLC can be used. Module PLCs must be able to communicate with the master PLC via a high-speed bus for proper synchronization when the plant starts or stops. An Ethernet-TCP/IP-based network is typically used for this purpose. Data exchange is either via cyclic exchange of network variables or acyclic communications modules. A machine operating on this architecture can only start once all subordinate PLCs have completed their start-up procedure.

Software

Programs running on module PLCs are usually not very sophisticated, since the task to be programmed is simple. A single time level (single task) is usually sufficient. Communication setup and programming on the master PLC is more complex.

Fieldbus

I/O devices and fieldbus topologies are as simple as the PLC programs on the module PLCs. Since only a small section has to be automated, relatively few I/O signals are needed. Therefore, local I/O devices are usually sufficient. If necessary, an additional conventional fieldbus (with few nodes and small spatial extent) may have to be used. I/O connections have to be configured and the fieldbus diagnosed individually for each module PLC.

Motion Control

Most I/O module PLCs cannot be used to control several axes. If several axes have to be moved or synchronized, it’s difficult to avoid using intelligent axes, which are typically expensive. Position control and synchronization are dealt with on the drives.

Centralized version control system

Hardware

In contrast to the distributed architecture, a central architecture usually features a computer, often a PC, which deals with all tasks such as I/O connections, PLC, and motion control. Computing capacity, therefore, has to be significantly higher. However, there is only one CPU—which means only one such spare part is needed.

Software

For reusability and maintenance, the software has to be structured and modularized. IEC 61131 provides object-oriented approaches for this purpose. Since there is only one PLC program, storage and archiving are simple, and central start-up or shutdown of the PLC is straightforward.

Fieldbus

If the central fieldbus master is based on conventional fieldbuses, the extent of the system and the required quantity of slaves needs to be considered.

Motion Control

Since motion control calculations must be performed in the central PC, the demands on the fieldbus are even higher. For position control on the PC, minimum cycle times of 3-4 ms are often required—which quickly reaches the limits of conventional fieldbuses. However, motion control on a central CPU offers a number of advantages. Since position control, coupling, and axis synchronization calculations can be dealt with by software components in the PC, the drives themselves can be dumb, requiring only current control to be implemented. In this setup, synchronized drives respond very quickly. And potentially troublesome coupling of the drives via special buses is not required. In addition, the higher performance of the PC CPU and the expansive storage capacity enable very complex table coupling. A standard Intel Pentium III PC can easily handle up to 100 position-controlled axes.

Deciding between centralized and distributed version control

Distributed, local control technology offers a very structured architecture. Replacement and testing of individual modules is straightforward. Due to the simple topology, standard fieldbuses can be used without problems. Communication among modules, with the master computer, and for synchronizing the PLCs during start-up and stopping, however, is relatively complicated.

Central diagnostics, commissioning, and maintenance are the principal arguments for using central control technology, as are simple start-up and stopping of the plant, as well as simple administration of the single PLC program. A distributed architecture can include some or all of these attributes, depending on the tools and design. If the fieldbus is powerful enough, a PC can control and synchronize a large number of axes.

Other criteria for selecting which architecture to use include flexibility and reusability, and costs in terms of the hardware, wiring, commissioning, and configuration. Training costs are another item that should be considered.

Josef Papenfort is TwinCAT product manager, Beckhoff (a proponent of centralized control architectures); www.beckhoff.com