UDS最全内容总结.doc

《UDS最全内容总结.doc》由会员分享，可在线阅读，更多相关《UDS最全内容总结.doc（19页珍藏版）》请在课桌文档上搜索。

1、前言2UDS 的7种效劳及肯定响应和否认响应的形式3$10诊断会话5$3E待机握手6$27平安访问7$22读数据8$2E写数据8$19 读DTC8$14去除DTC10统一诊断效劳 (Unified diagnostic services ， UDS) 一10Diagnostic request的格式：10统一诊断效劳 (Unified diagnostic services ， UDS) 二12Diagnostic Session Control (0*10)12诊断response的格式：Diagnostic Session Control13ECU Reset 诊断request的格式13

2、Security Access (0*27)13统一诊断效劳 (Unified diagnostic services ， UDS) 三14Tester Present (0*3E)15Control DTC Setting (0*85)16Response On Event (0*86)16Link Control (0*87)16统一诊断效劳 (Unified diagnostic services ， UDS) 四16Read Data By Identifier (0*22)160*23效劳的请求格式0*2317统一诊断效劳 (Unified diagnostic services ，

3、 UDS) 五170*14:Clear Diagnostic Information170*19:Read DTC Information18统一诊断效劳 (Unified diagnostic services ， UDS) 六19Input Output Control By Identifier (0*2F)19Routine Control (0*31)20统一诊断效劳 (Unified diagnostic services ， UDS) 七21Request Download 0*34：21Transfer Data0*36：22Request Transfer E*it0*37：

4、22基于CAN总线实现的UDS诊断DoCAN23前言UDS协议即ISO14229,是Unified Diagnostic Services，统一诊断效劳，是诊断效劳的规化标准，比方读取故障码应该向ECU发什么指令，读数据流又是发什么指令。OBD是关注车辆售后实时排放的理念形成的行业规，而UDS是诊断效劳的统一化规，只是应用层的规。UDS(Unified diagnostic services)，与OBD最大的区别就在于“Unified上，UDS是面向整车所有ECU(电控单元)的，而OBD是面向排放系统ECU的。简单说UDS而言，它只是一个应用层协议(ISO 14229-1)，所以它既可以在CA

5、N线上实现(见下列图.1)，甚至也能在Ethernet上实现(DOIP, Diagnostic over Internet protocol 见下列图.2)。并且，UDS提供的是一个诊断效劳的根本框架，主机厂和零部件供给商可以根据实际情况选择实现其中的一局部或是自定义出一些私有化的诊断效劳来，所以基于UDS协议的诊断又常常被称为Enhanced diagnostic(增强型诊断)，UDS不是法规要求的，没有统一实现标准，其优势在于方便生产线检测设备的开发，同时更大的方便了售后维修保养和车联网的功能实现。UDSUnified Diagnostic Services，统一的诊断效劳诊断协议是ISO

6、 15765 和ISO 14229 定义的一种汽车通用诊断协议，位于OSI模型中的应用层，它可在不同的汽车总线例如CAN, LIN, Fle*ray, Internet 和K-line上实现。UDS协议的应用层定义是ISO 14229-1，目前大局部汽车厂商均采用UDS on CAN的诊断协议。如下列图所示，ISO 14229-1也就是UDS协议仅对应用层做出了定义，物理层有双绞线和光纤供用户选择，数据链路层采用CAN总线的ISO 11898-1协议，针对Classical CAN仅有8个字节的数据场与应用层可处理多帧数据的矛盾，ISO 15765-2对网络层进展了定义。CAN的8字节数据场会

7、腾出一帧来表示网络层的信息。下列图右侧是排放相关的协议，ISO 15031-5主要针对OBD协议，为法规强制要求车厂满足的协议。学习时，我们应在了解CAN总线根本知识的前提下，着重学习ISO 15765-2和ISO 11898-1的协议容，并通过BootLoader作为例子，对UDS有一个大致的了解。UDS 的7种效劳及肯定响应和否认响应的形式UDS本质上是一系列的效劳，共包含6大类26种。每种效劳都有自己独立的ID，即SID。SID： (Service ID Identifier以下简称SID)Service，诊断效劳ID。UDS本质上是一种定向的通信，是一种交互协议Request/Resp

