UDS统一诊断服务

Posted 淘气的包子

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了UDS统一诊断服务相关的知识,希望对你有一定的参考价值。

介绍UDS统一诊断服务。

1.概述

UDS(Unified Diagnostic Services)是ISO 15765和ISO 14229定义的一种汽车通用诊断协议,位于OSI模型中的应用层,它可在不同的汽车总线(如CAN、LIN、Flexray)上实现,用于车辆电子系统的故障诊断和通信。它提供了一组标准化的诊断服务,允许诊断工具与车辆的电子控制单元(ECU)进行通信,以诊断和解决故障。

2.诊断原理

根据UDS的诊断协议,汽车上的控制系统需要根据规则化的诊断协议进行故障记录和处理,最终体现为诊断故障代码(Diagnostic Trouble Code,DTC)的方式。

3.UDS诊断服务介绍

(1)诊断会话控制服务(Diagnostic Session Control Service)

该服务用于建立和管理诊断会话,包括默认会话、扩展会话和制造商自定义会话。通过该服务,诊断工具可以选择适当的会话模式与ECU进行通信。

(2)ECU重置服务(ECU Reset Service)

该服务用于重置ECU的状态。诊断工具可以向ECU发送重置请求,使其返回到默认状态。

(3)读取数据服务(Read Data Service)

该服务用于从ECU读取数据。诊断工具可以发送读取请求,指定要读取的数据标识符或数据标识符组合,然后ECU将返回相应的数据值。

(4)写入数据服务(Write Data Service)

该服务用于向ECU写入数据。诊断工具可以发送写入请求,指定要写入的数据标识符和相应的数据值,以便ECU进行配置或设置。

(5)安全访问服务(Security Access Service)

该服务用于控制对ECU的安全访问。ECU可以设置访问级别,并要求诊断工具进行安全访问验证,以确保只有授权的工具可以进行访问和修改。

(6)诊断错误管理服务(Diagnostic Trouble Code Management Service)

该服务用于管理诊断故障码(DTC)和诊断事件。诊断工具可以请求ECU返回DTC和相关信息,以帮助定位和解决故障。

(7)例程控制服务(Routine Control Service)

该服务用于控制ECU的特定例程和操作。诊断工具可以发送例程控制请求,以启动、停止或控制ECU执行特定的例程。

(8)编码和标定服务(Coding and Programming Service)

该服务用于对ECU进行编码和编程操作。诊断工具可以向ECU发送编码或编程请求,以更改ECU的配置或更新软件。

4.UDS诊断服务分类

根据功能和处理目的被分类为不同的功能单元:

4.1 诊断和通信管理功能单元(Diagnostic and Communication Management)

$10 - 诊断会话控制(DiagnosticSessionControl)
该服务请求ECU从活动会话过渡到其他会话。包含三个子功能:01 - Default、02 - Programming、03 - Extended。


$11 - 电控单元复位(ECUReset)
该服务请求ECU执行复位。ECUReset请求参数的示例包括:hardReset、keyOffOnReset、softReset。


$27 - 安全访问(SecurityAccess)
此服务用于在活动诊断会话中达到更高的安全级别。可能需要SecurityAccess请求来解锁并访问受保护的功能及数据(例如通过DID读取ECU ID信息)。也可以用于从一个会话通过解锁以成功切换到其他会话。


$28 - 通讯控制(CommunicationControl)
该服务请求ECU控制其通信行为。一个典型的示例包括要求CAN总线中的ECU关闭车载通信,以提高诊断通信的效率。


$3E - 待机握手(TesterPresent)
TesterPresent请求通常定期发送,并包含一个功能地址。它指示测试仪仍处于连接状态,并请求ECU保持当前诊断状态(例如,除默认会话之外的其他会话处于活动状态,RoE机制仍处于活动状态)。对这个服务的正响应抑制可以减少总线负载。


$83 - 访问时间参数(AccessTimingParameter)
该请求用于读取和/或修改通信定时参数。


$84 - 安全数据传输(SecuredDataTransmission)
此请求用于传输受加密方法保护的诊断数据。为此,必须实现位于应用程序层与测试仪和ECU的应用程序之间的“安全子层”。数据根据ISO 15764(扩展数据链接安全性)进行处理。


