AP-13 AUTOSAR AP中的DDS数据分发服务 核心架构与QoS策略体系深度解析

AP-13 AUTOSAR AP中的DDS数据分发服务：核心架构与QoS策略体系深度解析

摘要：数据分发服务（Data Distribution Service，DDS）是OMG（Object Management Group）制定的以数据为中心的发布-订阅中间件标准，广泛应用于军事、航空航天、汽车自动驾驶等高可靠性领域。本文深入解析DDS在AUTOSAR Adaptive Platform中的集成应用，涵盖全局数据空间架构、实体层次模型、QoS策略体系以及Request-Offered语义匹配机制，为汽车行业从业者提供完整的技术参考。

目录

1. 引言：为什么AUTOSAR AP需要DDS

1.1 AP通信管理（ara::com）的演进

AUTOSAR Adaptive Platform的通信管理（ara::com）是连接应用层与底层通信协议的桥梁。在ARA-COM的架构设计中，通信绑定的选择是一个核心设计决策。最初的ARA-COM主要支持SOME/IP（Scalable Service-Oriented Middleware over IP）作为主要通信协议，这一选择与AUTOSAR Classic Platform保持了一致性。

然而，随着智能驾驶技术的快速发展，传感器数据量呈指数级增长，传统的SOME/IP协议在某些场景下面临严峻挑战。SOME/IP最初设计用于车载娱乐系统和车身控制，数据传输量相对有限；但在自动驾驶场景中，激光雷达点云（单个帧可达数MB）、高分辨率摄像头图像流（每秒数百MB）以及多传感器融合数据，对通信中间件提出了更高要求。

1.2 SOME/IP的局限性分析

尽管SOME/IP在传统车载网络中表现优异，但在以下方面存在固有局限：

• 服务耦合问题：SOME/IP采用RPC（Remote Procedure Call）模式，客户端必须知道服务提供者的IP地址和端口，服务接口的变化会直接影响客户端代码。
• QoS表达能力有限：SOME/IP仅支持基本的可靠性配置，无法表达复杂的传输属性如截止时间（Deadline）、延迟预算（Latency Budget）等。
• 大数据量传输效率：SOME/IP基于SOA架构，适合方法调用和事件通知，但用于大规模流数据传输时序列化开销较大。
• 发布-订阅灵活性：SOME/IP的发布-订阅机制需要通过服务发现动态配置，灵活性不如以数据为中心的模型。

1.3 DDS的引入动机

DDS（Data Distribution Service）是由OMG于2004年发布的以数据为中心的发布-订阅中间件标准。与SOME/IP相比，DDS具有以下核心优势：

数据中心解耦

DDS采用"全局数据空间"（Global Data Space）模型，生产者和消费者通过Topic进行数据交换，无需知道对方的存在，真正实现时间、空间和通信机制的全面解耦。

丰富的QoS策略

DDS定义了20+种QoS策略，涵盖数据传输、资源管理、活性监控等维度，可以精确控制数据分发行为，满足不同应用场景的需求。

在汽车行业，DDS已被多个技术规范采纳：

• OMG DDSI-RTPS（Real-Time Publish-Subscribe）协议规范
• AUTOSAR AP Adaptive Platform规范中的DDS绑定支持
• ROS2（Robot Operating System 2）将DDS作为默认通信中间件
• MGVP（Micro AutoGBA Vehicle Platform）等国产自动驾驶平台

1.4 汽车场景驱动因素

自动驾驶系统对数据分发服务的需求尤为迫切：

表1：自动驾驶典型数据类型及通信需求

2. DDS核心架构与数据模型

2.1 全局数据空间（Global Data Space）

DDS的核心理念是"以数据为中心"（Data-Centric），这与传统的"以服务为中心"的SOA架构有本质区别。在DDS模型中，所有参与通信的应用程序共享一个逻辑上的"全局数据空间"，数据生产者向数据空间写入数据，数据消费者从数据空间读取数据，双方无需知道彼此的存在。

图1：DDS全局数据空间 vs SOME/IP服务注册表架构对比

