《UDS协议从入门到精通(UDS速查手册)》持续更新中...


常用服务已更新完毕,后面将陆续更新不常用服务

一、前言

  汽车软件开发/测试工作中不免涉及到UDS协议。实际上该协议的应用不仅仅局限于最常见的汽车故障检测工作中(比如4S店对汽车故障的快速定位),在车载ECU间的通信、数据传输、ECU软件的升级刷写等场景中都有着广泛的应用。
  经查阅各类资料和网络文章,仔细阅读14229-1协议标准,集众多网友、博主以及自己对该协议的理解,在本专栏针对UDS 14229-1中定义的全部26种服务作详细阐述, 并以图示方式给出直观的通信示例,可以作为一部中文UDS手册,便于随手查询

一、UDS简介

1.1 从汽车诊断说起

  汽车诊断是指对汽车进行故障检测和定位的过程,它是确保汽车安全和性能的重要环节。

  在汽车维修和开发工作中,诊断工具是必不可少的设备。通过诊断工具,技师可以读取车辆的故障码,进而定位故障原因。汽车软件开发或者测试人员也可以通过诊断工具连接到汽车的电子系统,读取和解析车辆的实时数据。而汽车诊断协议就是指诊断工具与车辆之间的通信协议。目前,市场上最常见的两种汽车诊断协议是OBD(On-Board Diagnostics)和UDS(Unified Diagnostic Services)。

  Tip📌:诊断工具也就是下文常提到的Tester,它可以是任何实现了通信协议的东西,比如可以是一个实现了UDS协议的上位机软件、实际的硬件设备(4S店的诊断仪)甚至是一个实现了UDS协议的系统中的测试脚本。

  在过去的几十年里,汽车诊断系统经历了巨大的变革和发展。起初,汽车诊断主要依靠人工检测和经验判断来发现问题。随着科技的进步,电子系统在汽车中的应用越来越广泛,汽车诊断也逐渐走向了自动化和数字化。从最初的简单故障指示灯到现在的复杂电子控制单元(ECU)和诊断协议的应用,汽车诊断技术已经取得了长足进步。

1.2 两种常见的诊断协议:OBD & UDS

  OBD和UDS是两种常见的诊断协议,它们在目标和应用领域上存在一些区别。OBD协议主要用于监测车辆的排放情况,通过读取车辆的故障码来判断是否符合排放标准。而UDS协议则更加全面和灵活,在各个ECU上是一种通用型的协议。

OBD(On-Board Diagnostic)
  主要用于跟汽车排放系统相关的ECU(电子控制单元,汽车上的板级控制器)的诊断。OBD协议分为两种:OBD-I和OBD-II。OBD-I是由美国为当时制造的加州汽车所制定的排放法规,随后这套法规被逐渐标准化,于是又提出了OBDII标准,包括:标准化的车载ECU数据诊断接口(SAE-J1962,也就是现在常说的OBD接口)、标准化的诊断解码工具(SAE-J1978)、标准化的诊断协议(ISO 9141-2、ISO 14230-4、ISO 15765-4)、标准化的故障码定义(SAE-J2012、ISO 15031-6)、标准化的维修服务指南(SAE-J2000),OBD-II在1996年开始实施,目前已经成为全球汽车行业的标准。因此,OBD标准可以看作一系列标准的集合,是具有强制标准需要参照的,是由法规要求的,其最初目的是环保,用于汽车排放系统相关的ECU上

UDS(Unified diagnostic services)
  UDS(Unified Diagnostic Services)是一种通用的汽车诊断协议,由欧洲汽车制造商协会(ACEA)和日本汽车制造商协会(JAMA)共同制定。它与OBD最大的区别就在于“Unified“上,是面向整车所有ECU的。单就UDS而言,它只是一个应用层协议(ISO 14229-1),不关心应用层以下的实现,比如执行该协议的应用层程序不关心通过何种物理传输方式实现与ECU硬件的通信,因此它既可以基于CAN线通信去实现,也能在Ethernet上实现。并且,UDS提供的是一个诊断服务的基本框架,定义了一系列的诊断服务和通用化的诊断流程,主机厂和零部件供应商可以根据实际情况选择实现其中的一部分或是自定义出一些私有化的诊断服务来,所以基于UDS协议的诊断又常常被称为Enhanced diagnosic(增强型诊断)。可见,UDS不是法规要求的,没有统一实现标准,可以基于该协议提供的诊断请求及响应格式进行二次开发

   简言之,UDS服务主要用于诊断设备Tester(Client)和ECU(Server)之间的诊断通信,诊断设备(Tester)发送诊断请求(request),ECU给出诊断响应(response),通过这种“一问一答”的形式让目标ECU执行一些期望的操作,而UDS就是为不同类型诊断功能的request和response定义了统一的内容和格式。

