CIE Components in Electronics
The Industrial Internet of Things (IIoT) will greatly change almost every industry at a rate faster than any previous disruption. Companies, and whole industries, must react quickly to capitalise on the new capabilities and avoid obsolescence. Dr. Stan Schneider, CEO, RTI, talks about how the IIC, Industry 4.0, DDS, and OPC UA are assembling the future
The Industrial Internet Consortium (IIC) and Industry 4.0 are the leading consortia in the IIoT. The IIC is building a technical architecture that spans industries and Industry 4.0 focuses on manufacturing, but goes beyond technical architecture into supply chain and product lifecycle. The goals and architectures are complementary, and the organisations are working together to map designs.
The Data Distribution Service (DDS) and Open Platform Communications Unified Architecture (OPC UA) are key connectivity technologies that underlie the IIC and Industry 4.0 designs. Like the consortia, these technologies are more complementary than competitive. The standards are working towards a future that will provide interoperability. In the meantime, projects must move forward. The guidance, developed jointly by the standards groups, is that DDS is for systems facing a primary software integration challenge, while OPC UA is for simpler software systems facing device interchangeability issues. While the distinction may sound confusing, it is not in practice. With knowledge of the primary problem, the best path is nearly always clear.
The IIC and Industry 4.0
In a sound bite, Industry 4.0 is about making things, while the IIC is about making things work. The IIC covers all sorts of industrial verticals whereas Industry 4.0 focuses on just manufacturing. The IIC is working mostly on IIoT technical system architecture. Industry 4.0 reaches much deeper. For instance, Industry 4.0 includes many aspects of manufacturing supply chains, product definitions, order processing, even recycling.
Interoperability for devices with OPC UA
OPC UA is a standard managed by the OPC Foundation. At its core, OPC UA targets device interoperability. Before OPC UA (or its predecessor OPC), applications simply accessed devices directly through proprietary APIs provided by their vendors. Unfortunately, this meant that applications became dependent on the particular device they controlled. Worse, higher level applications such as Human-Machine Interfaces (HMI) had no easy way to find, connect to, or control the various devices in factories.
OPC UA divides system software into clients and servers. The servers usually reside on a device; they provide a way to access the device through a standard “device model”. There are device models for dozens of types of devices from sensor to feedback controllers. Thus, with OPC UA, clients can connect to a device and call functions from the generic device model. Client software is independent of the actual device, and factory integrators are free to switch manufacturers or models as needed.
Recently, the OPC Foundation began work on a publish-subscribe interface. This works by allowing OPC UA clients to register interest in server data updates. The updates are then pushed proactively to clients. Several early adopters are sampling OPC UA compatible devices, including implementations of the pub-sub model.
DDS addresses real-time systems
The Data Distribution Service (DDS) is a standard managed by the Object Management Group (OMG). The OMG is the world’s largest system software standards organisation. The OMG also manages industry consortia such as the IIC. DDS directly addresses real-time systems. It features extensive fine control of real-time QoS parameters, including reliability, bandwidth control, delivery deadlines, liveliness status, resource limits, and (new) security. It explicitly manages the communications “data model”, or types used to communicate between endpoints. It is thus a “data-centric” technology. Like a database, which provides data-centric storage, DDS understands the contents of the information it manages. DDS is all about the data. This data-centric nature, analogous to a database, justifies the term “databus”.
The databus replaces the application-application interaction with application-data-application interaction. This abstraction is the crux of data centricity. Data centricity greatly eases scaling, interoperability, and system integration. The DDS databus goes well beyond pub-sub. Most pub-sub is very primitive. An application “registers interest”, and then everything is simply sent to that application. There’s no control of flow.
A databus is much more expressive. For instance, an intersection could say, “I am interested only in vehicle positions within 200m, moving at 10m/s towards me. If a vehicle comes into my range, I need to be updated 200 times a second; no slower or faster. I also need to know that you actually are in touch with currently-live sensors on all possible roadway approaches at all times.” The DDS databus technology ensures ultra-reliable operation and simplifies application code. It does not require servers, greatly easing configuration and operations while eliminating failure and choke points.
Working together: DDS and OPC UA
The DDS and OPC UA communities are working together to help developers combine the benefits of the technologies. The most developed effort will allow DDS and OPC UA systems to interact through bridges. The IIC’s Industrial Reference Architecture develops the concept of “Core Connectivity Standards”. A core standard must provide syntactic interoperability, have standards-defined gateways to all other core connectivity standards and be stable and proven across multiple industries.
The bridge technology will let you take data from an OPC UA server and publish it over DDS. Or, you can take data from DDS and use it to update a variable on a device that hosts an OPC UA server. So, a DDS software system can “peek and poke” data in a device.
Choosing a path
DDS is a data-centric approach to software systems integration. Software teams use DDS to write software modules that interact through a data model. This is perfect for systems facing a primary software integration challenge.
OPC UA, by contrast, is an object-oriented technology for device interoperability. The main goal is to decouple applications from device details, rather than providing large system integration architecture. Workcell integrators use OPC UA to write programs through a device model. Let’s look at common perspectives of the different decision makers:
Device manufacturers have the goal of making devices that will sell into many applications. The device offers services, such as configure, start, stop, etc. They have no idea how the device will eventually be used. Their users are likely not software types; they just want to add or integrate the device into a simple system by configuring it. They may write some device software, or perhaps just configure their device with a graphical workcell tool. Those clients need OPC UA. OPC UA will allow the device users to write generic software that will work with their competitor’s devices. They would not know where to begin to configure a DDS data model with system Types, Topics, and QoS.
Software architects are building a system or product line, and control the architecture of that system. They critically need to integrate components written by different programmers or even entire teams. So they need DDS. It will define the interfaces, capture the dataflow, enable module evolution, and enforce interoperation between teams. If their system needs redundancy for reliability, or fast complex connections, or selective data filtering, then they really need DDS. OPC UA won’t help to capture their shared information model.
These are the extremes. But nonetheless, most applications fall clearly on one side or the other. The challenge comes tomorrow. The future will require devices to be parts of large distributed, intelligent systems. So, these perspectives will have to coexist someday. Fortunately, whichever path you choose, the standards communities are committed to merging the paths in the future. Thus, the investment should be preserved.
