ISO 14229

UDS本质上是一系列服务的集合。UDS的服务包含6大类，共26种。每种服务都有自己独立的ID，即SID。

SID：Service Identifier，诊断服务ID。UDS本质上是一种定向的通信，是一种交互协议（Request/Response），即诊断方(Tester)给ECU发送指定的请求数据（Request），这条数据中需要包含SID，且SID处于该应用层数据的第一个字节。如果是肯定的响应（Positive Response），首字节回复[SID+0x40]，举例子就是请求0x10，响应0x50；请求0x22，响应0x62。如果是否定的响应（Negative Response），首字节回复0x7F，第二字节回复刚才询问的SID。比如Tester请求0x10服务，我想进入编程模式，ECU给出否定响应，首字节0x7F，第二字节回复0x10，代表我否定你的0x10服务请求，第三字节是NRC(否定响应码)，代表我否定你的依据。

22

当前诊断任务模式	同上	发送22 F1 86
整车零部件号	同上
应用软件版本号（正常升级版本）	同上	发送22 F1 88
应用软件版本号（固定版本）	同上	发送22 F1 B0
系统供应商代码	同上	发送22 F1 8A
ECU生产日期	同上	发送22 F1 8B
控制器序列号	同上	发送22 F1 8C
整车VIN	同上	发送22 F1 90
硬件版本号	同上	发送22 F1 91
序列号数据标识符	同上	发送22 F1 98
刷新日期	同上	发送22 F1 99
车辆配置码	同上	发送22 F1 70
应用硬件版本号（固定版本）	同上	发送22 F1 BF
ECU装配日期	同上	发送22 F1 9D
软件总成版本号	同上	发送22 F1 C0
清保养	同上	发送22 F1 71
读同步时各ECU里程	同上	发送22 F1 73
软件总成零件号	同上	发送22 F1 D0

连续帧请求方式

这里以SID:2E 服务：F1 90 写VIN为例

$27安全访问

$27安全访问：ECU当中有很多数据是整车厂独有的，并不希望开放给所有客户，它需要做一个保密的设定。我们在读取一些特殊数据的时候，要先进行一个安全解锁。ECU上电之后是一个锁定的状态（Locked），我们通过$27服务，加上一个子服务，再加上一个钥匙，这样的服务请求可以进行解锁。比如下面的例子，2n-1是一个子服务，通过首轮种子的请求，首轮ECU会返回67+01+AA+BB+CC+DD，AA~DD就是种子了。之后第二轮，诊断端会利用种子进行运算（利用整车厂的算法），生成k1（不一定是1个字节），那么发送请求，27+02+[k1]。ECU同样也会通过种子算出k2。当k1和k2匹配时，解锁（Unlocked）成功。

$27安全访问服务的否定响应服务ID也是7F。还记得刚才否定响应的格式吗？7F+27+NRC（否定响应码）。

实际通信的截图，黄色位置是密钥区域

例子：

Tester： 02 27 05 00 00 00 00 00 安全访问，05子功能

ECU： 06 67 05 08 27 11 F0 00 肯定响应，回复了对应安全级别的种子

Tester： 06 27 06 FF FF FF FF 00 发送密钥，4个FF。注意06是与05成对使用的。

ECU： 03 7F 27 78 00 00 00 00 若为否定响应，7F+27+NRC

ECU： 02 67 06 00 00 00 00 00 若为肯定响应，通过安全校验

细说下安全验证算法。安全验证算法包括1个核心，3个主体。

第一个主体通常和ECU有关。比如我们先用22服务读取ECU的SN，取其中4个字节，作为“调味料”参与，显然这个“调味料”对于这个ECU来说是不变的，也能通过22服务方便的读取到。

第二个主体seed，通常与ECU的运行时间有关系，是主料，在27服务发送奇数子功能时回复。seed通常一直在发生变化，无法发现其规律。

第三个主体是执行次数，就是算法要执行几轮。执行1轮和2轮得到的结果肯定是不一样的对吧。

最大的核心就是算法了。举个简单的算法，比如seed和ECU SN前4个字节加一下，循环左移两位，执行3轮，return这个数作为key，结束。安全验证就是一把锁，算法越复杂，短时间解开的成本越高，越不易被破解掉。如果失败次数过多还会触发惩罚机制，一段时间内都无法再尝试解锁，防止人为的破解。

来自 https://zhuanlan.zhihu.com/p/37310388

BOOTLOADER升级过程

https://mp.weixin.qq.com/s/q-RhpwOiliSq2b3m5xPR-w

物理寻址，功能寻址

功能寻址可以广播诊断请求Request，同时等待总线上的ECU给与响应，可以针对多个ECU的某功能；

物理寻址指定发送特定诊断请求Request，等待指定ECU给与响应，点对点；

诊断报文一般会有三个CAN ID

DiagRequest(诊断物理请求报文)：ECU接收来自Client的报文；

DiagState(诊断功能请求报文)：ECU接收来自Client的报文；

DiagResponse(诊断响应报文)：ECU反馈的报文。

功能寻址与物理寻址支持的服务不同

物理寻址可以访问ECU所支持的所以服务；

功能寻址只能访问部分服务。

功能寻址与物理寻址错误反馈NRC不同

物理寻址出现错误时反馈所有NRC码；

功能寻址在以下情况不需要反馈错误码：

31（requestOutOfRange）；

12（subFunctionNotSupported）；

11（serviceNotSupported）；

7F（serviceNotSupportedInActiveSession）；

7E（subFunctionNotSupportedInActiveSession）；

功能寻址可一般使用场景：

刷新软件前使用28服务关闭ECU通信使能；

刷新软件前使用85服务关闭ECU故障检测功能；

使用22服务读取多个ECU信息；

使用14服务时清除多个ECU DTC；