弥合安全分析与故障仿真之间差距的方法

在汽车领域，失效可能导致严重的人身伤害，为此《ISO 26262 标准》为安全评估提供了最先进的指导方针。该标准规定了一套全面的流程，涵盖从危害分析、风险评估流程到故障注入和仿真技术等各个环节。

本文提出了一种基于模型的方法，旨在弥合安全分析与故障仿真之间的差距。一方面，通过将分析流程形式化；另一方面，建立从模型驱动的数据到故障注入和仿真场景的映射，我们为安全相关系统打造了一种高效的探索方法。这一方法不仅能提升安全评估结果的质量和一致性，还能将繁琐的手动任务减少多达 60%，从而显著加快安全评估周期。

如今，集成电路被广泛应用于各类安全关键系统，这些系统的运行可能会对人类生命造成影响。因此，安全评估成为设计和制造周期中的关键环节。通过安全评估，可将系统安全受到严重影响的错误行为风险降至最低。为此，设计人员需遵循特定领域标准中规定的安全评估指南（例如，基于《IEC 61508 标准》制定的《道路车辆功能安全 ISO 26262 标准》）。

要使电气 / 电子（E/E）系统符合《ISO 26262 标准》并认证为功能安全系统，需执行一套详尽的流程：首先预测潜在风险，随后确定这些风险的成因与影响；为减轻失效影响，需采取适当的应对措施；之后计算评估指标，以证明系统的安全水平。

这种概率性安全分析流程依赖于手动数据收集与检查、专家判断以及基于电子表格的计算，并通过多种方法执行，如故障树分析（FTA）、失效模式、影响及诊断分析（FMEDA）以及相关性失效分析（DFA）。当目标安全等级要求极高时，该标准还规定需额外应用故障注入技术。具体而言，就是在可执行的系统模型中刻意植入故障，随后监测模型的响应。在合适的仿真平台上运行经过修改的系统模型，能够了解失效影响、发现导致系统严重故障的故障场景，并验证已集成的安全 / 诊断机制是否合格。因此，我们将故障注入视为一种定量安全评估流程，因为它能为失效率和覆盖度指标提供实测值。

图1.安全评估的不同视角

图 1 展示了两种安全评估视角的概况。对于每种视角，我们都会区分可复用的通用基础内容和与应用相关的用例。一方面，行业中通常会使用失效目录进行概率性分析。失效目录是一个数据库，包含已知的失效模式、已确认的失效率，以及从相关可靠性手册或以往项目中收集的类似信息。失效目录的具体体现形式包括完整构建的故障树和填写完毕的 FMEDA 电子表格。另一方面，定量评估依赖于系统建模与仿真指南，这些指南通过故障建模和失效影响仿真的形式化方法得到扩展，并通过在合适的仿真平台上对可执行模型开展故障注入测试来应用。

本文在第二节探讨安全分析与故障注入之间的关联：首先介绍最相关的安全分析方法（第二节 A 部分）和故障注入技术（第二节 B 部分），然后在第二节 C 部分阐述两种场景之间的差异及潜在关联。之后，在第三节详细说明连接分析与仿真的模型驱动解决方案：先对该方法进行总体介绍（第三节 A 部分），再解释基于元模型的安全分析方法形式化过程（第三节 B 部分），以及这些方法与故障注入的映射关系（第三节 C 部分）。

A. 安全分析方法

根据《ISO 26262 标准》，安全分析需在安全评估周期的不同阶段开展，主要用于：（1）验证安全目标与安全概念；（2）验证安全要求；（3）识别可能导致安全目标失效的条件与事件（如故障、失效等）；（4）确定适当的应对措施。

该标准提及了多种安全分析方法，并根据这些方法从原因到结果的分析方向（演绎法与归纳法）以及详细程度（定性与定量）对其进行区分。

1.故障树分析（FTA）

故障树分析是一种成熟的演绎式（自上而下）安全分析方法。它以导致系统失效的不良事件为分析对象，进而探究所有可能的成因。故障树是一种无环图形表示，使用逻辑连接器和逻辑门，展示事件的不同层级。构建故障树需采用系统的反向追溯流程：从顶事件开始，最终追溯到基本（或称初始）事件。

故障树分析的核心在于组合分析，这使其难以用于包含时序和序列关系的复杂系统描述。不过，通过时间故障树（TFT）和动态故障树（DFT）等方法的扩展，这一局限性得到了改善。时间故障树方法可捕捉故障与事件之间的时序依赖关系；动态故障树方法则在故障树语法中新增了逻辑门（如功能依赖门、优先级与门），以对容错系统的动态行为（如序列相关故障）进行建模。

