The other day some utility industry colleagues and I discussed IT/OT convergence. The discussion included an exchange on the future of containers in the Operational Technology (OT) environment. I thought the topic would make for a good blog post.
First, let’s define what we mean by the term “container.” In the information technology (IT) world, a container is the combination of a piece of software and all the executables, libraries, configuration files, and other dependencies that an application or server needs to function. This “bundle of code” runs in a protected environment such that the software running in one container cannot directly impact software running in a different container.
By bundling all application components together and not relying on similar functions and code provided by an operating system, the software becomes relatively portable. I can move it from one container platform to the next, and I don’t need to worry about the operating system version or what library (often called a DLL in the Microsoft Windows world) on the system might have been modified by installing another application. I can run two different pieces of software that might require two different versions of the same library. Since each container gets its own copy of the library, there’s no reason they both need to run the same version.
This concept is very close to virtualization, where multiple copies of an operating system may be running on a system, each as an independent “virtual machine” running its own set of applications or services. The main distinction is that a machine supporting containers only has one copy of the operating system running. Thus, it does not require the overhead of multiple virtual machines. The most common implementations of containers are Docker and Kubernetes.
While containers are common in the IT world, what benefit would they bring to the OT world? In a nutshell, they would allow more modularity of function in OT devices. Many OT devices today run on what one might call “monolithic” software. That is, from the operator’s point of view, the device runs a single firmware image. If I want to upgrade a device to take advantage of a new feature or address a cyber vulnerability, I need to replace a single firmware image with a new one. This means I now need to be concerned about what functions that previously worked fine may have had new bugs introduced in the latest version. Most OT operators would probably prefer to have the option to upgrade only the software for that one function that needs to be added or upgraded. However, with many OT devices today, that is not possible – the options are to either replace all of the software or none of it.
In recent years (decades?), we’ve seen a trend of many functions being combined into a single box. For example, in the electric utility protection world, a relaying scheme made up of electromechanical relays that may have taken up the better part of an 8-ft panel now fits into a single microprocessor-based box that’s less than 6 inches tall. And now, that 6-inch-tall box serves not only as a protection system, but also as a SCADA interface, Phasor Measurement Unit (PMU), digital fault recorder, and human-machine interface (HMI).
As OT devices become more powerful, the consolidation trend will continue and (continuing our protection example) drive the combination of many panels, perhaps all of a single substation’s automation functions, into a single box. (Or maybe two or three boxes for redundancy purposes.) However, many who might design that sort of configuration are wary of combining so many functions into a monolithic piece of software. There are too many hidden interdependencies, and the risk of a single code modification affecting so many critical functions is too significant. Containers offer a way to allow for consolidation (and resulting economies of scale) to continue at the hardware layer while increasing the separation of functions to reduce the risks at the software layer. In the long run, this means OT operators will be able to implement greater functionality at a lower cost and the same or greater level of reliability.
Once functions are containerized, I can manage OT device functions individually and move to an operations model where choosing device functions becomes more like choosing apps on a smart phone. Furthermore, hardware platforms may become less specialized and the cost to implement OT functions may drop lower.
I expect containers will be a continuing theme on this blog. Stay tuned…