笔记：A coupled failure mode and effects analysis method for hardware-software failure interactions in embedded systems of intelligent equipment

A coupled failure mode and effects analysis method for hardware-software failure interactions in embedded systems of intelligent equipment

Abstraction

Failure mode and effects analysis (FMEA) is an effective risk prevention and control method that has been widely applied across various domains to identify potential failures and enhance system reliability. However, conventional FMEA methods often analyze software and hardware failures in isolation, making it difficult to adequately identify or assess the impact of hardware-software interactions on system safety. To address this limitation, this paper proposes an FMEA method that accounts for hardware-software fault coupling (HSFC-FMEA), focusing on the influence of such couplings on the Risk Priority Number (RPN). By incorporating the Hadamard product and power-exponent based inner/outer product mappings, a fault mode coupling matrix and computational model are constructed to calculate the RPN for coupled failure modes. Furthermore, using sparse matrix compression, the HSFC-FMEA method can be extended to large-scale systems with integrated hardware-software functionalities beyond embedded systems. A case study on an intelligent gas filling control device demonstrates the effectiveness of this method. By incorporating coupling effects between software and hardware fault modes in severity, occurrence, and detectability, it introduces a new dimension to risk assessment in integrated systems, thereby addressing the oversight of coupled failure modes caused by isolated analysis. Comparisons with classical methods further confirm the adaptability and effectiveness of HSFC-FMEA.

摘要翻译：故障模式与影响分析（FMEA）是一种广泛应用于多个领域的主动风险预防与控制方法，可用于识别潜在故障并提高系统可靠性。然而，传统FMEA通常分别分析软件和硬件故障，很难充分识别和评价软硬件交互对系统安全性的影响。针对这一问题，本文提出考虑软硬件故障耦合的FMEA方法（Hardware-Software Failure Coupling FMEA，HSFC-FMEA），重点研究软硬件故障耦合对风险优先数（RPN）的影响。方法引入Hadamard积以及基于幂指数的内/外积映射，构造故障模式耦合矩阵和计算模型，以获得耦合故障模式的RPN；同时通过稀疏矩阵压缩降低大规模软硬件一体化系统的分析规模。作者以智能气体加注控制装置为案例，在Severity、Occurrence和Detection三个维度中显式加入软硬件故障耦合影响，由此识别传统独立分析可能遗漏的耦合故障模式。与传统FMEA、模糊FMEA等方法的比较进一步验证了HSFC-FMEA的适用性。

Introduction

智能装备中的嵌入式控制系统本质上是软件和硬件共同完成系统功能。传感器、处理器、接口电路和执行机构负责物理信息的获取与执行，软件则完成信号处理、状态判断、控制逻辑和异常处置。因此，最终事故往往不一定由某一个单独的硬件故障或软件缺陷直接造成，而可能来自二者在特定条件下的共同作用。

论文给出了一个非常直观的例子：铁路信号设备受到雷击后无法正常输出车辆状态，这本身属于硬件故障；与此同时，读取该信号的软件存在if-case设计缺陷。当系统没有收到车辆信号时，软件没有进入面向危险的安全状态，而是继续使用之前保存的正常信号，最终错误地显示绿灯。事故后果并不是“硬件故障 + 软件故障”两个独立影响的简单相加，而是二者耦合以后形成了新的危险行为。

传统FMEA通常对Hardware FMEA和Software FMEA分别分析，再使用：

RPN = S × O × D

对每个故障模式单独排序。这种方式隐含了一个重要假设：不同故障模式基本可以独立评价。

本文认为，在软件密集型嵌入式系统中，这个假设并不总成立。一个硬件故障可能触发软件异常，一个软件错误也可能让硬件持续工作在错误状态，甚至造成过载和物理损伤。因此，需要在原有FMEA之外增加一个Hardware-Software Failure Coupling（HSFC）分析层。

HSFC-FMEA overview

HSFC-FMEA并没有替换传统FMEA，而是在已有Hardware FMEA和Software FMEA结果之上增加耦合分析。

作者把整个过程概括为三个主要步骤：

