FEATURE EMBEDDED TECHNOLOGY
The Software-Defined Future of Industrial Automation (IA)
Stan Schneider, PhD. CEO, Real-Time Innovations (RTI) compares OPC UA and DDS, how they work, and where they fit
Instead of client and server objects,
DDS targets software-defined systems with “data centricity”. This simply means that all data appears “as if” it lives inside every device and algorithm in local memory. DDS works by keeping track of which application needs what data, knowing when it needs that data, and then delivering it so it is present in local memory on time. Applications talk only to the “local” data space, not to each other. DDS is like a distributed virtual shared
I
n the next 20 years, processors will improve by another factor of 10,000x.
Developing architectures seek to solve the problems of the last twenty years, such as reconfiguring workcells, small lot sizes, flexible automation, and vendor interoperability. But these will be far more easily solved with flexible, capable software than today’s device-centric integration. Software is also critical to enable use of this coming vast computing improvement. The future belongs to software. 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). DDS finds traction in applications in medical systems, transportation, autonomous vehicles, defence, 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 used in industrial automation and manufacturing. There is almost no overlap in use cases. DDS evolved for robotics and
distributed control with extensive custom software written by computer scientists.
10 DECEMBER/JANUARY 2021 | ELECTRONICS
DDS directly targets software teams building intelligent distributed machines. By contrast, OPC UA grew up in the
plant environment where software engineers are rare. Its prime goal was to support manufacturing engineers and technicians building workcells. OPC UA seeks to minimise, rather than to enable, software development. DDS supports publish subscribe, as does
the new specification for OPC UA “Pubsub”. But OPC UA does not - and will never - do what DDS does. DDS is fundamentally a distributed software development architecture; OPC UA is not. Thus, the question is not about choosing DDS or OPC UA. The question is understanding what they do and deciding which one your design needs, or if you need both.
KEY DIFFERENCES OPC UA is an object-oriented design; designs use server objects that offer data to clients. To get data, clients query servers. 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. OPC UA PubSub is very new; there are few deployed applications.
Figure 1:
OPC UA integrates software supplied from external sources and focuses on vendor interoperability. DDS provides a common data model for writing distributed software. It supports teams of programmers building large distributed systems with extensive custom functionality
memory. Data centricity provides “instant” local access to all data by every device and every algorithm, at every level, in the same way, at any time. There are no servers or objects or special locations. Since DDS applications interact only with the shared distributed memory, each is independent of how other applications work, where they live, or when they execute.
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. In contrast, no devices today come with
DDS pre-installed. That’s because DDS does not integrate devices per se; instead, DDS integrates software modules. To add devices to a system, DDS users model devices as software. DDS integrates everything through a
“system data model”. The popular “layered databus” architecture connects data models between layers. DDS systems can connect transparently to devices despite different interfaces, to web technologies, and even to OPC UA. Good software architecture avoids
extraneous coupling. Coupling can be obvious, like coupling clients to servers. It can also be subtle, such as when modules must start in order or execute at the same rate. Coupling can be good, for instance for synchronous feedback control with minimal delay. In larger systems, coupling is bad; loosely-coupled
/ ELECTRONICS
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46
