Classical Automation enters Alien World of IT: Part 2

In part 1 I described the main differences in aims and system architecture between classical automation and classical IT: automation needs highly reliable, fast and predictive systems, whereas the IT world needs to be more “social”: versatile, adaptive and communication friendly. In this second part, I will try to explain the core differences in communication.

Part 2

Field busses versus internet protocols

A PLC (see part 1 for explanation) samples its inputs and combines it with internal states to a snapshot called “process image”. This snapshot is used for calculations and decisions. It results in a simultaneous state renewal (change) of all outputs. Input and output signals are typically either 24 V digital signals or analogue signals like 0 to 10 V voltage or 4 to 20 mA current loop. But if you have hundreds of sensor inputs, you will no longer be able to connect them all physically with individual cables. The solution is a “bus” with just a few wires. It transports the information between the PLC and many sensors and actuators sequentially (it works “serial” instead of “parallel”, picture 1). Sensors and actuators need to be more “intelligent”: They need to have an integrated communication processor to exchange their values with the controller.  

pic. 1: Conventional wiring (left) versus field bus wiring (right).

So-called “field busses” or “industrial busses” need to transport information in a predictive way. Predictiveness in communication means that you need to know precisely the maximum reaction time between an enquiry and the answer to this enquiry (by the way, this is the definition of “real-time capability” and not an arbitrarily defined absolute time limit). Whatever this reaction time may be, any deviation of its rated value is called “jitter” and makes a system less predictive. A small and known maximum jitter is the crucial property of a real-time system in automation. This is the reason why reducing the reaction time by using interrupts is not a smart idea: Any interruption introduces a probabilistic factor, and the whole system loses its deterministic property. No wonder, field busses often work cyclically and deterministically, just like the controllers (PLCs) to which they are connected. A cyclically working system offers a defined jitter. You may imagine that combining several asynchronous cyclical systems (like a PLC and a field bus) will sum up their jitters. Synchronising the bus cycle with the PLC cycle is an easy way out of this problem.

pic. 2: Reaction time and jitter in automation.

“Protocols” are agreements between communication partners which define the phases of and behaviour during communication. A huge problem is the historically grown diversity of these protocols in automation. Machines often talk in different “languages”, and there is a whole industry involved in translating these languages. Let’s have a closer look at one of the classical field busses, defined in IEC 61784 / EN 50170 norm: The “Process Field Bus for Decentralized Peripherals” (Profibus DP). It uses a differential digital signal on two wires, based on the RS485 standard, but with very high bit rates (up to 12 Mbit/s). It works with a strict master-slave constellation and the protocol part DP V0 uses cyclical data transport (see picture 3). The controller (PLC) is master, and peripheral IOs are slave devices which are only allowed to answer to requests coming cyclically from the master.

During configuration time the engineer needs to tell the controller how many IOs and which type of IOs are connected. After a startup sequence (“parameterisation” and “configuration”) in which every slave device has to “join” the network, the PLC cyclically polls all IOs with a defined poll rate (“request frame”). The slaves (peripheral IOs) acknowledge the reception of their data and immediately reply with their IO states (“response frame”).

pic. 3: Cyclical data exchange on a Profibus

I do not want to complicate this short introduction, so I only mention that there can be a token ring communication to allow multiple masters on a Profibus (only the master with the token is permitted to poll, and when it has done its cycle it passes over the token to the next master). There is a lot of built-in safety: E.g. if a slave does not get polled in a predefined time, it changes its output to pre-defined “safe states”. If a slave detects a malfunction, it can set the alarm (“diagnostic”) bit in his answer to the PLC which in return lets the master request the diagnostic data with its next poll.

There are also built-in methods to deal with the “consistency problem” of a serial bus: In part one, I introduced the “process image”. I mentioned how important it is in automation to get a consistent frozen snapshot of the inputs states (or to switch the outputs simultaneously). But how can you get such a snapshot when the input information of several sensors is transmitted in a sequence? When the second sensor value answers his poll request, the first sensor value could already have changed. Profibus knows a “freeze” command. The PLC broadcasts this command, and all slaves do freeze their input values until they have been polled. This way you get a snapshot of the moment when the PLC has sent the “freeze frame” (telegram).