二、相关术语介绍

2.1 Service ID(SID)

  在UDS协议中,Service ID(SID)是指服务标识符,用于标识要执行的服务。每个服务都有一个唯一的SID,在诊断会话中通过SID来区分要执行/响应哪种服务请求。14229-1中定义了26种服务并将这些服务分为6大类:诊断和通信管理类、数据传输类、存储数据传输类、输入输出控制类、例程功能类、上传下载类。

  Tip📌:表格中标黄部分为常用的服务,其他的不常用。

大类SID (Hex)诊断服务名服务Service
诊断和通信管理类10诊断会话控制Diagnostic Session Control
11ECU复位ECU Reset
27安全访问Security Access
28通讯控制Comunication Control
3E待机握手Tester Present
83访问时间参数Access Timing Parameter
84安全数据传输Secured Data Transmission
85控制DTC的设置Control DTC Setting
86事件响应Response On Event
87链路控制Link Control
数据传输类22通过ID读数据Read Data By Identifier
23通过地址读取内存Read Memory By Adress
24通过ID读比例数据Read Scaling Data By Identifier
2A通过周期ID读取数据Read Data By Periodic Identifier
2C动态定义标识符Dynamically Define Data Identifier
2E通过ID写数据Write Data By Identifier
3D通过地址写内存Write Memory By Adress
存储数据传输类14清除诊断信息Clear Diagnostic Infomation
19读取故障码信息Read DTC Infomation
输入输出控制类2F通过ID控制输入输出Input/Output Control By Identifier
例程功能类31例行程序控制Routine Control
上传下载类34请求下载Request Download
35请求上传Request Upload
36数据传输Transfer Data
37请求退出传输Request Transfer Exit
38请求文件传输Request File Transfer

2.2 诊断请求(Diagnostic Request)

  诊断请求是指诊断工具向车辆发送的请求消息,用于请求执行某个服务。诊断请求消息由三个部分组成:SID、子功能和实际数据。其中,SID用于标识要执行的服务,至于子功能:指的是这个服务还能更进一步的划分或者具有启动/暂停之类的子功能。

  尽管服务类型不尽相同,但UDS针对这些服务定义了统一的诊断请求包的格式,每个诊断请求由1个Byte的SID + 1个Byte的 sub-function(实际上是1bit spr + 7bit sub-function,具体解释看下文)+ 不定长的实际数据构成,其格式如下所示:


在这里插入图片描述


Tip📌:spr存在的目的是告诉ECU针对某个服务请求是否需要发送正响应数据,用于减少ECU发送不必要的响应,节约系统资源:

  • spr=1, 抑制正响应,即ECU不给出正响应;
  • spr=0, 需要ECU给出正响应,如果某个服务没有sub-function,即没有第二个字节,那默认是要发正响应的。

2.3 正响应/负响应(Positive/Negative Response)

  诊断工具向车辆发送服务请求后,如果服务执行成功,则返回的响应消息称为正响应,反之返回的响应消息称为负响应。

2.3.1 正响应报文格式

  正响应报文的字节组成格式如下所示:


在这里插入图片描述


  ——举个最简单的例子(0x10-诊断会话控制服务):

诊断仪 目标ECU 10 01 1 诊断仪发送请求: byte1的10是SID, byte2的01是sub-function, 且可知Bit 7是0,即不抑制正响应 50 01 2 目标ECU给出响应: byte1是SID+0x40 = 50, byte2是sub-funtion 诊断仪 目标ECU

  ——再举个不带sub-function的例子(0x22-通过DID读数据):

