As consumers, we are used to rapid advances in commercial software and hardware technology, to the point where constant innovation is expected and demanded. We want our new smartphone to be much better than our ancient model from two years back, and we expect our Gmail service to constantly improve, all with no effort on our part to download or learn how to use new software. We also expect and demand a better buying process, including free trials, immediate experiences, and on-demand purchases from online app stores and websites.

But when it comes to industrial automation hardware and software products, innovation seems to move at a snail’s pace. The old argument of waiting for years for new technologies to be proven in the commercial sector before trying them out in industrial automation applications carries less weight by the day.

Industry sectors with critical real-time control requirements, such as aerospace, automotive, and defense, are integrating commercial-off-the-shelf (COTS) technologies into their automation systems quickly—so why haven’t automation suppliers followed suit? Why do we read about autonomous cars, drones, and the big data technologies powering Google—and so little about similarly exciting innovations in the process industries?

ExxonMobil has been shifting away from proprietary, closed systems, and it is leading the charge to build the next-generation, multivendor automation system. ExxonMobil engaged Lockheed Martin to build a multivendor interoperable prototype that is a standards-based, open, and secure architecture, with commercially available software and hardware components. Lockheed Martin has deep experience with these types of systems from its other business and engineering activities. This decision, which made waves across the industry, can be seen as a harsh but honest indictment of the pace of change, interoperability, and innovation in process automation.

If ExxonMobil is demanding this type of automation system, can other major process industry end users be far behind? Don’t others also want truly open systems, along with the lower costs and other benefits they provide? Like ExxonMobil, don’t they realize that automation system innovations are essential to improving the bottom line? To see how this trend might play out, let’s look at the automation industry’s current status with respect to adopting COTS technologies.

COTS at server level

The picture is not all bleak, as one can see from looking at the advances made by using COTS technologies at the server level. Many remember when proprietary distributed control system (DCS) server hardware was used for human-machine interface (HMI), historian, and other functions. Costs were astronomical, and there was no interoperability with other server-level hardware or software, or with any controllers from other suppliers. If you bought a brand X DCS, you were locked into its architecture for decades, and you paid whatever price the company dictated if something failed or if you wanted to upgrade part of the system.

Although DCS suppliers have worked hard to maintain their proprietary architectures, frustrating major customers such as ExxonMobil, other automation industry suppliers eroded their position and grabbed market share by adapting COTS technologies, particularly PC-based servers.

PC-based HMI software with performance equaling or exceeding what is available from DCS suppliers is widely available and very popular throughout the industry. Modern PC-based historians are likewise available, as are other server-level software applications. And much of this software can run on platforms such as Linux, not just Windows, further increasing openness and driving down costs.

Many users have responded and created their own DCS-like automation systems by combining open software applications at the server level with controllers from other suppliers. The result is a lower-cost automation system, and one open enough to give the end user some leverage with suppliers.

If your HMI supplier is not measuring up, it is possible to switch to another without having to change any of the underlying hardware or any of the other software applications. The same goes for your historian supplier and for other server-level software suppliers.

COTS at specialized software level

Data analytics, advanced control, and other specialized automation applications interface closely with server-level platforms, but the degree of openness among these specialized applications varies greatly. Some are provided by DCS suppliers and thus work best, and sometimes only, with their own DCS automation platforms.

Other specialized automation suppliers have adopted a COTS approach wholeheartedly to create applications offering all the benefits end users have come to expect from their experiences with commercial hardware and software.

This is particularly true in the data analytics category. Tableau business intelligence software is an example, because its applications can connect to automation system data after the fact and do not affect real-time control. Data analytics is therefore an area where one should expect to see substantial innovation via adoption of a more consumer-like business model, as with this pattern search feature.

Software made available under this concept is freely available to anyone online, instead of only through designated supplier sales channels. The software must be easy to learn and use, because if it is not, the customer will simply try it and not buy it.

Automation suppliers are well known for opaque pricing, with many suppliers requiring extensive interaction with a salesperson to find out just what their products cost. This is in direct contrast to COTS software, where pricing is much more clearly stated with no interaction required to discern the bottom line.