$85 - 诊断故障码设置控制(ControlDTCSetting)
该服务要求ECU停止/恢复DTC的设置。将此服务与车载通信切换 (服务$28通讯控制)相结合,可增加用于Flash编程的速度。


$86 - 事件响应(ResponseOnEvent)
事件响应(RoE)服务请求ECU自动传输指定事件的响应。


$87 - 链路控制(LinkControl)
该服务请求控制通信数据速率。对于CAN,它会影响ISO 11898中规定的数据链路层,从而影响用于板载通信以及诊断通信的数据速率。转换数据速率的请求分为:验证网络上的ECU是否允许特定的数据速率,在验证结果为肯定的情况下请求转换,执行转换。

4.2 数据传输功能单元(Data Transmission)

$22 - 通过ID读数据(ReadDataByldentifier)
该服务请求读取由DID参数标识的数据记录值。DID用于标识特定的本地数据记录。数据标识符0xF224可以包含诸如电池电压,歧管绝对压力,空气质量流量,车辆大气压以及计算出的负载值之类的数据。


$23 - 通过地址读内存(ReadMemoryByAddress)
该服务请求读取指定内存范围的当前值。请求参数是内存地址和内存大小。用于请求参数的字节数在addressAndLengthFormatldentifier中指定。


$24 - 通过ID读比例数据(ReadScalingDataByidentifier)
该服务请求ECU将缩放信息值传输到测试仪。测试人员使用定标信息值来转换数据。这项服务的实施增加了ECU软件的实用性。作为替代,测试器可以将缩放比例信息存储在数据库中。


$2A - 通过周期ID读取数据(ReadDataUyPeriodicidentifier)
该服务请求定期发送数据记录值。所请求的数据的传输速率由传输模式参数设置,例如“中等速率发送”,例如300 ms。


$2C - 动态定义标识符(DynamicallyDefineDataldentifier)
该服务允许测试人员在ECU中动态定义新的数据标识符,其中包含对静态定义的标识符和/或内存地址的引用。测试人员随后可以通过服务请求2A(readDataByPeriodicIdentifier)读取此动态定义的数据记录。动态定义的标识符的一个优点是, 一次服务可以请求传输很多的的数据记录。


$2E - 通过ID写数据(WriteDataByldentifier)
通过此服务,可以将由标识符(DID)指定的数据记录写入ECU存储器。


$3D - 通过地址写内存(WriteMemoryByAddress)
该服务允许将数据记录直接写入ECU的内存。请求参数是内存地址和内存大小以及数据记录。用于参数内存地址和内存大小的字节数在addressAndLengthFormatidentifier中指定。

4.3 存储数据传输功能单元(Stored Data Transmission)

$14 - 清除诊断信息(ClearDiagnosticInformation)
清除(复位)DTC格式,它可以改变DTC的状态。此服务允许在一个或多个ECU中清除错误存储器的内容。因此,可以使用物理地址或功能地址来请求服务。3个FF代表清除所有DTC。例如:
请求:14 + FF + FF + FF;
响应:54 。


$19 - 读取故障码信息(ReadDTCInformation)
诊断故障代码(DTC)用于编码和识别检测到的与排放有关和与排放无关的故障。DTC通常为三个字节,OBD II占用两个字节。该服务从一个或多个ECU请求DTC信息的状态。因此,该服务可以用物理地址或功能地址查询。测试人员可以请求与DTC关联的已存储数据记录,也称为“DTC快照”。DTC快照包含故障发生时的特定数据值。

4.4 输入输出控制功能单元(Input & Output Control)

$2F - 通过标识符控制输入输出(InputOutputControlByIdentifier)
该服务主要用于代替输入信号的值或控制ECU的输出。通常,此服务会绕过ECU的应用程序软件并直接触发输出电路,然后直接读取连接到输入电路的传感器。

4.5 例行程序功能单元(Remote Activation of Routine)

$31 - 例行程序控制(RoutineControl)
该服务用于维护和停止ECU内部例行程序。可以读取例程的结果以进行分析。该例行程序由两个字节的例行程序identifier标识。

4.6 上传下载功能单元(Upload & Download)

