诊断协议那些事儿's blog

本专栏将以ISO14229为基础深入介绍诊断那些事儿，从故障定位到软件刷写……重点掌握各个服务的功能、报文格式，为后续功能开发打下基础！

对称加密：加密和解密使用相同密钥的加密算法。非对称加密：一对加密密钥和解密密钥，用户加密后所得的信息，只能用该用户的解密密钥才能解开。如果知道了其中一个，不能计算出另一个。公开的加密密钥为公钥，不公开的解密密钥为私钥。PKI：PKI的全称是PublicKeyInfrastructure，译为公钥基础设施。PKI是包括硬件、软件、人员、策略和规程的集合，用来实现基于公钥密码体制的密钥和证书的产生、管理、存储、分发和撤销等功能。用来建立不同实体间的“信任”关系。X.509：是密码学里公钥证书的格式标准。

本文为诊断协议那些事儿专栏文章，旨在介绍诊断的全景！含有ISO14229国际标准，Autosar组织Classic Platform Autosar规范，以及Vector的技术文档，有兴趣学习的可以联系小编，获取文档，共同为车载诊断行业添砖加瓦。

本文仅仅简单介绍了UDS的起源和发展，还有许多值得去挖掘和研究的内容，后续小编会不断介绍ISO协议，以此来加深对诊断的理解。

UDS应用场景：①在行驶过程中，要用它来监测各种故障，并记下故障码；②在售后服务、4S店中读取ECU故障码，精准地定位故障，节约维修工时。③在开发阶段构建Bootloader，上传和下载数据：给ECU更新软件，售后OTA刷写。④在整车下线前针对不同配置的车型进行编码、改写参数、终端元件检测等操作。⑤远程诊断技术：随时或定期主动诊断，出现故障诊断专家可以远程协助，并利用OTA技术远程恢复故障

在线自诊断：包括故障实时监测，故障灯显示和故障代码实时更新存储；通过车内电子控制单元的软件系统和硬件系统实现了车内在线自诊断功能。车辆内的电子控制系统中各个组成部分的运行状况被车内在线诊断系统连续监控，根据监控的相关数据可以有效判断出电子控制系统是否存在故障。当车内在线诊断系统判断出故障后，向驾驶人员提示警告（如仪表盘故障指示灯点亮）并通过 ECU 的 EEPROM 或者Flash 存储 DTC 和故障发生时的相关数据，同时采取相关的Action（如进入降级模式）等！

个人建议在诊断学习时，首先对整体框架有个基本的认识，比如ISO14229与ISO15765、ISO11898等的关系，再深入学习后面各个模块后，对整体知识进行回归。本专栏旨在将诊断协议那些事儿整体框架描述清楚，对于知识的细化会慢慢进行完善，并及时更新。如有问题欢迎批评指正！

ISO14229协议也在随着技术发展不断更新，唯有不断学习才能不被淘汰，欢迎各位评论，提出宝贵意见，小编也会持续更新，以提供更好的作品。

网络层协议协议有如下功能：①应用层诊断服务数据——CAN数据帧②将数据从发送方传递给接收方③多帧数据传输：发送/接收最多 4095 个字节的数据信息④错误处理/时间管理：保证数据传输的可靠性⑤报告发送/接收完成状态。

本文为诊断协议那些事儿专栏文章，从一个 ECU 到另一个 ECU，或外部诊断设备和一个 ECU 之间的通信，不仅依赖前文介绍的诊断寻址方式，更需要关注数据的传输，依赖网络层、传输层协议去完成，特别是要传输的数据超过了单个CAN 帧的长度，则需要提供拆包、组包的方法。

UDS（统一诊断服务）协议中的时间参数对于诊断仪和ECU之间的通信的稳定性和效率至关重要。这些参数在不同的协议层级中发挥作用，包括网络层、会话层和应用层。从上到下，它分为应用层、会话层、传输层和网络层，每层都包含了特定的组件或参数。ISO15765-2 CANTP传输层网络时间参数这些时间参数的设置对于诊断工具和ECU之间的通信至关重要，它们确保了诊断过程的顺利进行，并允许诊断工具根据这些参数设置合适的超时预期，评估ECU的响应是否及时。

