CANdelaStudio制作CDD：UDS诊断数据库建库与ODX导出

简介这份PDF是Vector CANdelaStudio诊断数据库创建的入门课堂资料面向汽车电子诊断工程师、ECU软件开发与测试人员以及刚接触AUTOSAR诊断体系的初学者帮助读者理解如何借助CANdelaStudio定义ECU诊断需求、生成CDD文件并保证开发、测试、生产到售后各阶段诊断规范的一致性与数据复用。压缩包内仅1个PDF文件约2.31MB内容完整记录了课堂讲解要点。讲解围绕V-L模型展开梳理CDDT模板与CDD文件的区别、ViewStandardProAdmin四个版本的功能权限差异并深入Variant变体、Classes类、DID与DataType关联、DTC故障码库等文件结构同时给出新建工程、通信参数设置、DID创建与激活、DTC导入导出等实操路径配合实际操作界面截图便于对照练习。目前已有314人学习适合作为诊断数据库入门与工具上手速查材料。1. 为什么诊断调查表必须变成 CDD 才算数手上有十几页诊断调查表的工程师最容易掉进的坑是直接在 CANoe 里手写 CAPL 发报文能通就交差等 ECU 换一版、DID 加三个前面写的全废。CDDCANdelaStudio Diagnostic Description就是为这件事存在的把 UDS 服务、DID、DTC、会话和安全等级按树形结构固化成一份带 schema 约束的描述文件向下导出 ODX/PDX 交给测试向上生成 ECU 侧诊断栈代码让同一份诊断数据在工具链里只有一处来源。速成班第一课要讲清的不是菜单在哪而是先后顺序先定会话与安全等级骨架再挂 DID 和读写权限最后才是导出与校验顺序搞反改一个安全等级就要回头重挂几十个 DID。文章面向刚接手诊断模块的软件工程师、台架测试工程师以及被拉来写诊断规范的 ECU 负责人。2. 建库前的准备诊断调查表到 CANdelaStudio 工程骨架2.1 规范里的字段到底对应 CDD 的哪个对象“制作 cdd 文件”最常见的失败方式是把整张诊断调查表当成待填表单从第一行开始一条一条录入。实际上调查表里有一大半内容是在复述 ISO 14229 的标准行为比如 0x22 支持的否定响应码、0x10 各子功能的固有语义这些在 CANdelaStudio 自带的 UDS 模板里已经存在不需要重新定义。真正需要人为决策的只有三块DID 列表、DTC 列表、会话与安全矩阵。把这三块从规范里摘出来单独整理后面无论是录 GUI 还是写脚本导入都会快很多。规范里的字段映射到 CDD 的对象需要注意的点服务 ID0x10/0x22/0x2E/0x31Service优先用模板库勾选别手搓服务定义子功能 / 会话类型Session、SubFunction默认、扩展、编程会话的跳转依赖关系要一起定义安全等级 seed/keySecurity Level独立对象被服务引用不是会话的子节点DID 编号与含义Data Identifier编号统一成 4 位十六进制含义写进 LONG-NAME字节长度与类型DIAG-CODED-TYPE、BIT-LENGTH长度写位还是字节各版本模板不一致先看模板读写权限Service 与 DID 的关联关系只读 DID 不要挂到 0x2E否则导出后下游会误判DTC 与快照DTC、DTC Group、SnapshotOBD 类 DTC 与 UDS 类要分开建组提示调查表里的“备注”列几乎不会进数据库但“超时时间”“会话保持要求”这类描述往往藏在备注里摘录时别整列丢掉。2.2 新建 CDD 工程与导入通信参数的最小步骤常见做法是从模板起步而不是从空白文件起步。模板分两类工具自带的 UDS 基础模板.cddtCANdelaStudio Diagnostic Description Template以及 OEM 下发的企业模板。企业模板通常已经带好了诊断地址、时间参数和一部分标准 DID直接拿它当骨架能省掉最多返工。新建工程后按下面顺序走载入模板设置 ECU 名称与诊断层参数物理请求 ID、物理响应 ID、功能请求 ID。在通信参数里核对 ISO 15765-2 的 STmin、BlockSize以及 P2、P2× 时间。这几项如果和 DBC、ECU 实际值不一致后面 CANoe 里发什么都收不到回复。导入 DBC 或手工建立网络对象确认诊断报文使用经典 CAN 还是 CAN FD、是否启用扩展寻址。保存为工程文件同时立刻打一个基线版本第一版永远是最干净的参照物。整理 DID 列表这一步用脚本比手敲可靠。把调查表的 DID 页读出来规整成固定列后续导入、比对、生成校验脚本都用同一份数据import pandas as pd # 固定输出列后续所有脚本和比对都以这个顺序为准 COLS [did_hex, name, length, dtype, read_session, write_session, security] df pd.read_excel(诊断调查表.xlsx, sheet_nameDID) # DID 编号统一成 0x 加 4 位大写十六进制避免 F186 / 0xf186 / 61830 三种写法混用 df[did_hex] df[DID].apply(lambda x: f0x{int(str(x).replace(0x, ), 16):04X}) # 长度统一成字节数规范里写 bit 的列要在这里折算 df[length] (df[字节长度].astype(int)) out df[COLS].sort_values(did_hex) out.to_csv(did_list.csv, indexFalse, encodingutf-8-sig) # 顺手统计每个会话下挂了多少 DID权限矩阵是否合理一眼能看出来 print(out.groupby([read_session, security]).size())这段脚本的关键不在 pandas 语法而在于把所有 DID 强制归一成同一格式编号补零到 4 位、长度折算成字节。encodingutf-8-sig是为了让 Excel 打开 CSV 时不乱码方便规范和工程两边对照着看。最后那句groupby是给权限矩阵做体检——如果某个扩展会话下挂了 200 个 DID通常说明规范把权限写宽了值得回头确认。2.3 命名规范与版本管理别让 CDD 变成一次性文件CDD 本质是文本格式的 XML这一点决定了它可以用 Git 管但直接提交未格式化的文件会让 diff 没法看因为工具的保存顺序不固定。务实的做法是约定一套命名规范再在提交前统一格式化。命名规范至少要覆盖三层DID 用DID_编号_含义服务对象用标准名加子功能DTC 用编号加故障描述缩写。短名SHORT-NAME一旦被导出成 ODX 或生成代码再改就会牵动上游所以短名要在建库第一版就定死。# 提交前格式化保证 diff 按行比较而不是整文件重排 xmllint --format current.cdd -o current.pretty.cdd # 与基线做结构性比对只看增删和关键属性变化 git diff --no-index --stat baseline/cdd.pretty.cdd current.pretty.cddxmllint --format只做缩进重排不改语义适合放进提交前的手工步骤里。--stat先给出改动规模几千行的改动如果集中在某一段多半是有人用 GUI 批量重排了对象顺序而不是真的加了内容这种提交最好退回重做。把格式化后的版本和原始文件都留在仓库里评审时看格式化版本生成代码时用原始文件。3. 做出第一个能跑通的 CDD会话、安全、DID 三步走3.1 先定会话与安全等级再谈 DID会话和安全等级是 CDD 的骨架DID 是挂在骨架上的叶子。骨架没定好就录 DID等于把权限判断抄了几十遍。典型乘用车的会话划分如下表实际项目会增减但层级关系基本一致。会话进入方式典型用途关联安全等级Default上电默认 / 0x10 01读 DTC、读基本标识无Extended0x10 03写配置、例程控制、读标定Level 10x27 01/02Programming0x10 02刷写、擦除、校验Level 20x27 11/12Supplier0x10 60产线标定、工程调试Level F自定义注意安全等级是独立对象被服务引用不是会话的下级。把它建成会话的子节点导出 ODX 时层级会错乱DiVa 用例也会找不到对应的解锁状态。另外要确认会话之间的跳转是否被允许。多数 ECU 要求先进入扩展会话再进编程会话直接跳会被拒绝并回 0x7F 0x10 0x22条件不满足。这一条在 CDD 里体现在会话对象的跳转属性上不是靠后续代码补。3.2 定义 DID 与数据类型0x22 和 0x2E 的权限怎么挂一个 DID 对象至少要描述四件事编号、长度、数据类型、可读写的服务。数据类型的选择直接决定导出后上位机怎么解析ASCII 字符串型适合 VIN、零件号这类定长文本无符号整型要同时确认字节序UDS 默认大端但个别规范会写成小端写错了现象是读出来的数值“看起来对但反过来”。多字节记录型record适合把几个信号打包在一个 DID 里代价是位定义要一条条对齐。批量生成 DID 定义块比在 GUI 里逐条新建快得多下面这段把 CSV 转成结构片段元素名以你手上 CANdelaStudio 版本生成的模板为准复制前先对着模板确认一遍import csv TEMPLATE DATA-IDENTIFIER ID{name} SHORT-NAME{name}/SHORT-NAME LONG-NAME{desc}/LONG-NAME DIAG-CODED-TYPE{dtype}/DIAG-CODED-TYPE BIT-LENGTH{bits}/BIT-LENGTH /DATA-IDENTIFIER with open(did_list.csv, encodingutf-8-sig) as f: rows list(csv.DictReader(f)) blocks [] for r in rows: blocks.append(TEMPLATE.format( namefDID_{r[did_hex][2:]}, descr[name], dtypeASCIISTRING if r[dtype].upper() ASCII else A_UINT32, bitsint(r[length]) * 8, # CSV 里是字节CDD 里按位填 )) open(did_blocks.xml, w, encodingutf-8).write(\n.join(blocks)) print(f生成 {len(blocks)} 个 DID 定义块)bits由字节乘以 8 得到这是最容易出错的一步——长度少填一半ECU 回的报文会被上位机截断现象是“读得到但值不对”。数据类型映射用一个 if 就够规范里出现新类型时手工加分支别写成模糊匹配。生成完定义块还要逐个把 DID 关联到服务上读操作挂到 0x22 的 DID 列表里写操作挂到 0x2E同时勾选允许的会话和安全等级。同一个 DID 被多个会话引用时实际权限取交集所以宁可在一个会话下多勾也不要在两个会话下互相矛盾。3.3 服务对象实操从 0x22 读 VIN 开始第一个能验证成果的闭环是读 VIN。步骤是在 0x22 服务下新增 DID 引用选 F186勾选 Default 会话不要求安全等级保存后导出 ODX在 CANoe 里发 22 F1 86收到 62 F1 86 加 17 字节 VIN 就算通。其余服务按同样套路扩展常见坑集中在下面这张表。服务常用子功能典型对象是否要安全常见坑0x1001/02/03/60会话否02 与 03 的跳转顺序有依赖直接跳会被拒0x2701/02、11/12安全等级否seed/key 长度与规范不一致奇数长度要确认补位规则0x22无DID视 DID权限取交集两个会话勾选矛盾时行为不可预期0x2E无DID通常要写长度与定义长度不符ECU 回 0x130x3101 开始Routine通常要例程结果要定义在返回参数里否则测试拿不到结果码0x1902/04/06DTC、DTC Group视状态掩码定义不全查询返回空建到 0x19 这一层时DTC 的分组策略要提前想清楚排放相关、安全相关、通信类各建一组后面做快照和扩展数据才有地方挂。DTC 只填编号不填状态掩码是“制作 cdd 文件”过程中最常见的返工来源。4. 从 CDD 到上车导出 ODX、生成诊断代码与一致性校验4.1 导出 ODX/PDX 时该选哪些参数ODX 是交付给测试和产线的中间格式导出参数选错测试侧就得反工。三个参数最需要确认ODX 版本、是否包含 ECU-VARIANT、通信参数是否随包导出。参数可选项选择依据ODX 版本2.0.1 / 2.2.0跟随客户或测试工具要求的版本不要自行升级ECU-VARIANT包含 / 不包含多配置 ECU 必须包含否则诊断描述覆盖不全通信参数导出 / 不导出DiVa 自动化测试需要纯台架手测可以省PDX 打包单文件 / 目录交付统一用单文件中间调试用目录便于定位提示每次导出都用「项目名_日期_版本号」命名并归档覆盖导出是“昨天还能用今天打不开”这类问题的头号原因。4.2 生成 ECU 侧诊断栈代码时CDD 里哪些属性会被带下去诊断栈代码生成器读取的是 CDD 里的服务表、DID 长度、NRC 列表和时间参数。这意味着改 CDD 就等于改代码接口DID 长度变了生成的结构体成员跟着变手写业务代码引用了旧成员就会编译失败。稳妥的做法是把生成目录和业务代码目录严格分开生成目录整体纳入版本管理但不手工编辑业务侧只调用生成出来的接口。CDD 变更后重新生成、编译、跑一遍回归三步不能省。时间参数尤其容易漏。P2、P2×、S3 这几个值在 CDD 里是一处配置、三处生效ECU 侧诊断栈的定时器、测试工具的等待时间、DiVa 判定超时的阈值。三处不一致表现就是“手工测能过自动化跑就挂”。4.3 用脚本做一次 CDD 与真实 ECU 的一致性校验导出前先在台架上做一遍自动比对比出了车间题再查要省事得多。用 python-can 加 ISO-TP 和 UDS 客户端库把第 2 章生成的did_list.csv当作期望值逐个 DID 读回来比对长度import csv import can import isotp import udsoncan from udsoncan.connections import PythonIsoTpConnection from udsoncan.client import Client # 这几个超时值必须与 CDD 中诊断层的配置一致单位秒 config { request_timeout: 5.0, p2_timeout: 0.05, p2_star_timeout: 5.0, exception_on_negative_response: False, # 不抛异常便于打印 NRC 比对 } bus can.interface.Bus(channelcan0, bustypesocketcan, bitrate500000) # txid/rxid 必须与 CDD 里的物理请求、物理响应 ID 对应 conn PythonIsoTpConnection(isotp.TransportLayer(txid0x7A0, rxid0x7A8, busbus)) with open(did_list.csv, encodingutf-8-sig) as f: expect {r[did_hex]: int(r[length]) for r in csv.DictReader(f)} with Client(conn, configconfig) as client: for did_hex, exp_len in expect.items(): did int(did_hex, 16) resp client.read_data_by_identifier(did) if not resp.valid: print(f{did_hex} NRC{resp.service_data}) continue actual len(resp.service_data.values[did]) flag OK if actual exp_len else LEN-MISMATCH print(f{did_hex} 期望{exp_len} 实际{actual} {flag})这段代码有三个地方值得说明。exception_on_negative_response设为 False是为了把 ECU 返回的否定响应码原样打印出来而不是被库当异常吞掉——NRC 本身就是重要信息0x31 说明会话不对0x13 说明长度不对指向的问题完全不同。txid/rxid要与 CDD 中定义的诊断地址严格对应搞反了根本收不到帧。超时值那一组参数必须和 CDD 一致否则台架上偶发的超时会被误判成 ECU 问题。较新版本的 udsoncan 用配置对象替代了字典写法参数语义相同按实际版本调整即可。跑完这一轮长度不匹配的 DID 要么是 CDD 写错了要么是 ECU 实现和规范不一致两种情况的处理方式完全不同但至少定位范围被压缩到了具体编号上。5. CDD 增量维护差异比对与报错定位的具体手法5.1 四类高频报错先查哪里改完 CDD 出问题先别急着回滚。下面四种现象覆盖了日常维护的大部分时间现象大概率原因先查哪里导出 ODX 报校验失败某 DID 长度与数据类型冲突检查 BIT-LENGTH 与 DIAG-CODED-TYPE 是否自洽发 0x22 返回 0x7F 0x22 0x31当前会话不满足该 DID 的权限检查该 DID 在 0x22 下勾选的会话生成代码重复定义短名冲突全局搜 SHORT-NAME重点看复制粘贴出来的对象DiVa 用例批量失败通信参数与 DBC 不一致比对 STmin、BlockSize 与诊断报文 ID批量失败基本不用看用例本身先怀疑数据库侧的公共参数这是排查顺序上的经验。5.2 用 XPath 拉出对象清单做差异比对两个版本的 CDD 谁删了哪个 DID、谁加了个新服务用文本 diff 看不清。把短名清单单独拉出来比对几十秒就能定位# 分别抽取两次版本的短名清单排序后做差异比对 xmllint --xpath //SHORT-NAME/text() new.cdd | tr \n | sort new_names.txt xmllint --xpath //SHORT-NAME/text() old.cdd | tr \n | sort old_names.txt diff old_names.txt new_names.txtXPath 里的//SHORT-NAME会命中所有层级的短名包括服务、DID、DTC 和数据类型所以输出清单同时反映了“新增对象”和“改名对象”两类变化。改名在清单里会表现为一删一增如果确认是改名而不是新增就要顺带检查上游代码里的引用——短名改成 ODX 和生成代码后就是接口名一处改名可能要改几十处调用。把这两条命令放进仓库的 tools 目录每次提交 CDD 前跑一次比事后翻 CHANGELOG 有效得多。本文还有配套的精品资源点击获取