Leendless

Menu

leendless
Published on 2025-03-20 / 107 Visits
2
0

诊断协议

#CAN

2 ISO 14229协议--UDS

2.1 UDS 常见报文

常见的UDS报文

常见的20个NRC
  • NRC 意为Negative Response code，即否定相应码,
  • SID 意为Service ID，即服务类ID，
  • DID 意为Data ID，即数据类ID，一般都是与产品系统相关的信息和一些配置信息，
  • RID 意为RoutineControl ID，即例程控制的ID，一般都是些与标定、烧录相关的耗时耗资源操作,
  • DTC 意为Diagnostic Trouble Code，即诊断故障代码。


    以上常用uds举例

故障码相关

RX：02(有效byte位) 19（服务id） 0a（子功能） 55 55 55 55 55
TX：07(有效byte位) 59（肯定应答） 0a（子功能） 09DTC状态掩码) c1 23 45（DTC）08(DTC状
态)

数据相关（写入vin码,此种操作需要开启权限，后面sid介绍有详细说明 ）

RX：10（首帧） 14（有效byte位） 2e（服务id） f1 90（vin码有关的DID） 01 02 03
RX：21（连续帧） 04 05 06 07 08 09 0a
RX：22（连续帧） 0b 0c 0d 0e 0f 10 11(17位vin码)
RX：03(有效byte位) 6e（肯定应答） f1 90（vin相关did） aa aa aa aa

2.2 UDS的26种服务

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

UDS的26种服务

通常，在CAN总线中，Addressing information寻址信息会在CAN的帧ID中体现出来，例外是远程寻址，但不常使用。所谓的寻址信息包含了源地址(Source Address)和目标地址(Target Address)，就是这条信息是由谁发给谁的，类似于收件人和发件人。当然，ECU回信给Tester时，ECU就变成源地址了。因此源地址和目标地址在UDS中并不是一成不变的。

肯定响应和否定响应的形式一定要熟记！如果是肯定的响应（Positive Response），回复 [SID+0x40]（这点要熟记） ，如请求0x10，响应0x50；请求0x22，响应0x62。如果是否定的响应（Negative Response），常用的否定响应回复7F+SID+NRC，回复的是一个声明。

UDS的寻址模式分两种，一种是物理寻址（点对点、一对一），根据物理地址的不同进行访问，但只能访问单个ECU节点，Tester为SA源地址，ECU作为TA目标地址；对应的，另一种是功能寻址（广播、一对多），根据功能的不同进行访问，它能访问多个ECU节点，对于标准帧来说，通常是0x7DF。

每一个ECU都有2个CAN的诊断帧ID，分别对应物理寻址的收与发。通常由主机厂来确定不同ECU的这两个特定的诊断ID。比如0x7E0对应接收Tester的消息，0x7E8对应发给Tester的消息。

2.3 0x10诊断会话（Diagnostic Session Control）

具体介绍见 ISO14229-1_2013_03-en的第36页DiagnosticSessionControl (0x10) service

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

为什么设计三个会话模式呢？因为权限问题。默认会话权限最小，可操作的服务少；03扩展模式通常用于解锁高权限诊断服务，例如写入数据/参数、读写诊断码；02编程模式用于解锁 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的图，当然完整版请参照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）时，不需要回复否定响应。
例如：

TX		2	11	83	00	00	00	00	00
RX		3	7F	11	78	AA	AA	AA	AA    //NRC 0x78坏了规矩
RX		2	51	03	AA	AA	AA	AA	AA

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

02 10 01 00 00 00 00 00
06 50 01 00 32 00 C8 AA     //进入01会话成功
02 10 02 00 00 00 00 00
03 7F 10 7E AA AA AA AA    //进入02会话失败
02 10 03 55 55 55 55 55
06 50 03 00 32 00 C8 AA     //进入03会话成功

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

下面的图表是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（否定响应码）。

2.4 0x3E待机握手（TesterPresent）

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

0x7E0	02 3e 00 cc cc cc cc cc	   //待机握手
0x7E8	02 7e 00 aa aa aa aa aa	   //肯定响应

2.5 0x27安全访问 （SecurityAccess）

具体介绍见 ISO14229-1_2013_03-en的第47页9.4 SecurityAccess (0x27) service

