UDS协议:数据传输功能单元

欢迎来到​​《UDS协议详解系列》​​的第3篇文章，本文主要介绍数据传输功能单元的读/写数据服务（$22和$2E）和不同数据长度处理方法（ISO 15765 - 2协议）。

图1 数据传输单元，引自[1]

图2 数据传输形式，引自[2]

读取数据服务（$22）

读取数据服务（$22）是根据DataIdentifier（即DID）去请求读取数据，其请求格式为SID+DID。

注意DID表示存储数据的地方，一般存储整车厂和零件供应商定义的数据，包括模拟输入和输出信号（比如转速信号），数字输入和输出信号（比如车门信号），内部数据和系统状态信息等，这里请求的DID可以是一个，也可以是多个。

图3 引自[1]

该服务的正响应格式为(SID+40)+DID+Data。下面看两个例子：

1）请求一个DID的情况：

2）请求两个DID的情况：

注意这三个DID的数据长度，将涉及下面的数据传输章节内容！

ISO14229请求一个DID（0xF190）的例子：

图4 请求0xF190的数据, 引自[1]

图5 响应0xF190的数据，引自[1]

由上可知DID=0xF190的数据很长，达到了17个字节。

再看一个请求了两个DID（0x010A，0x0110）的例子：

图6 请求0x010A和0x0110的数据，引自[1]

图7 响应0x010A和0x0110的数据，引自[1]

由上可知DID=0x010A的数据有11个字节，DID=0x0110的数据有1个字节。

考虑上文已经介绍了相应服务支持的相应负响应，此处不再列出，但此处我们看一下服务响应执行的流程图，以此可了解到软件执行响应的大致逻辑，即先判断是什么SID，然后判断DID长度是否正确，再判断是否有多个DID......

图8 响应执行流程图，引自[1]

写入数据服务（$2E）

写入数据服务（$2E）是根据DataIdentifier（即DID）去请求写入数据，其请求格式为SID+DID+Data.

注意这里一次只写一个DID的数据，不像读取数据服务（$22）可以一次读取多个DID的数据。通过该服务可以：写入一些配置信息到ECU（比如VIN码），清除非易失性数据，重置学习值，设置一些可选内容。

下面看一个入VIN码到DID（0xF190）的例子：

注意：$2E要在ECU解锁了才能执行，，而回顾上篇文章可知，在默认会话模式不支持$27服务，故先进非默认会话模式解锁，解锁后再写入数据。

ISO14229写入VIN码到DID（0xF190）的例子：

图9 请求写入数据到DID=0xF190，引自[1]

图10 响应成功写入数据到DID=0xF190，引自[1]

以上就简单介绍了读取/写入数据服务（$22和$2E），一般在请求这两个服务前，需要使用安全访问服务（$27）解锁，处于解锁状态才能去读写数据。

另外通过这两个服务的使用发现数据长度有超过8个字节的情况，当使用CAN总线进行UDS通讯时，我们知道一帧数据只能包含8个字节的数据，那意味着无法一帧就传输完所有的数据，那么该怎么处理呢？ISO15765-2协议就被提出来解决该问题。

数据传输处理

ISO15765-2协议提出了单帧传输和多帧传输的概念，通过之前请求-响应例子来理解：

比如上文：请求10 03，响应50 03 00 32 01 F4，这里不管是请求还是响应都只要使用单帧传输就可以了，即用一条CAN帧就可以传输完毕。其具体通讯过程：

比如上文：请求22 F1 90，响应62 F1 90 57 30 4C 30 30 30 30 34 33 4D 42 35 34 31 33 32 36，这里请求单帧传输即可，但响应显然无法单帧传输实现，就需要多帧传输。其具体通讯过程：

对上述通讯过程进行说明：

对于多帧传输，定义了三种帧类型，有FirstFrame(FF，首帧)、ConsecutiveFrame(CF，续帧)和FlowControl(FC，流控帧)，如该例的注释。

怎么识别这三种帧类型？如上例中橙色字体：1开头为首帧，2开头为续帧，3开头为流控帧。

为什么需要这三种类型？由于数据无法一帧数据传输完毕，这时通讯就更复杂：一是客户端需要分多次发送数据，得让服务端明白是否接收数据完整，如何组合接收的数据；二是服务端需要根据自身接收的处理能力来要求客户端如何去发送，比如多长时间发送。因此：

• 先通过首帧会告诉客户端数据有多长，比如这里的 0x0 14，即数据长度有20个字节；

• 然后客户端根据要接收的数据长度，决定是否允许续帧发送（0x0，表示允许发送），每回一帧流控帧后所允许的续帧数量（0x00,表示只发一帧流控帧，服务端将一直发续帧直到全部数据发送完毕），续帧发送的最小时间间隔多长（0x0A，10ms），发送给服务端；

