📚 课程目录第3章系统总体架构

3. 系统总体架构

L2+与L3级智能驾驶系统的落地，本质上是一场关于“算力如何被组织、软件如何被部署、数据如何流动”的架构工程。与L2级辅助驾驶的分布式ECU堆叠不同，L2+与L3系统面临的是传感器数量激增（通常12~20个）、AI模型复杂度指数级上升、以及功能安全（ISO 26262）与预期功能安全（ISO 21448）的双重约束。因此，理解系统总体架构是进入智能驾驶领域的基石。本章将围绕经典的“感知-决策-执行”逻辑主线，深入剖析当前主流的域集中式电子电气架构，并阐明面向服务的软件架构（SOA）如何在其中发挥关键作用。

上图展示了L2+/L3系统架构的全景。感知层负责将物理世界的连续信号转化为数字化的语义信息；决策规划层基于这些语义信息进行驾驶策略的推理与轨迹的生成；执行层则将规划结果转化为车辆的机械动作。而这一切的算力底座，正是位于下方的域控制器与中央计算平台，SOA软件架构则贯穿其中，定义了软件模块之间的协作方式。下面我们将分层展开论述。

3.1 感知-决策-执行三层架构：从信号到动作的闭环

核心原理：数据流与责任边界

三层架构并非简单的功能堆叠，而是对智能驾驶系统实时性与确定性的工程妥协。感知层强调“全”与“准”，决策层强调“对”与“稳”，执行层强调“快”与“精”。在L3级系统中，该架构还引入了“最小风险策略（MRC）”的概念——当系统或驾驶员均无法接管时，决策层必须能生成一个安全停车的轨迹并交由执行层完成。

层级	核心功能	典型硬件/模块	关键性能指标	失效模式
感知层	环境重建、目标检测、语义分割	摄像头、LiDAR、雷达、IMU	目标检出率 > 99%，延迟 < 100ms	漏检、误检、传感器遮挡
决策层	行为预测、路径规划、控制决策	AI加速芯片、MPC控制器	规划周期 10-50Hz，决策延迟 < 50ms	预测偏差、规划死锁
执行层	转向、制动、驱动指令响应	EPS、ESP、VCU	指令响应延迟 < 50ms，控制精度 > 95%	执行器卡滞、通讯中断

判断方法与操作流程：如何界定层级边界

在实际工程中，判断一个功能属于哪一层，可依据以下流程：第一步，确认输入数据是否为原始传感器流（属于感知）或已处理的目标列表（属于决策输入）；第二步，确认输出是否为方向盘转角、制动压力等物理量（属于执行）或轨迹点序列（属于决策输出）；第三步，检查该模块是否包含状态机切换逻辑（如从ACC切换至AEB），若是则属于决策层。这种清晰的边界划分有助于团队分工与接口定义。

经验提醒：在L3系统设计中，感知层与决策层之间通常需要增加一层“对象级融合”接口。不要将原始点云直接传递给规划模块，否则会导致计算负载不可控。建议在感知层内部完成BEV（鸟瞰视角）特征转换，输出标准化的目标列表（含速度、加速度、朝向角、预测轨迹）。

案例拆解：AEB自动紧急制动中的三层协作

以典型的AEB（自动紧急制动）功能为例：背景是车辆以60km/h行驶，前方静止车辆。感知层通过前视摄像头与毫米波雷达融合，在80ms内输出前方目标距离为30m且相对速度为-60km/h。决策层接收到该信号后，首先进行碰撞时间（TTC）计算，TTC = 30m / (60km/h ≈ 16.7m/s) ≈ 1.8s。由于TTC小于2.0s阈值，决策层判定需要触发AEB，并生成目标减速度-6m/s²的制动请求。执行层收到请求后，ESP系统在10ms内建立制动压力，并在200ms内达到目标减速度。整个闭环耗时约300ms，远低于人眼反应时间（约500ms）。复盘要点：若感知层延迟增加至200ms，TTC计算将变为1.6s，系统仍能触发，但制动距离会增加约1.5m，可能造成碰撞风险。因此，三层架构的延迟预算必须严格分配。

风险提示：执行层并非简单的“执行者”。在L3级中，执行层必须具备“降级模式”。例如，当制动系统部分失效时，执行层应能通过动力系统反向扭矩或电子驻车制动实现冗余制动。若执行层缺乏独立的安全监控逻辑，将导致系统在边缘场景下失控。

