UDS诊断

电池管理系统BMS 同时被 2 个专栏收录
18 篇文章 40 订阅
4 篇文章 1 订阅
本文转载自:知乎用户——心机之花,网址:https://zhuanlan.zhihu.com/p/37310388,收藏转载仅供自己学习,如有侵权,请联系博主删除,谢谢。

写在前面:UDS实践性强,逻辑复杂,很多服务非要体验过一次才能理解,导致包括我在内的初学者感觉晦涩难懂,不明觉厉,因此将自己的理解写下来、整理下来,与君共勉。

零、UDS诊断命令备忘录

一、简介

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最为核心的功能。

使用电脑进行车辆诊断,诊断线插在OBD接口上

为什么我们要设计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)的解读 zhuanlan.zhihu.com图标

排放相关的诊断内容,即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有一个大致的认识。切记知行合一,实践很重要。

摘自ISO 14229-1-2013
摘自ISO 14229-1-2013
摘自恒润科技公开资料
摘自恒润科技公开资料

二、UDS的服务

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的26种服务

UDS的服务分为6大类,但常用的服务是加背景色的15种。这15种服务又可粗略地划分为权限控制、读取数据/信息、写入数据/信息、通信控制、功能控制这几类(注:这几类是我自己划分的)。

ISO14229-1英文原文中大篇幅的对26种服务进行了解释,英文原文链接如下。学习时如果遇到困惑可以找标准中的相关语句进行翻译,协议是所有学习材料的根本。

ISO14229-1-2013-汽车诊断协议.pdf max.book118.com

本文重点介绍以下几个服务:$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(待机握手)。其他的服务楼主有时间会补齐,敬请期待。

26种服务,其中15种较为常用
少了0x38

$10诊断会话 Diagnostic Session Control

$10包含3个子功能,01 Default默认会话,02 Programming编程会话,03 Extended扩展会话,ECU上电时,进入的是默认会话(Default)

为什么设计三个会话模式呢?因为权限问题。默认会话权限最小,可操作的服务少;扩展模式通常用于解锁高权限诊断服务,例如写入数据/参数、读写诊断码;编程模式用于解锁bootloader相关的诊断服务,即程序烧录。

题外话,讲个故事。这三个会话模式好比普通项目成员(默认会话)、项目组长(扩展会话)和会计(编程会话)的关系,小职员权限最小,小职员有的权限项目组长全有,项目组长还多了些其他的高端权限(如写数据、例程控制)。会计则不同,它有些自己独有的权限(刷写程序),但项目组的很多权限它没有(读/擦故障码),因为它只干会计相关的事,本身不参与项目。

这里来一张权限表格。带颜色的区域代表需要解锁操作。

15个服务在不同会话中的权限情况(本表仅作参考)

如果您进入了一个非默认会话的状态,一个定时器会运转,如果一段时间内没有请求,那么到时间后,诊断退回到默认会话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的中文版本链接。

这里提一下一个特殊的NRC——0x78,requestCorrectlyReceived-ResponsePending(RCRRP,请求已被正确接收-回复待定)。这个NRC表明请求消息被正确地接收,请求消息中的所有参数都是有效的,但是要执行的操作还没有完成,Server端还没有准备好接收另一个请求。一旦请求的服务已经完成,服务器应该发送一个积极的响应或消极的响应,响应代码应与此不同。这个NRC的消极响应可以被Server端重复,直到被请求的服务完成并且最终的响应消息被发送。

当使用此NRC时,服务器应始终发送最终响应(不管正响应还是负响应),与suppress-PosRspMsgIndicationBit值或NRCs SNS、SFNS、SNSIAS、SFNSIAS和ROOR对功能上处理请求的响应抑制要求无关

NRC 0x78坏了规矩的例子
14229-1协议第329页

例子:以CAN总线网络举例。CAN帧一共8个字节,第一字节被网络层占用。(ISO 15765-2的知识)

进入01会话成功,进入02会话失败,进入03会话成功

请求(Request):02 10 02 xx xx xx xx xx ; 02是网络层单帧SF,表示应用层包含有2个字节,10是服务ID(SID),02是子功能——进入编程会话。但ECU婉拒了它的请求。

摘自ISO 14229-1:2013 p39

