1. 课程导入

1.1 为什么我们要聊架构演进？

做网关设计，不能只盯着芯片和协议栈。你得先搞清楚——这个网关到底要放在什么样的电气架构里？

我入行那会儿，车上能有 30 多个 ECU 就算豪华车了。每个 ECU 管自己的事：车窗、门锁、雨刮、灯光……各玩各的。那时候的网关，说白了就是个“信号搬运工”。

但现在不一样了。一辆智能电动车，ECU 数量轻松破百，软件代码量上亿行。你想想看，如果还是每个节点各自为政，线束重量能赶上一个小型发动机。

所以，架构必须变。网关的角色也必须跟着变。

1.2 分布式架构：网关的“石器时代”

早期的分布式架构，每个功能对应一个独立 ECU。比如一个车身控制模块只管车窗，另一个只管门锁。它们之间通过低速 CAN 总线（如 CAN 2.0B，125kbps~500kbps）通信。

网关呢？就是一个简单的路由节点。它把 CAN 网络上的信号，原封不动地搬到另一个 CAN 网络上。没什么复杂的逻辑，也没什么安全策略。

我记得有一次调试一个车身网络问题，发现车窗和门锁的信号居然走了两条不同的 CAN 路径，导致门锁解锁后车窗要延迟 200ms 才能降下来。这种问题在分布式架构里特别常见——信号路径长，延迟不可控。

1.3 域集中式架构：网关开始“长脑子”

大概 2015 年以后，行业开始往域集中式走。整车被划分为几个功能域：动力域、底盘域、车身域、信息娱乐域、自动驾驶域。每个域有一个高性能的域控制器（Domain Controller），它接管了该域内所有 ECU 的逻辑。

这时候的网关，不再是简单的“信号搬运工”了。它变成了一个“域间路由器”。

• 路由策略复杂了： 不再是简单的 ID 映射，而是基于信号的路由。网关需要解析报文内容，判断哪些信号需要跨域转发。
• 安全要求上来了： 自动驾驶域和动力域的信号，不能随便让信息娱乐域读到。网关必须做防火墙和访问控制。
• 带宽需求暴涨： CAN 不够用了，开始引入 CAN FD（最高 8Mbps）和车载以太网（100BASE-T1 / 1000BASE-T1）。

我参与过一个项目，网关需要同时处理 6 路 CAN FD 和 2 路以太网。那时候我才意识到，网关的软件架构必须重新设计——不能再跑裸机了，得上 RTOS，甚至需要多核异构方案。

1.4 中央集中式架构：网关“消失”了？

到了 2020 年以后，特斯拉、华为、蔚来这些新势力开始推中央集中式架构。整车只有一个或两个超级计算中心（如 Vehicle Computer / Central Compute Platform），所有传感器和执行器都通过区域控制器（Zone Controller）接入。

这时候，传统的“网关”概念其实已经模糊了。中央计算平台内部通过 PCIe 或高速以太网通信，区域控制器只做 I/O 聚合和电源分配。网关的功能被拆解了：

• 路由功能 → 由中央计算平台的软件定义网络（SDN）模块完成
• 安全策略 → 由中央计算平台的 Hypervisor 和防火墙统一管理
• 协议转换 → 由区域控制器的通信协处理器完成

但注意，网关并没有真正“消失”。它只是从一个独立的硬件盒子，变成了一个逻辑功能单元，分布在中央计算平台和区域控制器中。

你想想看，如果网关完全消失了，那不同总线之间的信号怎么对齐？不同安全域之间的数据怎么隔离？OTA 刷写时，怎么保证不会把动力域的固件刷到信息娱乐域去？

所以，我的观点是：网关的形态变了，但它的核心职责——隔离、路由、安全、诊断——永远不会消失。

1.5 网关角色的演变总结

下面这张图，是我自己总结的网关角色演变路径。你可以把它当作一个快速参考。

1.6 对网关设计的影响

搞清楚了架构演进，你就能回答一个关键问题：我设计的网关，到底要满足哪些需求？

我列了一个清单，你可以对照着看：

1. 多协议支持： 从 CAN/LIN 到 CAN FD/以太网，甚至 FlexRay 和 MOST，你的网关必须能“说多种语言”。
2. 实时性保证： 动力域和自动驾驶域的信号，延迟必须控制在微秒级。网关不能成为瓶颈。
3. 安全隔离： 不同安全域之间必须做硬件级隔离，不能靠软件“假装”隔离。
4. OTA 能力： 网关本身要支持远程升级，还要能管理其他 ECU 的刷写流程。
5. 诊断与日志： 网关是整车网络的“交通警察”，必须能记录异常流量，支持 UDS 诊断。

1.7 本章小结

嗯，这一章我们聊了不少。从分布式到域集中，再到中央集中，网关的角色一直在变。但它的核心职责——隔离、路由、安全、诊断——始终没变。

我个人觉得，做网关设计最忌讳的就是“只盯着眼前的需求”。你设计的网关，至少要能支撑未来 3~5 年的架构演进。否则，等架构一升级，你的网关就成了那个“拖后腿”的瓶颈。