摘要： 安全分析的执行往往独立于系统设计生命周期，这导致系统设计与安全工件之间存在不一致性。此外，生成安全工件的过程需人工操作，不仅耗时，还容易出错。因此，安全分析常常需要返工，成本高昂，且会延长系统开发时间。目前，已有多种基于模型的系统工程（ MBSE ）方法被开发出来，用于自动生成特定的安全工件。然而，这些方法仅涵盖了系统设计和安全生命周期的一部分。若要充分发挥MBSE的优势，就必须在整个生命周期内将系统设计与安全分析相结合，并且从同一个模型中生成多个安全工件。此外，那些需要在系统设计模型与安全模型之间进行模型转换的MBSE方法，无法将安全工件的变更自动反映到系统模型和安全模型中。本文提出了一种利用MBSE方法集成整个系统设计与安全生命周期的框架。该框架将系统设计与安全数据整合到一个单一的系统建模语言（SysML）模型中，能够从该模型自动生成失效模式与影响分析（ FMEA ）表、故障树等安全工件。由于无需进行模型转换，该框架确保了系统设计与安全分析的一致性，从而减少了安全分析所需的资源投入。所提出的集成系统设计与安全（ISDS）框架包含三个阶段，这三个阶段共同覆盖了整个系统设计与安全生命周期。本文通过一个实际案例研究，展示了该框架第一阶段的应用过程。

01. 简介

对更高功能的需求以及硬件组件尺寸的快速缩小，促使人们设计出具有高度相互依赖的硬件/软件架构的复杂系统。系统复杂性的增加主要源于规模（系统中元素的数量）、多样性（构成系统的不同元素的数量）和连接性（元素之间的相互关系）的提升。虽然复杂性的提高在系统性能和稳健性方面带来了价值，但确保此类系统安全可靠地运行变得愈发具有挑战性。事故的发生往往是由于软件与硬件之间一些未预料到的交互作用。

传统上，为确保系统安全，在系统设计生命周期的不同阶段会采用多种安全分析技术，如失效模式与影响分析（FMEA）、故障树分析（FTA）和危害分析等。这些分析通常使用独立的工具进行，这就要求工程师从系统设计模型中手动提取相关信息。这不仅耗时且容易出错，还导致系统设计模型与安全模型之间缺乏可追溯性。此外，随着设计的不断演变，如果未能在每个工具中更新模型，会造成系统设计与安全模型不一致，进而导致安全分析结果不准确。这些局限性累积起来，使得系统的安全评估需要返工，既耗时又昂贵。此外，有研究表明，随着系统在生命周期各阶段的推进，修复设计错误的成本会急剧增加，而尽早发现设计错误则能显著减少对项目进度的影响。

为解决上述局限性，研究人员采用了基于模型的系统工程（MBSE）方法进行安全分析。这种方法提高了系统开发的完整性和一致性，促进了设计团队之间更好的沟通，实现了系统不同模型之间更强的可追溯性，并且便于与其他工程分析进行集成。

在MBSE中，模型是“单一信息源”。可以从模型中提取多个视图，作为进一步分析的输入。隐藏无关信息，只分析包含相关信息的视图，有助于管理系统的复杂性。为实施MBSE，多年来已开发出多种建模语言。然而，系统建模语言（ SysML ）是首选语言，已成为系统工程领域事实上的建模语言。

SysML是一种通用的图形化建模语言，适用于对复杂系统进行规范、分析、设计和验证，这些系统可能包含硬件、软件、信息、人员、流程和设施。作为一种具有灵活语义的标准化语言，它能够创建针对特定应用定制的模型。SysML允许创建扩展，这些扩展是不属于SysML规范的模型组件。通过构造型、属性和标记值，扩展能够在单一模型中捕捉特定领域的信息。在基于SysML的安全分析方法中，可以利用扩展在系统设计模型本身中添加与安全相关的信息。这一特性有助于维持系统设计与安全模型之间的一致性和可追溯性。借助扩展，能够自动生成安全工件，从而减少安全评估和设计变更所需的开发时间与资源。MBSE和SysML的这些优势不仅可以解决安全分析中的问题，还能在系统设计生命周期的不同阶段自动生成安全工件。

