因为ISO文档需要收费，所以以下内容整理于网络，请以ISO文档为准。
2022.7.15更新：UDS相关协议已制定成国家标准，标准号是GB/T 40822-2021，标准名是《道路车辆 统一的诊断服务》，英文名是《Road vehicles—Unified diagnostic services》，官网上卖两百多，淘宝只需要卖2块钱，搜索“国家标准”关键字，然后找客服询价就行了。
一、协议栈总览
二、UDS应用层
USD应用层由ISO 14229标准定义。诊断通信的过程从用户角度来看非常容易理解，诊断仪发送诊断请求(request)，ECU给出诊断响应（response），而UDS就是为不同的诊断功能的request和response定义了统一的内容和格式。
Diagnostic request的格式：
Diagnostic request的格式可以分为两类：一类是拥有sub-function的，另一类是没有sub-function的，如下面两张图所示。Service ID（以下简称SID）的长度固定为1个字节，代表了这条诊断命令执行的什么功能。sub-function的长度也是1个字节，它通常表示对这个诊断服务的具体操作，比如是启动、停止还是查询这个诊断服务。而后面的parameter则根据各个诊断服务的不同具有不同的内容，长度和格式并没有统一规格，它用于限定诊断服务执行的条件，比如某个诊断服务执行的时间等。parameter的一个重要应用是作为标识符，标识诊断请求要读出的数据内容，我会在后续的文章里详细讲述各个诊断服务的应用。
拥有sub-function的诊断请求：
无sub-function的诊断请求：
有一点要补充的是，其实sub-function严格来说是7个bit，而不是1个byte，因为它的最高位bit被用于抑制正响应（suppresspositive response,SPR），如果这个bit被置1，则ECU不会给出正响应（positive response）；如果这个bit被置0，则ECU会给出正响应。这样做的目的是可以告诉ECU不要发不必要的response，从而节约通信资源。
Diagnostic response的格式：
Diagnostic response分为positive和negative两类。positive response意味着诊断仪发过来的诊断请求被执行了，而negative response则意味着ECU因为某种原因无法执行诊断仪发过来的诊断请求，而无法执行的原因则存在于negative response的报文中。
positive response的格式如上图所示，也基本上是由三部分组成，其中的response SID这个字节作为诊断请求的echo，它等于SID + 0X40。后面的两个部分则视具体的诊断服务而定。
negative response的格式固定为3个字节，第一个字节为0x7F，第二个字节是被拒绝掉的SID，第三个字节是这个诊断服务无法被执行的原因。下面这张表格列举了部分原因代码，比如，如果ECU给出7F 22 13这个negative response，则说明22这个服务因为诊断请求数据长度不对的原因无法执行。
| Hex | Mnemonic | Description |
|---|---|---|
| 10 | GR | General reject |
| 11 | SNS | Service not supported |
| 12 | SFNS | Sub-Function not supported |
| 13 | IMLOIF | Incorrect message length or invalid format |
| 14 | RTL | Response too long |
| 21 | BRR | Busy repeat request |
| 22 | CNC | Conditions not correct |
| 24 | RSE | Request sequence error |
| 25 | NRFSC | No response from sub-net component |
| 26 | FPEORA | Failure prevents execution of requested action |
| 31 | ROOR | Request out of range |
| 33 | SAD | Security access denied |
| 35 | IK | Invalid key |
| 36 | ENOA | Exceeded number of attempts |
| 37 | RTDNE | Required time delay not expired |
| 38-4F | RBEDLSD | Reserved by Extended Data Link Security Document |
| 70 | UDNA | Upload/Download not accepted |
| 71 | TDS | Transfer data suspended |
| 72 | GPF | General programming failure |
| 73 | WBSC | Wrong Block Sequence Counter |
| 78 | RCRRP | Request correctly received, but response is pending |
| 7E | SFNSIAS | Sub-Function not supported in active session |
| 7F | SNSIAS | Service not supported in active session |
总结：诊断通信的过程就是诊断仪和ECU交换数据，前者发的是request，后者发的是response，而UDS最重要的作用就是定义了这些request和response的格式和内容。今天这篇文章对request和response进行了简要介绍，在后面描述各种诊断服务的文章中我会通过更多的示例来说明这两个基本概念。
三、UDS传输层&网络层：DoCAN
可以从总览图中了解到DoCAN是传输层和网络层的协议，由ISO 15765标准定义，其底层是ISO 11898标准定义的CAN 2.0协议，因为CAN 2.0协议的一个数据帧最多包含8个字节的数据，因此如果一条诊断命令超过了8字节，就需要DoCAN协议分包后再交给CAN 2.0协议进行传输。ISO 15765-2定义了4种类型的帧结构，分别是：SingleFrame、FirstFrame、ConsecutiveFrame、FlowControl。其中SingleFrame用于长度不超过7个字节的诊断命令或响应，FirstFrame、ConsecutiveFrame、FlowControl用于传输长度大于7个字节的诊断命令或响应。每个诊断帧的第一个字节的高4bit用于描述该帧的类型，即该帧属于上述四种中的哪一种。
SingleFrame用于下面这种简单的场景：当诊断报文长度小于等于7时，再加上一个字节的PCI控制信息就是小于等于8，可以在一帧CAN报文上传输，所以不需要进行分包。此时数据域的第一个字节高4位值为0000，标识这是一个帧SingleFrame，低4位是SF_DL，即DataLength，描述后面有几个字节。如果有没有使用的字节，通常要用0x55或0xAA来填充，因为这两个值的二进制表述其实就是01010101和10101010，这样在CAN总线上可以让信号跳变得更频繁一些，不会出现长时间电平不变的情况。
如果一帧CAN报文无法承载一条诊断报文，则需要按照下面的流程进行分包发送：
首先，发送端要以一个FirstFrame开启通信，告诉接收端还有后续的内容要发，FirstFrame使用前两个字节作为PCI信息，第一个字节高4位为0001，标识这是一个FirstFrame，低4位加上第二个字节用于描述总共发送的数据长度是多少（包括在FirstFrame中和在ConsecutiveFrame中的所有字节数）。
之后接收端发送FlowControl，告诉发送端能以什么样的速度来发送数据，FlowControl第一字节的高4位为0011，低4位为FS，即FlowStatus，第二个字节为BS(BlockSize)，第三个字节为STmin（SeperateTime）。FlowControl有0、1、2三种状态，分别命名为ContinueToSend (CTS)、Wait (WT)、Overflow (OVFLW)。如果允许发送端继续发送ConsecutiveFrame，则FlowStatus=0；若要求发送端等一会再发送ConsecutiveFrame，则FlowStatus=1，再下次允许sender发送ConsecutiveFrame时，receiver再发一个FlowStatus=0的FlowControl。如果receiver因为资源问题无法接收sender发送的数据，则发送一个FlowStatus=2的FlowControl。
BS指示sender一次可以发送多少个ConsecutiveFrame，当发送ConsecutiveFrame数量达到BS时，需要receiver再次以一个FlowControl开启下一波的ConsecutiveFrame发送。
receiver根据自身的接收和处理能力使用STmin指示sender在发送ConsecutiveFrame时最小的时间间隔是多少，从而实现流控制。
ConsecutiveFrame就是承载FirstFrame无法完全承载的剩余数据了，它使用第一个字节用作PCI，高4bit为0010，低4bit用于标识ConsecutiveFrame的序列号，从1开始，每发送一次ConsecutiveFrame增加1。
不分段传输的诊断服务举例：
request：02 10 03 55 55 55 55 55
response：06 50 03 00 32 01 F4 AA
这是一个请求进入extended session的最简单的诊断服务，请求和应答都是SingleFrame，加粗的0标识了SingleFrame，后面的2和6表示了这条诊断报文拥有几个字节的数据。
分段传输的诊断服务举例：
这是一个读取DTC的命令和应答。
03 19 02 08 55 55 55 55 （诊断仪发送的SingleFrame的request）
10 33 59 02 19 01 00 07 （ECU以FirstFrame开始传输的response）
30 00 00 55 55 55 55 55 （诊断仪发送的FlowControl）
21 09 03 05 02 09 05 04 （ECU发送的ConsecutiveFrame）
22 07 09 05 06 06 09 05 （ECU发送的ConsecutiveFrame）
23 08 03 08 07 01 05 08 （ECU发送的ConsecutiveFrame）
24 07 01 06 08 07 01 0C （ECU发送的ConsecutiveFrame）
25 08 07 01 0D 08 07 03 （ECU发送的ConsecutiveFrame）
26 07 09 08 01 01 09 09 （ECU发送的ConsecutiveFrame）
27 01 07 09 AA AA AA AA （ECU发送的ConsecutiveFrame，此时传输结束）
在这里我把所有传输层相关的PCI信息都用粗体标识了。
需要提一下的是，BS和STmin等于0时，表示接收端可以以最快的速度来接收数据，发送端可以一次发送的ConsecutiveFrame数量不受限制。
四、UDS传输层&网络层：DoIP
DoIP是Diagnostic communication over Internet Protocol 的简称，顾名思义，就是通过网络协议进行诊断通信，由ISO13400 系列标准定义。这里的网络协议，指的就是OSI七层模型中，通用计算机网络所使用的从层4到层1这四层协议。AutoSAR官网上有一份完整的DoIP文档：Specification of Diagnostic over IP，协议内容在7.3节。
DoIP报文结构：
| Item | Position (Byte) | Length (Byte) |
|---|---|---|
| Protocol version | 0 | 1 |
| Inverse protocol version | 1 | 1 |
| Payload type | 2 | 2 |
| Payload length | 4 | 4 |
| Payload type specific message content | 8 | … |
DoIP报文有如下类型的Payload：
| Payload Type value | Payload type name | Connection Kind |
|---|---|---|
| 0x0001 | Vehicle Identification request message | UDP |
| 0x0002 | Vehicle identification request message with EID | UDP |
| 0x0003 | Vehicle identification request message with VIN | UDP |
| 0x0005 | Routing activation request | TCP |
| 0x0008 | Alive Check response | TCP |
| 0x4001 | DoIP entity status request | UDP |
| 0x4003 | Diagnostic power mode information request | UDP |
| 0x8001 | Diagnostic message | TCP |
| 0x0000 | Generic DoIP header negative acknowledge | UDP/TCP |
| 0x0004 | Vehicle announcement message/vehicle identification response | UDP |
| 0x0006 | Routing activation response | TCP |
| 0x0007 | Alive Check request | TCP |
| 0x4002 | DoIP entity status response | UDP |
| 0x4004 | Diagnostic power mode information response | UDP |
| 0x8002 | Diagnostic message positive acknowledgement | TCP |
| 0x8003 | Diagnostic message negative acknowledgement | TCP |
再详细说一下Diagnostic message类型的Payload：
Diagnostic message (for request and response) (payload type 0x8001)
| Item | Position (Byte) | Length (Byte) |
|---|---|---|
| Source address | 0 | 2 |
| Target address | 2 | 2 |
| User data | 4 | … |
Diagnostic acknowledge message (payload type 0x8002)
| Item | Position (Byte) | Length (Byte) |
|---|---|---|
| Source address | 0 | 2 |
| Target address | 2 | 2 |
| ACK code (0x00) | 4 | 1 |
| Previous diagnostic message | 5 | … |
Diagnostic negative acknowledge message (payload type 0x8003)
| Item | Position (Byte) | Length (Byte) |
|---|---|---|
| Source address | 0 | 2 |
| Target address | 2 | 2 |
| Diagnostic message negative acknowledge code | 4 | 1 |
| Previous diagnostic message | 5 | … |
5058
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
