Classical Automation enters Alien World of IT: Part 1
When I started computing in the seventies, it was natural to understand the hardware of your CPU. I needed to key in every single byte and its RAM address with a hex-keyboard. After filling one kB of RAM, you better have been sure to control the content by reading your 7-segment display a second time before pressing the “run” button. Connecting switches and LEDs was the normal way to let “users” interact with your software. It was very much “physical computing”. Later in university, I learned using FORTRAN to do calculations. I was not even allowed to touch the computer. We needed to punch holes into sheets of cardboard (so-called “punchcards”) and let an “operator” feed these sheets into the computer which was more or less a room full of 19” towers. The next day we could collect the computing results as printouts or punchcards. Since these days I have been a traveller between these two worlds of physical computing and the classical IT world. They are very different and specialised. Very often the experts of one world do not understand what the experts of the other world are talking about, or why they see difficulties in problems which do not exist in their own world.
Naturally, the tools and rules for these two computing topics have been historically established differently to follow their specific aims. And this seems to be one of the main obstacles for rapid development in IIoT (“Industrial Internet of Things”). In this series of articles, I will try to explain some of the core differences. Hopefully, you will come to understand why safety and security have seldom met in the automation industry before Industry 4.0 or why cyclically running a state machine is not the best architecture for an OS like MS Windows. Maybe you are more the IT type of expert and want to understand what makes a PLC (“programmable logic controller”) architecture so unique. Go on reading…
Deterministic versus probabilistic system architectures.
In the automation industry, “Things” are the domain of classical engineers. They design embedded systems or program PLCs (“Programmable Logic Controller”) to control complex machines for production processes. Their system architecture aims to maximise reliability and often uses maximum reduction. Things need to reliably perform the same tasks over and over very often without the interaction of humans. So-called HMIs (human-machine interfaces) allow human supervision and adaption of process values but are not a central part of the core control algorithms. I’ll try to give you an impression of how this type of architecture developed.
Pic. 1: Simple logic circuit. LED turns on if both buttons are pressed.
In the beginning, physical computing was done by combining binary logic gates. Like in picture 1 you see two switches (could be binary sensors like light barriers). If you close both, the output turns on a LED. Now think of a way to monitor a switching sequence by such logic gates. You end up with a “clocked logic” which works in cycles (pic. 2).
Pic. 2: Example of a clocked logic. You can simulate the logic using this link: http://simulator.io/board/Yc9tpDmfyO/3
A PLC works like such a clocked logic. A bunch of gates can be connected (output to inputs) by your PLC “program” to make this controller flexible (in the early PLCs there was indeed an array of logic blocks – therefore the name – whereas today a CPU does the job). But in the core there is always a cyclical operation: Get a snapshot of all inputs, calculate binary operations on the inputs, set all outputs. Thus the logical operations depend on inputs and defined “internal states” (buffered in logic circuits called “Flip-Flops”) which all need to be buffered in a kind of “snapshot-buffer” (“latch”) before the PLC performs binary calculations. The results are buffered again before they switch the outputs all at the same time (picture 3). This buffering of the so-called “process image” is essential to avoid misinterpretation.
Pic. 3: Cyclical operation of a PLC using a "process image".
Any sequence needs a clock to detect “before” and “after”. But clocking a signal (input) means to “sample” it. The clock rate turns out to be a sample rate and as Nyquist has mathematically shown you can only reliably detect any signal which is not shorter than double the sample rate. Take the example of picture 2: If an object moves through both light beams, this always results in a sequence “00 – 01 – 11 – 10 – 00” or “00 – 10 – 11 – 01 – 00” depending on the direction of the transition. The clock period should be shorter than half the time between two of the states to detect such a sequence. Sampling the two light barriers at different times would make the detection very complicated if not impossible. To calculate a minimum clock rate you expect simultaneously sampled signals.
Nyquist for dummies
C.E. Shannon introduced the term „Nyquist frequency“ in signal theory when he worked on “time-discrete systems”- don’t worry it only sounds complicated. When we look at a digital signal it becomes quite easy to understand:
Let’s say we have a square wave toggling between the two digital values “0” and “1”. Your machine cannot continuously watch that signal but needs to cyclically pick the actual value (“sample” it). If you look at the timeline of the signal and the “sample points” you will understand that you need to sample at least twice per square wave period to reliably detect the two states of the square wave. So the “sample frequency” (sometimes also called “sample rate”) must be twice as high as the signal frequency.
In other words: The highest signal frequency which can be reliably processed is ½ the sampling frequency. This highest signal frequency allowed as input to your system is called the “Nyquist-frequency”.
Signal frequency barely okay:
Signal frequency too high => “signal aliasing”(red dot):
This sequential concept of sampling a process image, doing calculations on the buffered input values and buffering results until the end of computation before simultaneously switching the outputs is essential for a highly predictable system. Later it was adopted by embedded controllers which use FSM (“finite state machines”). Each cycle of the FSM starts with a defined state and may end in a transition into a different state depending on signal states. You could reduce the concept of such Controllers to a simple task: “Cyclically switching states (and outputs) according to input and internal states”. Such a controller works completely predictably and reliably (“deterministic”) because at design time you need to know every possible state it can have as well as the state transition rules.
EN 61131 is one of the central norms following this architecture and was established to define the behaviour of controllers in the automation industry. It also defines programming languages like Ladder Diagram (LD), Function Block Diagram (FBD), Sequential Function Chart (SFC) or Instruction List (IL) which reflect the historical electronic roots of the PLC technology (e.g. “ladder” is very close to the circuit diagram of a digital logic).
Pic. 4: Examples of PLC programs in LD (left) and FDB (right).
To get such “Things” connected to the cloud means entering a different world with different aims and rules: The classical world of IT. You often find a separation in so-called “backends” (with databases to store and retrieve mass data collections effectively) and frontends (mostly PC based applications with a highly interactive GUI). You could even say that data-human interaction is the base of classical IT, whereas sensor-actuator interaction is the domain of controllers in automation. Therefore the system architecture of IT is often optimised for maximum efficiency, re-usability, usability, and comfort. Smart user interfaces (UIs), object-based programming languages and multi-tasking operating systems do fit well to these aims.
Cyclical operating software would be a waste of resources. IT systems more often use an event-based concept: You click on a virtual button which triggers an “event” inside the software. This event triggers all linked processes. Background processes (often referred to as “daemons”) continually monitor the mouse to detect a click or perform other jobs. These daemons work mostly independently and asynchronously. Other processes can subscribe to get messages whenever certain events occur. So there are “services” offered by backend processes. Such processes provide their services to client processes.
While a PLC in automation would cyclically ask a switch if it is closed, an operating system like Linux would organise the following scenario: The keyboard service sends a message as soon as a key is pressed. Any application software which has subscribed to this message will receive it with a minimal delay and may or may not react to it. The communication between a service and a client usually is message and event-based. It uses well-defined interfaces which is the only dependency between them. Because the rest is independent service and client processes can run on different systems, and they often do so (e.g. “backend” and “frontend” systems). Such server-client structures easily allow a distributed and highly scalable architecture. A modern cloud provider like AWS does provide over a thousand services, and millions of clients can use them simultaneously over the internet.
So this type of architecture is anything else but “finite state”: Working with many independent and asynchronous processes result in a less predictable system. The amount of possible states is typically too high to be entirely known and considered at design time. On the other hand, because of scalability and the object-oriented design principles, such systems are nearly unlimited when working with mass data. In many ways, they are much more like we: multi-tasking, highly interactive, communication friendly and adaptive at the expense of reliability and velocity. No wonder that IT is predestined to interact with humans (GUI). No wonder that communication between systems has a much more “social touch” (we will have a look at this in part 2). And no wonder that “probabilistic computing” (using statistical methods for decisions) allows for machine learning and AI (artificial intelligence).
Pic. 5: IIoT – where automation meets IT.
If automation engineers want to join their deterministic home with this fantastic new probabilistic world, they need to understand that it is based on these “human” qualities. Connecting the cloud to real-world machines, on the other hand, does introduce new risks and IT engineers need to understand the base of reliable working automation.
Part 2 is about field busses versus internet protocols, part 3 is about safety and security, and the final part 4 will talk about opensource versus protection of IP.
CommentsAdd a comment
Much like MikeJones, I enjoyed your article a lot, even though cleaning my desk from my nostalgic tear drops menaced to ruin the experience.
Most in the same way you (and him) did, I traveled the path from punchcards to Raspberry Pi and (I)IoT, passing through BASIC, PASCAL, FORTRAN, C, C++ and C# (I even know what Algol was, even though I have never used it), from Rockwell's AIM65 and Intel's MCS85 to the current ARMs.
I can't wait for the next issue!
My point is: both worlds are converging, many times against their proponents will. The computing power these new approaches have for us, developers, has never been so big, and keeps increasing as much as the systems keep shrinking in size and (not always) in price.
Thank you, VdH!
Dear arodulfo, Yes, those 2 worlds definitely do converge and the monetary pressure for it is so strong and convincing that unwilling proponents cannot prevent this process. So it is a better strategy to bow to the changes and use the opportunity to be part of great visions. So let's share some more Dino "generation A" stuff: remember the times when you did not need tweezers and glasses to change data medium but 2 strong arms to change the removable disk (RL02 with 10 MB) of a PDP11/10? Remember you needed an ear protector when printing your listings on LA36 DecWriter? When you used the 8" RX01 drive to save at maximum 1/4 MB per medium, you do know why floppy disks were called "floppy": two layers of cardboard with a piece of plastic in between. But the system could boot from these 256 kBytes! Never heard of an 18-bit bus? DEC's PDP11 used it... Imagine a RAM which needs 1mm per bit... it was called "ferrit-core memory"... Ever used "wire-wrap" instead of a PCB to build a complex digital device with dozens of 74xxx ICs?
Loved this article as it took me back so many years!
Started my experience with "computers" way back in 1970 when the machine was jam packed with valves and broke down on a weekly basis! This machine had 32k of Ram The language was something called "Algol". I really do remember the green punch cards - average program would require about 200 of them. Submit to the operator and go back the next day to get a single sheet of (green lined) paper with the words "Syntax Error" - and that was it - no clue as to where the error had occurred!
Loved the article and look forward to the next installment!
Having been involved, over the years, with both systems it seems to me that PLC systems are, in a lot of ways, emulating IT systems. A lot of PLC manufacturers now incorporate interrupt (or event) driven functions. Would you not agree?
Maybe eventually systems may become indivisible?
@MikeJones Good to know that I'm not the only Dino out there ;-) Some weeks ago, when I talked about punch cards at lunch, a quite young colleague said to me "you're not "gen X" you're "gen A". At the meeting after lunch, they dropped a punch card on my table (don't know where they found it) as a present for me. I started punching holes in it with my pencil and said: "...all right, so I'm writing today's protocol...". Yes, you're right: Both worlds will definitely melt together in the near future. This was the reason to write these articles. I'm absolutely convinced, that we can earn lots of experience and knowledge from both worlds. Most modern PLCs do already run under some kind of RTOS and several (like the REVOLUTION PI) even use a Linux OS. So internally they do use classical software patterns of the IT world. But many of today's automation engineers still love to use the EN61131-way to set up their control programs. So Siemens and others are trying to limit the event-driven parts of their PLCs to Gateway-Functions (OPCUA / MQTT). Real Event-driven and distributed control systems would need to implement EN61499 which was defined to implement component/module based programming. EN61499 has innovated from cyclical control mechanisms to event-driven control. As far as I know, some people have implemented an EN61499 software on REVOLUTION PI. For me, it seems that EN61499 is sadly only an academic vision (I don't know any PLC which is sold with EN61499 software toolchain). I do know that a group has implemented a component- and JAVA-based PLC software ("https://www.openpr.de/news/675628/Elbfisch-Open-Source-Projekt-fuer-die-Industrie-Automatisierung.html") on this hardware platform. But to my experience, the market does not (yet) demand a switch to such innovative new models for automation controllers.