第二章：系统架构总览——自动驾驶的“骨架”与“血脉”
大家好，我是你们这趟自动驾驶之旅的向导。今天咱们聊点硬核的——系统架构总览。
说实话，我见过不少新人，一上来就扎进感知算法里，调模型调得昏天黑地。结果呢？一上路就出问题。为什么？因为没搞懂整个系统是怎么串起来的。你想想看，自动驾驶不是单点技术，它是一个系统工程。就像盖房子，你不能只盯着砖头好不好看，得先看地基和框架稳不稳。
这一章，我就带你把这个“骨架”和“血脉”捋清楚。咱们从三个核心模块讲起：感知、决策、控制。然后聊聊数据流和信号流怎么跑，最后看看硬件和软件是怎么分层的。
2.1 核心模块：感知、决策、控制
自动驾驶系统，说白了就干三件事：看路、想路、走路。对应到技术上，就是感知、决策、控制。
2.1.1 感知模块——车的“眼睛”和“耳朵”
感知模块负责从传感器数据里提取有用信息。它要回答一个问题：“我周围发生了什么？”
常见的传感器包括：
- 摄像头：提供视觉信息，比如车道线、交通标志、行人、车辆。分辨率高，但受光照影响大。
- 激光雷达（LiDAR）：发射激光束，测量距离。精度高，能生成3D点云。但成本高，雨雪天性能会下降。
- 毫米波雷达：用无线电波测距和测速。不怕雨雪，但分辨率低，没法识别物体类别。
- 超声波雷达：近距离探测，主要用于泊车。
- IMU/GNSS：提供车辆自身的位置、姿态、速度信息。
核心要点：没有哪个传感器是万能的。感知模块的核心能力是多传感器融合——取长补短，得到更可靠的环境模型。
我在项目中遇到过一件事：有一次测试，纯视觉方案在隧道出口处突然“失明”了。因为光线剧烈变化，摄像头过曝了。还好我们融合了毫米波雷达的数据，系统没有丢失前方车辆。嗯，这就是融合的价值。
2.1.2 决策模块——车的“大脑”
决策模块拿到感知信息后，要回答：“我接下来该怎么做？”
它通常分为几个层次：
- 行为决策：决定宏观行为，比如“跟车”、“变道”、“超车”、“停车”。这层有点像人的直觉判断。
- 路径规划：在行为决策的指导下，规划出一条具体的、无碰撞的轨迹。要考虑道路结构、交通规则、障碍物。
- 运动规划：把路径转化为具体的速度、加速度、转向角指令。要保证舒适性和安全性。
我的经验：决策模块是系统里最难调试的部分。感知错了，你还能看到数据。决策错了，你都不知道它为什么这么选。我建议新人多花时间理解“状态机”和“代价函数”的设计逻辑。
2.1.3 控制模块——车的“手脚”
控制模块负责执行决策。它要回答：“怎么让车按照规划的轨迹走？”
核心是控制算法，比如：
- PID控制：经典方法，简单可靠。用于油门、刹车、转向的闭环控制。
- 模型预测控制（MPC）：更高级的方法。能预测未来状态，优化控制量。适合处理约束条件，比如最大转向角、最大加速度。
控制模块的输出是具体的执行器指令：油门开度、刹车压力、方向盘转角。
注意：控制模块的延迟是致命的。我曾经见过一个案例，因为控制指令的通信延迟，车辆在紧急避障时反应慢了200毫秒，差点撞上护栏。所以，实时性是控制模块的生命线。
2.2 数据流与信号流——系统的“血脉”
模块之间怎么协作？靠数据流和信号流。
我习惯把数据流分成两类：
- 感知数据流：从传感器到感知模块。数据量大，带宽要求高。比如摄像头每秒产生几十兆字节的图像数据。
- 决策控制数据流：从感知模块到决策模块，再到控制模块。数据量小，但实时性要求极高。比如障碍物位置、速度、规划轨迹。
信号流则更底层，指的是硬件之间的电气信号。比如：
- 传感器通过CAN总线或以太网发送数据。
- 控制模块通过PWM信号或LIN总线驱动执行器。
这里有个关键点：数据流和信号流的设计决定了系统的实时性和可靠性。
举个例子：
// 伪代码：数据流示例
while (vehicle_is_running) {
// 1. 感知模块处理传感器数据
sensor_data = read_sensors(); // 从CAN总线读取
perception_result = process_perception(sensor_data); // 目标检测、跟踪
// 2. 决策模块基于感知结果做规划
decision = make_decision(perception_result); // 行为决策 + 路径规划
// 3. 控制模块执行决策
control_command = compute_control(decision); // PID或MPC计算
send_to_actuators(control_command); // 通过CAN总线发送
// 4. 等待下一个周期（通常10-100ms）
sleep(cycle_time);
}
核心原则：数据流要保证“端到端延迟”可控。从传感器采集到执行器响应，整个链路的时间必须满足安全要求。比如，AEB（自动紧急制动）系统要求延迟小于100ms。
2.3 硬件与软件分层——系统的“骨架”
一个好的架构，一定是分层的。每一层各司其职，层与层之间通过清晰的接口通信。
2.3.1 硬件分层
从下往上，硬件大致分为：
| 层级 | 组件 | 职责 |
|---|---|---|
| 执行层 | 转向、制动、油门、悬架 | 执行控制指令，完成车辆运动 |
| 驱动层 | 电机控制器、ECU、线控底盘 | 将控制信号转化为物理动作 |
| 计算层 | 域控制器、GPU、FPGA、SoC | 运行感知、决策、控制算法 |
| 感知层 | 摄像头、LiDAR、雷达、IMU | 采集环境数据 |
| 通信层 | CAN、以太网、车载网络 | 连接各硬件，传输数据 |
我个人习惯把“计算层”再细分：
- 主控芯片：比如NVIDIA Orin、高通Snapdragon Ride。负责运行复杂的AI模型和规划算法。
- 安全芯片：比如Infineon TC397。负责监控系统状态，处理故障，保证功能安全。
2.3.2 软件分层
软件架构同样分层清晰：
| 层级 | 组件 | 职责 |
|---|---|---|
| 应用层 | 感知算法、决策规划、控制算法 | 实现自动驾驶核心功能 |
| 中间件层 | ROS 2、CyberRT、AUTOSAR Adaptive | 提供通信、调度、数据管理服务 |
| 操作系统层 | Linux (RT-Preempt)、QNX、VxWorks | 管理硬件资源，提供实时性保障 |
| 硬件抽象层 | BSP、驱动程序、HAL | 屏蔽硬件差异，为上层提供统一接口 |
我的建议：新人最容易忽略的是中间件层。你想想看，如果通信机制没选好，模块之间数据传不过去，算法写得再好也没用。我建议你从ROS 2入手，它用DDS作为通信协议，天生支持分布式和实时性。
2.4 架构设计中的“坑”与“道”
最后，分享几个我在实际项目中踩过的坑：
- 坑一：过度依赖单一传感器。我曾经参与过一个项目，前期只用了摄像头做感知。结果一到雨天，系统性能直线下降。后来不得不紧急加入激光雷达和毫米波雷达，架构大改，浪费了三个月。
- 坑二：忽视功能安全。有一次，我们在高速测试时，主控芯片突然过热降频。因为没有独立的监控模块，系统直接“死机”了。从那以后，我坚持在架构中加入独立的“安全岛”芯片。
- 坑三：软件与硬件耦合太紧。早期我们为了性能，把算法直接跑在特定硬件上。结果换硬件平台时，代码几乎重写。后来我们引入了硬件抽象层，才解决了这个问题。
避坑指南：我曾经因为没做好模块间的接口定义，导致感知模块输出的坐标系和决策模块期望的不一致。排查了整整两天。所以，一定要在架构设计阶段就把接口协议定死，比如用Protobuf或IDL定义消息格式。
好了，这一章的内容就到这里。系统架构总览，说白了就是让你看清自动驾驶这头“大象”的全貌。下一章，我们会深入感知模块，聊聊传感器是怎么“看”世界的。
记住：架构设计没有银弹。但理解了这些核心模块、数据流和分层思想，你就有了搭建任何自动驾驶系统的基础。
公众号:蓝海资料掘金营，微信deep3321