开篇：核心理念

做智能驾驶系统架构，问题很多，很杂。我的核心思路只有一条：适配业务生命周期的演进式架构。

架构不是一成不变的艺术品，而是服务于业务的工具箱。不同阶段，用不同工具。

• 0-1阶段 (原型验证): 目标是快。快速验证功能，快速试错。技术选型要灵活，比如用ROS2搭架子，让算法跑起来是第一要务。
• 1-100阶段 (产品量产): 目标是稳。可靠性、安全性、成本、功耗，这些非功能性需求上升为核心。必须引入车规级、标准化的东西。

架构师的职责，就是为系统在不同阶段选择最合适的“武器”。

一、定战略：蓝图比代码重要

把产品经理的“城市领航辅助”这种想法，翻译成技术能看懂的语言和路径，就是架构师的第一步。

具体工作：架构分代规划

输出物是《系统架构演进蓝图》。这不是一份文档，是未来几年的作战地图。

• Gen 1.0 (高速NOA): 目标是快速上车。传感器方案可能是“视觉+前向毫米波”，域控制器选成熟货架产品，软件架构以模块化功能为主，解决结构化道路问题。
• Gen 2.0 (城市NOA): 目标是啃硬骨头。架构要大改。
  • 硬件升级： 引入激光雷达、高分辨率摄像头。算力平台升级，支持大模型。
  • 软件重构： 架构要为BEV + Transformer这类模型服务。数据吞吐量极大，对中间件和OS的要求完全不同。这是当前的主流趋势，架构必须提前布局。
• Gen 3.0 (迈向L3+): 目标是无人。核心是冗余。计算冗余、传感器冗余、执行冗余。架构要原生支持“影子模式”，让量产车队成为数据收集和算法迭代的闭环系统。

这个蓝图需要和管理层、产品、项目组反复对齐，确保大家在同一张图上作战。

二、做决策：数据驱动，而非拍脑袋

架构师做的每个关键决策，比如选哪家的芯片、用什么中间件，都影响深远。不能凭感觉。

具体工作：基于PoC的技术选型

1. 建立评估矩阵： 把所有要考虑的维度列出来。以选SoC为例：算力(TOPS)、功耗(W)、SDK成熟度、功能安全等级(ASIL)、成本、供应链。
2. 动手实测 (PoC)： 拿各家的开发板（EVK），让算法团队把我们最核心的模型（比如BEV感知）上去跑。我们要的是真实帧率、真实功耗，不是PPT上的峰值算力。
3. 输出决策报告： “方案A算力高，但功耗超标，需要主动散热，增加成本和风险。方案B算力略低，但我们的算法优化后能跑到目标帧率，且SDK工具链完善，可缩短开发周期。结论：选B。”

行业趋势补充：
随着BEV模型带来的数据量激增，传统的CAN总线早已不够用。决策时必须考虑支持DDS或类似的高带宽、低延迟中间件，并配合车载以太网。这是支撑“软件定义汽车”（SDV）的基础。

三、定接口：系统解耦的“交通法”

我们用Node（节点）作为基本开发和部署单元。系统复杂，几十上百个节点，必须解耦，否则就是一锅粥。接口定义就是解耦的法律。

1. 核心节点拆解 (Node Breakdown)

一个典型的智能驾驶系统，会包含以下几类节点：

• 驱动层 (Drivers):
  • lidar_driver_node: 负责连接激光雷达，输出原始点云数据。
  • camera_driver_node: 连接摄像头，输出图像数据。
  • radar_driver_node: 连接毫米波雷达，输出目标点数据。
  • imu_gnss_driver_node: 连接惯导和GPS，输出车辆姿态和位置信息。
• 感知层 (Perception):
  • perception_fusion_node (或bev_fusion_node): 核心节点。订阅所有传感器数据，进行时空同步，融合成统一的BEV（鸟瞰图）视图或3D目标物列表。
  • traffic_light_detection_node: 专门识别交通灯状态。
• 定位层 (Localization):
  • localization_node: 融合IMU/GNSS、轮速和高精地图，输出车辆在地图中的精确姿态（Pose）。