与SOME/IP的服务注册表（Service Registry）相比，全局数据空间具有以下特点：

• 位置透明性：数据生产者不知道有多少消费者，消费者也不知道有多少生产者
• 动态发现：新的数据生产者或消费者可以随时加入，无需重新配置
• 数据导向：程序员关注"共享什么数据"而非"发送什么消息"
• 隐式通信：发布和订阅是解耦的，无需显式的请求-响应交互

2.2 数据模型三要素

DDS的数据模型由三个核心要素构成，任何有效的数据交换都离不开这三者的协同作用：

2.2.1 Topic（主题）

Topic是DDS中数据通道的标识符，类似于网络协议中的端口号或ROS中的Topic。Topic由两个属性唯一标识：

• Topic名称（Name）：字符串类型的逻辑标识，如"LiDAR_PointCloud"、"VehicleSpeed"等
• 数据类型（Type）：Topic承载的数据结构定义，必须是符合IDL（Interface Definition Language）规范的struct类型

// DDS Topic数据类型定义示例（OMG IDL语法）
module automotive {
module sensor {
@final
struct PointCloud {
uint64 timestamp; // 微秒级时间戳
string frame_id; // 坐标系标识
uint32 width; // 点数量
uint32 height; // 高度（用于组织）
boolean is_dense; // 是否所有点有效
sequence<float, 100000> x; // X坐标序列
sequence<float, 100000> y; // Y坐标序列
sequence<float, 100000> z; // Z坐标序列
sequence<uint8, 100000> intensity; // 强度值
};
};
};

2.2.2 Type（数据类型）

DDS支持多种数据类型定义方式：

• OMG IDL：标准的接口定义语言，可映射到C++、Java、C#等多种语言
• XCDL（XML Complete Data Representation）：XML格式的类型定义
• 动态类型（Dynamic Type）：运行时构造的数据类型，用于动态数据交换场景

2.2.3 QoS（Quality of Service，服务质量）

QoS是DDS区分于其他中间件的核心特性。QoS策略定义了数据在传输过程中的行为特性，包括传输可靠性、资源使用、数据新鲜度等多个维度。每个Topic可以配置独立的QoS策略，每个DataWriter和DataReader也可以配置自己的QoS。

2.3 实体层次结构

DDS的实体层次结构体现了其模块化设计思想，从顶层到底层依次为：

图2：DDS实体层次结构图

2.3.1 DomainParticipant（域参与者）

DomainParticipant是DDS世界中的最顶层实体，代表一个应用程序在某个Domain中的入口点。一个DomainParticipant可以创建多个Publisher、Subscriber和Topic。DomainParticipant的主要职责包括：

• 创建和销毁DomainParticipantListener，监听域级事件
• 创建Topic，包括数据类型注册和名称管理
• 管理DomainParticipant的QoS配置

2.3.2 Publisher（发布者）和 Subscriber（订阅者）

Publisher负责管理一个或多个DataWriter，是数据发布的容器实体。Subscriber负责管理一个或多个DataReader，是数据订阅的容器实体。这种容器化设计允许对一组相关的Writer或Reader进行统一管理。

2.3.3 DataWriter（数据写入者）和 DataReader（数据读取者）

DataWriter是实际执行数据写入的端点实体，它绑定到特定的Topic并负责：

• 样本序列化
• 发送逻辑（何时发送、如何重试）
• QoS策略执行

DataReader是数据读取的端点实体，负责：

• 样本接收和反序列化
• 接收缓存管理
• 读取条件（ReadCondition）和查询条件（QueryCondition）

2.3.4 Topic（主题）

Topic是连接DataWriter和DataReader的逻辑通道，是DDS以数据为中心理念的核心体现。同一个Topic可以有多个DataWriter（多源发布）和多个DataReader（多接收方订阅）。

3. QoS策略体系深度拆解

DDS定义了超过20种QoS策略，这些策略可以按功能分为五大类别。下图展示了完整的QoS策略分类体系：