网络层协议协议有如下功能：①应用层诊断服务数据——CAN数据帧②将数据从发送方传递给接收方③多帧数据传输：发送/接收最多 4095 个字节的数据信息④错误处理/时间管理：保证数据传输的可靠性⑤报告发送/接收完成状态。

网路层的所有内容被称为网络层协议数据单元，记为N_PDU，①常规寻址（Normal addressing）—11位ID的CAN报文；②常规固定寻址（Normal fixed addressing）—29位CAN ID的报文；③扩展寻址（Extended addressing）——11位ID的CAN报文；④混合寻址（Mixed Addressing）——11或29位CAN ID；

本文介绍了六个服务原语请求 request/指示 indication、响应 response/确认 confirm、请求_确认 req_confirm/响应_确认 rsp_confirm，以及有确认服务和无确认服务的时序图。

前文介绍了很多UDS服务和ISO 14229协议的文章，有读者会有疑问服务和协议的关系到底是什么呢？ISO14229系列规范介绍UDS服务列表本文小编将展开介绍。

否定响应码的取值范围为0x00-0xFF，细分为三个区间：0x00：服务器内部实现的positiveResponse参数值，否定响应报文中不会出现此NRC；0x01-0x7F：与通信有关的否定响应代码；0x80-0xFF：当服务器收到请求时，用于指示规定条件不正确的否定响应代码【一般用于NRC 0x22条件错误生效时，更详细的报告无法采取请求动作的原因】

一般情况下ECU所支持的服务，物理寻址都可以访问，功能寻址仅能访问部分服务。仅供参考：功能寻址支持的服务10、11、14、19、22、28、3E、85，19服务读取DTC信息和22服务通过DID读取数据，因为往往会涉及多帧通信，故在实际项目中一般不支持！针对实际项目开发过程中遇到的问题以及对于标准的解读，欢迎读者提供宝贵意见！

多帧通信只能使用物理寻址，不支持功能寻址，功能寻址发送的多帧传输的首帧应被接收方忽略

诊断三要素，包含：请求、肯定响应和否定响应

一般情况下如果这个服务支持Sub-function，就存在支持肯定响应抑制位的可能，实际项目开发中一般支持SPRMIB的服务10、11、28、3E、85【仅供参考】

当功能寻址用于请求消息，且需发送带NRC=RCRRP（0x78，正确接收的请求响应未决）的否定响应消息时，如果使用NRC=SNSSNSIASSFNSSFNSIAS（sub-functionNotSupportedInActiveSession）或NRC=ROOR（requestOutOfRange）的最终否定响应消息为接收的请求消息的PDU分析结果，则应发送此最终否定响应消息！！！以上就是今天要讲的内容，欢迎各位评论，提出宝贵意见，小编也会持续更新，以提供更好的作品。

本文介绍了UDS的服务列表，其中包含6大类功能单元下的26+1项具体服务。需注意每个请求服务应被分配一个唯一的SID

诊断会话又称作诊断模式，本质上是UDS各个服务的“权限条件”，使用10服务启动服务器不同的会话状态。不同的会话状态具有一组特定的诊断服务和/或功能、以及不同的定时参数 。标准定义了默认会话和非默认会话下允许的服务。诊断会话分为默认会话和非默认会话两种，非默认会话有可以进一步分为编程会话、扩展会话、安全系统会话等。

27服务提供了一套因安全、排放等被限制访问的数据或诊断服务解锁的机制，安全访问就是给其他服务加了一套访问权限，只有通过安全访问服务去获取这个权限后，才有资格去执行这些服务，其过程的本质是种子与密钥的关系.

27服务的初衷就是防止无权限人员进行非法数据操作，用来确保车辆ECU的安全，如果任何持有诊断设备的人都可以通过诊断指令对车辆ECU进行操作，将存在较大的安全隐患。为了验证产线、售后的操作人员是否有权限操作，在对车辆ECU进行诊断检查时，需要验证其提供的密钥是否有效，而产生有效密钥的前提需要ECU反馈给诊断设备一个随机的种子Seed，如果Seed不具有随机性，不法分子将通过大量的重试来破解密钥，只有Seed具有随机性，才能确保每次产生的Key不同，因此诊断设备每次应发送不同的密钥来进行解锁。

