The future of IIoT software in manufacturing
The top Industrial Internet of Things (IIoT) connectivity framework standards are OPC Foundation’s OPC Unified Architecture (OPC UA) and Object Management Group’s (OMG’s) Data Distribution Service (DDS). Both are gaining widespread adoption in industrial systems, though not the same sectors.
Each differ from many of today’s discrete automation systems, which use a simple architecture. A programmable logic controller (PLC) connects devices over a fieldbus. The PLC controls the devices and manages upstream connections to higher-level software such as human-machine interfaces (HMIs) and data historians. Factory-floor software is straightforward. It reads sensors, executes logic, and drives actuators, thereby implementing a repetitive operation. The factory has a series of workcells, each with a few dozen devices.
Why designs are changing
The traditional PLC and HMI design served well for the last three decades. However, it may not survive the next one. Why? Processor speeds and easy interconnectivity offer more capable compute resources. The PLC-centric workcell design can build reliable systems that endlessly repeat an operation. They aren’t truly “smart,” though. They don’t adapt well to change. They can’t take advantage of the explosion in compute and networking capacity. In short, they don’t provide a path to intelligent, but more complex, software.
The IIoT has the potential to transform industrial systems. To do that, it must share data across the workcell, factory, and front office. Of course, it’s not that simple. Pervasive data use requires a new architecture and new approach to connectivity.
OPC UA and DDS solve entirely different problems. Hardware engineers use OPC UA because it makes device connections simple. System architects use DDS because it spans system layers with a consistent model. DDS and OPC UA are different, but it’s not a matter of choosing the right one; they do not compete.
In fact, there is growing appreciation for how they can work together to build a powerful industrial communication architecture in the future. The real challenge is deciding which problem needs to be solved. That makes it critical to understand what OPC UA and DDS can do. It’s important to identify when to use DDS alone, when to use OPC UA alone, and when to use a combination of both frameworks.
OPC UA and TSN connect
In the discrete manufacturing sector, OPC UA and time-sensitive networking (TSN) offer a potential path to resolving the “fieldbus wars.” OPC UA is useful for integrating dedicated devices, such as conveyor belts, sensors, repetitive robots, and drives into a workcell. It can connect workcells to software like HMIs and historians. It does this by modeling devices and allowing factory technicians and manufacturing engineers to coordinate these devices through a PLC controller (see Figure 1).
Workcells aren’t so much programmed as they are configured. Manufacturing engineers or technicians use a palette of devices to implement a function in the cell. The devices come with standard models so the factory isn’t locked to one vendor. OPC UA systems are compositions of devices and existing modules such as data historians and HMIs. This design makes it easy to assemble workcells of devices with little software effort.
OPC UA connects workcell data to systemwide data by changing the communication pattern from pubsub to client/server (request/reply). To receive data, an application or higher-level client has to discover and connect to the server. This architecture is not designed to enable programming teams. For instance, translating pubsub and client/server presents an inconsistent programming model across levels. And it doesn’t let teams pre-define new software interfaces or shared data types. Without these, OPC UA doesn’t provide one source of “system truth” for systemwide software.
OPC UA is optimal for integrating devices into a workcell, although OPC UA can frustrate teams trying to build complex system software.
DDS enables system software
DDS, on the other hand, targets teams building distributed software applications. The first DDS application was feedback control over Ethernet for intelligent robotics. DDS then spread into software-intensive distributed applications such as autonomous vehicles and Navy combat system management.
Its fundamental purpose is combining software applications into a complex system-of-systems with one consistent model. Most DDS systems combine “functional” artificial intelligence with 10 to 50 applications and devices, but some DDS systems are comprised of hundreds of thousands of devices and applications, which are written by thousands of programmers.
The key to understanding DDS is to realize that distributed systems are fundamentally parallel and the system architecture must match that reality. This isn’t new; the heart of a current distributed control system (DCS) is a control execution engine that manages timeslices and control loops. All data is stored in “sandbox RAM” so processes can access any data without unwanted interaction. The DCS provides an environment to combine function blocks into parallel, deterministic feedback loops in one box.
DDS takes that same concept and distributes it. DDS implements a data-centric shared “global data space.” This means all data appears as if it lives inside every device and algorithm. This is, of course, an illusion—all data can’t be everywhere. DDS works by keeping track of which application needs what data and when, and then delivers it. As a result, data an application actually needs is present in local memory on time.
The essence of data centricity is instant local access to anything by every device and every algorithm, at every level, in the same way, at any time. It’s best to think of it as a distributed shared memory, similar to the DCS sandbox RAM. There are no servers or objects or special locations. It’s a parallel software architecture across the system.
DDS is about data centricity, not patterns. While most standards use pubsub, the standard also specifies requests/replies and some vendors support queuing. Applications interact in many ways, but only with the shared distributed memory, not with each other directly. DDS also defines system interfaces (data types) and quality of service (QoS) flow control. It integrates modules with a transparent and consistent systemwide architecture that’s independent of patterns. This is the connectivity analog to data-centric system “truth” databases use to power the enterprise.
However, DDS doesn’t model devices. Factory engineers and technicians can’t combine devices into workcells without writing code.
Should you use OPC UA, or DDS, or both?
Manufacturing systems compete on the same basis they have for decades: reliability, production rates, or implementation cost. In the not-too-distant future, clever industrial software engineers may figure out how to apply artificial intelligence, distributed information control, or smart flexibility. Those applications require sophisticated software and a systemwide approach. If you believe software can be bought and remain competitive, you don’t have to change. If, on the other hand, you see a future where the best software wins, you will need a different path to keep up see Figure 3.
A system may also need to be built from interoperable devices. Fortunately, this doesn’t have to be an all-or-nothing decision; DDS, OPC UA, and TSN can work together. The Object Management Group (OMG), the parent organization for the Industrial Internet Consortium (IIC), recently approved a standard to integrate DDS with OPC UA. OMG and OPC Foundation are working on standards to use TSN with DDS and OPC UA. DDS vendors are working on easy configuration tools.
IIC developed an integrated architecture and has several testbeds using OPC UA in manufacturing applications and DDS in applications such as electric power and health care. Some use OPC UA and DDS like the IIC Security Claims Evaluation testbed and the IIC Smart Factory Machine Learning for Predictive Maintenance testbed. Combining the flexibility of interchangeable devices with a powerful software development environment is not that far off.
The real challenge is to fully understand how OPC UA and DDS work in advanced manufacturing environments. Many people have difficulty defining what these technologies do. To stay competitive in the future, it’s vital to research and ask questions to ensure the right platform, or the right combination, is chosen.
Stan Schneider, PhD, is vice chair of the Industrial Internet Consortium (IIC), a CFE Media content partner, and is CEO of Real-Time Innovations (RTI). Edited by Emily Guenther, associate content manager, Control Engineering, CFE Media, firstname.lastname@example.org.
KEYWORDS: Data Distribution Service (DDS), OPC Unified Architecture (UA)
When to use OPC UA and DDS frameworks
When to use a combination of both standard frameworks
Defining how DDS and OPC UA.
Consider this: What framework would be the best fit for your manufacturing operations?