2. 汽车电子电气架构基础

车载网络安全验证与审计的所有工作，最终都要落到具体的电子电气架构上。不理解报文从哪个 ECU 发出、经过哪条总线、由哪个网关转发、最终被哪个域控制器消费，就无法判断一条异常报文是真实攻击、功能故障，还是正常的跨域通信。本章从节点、总线、网关到架构演进，建立后续验证与审计工作的“地图”。

一、核心对象：从 ECU 到区域架构

ECU（电子控制单元）是车载网络的最小功能节点，通常由微控制器、电源管理、收发器和外围驱动组成。它既产生信号，也消费信号，是安全验证中最基本的被审计对象。ECU 的安全属性包括：固件是否签名、诊断接口是否鉴权、报文发送是否有速率限制、是否存在可被刷写的调试口。

总线是节点之间的通信介质。不同总线在速率、拓扑、确定性和成本上差异明显：

• CAN：多主、广播、基于 ID 仲裁，速率常见 125 kbit/s～1 Mbit/s，是动力、车身、底盘的主力总线。
• LIN：单主多从、低成本、低速率（最高 20 kbit/s），用于车窗、座椅、雨刮等非关键执行器。
• FlexRay：时间触发 + 事件触发，速率 10 Mbit/s，具备双通道冗余，用于线控转向、主动悬架等高确定性场景。
• 车载以太网：100BASE-T1 / 1000BASE-T1，支持 IP 通信，是摄像头、激光雷达、域控制器和 OTA 的主干。

网关负责在不同总线之间转发、过滤和路由报文，是跨域通信的咽喉，也是安全审计的关键观测点。域控制器按功能域（动力、底盘、座舱、智驾）集中算力，替代大量分散 ECU。区域架构则进一步按物理位置（前、后、左、右）划分区域控制器，通过以太网主干连接，就近接入本地节点，减少线束长度和重量。

二、方法流程：如何从架构推导验证范围

安全验证不是“把所有总线都抓一遍”，而是从架构出发确定边界和优先级。推荐流程如下：

1. 绘制通信矩阵：列出每条总线的报文 ID、周期、发送节点、接收节点、信号含义。
2. 识别跨域路径：标记哪些报文经过网关、哪些经过以太网交换机、哪些进入域控制器。
3. 确定信任边界：把网关、域控、区域控制器、诊断接口、OTA 通道作为信任边界。
4. 选择观测点：在边界处部署抓包、镜像或日志采集，形成可审计的数据源。
5. 建立基线：记录正常状态下的报文周期、负载分布、源地址集合，作为异常检测参照。

三、案例场景：一条异常报文的跨域追踪

假设某车型在路试中出现“车门偶发误锁”。安全工程师从区域控制器日志中发现一条异常 CAN 报文，ID 为 0x2A1，周期由正常的 100 ms 变为 20 ms，负载中门锁控制位被反复置位。追踪过程如下：

观测点1：左区域控制器本地 CAN
  0x2A1 周期 20ms  DLC=8  数据 01 00 00 00 00 00 00 00
  正常基线：周期 100ms，数据 00 ...

观测点2：区域控制器到以太网主干
  未发现对应 SOME/IP 服务调用，说明报文未按预期上报

观测点3：中央网关路由表
  0x2A1 被配置为“本地消费”，不应跨域转发

结论：异常报文来自本地子网内某个被篡改节点，
      且该节点绕过了区域控制器的过滤逻辑。

这个案例说明：架构知识直接决定排查路径。如果不知道 0x2A1 是本地消费报文，就可能误判为网关转发攻击；如果不知道区域控制器的过滤规则，就无法定位绕过点。

四、常见误区与复盘

五、架构对象与安全关注点清单