Page 39

Industrial Ethernet Book 104

Technology and the cloud. A goal of the IIC is to identify and demonstrate common architectures across IIoT domains. It is important to note that the goal is not to design new standards, but rather to determine how existing standards and technologies can be integrated to enable development of IIoT applications. The DDS standard is managed by the Object Management Group (OMG), an international, open-membership, not-for-profit technology standards consortium. The DDS standard specifies both an Application Programming Interface (API) that ensures portability of application code between DDS providers and a communication protocol for interoperability between systems and devices implemented using different providers. Implementing layered databus A databus is used to integrate systems and devices. With a decentralized, serverless architecture, Connext DDS abstracts the complexity of the direct point-to-point communication between devices and system components. Components that connect to the Databus act as publishers (providers) of data or subscribers (consumers) of data. Components can also act as both. Components have no direct dependencies between each other, but rather depend only on topics to which they subscribe and publish. Components publish data that they produce, and subscribe to data that they want to consume. In this example, a pressure sensor publishes pressure data. The control application subscribes to the pressure data and produces commands for the surgical robot (the actuator in this simple example system). The important observation here is that, using the databus, the components are fully interoperable, and yet they have no hard-coded dependencies on each other. Connext DDS automatically discovers and connects components at runtime based on matching publications and subscriptions by topic. The resulting loose coupling between components offers a number of advantages. In this example, no code changes are required to the existing system components upon addition of a second pressure sensor or a equipment health monitor. New devices and system components can even be added at runtime without halting the system or any of its components. Mars Rover system architecture Each topic being published or subscribed to has an associated data type or schema, similar to the schema in a relational database. In the Mars Rover, the process might include giving each robot a unique name or number. In addition, the schema is populated with real-time data, such as each robot’s position, direction and acceleration. Although the schema is defined centrally, the data itself Comparison of Message-Centric and Data-Centric Architectures. is not stored in any one location. Published data is replicated across all publishers and subscribers, and data is cached with each subscriber for near-zero-latency access. Note how the data schema represents each robot’s state, rather than messages or updates about the state. This is a fundamental difference between the databus architectural pattern and conventional messaging patterns. By communicating state rather than messages, the layered databus architectural pattern is inherently robust to loss, duplication and reordering of published data. Solution for robotics projects Answering the following five questions can help determine if a robotics project will benefit from using a databus architecture. • Is it a big problem if your system stops working for a short time and you have to wait for it to recover? • Is the system’s response time defined in terms of milliseconds or even microseconds? • Do you have more than 10 software engineers on the project? • Are you sending data to many destinations, as opposed to just one (like to the cloud or a database)? • Are you implementing a new IIoT architecture? If a downtime of a few seconds would result in severe or even life-threatening consequences, the application will likely benefit from the use of the DDS communication protocol. Likewise, SOURCE: RTI Connext DDS would be applicable for robotic projects with response time requirements on the order of milliseconds or microseconds, with a dozen or more developers contributing to the project, with communication patterns that share data with multiple destinations. Or perhaps the project is driven by modern IIoT requirements in general. To date, more than 1,000 different system designs across a broad range of industries implement the layered databus architectural pattern using DDS. The Connext DDS standard itself is referenced by more than 15 other standards and reference architectures, including the OMG and IIC. Unique real-time quality of service The NASA and ESA telerobotic systems as well as the DLR surgical robotics system use Connext DDS to implement the layered databus architectural pattern. Utilizing advanced real-time QoS, Connext DDS can be implemented across a space link as well as for the MIRS robot’s 3kHz closed control loop. RTI Connext DDS includes a highly-tunable reliability protocol, offering per-subscriber best-effort or reliable data transmission to optimally balance throughput and latency across a wide variety of interconnections. For a sensor that outputs updates at a relatively high frequency, best effort may be the best option, while a high-latency, lossy connection, such as the space link likely dictates the reliable QoS policy. Connext DDS QoS is time-aware so timeouts that 39 2.2018 industrial ethernet book


Industrial Ethernet Book 104
To see the actual publication please follow the link above