
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协议,重点介绍如何进行多帧传输,如下所示:
文章转载自公众号:汽车电子与软件