我们看下上面的图表,这个是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待机握手

$3E服务用于向服务器指示诊断仪仍然连接在网络上,之前已经激活的诊断服务功能可以仍然保持激活状态。

例子:02 3E 80 00 00 00 00 00,发送一个3E服务的报文,保持非默认会话状态。80表示无需回复。

$27安全访问

$27安全访问:ECU当中有很多数据是整车厂独有的,并不希望开放给所有客户,它需要做一个保密的设定。我们在读取一些特殊数据的时候,要先进行一个安全解锁ECU上电之后是一个锁定的状态(Locked),我们通过$27服务,加上一个子服务,再加上一个钥匙,这样的服务请求可以进行解锁。比如下面的例子,2n-1是一个子服务,通过首轮种子的请求,首轮ECU会返回67+01+AA+BB+CC+DD,AA~DD就是种子了。之后第二轮,诊断端会利用种子进行运算(利用整车厂的算法),生成k1(不一定是1个字节),那么发送请求,27+02+[k1]。ECU同样也会通过种子算出k2。当k1和k2匹配时,解锁(Unlocked)成功。

$27安全访问服务的否定响应服务ID也是7F。还记得刚才否定响应的格式吗?7F+27+NRC(否定响应码)。

实际通信的截图,黄色位置是密钥区域

例子:

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读数据

$22读数据,Request(请求):22+DID(Data Identifier,通常是两个字节)

Response(响应):62+DID+Data

DID有一部分已经被ISO 14229-1规定了。比如0xF186就是当前诊断会话数据标识符,0xF187就是车厂备件号数据标识符,0xF188就是车厂ECU软件号码数据ID,0xF189就是车厂ECU软件版本号数据标识符。

14229-1协议第339页

$2E写数据

$2E写数据,Request(请求):2E+DID+Data

Response(响应):6E+DID

写入一个VIN码

正确的顺序是10开头的帧请求、30开头的帧回复、21开头再请求、22开头继续请求、03开头回复确认。我们一帧一帧来看。

  • 10 14根据ISO15765-2代表这是一组多帧中的首帧(属于传输层的信息),一会要发0x14=20个字节的有效数据。之后是2E+F190(代表这是VIN码)+VIN码的前3个字节。意思是作为外部工具,想写入一个VIN码数据。这件事情正常是发生在车辆下线时。
  • 30 00 14是TP层(传输层)的信息,表示这是一个流控帧,ECU发出的,表示可以一直连续发,但连续帧最短的间隔时间要求是20ms。
  • 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 读DTC

19服务是一套诊断服务中的重中之重。协议中篇幅长达63页,通信举例达到了18个。可以说没有19服务,就没有完整的UDS。

DTC(diagnostic trouble code):如果系统检测到了一个错误,它将存储为DTC。DTC可表现为:一个显而易见的故障;通讯信号的丢失(不会使故障灯亮起);排放相关的故障;安全相关的错误等。DTC可以揭示错误的位置和错误类型。通常DTC占用3个字节,OBD II占用两个字节。图中FTB为Fault Type Byte。

故障码包括四个大类,分别是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。

这是ISO15031中的故障码,和UDS中的故障码在长度上有一定的不同

$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列表及其状态都会打印出来。

黄色框是DTC,紧跟着的是DTC状态
同时读取当前/历史故障,黄色框是DTC,紧跟着的是DTC状态

刚才提到,一个DTC除了它自己的3个字节,还有一个字节专门用于表达DTC的状态,这个字节我们叫它DTC状态掩码。这个状态字节每个位的含义下面列举出来。注意,在实际项目中,并不是所有的DTC状态都是支持的。DTC状态掩码前7个位的理解是UDS的一个难点。

关于DTC状态掩码更详细的解释参见文末的学习资料22,张老师有详细的解答。

DTC状态掩码
Request/Response。括号标识循环,可以读出很多DTC

$14清除DTC

清除(复位)DTC格式,它可以改变DTC的状态。DTC状态中的八个位,除bit4和bit6外均会被清零,包含当前故障(TestFailed)和历史故障(ConfirmedDTC)。bit4和bit6这两个testNotCompleted开头的会被强制置1。

3个FF代表清除所有DTC。

Request:14+FF+FF+FF;

Response:54 。

