嵌入式控制系统设计/故障模式和预防
故障模式是指系统故障的方式，或观察故障的方式。因此，它与故障原因不同，而是描述故障发生的方式。故障模式有三种类型：概念性、技术性和组织性。本文仅讨论技术性故障模式，重点关注嵌入式控制系统。本章对于嵌入式系统设计人员非常重要，因为此类系统通常在没有人工监督的情况下工作，并且在人工纠正故障的执行成本很高的地点工作。因此，设计人员应格外注意系统中可能出现的问题（即识别其故障模式）并对每种故障的风险进行评估（即分析每种故障模式的后果）。很明显，避免故障比修复故障要好得多，并且从这方面来说，简单的设计比复杂的系统更容易；但是，制作简单的设计仍然是一种工程艺术形式，尚未成为一种结构化的工程学科。还要记住，许多故障不会被测试检测到。
嵌入式系统中的技术故障模式可以分为两大类：硬件故障模式和软件故障模式；然而，最难预防的故障是那些由硬件和软件之间微妙交互引起的故障。
以下是软件故障模式的一些示例
- 缓冲区溢出：计算机内存小于程序员预期的内存，因此在嵌入式系统运行期间，系统中的某个程序正在访问计算机内存的错误部分。
- 悬空指针：此错误在非安全编程语言中很常见，在这种语言中，程序员负责始终确保每个指针指向正确的内存位置。
- 资源泄漏[1]，其中编程错误导致计算机对某些硬件资源失去控制；内存泄漏是最简单的资源泄漏形式。
- 竞态条件，其中系统不同组件的特定相对时间事件导致意外行为。此类竞态条件通常难以仅通过测试检测到。
- 语义设计，例如：视觉软件环境中两个子系统之间箭头的含义应该与硬件对其的解释相同。
以下是硬件故障模式的一些示例
- 电气故障：短路、电压/电流过高
- 机械故障：阀门卡住
- 温度影响：组件变形
- 材料故障：腐蚀
再次强调，这些示例仅是后果，而不是原因！
以下是软件故障原因的一些示例
以下是硬件故障原因的一些示例
- 恶劣环境：任何阻止系统正常运行的因素。
- 传感器校准不良
- 选择错误的尺寸
- 制造/装配工艺缺陷
一些故障不是由硬件或软件引起的，而是由系统级引起的。
系统故障原因的一个示例
- 运行故障：人工操作员也会犯错误。三哩岛事故是运行故障的典型例子。
由于嵌入式系统功能和能力不断增强，很难预防甚至检测故障模式。确保可靠性的一种方法是使用概率可靠性建模等技术进行大量测试。这些技术的问题之一是它们仅在开发的后期阶段使用。最好在开发的早期阶段就将质量和可靠性设计进去。
为了在设计过程中检测故障，重要的是在设计之初对系统（尤其是软件）进行不同的测试。但测试通常很昂贵，而且也应该提供正确的信息：测试结果的可用性取决于测试的质量。因此，找到合适的测试并不总是容易的。
软件领域中的动态分析是通过在处理器上执行程序来测试和评估软件。在硬件上进行动态分析的一个例子可能是振动和应力分析。
如今，工程师已经为软件开发了静态分析，它是一种无需测试的方法：无需开发特定测试，并且可以在无需执行程序的情况下检查软件缺陷。
有很多方法可以降低故障发生的可能性。但有些故障需要比其他故障更紧急地处理。首先应该看一下系统发生故障的频率，这被称为系统的故障率。希望系统不会发生故障，但如果故障非常罕见，通常没有必要采取措施。
故障模式的另一个方面是其严重程度。短路的电器可能危及生命，而自动售货机中阀门卡住的危害性则较小。
尽管工程师可以尽一切努力设计一个不会发生故障的系统，但故障总是会发生的。例如：如今一部普通的手机包含多达 200 万行软件代码。很可能在这其中的一行代码中引入了故障。系统变得越来越复杂。例如：预计同一款手机在 10 年内将包含多达 1000 万行代码。因此，设计应该更加健壮。[2] 当系统检测到出现问题时，它可以发出信号并进入安全模式，直到用户采取适当的措施。以自动售货机中阀门卡住为例：机器可以点亮所有 LED 以发出信号，表明存在问题，并停止提供苏打水，直到维修完毕。
当单独的系统必须协同工作时，也会发生故障，例如：RoboCup中的不同机器人。另一个此类复杂系统的例子是麻省理工学院詹姆斯·麦克莱尔金教授的机器人，它们必须共同演奏《星球大战》主题曲，但每个机器人只能演奏一些音符。因此，它们必须合作才能正确演奏完整的主题曲。[3]
设计嵌入式控制系统的成本往往随着可靠性的提高而呈指数级增长：消除系统中 X% 的故障并不一定会使可靠性提高 X%（一项研究表明，在IBM中，消除 60% 的错误仅增加了 3% 的可靠性）。在某些情况下，因此可能更具成本效益的是不研究更可靠的系统，而是支付故障成本。但是，必须记住，这种策略会导致公司因销售不可信的系统而声誉受损。在不同的设计标准之间始终存在权衡，具体取决于系统。当然，关键系统应始终设计得尽可能可靠。
所有这些都强调了在设计过程中消除故障的重要性。幸运的是，工程师已经开发出了一些系统地执行此操作的过程。以下所有过程都可以在所谓的安全工程中使用。故障研究是设计嵌入式控制系统的重要方面，因为它可以节省时间、金钱，甚至生命，并且有助于系统未来的修改。
由于测试不完全，存在许多实时灾难的例子。
安全系数用于确保设计能够正常工作，并防止其发生故障。但是，较大的安全系数并不总是会产生可靠的系统。通常，它们会导致过度设计的系统，这些系统更昂贵，并且制造/组装时间更长。
为了减少（或更好地防止）系统故障的可能性，工程师们开发了一种名为“故障模式及影响分析”（FMEA）的技术。这是用于识别系统中潜在或实际故障模式并选择适当的纠正措施的工具。FMEA 提供了一种分析方法来确定哪个风险最令人担忧，因此需要采取措施来防止问题在出现之前出现。这些规范的制定将确保系统满足定义的要求。
还可以识别需要特殊控制以防止或检测故障模式的关键或重要的设计/工艺特性。一个关键步骤是预测产品可能出现的问题。虽然无法预测所有故障模式，但开发团队应尽可能全面地制定潜在故障模式的广泛清单。FMEA 从设计开始，并在整个设计过程中维护和调整。这样就可以设计出无故障的系统。这样，FMEA 就包含了用于将来系统改进的重要信息。
进行FMEA的过程很简单。它分三个主要步骤完成，需要采取相应的行动。但在开始使用FMEA之前，重要的是要做好一些预备工作，以确保将健壮性和历史记录纳入分析。重要的是要考虑故意和非故意使用！非故意使用是一种恶劣环境。
- 步骤1：确定严重程度
根据用户感知的功能要求及其影响，确定所有故障模式。每个影响都被赋予一个严重程度(SEV)，从1（无危险）到10（重要）。如果影响的严重程度为9或10，则需要采取措施来更改设计，如果可能，消除故障模式，或保护用户免受影响。
- 步骤2：确定概率
在这一步中，有必要查看故障的原因以及故障发生的次数。故障模式被赋予一个概率(OCCUR)，同样从1到10。如果发生率很高（对于非安全故障模式，发生率>4，当步骤1中的严重程度为9或10时，发生率>1），则需要确定行动。
提示：概率也可以在故障表中实施后使用，以让操作员初步猜测频繁发生的故障的来源。
- 步骤3：确定检测率
当确定适当的行动时，有必要测试其效率。还需要进行设计验证。需要选择适当的检验方法。前两步中的每个组合都将获得一个检测率(DETEC)。这个数字代表了计划测试和检验消除缺陷或检测故障模式的能力。
在这三个基本步骤之后，将计算风险优先级数（RPN）。
RPN 在选择针对故障模式的行动中并不起重要作用。它们更像是评估这些行动的阈值。
RPN 最高的故障模式应优先考虑纠正措施。
分配完这些值后，会记录建议的行动、目标、责任人和实施日期。一旦行动在设计/工艺中实施，就应该检查新的 RPN，以确认改进情况。只要设计或工艺发生变化，FMEA 就应该更新。
一些合乎逻辑但重要的想法浮出水面
- 尝试消除故障模式（一些故障比其他故障更容易预防）
- 最小化故障的严重程度
- 减少故障模式的发生率
- 改进检测率(!)
与 FMEA 一样，预测性故障确定(AFD) 的目标是识别和防止潜在故障。 [4] 然而，AFD 的方法正好与 FMEA 相反。AFD 不是寻找故障模式的原因，而是要求开发人员将关注的故障视为预期结果，并寻找方法确保这种故障始终可靠地发生。这样，AFD 就是 FMEA 的补充方法。使用 FMEA，可以找到风险优先级数最高的故障，然后使用 AFD 方法重新设计。
AFD 比 FMEA 更适合于复杂故障分析。FMEA 依赖于基于应用程序或他人个人经验识别故障及其原因。但是，这种方法的问题是“否认现象”。如果试图考虑正常运行的系统可能出现的问题，就会倾向于抵制思考可能发生的令人不快的情况，除非它们确实之前已经经历过。有时人们甚至会否认问题，因为他们不会承认在设计中犯了错误。通过颠倒问题，AFD 克服了这种“否认现象”，并为故障分析打开了创造性的见解。
- 步骤 1：制定或反转问题
工程师不应该思考故障的可能原因，而是应该思考如何在相同的环境条件下使故障发生，这些环境条件导致了故障的发生。首先需要识别这些条件。之后，应该考虑导致故障的场景，并尝试将其定位。
- 步骤 2：寻找解决方案或方法来产生故障
现在，思维过程转变为寻找产生所检查故障的机制或方法。功能分析可能有助于识别故障场景中涉及的一系列功能或行动。
- 步骤 3：验证是否有资源可以导致故障
有七类潜在资源：物质、场效应、可用空间、时间、物体结构、系统功能以及有关系统的其他数据。对于导致故障的每个潜在解决方案，有必要检查是否有足够的资源来支持该解决方案。
故障树分析 (FTA) 是一种第三种故障分析形式，它使用布尔逻辑 来组合一系列低级事件，分析系统的非期望状态。FTA 在设计过程中实施后进行，即在测试级别进行，但如果所有这些故障树都被收集并维护良好，那么如果仍然发生故障，它们也将在操作级别提供有用的帮助。这种分析方法主要用于安全工程领域。
FTA 分析包含五个步骤
- 步骤 1：定义要研究的非期望事件
定义不希望发生的事件可能非常困难，尽管有些事件很容易观察到。拥有广泛系统设计知识的工程师或具有工程背景的系统分析师是帮助定义和编号不希望发生的事件的最佳人选。然后，将不希望发生的事件用于创建故障树分析（FTA），*一个 FTA 一个事件*。
- 步骤 2：了解系统
选择不希望发生的事件后，会对所有可能影响该事件的概率原因进行研究和分析。通常不可能获得导致该事件的概率的准确数字，因为这样做可能非常昂贵且耗时。
系统设计人员对系统了如指掌，这些知识对于避免遗漏任何影响不希望发生的事件的原因至关重要。对于所选事件，所有原因将被编号并按发生的顺序排序。
- 步骤 3：构建故障树
选择不希望发生的事件并分析系统，以便了解所有造成的影响以及可能的概率，现在可以构建故障树。故障树基于 AND 和 OR 门，它们定义了故障树的主要特征。
- 步骤 4：评估故障树
分析树以发现任何可能的改进，换句话说，研究风险管理，并寻找系统改进的方法。简而言之，在这个步骤中，我们将识别所有直接或间接影响系统的所有潜在危害。
- 步骤 5：控制已识别的危害
此步骤非常具体，并且在不同的系统之间存在很大差异，但主要点始终是，在识别了危害之后，将采取一切可能的方法来降低发生的概率。
由于组装 FTA 可能是一项昂贵且繁琐的体验，因此最佳方法是考虑子系统，然后将它们集成在一起。