Automation Systems Made of Things

When General Electric publicized its vision for the business value of the Industrial Internet in this 2012 report, a key point was getting more value from assets that are “big things that spin”, such as GE’s canonical Industrial Internet target, aircraft engines. Being the OEM for these engines, GE had an advantage both in domain expertise and in access to the assets. It was, of course, GE that had designed the automation systems and data collection systems in these engines, so capturing engine data for analytics required only incremental equipment and effort.

Many big things that spin (and many more big things that don’t spin) are today controlled by distributed control system (DCS) products. DCS controls most processes where the control cycle is 100 milliseconds or more. This includes things like chemical plants, refineries, power plants, paper mills, breweries, and utilities. Today DCS system architecture is very hierarchical and thus defined physically more than logically (see figure).


Hierarchy of Process Control Systems (Source: ExxonMobil)

But during the last couple of years some major DCS end users (led by ExxonMobil) have basically declared war on this DCS architecture, for business reasons. Instead, they have envisioned an automation architecture that closely mirrors many IIoT reference models (for more details see this ARC report).

The key difference is that the new systems will consist of 1-2 small on-premise clouds and hundred or thousands of networked intelligent embedded systems. These thousands of systems will replace the sensor I/O cards that now dominate the DCS hardware. But these new systems will not be deployed in hierarchical networks but instead in very flat ones. The edge device functions will be highly programmable and manageable.

The important characteristics of these systems will be the smaller modularity of the smart devices (“things”) and their flatter networks. In this kind of automation system, access to the full portfolio of sensor data will no longer be the privilege of the OEM. Rather, this kind of automation system will serve many different IoT applications, while still meeting the specific requirements of each app.

To deploy this kind of system and for all kinds of IIoT applications to access the edge devices, these systems will require much more manageable networks. But networks will not be a problem, IMHO. The real bottleneck in adoption will be the slow rate at which these systems are refreshed, typically 15-20 years today. What could make the uptake happen faster? Simply a convincing demonstration of business value. That business value will derive from a number of improvements. Here are several that are top-of-mind:

  1. Vastly better system monitoring/management/diagnostics as the new systems fully adopt IT management technologies
  2. Corporate-level curation and management of embedded automation system intellectual property (this IP is critical for operational excellence, but is it now managed haphazardly).
  3. Far more secure OT systems requiring much less effort to keep secure.
  4. Finally (and this is probably the biggest value) the operational asset performance and safety improvements that result from 1-3 above.

ARC Advisory Group is now joining an effort to develop detailed reference architectures for this kind of process automation system, and we are excited at the prospects.


  1. I personally agree apps need access to sensor data. Already today a DCS serves as the connection point for many sensors which are not used for control nor for display to the operators. These sensors are connected to the DCS because they use 4-20 mA and only the DCS accepts this old analog signal. Apps get their data through the historian which gets the data from the DCS. Many such plants are modernized with digital wireless sensors to add more sensors without 4-20 mA. The wireless sensor network is often connected directly to the historian since digital wireless does not need analog input cards. It appears ExxonMobil envisions a real-time service bus based on an open protocol like FF-HSE. Sensors for reliability and energy efficiency applications could be added to existing fieldbus networks and be access directly (read-only) by apps on-prem and IIoT.