1. 从“辅助”到“自主”汽车电子架构的十字路口干了十几年汽车电子我亲眼看着车里的控制器从几个变成了几十个功能从简单的车窗升降变成了能自己刹车、自己转弯。这两年跟同行聊话题总绕不开ADAS和自动驾驶。这不仅仅是多了几个功能那么简单它正在把整个汽车的“大脑”和“神经系统”彻底重写一遍。过去那种一个功能对应一个“小黑盒”ECU的分布式架构就像老式收音机里塞满了各种独立功能的电路板现在已经玩不转了。为什么想象一下要实现自动紧急制动AEB你的车需要同时“看”到前方的障碍物摄像头还要“感知”到它的距离和相对速度雷达。在传统的架构里摄像头和雷达可能各自有一个ECU处理数据得出“前方有车”和“距离50米速度差30km/h”的结论然后再把这两个结论发给另一个负责决策的ECU。这个过程中数据来回传输有延迟不同供应商的ECU之间通信可能还有兼容性问题更别提对海量原始数据进行融合处理的算力要求了。这就像让几个只说方言的人通过写信来协作完成一个紧急任务效率低容易出错而且很难升级。所以行业正在向域控制器和中央计算架构演进。简单说就是把功能相近的“小黑盒”合并成几个功能强大的“大脑分区”域比如车身域、动力域而最核心的感知、决策任务则交给一个或几个性能怪兽级的中央计算平台。这种转变的核心驱动力就是为了应对ADAS和自动驾驶带来的三大挑战海量数据处理、硬核的功能安全Functional Safety要求以及不可或缺的信息安全Security。今天我就结合NXP这类一线芯片厂商的方案来拆解一下这个从感知到决策的安全架构到底是怎么一步步构建起来的里面有哪些门道和坑。2. 安全是底线而非特性功能安全与信息安全的双重挑战在聊具体的技术之前我们必须先确立一个共识对于ADAS和自动驾驶安全不是“加分项”而是“入场券”和“生命线”。这里的安全是两层意思功能安全和信息安全。很多刚入行的朋友容易混淆其实它们防范的是两种完全不同性质的“失效”。2.1 功能安全如何应对“非恶意”的失效功能安全关注的是系统在发生随机硬件故障或系统性故障时如何避免导致人身伤害的风险。它的核心标准是ISO 26262。你可以把它理解成汽车的“抗灾应急预案”。它不是要求系统100%不出故障这在物理上不可能而是要求系统在故障发生时能进入或维持在一个安全的状态。这里的关键量化工具是汽车安全完整性等级ASIL。ASIL从A到D等级越高要求越严苛。它由三个因素决定严重度S如果危害发生会造成多严重的伤害从轻伤到致命。暴露率E车辆运行在可能导致危害的场景下的概率有多高可控性C驾驶员或其他交通参与者能否通过及时反应来避免事故例如高速公路上自适应巡航ACC系统的意外加速故障其严重度很高S3暴露率也高E4可控性在高速下较低C3。综合评估下来这个功能就可能需要达到ASIL D等级这是最高的安全要求。要达到ASIL D芯片和系统设计上就要下血本。比如处理器内核需要锁步Lockstep运行一个内核干活另一个完全相同的内核同步执行同样的指令实时比较结果。一旦出现不一致立刻触发安全机制如关闭输出、进入安全状态。内存需要带ECC纠错通信总线需要冗余和校验。NXP的S32系列处理器家族从微控制器到高性能处理器都按照这个理念设计提供可扩展的安全支持让开发者能基于同一套架构开发从ASIL B到ASIL D的不同应用。注意功能安全的开发成本极高。它不仅仅是硬件上的冗余更贯穿整个开发流程——从需求、设计、编码、测试到生产都需要遵循一套严苛的流程和文档体系。对于初创团队或从消费电子转过来的团队这是第一个需要补课和适应的高门槛。2.2 信息安全筑起抵御“恶意攻击”的防火墙如果说功能安全防的是“天灾”那信息安全防的就是“人祸”。一辆联网的、具备自动驾驶能力的汽车其攻击面大大增加远程车联网T-Box、蓝牙/Wi-Fi、甚至轮胎压力监测系统TPMS都可能成为黑客的入口。攻击的动机也很多样窃取用户隐私数据、勒索软件、甚至远程操控车辆。信息安全的目标是CIA三元组保密性Confidentiality、完整性Integrity、可用性Availability。在汽车上具体表现为防止未经授权的访问和控制确保黑客不能通过远程漏洞接管你的方向盘或刹车。保护数据隐私车辆采集的摄像头数据、行驶轨迹、个人习惯等信息必须加密存储和传输。保障系统可用性防止拒绝服务攻击导致关键ADAS功能失灵。实现这些需要一整套从硬件到软件的安全架构硬件安全模块HSM这是芯片里的“保险箱”。NXP的处理器通常集成高性能的HSM用于安全存储密钥、执行加密解密运算如AES, SHA, RSA、进行安全启动。所有关键的安全操作都在这个隔离的、防篡改的硬件环境中进行即使主系统被攻破密钥也不会泄露。安全启动与信任链从芯片上电第一行代码开始每一级软件Bootloader、操作系统、应用在加载前都要用数字签名验证其完整性和来源合法性。这确保了系统运行的都是经过授权的、未被篡改的代码。网络隔离与防火墙在车载以太网等高速网络架构中必须通过交换机或网关的硬件防火墙严格限制不同网络域如娱乐域、驾驶域之间的通信防止攻击从信息娱乐系统渗透到动力控制系统。功能安全和信息安全必须协同设计。例如一个安全关键的控制指令如刹车既要通过功能安全机制确保指令执行可靠不因硬件故障出错也要通过信息安全机制确保指令来源可信不被黑客恶意注入。3. 感知系统的进化从“单科状元”到“全能融合”自动驾驶的“眼睛”和“耳朵”就是传感器主要包括摄像头、雷达Radar、激光雷达LiDAR。早期的ADAS功能比较单一比如用摄像头做车道线识别LDW用雷达做自适应巡航ACC基本是各干各的也就是“无融合”或“弱融合”。但到了L2及以上级别必须进行传感器融合因为没有任何一种传感器是完美的。3.1 三大传感器的能力象限与互补性我们可以用一个简单的表格来对比它们的特点传感器优势劣势在融合中的角色摄像头高分辨率丰富的纹理和颜色信息擅长分类识别车、人、标志牌、交通灯。成本相对较低。受光照、天气影响极大夜间、逆光、雾霾。无法直接测距。提供“是什么”的语义信息。是环境理解的核心。雷达毫米波直接测量距离、速度、角度精度高。全天候工作穿透雨、雾、灰尘。分辨率低传统雷达难以识别物体轮廓和类型。对静止物体不敏感易过滤掉。提供“在哪里、有多快”的精确物理信息。是测速和测距的主力。激光雷达生成高精度3D点云能精确描绘物体轮廓和地形。成本高昂在极端天气大雨、浓雾下性能下降。提供高精度的3D环境建模是定位和地图构建的关键。所以一个强大的感知系统会让摄像头告诉系统“前方50米有个物体看起来是行人”同时雷达确认“确实在50米处相对速度5km/h”激光雷达则勾勒出这个行人的精确三维轮廓。这种多源信息交叉验证能极大提升感知的准确性和鲁棒性。3.2 专用处理芯片的崛起以NXP S32R和S32V为例海量的原始传感器数据尤其是摄像头的高清视频流和雷达的原始回波数据对处理能力提出了变态的要求。通用CPU根本吃不消于是专用处理器ASIC或高度优化的处理器成为必然选择。雷达信号处理专家S32R系列传统雷达ECU需要多颗芯片一颗MCU做控制一颗DSP或FPGA做雷达信号处理FFT、滤波、CFAR检测等。NXP的S32R系列将这些高度集成。以S32R45为例它内置了强大的雷达处理加速器SPT专门用于处理雷达中频IF信号进行快速傅里叶变换等运算其性能功耗比远超“通用CPU外挂DSP”的方案。更重要的是它从设计之初就考虑了功能安全支持锁步核、ASIL D并集成了HSM和千兆以太网接口为成像雷达这种下一代高分辨率雷达铺平了道路。成像雷达能提供接近激光雷达的点云密度是未来传感器融合的关键一环。视觉与AI处理核心S32V系列视觉处理流水线非常复杂图像信号处理ISP负责降噪、HDR、色彩校正、几何变换、然后才是目标检测与识别的AI算法。S32V234这类视觉处理器集成了强大的ISP、CPU集群Arm Cortex-A53和专用的AI加速器如APEX。特别是APEX这类加速器针对卷积神经网络CNN运算进行了硬件级优化能高效运行YOLO、ResNet等目标检测模型实现实时的人、车、标志牌识别。它同样具备功能安全和信息安全特性。实操心得选择感知芯片时不能只看TOPS每秒万亿次运算这个纸面算力。更要关注架构效率和工具链成熟度。比如芯片的AI加速器是否支持你常用的深度学习框架TensorFlow Lite, ONNXISP的调优工具是否易用雷达加速器的算法库是否丰富这些因素直接决定了你的算法落地速度和最终性能。4. 从“感知”到“决策”的桥梁计算平台的架构演进当感知系统告诉我们“周围有什么”之后决策规划系统就要回答“我该怎么办”。这需要更高的抽象思维能力和更复杂的计算包括路径规划、行为预测、运动控制等。这部分的计算负载正在从分散的域控制器向中央计算平台集中。4.1 域集中与中央计算算力的“合纵连横”未来的电子电气架构EEA可以粗略分为三层传感器/执行器层负责数据采集和最终执行。这一层趋向于简单化、标准化。区域控制器Zonal层按物理位置划分如左前、右前负责本区域传感器的数据初步聚合和本区域执行器的驱动简化线束。中央计算平台层这是真正的“大脑”。它接收来自所有区域控制器的融合后数据进行全局的感知融合、高精定位、决策规划并将控制指令下发。NXP与Kalray合作的BlueBox就是这类中央计算平台的典型参考设计。它可能包含高性能通用计算单元如NXP的Layerscape系列多核Arm处理器负责运行复杂的操作系统、中间件和部分算法。专用AI加速单元如Kalray的MPPA众核处理器专门用于处理感知模型目标检测、分割等高度并行计算。安全微控制器如NXP的S32系列作为一个独立的安全岛负责运行对功能安全要求最高的控制代码如车辆运动控制并监控整个主计算平台的状态。即使主平台软件崩溃安全岛也能接管车辆执行最小风险策略如安全靠边停车。4.2 软件定义汽车与可扩展性硬件架构在演进软件更是核心。未来的汽车软件将是分层、解耦的底层硬件抽象层BSP、操作系统如QNX、Linux Auto、中间件如ROS2、AUTOSAR Adaptive。中间层感知、定位、规划、控制等核心算法模块。上层具体的应用功能如高速领航、自动泊车。这种架构的好处是可扩展性。就像NXP强调的从基础的NCAP功能AEB、LKA到L2的领航辅助再到L4的自动驾驶开发者可以基于同一套硬件平台如S32处理器家族和软件框架通过增加传感器、升级软件算法来平滑演进而不需要每次都重新设计硬件。这极大地保护了投资加快了开发节奏。踩过的坑在这样复杂的异构计算平台上数据流和任务调度是性能瓶颈的重灾区。摄像头数据如何零拷贝地送到AI加速器CPU、GPU、加速器之间的内存如何共享不同安全等级的任务如何隔离这些问题必须在架构设计初期就通盘考虑。我们曾经在一个项目上因为内存带宽规划不足导致AI推理结果无法及时送达到规划模块造成了数百毫秒的延迟这对于高速行驶的车辆是致命的。5. 开发流程与验证通往安全的漫漫长路有了先进的芯片和架构并不等于就有了安全的自动驾驶系统。开发流程的严谨性同样至关重要尤其是遵循**功能安全ISO 26262和预期功能安全SOTIF, ISO 21448**的流程。5.1 V模型开发与持续验证汽车软件开发普遍遵循V模型。左边是需求分解和设计右边是集成和测试。对于ASIL D级别的功能要求有非常严格的测试覆盖率如MC/DC修正条件/判定覆盖确保每一行代码、每一个分支逻辑都被测试到。这需要强大的仿真和测试工具链支持包括模型在环MIL在Simulink等环境中验证算法模型。软件在环SIL将生成的代码在PC上运行测试。硬件在环HIL将真实ECU接入仿真环境模拟传感器输入和执行器反馈进行极端场景和故障注入测试。实车路试最终在真实道路上积累里程覆盖长尾场景。5.2 应对“未知的未知”SOTIF的重要性ISO 26262主要解决系统“失效”导致的风险。但自动驾驶很多事故源于性能不足而非失效。比如在极端光照下视觉算法就是识别不出一个穿着特殊颜色衣服的行人这算“失效”吗不算但它导致了危险。这就是SOTIF要解决的问题。SOTIF关注的是在没有故障的情况下由于设计局限或环境干扰系统可能产生的危险。其核心工作是识别和评估潜在的危险场景特别是那些罕见但危险的“长尾场景”。通过改进系统设计如增加传感器冗余、改进算法和定义操作域ODD来降低风险。通过海量的测试和验证来证明剩余风险是可接受的。这催生了对场景库和仿真测试的巨大需求。我们需要在虚拟世界中构建数百万甚至数十亿公里的驾驶场景包括各种极端、 corner case来“喂养”和测试我们的系统。个人体会自动驾驶的开发越来越像一场“数据驱动”和“安全流程驱动”的双重马拉松。算法工程师追求极致的感知精度和规划拟人度而系统安全工程师则用严苛的标准审视每一个环节。两者必须紧密协作。最有效的沟通方式就是一起基于具体的、量化的场景Scenario进行讨论而不是空谈技术指标。例如不要说“我们的识别率99.9%”而要说“在黄昏时分前方100米有横穿马路的行人我们的系统能在80米处稳定识别并触发AEB制动减速度达到0.8g”。这样所有人的目标才是一致的。
汽车电子架构演进：从分布式ECU到中央计算平台的安全挑战与实现
发布时间：2026/6/25 16:40:26
1. 从“辅助”到“自主”汽车电子架构的十字路口干了十几年汽车电子我亲眼看着车里的控制器从几个变成了几十个功能从简单的车窗升降变成了能自己刹车、自己转弯。这两年跟同行聊话题总绕不开ADAS和自动驾驶。这不仅仅是多了几个功能那么简单它正在把整个汽车的“大脑”和“神经系统”彻底重写一遍。过去那种一个功能对应一个“小黑盒”ECU的分布式架构就像老式收音机里塞满了各种独立功能的电路板现在已经玩不转了。为什么想象一下要实现自动紧急制动AEB你的车需要同时“看”到前方的障碍物摄像头还要“感知”到它的距离和相对速度雷达。在传统的架构里摄像头和雷达可能各自有一个ECU处理数据得出“前方有车”和“距离50米速度差30km/h”的结论然后再把这两个结论发给另一个负责决策的ECU。这个过程中数据来回传输有延迟不同供应商的ECU之间通信可能还有兼容性问题更别提对海量原始数据进行融合处理的算力要求了。这就像让几个只说方言的人通过写信来协作完成一个紧急任务效率低容易出错而且很难升级。所以行业正在向域控制器和中央计算架构演进。简单说就是把功能相近的“小黑盒”合并成几个功能强大的“大脑分区”域比如车身域、动力域而最核心的感知、决策任务则交给一个或几个性能怪兽级的中央计算平台。这种转变的核心驱动力就是为了应对ADAS和自动驾驶带来的三大挑战海量数据处理、硬核的功能安全Functional Safety要求以及不可或缺的信息安全Security。今天我就结合NXP这类一线芯片厂商的方案来拆解一下这个从感知到决策的安全架构到底是怎么一步步构建起来的里面有哪些门道和坑。2. 安全是底线而非特性功能安全与信息安全的双重挑战在聊具体的技术之前我们必须先确立一个共识对于ADAS和自动驾驶安全不是“加分项”而是“入场券”和“生命线”。这里的安全是两层意思功能安全和信息安全。很多刚入行的朋友容易混淆其实它们防范的是两种完全不同性质的“失效”。2.1 功能安全如何应对“非恶意”的失效功能安全关注的是系统在发生随机硬件故障或系统性故障时如何避免导致人身伤害的风险。它的核心标准是ISO 26262。你可以把它理解成汽车的“抗灾应急预案”。它不是要求系统100%不出故障这在物理上不可能而是要求系统在故障发生时能进入或维持在一个安全的状态。这里的关键量化工具是汽车安全完整性等级ASIL。ASIL从A到D等级越高要求越严苛。它由三个因素决定严重度S如果危害发生会造成多严重的伤害从轻伤到致命。暴露率E车辆运行在可能导致危害的场景下的概率有多高可控性C驾驶员或其他交通参与者能否通过及时反应来避免事故例如高速公路上自适应巡航ACC系统的意外加速故障其严重度很高S3暴露率也高E4可控性在高速下较低C3。综合评估下来这个功能就可能需要达到ASIL D等级这是最高的安全要求。要达到ASIL D芯片和系统设计上就要下血本。比如处理器内核需要锁步Lockstep运行一个内核干活另一个完全相同的内核同步执行同样的指令实时比较结果。一旦出现不一致立刻触发安全机制如关闭输出、进入安全状态。内存需要带ECC纠错通信总线需要冗余和校验。NXP的S32系列处理器家族从微控制器到高性能处理器都按照这个理念设计提供可扩展的安全支持让开发者能基于同一套架构开发从ASIL B到ASIL D的不同应用。注意功能安全的开发成本极高。它不仅仅是硬件上的冗余更贯穿整个开发流程——从需求、设计、编码、测试到生产都需要遵循一套严苛的流程和文档体系。对于初创团队或从消费电子转过来的团队这是第一个需要补课和适应的高门槛。2.2 信息安全筑起抵御“恶意攻击”的防火墙如果说功能安全防的是“天灾”那信息安全防的就是“人祸”。一辆联网的、具备自动驾驶能力的汽车其攻击面大大增加远程车联网T-Box、蓝牙/Wi-Fi、甚至轮胎压力监测系统TPMS都可能成为黑客的入口。攻击的动机也很多样窃取用户隐私数据、勒索软件、甚至远程操控车辆。信息安全的目标是CIA三元组保密性Confidentiality、完整性Integrity、可用性Availability。在汽车上具体表现为防止未经授权的访问和控制确保黑客不能通过远程漏洞接管你的方向盘或刹车。保护数据隐私车辆采集的摄像头数据、行驶轨迹、个人习惯等信息必须加密存储和传输。保障系统可用性防止拒绝服务攻击导致关键ADAS功能失灵。实现这些需要一整套从硬件到软件的安全架构硬件安全模块HSM这是芯片里的“保险箱”。NXP的处理器通常集成高性能的HSM用于安全存储密钥、执行加密解密运算如AES, SHA, RSA、进行安全启动。所有关键的安全操作都在这个隔离的、防篡改的硬件环境中进行即使主系统被攻破密钥也不会泄露。安全启动与信任链从芯片上电第一行代码开始每一级软件Bootloader、操作系统、应用在加载前都要用数字签名验证其完整性和来源合法性。这确保了系统运行的都是经过授权的、未被篡改的代码。网络隔离与防火墙在车载以太网等高速网络架构中必须通过交换机或网关的硬件防火墙严格限制不同网络域如娱乐域、驾驶域之间的通信防止攻击从信息娱乐系统渗透到动力控制系统。功能安全和信息安全必须协同设计。例如一个安全关键的控制指令如刹车既要通过功能安全机制确保指令执行可靠不因硬件故障出错也要通过信息安全机制确保指令来源可信不被黑客恶意注入。3. 感知系统的进化从“单科状元”到“全能融合”自动驾驶的“眼睛”和“耳朵”就是传感器主要包括摄像头、雷达Radar、激光雷达LiDAR。早期的ADAS功能比较单一比如用摄像头做车道线识别LDW用雷达做自适应巡航ACC基本是各干各的也就是“无融合”或“弱融合”。但到了L2及以上级别必须进行传感器融合因为没有任何一种传感器是完美的。3.1 三大传感器的能力象限与互补性我们可以用一个简单的表格来对比它们的特点传感器优势劣势在融合中的角色摄像头高分辨率丰富的纹理和颜色信息擅长分类识别车、人、标志牌、交通灯。成本相对较低。受光照、天气影响极大夜间、逆光、雾霾。无法直接测距。提供“是什么”的语义信息。是环境理解的核心。雷达毫米波直接测量距离、速度、角度精度高。全天候工作穿透雨、雾、灰尘。分辨率低传统雷达难以识别物体轮廓和类型。对静止物体不敏感易过滤掉。提供“在哪里、有多快”的精确物理信息。是测速和测距的主力。激光雷达生成高精度3D点云能精确描绘物体轮廓和地形。成本高昂在极端天气大雨、浓雾下性能下降。提供高精度的3D环境建模是定位和地图构建的关键。所以一个强大的感知系统会让摄像头告诉系统“前方50米有个物体看起来是行人”同时雷达确认“确实在50米处相对速度5km/h”激光雷达则勾勒出这个行人的精确三维轮廓。这种多源信息交叉验证能极大提升感知的准确性和鲁棒性。3.2 专用处理芯片的崛起以NXP S32R和S32V为例海量的原始传感器数据尤其是摄像头的高清视频流和雷达的原始回波数据对处理能力提出了变态的要求。通用CPU根本吃不消于是专用处理器ASIC或高度优化的处理器成为必然选择。雷达信号处理专家S32R系列传统雷达ECU需要多颗芯片一颗MCU做控制一颗DSP或FPGA做雷达信号处理FFT、滤波、CFAR检测等。NXP的S32R系列将这些高度集成。以S32R45为例它内置了强大的雷达处理加速器SPT专门用于处理雷达中频IF信号进行快速傅里叶变换等运算其性能功耗比远超“通用CPU外挂DSP”的方案。更重要的是它从设计之初就考虑了功能安全支持锁步核、ASIL D并集成了HSM和千兆以太网接口为成像雷达这种下一代高分辨率雷达铺平了道路。成像雷达能提供接近激光雷达的点云密度是未来传感器融合的关键一环。视觉与AI处理核心S32V系列视觉处理流水线非常复杂图像信号处理ISP负责降噪、HDR、色彩校正、几何变换、然后才是目标检测与识别的AI算法。S32V234这类视觉处理器集成了强大的ISP、CPU集群Arm Cortex-A53和专用的AI加速器如APEX。特别是APEX这类加速器针对卷积神经网络CNN运算进行了硬件级优化能高效运行YOLO、ResNet等目标检测模型实现实时的人、车、标志牌识别。它同样具备功能安全和信息安全特性。实操心得选择感知芯片时不能只看TOPS每秒万亿次运算这个纸面算力。更要关注架构效率和工具链成熟度。比如芯片的AI加速器是否支持你常用的深度学习框架TensorFlow Lite, ONNXISP的调优工具是否易用雷达加速器的算法库是否丰富这些因素直接决定了你的算法落地速度和最终性能。4. 从“感知”到“决策”的桥梁计算平台的架构演进当感知系统告诉我们“周围有什么”之后决策规划系统就要回答“我该怎么办”。这需要更高的抽象思维能力和更复杂的计算包括路径规划、行为预测、运动控制等。这部分的计算负载正在从分散的域控制器向中央计算平台集中。4.1 域集中与中央计算算力的“合纵连横”未来的电子电气架构EEA可以粗略分为三层传感器/执行器层负责数据采集和最终执行。这一层趋向于简单化、标准化。区域控制器Zonal层按物理位置划分如左前、右前负责本区域传感器的数据初步聚合和本区域执行器的驱动简化线束。中央计算平台层这是真正的“大脑”。它接收来自所有区域控制器的融合后数据进行全局的感知融合、高精定位、决策规划并将控制指令下发。NXP与Kalray合作的BlueBox就是这类中央计算平台的典型参考设计。它可能包含高性能通用计算单元如NXP的Layerscape系列多核Arm处理器负责运行复杂的操作系统、中间件和部分算法。专用AI加速单元如Kalray的MPPA众核处理器专门用于处理感知模型目标检测、分割等高度并行计算。安全微控制器如NXP的S32系列作为一个独立的安全岛负责运行对功能安全要求最高的控制代码如车辆运动控制并监控整个主计算平台的状态。即使主平台软件崩溃安全岛也能接管车辆执行最小风险策略如安全靠边停车。4.2 软件定义汽车与可扩展性硬件架构在演进软件更是核心。未来的汽车软件将是分层、解耦的底层硬件抽象层BSP、操作系统如QNX、Linux Auto、中间件如ROS2、AUTOSAR Adaptive。中间层感知、定位、规划、控制等核心算法模块。上层具体的应用功能如高速领航、自动泊车。这种架构的好处是可扩展性。就像NXP强调的从基础的NCAP功能AEB、LKA到L2的领航辅助再到L4的自动驾驶开发者可以基于同一套硬件平台如S32处理器家族和软件框架通过增加传感器、升级软件算法来平滑演进而不需要每次都重新设计硬件。这极大地保护了投资加快了开发节奏。踩过的坑在这样复杂的异构计算平台上数据流和任务调度是性能瓶颈的重灾区。摄像头数据如何零拷贝地送到AI加速器CPU、GPU、加速器之间的内存如何共享不同安全等级的任务如何隔离这些问题必须在架构设计初期就通盘考虑。我们曾经在一个项目上因为内存带宽规划不足导致AI推理结果无法及时送达到规划模块造成了数百毫秒的延迟这对于高速行驶的车辆是致命的。5. 开发流程与验证通往安全的漫漫长路有了先进的芯片和架构并不等于就有了安全的自动驾驶系统。开发流程的严谨性同样至关重要尤其是遵循**功能安全ISO 26262和预期功能安全SOTIF, ISO 21448**的流程。5.1 V模型开发与持续验证汽车软件开发普遍遵循V模型。左边是需求分解和设计右边是集成和测试。对于ASIL D级别的功能要求有非常严格的测试覆盖率如MC/DC修正条件/判定覆盖确保每一行代码、每一个分支逻辑都被测试到。这需要强大的仿真和测试工具链支持包括模型在环MIL在Simulink等环境中验证算法模型。软件在环SIL将生成的代码在PC上运行测试。硬件在环HIL将真实ECU接入仿真环境模拟传感器输入和执行器反馈进行极端场景和故障注入测试。实车路试最终在真实道路上积累里程覆盖长尾场景。5.2 应对“未知的未知”SOTIF的重要性ISO 26262主要解决系统“失效”导致的风险。但自动驾驶很多事故源于性能不足而非失效。比如在极端光照下视觉算法就是识别不出一个穿着特殊颜色衣服的行人这算“失效”吗不算但它导致了危险。这就是SOTIF要解决的问题。SOTIF关注的是在没有故障的情况下由于设计局限或环境干扰系统可能产生的危险。其核心工作是识别和评估潜在的危险场景特别是那些罕见但危险的“长尾场景”。通过改进系统设计如增加传感器冗余、改进算法和定义操作域ODD来降低风险。通过海量的测试和验证来证明剩余风险是可接受的。这催生了对场景库和仿真测试的巨大需求。我们需要在虚拟世界中构建数百万甚至数十亿公里的驾驶场景包括各种极端、 corner case来“喂养”和测试我们的系统。个人体会自动驾驶的开发越来越像一场“数据驱动”和“安全流程驱动”的双重马拉松。算法工程师追求极致的感知精度和规划拟人度而系统安全工程师则用严苛的标准审视每一个环节。两者必须紧密协作。最有效的沟通方式就是一起基于具体的、量化的场景Scenario进行讨论而不是空谈技术指标。例如不要说“我们的识别率99.9%”而要说“在黄昏时分前方100米有横穿马路的行人我们的系统能在80米处稳定识别并触发AEB制动减速度达到0.8g”。这样所有人的目标才是一致的。