结合27服务安全访问状态转换（ISO14229-1 2020 Annex I：Security access state chart）描述NRC优先级

11服务基于ECUReset请求消息中嵌入的resetType参数值的内容，来请求服务器有效地执行服务器复位。服务器复位成功之后，服务器应激活Default Session。

本文介绍诊断和通讯管理功能单元下的28服务CommunicationControl，该服务的目的是打开/关闭一个或多个服务器的某些消息（例如，应用程序通信消息）的发送和/或接收。

3E服务用于将一个或多个服务器保持在非默认会话的诊断会话状态，通过**周期性**地传输TesterPresent请求消息，可防止服务器自动返回默认会话。

诊断协议那些事儿专栏系列文章，本文介绍诊断和通讯管理功能单元下的83服务AccessTimingParameter，该服务的目的是读取/修改有效通信的计时参数。

参数定义此参数包含由安全子层处理的数据。以上就是今天要讲的内容，欢迎各位评论，提出宝贵意见，小编也会持续更新，以提供更好的作品。

客户端应使用ControlDTCSeting服务来停止或恢复服务器中DTC状态位的更新。在ECU中，每个DTC都有一个状态，使用一个byte数据定义（有关位的定义，后续会在statusofDTC文章介绍），DTC状态位在对ReadDTCInformation 的某些Sub-Function的肯定响应的statusOfDTC参数中报告。

0x87服务（LinkControl，链接控制服务）用于控制客户端与服务端之间的通讯，以获得用于诊断目的(如刷新)的总线带宽。此服务可选地应用于那些数据链路层，它提供了在非默认诊断会话模式重新配置其通信参数的能力(例如更改CAN的波特率或重新配置FlexRay周期设计)。此服务绑定到非defaultSession，也就是链接控制服务应在非默认会话下执行，当发生会话转换（诊断会话控制服务）或ECU复位，通信速率要恢复默认状态。

Diagnostic Trouble Code直译即为诊断故障码，简称DTC，一种用来记录当某ECU发生或检测到某种故障时所呈现在大家眼前的标识码，通过该标识码便可以查表的方式获得该故障信息，如故障触发条件、故障解除条件、系统功能表现等。

当ECU产生DTC时，我们只知道有故障发生了，并不清楚该故障什么时候发生，现在是否已经恢复、发生过几次，恢复过几次等信息，基于此ISO发布的14229-1使用DTC状态位这一概念来得描述上述信息，使我们对该故障的产生以及恢复有个清晰的认识，便于我们快速定位问题所在。本文将介绍UDS中DTC信息的最后一个byte解析：StatusofDTC位的定义,供19服务ReadDTCInformation使用。每个服务器都应遵守本文中定义的DTC状态信息的约定。

存储数据传输服务下的14服务ClearDiagnosticlnformation，客户端使用ClearDiagnosticlnformation服务清除一个或多个服务器存储器中的诊断信息。

本文介绍了读取DTC信息的子服务list,共有27个子服务，其中五个子服务使用最多，后续会详细介绍，针对其他服务并不常见，如果有问题可私聊小编。

19 01服务是读取DTC信息的第一个子服务：客户端可以通过发送对此服务的请求并将sub-function设置为reportNumberOfDTCByStatusMask来检索与客户端定义的状态掩码匹配的DTC数量。

客户端可以通过发送一个带有设置为reportDTCByStatusMask的Sub-Function字节的请求来检索满足客户端定义的状态掩码的DTC列表。该Sub-Function允许客户端请求服务器报告所有“testFailed”或“confirmed”等的DTC。

为了方便找到故障的原因，车厂一般会在诊断调查表中定义一些信息作为快照信息，例如故障发生时间、电压、行驶里程数、车速等。在对应故障发生时，ECU端要记录发生故障时的快照信息，客户端可以通过此服务检索客户端定义的DTCMaskRecord的捕获DTC Snapshot记录号以及DTCSnapshot记录数据。通过查找故障发生时刻的这些数据，来分析故障原因。