一、从 “失效” 到 “预防”：FMEA的核心价值
在新时代智能交通等关键领域，软件代码行数已突破亿级，一个软件逻辑错误可能导致灾难性后果，行业数据显示，软件失效引发的系统性风险占比高达60%。例如，某车企因软件误判电池状态导致自燃事故，根源正是未在早期识别电压采样算法缺陷。这类事故凸显了失效模式与影响分析（FMEA）的重要性，通过结构化分析潜在失效模式，帮助企业让软件FMEA成为安全开发的 “免疫系统”，而非事后补丁。
二、软件FMEA及系统/硬件FMEA的区别？
FMEA（Failure Mode and Effects Analysis）是一种以预防为核心的质量管理方法，通过结构化流程（七步法）识别系统/组件可能的失效模式（如传感器数据丢失）、评估其对功能/安全的直接影响（如紧急制动失效），并追溯失效根源（如滤波算法参数错误），最终制定预防措施，实现风险前移管控。其核心逻辑遵循“失效三要素”（模式-影响-原因）与“七步法闭环”（定义范围→结构分析→功能分析→失效分析→风险评估→措施优化→持续监控），形成从风险识别到动态监控的完整链条，然而，在软硬件深度融合的智能系统中，FMEA在软硬件的应用逻辑呈现还是存在着如下差异：
三、为什么软件FMEA成为 “必答题”？
1. 软件失效的特殊性
1) 系统性风险：软件缺陷一旦存在，可能在特定条件下重复触发（如某ECU因未处理浮点溢出导致偶发重启）。
2) 动态复杂性：软件行为依赖输入条件、系统状态及时序，传统测试难以覆盖所有场景（如多任务调度冲突）。
2. 行业标准驱动
ISO26262明确要求将FMEA类似的分析方法纳入功能安全开发流程，例如：
1) ASIL D级功能需通过FMEA确保探测度≤2（某电池管理系统通过冗余ADC通道实现）。
2) 安全目标需与FMEA的严重度（S）评估直接关联。
3. 成本效益比
研究表明，在设计阶段发现并修复软件缺陷的成本，仅为量产阶段的1/100（某车企通过FMEA提前发现导航路径规划算法错误，避免召回损失）。
四、软件FMEA的几大痛点与挑战
1. 动态行为的不可预测性
软件功能的执行依赖实时输入条件、系统状态及复杂算法逻辑，这使得其行为难以通过静态分析完全预判。例如，自动驾驶系统可能因暴雨天气下的传感器噪声触发误判，或因用户非常规操作序列导致功能异常。
2. 接口交互的复杂性
模块间数据交互是软件失效的高发区。例如，某ADAS系统因摄像头与雷达数据同步失败导致目标误判，根源在于接口时序未对齐。为应对这一问题，需建立接口列表，明确数据类型、范围及交互时序，并通过数据流分析工具（如 Simulink）验证兼容性。同时，采用防御性编程策略（如输入数据校验、异常熔断机制）可有效阻断失效链传递，降低连锁风险。
3. 系统性失效的顽固性
软件逻辑缺陷可能长期潜伏，直至特定条件触发。例如，某变速箱控制单元因未处理负数扭矩输入导致动力中断，该问题在常规测试中未暴露，最终在用户激烈驾驶时显现。这类系统性失效的隐蔽性强，依赖传统测试方法难以有效识别。
4. 量化评估的局限性
传统RPN（风险优先级数）对软件的适用性存疑，因其基于随机失效假设，而软件失效多为系统性事件。例如，某电池管理系统因算法缺陷导致过压保护失效，其风险无法通过简单的发生概率评估。此外，软件失效的频率（O）和探测度（D）受设计成熟度、测试覆盖度等主观因素影响，难以客观量化。
五、CREEK工程实践
1．软件FMEA分析什么？
我们需要谈的第一个问题是：软件FMEA需要分析到什么细节程度？
以ISO26262对于软件安全分析的参考为例，“ISO26262, Part6, Annex E: Safety analyses and dependent failure analyses are intended to be applied at the software architecture level. Code level safety analyses (e.g. with respect to runtime errors such as divide by zero, access beyond array index boundary) are neither required nor considered necessary for the following reasons...”
正如2月份开展的第三期云氪专家讲坛（CETE-03）上所讲，软件FMEA分析的是软件设计，设计本身是个很粗放和抽象的概念，它可以在一个很高的软件架构维度，比如到软件组件层级，也可以在一个中间的软件设计维度，比如到软件单元层级，同样，亦可以在一个很细节的实现维度，比如到每个软件函数。如下视图展示了软件组件，软件单元和软件函数的简单关系。
那么，我们到底如何选择？笔者认为，各个层级和维度都应该纳入到软件FMEA的分析中去。因为在不同的维度上，能够识别的潜在系统性失效侧重点不同，对设计和开发的指导也会有所侧重。
我们云氪专家讲坛上讲过，软件FMEA主要重点识别软件分析对象（组件，单元，函数）的几个方面：软件对象的功能逻辑，软件对象的数据接口，软件对象的时序和执行，软件对象的内存属性，软件对象的部署。那么下表我们就从这几个维度罗列下软件FMEA对不同层级对象开展分析时，提供的贡献：
我们要谈的第二个问题就是，我们需要什么样的输入来支持开展软件FMEA分析？
在云氪专家讲坛上，多位同事提到了这个问题，我们到底需要什么样的输入才能开展软件FMEA。其实，承接第一个问题的部分，我们通过软件FMEA分析维度，应该可以看出我们需要的其实是一个完整的软件架构和软件详细设计。笔者认为，一个完整的软件架构设计至少包括如下几个方面：
-静态视角：软件有哪些层级，哪些组件，每个组件的接口是什么样的？软件的资源是如何部署到芯片的内核，存储等资源上的？
-功能视角：软件的组件或者单元，如何配合来实现系统分配给软件的功能？
-动态视角：软件的各个组件和单元是如何被调度的？软件的状态是如何切换的？
当然，这部分如何具体开展也是一个很大的话题，由于本篇幅有限，笔者会在后续文章中针对软件架构设计展开单独的分享。
2．软件FMEA如何开展？
话接上期云氪讲坛，我们以IQ-FMEA工具使用为例，首先我们需要的是构建一个软件FMEA结构树。以下我们推荐了如下结构：
每个最底层的失效原因层级，我们把它分成两个部分：
在软件概念设计或者高层软件架构设计阶段，可以参考上图标绿色的部分，针对软件组件本身，接口的失效，分析它对软件系统功能的影响，并引导出概念性的需求和设计约束，用来传递给下游的设计工作。比如，我们基于SWC的功能逻辑和部署，评估它的各个失效对系统软件功能链路里的影响是什么，以及如何应对。如下是一个示例，某个SWC的输入接口时效性问题，会导致系统软件计算的max allowed限制产生问题，从而错误的抑制系统的输出能力：
在详细软件架构设计（或软件组件设计）中，此时软件已经细分到软件单元和软件实现层面，此时可以参考上图标蓝色的部分，分析它对软件组件功能的影响，并引导出详细的设计需求和设计约束。
针对Design error，我们主要考虑软件单元或函数的行为，软件单元或函数的接口，软件单元或函数的配置参数，软件单元或函数的标定参数等。我们常规考虑的措施可以参见如下：
- 参考公司指定的软件开发手册或指南开展设计
- 软件架构，详细设计评审
- 引入相关安全或诊断机制，如对输入接口或参数进行合理性诊断等
- 基于需求的软件测试，基于结构覆盖度的测试分析
- 软件静态检查
- 标定参数评审
- 软件代码评审
- etc
针对FFI，我们主要考虑软件单元或函数的执行时间和顺序，软件单元或函数的数据交互，软件单元或函数的内存属性等。我们常规考虑的措施可以参见如下：
- 引入相关安全或诊断机制，如对输入接口或参数进行合理性诊断等
- 内部的安全数据通信链路
- 安全的操作系统调度监控和保护
- 内存和运行的MPU
- 冗余和异构存储
- 任务或者运行实体的程序流监控
- E2E机制
- etc
六、给工程师与企业的一些建议
一个好的FMEA要有一个好的设计，完整的表达清楚系统或者软件的设计思路和行为，方能更好的开展针对性的分析。引入系统或者软件工程的开发理念和方法论，是做好FMEA的一个最佳实践。
工程师需在需求阶段即启动FMEA，通过跨部门协作（开发、测试、安全团队）覆盖多维度风险，并借助专业工具（如IQ-FMEA）管理失效链与生成风险矩阵。
企业层面，应定期开展方法论培训以确保团队掌握AIAG&VDA等最新标准，建立包含行业案例与历史数据的失效模式库，并将FMEA深度融入敏捷开发流程，强制迭代周期输出风险报告。
未来趋势上，AI辅助分析（如通过AI生成失效模式）、MBSE 集成（与 SysML结合实现设计 - 分析闭环）等可能成为提升软件FMEA效能的关键路径。
七、结语
软件FMEA是智能时代的 “安全基石”。通过系统性分析动态行为、接口交互和系统性风险，企业可将软件失效概率降至百万分之一以下。在 “软件定义一切” 的今天，唯有将FMEA融入开发血脉，才能打造真正可靠的智能系统。
公众号 |氪技术 欢迎转发分享
网 址 |www.creek-auto.com.cn