本文介绍了一个名为集成系统设计与安全（ISDS）的框架，该框架将传统的安全分析技术与MBSE设计方法在整个系统生命周期内进行集成。通过带有安全相关信息标注的系统设计SysML模型，可以自动生成FMEA表、故障树等安全工件。通过构建单一的SysML模型，该框架确保了设计模型与安全模型之间的一致性。此外，安全工件的自动生成有助于缩短系统开发时间。该框架与文献中其他方法的关键区别在于，它提供了在整个系统开发生命周期内确保系统安全的方法。

本文其余部分的结构如下：第2节讨论安全分析领域的研究现状以及将安全分析与MBSE集成的相关工作；第3节介绍ISDS框架；第4节展示该框架在前方碰撞预警（FCW）系统设计中的应用；第5节对全文进行总结。

02. 文献综述

为确保系统安全，安全分析必须在概念阶段早期以及整个系统开发和采购周期中实施。安全标准（如IEC 61508和ISO 26262）推荐的传统安全分析技术包括初步危害分析（ PHA ）、功能危害分析（FHA）、失效模式与影响分析（FMEA）和故障树分析（ FTA ）。初步危害分析（PHA）会详细分析已识别的危害或找出之前未被发现的危害，以确定致因因素、风险和缓解策略。功能危害分析（FHA）通过分析系统/子系统功能来识别系统危害。PHA和FHA均为定性的归纳方法，在设计早期阶段执行。另一种定性危害分析技术是HAZOP，它通过引导词来设想由于系统参数偏离预期行为而可能产生的危害。失效模式与影响分析（FMEA）是一种归纳式的自下而上的方法，用于确定因组件或功能失效而发生的非预期事件的影响，并在系统设计中缓解相关风险。失效模式、影响及诊断分析（FMEDA）是FMEA的扩展，它能确定子系统的失效率和失效模式的诊断能力。传统上，FMEA主要用于硬件分析，但研究人员发现，系统对软件实现其预期功能的依赖程度日益增加，因此现在也有必要进行软件失效模式与影响分析（SFMEA）。最后，故障树分析（FTA）是一种演绎式的自上而下的方法，用于确定特定非预期事件的根本原因。故障树是一种逻辑图形化模型，它表示可能共同导致非预期事件发生的系统事件或状态组合。

近年来，系统理论过程分析（STPA）在安全领域逐渐受到青睐。这是一种自上而下的方法，在分析中使用系统的功能控制图，而非传统安全分析方法所使用的物理组件图。多项研究表明，在安全关键型、软件密集型系统中，STPA在识别危害方面比传统分析方法（如FTA、FMEA等）更具优势。然而，工业界在分析安全关键型系统时，仍在使用传统方法。Sulaman等人在避撞系统上对STPA和FMEA这两种安全分析技术进行了比较，发现这两种方法在识别所有类型的危害方面效果相当，但各自更擅长识别特定类型的危害。因此，本文仅关注传统的安全分析技术。下一部分将讨论相关工作，这些工作采用了上述一种或多种方法，并通过将这些方法与基于模型的方法相结合，克服了安全分析过程中的一些局限性。

A. 相关工作

诸如IEC 61508和ISO 26262等安全标准要求随着设计的推进，反复创建不同的安全工件。多年来，研究人员开发了多种利用基于模型的系统设计来自动生成故障树、FMEA表等安全工件的方法。这些方法的差异体现在用于建模系统架构的语言（如SysML、AADL等）以及用于建模系统架构安全相关方面的语言（如SysML配置文件、AltaRica、HiP-HOPS、FSAP/NuSMV等）。本文仅关注那些使用 SysML 描述系统架构的方法。

对于使用SysML建模系统架构，同时使用另一种语言（如AltaRica）建模架构安全相关方面的方法，需要进行中间模型转换以创建安全模型。然后可以从该安全模型自动生成FMEA表、故障树等安全工件。在文献中，作者展示了从SysML模型生成单一类型安全工件的能力。Xiang等人将SysML模型转换为可靠性配置模型（RCM）规范，并从该规范生成静态故障树。Hecht等人将用于建模系统结构和行为的SysML图转换为AltaRica模型，进而生成FMEA表。尽管文献证明了使用SysML模型自动生成安全工件的实用性，但它们都局限于生成特定类型的安全工件。随着系统设计的演变，整个安全生命周期需要生成多种安全工件。为每种安全工件都将SysML模型转换为不同的安全模型，这种做法效率低下且耗时。

