UDS诊断服务从编写诊断规范到最终实现使用诊断仪读取故障信息，中间需要做哪些工作？

笑看风云

公司在开发整车控制器，需要做UDS诊断，怎么在VCU中加入UDS服务以及如何做诊断仪，中间都需要大概哪些阶段呢

原文地址：https://www.zhihu.com/question/426056912

卡卡

随着OTA的普及，以及最近几年车载行业的蓬勃发展，越来越多的ECU都在支持刷写升级，刷写分为CAN/CANFD刷写、路由刷写、DoIP刷写等（LIN刷写除外）；然而无论是哪种刷写模式几乎都无法避开$34、$36、$37这三个服务，因此今天我们暂不讲完整的刷写流程，先来认识一下这3个服务的功能用途及组成。
34服务
功能：获取DUT支持的单次刷写命令的最大长度
命令格式（请求&应答）：


#1：34服务
#2：dataFormatIdentifier，一般使用默认值00；高四位表示Compression Method，第四位表示Encryping Method；一般都未使用，使用默认值
#3：addressAndLengthFormatIdentifier，高四位代表memory Address长度；第四位表示memorySize的长度。
#4：memoryAddress，开始刷写（下载）的起始位置地址
#5：memorySize，从开始刷写到刷写结束的文件长度。
肯定应答：

A_Data byte	Parameter Name	Cvt	Byte value	Mnemonic
#1	RequestDownload Response SID	M	7416	RDPR
#2	lengthFormatldentifier	M	0016 to F016	LFID
#3 : #n	maxNumberOfBlockLength=[   byte#1(MSB)     :   byte#m ]	M : M	0016 to FF16 ： 0016 to FF16	MNROB- B1 ： Bm

#1：对34服务肯定应答74
#2：lengthFormatIdentifier，高四位表示参数maxNumberOfBlockLength的长度，低四位为保留位。#3...：maxNumberOfBlockLength，表示用户每次传输数据的请求中包含的最大字节数。
否定应答：

Hex	Description	Cvt	Mnemonic
13	incorrectMessageLengthOrlnvalidFormatThe length of the message is wrong.	M	IMLOIF
22	conditionsNotCorrectThis return code shall be sent if a server receives a request for this service while inthe process of receiving a download of a software or calibration module. This couldoccur if there is a data size mismatch between the server and the client during thedownload of a module.	M	CNC
31	requestOutOfRangeThis return code shall be sent ifthe specified dataFormatldentifier is not valid.The specified addressAndLengthFormatldentifier is not valid,orThe specified memory Address/memory Size is not valid.	M	ROOR
33	securityAccessDeniedThis return code shall be sent if the server is secure (for servers that support the Security Access service) when a request for this service has been received.	M	SAD
70	uploadDownloadNotAcceptedThis response code indicates that an attempt to download to a server's memorycannot be accomplished due to fault conditions.	M	UDNA