诊断仪 目标ECU 22 F1 86 1 诊断仪发送请求: byte1的22是SID, byte2和byte3是DID(数据ID), 由于没有sub-function, 因此默认需要目标ECU给出正响应 62 F1 86 01 2 目标ECU给出响应: byte1的62是SID+0x40, byte2和byte3是DID, byte4是读到的数据 诊断仪 目标ECU

2.3.2 负响应报文格式

  负响应消息由两部分组成:SID和负响应码(NRC)。SID用于标识响应的服务,负响应码指示服务执行失败的原因。

  负响应报文的字节组成格式如下所示:


在这里插入图片描述


  ——还是拿0x10-诊断会话控制服务来举例:

诊断仪 目标ECU 10 05 1 诊断仪发送请求: 现在sub-function是05了, 假设系统不支持这个sub-function 7F 10 12 2 目标ECU给出响应: byte1是代表负响应的固定值0x7F, 10为SID,12为NRC, 指代sub-function not supported错误 诊断仪 目标ECU

2.4 负响应码(Negative Response Code - NRC)

  在UDS协议中,负响应码用于指示服务执行失败的原因。NRC用一个字节表示,每个取值都对应一种不同的错误类型。

NRC码含义NRC码含义
0x01 - 0x0f暂保留;0x78收到请求,延迟响应;
0x10未知错误,服务被拒绝;0x79 - 0x7d暂保留;
0x11不支持该服务请求;0x7e当前会话下子功能不支持;
0x12不支持子功能;0x7f当前会话下服务不支持;
0x13消息长度或格式错误;0x80暂保留;
0x14请求信息长度超出;0x81rpm(每分钟转速)太高;
0x15 - 0x20暂保留;0x82rpm太低;
0x21服务端正忙;0x83当前引擎正在运行;
0x22条件不满足;0x84当前引擎未运行;
0x23暂保留;0x85截止当前时间引擎运行时间太短;
0x24请求顺序错误;0x86温度过高;
0x25指令已经被接收,但是未被执行;0x87温度过低;
0x26失败的操作导致当前操作无法执行;0x88车速过高;
0x27 - 0x30暂保留;0x89车速过低;
0x31参数错误;0x8a油门/踏板过高(超过了当前要求的最大阈值);
0x32暂保留;0x8b油门/踏板过低;
0x33安全校验未通过;0x8c变速器档位不在空档;
0x34暂保留;0x8d变速器档位不在排挡;
0x35密钥不匹配;0x8e暂保留;
0x36已达到解锁最大错误次数;0x8f制动开关没有关闭
0x37超时时间未到;0x90换挡杆不在驻车档;
0x38 - 0x4f由扩展数据链路安全性保留;0x91变矩器离合器锁定;
0x50 - 0x6f暂保留;0x92电压过高;
0x70不允许上传下载;0x93电压过低;
0x71数据传输中断;0x94 - 0xef暂保留(特定条件下);
0x72擦除或烧写内存错误;0xf0 - 0xfe为汽车制造商保留;
0x73块序列计数错误;0xff暂保留;
0x74 - 0x77暂保留;

  以上内容是对UDS协议及一些入门基础知识的阐述,在接下来的篇章中,将详细介绍UDS协议中定义的全部26种服务。每一种服务都将被仔细解析和阐述,以便大家能够全面理解其功能和用法。各篇章还将通过图示方式给出直观的通信示例,帮助大家更好地理解UDS协议的实际应用。

三、UDS服务详述

  Tip📌:各表格中标黄的为常用服务!!!

3.1 诊断和通信管理类

  诊断和通信管理类是UDS服务的核心部分,它提供了与ECU进行通信以及执行诊断操作的基本功能。这些功能包括诊断会话的建立和终止、ECU的重置和诊断通信的管理。通过诊断和通信管理类,技术人员可以与ECU进行交互,获取ECU的状态信息,并执行各种诊断操作。主要包括如下服务:

