BUSMASTER UDS 诊断面板使用教程

BUSMASTER 经典回顾 - UDS 诊断面板使用教程

前两篇文章中，我们介绍了 BUSMASTER 的基础收发，以及 ASC/BLF/LOG 文件的录制、查看和播放。实际项目调试中，另一个很常见的需求是对 ECU 做 UDS 诊断，例如进入扩展会话、读取 DID、执行安全访问，或者下载 HEX 文件。

官方开源版本 BUSMASTER 原本也提供了诊断相关功能，但整体比较基础。霸码科技在维护 BUSMASTER 的过程中，进一步补充了更贴近实际项目的 UDS 使用能力，包括服务列表、参数化请求模板、自动安全访问解锁、HEX 下载、CAN FD 诊断等。本文就以一个实际演示界面为例，介绍如何在 BUSMASTER 的 Diagnostics / UDS 面板中完成常见诊断操作。

Diagnostics 入口位于 CAN 页面工具栏中。打开诊断面板之前，仍然建议先完成基础 CAN/CAN FD 通道配置：驱动选择、硬件通道映射、波特率、终端电阻、工作模式等都应先确认无误。基础收发配置可以参考前一篇基础收发教程。

1. 先认识 UDS 主诊断窗口

打开 Diagnostics 面板后，主窗口可以按几块理解。

图中几个区域的含义如下：

1. Services：左侧 UDS 服务树。这里整理了常见标准服务和示例请求，可以展开服务节点后直接选择或双击请求模板。
2. Request：当前诊断请求区域。这里可以确认通道、CAN ID，也可以直接编辑 Data Bytes (Hex) 后发送。
3. 辅助功能区：包括 SecurityAccess 自动解锁、Tester Present 会话保持、HEX 文件下载等功能入口。
4. Response 和 Log：用于查看正响应、负响应、响应数据，以及每次诊断操作的历史记录。

实际调试时，左侧服务树、右侧请求区、下方响应日志通常会一起使用：先从服务树选择请求，再根据项目参数修改数据，发送后从响应区和日志区确认结果。

2. 使用服务树模板发送标准 UDS 请求

左侧服务树是 BUSMUST 维护版本 Diagnostics 的重点增强功能。它按照 UDS ISO 标准服务设计和实现，不只是让用户手动输入 10 03、22 F1 90 这类原始十六进制数据，而是把 UDS 服务整理成可展开、可选择、可参数化的请求模板。

服务树中包含 UDS 约定的全部服务，其中常见服务的入口包括：

• DiagnosticSessionControl (0x10)：默认会话、编程会话、扩展会话。
• ECUReset (0x11)。
• SecurityAccess (0x27)：requestSeed / sendKey。
• TesterPresent (0x3E)。
• ReadDataByIdentifier (0x22)。
• WriteDataByIdentifier (0x2E)。
• RoutineControl (0x31)。
• RequestDownload (0x34)、TransferData (0x36)、RequestTransferExit (0x37)。

对于 ReadDataByIdentifier、SecurityAccess 这类可能包含大量 DID 或安全等级的服务，默认模板只预置了一些常见条目。项目中实际使用的 DID、安全等级、Routine ID 等内容，可以在后文介绍的服务树维护功能中继续添加、编辑、导入和导出。

典型操作方式是：展开目标服务，双击现成请求后直接发送；如果只是单击选中某个请求，可以在左下角的属性明细区域查看并编辑这个条目的名称、参数、描述等内容。

如果项目中需要发送模板里没有预置的合法请求，更推荐在左侧服务树中基于对应服务新增条目。例如新增一个项目自定义 DID，或者新增一个项目特定的 Routine，只需要在属性区编辑 DID、Routine ID、参数说明等字段，其他默认字节仍然由模板保留。这样做比在右侧直接手写完整 payload 更适合长期维护，也更适合团队共享。

例如图中的演示流程是：先发送 10 03 进入扩展会话，再执行 27 服务自动解锁，随后读取 DID。这样的流程如果完全手写十六进制数据，也可以完成；但使用服务树模板后，更容易减少手工拼写 payload 的错误。

3. 自动保持会话：Tester Present 3E

诊断会话进入扩展会话或编程会话后，如果长时间没有诊断通信，ECU 可能自动回到默认会话。Tester Present 用于周期性发送 3E 服务，保持当前诊断会话。

在完整诊断流程中，Tester Present 经常和扩展会话、安全访问、下载流程配合使用，因此建议在需要长时间保持非默认会话时同步检查这一项配置。

在主诊断窗口中勾选 ON/OFF 后，软件会按配置发送 Tester Present。相关周期、功能寻址、不要求正响应等参数，可以在 Diagnostics Settings 中进一步配置。

如果现场出现“刚进入扩展会话，过一会儿又退回默认会话”的情况，Tester Present 是优先需要检查的功能之一。

4. 自动解锁：SecurityAccess 27

UDS 27 安全访问通常包含两步：

1. 发送 requestSeed，例如 27 01、27 03、27 11 等。
2. 根据 ECU 返回的 seed 计算 key，再发送对应等级的 sendKey，例如 27 02 ...、27 04 ...、27 12 ... 等。

