TAepcphlincoaltoiognys control when ACKs or NAKs are sent can be aggressively set to dozens of microseconds for the surgical robot system, or to seconds for the higher-latency space link. The DDS protocol is the only protocol that will work optimally in each of these very different scenarios. DDS subscribers can also specify time-based filters to sub-sample the data stream to, for example, conserve network bandwidth and CPU power. Flexible QoS configuration makes DDS a framework that can be used across the entire breadth of the IIoT for communication between devices, machines and systems, and from devices and systems into the cloud for data analytics. Its protocol can be fine-tuned to work equally well across any communication media, including shared memory, LANs, WANs, LTE, satellite or radio links. Implementing equivalent communicationprotocol intelligence using standard message-centric software, including plain socket programming, requires significant work before developers can even address the application logic. In contrast, the DDS datacentric software integrates intelligence into the communication platform to reduce the application-development workload. Safety and mission-critical systems Both the space rover and MIRS applications require robust security and safety. A surgical robot, for example, must be protected against vulnerabilities in the remote connection to prevent a hacker from taking control of the device. Traditional transport-layer security methods secure the communication channel and require full encryption of all data. Such gross-level security can be compute-intensive and cause latencies and jitter that would be unacceptable in time-critical applications, such as with the MIRS technique. In addition, traditional transport-layer security requires robust network connections and lack multicast support. DDS overcomes these issues by securing the data itself in real-time. The approach supports secure multicast and allows setting of per-topic security policies and access privileges, making it possible to apply different security policies to different data, even when they are sent on the same channel. Safety certification is another consideration in choosing a connectivity framework. Developers must ensure, for example, that a medical robot never takes an action that would endanger a patient. The International Electrotechnical Commission (IEC) specifies requirements for the safety and effectiveness of medical devices in its IEC 60601 class 3 standards. Similarly, the DO-178C Level A standard describes requirements for flight- management systems and ISO 26262 specifies road-vehicle functional safety. Connext DDS has achieved DO-178C safety certification to provide a strong head start for developers building safety-certified medical robots. The safety-certifiable version is based on the DDS standard and its wire protocol and is fully interoperable with regular DDS implementations. To understand the benefit of using a safety-certifiable connectivity framework like DDS, consider that DO-178C Level A certification can cost more than $100 per executable line of code−and this only includes the cost of developing certification evidence, not the cost of writing certifiable code in the first place. Relative to non-safety critical code, certifiable software is more expensive to develop because it must be deterministic in execution time and memory, traceable to requirements, and fully testable. Using DDS technology reduces the amount of code one has to develop and certify in two ways: it eliminates the need to create a custom connectivity infrastructure and its high-level interfaces reduce the amount of communication and integration logic required by typical lower-level connectivity interfaces. Thus, it is not unusual for DDS to reduce the amount of custom lines of code in a system by 20,000 to hundreds of thousands. This results in a certification cost savings of $2 million or more, in addition to the reduced cost of software development and integration. With Connext DDS, the certifiable code base is derived from a scaled-down DDS implementation for resource- constrained environments. Characterized by a very small memory footprint and a reduced source-code line count, the solution makes it feasible to develop certification evidence. The implementation follows the DDS specifications and the DDS wire protocol, but implements a subset of the standard DDS API that is most amenable to certification and relevant to safety-critical systems and devices. The developed DO-178C Level A certification evidence can be used as a starting point for medical-safety certification. The evidence includes 940 high-level requirements, more than 3,000 low-level requirements, and a body of 3,000 test files that altogether achieve 99.88% code coverage. The solution can be used for safety certification in robotic systems. Already developed and tested, such evidence also reduces the risk and time required for certification— on top of the millions of dollars of savings from the overall reduction in custom code and evidence. Technology report by Real-Time Innovations. 40 industrial ethernet book 2.2018 SOURCE: RTI Examples of Types of Data and Required Security Policies: illustrates data including remote commands, diagnostic data and patient data, and different security policies required. Diagnostic data must be authenticated, for example, while it does not require the encryption that would be necessary with patient data under HIPAA rules.
Industrial Ethernet Book 104
To see the actual publication please follow the link above