1. ADAS系统概述：ADAS功能定义、传感器架构、域控制器与MCU/SoC选型
各位同学，咱们今天聊聊ADAS系统的整体面貌。说实话，我入行那会儿，ADAS还是个挺新鲜的概念，现在已经是智能汽车的标配了。这一章，我带你从功能定义、传感器架构，一直聊到域控制器和芯片选型，把底层的逻辑理清楚。
1.1 ADAS功能定义：从L0到L2+，到底在做什么？
ADAS，全称是Advanced Driver Assistance Systems，高级驾驶辅助系统。说白了，就是帮驾驶员看路、判断、执行的一套电子系统。它不是自动驾驶，而是「辅助」——这个定位很重要。
我个人习惯把ADAS功能分成三个层级：
- 感知预警类：比如FCW（前向碰撞预警）、LDW（车道偏离预警）、BSD（盲区监测）。这些功能只报警，不干预。
- 控制干预类：比如AEB（自动紧急制动）、LKA（车道保持辅助）、ACC（自适应巡航）。系统会主动踩刹车或打方向。
- 融合决策类：比如TJA（交通拥堵辅助）、HWA（高速公路辅助）。需要多传感器融合，做路径规划和横纵向控制。
嗯，这里要注意一个坑：很多项目把L2+的功能定义得过于激进。我曾经见过一个方案，想在单颗MCU上跑AEB+LKA+ACC，结果算力不够，导致AEB响应延迟了200ms。200ms在高速上意味着什么？差不多6米的刹车距离。所以功能定义一定要和硬件能力匹配。
核心原则：ADAS功能的安全等级（ASIL）决定了开发成本。FCW通常只需ASIL B，而AEB必须做到ASIL D。功能定义阶段就要明确每个功能的ASIL等级，否则后期改架构会非常痛苦。
1.2 传感器架构：摄像头、毫米波雷达、激光雷达怎么搭？
传感器是ADAS的眼睛。目前主流的方案有三种：
| 传感器类型 | 优势 | 劣势 | 典型应用 |
|---|---|---|---|
| 摄像头（单目/双目） | 成本低，能识别车道线、交通标志、行人 | 受光照影响大，测距精度一般 | LDW、TSR、FCW |
| 毫米波雷达（77GHz/24GHz） | 全天候工作，测距测速准 | 角度分辨率低，无法识别物体类别 | ACC、AEB、BSD |
| 激光雷达（LiDAR） | 3D点云，精度极高 | 成本高，受雨雾影响 | L3+高阶感知、SLAM |
你想想看，为什么现在L2级方案普遍用「1前视摄像头+5毫米波雷达」？说白了，这是成本和性能的平衡点。摄像头负责识别，雷达负责测距，两者互补。
我在项目中遇到过一个问题：某款车在隧道出口处，摄像头因为亮度突变导致短暂「失明」，而毫米波雷达不受影响。如果系统完全依赖摄像头做AEB决策，那隧道出口就是高风险场景。所以我的建议是：关键安全功能必须有多传感器冗余，至少要有两种不同物理原理的传感器同时覆盖。
避坑指南：传感器标定是ADAS开发中最容易被低估的环节。我曾经因为摄像头和雷达的外参标定差了0.5度，导致融合后的目标位置偏移了1.2米（在50米处）。这个误差足以让AEB误触发或漏触发。所以，传感器架构设计时就要预留标定接口和自检机制。
1.3 域控制器：为什么需要它？
早期的ADAS是分布式架构——一个功能一个ECU。比如AEB一个盒子，ACC一个盒子，各自为政。但这样有两个问题：
- 线束太多，重量和成本都高
- 功能间无法高效协同，比如AEB和ACC抢方向盘
域控制器（Domain Controller）就是把这些功能集中到一个高性能计算平台上。它负责：
- 传感器数据融合：把摄像头、雷达、激光雷达的数据统一处理
- 决策规划：运行路径规划算法
- 控制输出：向执行器（刹车、转向）发送指令
- 功能安全监控：实时检测系统是否异常
嗯，这里有个关键点：域控制器不是简单地把代码堆在一起。它需要做功能隔离。比如，AEB的代码和娱乐系统的代码必须跑在不同的核或不同的虚拟机里，否则娱乐系统死机可能导致AEB失效。这在ISO 26262里叫「freedom from interference」。
1.4 MCU与SoC选型：算力、安全、成本的三角博弈
选芯片是ADAS系统设计中最头疼的事。我一般从三个维度来评估：
1.4.1 MCU：安全管家
MCU（微控制器）负责实时控制和功能安全监控。典型代表：Infineon TC3xx系列、NXP S32K系列。
- 特点：实时性强，有硬件安全机制（如Lockstep核、ECC、MPU）
- 适合：执行AEB、EPS等安全关键控制
- 选型要点：ASIL等级、Flash大小、CAN/CAN FD接口数量
1.4.2 SoC：算力担当
SoC（系统级芯片）负责传感器处理和AI推理。典型代表：NVIDIA Orin、TI TDA4、高通Snapdragon Ride。
- 特点：算力高（几十到几百TOPS），有GPU/NPU加速
- 适合：运行深度学习模型、多传感器融合
- 选型要点：算力（TOPS）、内存带宽、功耗、生态支持
重要提醒：不要只看算力！我见过一个项目选了200 TOPS的SoC，结果因为内存带宽不够，实际推理帧率只有标称值的30%。选SoC时一定要看「有效算力」——也就是在典型工作负载下的实际性能。另外，SoC的功耗和散热也是大问题，域控制器通常需要主动散热。
1.4.3 典型架构示例
一个L2+级别的域控制器，我常用的方案是：
SoC（TI TDA4VM）：
- 2个Cortex-A72：运行Linux，做传感器融合和路径规划
- 4个Cortex-R5F：运行RTOS，做实时控制
- C7x DSP + MMA：加速AI推理
MCU（Infineon TC397）：
- 6个TriCore核，其中2个Lockstep
- 负责AEB、EPS的安全监控
- 通过SPI与SoC通信，心跳检测这个架构的好处是：SoC负责「动脑子」，MCU负责「保安全」。即使SoC死机了，MCU还能独立执行AEB等安全功能。
我的经验：选型时一定要留余量。算力留30%余量，Flash留50%余量，RAM留40%余量。因为软件开发过程中，功能只会增加不会减少。我曾经因为Flash只留了20%余量，结果后期加了一个OTA功能，不得不换芯片，项目延期了3个月。
1.5 本章小结
这一章我们聊了ADAS的功能定义、传感器架构、域控制器和芯片选型。说白了，ADAS系统设计就是一场平衡游戏——在功能、安全、成本、算力之间找到最优解。下一章，我们会深入静态代码分析，看看怎么保证这些代码不出bug。
嗯，最后说一句：选型文档一定要写清楚每个芯片的ASIL等级和失效模式。这是功能安全评审的硬性要求，也是你后期甩锅的依据——开个玩笑，但确实很重要。