Yakymets等人认识到需要一种涵盖安全生命周期所有阶段的集成方法，因此开发了一个名为Sophia的安全评估框架。该框架支持生成从系统规范到验证与确认活动所需的工件，以符合安全标准的要求。系统架构使用SysML或RobotML（一种用于机器人系统的SysML扩展）进行定义。通过对物理和功能架构进行危害与风险分析，识别出系统级的“担忧事件”或危害。在SysML模型中标注安全信息，并为每个危害定义失效模式与临界性分析（FMECA）。接着，将SysML模型转换为AltaRica模型，然后为每个危害生成故障树。同时，为系统功能或组件确定安全需求，以防止危害发生。然而，这种方法以及其他任何需要进行模型到模型转换的基于模型的安全分析方法，都存在一个缺点：难以维持安全工件与系统设计模型、安全模型之间的一致性，并且在转换过程中数据丢失的可能性会增加。据作者所知，目前尚未实现将安全工件反向转换回安全模型的功能。这种反馈机制的缺失意味着，安全分析的结果无法自动反映到安全模型中，必须手动更新。此外，如果手动进行转换，不仅耗时，还容易出错。

为克服上述局限性，研究人员提出将系统设计模型和安全模型进行集成，将设计数据和安全数据存储在同一个SysML模型中。通过使用SysML的扩展机制（构造型、属性和标记值）创建专门的“安全配置文件”，将与安全相关的信息存储在SysML模型中。这样一来，就无需进行模型转换，并且可以利用安全分析的结果来更新SysML模型中存储的安全数据。Helle提出的方法利用系统功能和逻辑架构的SysML模型自动生成可靠性框图。通过标记值将组件失效率等安全数据嵌入到框图中，并使用构造型在功能架构中识别故障档案。然后，通过脚本遍历SysML模型，为每个故障档案生成可靠性框图。尽管该方法仅侧重于生成单一的安全工件，并且在整个安全生命周期中的适用性有限，但它证明了通过将所需的安全数据直接嵌入到SysML模型中，无需进行模型转换，就能自动生成安全工件。

本文提出了一个集成系统设计与安全生命周期过程的框架，该框架克服了上述相关工作的局限性。按照安全标准的建议，在生命周期早期生成系统级安全需求。使用SysML对系统架构进行建模，并且随着设计的演变，通过SysML配置文件将安全相关数据存储在同一个模型中。因此，无需进行模型转换，仅从SysML模型就能自动生成FMEA表、故障树等安全工件。将高层级安全需求分解为硬件和软件安全需求，并将其分配给相应的低层级组件。在生命周期各个阶段生成的安全工件，可为系统设计的安全性提供证据支持。

03. ISDS框架

本文提出的ISDS框架通过分析系统的运行、功能和逻辑设计视图，自动生成安全工件。如图1所示，该框架遵循“V”型系统开发生命周期模型，不仅能够体现模型开发的迭代性，还能突出每个相应开发阶段都存在一个验证阶段。在ISDS框架中，系统设计生命周期与安全生命周期通过各个阶段之间的一一映射实现集成，这种映射从项目定义阶段开始，一直持续到验证与确认阶段。ISDS框架的左侧涉及项目定义工作，在此阶段，利用SysML图以图形方式表示设计和安全数据，并将其整合到同一 个SysML模型中。框架的右侧涉及每个对应项目定义阶段（左侧）的验证方法。该框架的主要贡献包括：1. 系统设计生命周期与安全生命周期的一一映射，能够在生命周期的不同阶段自动生成 FMEA 表、故障树等安全工件；2. 将高层级安全需求分解为低层级的硬件和软件安全需求；3. 能够将安全工件的任何变更自动反映回SysML模型中；4. 从SysML模型自动生成协议，通过故障注入仿真完成系统安全验证。

图1:集成系统设计和安全框架（ISDS）。框架的左侧对应于生命周期的项目定义阶段，其中使用不同的SysML图捕获不同的设计和安全信息，并将其捕获在单个SysML模型中。框架的右侧对应于生命周期的测试和集成阶段，在该阶段，系统设计根据组件、子系统和系统级别的安全需求进行验证

ISDS是一个概念框架，如图2所示，它分为三个阶段。第一阶段主要进行系统级的系统设计和安全分析，最终自动生成系统级的FMEA和故障树。第一阶段的分析结果将被带入ISDS框架的第二阶段，该阶段主要开展子系统或组件级别的系统设计和安全分析。第三阶段则专注于验证系统设计的安全性。下文将简要概述每个阶段的内容。但本文仅重点详细描述和实施ISDS框架的第一阶段，第二阶段和第三阶段的内容将在未来的研究成果中呈现。