8、onse，即诊断方给ECU发送指定的请求数据Request，这条数据中需要包含SID。如果是肯定的响应Positive Response，回复SID+0*40，就是请求10，响应50；请求22，响应62，回复的是一组数据。如果是否认的响应Negative Response，回复7F+SID+NRC，回复的是一个声明。肯定响应和否认响应的形式一定要熟记。UDS的26种效劳中，有7种很重要。它们分别是：$10Diagnostic Session Control诊断会话，$14 Clear Diagnostic Information去除诊断信息，$19Read DTC Information，$2

9、2Read Data By Identifier通过ID读数据，$27Security Access平安访问，$2E Write Data By Identifier通过ID写数据，$3ETester Present待机握手。下面对这7个效劳进展解读。$10诊断会话Diagnostic Session Control (0*10)DiagnosticSessionControl诊断request的格式Diagnostic Session Control这个效劳的SID是0*10，request固定为2个byte，第一个byte是SID，第二个byte的低7bit是sub-function，用于

10、指示ECU将进入的session。UDS定义的session包括：0*00 ISOSAE Reserved保存0*01 default Session0*02 Programming Session0*03 e*tended Diagnostic Session0*04 safety System Diagnostic Session0*05 0*3F ISOSAE Reserved保存0*40 0*5F vehicle Manufacturer Specific由整车厂自定义使用0*60 0*7E system Supplier Specific由ECU供给商自定义使用0*7F ISOSAE

11、 Reserved保存Diagnostic Session Control用于控制ECU在不同的session之间进展转换，session可以看作是ECU所处的一种软件状态，在不同的session中诊断效劳执行的权限不同。 ECU上电之后，默认处在default Session中，在这个session中很多诊断效劳不可以执行，很多诊断相关的数据不能读取或写入。一般的诊断仪启动之后，会给ECU发送10 03，即让ECU进入 e*tended Diagnostic Session中，在这个session中可执行的诊断效劳就很多了。而如果要让ECU保持在non-default Session中，则需

12、要诊断仪每隔固定的时间发送0*3E效劳，ECU才会知道诊断仪有和自己通信的需求，从而保持在non-default Session中。另一个常用的session是Programming Session，在这个session中可以进展软件刷写的一系列诊断效劳。0*40 0*5F 这个围中的session由整车厂自定义使用，比方，*些诊断效劳或诊断数据的操作需要在生产线上执行，即所谓的End-Of-Line，整车厂可以从这个围中选择一个值来表示EOL session；又或者在开发阶段需要*种“超级session，则也可以从这里选一个值用来使ECU进入开发模式的session。Diagnostic S

13、ession Control这个效劳非常简单，但是它却是ECU和诊断通信的第一条诊断命令。$10包含3个子功能，01 Default，02 Programming，03 E*tended，ECU上电时，进入的是默认会话Default。如果您进入了一个非默认会话的状态，一个定时器会运转，如果一段时间没有请求，则到时间后，诊断退回到默认会话01。当然，我们有一个$3E的效劳，可以使诊断保持在非默认的状态。UDS包含4种类型，即SID，SID+SFSub-function，SID+DIDData Identifier读写用，SID+SF+DID。NRC：Negative Response Code否

14、认响应码。如果ECU拒绝了一个请求，它会回应一个NRC。不同的NRC有不同的含义。14229-1协议第329页单词：Consult查阅 Session会话 DTC diagnostic trouble code故障码Handling处理 Conditions条件 restricted受限的 Concept概念SAsource address 源地址 TA目标地址例子：以CAN总线网络举例。八个帧数据字节，第一字节被网络层占用。请求Request:02 10 02 * * * * * ; 02中的0代表网络层单帧SF，2代表 数据域有2个字节；SF，数据域有2个字节，10是SID，02是子功能。

