UDS教程——0.1总述

01

什么是诊断

车辆在运行过程中，不可避免地会发生一些故障，为了确保行车安全，我们要求车上的ECU能够实时监测部件的运行状态，一旦发现异常情况，能通过点亮报警灯等方式提示驾驶员。但是，点亮报警灯只能告诉驾驶员车辆发生了故障，最多只能定位到故障ECU，比如ABS报警灯亮说明ABS系统出现故障，但具体是发生什么故障并不能通过报警灯显示出来。这时就需要ECU在本地存储一个与故障相对应的故障代码，在进行维修的时候，可以通过车上的OBD接口连接诊断仪，把这个存储的故障代码读取出来，从而进一步定位到更加具体的故障部件，比如ABS传感器发生断路等。

以上就涉及到了车辆故障诊断的两个方面，一个是在线诊断（Onboard Diagnostic），包括故障实时监测、故障灯显示和故障代码实时更新存储，另一个是离线诊断（Offboard Diagnostic），就是指维修时连接外部诊断仪，进行故障码读取，从而快速定位故障部件，有的诊断仪还可以直接显示维修建议。

02

诊断协议体系

想要把存储的故障码读取出来，就需要诊断仪和ECU之间有一个通讯协议。目前最常用的是基于CAN线的UDS诊断。

UDS（Unified diagnostic service） 是由ISO 14229-1标准定义的一套国际通用的诊断服务指令，规定了诊断请求和响应的格式。在整个体系中处于最上层的应用层。

诊断指令通过 CAN（ISO 11898） 网络进行传输，当然现在也有基于LIN或以太网等其它网络的诊断，诊断指令都是由UDS定义的，只不过底层传输方式不一样，本专栏只讨论基于CAN网络的诊断。

但有个问题是CAN每帧只能传输8个字节（以传统CAN为例），而有些诊断指令的长度是大于8字节的，这个时候就需要在应用层和底层传输协议之间加入一个传输层，定义了一些多帧传输的机制。传输层对应的国际标准是ISO 15765-2/3，它的功能就是：发送方的传输层将应用层大于8字节的诊断数据按一定规则进行拆分，形成多个CAN帧进行发送，接收方的传输层收到这些CAN帧后，以相同的规则把应用层数据进行组合，形成完整的诊断数据。它是上下层之间的一个媒介。

03

车辆诊断的发展

上面提到的是最基本的故障诊断功能，其实诊断能够完成的功能还有很多。例如，在车辆生产完毕时，需要对一些部件进行EOL下线检测，来验证装配是否正确，现在大多数下线检测都是通过诊断指令来实现的，比如给车身控制模块（BCM）发送一个诊断指令，让雨刷动两下，从而验证雨刷功能正常。

此外，很多车上的ECU会有更新升级软件的需求，最初都需要把ECU从车上拆下来，用专用的程序烧写设备进行软件烧写，但现在大部分车辆能够通过诊断仪来更新ECU软件，省去了拆装ECU的麻烦，在OBD接口上连接一个诊断仪就可以了。这个功能也是通过诊断来实现的，也就是我们常说的BootLoader。包括现在很火热的OTA，其底层实现方法也是诊断，只不过OTA不需要连接外部诊断仪，而是用Tbox、网关或车辆主机充当诊断仪，ECU软件更新包是从云端获取下来的，再通过诊断协议发送给ECU，实现软件的更新。

现在UDS诊断在车上越来越普及，开发和测试需求都越来越多，但UDS的学习成本其实还是蛮高的，14229-1这一本协议就四百多页，乍一看起来很没有头绪，网上其他一些资料也都比较零散。在接下来的一段时间内，我会更新一个系列教程，与大家分享一下我在UDS开发和测试方面的一些积累，包括应用层、网络层，以及Vector相关工具链的使用方法，希望能对大家有一点帮助。