故障树分析方法可通过以下三个核心要点概括：

· 整体结构：分析采用自上而下的方式，从需识别所有潜在成因的系统失效事件开始。分析信息以树状结构组织，包含多个事件，事件之间通过逻辑组合相互连接（见图 2 示例）。每棵故障树必定且仅有一个顶事件。为实现模块化并对系统不同部分分别分析，故障树还可选择性地分解为多个子树。

· 事件类型：事件分为顶事件、基本事件（树的叶节点）和中间事件三类。其中，基本事件可分为：无需进一步展开的基础事件、因信息不足等原因未进一步展开的未展开事件、适用于逻辑门的特定条件或限制的条件事件，以及外部事件。

故障逻辑：故障树的构建基于从顶事件到基本事件的反向追溯过程。非基本事件可能由单个事件触发，也可能由多个事件组合触发。除了 “与”“或”“异或” 等传统逻辑门外，还会用到故障树特有的逻辑门，如 “表决或” 门（VotingOR）。

图2.故障树示例

2.失效模式与影响分析（FMEA）

失效模式与影响分析是一种归纳式（自下而上）的方法，主要流程包括：（1）识别潜在失效模式；（2）评估失效模式对系统行为的影响；（3）提出减轻失效影响的适当应对措施。

从本质上讲，失效模式与影响分析是一种定性技术，但通过以下两方面可引入定量分析维度：一是关键性评估（即失效模式、影响及关键性分析 FMECA）；二是诊断覆盖度分析（即失效模式、影响及诊断分析 FMEDA）。通过分析严重失效影响的发生概率，并利用覆盖因子和失效率描述风险检测情况，可确定设计行动的优先级，同时完善失效缓解机制。

FMEDA 通常以表格形式记录，如表 1 所示的 FMEDA 电子表格简化摘录。对于每个与安全相关的系统部件，会根据《ISO 标准》分配一个元件类型，并确定其失效率。该部件的多项功能可能会受到不同失效模式的影响，这些失效模式需通过以下属性来描述：故障分布（主要指各失效模式在部件总失效率中所占的百分比）、故障类型（硬错误与软错误）以及失效影响。失效影响会根据严重程度进行分类，最后记录减轻失效影响的适当安全措施及其诊断覆盖度数值。

表1.FMEDA表的简单示例

3.相关性失效分析（DFA）

相关性失效分析主要针对两类故障：同时发生的故障和相继发生的故障。这类故障的发生概率不能简单地表示为各自发生概率的乘积。相关性故障可分为共因故障和级联失效：共因故障由单一特定事件或根本原因引发；级联失效则是指某一设备元件失效后，通过架构中的耦合机制导致至少一个其他元件失效的故障。相关性失效分析同样以表格形式记录，如表 2 所示的示例。

表 2. DFA 表格简单示例

B. 故障注入技术

过去几十年间，故障注入技术一直被用于评估被测系统的可靠性。该技术通过在系统中刻意植入故障，随后监测系统对故障的响应行为来实现评估目的。故障注入的主要目的包括：观察系统在故障环境下的反应，以及验证故障检测和 / 或纠正机制的有效性。

为此，需确定合适的注入点、观察 / 诊断点和工作负载。通过 “操作剖面”（即对系统使用方式的定量描述）可排除非活跃的故障位置。此外，通常还会采用故障压缩技术来减少需注入的故障数量。

设计领域常用的故障注入技术多样，部分针对物理原型，部分针对虚拟模型，主要可分为以下几类：

1.基于硬件的故障注入

这类故障注入在物理层面实施，以影响系统实际硬件。具体方式包括：改变环境参数（如重离子辐射、电磁干扰等）、修改电路引脚值，或干扰电源供应（如通过电压骤降操控电源轨）。

2.基于软件的故障注入

此类技术用于复现硬件中发生的故障和错误，通过在应用程序或操作系统中植入故障来实现，主要关注实现细节、程序状态和通信过程。根据应用阶段的不同，可分为编译时注入和运行时注入。

3.基于仿真的故障注入

该技术在评估早期阶段实施，通过在寄存器传输级（RTL）和门级（GL）模型中植入故障来开展。具体实施方式有两种：一是通过添加 “破坏器”（saboteurs）或应用 “变异体”（mutants）修改代码；二是利用仿真器内置命令扩展仿真工具，以支持故障植入和响应监测。

