1. 为什么我要把整套安全分析流程推倒重来如果你在整车电子电气设计这条线上待过两三年大概率见过这种场面安全评审前夜安全工程师对着 FMEA 表格里几百行失效模式挨个问设计工程师“这个失效如果发生影响是什么”设计工程师翻着原理图和数据手册现场编原因凌晨一点大家还在群里对口径确保第二天汇报结果一致。这不是某一个团队的问题而是传统“文档驱动型安全分析”的常态。“Auto Design Safety Analysis: Reloaded”是我们内部做了半年的一个重构项目目标很直接把汽车设计阶段的安全分析从人工填表变成“领域知识 规则引擎 数据模型”的自动化流程。标题里 Auto 这个词我始终按两层意思理解一是 Automotive Design汽车设计二是 Automation自动化。这两个意思恰好也是这个项目的两条腿——没有汽车设计的领域知识自动化只会把错误放大没有自动化工具领域知识又会被大量重复劳动淹没。这篇文章是这次重构的完整复盘包括框架选型、数据建模、落地过程中踩过的坑以及一个转向系统项目的实测数据。1.1 传统 FMEA 评审的真实痛点先说痛点因为自动化要解决的永远是人的问题而不是工具的问题。传统 FMEA 的最大问题不是“表格不好填”而是大量工作在做“信息搬运”。系统架构在 SysML 模型里需求在需求管理平台里硬件接口定义在原理图或者接口清单里功能安全目标在另一份文档里。安全工程师做分析时要把这些分散的信息手动抓取出来再逐行填进 FMEA 的“失效模式、失效原因、局部影响、系统影响、检测机制、风险等级”这些字段里。一次中等规模的子系统评审几十个组件、几百个信号、上千条连接关系靠人力去展开通常要两三周。另一个让人头疼的问题是描述口径不统一。同一个失效模式硬件工程师写“输出引脚对地短路”软件工程师写“ADC 采样值跳变到 0”测试工程师写“传感器信号丢失”。三个人其实在讲同一件事但文字不一样评审会上就要花大量时间对齐。等到项目进入下一阶段这些描述还会漂移新版 FMEA 里可能就变成另一个说法追溯性基本靠人脑记忆。第三个问题是风险等级打分的主观性。SSeverity、OOccurrence、DDetection三个维度标准里定义得很清楚真正打起来每个人都有自己的理解。同一个失效模式机械背景的人觉得“这个不太可能发生”电子背景的人觉得“电磁干扰下大概率出现”。这不是谁对谁错而是缺少统一的上下文。自动化工具最大的价值之一就是把这些上下文显式地建模让打分不再完全依赖个人经验。1.2 这次重构的三个目标项目启动前我给自己定了三条硬指标整个 Reloaded 版本都围绕这三条展开。第一把“已知的重复劳动”交给机器。FMEA 初稿、故障树初稿、安全需求清单初稿这些不是创造性工作而是基于组件类型、接口关系、失效模式库的机械展开。自动生成初稿人工负责裁切、补充和判断效率完全不一样。第二让安全需求和设计模型之间建立可追踪的双向链接。从顶层安全目标拆到功能安全需求再分配到具体组件每一步都要能追溯到“为什么会有这条需求”。分析过程中自动生成的所有条目也必须能回溯到对应的失效模式。第三把“文档输出物”变成“工程数据”。以前安全分析的产物是 PDF评审完就归档后续设计变更很难快速反应。这次我们要求所有分析结果以结构化数据存储版本可比较查询可检索设计变更时能自动生成增量的影响分析。这三条其实都不算激进很多成熟团队大概已经做到了。但对我们这种长期依赖人工表格的团队来说算是一次比较大的转向。2. 分析框架选型FMEA、FTA、STPA 不是互相替代的关系很多团队做安全分析开口就是“我们要做 FMEA”。我不太认同这种直接把方法和工具绑定的做法。先想清楚要回答什么问题再选择分析框架不然自动化只是在加速一个可能本来就不合适的流程。ReLoaded 项目启动的第一周我们把 FMEA、FTA故障树分析、STPA系统理论过程分析放在一起做了对比核心结论是它们不是互相替代的关系而是从不同维度回答不同的问题。2.1 FMEA适合逐点排查不适合回答系统级问题FMEA 的分析单元是“组件或功能的一个失效模式”。它的思路是自下而上单个引脚短路了会怎样传感器漂移了会怎样继电器卡滞了会怎样这种逐点排查非常擅长发现单点失效尤其是硬件层面的问题。但 FMEA 对“多个条件组合导致的失效”几乎无能为力。比如“电池电压跌落 控制器重启 通信总线繁忙”同时发生或者“驾驶员在弯道中松开加速踏板的同时转向助力系统进入降级模式”这种场景在 FMEA 表格里很难被自然表达。硬要写就得写组合失效行数爆炸而且容易漏。自动化项目里 FMEA 仍然是最适合打底的方法因为它结构规整字段固定规则容易编码。我们先做 FMEA不是为了替代其他方法而是为了先把单点失效的底网织密。2.2 FTA从顶层失效倒推原因正好补上 FMEA 的短板FTA 的思路是自上而下。先把一个不希望发生的顶层事件定义清楚比如“行车过程中转向助力意外丧失”然后一层一层往下展开是因为电源失效还是控制器异常复位还是电机驱动电路故障每层都用逻辑门连接体现“与”“或”“非”的组合关系。FTA 和 FMEA 正好形成互补。FMEA 从零件往系统看容易漏掉多个失效的组合FTA 从系统往零件看能抓住关键的单点路径和组合路径。自动化做 FTA 的难度比 FMEA 大因为上下层之间的逻辑关系很难全自动生成尤其是“与门”这种组合关系需要非常明确的场景定义。从工具角度FTA 也很适合做定量分析结合失效率数据算出顶事件的概率。这正好为我们后续引入可靠性数据留了口子。2.3 STPA针对“系统行为”而不是“组件失效”现代汽车里大量的安全问题不是硬件坏了而是“行为不正确”。控制器发送了一个不该发送的指令或者在错误的时间发送了一个正确的指令甚至指令没有执行——这一类问题用 FMEA 很难描述因为组件本身没有失效。STPA 把分析对象从“失效模式”换成了“不安全控制动作”关心的是控制器对外部执行器发出的每个动作在特定上下文里会不会导致危险。它特别适合软件占比高、功能逻辑复杂的系统比如智驾域、底盘域控、能量管理这类场景。STPA 的缺点是分析结果不够“条文化”很难直接生成评审用的表格。它对分析师的系统思维能力要求也高。如果团队没有经过 STPA 训练容易变成“四个人对着流程图争论一个动作安不安全”效率很低。为了让你直观理解三类方法的核心我整理了一张表方法出发点分析单元典型问题主要弱点FMEA自下而上组件/功能的失效模式这个 pins 短路会怎样组合失效表达困难FTA自上而下顶事件→原因组合这个危险场景是怎么发生的依赖顶事件定义质量组合规模大STPA系统行为控制动作是否安全这个控制动作是否会导致危险结果较散难以直接形成表格审查2.4 我的选型结论以 FMEA 打底FTA 深入STPA 专题补充我们这个项目最终选的是混合流程每个子系统先跑一遍自动化 FMEA对检测出来的关键失效模式做 FTA再对涉及多控制器协同的功能场景做专题 STPA。自动化的重点放在 FMEA 环节因为它的规则最容易固化FTA 部分用半自动方式工具负责整理结构和漏项逻辑门由人工确认STPA 只对高风险场景启用不要求每个子系统都做。这个选型不是理论上的最优解而是考虑到团队成员背景和投入产出比之后的选择。如果一开始就三套工具全面铺开团队一定会被任务量压垮自动化工具只会成为负担。3. Reloaded 的核心改造把安全分析从“写文档”变成“建模型”框架选型确定后接下来是数据模型设计。这步是整个项目中我认为最关键、也最容易被忽略的部分。很多人做自动化上来就写脚本把表格解析成 Word思路还是“用程序写文档”这其实没有从根上改变流程。我们这次把整个安全分析过程当成“建模”来做设计信息、失效知识、分析规则、安全需求统一用结构化数据表达文档只是这个数据模型的一种输出视图。3.1 核心数据模型分析项、失效模式、控制动作、安全需求我们定义了一套内部叫“SAMSafety Analysis Model”的数据模型核心实体只有四个Analysis Item、Failure Mode、Control Action、Safety Requirement外加若干关系表。Analysis Item 是安全分析的最小单元可以是一个传感器、一个控制器、一个执行器也可以是一个软件模块或者一条通信消息。每个 Analysis Item 必须有父级归属、接口列表、关联的功能清单。没有接口信息和功能上下文下游的失效传播分析就做不了。Failure Mode 是 FMEA 表的行。每条 Failure Mode 必须关联到一个 Analysis Item并带失效类型、失效原因、局部影响、系统影响、检测机制等字段。Reloaded 版本里我们还加了“失效模式来源”用来区分是自动生成的还是人工补充的这为后续质量评估提供了依据。Control Action 是 STPA 分析的最小单元关联到发送方和接收方以及动作发生的上下文。Safety Requirement 则记录了从所有分析条目中派生出的安全需求每条必须关联到上游分析条目并最终分配到具体的设计组件。之所以把四个实体拆开而不是直接写 Excel是为了让关系可追踪。以前 FMEA 表格里“这个失效对应哪条安全需求”全靠人写注释现在是一对一的数据库关系基本不可能丢。3.2 自动生成 FMEA 草稿的逻辑数据模型搭好之后自动化最核心的算法就是“从接口和功能信息推失效传播路径”。我们采用的方法是先按 Analysis Item 的类型套用标准失效模式库。比如“模拟输入引脚”这类组件默认展开“对地短路、对电源短路、开路、漂移、超时”五种失效模式“电机驱动输出”则展开“输出短路、开路、过流、异常关断、非预期使能”等模式。这一步不涉及智能只是一张“组件类型 → 常见失效模式”的映射表。真正的关键在下一步失效传播。系统架构模型里存了各组件之间的信号流关系比如传感器输出信号进入控制器 ADC 输入控制器再通过 PWM 控制电机驱动。如果传感器“输出漂移”了沿着信号流看控制器的“输入值异常”再往下是“控制算法计算出错误的扭矩指令”最终到系统层面上是“非预期驱动扭矩”。这个传播链不是靠字符串匹配做出来的而是依赖每个 Analysis Item 里提前定义好的“输入输出数据接口”。每个接口有哪些信号、信号范围是多少、信号异常会导致下游什么反应这些信息来自设计模型和安全专家共同维护的接口失效字典。这套逻辑跑下来FMEA 草稿的准确率取决于两件事一个是失效模式库覆盖得够不够全另一个是接口失效字典定义得够不够细。第一版上线时我们只覆盖了硬件组件结果软件控制器的分析基本是空白后来把软件逻辑单元也纳入了 Analysis Item覆盖率才上来。3.3 安全需求的追踪关系与一致性检查FMEA 草稿生成后转换逻辑会自动为每条高风险失效模式创建一条安全需求。比如传感器“输出信号漂移”被标记为安全相关失效后自动生成“当传感器输出信号超出 [x, y] 范围时控制器应在 50 ms 内进入安全状态并执行降级策略”这样的需求草稿。这个自动生成的功能不是让你直接用而是保证“每条高风险的失效模式都有人去思考怎么对应”避免评审时发现某个高风险失效没有对应任何安全机制。这一点在人工流程里特别容易漏因为安全工程师会遗漏也会因为 FMEA 持续更新而漏掉新增条目。Reloaded 版本还加了一组自动一致性检查规则包括三件事每个 ASIL C 及以上等级的失效模式必须至少关联一条 Safety Requirement。每条 Safety Requirement 必须分配到一个设计组件不支持“未分配”状态。每条 Safety Requirement 必须关联到一个验证方法无论是测试、仿真还是分析。每次运行后工具会生成一份“一致性检查报告”直接列出违反规则的条目。这一步对评审效率的提升非常大因为以前人工查出“这条需求没分配”需要把一堆文档来回翻现在工具自动扫一遍就有结果。根据我个人的经验一致性检查的价值甚至比 FMEA 自动生成还大因为它解决的是“安全证据链是否完整”这个根本问题。4. 数据源和失效知识库自动化最容易被低估的部分准备数据模型和规则引擎大概花了两周之后我以为最快进入实战了结果真正耗时的是数据源梳理和失效知识库建设。自动化有一个铁律输入是垃圾输出就是垃圾。这句话在我们项目里被验证得淋漓尽致。4.1 设计数据从哪来架构模型、需求条目、接口定义要自动分析设计安全性首先得把设计信息结构化地读进来。我们主要对接了三类数据源系统架构模型包括组件列表、层级关系、信号流、通信协议。这部分一般来自 SysML 或 EA 等架构工具格式还算规范但很多组件只有名字没有详细接口定义。功能需求与安全需求来自需求管理平台包含需求的唯一标识、文字描述、优先级、ASIL 等级等。这里的问题在于需求粒度差别很大有的需求精确到信号级有的还停留在“系统应确保安全”这种空洞表述。硬件接口清单主要包括连接器、引脚、信号方向、电压范围、通信类型。这是做失效传播最重要的输入但也是最难维护的输入。项目中期设计变更频繁接口清单经常和架构模型对不上。我们做了一个“数据归一化层”来处理这些问题。不管原始数据来自哪里统一转换成 SAM 模型的标准结构并在导入时做一次字段合法性校验。如果某个 Analysis Item 没有接口信息工具会标记为“输入数据不完整”而不是强行套规则生成结果。这样避免产生大量无意义甚至误导性的失效模式。4.2 失效知识库的建立从历史问题库、测试缺陷、供应商反馈失效模式库是整个自动化的“燃料”。第一版我们参考了通用的元件可靠性手册但很快发现通用手册只能覆盖“电阻开路”“电容短路”这种基础失效离汽车级应用差得很远。真正有价值的知识库一定来自企业内部积累。我们花了三周时间把以下来源的数据导入了失效知识库近三年的售后索赔数据中与电子电气相关的故障描述。测试部门的故障注入报告尤其是针对传感器、控制器、执行器的注入结果。供应商提交的 8D 报告里涉及的失效模式和根因。历史项目里已经人工审查过的 FMEA抽取出高频失效模式。每条知识都打上了“来源”和“置信区间”。比如售后索赔数据里出现的失效模式可信度较高供应商 8D 报告里某个具体批次的失效模式可信度也高而通用手册里的失效模式只作为兜底。这个设计在后面过滤误报的时候帮了大忙因为我们能根据来源优先级调整规则的权重。4.3 版本一致性和基线管理这部分是最枯燥、也最容易翻车的。安全分析和设计版本强相关同一个控制器芯片从 A 版本换成 B 版本引脚定义都可能变失效传播路径也随之变化。如果工具连接的是实时更新的数据库每次一重跑结果都不同谁也没法做评审。我们后来确立了“分析快照”机制。每次安全分析只针对一个固定的设计基线通常由配置管理平台发布一个带版本号的架构快照。分析工具从这个快照读取数据生成的 FMEA、故障树和需求追踪结果也打上同样的版本号。一旦设计发生变更先跑“变更影响分析”只对受影响的 Analysis Item 和依赖路径重新分析而不是全部重跑。这套机制在项目后期展现的价值最大。因为设计迭代不断发生如果每次都全量重跑安全分析的工作量会变成一个无底洞而只跑增量评审团队可以在最短时间内看到“这次改动引入了哪些新的失效模式、哪些原有失效模式的严重度或发生度可能变化”。这也是 Reloaded 版本比旧流程高效的重要原因之一。5. 落地过程踩过的坑误报、漏报和“工具不信任”再完美的工具如果团队不用或者用了但结果没有人认真复核数字化投入就打水漂了。落地阶段我们遇到三个非常现实的坑写出来给大家避避雷。5.1 规则误报率一开始高到没人看第一轮自动化建议跑出来结果非常“壮观”工具生成了 1200 多条失效模式安全工程师复核完真正有分析价值的只有不到 30%。剩下的 70% 全是“泛化失效”随便一个信号输入都写“可能发生短路导致信号异常”这类描述放到哪个项目里都成立但没有任何设计针对性。误报的根源是规则设计得太粗。我们没有区分“这个组件的失效是否影响安全相关功能”。一个用于氛围灯的 PWM 输出和用于转向助力的 PWM 输出工具都套用了同一套“输出短路、开路、过流”规则这显然不合理。解决办法是引入“安全相关路径判定”。在模型里每个 Analysis Item 被标记为“安全相关”或“非安全相关”这个标记可以由工具根据“组件是否处于安全关键功能链路上”自动判断也允许人工调整。对于非安全相关组件自动生成的失效模式只保留基本记录不展开详细安全分析。这样把 1200 多条压缩到 400 多条误报率降到可接受范围。这个经验对后来很有用“自动生成的东西必须允许人工修正同时保留修正痕迹”。我们给每个 Analysis Item 加了“安全相关置信度”字段工具自动计算人可调。这样一来误报可以被快速压制但人的修正不会被覆盖。5.2 自动建议和安全目标冲突时怎么办自动化会生成很多“看起来非常吓人”的建议。比如工具发现转向电机控制器的故障响应时间比安全目标要求的长就自动建议“增加 watchdog 冗余和独立关断通道”。这个建议听起来合理但系统架构师评估后认为现有监控机制已经覆盖了瞬态故障场景增加冗余通道会显著增加 BOM 成本还会引入新的共因失效风险。这种情况如果在旧流程里可能演变成一场争论工具说有问题架构师说没问题最后不了了之。我们在 Reloaded 版本里建立了一个“建议裁决流程”每一条自动生成的分析结论都带一个状态——接受、拒绝、需要评审。架构师必须对“拒绝”或“接受”给出理由并记录在数据模型里。不要小看这个“拒绝留痕”机制。它把工具从“裁判官”变成了“建议者”既保留了自动化的效率也留住了人做最终决定的权力。团队对工具的信任正是靠这种“工具不强迫你但它帮你把问题摆清楚”的体验建立起来的。5.3 让工程师愿意用把工具嵌进流程而不是另起炉灶工具上线初期安全团队很兴奋但设计工程师积极性不高觉得“多了一个系统要维护”。后来我们做了一个很关键的改变不再要求设计工程师去新工具里填写表格、检查分析结果而是让自动化工具以“报告”的形式直接嵌入到设计工程师每周的评审例会材料里。每周自动生成一份“安全分析增量报告”列出本周设计变更影响到的失效模式、需要设计工程师确认的新增失效传播路径、以及哪些安全需求还没有分配到位。设计工程师不需要主动打开什么平台只需要在评审时看着这份报告逐条确认。这个“被动触发”的交互方式极大降低了使用门槛。另外我们让工具自动生成评审纪要的要点包括讨论结论、待办事项、责任人、截止时间。评审会开完之后纪要通过邮件发出去大家不需要回到系统里翻记录。虽然这对工具本身没什么技术含量但团队配合度明显提升。原因很简单工具越少占用人的额外精力人越愿意配合。6. 一个转向系统的实测数据方法论说得再多不如拿一个真实项目看数据。我们选择了一个电动助力转向系统作为试点因为转向系统的安全等级高、功能链路清晰、组件数量适中很适合验证自动化效果。6.1 测试范围与基线试点项目基于一个量产项目的架构快照 v2.3分析范围包括转向扭矩传感器、方向盘转角传感器、EPS 控制器、无刷电机、减速机构、CAN 通信链路。人工基线由一位功能安全工程师加一位系统工程师完成用传统 FMEA 表格式分析自动化流程则由同一套数据模型和工具生成初稿再由同一组工程师审查校正。两种流程都限定在两周内完成第一轮评审。我们比较了初稿生成耗时、失效模式数量、评审期间补充的漏项数量、以及安全需求追踪覆盖率这几个指标。6.2 自动化输出的结果和成本对比以下是这一轮试点比较有代表性的数据指标人工流程Reloaded 流程FMEA 初稿生成耗时约 3 人天自动生成约 40 分钟加上人工补充约 1 人天初稿失效模式条数214 条316 条评审前补充的遗漏项17 条6 条评审会议时长约 8 小时约 4 小时安全需求追踪覆盖率62%96%失效模式条数变多不全是好事里面有一部分是自动生成的低风险条目人工复核后约两成被降级为“非安全相关记录”。但评审前补充的遗漏项从 17 条降到 6 条说明自动生成的底网确实比人工靠记忆展开更密集。评审时长缩短一半主要是因为会议前大家已经就自动报告达成大方向一致会上不用再从零开始建立上下文。6.3 这份数据能说明什么不能说明什么说实话第一次看到这些数字我心里也打鼓担心是团队为了配合项目“表现得好一点”。但仔细看细节耗时下降更多是流程重构带来的不完全是工具本身的功能。比如以前 FMEA 初稿要人工找数据、排版、对齐字段现在这套工作被直接省掉了。漏项减少则更多归功于失效模式库的覆盖度而不是什么智能算法。我不建议把这些数据到处宣传因为它只代表一个试点项目不代表所有子系统都能达到同水平。更重要的启示是目标要选准。我们的目标是“减少安全分析中的重复劳动提高证据链完整性”不是“完全替代人工”。只要这个定位不偏自动化的价值是非常明确的。想真正提高安全性永远要靠人来做深度判断。7. 后续还能怎么扩展我的一点真实体会试点跑通之后不少同事都在问下一步做什么。我从实际场景出发说说我看到的几个方向以及我自己踩坑之后的建议。7.1 和需求管理平台、CI 流水线的联动第一个方向是把安全分析集成到日常开发闭环里。目前我们是设计基线发布后手动触发分析下一步可以做成自动联动需求管理平台一旦有新版本需求或者架构模型库有模型变更工具自动跑一轮“影响分析”只输出变化部分给评审人。这相当于为安全分析建了一条“增量检查流水线”和代码 CI 的思路一致。我在实际开发中发现这一步的价值不是“更智能”而是“更及时”。以前安全分析是阶段性的季度评审或里程碑评审才做一次但如果能随设计变更自动触发很多问题会在设计早期暴露修复成本比后期低一个数量级。这个方向不涉及复杂的算法主要是做好数据触发机制和通知分发。7.2 把可靠性数据和仿真故障注入纳入闭环第二个方向是把定量可靠性数据引入分析。我们在 FTA 阶段已经可以用失效率数据计算顶事件概率但目前这些失效率大多来自供应商手册和实际运行环境有偏差。后续可以接入可靠性试验数据、路试验数据甚至是售后数据让失效模式的发生度评估从“拍脑袋”逐步走向“数据驱动”。同时故障注入仿真的结果也可以反向校准失效模式库。比如在 HIL 测试台上做信号开路、短路、漂移注入得到的系统响应比自动推理的结果更贴近真实。把这些仿真结论写回失效知识库相当于每一次测试都在给安全分析工具“喂数据”。长期坚持知识库的置信度会越来越高。7.3 我的建议先固化流程再谈工具最后想给准备做类似尝试的团队一个实在建议先把你现有的安全分析流程里“哪些步骤是固定动作、哪些步骤是纯经验判断”分清楚再决定自动化边界。固定动作比如从接口清单生成失效传播路径、检查安全需求是否都分配了组件、统计风险等级分布这些适合自动化纯经验判断比如某个失效模式的检测机制是否充分、是否需要新增安全机制这些不适合全自动适合做成“带上下文的建议”。我们 Reloaded 项目做到一半最大的感受是自动化工具最好用的部分不是“自动生成结论”而是“自动把上下文整理好让人快速做出有依据的判断”。如果一开始目标定成“系统自动输出所有安全结论”大概率会失败如果定成“系统把需要人判断的点全部用数据和结构呈现出来”那它就一定是个好工具。希望这篇复盘能帮你少走一些弯路也欢迎在评论区聊聊你们在安全分析自动化里遇到的卡点。 汽车安全分析自动化：从FMEA到数据模型的重构实践
1. 为什么我要把整套安全分析流程推倒重来如果你在整车电子电气设计这条线上待过两三年大概率见过这种场面安全评审前夜安全工程师对着 FMEA 表格里几百行失效模式挨个问设计工程师“这个失效如果发生影响是什么”设计工程师翻着原理图和数据手册现场编原因凌晨一点大家还在群里对口径确保第二天汇报结果一致。这不是某一个团队的问题而是传统“文档驱动型安全分析”的常态。“Auto Design Safety Analysis: Reloaded”是我们内部做了半年的一个重构项目目标很直接把汽车设计阶段的安全分析从人工填表变成“领域知识 规则引擎 数据模型”的自动化流程。标题里 Auto 这个词我始终按两层意思理解一是 Automotive Design汽车设计二是 Automation自动化。这两个意思恰好也是这个项目的两条腿——没有汽车设计的领域知识自动化只会把错误放大没有自动化工具领域知识又会被大量重复劳动淹没。这篇文章是这次重构的完整复盘包括框架选型、数据建模、落地过程中踩过的坑以及一个转向系统项目的实测数据。1.1 传统 FMEA 评审的真实痛点先说痛点因为自动化要解决的永远是人的问题而不是工具的问题。传统 FMEA 的最大问题不是“表格不好填”而是大量工作在做“信息搬运”。系统架构在 SysML 模型里需求在需求管理平台里硬件接口定义在原理图或者接口清单里功能安全目标在另一份文档里。安全工程师做分析时要把这些分散的信息手动抓取出来再逐行填进 FMEA 的“失效模式、失效原因、局部影响、系统影响、检测机制、风险等级”这些字段里。一次中等规模的子系统评审几十个组件、几百个信号、上千条连接关系靠人力去展开通常要两三周。另一个让人头疼的问题是描述口径不统一。同一个失效模式硬件工程师写“输出引脚对地短路”软件工程师写“ADC 采样值跳变到 0”测试工程师写“传感器信号丢失”。三个人其实在讲同一件事但文字不一样评审会上就要花大量时间对齐。等到项目进入下一阶段这些描述还会漂移新版 FMEA 里可能就变成另一个说法追溯性基本靠人脑记忆。第三个问题是风险等级打分的主观性。SSeverity、OOccurrence、DDetection三个维度标准里定义得很清楚真正打起来每个人都有自己的理解。同一个失效模式机械背景的人觉得“这个不太可能发生”电子背景的人觉得“电磁干扰下大概率出现”。这不是谁对谁错而是缺少统一的上下文。自动化工具最大的价值之一就是把这些上下文显式地建模让打分不再完全依赖个人经验。1.2 这次重构的三个目标项目启动前我给自己定了三条硬指标整个 Reloaded 版本都围绕这三条展开。第一把“已知的重复劳动”交给机器。FMEA 初稿、故障树初稿、安全需求清单初稿这些不是创造性工作而是基于组件类型、接口关系、失效模式库的机械展开。自动生成初稿人工负责裁切、补充和判断效率完全不一样。第二让安全需求和设计模型之间建立可追踪的双向链接。从顶层安全目标拆到功能安全需求再分配到具体组件每一步都要能追溯到“为什么会有这条需求”。分析过程中自动生成的所有条目也必须能回溯到对应的失效模式。第三把“文档输出物”变成“工程数据”。以前安全分析的产物是 PDF评审完就归档后续设计变更很难快速反应。这次我们要求所有分析结果以结构化数据存储版本可比较查询可检索设计变更时能自动生成增量的影响分析。这三条其实都不算激进很多成熟团队大概已经做到了。但对我们这种长期依赖人工表格的团队来说算是一次比较大的转向。2. 分析框架选型FMEA、FTA、STPA 不是互相替代的关系很多团队做安全分析开口就是“我们要做 FMEA”。我不太认同这种直接把方法和工具绑定的做法。先想清楚要回答什么问题再选择分析框架不然自动化只是在加速一个可能本来就不合适的流程。ReLoaded 项目启动的第一周我们把 FMEA、FTA故障树分析、STPA系统理论过程分析放在一起做了对比核心结论是它们不是互相替代的关系而是从不同维度回答不同的问题。2.1 FMEA适合逐点排查不适合回答系统级问题FMEA 的分析单元是“组件或功能的一个失效模式”。它的思路是自下而上单个引脚短路了会怎样传感器漂移了会怎样继电器卡滞了会怎样这种逐点排查非常擅长发现单点失效尤其是硬件层面的问题。但 FMEA 对“多个条件组合导致的失效”几乎无能为力。比如“电池电压跌落 控制器重启 通信总线繁忙”同时发生或者“驾驶员在弯道中松开加速踏板的同时转向助力系统进入降级模式”这种场景在 FMEA 表格里很难被自然表达。硬要写就得写组合失效行数爆炸而且容易漏。自动化项目里 FMEA 仍然是最适合打底的方法因为它结构规整字段固定规则容易编码。我们先做 FMEA不是为了替代其他方法而是为了先把单点失效的底网织密。2.2 FTA从顶层失效倒推原因正好补上 FMEA 的短板FTA 的思路是自上而下。先把一个不希望发生的顶层事件定义清楚比如“行车过程中转向助力意外丧失”然后一层一层往下展开是因为电源失效还是控制器异常复位还是电机驱动电路故障每层都用逻辑门连接体现“与”“或”“非”的组合关系。FTA 和 FMEA 正好形成互补。FMEA 从零件往系统看容易漏掉多个失效的组合FTA 从系统往零件看能抓住关键的单点路径和组合路径。自动化做 FTA 的难度比 FMEA 大因为上下层之间的逻辑关系很难全自动生成尤其是“与门”这种组合关系需要非常明确的场景定义。从工具角度FTA 也很适合做定量分析结合失效率数据算出顶事件的概率。这正好为我们后续引入可靠性数据留了口子。2.3 STPA针对“系统行为”而不是“组件失效”现代汽车里大量的安全问题不是硬件坏了而是“行为不正确”。控制器发送了一个不该发送的指令或者在错误的时间发送了一个正确的指令甚至指令没有执行——这一类问题用 FMEA 很难描述因为组件本身没有失效。STPA 把分析对象从“失效模式”换成了“不安全控制动作”关心的是控制器对外部执行器发出的每个动作在特定上下文里会不会导致危险。它特别适合软件占比高、功能逻辑复杂的系统比如智驾域、底盘域控、能量管理这类场景。STPA 的缺点是分析结果不够“条文化”很难直接生成评审用的表格。它对分析师的系统思维能力要求也高。如果团队没有经过 STPA 训练容易变成“四个人对着流程图争论一个动作安不安全”效率很低。为了让你直观理解三类方法的核心我整理了一张表方法出发点分析单元典型问题主要弱点FMEA自下而上组件/功能的失效模式这个 pins 短路会怎样组合失效表达困难FTA自上而下顶事件→原因组合这个危险场景是怎么发生的依赖顶事件定义质量组合规模大STPA系统行为控制动作是否安全这个控制动作是否会导致危险结果较散难以直接形成表格审查2.4 我的选型结论以 FMEA 打底FTA 深入STPA 专题补充我们这个项目最终选的是混合流程每个子系统先跑一遍自动化 FMEA对检测出来的关键失效模式做 FTA再对涉及多控制器协同的功能场景做专题 STPA。自动化的重点放在 FMEA 环节因为它的规则最容易固化FTA 部分用半自动方式工具负责整理结构和漏项逻辑门由人工确认STPA 只对高风险场景启用不要求每个子系统都做。这个选型不是理论上的最优解而是考虑到团队成员背景和投入产出比之后的选择。如果一开始就三套工具全面铺开团队一定会被任务量压垮自动化工具只会成为负担。3. Reloaded 的核心改造把安全分析从“写文档”变成“建模型”框架选型确定后接下来是数据模型设计。这步是整个项目中我认为最关键、也最容易被忽略的部分。很多人做自动化上来就写脚本把表格解析成 Word思路还是“用程序写文档”这其实没有从根上改变流程。我们这次把整个安全分析过程当成“建模”来做设计信息、失效知识、分析规则、安全需求统一用结构化数据表达文档只是这个数据模型的一种输出视图。3.1 核心数据模型分析项、失效模式、控制动作、安全需求我们定义了一套内部叫“SAMSafety Analysis Model”的数据模型核心实体只有四个Analysis Item、Failure Mode、Control Action、Safety Requirement外加若干关系表。Analysis Item 是安全分析的最小单元可以是一个传感器、一个控制器、一个执行器也可以是一个软件模块或者一条通信消息。每个 Analysis Item 必须有父级归属、接口列表、关联的功能清单。没有接口信息和功能上下文下游的失效传播分析就做不了。Failure Mode 是 FMEA 表的行。每条 Failure Mode 必须关联到一个 Analysis Item并带失效类型、失效原因、局部影响、系统影响、检测机制等字段。Reloaded 版本里我们还加了“失效模式来源”用来区分是自动生成的还是人工补充的这为后续质量评估提供了依据。Control Action 是 STPA 分析的最小单元关联到发送方和接收方以及动作发生的上下文。Safety Requirement 则记录了从所有分析条目中派生出的安全需求每条必须关联到上游分析条目并最终分配到具体的设计组件。之所以把四个实体拆开而不是直接写 Excel是为了让关系可追踪。以前 FMEA 表格里“这个失效对应哪条安全需求”全靠人写注释现在是一对一的数据库关系基本不可能丢。3.2 自动生成 FMEA 草稿的逻辑数据模型搭好之后自动化最核心的算法就是“从接口和功能信息推失效传播路径”。我们采用的方法是先按 Analysis Item 的类型套用标准失效模式库。比如“模拟输入引脚”这类组件默认展开“对地短路、对电源短路、开路、漂移、超时”五种失效模式“电机驱动输出”则展开“输出短路、开路、过流、异常关断、非预期使能”等模式。这一步不涉及智能只是一张“组件类型 → 常见失效模式”的映射表。真正的关键在下一步失效传播。系统架构模型里存了各组件之间的信号流关系比如传感器输出信号进入控制器 ADC 输入控制器再通过 PWM 控制电机驱动。如果传感器“输出漂移”了沿着信号流看控制器的“输入值异常”再往下是“控制算法计算出错误的扭矩指令”最终到系统层面上是“非预期驱动扭矩”。这个传播链不是靠字符串匹配做出来的而是依赖每个 Analysis Item 里提前定义好的“输入输出数据接口”。每个接口有哪些信号、信号范围是多少、信号异常会导致下游什么反应这些信息来自设计模型和安全专家共同维护的接口失效字典。这套逻辑跑下来FMEA 草稿的准确率取决于两件事一个是失效模式库覆盖得够不够全另一个是接口失效字典定义得够不够细。第一版上线时我们只覆盖了硬件组件结果软件控制器的分析基本是空白后来把软件逻辑单元也纳入了 Analysis Item覆盖率才上来。3.3 安全需求的追踪关系与一致性检查FMEA 草稿生成后转换逻辑会自动为每条高风险失效模式创建一条安全需求。比如传感器“输出信号漂移”被标记为安全相关失效后自动生成“当传感器输出信号超出 [x, y] 范围时控制器应在 50 ms 内进入安全状态并执行降级策略”这样的需求草稿。这个自动生成的功能不是让你直接用而是保证“每条高风险的失效模式都有人去思考怎么对应”避免评审时发现某个高风险失效没有对应任何安全机制。这一点在人工流程里特别容易漏因为安全工程师会遗漏也会因为 FMEA 持续更新而漏掉新增条目。Reloaded 版本还加了一组自动一致性检查规则包括三件事每个 ASIL C 及以上等级的失效模式必须至少关联一条 Safety Requirement。每条 Safety Requirement 必须分配到一个设计组件不支持“未分配”状态。每条 Safety Requirement 必须关联到一个验证方法无论是测试、仿真还是分析。每次运行后工具会生成一份“一致性检查报告”直接列出违反规则的条目。这一步对评审效率的提升非常大因为以前人工查出“这条需求没分配”需要把一堆文档来回翻现在工具自动扫一遍就有结果。根据我个人的经验一致性检查的价值甚至比 FMEA 自动生成还大因为它解决的是“安全证据链是否完整”这个根本问题。4. 数据源和失效知识库自动化最容易被低估的部分准备数据模型和规则引擎大概花了两周之后我以为最快进入实战了结果真正耗时的是数据源梳理和失效知识库建设。自动化有一个铁律输入是垃圾输出就是垃圾。这句话在我们项目里被验证得淋漓尽致。4.1 设计数据从哪来架构模型、需求条目、接口定义要自动分析设计安全性首先得把设计信息结构化地读进来。我们主要对接了三类数据源系统架构模型包括组件列表、层级关系、信号流、通信协议。这部分一般来自 SysML 或 EA 等架构工具格式还算规范但很多组件只有名字没有详细接口定义。功能需求与安全需求来自需求管理平台包含需求的唯一标识、文字描述、优先级、ASIL 等级等。这里的问题在于需求粒度差别很大有的需求精确到信号级有的还停留在“系统应确保安全”这种空洞表述。硬件接口清单主要包括连接器、引脚、信号方向、电压范围、通信类型。这是做失效传播最重要的输入但也是最难维护的输入。项目中期设计变更频繁接口清单经常和架构模型对不上。我们做了一个“数据归一化层”来处理这些问题。不管原始数据来自哪里统一转换成 SAM 模型的标准结构并在导入时做一次字段合法性校验。如果某个 Analysis Item 没有接口信息工具会标记为“输入数据不完整”而不是强行套规则生成结果。这样避免产生大量无意义甚至误导性的失效模式。4.2 失效知识库的建立从历史问题库、测试缺陷、供应商反馈失效模式库是整个自动化的“燃料”。第一版我们参考了通用的元件可靠性手册但很快发现通用手册只能覆盖“电阻开路”“电容短路”这种基础失效离汽车级应用差得很远。真正有价值的知识库一定来自企业内部积累。我们花了三周时间把以下来源的数据导入了失效知识库近三年的售后索赔数据中与电子电气相关的故障描述。测试部门的故障注入报告尤其是针对传感器、控制器、执行器的注入结果。供应商提交的 8D 报告里涉及的失效模式和根因。历史项目里已经人工审查过的 FMEA抽取出高频失效模式。每条知识都打上了“来源”和“置信区间”。比如售后索赔数据里出现的失效模式可信度较高供应商 8D 报告里某个具体批次的失效模式可信度也高而通用手册里的失效模式只作为兜底。这个设计在后面过滤误报的时候帮了大忙因为我们能根据来源优先级调整规则的权重。4.3 版本一致性和基线管理这部分是最枯燥、也最容易翻车的。安全分析和设计版本强相关同一个控制器芯片从 A 版本换成 B 版本引脚定义都可能变失效传播路径也随之变化。如果工具连接的是实时更新的数据库每次一重跑结果都不同谁也没法做评审。我们后来确立了“分析快照”机制。每次安全分析只针对一个固定的设计基线通常由配置管理平台发布一个带版本号的架构快照。分析工具从这个快照读取数据生成的 FMEA、故障树和需求追踪结果也打上同样的版本号。一旦设计发生变更先跑“变更影响分析”只对受影响的 Analysis Item 和依赖路径重新分析而不是全部重跑。这套机制在项目后期展现的价值最大。因为设计迭代不断发生如果每次都全量重跑安全分析的工作量会变成一个无底洞而只跑增量评审团队可以在最短时间内看到“这次改动引入了哪些新的失效模式、哪些原有失效模式的严重度或发生度可能变化”。这也是 Reloaded 版本比旧流程高效的重要原因之一。5. 落地过程踩过的坑误报、漏报和“工具不信任”再完美的工具如果团队不用或者用了但结果没有人认真复核数字化投入就打水漂了。落地阶段我们遇到三个非常现实的坑写出来给大家避避雷。5.1 规则误报率一开始高到没人看第一轮自动化建议跑出来结果非常“壮观”工具生成了 1200 多条失效模式安全工程师复核完真正有分析价值的只有不到 30%。剩下的 70% 全是“泛化失效”随便一个信号输入都写“可能发生短路导致信号异常”这类描述放到哪个项目里都成立但没有任何设计针对性。误报的根源是规则设计得太粗。我们没有区分“这个组件的失效是否影响安全相关功能”。一个用于氛围灯的 PWM 输出和用于转向助力的 PWM 输出工具都套用了同一套“输出短路、开路、过流”规则这显然不合理。解决办法是引入“安全相关路径判定”。在模型里每个 Analysis Item 被标记为“安全相关”或“非安全相关”这个标记可以由工具根据“组件是否处于安全关键功能链路上”自动判断也允许人工调整。对于非安全相关组件自动生成的失效模式只保留基本记录不展开详细安全分析。这样把 1200 多条压缩到 400 多条误报率降到可接受范围。这个经验对后来很有用“自动生成的东西必须允许人工修正同时保留修正痕迹”。我们给每个 Analysis Item 加了“安全相关置信度”字段工具自动计算人可调。这样一来误报可以被快速压制但人的修正不会被覆盖。5.2 自动建议和安全目标冲突时怎么办自动化会生成很多“看起来非常吓人”的建议。比如工具发现转向电机控制器的故障响应时间比安全目标要求的长就自动建议“增加 watchdog 冗余和独立关断通道”。这个建议听起来合理但系统架构师评估后认为现有监控机制已经覆盖了瞬态故障场景增加冗余通道会显著增加 BOM 成本还会引入新的共因失效风险。这种情况如果在旧流程里可能演变成一场争论工具说有问题架构师说没问题最后不了了之。我们在 Reloaded 版本里建立了一个“建议裁决流程”每一条自动生成的分析结论都带一个状态——接受、拒绝、需要评审。架构师必须对“拒绝”或“接受”给出理由并记录在数据模型里。不要小看这个“拒绝留痕”机制。它把工具从“裁判官”变成了“建议者”既保留了自动化的效率也留住了人做最终决定的权力。团队对工具的信任正是靠这种“工具不强迫你但它帮你把问题摆清楚”的体验建立起来的。5.3 让工程师愿意用把工具嵌进流程而不是另起炉灶工具上线初期安全团队很兴奋但设计工程师积极性不高觉得“多了一个系统要维护”。后来我们做了一个很关键的改变不再要求设计工程师去新工具里填写表格、检查分析结果而是让自动化工具以“报告”的形式直接嵌入到设计工程师每周的评审例会材料里。每周自动生成一份“安全分析增量报告”列出本周设计变更影响到的失效模式、需要设计工程师确认的新增失效传播路径、以及哪些安全需求还没有分配到位。设计工程师不需要主动打开什么平台只需要在评审时看着这份报告逐条确认。这个“被动触发”的交互方式极大降低了使用门槛。另外我们让工具自动生成评审纪要的要点包括讨论结论、待办事项、责任人、截止时间。评审会开完之后纪要通过邮件发出去大家不需要回到系统里翻记录。虽然这对工具本身没什么技术含量但团队配合度明显提升。原因很简单工具越少占用人的额外精力人越愿意配合。6. 一个转向系统的实测数据方法论说得再多不如拿一个真实项目看数据。我们选择了一个电动助力转向系统作为试点因为转向系统的安全等级高、功能链路清晰、组件数量适中很适合验证自动化效果。6.1 测试范围与基线试点项目基于一个量产项目的架构快照 v2.3分析范围包括转向扭矩传感器、方向盘转角传感器、EPS 控制器、无刷电机、减速机构、CAN 通信链路。人工基线由一位功能安全工程师加一位系统工程师完成用传统 FMEA 表格式分析自动化流程则由同一套数据模型和工具生成初稿再由同一组工程师审查校正。两种流程都限定在两周内完成第一轮评审。我们比较了初稿生成耗时、失效模式数量、评审期间补充的漏项数量、以及安全需求追踪覆盖率这几个指标。6.2 自动化输出的结果和成本对比以下是这一轮试点比较有代表性的数据指标人工流程Reloaded 流程FMEA 初稿生成耗时约 3 人天自动生成约 40 分钟加上人工补充约 1 人天初稿失效模式条数214 条316 条评审前补充的遗漏项17 条6 条评审会议时长约 8 小时约 4 小时安全需求追踪覆盖率62%96%失效模式条数变多不全是好事里面有一部分是自动生成的低风险条目人工复核后约两成被降级为“非安全相关记录”。但评审前补充的遗漏项从 17 条降到 6 条说明自动生成的底网确实比人工靠记忆展开更密集。评审时长缩短一半主要是因为会议前大家已经就自动报告达成大方向一致会上不用再从零开始建立上下文。6.3 这份数据能说明什么不能说明什么说实话第一次看到这些数字我心里也打鼓担心是团队为了配合项目“表现得好一点”。但仔细看细节耗时下降更多是流程重构带来的不完全是工具本身的功能。比如以前 FMEA 初稿要人工找数据、排版、对齐字段现在这套工作被直接省掉了。漏项减少则更多归功于失效模式库的覆盖度而不是什么智能算法。我不建议把这些数据到处宣传因为它只代表一个试点项目不代表所有子系统都能达到同水平。更重要的启示是目标要选准。我们的目标是“减少安全分析中的重复劳动提高证据链完整性”不是“完全替代人工”。只要这个定位不偏自动化的价值是非常明确的。想真正提高安全性永远要靠人来做深度判断。7. 后续还能怎么扩展我的一点真实体会试点跑通之后不少同事都在问下一步做什么。我从实际场景出发说说我看到的几个方向以及我自己踩坑之后的建议。7.1 和需求管理平台、CI 流水线的联动第一个方向是把安全分析集成到日常开发闭环里。目前我们是设计基线发布后手动触发分析下一步可以做成自动联动需求管理平台一旦有新版本需求或者架构模型库有模型变更工具自动跑一轮“影响分析”只输出变化部分给评审人。这相当于为安全分析建了一条“增量检查流水线”和代码 CI 的思路一致。我在实际开发中发现这一步的价值不是“更智能”而是“更及时”。以前安全分析是阶段性的季度评审或里程碑评审才做一次但如果能随设计变更自动触发很多问题会在设计早期暴露修复成本比后期低一个数量级。这个方向不涉及复杂的算法主要是做好数据触发机制和通知分发。7.2 把可靠性数据和仿真故障注入纳入闭环第二个方向是把定量可靠性数据引入分析。我们在 FTA 阶段已经可以用失效率数据计算顶事件概率但目前这些失效率大多来自供应商手册和实际运行环境有偏差。后续可以接入可靠性试验数据、路试验数据甚至是售后数据让失效模式的发生度评估从“拍脑袋”逐步走向“数据驱动”。同时故障注入仿真的结果也可以反向校准失效模式库。比如在 HIL 测试台上做信号开路、短路、漂移注入得到的系统响应比自动推理的结果更贴近真实。把这些仿真结论写回失效知识库相当于每一次测试都在给安全分析工具“喂数据”。长期坚持知识库的置信度会越来越高。7.3 我的建议先固化流程再谈工具最后想给准备做类似尝试的团队一个实在建议先把你现有的安全分析流程里“哪些步骤是固定动作、哪些步骤是纯经验判断”分清楚再决定自动化边界。固定动作比如从接口清单生成失效传播路径、检查安全需求是否都分配了组件、统计风险等级分布这些适合自动化纯经验判断比如某个失效模式的检测机制是否充分、是否需要新增安全机制这些不适合全自动适合做成“带上下文的建议”。我们 Reloaded 项目做到一半最大的感受是自动化工具最好用的部分不是“自动生成结论”而是“自动把上下文整理好让人快速做出有依据的判断”。如果一开始目标定成“系统自动输出所有安全结论”大概率会失败如果定成“系统把需要人判断的点全部用数据和结构呈现出来”那它就一定是个好工具。希望这篇复盘能帮你少走一些弯路也欢迎在评论区聊聊你们在安全分析自动化里遇到的卡点。