1. 根据系统功能关联建立Hardware-Software Failure Matrix，并使用Sparse Matrix Compression去除不存在耦合关系的元素；
2. 由多专业专家使用Delphi Method分别评价软硬件故障在S、O、D三个维度上的Coupling Degree；
3. 通过矩阵外积、Hadamard Product和幂指数缩放计算Coupled Severity、Coupled Occurrence、Coupled Detection以及最终的Coupled RPN（C-RPN）。

完整流程中，系统工程、硬件工程和软件工程人员共同参与。若耦合分析发现高风险项，则设计分别反馈到硬件或软件侧进行修改，再重新进行FMEA和耦合计算。

因此，这篇文章对FMEA最直接的扩展可以写成：

Independent Hardware FMEA + Independent Software FMEA + Coupling Matrix → HSFC-FMEA

Why coupling needs a separate risk dimension

传统FMEA中，S、O、D均在1～10范围内评分：

• Severity（S）：故障后果严重程度；
• Occurrence（O）：故障发生可能性；
• Detection（D）：故障被发现的难易程度。

对于软硬件耦合故障，仅知道两个独立故障各自的S/O/D还不够。例如一个硬件故障本身Severity很高，但软件可能及时检测并进入Fail-safe，因此实际耦合风险较低；反过来，一个本来可以容忍的硬件异常，如果恰好与异常软件逻辑同时存在，可能让后果迅速放大。

本文因此新增Coupling Degree X，分别建立：

X_S, X_O, X_D

也就是说，软件—硬件故障组合不仅有一个“是否相关”的标签，而是分别评价这种交互对严重度、发生度和可探测度产生多大的放大或削弱作用。

Coupling degree

论文把Coupling Degree分为五类。

Negative coupling

两个故障模式之间的交互反而削弱原有影响，耦合系数设置为0.1。

No coupling

两个故障模式之间没有有效交互，耦合系数设置为0。这类组合在后续矩阵压缩中可以直接去除。

Weak coupling

交互只轻微放大故障影响，耦合程度为1～2。

Moderate coupling

软硬件交互明显放大Severity、Occurrence或Detection，取值为3～6。

Strong coupling

故障组合可能使后果出现非常明显甚至不可接受的放大，耦合程度为7～10。

这里最重要的不是具体等级名称，而是作者把“软硬件有没有关系”进一步量化为S/O/D三个独立耦合矩阵，使同一对故障模式可以在不同风险维度表现出不同强度。

Delphi evaluation

Coupling Degree并不是直接由设备数据自动得到，本文采用Delphi Method组织专家评价。

建议专家组包含5～10人：

• 1～3名software engineers；
• 1～3名hardware design engineers；
• 1～2名system designers；
• 1～2名technical supervisors。

评价进行三轮匿名咨询。第一轮收集开放式意见；后续轮次对S/O/D耦合程度进行定量评分，并把统计结果匿名反馈给专家重新评价。

论文采用最终轮次的median作为Coupling Degree结果，并要求连续两轮意见趋于稳定。所有评价项的Coefficient of Variation低于给定一致性标准后结束评价。

这种设计的作用是尽量降低某一个专家极端判断对矩阵结果的影响。

Hadamard-product coupling model

本文数学部分的核心是把Hardware FMEA和Software FMEA结果转化为矩阵。

假设有m个硬件故障模式和n个软件故障模式。

硬件Severity表示为列向量，软件Severity表示为行向量。两者首先通过outer product生成m × n基础矩阵，这个矩阵的每一个元素都对应：

Hardware failure i × Software failure j

然后再与同维度的Coupling Degree Matrix进行Hadamard Product，即逐元素相乘。

Hadamard Product定义为：

(A ⊙ B)_ij = A_ij × B_ij

因此，每个软硬件故障组合都有独立的耦合参数，不会因为矩阵运算而与其他组合混在一起。

Generalized power-exponent fusion

如果直接把hardware S、software S和coupling degree全部继续相乘，数值会快速膨胀。

作者因此对基础风险因素和耦合因子分别进行幂指数收缩：

• 对hardware/software同类S/O/D组合使用p = 1/2；
• 对S/O/D三个Coupling Degree的乘积使用q = 1/3。

因此，两个独立风险因素先取平方根后进行外积，三个耦合参数则使用立方根缩放。