27 服务真正麻烦的地方不只是计算 key，而是 requestSeed 和 sendKey 之间通常存在超时限制。如果手动复制 seed，再切到外部工具计算 key，最后再填回 sendKey，请求很可能已经超时，ECU 会拒绝本次安全访问。BUSMASTER 的 UDS 面板支持配置 Key-Gen DLL 后自动完成 seed/key 计算和发送，避免因为 requestSeed 和 sendKey 间隔超时导致解锁失败。

在 Settings 中选择安全算法 DLL 后，回到主诊断窗口选择目标安全等级，点击 Unlock，软件就会按对应等级执行 seed/key 解锁。

UDS 27 的 seed/key 算法通常不是通用算法。Key-Gen DLL 一般来自三种途径：

• 项目客户或主机厂直接提供。
• 主机厂提供 seed/key 算法文档，工程师根据 BMAPI SDK 中的 UDS Security DLL 模板工程实现并编译。
• 从已有 CANoe 工程中复用安全访问 DLL。CANoe 使用的 DLL 接口与 BUSMASTER 这里的 DLL 兼容。

这里要注意三点：

• 自动解锁是否成功，取决于 ECU 当前会话、安全等级、DLL 算法和 ECU 的重试间隔。
• 如果 ECU 要求先进入扩展会话或编程会话，应先发送 10 03 或项目要求的会话控制请求。
• 自动解锁不是“破解 ECU”，它只是按项目授权提供的 seed/key 算法，自动完成 UDS 27 服务交互。

5. 自动 HEX 下载：34 / 36 / 37

UDS 下载通常涉及三个基础服务：

• 34 RequestDownload：请求下载，携带地址、长度等信息。
• 36 TransferData：分块传输数据。
• 37 RequestTransferExit：传输结束。

BUSMASTER 的 UDS 面板提供 Download HEX File 区域，可以选择 HEX 文件并触发下载流程。软件会解析 Intel HEX 文件中的地址和数据内容；如果 HEX 文件内存在多个地址不连续的数据段，软件会按段拆分，并根据需要自动组织多轮 34 RequestDownload、36 TransferData、37 RequestTransferExit 服务交互。

也就是说，这个功能的重点不是简单发送一次 34 / 36 / 37，而是把 HEX 解析、地址分段、数据切块和 UDS 下载服务组合起来，完成更接近实际项目的 HEX 下载操作。本文只介绍这个入口和基本用途，不展开刷写策略、擦写流程、校验 Routine、Bootloader 状态机等更复杂内容。实际项目中，是否需要先进入编程会话、是否需要先解锁、下载地址和长度如何填写，都应以 ECU Bootloader 设计和项目规范为准。

6. 手动编辑诊断请求

服务树模板适合发送项目中长期维护的标准请求，但诊断调试中仍然经常需要临时手动改请求。

手动编辑有两类典型用法。

第一类是临时发送原始 UDS payload：选择 Channel，确认或填写 CAN ID，在 Data Bytes (Hex) 中输入请求，例如 22 F1 90，然后点击 Send。这种方式不会修改左侧服务树，适合一次性验证、临时试验，或者故意构造 UDS 级别的异常请求。

第二类是基于模板修改：先从左侧服务树双击或选择一个现成请求，让软件自动生成基础 payload，再在 Data Bytes (Hex) 或属性区里修改 DID、子功能或数据，最后发送。如果这个请求后续还会反复使用，建议回到左侧服务树中通过 Add 新增条目并保存，而不是每次都在右侧手写。

右侧手动编辑还适合制造一些“正确传输、但 UDS 内容故意错误”的测试场景，例如不存在的服务、非法子功能、错误长度的 31 RoutineControl 请求等。需要注意的是，诊断面板底层仍然会按标准 ISO-TP 发送；如果要故意构造 ISO-TP 流控层面的错误报文，就不再适合使用 UDS 面板，而应回到底层 Message / Transmit Window 逐帧构造。

7. 查看响应、日志和底层报文

发送请求后，可以从几个位置判断结果。

Response 区域会显示正响应或负响应说明，并显示响应长度和响应数据。多帧响应会显示合并后的诊断数据。Log 区域会记录每次诊断服务的发送请求和响应结果，适合确认操作顺序，例如先进入扩展会话，再执行安全访问，再读取 DID。

Message Window 则用于查看底层 CAN / CAN FD 报文。这里可以看到 ISO-TP 单帧、多帧、流控帧以及实际 Tx/Rx 数据。遇到诊断无响应、多帧失败或 ECU 返回异常时，Message Window 往往比上层诊断界面更适合做底层定位。

8. Diagnostics Settings 配置说明

Diagnostics Settings 是 UDS 通信的基础配置。如果这里的 ID、寻址方式或 ISO-TP 参数不正确，前面介绍的服务树、自动解锁、手动发送都可能没有响应。

图中几个区域可以按下面理解：

1. 诊断标准和寻址方式
   Diagnostic Standard 通常选择 UDS (ISO 14229)；Interface 按 ECU 项目要求选择，例如 11bits Normal、11 位扩展寻址或 29 位寻址。

