汽车UDS支持的服务

2021年5月5日
评论
501
前文写了UDS的概览:

汽车UDS:统一诊断服务概览

今天总结下常用的服务。
UDS的服务包含了6大类,共26种,每种服务都有自己独立的ID,即SID(Service Identifier)。常用服务有10、11、27、28、3E、85、19、14、22、23、2C、2E、3D、2F、31、34、35、36、37、38。

诊断和通信控制功能

SID10

诊断会话控制服务

SID11

控制器重启服务

SID27

身份认证服务

SID28

通信控制服务

SID3E

握手服务

SID85

DTC设置控制服务

故障码传输功能

SID19

读取故障码信息服务

SID14

清除故障码服务

数据传输功能

SID22

根据标识符读取数据服务

SID23

根据地址读取数据服务

SID2C

静态定义标识符服务

SID2E

根据标识符写入数据服务

SID3D

根据地址写入数据服务

IO控制功能

SID2F

输入输出控制

例程控制功能

SID31

例程控制

上传和下载功能

SID34

请求下载数据

SID35

请求上传数据

SID36

请求上传或下载数据

SID37

数据传输完成,请求退出

SID38

文件传输请求

10 服务

10服务是Diagnostic Session Control诊断会话控制,子功能有01、02、03三种,这三种代表10服务可以进入的3种不同的会话模式,不同的会话模式中诊断服务执行的权限不同。
  • 01 Default默认会话;
  • 02 Programming编程会话(用于解锁bootloader相关的诊断服务,即程序烧录);
  • 03 Extended扩展会话;

ECU上电时,进入默认会话(Default)。如果进入非默认会话,超过一段时间无请求,那么诊断将退回到默认会话01。值得一提的是,通过3E服务,可以使诊断保持在非默认状态。

11 服务

11服务是ECU Reset复位操作。比如在ECU升级成功后的复位请求操作,且在成功复位后ECU应切换到默认会话模式。关于该服务常用(01/02/03)的请求格式如下:

汽车UDS支持的服务

关于sub-funtion主要的选项定义如下:
  •     00:硬件复位(等同于ECU断蓄电池电再上电);
  •     01:KeyOffOn复位(等同于将点火钥匙旋至OFF后再回到ON位置);
  •     02:软件复位;
ECU在收到对应的复位请求后,返回的肯定响应格式如下:

汽车UDS支持的服务

27 服务

27服务是Security Access安全访问。加上子服务,再加上种子(seed),可以请求解锁。

服务的格式:

 +  + 

SID是27。

Sub-function,表征安全访问类型。

  • 00:ISOSAEReserved
  • 01:request Seed
  • 02:send Key
  • 03,05,07-5F: request Seed(不同安全等级)
  • 04,06,08-60: send Key(不同安全等级)
  • 61-7E:留给OEM自行发挥
  • 7F:ISOSAEReserved

完成安全访问的步骤:

  • 诊断仪向ECU请求“种子”(通常是与时间相关的伪随机数),
  • ECU向诊断仪发送“种子”,
  • 诊断仪向ECU发送“密钥” (根据请求得到的种子和一个本地的密码进行计算得来)
  • ECU判断诊断仪发来的“密钥”是否有效
汽车UDS支持的服务

举个例子:

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+NRCTx:02 67 06 00 00 00 00 00 肯定响应,通过安全校验
28 服务

28服务是Communication Control通讯控制。用于打开/关闭某些类别的报文的发送/接收,通常在软件刷写时使用。

在刷写软件时,需要下载大量数据,此阶段的总线负载较高,可以在刷写前发送28服务,将通信关闭,使其他节点保持静默,把所有通信资源都留给软件下载,当下载完成后再利用28服务将通信恢复。

28服务的格式:

 +  + + 

SID即0x28。

Sub-function,表明要对ECU的通信进行哪种控制,具体包括 :

  • 00 enableRxAndTx (激活接收和发送)
  • 01 enableRxAndDisableTx(激活接收和关闭发送)
  • 02 disableRxAndEnableTx(激活发送和关闭接收)
  • 03 disableRxAndTx(关闭接收和发送)
  • 04-3F ISOSAEReserved(预留)
  • 40-5F  vehicleManufacturerSpecific(OEM自行发挥)
  • 60-7E systemSupplierSpecific(供应商自行发挥)
  • 7F:ISOSAEReserved(预留)

communication Type,即诊断请求对哪种报文进行控制,长度为1 byte。最常用的就是低2 位,0代表预留,1代表应用报文,2代表网络管理报文,3代表普通应用报文和网络管理报文。

Node ID num是可选项,只有当sub-functional等于0x04或0x05时才需要使用。

