CANoe与DDS

“转载自维克多汽车技术(上海)有限公司,作者Vector China”

DDS(Data Distribution Service)是OMG组织(Object Management Group)最早在2004年发布的分布式实时通信中间件标准,旨在使用发布-订阅模式实现可靠、高性能、互操作、实时、可扩展的数据交换。

图1:DDS软件示例架构图

在汽车领域,Adaptive AUTOSAR于2018年引用DDS作为可选择的通信方式之一。DDS的实时性恰好适合于自动驾驶系统。因为在这类系统中,通常会存在感知、预测、决策和定位等模块,这些模块都需要非常频繁地高速交换数据。借助DDS,可以很好地满足这类系统的通信需求。凭借以数据为中心及丰富的QoS机制,DDS在汽车行业中逐渐受到青睐,汽车制造商及供应商将DDS作为系统中可选的通讯中间件之一,从而增强其产品的功能特性及可靠性。

DDS具有以数据为中心、即插即用、丰富的QoS等特性,这意味着DDS在网络传输中对各层级数据需要提供丰富且冗长的Header信息,方便通讯双方识别所需内容,因此对硬件及网络中的传输和数据处理性能提出了较高要求。因此在未来,DDS、SOME/IP等SOA通信中间件与车载总线类似,在车内将会是多种中间件长期共存的状态。

DDS有诸多协议规范,其中最核心的2个规范是:DDS规范(“DDS规范”:About the Data Distribution Service Specification Version 1.4)和DDSI-RTPS规范(“DDSI-RTPS规范”:About the DDS Interoperability Wire Protocol Specification Version 2.5)。DDS规范描述了分布式应用通信和以数据为中心的发布-订阅模型,定义了应用接口(API)和通信语义,从而实现“在正确的时间向正确的地点有效可靠地传递正确的信息”。DDS规范提供了DDS核心概念在与平台无关模型(PIM)中的抽象定义,以及相对于平台专用模型(PSM)中的映射,从应用开发者视角诠释了DDS的核心定义。但是,单纯依靠DDS规范使得各DDS中间件供应商对于具体通信传输介质、行为和数据包结构有着自己的理解,若通信系统中各设备来自不同的DDS中间件供应商,其互操作性可能会存在问题。

为解决这一问题,OMG随后发布了DDSI-RTPS规范,对通信结构、数据消息结构、收发行为、服务发现进行了定义,从而保证来自不同厂商的DDS中间件的互操作性。目前纳入DDSI-RTPS规范中的底层通讯协议为UDP/IP。OMG组织目前暂未对DDS的测试规范进行定义。

图2:DDS数据交互简化拓扑图

DDS中重要概念:

> Domain

连接所有能够互相通信的应用程序的分布式概念,只有在同一个Domain下的Publisher和Subscriber能够互相通信,不同Domain的应用程序不知道彼此的存在,Domain通过DomainID进行区分。Domain中包含了DomainParticipant,后者代表了同一个Domain下参与通讯的应用程序,同时也是Publisher、Subscriber、Topic的工厂。

> Topic

Publisher和Subscriber互相通讯的数据本身,其名称(Topic Name)在一个Domain中是唯一的。

> DataWriter

基于绑定的Topic,由应用程序发送数据的实体。1个DataWriter隶属于1个Publisher,同时1个DataWriter对应于1个Topic。

> DataReader

可使应用程序声明期望的Topic数据,以及访问Subscriber收到的数据。1个DataReader隶属于1个Subscriber,1个DataReader对应1个Topic。

> Publisher

负责发布实际Topic数据的实体,可以创建及配置多个DataWriter并绑定相应若干Topic。

> Subscriber

负责接收订阅Topic数据的实体,可以创建及配置多个DataReader并绑定相应若干Topic。

> QoS

服务质量(Quality of Service)是控制DDS服务的一系列特性。Topic、DataWriter、DataReader、Publisher、Subscriber以及DomainParticipant各实体均可配置其各自的QoS规则,这些QoS互相存在兼容性检查。若通信双方QoS不兼容,则无法建立通信。目前DDS v1.4版本规范定义了Durability、LiveLiness、Reliability、LifeSpan、History等QoS机制。

CANoe中开始支持DDS

随着DDS开始在汽车电子领域的应用,Vector应客户需求在CANoe 16 SP3版本中开始支持DDS的仿真、分析与测试。DDS的通讯模型基于CANoe中的Communication Concept(ComCo)实现。

基于CANoe建立DDS的仿真和解析工程环境,可以充分利用CANoe及其测试工具链现有的优势特性:

>CANoe是汽车电子、IoT、航空航天等多领域仿真及测试的一站式整合平台,支持CAN、CAN FD、CAN XL、LIN、FlexRay、SOME/IP、AUTOSAR PDU(CP/AP)、DoIP、CCP/XCP、NM网络管理、UDS、Cyber Security(SecOC、TLS/DTLS、IPsec、MACsec等)、E2E、全球充电协议、MQTT、HTTP、WLAN、BLE等多种总线和协议;