The bit rate of the bus limits the poll rate, and in case of transmission errors, there might be poll cycles which do not reflect the actual IO state. But at the end of the day, this type of communication is exceptionally reliable and deterministic. Profibus was introduced in the nineties, and with over 40 million certificated devices it is still one of the most used communication protocols in the automation industry. Its reliability makes it perfect for safety technology (we will have a look at this topic in part 3 of this series).

This cyclical master-slave concept may look somehow weird to IT engineers: Why asking a switch position over and over and why should a switch continuously tell the controller that its state is “on” instead of sending just one message when it changes its state from “off” to “on”? Because it would be challenging to construct a deterministic system when using such an event-based communication.

When an application program communicates with a database, and they both run on different hardware, you often have a server-client architecture. A single server needs to process data for many clients. See the core difference? Many clients must be able to initiate the communication – they are communication masters – and the central server reacts as a slave system to them. Using a message triggered dialogue feels much more natural in such an environment. You could, of course, think of a deterministic network which is message based (e.g. Token Ring). But because of their ultrahigh statistical overall data throughput, probabilistic networks like Ethernet have won the race. Such networks allow any participant to initiate communication at any time they need to send a message. This freedom results in possible “collisions” when two clients start simultaneously. But having a fast collision detection and reaction strategy, you still end up with a brilliant throughput. In modern network topologies (star instead of bus or mash), you avoid collisions by powerful “switches” which time-shift simultaneous messages to “daisy chain” them.

IT networks and their protocols are not only able to transport gigabits per second instead of megabits like Profibus but also their topology is flexible. It is technically no problem to span such a network worldwide, like the internet. A key to this flexibility is the protocol abstraction into “layers” which build a “stack”. The OSI reference model defines seven layers (see picture 4). Profibus, e.g. does only defines three of them (layer 1, 2 and 7). The internet with its TCP/IP protocol uses all of them.

pic. 4: OSI protocol layers; HTTP as an example.

The flexibility of such communication architecture results from the fact that two partners may communicate using the same layer but need not know anything about the communication processes in lower layers. They receive their messages from the next lower layer just as if they would directly communicate with their network partner at the same layer (picture 5). You can think of it as “virtualised communication” with the neighbour (partner) layer.

pic. 5: Layer to Layer communication using protocol stacks.

Using a network layer (OSI layer 5) offers the possibility of packet-switched routing: Each network node can make its own decision to which neighbour node it forwards a received information package to bring it to the desired receiver address (IP). This is the base of the internet, and it merely means you can never know which way packets of information will travel from sender IP to receiver IP.

The odds of this flexibility is the loss of “real-time ability”. You no longer can precisely predict or define a maximum response time of your communication partner. If you use a TCP/IP based network to communicate a state change of a switch, it could take some microseconds or dozens of milliseconds for the controller to receive the message. “TSN” (time sensitive networks) deal with these odds, and they aim to establish real-time ability in IT network protocols.

The good news is we do not need the real-time ability for IIoT. Latency is not the primary criteria. But there is a particular limitation when planning to bring an industrial machine into the internet: For event-driven communication protocol stacks, you always need threading or multi-tasking operating systems. Classical PLCs usually do not have such an OS. Modern so-called “soft PLCs.” are applications running on Linux based IPCs (“industrial PCs.” – computers which are often mounted on DIN-rails and do not use keyboards, mouses and monitors). Although such systems efficiently can manage TCP/IP protocol stacks, it is wise to strictly separate message-based IIoT communication from the control software. Gateways are a perfect mean of network and software separation. A gateway can behave like any peripheral IO to the PLC (talking its field bus protocol) and connects to the message based internet on the other side. Gateways are often the point where safety meets security – but that’s the topic of part 3…

Next Part 3 Part 4