Severity基础矩阵可以理解为：

S_ij = sqrt(S_H,i) × sqrt(S_S,j)

随后：

ES = S ⊙ X_S^(1/3)

同样得到：

EO = O ⊙ X_O^(1/3)

ED = D ⊙ X_D^(1/3)

最终Coupled RPN为：

C-RPN = ES ⊙ EO ⊙ ED

换句话说，每个矩阵位置(i,j)最终给出一个“硬件故障i + 软件故障j”的耦合风险值。

Why use a matrix

矩阵表达有两个实际意义。

第一，它保留了FMEA原来的分析习惯。硬件工程师和软件工程师仍然先做各自熟悉的FMEA，不需要从头使用一套完全不同的概率模型。

第二，它把“所有hardware failure × all software failure”的潜在组合显式铺开。某些独立分析中风险并不最高的故障，组合后可能进入高风险区域。

因此，矩阵不是只用于数学计算，也是一种完整性检查工具：它迫使分析团队逐项确认哪些软硬件故障真正存在功能交互。

Sparse matrix compression

软硬件组合数量很容易膨胀。

如果系统具有数百甚至数千个组件，每个组件又包含多个故障模式，完整矩阵会非常大。但实际系统中，大多数软件模块并不会与所有硬件故障发生直接功能耦合。

因此，作者首先建立Initial Coupling Matrix，把明显没有结构或功能关系的软硬件组合设为0，再使用Sparse Matrix Compression去掉这些零元素。

案例中具体采用：

• CSR（Compressed Sparse Row）；
• CSC（Compressed Sparse Column）。

最终只保留存在HSFC关系的故障组合进行后续Delphi评价和C-RPN计算。

这个步骤本质上是把分析工作量从：

all hardware failures × all software failures

压缩为：

functionally relevant hardware-software failure pairs

Dynamic evolution model

论文还尝试把环境和时间因素引入HSFC-FMEA，使O和D不再完全是固定评分。

Software attributes

软件故障属性中，Occurrence可以随运行时间变化：

dO_sj(t)/dt = λ_j - μ_j O_sj(t)

其中：

• λ_j表示风险累积速度；
• μ_j表示风险缓解速度。

因此，软件缺陷的触发概率可以随系统运行状态逐步演化。

Detection同样允许写成D_sj(t)，用于描述日志覆盖、监测机制和运行时间对软件故障可探测性的影响。

Hardware attributes

硬件Occurrence则被写成环境参数θ的函数，例如：

O_hi(θ) = α_i e^(β_i θ)

Detection也可以随环境变化。

作者进一步使用Arrhenius Equation和Hallberg-Peck Model描述温度与湿度对硬件寿命和失效率的影响。

因此，动态C-RPN形式为：

RPN_ij(t, θ) = S_ij(t, θ) × O_ij(t, θ) × D_ij(t, θ)

这里的思路是：软硬件耦合程度不必永远是一个固定风险，它还可以随运行时间和工作环境发生改变。

HSFC-FMEA analysis process

实际工程使用中，作者给出的步骤为：

1. 确定FMEA边界，分别完成Hardware FMEA和Software FMEA；
2. 建立跨专业分析团队；
3. 找出真正具有软件—硬件接口关系的模块与设备；
4. 用硬件故障模式作为纵向、软件故障模式作为横向建立Coupling Matrix；
5. 通过功能和结构关系把明显无关的组合设为0并压缩矩阵；
6. 使用Delphi评价X_S/X_O/X_D；
7. 计算Coupled S/O/D和C-RPN；
8. 根据排序识别严重耦合故障并修改设计；
9. 对修改后的系统重新分析。

这个流程仍然保持FMEA典型的“识别—排序—改进—再分析”闭环，只是风险对象从单个故障扩展为软硬件故障组合。

Case study: intelligent gas filling control device

案例对象是一套以嵌入式系统为核心的智能气体加注控制设备。

系统硬件包括：

• power supply；
• transformer；
• pressure pump；
• pipeline；
• pressure sensor；
• main control chip；
• contactor；
• alarm module等。

软件负责传感器信号读取、控制逻辑、I/O驱动和泵的启停控制。

