前言
这一块可是汽车电子工程师必须掌握的硬菜，虽然不难，但是都要懂点。
UDS相关的detail knowhow内容就不在本文中体现了，大家可以在网上搜索ISO14229、ISO15765、ISO11898等一系列标准来学习。本文只介绍knowhow summary和project level相关的内容，尽量偏向实战应用。
简单来讲，汽车的诊断基本都是通过UDS实现的。其中ISO14229定义了应用层，而ISO15765、ISO10681、ISO13400和ISO17987则分别定义了以CAN、Flexray、以太网和LIN通信实现的传输层和网络层，即通过CAN、Flexray和以太网等通信方式实现ISO14229定义的UDS应用层。
图1 UDS协议栈
还记得上一篇文章分享的网络拓扑图吗？在整车中，有不止一个CAN网络，每个CAN网络都有一定数量的ECU节点。其中有一个CAN网络名字叫做：诊断CAN网络，就是专门用来诊断的。诊断，实际上是开发人员拿着一些便携式设备，例如笔记本电脑、诊断仪等设备，通过OBD口等专用接口，接入整车CAN网络中，作为一个特殊的“外来使者”（Tester），抓取CAN网络中的消息，并能够对原生的CAN网络拓扑中的ECU进行通信、访问、刷写等操作。
系统测试很大程度上依赖UDS诊断提供的各种基础服务，例如读取DTC，读取Internal Fault Table，读写DID来改变或控制ECU的一些功能等等。
一、工程师在做诊断时，是一种什么样的场景？
下面给一个具体而真实的场景描述：
- 前几天，我负责开发的某款ADAS产品（比如IFC-智能前视摄像头模块）按照客户的要求进行了一次重要功能升级，同时修复了几个软件的bug；新版软件release后，我赶紧把软件刷到产品中，在实验室里做了一遍完整的系统台架测试。今天，我需要将产品安装到整车上，进行一次实车的诊断。
- 我和助手，手里抱着笔记本电脑、刚测试过的IFC控制器、CANoe（如图1）、产品线束（连接PC、CANoe和）、OBD连接器及线束；到了车内，先将IFC接到后视镜底座的IFC指甲上，连接好线束；接着将OBD连接器插上整车OBD口，将线束依次连接好；顺序大体为，OBD线束连接好产品线束，产品线束连接好CANoe，CANoe连接好电脑。打开电脑里的CANoe软件，配置好CAN网络；车辆IGN off后等3秒，再IGN ON；打开CANoe的trace窗口，首先检查通信是否正常；若通信正常，则按照CAN消息打开对应产品的相关消息（例如IFC，打开IFC1和IFC2两个消息），看消息中的信号数值是否与预期相符；若与预期相符，那么利用UDS诊断写入一些关键的DID值，以打开底层的开发者使用的CoreMsg，观察视觉检测算法相关信号是否正常；若正常，那就准备开车实车测试。当然，副驾驶的助手需要全程抱着电脑，实时观察整车CAN网络的消息和信号数值是否符合实车运行的场景，是否有错误等等（如图2）。
- 测试过程中，要将所有的CAN网络数据，保存下来。
- 诊断除了在整车上做，也经常在自己的办公桌上进行。一般工具就是自己的笔记本电脑、CANoe盒和连接电脑的线束、连接CANoe-产品-电源-120Ω终端电阻的产品线束、12V电源、产品本身。需要提一点，与整车不同，在办公桌上搭台架，必须要12电源给产品供电，也需要一个120Ω的终端电阻，模拟实车上CAN网络的阻抗。
图1 死贵死贵的CAN盒
图2 实车诊断时的副驾驶助手电脑屏幕的场景还原
二、诊断的应用层：
诊断的应用层就是对ISO14229的实现。应用层相关内容，也是大部分汽车工程师在提到诊断时，脑子里最先浮现出的场景。
应用层主要定义了诊断命令，通过发送诊断命令，开发人员可以对CAN网络中相关ECU节点进行操作。诊断牵涉到几个概念：SID、DID、RID和DTC。这几种概念的组合格式是在ISO15765传输层定义的，一般遵循以下格式，组成完整的诊断命令：
发请求时的格式1：SID+DID；
发请求时的格式2：SID（特指例程控制服务）+子类型+RID；
正响应时的格式1：（SID+40）+DID+其他定义的label；
正响应时的格式2：（SID+40）+子类型+RID+返回的结果数据；
负响应时的格式： 7F+SID+DID+其他定义的 label。
其中：
SID意为Service ID，即服务类ID，表征发送的诊断命令的服务类型，一般有选择会话模式、重启ECU、清除诊断命令、读DTC、读DID、写DID、例程控制、通信控制、请求下载、请求上传、测试者在线等服务类型。具体如图3所示。
图3 常用的SID
图4 自定义的集中会话模式
DID意为Data ID，即数据类ID，一般都是与产品系统相关的信息和一些配置信息，例如：BootLoader软件版本号、Host软件版本号、目前运行在哪个会话模式中、ECU的生产日期、ECU序列号、车辆VIN码、硬件版本号、车辆生产日期、车辆配置信息、CAN矩阵版本号、工厂标定配置参数、工厂标定输出Flag、电源电压状态、工厂标定成功次数、工厂标定失败次数、产品系统配置、产品当前内部错误表、产品历史内部错误表、3.3V-ADC、1.8V-ADC、1.1V-ADC、标定开关（选择工厂、服务站标定类型）、Feature标定文件Checksum、Feature版本号、当前运行程序（是APP？还是PBL）、ECU重启次数、系统运行时间、系统运行总时间等等信息。
图5 常见的DID
RID意为RoutineControl ID，即例程控制的ID，一般都是些与标定、烧录相关的耗时耗资源操作，例如：产品工厂标定例程、产品服务站标定例程、擦除产品内存例程、检查程序相关性例程、MTF计算例程、BootLoader的CRC计算例程、APP程序的CRC计算例程、Flash的CRC计算例程等等。
图6 常见的RID
使用CANoe进行诊断操作时，情景如下图：
图7 输入诊断命令“22 F1 A1”
以上意思为，读取（SID=22）DID为F1A1的数据，查表获知，F1A1代表车联配置字信息。
三、诊断故障码DTC
DTC，Diagnostic Trouble Code，诊断故障码，是UDS诊断最基础的应用之一。本身没有什么难理解的，主要发诊断命令读取DTC即可。主要用于产品故障的诊断。一旦读出对应的DTC故障，就要按照DTC指引的方向去检查问题。下图以IFC为例，分享一种常见的DTC列表。
图8 常见DTC示例
总结
UDS诊断不是一个难以理解的概念，不能把它当成理解某个复杂算法一样去看待。他只是一种定义，而且跟项目最息息相关的定义。每到拿到新项目时，最关注的一部分就应该是UDS诊断定义的该项目的SID、DID和DTC等信息，制作成诊断手册（可以使用Excel表格），不需要记住，但是用到的时候方便查看