图3：QoS策略分类体系思维导图

3.1 数据传输类策略

3.1.1 RELIABILITY（可靠性）

RELIABILITY策略控制数据传输的可靠性级别：

RELIABLE模式的协议机制：当RELIABILITY设置为RELIABLE时，DDS使用RTPS协议中的HEARTBEAT和ACKNACK消息实现可靠传输：

图4：RELIABILITY协议HEARTBEAT/ACKNACK交互时序图

// C++ 配置RELIABILITY QoS示例（ara::com风格）
ara::com::ServicePublisher<PointCloudTopic> publisher;
publisher.SetQoS<ara::com::qos::Reliability>(
ara::com::qos::Reliability::Reliable()
);

// 或者通过配置文件
/*
<qos>
<reliability>RELIABLE</reliability>
</qos>
*/

3.1.2 DEADLINE（截止时间）

DEADLINE策略定义了数据写入/读取的期望频率：

• 对于DataWriter：期望每duration时间间隔写入新数据
• 对于DataReader：期望每duration时间间隔收到新数据

关键理解：DEADLINE是"监控型"QoS，当超过指定时间间隔未写入/读取数据时，会触发on_offered_deadline_missed或on_requested_deadline_missed回调，但不会自动采取补救措施。

// 配置DEADLINE策略
struct DeadlinePolicy {
Duration_t period; // 期望周期，默认DURATION_INFINITE
};

// 示例：传感器数据每100ms更新一次
qos.deadline.period = 100000; // 100ms in microseconds

3.1.3 LATENCY_BUDGET（延迟预算）

LATENCY_BUDGET策略定义了数据从写入到可被读取的最大可接受延迟：

• 对于DataWriter：提示数据应该保留多久才被认定为过期
• 对于DataReader：提示应用程序期望的延迟上限

汽车应用提示：在自动驾驶场景中，感知数据的LATENCY_BUDGET通常设置为20-50ms，超过此时间的感知数据可能已失去决策参考价值。

3.1.4 TIME_BASED_FILTER（基于时间的过滤）

TIME_BASED_FILTER允许DataReader设置最小接收间隔，过滤掉过于频繁的数据更新：

// 示例：每秒最多接收10次数据（100ms间隔）
qos.time_based_filter.minimum_separation = 100000; // 100ms

此策略在以下场景特别有用：

• 数据源更新频率高于消费者处理能力
• 需要降低CPU负载或网络带宽占用
• 实现数据降采样

3.1.5 DESTINATION_ORDER（目标顺序）

DESTINATION_ORDER策略控制多个DataWriter写入同一Topic时的数据排序方式：

3.2 数据持久化类策略

3.2.1 DURABILITY（持久性）

DURABILITY策略控制数据的持久化级别，决定晚加入的DataReader能否获取历史数据：

图5：DURABILITY四级对比图

表2：DURABILITY四级对比矩阵

3.2.2 DURABILITY_SERVICE（持久化服务）

DURABILITY_SERVICE策略是DURABILITY的补充，用于配置持久化服务的具体参数：

struct DurabilityServicePolicy {
Duration_t service_cleanup_delay; // 清理延迟
HistoryQosPolicy history_kind; // 历史保留策略
int32 history_depth; // 保留深度
int32 max_samples; // 最大样本数
int32 max_instances; // 最大实例数
int32 max_samples_per_instance; // 每实例最大样本
};

3.3 数据管理类策略

3.3.1 HISTORY（历史管理）

HISTORY策略决定DataWriter和DataReader保留多少历史样本：

注意：KEEP_ALL模式可能导致内存无限增长，必须配合RESOURCE_LIMITS策略使用，设置max_samples等参数上限。

3.3.2 OWNERSHIP（所有权）

OWNERSHIP策略控制Topic的数据来源数量：

• SHARED（默认）：多个DataWriter可以同时写入，后写入的样本覆盖先前的
• EXCLUSIVE：每个Instance只接受一个DataWriter的数据，通过OWNERSHIP_STRENGTH确定优先级

