📚 课程目录第1章汽车电子电气架构演进

1. 汽车电子电气架构演进：从分布式到集中式，网关角色的演变与定位

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

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

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

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

  核心观点： 网关的复杂度，直接反映了整车电气架构的进化阶段。搞懂架构演进，你才能设计出“不过时”的网关。

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

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

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

避坑指南： 我曾经在分布式架构项目中吃过亏——以为网关只是“透传”信号，结果忽略了不同 CAN 网络之间的时钟漂移。两个网络采样点不一致，导致信号丢帧。后来我养成了一个习惯：只要涉及跨网络信号路由，必须做信号级延迟预算。

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

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

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

我的习惯： 在域集中式架构下，我建议把网关的软件分成三层：驱动层（处理物理总线差异）、路由层（做信号级转发）、服务层（处理诊断、OTA、安全策略）。这样每层可以独立演进，不会牵一发动全身。

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

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

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

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

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

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

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

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

我的建议： 如果你现在开始设计一个新网关，直接按中央集中式架构的需求来规划硬件资源。哪怕当前项目还是域集中式，也要预留足够的算力和接口。因为架构演进的速度，比你想象的要快得多。

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

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