【诊断】汽车电子的UDS诊断总结

UDS诊断中的物理寻址和功能寻址

诊断的响应规则：物理寻址和功能寻址

  • UDS诊断服务是实现人或设备与ECU控制器交流的一种语言，那么
    • 诊断服务的响应规则就如同是语法，而SID（Service ID）定义就如同词汇。
  • 2种响应规则：物理寻址和功能寻址
  • 整车厂定义，提供给供应商

物理寻址PHY

  • 指定发送特定诊断请求Request，等待指定ECU给与响应。
  • 类似：医生和患者一对一
  • 报文可以多帧

功能寻址FUN

  • 可以广播诊断请求Request，同时等待总线上的ECU给与响应。
  • 类似：医生喊话“感冒的人？”和患者一对多
  • 所有报文都是单帧
    image

对比

支持的服务：

  • 物理寻址：支持所有UDS服务，
  • 功能寻址：只支持部分服务，如10、11、28、3E、85、22、14和19等

寻址对象：

  • 功能寻址：它是基于ECU（Electronic Control Unit，电子控制单元）的功能或服务进行寻址的。当诊断仪发送请求时，所有支持该功能或服务的ECU都会响应。
  • 物理寻址：它是基于ECU的物理地址（通常是ECU的硬件标识符或地址）进行寻址的。诊断仪通过物理地址来指定和通信特定的ECU。

通信范围：

  • 功能寻址：通常用于广播请求，例如请求所有ECU报告它们的状态。
  • 物理寻址：用于与特定ECU进行一对一的通信。

响应行为：

  • 功能寻址：可能导致多个ECU响应同一个请求。
  • 物理寻址：只有被寻址的ECU会响应请求。

工程示例

  • image
    image

诊断所处的层

image
image
image

诊断命令

UDS本质上是一种定向的通信

  • 是一种交互协议（Request/Response），即诊断方(Tester)给ECU发送指定的请求数据（Request）

诊断命令格式

  • (报文长度) + (SID诊断服务ID) + (SF子功能) + (DID) + (其他)
    • SF：粉色子功能
    • DID： data ID，22/2E服务多用，如图绿色
      image
      image

SID常见服务格式

  • image

正反馈/负反馈交互

  • 正反馈：(SID+40)
  • 负反馈：7F + SID + NRC
    image

特殊的NRC——0x78

  • requestCorrectlyReceived-ResponsePending（RCRRP，请求已被正确接收-回复待定）
    • 这个NRC表明请求消息被正确地接收，请求消息中的所有参数都是有效的，但是要执行的操作还没有完成，Server端还没有准备好接收另一个请求。
    • 一旦请求的服务已经完成，服务器应该发送一个积极的响应或消极的响应，响应代码应与此不同。
    • 这个NRC的消极响应可以被Server端重复，直到被请求的服务完成并且最终的响应消息被发送。
  • 在学钥匙报文中可见此NRC

诊断服务SID

  • UDS本质上是一系列服务的集合。

  • UDS的服务包含6大类，共26种。每种服务都有自己独立的ID，即SID

    • 0开头的SID：给OBD使用的，OBD必须要有

  • 诊断服务分类

    • UDS的服务分为6大类，但常用的服务是加背景色的15种。
    • 这15种服务又可粗略地划分为权限控制、读取数据/信息、写入数据/信息、通信控制、功能控制这几类（博主自己划分）
      image

  • 最常用的诊断服务

    • $10 Diagnostic Session Control（诊断会话）
    • $27 Security Access（安全访问）
    • $22 Read Data By Identifier（通过ID读数据）
    • $2E Write Data By Identifier（通过ID写数据）
    • $14 Clear Diagnostic Information（清除诊断信息）
    • $19 Read DTC Information
    • $3E Tester Present（待机握手）。
      image

$10：诊断会话 Diagnostic Session Control

不同会话：不同权限

  • 不同的诊断服务需要的权限不同

3种会话

$3E 80：待机握手，连接保持

$3E服务用于向服务器指示诊断仪仍然连接在网络上

  • 之前已经激活的诊断服务功能可以仍然保持激活状态。

例子：02 3E 80 00 00 00 00 00

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

非默认会话保持

  • 进入了一个非默认会话的状态，一个定时器会运转
  • 如果一段时间内没有请求，那么到时间后，诊断退回到默认会话01(最低权限)
  • $3E服务：可以使诊断保持在非默认的状态

$27：安全访问

不同DID: 单/双数

  • 首轮Tester种子的请求（27+01），ECU会返回67+01+AA+BB+CC+DD，AA~DD就是种子了。
  • 第二轮，诊断端的Tester会利用种子进行运算（根据整车厂的算法），生成k1（不一定是1个字节），之后发送请求，子服务是2n，这里我们还是假定n=1，即02子服务。这样Tester发出的就是27+02+[k1]。
  • 之后，ECU同样也会根据第一轮的种子自行算出k2。
  • 当ECU检查出k1和k2完全一致时，解锁（Unlocked）成功。
    image
    image
    image