2. 诊断 CAN ID 和填充参数
   Request to ECU 是诊断请求 ID，Response from ECU 是 ECU 响应 ID，Functional Addr. 是功能寻址 ID。Padding byte 用于强制填充到最大 DLC 时指定填充值。

3. ISO-TP 参数
   STmin、BlockSize、Flow Control Length 与多帧诊断通信有关。单帧请求能正常工作，但多帧请求或多帧响应异常时，可以重点检查这里。

4. 超时和会话保持参数
   P2 Time Out 是等待 ECU 响应的基础超时时间；P2 Extended 用于 ECU 返回 78 response pending 后继续等待；S3 Client、S3 Server 与 Tester Present 和会话超时有关。

5. 安全访问 DLL
   Key-Gen DLL 用于 UDS 27 seed/key 解锁；GenerateKey custom option string 可以向解锁 DLL 传入项目自定义参数。

CAN FD 诊断场景下，还需要关注 CAN-FD Request、Max payload bytes、FD、BRS 等选项。这些配置应与 ECU 项目的诊断要求保持一致。

9. 维护服务树：新增 DID、导入和导出

服务树可以按项目维护。对于一个具体 ECU 项目，建议团队维护同一份 XML 配置，把这个 ECU 支持的 DID、Routine、安全等级、下载模板等内容提前整理好。这样大部分日常诊断操作都可以通过双击模板发送完成，而不需要每位工程师都重复手写诊断请求。

以新增一个固定 DID 读取项为例，典型操作是：

1. 在左侧选择合适服务，例如 ReadDataByIdentifier (0x22)。
2. 点击 Add 新增条目。
3. 在下方属性区填写名称和 DID，例如 F190 或项目自定义 DID。
4. 点击 Save 保存；需要立即验证时，可以点击 Save and Send。

团队协作时，可以通过 Export 导出服务树配置，再由其他工程师 Import 导入。它的定位有点类似 Vector CDD 在诊断项目中的作用：把“这个 ECU 支持哪些诊断服务、每个服务有哪些常用参数”沉淀成项目资产；只是 BUSMASTER 这里采用的是更轻量的 XML 配置方式。

10. 常见问题排查

10.1 发送后没有响应

先不要急着排查 UDS 本身，建议先确认基础收发是否正常：例如在 Transmit Window 中手动发送一帧普通 CAN / CAN FD 报文，确认硬件通道、波特率、终端电阻、接线和 ECU 上电状态没有问题。

基础链路确认正常后，再检查 UDS 级别的配置：通道号、请求 ID、响应 ID、寻址方式、功能寻址 ID、填充字节等是否符合项目要求。如果项目使用 CAN FD 诊断，还要确认 CAN-FD Request、FD、BRS、最大 payload 等选项是否与 ECU 约定一致。有些 ECU 会明确要求 CAN FD 报文，或者只接受特定的 BRS 配置。

如果上层诊断界面没有响应，建议同时看 Message Window：先确认诊断请求是否真的发出，再确认是否有 ECU 响应帧回来。这样可以把问题分成两类：一类是硬件连接、波特率、总线状态等基础通信问题；另一类才是诊断 ID、寻址方式、ISO-TP 或 ECU 服务支持范围的问题。

10.2 单帧可以，多帧失败

单帧请求可以，多帧请求或多帧响应失败时，重点检查 ISO-TP 参数，例如 STmin、BlockSize、Flow Control Length。

如果是 CAN FD 诊断，还要检查 Max payload bytes、FD、BRS 等设置是否与 ECU 要求一致。部分项目中，经典 CAN 单帧诊断正常，并不代表 CAN FD 多帧诊断参数也一定正确。

10.3 解锁失败

解锁失败时，先确认是否已经进入正确诊断会话，再确认安全等级是否选对。随后检查 Key-Gen DLL 是否匹配当前 ECU 项目，以及是否触发了 ECU 的安全访问重试间隔或锁定时间。

如果 ECU 已经返回 seed，但 sendKey 后仍然失败，通常要重点检查算法 DLL、输入参数和安全等级对应关系。

结尾

Diagnostics / UDS 面板把常见诊断操作集中在一个界面中：标准服务可以从服务树模板选择，会话保持、自动解锁和 HEX 下载可以由界面辅助完成，临时请求也可以手动编辑。对于售后支持、产线测试、ECU 调试和重复性诊断流程，它比纯手写十六进制请求更直观，也更适合沉淀项目模板。

掌握这些基础功能后，BUSMASTER 就不只是报文收发工具，也可以承担常见 ECU 诊断、调试和刷写前验证工作。

如果项目需求进一步复杂，例如需要把会话切换、安全访问、擦除、下载、校验、复位等步骤编排成完整自动化流程，更推荐使用 BMAPI SDK 做二次开发。对于 Python 用户，也可以关注霸码科技提供的 python-udsoncan 这个专用的 UDS 库，用脚本实现更灵活、更定制化的诊断或 Bootloader 下载流程。这类自动化开发属于 SDK 使用范畴，不在本文展开。

---

安装或升级 BUSMASTER、查找历史版本时，请前往下载中心。