目录

一、前言

二、诊断模型

三、诊断流程

四、诊断服务SI

---

一、前言

之前有篇博文刨根问底VS浅尝而止，本着了解知识由浅入深，先宏观再深究，先应用再具体的原则来总结UDS的内容。UDS（Unified Diagnostic Services，统一的诊断服务）诊断协议是在汽车电子ECU环境下的一种诊断通信协议。

二、诊断模型

应用层：诊断服务的具体实现，用于tester/client发出诊断请求，server（MCU）根据请求做出不同响应

网络层：中间层，是数据转换的桥梁，包括多帧数据传输，进行数据的打包、拆包，协调上下层工作；还包括对等实体间的通信，数据同步，时间管理，错误管理。

数据链路层：CAN 总线（ISO 11898-1）最初指定的链路层协议仅包括对物理层的抽象需求，ISO11898-1-2015指定了经典CAN帧格式和新引入CAN-FD帧格式。 高速物理层关于电气方面的（电压，电流，数量导体）规定来自于 ISO 11898-2，该协议目前被广泛接受；低速则在 ISO 11898-3 中。但是，物理层关于机械方面的（接头种类和数量、颜色、标签、标准输出）并没有标准文档来正式指定。

物理层：传输所需要的硬件条件，包括收发器，终端电阻，双绞线，距离限制，尺寸；哪些传感器的CANH和CANL连接到网络上，不同速率网络通信需要网关等。

三、诊断流程

客户端(client)/诊断仪(tester)：发送诊断请求者（读写数据，启动例程）

服务器（server/ECU）：诊断响应的提供者-ECU发送诊断响应（正响应、负响应）

远程诊断（Remote diagnosis）：客户端和服务器不在同一个网段

服务函数：

请求request：诊断仪对ECU发送请求

请求_确认req_confirm:当请求被成功收到之后，诊断仪会调用req_confirm表示“请求已经正确的发送成功”

指示indication：ECU收到请求后会有一个指示（回调）告诉ECU上层“收到一个诊断请求”

响应response：ECU对请求处理完之后，会有返回一个响应

响应_确认rsp_confirm:诊断仪收到响应之后，ECU会触发rsp_confirm,表示响应发送成功

确认confirm：当响应发到网络被诊断仪接收到之后，诊断仪会有一个确认confirm（回调），表示已经处理完请求

服务分为两类有确认服务和无确认服务：

有确认服务：

无确认服务：

诊断的流程：

UDS应用层服务原语格式描述：

service_name.type (
parameter A, parameter B, parameter C
[,parameter 1, …]
)

• “service_name” is the name of the diagnostic service (e.g. DiagnosticSessionControl),
• “type” indicates the type of the service primitive (e.g. request, indication,response, confirm, req_confirm and rsp_confirm),
• “parameter A, …” is the A_SDU (Application layer Service Data Unit) as a list of values passed by the service primitive (addressing information),
• “parameter A, parameter B, parameter C” are mandatory parameters that shall be included in all service calls,
• “[,parameter 1, …]” are parameters that depend on the specific service (e.g. parameter 1 can be the diagnosticSession for the DiagnosticSessionControl service). The brackets indicate that this part of the parameter list may be empty.

四、诊断服务SI

（1）首先看下具体有哪些服务

（2）在默认会话和非默认会话支持的服务

五、总结

        ISO 11898是CAN总线的规范，对应于OSI是层一和层二，即物理层和数据链路层。对于物理层来说，定义了CAN总线信号在双绞线上的电压形式，对于数据链路层来说，定义了CAN帧的各个域的用途。

        ISO 15765-2是诊断服务在CAN总线上传输的实现方式，对应于OSI是层4，传输层。对于classical CAN总线来说，它一帧只能承载8个字节，而上层的诊断服务却可能超过8个字节，这时候就需要传输层对数据进行分包重组流控制。ISO 15765-2还定义了应用层、传输层、数据链路层之间的编程接口，其实就是request, confirm, indication这几个原语的定义。ISO 15765-3和ISO 14229-3的内容是一样的，后者取代了前者。ISO 15765-4定义了基于CAN总线实现OBD通信的方式。

        ISO 14229-1 对应于OSI的层7，即应用层，它定义了诊断服务的格式。ISO 14229-2定义了诊断会话中的各种时间参数，比如ECU的响应时间等。ISO 14229-3 一直到ISO 14229-7 分别定义了UDS在CAN,FlexRay, Internet Protocol ，K-Line ，LIN上的实现要求 。

        这三部分协议一起使用，就可以实现完整的诊断功能了。总结来说，ISO 14229-1生成诊断服务，ISO 15765-2对诊断服务进行分包并把分包后的数据交给ISO 11898，ISO 11898给收到的数据加上CAN总线特有的包头和包尾，然后通过双绞线以电压差的形式发送出去。

参考：

UDS入门：UDS诊断 入门学习备忘录_JawSoW的博客-程序员宅基地

CAN 总线 之三 CAN 国际标准 ISO 11898 解读：CAN 总线 之三 CAN 国际标准 ISO 11898 解读_ZC·Shou的博客-程序员宅基地_iso11898

https://www.zhihu.com/question/303256393/answer/542832019

UDS应用层服务原语格式描述_microcosmv的博客-程序员宅基地_uds服务原语