第三章 自动驾驶域控制器简介：域控制器架构、典型功能模块、传感器与执行器接口
好，我们进入第三章。这一章，我想跟你聊聊域控制器本身。
说实话，很多刚入行的朋友容易把域控制器想得太神秘。觉得它就是个超级电脑，把传感器数据接进来，算一算，然后控制车子跑就行了。嗯，这个理解没错，但太粗糙了。你想想看，一个要保证功能安全的系统，它的架构设计、模块划分、接口定义，每一步都藏着坑。
我个人习惯，在开始做HARA分析之前，先把域控制器的“家底”摸清楚。你连它长什么样、里面有什么、怎么跟外界打交道都不知道，那后面的危害分析就是空中楼阁。
3.1 域控制器架构：从分布式到集中式
先聊聊架构演变。我记得2016年那会儿，我参与的一个L2项目，还是典型的分布式架构。一个ACC模块、一个LKA模块、一个APA模块，各自有独立的ECU，通过CAN总线通信。那时候做功能安全，每个ECU都要单独做HARA，工作量巨大，而且系统级的安全目标很难协调。
现在的域控制器，说白了就是把原来分散的功能集中起来。一个域控制器，接管了感知、决策、控制的大部分任务。这样做的好处很明显：
- 算力集中：一个高性能SoC，比一堆低性能MCU加起来还强
- 通信简化：内部高速总线，比外部CAN/LIN快得多
- 安全统一：安全机制可以集中设计，不用跨ECU协调
但集中也有集中的麻烦。我曾经遇到过一个项目，因为把所有功能都塞进一个域控，导致单个SoC的故障影响面太大，最后不得不做冗余设计。所以，架构选择是个权衡。
目前主流的域控制器架构，我把它分为三类：
| 架构类型 | 特点 | 典型应用 | 安全考量 |
|---|---|---|---|
| 单芯片集中式 | 一个SoC跑所有功能 | L2+、部分L3 | 单点故障风险高，需硬件冗余 |
| 主从式 | 主SoC+安全MCU | L3、L4 | 安全MCU负责监控和降级 |
| 双芯片冗余式 | 两个SoC互为备份 | L4、RoboTaxi | 完全冗余，成本高 |
关键点：做HARA时，架构类型直接决定了你分析的范围。单芯片架构，你重点分析SoC内部的故障模式；主从式架构，你还要分析主芯片和安全MCU之间的交互故障。
3.2 典型功能模块：域控的“五脏六腑”
一个典型的自动驾驶域控制器，内部有哪些模块？我把它拆成几个核心部分：
3.2.1 感知处理模块
这个模块负责处理摄像头、激光雷达、毫米波雷达的原始数据。说白了，就是把传感器看到的“像素点”和“点云”变成有意义的目标信息。
- 摄像头：ISP处理、目标检测、车道线识别
- 激光雷达：点云分割、目标聚类、障碍物检测
- 毫米波雷达：目标跟踪、速度估计
这里有个坑。我记得有一次，感知模块的ISP处理出了个bug，导致夜间场景下摄像头画面过曝，目标检测完全失效。这个故障在HARA分析里，属于“感知功能丧失”，安全等级直接ASIL D。
3.2.2 融合与决策模块
感知模块输出的是“候选目标”，融合模块要把不同传感器的结果对齐、关联，生成一个统一的“环境模型”。决策模块再基于这个模型，规划出车辆的行驶轨迹。
- 传感器融合：时间同步、空间对齐、目标关联
- 行为决策：换道、跟车、避障
- 路径规划：生成可行驶的轨迹
个人经验：融合模块的故障模式往往很隐蔽。比如时间同步偏差，可能导致感知结果错位，车辆误判障碍物位置。这种故障在HARA里，我通常会归类为“感知信息错误”，危害等级很高。
3.2.3 控制执行模块
决策模块规划好了轨迹，控制模块负责把它转化成具体的控制指令：油门、刹车、转向。这个模块直接跟执行器打交道，安全要求最高。
- 纵向控制：速度控制、跟车距离控制
- 横向控制：转向角度控制、车道保持
- 执行器接口：PWM、CAN、以太网
3.2.4 安全监控模块
这个模块是域控的“安全卫士”。它独立于主功能模块，负责监控系统状态，发现异常就触发降级或安全停车。
- 硬件监控：电压、温度、时钟
- 软件监控：任务超时、数据流检查
- 故障响应：降级、报警、安全停车
警告：安全监控模块本身也要做HARA！我曾经见过一个项目，安全监控模块的看门狗电路设计有缺陷，导致主芯片死机了，监控模块却没检测到。这个教训告诉我们，安全机制本身也可能失效。
3.3 传感器与执行器接口：域控的“手脚”
域控制器不是孤岛，它要跟外界打交道。传感器是它的“眼睛”和“耳朵”，执行器是它的“手脚”。接口设计的好坏，直接影响功能安全。
3.3.1 传感器接口
常见的传感器接口有：
| 传感器类型 | 接口类型 | 带宽需求 | 安全考量 |
|---|---|---|---|
| 摄像头 | GMSL、FPD-Link | 高（~2Gbps） | 数据完整性、线束故障 |
| 激光雷达 | 以太网 | 高（~1Gbps） | 数据延迟、丢包 |
| 毫米波雷达 | CAN、CAN-FD | 中（~1Mbps） | 信号干扰、数据错误 |
| 超声波雷达 | LIN、IO | 低（~20kbps） | 信号丢失、误触发 |
嗯，这里要注意。摄像头接口的GMSL线束，在整车布线中很容易受到电磁干扰。我有个项目，就是因为摄像头线束屏蔽没做好，导致高速行驶时画面出现雪花，目标检测频繁失效。后来我们在HARA里专门加了一条“摄像头线束EMC故障”的 hazard。
3.3.2 执行器接口
执行器接口相对简单，但安全要求极高。常见的执行器接口：
- 转向系统：CAN或FlexRay，控制转向角度
- 制动系统：CAN或PWM，控制制动压力
- 动力系统：CAN，控制油门开度
关键点：执行器接口的故障模式，最怕的是“非预期输出”。比如，制动指令是0%，但实际输出却是100%。这种故障在HARA里，通常直接归类为“非预期制动”，安全等级ASIL D。
3.3.3 接口故障的典型模式
我总结了一下，接口故障常见的几种模式：
- 数据丢失：传感器数据没传过来，或者执行器没收到指令
- 数据错误：数据传过来了，但内容不对（比如CRC校验失败）
- 数据延迟：数据来得太晚，导致控制指令滞后
- 数据重复：同样的数据传了两次，导致执行器重复执行
- 数据乱序：数据到达的顺序乱了，导致控制逻辑混乱
这些故障模式，在HARA分析里都要一一考虑。我个人习惯，会为每个接口单独建一个故障模式表，然后跟功能模块的故障模式做交叉分析。
3.4 小结
这一章，我们聊了域控制器的架构、功能模块和接口。你可能会觉得，这些内容跟HARA分析有什么关系？
关系大了。做HARA的第一步，就是识别系统的功能、模块和接口。你只有把域控的“家底”摸清楚了，才能知道哪些地方可能出故障，出了故障会有什么后果。
下一章，我们会正式进入HARA分析的核心流程。到时候，你会看到，我们这一章讲的所有内容，都会成为HARA分析的输入。
好，今天就到这里。有什么问题，欢迎在课程群里讨论。