// EXCLUSIVE所有权模式配置
qos.ownership.kind = EXCLUSIVE_OWNERSHIP_QOS;

// 当有多个Writer竞争时，按strength决定谁有效
qos.ownership_strength.value = 100; // 更高优先

3.3.3 PRESENTATION（呈现）

PRESENTATION策略控制数据在订阅端的组织方式：

3.4 资源管理类策略

3.4.1 RESOURCE_LIMITS（资源限制）

RESOURCE_LIMITS策略防止数据交换过程中资源无限增长：

struct ResourceLimitsQosPolicy {
int32 max_samples; // 最大样本总数
int32 max_instances; // 最大实例数
int32 max_samples_per_instance; // 每实例最大样本数
};

这些限制与HISTORY策略配合使用：当达到资源限制时，新样本的写入行为取决于HISTORY配置：

• KEEP_LAST：丢弃最旧的样本，保留最新的
• KEEP_ALL：拒绝写入新样本，等待消费

3.5 活性监控类策略

3.5.1 LIVELINESS（活性）

LIVELINESS策略确保参与通信的实体处于活跃状态：

3.5.2 LIVELINESS_LEASE_DURATION（活性租约时长）

LIVELINESS_LEASE_DURATION定义实体必须声明活性的最大时间间隔：

// 示例：5秒内未声明活性则视为离线
qos.liveliness.kind = MANUAL_BY_TOPIC;
qos.liveliness_lease_duration.duration = 5000000; // 5秒 in microseconds

4. Request-Offered语义与匹配机制

4.1 QoS兼容性矩阵

DDS中的QoS策略分为两类：

• RxO（Request-Offered）策略：DataWriter声明OFFERED值，DataReader声明REQUESTED值，需要双方兼容才能建立连接
• 独立策略：DataWriter和DataReader独立配置，无需匹配

图6：QoS Request-Offered匹配规则矩阵

表3：QoS策略RxO匹配规则汇总

4.2 分区（Partition）机制

PARTITION策略提供逻辑上的数据隔离机制，类似于"虚拟通道"的概念：

• 只有DataWriter和DataReader的PARTITION配置完全一致时才能建立连接
• 可以配置多个分区名称（通配符支持）
• 常用于实现服务实例隔离

// DataWriter配置
qos.partition.names = {"sensors.lidar", "sensors.camera"};

// DataReader配置 – 必须完全匹配才能通信
// 可以使用通配符
qos.partition.names = {"sensors.*"}; // 匹配所有sensors前缀

AUTOSAR AP应用：在ara::com中，PARTITION可以与Service Instance ID配合使用，实现不同服务实例的数据隔离。

4.3 内容过滤（Content Filter）

Content Filter允许DataReader在订阅端基于数据内容进行过滤，减少网络传输和应用程序处理负担：

// SQL风格的过滤表达式
content_filter.filter_expression = "x > 0 AND y < 100 AND intensity > 50";
content_filter.expression_parameters = {"param1", "param2"};

过滤在DataReader端执行，只有满足条件的样本才会传递给应用程序。这对于以下场景特别有价值：

• 感兴趣区域（ROI）过滤
• 阈值过滤
• 多区域选择

4.4 时间过滤（Time-Based Filter）

前文已介绍TIME_BASED_FILTER策略，此处补充其在实际应用中的典型配置：

5. 主流DDS实现方案对比

当前业界存在多个DDS实现方案，各有特色：

表4：主流DDS实现对比

5.1 RTI Connext DDS

RTI Connext DDS是商业DDS市场的领导者，被广泛应用于汽车、航空、医疗等高可靠性领域：

• 完整的QoS策略支持
• 丰富的工具链（System Designer, Monitor, Routing Service）
• 通过TUV SUD的ISO 26262认证
• 支持多种汽车通信协议网关

5.2 Eclipse CycloneDDS

CycloneDDS是Eclipse Foundation旗下的开源DDS项目，特点是：

• 轻量级设计，资源占用低
• 支持嵌入式平台（ARM, RISC-V）
• 与ROS2生态系统深度集成
• 活跃的开源社区

