Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

DDS and OPC-UA Explained

5,979 views

Published on

The Object Management Group (OMG) Data Distribution Service (DDS) and the OPC Foundation Open Platform Communications - Unified Architecture (OPC-UA) are commonly considered as two of the most relevant technologies for data and information management in the Industrial Internet of Things (IIoT). Although several articles and quotes about the two technologies have appeared recently in the media, there is still incredible confusion on how the two technologies compare and what their applicability really is.

This presentation, was motivated by the presenter's frustration caused by reading and hearing so many misconceptions as well as "apple-to-oranges" comparisons of the two technologies. Thus to contribute to clarity and help with positioning and applicability this presentation will (1) explain the key concepts behind DDS and OPC-UA and relate them to the reasons why these technologies were created in the first place, (2) clarify the differences and applicability in IIoT for DDS and OPC-UA, and (3) report on the ongoing standardization activities that are looking at DDS / OPC-UA inter-working.

Published in: Technology
  • My colleagues were requiring GA DDS DDS-18 several days ago and were made aware of an online service with lots of sample forms . If you require GA DDS DDS-18 too , here's http://pdf.ac/4Xe9mq
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

DDS and OPC-UA Explained

  1. 1. CopyrightPrismTech,2016 Angelo Corsaro, PhD CTO, ADLINK Tech. Inc. Co-Chair, OMG DDS-SIG angelo.corsaro@adlinktech.com DDS & OPC-UA .Explained
  2. 2. Motivations
  3. 3. http://bit.ly/1Mzk4PV Appeared in on the 23rd of July 2015
  4. 4. Genesis
  5. 5. DDS Genesis
  6. 6. CopyrightPrismTech,2016 In the late ‘90s the DoD raised attention on the role that Information Superiority will play in the future of nations. A series of operational and technological initiatives were undertaken to enable Information Superiority. The concept of the Global Information Grid (GIG) was popularised. Information Superiority
  7. 7. CopyrightPrismTech,2016 A globally interconnected, end-to-end set of information capabilities for collecting, processing, storing, disseminating, and managing information on demand to warfighters, policy makers, and support personnel The Global [Image from https://en.wikipedia.org/wiki/Global_Information_Grid] Information Grid “The right data at the right place at the right time”
  8. 8. CopyrightPrismTech,2016 Client/Server technologies popular in the 90’s such as CORBA, COM+/DCOM were not suited to implementing the GiG due to the tight coupling, high sensibility to faults, scalability and performance issues Making the Gig: Challenges
  9. 9. CopyrightPrismTech,2016 The Data Distribution Service (DDS) was introduced to overcome the limitations of existing technologies and address the data sharing requirements of the GiG for the engagement, awareness and planning grid. Enabling the Gig: 7dds DDS
  10. 10. CopyrightPrismTech,2016 DDS has been endorsed and recommended worldwide as the technology at the foundation for network centric systems and GIG-like functionalities Recommendation
  11. 11. CopyrightPrismTech,2016 Massive deployments in Defence & Aerospace Integrated Modular Vetronics Training & Simulation Systems Naval Combat Systems Air Traffic Control & Management Unmanned Air Vehicles Aerospace Applications
  12. 12. OPC Genesis
  13. 13. CopyrightPrismTech,2016 In the early ‘90s Automation Industry there was no standard for interacting with control hardware and field devices. As a result client applications, such as HMI, had to embed drivers and protocols for all the devices they had to interact with. It was the age of Integration Nightmare. Integration Nightmare
  14. 14. CopyrightPrismTech,2016 "All problems in computer science can be solved by another level of indirection, except of course for the problem of too many indirections” —David Wheeler Indirection
  15. 15. CopyrightPrismTech,2016 OPC (OLE for Process Control) was introduced in 1996 as a mean to shield client applications from the details of the automation equipments and providing standardised interfaces to interact with control hardware and field devices. OPC to the rescue Before After [Adapted from OPC Foundation Slides OPC UA Connectivity]
  16. 16. Standards & Evolution
  17. 17. DDS
  18. 18. CopyrightPrismTech,2016 The DDS specification describes a Data- Centric Publish-Subscribe (DCPS) model for distributed application communication and integration. This specification defines both the Application Interfaces (APIs) and the Communication Semantics (behaviour and quality of service) that enable the efficient delivery of information from information producers to matching consumers. The purpose of the DDS specification can be summarised as enabling the “Efficient and Robust Delivery of the Right Information to the Right Place at the Right Time”. Data Distribution [Extract from DDS Specification v1.4] Service (DDS)
  19. 19. CopyrightPrismTech,2016 DDS Standard Evolution 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 ‣ DDS 1.0 ‣ DDSI-RTPS 1.0 ‣ DDS-XTYPES 1.0 ‣ DDS-SECURITY 1.0 ‣ DDS-XTYPES 1.1 ‣ DDSI-RTPS 2.2 ‣ DDS 1.4 ‣ DLRL 1.4 ‣ DDS-RPC 1.0 ‣ DDSI-RTPS 2.0 ‣ DDS 1.2 ‣ DDS-PSM-CXX 1.0 ‣ DDS-PSM-Java ‣ DDSI-RTPS 2.1
  20. 20. CopyrightPrismTech,2016 DDS. Describes the semantics of the information sharing abstraction supported by DDS. Defines a nominal type system for describing DDS information models. DDSI-RTPS. Defines a protocol for interoperable wire implementation of the DDS semantics. Standard Structure
  21. 21. CopyrightPrismTech,2016 DDS-XTypes. Extends the DDS type system with support for structural typing as well as a dynamic type definition. DDS-Security. Introduces information centric security in DDS for data in movement as as well as data at rest. Standard Structure
  22. 22. CopyrightPrismTech,2016 DDS-RPC. Extends DDS with support for Remote Procedure Calls. DDS-PSM-*. Defines highly ergonomic and optimised API mapping for specific programming languages instead of deriving those for the DDS-PSM-IDL DLRL. Defines a language independent Object/Relational Mapping for DDS Standard Structure
  23. 23. DDS Abstractions
  24. 24. CopyrightPrismTech,2016 Applications can autonomously and asynchronously read and write data enjoying spatial and temporal decoupling Virtualised Data Space DDS Global Data Space ... Data Writer Data Writer Data Writer Data Reader Data Reader Data Reader Data Reader Data Writer TopicA QoS TopicB QoS TopicC QoS TopicD QoS
  25. 25. CopyrightPrismTech,2016 Built-in dynamic discovery isolates applications from network topology and connectivity details Dynamic DDS Global Data Space ... Data Writer Data Writer Data Writer Data Reader Data Reader Data Reader Data Reader Data Writer TopicA QoS TopicB QoS TopicC QoS TopicD QoS Discovery
  26. 26. CopyrightPrismTech,2016 QoS policies allow the expression of data’s temporal and availability constraints QoS Enabled DDS Global Data Space ... Data Writer Data Writer Data Writer Data Reader Data Reader Data Reader Data Reader Data Writer TopicA QoS TopicB QoS TopicC QoS TopicD QoS
  27. 27. CopyrightPrismTech,2016 No single point of failure or bottleneck Decentralised Data Writer Data Writer Data Writer Data Reader Data Reader Data Reader Data Writer TopicA QoS TopicB QoS TopicC QoS TopicD QoS TopicD QoS TopicD QoS TopicA QoS Data-Space DDS Global Data Space ... Data Writer Data Writer Data Writer Data Reader Data Reader Data Reader Data Reader Data Writer TopicA QoS TopicB QoS TopicC QoS TopicD QoS
  28. 28. CopyrightPrismTech,2016 Connectivity is dynamically adapted to choose the most effective way of sharing data Adaptive Data Writer Data Writer Data Writer Data Reader Data Reader Data Reader Data Writer TopicA QoS TopicB QoS TopicC QoS TopicD QoS TopicD QoS TopicD QoS TopicA QoS The communication between the DataWriter and matching DataReaders can be peer-to- peer exploiting UDP/IP (Unicast and Multicast)or TCP/IP The communication between the DataWriter and matching DataReaders can be “brokered” but still exploiting UDP/IP (Unicast and Multicast)or TCP/IP Connectivity
  29. 29. CopyrightPrismTech,2016 A domain-wide information’s class A Topic defined by means of a <name, type, qos> DDS Topics allow to expression of functional and non-functional properties of a system information model Topic DDS Global Data Space ... Data Writer Data Writer Data Writer Data Reader Data Reader Data Reader Data Reader Data Writer TopicA QoS TopicB QoS TopicC QoS TopicD QoS Topic Type Name QoS
  30. 30. OPC
  31. 31. CopyrightPrismTech,2016 OPC = OLE for Process Control ‣ OPC-UA 1.0.3 OPC Standard Evolution 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 ‣ OPC 1.0 1998 1999 2000 2001 2002 2003 2004 200519971996 ‣ OPC Data Acces (DA) 2.0 ‣ OPC Alarms and Events 1.01 ‣ OPC Historical Data Access ‣ OPC Security ‣ .Net is launched and DCOM deprecated ‣ OPC-XML-DA 3.0 ‣ OPC-UA 1.0 ‣ OPC-UA 1.0.2 ‣ OPC-UA Part 1-5 ‣ OPC-UA Part 6-8 Rebranding => OPC = Open Platform Communication
  32. 32. CopyrightPrismTech,2016 OPC UA is a platform-independent standard through which various kinds of systems and devices can communicate by sending Messages between Clients and Servers over various types of networks. It supports robust, secure communication that assures the identity of Clients and Servers and resists attacks. OPC UA defines sets of Services that Servers may provide […]. Information is conveyed using OPC UA-defined and vendor-defined data types, and Servers define object models that Clients can dynamically discover. Servers can provide access to both current and historical data, as well as Alarms and Events to notify Clients of important changes. OPC UA [Extract from OPC-UA Overview and Concepts v1.03
  33. 33. CopyrightPrismTech,2016 OPC-UA is organised in Core, Access Type and Utility specifications Standard Structure
  34. 34. CopyrightPrismTech,2016 Security Model. Defines how communication between OPC-UA Clients and Servers should be secured Address Space Model. Describes the contents and structure of the Server’s AddressSpace.
 Services. Defines the services provided by OPC UA Servers. CORE Specifications
  35. 35. CopyrightPrismTech,2016 Information Model. Specifies the types and their relationships defined for OPC UA Servers. Service Mapping. Specifies the mappings to transport protocols and data encodings supported by OPC UA. Profiles. Specifies the Profiles that are available for OPC Clients and Servers. These Profiles provide groups of Services or functionality that can be used for conformance level certification. CORE Specifications
  36. 36. CopyrightPrismTech,2016 Data Access. Specifies the use of OPC UA for data access. Alarms & Conditions. Specifies the use of OPC UA support for access to Alarms and Conditions. Programs. Specifies OPC UA support for access to Programs. Historical Access. Specifies use of OPC UA for historical access. This access includes both historical data and historical Events. Access Type Specifications
  37. 37. CopyrightPrismTech,2016 Discovery. Specifies how Discovery Servers operate in different scenarios and describes how UA Clients and Servers should interact with them. Aggregates. specifies how to compute and return aggregates like minimum, maximum, average etc. Aggregates can be used with current and historical data. Utility Specifications
  38. 38. OPC-UA Abstractions
  39. 39. CopyrightPrismTech,2016 OPC UA is rooted in the client-server model. Clients interact with the server and are coupled in time, e.g. client and server must be running at the same time for anything useful to happen. Client/Server
  40. 40. CopyrightPrismTech,2016 The OPC UA server provides, through a standard API, access to its address space. The address space is organised as a graph of nodes. A server can decide to expose a specific view. Client/Server
  41. 41. CopyrightPrismTech,2016 Clients can register subscriptions with the server and eventually be notified by a server when data changes or some event occurs. Client/Server
  42. 42. Checkpoint
  43. 43. CopyrightPrismTech,2016 For the objectives stated from both the DDS and OPC-UA specifications it emerges how both standards address the problem of information management in distributed systems. Both DDS as well as OPC UA provide support for Information Modelling. DDS through relational data modelling while OPC UA via Object Oriented modelling. similarities DDS & OPC-UA
  44. 44. CopyrightPrismTech,2016 DDS abstraction is centred around a Decentralised Data Space that decouples applications in time and space. OPC UA abstraction is centred around client-server. DDS & OPC-UA DDS Global Data Space ... Data Writer Data Writer Data Writer Data Reader Data Reader Data Reader Data Reader Data Writer TopicA QoS TopicB QoS TopicC QoS TopicD QoS differences
  45. 45. CopyrightPrismTech,2016 DDS applications interact by anonymously and asynchronously reading and writing data in the global data space. OPC UA applications interact by invoking requests on one or more UA servers. DDS & OPC-UA DDS Global Data Space ... Data Writer Data Writer Data Writer Data Reader Data Reader Data Reader Data Reader Data Writer TopicA QoS TopicB QoS TopicC QoS TopicD QoS differences
  46. 46. CopyrightPrismTech,2016 DDS favours resource- oriented and declarative programming style, i.e., you express how things should be. OPC UA favours an imperative programming style, i.e. you express how things should be done. DDS & OPC-UA DDS Global Data Space ... Data Writer Data Writer Data Writer Data Reader Data Reader Data Reader Data Reader Data Writer TopicA QoS TopicB QoS TopicC QoS TopicD QoS differences
  47. 47. CopyrightPrismTech,2016 DDS applications enjoy complete location transparency. Data gets automatically where there is interest. OPC UA applications have to undergo a two step resolution process, first they need to look- up servers and then browse data in its address space. DDS & OPC-UA DDS Global Data Space ... Data Writer Data Writer Data Writer Data Reader Data Reader Data Reader Data Reader Data Writer TopicA QoS TopicB QoS TopicC QoS TopicD QoS differences
  48. 48. CopyrightPrismTech,2016 DDS data modelling is relational. DDS Information model can be queried joined and projected OPC UA data modelling is Object Oriented. OPC UA can be browsed and queried when servers support this extension. DDS & OPC-UA differences DDS data model OPC-UA data model
  49. 49. CopyrightPrismTech,2016 DDS’ Dynamic Discovery allows for very dynamic systems in which applications and data are discovered automatically. Applications are notified of relevant information discovered. DDS has out-of-the box a plug-and-play nature. OPC UA applications have to explicitly “search” for things. That means that supporting plug and play behaviours requires programmatic effort. DDS & OPC-UA DDS Global Data Space ... Data Writer Data Writer Data Writer Data Reader Data Reader Data Reader Data Reader Data Writer TopicA QoS TopicB QoS TopicC QoS TopicD QoS differences OPC-UA Discovery
  50. 50. CopyrightPrismTech,2016 DDS allows information to be annotated with QoS so to capture non- functional properties. OPC UA does not support QoS specification. DDS & OPC-UA DDS Global Data Space ... Data Writer Data Writer Data Writer Data Reader Data Reader Data Reader Data Reader Data Writer TopicA QoS TopicB QoS TopicC QoS TopicD QoS differences
  51. 51. CopyrightPrismTech,2016 DDS security addresses data in motion as well as data at rest. Additionally DDS security provides pluggable Authentication, Access Control, Cryptography and Logging OPC UA security focuses on establishing secure channels between client and servers. DDS & OPC-UA DDS Global Data Space ... Data Writer Data Writer Data Writer Data Reader Data Reader Data Reader Data Reader Data Writer TopicA QoS TopicB QoS TopicC QoS TopicD QoS differences
  52. 52. CopyrightPrismTech,2016 DDS / OPC Standard Evolution
  53. 53. CopyrightPrismTech,2016 Standard “Mapping” Part 2. Security Model DDS-Security Part 3. Address Space Model DDS Part 4. Services There is no server concept in DDS. Negotiation is done via the discovery services. Part 5. Information Model DDS, DDS-XTypes Part 6. Service Mappings Platform Specific Models of each specification define implementation when necessary. Part 7. Profiles Each Specification has its own conformance points. Part 8. Data Access DDS, DDS-XTypes Part 9. Alarm & Conditions Alarms / Events are represented as topics in DDS. Part 10. Programs DDS-RPC Part 11. Historical Access DDS, DDSI-RTPS, DDS provides built-in support for history. Beside this vendor support seamless integration with time series stores. Part 12. Discovery DDS, DDSI-RTPS. DDS Has built-in decentralised discovery. Part 13. Aggregates DDS promotes micro-service architectures, thus aggregates are typically provided by analytics, or similar applications.
  54. 54. Misconceptions
  55. 55. http://bit.ly/1Mzk4PV Appeared in on the 23rd of July 2015
  56. 56. CopyrightPrismTech,2016 EtherCAT - Ethernet for Control Automation Technology - is an Ethernet-based fieldbus system. The protocol is standardised in IEC 61158 and is suitable for both hard and soft real-time requirements in automation technology. ETHERCAT
  57. 57. CopyrightPrismTech,2016 The goal during development of EtherCAT was to apply Ethernet for automation applications requiring short data update times (also called cycle times; ≤ 100 µs) with low communication jitter (for precise synchronisation purposes; ≤ 1 µs) and reduced hardware costs. ETHERCAT
  58. 58. CopyrightPrismTech,2016 Notice that not all communication stack follow literally the OSI Model. As an example the IP stack deviates in many respects. OSI Model Refresher 7. Application High-level APIs, including resource sharing, remote file access, directory services and virtual terminals 6. Presentation Translation of data between a networking service and an application; including character encoding, data compression and encryption/ decryption 5. Session Managing communication sessions, i.e. continuous exchange of information in the form of multiple back-and-forth transmissions between two nodes 4. Transport Reliable transmission of data segments between points on a network, including segmentation, acknowledgement and multiplexing 3. Network Structuring and managing a multi-node network, including addressing, routing and traffic control 2. Data Link Reliable transmission of data frames between two nodes connected by a physical layer 1. Physical Transmission and reception of raw bit streams over a physical medium
  59. 59. CopyrightPrismTech,2016 DDS provides the features defined as part of the Session and Presentation ISO/OSI Model as part of the DDSI-RTPS and DDS layer and layers and sits on-top the Network layer. EtherCat is implemented at the Physical and Data Link Layers, this it is way below the stack in terms of abstractions. DDS vs ETHERCAT IP UDP TCP DDSI-RTPS DDS User App.
  60. 60. CopyrightPrismTech,2016 DDS is in reality a coordination abstraction for distributed computations. It leverages a protocol, namely DDSI-RTPS but it is far more than a protocol. DDS is more than a messaging protocol UDP TCP DDSI-RTPS DDS User App. 7. Application High-level APIs, including resource sharing, remote file access, directory services and virtual terminals 6. Presentation Translation of data between a networking service and an application; including character encoding, data compression and encryption/ decryption 5. Session Managing communication sessions, i.e. continuous exchange of information in the form of multiple back-and-forth transmissions between two nodes 4. Transport Reliable transmission of data segments between points on a network, including segmentation, acknowledgement and multiplexing 3. Network Structuring and managing a multi-node network, including addressing, routing and traffic control 2. Data Link Reliable transmission of data frames between two nodes connected by a physical layer 1. Physical Transmission and reception of raw bit streams over a physical medium IP
  61. 61. CopyrightPrismTech,2016 DDS integrates at European Scale in Air Traffic Control Centres. DDS is at the foundation of several large scale systems such as Smart Cities, Transportation Management Systems, Energy Production, Ground Satellite Control Centres, Connected Vehicles etc. DDS isn’t just for the EDGE
  62. 62. DDS in IIoT
  63. 63. CopyrightPrismTech,2016 Some DDS deployments in IOT/IIoT Agricultural Vehicle Systems Train Control Systems Complex Medical Devices Smart CitiesLarge Scale SCADA Systems High Frequency Auto-Trading
  64. 64. DDS / OPC-UA Interworking
  65. 65. CopyrightPrismTech,2016 Upcoming OMG standard defining a gateway to automatically bridge data from OPC-UA to DDS and vice-versa. OPC-UA/DDS gateway DDS Global Data Space ... Data Writer Data Writer Data Reader Data Reader Data Reader Data Reader Data Writer TopicA QoS TopicB QoS TopicC QoS TopicD QoS DDS/OPC-UA Gateway OPC-UA Server +Client DDSI- RTPS OPC-UA Client OPC-UA Client OPC-UA Client OPC-UA Client
  66. 66. Concluding Remarks
  67. 67. CopyrightPrismTech,2016 DDS and OPC UA address a similar problem in a very different way. DDS was designed since its inception to support GIG-like systems, thus naturally matches IoT/IIoT requirements. OPC has emerged from the Automation industry, thus its ecosystem is its biggest strength. Summing Up
  68. 68. CopyrightPrismTech,2016
  69. 69. Your First DDS Application
  70. 70. CopyrightPrismTech,2016 Anatomy of a DDS Application
  71. 71. CopyrightPrismTech,2016 Writing Data in C++ #include <dds.hpp> int main(int, char**) { DomainParticipant dp(0); Topic<Meter> topic(“SmartMeter”); Publisher pub(dp); DataWriter<Meter> dw(pub, topic); while (!done) { auto value = readMeter() dw.write(value); std::this_thread::sleep_for(SAMPLING_PERIOD); } return 0; } enum UtilityKind { ELECTRICITY, GAS, WATER }; struct Meter { string sn; UtilityKind utility; float reading; float error; }; #pragma keylist Meter sn
  72. 72. CopyrightPrismTech,2016 Reading Data in C++ #include <dds.hpp> int main(int, char**) { DomainParticipant dp(0); Topic<Meter> topic(”SmartMeter”); Subscriber sub(dp); DataReader<Meter> dr(dp, topic); LambdaDataReaderListener<DataReader<Meter>> lst; lst.data_available = [](DataReader<Meter>& dr) { auto samples = data.read(); std::for_each(samples.begin(), samples.end(), [](Sample<Meter>& sample) { std::cout << sample.data() << std::endl; } } dr.listener(lst); // Print incoming data up to when the user does a Ctrl-C std::this_thread::join(); return 0; } enum UtilityKind { ELECTRICITY, GAS, WATER }; struct Meter { string sn; UtilityKind utility; float reading; float error; }; #pragma keylist Meter sn
  73. 73. CopyrightPrismTech,2016 Writing Data in Python import dds import time
 
 if __name__ == '__main__':
 topic = dds.Topic("SmartMeter", "Meter")
 dw = dds.Writer(topic)
 
 while True:
 m = readMeter()
 dw.write(m)
 time.sleep(0.1) enum UtilityKind { ELECTRICITY, GAS, WATER }; struct Meter { string sn; UtilityKind utility; float reading; float error; }; #pragma keylist Meter sn
  74. 74. CopyrightPrismTech,2016 Reading Data in Python import dds
 import sys
 
 def readData(dr): 
 samples = dds.range(dr.read())
 for s in samples:
 sys.stdout.write(str(s.getData()))
 
 if __name__ == '__main__':
 t = dds.Topic("SmartMeter", "Meter")
 dr = dds.Reader(t)
 dr.onDataAvailable = readData enum UtilityKind { ELECTRICITY, GAS, WATER }; struct Meter { string sn; UtilityKind utility; float reading; float error; }; #pragma keylist Meter sn

×