功能安全这个行当做到第五、六篇文章的时候往往才是真正开始扎心的时候。前面聊了概念阶段、系统级设计、软硬件开发框架都搭起来了但到了“架构设计”这一层很多团队会突然发现文档堆了一堆ASIL等级分得清清楚楚安全机制也画了一堆框图可评审专家一问“为什么这个安全机制放在这里你的安全指标是怎么算出来的这个软件组件凭什么可以直接复用”就答不上来了。这篇文章是【功能安全的架构设计】系列的第六篇我准备换一个角度来聊。之前的文章更多是按流程阶段来拆这一篇我更想聚焦在“安全架构落地时那些最容易被挑战、也最容易被含糊过去的决策点”上包括安全目标怎么变成架构约束、ASIL分解的边界条件、硬件架构度量的具体计算、软件组件鉴定到底怎么操作以及从架构评审视角看哪些地方最容易被挑战。内容偏硬但我会尽量用自己实际做项目时的思路和踩坑经历来讲希望能对你的工作有直接帮助。1. 安全架构的起点安全目标与ASIL的拆解聊架构之前必须先把源头说清楚。你做的不是“为了架构而架构”而是为了满足一项项安全目标架构才有意义。ISO 26262里定义的安全目标Safety Goal本质上是对车辆或系统级危险事件的顶层约束比如“在车辆行驶过程中不允许发生非预期的加速”。这个约束不是软件层面的也不是硬件层面的而是要落在整个系统架构上。1.1 怎么把安全目标翻译成架构约束我见过不少工程师安全目标写得挺漂亮但一进入架构设计就不知道安全目标跟自己的架构图有什么关系了。实际上安全目标落到架构上至少要回答清楚四个问题第一安全状态是什么也就是说当系统检测到故障或者异常时系统要退到什么模式才算安全。是进入降功率、锁存、还是切断输出这个状态必须在架构设计阶段就固化下来不能等软件开发完了再讨论。第二容错时间间隔FTTI是多少从故障发生到系统进入安全状态允许的最长时间。这个时间直接决定了你的安全机制放在哪一层、用硬件实现还是软件实现、诊断的响应速度需要多快。FTTI定了架构里各个安全机制的时序约束才算有依据。第三安全完整性等级ASIL是多少ASIL不是拍脑袋定的它来自危害分析和风险评估HARA根据严重度、暴露率、可控性三个维度综合得出。ASIL等级决定了后续硬件架构度量的目标值也决定了软件开发的强制性要求。第四故障是怎么传播的安全目标对应的危险事件是由某个单点故障引起的还是多个故障叠加造成的这会直接影响你是做监控机制就够了还是必须上冗余架构。这四个问题在架构层面必须形成可追踪的关系。我比较习惯的做法是建立一张“安全目标-功能安全需求-架构要素”的追踪矩阵每一个架构模块的安全职责和约束都写清楚评审的时候直接按矩阵问哪里断了补哪里简单粗暴但有效。1.2 ASIL分解别把等级越堆越高ASIL分解是架构设计里比较有意思、也比较容易被用错的一个手段。ASIL分解的核心逻辑是一个ASIL D的需求如果分解成两个相互独立的需求可以分别降低等级。比如ASIL D可以分解为ASIL C(D) ASIL A(D)或者ASIL B(D) ASIL B(D)甚至ASIL D ASIL QM(D)但有一个硬性前提分解后的各部分之间必须满足独立性要求否则分解不成立。我见过最典型的错误是FPGA工程师为了实现方便把原本ASIL D的功能硬拆成ASIL B ASIL B但两个通道共用同一个时钟、同一个电源、同一个复位逻辑评审的时候直接被挑战“独立性证据在哪里”。所以做ASIL分解前一定要先梳理独立性的依据是不同芯片、不同供电、不同时钟、不同传感器还是物理隔离没有这些证据分解就是纸面游戏。另一个容易忽略的点是ASIL分解不是只在安全概念阶段做一次就完了。进入架构设计后每个安全机制本身的ASIL等级也要根据它的作用重新审视。比如一个ASIL D的安全目标靠一个ASIL B的监控机制来保护这个监控机制的开发流程要求虽然可以按ASIL B去执行但它的实际失效风险会直接影响安全目标的达成所以架构上要有额外的检测或缓解措施来覆盖这个弱点。2. 系统级架构设计从技术安全概念到软硬件的边界系统级架构设计说白了就是回答“我用什么方式来实现安全目标”。安全概念定义了“要做什么”技术安全概念定义“怎么在技术上做”而系统架构则是把技术安全概念落实到具体模块、具体软硬件的载体上。这个阶段做得好不好直接决定后面三个月开发阶段是不是地狱模式。2.1 技术安全需求怎么落地成架构技术安全需求Technical Safety Requirements, TSR是从安全概念衍生的、分配到系统级的技术约束。落地成架构的时候要逐条梳理TSR对应到哪个架构层比如传感器层、控制器层、执行器层还是通信层然后明确每一个安全机制的职责归属。我建议先把安全机制按功能分为四类探测、缓解、容错、降级。探测类机制负责发现故障比如看门狗、电压监测、CRC校验、E2E通信校验缓解类机制负责在故障发生后把系统拉到安全状态比如关断输出、驱动刹车容错类机制让系统在部分故障下仍然保持功能比如双通道冗余、表决逻辑降级类机制是让系统在一个较低但仍安全的性能水平上继续运行比如限制加速扭矩。架构设计时要清楚每个安全机制分到哪个模块是硬件实现还是软件实现它的触发条件和执行路径是什么故障发生时通过哪个通信路径传递状态。这些信息不能只停留在技术安全需求文档里架构图必须能明确看出来哪个模块负责监测哪个模块负责执行信息流怎么走故障传播路径怎么切断。2.2 冗余设计的实际取舍与独立性约束安全架构里谈冗余很多人容易陷入“越多越好”的误区。其实冗余的本质是“为同一安全目标提供多于一条独立路径以避免单点失效”。这里面有两个核心关键词独立和单点失效。比如做双通道冗余两个通道如果使用了同一个型号的微控制器一旦这个型号存在系统性失效比如一个内核缺陷那两条通道同时挂掉的可能性非常大架构上就必须评估是否需要在硬件层面做异构设计比如主核用Infineon监控核用NXP或者一个是MCU一个是CPLD/FPGA这样至少系统性缺陷的重叠面会小很多。冗余的拓扑结构也很有讲究。常见的架构有1oo1、1oo2、2oo2、2oo3等模式。1oo1就是单通道故障直接导致功能失效常用于ASIL B以下或可快速安全停机的场景。1oo2是双通道并联任何一条通道都能单独把系统带到安全状态这种结构安全性高但可用性会受影响因为一个通道故障系统就停机了。2oo2是双通道串联必须两个通道一致才继续工作这种结构可用性高但对单点故障的容忍能力差两个通道只要有一个故障系统就会错误停机。2oo3是表决架构三取二安全和可用性都高但成本和复杂度也随之上升。我实际做项目时的经验是不要单纯追求高等级冗余而是要从三个维度去权衡安全目标的失效概率要求、系统的可用性需求比如客户不希望无故停车、以及成本约束。做过几个项目之后你会发现真正难的不是画冗余框图而是把冗余之间的独立性证据做扎实包括电源隔离、时钟源、复位及启动时序、内存和寄存器复用边界、通信链路物理隔离等细节。提示在做冗余架构设计时建议从早期就引入“共因失效CCF”分析把两个通道之间任何可能的共享资源列成一个清单逐项确认是否有对应的防护措施。否则等你画完图才发现两个通道共用了同一个DMA通道评审时是没法辩护的。3. 硬件架构度量不是有安全机制就算数很多团队做硬件架构设计时画完安全机制框图就觉得大功告成了直到需要提交硬件架构度量Hardware Architectural Metrics才意识到自己要补各种各样的计算有些指标还远远达不到目标值于是开始疯狂加班。硬件架构度量其实就是两个指标单点故障指标SPFM和潜在故障指标LFM还有一个相关项失效概率PMHF——这几个指标在ISO 26262-5里都有明确的公式定义。设计人员不仅要算还要会解释“为什么这个数字合理”。3.1 SPFM、LFM、PMHF到底怎么算SPFM的定义是能够被安全机制覆盖的单点故障和残余故障的比率计算公式是SPFM 1 - (单点故障失效率的残余部分 残余故障率) / (所有单点故障失效率之和)简单说这个指标衡量的是系统对直接导致安全目标违背的故障有多强的吸收能力。LFM则关注潜在故障即潜伏的多点故障中有多少比例是可以被安全机制探测或控制的它主要衡量系统中两点故障叠加时第二点故障能否被及时感知。PMHF是整个系统在单位运行时间内通常以FIT为单位1 FIT 10^-9次失效每小时发生安全目标违背的期望概率通常与ISO 26262-5里的ASIL等级对应阈值做比较。具体计算时第一步是列出硬件元器件清单逐个确认每个元器件的失效率λ。这些数据可以来自SN 29500、IEC 62380、或者是供应商提供的专门失效率手册。第二步是分析每一个失效模式判断它是安全失效、单点故障、残余故障还是潜在故障。第三步是给每个单点故障和潜在故障分配对应的安全机制并查表得到诊断覆盖率Diagnostic Coverage, DC。最后将所有结果带入公式算出SPFM和LFM。这一步最大的难点也是最容易被挑战的点就是诊断覆盖率的取值。很多团队直接从ISO 26262-5的表格里挑一个看似合理的覆盖率却拿不出工程上“为什么能达到这个覆盖率”的证据。比如你说电压监测能达到99%的覆盖率那就需要说明覆盖了哪些失效模式比如过压、欠压、纹波超标有没有做故障注入测试去验证监测电路的实际表现。3.2 诊断覆盖率的现实考量不是查表那么简单诊断覆盖率不是拍脑袋填出来的也不是越高越好的教条它应该与具体的安全机制实现强关联。下面这张表是我整理的一些常用安全机制的参考覆盖率区间但请注意这只是工程上常见的参考范围实际取值必须要结合具体设计的验证结论来调整安全机制覆盖的典型失效模式参考诊断覆盖率范围实现层级程序流监控看门狗MCU程序跑飞、死循环90% - 99%软件/硬件锁步核比对MCU内核瞬时故障99% - 99.9%硬件冗余核RAM ECC位翻转、多位错误90% - 99%硬件/软件通信E2E保护CRC计数器超时通信数据损坏、丢失、重排99%左右取决于帧设计软件/硬件电压监测供电过压、欠压90% - 99%硬件时钟监测时钟丢失、频率漂移90% - 99%硬件输出使能路径的冗余关断输出驱动短路、锁死99%以上硬件注意这里有一个工程细节诊断覆盖率是“某个安全机制针对某个失效率的覆盖百分比”不同失效模式的覆盖率往往不同。如果你只填一个总体的覆盖率评审的时候几乎肯定会被挑战“这个99%是怎么综合出来的是加权平均还是最保守值”正确的做法是把元器件的每个失效模式都列出来逐项分配安全机制再逐项给覆盖率最后汇总计算。我在实际项目里的建议是在架构设计阶段就同步拉一个“失效模式-诊断机制-覆盖率”的清单而不是等到硬件设计快结束了才补。前期就做可以暴露覆盖率不足的模块及时调整安全机制后期再做往往只能为了指标好看而疯狂堆安全机制反而把架构搞得很复杂成本也上去了。4. 软件架构与软件组件鉴定复用不是免费的聊到软件层面我必须把“软件组件鉴定”Software Component Qualification单独拿出来讲因为这是这几年功能安全落地时最容易被轻视、也最容易拖垮项目进度的一件事。软件组件鉴定是什么呢简单说就是当你打算复用某个已有的软件组件比如第三方库、内部此前开发的底层驱动、或者某个经过市场验证的算法模块但这个组件不是按照ISO 26262要求的完整流程开发出来的那你能不能把它“洗白”成符合功能安全要求的组件用于安全相关功能答案是能但有代价。ISO 26262在第六章Part 8专门列了软件组件鉴定的要求。核心思路是通过提供额外的证据和测试证明这个组件在目标环境和目标安全目标下足够可靠。4.1 软件组件鉴定的几个硬条件做组件鉴定之前先确认以下几条第一这个组件的失效模式是否可控。如果这个组件存在无法被安全机制探测的失效模式那鉴定得再漂亮也不能用。鉴定的前提是组件本身的失效模式要么是安全的要么是有安全机制能覆盖的。第二鉴定过程中必须有独立、可信的证据。这包括组件的需求规格、接口定义、已知失效行为的分析以及针对目标环境运行的测试结果和数据。第三鉴定活动必须形成报告说明这个组件的使用条件、限制和适用场景。这份报告就是“软件组件鉴定报告”的核心内容。报告中要写明组件的鉴定范围是哪些ASIL等级、在什么配置下鉴定通过、有哪些已知限制和假设条件。我自己参与过几轮组件鉴定的评审最深的体会是评审专家不关心你写的报告有多厚只关心三个问题——你用的鉴定方法是否能有效暴露组件的问题你的测试用例是否覆盖了最关键的失效场景你的报告是否对组件的所有假设条件做了明确声明这三个问题答不清晰报告基本过不了。注意组件鉴定绝不是“把组件包装一下再说是符合ISO 26262的”而是要把它的失效模式、运行边界、异常行为都摸透并留下充分的验证记录。如果你的组件是一个黑盒供应商连内部结构测试文档都不给那做鉴定的风险非常高建议优先考虑替换或自己重新开发。4.2 软件架构的分层与隔离安全相关代码的护城河软件架构上除了组件鉴定另一个关键点是安全相关功能与非安全相关功能的隔离。隔离的目的在于防止非安全相关功能比如UI界面、蓝牙、诊断的故障把安全相关逻辑一起拖下水。实现隔离的手段有几种一种是按环节物理隔离比如安全核心使用单独的内核、单独的内存区和单独的中断优先级另一种是逻辑隔离通过软件架构上的任务切换机制确保非安全功能的执行时间不会挤压安全功能的时间预算还有一种纯粹靠代码层面的模块封装和不可绕过的数据访问控制。我在项目中最推荐的工程实践是把安全相关功能集中到独立的软件组件中跟非安全组件通过明确的接口通信且安全组件内部不使用动态内存分配、不使用递归、不依赖全局变量。这套约束虽然看起来像是老生常谈但它能让软件架构做静态分析的时候非常友好也让故障模式的可控制性成倍提升。5. 架构评审与经验总结那些最容易被挑战的地方下面这几条是我从实际架构评审中被挑战过、也看别人被挑战过的最高频的问题算是给各位排雷。5.1 评审最常见的五个致命问题第一安全机制没有对应到具体安全目标。架构图上画了好几个安全机制但评审问“这个机制保护的是哪个安全目标”答不上来。解决方法是架构文档中包含安全机制到安全目标的完整映射关系。第二诊断覆盖率没有工程证据。之前说过填一个99%的表容易但支撑99%的故障注入报告没有或测试场景太理想化跟实际交付环境差距很大。第三独立性只体现在图上。图上两个通道是“独立”的但供电网络、PCB层叠、接地策略、时钟源、复位信号等没有做过共因失效分析。评审专家一眼就能看出你是真隔离还是假隔离。第四软件组件的鉴定报告与使用场景不匹配。鉴定报告写的是A场景下的验证结果但你在B场景里面用ASIL等级和工作环境温度范围都变了这黑盒就没法继续用了。第五架构设计没有跟着硬件故障模式分析迭代走。系统架构早期定了但后来说硬件器件更换或者安全机制升级了架构设计图和技术安全需求却没更新导致软件开发和测试基于的架构基础已经和实际设计不一致。这些问题有一个共同根源安全架构设计和硬件失效分析、软件开发计划没有强联动起来各做各的最后评审对不上账。5.2 从数据架构设计和智能体架构里借鉴的两个思路说到架构设计这些年除了ISO 26262我也看了不少“问数智能体架构设计”和“华为企业数据架构设计方法”这类跨领域架构方法论。它们和功能安全软件架构虽然不是一个赛道但有两件事对功能安全架构很有参考价值。第一个可借鉴的思路是分层和解耦的设计理念。智能体架构里管理者、执行者和知识库是分层隔离的每层只做自己的事层间通过标准化接口通信。这跟我们软件架构里安全组件与非安全组件的隔离逻辑完全一致。如果你能把安全相关的控制流和数据流也做成清晰的分层评审专家反而更容易信任你的设计。第二个可借鉴的思路是数据流和控制流的显性建模。数据架构设计里特别强调打通“数据从哪里来、到哪里去、中间经过哪些变换”的全链路强调物理实体和数字孪生之间的一致性。这个逻辑完全可以套用到功能安全架构设计里——安全相关的传感器数据经过哪些处理、在哪里被判断是否存在危险、最终在哪里执行安全动作整条链路必须清晰显性化而不是散落在各处。许多架构评审不过的项目其实不是安全概念有问题而是这条链路本身讲不清楚。6. 架构设计里的经验与体会六篇文章写到这里我个人的体会是功能安全的架构设计本质上是在做一道“系统性的信任证明题”。你要证明的不只是“这个架构能实现功能”而是“这个架构在出现故障时仍然能实现功能”以及“如果故障是隐藏的、是组合出现的系统仍然能够把危害控制在可接受的范围内”。所以在架构设计过程中永远不要只盯着自己的那条功能链路要多问问故障从哪里来故障会走到哪里去安全机制能不能真正兜住底如果兜不住还有没有后备手段哪怕你画的架构图再漂亮只要这条故障链路上有一个环节是失控的评审时早晚会暴露。另外做架构设计不要单打独斗。硬件工程师对失效模式的理解、软件架构师对任务调度时序的把握、系统工程师对整车级故障场景的洞察这些是拼图一样互补的。多拉一场架构建模评审会比多写十页文档有用。最后安全架构是活的。随着软件开发深入、后续测试结果反馈、供应商元器件变更架构也会面临迭代。保持文档与设计的一致性保持追踪矩阵的完整保持每一次变更都经过影响分析这才是让安全架构真正落地的不二法门。希望这篇关于架构设计的梳理能帮你在下一次评审前更有底气。如果你也在做类似的系统欢迎针对具体的架构难点跟我交流很多问题是拿出来聊一聊才有新的解法。