Implementing distributed systems based on the DDS (Data Distribution Service) standard can be a challenging and complex endeavor. A solid architecture and following best practices from the outset are essential to ensure success in DDS-based projects. In this article, we will explore the significance of setting our projects to success by following certain best practices in order to build a solid Fast DDS architecture that will help ensure performance, security, and efficiency in these systems.
Less is more:
Before delving into DDS architecture best practices, it is essential to understand the right approach. First and foremost, before we dive head-first into an endless list of necessities regarding optimizations, we should start by focusing on conceptual functionality, avoiding over-engineering that would only create a product more complicated than necessary and that would ultimately result in having to spend time and resources for this to be fixed.
Node Identification and Security:
At the beginning of any DDS project, it is crucial to clearly understand which nodes exist in the distributed application and how they are to interact with one another. This includes identifying which nodes need to consume data produced by other nodes.
Furthermore, a critical aspect is performing a cybersecurity analysis. We must consider which nodes will run with others, where they will run, and which topics will contain critical information. This process also involves decision-making on the level of cyber security and authentication among participants, as well as the exposure level of the different nodes of the distributed application.
As a result of the cybersecurity analysis, segmenting or isolating subsystems within the distributed application might be required. If there is still a need for these subsystems to communicate with one another, it is recommended to deploy a DDS Router, which provides fine-grained control over the data that traverses the boundaries between the distributed application subsystem/segments.
See example here
Consumer Perspective and Fault Tolerance:
From the consumer's perspective, it is essential to consider whether data consumers will require historical information when subscribing to a topic or if, on the other hand, receiving only the data produced after the consumer joins the network is enough. Additionally, we must address the crucial question of what happens when a node disappears due to a planned disconnection or an unexpected failure. The importance of implementing all the DDS entities’ listener callbacks is highlighted here, as they can be used to monitor the operation of remote nodes. For example, in the context of an autonomous car, how long can it function without GPS if this source of information is lost? This relates to system resilience.
Data Model Definition:
The next step is to define the data model. This involves determining which communication channels will exist within the distributed application and how they will be structured. Striking a balance between a uniform data model and avoiding too many similar topics is important. When data streams are conceptually similar, it is recommended to multiplex them using keys in the topics to save resources, i.e., leveraging DDS Topic instances. In that sense, our “commercial flights tracking” example is a great way to better understand the practical applications of DDS topic instances.
Quality of Service (QoS) Creation:
Quality of service (QoS) plays a pivotal role in the efficiency and reliability of DDS systems. Appropriate QoS profiles must be established for each topic but can also be established in endpoints and participants. This may include varying reliability levels depending on the importance of the transmitted data. Packet loss may be acceptable to different degrees in some cases, while in others, it may be critical or not relevant at all.
For cases where the consumer is only interested in receiving updates from time to time, but the periodicity of those updates is not critical, and any loss of samples between update receptions is not important, BEST_EFFORT reliability is recommended. However, if some applications require receiving every update, this would be an example of applications that require RELIABLE communication.
Durability QoS determines whether or not the consumer receives information that was published while not running. If this is the case, the chosen configuration would be TRANSIENT_LOCAL durability. On the other hand, if the consumer only wishes to receive data published while it is running, then the chosen configuration would be VOLATILE durability.
Reliability requirements also determine how much data the producers and consumers store. This QoS directly impacts both the behavior and reliability of the communication.
The history depth will determine how much data can be stored and resent. If we wish to only KEEP_LAST, this will mean that once endpoints are full, new data samples will overwrite the old ones. Both Reliable and History QoS must be set accordingly since the history depth will determine how much data can be stored or resent in case of packet loss.
As mentioned before, if we wish late joiners to receive all information vs receive information from the moment they join, this QoS will determine how long the samples will be kept in the system.
It's important to specify QoS clearly through XML files or via a common API that simplifies operation for applications subscribing to the DDS middleware. Additionally, monitoring all callbacks to detect misconfigurations is crucial.
Update Frequencies and Operational Logging:
Finally, it is essential to have a clear understanding of the required frequencies for different data flows and topics. How often do updates need to be received for objects? At what rate can these updates be produced? Maintaining operational logs and monitoring what transpires in the DDS network is essential to identify issues and optimize the system.
The periodicity at which a consumer receives updates is determined by deadline QoS, allowing the consumer to detect when the producer can no longer provide the expected updates and take the appropriate action.
Conclusion:
In summary, a robust architecture and adherence to best practices are critical to the success of DDS projects. eProsima provides the expertise needed to help you design a solid and efficient architecture. Our DDS experience and approach to focusing on conceptual functionality first, followed by optimizations, ensures optimal performance in your distributed application. Additionally, we offer support services to ensure your DDS project runs reliably and securely. Don't let your DDS implementation be a challenge—trust Fast DDS to simplify the process and save you time and resources!
What can you expect from our team of experts?
The Architecture Study provides a comprehensive analysis of the whole customer’s system architecture, covering the overall architecture design, the data model design, and the QoS setting.
This service starts with the customer’s use case requirements and closes with a detailed report that includes optimization recommendations, general findings, and a testing phase. The result is an extremely fast, efficient, and reliable communication layer in the customer’s network.
Want more information?
Email us at
ADVANTAGES OF EPROSIMA FAST DDS:
- Excellent performance: Low latency, high throughput even in low bandwidth environments. See the performance benchmarks.
- Easy Multi-Platform Integration: Windows, Linux, Mac OS, QNX, VxWorks, iOS, Android, Raspbian.
- Free and Open Source: Apache License 2.0
- Standard-based and Interoperable DDS compliance: OMG DDS 1.4 Compliant. Minimum profile
- Full RTPS compliance: OMG RTPS 2.2 compliant
- Personalized Services & Commercial Support available
- Well-documented & easy to use: See our User Manual and a "hello world" example video tutorial here.
- Well-suited for: Robotics, IoT, Automotive, and Critical applications
DOWNLOADS AND ONLINE DOCUMENTATION
Visit the release page to check for more details.
Please also visit the eProsima Fast DDS product page for more information or download Fast DDS here.
FOR MORE INFORMATION:
Please get in touch with