图2:ISDS框架的不同阶段。考虑到框架的规模和范围，它被分为三个逻辑阶段，以便更容易演示其应用。第一阶段仅涉及系统级的设计活动和安全分析。第2阶段使用第1阶段的结果，并在组件级别完成设计活动和安全分析。第3阶段涉及组件、子系统和系统级别的安全验证。通过验证系统设计是否符合相应项目定义阶段中定义的安全需求，在每个级别进行系统安全验证

A. ISDS框架：各阶段概述

本部分将对 ISDS 框架的每个阶段进行概述。

（1）. 第一阶段：系统级分析

第一阶段仅包含系统级的系统设计活动和安全分析。从系统设计生命周期的角度来看，需要先确定系统所需具备的能力，并将这些能力转化为需求，进而以此为基础构建系统的功能架构和逻辑架构。从安全生命周期的角度来看，需要识别那些可能导致（非预期）事故场景的运行场景。通过危害分析确定系统设计必须满足的高层级（或系统级）安全需求，避免违反这些需求。针对系统的功能架构和逻辑架构，需重复进行危害分析，以识别与系统功能相关的危害。安全工程师还需找出可能导致安全目标被违反的失效模式组合。利用危害分析获取的数据以及系统架构信息，可自动生成系统级的FMEA表和故障树。安全分析的结果会指出为确保系统安全而需对系统设计进行的修改。完成必要的设计变更后，需再次进行安全分析，以更新安全工件。

（2）. 第二阶段：子系统级分析

在第二阶段，通过将系统架构分解为系统硬件架构和软件架构，进一步完善系统设计。确定构成子系统的组件模块。针对第一阶段识别出的与某一功能相关的每个危害，制定相应的硬件安全需求和软件安全需求，并将这些需求分配给对应的子系统。通过识别构成子系统的各组件的不同失效模式，自动生成子系统FMEA表。安全工程师需找出可能导致硬件或软件安全需求被违反的失效模式或失效模式组合，并利用这些失效模式生成子系统故障树。针对这些失效模式添加安全机制，以防止安全需求被违反。第二阶段结束时，将为每个子系统自动生成一系列FMEA表和故障树。

（3）. 第三阶段：系统验证

第三阶段主要致力于验证系统设计的安全性。验证工作将依据系统的层级结构展开，从低层级的组件设计开始，逐步推进到高层级的系统设计。在组件级别，需验证子系统中每个组件的行为，确保其不会违反子系统的硬件或软件安全需求。对于那些其缓解策略或安全机制无法防止硬件或软件安全需求被违反的组件失效模式，需明确指出，并为采取纠正措施提供建议。这些建议将在框架的详细设计阶段作为设计变更加以实施。同时，更新安全分析内容，以与最新的设计保持一致。这一验证过程需不断重复，直至组件级别的所有硬件和软件安全需求均得到满足。可采用模型检查、故障注入等多种方法开展此项验证工作。

在子系统级别，需为每个子系统自动生成硬件FMEDA表。FMEDA表包含子系统中各组件的失效模式，以及失效率、用于防止失效模式的安全机制、安全机制对失效模式的诊断覆盖率等额外数据。这些数据既可以由工程师手动添加，也可以通过故障注入获取。为完成故障注入仿真，需从SysML模型中自动生成包含每个子系统设计和安全信息的协议。协议中的设计信息来源于系统，包括子系统中组件的组织方式；安全信息则包括子系统的组件失效模式及其相应的安全机制。通过故障注入仿真，识别出那些会导致子系统级安全需求被违反的失效模式。与组件级验证过程类似，针对这些会导致子系统级安全需求被违反的失效模式，需提供纠正措施建议，并在框架的高层级设计阶段将这些建议作为设计变更加以实施。同时，更新系统级安全分析内容，以与最新的设计保持一致。这一验证过程需不断重复，直至子系统级别的所有安全需求均得到满足。

最后，通过故障注入仿真开展系统级验证。在仿真环境中，针对第一阶段识别出的故障运行场景对系统设计进行测试。通过软件将子系统的失效模式逐一注入到系统设计中，并观察系统的行为。若某一高层级（或系统级）安全需求被违反，则需修改系统设计以防止此类违反情况再次发生。可注入多种失效模式，以观察可能导致安全需求被违反的失效模式组合。需针对所有失效模式重复这一过程，直至所有失效模式或失效模式组合均不会导致任何高层级安全需求被违反，验证工作方可完成。下一部分将介绍为ISDS框架第一阶段开发的SysML配置文件，该配置文件用于在SysML模型中存储安全相关信息。

