2. 车载系统基础
车载安全运营的第一步，是理解“车”本身是如何被电子系统组织起来的。与通用IT系统不同，汽车是一个强实时、强安全、强约束的分布式嵌入式系统：动力、制动、转向、座舱、智驾、诊断、OTA等能力分散在几十到上百个电子控制单元（ECU）中，通过多种总线与网络协同工作。安全运营人员若不了解这些结构，就无法判断一条异常报文究竟来自传感器、网关、域控制器还是诊断接口，也无法评估一次入侵对整车功能安全的影响范围。
一、电子电气架构：从分布式到集中式
汽车电子电气架构（E/E Architecture）决定了ECU如何分布、如何通信、如何供电以及如何被诊断。传统架构是“分布式”：每个功能对应一个ECU，例如车窗、座椅、雨刮、发动机、ABS各自独立，通过CAN/LIN总线互联。随着智能座舱与自动驾驶发展，ECU数量激增，线束复杂、算力分散、升级困难，于是架构向“域集中”和“中央集中”演进。
典型演进路径为：分布式ECU → 域控制器（Domain Controller）→ 中央计算平台+区域控制器（Zonal Controller）。域控制器按功能域划分，如动力域、底盘域、车身域、座舱域、智驾域；区域控制器则按物理位置划分，负责就近接入与配电。对安全运营而言，架构越集中，攻击面越集中，但可观测点也更清晰：网关、域控、中央计算平台和OTA通道成为关键监测节点。
核心判断：安全事件的影响范围，往往由“该ECU挂在哪个域、经过哪些网关、是否具备OTA与诊断能力”决定，而不是由漏洞本身单独决定。
二、ECU：车载安全的最小功能单元
ECU由微控制器、存储器、输入输出接口、通信控制器和电源管理组成，运行固件并执行特定控制逻辑。安全运营关注ECU的四个层面：
- 固件与刷写：Bootloader、应用固件、标定数据是否被篡改，刷写是否经过签名校验。
- 通信：ECU收发的CAN/LIN/FlexRay/以太网报文是否合法，是否存在伪造、重放、洪泛。
- 诊断：UDS诊断服务（如0x27安全访问、0x2E写数据、0x31例程控制）是否被滥用。
- 资源：CPU、内存、总线负载是否异常，是否出现拒绝服务或降级。
在事件响应中，ECU通常无法像服务器一样安装Agent，因此监测依赖网关镜像、总线记录仪、诊断日志和域控日志。安全人员需要建立“ECU资产台账”，记录其所属域、总线类型、诊断地址、固件版本和刷写权限。
三、CAN/LIN/FlexRay：经典车载总线
CAN是应用最广的车载总线，采用广播式、多主、优先级仲裁机制，报文ID越小优先级越高。CAN帧没有源地址，只有ID和数据，因此伪造与重放门槛低。安全运营常见异常包括：同一ID高频发送、周期突变、数据场越界、诊断ID异常出现。
LIN是低成本单主多从总线，常用于车窗、雨刮、空调等低速车身控制，速率通常低于20kbps，安全关注点在于主节点被篡改后从节点被批量控制。
FlexRay用于高实时、高可靠场景，如线控底盘、主动悬架，采用时间触发与静态/动态段，具备冗余通道。其安全价值在于确定性，但配置复杂，若调度表被篡改，可能导致关键控制失效。
CAN异常监测示例（伪日志）：
[10:22:31.120] CAN1 ID=0x0C9 DLC=8 DATA=00 00 00 00 00 00 00 00 周期=10ms 正常
[10:22:31.130] CAN1 ID=0x0C9 DLC=8 DATA=FF FF FF FF FF FF FF FF 周期=1ms 异常：高频+数据突变
[10:22:31.131] CAN1 ID=0x7DF DLC=8 DATA=02 27 01 00 00 00 00 00 异常：诊断请求出现在动力总线
四、车载以太网与SOA：面向服务的车载网络
车载以太网（如100BASE-T1、1000BASE-T1）提供高带宽、全双工、点对点通信，支撑摄像头、激光雷达、OTA和域控间数据交换。与CAN不同，以太网可承载IP协议栈，因此会引入ARP、DHCP、TCP/UDP、TLS、SOME/IP、DDS等协议，攻击面更接近IT系统，但实时性与功能安全约束更强。
SOA（面向服务架构）将功能封装为服务，通过SOME/IP或DDS进行服务发现与调用。例如“车门状态服务”“空调控制服务”“智驾感知服务”。SOA提升了软件复用与OTA灵活性，但也带来新的风险：未授权服务发现、服务接口滥用、中间人篡改、服务拒绝。安全运营需要监测服务注册、服务调用频率、接口参数合法性和跨域调用链。
五、域控制器与中央计算：安全监测的关键节点
域控制器通常运行Linux/QNX/Android等操作系统，具备较强算力与网络能力，是安全监测的理想位置。它可采集CAN、以太网、诊断和OTA日志，执行入侵检测规则，并与云端安全运营中心联动。中央计算平台则进一步集中算力，形成“车端SOC+云端SIEM”的协同监测模式。
下表给出典型车载网络与安全监测要点对比：
| 网络/对象 | 典型速率 | 典型场景 | 安全监测要点 |
|---|---|---|---|
| CAN | 125k~1Mbps | 动力、底盘、车身 | ID周期、数据突变、诊断滥用、总线负载 |
| LIN | <20kbps | 车窗、雨刮、空调 | 主节点异常、从节点批量响应 |
| FlexRay | 10Mbps | 线控、主动悬架 | 调度表、冗余通道、静态段异常 |
| 车载以太网 | 100M~1Gbps | 智驾、座舱、OTA | ARP欺骗、SOME/IP滥用、TLS异常、流量突增 |
| 域控制器 | — | 域集中计算 | 进程异常、服务注册、跨域调用、日志完整性 |
六、案例与误区复盘
案例：某车型在售后诊断接口被插入第三方设备后，攻击者通过UDS安全访问绕过校验，向车身域控制器写入异常标定，导致车窗在行驶中自动下降。安全运营通过网关日志发现诊断ID 0x7DF在非诊断时段高频出现，且0x27服务连续失败后成功，最终定位到诊断接口未做访问控制。
常见误区：
- 只关注CAN，忽略以太网与SOA服务调用，导致智驾域事件无法发现。
- 把ECU当作“黑盒”，没有资产台账，事件发生时无法快速定位影响范围。
- 认为域控制器集中后更安全，却未对域控自身进程与服务做监测。
- 只依赖云端日志，忽略车端实时检测，导致响应延迟超过功能安全容忍时间。
运营建议：建立“网络—ECU—域—服务”四层资产模型；在网关和域控部署轻量级检测规则；对诊断、OTA、服务发现三类高价值通道单独审计；将总线异常与云端告警关联，形成车端发现、云端研判、车端处置的闭环。
理解上述架构与总线后，安全运营才能把“异常报文、异常诊断、异常服务调用、异常固件”映射到具体ECU与域，进而判断影响范围、响应优先级和处置手段。这是后续入侵检测、事件响应与取证分析的基础。