Manufacturing automation and computer development can both trace their origins to the work of Joseph Marie Jacquard, who in 1804 patented a punch card system for controlling automated weaving machines. A generation later, Charles Babbage used these cards in his design for an ‘analytical engine’, and Ada Lovelace showed how the engine could be programmed to solve complex mathematical problems.

In the centuries since, the world of software development pioneered by Lovelace, and that of machine automation transformed by Jacquard, have diverged. By the late 20th century, software coding was performed using text-based languages, while automation made use of physical relays and switches, tied to the workings of the machine.

David Nichols is co-founder of Loupe, a US specialist that solves some of the toughest challenges automation design. When he started his career, older engineers shared stories of the methods used to debug these physical relays.

“One engineer e told me stories about using air relays and physical air systems, pneumatic systems, to control machinery,” Nichol says. They’re literal air tubes running around this thing to control its behavior. When there would be an issue with the logic of this contraption of all these tubes running around, they would take a drag off of a cigarette and exhale it into one of the tubes to trace physically where the smoke goes and figure out the logic.”

The world that David Nichols’ mentor describes was coming to an end. Soon, almost all control systems were moved to a new device: the PLC, or Programmable Logic Controller. This is essentially a special purpose embedded computer, housed in a rugged box suitable for use in an industrial environment. But while a PLC is a computer, the way in which it is programmed is very similar to those pneumatic systems, or more common electrical relays.

Now, as value and efficiency is increasingly derived from data, a new change is needed.It is one that will reconnect automation and control, after two centuries in which each has become its own domain.

These physical relays spurred innovation. But by the mid-20th Century, they were reaching their limits. “You can make a machine do something with levers and switches and gears,” Nichol says,  “And you can build all sorts of contraption just out of metal parts to a certain level of sophistication, really quite sophisticated. If you go look at the pinnacle of clockmaking or engineering of that type, it’s truly amazing what folks were doing before electricity, before computers, just with mechanisms, just with hardware.

“What you see engineers doing over time is saying we could replace that with an electrical circuit or we can build more sophisticated systems or we can build systems that are better performing in some way that we care about by integrating a computer in there that’s more general purpose so it can be reprogrammed.”

This was the birth of the PLC, or programmable logic controller. PLCs revolutionised the world of industrial automation. Jan Bajorat, head of efficient engineering at Siemens, explains their value.

“The big game changer was the PLC, because now the engineers could basically do the rewiring in the software, programming the PLC itself and then this allows for much faster installation, for better troubleshooting, if something is odd, if the logic is not working. This allows for much more complex logic,” Bajorat says. “If you think about advanced motion control, advanced control algorithms, I could not picture those being wired in fixed electrical diagrams so this was massive, a massive change.”

Rather than being physically built each time, control systems could now be easily reprogrammed. That saves time in initial design, and in ongoing maintenance. “We’re not going to have to rewire it,” Nichols explains. “If there are mistakes, we can change them quickly. We can develop more quickly. There’s a lot less possibility for wiring mistakes or maintenance tasks. There were lots of reasons why programmable logic controllers were a revolution of their own.”

Peter Kurhajec is CTO of MTS, a Slovakian automation company. “The PLCs were incredibly successful because they delivered deterministic behavior,” he says. “They delivered hard real time. They were able to serve the whole ecosystem of IO devices, which were also very robust. We have have PLCs working for 50 years now, so they are very resilient, very robust, very, very durable. So these are the aspects that made the PLCs really extremely successful.”

PLCs hit their limits

PLCs offered robust, repeatable, and flexible control. But while the world of computing, pioneered by Babbage and Lovelace, was evolving, industrial control was still bound to individual machines.

“If you think now about the need for evolution, then this is often driven by access, for example, accessibility of the data,” says Bajorat. “But now when you think about how to optimize production, then data is key for artificial intelligence and such use cases. And those systems were often not designed perfectly for this manner. By nature, they were not made fully accessible from all the IT systems that are in place nowadays.”

This lack of integration with data systems limited the flexibility of PLCs, while general computing systems were being developed to take on any task. Key to this was the use of text-based languages and a software stack, rather than the visual systems used to program PLCs. “We don’t build computers and languages out of individual switches anymore,” says Nichols. 