15、肯定响应:02 50 02 * * * * *；02同上，10+40表示对SID的肯定回复，02是子功能。否认响应:03 7F 10 22 * * * *；03同上，7F表示否认响应，10是SID，22是NRC。$3E待机握手Tester Present (0*3E)这个诊断效劳的用处可以通过它的名字很明显地得知，即告知ECU诊断仪还在连接着。在上一篇文章中我说到了关于session的局部，如果没有诊断命令的发送和接收，ECU将从non-default session中回退到default session， 0*3E就是用于使ECU保持在当前session。这应该是UDS中最简单的一个诊断效劳

16、了，它永远只有两个byte，格式如下：0*3E诊断效劳的格式当sub-function是0*00时，ECU要给出response；当sub-function是0*80时，ECU不需要要给出response。一般来说主机厂会为这个效劳定义两个时间参数，一个参数用于规定自己的诊断仪发送0*3E效劳的间隔，另一个参数用于定义ECU收不到0*3E效劳的timeout时间。$3E效劳用于向效劳器指示诊断仪仍然连接在网络上，之前已经激活的诊断效劳功能可以仍然保持激活状态。0*3E就是用于使ECU保持在当前session。这应该是UDS中最简单的一个诊断效劳了，它永远只有两个byte，格式如下：例子：023

17、E80 00 00 00 00 00，发送一个3E效劳的报文，保持非默认会话状态。80表示无需回复。$27平安访问Security Access (0*27)厂家可能会为ECU定义*些平安级别稍微高一些的诊断效劳，在执行此类效劳之前，就需要执行Security Access 这个诊断命令，进展一个简单的身份验证。完成Security Access 有以下步骤：诊断仪向ECU请求“Seed通常是一个与时间相关的伪随机数,ECU向诊断仪发送“Seed诊断仪向ECU发送“Key (根据请求得到的Seed和一个本地的密码进展计算得来)ECU判断诊断仪发来的“Key是否有效根据UDS的定义，0*03,

18、0*05, 0*07 0*41 这个围留给用于request Seed的sub-function；0*04, 0*06, 0*08 0*42这个围留给用于send Key的sub-function。具体选择哪对值，由整车厂自己定义。整车厂也可以选择多对sub-function，用于不同等级的平安访问。下面我举一个完成Security Access的诊断命令的例子，假设0*05用于request Seed，0*06用于send Key。诊断仪发送 27 05ECU响应 67 05 01 01 01seed是 01 01 01诊断仪发送 27 06 02 03 04key值是02 03 04，se

19、ed是 01 01 01，假设本地密码为01 02 03，而算法就是将密码与seed相加ECU验证成功 67 06此时ECU就处于unlocked的状态了，那些被保护起来的诊断效劳和诊断数据可以被操作了。通常来说，如果ECU重启，或者回到了default session，unlocked状态就失效了，如果要执行相关诊断效劳，则需要再次执行上面描述的过程。$27平安访问：ECU当中有很多数据是整车厂独有的，并不希望开放给所有客户，它需要做一个的设定。我们在读取一些特殊数据的时候，要先进展一个平安解锁。ECU上电之后是一个锁定的状态Locked，我们通过$27效劳，加上一个子效劳，再加上一个钥匙，

20、这样的效劳请求可以进展解锁。比方下面的例子，2n-1是一个子效劳，通过首轮种子的请求，首轮ECU会返回67+01+AA+BB+CC+DD，AADD就是种子了。之后第二轮，诊断端会利用种子进展运算利用整车厂的算法，生成k1不一定是1个字节，则发送请求，27+02+k1。ECU同样也会通过种子算出k2。当k1和k2匹配时，解锁Unlocked成功。$27平安访问效劳的否认响应效劳ID也是7F。还记得刚刚否认响应的格式吗？7F+27+NRCR*： 0227 0500 00 00 00 00 平安访问，05子功能T*： 0767 0508 27 11 F0 77 肯定响应，回复了对应平安级别的种子R*

21、： 0627 06FF FF FF FF 00 发送密钥，4个FF。注意06是与05成对使用的。T*： 037F 27 7800 00 00 00 否认响应，7F+27+NRCT*： 0267 0600 00 00 00 00 肯定响应，通过平安校验$22读数据$22读数据，Request请求：22+DIDData Identifier，通常是两个字节Response响应：62+DID+DataDID有一局部已经被ISO 14229-1规定了。比方0*F186就是当前诊断会话数据标识符，0*F187就是车厂备件号数据标识符，0*F188就是车厂ECU软件数据ID，0*F189就是车厂ECU软件