• 最后服务端根据客户端响应的流控帧信息，按规定的要求顺序发送数据给客户端（粉色字体1，2表示续帧的顺序）。

注意：本例涉及的更具体过程可参考下面结合ISO14229标准的解释。

ISO14229标准的逻辑是：先定义一个叫N_PCI的，通过它可知道是单帧还是多帧，是多帧的话，是首帧还是流控帧还是续帧；然后是单帧发送什么内容？是首帧又发送什么内容？....;

首先忽略N_AI，先关注N_PCI，协议定义了4种N_PCI类型。SingleFrame(SF，单帧)用于单帧传输，FirstFrame(FF，首帧)、ConsecutiveFrame(CF，续帧)和FlowControl(FC，流控帧)用于多帧传输。

对于单帧，N_PCI包括N_PCI类型和SF_DL，比如请求10 02，即N_Data为10 02，可知N_PCI类型为单帧，即0；SF_DL为2，即单帧的数据长度为2；那么忽略N_AI，N_PDU包含N_PCI和N_Data，即02 10 02。 对于响应50 02 00 32 01 F4，那么忽略N_AI，N_PDU为06 50 02 00 32 01 F4。

图11 引自[1]

对于首帧、续帧和流控帧，以响应62 F1 90 57 30 4C 30 30 30 30 34 33 4D 42 35 34 31 33 32 36进行说明，数据长得采用多帧传输。

对于首帧，N_PCI包括N_PCI类型和FF_DL，N_PCI类型为首帧，即1；FF_DL为0x14，即单帧的数据长度为20；那么忽略N_AI，N_PDU包含N_PCI和N_Data，即10 14 62 F1 90 57 30 30。注意N_Data已发送部分，还剩下30 30 34 33 4D 42 35 34 31 33 32 36 未发送。如何处理呢？

根据下图12左图的定义，服务端（作为发送方）响应时，发送方发送首帧后，接收方（客户端）接收到了将回复流控帧，即对发送方如何发送续帧做出一些要求，然后发送方再根据接收方的要求发送续帧。

对于流控帧，N_PCI包括N_PCI类型、FS、BS和STmin，这三个参数均是告诉发送方对续帧的要求，其示意如下图12的右图，其具体定义如图13所示。

• N_PCI类型为流控帧，即3；

• FS（flow status）,即流控状态，这里假设其值为0（表示续帧可持续发送，其他状态定义见图13）;

• BS(block size)，即一帧流控帧所允许发送的续帧数量，如果其值为0x00，则表示只发一帧流控帧，服务端将一直发续帧直到全部数据发送完毕，这里假设其值为0x00，其他值定义见图13；

• STmin（separation time）表示要求续帧之间的最小时间间隔，这里假设其值为10ms，即0x0A，其他值定义见图13。

那么忽略N_AI，N_PDU包含N_PCI和N_Data，由上可知N_PCI为30 00 0A，而N_Data为空，因为接收方无数据需发送给发送方，故N_PDU为30 00 0A。

当发送方收到流控帧后，将采用续帧发送剩余的数据。对于续帧，N_PCI包括N_PCI类型和SN，N_PCI类型为续帧，即2；SN（sequence number）,表示续帧的顺序号，具体说明见图14。比如上面还剩余12个字节数据，那意味着还需要两帧续帧才能将数据发送完毕，这时就需要给续帧一个顺序号，让接收方知道，接收方才能按规定和顺序去读取完整的数据。那么忽略N_AI，N_PDU包含N_PCI和N_Data，这需要发送两帧续帧，第一帧为：21 30 30 34 33 4D 42 35，第二帧为：22 34 31 33 32 36。

图12 多帧传输示意，引自[1]

图13 引自[1]

图14 SN的定义，引自[1]

综上多帧传输的详细分析过程，再重复下整个请求--响应过程：

• 客户端请求：22 F1 90 （单帧传输）

• 服务端响应：62 F1 90 57 30 4C 30 30 30 30 34 33 4D 42 35 34 31 33 32 36（多帧传输），其多帧传输的具体过程为：

• 服务端响应首帧(FF): 10 14 62 F1 90 57 30 30

• 客户端收到首帧，发送流控帧（FC）：30 00 0A

• 服务端收到流控帧，发送第一条续帧（CF）：21 30 30 34 33 4D 42 35，

• 服务端间隔10ms（即0x0A）后，发送第2条续帧（CF）：22 34 31 33 32 36

• 服务端响应发送完毕。

以上就简单介绍了ISO14229-1协议的数据传输功能单元的读取/写入数据服务，对读取的数据长度问题，引出了ISO15765-2协议，重点介绍如何进行多帧传输，如下所示：

文章转载自公众号：汽车电子与软件