5.3 eProsima Fast DDS

Fast DDS（原名Fast RTPS）是ROS2的默认DDS实现：

• 完整的RTPS协议实现
• 内置DDS-XRCE协议支持（用于资源受限设备）
• 支持动态发现机制
• 提供Python绑定

6. DDS在汽车场景中的应用模式

6.1 传感器数据分发

在自动驾驶系统中，传感器数据分发是DDS最典型的应用场景之一。以下架构展示了从传感器到感知算法的完整数据流：

图7：DDS在自动驾驶数据流中的应用架构图

激光雷达点云分发

// 激光雷达点云发布者配置
PublisherConfig lidar_pub;
lidar_pub.qos.reliability.kind = RELIABLE;
lidar_pub.qos.durability.kind = TRANSIENT_LOCAL;
lidar_pub.qos.deadline.period = 100000; // 100ms
lidar_pub.qos.latency_budget.duration = 50000; // 50ms

// 点云数据结构
struct LidarPointCloud {
uint64 timestamp;
string frame_id;
uint32 point_count;
sequence<Point3D, 200000> points;
};

摄像头图像流分发

// 摄像头发布者配置
PublisherConfig camera_pub;
camera_pub.qos.reliability.kind = BEST_EFFORT; // 视频流可容忍丢帧
camera_pub.qos.history.kind = KEEP_LAST;
camera_pub.qos.history.depth = 2; // 仅保留最近2帧
camera_pub.qos.resource_limits.max_samples = 2;

6.2 决策结果广播

从感知到规划再到控制，DDS支撑了自动驾驶决策链条的数据传递：

• 感知融合结果：RELIABLE + TRANSIENT_LOCAL
• 轨迹规划结果：RELIABLE + RELIABLE
• 控制指令：RELIABLE + OWNERSHIP_EXCLUSIVE

关键设计：对于控制指令这类安全关键数据，建议配置OWNERSHIP为EXCLUSIVE，并设置较高的OWNERSHIP_STRENGTH，确保只有主控制器有权发布控制指令。

6.3 V2X场景扩展

车联网（V2X）场景中，DDS需要与外部车辆和基础设施通信。OMG制定了DDS-XRCE（DDS for eXtremely Resource Constrained Environments）协议来解决这一问题：

• DDS-XRCE Agent：运行在车载网关，连接传统DDS网络
• DDS-XRCE Client：运行在资源受限的OBU（车载单元）
• 通过UDP/TCP传输XRCE消息

// V2X数据分发配置
PublisherConfig v2x_pub;
v2x_pub.qos.reliability.kind = BEST_EFFORT; // V2X对延迟敏感
v2x_pub.qos.latency_budget.duration = 20000; // 20ms预算
v2x_pub.qos.transport_priority.high = true;

7. 总结与展望

本文深入解析了AUTOSAR AP中DDS数据分发服务的核心架构和QoS策略体系。DDS以其独特的"以数据为中心"的设计理念和丰富的QoS策略，为智能驾驶系统提供了强大而灵活的数据分发能力。

核心要点回顾

未来发展趋势

• TSN集成：DDS与时间敏感网络的深度融合
• 确定性网络：支持工业以太网、汽车以太网的确定性通信
• 边缘计算：DDS在边缘计算场景的应用扩展
• 安全增强：DDS-Security规范的深化应用

后续内容预告：AP-14将深入讲解DDS在AUTOSAR AP中的具体集成方法，包括ara::com的DDS绑定配置和代码示例；AP-15将分析DDS与AUTOSAR Classic Platform通信的桥接方案。

参考标准：

• OMG Data Distribution Service (DDS) v1.4
• OMG DDSI-RTPS (Real-Time Publish-Subscribe) v2.5
• AUTOSAR AP Release 20-11
• ISO 26262 Road vehicles – Functional safety

作者：汽车电子软件架构师，专注AUTOSAR、智能驾驶中间件技术

声明：本文为作者原创，转载需授权。