22、版本号数据标识符。$2E写数据$22写数据，Request请求：2E+DID+DataResponse响应：6E+DID注意，比方0*F186这个DID不支持直接写入数据，需要用$10来进展会话转换。也就是说，对于写数据的请求，一般来说需要在一个非默认会话，和解锁的状态下才能进展。$19 读DTCDTCdiagnostic trouble code：如果系统检测到了一个错误，它将存储为DTC。DTC可表现为：一个显而易见的故障；通讯信号的丧失不会使故障灯亮起；排放相关的故障；平安相关的错误等。DTC可以提醒错误的位置和错误类型。通常DTC占用3个字节，OBD II占用两个字节。图中FTB为Fa

23、ult Type Byte。故障码包括四个大类，分别是PCBU，P是powertrain动力系统，C是Chassis底盘，B是Body车身，U是network通信系统。一个DTC信息占用4个字节。最后一个字节是DTC的状态。前两个字节是我们熟知的类似P0047的故障码。LowByte暂不清楚。$19拥有28个子效劳Sub-Function。常用的子效劳有02通过DTC状态掩码读取DTC，04读取快照信息，06读取扩展信息，0A读ECU支持的所有DTC数据。刚刚提到，一个DTC除了它自己的3个字节，还有一个字节专门用于表达DTC的状态。这个状态字节每个位的含义可以查询ISO 14229-1。注意

24、，并不是所有的DTC状态都是支持的。下列图是Request/Response。括号标识循环，可以读出很多DTC。$14去除DTC去除复位DTC格式，它可以改变DTC的状态。3个FF代表去除所有DTC。Request：14+FF+FF+FF；Response：54 。我们刚刚学完了7种重要的效劳，SID。除此之外，在CAN总线中，Addressing information寻址信息通过CAN帧ID表达出来。通讯的模式分两种，一种是物理寻址点对点，根据物理地址的不同进展访问，但只能访问单个ECU节点，Test为SA源地址，ECU*作为TA目标地址；对应的，另一种是功能寻址播送，根据功能的不同进展访

25、问，它能访问多个ECU节点。每一个ECU都有2个CAN帧ID，分别对应收和发的物理寻址。以上只是一些粗浅的理解。对26种效劳更详细的解读请拉到屏幕下方参考教师的8篇文章。教师也开通了微信公众号，可以了解一下。UDS应用的设备：在UDS 诊断产品中知名度最高，应用最广泛的是德国Vector公司的CAN case 配合其CANoe软件，Vector 产品功能齐全，适合系统级汽车总线开发，被大局部汽车厂商采用。Vector 产品因不开放API，不能做二次开发且价格昂贵，不适用于硬件开发团队和生产线的自动化测试。目前市面上有很多CAN 厂商如Kvaser, ZLG 等能提供低本钱、体积小、驱动简单、开

26、放API 的设备，很适合进展二次开发。杂记变速器控制单元TCU和防抱死系统ABS是CAN车载网络上的两大电子控制单元， 这2个ECU要通过CAN网络进展大量的信息交互。但是由于电磁干扰、串扰、静电等外界干扰或电控单元本身控制策略引起的通信停顿等原因， 2个控制单元之间可能会出现通信丧失的现象。控制系统需要将故障信息例如通信丧失故障信息 诊断出来， 以处理通信被破坏时出现丧失帧的故障现象， 并记录为DTC diagnostic trouble code。ECU的输入信号主要有4种形式： 模拟信号水温、油压、蓄电池电压等； 数字信号各种开关信号等； PWM信号脉冲信号、频率信号等； 网络信号CAN

