UDS

0X10服务

默认会话

  • Default Session(01)
  • 读取数据、故障码、重置ECU

扩展会话

  • Extended Session(03)
  • 解锁ECU、控制输入输出

编程会话

  • Extended Session(02)
  • 刷写ECU的相关服务

总而言之,在不同的会话模式下,做的事情不一样。

ECU制造商可以自定义额外会话

  • 标准会话:默认会话、非默认会话(扩展、编程)

ECU一上电就处于默认会话

会话最大超时时间

进入编程会话的前提必须先进入扩展会话

10服务请求和相应的报文格式

诊断请求:10 会话子功能

否定响应:7F 10 NRC(否定响应码)

肯定响应:50 会话子功能 会话的超时时间 (协议规定两个字节来表示) 扩展的增强性的会话超时时间(也是两个字节来表示)

EXAMPLE:

请求示例: 10 02

否定响应: 7F 10 22 (先决条件不正确)

请求实例: 10 03

肯定响应: 50 03 00 32 01 F4

ISO14229 -1

规定26个诊断服务细节,也就是UDS诊断报文的细节

ISO11898(CAN协议) 中的数据帧

帧起始 仲裁域 控制域 数据域(最多8个字节) CRC域 ACK域 帧结束

UDS的诊断报文就在CAN报文的数据域

  • 有时候一帧报文CAN便能传输完成(单帧传输)
  • 但有时候一帧CAN报文装不下(多帧报文传输)

ISO15765-2

规定了基于CAN总线进行UDS报文传输的细节(包括四种帧)

  • 单帧(SF):发送方 ------------ 接收方(首字节第一位为0)

一个单帧的UDS诊断请求CAN报文(这里面的0代表单帧,2代表后面的有效字节数)

02   10    03

一个单帧的UDS诊断响应CAN报文

06    50    03    00    32    01    F4

  • 多帧,首先会发送一个首帧(FF)给接收方,然后接收方返回一个“流控帧”(FC),这个流控帧会告诉发送方,接下来该怎么继续发送,如何发送后续的帧。然后发送方按照指示会发送一个“连续帧(CF)”,然后再等待接收FC指示……

一次多帧传输UDS诊断响应的CAN报文过程

FF(第一个字节为1代表首帧):10 10 62 F1 89 44 65 76

FC(第一个字节为3代表流控帧):30 00 14

CF(第一字节为2代表连续帧):21 65 6C 6F 70 65 72 70

CF(第一字节为2代表连续帧):22 45 43 55

### UDS诊断 0X27服务,解锁ECU

过程

解锁ECU的27服务必须要在扩展会话下进行

ECU可以设定多个不同的安全级别

NRC 描述
0X12 27服务的子功能不被当前ECU所支持
0X22 27服务的使用的条件不正确,没有处于扩展会话状态下
0X24 没有经过27 01“请求种子” 服务,直接就27 02 “发送Key” 时
0X35 27 02 发送的Key不正确(ECU验证失败)
0X36 到达了ECU验证Key失败的最大次数
0X37 到达最大失败次数后,ECU会处于不准解锁的计时等待阶段

UDS中的诊断故障码DTC

五位故障码(占俩个字节)

P0420

前两个比特代表故障系统:

  • P(0):动力系统
  • C(1):底盘系统
  • B(2):车身系统
  • U(3):网络系统

三四比特代表标准故障码/制造商自定义:

  • 0:ISO/SAE 控制
  • 1:制造商自定义
  • 2:ISO/SAE控制
  • 3:ISO/SAE控制

5-8比特代表故障所属的子系统

  • 0-2:燃料或空气计量系统

  • 3:点火系统

  • 4:排放系统

  • 5:车速控制系统

  • 6:辅助输出系统

  • 7-9:传动系统

  • A:混动驱动系统

9-16比特代表发生故障的具体部件及类型

UDS中的3字节故障码

UDS中的故障码(DTC)占3个字节

车企中主要采用

Root DTC(2Byte) + FTB(1Byte)

五位故障码 + 故障类型码

P0420 00

FTB

UDS故障码状态位

使用UDS 的19 02 服务读取故障码信息时,读取到的故障码信息占4个字节

0x19服务的01子功能



易碎

易碎

我看到的今夜的星空,是几万年前的光,我眼中的你是此时的你!

0 条评论

发表回复

Avatar placeholder

您的邮箱地址不会被公开。 必填项已用 * 标注

网站ICP备案皖ICP备2024045222号-1