1. 课程导入

当你把诊断仪插上OBD接口,几秒钟后屏幕上跳出故障码、冻结帧、ECU版本信息,甚至能远程刷写一个控制器的固件——这背后并不是一根线在“说话”,而是一整套分层、分角色、分协议的通信与传输体系在协同工作。AUTOSAR诊断通信与传输工程,研究的正是这套体系如何被标准化地设计、配置、实现与验证。

本课程面向汽车电子软件工程师、诊断系统开发人员、测试与集成工程师,目标不是让你记住某个API的名字,而是建立一条从“诊断需求”到“总线报文”再到“ECU内部服务”的完整链路认知。学完本课程,你应当能够读懂诊断规范中的通信栈描述,理解UDS服务如何被封装进CAN/CAN FD/DoIP报文,掌握诊断传输层的时间参数与流控机制,并能在AUTOSAR配置工具中定位关键参数。

核心判断:诊断通信不是“发一条请求、收一条响应”这么简单。它至少涉及应用层服务、会话与安全状态、传输层分包与重组、网络层寻址、数据链路层帧格式,以及ECU内部的诊断事件管理。任何一层配置错误,都会表现为“诊断仪连不上”或“服务超时”。

一、汽车电子诊断背景:从OBD到AUTOSAR诊断栈

早期车载诊断以OBD-II为主,关注排放相关故障的标准化读取。随着电子控制单元数量增加、软件复杂度上升,诊断需求扩展到生产下线检测、售后维修、OTA升级、法规合规与网络安全。ISO 14229(UDS)定义了统一诊断服务,ISO 15765-2(CAN TP)和ISO 13400(DoIP)分别解决CAN与以太网上的传输问题。AUTOSAR则把这些标准组织成可配置的软件模块,形成诊断通信栈。

在AUTOSAR经典平台中,诊断栈通常包含DCM(Diagnostic Communication Manager)、DEM(Diagnostic Event Manager)、FIM(Function Inhibition Manager)、DET(Development Error Tracer)以及底层通信模块。DCM负责服务调度与会话管理,DEM负责故障事件与故障码存储,传输层则由CanTp、DoIP、SoAd等模块承担。理解这些模块的职责边界,是后续配置与排障的基础。

二、核心概念:诊断通信中的五个关键对象

  • 诊断服务:如0x10会话控制、0x27安全访问、0x22读数据、0x2E写数据、0x31例程控制、0x19读故障码。服务由SID和子功能组成。
  • 诊断会话:默认会话、编程会话、扩展会话。不同会话下可执行的服务集合不同,会话切换有超时约束。
  • 安全等级:通过种子-密钥机制解锁,防止未授权写入或例程执行。
  • 传输层:负责将超过单帧长度的诊断数据拆分为多帧,并处理流控、序号、超时与错误恢复。
  • 诊断事件:ECU内部监测到的故障状态,经DEM处理形成DTC、冻结帧与扩展数据。

这五个对象之间不是并列关系,而是存在明确的依赖与约束。例如,安全访问必须在非默认会话下进行;编程会话通常要求先解锁安全等级;传输层超时会导致DCM向诊断仪返回否定响应。把这些关系画成一张结构图,比逐条背诵更容易形成系统认知。

AUTOSAR诊断通信与传输工程整体框架 诊断仪 / 测试端 UDS请求与响应 OBD / DoIP / CAN 应用层:UDS / OBD服务 0x10会话 · 0x27安全 · 0x22/0x2E数据 · 0x31例程 · 0x19故障码 DCM服务调度 · 会话与安全状态机 ECU内部诊断管理 DEM事件与DTC FIM功能抑制 传输层:CAN TP / DoIP / SoAd 单帧 · 首帧 · 连续帧 · 流控帧 · 序号与超时 网络层与数据链路层 CAN / CAN FD / Ethernet · 寻址与路由 物理总线 双绞线 / 以太网线束 配置与验证 参数 · 测试 · 诊断规范 事件触发诊断 请求下发 学习主线:诊断需求 → 服务设计 → 传输配置 → 总线映射 → ECU集成 → 测试验证 关键约束:会话状态 · 安全等级 · 传输超时 · 寻址方式 · 并发诊断连接

三、方法流程:从诊断需求到可运行配置

一个典型的诊断通信开发流程可以概括为六步。第一步,梳理诊断需求:确定需要支持哪些UDS服务、哪些DTC、哪些会话与安全等级。第二步,设计诊断数据库:通常以ODX或CDD文件描述服务、参数、寻址与传输属性。第三步,配置AUTOSAR诊断栈:在工具中设置DCM服务表、会话超时、安全算法、DEM事件映射。第四步,配置传输层:设置CanTp的块大小、STmin、N_As/N_Ar/N_Bs/N_Br等时间参数,或配置DoIP的连接与路由。第五步,集成与生成代码:将配置导入ECU工程,生成诊断栈代码并编译。第六步,测试验证:使用诊断仪或自动化脚本验证服务响应、超时行为、故障码读写与安全访问。

典型诊断请求链路(CAN TP):
诊断仪 → 0x7DF功能寻址 → ECU收到首帧FF → 回复流控帧FC
→ 诊断仪发送连续帧CF → ECU重组完整UDS请求
→ DCM调度服务 → 生成响应 → CanTp分包 → 诊断仪接收

关键时间参数示例:
N_As = 1000 ms  发送方网络层超时
N_Ar = 1000 ms  接收方网络层超时
N_Bs = 1000 ms  等待流控帧超时
N_Cr = 1000 ms  等待连续帧超时
STmin = 10 ms   连续帧最小间隔
BlockSize = 8   每8帧等待一次流控

四、案例与场景:一次“诊断仪连不上”的复盘

某项目在台架测试时,诊断仪发送0x10 0x03进入扩展会话,ECU无响应。排查发现:CANoe中诊断请求使用物理寻址0x7E0,而ECU配置的功能寻址为0x7DF,物理寻址为0x7E0,看似正确。进一步检查CanTp配置,发现N_Bs设置为0,导致ECU在发送首帧后不等待流控帧,直接认为传输失败。修正N_Bs为1000ms后,会话切换正常。这个案例说明:诊断通信故障往往不在应用层,而在传输层时间参数或寻址配置。

常见误区:把诊断通信等同于“调用UDS服务”。实际上,UDS服务能否执行,取决于会话状态、安全等级、传输层是否成功交付、ECU内部是否满足执行条件。排障时应按“物理层→传输层→会话/安全→服务”的顺序逐层确认,而不是反复修改应用代码。

五、学习目标与课程地图

模块核心内容关键产出
诊断通信基础UDS服务、会话、安全访问、DTC能读懂诊断规范与ODX
传输层协议CAN TP、DoIP、流控与超时能配置并分析传输过程
AUTOSAR诊断栈DCM、DEM、FIM、配置参数能完成诊断栈集成
诊断测试与排障测试用例、日志分析、故障定位能独立完成诊断验证

本课程后续将围绕这条主线展开:先建立诊断通信的整体框架,再深入UDS服务与状态机,然后进入CAN TP与DoIP传输细节,接着讲解AUTOSAR诊断栈的配置与集成,最后通过测试与排障案例把知识闭环。你不需要一次记住所有参数,但需要始终清楚当前问题位于哪一层、哪一环节。

建议在学习每个模块时,都问自己三个问题:这个对象在诊断链路中处于什么位置?它依赖哪些上游条件?它的输出会触发哪些下游行为?把这三个问题回答清楚,诊断通信就不再是零散的知识点,而是一条可追踪的工程链路。