ISO 26262安全分析实战：HARA、FMEA、FTA与DFA全解析

ISO 26262安全分析概览这个话题在我手上也算是个老熟人了。这几年功能安全从高端配置逐渐变成很多车企和零部件供应商的准入门槛ISO 26262这个标准也从文档柜里的生僻词变成了工程师之间日常讨论的词汇。但说句实在话标准文本翻过一遍容易真正把安全分析做到位、做出价值又是另一回事。这个标题叫互动分享 | ISO 26262安全分析概览从字面看核心就是ISO 26262体系里的安全分析到底怎么做、包含哪些内容、不同分析方法的侧重点在哪里。适合谁看呢我觉得三类人最需要刚接手功能安全任务的工程师想在项目里系统落地安全分析的团队以及想了解功能安全核心逻辑的产品经理或质量人员。这篇文章我尽量把安全分析从为什么做讲清楚再落到怎么做的具体的方法和实例上不谈空话只讲手上做过的项目和踩过的坑。IS0 26262的框架体系相当庞大包括功能安全管理、概念阶段、产品开发、系统集成、确认活动等多个章节安全分析并不是某一个孤立章节而是贯穿整个开发链路的横向活动。这也是很多团队最初抓不住重点的原因——看到标准里FMEA、FTA、DFA到处出现就以为做几张表格就够了实际上完全不是这么回事。1. 安全分析在ISO 26262里到底扮演什么角色1.1 从流程里看安全分析的位置ISO 26262将整个安全生命周期划分为几个阶段包括概念阶段、系统级开发、硬件级开发和软件级开发。安全分析在这几个阶段中以不同的形态反复出现它的地位是验证支撑者和设计输入者双重身份。举个例子在概念阶段做HARA危害分析与风险评估它输出的是安全目标以及ASIL等级。这个输出直接决定了后续系统设计的严苛程度比如一个功能被评定为ASIL D那它的硬件随机失效度量指标、软件开发的验证深度都要比ASIL B高一个数量级。所以安全分析做得好不好会直接影响产品的架构和成本。到了系统设计阶段安全分析又承担着验证安全机制是否够用的责任。这时候FMEA、FTA开始起作用它们用来回答如果某个部件失效了安全机制能不能在容错时间内防止危害发生。这不是猜出来的而是逐条分析、逐层推导出来的结论。1.2 安全分析要回答的四个问题我习惯把安全分析的目的归结为四个问题。做分析前先问这四项思路就不会跑偏。可能出什么问题这是失效场景的识别对应FMEA和HAZOP思想。问题会导致什么后果这是危害评估对应HARA中的严重度、暴露度、可控性评分。怎么防止或者减轻后果这是安全机制的确定对应安全需求推导。安全机制本身可靠吗这是对安全机制的验证对应FTA、DFA分析。这四个问题环环相扣缺一个整条安全论证链就断了。安全分析不是交差用的它是在回答审查员、客户甚至事故调查中凭什么说这个系统是安全的这个终极问题。2. HARA安全分析的第一场硬仗2.1 HARA的三个关键步骤HARA是安全分析里最容易被轻视、实际上又最考验功底的环节。很多新人觉得HARA就是开个会、列一串场景、打几个分太天真了。HARA分三步走每一步都有讲究。第一步是场景分析也叫做运行场景与操作模式的梳理。这里要覆盖的是目标功能在整车上的使用工况包括高速公路行驶、城市拥堵、停车入库、极端天气、上下坡、夜间行车等等。场景越具体后面识别出的危害就越有针对性。一套好的场景矩阵需要融合整车架构、驾驶习惯、目标市场的道路法规等多方面信息。第二步是危害识别针对每一个场景找出可能导致人身伤害的潜在事件。以电动尾门为例危害可能是尾门意外关闭夹住用户也可能是尾门在行驶中意外打开遮挡后视视野。识别危害时要站在用户和周边交通参与者的角度去想不能只考虑功能失效本身还要考虑人员误操作、环境干扰等叠加因素。第三步是风险评价也就是对每一个危害事件从严重度、暴露概率、可控性三个维度打分最终确定ASIL等级。评分不是一个人说了算的需要跨职能评审包括安全工程师、系统工程师、功能开发工程师一起参与否则标准要求就难以客观体现。2.2 ASIL等级怎么评才有说服力ISO 26262定义了A、B、C、D四档ASIL等级D是最严格的另外还有QM等级代表仅需按常规质量管理流程开发即可。我见过不少团队喜欢在评分时往宽松方向靠理由是这个失效概率本来就很低。这里要提醒一句ISO 26262的评分逻辑里C可控性这个维度特别容易被误判。可控性指的是驾驶员或者乘客在危害发生的时候有多大能力去避免伤害。举个例子转向系统完全失控和制动系统完全失灵从可控性角度评价是明显不一样的后者在多数场景下被认为几乎不可控。误判可控性最直接的结果就是ASIL等级定低了后续开发深度不足这项风险在审核的时候必然会被挑战到那时返工成本就不是重新打一次分这么简单了。以我的实际经验ASIL等级评审时要带着数据支撑去讨论。暴露度要依据目标市场的行驶工况统计数据来估算严重度要参照对应伤害类型的医学评分或以往事故统计。纯粹拍脑袋定出来的等级理由根本站不住脚。2.3 一个HARA实例AEB系统的场景拆解我们把自动紧急制动AEB中的部分场景拿出来做一个简化版的HARA演示。目标车辆在城区道路上正常跟车突然前方车辆急刹此时AEB功能需要自动触发制动以避免追尾。在这个场景下可能的危害事件有几种比如AEB失效没有触发制动再比如AEB误触发导致车辆急停后车追尾。分别来评价AEB失效不制动严重度S3可能致命伤害暴露度E4典型城市跟车工况频繁发生可控性C3驾驶员来不及反应几乎不能控制。ASIL等级评定为ASIL D。AEB误触发急停严重度S2可能造成轻伤或中等伤害暴露度E4可控性C2如果驾驶员保持警觉仍有一定控制空间。ASIL等级初步评定为ASIL B或C具体得看对目标市场和场景细节的假设。从这里就能看出同一个功能不同的失效模式对应的ASIL等级可能差得很远。HARA的输入是功能行为而非单一零部件所以它的输出安全目标也是针对避免危害事件发生而非防止某个零件损坏。3. FMEA、FTA、DFA的实战拆解3.1 FMEA别把它当成填表格的体力活FMEA在ISO 26262中的应用不算陌生但执行的思路需要特别说明。在传统可靠性领域FMEA常被用来识别产品设计弱点并通过对严重度、发生度、探测度打分计算RPN值来排出优先级。但在ISO 26262的语境下FMEA的主要作用是验证安全机制的覆盖率以及支持安全需求的推导。所以做FMEA时千万别把精力全花在计算风险优先数上。我在评审过的一个项目里看到整张DFMEA表填满了密密麻麻的RPN数值但审查员问安全目标对应的失效模式有没有被安全机制覆盖团队却答不上来这就说明FMEA没做到点子上。在功能安全场景下FMEA更重要的输出是每个失效模式的检测与响应措施。比如分析一个电机控制器的功率管短路失效模式安全机制可以设计为电流传感器实时监测超过阈值就触发关断驱动通道并进入安全状态。这条失效模式对安全目标是否有影响、安全机制是否能有效检测和响应才是审查的重点。我建议在实操中把FMEA表格从部件失效模式为主切换为以安全相关功能失效模式为主线来组织。这样可以有效避免FMEA和FTA内容脱节也更容易推导出安全机制。3.2 FTA定量和定性的博弈FTA故障树分析用于从顶事件向下追溯所有可能的失效组合和失效路径。在ISO 26262中FTA可以作为双点失效分析的有效工具也是验证安全机制在存在多个故障叠加场景下是否仍然有效的重要方法。FTA有两种用法一种是定性只看布尔逻辑的组合关系另外一种是定量结合失效率数据来估算顶事件的发生概率。我个人的经验是在FTA搭建阶段先用定性方式把逻辑关系理清楚不要急着堆数据。很多团队上来就找失效率手册各种数值一填看起来很高大上但逻辑本身有漏洞填了什么数据都白搭。搭建FTA时要注意基本的逻辑门语义。与门表示所有输入事件同时发生顶事件才发生或门表示任一输入事件发生顶事件就发生。很多新手在这上面出错把或门用成与门算出来的概率差了若干个数量级后续设计决策完全被带偏。还有一种常见情况是与门下面的分支事件并不是真正独立的比如两个输入事件都源于同一个传感器失效这时候就必须在FTA里用DFA依赖失效分析来处理否则结果会低估风险。3.3 DFA专门对付共因失效DFA的全称是Dependent Failure Analysis中文常译作相依失效分析它主要用来识别和分析共因失效、级联失效等相互依赖的失效场景。共因失效在工程实践中相当常见比如两个独立的安全机制共用了同一路电源一旦这路电源失效两个机制同时失效那么所谓的冗余实际并不存在。再比如多个ECU共用同一条通信总线网络异常会导致它们的信号全部丢失。DFA的分析过程通常需要列出安全机制所依赖的所有共享资源包括硬件资源、软件资源、通信链路、电源分布和时钟源。然后判断这些共享资源失效是否会导致多个安全机制同时丧失功能如果有这种风险就需要在架构上做解耦优化。DFA的分析结果直接作为系统架构设计的输入。在我做过的项目里DFA发现双通道逆变器共用了同一个低压电源的保险丝后来在架构评审阶段就把两个通道改成了独立的保险丝供电这就是DFA真实改变设计、降低风险的典型案例。4. 安全分析输出物如何落地4.1 从安全目标推导安全需求安全分析不是停留在表格里的最终的成果要转化为可落地的设计输入。以HARA和FMEA的输出为例安全目标往往是一个比较顶层的描述比如避免车辆在行驶过程中发生非预期加速。从这条安全目标推导出的系统安全需求要包含技术性的内容。比如加速踏板位置传感器信号有效性必须在10毫秒内得到确认或者当检测到非预期加速时动力系统必须在200毫秒内进入安全状态。这些需求直接给到系统工程师和软件工程师成为他们设计算法的约束条件。在实际项目中安全分析的人员往往是和系统工程师背靠背工作的。如果安全分析团队不了解系统架构的实际情况推导出的安全需求很可能无法实现或者成本过高。我的经验是安全分析不能太独立一定要参加架构设计评审在关键设计决策点上及时输出分析结论。4.2 安全机制验证与确认安全分析推导出的安全机制要进行验证和确认。验证是指用仿真、测试、评审等方式证明安全机制在预定的条件下能够工作确认则是站在整车和用户层面确认最终产品在真实使用场景下确实足够安全。FMEA中列出的每一个安全机制都要有对应的验证活动。这个对应关系是安全论证链上的关键环节审查员在审核时往往会随机抽查一个安全机制要求提供它的验证证据。所以我在做项目计划的时候会专门建立一个FMEA安全机制与验证活动的追溯表把每一条机制和对应的测试用例、仿真模型关联起来。测试工况设计不能只看正常工况更要考虑边界和极端情况。比如安全机制的响应时间需要在最恶劣的温度、电压、故障注入组合下测试而不是在理想条件下测一次就写结论。这一点上我吃过亏用常温正常电压测出来的响应时间好看得很结果做高低温测试时候一次就不过后来把测试矩阵里的边界条件全部补足了。4.3 文档化和评审经验或者叫它怎么让安全分析经得起审核。文档化是功能安全里最繁琐但是完全不可少的工作。文档的作用不只是记录更是在追溯。一个触发条件、一条失效模式、一个ASIL等级结论没有清晰的记录审查时根本说不清。关于文档数量我见过两种走极端的团队一种是文档写得很厚几百页PDF堆在那里但内容和实际设计对不上另一种是文档极简几张表格打完收工证据链严重不足审核开放问题一大堆。我的看法是安全分析文档追求的不是厚度而是可追溯性。从危害场景到安全目标到安全需求到安全机制到测试报告每一步都要有据可查。内部评审建议至少要经过两步。第一步是技术评审由同级或高级工程师对分析内容进行质询专门找漏洞第二步是独立评审最好由没有参与该项目的安全专家来进行。独立评审的价值在跳出惯性思维项目组自身容易陷入自证清白的心理不容易发现问题。5. 实操中踩过的坑与应对5.1 常见误区整理做功能安全这几年见过不少团队栽在同一个坑里我挑几个典型的分享出来。第一个坑是把HARA当文档任务做场景只写两三个泛泛的工况。很多团队的市场目标是国内加欧洲但是场景分析只写了高速公路和城市道路两个场景地下停车场、雨雪天气、夜间照明不良这些场景全部漏掉。结果危害识别不完整安全目标缺项后期补都来不及。第二个坑是FMEA和FTA没有交互。FMEA在部件层面分析失效模式FTA在系统层面分析失效逻辑两者如果各做各的就会出现同样的失效在FMEA里认为已被安全机制覆盖但在FTA里又有一条未覆盖的失效路径逻辑上互相矛盾。解决办法是开跨分析方法的联合评审会议用统一的失效模式清单来约束输入。第三个坑是忽略安全机制自身的失效模式。很多团队做完FMEA看到所有危害都有对应的安全机制觉得万事大吉。但安全机制本身也可能是会失效的。比如一个监测电流的ADC出故障了安全机制还能不能发挥作用这类机制失效的分析正是FTA和DFA发挥作用的场景不能省。5.2 提高安全分析质量的几个习惯经验积累下来有四个习惯值得刻意培养。第一个习惯是画图说话。分析过程中多画框图、状态图把系统和失效逻辑画出来再讨论比直接对着Excel表格讨论强得多。视觉化的信息能让大家更快地发现逻辑漏洞也能让审查员清晰地理解你的安全概念。第二个习惯是记录分析过程中的未决点。分析中经常会遇到信息不足、需要等待系统设计确定的情况一定不能假装不存在。用一个专门的问题清单把这些未决点记下来定期追踪、更新、关闭这样才能确保分析结论都在动态维护中。第三个习惯是尽早让安全分析参与到架构评审中。安全分析如果在架构已经冻结之后才介入那它只能做验证做不了设计输入。最好在架构定义阶段就把HARA初步结论拿过来把ASIL等级分配到各个功能模块对架构形成安全约束。这样安全分析的价值能最大化发挥。第四个习惯是形成分析结果变更管理意识。项目不可能一成不变设计变更后安全分析必须同步更新。不要等审核前才慌慌张张做一轮全面更新那基本都会漏掉重要的细节。变更驱动分析更新应该是一个持续性的状态。6. 案例分析一个完整的安全分析串联演示我在很多培训场合都喜欢用电动助力转向EPS来做完整演示因为它的失效模式清晰、安全机制也比较有代表性。EPS的核心功能是根据方向盘扭矩和车速提供转向助力如果助力异常会直接影响车辆操控。在HARA阶段我们先列出运行场景城市低速泊车、城郊中速行驶、高速巡航、湿滑路面行驶等。接下来识别危害事件比如转向助力完全丧失和转向助力非预期施加。对于转向助力完全丧失这个危害在高速行驶场景下驾驶员需要施加很大的手力来转动方向可能会超出人的生理极限严重度和可控性评估结果都比较差最终评定为ASIL D。安全目标随之推导出来避免在车辆行驶过程中发生转向助力完全丧失。系统层面设计的安全机制包括内部冗余设计比如电机双绕组结构一套绕组失效后另一套绕组还能提供助力的能力以及失效检测比如扭矩传感器信号交叉校验。FTA的顶事件就定义为发生非预期转向助力丧失。底下展开的分支包括电机相关失效、扭矩传感器失效、供电异常、软件异常退出等。通过故障树分析发现双绕组电机方案使得电机本体单点失效的概率大幅降低但是供电回路如果设计为单路就是单点失效的隐患。于是DFA分析介入重点排查两个绕组的供电是否可能因共因失效而同时丢失。经过这一串分析最终的架构为双路独立供电、双绕组电机、传感器交叉校验加冗余设计再加上ASIL D等级的软件监控机制。安全分析输出的每一项都直接对应了具体的架构决策这就是安全分析落到实处的样子。7. 安全分析的延伸与未来趋势写完上面的内容我觉得还有一点值得聊一聊安全分析这个行当正在发生什么变化。随着整车电子电气架构逐步走向中央计算加区域控制的新形态安全分析的复杂度也上了一个台阶。原来一个功能由一个控制器负责分析范围相对集中现在一个域控制器要同时集成动力、底盘、智驾多个功能失效模式之间的交互影响呈指数级增长。这对安全分析提出两个新要求一是分析效率必须提升二是分析方法要从静态表格走向动态模型驱动。我接触到的行业中很多工具链已经在尝试把HARA、FMEA、FTA和DFA统一到同一个系统模型里用模型来联动更新分析结果。这种方式一旦落地设计变更后的分析更新周期可以从数周压缩到数天效率提升明显。另外随着自动驾驶等级提升传统以驾驶员作为可控性因素的评分逻辑也在受到挑战。L3级及以上的系统里系统的决策和控制替代了很大一部分人类操作ISO 26262的很多概念正在和预期功能安全SOTIF碰撞融合。安全分析的方法论也必然随之演进可能未来很多人为可控评估要重新定义。作为一个在一线做了不少年功能安全的人我的体会是ISO 26262中的安全分析不是一道可以一步到位的流程也不是满足审查的文档堆砌它的本质是工程判断力的系统化表达。做安全分析时最重要的能力不是背标准而是在理解系统行为的基础上用一套严谨的思维工具把潜在的风险一层一层地找出来并且推动设计去消解这些风险。最后再分享一个实操中的小技巧。无论做HARA、FMEA还是FTA一定要用提问清单来引导分析。我自己常备一份包含二十多个问题的清单从这个失效会不会导致安全目标违反到安全机制检测到这个失效需要多长时间到失效发生后进入安全状态需要哪些条件逐个过一遍。这样一来分析过程不会遗漏关键维度出来的结论也经得起推敲。