Industrial Automation and IoT Software: Common Threads

Last month ARC published a report I wrote on the future of software for industrial automation and embedded systems. It was entitled “The End of Industrial Automation (as we know it)”. Here I’ll make some observations about some of the many common threads between future automation software and future software for the Industrial IoT.

First, both automation and IoT have software elements that run inside of “things”, meaning they are embedded systems in all or in part. I say in part because industrial controllers (PLCs and DCS) contain both embedded and programmed (or at least configured) software elements. Most IoT installations don’t touch this embedded software but instead use an interface or service provided by the “thing”, such as an OPC UA server perhaps, but probably some legacy interface.

Second, both automation and IoT require taking some action to deliver value. In automation the action usually involves the precise control of a machine or a process unit operation. In IoT the range of actions is much broader, but an IoT story without some available action to deliver greater value makes no sense.

Third, I received this excellent question from a Canadian reader: “What is the relationship between this new automation software and cloud-native software?” Cloud-native is a buzzword, but it has this definition, given by the Cloud Native Computing Foundation (emphasis mine):

"Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach…."

My ARC report talks a great deal about the value of containers and declarative APIs. I’ll leave service meshes for later. Let me focus here on the concept of “immutable Infrastructure” (II) which plays into both IoT and automation.

II refers to software infrastructure. It means that when you modify some code, your installation deploys the changes by replacing, not modifying, the old code everywhere. With II you can't poke  inside a machine to tweek code or an environment variable while it is running (then, of course, not document your tweek and forget about it until sometime later). Docker/containers are part of II but only part. II requires the complete automation of a software runtime environment. This is only possible in environments that have an API covering all aspects of configuration and monitoring.

IT folks contrast II with the legacy view of “artisanal infrastructure”. In the past when hardware was much more expensive, IT needed to carefully configure and maintain (tweek) individual servers to manage their large hardware investment. In the cloud, this is madness. A cloud server is a pure commodity; indistinguishable from any other, and not some engineer's science project. The IT focus shifts to application performance, because server hardware has become mere infrastructure.

What's the connection of this with automation software? The word “artisanal” is absolutely perfect to describe the historical practice of industrial automation. Every PLC or DCS in the world represents an artisanal work of engineering. Sadly, industrial automation is essentially practiced today much like a medieval cottage industry. The cloud-native computing liberates IT organizations from of this faulty hardware-centric perspective. Industrial automation can (and will) experience a similar liberation from a hardware-centric focus.

By the way, if you’d like a full copy of my report on future automation software, please drop me an email with your contact information and I’ll gladly send you one.