C. 差异与潜在关联

安全分析（第二节 A 部分）与故障注入（第二节 B 部分）之间存在差距，这主要源于两者在需求、工作方式和目的上的差异：

安全分析：旨在在较高抽象层级和设计早期阶段提供安全证据。通过以下方式获取安全证据：（1）检查系统概念描述；（2）收集与应用相关的数据；（3）评估安全要求的满足情况；（4）进行统计计算。安全分析数据以表格、树状图等多种形式组织。在工业场景中，面对大型系统时，手动创建和维护数据的工作繁琐且容易出错。在许多情况下，安全分析人员需处理包含数千行数据的 FMEDA 电子表格和包含数百个项目的故障树。

故障注入：旨在通过以下方式验证具体系统实现是否符合安全要求：（1）在正常设计模型中添加故障条件下的预期行为描述；（2）通过仿真和监测观察故障带来的影响。然而，故障注入存在诸多局限性：故障注入所需的完全确定性、详细的系统模型通常要到设计后期才能获取，而此时重新设计的成本极高；此外，系统正常行为可能出现的偏差数量庞大，要进行全面的故障注入测试几乎不现实。

显然，要应对当今复杂系统的安全评估挑战，需合理结合安全分析与故障注入这两种方法，充分利用各自优势，同时最大限度地降低其局限性。因此，安全分析（如 FMECA/FMEDA、FTA、DFA 等）与故障仿真之间的关联成为重要的研究课题。

在本研究中，我们通过考虑两种流程的结构相似性来解决这一挑战性问题。事实上，无论抽象层级和评估方法如何，安全评估始终会涉及三类基本要素：

1.目标（Targets）：为确保系统可靠运行（本文中特指安全运行）而需保护的系统元件或功能。

2.威胁（Threats）：可能对目标造成危害的故障、偏差、失效及其他事件。

3.应对措施（Countermeasures）：用于保护目标、减轻威胁的各类机制和措施。

基于这一认知，通过将安全分析成果形式化，使其与模型驱动技术兼容，我们建立了分析与仿真领域之间的关联。由此，实现了系统安全评估周期中的自动化数据交换，减少了整体工作量，并提升了评估结果的质量。

本研究提出了传统安全分析流程的基于模型替代方案，并将其与定量评估相结合（见图 1）。应用模型驱动开发技术（尤其是元建模和代码生成技术），可实现安全分析方法的形式化，系统地提取相关分析数据，并通过减少手动任务提高效率和质量。

A. 方法概述

图 3 一方面展示了传统的安全评估流程，另一方面呈现了本文提出的用于连接安全分析与故障仿真的模型驱动流程。

图3.方法概述：基于模型的安全分析以及与故障注入和模拟的链接

在传统流程中，安全评估由不同团队分别执行：一个团队负责安全分析，另一个团队负责故障注入和仿真。安全分析的常规输入包括设计规范、区域信息、安全要求、失效目录以及包含不同元件类型基准失效率的可靠性数据。安全工程师以这些信息为基础开展分析，并将分析结果记录在 FMEDA Excel 电子表格等文档中。这一过程需要繁琐的手动输入，既耗费成本又耗时，分析人员需识别分析成果并将其填入电子表格。

另一方面，当涉及《ISO 26262 标准》中要求最严格的 ASIL C 级和 D 级安全完整性等级时，需开展故障注入工作。负责故障注入的团队会通过蒙特卡洛测试等方式，在系统正常模型中植入故障。在某些情况下，会利用 FMEDA 的分析结果确定注入点。运行相应的仿真后，可测量诊断覆盖度数值，并将仿真结果与分析结果进行比较。然而，要实现两者的关联，需对分析数据进行极为复杂的手动检查。在实际场景中，FMEDA 电子表格往往包含数千行数据，从中筛选数据以确定故障注入点的工作繁琐且易出错。

为此，我们开发了一种替代流程，旨在为两种安全评估场景建立系统化、自动化的映射关系。该流程的常规输入基本保持不变，但失效目录的内容由形式化的失效模式数据库和可靠性数据共同涵盖。借助这一数据库，可更系统地获取分析所需的相关信息。

该解决方案的核心在于，用基于相应元模型实例构建的数据模型，替代传统安全分析和文档记录所使用的格式。这些元模型涵盖了 FMEDA 电子表格、故障树和 DFA 表格的结构，从而以形式化的方式描述分析成果、成果各自的属性以及它们之间的关系。