27、、LIN上传输的信号。微控制器可以通过监测这些信号来判别输入电路的工作状况。输出的信号往往用作控制电磁阀、指示灯、步进电机等， 大多数为数字信号。统一诊断效劳 (Unified diagnostic services ， UDS) 一UDS由ISO-14229系列标准定义，ISO 14229-1 定义了诊断效劳，不涉及网络及实现，只有应用层的容。而ISO 14229-3则定义了UDS在CAN总线上的实现。诊断通信的过程从用户角度来看非常容易理解，诊断仪发送诊断请求(request)，ECU给出诊断响应response，而UDS就是为不同的诊断功能的request和response定义了统一的容

28、和格式。Diagnostic request的格式：Diagnostic request的格式可以分为两类：一类是拥有sub-function的，一类是没有sub-function的，如下面两图所示。Service ID(以下简称SID)的长度固定为1个字节，代表了这条诊断命令执行的什么功能。Sub-function的长度也是1个字节，它通常表示对这个诊断效劳的具体操作，比方是启动、停顿还是查询这个诊断效劳。Parameter则根据各个诊断效劳的不同具有不同的容，长度和格式并没有统一规格，它用于限定诊断效劳执行的条件，比方*个诊断效劳执行的时间等。parameter的一个重要应用是作为标识符，

29、标识诊断请求要读出的数据容。有一点要补充的是，其实sub-function严格来说是7个bit，而不是1个byte，因为它的最高位bit被用于抑制正响应suppress positive response,SPR，如果这个bit被置1，则ECU不会给出正响应positive response； 如果这个bit被置0，则ECU会给出正响应。这样做的目的是可以告诉ECU不要发不必要的response，从而节约通信资源。Diagnostic response的格式：Diagnostic response分为positive和negative两类。positive response意味着诊断仪发过来的

30、诊断请求被执行了negative response则意味着ECU因为*种原因无法执行诊断仪发过来的诊断请求，而无法执行的原因则存在于negative response的报文中。positive responsepositive response的格式如上图所示，也根本上是由三局部组成，其中的response SID这个字节作为诊断请求的echo，它等于SID + 0*40。后面的两个局部则视具体的诊断效劳而定。negative responsenegative response的格式固定为3个字节，第一个字节为0*7F，第二个字节是被拒绝掉的SID，第三个字节是这个诊断效劳无法被执行的原因。下

31、面这图列举了局部原因代码，比方，如果ECU给出7F 22 13这个negative response，则说明22这个效劳因为诊断请求数据长度不对的原因无法执行。总结：诊断通信的过程就是诊断仪和ECU交换数据，前者发的是request，后者发的是response，而UDS最重要的作用就是定义了这些request和response的格式和容。统一诊断效劳 (Unified diagnostic services ， UDS) 二UDS定义的诊断效劳从逻辑来说分为以下几类：Diagnostic and Communication Management 诊断和通信管理Data Transmission

32、 数据传输Stored Data Transmission 存储数据传输，用于操作DTCInput Output Control IO控制Routine Control 不知如何翻译好，作用是调用ECU部的预置函数Upload Download 上传下载UDS规定使用1个byte来表示诊断效劳，即所谓的Service ID,简称SID。本文介绍一下Diagnostic and Communication Management 这一类诊断效劳中的一局部。Diagnostic Session Control (0*10)DiagnosticSessionControl诊断request的格式Dia

33、gnostic Session Control这个效劳的SID是0*10，request固定为2个byte，第一个byte是SID，第二个byte的低7bit是sub-function，用于指示ECU将进入的session。UDS定义的session包括：0*00 ISOSAE Reserved保存0*01 default Session0*02 Programming Session0*03 e*tended Diagnostic Session0*04 safety System Diagnostic Session0*05 0*3F ISOSAE Reserved保存0*40 0*5F

34、vehicle Manufacturer Specific由整车厂自定义使用0*60 0*7E system Supplier Specific由ECU供给商自定义使用0*7F ISOSAE Reserved保存Diagnostic Session Control用于控制ECU在不同的session之间进展转换，session可以看作是ECU所处的一种软件状态，在不同的session中诊断效劳执行的权限不同。 ECU上电之后，默认处在default Session中，在这个session中很多诊断效劳不可以执行，很多诊断相关的数据不能读取或写入。一般的诊断仪启动之后，会给ECU发送10 03，

