二、物理寻址与功能寻址基础：CAN标识符分配、物理寻址（点对点）原理、功能寻址（广播）原理

好，咱们进入第二个大块。说实话，很多刚入行的兄弟搞不清物理寻址和功能寻址到底有啥区别。我当年也踩过这个坑——在台架上测试ECU，发了一帧诊断请求，结果三个ECU同时响应，总线直接乱套了。嗯，这就是没搞懂寻址方式的结果。

今天咱们就把这个基础打牢。你想想看，CAN总线上挂着十几个ECU，诊断仪要跟其中一个说话，怎么保证别的ECU不插嘴？这就是寻址要解决的问题。

2.1 CAN标识符分配——诊断报文的“门牌号”

先说说CAN标识符（CAN ID）。在UDS诊断里，CAN ID就是报文的“门牌号”。每个ECU收到一帧CAN报文，第一件事就是看ID——是不是找我的？不是就扔了。

标准做法是这样的：

• 物理请求ID：诊断仪发给特定ECU，比如 0x7E0（常用）
• 物理响应ID：那个ECU回复诊断仪，比如 0x7E8
• 功能请求ID：诊断仪广播给所有ECU，比如 0x7DF
• 功能响应ID：各ECU回复时用各自的物理响应ID

我习惯把CAN ID分配比作快递单号。物理寻址就像顺丰寄件，有明确的收件人地址；功能寻址就像小区广播喇叭，喊一声“所有业主注意”，大家都能听到。

2.2 物理寻址（点对点）原理

物理寻址，说白了就是诊断仪跟一个ECU单独聊天。你发一帧请求，只有那个ECU会响应，别的ECU看到ID不对，直接忽略。

举个例子，咱们常用的11位CAN ID配置：

// 诊断仪 -> ECU1（物理请求）
CAN ID: 0x7E0
DLC: 8
Data: 02 10 03 00 00 00 00 00  // 诊断会话控制请求

// ECU1 -> 诊断仪（物理响应）
CAN ID: 0x7E8
DLC: 8
Data: 06 50 03 00 32 01 F4 00  // 肯定响应

这里要注意：物理响应ID通常是请求ID + 0x8。0x7E0 + 0x8 = 0x7E8，这是行业惯例。我在项目中遇到过一家供应商，他们偏要用0x7E9做响应ID，结果我们的诊断仪死活收不到回复。查了两天才发现是ID没对上。

2.3 功能寻址（广播）原理

功能寻址就更有意思了。诊断仪发一个广播ID，所有支持该功能的ECU都会收到。但响应方式有讲究——不是所有ECU都同时回复，那样总线会爆掉。

标准做法是：

• 功能请求：诊断仪发 0x7DF，所有ECU接收
• 功能响应：各ECU用自己的物理响应ID回复（如 0x7E8、0x7E9、0x7EA...）

但这里有个大坑：如果多个ECU同时回复，CAN总线会仲裁。ID小的优先发送，ID大的就得等。我曾经调试一个项目，三个ECU同时响应功能寻址，结果ID最小的那个总是先发，另外两个一直等，最后超时了。嗯，这就是为什么功能寻址通常只用于“读取”操作，比如读VIN、读DTC。

2.4 两种寻址的对比

咱们用表格总结一下，这样更直观：

对比项	物理寻址	功能寻址
通信方式	点对点（1对1）	广播（1对多）
请求CAN ID	特定ECU的ID（如0x7E0）	广播ID（如0x7DF）
响应方式	只有目标ECU回复	所有ECU用各自ID回复
适用场景	刷写、写配置、关键操作	读取信息、广播请求
总线负载	低（只有1个响应）	高（多个响应可能冲突）
可靠性	高（一对一确认）	中（可能丢响应）

2.5 实际项目中的选择策略

说了这么多，到底什么时候用物理寻址，什么时候用功能寻址？我个人的经验是这样的：

1. 刷写ECU：必须用物理寻址。你不想把A车的程序刷到B车去吧？
2. 读DTC（故障码）：可以用功能寻址。一次请求，所有ECU汇报故障，效率高。
3. 写VIN码：必须物理寻址。VIN是车辆唯一标识，不能乱写。
4. 读软件版本：功能寻址方便，但要注意总线负载。
5. 执行例程（Routine）：看情况。如果是“读取类”例程可以用功能寻址，“写入类”必须物理寻址。

最后说一句，CAN ID的分配不是随便定的。ISO 15765-2标准里其实有推荐值，但很多OEM会自己定义。我见过一个项目，OEM把物理请求ID定成0x700 + ECU编号，结果编号从1到32，ID范围0x701到0x720。嗯，这样也挺好，有规律，好排查。

好了，物理寻址和功能寻址的基础就讲到这里。下一章咱们聊聊诊断会话控制——怎么让ECU进入不同的工作模式。这个在实际调试中特别重要，你想想看，ECU在默认会话里很多诊断服务是不支持的，得先“敲门”才行。