Service(点击即可跳转功能简述
0x10:诊断会话控制客户端控制目标ECU的诊断会话状态。
0x11:ECU复位客户端强制让目标ECU执行复位操作。
0x27:安全访问客户端请求解锁受保护的目标ECU。
0x28:通讯控制客户端控制目标ECU的通信行为 (在特定情况下启用或禁用ECU的某些通信功能)。
0x3E:待机握手客户端向目标ECU表明它仍然存在。
0x85:控制DTC的设置客户端控制目标ECU中dtc的设置。
0x83:访问时间参数(待更新...)客户端使用此服务读取/修改当前通信的定时参数。
0x84:安全数据传输(待更新...)客户端使用此服务执行具有扩展数据链路安全性的数据传输。
0x86:事件响应(待更新...)客户端请求设置和/或控制目标ECU中的事件机制。
0x87:链路控制客户端请求控制通信波特率。

3.2 数据传输类

  数据传输类是用于在ECU和诊断工具之间传输数据的UDS服务类别。它提供了可靠的数据传输机制,确保数据的完整性和准确性。数据传输类包括数据的读取和写入功能,允许技术人员读取和修改ECU中的数据。此外,数据传输类还支持数据的块传输,以提高数据传输的效率。主要包括如下服务:

Service(点击即可跳转功能简述
0x22:通过ID读数据客户端请求读取由提供的DID标识的记录的当前值。
0x2E:通过ID写数据客户端请求写入由提供的DID指定的记录数据。
0x23:通过地址读内存客户端请求读取所提供内存范围的当前值。
0x24:通过ID读缩放数据/换算信息客户端请求读取由提供的DID标识的比例数据。
0x2A:通过周期读ID数据(待更新… …)客户端请求调度目标ECU中的数据进行周期性传输。
0x2C:动态定义标识符(待更新… …)客户端请求动态定义数据标识符,这些标识符随后可能被0x22-读DID服务读取。
0x3D:通过地址写内存(待更新… …)客户端请求覆盖提供的内存范围。

3.3 存储数据传输类

  存储数据传输类是一种特殊的数据传输类别,用于在ECU和诊断工具之间传输存储数据。存储数据可以是ECU的配置信息、故障码或日志文件等。通过存储数据传输类,技术人员可以读取和清除ECU中的存储数据,以便进行故障诊断和维修。所涉及的两个服务都是常用服务类型。主要包括如下服务:

Service(点击即可跳转功能简述
0x14:清除诊断信息允许客户端从目标ECU清除诊断信息(包括dtc、捕获的数据等)。
0x19:读取故障码信息允许客户端从目标ECU请求诊断信息(包括dtc、捕获数据等)。

3.4 IO控制类

  IO控制类是用于控制ECU输入输出(IO)功能的UDS服务类别。它提供了对ECU输入输出功能的访问和控制,包括读取和设置ECU的输入输出状态。通过IO控制类,技术人员可以与ECU的IO功能进行交互,实现对车辆系统的控制和监控。主要包括如下服务:

Service(点击即可跳转功能简述
0x2F:通过ID控制输入输出客户端请求控制特定于目标ECU的输入/输出。

3.5 例程功能类 - 调用ECU内部预置函数

  例程功能类是一种特殊的UDS服务类别,它允许技术人员调用ECU内部预置的函数。这些函数可以执行特定的操作,如执行自检、执行校准或执行特殊功能。通过例程功能类,技术人员可以利用ECU内部的功能来进行诊断和维修。主要包括如下服务:

Service(点击即可跳转功能简述
0x31:例行程序控制客户端请求启动、停止目标ECU中的例程(简单理解就是个函数)或请求例程结果。

3.6 上传下载类

  上传下载类是用于在ECU和诊断工具之间进行数据上传和下载的UDS服务类别。它提供了将数据从ECU上传到诊断工具或将数据从诊断工具下载到ECU的功能。上传下载类可用于备份和恢复ECU配置、更新ECU软件或执行其他数据传输操作。主要包括如下服务:

Service(点击即可跳转功能简述
0x34:请求下载客户端请求协商从客户端到目标ECU的数据传输。
0x36:数据传输客户端向目标ECU发送数据(下载)或向目标ECU请求数据(上传)。
0x37:请求退出传输客户端请求终止数据传输。
0x35:请求上传(待更新... ...)客户端请求从目标ECU到客户端的数据传输。
0x38:请求文件传输(待更新... ...)客户端请求在目标ECU和客户端之间进行文件传输。

四、写在最后

  汽车软件开发、测试、维修等过程中,UDS协议的使用已经越来越广泛了,不管底层基于哪种物理总线实现ECU间或者诊断设备和ECU间的通信,应用层大多都会经过UDS协议封装数据包。但这个协议细节众多,直接看ISO 14229-1标准文件的话学习成本太高,对不常读英文手册的人来说看起来更是尤为烦躁,而网上很多文章通常直接截取标准文件中的图片加以简单说明,同样不够友好。因此开设该专栏,力争针对ISO14229-1标准做一份细致全面的中文手册,以便随手查阅。

  近一年来,我从事车载操作系统的开发工作,即ECU固件软件的开发,又以ECU OTA升级为主要工作内容,对UDS、ECU软件刷写、部分BSW模块的开发有了一定的认识,后续将陆续开设各类专栏一方面对工作涉及的内容做较为全面的总结,一方面与大家分享,希望帮助更多的朋友进军汽车软件开发行业,共同学习进步!

>>>>>>>>> 返回专栏总目录 《UDS协议从入门到精通(UDS速查手册)》<<<<<<<<<

  • 80
    点赞
  • 264
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 14
    评论
### 回答1: UDS诊断协议是一种通用的诊断协议,用于执行诊断功能和运行控件单元。UDS协议也是ISO 14229标准的一部分,它是一种用于与车辆ECU进行通信的标准通信协议。本文介绍了如何快速入门UDS诊断协议。 首先,我们需要了解UDS协议的基本概念和术语。UDS协议有几个重要的术语包括传输层、会话层、诊断层以及识别码。了解这些术语将有助于我们更好地理解UDS协议的工作原理。 其次,我们需要掌握UDS协议的消息格式。UDS协议的消息格式由几个部分组成,包括服务识别码、数据长度、数据和响应代码。通过了解这个消息格式,我们可以更好地理解UDS协议各个部分的作用。 最后,我们需要了解UDS的一些常见服务和命令。UDS协议包括许多不同的服务和命令,例如读取故障码、清除故障码、发送诊断命令等。通过了解这些常见服务和命令,我们可以更好地应用UDS协议进行车辆诊断和控制。 总之,通过阅读UDS诊断协议快速入门PDF,我们可以了解UDS协议的基本概念、消息格式和常见服务和命令,进而更好地应用UDS协议进行车辆诊断和控制。 ### 回答2: UDS诊断协议是当前汽车电子控制系统诊断的通用标准协议,其主要作用是实现诊断设备与汽车电子控制系统之间的通信与数据交换。对于汽车诊断技术从业人员来说,熟练掌握UDS协议的使用及其原理就显得尤为重要。 而《UDS诊断协议快速入门PDF》就是针对UDS诊断协议使用者所编写的一份教程材料,旨在帮助初学者快速掌握UDS协议的使用技巧。 本教程内容包括:UDS协议的介绍、基础概念的讲解、UDS会话的建立、诊断服务的分类、UDS服务的具体实现及其使用实例等等;同时还介绍了相关诊断设备的硬件和软件架构,以及常见的应用场景和注意事项等内容。 总的来说,《UDS诊断协议快速入门PDF》对于想要学习和掌握UDS诊断协议的从业人员来说,是一份非常有用的教程材料,可以帮助他们更加有效地实现汽车电子控制系统的诊断与故障排除,提高自身的技术水平和工作效率。 ### 回答3: uds诊断协议是一种广泛应用于汽车行业的通信协议,它为故障诊断、程序更新等提供了标准化的通信方式。uds诊断协议快速入门pdf是一份针对初学者的入门指南,通过简单易懂的语言和丰富的示例,帮助读者了解uds协议的基础知识和应用场景,具体内容包括: 1. uds协议的基础概念和结构,包括诊断会话、功能请求、响应报文等; 2. uds协议通信流程和数据传输方式,包括CAN总线和ISO 14229标准; 3. uds协议支持的功能服务和特殊功能服务,包括ECU诊断、编程/重置/初始化、信息查询等; 4. uds协议的应用范围和限制,包括OBD、ECU编程、安全性等方面的考虑。 该pdf指南还提供了一些常见问题的解决方案,以及对uds协议未来发展趋势的展望。通过学习这份快速入门指南,读者可以掌握uds协议的基础知识,为后续的学习和应用打下更加坚实的基础。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 14
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

车载系统攻城狮

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值