DDS

DDS (Data Distribution Service Standard) is a set of standards managed by the Object Management Group (OMG) that define a data bus. A data bus is a data-centric information flow control. The concept is similar to a database, which is a data-centric information store. The main difference, however, is that a database searches for old information by relating the properties of the stored data to each other. A data bus, on the other hand, finds future information by filtering the properties of incoming data. Both - database and data bus - understand the content and allow applications to act directly with and through the data instead of with each other. Applications that use a database or a data bus have no direct relationship with other applications.

The data bus uses knowledge of the structure, content and requirements of the data to manage the data flow. For example, it can resolve redundancy to support multiple sources, data sinks and networks. It can also control Quality of Service (QoS), such as update rate, reliability and guaranteed notification of data liveness. It can read the data in the updates and optimize their sending, or decide not to send them. It also dynamically recognizes and saves data flows. All these points define the interaction between software modules. The data-centric paradigm therefore enables simple software integration.

The following five questions help in deciding whether DDS is suitable for an application. If three questions are answered with 'yes', the use of DDS makes sense.

1. Is it a major problem if my system goes down for a short time?
2. Are milliseconds important in my communication?
3. Do I employ different software development teams or more than ten software developers?
4. Am I sending data to many places instead of just one, like a cloud or database?
5. Am I implementing a new IIoT architecture?

OPC UA

OPC UA (Open Platform Communications Unified Architecture) is a standard managed by the OPC Foundation, which is also documented as IEC 62541 and is aimed at device interoperability. Instead of accessing devices directly via proprietary application programming interfaces (APIs), OPC UA defines standard APIs that allow the device type or manufacturer to be changed. In this way, higher level applications, such as Human Machine Interfaces (HMI), can also find, connect to and control the various devices in factories.

OPC UA divides system software into clients and servers. The servers are usually located on a device or a higher-level programmable logic controller (PLC). They provide a way to access the device via a standard 'device model'. These are available for dozens of device types, from sensors to feedback controllers. Each manufacturer is responsible for providing the server that maps the generic device model to the specific device. Thus, the servers provide a standardized object-oriented, remotely callable API that implements the device model.

Clients can use the generic device model to establish a connection to a device and call functions. This means that the client software is independent of the actual device internals and factory integrators can change manufacturers or models as required. OPC UA can therefore build and manage a system of interchangeable parts, similar to how standardized printer drivers enable the integration of PC systems. It is important to note that the device model also provides a level of 'semantic' interoperability as it defines the generic object APIs in known units and specified reference points.

A decision in favor of OPC UA can be made based on the following questions:

1. Am I working in discrete manufacturing?
2. Am I connected to the Industry 4.0 platform program?
3. Am I building a device that will be integrated by control or process engineers or technicians and not by software developers?
4. Will my product be used in different applications in different systems, as opposed to one system (type) where you control the architecture?
5. Am I building devices for a 'work cell'?

oneM2M

oneM2M offers a common service layer that lies between the applications and the connectivity transport layer. The focus here is on the provision of shared services based on various connectivity standards.

The following questions will help you decide whether to use oneM2M:

1. Do I know what 'ICT' stands for and does it describe my work? Information and communication technology (ICT) is the most important target sector for oneM2M.
2. Is the mobile network my primary connection technology?
3. Are my target applications largely made up of moving components?
4. Do the components of the system tolerate intermittent connections and loosely controlled latencies?
5. Will the system utilize the services of a communications provider - a telecommunications provider?

These questions differ in character from the questions about the previous technologies. oneM2M results from the cooperation of many mobile network providers. It targets the networks of mobile devices that communicate largely or only via the base station infrastructure.

RESTful HTTP

REST (Representational State Transfer) via HTTP is the most common interface between consumer applications and web services. It represents an architectural pattern for accessing and modifying an object or resource. A server usually controls the object, others request a 'representation' and can then send requests to create, modify or delete the object.

To see if RESTful HTTP fits an application, these questions are helpful:

1. Am I connecting independent devices to a single web service API?
2. Am I building an HMI interface to an IoT device or service?
3. Does my application only need to be fast enough for human interaction?
4. Does my data flow need to cross firewalls that I don't control?
5. Is there no communication between the different devices?

A comparison of the technologies

If you compare these technologies with each other, major differences become apparent and it is clear that the connectivity approaches do not overlap.

For example, OPC UA is object-oriented (OO), while DDS is data-centric. These are diametrical opposites. Object-oriented here means "encapsulating data and exposing methods". Data-centric is all about data disclosure and there are no user-defined methods. The only methods are defined by the standard.

OPC UA is aimed at final device-centric integration by plant designers. It offers simple interoperability between devices from different manufacturers. In contrast, DDS is aimed at final data-centric software integration by software teams. When intelligent software becomes important, DDS provides the interface control of data abstraction and data flow required by software teams.

oneM2M and RESTful HTTP are aimed at connecting edge and cloud services. In contrast to DDS or OPC UA, both are rarely used for communication between devices. They are aimed at completely different areas. oneM2M offers common services for the integration of mobile devices. None of the other technologies focus on this application.

Based on these differences, it is clear that these technologies do not compete with each other in practice. Nevertheless, the 'confusion' caused by competition is great. Different providers and standardization organizations often use similar words for very different concepts in their positioning. Common terms such as 'publish subscribe' therefore conceal major differences in terms of information types, recognition, data selection and QoS control. 'Real-time' without specifying a time period in milliseconds or minutes is meaningless. And the Internet of 'things' leaves the user with a huge choice of 'things'. You should not be restricted by a prescribed fieldbus, a protocol to be used or similar. Openness, future-proofing, safety and security aspects should ultimately be the deciding factors.

Authors:
Dr. Stan Schneider is CEO of Real-Time Innovations;
Reiner Duwe is Sales Manager EMEA at RTI.