比如:

28 01 01 表示激活应用报文的接收并关闭应用报文的发送(网络管理报文不受影响)。

28 00 01 表示激活应用报文的接收和发送(网络管理报文不受影响)。

3E 服务

3E服务是Tester Present待机握手

用于向ECU指示诊断仪仍然连接在网络上,先前激活的特定诊断服务和通信功能仍然保持激活状态,周期性发送。

在前面我们介绍了通过10服务使切换ECU的当前会话状态;当我们通过10 02/03请求ECU进入编程/扩展会话后;则需要周期性地发送TesterPresent (3E 服务) 服务,用于ECU非默认会话模式的保持,防止其自动返回到默认会话状态。关于3E服务的请求格式如下:

汽车UDS支持的服务

这里对sub-function的Bit7进行介绍,该位suppressPosRspMsgIndicationBit表示抑制肯定响应消息指示位;如果该位为0,那么报文的响应正常发送;但如果该位是1,那么注意此时的肯定响应是不需要进行回复发送的。所以,关于周期性的3E服务,我们常用的是80这个sub-function;这样ECU不需进行肯定响应的回复。

  如果请求的是3E 00 ,那么ECU在收到该服务后,返回的肯定响应格式如下:

汽车UDS支持的服务
85 服务

85服务是Control DTC Setting控制DTC设置,开启或关闭ECU内部的诊断故障码设置功能

通常与28服务一起使用。在开始刷新前,为了提升传输速率,通过28服务将所有ECU的通信服务关闭,这种情况下,ECU收到不到其他节点的报文,没有必要存储DTC,可以使用85服务将ECU存储DTC的功能禁止。

85服务的格式:

SID> + Sub-function> + DTCSettingControlOptionalRecord>

SID:0x85

sub-function,表明是打开还是关闭ECU的DTC存储,具体包括 :

0x01 on;0x02 off。

DTCSettingControlOptionalRecord:可选项,OEM自行定义。

22和2E服务

22服务是Read Data By Identifier读DID;2E服务是Write Data By  Identifier写DID。两个服务成对出现,所以一起介绍。

Request(请求):

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

Response(响应):

62+DID+Data

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

Request(请求):

2E+DID+Data

Response(响应):

6E+DID

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

19 服务

19服务是Read DTC Information 读取故障码信息,19 拥有28种子服务(Sub-Function)。

常用的子服务:

01(通过DTC掩码读取DTC数量)02(通过DTC状态掩码读取DTC)06(读取扩展信息)0A(读ECU支持的所有DTC数据)0E(读取最近确认的DTC)

0x01 (reportNumberOfDTCByStatusMask)

sub-function = 0x01用于读取符合特定条件的DTC数量,此时parameter为一个byte的Mask,用于与DTC的Status进行“按位取与”运算,而ECU返回的则是取"与"运算之后不为0的DTC的数量。DTC的Status用一个byte表示,其中的8个bit分别代表DTC的不同状态,比如,bit 0 表示这个DTC是active的还是passive的,bit 4表示这个DTC是否已经被confirm了,如果DTC的状态是confirm,则说明该DTC已经被ECU存储下来了。

像19 01 08这个命令,就是读取所有状态为confirm的DTC的数量。

0x02 (reportDTCByStatusMask)

sub-function = 0x02用于读取符合特定条件的DTC列表,parameter仍为一个byte的Mask,用于与DTC的Status进行“按位与”运算,而ECU返回的则是取"与"运算之后不为0的DTC。

19 02 01这个命令,就是读取所有状态为active的DTC的数量。

此时ECU返回的格式应该是59 02 01 XX XX XX 01 YY YY YY 09。

返回的DTC列表中的每个条目为4个字节,前三个字节用于标识DTC,比如 XX XX XX,最后一个字节用于标识DTC状态,比如01,表示DTC是active的,09表示DTC是active且confirm的。

0x06 (reportDTCExtDataRecordByDTCNumber)

sub-function = 0x06用于读取某个DTC及其相关的环境数据,此时parameter为4个byte,前三个byte用于标识我们要读取的DTC,第四个byte用于标识要读取的环境数据的范围,UDS规定使用FF来表示读取所有的环境数据,各厂家可以要根据自己的需求定义其他的值来代表要读取的环境数据的范围。环境数据包括DTC状态,优先级,发生次数,老化计数器,时间戳,里程等,厂家还可以根据自己的需求定义一些此DTC产生时的测量数据。

比如 19 06 XX XX XX FF就表示读取 XX XX XX这个DTC的所有环境数据,ECU的返回值应该是59 06 XX XX XX AA BB CC DD.....,其中AA BB CC DD...代表的就是XX XX XX这个DTC产生时所一起存储的环境数据。