35、即让ECU进入 e*tended Diagnostic Session中，在这个session中可执行的诊断效劳就很多了。而如果要让ECU保持在non-default Session中，则需要诊断仪每隔固定的时间发送0*3E效劳，ECU才会知道诊断仪有和自己通信的需求，从而保持在non-default Session中。另一个常用的session是Programming Session，在这个session中可以进展软件刷写的一系列诊断效劳。0*40 0*5F 这个围中的session由整车厂自定义使用，比方，*些诊断效劳或诊断数据的操作需要在生产线上执行，即所谓的End-Of-Line，整车

36、厂可以从这个围中选择一个值来表示EOL session；又或者在开发阶段需要*种“超级session，则也可以从这里选一个值用来使ECU进入开发模式的session。Diagnostic Session Control这个效劳非常简单，但是它却是ECU和诊断通信的第一条诊断命令。诊断response的格式：DiagnosticSessionControl这个诊断效劳的response分为三局部，第一局部是0*50，作为SID的echo；第二局部是进入的session，作为sub-function的echo；第三局部是4个字节，前两个字节代表P2 Server_ma*，即ECU在应用层上对诊断命

37、令的响应时间，后两个字节代表P2*Server_ma*，即ECU在暂时无法处理当前诊断命令具体表现为发送了NRC 0*78，在应用层上对诊断命令响应的最长时间。ECUReset 诊断request的格式ECU Reset (0*11) ECU Reset 这条指令的用途是通过诊断请求使ECU重启。ECU Reset 这个效劳的SID是0*11，request固定为2个byte，第一个byte是SID，第二个byte的低7bit是sub-function，用于指示ECU将模拟哪种方式进展重启。常用的sub-function包括只举2个例子，UDS还定义了很多其他的值0*01hard Reset

38、模拟KL30的重启0*02key Off On Reset 模拟KL15的重启当我们通过诊断命令改写了ECU的*些数据，或者对ECU进展了*些设置，只有将ECU重启才能将这些配置生效，所以就有了这个诊断命令。在ECU Reset 执行之后，ECU会从Non-default session回退到default session中。Security Access (0*27)厂家可能会为ECU定义*些平安级别稍微高一些的诊断效劳，在执行此类效劳之前，就需要执行Security Access 这个诊断命令，进展一个简单的身份验证。完成Security Access 有以下步骤：诊断仪向ECU请求“Se

39、ed通常是一个与时间相关的伪随机数,ECU向诊断仪发送“Seed诊断仪向ECU发送“Key (根据请求得到的Seed和一个本地的密码进展计算得来)ECU判断诊断仪发来的“Key是否有效根据UDS的定义，0*03, 0*05, 0*07 0*41 这个围留给用于request Seed的sub-function；0*04, 0*06, 0*08 0*42这个围留给用于send Key的sub-function。具体选择哪对值，由整车厂自己定义。整车厂也可以选择多对sub-function，用于不同等级的平安访问。下面我举一个完成Security Access的诊断命令的例子，假设0*05用于re

40、quest Seed，0*06用于send Key。诊断仪发送 27 05ECU响应 67 05 01 01 01seed是 01 01 01诊断仪发送 27 06 02 03 04key值是02 03 04，seed是 01 01 01，假设本地密码为01 02 03，而算法就是将密码与seed相加ECU验证成功 67 06此时ECU就处于unlocked的状态了，那些被保护起来的诊断效劳和诊断数据可以被操作了。通常来说，如果ECU重启，或者回到了default session，unlocked状态就失效了，如果要执行相关诊断效劳，则需要再次执行上面描述的过程。统一诊断效劳 (Unified

41、 diagnostic services ， UDS) 三在上一篇文章中我写了Diagnostic and Communication Management 诊断和通信管理这一类诊断效劳中的0*10 , 0*11 , 0*27，在这篇文章中继续这一大类诊断效劳中的其他容。Communication Control (0*28)该效劳用于翻开/关闭*些类别的报文的发送/接收。它通常在刷写软件或大量数据的时候使用，因为在刷软件或参数的时候并不需要ECU进展与通信相关的功能，将通信关闭之后可以把所有通信资源都留给软件或参数的下载，当下载过程完成之后再利用该效劳将通信恢复即可。0*28效劳的格式如下列

