前言：
本人目前在一家智驾公司实习，接触到了诊断的标准之一ISO15765，网上的资料很多，但是感觉对小白不太友好，尤其是一些专用术语比较苦涩难懂，但是这标准在汽车诊断中又非常重要，本文就以小白的视角来带你了解认识ISO15765和ISO 14229
什么是ISO15765？
直接上定义和组成(づ｡◕‿‿◕｡)づ
定义：
ISO 15765 是国际标准化组织（ISO）制定的一个关于汽车诊断通信的标准系列，全称为 ISO 15765 - Road vehicles - Diagnostic communication（道路车辆—诊断通信）。它定义了一种用于在车载网络（如 CAN、Ethernet 等）上传输诊断数据的协议栈。
组成：
ISO 15765 标准分为四个部分，每个部分负责不同的功能：
1、ISO 15765-1: 概述和用例（General Information and Use Cases）
-
提供了 ISO 15765 标准的背景、目的和适用范围。
-
描述了诊断通信的基本概念和应用场景（如故障诊断、ECU 编程等）
2、 ISO 15765-2: 网络层协议（Network Layer Protocol）
我们知道，普通CAN总线一帧只能传输8字节的数据，而在实际使用中有些消息长度超过8字节，无法通过CAN一帧来传输，ISO 15765-2就是解决这个问题，它通过将该消息按照一定规则进行分割，重组为若干个CAN帧进行传输，从而解决数据长度过长的问题，这种“分割”、“重组”被称为拆包和组包。
2.1、拆包
拆包：用于将接收到的数据从底层协议解封装并提取出上层协议数据的过程。通俗讲就是将消息长度超出CAN帧容量的数据按照一定规则拆成多个CAN帧进行传输
2.2、组包
组包：将接收到的多个 CAN 帧重新组合成 完整的 N_PDU。
在 ISO 15765-2 标准中，N_PDU（Network Protocol Data Unit，网络层协议数据单元）是网络层协议中用于传输诊断数据的基本单位，它是由N_PCI（Network Protocol Control Information，网络协议控制信息）和N_Data（Network Data，网络层数据）组成
N_PCI：网络层协议控制信息。用于标识帧类型（N_PDU类型）、控制数据传输（如帧类型、数据长度、帧序号等），也用于告诉接收方如何处理 N_PDU 中的数据部分（N_Data）。
N_Data：网络层数据。包含实际的应用层数据（如诊断请求或响应）
2.3帧解析
下图是N_PDU的组成和类型
N_PDU类型：分为四个类型，单帧SF、首诊FF、连续帧CF、流控帧FC。
Byte0、Byte1、Byte2：表示帧的前三个字节
Bit7~4、Bit3~0：分别表示首字节的高四位和低四位
我们分类型一个一个看
2.3.1单帧SingleFrame（SF）
单帧仅用一帧即可完成传输。单帧第一个字节byte0的高4位固定为0，第一个字节Byte0的低四位（S_DLC）规定为接下来准备传输的数据长度，从第二个字节Byte2起为传输的数据。
2.3.2首帧FirstFrme（FF）
当一条消息需要多帧传输时，那么组包后的第一帧被叫做首帧。首帧第一个字节Byte0的高4位固定为1，第一个字节Byte0的低四位和第二字节加起来（FF_DLC）规定为接下来准备传输的数据长度，从第三个字节Byte2起为传输的数据。
2.3.3连续帧ConsecutiveFrame(CF)
当一条消息需要多帧传输时，除首帧外的其他帧被称为连续帧，连续帧第一个字节Byte0的高4位固定为2，第一个字节Byte0的低四位为连续帧编号（SN），第一条连续帧编号为1，依次增加，SN范围0~15；当SN=15时，下一条连续帧编号置0，依次循环。第二个字节Byte1起为传输的数据。
2.3.1流控帧FlowControl (FC)
流控帧的作用在于告知发送端接收端的接收能力。流控帧第一个字节Byte0的高4位固定为3，第一个字节Byte0的低四位FS（ Flow Status）用于指示数据流的控制状态，常取值有：
0表示数据流处于正常状态，可以继续发送数据；
1表示网络或接收方出现拥塞，发送方应降低数据发送速率；
2表示数据流已关闭，发送方不应再发送数据；
3表示数据流暂时停止，发送方应暂停发送数据，直到收到恢复通知；
4表示数据流中出现错误，发送方应停止发送数据并处理错误。
第二字节BS（BlockSize）用于指示发送方在接收到流控帧后，可以连续发送的最大帧数。常取值有：
0表示发送方可以连续发送连续帧，无需等待接收方的流控帧
1-255表示发送方在发送指定数量的连续帧后，必须等待接收方的下一个流控帧
第三字节STmin（SeparationTimeMin）表示发送方在发送连续帧时，相邻两帧之间的最小时间间隔。常取值有：
0x00-0x7F：表示时间间隔为 0ms 到 127ms。
0x80-0xF0：保留值，未使用。
0xF1-0xF9：表示时间间隔为 100µs 到 900µs（以 100µs 为步长）。
0xFA-0xFE：保留值，未使用。
0xFF：表示发送方可以自由选择时间间隔（无限制）。
2.4帧传输
2.4.1单帧
单帧仅用一帧即可完成传输，故比较简单
2.4.2多帧
多帧需要进行拆组分成首帧和连续帧，发送方发送首帧，等待接收方发送流控帧，发送方再根据流控帧信息发送对于数量和时间间隔的连续帧
2.5CAN ID定义
CAN ID（Controller Area Network Identifier）是CAN协议中用于标识消息的唯一标识符，它不仅用于标识消息的内容，还决定了消息的优先级、目标节点以及通信方式，为了将数据发送指定节点，就需要对源地址以及目标地址进行编码。这里介绍一种基于地址的编码方式——标准地址编码
2.5.1标准地址编码
标准地址编码指CAN ID由以下几部分组成
（1）源地址（N_SA, Network Source Address）：发送消息的节点地址。
（2）目标地址（N_TA, Network Target Address）：接收消息的节点地址。
（3）目标地址类型（N_TAtype, Network Target Address Type）：标识目标地址是物理地址还是功能地址。
物理地址：指向具体的设备或节点。
功能地址：指向一组设备或节点（广播或组播）。
（4）消息类型（Mtype, Message Type）：标识消息的类别或功能。
2.5.1标准地址编码格式
标准地址编码的CAN ID格式可以根据具体的应用需求设计。以下是两种常见的格式：
（1）11-bit标准CAN ID格式
| 字段 | 位数 | 描述 |
|---|---|---|
| 源地址（N_SA） | 8 | 发送消息的节点地址。 |
| 目标地址（N_TA） | 8 | 接收消息的节点地址。 |
| 目标地址类型（N_TAtype） | 1 | 0：物理地址，1：功能地址。 |
| 消息类型（Mtype） | 3 | 标识消息的类别或功能。 |
此时编码方式：CAN ID = (N_SA << 3) | (N_TA << 1) | N_TAtype | Mtype
（2）29-bit标准CAN ID格式
| 字段 | 位数 | 描述 |
|---|---|---|
| 源地址（N_SA） | 8 | 发送消息的节点地址。 |
| 目标地址（N_TA） | 8 | 接收消息的节点地址。 |
| 目标地址类型（N_TAtype） | 1 | 0：物理地址，1：功能地址。 |
| 消息类型（Mtype） | 3 | 标识消息的类别或功能。 |
| 其他字段 | 9 | 用于扩展或其他控制信息。 |
此时编码方式：CAN ID = (N_SA << 21) | (N_TA << 13) | (N_TAtype << 12) | (Mtype << 9) | OtherFields
2.6帧传输超时控制
ISO15765-2中针对帧传输之间的时间间隔制定相应超时机制，在网络层中有如下几个时间参数：
| 时间参数 | 描述 | 超时时间(ms) | 运行需求(ms) |
| N_As | 发送端发送一条CAN消息的时间 | 1000 | N/A |
| N_Ar | 接收端发送一条CAN消息的时间 | 1000 | N/A |
| N_Bs | 发送端发送首帧后到接受到流控帧的时间 | 1000 | N/A |
| N_Br | 接收端收到首帧后到发送流控帧的时间 | N/A | (N_Br+N_Ar)<(0.9*N_Bs) |
| N_Cs | 发送端收到流控帧后到发送连续帧的时间 | N/A | N_Cs+N_As)<(0.9*N_Cr) |
| N_Cr | 接收端收下一个连续帧的时间 | 1000 | -------- |
将多帧传输图结合起来
若超时，则相应的处理方法如下
| 时间参数 | 描述 | 超时时间 (ms) | 超时后的处理机制 |
|---|---|---|---|
| N_As | 发送端发送一条CAN消息的时间 | 1000 | - 记录错误，尝试重新发送消息。 - 多次重试失败后，上报错误并停止发送。 |
| N_Ar | 接收端发送一条CAN消息的时间 | 1000 | - 记录错误，尝试重新发送消息。 - 多次重试失败后，上报错误并停止响应。 |
| N_Bs | 发送端发送首帧（FF）后到接收到流控帧（FC）的时间 | 1000 | - 终止当前通信，尝试重新发送首帧（FF）。 - 多次重试失败后，上报错误并停止发送。 |
| N_Br | 接收端收到首帧后到发送流控帧的时间 | N/A | - 终止当前通信，尝试重新接收首帧（FF）。 - 多次重试失败后，上报错误并停止响应。 |
| N_Cs | 发送端收到流控帧后到发送连续帧（CF）的时间 | N/A | - 终止当前通信，尝试重新发送首帧（FF）。 - 多次重试失败后，上报错误并停止发送。 |
| N_Cr | 接收端接收下一个连续帧的时间 | 1000 | - 终止当前通信，尝试重新接收首帧（FF）。 - 多次重试失败后，上报错误并停止响应。 |
ok，如果到这里你没什么问题的话，那么我们就顺利完成了 ISO 15765-2: 网络层协议的入门内容
3、ISO15765-3 应用层定义
3.1概述
ISO15765-3这里主要讲一下里面的重点——数据层定义，我学习之后做了个不恰当的比方，ISO 15765-2是“网络层协议”（Network Layer Protocol），核心是定义了如何在CAN总线上传输超过8个字节的数据。具体包括：SF、FF、CF、CF；与ISO15765-3相比较，就好比医院开药，ISO 15765-2是药师，仅仅用于给你分配药物（分配帧），而ISO15765-3是医师，将这些药物的药效给你进行说明（给予帧的实际诊断意义，也就是对数据进行定义），有了这一印象，就好理解接下来的内容了。
3.2组成
这里的数据定义就是实际意义上的UDS（Unified Diagnostic Services，统一诊断服务），它也在ISO14229-1有定义。
3.2.1服务标识符及子服务标识
一条诊断报文通常是由服务标识符（Service Identifier, SID） 和 子服务标识（Sub-function, SI） 构成，说的再多没有一个表格来得实在，以下表格是一些常见的SID以及和他相应的SI，其中服务标识符的位置是该帧Data的第一个字节，子服务标识是该帧Data的第二个字节
| 服务ID（SID） | 服务名称 | 功能描述 | 子功能/DID示例 |
| 0x10 | Diagnostic Session Control | 切换ECU的诊断会话模式。 | 0x01：默认会话（Default Session） |
| 0x02：编程会话（Programming Session） | |||
| 0x03：扩展会话（Extended Session） | |||
| 0x11 | ECU Reset | 复位ECU。 | 0x01：硬复位（Hard Reset） |
| 0x02：软复位（Soft Reset） | |||
| 0x03：钥匙复位（Key Off Reset） | |||
| 0x14 | Clear Diagnostic Information | 清除ECU中存储的诊断信息（如故障码）。 | 无子功能，通常与DTC组号一起使用。 |
| 0x19 | Read DTC Information | 读取ECU中存储的故障码（DTC）信息。 | 0x01：读取DTC数量 |
| 0x02：读取DTC状态 | |||
| 0x04：读取DTC快照数据 | |||
| 0x06：读取扩展DTC信息 | |||
| 0x22 | Read Data By Identifier | 通过数据标识符（DID）读取ECU中的数据。 | DID示例： |
| 0xF100：VIN（车辆识别码） | |||
| 0xF121：ECU硬件版本 | |||
| 0xF187：软件版本号 | |||
| 0x23 | Read Memory By Address | 通过内存地址读取ECU中的内存数据。 | 需要指定内存地址和长度。 |
| 0x24 | Read Scaling Data By Identifier | 通过标识符读取ECU中的缩放数据（如传感器校准数据）。 | DID示例： |
| 0xF110：发动机转速校准数据 | |||
| 0x27 | Security Access | 安全访问服务，用于解锁受保护的功能（如写入数据或软件更新）。 | 0x01：请求种子（Seed） |
| 0x02：发送密钥（Key） | |||
| 0x28 | Communication Control | 控制ECU的通信行为（如禁用或启用某些消息的发送）。 | 0x00：启用通信 |
| 0x01：禁用通信 | |||
| 0x2E | Write Data By Identifier | 通过数据标识符（DID）向ECU写入数据。 | DID示例： |
| 0xF190：写入VIN（车辆识别码） | |||
| 0xF12A：写入校准数据 | |||
| 0x2F | Input Output Control By Identifier | 通过标识符控制ECU的输入输出行为。 | DID示例： |
| 0xF130：控制发动机启停 | |||
| 0x31 | Routine Control | 控制ECU中的诊断例程（如启动、停止或查询例程状态）。 | 0x01：启动例程 |
| 0x02：停止例程 | |||
| 0x03：查询例程状态 | |||
| 0x34 | Request Download | 请求下载数据到ECU（用于软件更新）。 | 需要指定数据地址和长度。 |
| 0x35 | Request Upload | 请求从ECU上传数据。 | 需要指定数据地址和长度。 |
| 0x36 | Transfer Data | 传输数据块（用于下载或上传数据）。 | 数据块内容由具体应用决定。 |
| 0x37 | Request Transfer Exit | 请求结束数据传输（用于下载或上传数据）。 | 无子功能。 |
| 0x3E | Tester Present | 通知ECU诊断工具仍然在线，以保持诊断会话。 | 0x00：无子功能 |
| 0x85 | Control DTC Setting | 控制DTC（故障码）的存储和报告行为。 | 0x01：启用DTC存储 |
| 0x02：禁用DTC存储 | |||
| 0x86 | Response On Event | 配置ECU在特定事件发生时自动发送响应。 | 0x01：启用事件响应 |
| 0x02：禁用事件响应 | |||
| 0x87 | Link Control | 控制通信链路的建立和释放。 | 0x01：建立链路 |
| 0x02：释放链路 |
3.2.2响应标识符
服务标识符一般是诊断仪向ECU的请求，而响应标识符一般是ECU针对请求而发送的响应，响应标识符分为肯定响应和否定响应
肯定响应SID = 请求SID + 0x40
如切换ECU的诊断会话模式的请求SID是 0x10，则肯定响应SID是0x50
否定响应SID固定为7F
3.3实例实战
学完ISO15765-2，ISO15765-3之后，你应该就看的懂一些简单的诊断报文了，来练练手吧
解析以下UDS报文，判断是什么帧，有什么诊断的意义？
· 02 10 02 00 00 00 00 00
首字节0x02：第一个字节byte0的高4位为0，故为单帧，
第一个字节Byte0的低四位2代表数据长度为 2字节，
第二个字节SID=0X10 第三个字节SuF=0x02：属于切换ECU的诊断会话模式中的编程会话模式
· 06 50 02 00 32 01 F4 00
首字节0x06：第一个字节byte0的高4位为0，故为单帧，
第一个字节Byte0的低四位6代表数据长度为 6字节
SID=0X50 SuF=0x02：肯定响应切换ECU的诊断会话模式中的编程会话模
· 30 00 00 00 00 00 00 00
首字节0x30：第一个字节byte0的高4位为3，故为流控帧，
第一个字节Byte0的低四位0代表FS=0，表示数据流处于正常状态，可以继续发送数据；
第二个字节为0代表BS=0，表示发送方可以连续发送连续帧，无需等待接收方的流控帧；
第三个字节为0代表STmin=0，表示时间间隔为 0ms
（暂时写到这）
扫一扫
3796
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
