1. 课程导入与平台认知

在传统分布式电子电气架构中，一辆车往往分布着几十甚至上百个 ECU，每个 ECU 负责一个或少数几个功能，通过 CAN、LIN、FlexRay 等总线互联。随着智能座舱、辅助驾驶、整车 OTA 和区域控制需求的增长，这种"一功能一控制器"的模式在算力利用率、线束重量、软件迭代效率上逐渐触及天花板。NXP S32 中央计算平台正是面向这一转折点推出的车规级计算与网络通信基础平台，它把原本分散的算力、网关与通信能力收敛到少数高性能计算节点和区域控制器中，形成"中央计算 + 区域接入"的分层架构。

理解 S32 平台，首先要区分它不是一个单一芯片，而是一个覆盖多档算力与多类通信外设的产品家族。S32K 系列面向车身、区域控制等实时控制场景，强调低功耗与功能安全；S32G 系列是车载网络与网关的核心，集成多路 CAN/CAN FD、LIN、FlexRay、车载以太网以及硬件安全引擎 HSE，承担跨域数据路由与安全通信；S32R 面向雷达信号处理；S32Z/S32E 则面向高实时域控与安全计算。在中央计算架构中，S32G 常作为中央网关或区域网关，向上通过千兆车载以太网连接中央计算单元，向下通过 CAN FD、LIN 连接末端节点，形成"以太网骨干 + CAN 边缘"的混合网络。

从架构演进看，可以把它划分为三个阶段。第一阶段是分布式架构，功能与 ECU 一一对应，通信以 CAN 为主，信号以广播方式在总线上传输，任何功能升级都依赖对应 ECU 的刷写。第二阶段是域集中架构，按动力、底盘、座舱、智驾等域划分域控制器，域内通信仍以 CAN/LIN 为主，域间通过以太网骨干互联，网关承担协议转换与路由。第三阶段是中央计算 + 区域架构，中央计算单元负责跨域融合与高算力任务，区域控制器负责就近接入与供电，S32G 类网关芯片在区域控制器中完成 CAN FD 与以太网的汇聚和转发。这一演进直接决定了车载网络与服务通信工程的学习重点：不再只是"配一个 CAN 报文"，而是要在多协议、多网络、面向服务的通信框架下完成端到端设计。

上图给出了 S32 平台在中央计算架构中的典型位置：中央计算单元位于顶层，通过千兆车载以太网骨干连接各区域控制器；区域控制器以 S32G 为核心，向下汇聚 CAN FD、LIN 等边缘网络，并集成 HSE 硬件安全引擎完成安全启动、密钥管理和安全通信。末端节点包括车身、动力、座舱、底盘等控制器以及诊断接口。右侧的三层学习地图对应本课程的组织逻辑：先认识芯片与平台，再掌握车载网络，最后进入面向服务的通信工程。

在车载网络层面，需要重点掌握几类通信技术。CAN FD 在传统 CAN 基础上把数据场扩展到 64 字节，并支持更高的数据段速率，典型配置为仲裁段 500 kbit/s、数据段 2 Mbit/s，适合车身与动力等实时控制信号。车载以太网以 100BASE-T1 和 1000BASE-T1 为主，采用单对双绞线，支持全双工，是骨干网络的首选。TSN（时间敏感网络）在以太网上提供确定性传输，通过 gPTP 时间同步、时间感知整形和帧抢占等机制，保证音视频流与控制指令的时延上界。S32G 的以太网交换与路由模块需要在这些协议之间完成转发、优先级映射和 VLAN 隔离。

在服务通信层面，SOME/IP 是面向服务的车载中间件协议，它把功能抽象为服务，通过服务发现（SOME/IP-SD）让客户端动态找到服务端，再以方法调用、事件通知和字段访问三种方式交互。例如，一个"车窗控制"服务可以暴露 MoveWindow 方法、WindowStatus 事件和 Position 字段，客户端通过服务发现获得服务实例的 IP、端口和实例 ID 后发起调用。DDS 则更多用于智驾与高吞吐场景，提供以数据为中心的发布订阅模型。UDS 诊断通过 DoIP 在以太网上传输，用于故障读取、刷写和例程控制。OTA 服务则把升级包分发、版本校验、回滚策略整合为端到端流程。

本课程后续将围绕三条主线展开。第一条是平台认知线，包括 S32K/G/Z 的选型依据、启动流程、时钟与电源设计、功能安全机制。第二条是网络工程线，包括 CAN FD 位定时计算与采样点设置、以太网 PHY 与交换配置、TSN 时间同步与流量调度、网关路由表设计。第三条是服务通信线，包括 SOME/IP 服务接口定义、服务发现配置、DDS 主题设计、UDS 诊断服务实现以及 OTA 升级流程。三条线并非孤立，而是通过 S32G 这一核心节点交汇：芯片提供通信外设与安全能力，网络承载数据流，服务通信定义数据语义与交互方式。