42、图所示0*28效劳的格式第一局部即SID，一个byte，值为0*28；第二局部是sub-function，说明要对ECU的通信进展哪种控制，具体包括 ：0*00 enable R* And T* 激活接收和发送0*01 enable R* And Disable T*激活接收和关闭发送0*02 disable R* And Enable T*激活发送和关闭接收0*03 disable R* And T*关闭接收和发送0*04 enable R* And Disable T* With Enhanced Address Information激活接收和关闭发送，针对特定的地址0*05 enabl

43、e R* And T* With Enhanced Address Information激活接收和发送，针对特定的地址0*06 - 0*7F都是保存或者留给厂商自定义的。第三局部communicationType的定义说明这条诊断请求要对哪种报文进展控制，长度为1个byte，这个byte中最常用的就是低2 bit，0*1代表普通应用报文，0*2代表网络管理报文，0*3代表普通应用报文和网络管理报文。第四局部 是optional的，只有当sub-functional等于0*04或0*05时才需要使用。定义如下表所示：举个完整的诊断效劳例子：28 01 01 表示激活应用报文的接收并关闭应用报文

44、的发送网络管理报文不受影响。28 00 01 表示激活应用报文的接收和发送网络管理报文不受影响。Tester Present (0*3E)这个诊断效劳的用处可以通过它的名字很明显地得知，即告知ECU诊断仪还在连接着。在上一篇文章中我说到了关于session的局部，如果没有诊断命令的发送和接收，ECU将从non-default session中回退到default session， 0*3E就是用于使ECU保持在当前session。这应该是UDS中最简单的一个诊断效劳了，它永远只有两个byte，格式如下：0*3E诊断效劳的格式当sub-function是0*00时，ECU要给出response；

45、当sub-function是0*80时，ECU不需要要给出response。一般来说主机厂会为这个效劳定义两个时间参数，一个参数用于规定自己的诊断仪发送0*3E效劳的间隔，另一个参数用于定义ECU收不到0*3E效劳的timeout时间。Control DTC Setting (0*85)该效劳用于控制ECU的DTC存储，这个效劳常常和前面提到的O* 28效劳一起使用，比方，在开场写参数之前，为了获得更快的传输速度，我们用O* 28效劳把所有ECU的通信关闭了，但此时因为收到不到相关的报文，ECU会没有必要地存储很多DTC，这时如果我们使用85效劳把ECU存储DTC的功能暂时性地制止掉，则不会造

46、成这种麻烦。0*85效劳的格式第一局部即SID，一个byte，值为0*85；第二局部是sub-function，说明是翻开还是关闭ECU的DTC存储，具体包括 ：0*01 on0*02 off第三局部是optional的，由各家自己定义，比方，可以用FF FF FF 来表示这条诊断命令针对所有的DTC。Response On Event (0*86)我在以前的文章里说，诊断通信过程是问答式的，诊断仪发请求，ECU给响应。0*86效劳算是一个例外，在ECU收到这条0*86效劳之后，当DTC产生时，它会自动地上报DTC及相关环境数据，直到用另一条0*86效劳来关闭ECU的这个行为。该功能主要用于E

47、CU的前期开发阶段，在售后和生产中是不会用到的，而且该效劳的格式复杂即可变的参数很多，执行它还分为好几个步骤，我就不详细写了。Link Control (0*87)这个效劳用于转化ECU数据链路层和物理层的状态，比方，在高速CAN上的ECU正常通信速率是500 kbit/s，但它同时也支持1M bit/s的波特率，如果需要刷写大量数据，便可以利用这条诊断效劳让ECU以1M bit/s的波特率进展通信。这个诊断效劳的执行分为两个步骤：1验证ECU是否支持要调整到的目标波特率2让ECU的数据链路层和物理层转到目标波特率的通信状态。只有当第一个步骤验证通过了，第二个步骤才可以成功执行。统一诊断效劳 (Unified diagnostic services ， UDS) 四这篇文章介绍一下UDS的第二类诊断效劳，即Data Transmi