1. 功能安全架构设计的整体思路拆解1.1 为什么“失效可运行”是架构设计的核心命题聊到功能安全的架构设计尤其是落到自动驾驶这个场景里有一个词是绕不开的失效可运行。很多刚接触ISO 26262的朋友容易把“失效可运行”和“故障容错”混为一谈其实两者有本质区别。故障容错的目标是系统在出现故障后仍能维持原有功能而失效可运行的目标更务实——系统在检测到故障后主动降级到一个安全状态但这个安全状态不是简单粗暴地断电停机而是保留最低限度的可控能力让车辆能够靠边停车或者由驾驶员接管。为什么这个区别在自动驾驶里如此关键因为一辆时速120公里行驶在高速上的车如果因为某个传感器失效就直接切断动力输出后果是灾难性的。所以架构设计的第一性原理就是任何单点失效都不能导致整车失去可控性。这句话听起来简单但落到具体设计上涉及传感器冗余、计算平台冗余、执行器冗余、电源冗余、通信冗余等一整条链路。我在实际项目中总结出一个判断标准如果一个失效模式发生后系统还能在500毫秒内进入一个“车辆可控、驾驶员可接管”的状态那这个架构就是合格的。500毫秒这个数字不是拍脑袋来的它来自对驾驶员反应时间和车辆动力学特性的综合考量——以120km/h计算500毫秒车辆已经行驶了约16.7米这已经是能接受的极限了。1.2 冗余设计的三种典型架构模式在功能安全的架构设计中冗余不是简单地“搞两套”而是要根据ASIL等级和安全目标来选择合适的冗余模式。我把它归纳为三种典型模式第一种是双冗余热备份。两套完全独立的系统同时运行主系统输出结果从系统同步计算但不输出。一旦主系统失效从系统在极短时间内接管。这种模式可靠性最高但成本也最高通常用在L3以上的自动驾驶计算平台中。双冗余的关键难点不在于硬件堆叠而在于故障检测的实时性和切换的确定性。我见过不少项目硬件是双套的但故障检测逻辑写得稀烂主系统都跑飞了从系统还不知道这就白搭了。第二种是异构冗余。两套系统采用不同的硬件架构、不同的软件实现甚至不同的算法原理。比如一套用规则算法另一套用端到端神经网络。这种模式的核心价值在于避免共因失效。你想想如果两套系统用的是同一款芯片、同一套代码那芯片的一个设计缺陷就可能同时干掉两套系统。异构冗余就是用来防这个的。但异构冗余的代价是开发成本翻倍而且两套系统的输出仲裁逻辑非常难写。第三种是降级冗余。系统检测到故障后不是切换到另一套完整系统而是关闭部分非关键功能保留核心安全功能。比如自动驾驶系统失效后保留车道保持和紧急制动但关闭自动变道和导航辅助。这种模式成本最低但安全目标的覆盖范围也最窄适合L2级别的系统。注意选择哪种冗余模式不能拍脑袋决定必须从HARA危害分析与风险评估出发先确定安全目标和ASIL等级再反推架构方案。我见过太多项目是先定架构再补安全分析结果做到一半发现ASIL等级根本达不到只能推倒重来。1.3 从ASIL等级反推架构约束ASIL等级是功能安全架构设计的“宪法”它直接决定了你能用什么架构、不能用什么架构。ASIL D要求单点失效覆盖率超过99%这意味着任何单点失效都不能导致安全目标违背。ASIL B就宽松很多允许一定的单点失效只要不影响安全目标即可。这里有一个很实用的经验公式ASIL等级每降一级架构复杂度大约可以降低40%。ASIL D通常需要双冗余甚至三冗余架构ASIL B可能只需要单套系统加一些诊断措施。所以在项目初期一定要把ASIL等级定准定高了浪费成本定低了过不了认证。我参与过一个L2项目最初HARA分析给出的ASIL等级是B架构方案是单套计算平台加冗余传感器。后来因为增加了自动变道功能重新评估后发现自动变道场景下的ASIL等级升到了D整个架构方案不得不推倒重来增加了第二套计算平台和冗余电源。这个教训告诉我们功能定义的变化会直接冲击架构设计所以在架构设计阶段就要预留一定的扩展余量。2. 核心细节解析与实操要点2.1 传感器冗余的配置策略与失效检测传感器是自动驾驶系统的“眼睛”也是失效概率最高的环节之一。摄像头怕逆光、怕雨雾毫米波雷达怕金属反射激光雷达怕脏污。所以传感器冗余的核心思路是用不同物理原理的传感器互相补位。具体怎么配我的经验是前向感知至少要有摄像头毫米波雷达的组合。摄像头负责识别车道线、交通标志、车辆类型毫米波雷达负责测距测速两者数据融合后能大幅降低误判率。如果预算允许再加一个激光雷达做真值校验那就是三重冗余了。但传感器冗余不是装上就完事了关键在于失效检测。摄像头的失效检测相对容易可以通过图像质量评估、帧率监控、曝光异常检测来判断。毫米波雷达的失效检测就麻烦一些因为它输出的点云数据本身就有噪声你很难区分“雷达坏了”和“当前场景就是没有目标”。我的做法是引入跨传感器一致性校验如果摄像头看到了前方有车但毫米波雷达在对应位置没有检测到任何目标且这种不一致持续超过200毫秒就触发传感器失效告警。这里有一个实操中的坑传感器的时间同步。不同传感器的采样频率不同摄像头可能是30帧毫米波雷达可能是20帧激光雷达可能是10帧。如果时间戳对齐没做好融合算法就会把不同时刻的数据当成同一时刻的导致误判。我的建议是统一用PTP精确时间协议做硬件级时间同步精度控制在1毫秒以内。2.2 计算平台冗余的故障切换机制计算平台是自动驾驶的“大脑”一旦失效整个系统就瘫痪了。所以L3以上的系统基本都要求双计算平台冗余。但双平台怎么切换这里面的门道很多。主从热备份模式是最常见的方案。主平台运行完整的感知、决策、控制算法从平台同步运行但输出被屏蔽。主平台通过心跳信号定期向从平台发送“我还活着”的消息从平台如果连续丢失3个心跳周期通常每个周期10毫秒就判定主平台失效立即接管输出。这个方案听起来简单但有一个致命问题如果主平台没有完全死掉而是输出了错误的结果怎么办比如主平台的决策模块因为内存位翻转输出了一个“向左打方向盘”的错误指令但心跳信号还在正常发送。这时候从平台如果只是傻等心跳丢失就会错过最佳接管时机。所以更完善的做法是引入输出校验机制。从平台不仅监控主平台的心跳还要对比两者的决策输出。如果两者输出差异超过阈值且持续超过一定时间就触发切换。但这里又有一个问题如果两个平台用的是同一套算法那它们很可能同时犯同样的错误。这就是为什么异构冗余在高级别自动驾驶中越来越受重视。我在实际项目中采用过一个折中方案主平台用规则算法从平台用轻量级的神经网络算法。两者输出做加权仲裁如果差异小于阈值以主平台为准如果差异大于阈值降级到安全策略比如靠边停车。这个方案的好处是既避免了共因失效又不需要两套完全不同的硬件。2.3 执行器冗余与电源冗余的工程实现执行器冗余是很多人容易忽略的环节。你感知再准、决策再对如果执行器失效了车还是控制不住。制动和转向是两大核心执行器都必须做冗余。制动冗余的典型方案是电子制动机械制动备份。正常情况用电子制动比如ESC如果电子制动失效驾驶员还能通过机械液压制动减速。但这里有一个问题自动驾驶模式下驾驶员可能不在驾驶位上机械制动就没人踩了。所以更高级的方案是双电子制动回路两套独立的电子制动系统互为备份。转向冗余的方案类似通常是双绕组电机。一个电机里有两套独立的绕组一套失效了另一套还能工作。但双绕组电机的控制逻辑很复杂两套绕组之间的力矩分配、故障隔离都需要精心设计。电源冗余是所有这些冗余的基础。如果电源挂了什么冗余都没用。所以自动驾驶系统通常要求双电源供电一路来自车辆主电池一路来自备用电池或超级电容。两路电源通过理想二极管做隔离任何一路失效都不会影响另一路。这里的关键参数是备用电源的续航时间至少要能支撑系统完成一次安全停车通常要求不少于10秒。提示电源冗余的切换时间非常关键。如果切换时间超过10毫秒计算平台就可能因为掉电而重启那就不是“失效可运行”而是“失效即宕机”了。所以理想二极管的选型和电路布局要特别讲究。3. 实操过程与核心环节实现3.1 从HARA到安全目标的完整推导流程功能安全架构设计不是从画框图开始的而是从HARA危害分析与风险评估开始的。这个流程我走过很多遍总结下来大概是这样的第一步是场景识别。把自动驾驶系统可能遇到的所有场景列出来比如高速公路巡航、城市拥堵跟车、自动泊车、紧急避障等。每个场景都要考虑正常工况和异常工况。第二步是危害识别。针对每个场景分析系统失效可能导致什么危害。比如高速公路巡航场景下如果前向感知失效可能导致追尾如果转向执行器失效可能导致车辆失控。第三步是风险评估。对每个危害从严重度S、暴露率E、可控性C三个维度打分。严重度从S0到S3暴露率从E0到E4可控性从C0到C3。然后查表得出ASIL等级。第四步是安全目标定义。针对每个ASIL等级较高的危害定义安全目标。比如“防止非预期的制动”对应ASIL D“防止非预期的转向”对应ASIL D。第五步是功能安全概念。把安全目标分解到各个功能模块确定每个模块的安全需求。比如“防止非预期的制动”可以分解为“制动指令必须经过双通道校验”、“制动执行器必须支持独立关断”等。这个流程走下来通常需要2-3周的时间取决于系统的复杂度。我见过有些团队为了赶进度HARA做得非常粗糙结果到了架构设计阶段发现安全目标根本没法分解只能返工。所以HARA的投入是值得的它是整个功能安全的地基。3.2 双冗余架构的详细设计与参数计算假设我们要设计一个满足ASIL D要求的自动驾驶计算平台双冗余架构的具体设计如下硬件层面两套完全独立的计算平台每套包含SoC、MCU、内存、存储、电源模块。两套平台之间通过高速以太网和CAN FD双通道通信。每套平台都有独立的电源输入来自车辆的双电源系统。软件层面主平台运行完整的感知、融合、决策、控制算法。从平台运行相同的算法但输出被屏蔽。两套平台通过心跳信号和输出校验双重机制进行故障检测。切换逻辑主平台每10毫秒发送一次心跳从平台连续丢失3次心跳即30毫秒后触发切换。同时从平台每50毫秒对比一次决策输出如果差异超过阈值且持续100毫秒也触发切换。切换时间要求小于100毫秒确保车辆在失效后200毫秒内进入安全状态。关键参数计算假设车辆时速120公里即33.3米/秒。200毫秒的响应时间内车辆行驶约6.7米。这个距离在高速公路上是可以接受的因为通常跟车距离在50米以上。但如果时速提高到150公里200毫秒就是8.3米就需要更快的响应时间或者更长的跟车距离。这里有一个经验值ASIL D系统的故障检测时间通常要求在10-50毫秒之间切换时间要求在50-100毫秒之间。这两个时间加起来就是系统从失效到恢复可控的总时间。这个总时间必须小于安全目标中定义的最大允许时间。3.3 失效检测与切换的代码实现要点失效检测和切换逻辑通常运行在MCU上而不是SoC上。因为MCU的实时性更好而且不受SoC上复杂操作系统的影响。下面是一个简化的心跳检测和切换逻辑的伪代码// 心跳检测任务每10毫秒执行一次 void heartbeat_check_task(void) { static uint8_t lost_count 0; if (receive_heartbeat_from_primary()) { lost_count 0; // 心跳正常继续监控 } else { lost_count; if (lost_count 3) { // 连续丢失3次心跳触发切换 trigger_failover(); lost_count 0; } } } // 输出校验任务每50毫秒执行一次 void output_check_task(void) { static uint8_t mismatch_count 0; float primary_output get_primary_decision(); float secondary_output get_secondary_decision(); if (fabs(primary_output - secondary_output) THRESHOLD) { mismatch_count; if (mismatch_count 2) { // 连续2次输出不一致触发切换 trigger_failover(); mismatch_count 0; } } else { mismatch_count 0; } }这段代码看起来简单但实际实现中有几个坑第一心跳信号的传输必须走独立通道不能和正常数据走同一条总线否则总线故障会导致心跳和数据同时丢失。第二切换逻辑本身必须是安全的如果切换逻辑自己失效了那就全完了。所以切换逻辑通常要做成硬件看门狗软件双重校验。第三切换后的状态初始化要快从平台接管后不能从头开始计算必须利用之前同步的状态数据快速进入控制循环。注意失效检测的阈值不能设得太敏感否则容易误触发。我见过一个项目因为阈值设得太小车辆过减速带时的振动导致传感器数据短暂异常系统就误判为传感器失效频繁触发降级。后来把阈值调大了30%才解决。所以阈值的设定一定要结合实际路测数据来调。4. 常见问题与排查技巧实录4.1 冗余系统共因失效的排查与预防共因失效是冗余架构最大的敌人。你搞了两套系统结果一个原因同时干掉两套那冗余就白做了。共因失效的典型来源包括同一款芯片的设计缺陷、同一套软件的逻辑错误、同一路电源的波动、同一环境因素如温度、振动、电磁干扰。排查共因失效我的经验是从物理层、硬件层、软件层、系统层四个层面逐一分析物理层两套系统是否共享了同一个连接器、同一根线束、同一个接地点如果是那这个连接器或线束的失效就会同时影响两套系统。解决方案是物理隔离两套系统的线束走向要分开接地点要独立。硬件层两套系统是否用了同一批次的芯片如果是那这批芯片的批次性缺陷就会同时影响两套系统。解决方案是异构选型比如主平台用NXP的芯片从平台用TI的芯片。软件层两套系统是否用了同一个编译器、同一个RTOS、同一个中间件如果是那这些基础软件的bug就会同时影响两套系统。解决方案是软件栈异构或者至少对基础软件做独立的验证和确认。系统层两套系统是否依赖了同一个外部信号比如两套系统都用同一个轮速传感器来估计车速那这个传感器失效就会同时影响两套系统。解决方案是信号源冗余或者对关键信号做交叉校验。我整理了一个共因失效排查的速查表在实际项目中很实用排查层面典型共因排查方法预防措施物理层共享连接器/线束检查线束走向和接地点物理隔离独立走线硬件层同批次芯片检查芯片批次号异构选型不同供应商软件层同编译器/RTOS检查软件栈配置软件栈异构或独立验证系统层共享信号源检查信号依赖关系信号源冗余或交叉校验环境层温度/振动/EMI环境测试和仿真独立屏蔽和散热设计4.2 故障切换过程中的常见异常与处理故障切换听起来很干脆——主系统挂了从系统接管。但实际做起来切换过程中会出现各种意想不到的异常。我遇到过几个典型的第一个是切换抖动。主系统因为瞬时故障触发了切换从系统刚接管主系统又恢复正常了结果两个系统来回切换车辆控制指令也跟着来回跳。这种抖动比单纯的主系统失效还危险。解决方案是引入切换迟滞一旦切换到从系统就至少在500毫秒内不允许切回主系统除非主系统通过了完整的自检。第二个是状态不同步。从系统虽然一直在同步运行但它的状态和主系统可能有细微差异。比如主系统的车辆位置估计是100.5米从系统是100.3米切换瞬间车辆控制指令就会有一个小跳变。解决方案是状态平滑过渡切换后的前100毫秒控制指令用两套系统的加权平均权重从主系统逐渐过渡到从系统。第三个是切换后性能下降。从系统虽然能接管但它的算力可能不如主系统或者它的算法精度稍低。切换后车辆的控制品质会下降比如跟车距离波动变大、车道保持精度变差。这个问题没有完美的解决方案只能在架构设计阶段就保证从系统的性能不低于主系统的80%。提示故障切换的测试一定要做故障注入。不能只测正常切换还要测切换过程中再发生故障、切换后从系统也失效、切换逻辑本身失效等极端情况。这些极端情况在实车上很难复现通常用HIL硬件在环台架来测。4.3 功能安全验证与确认的实操经验功能安全的验证与确认是架构设计的最后一道关卡。验证是证明“你做对了”确认是证明“你做的是对的”。这两件事都不能偷懒。验证阶段我通常分三步走第一步是需求追溯确保每一条安全需求都能追溯到对应的架构设计元素每一条架构设计元素都能追溯到对应的安全需求。第二步是故障注入测试在HIL台架上模拟各种失效模式验证系统的失效检测和切换逻辑是否按预期工作。第三步是覆盖率分析分析单点失效覆盖率、潜伏失效覆盖率是否达到ASIL等级的要求。确认阶段核心是实车测试。实车测试要覆盖HARA中识别的所有场景包括正常场景和异常场景。异常场景的测试尤其重要比如传感器遮挡、通信丢包、电源波动等。实车测试的数据要完整记录用于后续的安全案例Safety Case编制。这里有一个实操中的经验安全案例的编制要贯穿整个开发流程不能等到最后再补。我见过很多项目开发做完了才开始写安全案例结果发现很多证据链缺失只能回头补测试、补文档浪费了大量时间。正确的做法是每个阶段都输出对应的安全证据最后汇总成安全案例。还有一个容易忽略的点功能安全不是一劳永逸的。系统上线后如果发生了任何与安全相关的变更比如软件升级、硬件替换、算法优化都需要重新评估功能安全的影响。我建议建立一个安全变更管理流程任何变更都要经过安全评估确定是否需要重新做HARA、重新验证、重新确认。5. 架构设计的扩展思考与个人体会5.1 从L2到L4架构设计的演进路径功能安全的架构设计不是一成不变的它随着自动驾驶等级的提升而演进。L2级别的架构相对简单通常单套计算平台加冗余传感器就能满足ASIL B的要求。L3级别就需要双计算平台冗余了因为系统要在特定条件下完全接管驾驶任务ASIL等级升到了D。L4级别更复杂不仅需要双计算平台还需要冗余的执行器和冗余的电源而且对失效可运行的要求更高——系统失效后不能只是靠边停车还要能在安全区域内完成停车。我个人的判断是L3是架构设计的分水岭。L2及以下架构设计的核心是“功能实现”L3及以上架构设计的核心是“安全冗余”。这个转变不仅仅是技术上的更是思维上的。做L2的团队转做L3最容易犯的错误就是用L2的思维做L3的架构结果安全冗余做得不到位过不了认证。5.2 成本与安全的平衡艺术功能安全架构设计最难的其实不是技术而是成本与安全的平衡。ASIL D要求的冗余架构成本可能是单套系统的2-3倍。对于量产车来说这个成本压力是巨大的。所以架构设计师要在满足安全目标的前提下尽可能降低成本。我的经验是不是所有环节都需要ASIL D。通过合理的架构分解可以把一部分安全需求分配到ASIL B甚至ASIL A的模块上。比如感知模块可以用ASIL B的摄像头加ASIL B的毫米波雷达通过异构冗余来达到ASIL D的安全目标。这样比直接用ASIL D的传感器成本低很多。另一个降本思路是利用现有量产件。很多执行器本身就有冗余设计比如EPS电动助力转向通常就有双绕组电机你只需要确认它的安全等级是否满足要求不需要重新开发。这样能省下大量的开发成本和时间。5.3 个人在实际项目中的几点体会做了这么多年的功能安全架构设计我有几点体会想分享第一安全不是堆出来的是设计出来的。我见过太多项目硬件堆了一大堆但安全分析做得很粗糙结果认证的时候被审核员问得哑口无言。安全架构的核心是逻辑是安全需求到架构元素的完整追溯是失效模式和影响分析的透彻程度。第二文档和代码一样重要。功能安全认证中文档的权重可能占到40%以上。安全计划、安全概念、安全分析、验证报告、确认报告每一份文档都要经得起推敲。我建议从项目第一天就建立文档模板和评审流程不要等到最后再补。第三测试要趁早故障注入要常态化。不要等到系统集成完了才开始测失效场景那样发现问题就太晚了。我通常要求在模块级就开始做故障注入测试每个模块都要有对应的失效模式测试用例。第四团队的安全文化比工具更重要。功能安全不是安全工程师一个人的事它需要系统、硬件、软件、测试各个团队的协同。如果团队成员没有安全意识再好的工具和流程也白搭。我建议定期做安全培训和案例分享让每个人都理解自己工作的安全意义。最后再分享一个小技巧建立安全案例的“证据地图”。把所有的安全证据测试报告、分析文档、评审记录都映射到安全目标上形成一个可视化的证据链。这样在认证审核时审核员问任何一个安全目标你都能快速找到对应的证据。这个证据地图在项目后期会帮你省下大量的时间。