Smart factories in the age of autonomy and Industry 4.0 require more than just the integration of data between industrial controllers, histories and HMIs. The increasing complexity of automation and the number of connected things is also driving the need for scalable, fast, reliable and interoperable communication. Equally important is the need to integrate innovative software technologies such as artificial intelligence (AI) closer to the edge to take advantage of real-time insights.

Modern protocols such as MQTT and OPC UA Pub/Sub are now popular technologies that bring new applications closer to the edge. They have been developed or retrofitted as lightweight publish/subscribe messaging transports. They are also ideal for connecting remote devices to edge applications or quickly integrating devices into a centralized cloud infrastructure.

But these types of centralized solutions don't really bring things closer to the edge, don't provide real-time capabilities, and aren't a good solution for convergence. What is needed is a holistic approach that handles both the lower layer networks and the upper cloud layer connections in an interoperable way and treats data as an equal part of the architecture.

Data centricity and convergence

Drastically transforming an industry requires a different perspective and should be reflected in the process of rethinking the entire software architecture of a system. The challenge of transforming raw data into actionable information is not solved by increasing connectivity and moving applications closer to the edge.

First, raw data consists of individual facts that lack context, have no meaning and are difficult to understand. Data in context consists of individual facts that are meaningful. Information is best described as a set of data in context with relevance to one or more issues at a specific point in time or for a specific time period - therefore it needs both relevance and a time frame.

Secondly, data is not a commodity but an asset. To understand this, a data valuation methodology is required. System architects today believe that the most powerful method for data assessment is an approach called data-centricity.

Data-centricity is an architectural pattern in which data is the primary and permanent asset as applications come and go. In a data-centric architecture, standardized data models are used to describe a system in terms of the information exchanged rather than devices or applications. Data models provide schemas (what information flows and how it relates to each other) and a control model (how and when it flows).

Finally, the types of data being generated today have evolved from simple time series data - timestamp, key, value - to advanced sensor data, real-time video streams, LIDAR and real-time GPS location data, to name a few. Managing these complex data sets requires a converged infrastructure solution that provides real-time capabilities and simplifies the management of data flow within a data-centric connectivity infrastructure.

TSN brings convergence to the architecture

Ethernet (standardized under IEEE 802.3) is one of the original network technologies. Due to its ease of implementation and its ability to evolve without losing backward compatibility, it has become the de facto standard in IT networking. Although it has been around for almost half a century, it is only in the last decade that Ethernet has begun to be integrated into OT (Operational Technology) solutions.
Industrial applications usually have strict timing and deterministic requirements. By definition, Ethernet does not guarantee deterministic message transmission or real-time behavior. However, its extremely high performance makes it suitable for most such applications, provided there is a way to manage the network traffic.

Two factors that have slowed the adoption of Ethernet in industry are jitter, the variation in delay between incoming packets, and latency, the time it takes for a packet to reach its destination. The original Ethernet specification lacked determinism. It was therefore long thought that the protocol could not be used reliably in many machine applications because it was feared that this lack of determinism could lead to poor quality or even machine damage.

Time-Sensitive Networking (TSN) solves the problem of standardized real-time communication on the basis of standard communication hardware. It is an extension of standard Ethernet that regulates data communication in Layer 2(Table 1).

It is important to remember that TSN is only a "channel" to get data from one place to another in a deterministic way. It does not address higher level application functions such as security or motion control. The real value of TSN for OT lies in the ability to virtualize industrial networks, just as many companies have consolidated their server infrastructure in the cloud. Sharing the same network hardware across different types of traffic is the foundation for convergence.

DDS brings data-centricity to the architecture

The Data Distribution Service (DDS) standard from the Object Management Group (OMG) is a platform-independent software framework for the development and implementation of data-centric software solutions. A DDS data model, or a relational concept such as a database table, provides a schema, while DDS Quality of Service (QoS) offers precise control over data rates, deadlines and other data flow parameters. By defining a common, secure "global data space", DDS provides a "single source of information" that enables the highest degree of cohesion (how related the functions within a single module are) while guaranteeing loose coupling (the dependencies between modules).
Distributed systems express coupling in four dimensions:

• Time - No dependency on start or join order. Participants can come and go; adding or removing applications or flow paths has no impact on others.
• Space - Data can originate from any physical location and from any type of producer. Producers and consumers can be in devices or applications in any location. In a larger system, applications can operate transparently at the edge, in the fog or in the cloud.
• Flow - Data flow rates or reliability requirements between endpoints do not interact. Each application can request data at different refresh rates, over any network, with or without reliability guarantees.
• Type - Automatically converts different types for a flow when they "match", allowing systems to evolve over time.

DDS gives the impression that all data in the system is local. Applications read and write to a global data space that looks like local storage, and the data-centric DDS middleware ensures that it contains the right data. Unlike OPC UA, OPC UA Pub/Sub and MQTT, there are no clients, servers or brokers. The global data space is located between each participant and provides secure, deterministic access to information without close links.

Quality of Service

The most important capability of DDS is Quality of Service (QoS). DDS allows each application to request 21 different parameters, such as deadlines, latency budgets, update frequency, history, liveliness detection, reliability, ordering, filtering and more. With these QoS parameters, system designers can create a distributed application based on the requirements for and availability of specific data. Examples include:

• Durability - allows stragglers to receive data that was produced before they started.
• Deadline and separation - setting minimum and maximum data refresh rates for each participant.
• Liveliness - ensures that each data flow is healthy.
• Latency Budget, Transport Priority & Reliability - decoupling the data flow on a per-stream basis.

Data Distribution Service via TSN