常见误区与总结

误区一：认为感知层越“重”越好。实际上，过度的感知计算会挤占决策层的算力资源，导致规划周期抖动。
误区二：将决策层视为单一模块。在L3中，决策层应拆分为“主决策”与“安全决策”两个独立通道，后者基于简化模型进行独立校验。
总结：三层架构的本质是“关注点分离”。每一层只对上一层负责，通过明确的接口契约进行交互。这种设计使得功能安全认证（ISO 26262）可以针对每一层独立进行，降低了系统级认证的复杂度。

3.2 域控制器与中央计算平台：算力的物理载体

核心原理：从分布式到集中式的演进逻辑

传统L2系统采用分布式ECU架构，每个传感器或执行器对应一个独立ECU，导致线束长度超过2km，软件升级困难。L2+/L3系统引入了域控制器（DCU）架构，将整车划分为智能驾驶域、座舱域、车身域、动力域等。智能驾驶域控制器集中处理摄像头、雷达、激光雷达的数据，并运行感知与决策算法。而更高阶的L3+系统则进一步演进为中央计算平台（CCP），将智驾、座舱、车联网甚至部分车身控制融合到一个高性能计算单元中，通过软件定义实现功能重组。

对比维度	分布式ECU架构	域控制器架构	中央计算平台
算力分布	分散，单ECU算力 < 1 TOPS	集中，智驾域 30-200 TOPS	超集中，500-1000+ TOPS
通信方式	CAN/CAN-FD	CAN-FD + 车载以太网	万兆以太网 + PCIe Switch
软件更新	几乎不可OTA	支持域内OTA	全车SOA化OTA
冗余设计	无或极少	关键域双冗余	全冗余（2+2或1+1）
典型芯片	MCU (如TC297)	SoC (如Orin-X, 英伟达)	多SoC + MCU (如Thor+TC399)

操作流程：域控制器的选型与算力评估

进行域控制器选型时，建议遵循以下步骤：第一步，统计传感器原始数据带宽。例如，8路摄像头（每路1080p@30fps，约3Gbps）加上1个激光雷达（约2Gbps），总输入带宽约26Gbps。这决定了域控制器需要具备至少4路以上的万兆以太网或MIPI CSI接口。第二步，评估AI算力需求。L3级典型需要同时运行目标检测、语义分割、轨迹预测三个模型，建议选择算力在100 TOPS以上的SoC，并预留30%的算力余量用于OTA升级后的新模型。第三步，确认安全冗余。L3级要求主控SoC失效时，备份MCU能在100ms内接管车辆控制，因此域控制器内部必须包含独立的ASIL-D级MCU。

  工程实战：某车型在开发L3级拥堵辅助功能时，最初选用单颗Orin-X（254 TOPS）域控制器。实测发现，在开启全部传感器融合与城市NOA功能后，AI负载达到85%，且CPU负载超过90%。随后工程师将决策规划算法中的部分规则逻辑迁移至MCU运行，并将感知模型从ResNet-50替换为轻量化的MobileNetV3，最终将AI负载降至70%，CPU负载降至75%，为后续功能迭代留出了空间。

案例拆解：中央计算平台的电源与散热设计

中央计算平台（CCP）的功耗通常高达500W-1000W，这对整车的12V电源系统与热管理提出了严峻挑战。背景：某L3级车型的CCP采用双Orin-X + 双TC399方案，峰值功耗达800W。问题：在夏季高温（40℃）环境下，CCP内部温度在连续运行30分钟后达到95℃，超过芯片结温上限（105℃），导致AI算力降频。分析：通过热成像仪检测发现，散热风道设计不合理，热风回流导致局部热点。操作：工程师重新设计了液冷板回路，将冷却液流量从4L/min提升至8L/min，并优化了风扇PWM控制策略，使温度稳定在78℃。结果：算力稳定性提升，且功耗降低了12%。复盘：CCP的散热设计必须在整车开发早期介入，否则后期改造成本极高。

风险说明：域控制器与CCP的引入虽然简化了线束，但带来了“单点故障”风险。必须为电源、通信、存储（eMMC/UFS）设计冗余路径。例如，采用双电源轨（主+备）供电，当主电源跌落时，备份电源在10ms内无缝切换。

常见误区与总结