$34 - 请求下载(RequestDownload)
此服务启动从测试仪到ECU的数据传输。当ECU准备从测试仪接收数据时,它会发送肯定响应,其中包含用于后续数据传输的可用块大小(每个传输数据请求的数据字节数)。


$35 - 请求上传(RequestUpload)
此服务启动从ECU到测试仪的数据传输。当ECU准备好将数据发送到测试仪时,它会发送一个肯定的响应,其中包含用于后续数据传输的块大小(每个传输数据请求的数据字节数)。


$36 - 数据传输(TransferData)
此服务用于在测试仪和ECU之间(下载)或在ECU和测试仪之间(向上)传输数据。如果需要一个以上的transferData请求来传输数据,则使用blockSequenceCounter对传输次数进行计数。计数器允许在传输损坏后重复传输块。因此,在出现通信问题时,不必再次传输完整的数据。


$37 - 请求退出传输(RequestTransferExit)
该服务用于终止transferData服务。完整的数据传输从requestDownloadrequestUpload服务开始,再由几个transferData服务继续,并由requestTransferExit服务完成。


$38 - 请求文件传输(RequestFileTransfer)
该服务用于终止transferData服务。完整的数据传输从requestDownloadrequestUpload服务开始,再由几个transferData服务继续,并由requestTransferExit服务完成。

5.否定响应码

UDS中定义的否定响应代码非常多,但常用的只有以下这些:

(1)ServiceNotSupported/服务不支持($11 )

当诊断仪发送的请求消息中服务标识符无法识别或不支持时,ECU应发送该响应码

(2)SubFunctionNotSupported/不支持子功能($12 )

该响应码表明请求的动作不能执行的原因是ECU不支持请求消息中的服务特定参数。如果诊断仪已经发送了一请求消息,并且该请求消息包含能识别且支持的服务标识符,但子功能要么无法识别要么不支持,此时ECU应(shall)发送此响应代码

(3)IncorrectMessageLengthOrInvalidFormat/不正确的消息长度或无效的格式($13)

该响应码表明请求的动作不能执行的原因是ECU接收到的请求消息长度与特定服务规定的长度不匹配或者是参数格式与特定服务规定的格式不匹配。

(4)conditionsNotCorrect/条件不正确($22)

该响应码表明请求的动作不能执行的原因是ECU的状态条件不允许。

(5)requestSequenceError/请求序列错误($24)

该响应码表明请求的动作不能执行的原因是ECU收到一个非预期的请求消息序列或诊断仪发送的消息。

(6)requestOutOfRange/请求超出范围($31)

该响应码表明请求的动作不能执行的原因是ECU检测到请求消息包含一个超出允许范围的参数或者是不支持或者激活会话模式下不支持的数据标识符/例程标识符的访问。应(shall)允许诊断仪在ECU内部进行读数据、写数据或通过数据调整功能的服务使用该响应代码。

(7)securityAccessDenied/安全访问拒绝($33)

用在需要安全访问但没通过安全访问的情况。

(8)invalidKey/密钥无效($35)

该响应码表明ECU不允许通过安全访问的原因是诊断仪发送的密钥与ECU内存中的密钥不匹配。

(9)generalProgrammingFailure/一般编程失败($72)

该响应码表明在不可擦除的内存设备中进行擦除或编程时ECU检测到错误发生。

(10)requestCorrectlyReceived-ResponsePending/正确接收请求消息-等待响应($78)

该响应码表明诊断仪请求的消息被ECU正确接收且请求消息中所有参数有效,但是将执行的动作未完成且ECU未准备好接收其它请求。一旦完成所请求的服务,ECU应(shall)发送一肯定响应消息或发送否定响应吗不为78的否定响应消息。

(11)subFunctionNotSupportedInActiveSession/激活会话不支持该子服务($7E)

该响应码表明请求的动作不能执行的原因是当前会话模式下ECU不支持请求的子服务。

(12)serviceNotSupportedInActiveSession/激活会话不支持该服务($7F)

该响应码表明请求的动作不能执行的原因是当前会话模式下ECU不支持请求的服务。