14服务

$2F IO控制

该服务可以通过DID(数据标识符)来进行输入信号的替换和控制零部件负载输出。这是一个用在产线上较多的服务。该报文的请求至少由4个字节组成。第一个字节是2F,第二第三字节是DID,其中第二字节是高位。第四字节是子功能,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是关;也可以是模拟量,比如空调风门的开度。

2F服务,黄色区域为2个字节的DID

上面这个图可以理解为,关闭开关,之后打开开关,之后控制权还给ECU,之后想复位回默认值,但是发现ECU不支持。这里NRC用0x22是否准确,还望大神告知。

2F服务有一个问题,如果通过2F服务修改了某个值,后续也不把控制权还给ECU,那么这个修改的有效时间是一直持续下去?

正确的做法是如果扩展会话超时,即切回默认会话,此时控制权应还给ECU,毕竟 2F的03子功能是"暂时接管控制权"。

6种模式的配置

非默认会话在实际中又细分为编程会话(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应用的设备

在UDS诊断产品中知名度最高,应用最广泛的是德国Vector公司的CAN卡 VN1630/1640 配合其CANoe 软件,Vector 产品功能齐全,适合系统级汽车总线开发,被大部分汽车厂商采用。通常工程师先用Vector的CANdela进行cdd文件的开发,之后将该cdd文件导入CANoe.diva中进行功能测试。下面的链接是Vector提供的全套解决方案,里面的CANdesc是UDS代码生成软件。

ECU诊断开发解决方案 - 图文 - 百度文库 wenku.baidu.com

Vector 产品很好用,节省开发时间,但价格昂贵,不适用于小厂或规模性采购。目前市面上有很多CAN 厂商(如Kvaser, ZLG 等)能提供低成本、体积小、驱动简单、开放API 的设备,很适合进行UDS相关的二次开发。

文不对题的例子

变速器控制单元TCU和防抱死系统ABS是CAN车载网络上的两大电子控制单元, 这2个ECU要通过CAN网络进行大量的信息交互。但是由于电磁干扰、串扰、静电等外界干扰或电控单元本身控制策略引起的通信停止等原因, 2个控制单元之间可能会出现通信丢失的现象。控制系统需要将故障信息(例如通信丢失故障信息) 诊断出来, 以处理通信被破坏时出现丢失帧的故障现象, 并记录为DTC (diagnostic trouble code)。当然,这些DTC也可以用于售后的维修保养。

ECU的输入信号主要有4种形式: ①模拟信号(水温、油压、蓄电池电压等); ②数字信号(各种开关信号等); ③PWM信号(脉冲信号、频率信号等); ④网络信号(CAN、LIN上传输的信号)。ECU可以通过监测这些信号来判别输入电路的工作状况。输出的信号往往用作控制电磁阀、指示灯、步进电机等, 大多数为数字信号。

讨论

问题:如果出现了UDS请求并发的情况,比如2E服务,正在写入、正在处理时,突然有11服务请求闯入,此时ECU会如何处理呢?

观点:此时应继续执行完2E的写入服务,11服务的请求将会被丢弃,不会有任何回复。


大家可以加入公众号:汽车ECU网络诊断技术,了解更多ECU诊断知识。

大家可以加入公众号:汽车ECU开发,了解更多汽车电子知识。

大家可以加入公众号:汽车电子expert成长之路,学习汽车电子知识(NXP为主)。



学习资料:

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.mp.weixin.qq.com/s?

22*.张丁:汽车控制器(ECU)中DTC的状态位

23.UDS_Wikipedia

24.(推荐)关于Autosar中DCM(14229UDS)模块的理解


代码参考:

1.SAE J1939 协议源代码分析(一)-程序结构框架

2.基于CAN总线的汽车诊断协议UDS(上位机开发网络层及错误代码解析) - CSDN博客

3.基于CAN总线的汽车诊断协议UDS(ECU底层模块移植开发) - CSDN博客

4.(推荐)基于CAN总线的汽车诊断协议UDS (网络层 ISO 15765)

5.(推荐)github上的UDS协议栈源码:ukign/UDSDemo

  • 0
    点赞
  • 0
    评论
  • 11
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

©️2021 CSDN 皮肤主题: 1024 设计师:白松林 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值