2. 车载网络演进

车载电子电气架构（E/E Architecture）的演进，本质上是一场围绕“算力集中化”与“通信骨干化”的持续重构。理解这一演进脉络，是理解网关角色为何变化、以及S32G这类车载网关芯片为何成为关键节点的前提。本节从分布式ECU出发，梳理域集中式与中央计算架构的差异，并重点分析网关在不同阶段承担的角色与典型拓扑。

一、核心原理：三代架构的算力与通信逻辑

早期汽车采用分布式ECU架构：每个功能（车窗、座椅、车灯、发动机）由独立ECU控制，ECU之间通过CAN/LIN总线互联。这种架构的特点是“功能就近、算力分散”，线束长度可达数公里，ECU数量常超过100个。其优点是开发解耦、故障隔离简单；缺点是算力无法共享、软件升级困难、线束重量与成本高。

随着智能座舱、ADAS、OTA等需求出现，域集中式架构应运而生。整车按功能域划分为动力域、底盘域、车身域、座舱域、智驾域等，每个域由一个域控制器（Domain Controller）统一管理，域内ECU通过CAN/LIN/以太网接入域控，域间通过车载以太网骨干互联。算力开始向域控集中，软件可跨ECU协同。

进一步演进到中央计算架构：整车设置1~2个中央计算单元（HPC），配合若干区域控制器（Zonal Controller）按物理位置就近接入传感器与执行器。中央计算负责全局算力调度与软件定义功能，区域控制器负责I/O汇聚与供电。此时通信骨干以千兆/万兆车载以太网为主，CAN逐步下沉为末端执行网络。

二、网关角色的三次跃迁

在分布式阶段，网关的核心任务是协议转换与总线隔离：例如将CAN FD报文转换为LIN指令，或将诊断请求从OBD口路由到目标ECU。此时网关是“翻译官”，吞吐量要求低，功能相对单一。

进入域集中式阶段，网关升级为域间数据路由与安全边界。它需要处理CAN、CAN FD、LIN、FlexRay、车载以太网等多种协议，并承担防火墙、入侵检测、诊断路由、OTA分发等任务。此时网关的吞吐量、实时性与安全能力成为关键指标。

在中央计算架构下，网关进一步演化为区域网关或中央网关，承担“数据汇聚+协议转换+安全隔离+时间同步”四位一体职责。它需要支持TSN时间敏感网络、SOME/IP服务发现、DoIP诊断、MACsec安全链路等。S32G正是面向这一阶段设计的车载网络处理器，集成多路CAN、LIN、以太网交换与硬件安全引擎。

三、典型拓扑对比

下表对比三代架构在拓扑、通信、算力与网关角色上的差异，便于快速定位当前项目所处阶段。

四、场景案例：一次跨域诊断请求的路径

以“诊断仪读取智驾域摄像头故障码”为例，在域集中式架构中，请求路径如下：诊断仪通过OBD口发送DoIP请求 → 中央网关接收并解析 → 网关根据路由表将请求转发至智驾域控 → 域控查询摄像头ECU故障码 → 结果沿原路返回。网关在此过程中需完成协议转换（DoIP↔CAN FD）、访问控制（仅允许授权诊断）与日志记录。

诊断仪 --DoIP--> 中央网关
中央网关 --路由表匹配--> 智驾域控
智驾域控 --CAN FD--> 摄像头ECU
摄像头ECU --故障码--> 智驾域控 --> 中央网关 --> 诊断仪

若在中央计算架构下，该请求可能由区域控制器就近接入，再经TSN骨干转发至中央计算，由中央计算统一调度诊断服务。路径更短、时延更低，但对网关的时间同步与服务质量（QoS）要求更高。

五、误区与复盘

复盘建议：在架构选型时，先明确当前阶段的通信矩阵与算力需求，再评估网关的吞吐量、协议栈与安全能力。S32G等车载网络处理器可作为域集中式向中央计算过渡的桥梁，支持多协议并发与硬件安全加速，适合作为中央网关或区域网关的核心器件。

综上，车载网络演进的主线是“算力集中、通信骨干化、软件定义”。网关从协议转换器逐步升级为数据路由与安全中枢，其吞吐量、协议栈与安全能力直接决定架构落地的可行性。理解这一脉络，才能在设计S32G网关方案时做出合理的拓扑与资源分配决策。