$27安全访问：ECU当中有很多数据是整车厂独有的，并不希望开放给所有客户，它需要做一个保密的设定。我们在读取一些特殊数据的时候，要先进行一个安全解锁。ECU上电之后是一个锁定的状态（Locked），我们通过$27服务，加上一个子服务，再加上一个钥匙，这样的服务请求可以进行解锁。

2.5.1 实例

（1）服务器处于“锁定”状态





实际报文

0x7E0	02 27 01 cc cc cc cc cc	//请求种子
0x7E8	10 0a 67 01 c1 78 c6 ff	//肯定响应
0x7E0	30 00 02 ff ff ff ff ff 	        //流控帧
0x7E8	21 48 8d 0c 1f aa aa aa	
0x7E0	10 0a 27 02 07 67 e5 3c	 //发送秘钥
0x7E8	30 00 00 aa aa aa aa aa	 //流控帧
0x7E0	21 ca 66 c8 ee ff ff ff	     //发送秘钥
0x7E8	02 67 02 aa aa aa aa aa	 //肯定响应

（2）服务器处于“解锁”状态



2.6 0x22读数据（ReadDataByIdentifier）

详见《ISO14229-1_2013_03-en》第106页10.2 ReadDataByIdentifier (0x22) service，中英文版本同页

$22读数据
Request（请求）： 22+DID（Data Identifier，通常是两个字节）
Response（响应）： 62+DID+Data

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

实际报文如下：

0x7e0	03 22 f1 8b cc cc cc cc
0x7e8	06 62 f1 8b 19 12 21 aa
0x7e0	03 22 f1 93 cc cc cc cc
0x7e8	06 62 f1 93 44 2e 31 aa
0x7e0	03 22 f1 95 cc cc cc cc
0x7e8	10 1b 62 f1 95 50 31 39
0x7e0	30 00 02 ff ff ff ff ff
0x7e8	21 36 31 5f 59 75 6e 6e

2.7 0x2E写数据（WriteDataByIdentifier）

$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 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的状态下才能进行。

实例报文

0x7E0	10 0b 2e f1 99 02 00 02	  //请求写入程序更新日期
0x7E8	30 00 00 aa aa aa aa aa	   //流控帧
0x7E0	21 03 01 01 02 00 ff ff	
0x7E8	03 6e f1 99 aa aa aa aa	   //肯定响应
0x7E0	10 0d 2e f1 98 53 48 49	   //写入数据
0x7E8	30 00 00 aa aa aa aa aa	   //流控帧
0x7E0	21 44 41 49 4f 54 41 41	
0x7E8	03 6e f1 98 aa aa aa aa	   //肯定响应

2.8 0x19读DTC（ReadDTCInformation）

详见《ISO14229-1_2013_03-en》第178页11.3 ReadDTCInformation (0x19) Service，中英文版本同页

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。

$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的一个难点。


2.9 0x14清除DTC（ClearDiagnosticInformation）

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

3个FF代表清除所有DTC。

Request： 14+FF+FF+FF
Response：54


2.10 0x2F IO控制（InputOutputControlByIdentifier）

该服务可以通过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是关；也可以是模拟量，比如空调风门的开度。

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

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

2F服务有一个问题，如果通过2F服务修改了某个值，后续也不把控制权还给ECU，那么这个修改的有效时间是一直持续下去？正确的做法是如果扩展会话超时，即切回默认会话，此时控制权应还给ECU，毕竟 2F的03子功能是"暂时接管控制权"。


2.11 0x31 例程控制（RoutineControl）

详见《ISO14229-1_2013_03-en》第260页 RoutineControl (0x31) service，中英文版本同页

客户端使用RoutineControl服务来执行已定义的步骤序列并获取任何相关结果。 这项服务具有很大的灵活性，但典型的使用可能包括擦除内存，重置或学习自适应数据，运行自检，覆盖正常服务器控制策略以及控制服务器值随时间变化等功能，包括预定义的序列（例如，关闭敞篷车顶）等等。通常，当用于控制输出时，该服务用于更复杂的类型控制，而inputOutputControlByIdentifier用于相对简单的（例如静态）输出控制。

请求消息定义


肯定响应消息格式



实际报文

