# Formal Safety Assessment and Improvement of DDS Protocol for Industrial Data Distribution Service
## 3 Related Foundation
### DDS Protocol and Standard Architecture  
DDS [27] is data-centric, using a publish/subscribe communication model, which has the advantages of real-time, dynamic, reliability, scalability, and flexibility [28], but faces security threats, such as unauthorized subscription, unauthorized publication, unauthorized access to data, and tampering and replay. To deal with the above security issues, the Object Management Group (OMG) released the DDS version 1.0 and 1.1 security specifications in 2016 and 2018, respectively, adding security mechanisms to DDS to deal with security threats [11; 29; 30]. However, security flaws remain unresolved. In addition, DDS is used in highly dynamic distributed systems, the network topology is dynamically discovered, the connections between nodes are established point-to-point, there is no central server as a single point of failure, and there is a rich set of QoS policies, which is why DDS commonly used for reasons in industrial environments. Currently, both DDS and Scalable service-Oriented MiddlewarE over IP (SOME/IP) have been incorporated into the AUTOSAR platform standard [17]. SOME/IP and DDS are the two most commonly used communication protocols in autonomous driving. From the perspective of autonomous driving, both SOME/IP and DDS protocols have good practicability, and SOME/IP can be used as a substitute for DDS protocol. SOME/IP is specially designed for the automotive field. It defines a set of communication standards for the needs of the automotive field, and has been deeply cultivated in the automotive field for a long time; DDS is an industrial-level strong real-time communication standard. The adaptability to the scene is relatively strong, but special tailoring is required when it is used in the field of automobile/autonomous driving. However, from the perspective of the trend of the latter, the market share of DDS will be larger than that of SOME/IP in the future. The OMG DDS standard consists of the DDS Interoperability Wire Protocol (DDSI) layer and the DDS layer. The DDSI layer specifies the network transport layer and the DDS layer specifies the data center publish-subscribe behavior and DDS API [31]. Figure 3 shows the stack view of the OMG DDS standard architecture [32]. The DDS specification is divided into two layers [33]: one is the Data-Centric Publish-Subscribe (DCPS) layer [34], and the other is the Data Local Reconstruction Layer (DLRL). The DCPS layer is the core and foundation of DDS and provides the basic services of communication; the DLRL layer abstracts the services provided by the DCPS layer and establishes the mapping relationship with the underlying services in the DLRL layer. The core of the DDS protocol is built around DCPS. This layer defines how DDS sends data from the publisher to the subscriber. The latest specification proposes a new concept, the global data space, which is the top-level abstraction of DDS and stores all data published in the domain. Since the global data space can be fully distributed, the system can scale without a single point of failure. In addition, the domain is a virtual data space in which DDS client applications send and receive data. Domain supports communication between domain participants, which encapsulates all data and communications from other domains in the domain. In addition, the DDS specification also defines six main entities, \begin{table}
\begin{tabular}{c c} \hline \hline
**Basic Color Set** & **Composite Color Set** \\ \hline Unit & Product \\ Boolean & Record \\ Integer & List \\ String & Union \\ Enumerated & Alias \\ Index & Subsets \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Color set defined by CPN Tools. namely Domain Participant, DataWriter, Publisher, Subscriber, DataReader, and Topic. These entities cooperate with each other to complete the publish-subscribe process. In addition, the DDS DCPS specification also defines the QoS policy.