B. ISDS框架：安全配置文件

ISDS框架通过SysML配置文件将设计数据和安全数据存储在同一个SysML模型中，从而实现系统设计模型与安全模型的集成。因此，无需进行模型转换即可创建安全模型并生成安全工件。下一部分将详细介绍该框架所使用的安全配置文件。

图3展示了ISDS框架的安全配置文件。由于安全目标属于高层级安全需求，因此将SysML需求元类扩展为“安全目标”构造型，该构造型包含一个用于捕捉相关风险的附加属性。根据ISO 26262的风险评估框架，安全目标的风险可分为QM、A、B、C、D五个等级（风险等级依次递增）。在活动图中，系统功能通过 “动作” 元类来表示。危害是指功能行为偏离预期且对系统构成风险的情况。因此，危害通过 “危害” 构造型来表示，该构造型是对 “动作” 元类的扩展。安全目标违规情况和继承的风险通过属性添加到危害中。“安全目标违规”属性旁的[1..*]表示其多重性，即一个危害可能与一个或多个安全目标违规情况相关联。“失效模式”构造型是对“危害”构造型的扩展，它继承了所关联的安全目标违规情况以及违反安全目标所带来的相关风险。此外，“失效模式”构造型还包含原因、影响和缓解策略等属性。一个失效模式可能对应多个原因、影响和缓解策略。每个属性旁的 [1..*]表示该属性可包含一个或多个值，即其多重性。由于该安全配置文件通过构造型和属性为所有必要的安全相关数据提供了存储位置，因此不仅可以从SysML模型中自动生成安全工件，还可以将安全工件中数据的任何变更自动反映到SysML模型中。这对于维持系统设计与安全分析的一致性至关重要。下一部分将详细介绍ISDS框架的第一阶段。

图3:ISDS框架第1阶段的安全配置文件。安全配置文件说明了如何使用原型扩展本地SysML元素来表示安全相关信息。需求和操作元素都是原生SysML元素。从父元素到子元素的三角形表示扩展或继承关系，可以理解为“是”的一种类型。子元素包含用于捕获安全相关信息的其他属性

C.ISDS框架：第一阶段详细说明

对ISDS框架每个阶段的说明，均从设计生命周期相关活动开始，接着介绍安全生命周期活动，最后阐述SysML建模活动。图4展示了ISDS框架第一阶段所执行活动的顺序。

图4:从系统设计和安全角度表示ISDS框架第一阶段活动顺序的序列图。该图突出显示了活动的负责实体和活动结果的目的地。从该图中可以清楚地看到，整合系统和安全生命周期所产生的迭代和协作性质

(1). 制定运行概念并生成故障运行场景

设计生命周期始于制定系统的运行概念，该过程需从利益相关者的角度明确系统的一系列能力，并确定系统的运行场景。在安全生命周期中，需识别出可能导致系统处于不安全状态的一系列运行场景。识别这些运行场景时，需确定一组变量（及其状态），这些变量应能涵盖系统在预期运行环境中可能遇到的各种场景。

(2). 确定系统需求

将上一步骤中识别出的系统能力转化为需求，并利用需求图在SysML模型中记录这些需求。

(3).开展系统危害与风险评估

对系统能力进行危害分析，以识别潜在的系统级危害。这些危害代表可能对系统本身或其运行环境构成重大风险的系统状态，例如人员伤亡或财产损失等。将识别出的危害转化为高层级安全需求（也称为安全目标），并通过需求图将其记录在SysML模型中。依据ISO 26262的风险评估框架，为每个安全目标分配风险等级（或安全完整性等级）。结合第一步中识别出的故障运行场景，对与安全目标相关联的危害进行评估，从而确定暴露度（故障运行场景发生的概率）、严重度（危害发生所造成的后果）和可控性（缓解故障场景的概率）等因素。通过综合这三个因素，计算出与该安全目标相关的安全完整性等级或风险。

(4).构建功能架构

在设计生命周期中构建的系统架构包含两个部分，即功能架构和逻辑架构。将需求转化为系统功能，进而构建功能架构。利用多个活动图在SysML模型中记录功能架构。

(5).构建逻辑架构