0x7e0	06 31 01 ff 00 01 00 cc	例程控制，擦除程序
0x7e8	03 7f 31 78 aa aa aa aa	已收到请求，但会晚些响应
0x7e8	05 71 01 ff 00 00 aa aa	肯定响应

2.12 0x11 ECU重置（ECUReset）

详见《ISO14229-1_2013_03-en》第43页 14.4 9.3 ECUReset (0x11) service，中英文版本同页

客户端使用ECUReset服务请求重置ECU。

该服务请求服务器根据ECUReset请求消息中嵌入的resetType参数值的内容有效地执行服务器重置。ECUReset肯定响应消息（如果需要）应在服务器中执行复位之前发送。 服务器重置成功后，服务器应激活defaultSession。



实际报文如下

0x7e0	02 11 01 cc cc cc cc cc	  //ECU复位请求
0x7e8	02 51 01 aa aa aa aa aa	  //肯定响应

2.13 0x36 数据传输（TransferData）

详见《ISO14229-1_2013_03-en》第280页 14.4 TransferData (0x36) service，中英文版本同页

TransferData服务用于客户端将数据从客户端传输到服务器（下载）或从服务器传输到客户端（上传）。数据传输方向由前面的RequestDownload或RequestUpload服务定义。 如果客户端发起请求下载，则要下载的数据包含在TransferData请求消息中的参数transferRequestParameter中。 如果客户端发起请求上传，则要上传的数据包含在TransferData响应消息中的参数transferResponseParameter中。

TransferData服务请求包含一个blockSequenceCounter，以便在多个TransferData请求序列期间传输数据服务失败的情况下，改进错误处理。 当接收到RequestDownload（0x34）或RequestUpload（0x35）请求消息时，服务器的blockSequenceCounter应初始化为1。 这意味着RequestDownload（0x34）或RequestUpload（0x35）请求消息后面的第一个TransferData（0x36）请求消息以blockSequenceCounter开头。

请求消息格式


肯定响应消息格式


实际报文如下

0x000007e0	10 0b 34 00 44 08 fd 80	   //请求下载
0x000007e8	30 00 00 aa aa aa aa aa	   //流控帧
0x000007e0	21 00 00 02 80 00 ff ff	
0x000007e8	04 74 20 0f ff aa aa aa	   //肯定响应
0x000007e0	12 02 36 01 de ad be ef	   //下载数据
0x000007e8	30 00 00 aa aa aa aa aa	   //流控帧
0x000007e0	21 00 00 00 00 00 00 00	
0x000007e0	22 00 00 00 00 00 00 00	
0x000007e0	23 00 00 00 00 00 00 00	
0x000007e0	24 00 00 00 00 00 00 00	
--------------------数据传输------------------
0x000007e8	02 76 01 aa aa aa aa aa	    //肯定响应
0x000007e0	12 02 36 02 00 00 00 06	    //blockSequenceCounter 加1
0x000007e8	30 00 00 aa aa aa aa aa	
0x000007e0	21 00 00 00 31 08 fd 83	
--------------------数据传输------------------
0x000007e0	28 34 56 78 ba cc 91 10	
0x000007e0	29 00 00 00 00 ff ff ff	
0x000007e8	02 76 00 aa aa aa aa aa	    //肯定响应

2.14 UDS 刷写

2.14.1 刷写流程中用到的诊断服务

10 01：诊断刷写完成后让目标ECU重置或让整车网络中其他ECU切换回默认会话

10 02：设置外部编程请求标志位或切换到编程会话（诊断刷写需要在编程会话下进行）

10 03：让目标ECU切换到扩展会话，以便进行其他诊断服务（2E、28、85、31等）

10 83：功能寻址，让整车网络中所有ECU进入扩展会话并抑制肯定响应，以便进行其他诊断服务（28、85）

11 01：Ecu Hard Reset，等同于掉电然后重启，主要用于需要彻底复位的场景，如刷写之后的复位

3E 80：功能寻址，通过周期性地发送该请求让整车网络中所有ECU保持当前诊断会话，并抑制肯定响应

27 xx/xx+1：由于重编程对于控制器来说属于破坏性行为，ECU理应得到保护：需要进行安全认证来解锁