随后，通过一组解析器和读取器实现自动化数据提取，替代手动数据输入，构建在语法和语义上符合元模型要求的数据模型。这些数据模型构成了与仿真场景之间的关联纽带。实际上，通过模型到模型的映射，可将安全分析数据模型中的特定元素与待仿真的系统正常模型中的相应元素相关联。映射的结果将用于生成故障库的基础内容，该故障库列出了需植入系统模型的具体故障，包括待注入的故障类型或类别，以及系统模型中的相关注入点。

在故障仿真平台中对故障库进行相应处理，可自动触发故障注入测试。最后，将仿真运行获得的结果与分析结果进行比较，验证分析方法所依据的专家判断的一致性和准确性。例如，可将仿真过程中测得的诊断覆盖度数值反向标注到 FMEDA 数据模型中。若未达到安全评估指标的目标值，则需对相关内容进行优化完善。

B. 通过元建模实现形式化安全分析

模型驱动开发（MDD）是系统工程领域的一种成熟方法。通过应用模型提高应用程序的开发抽象层级，可降低复杂性并提高效率。元建模是更高层次的抽象手段，它能突出模型属性、明确模型元素之间的关系，并以形式化方式确定模型必须满足的约束条件。元建模所具备的形式化特性，是我们在安全评估研究中应用该技术的主要原因。

我们分别为 FTA、FMEDA和 DFA构建了元模型。在本节后续内容中，我们将重点介绍图 5 所示的 FMEDA 元模型。

图4.失效模式数据库的简化元模型

图5.简化的FMEDA元模型

构建 FMEDA 元模型时，主要参考了两方面依据：一是第二节 A 部分中提及的 FMEDA 分析步骤；二是安全分析人员记录 FMEDA 结果所使用的电子表格结构（FMEDA 表格示例已简化并浓缩于表 1 中）。

在 FMEDA 元模型（见图 5）中，根类记录了团队成员及其职责分配情况。待分析的结构部件（无论是系统、组件还是子组件），需根据《ISO 26262 标准》规定的类型、自身的失效率以及所实现的功能进行描述。此外，元模型还涵盖了影响这些功能的失效模式及其相关属性、失效影响及其严重程度，以及用于减轻一种或多种失效模式影响的安全措施及其诊断覆盖度。

基于 FMEDA 元模型，我们构建了一个框架，该框架包含应用程序编程接口（API）和一组工具，其中工具包括数据读取器、解析器、写入器以及其他用于构建、可视化和修改数据模型的插件。该框架的一个关键组件是用于从相应数据库导入相关失效模式的插件。

该数据库包含的信息来源包括：内部失效目录、以往项目的现场反馈数据，以及《ISO 26262 标准》第 5 部分附录 D 中规定的故障模型清单。此外，数据库还包含公认的可靠性手册或行业标准（如西门子标准 SN 29500）中规定的各类元件的典型基准失效率数值。

失效模式数据库的结构同样通过元模型（见图 4）进行描述，基于该元模型可生成用于管理数据库的 SQL API。数据库中包含多个目录，分别对应不同的潜在数据源。每个目录中涵盖多个领域（例如，《ISO 26262 标准》中的处理单元领域和通信领域）。每个领域都关联一组组件（更准确地说是组件类型）。每个组件都对应一组失效模式，这些失效模式可通过分布情况及其背后的原理等信息来描述。组件的失效率取决于技术和运行参数，数据库通过所谓的 “配置” 来涵盖这些影响因素。

C. 从安全分析到故障仿真的模型驱动数据映射

通过 FMEDA、FTA 和 DFA 元模型（见第三节 B 部分）支持基于模型的安全分析，是实现从安全分析向故障注入过渡的第一步。实际上，用构建的数据模型替代大量表格数据，不仅简化了探索、维护和复用工作，还构成了过渡过程第二步（即映射到故障注入流程）的起点。

安全数据模型（可使用 Python 或 C++ 等通用面向对象编程语言处理的关联对象集合）与可执行系统模型（通常采用 SystemC、SystemVerilog、VHDL 等语言开发）的元素之间存在关联，通过识别这些关联，可建立两种场景之间的连接。在此过程中，我们应用模型驱动技术和系统化匹配算法来识别相关映射点，大幅减少了工作量。