0x0E(reportMostRecentConfirmedDTC)

sub-function = 0x0E时,不需要parameter。

0x0E表示,要求ECU上报最近的一条被置为confirm的DTC。0x0E的19服务通常被作为参数传递给86指令,要求ECU在发生DTC存储的时候进行自动上报,即19 0E这两个字节的指令被嵌入到86服务的命令中。这条命令在开发阶段会用到,比如验证某个故障路径是否生效。

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

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

14 服务

14服务是Clear Diagnostic Information清除诊断信息

清除ECU中存储的DTC。第一个字节是SID,后三个字节用来标识将要被删除的DTC种类,UDS规定用FF FF FF表示所有种类的DTC,OEM自定义代表动力总成,底盘,车身,网络通信等种类DTC的值。

举个例子:

14 FF FF FF 表示删除ECU中所有DTC。

ECU响应0x54,表示成功执行。

2F 服务

2F服务是Input Output Control By Identifier通过ID控制输入输出

输入输出功能主要是ECU的输入信号(如传感器)和输出信号(如执行器)进行控制。该服务在产线上用的非常多。比如,生产线车辆装配完成后,要看看冷却风扇的工作是否正常,就可以通过2F服务的诊断命令来控制风扇动作,直观且高效。

31 服务

31服务是Routine Control例程控制。
31服务是调用ECU内置的一些操作序列的接口,这个服务应用灵活,OEM可以根据自己的需要为ECU定义各种各样的内部操作,而要执行这些操作只需要调用31服务就可以实现。典型的用途包括检查边界条件、清除闪存、对数据进行较验、对软硬件依赖性进行校验,甚至有需要的话可以进行恢复出厂设置的操作,还有与ECU自身逻辑功能相关的操作也可以定义。
31服务的格式:
SID> + Sub-function> + Routine ID> + RoutineControlRptionRecord>
  • SID即0x31
  • sub-function,用于标识要执行什么动作:01开启,02停止,03请求结果
  • routineIdentifier,用于标识要执行的routine
  • routineControlOptionRecord,可选参数,用于标识routine执行时所需要的参数,由各家自定义它的内容
使用31服务时,发送31 01,31 02,31 03 有顺序吗?
不一定是这样的顺序,开启例程后可以发送请求例程结果(31 01 → 31 03),开启例程后,关闭例程再请求例程结果也可以,因为此时请求的是关闭例程的结果,14229里并没有对31 03做限制只对31 01有效(31 01 → 31 02 → 31 03)。
汽车UDS支持的服务
总结
常用的UDS服务主要就是以上类型,大家如果要熟悉熟练对UDS指令的操作,最好用CAN收发工具模拟发送请求,多多联系尝试。UDS在ECU软件开发过程中,时刻围绕着我们,经常用到,但是了解14229协议后,真的十分简单。多多操作,多多思考。

作者简介:

Demu传统汽车电控向智能驾驶转变的汽车人。从事发动机控制器系统工程师和软件工程师多年,有丰富的ECU系统和软件设计经验。欢迎大家一起留言交流,共同进步.

继续阅读
weinxin
扫码关注公众号
关注公众号领精彩彩蛋!
万字长文趣味解读整车OTA,建议收藏! 汽车技术

万字长文趣味解读整车OTA,建议收藏!

本文共三大章节,分别为整车OTA为什么困难重重、整车OTA需要注意些什么、uboot介绍,字数接近二万五千字,建议收藏阅读。 第1篇 整车OTA为什么困难重重 什么是汽车OTA 首先,我们先来看看各位...
汽车HMI设计原则 汽车技术

汽车HMI设计原则

汽车制造商必须为汽车显示屏选择正确的设计原则,否则分心驾驶将达到新的水平 近几年,车载大屏设计越来越受到车企的青睐,比如,梅赛德斯-奔驰)凭借其全新的全宽仪表盘显示器MBUX超屏吸引了大量关注。几乎所...
AutoSar模式管理总揽 汽车技术

AutoSar模式管理总揽

介绍下AUTOSAR中的模式管理(Mode Manager)的机理。了解模式管理之前,先解释下三个重要的概念:模式、状态和阶段。 Mode(模式) 模式是运行在车辆中的各种状态机(不仅仅是ECU状态管...
如何快速学习AUTOSAR? 汽车技术

如何快速学习AUTOSAR?

后台有同学询问:做汽车电子领域,但是没有软件基础,如何学习AUTOSAR呢?估计很多刚开始接触AUTOSAR的同学都有类似的疑问,简单分享下AUTOSAR的概览和学习技巧,希望能帮助到大家。   关于...

发表评论