Centralised or decentralised automation? That is the question
Published: 23 February, 2022
Tony Coghlan, Managing Director at Turck Banner, takes a look at the discussion surrounding whether automation should be centralised or decentralised.
The Centralised model has been around for many years and is often regarded as the outdated 70’s and 80’s model. It is a control pyramid with the sensors and actuators at the bottom. Sensor data passes upwards and control commands pass downwards to the actuators.
Each level in the pyramid only has access to the level above and below it, and every bit of data or control must pass through it, regardless of whether it is being used by that level. This often results in large quantities of data and control being transferred, which can slow the response time (latency) of the whole process.
In the Decentralised model the strict hierarchy of the vertical pyramid is dissolved, allowing a network of communication, with each part talking directly to the other parts that require the information. Instead of having one PLC (Programable Logic Controller) controlling every part of the machine or process, multiple smaller PLCs are distributed throughout the machine, each autonomously controlling, preprocessing or collecting data from a smaller part of the machine.
The Decentralised model has led to the development of a number of PLC variations. The traditional PLC is an industrial computer running sophisticated software designed for the control of a manufacturing process. It has many digital and analogue I/O and was traditionally housed in a control cabinet. In the decentralised world the PLC is now in a rugged IP67 housing, mounted directly onto the machine.
A Field Logic Controller (FLC) is also a PLC in a rugged IP67 housing, mounted directly to the part of the machine that requires the control. The difference is mainly in the software, as an FLC typically runs a much simpler control language than the PLC.
An Edge Controller is a PLC that sits at the edge of the digital world and the real world. They typically pre-process data received, sending only filtered and refined data in the correct format to the required systems (ERP, MES, SCADA, Cloud, etc,)
All of these Decentralisation Units (DU) receive the information that it needs to control its part of the process. This information can come either from sensors on the machine within its area of control or from other controllers. It can also pass information to any other area that requires it. Turck has blurred these definitions further by producing devices with combinations of PLC, FLC and Edge controllers in single units. This allows the user to choose exactly what they need in terms of control, processing and communication for any part of the machine.
A simple example would be a roller conveyor between two parts of a production line. Sensors on the conveyor can detect when a part is present, and the Decentralisation Unit (DU) can control the rollers around that part to transport it towards the next machine. When the part reaches the end of the conveyor, communication between the conveyor DU and the next machine’s DU will determine if the part is moved into the next machine or waits for the part to be needed. When a part is not on a roller, or is waiting, the roller will be stopped, thus saving energy and wear. If the next machine is stopped, or running slowly, parts will probably gather along the length of the conveyor with the conveyor DU effectively parking each part it receives in the queue. When there is no more capacity on the conveyor for more parts the conveyor DU will communicate with the preceding machine, which may then stop or divert parts elsewhere.
As each controller is not burdened with information that it does not require, processing speed is rarely an issue. Resources can be allocated efficiently, choosing the most costeffective devices where they are needed. Information that isn’t time critical can be stored in the DU and provided where it is needed, either on demand or on a schedule.
The conveyor DU in the example above may send the count of product passing along it to a cloud-based storage service once a minute, enabling this information to be used by an OEE (Overall Equipment Effectiveness) process. It may also pass on the current condition of the monitored parts within its scope, or more likely will pre-process this information to determine what needs to be sent and within which time frame.
If a parameter is within tolerance, a record of that data is not needed every second. A periodic record would be all that is required to show a gradual degradation. However, as soon as the parameter is outside of the tolerance, a constant recording may be required, thus saving huge amounts of data transport and storage.
The decentralised model of a network of communication requires interfaces to be programmed between every connection. Many different industrial bus protocols are used and often each product or machine manufacturer has their own preference, which adds an extra layer of complexity to each interface. Many interfaces are also required between the industrial networks and the Cloud and commercial networks.
Turck Banner has Multiprotocol devices which sit between two networks and translate the data to facilitate these interfaces. They also have devices which can bridge two ethernet networks, each able to use their full range of IP addresses. They allow communication between the two networks when required, but otherwise the two networks are completely independent.
While HMIs (Human Machine Interface) are commonplace on the machine, increasingly the human element of this interface is no longer present at the machine but is in an office or workshop sometimes thousands of miles away. This is where the cloud-based solutions excel, as the data can be accessed from anywhere. Many solutions also have the facility to send emails and SMS messages to alert someone when urgent attention is required. To access the data from anywhere in a meaningful format, dashboards are created that are typically accessed through a web browser.
Each person with a different role in a company will want to see different information on their dashboard from the same machine, and every machine will have its own dashboard. At what point does having a dashboard for every part of the machine solution is to be able to combine all the information that someone wants into their own unique dashboard, this currently requires significant programming.
Currently some standards are being developed to address the problem with dissimilar protocols and, if these are adopted, writing interfaces will become much easier. OPC UA and AutomationML are both open communication developments that define how the data exchange takes place and what the content is.
Eventually adding the information, you want from any machine to your own personal dashboard will become as simple as a few clicks. When these things happen, the decentralised model will probably become the normal configuration. Until then the model will be a hybrid somewhere between the two extremes.
Centralised or decentralised, they are not mutually exclusive and currently most companies are using a combination of both. Centralised does not mean old and outdated and equally decentralised does not mean you are running the most efficient factory. Decentralised is the direction of the future
https://www.linkedin.com/company/turck-banner-ltd/
https://twitter.com/TurckBannerUK