逻辑架构用于展示系统的结构设计，它将功能分配给各个模块或子系统，并明确各模块之间的连接关系和数据流。利用模块定义图和内部模块图记录逻辑架构。

(6).开展子系统危害与风险评估

在安全生命周期中，通过危害分析识别潜在的子系统级危害。对分配给每个子系统的功能进行分析，找出其行为偏离预期的情况，并将这些情况作为危害记录下来。通过追溯危害发生时可能被违反的安全目标，确定每个危害的影响。将这些危害添加到功能架构活动图中。某一危害的风险由该危害发生时可能被违反的安全目标决定。若某一危害可能导致多个安全目标被违反，则取其中风险最高的等级作为该危害的风险等级。至此，SysML模型已包含自动生成系统FMEA和系统故障树所需的全部信息。

(7).生成系统FMEA

首先自动生成的安全工件是系统FMEA。图5概述了生成过程。生成SysML模型的XML元数据交换（XMI）文件，然后通过Python脚本解析该文件，以创建FMEA表。遍历逻辑架构中所有模块的每个功能，将识别出的危害作为失效模式提取出来，同时提取相应的安全目标违规情况和相关风险。生成一个.xlsx文件（电子表格），其中包含模块名称、模块功能、失效模式、安全目标违规情况和相关风险等信息。生成FMEA表的算法如算法1所示。安全工程师需对生成的 FMEA 进行进一步分析，补充完善原因、影响和缓解策略等信息。安全配置文件中设有专门的存储区域，用于保存工程师输入的数据。将补充完整的文件重新导入SysML模型，以存储这些新增信息。通过Python脚本解析经过编辑的电子表格，并遍历之前生成的SysML模型XMI文件，为每个失效模式添加原因、影响和缓解策略等属性，从而更新SysML模型。因此，工程师对安全工件所做的任何修改都能自动反映到SysML模型中。更新FMEA表的算法如算法2所示。

图5：从SysML模型自动生成FMEA的过程

（8）.构建功能失效矩阵

生成系统FMEA后，设计工程师和安全工程师需共同协作，识别子系统内部可能导致安全目标被违反的失效模式组合。根据安全标准的建议，失效模式组合的阶数限制为2阶。基于FMEA的结构，通过Python脚本为每个安全目标生成功能失效矩阵模板。该矩阵的行和列均列出了子系统的各个失效模式。矩阵中带有标记的单元格表示，对应行和列中的失效模式单独存在时不会违反安全目标，但两者组合在一起时则会导致安全目标被违反。需要注意的是，只有不同功能的失效模式组合才可能导致安全目标被违反，因为某一特定功能无法同时呈现多种正常行为或异常行为。

（9）.生成系统故障树

接下来从SysML模型中自动生成的安全工件是系统故障树。与FMEA的生成过程类似，故障树的生成过程也是自动化的，生成速度快，且与最新的系统设计保持一致。图6展示了该生成过程，图7则展示了故障树的结构。由于通过内部模块图已知各模块之间的连接关系和数据流，因此某一模块的故障既可能是该模块的内部故障（基于其失效模式），也可能是该模块的输入故障。通过 Python 脚本解析SysML模型的XMI文件和FMEA表中的数据，从而生成故障树。利用内部模块图，该脚本可追溯从输出到输入的信息流，并为每个安全目标违规情况生成一系列事件（或失效）。在模块的内部失效中，仅考虑那些可能导致安全目标被违反的失效模式。模块的内部失效通过“OR”逻辑门来表示，该“OR”门的输入既可以是可能导致特定安全目标被违反的单个失效模式，也可以是功能失效矩阵中已识别出的失效模式组合。失效模式组合则通过“AND”逻辑门来表示。生成故障树的算法如算法3所示。生成的故障树采用Open-PSA模型交换格式，可使用支持XFTA引擎的工具查看该故障树。

图6:从SysML模型自动生成故障树的过程

图7:生成的故障树的结构。此结构表示从输出到输入的块序列。块的内部失效包括单个失效模式或违反安全目标的失效模式组合。失效模式的组合使用逻辑与门表示

04. 案例研究：第一阶段的应用

本部分通过一个案例研究，展示如何运用ISDS框架的第一阶段从SysML模型中自动生成系统级FMEA表和故障树。该案例研究聚焦于前方碰撞预警（FCW）系统的开发。需要说明的是，本研究的重点在于ISDS框架的应用，而非对FCW系统进行全面设计。

