In the last 20 years, CPUs and networks improved by a factor of 10,000X. According to Moores Law, in the next 20 years, they will improve by another factor of 10,000X. During the 40-year design lifecycle of todays industrial automation (IA) architectures, computers will be a mind-boggling 100,000,000X more powerful. Its hard to overstate the implications.

Using such power will determine which companies, industries, and even economies win or lose. For todays designers of tomorrows long-lifetime systems, enabling intelligent software is the only significant factor.

In fact, this is already happening. In industry after industry, software is becoming the most valuable part of every system. IA has been an exception to this rule. Nonetheless, like autonomous cars and intelligent medical systems, IA can use sensor fusion, fast distributed reactions, and artificial intelligence (AI) to replace rigid or manual processes with smart autonomy.

Developing architectures seek to solve the problems of the last 20 years, such as reconfiguring workcells, small lot sizes, flexible automation, and vendor interoperability. These will be far more easily solved with flexible software than rigid specifications. The future belongs to software.

The Harsh Truth

Todays discrete automation systems use a simple hardware-focused 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 historians. Factory-floor software reads sensors, executes logic, and drives actuators, thereby implementing a repetitive operation in a workcell. The factory consists of a series of these workcells, each with a few dozen devices.

Workcells arent so much programmed as they are configured. Manufacturing engineers or technicians use a palette of devices to implement a function in the cell. The goal of this design is to make it easy to assemble workcells of devices with little software effort. Unfortunately, the goal of minimizing software in plants precludes using advanced computing and intelligent systems. As eloquently put by one industry leader:

One of the harsh truths about manufacturing software is that it is not developed by software engineers or computer science majors. We would not regularly ask an electrical engineer to design a mechanical system, or a chemical engineer to design an electrical system, but we often ask mechanical, electrical, and chemical engineers to design and develop software systems.Brand, Dennis L. (2012-11-13T22:58:59). Plant IT: Integrating Information Technology into Automated Manufacturing. Momentum Press.

Brandls harsh truth simply cant continue. Superior custom software will take its place above reliability, performance, and interoperability as the key to competition. That means industrial companies will need to write their own code with competitive, professional software teams. You cant win a software war with someone elses software.

How can we enable this future? First, we need to understand the available industrial architectural frameworks. Then, we can put them together to enable software-driven IA.

What are OPC UA and DDS?

The top industrial architectural frameworks are the OPC Unified Architecture (OPC UA, managed by the OPC Foundation), and the Data Distribution Service (DDS, managed by the Object Management Group). Both have widespread adoption in industrial systems, although not in the same use cases (Fig. 1). DDS finds traction in applications in medical systems, transportation, autonomous vehicles, defense, power control, robotics, and oil and gas. OPC UA is also used in many of these industries, but not in the applications. Rather, OPC UA is mostly employed in discrete automation and manufacturing. In practice, theres almost no overlap in use cases.

1. OPC UA integrates software supplied from external sources, like devices with embedded software, HMIs, and historians. It focuses on vendor interoperability by specifying standard interfaces as companion specifications. Theres no facility for custom-written software, so most systems have little to no end-user software. By contrast, DDS provides a common data modelthe key requirement for writing distributed software. It therefore supports teams of programmers building large distributed systems with extensive custom functionality. Unlike OPC UA, there are few sources of supplier software.

DDS supports publish subscribe, as does the new specification for OPC UA PubSub. But OPC UA does notand will neverdo what DDS does. DDS is fundamentally a software-development architecture; OPC UA is not. Thus, the question isnt about choosing DDS or OPC UA. The question is understanding what they do and deciding which one is needed for your design, or if you need both.

That of course leaves the question: Why are they so different?

DDS evolved as a software-development framework for control systems. The first DDS applications were feedback-control systems for intelligent distributed robotics communicating over Ethernet. They used extensive custom software written by computer scientists. Almost all DDS applications integrate an AI component or very smart algorithms. DDS directly targets software teams building intelligent distributed machines.

By contrast, OPC UA grew up in the plant environment where, as Brandl points out, software engineers are rare. Its prime goal was to help PLC-centric workcell designs select different vendor hardware without writing software. The workcells endlessly repeat an operation, but theyre not truly smart. OPC UA seeks to minimize, rather than enable, software development.

We must differentiate integrating existing software components from writing new software. OPC UA supports software integration of modules like HMIs and historians. However, it offers no facility for composing intelligent software modules. Its not a software-development architecture for distributed applications.

What Does OPC UA PubSub Do?

OPC UA PubSub is a simple way to send information from a publisher to many subscribers. A publisher collects a DataSet at regular intervals and writes it to its subscribers. A DataSet is pulled out of the OPC UA information model, essentially a list of key-value pairs. On the other end, the Subscriber unpacks it and pushes it into the UA information model. Theres also support for simple structured data types.

