Containers, Open Automation, and Dick Morley

Tuesday night I spoke to a lively group from the ISA Boston Section on the topic of Open Process Automation. I had fun, and hope everyone else did, too. The most important point I wanted to make was this: Pretty soon it’s possible that the automation and IIoT edge worlds may have a common runtime software environment. Let me explain that in plainer English.

In the automation world, especially for PLCs, the term “runtime” refers to the software layer beneath the PLC’s automation application. DCS controllers have the equivalent but they don’t use the term “runtime” much. Regardless, the runtime in today’s automation products is both proprietary and opaque. Proprietary because there are no applicable standards and opaque because the only applications that use the runtime are the automation supplier’s own tools. For many good reasons, suppliers DO NOT WANT end user customers writing code that would run directly on today’s controllers. Rather, their configuration tools are the sole means for generating the code that executes on the controller.

Containers to the Rescue
That could change. Indeed, there are a handful of IIoT and automation products impending or on the market now where that is not the case. End users can code the software automation application using any software development tool chain they want. The standardized part is that the applications are delivered as Linux containers. The standard runtime is provided by the container execution engine – which today is a service called Docker (see figure). Docker is open source software and the Docker engine API is documented.

DCN Software Stack

Possible Software Stack for a “DCN” or Distributed Control Node (Source: ARC Advisory Group)

In my talk last night, I suggested that containers might be a very simplifying way to manage installations with thousands of very small systems that the Open Process Automation folks are calling “DCNs” for Distributed Control Node. A very large DCS installation today can consist of thousands of interactive components. A few dozen of these (usually the controllers) are most critical. Monitoring and managing the whole enchilada of a large DCS is a challenge, and the management software tools are all vendor-specific. If you scale up the number of modules (“things”) by a factor of 10 or 100, then you had better make the management 1000x easier or end users will still be in pain.

On Dick Morley
At last night’s meeting Don Clark of Schneider Electric announced that Dick Morley, founder of Modicon, was near death. It turned out that Dick died Tuesday night while we were meeting. I did not know Dick well, but Dick was the inventor of the PLC, the founder of Modicon, and became the foster parent of many, many children. Apparently, Dick was financially destitute at his death. Learn from that! There are many very important things making a great life that do not register on a balance sheet.

This came from Don Clark:
“For any who wish, we’ve set up a memorial fund for both a fitting and simple granite memorial at [Dick Morley’s] graveside as well as setting up a scholarship fund for some deserving student(s). Please go to the GoFundMe site: and make a contribution to his memory.”

Rest in peace, Dick, and thank you.


  1. There actually is a common control strategy programming language for controllers which is in use in a few thousand plants; the IEC 61804-2 function block diagram used as part of the FOUNDATION fieldbus (FF) technology. While FF is most known for the communication, this communication is integral with the function block language. It allows configuration software in the DCS from one vendor to build a control strategy and download it to control devices from multiple other vendors. These control devices can then communicate peer to peer as needed for control. The control execution and communication across multiple control devices is time synchronized. It is mostly supported in H1 instruments but can be used in Ethernet devices as well. It is explained in this document:

    • Jonas,

      Thanks for your comment.

      The difficult and much overused word “open” implies that system designers should be free to choose not only IEC 61842-2 but ANY OTHER modelling language, programming language, tool chain, or deployment strategy they wish provided their [executable software] deliverables comply with the standards-defined interfaces. This sort of constrained freedom creates an environment for rapid innovation, as the open source world has so well illustrated.