第2章物理寻址详解

第1章：物理寻址详解

1.1 物理寻址的定义

物理寻址，说白了就是「点对点通信」。

在UDS协议里，一个物理请求报文，只能发给一个ECU。目标ECU收到后，也必须回复一个物理响应报文。这个响应，也只有那个特定的ECU能发。

我刚开始接触UDS时，总把物理寻址和功能寻址搞混。后来一个老工程师跟我说了句话，我记到现在——「物理寻址是打电话，功能寻址是广播。」

你想想看，打电话时，你只跟一个人说话。对方回答，也只回给你一个人。这就是物理寻址的本质。

核心要点：

物理请求：一个Tester → 一个ECU
物理响应：一个ECU → 一个Tester
通信关系：1对1，独占通道

为什么会这样设计？因为很多诊断操作，比如刷写ECU、读取故障码、执行例程，都需要独占访问。如果多个ECU同时响应，总线就乱套了。

1.2 物理寻址的CAN ID范围

物理寻址的CAN ID，在标准UDS协议里有明确的规定。我习惯把它分成两部分来看：

方向	CAN ID范围（11位标准帧）	说明
物理请求	0x7E0 - 0x7E7	Tester发给特定ECU
物理响应	0x7E8 - 0x7EF	ECU回复给Tester

嗯，这里要注意：

物理请求ID = 0x700 + ECU的逻辑地址
物理响应ID = 物理请求ID + 0x8

举个例子。假设一个ECU的逻辑地址是0x10，那么：

物理请求ID = 0x700 + 0x10 = 0x710
物理响应ID = 0x710 + 0x8 = 0x718

我在项目中遇到过一个问题。有个同事把物理请求ID配成了0x7E0，但ECU的逻辑地址是0x11。结果ECU根本不响应。查了半天才发现，0x7E0对应的是逻辑地址0x00的ECU，不是0x11。这种低级错误，其实很容易犯。

避坑指南：

我曾经见过一个项目，物理请求ID和物理响应ID的偏移量不是0x8，而是0x10。原因是OEM自定义了协议。所以，拿到需求后，第一件事就是确认OEM的ID分配规则。别想当然。

1.3 物理寻址的通信流程

物理寻址的通信流程，其实很简单。我画个流程图给你看：

Tester                    ECU
  |                         |
  |--- 物理请求 (0x710) --->|
  |                         |
  |<-- 物理响应 (0x718) ---|
  |                         |
  |--- 物理请求 (0x710) --->|
  |                         |
  |<-- 物理响应 (0x718) ---|
  |                         |

具体步骤：

Tester发送物理请求：CAN ID为0x710，数据域包含UDS服务ID和参数
ECU接收并处理：只有逻辑地址为0x10的ECU会处理这个报文
ECU发送物理响应：CAN ID为0x718，数据域包含响应数据
Tester接收响应：只有Tester会处理这个响应报文

你可能会问，如果总线上有多个ECU，它们怎么知道哪个报文是给自己的？

答案就在CAN ID里。每个ECU在初始化时，会配置好自己的物理请求ID和物理响应ID。收到报文后，ECU只检查CAN ID是否匹配自己的物理请求ID。匹配，就处理。不匹配，直接丢弃。

个人经验：

我建议你在做诊断测试时，先用CAN工具抓一下总线报文。确认物理请求ID和物理响应ID是否正确。这一步花不了几分钟，但能省下后面排查问题的大把时间。

1.4 物理寻址的应用场景

物理寻址的应用场景，主要集中在需要「独占访问」的操作上。我列几个常见的：

ECU刷写：刷写时，Tester必须独占访问目标ECU。如果多个ECU同时响应，刷写数据就会冲突。
故障码读取：读取某个ECU的故障码时，你只想要那个ECU的数据。其他ECU的数据，你不需要。
例程控制：比如执行某个ECU的自检例程。这个例程只能由那个ECU执行，其他ECU不能参与。
数据读取：读取某个ECU的特定数据，比如车速、水温等。这些数据只属于那个ECU。

我记得有一次，客户反馈说刷写时总失败。我抓了总线报文一看，发现Tester发送的是功能寻址请求，结果多个ECU同时响应，总线负载瞬间爆了。后来改成物理寻址，问题就解决了。

总结一下：

物理寻址，就是「一对一」的通信方式。它适用于需要独占访问的场景。CAN ID的分配有固定规则，但也要注意OEM的自定义情况。通信流程简单直接，但每一步都不能出错。