映射流程的第一步是获取用于故障注入和仿真的系统正常模型。根据从设计初期到最终实现的不同开发阶段，该正常模型的架构复杂程度可能有所不同；同时，它也可在不同抽象层级（如事务级建模 TLM、寄存器传输级 RTL、门级 GL）进行描述。此外，我们还会考虑多种建模语言。在本研究的用例中，我们主要采用 SystemC 开发的虚拟原型，已有大量文献证明 SystemC 适用于故障注入、错误仿真和安全评估。

为在模型驱动安全评估环境中构建获取系统模型的通用机制，我们构建了一个抽象元模型，用于描述基本系统结构，且不依赖于抽象层级和建模语言。事实上，无论语法和语义存在何种差异，系统模型架构都可简单表示为一组相互连接、构成结构层次的元素。基于这一认知，我们构建了图 6 所示的元模型。

图 6.简化的系统架构元模型

表 3.安全分析成果与故障注入和仿真相关系统元素之间的映射

获取系统正常模型后，需将其元素作为各类安全分析成果（如与安全相关的系统部件、失效模式与影响、安全措施）的映射目标。根据表 3 中列出的对应关系，通过适当的引用，可在 FMEDA/FTA/DFA 数据模型与系统模型对象（即图 6 中元模型类的实例）之间建立关联。

映射通过所谓的 “匹配算法” 实现，该算法用于识别可能分配给特定分析成果的潜在候选对象（即系统模型元素）。匹配算法既可以基于两种场景中数据模型对象的唯一标识（ID），也可以基于对象名称。

映射完成后，需进行配置：除已确定的注入点、观察点和诊断点外，还需定义注入所需的额外细节（如待植入的信号 / 变量值以及精确的时间范围）。配置过程既可以手动执行，也可以通过操作剖面半自动推导完成。

从安全分析场景向故障注入与仿真场景过渡的最后一项任务，是基于已添加映射和配置信息的安全分析数据模型，通过模板生成故障库。在该故障库中，所有需植入系统模型的具体故障都以故障注入和仿真平台相关工具可处理的格式列出。

本文提出的模型驱动安全评估环境，与传统分析和评估流程相比，具有显著的改进和优势：

1.通过安全分析元模型（针对 FTA、FMEDA 和 DFA）及相关框架，实现了基于模型的自动化支持，为数据提取、可视化和操作提供了便利。

2.用基于相应元模型实例构建的结构化、简洁的数据模型，替代传统安全分析文档，不仅为复用、一致性检查和基于模板生成衍生模型视图提供了可能，还加快了流程周期，提高了定量评估结果的质量。

3.除通过自动化支持减少工作量外，该环境还提供了一个可动态扩展的失效模式数据库，对已有安全和可靠性相关先验知识进行了有序整理。环境中配备了专门的插件，允许用户在分析迭代过程中存储新添加的失效模式或失效率数值。

本研究的另一项重要贡献，是在汽车应用工业场景中建立了安全分析与故障仿真之间的关联。通过定义语义和语法对应关系，并应用模型到模型的转换技术，实现了在安全评估相关的不同平台上开展工作的不同团队之间的结构化、系统化数据交换。这一关联建立的核心思路，是将双方数据模型对象划分为安全评估的三类基本要素（目标、威胁、应对措施），然后利用匹配算法识别相关映射候选对象，并生成故障库的大部分内容，以自动触发故障注入测试。

在用于验证所提方法可行性和实用性的案例研究中，我们在新环境中对 CPU 模型（MIPS 架构）进行了安全评估。结果表明，与传统流程相比，手动任务减少了多达 60%。

本文针对概率性分析和故障仿真这两种主要安全评估视角之间的差异展开了研究。由于认证安全关键系统需要同时借助这两种视角，因此建立两者之间的系统化数据交换机制具有重要意义。

通过模型驱动开发技术，我们对工业领域中成熟的安全分析方法（FMEDA、FTA、DFA）进行了形式化处理，并建立了与故障注入和仿真之间的关联。由此，手动数据录入被自动化提取所替代，同时借助完善的框架增强了数据处理和可视化能力。此外，通过匹配算法将安全分析数据模型的特定成果映射到系统模型的相应元素，实现了两者的关联。我们还生成了故障库，并构建了从仿真到分析的反向标注机制，以发现分析过程中可能存在的不足。

综上所述，我们提出的方法显著加快了安全评估周期，减少了繁琐且易出错的任务，提高了评估结果的质量。

在未来的工作中，我们将改进用于识别映射候选对象的匹配算法，并完善已构建的元模型，以实现安全要求的自动化追溯，并开展更有效的一致性检查。