DDS Middleware
What is DDS middleware:
Data Distribution Service (DDS) middleware is used for data transmission in real time systems operating in a distributed environment.
DDS middleware is widely used, mainly in defense, aerospace industrial internet of things, healthcare and automotive. Real-time distributed systems require fast, efficient and predictable data communication. Since the DDS middleware uses a UDP-based protocol, its latency is a few hundred microseconds at most. The minimum level of 10 milliseconds provides a very low delay compared to other middlewares. Recently, DDS middleware has been used with the newly developed standards such as Time Sensitive Networking, and it has come to the fore in using it for stable communication in autonomous vehicles and robotic applications.
In the last DDS seminar I went to, they talked about using 784 mirrors synchronously in the ELT (Extremly Large Telescop) project in the world’s largest telescope project. The Swiss watch manufacturer explained that DDS was used to determine the sportsman times in the Olympic and many other sports races and distribute them to all interested parties.
The DDS middleware is architecturally based on the publish-subscribe design pattern. The publish-subscribe architecture ensures that the application providing the data and the application accessing the data become independent from each other. The component that creates the data publishes the data over the middleware. The component that publishes the data does not need to know to whom it should transmit the data. The middleware is responsible for transmitting data to other components that subscribe to this data.
There is no special broker or registry service in the DDS middleware. Data is transmitted directly to all subscribed applications via a UDP multicast based protocol.
New components can be added to the system to publish data, or new components that can subscribe to existing data and process the data can be easily added. For example, a new component can be added to publish temperature and humidity data in a smart building system. This component can publish data over a predefined data model.
Another feature of the DDS middleware is that it is data-centric. Being data-centric means being aware of the format of data at the middleware level. In this concept, if you share wind farm energy data, it means that you separate each different wind farm with a separate switch at the interlayer level. When the wind turbine number 44 starts to publish data, other applications can understand with the middleware status information that this wind turbine provided data to the system for the first time. In addition, when the energy level of the wind turbine number 44 falls below 50%, filters such as information data, which are generally made at the application level, can be made at the middleware level. As such, DDS works like a kind of distributed database, not just a middleware that transmits data from point to point.
Quality of Service Features
Another feature that distinguishes DDS middleware from other middlewares such as AMQP and MQTT is that it provides a wide range of service quality support to meet the real-time and fault tolerance needs of real-time systems. So when you use DDS instead of MQTT, you will not only be advantageous in terms of performance. Also, by using DDS, you will be able to develop the features you want in a mission critical application more easily. While the system is running, when an application is unintentionally closed and opened, it will receive status information from the middleware and continue to work smoothly. Durability quality of service used for this purpose; It determines whether the data will be volatile, transient in memory or persistent on disk. The fact that a data is volatile determines that it will only be delivered to the modules listening at that moment, if it is persistent in memory (transient), it will be transmitted to the modules that are included in the system later, and if it is persistent on the disk, it can be accessed even when the system is turned off.
Reliability, which determines that the data will be sent securely, is an example of this. While data that must be delivered, such as commands, are sent in a secure service quality (reliable), periodically updated data do not need to be sent at this service quality (best effort).
The applications that need that data can be immediately notified that the application that produces the data is closed with the liveliness service quality. You can even start receiving data from the secondary source that can publish the same data (with the Ownership quality of service).
Effective Communication Protocol and Interoperability:
RTPS (Real-Time Publish Subscribe) protocol is available to ensure that DDS middleware developed by different companies are compatible at the protocol level and have a mature communication protocol. RTPS is a protocol that runs on UDP / IP (multicast and unicast). It encodes the data in binary and uses the standard we call OMG Common Data Representation (CDR) for this purpose.
Due to CDR encoding, it requires much less network capacity than text formats such as Json or XML and spends less time for encoding.
DDS Middleware and Open Architecture Standards
The DDS middleware has become a prominent MIDDLEWARE for major open architecture system architectures in the defense industry. Among these standards, Nato Generic Vehicle Architecture (GVA) for military vehicles, Future Avionics Capability Environment (FACE) for avionics systems and Open Architecture Computing Environment (OACE) for ship command control systems.
Robot Operating System (ROS) 2, which provides architectural infrastructure for robot software, also preferred the DDS middleware. In the automotive world, with the new standard we call AUTOSAR Adaptive, it is aimed to meet the high data transmission need of DDS in new generation vehicles in real time.
Finally, the OPEN FMB standard developed for energy systems shows between the intermediate layers that can be used with DDS, MQTT and AMQP.
DDS Middleware products.
Links to DDS prducts
