What Is the Distributed Control Node

Note: This is the third in a series of ARC Insights on Software for Open Process Automation.

The Distributed Control Node

The distributed control node (DCN) is the smallest, lowest level, and lowest cost component in the ExxonMobil Open Process Automation (OPA) vision.  A DCN combines the capabilities of today’s DCS I/O modules and controllers, but on a far smaller scale.  Some DCNs might be dedicated to controlling a single process loop, interfacing to just two to three process field devices and executing a very small number of control function blocks.  This report will not address DCN hardware, except to note the required physical interfaces. The major challenges for the development and success of DCNs lie in the software realm.

DCN Software Requirements

Developing DCN software will be challenging because a wide variety of software capabilities may be needed, even for otherwise identical DCN hardware.  Note that an open process automation system may include
anywhere from just a few to up to several thousand DCN modules. All
requirements must be manageable at that scale.  A brief discussion of the key functional requirements as envisioned by ARC Advisory Group
follows.

Field Device Interface and Management

The DCN needs to support field device I/O, device configuration, and device management of its connected process field devices. Field device management is a chronic pain point in process automation.  This is due primarily to the lack of multi-protocol network functionality (IP) in the existing process fieldbus technologies (HART, FOUNDATION fieldbus, Profibus).  At a minimum, the DCN should enable centralized device management applications to access its local field devices.  On the other hand, because the DCN has full-time fieldbus connectivity to a small set of devices, it is a natural candidate to perform continuous device monitoring and diagnostics.

Process Control

Process control functions, including complete process control loops, should be executable locally on the DCN to provide control at the point of field I/O.  The DCN can provide “single loop integrity” in the process control functions using local field device I/O that can continue to execute regardless of the state of the overall system. Another key requirement is that the DCN runtime software environment must support multiple vendors that may employ any number of control configuration software development tools and languages (MATLAB, IEC 61131 and IEC 61499 languages, programming/scripting languages such as C, C++, Python, Ruby, etc.).

Online Control Modification/Update

Today’s DCS controllers use proprietary methods to support online modification of an installed and operating control configuration. The DCN must support this capability, but in a much more standardized fashion. Likewise, as much as possible of the installed DCN software should be updatable while the process control functions operate.  Minimal interruption of the process control function and (especially) minimal disturbance to output signals that drive field actuators is of paramount importance so DCN transients do not disturb the process.

Industrial Network Protocols

For process industry applications, a relatively small number of protocols will cover most situations. To be truly useful, however, DCNs should have the flexibility to support any number of industrial protocols.  Implementation should be such that only the required protocols consume any DCN resources. Even the most common field device protocols (HART, FF-H1, Profibus, Modbus) and industrial network protocols (OPC UA, DDS, MQTT) will not all be used in any single DCN.

DCN Monitoring and Management

The DCN must be capable of monitoring and reporting its own status.

Other Applications

Any number of other applications could conceivably be performed in the DCN. These include applications like alarming, control loop performance monitoring, model predictive control, and local historical data storage.

DCN Software Deployment and Management

One of the key questions regarding DCN software is how to manage its deployment at scale.  Some form of DCN will assume the roles of today’s DCS I/O modules. So, there may well be hundreds or thousands of DCNs in a typical process unit, and tens to hundreds of thousands of DCNs in a large, multi-unit complex.

The Open Process Automation vision is for DCNs to be sourced from different suppliers, but easily interchangeable, so that older DCNs can easily be replaced with new ones.  However, the critical value is delivered by the DCN software, not just the hardware.  DCN software must support different processors, operating systems, software libraries, and applications, as well as different versions of each.  On top of this, the DCN applications need to be easily upgraded while remaining interoperable.  How will it be possible to achieve this?  How can thousands of such heterogeneous devices be managed reliably and economically? This management capability is absolutely necessary for open process automation systems to compete with today’s DCS.

The likely solution is that cloud computing software technology will propagate to the extreme edge of the automation space – including the DCN. Management of cloud computing resources, now a well-established though rapidly evolving discipline, involves a similar set of issues. However, to propagate into the automation space, these approaches would have to make management of a large and heterogeneous automation system simpler, more accessible, and more effective than possible with today’s more homogeneous (though proprietary) DCS software.

DCN Software as Container Applications

Using Linux containers to build and deploy microservice applications is now the hottest trend in cloud computing software. Containers evolved from older UNIX technologies for isolating applications and mapping resources to specific applications.  The emergence of powerful new open-source software tools and workflows for defining, deploying, and managing large numbers of container applications have made containers very popular in recent years. The primary software tool, Docker, also enables global collaboration and re-use through (public or private) repositories of reference Linux images. These can be easily re-used, augmented, or customized as needed in individual cases, then automatically deployed at any scale.  This capability greatly reduces the complexity of deploying container applications.

Today, Docker is already included in several Industrial IoT gateway products.  Docker has also been ported to very small, low-cost single-board computers.  These low-end devices have hardware resources (and price points) comparable to those envisioned for future DCN products.

Another interesting aspect of container-based applications is ability to update them online by switching between two versions of the same containerized application.  One firm has demonstrated a container application for controlling a drone that can be revised in a few milliseconds while the drone is flying.  The time required to cutover to the revised application is short enough that the flight of the drone is undisturbed. Indeed, even today’s container technology appears to have many capabilities that satisfy the DCN software requirements.

Both industrial automation and the Industrial IoT require widely distributed intelligence. This intelligence has often been provided by low-cost embedded systems.  Eventually, container technology may become a general solution to the vexing problems of deploying, maintaining, and upgrading software for these embedded systems, which must serve a long life delivering applications for connected assets. In addition, the application interface to the container engine may become a runtime software standard that is common across embedded systems, automation, and IIoT.  If so, the implications are huge.

Ongoing research and development for container technology has also expanded rapidly as containers become a commonplace cloud computing paradigm.  Developments in this area are occurring at internet speeds.  One R&D area that is promising for automation is management of application state information through application revisions and over a long lifecycle.

Recommendations

Recent advances in standardized container software technology come at a time when open process automation advocates badly need a single technology to manage the diverse DCN software lifecycle. This is a fortunate coincidence and leads ARC to make the following recommendations for OPA advocates in particular and the larger automation community in general:

• Open Process Automation advocates should compare the container software lifecycle with the OPA lifecycle processes they have already mapped out. ARC believes advocates should map the container development/deployment/maintenance work processes to the OPA requirements for software development, testing, deployment, operation, and maintenance.
• Consider the implications of the Linux Container engine as a common software runtime environment spanning industrial automation, IIoT, and embedded systems.
• Monitor future interactions of container software and embedded system technologies, especially embedded systems for connected assets.

If you would like to buy this report or obtain information about how to become a client, please  Contact Us

Keywords: Containers, DCN, Distributed Control Node, Docker, Embedded Systems, IIoT, Linux, Open Process Automation, ARC Advisory Group.