28 83 03：功能寻址，禁止整车网络中所有ECU发送和接收网络管理报文和应用报文，并抑制肯定响应

28 80 03：功能寻址，允许整车网络中所有ECU发送和接收网络管理报文和应用报文，并抑制肯定响应

22 xxxx：获取目标ECU的相关信息，或者获取控制器当前运行的分区信息，或者读取软件安装进度

2E xxxx yy：写入指纹信息到控制器中

85 82：功能寻址，刷写前禁用整车网络中所有ECU的DTC故障码存储功能，并抑制肯定响应

85 81：功能寻址，刷写完成后开启整车网络中所有ECU的DTC故障码存储功能，并抑制肯定响应

14 FFFFFF：清除目标ECU的所有故障信息，此操作在刷写完成后进行

31 01 xxxx：刷写前检查编程条件，或者文件下载后检查编程依赖关系，或者智能件中用来启动软件安装流程，或者文件下载前擦除擦除内存，或者检查文件签名是否正确

34：请求下载数据到ECU，ECU会通过74响应告诉诊断仪每次传输的最大的数据块的字节数

36：Tester向ECU传输数据，这个数据不能大于34服务中ECU要求的最大数据块

37：退出当前软件段编程

2.12.2 重编程时序

2.12.2.1 预编程

预编程步骤用来为要下载的 ECU 做编程前的 CAN 网络准备。此步骤也包含了提高
下载能力的准备。此步骤的请求报文能采用是物理寻址，或功能寻址。


  1. 诊断会话控制 10 83：为了禁止 ECU 间的正常通信和 DTC 设置，预编程需要启动非默认会话模式。通过使用会话类型为扩展会话模式的诊断会话控制(10)服务来完成，通过功能寻址发送给所有的 ECU。

  2. 例程控制“检查编程预条件”31 01 F002：通过此例程来检查 ECU 编程条件，从而确保系统安全，预编程条件由 ECU 决定，如果有任何不安全的因素，ECU 应该拒绝编程，此例程控制不需要安全访问。注意：如果 ECU 在未收到“检查编程预条件”例程(31 01 F002)的情况下，收到“10 02”请求，ECU 应该拒绝进入 Bootloader 模式，并且发送否定响应 NRC22。

  3. 控制 DTC 设置 85 82：诊断仪通过 DTC 设置类型设为“关闭”的控制 DTC设置服务请求，通过功能寻址发送给所有的 ECU。

  4. 通信控制 28 83 ：诊断仪通过通信控制(28)服务请求，禁止非诊断报文的发送和接收。请求中的控制类型参数置为“disable the transmission and the reception”，通信类型置为 01“application messages”，通过功能寻址发送给所有的 ECU。

2.12.2.2 主编程

在预编程步骤之后，即为 ECU 主编程步骤。主编程时序是单个 ECU 编程事件的应
用，因此所有服务的请求使用物理寻址。

下图描述了在主编程步骤中执行的各个功能。


下载Flash驱动的流程如下：