误区一：认为算力越大越好。实际上，高算力芯片的功耗与散热成本呈指数级上升，且过高的算力利用率会导致系统实时性下降。
误区二：将域控制器与CCP视为纯硬件。实际上，硬件只是载体，真正的价值在于其上的SOA软件框架与数据通信中间件。
总结：域控制器与CCP的选择应基于“功能需求-算力需求-功耗预算-成本约束”的四维平衡。建议采用“主控SoC + 安全MCU”的异构架构，兼顾高性能与高安全。

3.3 SOA软件架构：软件定义汽车的实现基石

核心原理：服务的抽象与解耦

SOA（面向服务的架构）将车辆功能封装为独立的、可复用的“服务”。每个服务具有标准化的接口（IDL定义），通过服务中间件（如SOME/IP、DDS）进行通信。在L2+/L3系统中，SOA的核心价值在于动态部署与功能编排。例如，“自动变道”功能可以被拆分为“目标检测服务”、“路径规划服务”、“转向控制服务”三个原子服务，通过服务编排引擎组合而成。当需要升级变道策略时，只需更新“路径规划服务”的代码，无需改动其他模块。

服务类型	示例	通信方式	实时性要求	部署位置
原子服务	摄像头数据获取	SOME/IP	低（100ms级）	域控制器
组合服务	自动紧急制动	DDS	高（10ms级）	中央计算平台
系统服务	健康监控、日志	HTTP/JSON	低（秒级）	中央计算平台

操作流程：SOA服务设计与接口定义

设计一个SOA服务需遵循以下流程：第一步，识别业务能力。例如，将“自适应巡航”拆分为“前车检测”、“速度规划”、“扭矩请求”三个能力。第二步，定义服务接口。使用IDL（接口定义语言）描述输入输出参数、数据类型、错误码。例如，速度规划服务的输入为“前车速度、相对距离、本车速度”，输出为“目标加速度”。第三步，选择通信中间件。对于实时性要求高的控制类服务，建议使用DDS（数据分发服务）；对于诊断与配置类服务，可使用SOME/IP。第四步，部署与编排。通过服务发现机制，动态绑定服务的提供者与消费者。

// 示例：速度规划服务接口定义 (IDL)
module driving_services {
    struct SpeedPlanRequest {
        float front_vehicle_speed;   // 前车速度 m/s
        float relative_distance;     // 相对距离 m
        float ego_speed;             // 本车速度 m/s
    };
    struct SpeedPlanResponse {
        float target_acceleration;   // 目标加速度 m/s²
        uint8_t confidence;          // 置信度 0-100
    };
    service SpeedPlanner {
        SpeedPlanResponse plan_speed(SpeedPlanRequest req);
    };
};

案例拆解：基于SOA的OTA升级与功能降级

背景：某L3级车型在用户使用过程中发现，自动泊车功能在特定车位（狭窄垂直车位）下成功率低。目标：通过OTA快速修复，无需进店。操作：工程师在云端修改了“车位检测服务”的算法参数，并新增了一个“窄车位辅助”组合服务。通过SOA的服务编排，将该服务动态部署到中央计算平台，并利用服务发现机制通知座舱域HMI更新功能菜单。结果：用户次日收到OTA推送，升级耗时15分钟，泊车成功率从72%提升至94%。风险与代价：OTA过程中若发生断电，可能导致服务注册信息丢失。因此，SOA框架必须支持“原子升级”与“回滚机制”。复盘：SOA架构使得功能迭代周期从传统的6个月缩短至2周，但要求服务接口具备极强的向后兼容性。

经验提醒：在SOA架构中，务必重视“服务健康检查”。建议每个服务定期向中央监控服务发送心跳包。当某个服务连续3次未响应时，监控服务应触发降级策略，例如从“自动变道”降级为“车道保持”，并通知驾驶员接管。

常见误区与总结

误区一：将SOA等同于“微服务”。在车内嵌入式环境中，微服务的粒度不宜过细，否则通信开销会拖垮实时性。建议服务粒度以“功能域”为单位。
误区二：忽视确定性通信。SOA的异步通信特性可能导致控制指令的抖动。对于安全关键服务，必须采用“事件触发 + 时间触发”混合调度机制。
总结：SOA是L2+/L3系统实现“软件定义汽车”的核心。它通过标准化接口、动态部署、服务编排三大能力，使得智能驾驶系统具备了持续进化、快速迭代的潜力。但SOA的落地必须与功能安全（ISO 26262）紧密结合，确保服务的动态行为不会破坏系统的安全完整性等级。