1. 功能安全架构设计的整体思路拆解1.1 从“失效可运行”说起为什么架构设计是功能安全的核心战场做功能安全这几年我越来越觉得真正决定一个系统能不能过ASIL D、能不能在整车厂那边顺利验收的不是某个单点技术有多先进而是架构设计阶段有没有把“失效”这件事想透。功能安全的架构设计六这个系列走到第六篇其实已经进入了深水区——前面几篇聊了概念阶段的HARA分析、安全目标定义、FSR技术安全需求分解到了架构设计这一层核心问题就变成了当系统真的出问题了它还能不能体面地活着这就是“失效可运行”Fail-Operational要解决的事。传统的Fail-Safe思路是出问题就切到安全状态比如断电、停机、降级到最小功能集。但自动驾驶不一样你没法在高速上跑到120km/h的时候突然说“对不起我失效了请驾驶员接管”——如果驾驶员在睡觉呢如果接管时间不够呢所以自动驾驶的功能安全架构必须做到Fail-Operational也就是部分失效后系统仍然能维持最低限度的安全运行直到驾驶员接管或者车辆安全停车。这个目标听起来简单落到架构上就是一连串硬核决策冗余怎么做、冗余到什么程度、切换逻辑怎么设计、故障检测覆盖率够不够、共因失效怎么防。每一个决策背后都是成本、复杂度、可靠性的三角博弈。我见过太多项目在架构阶段偷懒结果到了集成测试阶段发现单点故障根本绕不过去回头改架构的代价是前期投入的十倍不止。1.2 冗余不是万能药双冗余、三冗余的选型逻辑热词里出现了“双冗余”这确实是功能安全架构设计里最常被提到的方案。但我想先泼一盆冷水冗余不是越多越好关键看你的安全目标要求多高的容错能力。先看一个基本的计算逻辑。假设单通道的失效率是λ那么双通道冗余假设完全独立的失效率大约是λ²。如果λ是10⁻⁵/h双冗余就是10⁻¹⁰/h看起来提升巨大。但现实是两个通道不可能完全独立——它们可能共享电源、共享时钟、共享通信总线这些共享资源就是共因失效Common Cause Failure的温床。所以实际的双冗余系统失效率往往在10⁻⁷到10⁻⁸/h之间比理论值差了两三个数量级。那三冗余呢三取二2oo3架构的容错能力确实更强单通道失效后系统仍然能正常运行而且还能通过多数表决来识别哪个通道出了问题。但代价是什么三个通道的硬件成本、三个通道的同步开销、三个通道的功耗和散热还有更复杂的故障检测和隔离逻辑。我个人的经验是对于ASIL D的自动驾驶系统如果安全目标要求“单点故障后仍能维持运行”双冗余是底线如果要求“单点故障后仍能维持运行且能识别并隔离故障通道”三冗余更稳妥。但具体选哪个还要看你的失效模式分析FMEA结果和共因失效的量化评估。还有一个容易被忽略的点异构冗余 vs 同构冗余。同构冗余就是两个通道用同样的硬件、同样的软件好处是开发成本低坏处是共因失效风险高——同一个软件bug可能同时干掉两个通道。异构冗余则是用不同的硬件平台、不同的软件实现甚至不同的算法共因失效风险大大降低但开发成本和验证复杂度直线上升。我参与过的一个项目最终选择了“同构硬件异构软件”的折中方案两个通道用同样的芯片但一个跑基于规则的控制算法另一个跑基于学习的控制算法这样既控制了硬件成本又避免了软件层面的共因失效。1.3 从HARA到架构安全需求如何驱动设计决策很多刚入行的朋友会问架构设计到底从哪里开始我的答案是从HARA危害分析与风险评估的输出开始。HARA会给你每个危害事件的ASIL等级和安全目标安全目标再分解成功能安全需求FSRFSR再分解成技术安全需求TSRTSR才是架构设计的直接输入。举个例子。假设HARA分析发现“车辆在高速行驶中失去转向能力”这个危害事件的ASIL是D安全目标是“防止车辆在非预期情况下失去转向能力”。这个安全目标分解到FSR层面可能是“系统应在转向系统单点故障时仍能提供至少50%的转向扭矩”。再分解到TSR层面就是“转向系统应采用双冗余架构每个通道应能独立提供至少50%的转向扭矩且故障检测时间应小于100ms”。你看到了TSR这一层架构设计的约束条件已经非常明确了冗余度、性能下限、故障检测时间。架构师要做的就是在这个约束空间里找到最优解。我见过一些团队跳过HARA直接拍脑袋定架构结果要么冗余过度导致成本爆炸要么冗余不足导致安全目标无法达成最后返工重来。2. 核心细节解析与实操要点2.1 故障检测与切换逻辑架构设计中最容易翻车的环节冗余架构搭好了不代表系统就安全了。真正决定系统安全性的是故障检测的覆盖率和切换逻辑的可靠性。我见过太多项目硬件冗余做得很漂亮但故障检测覆盖率只有60%剩下的40%故障根本检测不到系统带着故障继续跑最后出了事才知道。故障检测的核心指标是诊断覆盖率Diagnostic Coverage, DC。ISO 26262对ASIL D的要求是DC ≥ 99%也就是说99%的故障必须被检测到。这个数字听起来很吓人但拆解下来就是单点故障、潜伏故障、共因故障每一类都要有对应的检测机制。具体怎么做我总结了几条实操经验电源监控每个冗余通道的供电电压、电流都要独立监控欠压、过压、纹波异常都要能检测到。我通常会用一颗独立的监控芯片而不是依赖主控芯片的ADC因为主控芯片本身也可能失效。时钟监控双通道的时钟频率偏差超过阈值就要报警。有些方案会用第三个独立时钟源来做交叉校验成本不高但效果很好。通信监控CAN、以太网、FlexRay这些总线要有CRC校验、超时监控、序列号检查。我特别想强调的是端到端保护E2E ProtectionISO 26262 Part 6里有详细规定但很多团队为了省事只做CRC不做序列号和超时结果通信故障检测覆盖率上不去。计算监控双通道的计算结果要交叉比对偏差超过阈值就触发切换。这里有个坑比对逻辑本身也可能失效所以比对逻辑最好放在独立的监控通道里而不是放在主计算通道里。切换逻辑的设计更是一门艺术。理想情况下故障检测到切换完成的时间应该尽可能短但太短了容易误切换太长了又来不及。我的经验值是对于自动驾驶的转向和制动系统故障检测到切换完成的时间应控制在100ms以内对于动力系统可以放宽到200ms。这个时间预算要分解到每个环节传感器采样时间、故障检测算法执行时间、切换决策时间、执行器响应时间每一环都要留够余量。还有一个容易被忽略的点切换后的状态确认。切换完成了不代表切换成功了系统需要确认备用通道真的接管了而且接管后的性能满足要求。我通常会设计一个“切换后验证窗口”比如切换后50ms内持续监控备用通道的输出如果输出异常就触发降级到安全状态。2.2 共因失效分析冗余架构的隐形杀手共因失效Common Cause Failure, CCF是冗余架构最大的敌人。两个通道同时失效的概率虽然低但一旦发生就是灾难性的。ISO 26262 Part 9里专门有一章讲CCF的分析方法但很多团队只是走个形式没有真正把CCF分析结果反馈到架构设计里。CCF的来源主要有几类共享资源电源、时钟、散热、通信总线、机械结构。两个通道共用同一个电源模块电源模块失效两个通道一起挂。环境应力温度、湿度、振动、EMC。两个通道在同一块PCB上局部过热可能同时影响两个通道。设计缺陷软件bug、硬件设计错误、制造工艺问题。同一个软件版本的两个通道同一个bug可能同时触发。人为因素维护操作、装配错误、测试遗漏。针对每一类CCF架构设计都要有对应的缓解措施。我通常会用一张CCF检查表来逐项确认CCF来源缓解措施验证方法共享电源独立电源模块或电源模块冗余故障注入测试共享时钟独立时钟源或时钟交叉校验频率偏差测试共享通信独立通信通道或E2E保护总线故障注入环境应力物理隔离或降额设计环境应力测试设计缺陷异构冗余或独立验证独立VV人为因素防错设计或操作确认过程审核这张表看起来简单但每一项都要有具体的量化指标和验证方法。比如“物理隔离”隔离距离是多少隔离材料是什么隔离效果怎么验证这些都要在架构设计文档里写清楚。2.3 安全机制的设计原则简单、独立、可验证安全机制Safety Mechanism是功能安全架构的执行单元。我见过很多安全机制设计得过于复杂结果验证的时候根本测不过来。我的原则是安全机制要简单、独立、可验证。简单意味着安全机制的逻辑要尽可能简单最好是“if-then”这种确定性逻辑不要引入复杂的算法。我见过一个项目用机器学习来做故障检测结果训练数据偏差导致误报率居高不下最后不得不换回基于阈值的简单检测。独立意味着安全机制不能依赖被监控的功能本身。比如你不能用主控芯片的ADC去监控主控芯片的电源因为主控芯片失效了ADC也失效了。安全机制应该有独立的传感器、独立的计算单元、独立的执行路径。可验证意味着安全机制本身也要能被测试和验证。ISO 26262要求安全机制本身也要有足够的诊断覆盖率不能出现“监控者谁来监控”的问题。我通常会在架构设计阶段就定义好每个安全机制的验证方法比如故障注入测试、边界测试、长时间运行测试。3. 实操过程与核心环节实现3.1 从需求到架构一个双冗余转向系统的设计实例光说理论太虚我拿一个实际做过的双冗余转向系统来拆解。这个项目的安全目标是ASIL D要求“单点故障后仍能提供至少50%的转向扭矩故障检测时间小于100ms”。第一步定义架构边界。我们把转向系统分成三个域传感域、计算域、执行域。传感域包括扭矩传感器、角度传感器、车速传感器计算域包括主控芯片和监控芯片执行域包括电机和驱动电路。第二步冗余分配。传感域采用双冗余两套独立的扭矩传感器和角度传感器信号通过不同的路径进入计算域。计算域采用双通道主控芯片跑控制算法监控芯片跑安全监控和故障检测。执行域采用双绕组电机两个独立的绕组分别由两个独立的驱动电路控制。第三步故障检测设计。每个传感器都有独立的信号调理电路输出通过SPI和CAN两条总线进入计算域。主控芯片和监控芯片交叉比对传感器数据偏差超过5%就触发故障计数。电机电流和位置反馈也做交叉比对偏差超过10%触发切换。第四步切换逻辑设计。故障检测到切换的流程是这样的监控芯片检测到故障后通过独立的GPIO线向主控芯片发送切换请求主控芯片收到请求后在10ms内完成控制权移交备用通道在20ms内接管执行器切换后50ms内持续监控备用通道的输出确认切换成功。第五步共因失效缓解。两个通道的电源来自不同的电源模块时钟来自不同的晶振通信走不同的总线。PCB布局上两个通道的走线物理隔离间距大于5mm。软件层面主控芯片和监控芯片的代码由不同的团队独立开发避免共因软件bug。这个架构最终通过了ASIL D的认证故障检测覆盖率做到了99.2%切换时间实测在80ms左右。但过程中也踩了不少坑后面会详细说。3.2 关键参数计算故障检测覆盖率和切换时间预算故障检测覆盖率DC的计算不是拍脑袋要有量化依据。ISO 26262 Part 5给出了DC的计算方法DC λdd / (λdd λdu)其中λdd是可检测的危险失效速率λdu是不可检测的危险失效速率。假设我们的转向系统单通道的危险失效速率是10⁻⁶/h其中可检测的占99%不可检测的占1%那么DC 0.99。但如果考虑共因失效两个通道同时失效的速率大约是10⁻⁹/h这个值要单独计算并纳入整体安全分析。切换时间预算的分解更考验经验。以100ms的总预算为例传感器采样和信号调理10ms故障检测算法执行20ms切换决策和通信15ms执行器响应30ms切换后验证25ms每一环都要留20%的余量因为实际运行中会有各种抖动和延迟。我见过一个项目把预算卡得太死结果高温环境下执行器响应变慢切换时间超标不得不重新设计。3.3 实操现场记录一次故障注入测试的完整过程故障注入测试是验证功能安全架构的终极手段。我记录了一次典型的测试过程测试目标验证主控芯片失效后系统能否在100ms内切换到备用通道并维持50%的转向扭矩。测试方法用故障注入设备在主控芯片的电源线上注入电压跌落模拟电源失效。测试步骤系统正常运行转向扭矩输出100%。注入电压跌落主控芯片在5ms内检测到欠压。监控芯片在10ms内确认故障发送切换请求。主控芯片在15ms内完成控制权移交。备用通道在35ms内接管执行器转向扭矩输出50%。切换后验证窗口内备用通道输出稳定切换成功。测试结果总切换时间42ms满足100ms的要求。但测试中也发现了一个问题切换瞬间转向扭矩有大约5%的抖动虽然不影响安全但驾驶员能感觉到。后来我们在切换逻辑里加了一个平滑过渡算法抖动降到了1%以内。4. 常见问题与排查技巧实录4.1 故障检测误报和漏报两个极端都要防故障检测最怕两个极端误报和漏报。误报会导致不必要的切换影响可用性漏报会导致故障未被发现影响安全性。误报的常见原因阈值设置过紧正常波动被当成故障。传感器噪声大信号调理不到位。环境应力温度、EMC导致信号漂移。漏报的常见原因诊断覆盖率不足某些故障模式没覆盖到。故障检测算法执行周期太长故障发生后没及时检测到。共因失效导致检测机制本身失效。我的排查技巧是先做FMEA把所有可能的故障模式列出来然后逐一确认检测机制是否覆盖。对于误报我会用实际路测数据来调整阈值而不是拍脑袋定。对于漏报我会用故障注入测试来验证确保每个故障模式都能被检测到。4.2 切换失败和切换抖动切换逻辑的调试经验切换失败通常有几个原因切换请求没送达通信总线故障或者GPIO线接触不良。切换决策没执行主控芯片死机或者切换逻辑有bug。备用通道没准备好备用通道本身有故障或者初始化没完成。切换抖动通常是切换瞬间的控制不连续导致的。我的解决方案是在切换逻辑里加入平滑过渡算法让备用通道的输出逐渐接管而不是瞬间切换。具体做法是切换后的前50ms内备用通道的输出从0逐渐增加到目标值同时主控通道的输出从当前值逐渐减小到0。这样虽然切换时间稍微长一点但驾驶体验好很多。4.3 常见问题速查表问题现象可能原因排查方法解决方案故障检测误报阈值过紧、噪声大路测数据分析调整阈值、增加滤波故障检测漏报DC不足、周期太长故障注入测试增加检测机制、缩短周期切换失败通信故障、逻辑bug切换过程日志分析冗余通信、逻辑审查切换抖动控制不连续切换瞬间数据分析平滑过渡算法共因失效共享资源、设计缺陷CCF分析、故障注入独立资源、异构冗余诊断覆盖率不达标故障模式未覆盖FMEA审查补充检测机制4.4 独家避坑技巧从实际项目中总结的经验坑一不要忽视潜伏故障。潜伏故障是指那些不会立即导致失效但会降低系统安全裕度的故障。比如备用通道的电源模块性能下降平时看不出来但主通道失效时备用通道也撑不住。我的做法是定期对备用通道做自检确保它随时处于可用状态。坑二不要过度依赖软件监控。软件监控本身也可能失效所以关键的安全机制最好有硬件备份。比如电源监控我通常会用独立的监控芯片而不是只靠软件ADC。坑三不要忽略切换后的状态确认。切换完成了不代表切换成功了一定要有切换后验证机制。我见过一个项目切换后没有验证结果备用通道其实没接管系统带着故障继续跑最后出了事。坑四不要低估共因失效的威力。两个通道用同一个供应商的芯片同一个批次的芯片可能有相同的制造缺陷。我的做法是关键芯片用不同供应商的或者至少用不同批次的。坑五不要忘记人为因素。维护操作、装配错误、测试遗漏都可能导致共因失效。我的做法是关键操作要有防错设计比如连接器防插反、软件版本防错刷。5. 架构设计的扩展思考从功能安全到预期功能安全功能安全解决的是“系统失效”导致的风险但自动驾驶还有另一类风险系统没失效但功能不足或性能局限导致的风险。这就是预期功能安全SOTIF要解决的问题。举个例子。功能安全关注的是“摄像头坏了怎么办”SOTIF关注的是“摄像头没坏但逆光条件下识别率下降怎么办”。这两个问题的架构设计思路完全不同功能安全靠冗余和故障检测SOTIF靠场景覆盖和性能边界定义。我在实际项目中的体会是功能安全和SOTIF的架构设计要协同考虑不能割裂。比如冗余架构的设计不仅要考虑故障后的切换还要考虑切换后的性能是否满足SOTIF的要求。如果备用通道的性能本身就处于边界状态切换过去也没用。还有一个趋势是端到端自动驾驶对功能安全架构的冲击。传统的模块化架构每个模块都有明确的安全需求和接口定义功能安全设计相对容易。但端到端架构是一个黑盒输入是传感器数据输出是控制指令中间的过程不可解释。这种情况下功能安全架构怎么设计我的看法是端到端架构需要更强的运行时监控和形式化验证。你没法在架构层面保证端到端模型的安全性但你可以通过运行时监控来检测异常输出通过形式化验证来证明某些关键属性。最后再分享一个小技巧架构设计文档不要写得太抽象要具体到每个安全机制的实现细节。我见过太多架构文档满篇都是“应采用冗余设计”“应保证故障检测覆盖率”但具体怎么做、参数是多少、怎么验证一个字都没有。这种文档到了开发阶段就是废纸。我的做法是架构文档里每个安全机制都要有明确的输入输出、参数定义、验证方法最好配上时序图和状态机图让开发人员一看就知道怎么实现。这个系列写到第六篇其实还有很多可以展开的地方比如多核锁步架构的设计、安全岛的实现、OTA升级对功能安全的影响等等。后面有机会再慢慢聊。