总之,UDS诊断服务提供了一种标准化的方式,使诊断工具能够与车辆的ECU进行通信、诊断故障和执行各种操作。通过使用UDS协议,技术人员可以快速准确地定位和解决车辆电子系统的故障,提高诊断效率和精确度。
 
原文链接:https://blog.csdn.net/qq_33163046/article/details/127057492

 

如何看懂UDS诊断报文

UDS介绍

UDS(Unified Diagnostic Services,统一的诊断服务)诊断协议是ISO 15765 和ISO 14229 定义的一种汽车通用诊断协议,位于OSI模型中的应用层,它可在不同的汽车总线(例如CAN, LIN, Flexray, Ethernet 和 K-line)上实现。UDS协议的应用层定义是ISO 14229-1,目前大部分汽车厂商均采用UDS on CAN的诊断协议。

UDS本质上是一系列的服务,共包含6大类26种。每种服务都有自己独立的ID,即SID。

  • SID:Service Identifier,诊断服务ID。UDS本质上是一种定向的通信,是一种交互协议(Request/Response),即诊断方给ECU发送指定的请求数据(Request),这条数据中需要包含SID。
  • 如果是肯定的响应(Positive Response),回复[SID+0x40],如请求10,响应50;请求22,响应62。
  • 如果是否定的响应(Negative Response),回复7F+SID+NRC,回复的是一个声明。

肯定响应和否定响应的形式一定要熟记。

常用服务介绍

UDS的26种服务中,有7种很重要。它们分别是:

  • $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(待机握手)。

 

下面对这7个服务进行解读。

$10诊断会话

$10包含3个子功能,

  • 01 Default,
  • 02 Programming,
  • 03 Extended,

ECU上电时,进入的是默认会话(Default)。如果您进入了一个非默认会话的状态,一个定时器会运转,如果一段时间内没有请求,那么到时间后,诊断退回到默认会话01。当然,我们有一个$3E的服务,可以使诊断保持在非默认的状态。

报文包含4种类型,即

  • SID,
  • SID+SF(Sub-function),
  • SID+DID(Data Identifier)(读写用),
  • SID+SF+DID。

NRC:Negative Response Code(否定响应码)。如果ECU拒绝了一个请求,它会回应一个NRC。不同的NRC有不同的含义。

例子:以CAN总线网络举例。

八个数据字节,第一字节被网络层占用

  • 请求(Request):

02 10 02 xx xx xx xx xx

02中的0代表网络层单帧SF,2代表 数据域有2个字节;10是SID,02是子功能

  • 肯定响应:

02 50 02 xx xx xx xx xx

02同上,10+40表示对SID的肯定回复,02是子功能。

  • 否定响应:

03 7F 10 22 xx xx xx xx;

03同上,7F表示否定响应,10是SID,22是NRC。

$3E待机握手

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

例子:

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

$27安全访问

27服务,加上一个子服务,再加上一个钥匙,这样的服务请求可以进行解锁。

比如下面的例子,2n-1是某个子服务,通过首轮种子的请求,首轮ECU会返回67+01+AA+BB+CC+DD,AA~DD就是种子了。之后第二轮,诊断端会利用种子进行运算(利用整车厂的算法),生成k1(不一定是1个字节),那么发送请求,27+02+[k1]。ECU同样也会通过种子算出k2。当k1和k2匹配时,解锁(Unlocked)成功。

  • 例子:

Rx: 02 27 05 00 00 00 00 00 安全访问,05子功能
Tx: 07 67 05 08 27 11 F0 77 肯定响应,回复了对应安全级别的种子
Rx: 06 27 06 FF FF FF FF 00 发送密钥,4个FF。注意06是与05成对使用的。
Tx: 03 7F 27 78 00 00 00 00 否定响应,7F+27+NRC
Tx: 02 67 06 00 00 00 00 00 肯定响应,通过安全校验

$22读数据

$22读数据,
Request(请求):

22+DID(Data Identifier,通常是两个字节)

Response(响应):

62+DID+Data

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

$2E写数据

$22写数据,
Request(请求):

2E+DID+Data

Response(响应):

6E+DID

注意,比如0xF186这个DID不支持直接写入数据,需要用$10来进行会话转换。也就是说,对于写数据的请求,一般来说需要在一个非默认会话,或解锁的状态下才能进行