Purchases carry much less risk, because the software is bought on a subscription basis, usually monthly or annually. Instead of buying “software for life” up front, one simply agrees on a subscription that can be cancelled at any time, like a music download service or Amazon Prime. And because the software is subscription based, innovation is constant and improvements are instantly made available to all customers via downloads, not just those with support contracts.

There is also a powerful incentive for suppliers to make continuous improvements to their software, because contracts can be readily cancelled if they do not. Instead of getting most of their money up front, suppliers have to earn it every day.

While commercial-off-the-shelf technologies have made significant inroads at the server and specialized software levels, this is much less so when it comes to controllers and I/O.

COTS at controller level

Of all the different levels of automation, controllers have been the slowest to adapt COTS technologies, and they are thus at the very center of the ExxonMobil initiative. DCS and programmable automation controller (PAC) vendors have insisted upon closed and proprietary controller and I/O system architectures, with consequently slow levels of innovation and high costs.

The same is true of the software used to program these controllers. Despite standards such as IEC 61131 for PLCs and organizations such as PLCopen, it remains virtually impossible to transfer a program written for one controller to another.

ExxonMobil and other end users would like to see an open architecture similar to COTS technologies where programming languages can be compiled and then downloaded and executed on any run-time platform. For example, a program written in C++ will run on any platform, but one written in ladder logic will only run on a single supplier’s controllers, and sometimes only on one controller from a supplier.

There are some exceptions to the closed controller and I/O system architectures found in process automation systems, and they are primarily found in machine automation. In this realm, particularly in the semiconductor industry, many machine-builder original equipment manufacturers “roll their own” open systems, often using PC-based or other industry standard control platforms.

These systems are programmed with COTS languages; execute on Windows Embedded, Linux, or other run-time platforms; and use Ethernet-based I/O. These open systems can use best-of-breed controllers and I/O, and give the purchaser the power to switch suppliers without redesigning the entire automation system. Ethernet I/O has forced open a crack in the controller-I/O link, and it is doing the same at the network level.

COTS at network and field device level

For this discussion, the network level is considered to be all of the networks used in an automation system, including those used to connect servers, controllers, I/O, and field devices. Open networks are now the norm at the server level as Ethernet has taken over for all server-level communications, just as it has in the commercial realm. Price/performance ratios and other innovations are thus increasing with great rapidity with no loss in reliability and with downward compatibility such that slower Ethernet hardware can coexist with newer and faster components on the same network.

Connections from servers to specialized software applications are all Ethernet based, as are links from servers to controllers. Controller-to-controller connections are Ethernet too, but at this level there are a plethora of incompatible protocols such as EtherNet/IP, Modbus TCP, and Profinet. Although multiple Ethernet protocols can run simultaneously on a single network, an EtherNet/IP device cannot talk to a controller supporting Modbus TCP.

Controller-to-I/O links are usually Ethernet based, although incompatible protocols are often used. Some CAN-based protocols are used for communications between controllers and I/O, with incompatibility among them, and of course with Ethernet.

For the networks used to connect controllers to field devices, communication systems are mostly closed, although suppliers represent them as open, because each “standard” is administered by an independent foundation instead of by the supplier. But from the end user’s point of view, many different and incompatible standards constitute closed systems. Ethernet is making some inroads in field device networking, but much remains to be done to create a truly open system.

Although field device networks are effectively closed due to the overabundance of standards, the field devices to which they connect are open because many support multiple networking standards. This of course drives up costs and is thus not an ideal or complete solution, but it often allows a field device from one supplier to work with a controller from another.

Increasing pace of change

The rate of adoption for COTS technologies in automation varies widely at different levels of automation systems, from very high at the server level to virtually nonexistent at the controller level. But, there is reason to expect the pace of change to increase. ExxonMobil is demanding change and putting its money where its mouth is. Other end users are watching, waiting, and hoping its efforts come to fruition, as the result will be more open and innovative automation systems.

A version of this article also was published at InTech magazine.