对于使用AUTOSAR制造车辆的公司来说，已经出现了两个不同的平台 - AUTOSAR Classic和AUTOSAR Adaptive 这两个AUTOSAR平台之间互操作性的基础标准。使 AUTOSAR 自适应应用程序能够与现有和未来的 DDS系统进行互操作。

什么是dds？

1. 1.DDS最重要的特性是以数据为中心，这是与其他很多通信中间件不同的地方。DDS的数据共享以Topic为单元，应用程序能够通过Topic判断其所包含的数据类型，而不必依赖其他的上下文信息。同时，DDS能够按照用户定义的方式自动地进行存储、发布或订阅数据，使应用程序能够像访问本地数据一样去写入或者读取数据
2. 2.DDS实现的数据共享可以理解成一个抽象的“全局数据空间”，任何应用程序，不论开发语言，或者运行的操作系统类型，都可以通过相同的方式访问这个“全局数据空间”，就好像访问本地的存储空间一样。当然“全局数据空间”仅仅是一个抽象的概念，在实现时仍然是分别存储在每个应用程序的本地空间当中。在系统运行时，数据是按需传输或存储的，数据的发布者仅仅发送对方需要的数据，而订阅者仅接收并存储本地应用程序当前需要的数据。DDS还提供了非常灵活的QoS（Quality of Service）策略，以满足用户对数据共享方式的不同需求，比如可靠性，故障处理等等。针对数据安全性要求比较高的系统，DDS还提供了细颗粒度的数据安全控制，包括应用程序身份认证，权限控制，数据加密等等。
3. 3.类似于SOME/IP-SD，DDS提供了对数据发布者和订阅者的动态发现机制，这意味着用户不必去配置通信节点的地址或其他属性信息，因为他们在运行的过程中会自动发现对方，并自动完成相关配置，即实现了“即插即用“。）

关于RTI DDS 详细的的介绍，请到最后一节查看。

什么是中间件？

中间件是位于操作系统和用户应用程序之间的软件层，它将操作系统提供的资源进行抽象和封装，为应用程序提供各种各样的高级的服务和功能，比如通信或数据共享。中间件的存在简化了应用程序开发者的工作，这使他们能够将注意力放在应用程序本身上，而不必在不同应用程序之间或不同系统之间的数据传输上花太多精力）

什么是 DDS 网络绑定？

在 AUTOSAR 自适应平台中，通信管理功能集群提供面向服务的通信建模和基础设施。应用程序构建在中间件之上，应用程序级 API 与协议无关，中间件在 API 和实际的底层通信技术之间进行代理。AUTOSAR 中代理或者此类映射称为“网络绑定”，下面是三个标准化的通信协议：

• DDS
• SOME/IP
• 基于信号的通信

由于 AUTOSAR 自适应平台的各种设计方面，为 AUTOSAR 设计和实现网络绑定组件通常是一项复杂的任务：面向应用程序的 API 和网络绑定组件之间不存在标准化的 API 层，因此要求特定网络绑定的实现者以各自不同的方式来集成 AUTOSAR 有自己的数据类型系统，必须通过网络绑定与每个底层通信技术（即 DDS 自己的可扩展类型）的类型系统和功能进行协调) AUTOSAR还规定了非常具体的对象生命周期和内存管理协议，这些协议必须与网络绑定封装的底层框架相匹配。

映射 DDS 和 AUTOSAR 类型系统

尽管 AUTOSAR 类型相当常见并且自然映射到 DDS-XTypes（布尔值、数字、字符串、结构、数组、序列等）——并且这种映射已经在通信管理规范中的 DDS 网络绑定材料中指定——但实际集成需要将 PSM（平台特定模块）组合在一起，用于 C 和C++编程语言中的两种类型系统。我们将选择AUTOSAR支持的唯一语言绑定，C++（最多C++14）和DDS的C语言PSM。从一个简单的示例开始，下面是从 DDS-IDL 或 DDS-XML 转换为 C 后的简单 Point3D 类型的外观：

struct Point3D {
        float x;
        float y;
        float z;
};

然后从AUTOSAR的ARXML转换为C++：

struct Point3D {
        float x;
        float y;
        float z;
};

让我们进一步改进我们的类型目录，将 3D 点分组为点云，为了简单起见，这些点云仅作为固定长度的数组排列。根据 DDS C PSM，有如下定义：

typedef Point3D PointCloud[1024];

但是相同的类型（1024个元素的点数组）将在AUTOSAR Adaptive中生成，如下所示：

typedef ara::core::Array<Point3D, 1024> PointCloud;

它们明显是相似但不相同的类型。事实上，ara：：core：：Array<>保留了一些普通固定长度数组类型的语义（例如索引访问），但也添加了类似 STL 的语义，如 begin（） 和 end（） 方法，并且不会隐式转换为 Point3D 指针。对于其他类型的，例如字符串和向量，此差距甚至更大。在RTI的ara：：com中，通过AUTOSAR建模的用户定义类型（结构体）的实现类型不包含值字段，而是引用内部管理的“后端存储”的功能兼容包装器。此类后端存储可能基于 Adaptive Platform 的 PSM（标准C++数值类型和 ara：：core 容器类型）或 DDS 的 PSM 自动生成类型，来自 DDS-IDL 或 DDS-XML。这种方法不仅简化了与多种不同的通信框架的集成，而且还为共享数据时的高效内存管理和增删改数据样本提供了便利。

实现高效的内存管理

由于上一节中描述的数据类型结构的灵活性，数据样本出现了两种非独占内存管理策略：

• 实现类型实例可以由应用程序直接分配堆栈或堆，这会导致内部类型实现使用 AUTOSAR 的内存中 PSM 类型。当传递给底层框架时，这些数据类型必须根据所需的目标数据格式（即，来自DDS-IDL或DDS-XML的DDS自动生成的类型）进行转换和/或序列化。
• 在寻求零拷贝传输时，应用程序还可以利用事件和字段通知程序提供的标准 Allocate（） 方法。在这种情况下，网络绑定将尽可能要求底层框架“借出”内部分配的数据样本，该样本将在应用程序填充和发回时“返回”。后者是一种非常强大的机制，允许在几种情况下进行与大小无关的恒定时间传输：
• 共享内存传输
• 内存映射网络接口
• 进程内通信

除了以高性能的方式映射类型系统和 API 之外，AUTOSAR 的汽车产品重点还带来了另一个挑战：功能安全合规性。在任何ISO-26262 ASIL级别中，评估任何DDS实施，都要有SEooC，脱离（SEooC）去评估本身就是一个挑战，下面是一些对DDS实施和AUTOSAR的一些约束和要求：

• C 是 DDS 网络绑定实现中唯一允许的 DDS 语言 PSM，因此可以轻松适应多种 DDS 实现（占用空间小、安全意识强）
• 多绑定支持是必须的，因为肯定需要提供多个DDS网络绑定才能支持上述各种DDS实现。
• AUTOSAR 自适应 DDS 网络绑定规范中更精简的服务发现和绑定功能方法，使用在大多数 DDS 中间件实现中更容易找到的常见 DDS 功能（主题、实例）

RTI DDS 介绍