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

1：基本概念

诊断物理寻址：物理地址是针对网络中具体的ECU。

功能寻址：是针对网络中多个或所有ECU。（准确来说是功能请求报文的ID对应多个ECU）

      如一个车身域网络中，存在3个ECU，（车身域控制器，娱乐系统域控制器，远程网络系统域控制器），我们需要分别为这三个控制器分配三个物理诊断寻址。

1：如0x618(请求报文ID)=车身 ，0x658服务器应答报文ID

2：0x628 (请求报文ID)=娱乐,  0x668服务器应答报文ID

3：0x638(请求报文ID) = 远程网络,  0x678服务器应答报文ID

对这三个ECU，我们还能设定一个，针对所有三个ECU报文的请求报文,如

0x 668（功能寻址ID）, 在网络中用0x 668报文发出请求报文，三个ECU都要接受，并处理这个请求信息。（对于是否应答？这么应答？则要根据具体情况来定）。

2：为什么要设计功能寻址

本人都是在零部件供应商打工的，一开始接触到功能寻址时，觉得非常难以理解，这不是脱裤子放屁，有了物理寻址还搞出一个功能寻址，不是多此一举吗？

直到我接触了，主机厂的整车联调，后我才明白功能寻址的意义，假设有如下场景。整车上，我们

**场景1）需要对某个ECU进行刷写（bootload操作）。

因为刷写（bootload操作），需要两个前提：

1；关闭网络上的所有通讯

2：刷写（bootload操作）具体ECU的过程中，会对被刷写（bootload操作）产生干扰，导致误报DTC

对应的解决方法，调用uds中的0x28（通讯控制），和0x85（DTC控制）服务。

如果依然采用物理寻址，一个个去设置，显得麻烦，实际车上，一个网络上会挂载10个以上的ECU，如果采用物理寻址的方法，一个个设置，就非常麻烦和低效。

如果采用功能寻址，就很方便了。

**场景2）整车读取某些数据0x22服务

需要说明：uds设计过程中，没有要求DID或参数的唯一性要求，如;F1 98 在ECU1中可以用来读取，软件版本。在ECU2中同样也可以。

于是主机厂的工程师们，只要采用功能寻址，发送一条DID为 F1 98的报文，就可以读取网络中所有ECU的软件版本。

注意：客户端client 采用功能寻址 时，不同的ECU采用物理回复的ID，进行回复

如：诊断客户端   0x 668 03 22 F1 98

          ECU1应答：0x658 07 62 F1 98 90 90 90 90(90就是对应ascil码的软件版本)

          ECU2应答：0x668 07 62 F1 98 91 91 91 91(91就是对应ascil码的软件版本)

          ECU3应答：0x678 07 62 F1 98 92 92 92 92(92就是对应ascil码的软件版本)

需要注意的是：ECU回复依然是采用的是，物理地址回复。