• 规划与决策层 (Planning & Decision):
  • prediction_node: 订阅感知结果和定位，预测其他交通参与者（车辆、行人）的未来轨迹。
  • behavior_planner_node: 做高层决策。决定是“跟车”、“变道”还是“超车”。
  • motion_planner_node: 根据行为决策，生成一条平滑、安全、可行驶的具体轨迹（Trajectory）。
• 控制与执行层 (Control & Execution):
  • control_node: 订阅规划好的轨迹和当前车辆状态，计算出具体的油门、刹车、方向盘转角指令。
  • vehicle_interface_node: 将控制指令转换为CAN报文，发送给车辆底盘执行。

2. 核心信息流 (Data Flow)

• Driver Nodes -> Perception Fusion Node: [原始点云、图像数据]
• Perception Fusion Node -> Prediction Node: [带ID和速度的3D目标物列表]
• Localization Node -> All Planning Nodes: [高精度车辆位姿]
• Prediction Node -> Behavior/Motion Planner Nodes: [带有多条预测轨迹的目标物列表]
• Motion Planner Node -> Control Node: [一条确定的、未来几秒的行驶轨迹点序列]
• Control Node -> Vehicle Interface Node: [具体的控制指令，如AckermannDrive.msg]

3. 接口定义 (Interface Definition)

我们不用Word写ICD。直接用代码化的方式定义，比如 Protobuf。下面这个Object定义，就是Perception节点产出、Prediction节点消费的数据格式。

// message definition for a perceived object
message Object {
  // ... (如前文所示的具体字段)
}

清晰的接口，让感知组和规划组可以并行开发，互不影响，只在联调时看数据对不对。

四、守底线：非功能性需求是生命线

车会跑只是基础，安全、稳定、不出事，才是底线。

1. 功能安全 (ISO 26262) 如何落地?

首先，功能安全不是一个独立的业务节点，它是一个贯穿整个系统的监控和裁决层。 它的实现是分布式的，融入在架构设计中。

核心思想：主-监控 (Main-Monitor) 架构

• 主功能 (Main Path): 就是上面提到的从感知到控制的全功能链路。它追求最优性能，但复杂性高，潜在风险也高。
• 监控功能 (Monitor Path): 这是一条或多条并行的、更简单的、以安全为唯一目标的校验链路。

具体实现：

1. 增加一个safety_monitor_node:
   • 订阅什么： 它不处理复杂的传感器数据，而是订阅关键节点的输出，比如motion_planner_node输出的轨迹和control_node输出的控制指令。
   • 做什么： 运行一系列简单但绝对可靠的安全规则检查。
     • 规则示例1 (轨迹检查): 规划出的轨迹是否会与高精地图中的静态障碍物（路沿、墙壁）在未来3秒内发生碰撞？
     • 规则示例2 (控制指令检查): 计算出的方向盘转角速度是否超过了物理极限？请求的加速度是否会导致车轮打滑？
   • 如何反应： 一旦监控节点发现主功能节点的输出违反了安全规则，它拥有最高裁决权。它可以直接绕过主控制器，通过vehicle_interface_node发送一个安全降级指令，比如“紧急制动”或“保持当前车道”。
2. 冗余节点设计:
   • 对于ASIL D级别的核心功能（如转向），可以设计冗余节点。例如，一个complex_motion_planner_node用于正常行驶，追求舒适和效率；同时有一个simple_safety_planner_node，它只会生成最保守的轨迹（如沿着车道中心线减速）。正常情况下simple节点只看不做，当complex节点失效（如心跳丢失）或其输出被safety_monitor_node否决时，系统可以立刻切换到simple节点的输出。
3. 节点自身健康监控:
   • 每个关键节点都要对外发布自己的“心跳”和状态信息。架构中有一个system_manager_node负责监控所有节点是否存活、资源占用是否正常。

2. 实时性与信息安全

• 实时性： 建立《端到端延迟预算表》，用工具链在CI/CD中卡住每个节点的耗时，防止性能劣化。
• 信息安全 (ISO 21434): 设计安全启动链（Secure Boot），关键ECU间的通信（如网关到域控）走加密通道（SecOC），防止被黑。

结语

架构师不是画图的。我们的工作是确保这台复杂的机器，在从实验室原型走向千万用户手中的整个过程中，始终保持在一条正确、安全且高效的轨道上。

架构本身就是一种持续的权衡与进化。