谈到汽车上的诊断，第一印象就是某天我的车上亮了我不知道什么意思一个黄色的故障灯，于是我很慌地跑到4S店。工作人员接上一个某某设备，读一下故障码，再清一下故障码后，问题没有了。来到前台，漂亮的美眉告诉我“工时费两百，谢谢惠顾！”
后来，我们在某宝上发现竟然有一种神奇的OBD盒子开卖，竟然可以适配市面上99.99%的车型，车主可以通过这个盒子在手机上实时的了解爱车的健康信息。出现故障的情况下也能自己先做个初步诊断，然后判断该故障的严重程度决定去4S店挨一刀还是自己DIY解决，所谓一盒在手，亮灯不愁。
为什么一个小小的盒子竟然能够适配几乎所有的车型呢？这得归功于国际标准化组织所规定的一系列统一诊断服务协议（Unified Diagnostics Services，简称UDS），所有的车厂在进行其诊断协议开发时都毫无例外的遵循该协议。
首先两个概念：在线诊断与离线诊断
1.在线自诊断：ECU在工作过程中，即时监控电子控制系统各组成部份的工作状态，检测到故障发生后，以一定的方式(比如警报指示灯)向驾驶员发出警告、采取相关的Action（如进入降级模式）并将故障相关信息存储到内部存储器。这个一般属于Fail-Safe功能开发的内容。
2.离线诊断：在车辆出现故障后， 通过外部仪器 （汽车故障诊断仪） 与车辆ECU进行通信， 读出ECU存储器内的故障信息，从而查找故障原因， 为车辆的检修提供线索和指导。离线诊断的关键在于诊断仪与ECU之间的诊断协议。
OSI结构中被UDS覆盖的5层
那么什么是诊断协议呢？诊断协议就是如何实现诊断设备和ECU之间的通信机制和诊断服务，ISO就是对这些问与答的机制进行了语法以及语意上的规定。
我们知道，ISO针对所有开放互联系统，制定了一个OSI的七层模型，其实这个UDS诊断服务的相关标准，也是能够套到OSI模型里去的。
注：ISO14229是可以覆盖所有的通讯介质的（CAN，LIN，K，Flexray,WLAN…..）, ISO 15765可以认为是其在CAN总线上的应用，本文仅以15765为例铺开。
从上可以看到，UDS的这几个协议，实际上覆盖了OSI七层结构中的5层：
1. 物理层和数据链路层
ISO 11898协议就是我们俗称的CAN底层协议，定义了CAN帧的电平、数据长度、发送速率、位场结构、仲裁机制、校验机制等等。
2. 网络层
网络层由ISO15765-2定义，主要有两个作用：为上层（应用层）提供服务以及定义网络对等层之间的通信规则。
1）定义了三种主要诊断服务类型
2）定义了对等层之间的通信规则
-发送方式：单帧发送或多帧发送。这取决于需要发送的数据长度，如果数据无法通过一帧CAN Message发送就需要对数据进行分割处理并通过多帧的方式发送。多帧发送的第一帧会携带总数据大小信息（包括后续帧）。
-接收能力：接收端在要求发送端继续发送的的时候需要考虑自己的接收能力，接收端的接收能力可以用BS和STmin两个参数来衡量。BS指接收端允许发送端连续发送连续帧的最大数目；STmin是指两个连续帧连续发送的最短时间间隔。这两个参数的设置受到接收缓冲区容量和接收端数据帧处理速度的限制。
-时间管理：时间管理机制是为防止通信双方因等待而被永久挂起, 进而失去通信的能力
3. 会话层和应用层
ISO15765-3定义了UDS on CAN的会话层和应用层实现。
会话层：
会话层的主要作用是维持ECU处于非默认会话模式，定义了两个时间参数：S3Client以及S3Server。
S3Client：该时间参数规定了诊断仪连续发送ox3E服务的时间间隔
S3Server：该时间参数规定了ECU处于非默认会话模式的最大时间（如果无后续任何来自诊断仪的请求服务），一旦在最大时间内收到后续服务，该时间将从新计时。
应用层：
应用层规定了诊断仪和ECU之间具体的诊断服务，包括每一条服务的具体功能、包含的子功能服务、请求-响应报文的参数格式。
所有的诊断服务的相关工作，都可以在上表中找到，因此对于整车厂和供应商来说只要根据实际情况在此基础制定某车型上某电子控制单元所需要的诊断服务即可。
下图为流控机制和时间超时管理叠加的示意图：