举例如下：
tester 发送：
0x34 0x00 0x44 0x80 01 C0 00 0x00 01 C0 00
ECU响应：
0x74 0x20 0x0FFF (Positive response starting with 0x34+ 0x40 = 0x74, the length of maxNumberOfBlockLength is 0x2 Byte, maxNumberOfBlockLength is 0FFF, 3KB, the amount of data block transferred by each 0x36 Service.）
36服务功能：诊断刷写进行数据传输
TransferData （0x36）—— 数据传输
这个服务通常是用来下载/上传数据时用的，数据的传输方向由不同的服务控制：0x34服务表示下载，0x35服务表示上传。
0x36服务包含了一个blockSequenceCounter，在多个服务请求序列失败的时候以提高错误处理机制。在接收到0x34/0x35服务以后，blockSequenceCounter会被初始化为1。
服务请求报文中参数定义：
（1）blockSequenceCounter
这个值在第一次初始化的时候为0x01，往后每增加一次0x36服务的请求这个值也跟着增加1，直到增加到0xFF，会重新再从0x00增加（笔者的理解就是blockSequenceCounter的值对应用户此次请求传输出去的数据，以确保数据传输无误）。
例如以下2种情形：
数据已经正确的传输给ECU了，但是用户这边没有收到肯定响应，timeout以后用户这边会再次重复刚刚发出去的数据（blockSequenceCounter还是之前那个值）。这时候ECU通过blockSequenceCounter的值就可以知道用户又重复传了一次相同的数据，就不用再次重新写一遍Memory而直接给用户发送肯定响应。
如果数据没有正确传输给ECU，用户这边也不会收到肯定响应，timeout以后用户这边会再次重复刚刚发出去的数据（blockSequenceCounter还是之前那个值）。这时候ECU通过blockSequenceCounter的值就可以知道这是新传来的数据，则执行写Memory的操作，并且在成功后发送相应的肯定响应。
命令格式（请求&应答）：
诊断请求：


#1：36服务
#2：blockSequenceCounter，变化规律为36 01 - 36 02 ··········· 36 FF 36 00 - 36 01 ········ 36 FF - 36 00 - 36 01 ········ 36 FF ···········直到刷写结束。
#3 ··· n：transferRequestParameterRecord，代表每次要刷写到DUT的数据内容。
肯定应答：


#1：对36服务肯定应答76#2：blockSequenceCounter，对应36服务请求的blockSequenceCounter。
例如：36   01 + data          7
           6 01肯定应答






需要注意的是，第一个0x34请求对应的0x36服务的BlockSequenceCounter参数值从 0x01开始，后续每个0x36服务该参数依次+1. 当累计值达到0xFF后，该参数从0x00开始下一轮传输。
举例如下：
tester发送：
0x36 0x00 (TransferData request 0x36, blockSequenceCounter is 0x00)
ECU响应：
0x76 0x00 (Positive response starting with 0x36+ 0x40 = 0x76)
37服务功能：请求结束刷写
命令格式（请求&应答）：
诊断请求：
0x37(RequestTransferExit)退出数据传输

A Data byte	Parameter Name	Cvt	Byte value	Mnemonic
#1	RequestTransferExit Request SID	M	3716	RTE
#2:#n	transferRequestParameterRecord[]=[transferRequestParameter#1:transferRequestParameter#m ]	U:U	0016to FF16:0016to FF16	TRPR-TRTP-:TRTP

#1：37服务
#2 ··· n：transferRequestParameterRecord，由主机厂定义，一般只需发送37即可，不带任何参数，不过实际情况可能要根据各个主机厂定义。
肯定应答：

A Data byte	Parameter Name	Cvt	Byte value	Mnemonic
#1	RequestTransferExit Request SID	M	7716	RTEPR
#2:#n	transferRequestParameterRecord[]=[transferRequestParameter#1:transferRequestParameter#m ]	U:U	0016to FF16:0016to FF16	TREPR-TREP-:TREP

#1：对37服务肯定应答77#2 ··· n：transferRequestParameterRecord，由主机厂定义，一般只需发送37即可，不带任何参数，不过实际情况可能要根据各个主机厂定义。
例如：
tester发送：
0x37 (RequestTransferExit)
ECU响应：
0x77 (Positive response starting with 0x37+ 0x40 = 0x77)
否定应答：

卡卡

前言

首次，请教大家关于诊断服务28的几个问题：

• 28服务有何作用，为什么要有28服务呢？
  
• 28服务在使用过程中有哪些注意事项呢？
  
• 28服务诊断请求与诊断响应如何交互？
  

这篇，我们来一起探索并回答这些问题。为了便于大家理解，以下是本文的主题大纲：




<hr/>正文

服务功能

功能描述
根据ISO14119-1标准中所述，诊断服务28服务主要用于网络中的报文发送与接受，比如控制应用报文的发送与接收，又或是控制网络管理报文的发送与接收，以便满足一定场景下的应用需求。
下列文中使用到的Client可直接理解为上位机Tester，Server可直接理解为接受Tester诊断请求的ECU。
应用场景

一般而言，对于28诊断服务，主要应用场景为以下场合：

• 存在某些特殊的测试场景，比如只希望接收或者发送对应的网络管理与应用报文；
  
• 绝大多数情况下应用在刷写ECU的过程中，即在预编程条件下执行28服务功能寻址便可以抑制总线应用报文与网络管理报文的发送与接收，以便减少网络总线负载，提高ECU下载效率，同时刷写结束后也要执行28服务使能对应控制报文的发送与接收，在此过程中一般会配合85服务一起使用，后期会给大家介绍，敬请关注。
  

上述这些应用场景较为常见，这里就不一一列举。
通信控制基本原理：
如下图1所示，针对28服务的通信控制过程会经过如下几个AUTOSAR BSW模块进行处理，然后完成最终的通信控制，具体步骤如下：

• Tester发送28通信控制服务请求给到Server，Server会将该诊断报文请求传递至DCM模块；
  
• DCM模块调用28服务对应的上层应用函数首先进行输入参数的基本校验，校验无误之后然后传递相关控制模式请求至BswM模块；
  
• BswM模块根据静态配置的规则来实现对应请求中的通道通信状态控制；(常见的模式控制为3X4 = 12种)
  

如下表1所示，列举出了常见的12种的通信控制模式：


                                              表1 12种常见的通信控制模式

如下图1所示为28通信控制的原理图，可以看到28诊断服务经过DCM，BswM，Com，NM完成整个上述12种通信模式的控制。其中蓝色表示的部分为最终完成通信控制的函数体。
对于BswM以及NM模块还不是很熟悉的小伙伴，可以参考我之前的文章AutoSAR之基础篇CanNM (qq.com))以及AUTOSAR基础篇之BswM (qq.com)。




                                                            图1 28服务通信控制原理图