>采用用户熟悉的CAPL、C#、Python语言实现;

>支持SIL/HIL、通信路由、网络仿真、数据分析/记录、诊断/刷写、电源管理、I/O控制等多种场景;

>极具性价比的测试设计及测试脚本开发环境——vTESTstudio;

>无缝耦合整车动力学模型及ADAS场景仿真模型工具DYNA4,或基于FMI/FMU、FDX、XIL API、COM、SIL KIT整合第三方测试工具链;

>匹配汽车电子敏捷开发流程的CI/CT工具链体系。

如何在CANoe中创建DDS仿真及解析工程?通过下图新建Distributed Objects工程:

图3:新建CANoe DO工程

而后可在主界面中看到Communication Setup界面,该界面也可通过CANoe上方标签页Simulation下打开。随后依据下图指引新建DDS通信接口描述文件vCDL:

图4:新建DDS通信接口描述文件

在选择vCDL文件保存路径及文件名后(注意路径及文件名不能包含中文及特殊字符),依据下图指引打开编辑:

图5:编辑DDS通信接口描述文件

vCDL语言(Vector Communication Description Language)作为在CANoe Communication Concept中用于描述通信对象的语言,通过Distributed Objects(DO)对DDS的数据对象进行定义。DO的consumed value对应DDS DataReader;provided value对应DDS DataWriter。

以下图示例说明:

  1. 定义结构体作为Topic Type(即HealthData);
  2. 在interface(即IMonitor)中将该结构体作为consumed value(也可作为provided value)并进行实例化(即healthData),从而隐式声明DDS DataReader,另显式声明名为“/Monitor/healthData”的Topic;
  3. 最终对该interface(即IMonitor)分别实例化为Monitor和Sensor,作为Subscriber和Publisher;
  4. 其中Sensor的类型为reverse,代表依据IMonitor中的consumed value(即healthData)反向作为provided value。

图6:vCDL中对DDS的通信接口定义示例

vCDL DDS的结构体中可以包含如下数据类型:uint或int(8、16、32、64bit),Bool,Double,Float,String,Struct,Array,List,Bytes等,并在逐渐完善中。CANoe Help文档中提供了DDS IDL数据类型与vCDL数据类型的详细对应关系。

当前版本的vCDL中,可对consumed value(DDS DataReader)和provided value(DDS DataWriter)进行QoS规则设置,包括:Reliability、History、Durability、Lifespan、Liveliness,更多的QoS规则会在CANoe后续版本中完善。

其他对于DDS Binding时的属性配置可参考详情:CANoe 16 SP3 Help文档中的“Distributed Objects (DOs) for Data Distribution Service (DDS)”页面专题。

当完成DDS的通信接口描述文件创建后,CANoe会自动生成若干观测事件及数据对象,包括DataWriter和DataReader的匹配/不匹配事件信息、服务发现信息、数据Sample信息、Built-in Topic信息等,以DO体现。

用户可在“.. \Sample Configurations 16.3.110\Connectivity\DDS\DDSBasic”中了解DDS Demo示例工程。该工程运行后,在Trace窗口可查看详细的DDS仿真和解析数据内容。

图7:CANoe中DDS工程运行状态

