4、异构网络网关架构：网关在CAN与DoIP之间的角色、路由策略
好，咱们进入第四讲。这一章我打算聊聊网关——这个在CAN和DoIP之间“两头受气”的家伙。
说实话，我在做网关设计之前，一直觉得它就是个“翻译官”。把CAN报文转成以太网报文，再转回来，完事。但真正上手之后才发现，事情远没那么简单。网关的角色，说白了就是一个“异构网络的交通警察”。它不仅要懂两边的“交通规则”，还得在关键时刻做出正确的路由决策。
4.1 网关的核心角色：不只是“桥”
网关在CAN与DoIP之间，扮演着三个关键角色：
- 协议转换器：把CAN的帧格式转成DoIP的TCP/UDP报文。这个最基础，但坑最多。
- 诊断会话管理器：维护两边的诊断会话状态。CAN那边可能还在用传统的“请求-响应”模式，DoIP这边已经支持并行请求了。怎么对齐？嗯，这是个问题。
- 安全网关：DoIP那边可能来自外部诊断仪，CAN这边是车内网络。网关必须做访问控制，不能什么报文都往里放。
我个人习惯：把网关看作一个“三明治”。上层是DoIP协议栈，下层是CAN协议栈，中间夹着一层路由逻辑。这层路由逻辑，才是网关的灵魂。
4.2 路由策略：物理路由 vs 逻辑路由
路由策略这块，我见过不少团队踩坑。咱们分两种来说。
4.2.1 物理路由：简单粗暴，但够用
物理路由，说白了就是“看接口办事”。网关收到一个DoIP报文，根据报文里的目标地址，直接映射到某个CAN接口上。
举个例子：
// 物理路由伪代码
if (doip_message.target_address == 0x100) {
// 目标ECU在CAN1总线上
forward_to_can_bus(doip_message, CAN_BUS_1);
} else if (doip_message.target_address == 0x200) {
// 目标ECU在CAN2总线上
forward_to_can_bus(doip_message, CAN_BUS_2);
}这种方式的优点很明显：实现简单，延迟低。但缺点也很致命——灵活性差。你想想看，如果某个ECU从CAN1挪到了CAN2，网关的配置就得跟着改。
避坑指南：我曾经在一个项目中，因为物理路由配置写死了，导致产线上换了一个ECU位置，整个网关固件都得重新刷。后来我学乖了，所有物理路由都做成可配置的，放在NVM里。
4.2.2 逻辑路由：灵活，但复杂
逻辑路由就不一样了。它不看物理接口，而是看报文里的“逻辑地址”或“服务标识”。网关内部维护一张路由表，把逻辑地址映射到目标网络。
比如这样：
// 逻辑路由伪代码
route_table = {
0x100: { target_bus: CAN_BUS_1, service_filter: [0x10, 0x22] },
0x200: { target_bus: CAN_BUS_2, service_filter: [0x19, 0x2E] },
0x300: { target_bus: DOIP, service_filter: [0x10, 0x11] }
};
if (route_table.contains(doip_message.logical_address)) {
route_entry = route_table[doip_message.logical_address];
if (route_entry.service_filter.contains(doip_message.service_id)) {
forward_to_bus(doip_message, route_entry.target_bus);
} else {
reject_message(doip_message, "Service not allowed");
}
}逻辑路由的好处是：ECU换位置了，只需要更新路由表，不用改代码。而且可以做更精细的访问控制——比如只允许某些诊断服务通过。
但代价呢？延迟会高一些，因为每次都要查表。而且路由表的管理是个麻烦事，搞不好就成了“配置地狱”。
4.3 路由策略的选择：什么时候用哪个？
我个人的经验是：
| 场景 | 推荐策略 | 原因 |
|---|---|---|
| CAN网络内部路由 | 物理路由 | CAN网络结构相对固定，物理路由延迟低 |
| CAN到DoIP的路由 | 逻辑路由 | DoIP那边地址空间大，逻辑路由更灵活 |
| 多网关级联场景 | 逻辑路由 | 需要跨网关寻址，物理路由搞不定 |
| 安全要求高的场景 | 逻辑路由+服务过滤 | 可以精确控制哪些服务能通过 |
注意：别把两种策略混在一起用。我见过一个项目，物理路由和逻辑路由同时生效，结果报文被转了两次，直接死循环了。要么全物理，要么全逻辑，别搞“混合模式”。
4.4 网关的“避坑”经验
最后，分享几个我在项目中踩过的坑：
- 超时处理：CAN那边响应慢，DoIP那边等不了。网关必须做超时管理，别让DoIP那边一直挂着。
- 报文分片：DoIP报文可能很大，但CAN帧只有8字节。网关得做好分片和重组。我曾经因为分片ID没处理好，导致两个诊断请求的数据混在一起了。
- 会话同步：CAN和DoIP的会话状态要同步。比如DoIP那边发了个“停止通信”，网关得确保CAN那边也退出诊断模式。
嗯，网关这块内容其实挺多的。今天咱们先聊到这，下一章我会讲讲具体的实现细节——包括怎么处理并发请求、怎么优化延迟。到时候再细聊。