Industry 4.0: The PLC evolves from Controller to Cloud InterfaceFollow article
With all the excitement over Industry 4.0 or as it is sometimes known, the Industrial Internet of Things, anyone might think that factory automation was a recent idea. Apparently, the history of industrial development since the 18th century can be divided into three phases:
- Industry 1.0: The harnessing of steam and then electrical power to drive machines.
- Industry 2.0: Mass production and the assembly line.
- Industry 3.0: Basic automation: first with electromechanical relays, then the electronic PLC.
And now 4.0 heralds full automation with no human supervision. In other words, machines controlled by intelligent systems that can ensure safe and reliable operation, tolerate faults and even plan their own maintenance. This has been the Holy Grail of ‘Lights Out’ factory operation since the 1980’s.
The Basic Programmable Logic Controller
Early attempts at automating industrial plant machinery involved electromechanical relays connected in such a way as to provide simple logic functions such as AND and OR. For example, a relay only closes to supply power to a motor if a master panel switch is closed AND an input relay is also energised. Creating this function merely involves wiring the panel switch, the input relay contacts and the output relay’s solenoid in series. Close the panel switch, energise the input relay solenoid and the motor is switched on. A motor driven sequencer called a cam timer was incorporated to provide control signals at pre-set intervals allowing a whole process to be completed without human intervention. Straight away you can see a major drawback: that word ‘wiring’ means that changing any part of the process involves guys with soldering irons moving connections around or even adding more relays. In 1969 the first electronic PLC called Modicon 084 was delivered and while it represented a massive step forward in versatility, the programming aspect was not a big hit with the customer. It was after all, a computer, programmed in Fortran and machine code! Fairly swiftly new factory engineer-friendly programming languages were developed. The IEC 61131-3 standard defines five programming languages for PLCs: Ladder Diagram (LD), Function Block Diagram (FBD), Structured Text (ST, like Pascal), Instruction List (IL, essentially assembler language), and Sequential Function Chart (SFC). Ladder diagram was the most popular because it was easily understood by engineers familiar with the old relay logic.
A PLC is not a Single-Board Computer
It’s easy to see the PLC simply as a computer rather like a desktop PC. There’s a lot more to it than that. The average PC sits in a temperature-controlled office with an electrically ‘clean’ power supply and no sources of heavy electromagnetic Interference (EMI) nearby. PLCs may live in an environment that’s either very hot or very cold with heavy EMI from big motors playing havoc with unprotected microelectronics. For this reason, despite the miniaturisation provided by integrated circuits over the intervening decades, a PLC still consists of a collection of boards in a rack, only one of which contains the digital processor.
This picture shows a typical PLC installation consisting of modules plugged into a common backplane. The module on the far left is the power supply with the PLC controller next to it. Other modules are input/output units providing heavily buffered and protected signals connected to actuators (motors, solenoids, etc) and sensors (limit switches, panel switches, thermostats, etc). This sort of setup might have controlled a complete production process in a factory or chemical plant. An early PLC didn’t have much more ‘intelligence’ than its predecessor’s relay-based controller: only working with on/off (logic) signals and responding to ‘Events’ signalled by the switches and sensors. Later on, the ability to read analogue sensors and send a variable signal to actuators was added. A very robust and reliable technique called 4-20mA Current Loop signalling was (and often still is) used to link the PLC to temperature sensors, for example, or to provide a variable speed motor drive. A communications link to the control room (originally just serial RS-232) allowed programming changes to be made, from subtle process tweaks to installation of a completely new process.
The Modern PLC
Although microcontroller chips have been the heart of PLC controllers for many years, it is only fairly recently that designs have started to exploit the massive increase in their processing power. Most chips on the market contain one or more fast, 32-bit ARM Cortex-M processor cores and come in a variety of versions, each tailored for a particular application such as motor control, power supply control or multi-media. Motor control chips for example, feature on-board hardware providing multiple PWM outputs, Quadrature Encoder (rotation sensor) inputs, analogue I/O and of course a great deal of simple logic signal I/O. A Cortex-M4F core also boasts Digital Signal Processing and Floating-Point maths hardware allowing complex control algorithms to be run in ‘real-time’. That last capability means that the PLC can at last take on Direct Control of machine actuators.
The processing power and relative low-cost of microcontroller chips make it practical to give every machine actuator its own dedicated controller. So, for example, providing every motorised joint in a robot arm with local closed-loop PID control independent of supervision. Process commands arriving via a communications link will just be of the form: ‘Rotate joint by x degrees at a speed of y degrees per second’. The ‘Machine PLC’ will translate that into the signals required to drive the motor at the set speed, perhaps ramping it up to start and then down to stop. It will use its own hardwired rotation sensor on the motor shaft to provide speed feedback for the control loop and angle sensor on the output shaft to confirm that the joint has moved to the requested position.
Hierarchical Factory Control with Industry 3.0
The beginning of the Industry 3.0 era saw the introduction of the basic PLC described above; by the end, factory automation had evolved into a sophisticated hierarchical structure with a single Master control room computer at the top, and small Machine PLCs at the bottom ‘Field level’; each of the latter dedicated to controlling a single machine. In the middle are a number of Supervisor PLCs each controlling and monitoring a sub-process (Fig.1).
Power comes with Responsibility in Industry 4.0
Even with Direct Control, the Machine PLC will still be spending a lot of time just ‘twiddling its thumbs’. Is there anything else it can be doing? This is where we start to move into Industry 4.0 territory with semi-autonomous Machine PLCs able to:
- Monitor the condition of mechanical components and flag up future maintenance issues before failure. For example, unexpected increases in motor current could indicate bearing seizure and vibration sensors might detect worn gearing or linkages.
- Communicate with each other directly within a process, so as to optimise performance at the process level. Each joint in robot arm is given its own command by the Supervisor, the aim of which is to move the arm’s end-effector (gripper) with a trajectory to a point in 3D space. The individual joints could provide each other with information on their status in order achieve an optimal movement.
- Gather performance data, feed it back to the Production Controller and if required to a remote location for analysis via the Internet.
- Detect both transient and hard faults within its electronics, preferably without having to shut down. This can be achieved by using the latest microcontrollers featuring extensive error detection and correction circuits including processor redundancy. Such devices for meeting the industrial Functional Safety standard IEC 61508 are available now.
Most of the big chip manufacturers now produce microcontrollers for applications required to meet the Industrial standard IEC 61508 and ISO 26262 for automotive systems. Examples are the Infineon AURIX range .and the Texas Instruments Hercules
What’s the difference between ‘Real-Time’ and ‘Deterministic’ operation?
Real-Time Operation: Real-time systems are systems that respond to an input immediately. This is a theoretical, but never practically realisable concept. Every real electrical or electronic circuit has a Propagation Delay. In other words, it takes a finite time for a signal to travel through the circuit from input to output. Even a short piece of wire has a propagation delay, especially so at very high frequencies. What can be achieved is:
Deterministic Operation: The ability for a system to respond with a consistent, predictable time delay between input and response. This time delay is commonly referred to as the Scan Time. A predictable Scan time can be accounted for in the software and/or hardware. For practical purposes, such a system would be said to be capable of ‘real-time’ operation – essential for communication networks in automation.
A more Democratic, less Hierarchical Architecture for Industry 4.0
We are going to need a network topology that’s a lot more flexible than that of Fig.1 in order to enable the features described above and at the same time maintain uninterrupted ‘real-time’ operation. Traditionally, for industrial applications, nodes have been linked by wire using a variety of protocols under the generic title of Fieldbus, defined in the standard IEC 61158. A fairly recent newcomer is EtherCAT, designed to meet the demands of Industry 4.0. EtherCAT is an extension of Ethernet optimised for industrial automation. Networks can be constructed with Line, Tree and Star topologies, or a mixture of all three. A simple line example is shown in Fig.2. The Master node generates all data packets and they ‘flow’ through each slave node from A to F via the Blue cables. Each node has a unique address and can receive or send data on the network. Clever techniques are used to ensure accurate timing and determinism for ‘real-time’ operation. While only the Blue cables are strictly necessary, the addition of the Red cable from the end slave node F back to the Master provides for continued operation should there be a cable breakage. Slave to Slave communication is possible albeit with a small timing overhead. Even so, EtherCAT is still a lot faster than the alternatives.
What about Wireless?
Wireless communication dominates the Internet of Things with applications such as Home Automation. In my opinion, wireless is nothing like robust or secure enough to replace cable in a large, electrically very noisy factory full of machines each capable of causing mechanical mayhem should communications be lost, corrupted or ‘hacked’. A cable linking two nodes has characteristics that can be measured precisely, just what you need when constructing an automation network. A wireless channel? Best of luck trying to characterise its performance in advance! It may happen with Industry 5.0, but cable looks like the best bet for the foreseeable future.
It’s difficult to resist the idea of a large network of fully interconnected microcontrollers with spare processing capacity turning into a collective intelligence – the factory as a ‘brain’. In this scenario, all the data collected by all the machine and process sensors is augmented with environmental data and Cloud data, then presented to a trained Deep Learning Neural Network. The result is a global tweaking of the whole factory operation as the DL network recognises patterns too small and complex for mere humans to spot. Another area of development is the use of so-called ‘Cognitive Sensors’ to optimise warehouse and supply-chain operation. Perhaps by Industry 5.0 the old joke about the already near-autonomous chip fabrication plants will become an unfunny reality:
“This plant is run by one man and a dog. The dog’s job is to scare off intruders. The man’s job is to feed the dog.”
If you're stuck for something to do, follow my posts on Twitter. I link to interesting articles on new electronics and related technologies, retweeting posts I spot about robots, space exploration and other issues.