系统还包含软硬件协同的overpressure protection：压力传感器持续检测储罐压力，软件判断是否超过安全范围，再由控制电路切断加注泵。

因此，如果压力传感器、驱动电路、contactor和控制程序中的异常同时出现，可能直接影响储罐超压保护功能，非常适合展示HSFC-FMEA。

Functional decomposition

作者按照FMEA方式进一步展开系统功能。

总体系统被分为：

• Power Supply System；
• Pressurization and Gas Storage；
• Central Processing Unit。

再继续向下分解到Power Control、Pressure Detection、Pressure Tank、Pressure Sensor、CPU Module、Processor Module等更具体对象。

这种结构展开用于确定两个问题：

1. 哪些硬件单元需要进入Hardware FMEA；
2. 哪些软件模块与这些硬件之间存在真实的功能接口。

因此，Coupling Matrix并不是把所有软硬件故障随机组合，而是建立在功能分解和接口关系基础上。

Software behavior

案例中的软件分析重点选择RB7 port driver program unit。

该程序负责初始化端口并根据RA1、RA2等输入条件完成时序判断和输出切换。

作者最终选取三个代表性Software Failure Modes：

• SFM1：Timing error
• SFM2：No output error in driving
• SFM3：Driving output stays in state 1

这些软件故障会与硬件驱动电路、contactor和传感器中的多个故障发生交互。

Initial FMEA scale

整个装置包含170个sub-components，共识别出510个故障模式：

• 480个hardware-related failure modes；
• 30个software-related failure modes。

因此初始耦合矩阵规模达到：

480 × 30

作者先由工程师根据结构和功能关系排除明显不相关的组合，再使用CSR和CSC压缩矩阵。

为正文重点分析，案例进一步展示了15个硬件故障模式和3个软件故障模式。

Independent FMEA results

传统独立分析中，Hardware RPN范围为：

15 ～ 700

Software RPN范围为：

360 ～ 648

其中最高Hardware RPN来自：

HFM4：Transistor Q1 open circuit

S = 10, O = 10, D = 7

RPN = 700

最高Software RPN来自：

SFM3：Driving output stays in state 1

S = 9, O = 9, D = 8

RPN = 648

论文还拟合了RPN与Severity之间的关系。软件FMEA的幂指数高于硬件，作者据此认为软件故障模式整体上具有更高的Occurrence和Detection评分。

Coupling degree results

专家分别对45个hardware-software组合在S、O、D三个维度进行Coupling Degree评价。

结果显示：

• Severity Coupling的均值和变化范围最大；
• Occurrence Coupling整体相对较低；
• Detection Coupling与Occurrence接近。

也就是说，在这个案例中，软硬件故障交互最明显的作用不是让单个故障“更容易发生”，而是让最终系统后果显著变严重。

这是本文比较值得注意的一点：coupling并不一定均匀地放大S、O、D，而可能主要改变某一个风险维度。

Expert consistency and robustness

为了验证Coupling Degree不是由个别专家随意决定，论文进一步进行Kendall’s W和CV分析。

五名专家对45组耦合关系进行了评价。

Kendall’s W结果为：

• S-Coupling：0.988
• O-Coupling：0.998
• D-Coupling：0.995
• Overall Coupling：0.996

均满足p < 0.001。

Coefficient of Variation的平均值只有0.013，最大值为0.248，没有超过0.3。

作者还让某一个专家的评分在基准值基础上变化约±40%，由于Delphi最终采用median，最终耦合评价结果基本不发生变化。

这说明在本案例数据中，最终Coupling Degree对单个专家极端评分具有较强鲁棒性。

Coupled RPN results

加入耦合以后，最明显的变化有两个。

第一，FMEA能够识别出独立分析中不存在的组合故障模式。案例中最终增加了36个新的耦合故障模式。

第二，部分组合的风险排序显著提高。

传统FMEA中最高RPN为700，而Coupled RPN最高达到：

4962.38

排名第一的是：

HFM4@SFM3

Transistor Q1 open circuit @ Driving output stays in state 1

C-RPN：

4962.38

排名第二：

HFM10@SFM3

Contactor JK1 fails to break when it should @ Driving output stays in state 1

