UDS协议数据传输功能单元.docVIP

UDS协议数据传输功能单元 1 读取数据服务（$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] 2? 写入数据服务（$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协议就被提出来解决该问题。 3? 数据传输处理 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标准的逻辑是：先定义一个叫