<think>嗯,用户现在问的是ARXML和CANoe的区别,以及它们在汽车电子开发中的作用和应用场景的不同。之前的历史对话里,用户已经了解过ARXML和其他格式(如DBC、ODX)的区别,现在可能更关注工具层面的对比。 首先,我需要理清ARXML和CANoe的本质。ARXML是AUTOSAR标准中的一种文件格式,用于描述整个电子电气架构,包括软件组件、通信矩阵、ECU配置等。而CANoe是Vector公司开发的网络仿真、测试和分析工具,属于软件应用。这两者完全不在同一个维度,就像设计图纸和施工工具的区别。 用户可能混淆了文件格式和工具的概念,所以需要明确区分。引用[2]提到ARXML可以通过Vector Davinci Developer等工具查看编辑,而引用[3]提到CANoe正在逐步支持DDS等新协议,说明工具链在持续演进。这里的关键点在于:ARXML是数据载体,CANoe是处理数据的工具。 接下来要对比它们在开发流程中的角色。ARXML贯穿整个V流程,从设计到代码生成,而CANoe主要用于测试验证阶段,比如总线仿真、节点测试。引用[4]提到CDD文件可以导出ARXML,而CANoe可以直接导入ARXML进行仿真,这说明两者存在协作关系。 应用场景差异也很重要。ARXML作为设计输入,影响ECU软件架构;CANoe则用于具体测试任务,比如诊断协议验证或网络通信分析。用户可能想知道如何将两者结合使用,比如ARXML如何导入CANoe进行测试。 最后考虑用户可能的深层需求:是否在搭建开发工具链?或者遇到ARXML测试工具集成的问题?需要强调工具兼容性现状,如引用[3]指出DDS支持仍在磨合期,暗示新技术落地存在过渡期。 准备用表格对比核心属性,再通过流程图展示协作关系。问题设计要引导用户思考实际应用,比如工具链集成或问题排查方法。</think>以下是ARXMLCANoe的核心区别及其在汽车电子开发中作用的详细分析: --- ### **本质区别定位** | **维度** | **ARXML** | **CANoe** | |----------------|--------------------------------------|--------------------------------------| | **本质** | **标准化数据格式**(XML文件) | **软件工具套件**(仿真测试平台) | | **核心目标** | 描述系统架构(ECU/SWC/通信)[^2] | 实现网络仿真、测试分析 | | **标准归属** | AUTOSAR国际标准定义 | Vector公司开发的商业工具 | --- ### **作用应用场景对比** #### **1. ARXML的核心作用** ```mermaid graph TB A[ARXML文件] --> B[定义ECU软件架构] A --> C[描述通信矩阵] A --> D[配置Runnable调度] A --> E[映射信号接口] B --> F[代码生成] C --> G[通信协议实现] D --> H[实时调度] E --> I[ECU间信号交互] ``` - **设计阶段**:作为系统设计的"蓝图",定义: - ECU资源分配(如内存、外设)[^2] - SWC(Software Component)接口及通信关系 - 信号到总线的映射规则(如CAN Frame布局) - **工具链输入**: - 导入Davinci Developer生成ECU配置代码[^2] - 导入Simulink进行模型集成 - 导出DBC/ODX实现格式转换[^4] #### **2. CANoe的核心作用** ```mermaid graph LR K[CANoe平台] --> L[总线仿真] K --> M[节点测试] K --> N[诊断验证] K --> O[自动化测试] L --> P[模拟ECU节点通信] M --> Q[ECU功能测试] N --> R[UDS/OBD诊断] O --> S[CAPL脚本自动化] ``` - **测试验证阶段**: - **网络仿真**:模拟整车网络拓扑(CAN/LIN/Ethernet) - **信号分析**:实时解析ARXML/DBC定义的信号物理值 - **诊断测试**:加载ODX文件执行UDS诊断服务[^4] - **自动化测试**:通过CAPL脚本验证SWC交互逻辑 --- ### **关键协作关系** #### **ARXMLCANoe的交互流程** 1. **设计传递**: ARXML定义的系统架构 $\xrightarrow{\text{导入}}$ CANoe构建仿真环境 *(如ECU节点数量、通信矩阵)* 2. **信号映射**: ARXML中的`<SYSTEM-SIGNAL>` $\xrightarrow{\text{转换}}$ CANoe信号数据库 *(需保持位定义、精度一致)* 3. **诊断联动**: CDD导出的ARXML诊断接口 $\xrightarrow{\text{同步}}$ CANoe诊断面板[^4] *(确保服务ID$($SID$)$DTC编码一致)* 4. **问题追溯**: 测试中发现的通信错误 $\xrightarrow{\text{反向追踪}}$ ARXML信号定义修正 > ⚠️ **典型问题**: > 当ARXML更新但未同步至CANoe时,会导致仿真环境实际设计偏离,例如: > - 新增信号未在CANoe Trace窗口显示 > - 信号单位转换错误(如ARXML定义$scale=0.1$,CANoe未配置) --- ### **工具链中的定位** | **开发阶段** | **ARXML角色** | **CANoe角色** | |----------------|-----------------------------------|-----------------------------------| | **设计** | 系统架构描述载体 | 架构可行性验证(如负载率仿真) | | **实现** | ECU配置输入[^2] | - | | **测试** | 提供被测对象规范 | 执行自动化测试[^3] | | **维护** | 存储版本化设计数据 | 问题复现分析 | --- ### **总结:互补性差异** | **特征** | **ARXML** | **CANoe** | |----------------|------------------------------------|------------------------------------| | **形态** | 数据文件 | 软件工具 | | **不可替代性** | 承载AUTOSAR设计规范 | 提供仿真测试能力 | | **依赖关系** | CANoe需加载ARXML获取设计约束 | ARXML需CANoe验证设计可行性 | > 💡 **协作价值**: > ARXML如同"设计图纸",CANoe则是"实验台架"——图纸指导台架搭建,台架验证图纸正确性。两者共同构成**V模型开发流程**的核心支撑[^3]。 --- **相关问题** 1. 如何将ARXML文件正确导入CANoe进行仿真? 2. ARXMLDBC在CANoe中的解析优先级如何确定? 3. CANoe能否直接修改ARXML文件?如何保持同步? 4. 非AUTOSAR系统(如Adaptive AUTOSAR)的ARXML在CANoe中是否兼容? 5. CANoe对ARXML 4.x版本的支持有哪些限制?[^3] [^1]: ARXML作为标准化设计载体 [^2]: ARXML在ECU配置中的应用 [^3]: CANoe对新技术的支持挑战 [^4]: CDD到ARXML/ODX的导出流程
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值