Most users plan to use OPC UA PubSub with the UDP transport. It has some simple options. It can chunk data thats too big to fit into a network packet (usually only about 1.5 kB). It can resend every message a fixed number of times in hopes of better reliability. But it doesnt guarantee reliability by detecting and retransmitting lost messages. And, it rigidly locks execution; every subscriber must get the same data in the same format. OPC UA PubSub also supports other non-real-time messaging middleware options, MQTT and AMQP.

Fundamentally, OPC UA PubSub offers a simple mechanism to connect variables on a set of tightly coupled devices. Every device gets the same data at the same rates at the same time. With the right companion specifications, it can ensure device interoperability. UA PubSub is very new; there are few deployed applications.

What Does DDS Do?

Unlike OPC UA, DDS supports modular software-defined systems with a simple concept: a shared global data space. This simply means that all data appears as if it lives right inside every device and algorithm in local memory. It is, of course, an illusion; all data cant be everywhere. DDS works by keeping track of which application needs what data, knowing when it needs that data, and then delivering it. So, the data actually required by any application is present in local memory on time. Applications talk only to the local data space, not to each other.

This is the essence of data centricity: Instant local access to all data by every device and every algorithm, at every level, in the same way, at any time. Its best to think of it as a distributed shared memory, similar to a distributed control system (DCS) sandbox RAM, implemented virtually.

Each DDS module specifies the schema (types) it can exchange in memory. DDS controls the flow into and out from this structured memory with QoS parameters that specify rate of flow of data, latencies, and reliability. There are no servers or objects or special locations. Since DDS applications interact only with the shared distributed memory, theyre independent of how other applications are written, where they live, or when they execute. Its a simple, naturally parallel software architecture across the entire system.

DDS implements a long list of features to support software-driven distributed control, including:

Some Key Differences

OPC UA PubSub provides none of the data-centric features that are the core of DDS. Lets look deeper.

Interoperability

OPC UA enables device interoperability through device models and companion specs for hundreds of situations. OPC UA devices crowd tradeshows, pinned to the wall as evidence of interoperability. The consistent message: Factory engineers and technicians can combine devices into workcells with OPC UA without writing code.

In contrast, no devices today come with DDS pre-installed. Thats because DDS doesnt integrate devices per se. Instead, DDS integrates software modules. To add devices to a system, DDS users model devices as software.

Instead of specifications for every permutation, DDS integrates everything through a system data model. It maps device functions from a vendors native API to the system data model. DDS vendors offer very sophisticated bridging and data routing technologies. Thus, the popular layered databus architecture allows systems to grow by connecting data models between layers (Fig. 2). This also means that a DDS system can connect to devices despite different interfaces, to web technologies, and even to OPC UA.

2. Autonomous vehicles are revolutionizing the automotive industry. With a data-centric approach, DDS handles both on-vehicle and control-room use cases. Data routing provides a consistent data model throughout the system, thus building a reliable, large-scale infrastructure. To adopt software drive, the IA industry needs a similar system approach.

Coupling

Coupling is a measure of interdependencies between software and system components. Coupling can be obvious, like coupling clients to servers. It can also be subtle, such as when software modules must start in a particular order or execute at the same rate.

The DDS data-centric design makes it seem like all data is local, so the application isnt coupled to any other application. DDS controls interactions with the data through 21 different QoS policies, including deadlines, latency budgets, update frequencies, history, liveliness detection, reliability, durability, ownership, ordering, and filtering. It also converts types that evolve, as long as they are still close enough to be compatible.

DDS runs on hundreds of platforms and over dozens of networks transparently. Theres no dependence on language, operating system, chip architecture, or type of network used. Thus, data-centric applications work in parallel and share data transparently without interference. Coupling is only by design.

By contrast, OPC UA applications talk directly to each other. For instance, in PubSub, every subscriber gets exactly the same data from the publisher at the same rate. Each subscriber gets all of the dataflow, so the whole system also relies on having similar connecting network properties and processor speeds/loads everywhere. All subscribers must have the same understanding of the data being sent; therefore, versions must exactly match. Each added participant adds a dependency, directly coupling the system.

Fundamentally, decoupling helps applications and devices work independently. With a few subscribers in a workcell, coupling may not matter. Coupling can be good, for instance, for synchronous feedback control with minimal delay. In larger systems, coupling is bad; loosely coupled systems are easier to scale, test, build with distributed teams, deploy, understand, and maintain. Each source of coupling is a real problem, and combining many sources is debilitating. Good software architecture should avoid coupling unless absolutely required to affect the application.

Discovery

DDS automatically discovers named topics across the system regardless of where the application lives. Applications dont have to do anything or have any knowledge to find the data they need.

OPC UA doesnt support discovery in this sense. Subscribers query a server to get a configuration that includes the publisher of the data they require. They can also introspect a publisher to see what it can publish. Both are active queries; OPC UA doesnt perform system-wide automatic discovery.

Security

OPC UA and DDS use fundamentally different approaches to security. OPC UA secures the underlying transports. The various pubsub middleware options and client-server require different security implementations (and often, certificates). Its possible to set up connections between OPC UA clients and services securely, but theres no generic way to indicate which data is allowed to flow to which client.

