写在前面:UDS实践性强,逻辑复杂,很多服务非要体验过一次才能理解,导致包括我在内的初学者感觉晦涩难懂,不明觉厉,因此将自己的理解写下来、整理下来,与君共勉。
![](https://pic2.zhimg.com/v2-da053897466d93763b859865d28b338d_r.jpg)
![](https://pic3.zhimg.com/v2-27c5297ecccb53ded98672923558ad9e_r.jpg)
UDS(Unified Diagnostic Services,统一的诊断服务)诊断协议是在汽车电子ECU环境下的一种诊断通信协议,在ISO 14229中规定。它是从ISO 14230-3(KWP2000)和ISO 15765-3协议衍生出来的。“统一”这个词意味着它是一个“国际化的”而非”公司特定的”标准。到目前为止,这种通信协议被用在几乎所有由OEM一级供应商所制造的新ECU上面。这些ECU控制车辆的各种功能,包括电控燃油喷射系统(EFI),发动机控制系统,变速箱,防抱死制动系统(ABS),门锁,制动器等。
诊断工具与车内的所有控制单元均有连接,且这些控制单元均启用了UDS服务。不同于仅使用OSI模型第一层、第二层的CAN协议,UDS服务使用OSI模型的第五层和第七层(会话层和应用层)。服务ID(SID)和与服务相关的参数包含在CAN数据帧的8个数据字节中,这些数据帧是从诊断工具发出的。
目前市面上的新车都具有用于车外诊断的诊断接口,这使得我们可以用电脑或诊断工具(业内称为测试器Tester)连接到车辆的总线系统上。因此,UDS中定义的消息可以发送到支持UDS服务的控制器(业内称ECU)。这样我们就可以访问各个控制单元的故障存储器或用新的固件更新ECU的程序。除此之外,UDS还用于下线检测时把一些信息(如VIN码)写入到汽车的各个零部件中。这些功能也是UDS最为核心的功能。
![](https://pic3.zhimg.com/v2-4a9cb327697e955fa8d87b8461a80d92_r.jpg)
为什么我们要设计UDS这样的诊断协议呢?在汽车诊断协议诞生之前,修车只能靠师傅的经验,因为汽车零部件不会告诉你它哪里出了问题。但有了诊断协议之后,一旦零部件出了问题或者出过问题,它们会把故障信息保存在内存里面,维修师傅就可以通过通信总线读取这些故障信息,比如一个ECU经历欠压故障之后,它会将欠压故障代表的DTC(诊断故障码)存储起来,可选择性保存的还有发生故障时的快照信息(比如此时的车速、读到的电压值等)。快照信息有助于测试工程师和售后技师查找发生故障的原因。
除了CAN总线以外,UDS也可在不同的汽车总线(例如 LIN, Flexray, Internet 和K-line)上实现。
如下图所示,ISO 14229也就是UDS协议仅对应用层、会话层做出了定义。这里有个疑问,UDS专指ISO 14229-1吗?这种说法是不对的,UDS包含了ISO 14229下属的7个子协议,其中ISO 14229-2还是会话层的,所以UDS仅包括应用层的说法也是错误的。
说明下,我们本篇文章我们仅使用CAN来描述UDS。对于CAN来说,物理层和数据链路层遵循ISO 11898协议;网络层方面,Classical CAN仅有8个字节的数据场与应用层处理多帧数据的需求构成了矛盾,ISO 15765-2协议解决了该问题,我们用CAN的8字节数据场会腾出一到两个字节的做法,来体现网络层的控制信息。
如果希望深入学习下UDS网络层的知识,请移步:
UDS网络层/TP层(ISO 15765-2)的解读
排放相关的诊断内容,即ISO 15031-5主要针对OBD协议,为法规强制要求燃油车满足的协议,电动车是无需满足的。燃油车通常既满足UDS协议,又满足OBD协议,这两个协议不冲突。小伙伴们有没有发现UDS协议的服务ID(SID)最小的是0x10,那是因为小于0x10的服务是OBD协议中规定的。
学习UDS之前,希望您对CAN的基础知识有初步的了解,知道一个CAN帧的基本构成,熟悉至少一种CAN盒的使用方法。协议方面,应通过PPT、论文、原版英文协议重点学习ISO 15765-2和ISO 14229-1的协议内容,之后可以将Git上的开源UDS协议栈移植到你熟悉的嵌入式平台上,进行数据收发;或使用CAN盒与支持UDS诊断的设备进行数据收发,对UDS有一个大致的认识。切记知行合一,实践很重要。
![](https://pic2.zhimg.com/v2-5095d17333415476c471f115d27bb759_r.jpg)
![](https://pic1.zhimg.com/v2-d6b5b10114b5bd8dac4afc79687d045c_r.jpg)
![](https://pic2.zhimg.com/v2-952205a2a48d5ca2a8a0c64b57d1ca0d_r.jpg)
![](https://pic1.zhimg.com/v2-4264a8b3b68826c2fa99ea504f120a34_r.jpg)
UDS本质上是一系列服务的集合。UDS的服务包含6大类,共26种。每种服务都有自己独立的ID,即SID。
SID:Service Identifier,诊断服务ID。UDS本质上是一种定向的通信,是一种交互协议(Request/Response),即诊断方(Tester)给ECU发送指定的请求数据(Request),这条数据中需要包含SID,且SID处于该应用层数据的第一个字节。如果是肯定的响应(Positive Response),首字节回复[SID+0x40],举例子就是请求0x10,响应0x50;请求0x22,响应0x62。如果是否定的响应(Negative Response),首字节回复0x7F,第二字节回复刚才询问的SID。比如Tester请求0x10服务,我想进入编程模式,ECU给出否定响应,首字节0x7F,第二字节回复0x10,代表我否定你的0x10服务请求,第三字节是NRC(否定响应码),代表我否定你的依据。
肯定响应和否定响应的形式一定要熟悉。
通常,在CAN总线中,Addressing information寻址信息会在CAN的帧ID中体现出来,例外是远程寻址,但不常使用。所谓的寻址信息包含了源地址(Source Address)和目标地址(Target Address),就是这条信息是由谁发给谁的,类似于收件人和发件人。当然,ECU回信给Tester时,ECU就变成源地址了。因此源地址和目标地址在UDS中并不是一成不变的。
UDS的寻址模式分两种,一种是物理寻址(点对点、一对一),根据物理地址的不同进行访问,但只能访问单个ECU节点,Tester为SA源地址,ECU作为TA目标地址;对应的,另一种是功能寻址(广播、一对多),根据功能的不同进行访问,它能访问多个ECU节点,对于标准帧来说,通常是0x7DF。
每一个ECU都有2个CAN的诊断帧ID,分别对应物理寻址的收与发。通常由主机厂来确定不同ECU的这两个特定的诊断ID。比如0x701对应接收Tester的消息,0x709对应发给Tester的消息。
UDS的服务分为6大类,但常用的服务是加背景色的15种。这15种服务又可粗略地划分为权限控制、读取数据/信息、写入数据/信息、通信控制、功能控制这几类(注:这几类是我自己划分的)。
ISO14229-1英文原文中大篇幅的对26种服务进行了解释,英文原文链接如下。学习时如果遇到困惑可以找标准中的相关语句进行翻译,协议是所有学习材料的根本。
ISO14229-1-2013-汽车诊断协议.pdf
本文重点介绍以下几个服务:$10 Diagnostic Session Control(诊断会话),$14 Clear Diagnostic Information(清除诊断信息),$19 Read DTC Information,$22 Read Data By Identifier(通过ID读数据),$27 Security Access(安全访问),$2E Write Data By Identifier(通过ID写数据),$3E Tester Present(待机握手)。其他的服务楼主有时间会补齐,敬请期待。
![](https://pic3.zhimg.com/v2-7b37481183478e2d260224327384c73a_r.jpg)
![](https://pic1.zhimg.com/v2-8095164b590d21a59103867533292034_r.jpg)
$10包含3个子功能,01 Default默认会话,02 Programming编程会话,03 Extended扩展会话,ECU上电时,进入的是默认会话(Default)。
为什么设计三个会话模式呢?因为权限问题。默认会话权限最小,可操作的服务少;扩展模式通常用于解锁高权限诊断服务,例如写入数据/参数、读写诊断码;编程模式用于解锁bootloader相关的诊断服务,即程序烧录。
题外话,讲个故事。这三个会话模式好比普通项目成员(默认会话)、项目组长(扩展会话)和会计(编程会话)的关系,小职员权限最小,小职员有的权限项目组长全有,项目组长还多了些其他的高端权限(如写数据、例程控制)。会计则不同,它有些自己独有的权限(刷写程序),但项目组的很多权限它没有(读/擦故障码),因为它只干会计相关的事,本身不参与项目。
这里来一张权限表格。带颜色的区域代表需要解锁操作。
![](https://pic2.zhimg.com/v2-8fd2b47092884a20d29c6d7bbb1898c1_r.jpg)
如果您进入了一个非默认会话的状态,一个定时器会运转,如果一段时间内没有请求,那么到时间后,诊断退回到默认会话01(最低权限)。当然,我们有一个$3E的服务,可以使诊断保持在非默认的状态。
UDS的请求命令有4种构成方式,即SID,SID+SF(Sub-function),SID+DID(Data Identifier)(读写用),SID+SF+DID。每种服务都有自己不同的构成方式,查看服务说明即可,不用死记硬背。
NRC:Negative Response Code(否定响应码)。如果ECU拒绝了一个请求,做出否定响应(Negative Response),它会在第三字节回复一个NRC。不同的NRC有不同的含义。本文开头时有一个常见NRC的图,当然完整版请参照ISO14229附录A。
这里提一下一个特殊的NRC——0x78,requestCorrectlyReceived-ResponsePending(RCRRP,请求已被正确接收-回复待定)。这个NRC表明请求消息被正确地接收,请求消息中的所有参数都是有效的,但是要执行的操作还没有完成,Server端还没有准备好接收另一个请求。一旦请求的服务已经完成,服务器应该发送一个积极的响应或消极的响应,响应代码应与此不同。这个NRC的消极响应可以被Server端重复,直到被请求的服务完成并且最终的响应消息被发送。
当使用此NRC时,服务器应始终发送最终响应(不管正响应还是负响应),与suppress-PosRspMsgIndicationBit值(抑制肯定响应位)或NRCs(SNS、SFNS、SNSIAS、SFNSIAS和ROOR)对功能寻址的处理请求的响应抑制要求无关。这里的有一个特殊的知识点,即什么情况下,功能寻址是不需要给出否定响应的呢?如果被测ECU需要回复上面5个NRC(SNS 0x11、SFNS 0x12、SNSIAS 0x7E、SFNSIAS 0x7F和ROOR 0x31)时,不需要回复否定响应。
![](https://pic4.zhimg.com/v2-8b0a3d8f822425fc0754f7c18425a1df_b.jpg)
![](https://pic3.zhimg.com/v2-f552c77ca59717088afb0020d5262b16_r.jpg)
例子:以CAN总线网络举例。CAN帧一共8个字节,第一字节被网络层占用。(ISO 15765-2的知识)
![](https://pic2.zhimg.com/v2-e08028b3aed27ba0e7a86dcd97e93941_b.jpg)
请求(Request):02 10 02 xx xx xx xx xx ; 02是网络层单帧SF,表示应用层包含有2个字节,10是服务ID(SID),02是子功能——进入编程会话。但ECU婉拒了它的请求。
![](https://pic2.zhimg.com/v2-4b3762e2d49aa861729c578d792451c5_r.jpg)
我们看下上面的图表,这个是ISO 14229定义的0x10服务应具有的请求报文格式,M意为Mandatory 强制。可以看到0x10服务仅有两个字节,整条报文是“服务ID+子功能”,比较简单。
肯定响应:02 50 02 xx xx xx xx xx;02即应用层含两个字节,50=10+40表示对SID的肯定回复,02是子功能。
否定响应:03 7F 10 7E xx xx xx xx;03同上,7F表示否定响应,10是SID,7E是NRC(否定响应码)。
$3E服务用于向服务器指示诊断仪仍然连接在网络上,之前已经激活的诊断服务功能可以仍然保持激活状态。
![](https://pic3.zhimg.com/v2-be53c3c361e5915fced2effc4dec2572_b.jpg)
例子:02 3E 80 00 00 00 00 00,发送一个3E服务的报文,保持非默认会话状态。80表示无需回复。
$27安全访问:ECU当中有很多数据是整车厂独有的,并不希望开放给所有客户,它需要做一个保密的设定。我们在读取一些特殊数据的时候,要先进行一个安全解锁。ECU上电之后是一个锁定的状态(Locked),我们通过$27服务,加上一个子服务,再加上一个钥匙,这样的服务请求可以进行解锁。比如下面的例子,2n-1是一个子服务,这里我们先用n=1,即01子服务来举例子。通过首轮Tester种子的请求(27+01),ECU会返回67+01+AA+BB+CC+DD,AA~DD就是种子了。之后第二轮,诊断端的Tester会利用种子进行运算(根据整车厂的算法),生成k1(不一定是1个字节),之后发送请求,子服务是2n,这里我们还是假定n=1,即02子服务。这样Tester发出的就是27+02+[k1]。之后,ECU同样也会根据第一轮的种子自行算出k2。当ECU检查出k1和k2完全一致时,解锁(Unlocked)成功。
![](https://pic3.zhimg.com/v2-cc398ad24a8ee3117620de016c60125a_r.jpg)
$27安全访问服务的否定响应服务ID也是7F。还记得刚才否定响应的格式吗?7F+27+NRC(否定响应码)。
![](https://pic2.zhimg.com/v2-827de78f545e8c9b3d857deebdf12c89_r.jpg)
例子:
Tester: 02 27 05 00 00 00 00 00 安全访问,05子功能
ECU: 06 67 05 08 27 11 F0 00 肯定响应,回复了对应安全级别的种子
Tester: 06 27 06 FF FF FF FF 00 发送密钥,4个FF。注意06是与05成对使用的。
ECU: 03 7F 27 78 00 00 00 00 若为否定响应,7F+27+NRC
ECU: 02 67 06 00 00 00 00 00 若为肯定响应,通过安全校验
细说下安全验证算法。安全验证算法包括1个核心,3个主体。
第一个主体通常和ECU有关。比如我们先用22服务读取ECU的SN,取其中4个字节,作为“调味料”参与,显然这个“调味料”对于这个ECU来说是不变的,也能通过22服务方便的读取到。
第二个主体seed,通常与ECU的运行时间有关系,是主料,在27服务发送奇数子功能时回复。seed通常一直在发生变化,无法发现其规律。
第三个主体是执行次数,就是算法要执行几轮。执行1轮和2轮得到的结果肯定是不一样的对吧。
最大的核心就是算法了。举个简单的算法,比如seed和ECU SN前4个字节加一下,循环左移两位,执行3轮,return这个数作为key,结束。安全验证就是一把锁,算法越复杂,短时间解开的成本越高,越不易被破解掉。如果失败次数过多还会触发惩罚机制,一段时间内都无法再尝试解锁,防止人为的破解。
$22读数据,Request(请求):22+DID(Data Identifier,通常是两个字节)
Response(响应):62+DID+Data
![](https://pic1.zhimg.com/v2-c9e1fbe12dcc6b1dfd09fe75d9385f64_b.jpg)
DID有一部分已经被ISO 14229-1规定了。比如0xF186就是当前诊断会话数据标识符,0xF187就是车厂备件号数据标识符,0xF188就是车厂ECU软件号码数据ID,0xF189就是车厂ECU软件版本号数据标识符。
![](https://pic4.zhimg.com/v2-829229a9bc09299b732da195212c3783_r.jpg)
$2E写数据,Request(请求):2E+DID+Data
Response(响应):6E+DID
![](https://pic4.zhimg.com/v2-c1e4c712af7df8c57297419937a39797_r.jpg)
正确的顺序是10开头的帧请求、30开头的帧回复、21开头再请求、22开头继续请求、03开头回复确认。我们一帧一帧来看。
- 10 14根据ISO15765-2代表这是一组多帧中的首帧(属于传输层的信息),一会要发0x14=20个字节的有效数据。之后是2E+F190(代表这是VIN码)+VIN码的前3个字节。意思是作为外部工具,想写入一个VIN码数据。这件事情正常是发生在车辆下线时。
- 30 00 0A是TP层(传输层)的信息,表示这是一个流控帧,ECU发出的,表示可以一直连续发,但连续帧最短的间隔时间要求是10ms。
- 21是TP层的信息,表示这是一个连续帧,序号为1。后面是VIN码的第4字节到第10字节。
- 22是TP层的信息,表示这是一个连续帧,序号为2。后面是VIN码的第11字节到第17字节。
- 03是TP层的信息,这里说的这个TP层的信息是传不到应用层的,即这是一个用完就会抛弃的信息。03的0表示这是一个单帧,3表示后面有3个有效字节。6E表示我们确认执行了2E服务的请求,这个请求写入的ID是F1 90,即VIN码。
注意,比如0xF190等DID不支持直接写入数据,需要用$10来进行会话转换。也就是说,对于写数据的请求,一般来说需要在一个扩展会话,和安全等级1的状态下才能进行。
19服务是一套诊断服务中的重中之重。协议中篇幅长达63页,通信举例达到了18个。可以说没有19服务,就没有完整的UDS。
DTC(diagnostic trouble code):如果系统检测到了一个错误,它将存储为DTC。DTC可表现为:一个显而易见的故障;通讯信号的丢失(不会使故障灯亮起);排放相关的故障;安全相关的错误等。DTC可以揭示错误的位置和错误类型。通常DTC占用3个字节,OBD II占用两个字节。图中FTB为Fault Type Byte。
![](https://pic3.zhimg.com/v2-0dd415c43a050999a287a112dc84eabe_r.jpg)
故障码包括四个大类,分别是PCBU,P是powertrain动力系统,C是Chassis底盘,B是Body车身,U是network通信系统。一个DTC信息占用4个字节。最后一个字节是DTC的状态。DTMMiddleByte和DTCLowByte两个字节是我们熟知的类似P0047(ISO15031中的故障码)中“0047”的纯数字故障码。第一个字节在乘用车中,前两个bit代表P/C/B/U(动力/底盘/车身/网络)中的一个,之后六个bit是数字,合在一起的样子形如“C01”。第一个字节的前2个bit中,用00/01/10/11分别表示P/C/B/U。(感谢aymjwwl007)
举个例子,U312345这个故障码(我杜撰的),它的状态是Test failed叠加Confirmed,那么DTC信息这四个字节就应该是0xF1(二进制11110001),0x23,0x45,0x09。
![](https://pic1.zhimg.com/v2-f2be75709e210c5b1ac87fc7b612c8ac_r.jpg)
![](https://pic3.zhimg.com/v2-9fa334cde3c04c880eb0106940321e4e_r.jpg)
$19拥有28个子服务(Sub-Function)。常用的子服务有:
01 (读取符合掩码条件的DTC数量)(必须支持),后面的参数是DTC状态掩码,若为01表示我想读当前故障,若为08表示我想读历史故障,若为09表示当前故障和历史故障都想读。
在肯定回复时,组合应该是59(19+40) – 01 (子功能) – 09 (本ECU所支持的掩码条件)-01 DTC的格式(ISO14229-1为01) – 00 01 (目前满足条件的DTC有一个)
02(读取符合掩码条件的DTC列表及其状态)(必须支持),后面的参数是DTC状态掩码,解读同上。
在肯定回复是,59 – 02(子功能)- 09(本ECU所支持的掩码条件) – XX XX XX ( DTC,车厂定义 ) – 01 (这个故障码怎么了,01表示当前故障)
04(读取快照信息),也叫冻结帧。
06(读取扩展信息)。
0A(读取ECU支持的所有DTC列表及其状态)(必须支持)。这个就不必发DTC状态掩码了。所有支持的DTC列表及其状态都会打印出来。
![](https://pic3.zhimg.com/v2-66e655dc290de2e290577bebe73df36a_r.jpg)
![](https://pic2.zhimg.com/v2-8447ef3fa5b76bf58c00c0a86ae78de1_r.jpg)
刚才提到,一个DTC除了它自己的3个字节,还有一个字节专门用于表达DTC的状态,这个字节我们叫它DTC状态掩码。这个状态字节每个位的含义下面列举出来。注意,在实际项目中,并不是所有的DTC状态都是支持的。DTC状态掩码前7个位的理解是UDS的一个难点。
关于DTC状态掩码更详细的解释参见文末的学习资料22,张老师有详细的解答。
![](https://pic1.zhimg.com/v2-3a9744d8b3be1c25160057d96b2b77dc_r.jpg)
![](https://pic1.zhimg.com/v2-e3afdb22c7da560a0154f4c93596ce44_r.jpg)
清除(复位)DTC格式,它可以改变DTC的状态。DTC状态中的八个位,除bit4和bit6外均会被清零,包含当前故障(TestFailed)和历史故障(ConfirmedDTC)。bit4和bit6这两个testNotCompleted开头的会被强制置1。
3个FF代表清除所有DTC。
Request:14+FF+FF+FF;
Response:54 。
![](https://pic1.zhimg.com/v2-901e517039fd104a965345380f3af5f8_r.jpg)
该服务可以通过DID(数据标识符)来进行输入信号的替换和控制零部件负载输出。这是一个用在产线上较多的服务。该报文的请求至少由4个字节组成。第一个字节是2F,第二第三字节是DID,其中第二字节是高位。第四字节是input Output Control Parameter(并不算一个子功能),可以看做IO控制类型。
IO控制类型分为4类,
00是控制权还给ECU,Return Control To ECU。
01是复位为默认值,Reset to Default。
02是冻结当前的状态,Freeze Current State。
03是短暂接管控制权,Short Term Adjustment。
若控制类型是00-02这三种,请求报文是4个字节。
若控制类型是03,请求报文的第五字节是控制代码,可以是数字量,比如01是开,00是关;也可以是模拟量,比如空调风门的开度。
![](https://pic3.zhimg.com/v2-0c2d6e6afbc66cac1fdcd4acaab43006_r.jpg)
上面这个图可以理解为,关闭开关,之后打开开关,之后控制权还给ECU,之后想复位回默认值,但是发现ECU不支持。这里NRC用0x22是否准确,还望大神告知。
2F服务有一个问题,如果通过2F服务修改了某个值,后续也不把控制权还给ECU,那么这个修改的有效时间是一直持续下去?
正确的做法是如果扩展会话超时,即切回默认会话,此时控制权应还给ECU,毕竟 2F的03子功能是"暂时接管控制权"。
非默认会话在实际中又细分为编程会话(Programming Diagnostic Session)和扩展会话(Extended)。在UDS的实际应用中,我们需要对26种服务针对不同会话、不同寻址模式的支持度进行配置。
也就是说,物理寻址+默认会话、物理寻址+编程会话、物理寻址+扩展会话、功能寻址+默认会话、功能寻址+编程会话、功能寻址+扩展会话,共6个模式。那么我们可以脑补一个26行、6列的表格了。
举个例子,对于10、11、3E、22(22有分歧)服务,它们需要支持所有的6个模式(物理+功能寻址)。
对于14、19服务,DTC相关,要求支持默认+扩展会话的4个模式(物理+功能寻址)。
对于27服务,即安全访问服务,仅支持扩展+物理、编程+物理2个模式。
对于2E、2F服务,仅支持扩展+物理1个模式,且要求安全等级为1。
对于34、36、37服务,涉及程序下载,仅支持编程+物理1个模式,且要求安全等级为2。
对于28、85服务,有些要求支持编程+扩展会话的4个模式,有些则要求仅支持扩展会话的2个模式。
对于31服务,要求安全等级为1,有些要求支持扩展+物理、编程+物理2个模式,有些则要求仅支持扩展+物理1种模式。
抑制肯定响应指示位(Suppress Positive Response Message Indication Bit)顾名思义,这个位是用来抑制肯定响应的。即本应回复肯定响应帧,但是发出方要求对方静默,不需要对方回复肯定响应。这个位的位置和子服务在同一个字节(应用层数据第二字节),为bit7,高位。
比如SID是0x10,子服务是0x01,如果是抑制肯定响应的话,子服务这个字节要改成0x81。这样发下去ECU就不会回复肯定响应了。
通常,10、28、3E、85服务是需要支持抑制肯定响应这个功能的。11服务部分厂家也是要求支持的。
以上只是一些粗浅的理解。对26种服务更详细的解读请拉到屏幕下方参考张老师的8篇文章。张老师也开通了微信公众号,"汽车ECU网络诊断技术"。可以去关注一下。
在UDS诊断产品中知名度最高,应用最广泛的是德国Vector公司的CAN卡 VN1630/1640 配合其CANoe 软件,Vector 产品功能齐全,适合系统级汽车总线开发,被大部分汽车厂商采用。通常工程师先用Vector的CANdela进行cdd文件的开发,之后将该cdd文件导入CANoe.diva中进行功能测试。下面的链接是Vector提供的全套解决方案,里面的CANdesc是UDS代码生成软件。
ECU诊断开发解决方案 – 图文 – 百度文库
Vector 产品很好用,节省开发时间,但价格昂贵,不适用于小厂或规模性采购。目前市面上有很多CAN 厂商(如Kvaser, ZLG 等)能提供低成本、体积小、驱动简单、开放API 的设备,很适合进行UDS相关的二次开发。
问题:如果出现了UDS请求并发的情况,比如2E服务,正在写入、正在处理时,突然有11服务请求闯入,此时ECU会如何处理呢?
观点:此时应继续执行完2E的写入服务,11服务的请求将会被丢弃,不会有任何回复。
AUTOSAR使用DCM、DEM、FIM、DET模块来共同实现诊断。我们主要讨论前两个模块。
![](https://pic3.zhimg.com/v2-03ceb6e745527152a48e94c080e229ea_r.jpg)
DCM,全称Diagnostic Communication Manager,为诊断服务提供通用接口。DCM帮我们处理总线上的诊断请求,在其提供的callback函数中,我们可以添加诸如DID数据、27运算结果等信息。
DEM,全称Diagnostic Event Manager,为DCM提供错误信息。应用层可以调用DEM提供的接口以决定某个DTC被Test为Pass或Fail。
对于DCM来说,这个模块还是太大了,我们又将其分为3个独立的子模块。
DSL,全称Diagnostic Session Layer,用于确保诊断请求和响应的数据流,监控诊断请求和响应的时序,管理诊断会话和安全等级。这一层是DCM的最外圈,叫他外环吧,它直接与PduR相接触,获取CanTp经由PduR上传的数据。
DSD,全称Diagnostic Service Dispatcher,用于处理诊断数据流。它位于DCM的中环,夹在DSL和DSP的中间。
DSP,全称Diagnostic Service Processing,实现每个具体的诊断服务,位于DCM的内环,这一层事无巨细。比如22服务、27服务的callback正是源于这一层。
大家可以加入公众号:汽车ECU网络诊断技术,了解更多ECU诊断知识。
大家可以加入公众号:汽车ECU开发,了解更多汽车电子知识。
大家可以加入公众号:汽车电子expert成长之路,学习汽车电子知识(NXP为主)。
如果您对我的文章感兴趣欢迎点赞或留言,大家有什么关于车辆诊断/CAN总线的问题都可以留言给我,闲下来的时候我会针对热点问题写新的文章。谢谢大家!
视频教程:
1.【【官方自制】UDS Protocol_哔哩哔哩_bilibili】【官方自制】UDS Protocol_哔哩哔哩_bilibili
2.【汽车总线技术】UDS诊断基础讲解合集_哔哩哔哩_bilibili
学习资料:
1.(全系列推荐)统一诊断服务 (Unified diagnostic services , UDS) (一)
2.统一诊断服务 (Unified diagnostic services , UDS) (二)
3.统一诊断服务 (Unified diagnostic services , UDS) (三)
4.统一诊断服务 (Unified diagnostic services , UDS) (四)
5.统一诊断服务 (Unified diagnostic services , UDS) (五)
6.统一诊断服务 (Unified diagnostic services , UDS) (六)
7.统一诊断服务 (Unified diagnostic services , UDS) (七)
8.基于CAN总线实现的UDS诊断(DoCAN)
9.【图文】UDS诊断服务_百度文库
10.CAN诊断基础-上部分_图文_百度文库
11.CAN诊断-下_已读_图文_百度文库
12.(推荐)ISO 14229+统一诊断服务
13.FlashBootloader_图文_百度文库
14.帐号登录
15.ISO 15031-5-2015
16.ISO 15765-3车载诊断标准-详细中文版
17.吉利汽车基于CAN线诊断技术规范_百度文库
18.UDS(ISO14229-2006) 汉译(No.7 应用层协议)
19.基于UDS标准的Flash Boot Loader 设计浅析
20.[图文]UDS诊断详解 – 百度文库
21.UDS诊断服务在车载ECU中的应用分析 – 百度文库
22.https://mp.weixin.qq.com/s?__biz=MzUyODgyMDI0OQ==&mid=2247483717&idx=2&sn=55e317acf1268f413f082c12b2cfa119&chksm=fa6b3033cd1cb925d9ead4bbb2dade0f9717e38b5818ceda53598d9f41b9f6469dfb8722b950&mpshare=1&scene=1&srcid=0529MTVAi9sTNyQA862pqGHf&pass_ticket=fXKprCqzX9p9OZ9nJFyHAS%2F9MqiG8sEkIcD5esPpqLN3MWs6fob6jp9mteazPgiW#rd
22*.张丁:汽车控制器(ECU)中DTC的状态位
23.UDS_Wikipedia
24.(推荐)关于Autosar中DCM(14229UDS)模块的理解
25.AUTOSAR_SWS_DiagnosticCommunicationManager(V4.2.2).pdf
代码参考:
1.SAE J1939 协议源代码分析(一)-程序结构框架
2.基于CAN总线的汽车诊断协议UDS(上位机开发网络层及错误代码解析) – CSDN博客
3.基于CAN总线的汽车诊断协议UDS(ECU底层模块移植开发) – CSDN博客
4.(推荐)基于CAN总线的汽车诊断协议UDS (网络层 ISO 15765)
5.(推荐)github上的UDS协议栈源码:ukign/UDSDemo
更新历史:
2019.7.3 更新文章结构,重写开头和0x10服务。
2022.1.16 修正$2F的错误。