下载应用程序的流程如下：


  1. 诊断会话控制 10 02：在收到一个会话类型为物理寻址的编程会话的诊断会话控制(10)服务后，ECU 开始编程事件。ECU 收到此请求后，将分配编程需要的所有必须的资源。安全访问 27 03/04：编程事件必须通过安全访问。

  2. 安全访问(27)：服务在排放相关和安全系统中是强制的。其它系统不要求使用该服务。下载前，通过安全访问过程是强制的，确保只有合法的诊断仪能对 ECU 进行下载操作。

  3. 写入数据 2E F184：在擦除内存例程之前，将“指纹”写到 ECU 内存中是强制的。“指纹”标识了是哪个诊断仪对 ECU 内存做了修改。在追踪指纹信息时，诊断仪将发送报文“22 F184”，ECU 将通过“62 F184…”，返回指纹信息。具体格式，请参看章节 3.4.2。

  4. 驱动下载 34、36、37：当 ECU 的非易失性存储单元中没有存储内存擦除例程时，将执行内存擦除例程的下载。下载应该按照如下时序来进行：请求下载、传输数据、请求传输退出。

  5. 例程控制--“擦除内存”31 01 FF00：为了允许应用软件和数据下载，ECU的内存将被擦除。此步骤通过例程来完成，使用例程控制(31)服务，来执行擦除内存。如果擦除内存例程被调用，那么应用程序有效标志位将被置为无效。

  6. 下载过程 34、36、37：应用软件或者数据的每一个连续的数据块（可能是一个完整的应用软件或者数据，也可能是应用软件或者数据的一部分）下载到 ECU 非易失性内存中，都是遵循下面的服务顺序完成数传输：

    • 请求下载(34)；
    • 传输数据(36)；
    • 请求传输退出(37)。

  7. 例程控制--“检查编程完整性”31 01 F001：此例程用来检查逻辑块的下载是否成功，例程的功能是检查下载的完整性。

  8. 例程控制--“检查编程依赖性”31 01 FF01：一旦完成所有的应用软件或数据块/模块的下载，诊断仪将开始一个例程来验证执行成功的下载。此例程触发 ECU 检查重编程的依赖性。ECU 供应商来定义检查内容，但必须确保所有逻辑块的兼容性和一致性。

  9. 电控单元复位 11 01：诊断仪使用物理寻址，发送一个复位类型为硬复位的 ECU复位(11)服务请求报文到 CAN 网络上。通过 ECU 复位服务请求将使 ECU 结束编程过程，返回到正常的操作模式。内存驱动代码必须从 RAM 缓存中完全清除，避免意外激活这些可能会进行非预期的内存擦除或程序操作的代码。

2.12.2.3 后编程


  1. 诊断会话控制 10 83：诊断仪发送一个会话类型为扩展会话的诊断会话控制(10)服务请求报文到 CAN 网络上。所有的 ECU 接收到诊断会话控制(10)而进入到扩展会话模式。此请求通过功能寻址发送，请求发送给所有包含在编程事件中进入默认会话模式的 ECU。

  2. 通信控制 28 80 01：诊断仪发送一个通信控制类型为使能接收和发送应用报文(28)的服务请求报文到 CAN 网络上，所有 ECU 恢复应用报文的接收和发送。

  3. DTC 控制 85 81：诊断仪发送一个 DTC 控制类型为打开 DTC 记录(85)的服务请求报文到 CAN 网络上，所有 ECU 打开 DTC 记录功能。

  4. 诊断会话控制 10 01：诊断仪发送一个会话类型为默认会话的诊断会话控制(10)服务请求报文到 CAN 网络上。所有的 ECU 接收到诊断会话控制(10)，而进入到默认会话模式。

  5. 清除诊断信息 14 FFFFFF：如果重编程 ECU 在编程步骤被重启，当编程 ECU运行在默认会话模式时，网络上其它的 ECU 仍然在不能正常通信状态，此时，一些可能被存储在编程 ECU 中诊断信息就应该通过物理寻址的清除诊断信息(14)服务来清除。

3.故障码数据解析

诊断帧ID说明

UDS每个PDU包含控制信息PCI，数据信息Data。具体如下图：