服务请求

服务请求是Client发送给到Server的诊断服务指令。
请求格式

按照ISO14229-1标准所述，如下图2所示为28服务诊断请求格式，即上述通信控制原理中诊断服务请求格式：



                                                       图2 28诊断服务请求格式

值得注意的是28服务诊断请求中的nodeIdentificationNumber仅在subFunction等于4或者5才有效，否则#4，#5参数可以不存在。
下图3中各参数解释如下：


                                                   图3 28诊断服务请求格式说明

如下图4所示，为上述subfunction(control Type)中的各项取值的具体含义：



                                               图4 28诊断服务subfunction取值说明

如下图5所示为communicationType的各项取值具体含义：



                                          图5 28服务communicationType定义说明

请求实例

以抑制网络管理报文发送为例，28服务诊断请求实例如下图6所示：



                                                  图6 28服务抑制网管报文请求实例

以控制远程特定地址节点进入仅诊断模式为例，节点地址为0x00 0A, 28服务诊断请求示例如下：


                                           图7 28服务特定节点进入诊断模式请求实例

关于控制控制远程特定地址节点进入正常工作模式，这里就不一一列举，具体message Flow可参考ISO14229-1规范。
服务响应

服务响应是针对Client对Server诊断请求的响应。
正响应格式

如下图8所示，为28诊断服务的正响应格式：


                                                           图8 28诊断服务正响应格式

从上图中可以看出，28诊断服务的正响应由以下三个部分组成：

• Response ID：该参数固定为SID+0x40 = 0x68；
  
• SubFunction：该参数为上述诊断请求格式中controlType;
  

正响应实例

抑制网络管理报文发送
如下图9所示，为上述28 01 02请求示例所对应的正响应：


                                                            图9 28 01 02正响应示例
其中，0x01就是跟诊断请求中的controlType保持一致即可。
控制远程特定地址节点进入仅诊断模式
如下图10所示，则为上述28 04 01 00 0A的所对应的正响应。



                                                   图10 28 04 01 00 0A正响应示例

负响应NRC支持

绝大多数情况下，Server针对Client的请求都会给到正响应，比如发生重启前需确保整车处于安全状态，如引擎熄火，车速不能超过3km/h等，或者为了防止不按照诊断请求格式进行请求，那么Server需要通过某种方式来告诉Client执行不成功的原因在哪里以便于调查问题直至得到正响应。
因此ISO14229-1针对所有的诊断服务提供了一种统一的诊断负响应的诊断格式：7F +SID + NRC。
其中NRC全称为Negetive Responce Code，每个NRC具有唯一的含义来代表当前诊断请求错误的原因所在。当然每个诊断服务支持的NRC不尽相同，具体支持的NRC需要参考ISO14229-1标准文档，对于27服务而言支持的NRC如下表2：



                                                               表2 28服务NRC支持

• 当诊断请求的subfuntion不在Server支持的范围内时，则Server会回复”7F 28 12“；
  
• 当发送报文长度或者格式不对时，则Server会回复"7F 28 13"；
  
• 例如当尝试请求复位时且当前车速条件不满足，此时Client发送诊断指请求时，Server将会回复“7F 28 22”来告诉请求者当前进入编程会话的条件不满足，请再次检查进入编程会话的条件。
  
• 当communicationType与nodeIdentificationNumber均超出规定的范围时，则Server会回复“7F 28 31”；
  

常见Bug大揭秘

对于从事过UDS开发的小伙伴可能会发现，其实针对每个服务的Bug都是有迹可循的，万变不离其宗，绝大多数问题都是由于针对需求理解不清晰或者其他人为因素导致的问题。
因此，为了方便大家能够在工作过程中能够快速找到问题症结所在，特将小T了解到的常见28服务Bug分享给到大家，当然具体问题还是要具体分析，小T这里所列出的只是比较典型且出现错误次数较多的Bug，仅供参考。



                                                             图11 28服务常见Bug大揭秘
<hr/>更多精彩内容！敬请关注公众号: ADAS与ECU之吾见！

清风寡欲

配置不同的服务，不同服务有不同的子功能，按照企业标准进行开发。