C-RPN：

4559.56

排名第三：

HFM14@SFM3

Sensor Y1 loss of function @ Driving output stays in state 1

C-RPN：

3751.21

这些结果说明，独立FMEA中一个硬件故障的风险不能完全代表它在实际嵌入式控制闭环中的危险程度。软件同时出现特定异常以后，系统后果可能发生明显放大。

Normalization of C-RPN

传统RPN范围通常是：

1 ～ 1000

而本文C-RPN理论上可以达到10000，案例最大值达到4962.38。

为了让新的结果还能与传统FMEA风险接受阈值对接，作者使用min-max normalization重新映射到1～1000：

RPN_norm = 1 + (RPN_C - min)/(max - min) × 999

因此，最高C-RPN 4962.38被归一化为1000。

这种处理保留当前分析样本中的相对排序和距离，同时让工程人员仍可以在熟悉的FMEA数值尺度内阅读结果。

Ranking consistency

作者进一步计算传统Hardware RPN排名与耦合风险排名之间的Spearman Rank Correlation。

对于每个Hardware Failure Mode，取它和所有Software Failure Modes组合后的最大C-RPN作为代表风险。

最终得到：

ρ = 0.73

论文认为这说明HSFC-FMEA仍然保留传统FMEA基本风险识别逻辑，同时通过耦合项补充了新的交互风险。

换句话说，新方法并没有完全推翻原有FMEA排序，而是在其上对软硬件交互敏感的项目进行重新加权。

Environmental influence

本文还专门分析高温高湿环境对HSFC的作用。

根据Arrhenius和Hallberg-Peck模型，作者比较35 °C与60 °C、85% humidity条件下的硬件可靠性。

计算得到Characteristic Life Ratio约为：

0.099

一年，即8760 h累计失效概率从：

0.2%

上升到：

6.5%

环境恶化首先增加Hardware Occurrence，再进一步提高相关软硬件组合的Occurrence Coupling和C-RPN。

例如Q1短路、Sensor Y1失效等故障在高温高湿环境下的RPN明显增加。

这部分体现了作者希望把HSFC-FMEA从静态专家评分继续推进到“环境—硬件可靠性—耦合风险”动态关联。

Comparison with other FMEA methods

论文将HSFC-FMEA与Traditional FMEA、Fuzzy FMEA和Bayesian方法进行了比较。

Traditional FMEA最简单，但把hardware和software独立分析。

Fuzzy FMEA主要改善专家评分中的模糊性和不确定性，但仍没有专门建模跨域Hardware-Software Coupling。

Bayesian Network能够更严格地表示概率依赖，但需要比较充分的概率数据和条件分布。作者认为，本案例数据主要来自少量专家给出的离散等级评分，如果直接建立复杂概率模型需要引入更多先验假设。

因此，本文选择Hadamard Product这种代数融合方式，希望保持传统FMEA直观的乘法逻辑，同时避免在样本有限的情况下建立过度复杂的概率模型。

在独立Hardware Failure Mode排序上，HSFC-FMEA与Traditional/Fuzzy FMEA总体趋势相近；真正新增的能力在于为每一个hardware-software组合单独给出Coupling Risk。

Design improvement

耦合矩阵分析最终发现原控制电路存在明显的高Severity Coupling风险。

设计团队据此增加：

• timer module；
• 新的normally closed contactor switch JK2。

改进的核心是降低单一驱动逻辑与原有contactor失效组合后产生危险输出的可能性。

重新执行FMEA后，无论是否考虑coupling，整体RPN均明显下降。

特别是在Coupled RPN分布中，原设计中大量落在500～5000范围内的高风险组合，在重新设计后明显向较低区间移动。

论文用这个结果形成完整闭环：

HSFC identification → high-risk coupling → redesign → HSFC-FMEA again → risk reduction

因此，HSFC-FMEA不只用于生成一个新的风险分数，也被用作设计改进的定位工具。

Conclusion

本文在传统Hardware FMEA和Software FMEA之间增加Hardware-Software Failure Coupling分析层，提出HSFC-FMEA。