DDS also can secure the underlying transports, but the primary approach instead provides overall dataflow security regardless of transport. DDS is fundamentally a flow-control technology. So, with a signed permissions document that describes allowed read and write access, DDS can secure and control the dataflow itself (Fig. 3). This requires no code; security can be added after the entire system is running.

3. Most security schemes secure the system edge, host, or network. These are important, but they dont match the application. DDS security adds the ability to control the dataflow itself, creating a system-wide layer that depends on the application rather than implementation like network, operating system, or device location. It also allows for directional security (e.g., read but not write).

Scaling

DDS supports domains that separate systems, partitions within a system, and transparent routing between subsystems and networks. With transparent routing, the data sources can be very far away. DDS systems can grow to hundreds of thousands of applications. Top to bottom, across subnets, or with any pattern (pubsub, request-reply, or queuing), DDS offers a unified data model, a single security model, and consistent access to data.

Since there are few deployments, scalability for OPC UA PubSub has yet to be demonstrated. However, OPC UA PubSub over UDP isnt designed for more than a few devices on a single network. With MQTT or AMQP, a publisher can talk to a cloud server, but not to other OPC UA PubSub subscribers. OPC UA client-server is designed to roll up workcells into a larger factory. So, OPC UA doesnt offer unified system data access in the same way as that of DDS.

Filtering

OPC UA subscribers can select a DataSet with a filter, but only to ensure reception of the correct data. They can also limit access to a single publisher.

DDS has extensive filtering. QoS matching enables subscribers to receive information only from capable sources. The time-based filter decouples the speed of producers from that of the users of information. Content filtering analyzes the content and delivers only data that fits the specification. Together, these filters ensure delivery of the right data to the right place at the right time with minimal wasted bandwidth.

Use of TSN

TSN, or Time Synchronous Networking (IEEE 802.1), is a developing set of standards that build on the existing Ethernet design to deliver data in bounded time, aka isochronous networking.

With TSN, OPC UA PubSub can deliver better real-time performance. TSN can be reliable, so the lack of reliability in OPC UA over UDP isnt as critical. However, since TSN is a flavor of Ethernet and requires central configuration, its limited to smaller, single-subnet systems.

DDS was initially developed for real-time control over a network. QoS settings can optimize use of the underlying network, supporting everything from slow, lossy networks like satellite links to isochronous transports like backplane buses and switched fabrics. On capable hardware, it offers predictable and fault-tolerant one-to-many delivery with bounded latencies.

Combining DDS with TSN allows more distributed determinism. A DDS over TSN system can combine high-level data access with true real-time performance. The OMG has an active standard in progress for DDS over TSN scheduled for release in Q4 2020.

When Should We Combine Capabilities?

OPC UAs main use case is to help manufacturing engineers build workcells without writing software. Its used in manufacturing things, but not as software inside the things being manufactured. In stark contrast, DDS users are software engineers building applications that go into things; DDS is only used to operate things. Thus, UA is about making things. DDS is about making things work.

Theres overlap coming in terms of things that make things, aka smart manufacturing systems. These will soon need sophisticated system software and custom programming.

The OMG recently passed a standard for an OPC UA/DDS gateway (Fig. 4). At its most basic level, this gateway takes the OPC UA information model and makes it available within the DDS global data space. The primary use case is to convert OPC UA-enabled devices to DDS devices. OPC UA devices can simply join the DDS network.

4. The DDS-OPCUA gateway standard connects an OPC UA system to the DDS global data space (A). Conceptually, it makes the OPC UA system data seem available to DDS software applications. The primary use case for the gateway is to enable devices that support OPC UA to participate in a DDS domain (B). Note that this allows intelligent software applications to access any OPC UA device. Together, these standards can provide attractive software development and easily integrated devices (C). It lets AI work at every system level.

In a large intelligent system, the DDS-based software environment can thus coordinate and work with the OPC UA devices. This allows for both sophisticated software and interoperable devices.

Note that this design offers many opportunities to leverage AI and intelligent software. At high levels, DDS interfaces to cloud-based intelligence. Future generations of this design can also implement AIs or smart algorithms for device interoperability

The Smart Machine Future

Historians will look back on our time and wonder how we got by without smart machines. The transition will not be smoothproduct lines, companies, and entire national economies are at stake. Brandls harsh truth may be the most dangerous paragraph in automation. That truth will not survive the smart machine era.

So, software excellence must join the manufacturing technology mix. In the next 20 years, manufacturing system performance will not improve by a factor of 10,000. Interoperability will not become 10,000X more valuable. But software will become 10,000X more important. Thats the inevitable result of exponential computing growth. Any architecture that doesn't target using compute power as its primary goal is already obsolete.

Does industrial automation need to adopt software development? Will future manufacturing systems compete primarily on unique user code? The software future says yes.

Stan Schneider, PhD., is CEO of Real-Time Innovations.

See the original post here:

Software Will Determine the Future of Industrial Automation - Electronic Design