汽车软件架构正由面向信号迈向面向服务，而DDS数据分发服务是新一代分布式实时通信中间件协议，高实时性能，高可靠性能，开放式体系结构和发布/订阅端的非耦合性能，大大加速和简化了分布式系统的开发，使其非常适用于汽车领域，不但能满足汽车智能驾驶领域大数据传输的需求，同时能够满足SOA架构。（SOA 面向服务）
DDS是数据分发服务，基于DCPS魔性的一种中间件协议和API标准，它将系统的组件集成在一起，提供业务和任务关键型物联网应用程序所需的低延迟数据连接，极高的可靠性和可扩展架构。
在分布式系统中中间件是位于操作系统和应用程序之间的软件层，它使系统的各个组件能够更轻松地通信和共享数据，它通过让软件开发人员专注于其应用程序的特定目的而不是再应用程序和系统之间传递信息的机制来简化分布式系统的开发。
如上图（一）所示，DDS中间件是一个软件层，它从操作系统、网络传输和低级数据格式的细节中抽象出应用程序。相同的概念和API以不同的编程语言提供，允许应用程序跨操作系统、语言和处理器架构交换信息。数据线格式、发现、连接、可靠性、协议、传输选择、QoS、安全等低级细节由中间件管理。
DDS通信的基本要素
域：用于链接所有发布者和订阅者的概念，属于一个或多个应用程序，它们在不同的主题下交换数据，这些参与域的单个应用程序成为DomainParticipant。DDS域由域ID标识。具有不同两个ID的域不知道彼此在网络中的存在，因此可以创建多个通信通道，这适用于涉及多个DDS应用程序的场景，他们各自的DomainParticipants相互通信，但这些应用程序不得干扰。DomainParticipant充当其它DCPS实体的容器，充当发布者，订阅者和主题实体的工厂，并在域中提供管理服务。
主题：它是发布者与订阅者绑定的实体，在DDS域中是唯一的，它可在进程之间交换的数据的消息，数据表示为可以包含不同数据类型的结构，如整数，字符串等
数据读入器：它是负责发布消息的实体，用户在创建此实体时必须提供一个主题，该主题将是发布数据的主题
数据读取器：它是订阅主题以接受发布的实体，用户在创建此实体时必须提供订阅主题
发布者：他是负责创建和配置其实现的数据写入器的DCPS实体，数据写入器是负责实际发布消息的实体，每个人都有一个分配的主题，在该主题下发布消息
订阅者：它是DCPS实体，负责接收在其订阅的主题下发布的数据，它为一个或多个数据读取器对象提供服务，这些对象负责将新数据的可用性传达给应用程序
通信流程：基于DDS的分布式系统中，加入DDS网络的节点发布自己想要发布的（或者想要订阅的）Topic和QoS，DDS网络上已经存在的节点收听到这个请求后和自己的发布订阅情况以及QoS标准进行对照，如果新加入节点的Topic信息与自己相关，并且QoS标准也符合要求，就主动同新加入的节点进行通信，将自己的Topic信息发送给新加入节点，同时，把新加入节点的相应信息注册到本节点上，以便有通信需求时建立点到点连接
四层结构：
应用层：使用DDS API在分布式系统中实现通信的用户应用程序；
DDS层：DDS通信中间件的稳健实现。它允许部署一个或多个 DDS域，其中同一域内的域参与者通过在域主题下发布/订阅来交换消息；
RTPS层：实施Real-Time Publish-Subscribe protocol（实时发布-订阅协议），以实现与DDS应用程序的互操作性。该层充当传输层的抽象层；
传输层：DDS可用于各种传输协议，例如：UDP、TCP、SHM；
DDS发现协议
DDS提供发现协议，该协议定义了DataWriters在给定Topic下与订阅同一Topic的DataReaders匹配的机制，允许跨域DomainParticipants自动查找和匹配DataWriters和DataReaders，以便他们可以开始共享数据，这适用于通信过程中的任何时候。
Fast DDS 作为DDS的一种具体实现，以下以Fast DDS举例其发现过程，分两个阶段执行：
参与者发现阶段（PDP）：在此阶段，DomainParticipants确认彼此的存在。为此，每个DomainParticipant都会定期发送公告消息，其中指定DomainParticipant正在侦听传入元数据和用户数据流量的单播地址（IP和端口）。当两个给定的DomainParticipants 存在于同一个DDS域中时，它们将匹配。默认情况下，通知消息使用众所周知的多播地址和端口（根据DomainId来计算）发送。此外，可以指定地址列表以使用单播发送通知。此外，还可以配置此类公告的周期。
端点发现阶段（EDP）：在这个阶段，DataWriters和DataReaders相互确认。为此，DomainParticipants使用PDP期间建立的通信通道相互共享有关其DataWriters和DataReaders的信息。除其他外，此信息包含Topic和数据类型。对于要匹配的两个端点，它们的主题和数据类型必须一致。一旦DataWriter和DataReader匹配，它们就可以发送/接收用户数据。
同时，Fast DDS提供如下四种发现机制：
简单的发现：这是默认的发现机制，在RTPS标准中定义并提供与其他DDS实现的兼容性。在这里，DomainParticipants是在早期单独发现的，以便随后匹配它们实现的DataWriter和DataReader；
发现服务器：这种发现机制使用集中式发现架构，其中服务器充当元流量发现的中心；
静态发现：这实现了DomainParticipant彼此之间的发现，但如果远程DomainParticipant事先知道这些实体，则可以跳过每个 DomainParticipant (DataReader/DataWriter) 中包含的实体的发现；手动发现：此机制仅与RTPS层兼容，它允许用户使用其选择的任何外部元信息通道手动匹配和取消匹配RTPSParticipants、RTPSWriters和RTPSReaders；
总结：
域由域ID标识，在一个DDS域下有俩个部分，一是域参与方，二是主题，在域中每个主题都是唯一的，一个域参与方就是一个应用程序，域部分定义域 ID 以指定它所属的 DDS 域，具有不同 ID 的两个域参与者不知道彼此在网络中的存在，因此，可以创建多个通信通道。这适用于涉及多个 DDS 应用程序且其各自的域参与者相互通信的情况，但这些应用程序不得干扰。域参与者充当其他 DCPS 实体的容器，充当发布者、订阅者和主题实体的工厂，并在域中提供管理服务。
实时发布订阅 （RTPS） 协议是为支持 DDS 应用程序而开发的，它是一种通过尽力而为的传输（如 UDP/IP）进行的发布-订阅通信中间件。
RTPS编写器：能够发送数据的端点。
RTPS读取器：能够接收数据的终结点。
RTPS参与者可以具有任意数量的写入器和读取器终结点。
DDS最重要的特性是以数据为中心，这是与其他很多通信中间件不同的地方。DDS的数据共享以Topic为单元，应用程序能够通过Topic判断其所包含的数据类型，而不必依赖其他的上下文信息。同时，DDS能够按照用户定义的方式自动地进行存储、发布或订阅数据，使应用程序能够像访问本地数据一样去写入或者读取数据。
DDS实现的数据共享可以理解成一个抽象的“全局数据空间”，任何应用程序，不论开发语言，或者运行的操作系统类型，都可以通过相同的方式访问这个“全局数据空间”，就好像访问本地的存储空间一样。当然“全局数据空间”仅仅是一个抽象的概念，在实现时仍然是分别存储在每个应用程序的本地空间当中。在系统运行时，数据是按需传输或存储的，数据的发布者仅仅发送对方需要的数据，而订阅者仅接收并存储本地应用程序当前需要的数据。
DDS提供了对数据发布者和订阅者的动态发现机制，这意味着用户不必去配置通信节点的地址或其他属性信息，因为他们在运行的过程中会自动发现对方，并自动完成相关配置，即实现了“即插即用“。