方法首先保留独立FMEA得到的S/O/D，再通过系统功能和接口关系建立软硬件故障组合矩阵；使用Delphi Method评价各故障对在Severity、Occurrence和Detection维度上的Coupling Degree；使用幂指数缩放、outer product和Hadamard Product得到Coupled S/O/D以及最终C-RPN。

为避免组合数量过大，作者使用Sparse Matrix Compression去除不存在耦合关系的故障对。智能气体加注控制装置案例中，170个子组件产生510个故障模式，原始矩阵达到480×30；耦合分析最终识别出36个传统独立FMEA没有直接表达的组合风险模式。

案例结果还表明，Coupling对Severity的影响最明显；最高C-RPN由Transistor Q1 open circuit与软件输出持续保持1状态共同形成，达到4962.38，远高于传统独立分析中的最高RPN 700。加入timer和JK2后，高风险耦合项整体下降，说明分析结果能够反馈到设计优化。

本文的后续方向包括扩展到机电、传感与控制等多领域耦合故障，在数据规模足够时引入Copula等概率依赖模型，并进一步完善环境、时间、自适应分析以及工具化和标准化能力。

论文评价

• 推测的软件工具链： 论文没有明确给出具体实现语言或FMEA软件。方法核心由Hardware/Software FMEA表、Coupling Matrix、CSR/CSC Sparse Matrix Compression、Hadamard Product、Delphi统计、Kendall’s W、CV、Spearman相关和多组RPN计算组成，因此使用MATLAB或Python都可以直接实现，Excel也可以承担小规模FMEA表和矩阵录入工作；论文图中大量矩阵计算、拟合曲线和箱线图更像由MATLAB/Python完成，但正文没有足够信息确认具体工具。论文作者贡献中明确标注了Software与Data curation，说明至少存在配套计算实现，但没有公开源码或程序结构。
• 收录原因： 文章针对一个传统FMEA中确实存在但经常被简化的问题：软硬件故障往往不是独立发生影响。与大量只改进RPN排序算法的FMEA论文不同，这篇工作先改变了“风险分析对象”，把单个hardware/software failure扩展为hardware failure × software failure的组合故障，再分别评价这种交互对S/O/D的影响。Sparse Matrix、Delphi一致性检验、环境影响分析、方法对比和实际设计修改使方法形成了比较完整的工程闭环，因此与RESS关注的复杂系统故障依赖、风险分析和可靠性设计具有较高契合度。
• 值得借鉴： 最值得借鉴的是“传统FMEA先完成，再单独增加Coupling Layer”的组织方式，这种方法不会破坏已有Hardware FMEA和Software FMEA流程，特别适合由不同专业团队分别维护基础故障数据；使用矩阵交叉软件和硬件故障模式，可以系统检查潜在组合风险；X_S/X_O/X_D三个矩阵把耦合作用拆到Severity、Occurrence和Detection三个维度，比单一相关系数更符合FMEA工程语言；先通过功能关系构造大矩阵，再用Sparse Matrix压缩零耦合项，也是一种比较实用的大系统分析策略；最后以“分析—改设计—重新分析”验证方法，而不是只展示风险排序，这种实验结构也很值得FMEA方法论文借鉴。
• 可能不足： 方法的关键输入Coupling Degree仍然主要依赖专家判断，Delphi、Kendall’s W和CV能够证明专家意见一致，但“一致”并不等于耦合强度本身已经被客观物理证据验证。矩阵方法表达的是不同故障模式之间的风险放大程度，并没有显式描述故障如何沿系统行为、控制逻辑或物理接口动态传播，因此它更接近Coupled Risk Ranking，而不是动态故障传播模型。p=1/2、q=1/3的幂指数来自参与乘积的同类因素数量，具有明确数学缩放目的，但仍需要更多案例证明这种缩放能够稳定对应工程风险。C-RPN再通过当前样本的min-max映射回1～1000，也意味着归一化值依赖当前分析集合，跨产品直接比较时需要谨慎。环境与时间模型在方法层面已经提出，但案例中主要还是高温高湿条件下的参数重算，并未形成完整的时序仿真。最后，案例只重点展示15个hardware和3个software failure modes，尚不足以证明在真正超大规模软件密集系统中的人工耦合识别成本和长期维护效率。