OCTOBER 19, 2017
Software for Open Process Automation:
Software for the Distributed Control Node
By Harry Forbes
Keywords
Containers, DCN, Distributed Control Node, Docker, Embedded Systems,
IIoT, Linux, Open Process Automation
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
The DCN, or distributed control node, is
envisioned as a small, low-cost I/O and
process control component in open
process automation systems. Container
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
software technology will likely provide
note the required physical interfaces. The major
the required capabilities for the DCN.
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.
VISION, EXPERIENCE, ANSWERS FOR INDUSTRY
ARC Insights, Page 2
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.
DCNs in an Open Process Automation System
(Source: The Open Group and ARC)
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.).
©2017 • ARC • 3 Allied Drive • Dedham, MA 02026 USA • 781-471-1000 • ARCweb.com
ARC Insights, Page 3
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 differ-
©2017 • ARC • 3 Allied Drive • Dedham, MA 02026 USA • 781-471-1000 • ARCweb.com
ARC Insights, Page 4
ent 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.
Likely DCN Software Stack
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 re-
©2017 • ARC • 3 Allied Drive • Dedham, MA 02026 USA • 781-471-1000 • ARCweb.com
ARC Insights, Page 5
sources to specific applications. The emergence of powerful new opensource 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
The application interface to the Linux
container engine may eventually
become a standard software runtime
environment that is common across
embedded systems, industrial
automation, and IIoT. If so, the
implications for each field are huge.
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
©2017 • ARC • 3 Allied Drive • Dedham, MA 02026 USA • 781-471-1000 • ARCweb.com
ARC Insights, Page 6
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.
For further information or to provide feedback on this Insight, please contact your
account manager or the author at HForbes@arcweb.com. ARC Insights are published and copyrighted by ARC Advisory Group. The information is proprietary to
ARC and no part may be reproduced without prior permission from ARC.
©2017 • ARC • 3 Allied Drive • Dedham, MA 02026 USA • 781-471-1000 • ARCweb.com