Reader’s Note
The automotive regulations and standards always consider the functional safety of the autonomous driving system by enabling the ‘x’ or multiple redundancy in all aspects such as triple redundancy controllers, dual redundancy networks, redundant data hubs, etc. In this current article, I would like to share the approach to enable redundancy in message discovery servers using ROS2 middleware.
Abstract
During the concept, design, and all the subsequent stages of autonomous driving applications, the system always be adhere to the regulations of system functional safety. To accomplish this, the architects always go ahead and use redundancy in all the implementations to avoid the failures of the system functions. As part of the current work of vehicle platform migration to ROS2, I just wanted to implement the redundancy in Data Discovery services to avoid the message server failures and to create efficient message traffic reduction across the ROS2 nodes.
I would like to share the brief details and the experience that I have come across during the implementation of “redundancy in message discovery server protocols” in the current article which is a very critical one for autonomous vehicle application development.
Terms to be known
Data Writers, Data Listeners & Domain Participants – To understand in detail, request you to refer to the ROS2 foundational documentation
Simple Discovery Server – By Default Option in ROS2
As we are all aware that the ROS2 comes with various DDS services (Refer to my previous articles) as RMW (ROS2 middleware) frameworks. These frameworks provide the basic services like message discovery protocols and also act as a bridge between the data writers, listeners, and all the domain participants (publishers and subscribers) to enable message handling services to avoid message losses, traffic management, etc.
By default, ROS2 provides the simple discovery servers which work as an end to end or peer to peer and also have the following drawbacks
1. Lack of dynamic scalability when the packets and nodes increased
2. Non-availability of seamless ‘multi-casting’ capability
3. No support for redundancy implementation
The below diagram shows the working functionalities and the high-level concept of a simple discovery server available in ROS. As depicted in the below block diagram, various nodes are connected and every node requires a multi-cast capability to share and exchange the information.
As per the above design, there are lots of chances for the data losses and high traffic during the messages exchange.
The Necessity of Discovery Server
Considering the functional safety of any autonomous driving system, the redundancy, minimal latency, reduced message traffic congestion etc are needed to be adhere to the regulated requirement standards (which is like a few milliseconds of interval to exchange the information) to achieve an efficient and highly responsive and reliable vehicle platform.
The Discovery Server Should be required to enable the efficiency in the following
1. Highly Scalable system when the packets and nodes increased
2. Efficient multi-casting capability
3. Multiple redundancy in Message Servers
To address and adhere to the regulations, I started looking for implementing the redundancy in message exchange discovery servers. I just come to know that the ROS2 FastDDS Discovery Server provides the required services with the relevant responses.
The FastDDS Discovery Server Protocol
The Fast DDS Discovery Server provides a Client-Server Architecture that allows nodes to connect with each other using an intermediate server which is called here as Discover Server. Each node functions as a discovery client, sharing its info with one or more discovery servers and receiving discovery information from it.
The follow block diagram depicts the FastDDS Discovery Server Architecture when compared to the simple discovery server.
By Enabling the above Architecture using FastDDS for the Discovery Servers, the following things are achievable:
1. Independent Discover Servers
2. Duplicated or connected with each other in order to create redundancy over the network
3. Avoid having a single point of failure
4. reduces the number of messages sent between the server and clients dramatically
Recommendation
I believe I have provided the enough information to kick off the work related with the Discovery servers. The FastDDS Discovery Servers are really a helpful framework which assists the designers and engineers to implement the redundancy in data exchange protocols. Please follow the references to get more details implementation, design and insights.
References
1. https://fast-dds.docs.eprosima.com/en/v2.1.0/fastdds/discovery/discovery.html