“When I was in school, I learned computer engineering all the way down to ‘Here’s how a CPU will add two numbers together out of a series of switches’. And they’ll teach you those fundamentals. And very quickly they say, ’Don’t worry about that anymore. We’re going to teach you about assembly language now. And by the way, don’t worry about that anymore. We’re going to teach you about C now. And you might need to know the memory registers at some point. But actually we’re going to stack a bunch of other stuff on top of this.’ It’s like a skyscraper until you just have no idea what’s on the lower levels.”

The visual languages used in PLCs were very different from this, as Bajorat describes. “They come from the electric engineering space—so this is about programming languages that look, are familiar, to electric engineers like ladder diagrams and such—they look like electric wiring.”

This delivered real power to electrical engineers, Kurhajec says. “They allow people from  an electrical engineering background to have tools that were similar to their way of thinking. They were a way of drawing the electrical schematics and so on. And what we got in the PLCs was this visual programming languages that allow those people to transition seamlessly from what they already know to actual programming of the PLCs. If you need to control the machine, control your servo drives, your pneumatical pistons and to create very complex logic: That was a perfect tool for that.”

But developers working with these systems could only handle a limited range of complexity. “One of the aspects of this kind of programming is that you have a domain that you are addressing on that machine and in the middle you have this electrical engineering mindset,” Kurhajec says. “So each problem you are addressing, you have to go from the domain you are solving, through the electrical engineering, to get your program to do what you want to do. And once you get used to it, it’s okay. But when it gets more complex, the textual programming languages are more suitable for this kind of more complex logic.”

Today, it isn’t enough to develop an innovative machine. To stand out from competitors, manufacturers must develop complex controls systems that boost efficiency.

“More and more of the value creation of machine building is into the software and less value creation is into the mechanical space,” says Bajorat.  “Then the question is how to be most efficient in the software development space for automation engineering and who is most efficient in software development? That’s the software development that we know from the IT space.”

Text-based programming languages allow for the detailed logic necessary for efficiency gains, and for easy maintenance. Modern programming languages are increasingly object-oriented. That means a basic object can be designed, and changes specified upon this. A piece of code can describe the steps needed to manufacture a storage tank. New code can be built upon this, to describe the steps taken to make it corrosion proof, or capable of holding its contents at high pressures. All the code that can be reused, is reused.

“The textual languages and object-oriented programming are something that can be very helpful. It can reduce the time of programming by effectively creating components that can be effectively reused across multiple projects,” Kurhajec says. “It allows you to describe your physical components in terms of actions and in terms of their properties. And syntactically it is very easy to write and very easy to read.If you want to use AI, AI will work much better with text than with those visual programming languages.”

We are all familiar with the ways software can be used to add features to a physical device. The smartphone you buy will become more useful over time, as upgrades and cloud-connected apps deliver functionality.  

This approach is now being adopted in automation. There has been an influx of IT-like engineering solutions. These include software version control using the GIT system developed initially for Linux; package management systems, unit testing, and remote deployment capabilities can now all be used with existing automation tools.

But to deliver these improvements, devices must be connected to the internet. And the division between industry and computing, or between operational technology, OT, and information technology, IT, has prevented this integration.

That is now changing, with the development of virtual PLCs and other virtual runtime solutions. These virtualised offerings bring the power and reliability of a physical systems, but allow for data to be pushed to an external container, for easier exchange.

They are far more flexible than physical systems. One aspect of that is they can be run anywhere, even far from the machines they are controlling. Jan Bajorat and his colleagues at Siemens have helped deliver some of the first virtualised control systems. “We have one well known customer, who is currently already using the virtual PLC from Siemens in production. It’s running in a data center several kilometers apart from the manufacturing itself. And this allows for greater flexibility and scalability. If they want to change something, they don’t have to move around physical devices. It allows for cost-efficient redundancy. If something fails, they can just in a second fire up another virtual PLC instance, and this new one takes over.”

This connectivity allows automation engineers to use the same tools as software developers. Products and processes like GIT, a system for sharing code updates, have been designed and improved over decades. Improvements can be rolled out over the Internet, in the same way that upgrades are delivered to a phone.

“You can centrally manage your applications, like virtual PLCs, from a central space. And then when you want to roll out a new version, you can do that much more easily and efficiently than today. You can roll out this new app instance, maybe on 50 plants around the world.”