安全验证算法的核心

  • 最大的核心就是算法了。
  • 举个简单的算法，比如seed和ECU SN前4个字节加一下，循环左移两位，执行3轮，return这个数作为key，结束。
  • 安全验证就是一把锁，算法越复杂，短时间解开的成本越高，越不易被破解掉。
  • 如果失败次数过多还会触发惩罚机制，一段时间内都无法再尝试解锁，防止人为的破解。

$22/2E：根据ID读写数据

$22读数据

  • Request（请求）：22+DID（Data Identifier，通常是两个字节）
  • Response（响应）：62+DID+Data
    image

部分DID

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

$2E写数据

  • Request（请求）：2E+DID+Data
  • Response（响应）：6E+DID

写数据的安全等级

  • 一般需要在一个扩展会话，和安全等级1的状态下才能进行。

$19：读DTC

19服务是一套诊断服务中的重中之重

  • image

DTC

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

DTC结构

  • 故障码包括四个大类，分别是PCBU，P是powertrain动力系统，C是Chassis底盘，B是Body车身，U是network通信系统。
  • 一个DTC信息占用4个字节。最后一个字节是DTC的状态。
    • DTMMiddleByte和DTCLowByte两个字节是我们熟知的类似P0047（ISO15031中的故障码）中“0047”的纯数字故障码。
    • 第一个字节在乘用车中，前两个bit代表P/C/B/U（动力/底盘/车身/网络）中的一个，之后六个bit是数字，合在一起的样子形如“C01”。
    • 第一个字节的前2个bit中，用00/01/10/11分别表示P/C/B/U。（感谢aymjwwl007）
  • 举个例子，U312345这个故障码（我杜撰的），
    • 它的状态是Test failed叠加Confirmed，那么DTC信息这四个字节就应该是0xF1(二进制11110001)，0x23，0x45，0x09。
      image

$19拥有28个子服务（Sub-Function）。常用的子服务有：

  • 01 (读取符合掩码条件的DTC数量)（必须支持）

    • 后面的参数是DTC状态掩码，若为01表示我想读当前故障，若为08表示我想读历史故障，若为09表示当前故障和历史故障都想读。
    • 在肯定回复时：
      • 组合应该是59(19+40) - 01 （子功能） - 09 （本ECU所支持的掩码条件）-01 DTC的格式（ISO14229-1为01） - 00 01 （目前满足条件的DTC有一个）

  • 02（读取符合掩码条件的DTC列表及其状态）（必须支持）

    • 后面的参数是DTC状态掩码，解读同上。
    • 在肯定回复时：
      • 59 - 02（子功能）- 09（本ECU所支持的掩码条件） - XX XX XX ( DTC,车厂定义 ) - 01 （这个故障码怎么了，01表示当前故障）

  • 04（读取快照信息），也叫冻结帧。

  • 06（读取扩展信息）。

  • 0A（读取ECU支持的所有DTC列表及其状态）（必须支持）

    • 这个就不必发DTC状态掩码了。所有支持的DTC列表及其状态都会打印出来。

黄色框是DTC，紧跟着的是DTC状态

image

同时读取当前/历史故障，黄色框是DTC，紧跟着的是DTC状态

image

$14：清除DTC

$14命令

  • 清除（复位）DTC格式，它可以改变DTC的状态。
  • DTC状态中的八个位，除bit4和bit6外均会被清零，包含当前故障（TestFailed）和历史故障（ConfirmedDTC）
  • bit4和bit6这两个testNotCompleted开头的会被强制置1。

格式

  • 3个FF代表清除所有DTC。
  • Request：14+FF+FF+FF
  • Response：54
    image

$2F：直接控制IO

2F服务：通过DID(数据标识符) 强制控制输入信号的替换和控制零部件负载输出

  • 这是一个用在产线上较多的服务。

Request（请求）：至少由4个字节组成

  • 第一个字节是2F，第二第三字节是DID，其中第二字节是高位。
  • 第四字节是input Output Control Parameter（并不算一个子功能），可以看做IO控制类型。
  • 如果第4字节是03，还需要第5字节：控制开关 00/01

IO控制类型分为4类

  • 00是控制权还给ECU，Return Control To ECU。
    • 请求报文是4个字节。
  • 01是复位为默认值，Reset to Default。
    • 请求报文是4个字节。
  • 02是冻结当前的状态，Freeze Current State。
    • 请求报文是4个字节。
  • 03是短暂接管控制权，Short Term Adjustment。
    • 请求报文的第五字节是控制代码
    • 可以是数字量，比如01是开，00是关；也可以是模拟量，比如空调风门的开度。

举例

  • 2F服务，黄色区域为2个字节的DID
    image
  • 这个图可以理解为：
    • 关闭开关：2F XX XX 03 00
    • 之后打开开关：2F XX XX 03 01
    • 之后控制权还给ECU：2F XX XX 00
    • 之后想复位回默认值，但是发现ECU不支持：2F XX XX 01

诊断命令备忘录

常见UDS报文

image

否定响应NRC

image

DTC状态位

image

参考链接

END

posted @ 2025-08-07 08:54  anliux  阅读(425)  评论(0)    收藏  举报