FCW系统能够识别车辆可能发生即将碰撞的情况，并通过声音或视觉信号向驾驶员发出警报。该系统的实现依赖于以下几个部分：前视传感器，用于获取车辆前方物体和道路的相关信息；处理单元，以传感器获取的信息作为输入，判断碰撞发生的概率；以及车辆内部的视觉和/或声音警报界面，用于向驾驶员发出警报。FCW系统的能力和需求基于文献确定。下文将详细介绍ISDS框架第一阶段各个步骤的具体实施过程。

A.识别故障运行场景

ISDS框架的第一步是识别一系列运行场景，系统在这些场景下应避免出现危害（或不安全）行为。表1列出了车辆的一组环境变量（及其状态）。

表1：配备前方碰撞预警系统的车辆的环境变量及其状态

通过组合每个变量的不同状态，可以构建出系统应避免出现不安全行为的驾驶场景。例如，一个潜在的驾驶场景可能是：车辆在结冰路面上以高速（130公里/小时≥速度>100公里/小时）行驶在高速公路上，前方有其他车辆，且无行人出现。

B.确定系统需求

如前所述，FCW系统的能力和需求参考自文献。利用需求图将这些需求记录在SysML模型中，如图8所示。

图8：FCW系统的SysML系统需求图

C.开展系统危害与风险评估

采用HAZOP方法对FCW系统进行系统危害分析，以识别系统级或车辆级危害。本次HAZOP分析使用的引导词如下：

·  功能丧失

·  过早（启动）

·  过晚（启动）

·  非请求（启动）

基于这些引导词，识别出与FCW系统相关的以下车辆级危害：

·  FCW系统意外失效

·  FCW系统过早启动

·  FCW系统过晚启动

·  FCW系统非请求启动

这些危害代表FCW系统的不安全行为。为防止这些危害的发生，制定了高层级安全需求（即安全目标），如图9所示。利用“安全目标”构造型将这些安全目标记录在SysML模型中。

图9:使用HAZOP方法确定的FCW系统的高级安全要求或安全目标的SysML图

依据ISO 26262标准中的风险评估框架，确定每个安全目标对应的风险等级（或安全完整性等级）。针对第一步中识别出的每个故障运行场景，分别确定暴露度、严重度和可控性，并计算出相应的风险。表2以“防止FCW系统过晚启动”这一安全目标（安全目标3）为例，展示了在特定运行场景下如何进行风险评估。对第一步中构建的所有运行场景均需重复进行此项风险评估。为安全目标分配的风险等级，取所有运行场景中识别出的最高风险等级，并将该风险等级作为属性添加到安全目标模型元素中。

表2：基于ISO 26262风险评估框架对某运行场景的风险评估

D.构建功能架构

功能架构包含一组可满足系统需求的功能。利用活动图在SysML模型中记录系统功能及其相互关系，如图10所示。

图10：SysML活动图，表示FCW系统的功能架构

E.构建逻辑架构

利用模块定义图和内部模块图构建逻辑架构。图11所示的模块定义图识别出了FCW系统的各个逻辑模块（或子系统），并将系统功能分配给每个模块。为保证图表的可读性，仅展示了车道检测传感器模块的功能分配情况。内部模块图用于识别子系统之间的连接关系和数据流，图12展示了FCW系统的内部模块图。

图11:SysML块定义图，表示FCW系统的逻辑架构。它显示了系统的不同逻辑块以及分配给它们的功能。为了可读性，仅显示了车道检测传感器块的功能分配

图12:SysML内部框图，表示FCW系统的逻辑架构。它显示了不同逻辑块和数据流之间的互连

F.开展子系统危害与风险评估

采用HAZOP方法，对图11中每个模块的各项功能进行子系统危害分析，以识别子系统级危害（与子系统功能相关的危害）。本次HAZOP研究使用的引导词如下：

·  功能丧失

·  功能过剩

·  功能不足

·  功能锁定

·  输出间歇性中断

·  方向错误

·  非请求（功能）

通过引导词启发思考，找出子系统功能可能存在的危害，并利用“危害”构造型将这些危害添加到子系统功能中，如图13所示。为每个危害添加“安全目标违规”属性，以记录该危害可能违反的安全目标。图13展示了在SysML模型中为“检测车道标线”功能记录的危害。

图13:SysML活动图显示了为检测车道标记功能识别的危害

G.生成系统FMEA

