五一假期闲来无事，坐在电脑前面敲点文字。今天分析诊断协议ISO 14229的不同版本内容间区别。何为诊断协议术语就是定义测试设备和待诊断设备之间通信规则，就是诊断协议。全球诸多主机厂和供应商，如果每家都定义各自的规则，会给社会资源带来极大的浪费。因此定义通用的诊断协议，互相之间变动就不会更改很大。对于任何一个技术协议都不是一蹴而就，就比如我们现在常用诊断协议ISO 14229，也不是起初就有的，如下是诊断协议的一个发展示意图：
-> 起初使用是ISO 9141协议，该协议典型特点是通信前需要通信双方建立握手协议，比较繁琐，伴随着时间推移和技术进步，该协议已经慢慢消失在的长河里。-> 后续就是ISO 14230，也就是我们常说的KWP 2000，最早应用于欧洲（50年车企好多），主要定义了应用层、数据链路层和物理层三方面，也称关键字协议（这种协议在进入系统会进行关键字校验而闻名）。现在还有在使用，但是范围极小。-> 随着需求变更，后续就出现了自己熟悉的ISO 15765，头次看到该协议，自己也是不明所以，发现它也定义了跟现在常用的UDS协议一样的内容呀，除了内容较为宽泛。这是一个基于车载CAN总线的诊断协议，现阶段需要参考一般是ISO 15765-2，定义了车载CAN / CAN FD总线在TP层通信规则。-> 期间因为车辆排放尾气与居住环境密切相关，为促进保护环境，定义了一个具有法规效应的协议ISO 15031，定义了01-0A 10个服务，读取排放相关内容和DTC。-> 最后是现在应用最广的ISO 14229，这是一个定义了应用层的诊断协议，不关心实际车载总线载体（车载总线CAN/lin/MOST/以太网等），只需将UDS协议在不同的车载总线做具体的应用和限制，相当于UDS在不同车载总线特色化（类比中国特色社会主义，核心在于特色化）。UDS诊断协议架构UDS协议是一个具备工程架构型的通用协议，现阶段不同协议分为不同的子类，比如行业现阶段应用最多的2013版，ISO 14229分为7个子类：
每一个子类对应一种车载总线（ISO 14229-3到7），伴随着新的需求，只需要对子类进行增加。比如2020版UDS协议，欧洲那边新增了一种车载总线CXPI，也就对应增加了ISO 14229-8。
对于UDS协议内容，说它具备工程美，是因为该协议整体定义了诊断通信请求和响应的通信规则：
请求中SID表示Service Identifier，服务作为诊断协议中功能载体，通过服务来实现具体功能，比如会话模式和安全访问状态机。通过ID来区分不同功能；响应是SID +40,在报文中以此规则界定肯定响应，否定响应标识符为7F，通信规则如下：
7F后续跟SID，表示否定具体哪个请求服务。NRC表示为毛给你否定响应。SID是从00-FF，UDS协议根据常用功能，定义了26个经典服务，也预留了可以让OEM和Supplier自定义的空间，因此说它具备工程美。 诊断协议应用场景对于OEM，基于自身功能需求，会定义自身诊断需求规范。这个时候对应的规则就是基于ISO 14229协议来做Specific应用定义。业界常用就是自身规范与协议保持一致，并在协议的基础上做自身需求定义，比如DID、DTC需求定义、自定义服务（除了26服务外）。OEM定义诊断需求规范后，所有该OEM供应商在实现ECU功能时，需要遵循该诊断需求规范，内容与其一致。诊断协议不同版本之间区别因为时间推移和需求不断变更，ISO 14229现下有三个版本：-> ISO 14229（2006版）-> ISO 14229（2013版）-> ISO 14229（2020版）
不同版本之间有不同区别（需求不断变更和车载诊断应用场景变化），对比2006版和2013版：-> 1、在功能寻址情况下，若ECU响应NRC 7E和7F，2013版UDS协议规定ECU不需要响应（降低车载总线负载），2006版UDS协议需要响应，加上NRC 11/12/31,就有五个NRC不需要响应；-> 2、2006版UDS协议只支持0x28 00-03 subfunction，2013版支持0x28 00-05 subfunction；-> 3、2006版不支持Service 38，2013版支持；-> 4、2006版UDS协议支持Service 19 0x 01-15 subfunction，2013版增加至Subfunction 0x 01-19、0x 42；-> 5、2013版UDS协议在定义Bootloader模式刷写过程更加详细和规范化。
2020版UDS协议，鉴于车载以太网在车载总线应用越来越普遍，考虑到车身信息安全因素，在UDS新版协议中增加了Service 29，主要用于车身访问认证：1、单项认证（Server端只需要认证Client端权限），双向认证（Server端和Client端双向都需要认证）；2、使用证书，比如Client发送带有第三方认证过的证书至Server端，在发送过程中Client会有对证书的签名，Server端接受到该证书和签名后，只需Check签名是否被篡改，若无，表示证书有效，允许Client进行访问，认证通过。当然这个认证过程还有更复杂的步骤，比如Client/Server端会生成质询数（Challenge Value），并通过哈希算法生成Session key，这是另外一种复杂的认真过程，容我时间后续整理。如上分享，若有所帮助，达到目的！
|
|
|