$19 读DTC

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

故障码包括四个大类,分别是PCBU,P是powertrain动力系统,C是Chassis底盘,B是Body车身,U是network通信系统。一个DTC信息占用4个字节。最后一个字节是DTC的状态。前两个字节是我们熟知的类似P0047的故障码。

DTCHighByteDTCMiddleByteDTCLowByteDTCStatus
Byte 1Byte 2Byte 3Byte 4

$19 拥有28个子服务(Sub-Function)。常用的子服务有02(通过DTC状态掩码读取DTC),04(读取快照信息),06(读取扩展信息),0A(读ECU支持的所有DTC数据)。

$14清除DTC

清除(复位)DTC格式,它可以改变DTC的状态。3个FF代表清除所有DTC。

Request:14+FF+FF+FF;
Response:54 。

诊断报文解析

UDS 的诊断数据的发送与接收都是基于CAN,所以每个数据流都包含基本的CAN Message 的架构

CAN Message =CAN ID + CAN DATA

根据上篇UDS文章的叙述,每一个PDU 包含控制信息PCI,数据信息Data.

 

网络层 PDU(协议数据单元)PCI(协议控制信息)格式:具体如下图所示:

帧类型bit7-4bit3-0Byte 2Byte 3
单帧PCItype=0SF_DLN/AN/A
首帧PCItype=1FF_DLFF_DLN/A
连续帧PCItype=2SNN/AN/A
流控帧PCItype=3FSBSST_min

 

综上所述,N_PDU =N_PCI+N_DATA, N_PCI的值主要集中的前三个字节N_DATA值主要集中在后面7位字节。其中,

  • SF_DL 代表单帧中数据字节数(取值0-7),
  • FF_DL代表 连续帧中的数据字节数(12bit可表四8~4095),
  • SN代表此帧为连续帧中的第几帧,(0、1、2...E、F、0、1...)
  • FS流控制帧,有三种状态:继续发送0、保持等待1、数据溢出2
  • BS规定发送端允许持续传输连续帧数目的最大值(0~255),
  • STmin限定连续帧相互之间所允许的最小时间间隔。

先面用连个例子进行说明,请参考!

例子 1--- 单帧的数据传输与接收

[图片上传失败...(image-b66bab-1538824826939)]

数据发送: 02 27 09
数据反馈: 03 7F 27 7E ---==否定的响应==(Negative Response),回复==7F+SID+NRC==,回复的是一个声明

数据发送: 02 10 40
数据反馈: 06 50 40 00 32 01 F4 ---==肯定的响应==(Positive Response),回复[==SID+0x40==],就是请求10,响应40;回复的是一组数据

由于这个数据发送与接收都是单帧传输,所以第一个数据的高四位均为0,四个数据流中的第一个字节的低四位,02,03,02,06代表的为此帧数据含有几个字节,多余的数据位都用 00或者AA行填充。

例子2 --- 多帧的数据接收与传输

[图片上传失败...(image-b5e84b-1538824826939)]

数据发送:

  • 06 19 04 00 01 00 00 00

数据反馈:

  • 10 1E 59 04 00 01 00 27
  • 30 00 00 00 00 00 00 00
  • 21 00 0B FF FF FF FF FF
  • 22 FF FF FF FF FF FF FF
  • 23 FF FF FF FF FF FF FF
  • 24 FF FF FF AA AA AA AA

数据发送为单帧,所以06代表发送的数据中含有6个字节,

回复为Positive Response,为连续帧。

  • 10中的1代表连续帧的首帧,==01E代表此连续帧含有30个字节==,
  • 30代表此连续帧的流控制帧,
  • 21,22,23,24代表连续帧中的第几帧,21代表第一帧,22代表第二帧,依此类推,其中AA为填充位。

参考资料:



作者:智车科技
链接:https://www.jianshu.com/p/b5805e734ed6
来源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

以上是关于UDS统一诊断服务的主要内容,如果未能解决你的问题,请参考以下文章

如何看懂UDS诊断报文

如何看懂UDS诊断报文

如何看懂UDS诊断报文

详解UDS CAN诊断:什么是UDS(ISO 14229)诊断?

UDS诊断详解

车载测试系列:UDS诊断服务