通过Python脚本解析SysML模型的XMI文件，生成FCW系统的系统FMEA。利用图11所示的模块定义图，识别出各个模块及其分配的功能。依据图13中的信息，提取出每项功能对应的危害。根据图13中记录的安全目标违规情况，确定相应的风险等级。将这些数据整理后存储在电子表格中，如表3所示。为保证表格的可读性，生成的FMEA仅包含FCW系统中一个模块（车道检测传感器模块）的相关信息。“原因”和“影响”列留空，由安全工程师在FMEA生成后补充完整。安全配置文件中的“失效模式”构造型包含“原因”和“影响”这两个属性的存储位置。因此，通过Python脚本将电子表格中的修改（补充的原因、影响和缓解策略）添加到模型的XMI文件中，即可将这些修改反映到SysML模型中。将更新后的XMI文件导入SysML软件，即可查看相应的修改内容。

表3：前方碰撞预警（FCW）系统车道检测传感器模块两项功能的失效模式与影响分析（FMEA）。“-”表示相关信息需由工程师填写

H. 构建功能失效矩阵

基于FMEA的结构，通过Python脚本生成功能失效矩阵模板。对于每个安全目标，该脚本会为每个模块（或子系统）生成一个独特的n×n矩阵，其中n代表该模块中失效模式的数量。表4展示了车道检测传感器模块的功能失效矩阵。

表4：识别违反安全目标3的失效模式组合的功能失效矩阵

I.生成系统故障树

FCW系统的系统故障树根据图12所示的逻辑架构生成。该故障树遵循图7所示的结构，以Open-PSA格式的XML文件形式生成，可使用支持XFTA引擎的开源工具（如SCRAM）查看。为便于阅读，图14仅展示了生成的故障树XML文件的部分内容。由于SCRAM工具的图形用户界面功能有限，难以导出高质量的故障树图像，因此通过图形软件重新绘制了故障树以实现可视化展示，如图15所示。每个圆形事件代表模块的内部故障，其中仅包含FMEA表中那些可能导致安全目标1被违反的失效模式。基于此故障树，可在系统设计中添加故障缓解策略和安全措施，以避免安全目标1被违反。

图14：FCW系统违反安全目标1的故障树XML的一小部分

图15:故障树XML的可视化

05. 讨论

在安全分析领域，生成安全工件的过程需人工操作、耗时且易出错，同时设计模型与安全模型之间存在不一致性，这些都是亟待解决的主要挑战。本文提出的ISDS框架通过将系统设计模型与安全模型集成到单一的SysML模型中，有效解决了这些问题。该框架利用SysML配置文件在SysML模型中捕捉安全数据，无需进行模型转换即可自动生成安全工件。因此，不仅不会出现数据丢失的情况，还能将安全工件的任何变更自动反映到SysML模型中。

ISDS框架在现有研究的基础上实现了多方面改进：首先，该框架实现了整个系统设计生命周期与安全生命周期的一一映射，明确了如何在集成生命周期的不同阶段应用多种安全分析方法，以自动生成安全工件；其次，将高层级安全需求分解为组件级的硬件安全需求和软件安全需求，这种分解确保了安全需求、为满足需求所做的设计决策以及验证设计是否符合需求的验证活动之间的可追溯性；再次，工程师对安全工件所做的修改可自动反映回SysML模型中，在工程师参与的情况下，将安全工件与SysML模型相关联，对于维持系统设计与安全分析的一致性至关重要；最后，从SysML模型中自动生成包含系统设计和安全信息的协议，该协议是完成系统安全验证所需的关键文件。故障注入仿真将为系统设计满足安全需求提供证据支持。从SysML模型中提取协议，确保了设计阶段（“V”型左侧）与验证阶段（“V”型右侧）之间的一致性和可追溯性。本文仅介绍了自动生成安全验证协议的概念及其优势，关于该协议的详细说明以及通过案例研究验证其实施效果的内容，将在后续研究成果中呈现。

06. 结论

本文提出了一种基于MBSE方法的ISDS框架，该框架实现了整个系统设计生命周期与安全生命周期的集成。该框架包含三个阶段，本文通过案例研究详细阐述并实施了框架的第一阶段。在未来的研究工作中，将进一步实施第二阶段和第三阶段：第二阶段将展示如何将高层级安全需求分解为组件级的硬件安全需求和软件安全需求；第三阶段将重点说明如何在组件级、子系统级和系统级完成安全验证。此外，还将利用SysML模型中的系统设计和安全信息生成协议，通过故障注入仿真验证系统设计是否符合安全需求。