数据举例：

  • 03 代表发送的数据中含有3个字节，回复为正反馈，为连续帧，
  • 10 代表连续帧的首帧，14代表此连续帧含有20个字节，
  • 30 代表此连续帧的流控制帧，
  • 21，22代表连续帧中的第几帧，21代表第一帧，22代表第二帧，依此类推，其中cc为填充位。(bit(7-4) -2-pcitype=2(连续帧）bit(3-0)--帧序号
  • 填充位需要和 ECU 厂提前确认

3.1 J1939诊断说明

3.1.1 J1939目录说明

  • 数据流解析请参考《saeJ1939-71》，直接全局搜索 PGN或者SPI，根据对应的CAN协议格式进行解析
  • 诊断协议请参考《saeJ1939-73》，直接全局搜索DMx故障码 和 FMI故障模式指示
  • 多包传输请参考《saeJ1939-21》，或者搜索私有文档说明《SAE J1939 多包传输.pdf》
  • 想详细了解，可以参考 https://blog.csdn.net/u012923807/article/details/95649142


广播公共消息（BAM） 0xEC00定义，参考 ：SAE J1939 多包传输 "表 5 TP．CM_BAM 参数描述”

TP.CM_BAM参数描述

广播公告（TP.CM_BAM）：全家目标地址
Byte 1 ： 控制字节 = 32
Byte 2,3 ： 整个报文的大小、字节数
Byte 5 ： SAE 保留，以 FF 填充
Byte 6-8 ：打包报文 PGN

数据传送消息（TP.DT）0xEB00定义，参考 SAE J1939 多包传输 “4.1 点对点会话”

TP.DT 参数组描述
更新速率由传送的 PGN 决定
数据长度 ：8字节

DP : 0
PF : 235
PS : DA，对于TP.CM_BAM，DA = 255
P : 7
PGN : 60160(00EB00)
Byte 1 ：包编号
Byte 2-8 : 打包的数据内容，如果如果最后一包不足8个字节，剩余字节以FF填充

/*这里采用杭叉G93实车数据进行分析，采用的 0xECFF和0xEBFF 进行传输*/

// 实车数据没有发送 DM5 故障信息

// 0x20：控制字节=32（固定）；0x000A有效BYTE数为10；0x02-有效数据包2个；0x00FECA-打包报文
为 DM1故障码报文的pgn，后面多包将发送DM1的报文。详细请参考SAE J1939 多包传输 "表 5 TP．
CM_BAM 参数描述"
0x18ecff00 20 0A 00 02 FF CA FE 00

// 提取 DM1 故障码数据 40 FF CE 0C 00 04 55 F1 E0 05，01表示包编号；40表示灯状态，bit7-
8为1（MIL点亮），其他灯参考J1939-73 "Active Diagnostic Trouble Codes (DM1)"的描述；故
障码为 CE 0C 00 04 和 55 F1 E0 05

0x18ebff00 01 40 FF CE 0C 00 04 55
0x18ebff00 02 F1 E0 05 FF FF FF FF

SPN(3278)+FMI(0)+CM(0)+OC(4)
SPN(61768)+FMI(0)+CM(0)+OC(5)// 解析完成之后，可以根据客户提供的 故障码清单 进行对比解析;

参考J1939-73--"5.6 Diagnostic Trouble Code Definition"。

3.1.3.5 数据请求说明

报文类型

“请求PGN”报文的定义：

  • 参数组名称： 请求PGN
  • 定义： 用于从一个或多个网络设备请求参数组
  • 传输速率： 用户自定义，推荐每秒请求不多于2或3次
  • 数据长度： 3字节
  • 数据页：0
  • PDU格式：234
  • PDU特定域：目标地址(全局或特定)
  • 缺省优先级： 6
  • 参数组编号： 59904（0x00EA00）
  • 参数定义:
    • 字节：1，2，3 被请求的参数组编号

对于特定目标地址的请求，目标地址必须做出响应。如果目标地址不支持请 求的PGN,也必须发出一个NACK的响应以表明它不支持该PGN。有些PGN是 多包的，因此一个单帧请求的响应可能有多个CAN数据帧。如果是全局请求， 当一个节点不支持某个PGN时，不能发出NACK响应。

// 单帧请求

如： 请求FEE9(燃油累积量)

1939请求 --- 0x18EA0021 E9 FE 00 FF FF FF FF FF // 注意前面三个BYTE为请求 PGN

1939控制器回复 0x18FEE900 FF FF FF FF 11 22 33 44 // 自己参考 J1939-71的PGN进行

数据解析

// 多帧请求-参考J1939-21

RX 0x18ec0000 10 0A 00 02 FF CA FE 00 // 请求发送

TX 0x18ec0000 11 02 01 FF FF CA FE 00 // 允许发送

RX 0x18ebff00 01 40 FF CE 0C 00 04 55 // 数据传输

RX 0x18ebff00 02 F1 E0 05 FF FF FF FF

3.2 ISO-27145故障诊断说明

3.2.1 27145目录说明

  • ISO27145-1: 这里边介绍的是一般信息和用例定义
  • ISO27145-2: 这里边介绍的是与排放相关的通用数据规则，用于查询
  • ISO27145-3: 这里边主要介绍了支持的服务 12服务 14服务 19服务 22服务 31服务
  • ISO27145-4: 车辆与测试设备的连接，主要定义一些 物理层，传输层，网络层的功能

留言邮箱地址可提供pdf文件

A 类业余电台操作证书考试内容提要

Comment