3、DoIP协议核心概念：逻辑地址、物理地址、实体（Entity）与网关、激活线（Activation Line）、DoIP报文结构
好，我们直接进入正题。
这一章要讲的东西，是DoIP协议的骨架。你把这些概念吃透了，后面看代码就跟看小说一样顺。我个人习惯是把这些核心概念先理清楚，再动手写代码，否则很容易掉坑里。
3.1 逻辑地址 vs 物理地址
这两个地址，是DoIP里最容易搞混的东西。我刚开始接触时也绕了一阵子。
物理地址（Physical Address），说白了就是网卡的MAC地址。它是硬件层面的，全球唯一。在DoIP里，物理地址用于底层的数据链路层通信。你想想看，两个设备要通信，总得知道对方的网卡是谁吧？物理地址就是干这个的。
逻辑地址（Logical Address），这才是DoIP协议的核心。它是一个16位的数值，范围从0x0000到0xFFFF。逻辑地址是应用层用来标识诊断实体的。什么意思呢？就是诊断仪（Tester）和ECU之间互相认识，靠的是逻辑地址，不是物理地址。
举个例子。我在项目中遇到过一台网关，它下面挂了十几个ECU。每个ECU都有一个唯一的逻辑地址，比如0x1001、0x1002。诊断仪发请求时，报文里填的是逻辑地址，网关收到后，再根据逻辑地址把报文转发给对应的ECU。物理地址在这个过程中，只是底层传输的“快递员”，逻辑地址才是“收件人姓名”。
关键点：
- 物理地址：MAC地址，硬件绑定，用于链路层
- 逻辑地址：16位数值，软件定义，用于应用层诊断
- 诊断仪和ECU之间，通过逻辑地址建立会话
我的经验： 调试时，如果发现诊断仪连不上ECU，先别急着查协议栈。先确认逻辑地址对不对。我曾经花了一整天，最后发现是逻辑地址写反了——诊断仪填了自己的逻辑地址，而不是目标ECU的。嗯，这种低级错误，犯过一次就记住了。
3.2 实体（Entity）与网关
DoIP协议里，实体（Entity）是一个抽象概念。它指的是一个能够处理DoIP报文的设备或功能单元。一个实体可以是一个ECU，也可以是一个网关，甚至可以是诊断仪本身。
实体分为两种：
- DoIP实体：直接支持DoIP协议的设备。比如一个支持以太网诊断的ECU。
- DoIP网关：它本身是一个实体，但它的作用是转发诊断请求到其他网络（比如CAN、LIN）。
网关在DoIP里特别重要。为什么？因为现在的汽车电子架构，基本都是域控制器+网关的模式。你想想看，诊断仪通过以太网连到网关，网关再通过CAN或FlexRay去访问其他ECU。网关在这里扮演了“翻译官”和“路由器”的角色。
我记得有一次做项目，客户要求诊断仪能通过DoIP访问CAN总线上的一个老式ECU。那个ECU根本不支持以太网。怎么办？网关上场了。网关收到DoIP请求后，把UDS诊断报文从以太网格式转换成CAN格式，再发出去。返回的响应再反向转换。整个过程对诊断仪来说是透明的——它只知道自己发了一个DoIP请求，收到了一个DoIP响应。
实体与网关的关系：
- 每个DoIP实体都有一个唯一的逻辑地址
- 网关也是一个实体，但它可以代理其他网络上的ECU
- 网关需要维护一个路由表，记录逻辑地址和物理通道的映射
避坑指南： 我曾经在实现网关时，忘记处理路由表的超时刷新。结果诊断仪换了一个ECU诊断，网关还拿着旧的路由信息，报文直接发丢了。嗯，从那以后，我每次都会给路由表加一个定时刷新机制。
3.3 激活线（Activation Line）
激活线，这个名字听起来有点玄乎。其实它就是一个硬件引脚，或者一个软件信号，用来告诉DoIP实体：“嘿，该干活了！”
在ISO 13400标准里，激活线的作用是控制DoIP实体的网络状态。具体来说：
- 激活线为高电平时，DoIP实体进入正常工作模式，可以接收和发送DoIP报文
- 激活线为低电平时，DoIP实体进入休眠或低功耗模式，不处理DoIP报文
你可能会问：“为什么需要这个？直接上电不就完了？”
原因很简单——省电。汽车电子对功耗要求很严。ECU不能一直开着以太网接口，那太费电了。激活线的作用就是让ECU在需要诊断时才“醒过来”。
我在实际项目中，激活线通常由网关或车身控制器来控制。诊断仪要开始诊断时，先通过某种方式（比如CAN报文）通知网关：“我要开始诊断了”。网关收到后，拉高对应ECU的激活线。ECU醒来，开始处理DoIP报文。诊断结束后，网关再拉低激活线，ECU继续睡觉。
实现细节： 激活线不一定非得是硬件引脚。有些设计里，激活线是通过一个特殊的DoIP报文来实现的，叫“激活请求”（Activation Request）。诊断仪发送这个报文，ECU收到后自动进入激活状态。我个人更推荐硬件激活线，因为它更可靠，不容易被软件bug干扰。
3.4 DoIP报文结构
终于到了报文结构。这是写代码时直接面对的东西，必须烂熟于心。
DoIP报文分为两个部分：头部（Header）和负载（Payload）。头部固定8个字节，负载长度可变。
先看头部结构：
| 字节偏移 | 字段名 | 长度（字节） | 说明 |
|---|---|---|---|
| 0 | 协议版本 | 1 | 当前固定为0x02（ISO 13400-2:2012） |
| 1 | 反向协议版本 | 1 | 协议版本的取反，用于校验 |
| 2-3 | 负载类型 | 2 | 标识报文类型，如0x0001是路由激活请求 |
| 4-7 | 负载长度 | 4 | 后面负载的字节数，大端序 |
负载部分，根据负载类型不同，结构也不同。常见的负载类型有：
- 0x0001：路由激活请求/响应
- 0x0002：诊断报文（UDS over DoIP）
- 0x0003：诊断报文确认
- 0x0004：DoIP实体状态请求/响应
- 0x0005：DoIP实体电源模式请求/响应
举个例子，一个诊断报文的DoIP帧长什么样：
// DoIP头部（8字节）
0x02 // 协议版本
0xFD // 反向协议版本（0x02取反）
0x00 0x02 // 负载类型：诊断报文
0x00 0x00 0x00 0x0A // 负载长度：10字节
// 负载（10字节）
0x0E 0x80 // 源逻辑地址（诊断仪）
0x10 0x01 // 目标逻辑地址（ECU）
0x22 0xF1 0x86 0x01 0x02 0x03 // UDS诊断请求（读取数据）注意： 负载长度字段是4字节，但实际DoIP报文的最大负载长度是65535字节（2^16-1）。为什么用4字节？这是为了兼容未来扩展。目前只用低2字节，高2字节填0。
我在写DoIP协议栈时，解析报文的第一步就是校验头部。先检查协议版本和反向版本是否匹配，再检查负载长度是否合理。如果头部校验不通过，直接丢弃报文，不处理。这样可以防止很多恶意攻击或错误报文。
避坑指南： 我曾经在实现时，忘记处理负载长度字段的大端序。结果在x86小端机器上测试，长度解析出来全是错的。嗯，从那以后，我每次解析多字节字段都会加一个ntohl()或手动转换。别偷懒，该转换就转换。
3.5 小结
这一章的内容，说白了就是DoIP协议的“身份证”和“通信规则”。
- 逻辑地址是应用层的身份标识，物理地址是底层的硬件标识
- 实体是处理DoIP报文的设备，网关是连接不同网络的桥梁
- 激活线控制ECU的唤醒和休眠，省电的关键
- 报文结构固定8字节头部+可变负载，解析时注意字节序和校验
下一章，我们会开始动手写代码。从最简单的DoIP实体初始化开始，一步步搭建协议栈。准备好了吗？