利用SysML建模进行功能安全和网络安全评估

为应对现代汽车系统日益增长的复杂性，开发公司纷纷采用基于模型的系统工程（MBSE）。在 MBSE 流程中，需要选择并组合合适的建模方法，包括半形式化建模、软件生成、工程仿真和软件仿真等建模与仿真方法。如今，框架方法论甚至可以支持建模方法的选择、定制和接口设计。在此数字化开发流程背景下，本文探讨了在汽车领域 MBSE 环境中，如何在系统开发早期阶段利用 SysML 建模有效支持开发人员进行功能安全和网络安全（IT 安全）评估。该方法的可行性通过在嵌入式系统软件平台（SPES）框架内开发功能安全和网络安全分析概念得以实现。此概念通过元模型进行记录，并以 SysML 配置文件为支撑，这些配置文件在 IBM Rational Rhapsody 环境中扩展了 SPES 配置文件。网络安全分析配置文件支持开发人员在系统层面按照基于微软 STRIDE 的 “通过修复漏洞增强软件安全性与安全性（HEAVENS）” 安全模型（专为汽车领域设计）的指南进行评估。开发了基于 SysML 模型的原型，即包含功能安全和网络安全评估的 SysML 系统设计，在汽车 MBSE 试点项目中验证了该方法。一个样本原型应用展示了该方法的可行性，并可估算在符合 SPES 的环境中，由 SysML 支持的开发人员进行功能安全和网络安全评估所需的工作量。主要成果包括：面向 SPES 的 SysML 模型（如上下文、场景、目标、功能模型）可复用且能进一步开发，在这些系统模型中实现了与功能安全和网络安全相关的模型扩展与细化。这些细化和扩展形成了支持项目定义、危害与风险分析、功能安全概念及技术安全概念的功能安全相关模型。同样，与网络安全相关的 SysML 模型有助于根据 HEAVENS 方法进行评估目标（TOE）描述、威胁分析与风险评估以及网络安全需求推导。通过使用辅助工具对这些扩展的 SysML 模型进行自动化处理，提高了其可用性。例如，辅助工具可在模型内自动确定功能安全和网络安全参数（如 ASIL 等级确定、安全级别推导），并基于开发人员的输入提供过滤后的图形视图。与模型检查器配合，辅助工具可协助快速执行分析、一致性检查并生成评估工件，如风险及其控制的表格概述。

汽车领域系统工程方法的应用受到日益增长的复杂性、集成需求、复杂供应链以及不断提高的（功能）安全和安保需求的推动。基于模型的系统工程（MBSE）将系统建模作为系统工程过程的一部分，用于支持所开发系统的分析、规范、设计、测试、验证和确认，例如 V 模型所要求的。这种方法的重要成果是开发出一个连贯的、共享的系统数字模型。与（数字）基于文档的方法相比，它有诸多优势，如改进规范、提高设计质量和一致性、复用设计和规范工件以及改善开发团队之间的沟通。因此，诸如一致性、可理解性和良好形式性等质量方面得到了增强。

系统建模语言（SysML）是一种通用的半形式化图形语言，用于对由硬件、软件、数据和物理工程环境中的其他元素组成的系统进行建模。它用于对需求、结构和行为以及相关参数进行建模，以描述系统、其组件及其周围环境。因此，SysML 是实施 MBSE 方法的理想选择。只有遵循结构良好的方法，才能有效使用 SysML。此外，其应用方式需要适应 MBSE 开发过程，特别是要超越原理性应用，例如在功能安全方面。

当前基于模型的开发方法在实践中常常失败，主要原因是缺乏建模（关于建模的）理论，以及理论、方法和工具的集成缺失。另一个问题是，工具链是根据现有开发流程定制的，而不是根据可用的最佳实践工具来调整和更新开发流程，在大公司中尤其如此。模型之间的转换容易出错，因为所应用的模型往往基于相互分离且不相关的建模理论。

嵌入式系统市场竞争压力巨大，因此上市时间和开发成本是重要驱动因素。无法交付高质量的嵌入式系统可能导致直接的财务后果或对人员造成威胁。例如，福特和丰田著名的汽车召回事件，还有西门子的 IEC 3 代列车因安全问题导致交付延迟，以及最近波音公司的安全问题。此外，物联网（IoT）方法、联网信息娱乐系统、无线网络中的汽车通信、远程更新和维护等，都凸显了网络安全措施的必要性。

人们发现安全和安保流程之间存在许多相似之处。这种重叠可用于定义这两个可靠性主题之间可比较的流程和评估技术。然而，与（功能）安全流程相比，IT 安全评估和生成流程尚不健全，特别是在（汽车）嵌入式领域，旨在实现联合或类似建模方法的情况更少。

在汽车供应链中，典型情况是工程服务提供商为原始设备制造商（OEMs）工作，提供动力系统、安全系统、车辆动力学和信息娱乐系统的系统、功能和软件开发服务，以及这些系统的电气和电子集成服务，这些工作的复杂性要求采用 MBSE 方法。此外，项目中的功能安全和网络安全需求至关重要。最相关的标准包括汽车功能安全标准 ISO 26262、过程管理标准汽车 SPICE（ASPICE）ISO/IEC 33004、自动驾驶预期功能安全（SOTIF）ISO/PAS 21448以及新的网络安全标准 ISO/PAS 21434 等。然而，这些流程目前仍严重依赖基于数字文档的方法，且往往无法联合进行。

在这种情况下，本文旨在帮助功能安全和网络安全工程师在复杂项目环境中的系统设计早期阶段开展评估工作。特别是支持他们准备涵盖功能安全和网络安全风险评估、功能安全和网络安全需求确定的 SysML 工件，以及在开发严谨程度分配方面的相关方法选择。这在设计概念层面以及后续的验证和确认中得以实现。因此，本文致力于解决以下最佳实践研究差距：（i）如何将功能安全和网络安全分析集成到 SPES 等 MBSE 方法中？（ii）如何在可追溯性、完整性、部分自动化方面减少系统开发手动方法的工作量？（iii）与基于文档的方法相比，基于模型的方法如何更有效地管理复杂的开发生命周期？（iv）如何使用半形式化模型在 MBSE 方法中实质性支持最佳实践功能安全和网络安全标准的实施？（v）如何验证该方法？

本文结构如下：第 2 节阐述了在汽车领域 MBSE 中使用 SPES XT 和 SysML 进行基于半形式化模型的安全和安保评估的主要研究差距。第 3 节描述了将汽车领域功能安全和网络安全评估的不同流程映射到基于模型的方法和半形式化语言范式的分析工作，这些概念以元模型形式记录，并解释了进一步的方法规范，以及分别使用 SysML 元模型进行基于标准的概念验证的提示。第 4 节涉及该方法的实施及其通过原型设计进行的验证，测试了各种 SysML 图中使用的构造型、标签、利用这些模型实现的自动化以及辅助工具和模型检查器应用对开发人员进行功能安全和网络安全评估的支持，并最终在实施层面进行了讨论和评估。第 5 节给出结论和展望。

若不聚焦于以核心为中心的方式，即与实现相关的文档，很难转向更有效的需求驱动和架构中心的流程。为此，国际系统工程委员会（INCOSE）提出了基于 ISO/IEC/IEEE 15288 标准的 MBSE 方法。在此背景下，嵌入式系统软件平台（SPES）是一种基于模型的方法，旨在无缝集成不同的相关流程和模型。它通过使用分析模型，将安全方面集成到开发过程及其模型中，专注于安全相关方面的建模，这些分析模型是按照整体基于模型的开发（MBD）原则开发的，旨在提高不同安全分析方法和技术之间的一致性和可追溯性。它有助于利用不同模型集成之间的协同作用。SPES 中使用的主要概念是抽象层、视图和视角。可根据结构重要性在不同抽象级别设计所开发的系统。视图和视角用于处理复杂工程过程中不同利益相关者的关注点。视图表示从一组相关关注点的角度对整个系统的描述，视角定义了如何使用视图。

在比较 IBM Telelogic Harmony-SE、INCOSE 面向对象系统工程方法（OOSEM）、IBM Rational 统一过程系统工程（RUP SE）、Vitech MBSE时，SPES与 Vitech MBSE 是唯一涵盖属性框架、功能安全、SysML、仿真和模型集成的方法，这显示了 SPES 方法的重要性。然而，所列的 MBSE 框架均未涵盖网络安全。其他维度可能包括方法或工具的成本以及提及该方法的出版物数量，即科学认可度、用户认可度、形式化证明程度等。

SPES 2020 中未解决的研究差距包括质量方面，即可变性、早期工件验证等，这些是能够应用 SPES 框架的开发过程的先决条件。SPES 2020 方法的扩展版本 SPES XT致力于解决 SPES 2020 中的一些问题和挑战，改进了软件与系统工程之间的集成、软件到硬件的优化部署、早期验证和模块化安全保障。模块化安全保障基于开放安全模型。同样，SPES XT 中也未讨论网络安全方面。

已有研究在不同抽象级别使用 SysML 模型进行功能安全评估，但通常不在 MBSE 环境中，即不受（汽车）嵌入式领域的 SPES 等整体建模环境的约束。此外，与本方法相比，很少有应用关注 ISO 26262 中关于危害和风险分析（HARA）的概念阶段，更多是将 SysML 用于形式化可视化。

总体而言，汽车电子电气系统中识别安全漏洞的网络安全评估方法不如安全评估方法成熟。汽车领域专用的网络安全标准是较新的 ISO/PAS 21434。HEAVENS（通过修复漏洞增强软件安全性与安全性）安全模型旨在为识别汽车领域复杂嵌入式系统的安全需求提供框架。该模型主要基于其他非汽车行业（如电信、IT、国防和 Web 应用）中使用的威胁分析和风险评估方法的最新技术。

为进行合理选择，比较了不同的网络安全方法及其与 HEAVENS 的相关性，考虑了应用领域、威胁覆盖范围、漏洞和风险评估：通用准则（CC）、操作关键威胁、资产和漏洞评估（OCTAVE）、欧洲电信标准协会（ETSI）、开放式 Web 应用安全项目（OWASP）、微软 STRIDE、汽车电子安全入侵保护应用（EVITA）、SECTRA 模型、通用漏洞评分系统（CVSS）等。对于威胁分析，选择 STRIDE 是因为它以通用方式对威胁进行分类，适用于嵌入式汽车领域。

例如，EVITA中描述的特定威胁是 STRIDE 威胁类别的子集。此外，STRIDE 以威胁为中心，这意味着它突出显示攻击的最终结果，而不是关注特定攻击 。攻击者利用威胁来利用漏洞，这会对资产造成风险。由于一个漏洞可能导致多种威胁，而单个威胁可能利用多个漏洞，因此无法将威胁与漏洞进行单射映射。通用准则（CC）和 WIFFs仅提供通用映射。HEAVENS 的风险评估部分从代表攻击潜力的威胁级别和与风险影响部分相关的影响级别中推导出安全级别。

可以比较上述安全评估框架中用于计算不同方法属性中威胁级别的参数，威胁级别参数主要与 CC 一致。在 HEAVENS 中，与 CC 相比，不考虑经过的时间，因为它使用以下参数（类别）：专业知识、关于评估目标（TOE）的知识、机会窗口和设备。也可以比较不同方法中用于计算影响级别的参数。成功攻击 TOE 的可能后果是根据影响级别因素确定的。与 OWASP 和 EVITA 的业务影响因素类似，HEAVENS 使用安全、财务、运营、隐私和法规因素。

总之，进一步的综述工作表明，SysML/UML 扩展对于开发人员进行系统网络安全评估是可行和有用的，也可与功能安全联合进行，并作为汽车（嵌入式）系统开发概念阶段部分自动化评估的起点。然而，到目前为止，它们通常仅应用于略有不同的领域，如网络、组织层面、物联网应用、工业控制系统（ICS），并专注于特定方法的应用，且未嵌入 MBSE 框架中。

为简洁呈现和清晰说明，从现在开始，重点将放在 SPES MBSE 框架内根据 HEAVENS 方法进行的 SysML 支持的网络安全评估。HEAVENS 的网络安全评估可分为三个步骤，系统开发人员需要涵盖并记录这些步骤，见图 1：

图 1：OMG SPEM（软件和系统过程工程元模型）图中的 HEAVENS 工作流程 

1. 威胁分析：TOE 是分析的特征或对象，对其进行 STRIDE 威胁分析。TOE 或其相关功能用例在数据流图（DFDs）中表示。识别出的安全威胁映射到资产。资产是数据流图中的实体，分为过程、数据流、数据存储或外部实体。在威胁和安全属性之间进行映射。

2. 风险评估：利用 STRIDE 威胁与资产的映射、影响级别和威胁级别来确定安全级别。

3. 网络安全需求推导：考虑 STRIDE 威胁与资产的映射以及安全级别来制定安全需求。

表 1 显示了 STRIDE 威胁及其安全属性映射，同时解释了缩写本身。

表 1：STRIDE 威胁与安全属性映射

在逐个元素的 STRIDE 变体中，DFD 中的每个元素都要评估 STRIDE 威胁。在逐个交互的 STRIDE 变体中，DFD 中每个元素的交互是威胁评估的基础。对于汽车领域应用，逐个元素的 STRIDE 变体比逐个交互的 STRIDE 变体更好。表 2 列出了 STRIDE 与 DFD 元素的逐个元素映射。

表 2：STRIDE 与元素的映射 

HEAVENS 的三个分析步骤（另见图 1）在 MBSE 方法中可使用表 1 和表 2 进行总结：

根据 HEAVENS 模型进行的网络安全评估使用微软的 STRIDE 威胁模型。TOE 的概念是评估的起点，类似于 ISO 26262 中使用的项目。STRIDE 中使用的威胁是网络安全中的安全对应物，类似于 ISO 26262 中使用的危害。

HEAVENS 方法执行威胁分析和风险评估（TARA）以推导出安全级别，类似于汽车安全完整性等级（ASIL）。威胁分析是基于与 TOE 相关的功能用例的数据流图进行的。为每个 TOE 的资产分配 STRIDE 威胁。威胁映射到也分配给资产的安全属性。

风险评估中使用影响级别和威胁这两个参数来推导安全级别。网络安全需求分配给资产，资产将映射到其相关威胁和安全属性以及安全级别。分配了威胁、安全属性和安全级别的资产是与 HEAVENS 网络安全需求相关的主要属性。

在当前应用环境中，系统和软件开发由 3 层模型组成。较高层与上下文相关，此处的上下文代表项目和技术层面。下一层定义系统，第三层关注硬件（HW）和软件（SW）。

这些级别映射到 SPES 中的抽象层，即上下文层、系统层和硬件 / 软件层。在这三个抽象层中，分别开发了需求视角、功能视角、逻辑视角和技术视角。

除了将抽象层和视角与安全和安保属性相关的不同模型进行映射外，概念开发还融入了自动化。自动化是通过辅助工具实现的，这些辅助工具独立于抽象层和视角。辅助工具是附加到模型上以增强其功能的自定义程序。通过自定义检查实现的模型检查器是该方法的附加组件，可基于系统模型和系统开发人员的评估输入生成额外的工件。一般来说，这种映射结构可用于所有项目。但并非每个层的安全或安保评估都需要所有四个视角。在网络安全评估中，SysML 对这类过程的支持提高了工作效率。表 3 列出了 SPES 与 HEAVENS 阶段的映射。

表 3：SPES 与 HEAVENS 工作流程阶段的映射

接下来，SysML 元模型用于表示 SPES 方法，以及 SPES 在 IT 安全方面的扩展，使开发人员能够在 IBM Rhapsody 等 MBSE 环境中使用它。图形化 / 半形式化元建模使步骤和依赖关系更加透明。

图 2 和图 3 展示了系统开发人员使用的网络安全评估的块定义图（BDD）元模型。在图 2 中，展示了评估目标描述。评估目标与 SysML 模型类型的关联类似于项目所使用的关联。同样，在网络安全评估中，ISO 26262 中的目标模型被数据流模型取代。数据流模型包括 SysML 活动图（ADs）、SysML 块定义图（BDDs）等的聚合。箭头和线条显示了开发人员可以使用的不同实体之间的关系。

在图 3 中，展示了威胁分析和风险评估元模型。每个评估目标都包含资产的组合（即强聚合）。每个资产都有多个 STRIDE 威胁标签，类型为 STRIDE。通过应用构造型 <<Process>>、<<DataFlow>>、<<DataFlowBlock>>、<<DataStore>> 和 <<ExternalEntity>> 对资产进行泛化。这些构造型在资产中创建了 STRIDE 威胁列表。<<CyberSecurityRequirement>> 是 SysML 需求的泛化，它被分配给资产。

图 2：开发人员可使用的显示评估目标描述的网络安全评估 BDD 元模型

图 3：HEAVENS 风险评估工作流程的网络安全评估元模型

可以评估 SysML 元模型对 HEAVENS 网络安全方法的覆盖范围及其与系统模型相关 SysML 图的关联能力，结果表明评估目标描述通过 BDD、用例图（UCD）、ADs 和内部块定义图（IBD）及相关关联来覆盖。威胁分析通过在相应模型元素（如块、对象流、参与者等）中生成标签的构造型来覆盖。风险评估通过辅助工具进行，网络安全需求可以使用 SysML 需求图（RD）建模，也可以通过表格形式提取其信息。这样就确保了该方法的完整性、可追溯性和可自动化性。

该方法基于元模型的实施和验证是通过原型设计完成的。本节包含与该概念相关的 SPES 打包、相关模型、与构造型模型结合的自动化以及关于模型检查的讨论。它借助试点系统工程项目中的原型详细阐述了该概念的验证，还讨论了实施的定量评估。

SPES 抽象层和视角（见第 2 节）在 SysML 包图（PD）结构中可视化，如图 4 所示，以展示不同包中 SysML 模型的组织。请注意，视图和视角是一起查看的模型集合，这些模型或单个模型可以分布在多个抽象层中。

图 4：面向 SPES 的扩展包结构

如第 3 节所述，集成 SPES、HEAVENS、ISO 26262 和 SysML 所需的各种模型包括上下文模型、场景模型、目标模型、需求模型、功能模型、结构模型、行为模型和数据流模型。请注意，前五个是 SPES 中的标准建模名称，而后三个是专门引入的。每个模型由第 3 节中介绍的适当组合的 SysML 图表类型组成。

在表 4 中，与 SPES、ISO 26262 和 HEAVENS 相关的模型元素的映射分布在不同的 SPES 抽象层和视角中。

表 4：SPES 抽象层和视角中使用的模型元素映射

对于自动化和模型检查，IBM Rational Rhapsody 提供了编程语言 C++ 和 Java 的应用程序外围接口（APIs）。第 3 节中介绍的辅助工具调用编程自动化脚本，以支持 SysML 模型。在当前方法中，使用 Rhapsody 模型接口的 Java API 和模型检查器的 Java 接口，在 Eclipse IDE 环境中使用 Rhapsody 软件开发工具包（SDK）实现自动化。

使用了以下自动化概念：

1. 安全级别由开发人员根据分配给每个 STRIDE 威胁的影响级别和威胁级别自动确定。威胁级别和影响级别也根据其参数自动计算。与威胁相关的安全属性也映射到该威胁。

2. 为实施该方法，扩展了第三方模型检查器，并使用 Java 插件进行自定义检查。第三方模型检查器包括一个自定义用户界面，用于显示检查及其结果。

3. 实施了图表视图，以图形方式隔离某些建模元素，提高可读性并降低复杂性。

例如，在显示技术安全概念的活动图中，根据评估输入对图形元素应用颜色变化并进行可视化。这有助于从图形上区分正常功能和安全相关功能。请注意，此功能与图表视图不同。

该方法的验证是通过使用和扩展博世工程有限公司开展的试点项目中可用的基于 SysML 模型的原型来进行的。选择了故障指示灯（MIL）异质性系统及其功能，在 IBM Rhapsody 环境中使用 SysML 进行开发和分析。它通过车辆的仪表组指示感兴趣的发动机管理系统（SOI）中的故障或缺陷。使用 “异质性” 一词是因为 MIL 系统指示发动机系统中由于影响发动机的外部因素导致的故障。例如，电子稳定程序（ESP）故障可能导致发动机排放增加，MIL 异质性通过仪表组指示此问题。

网络安全评估方法基于评估目标描述，见图 2。开发人员根据 HEAVENS，按照以下构造型对资产进行分类：适用于 SysML 块和泳道的 <<Process>>、适用于 SysML 块和泳道的 <<DataStore>>、适用于活动图和泳道中对象流的 <<DataFlow>>、适用于用例图中参与者的 <<ExternalEntity>>、<<DataFlowBlock>> 是一个附加构造型，其用途与 <<DataFlow>> 相同，但应用于块而不是对象流。

图 5：应用于评估目标块元素的网络安全构造型

与构造型资产相关的 STRIDE 威胁作为标签列出。威胁分析阶段由开发人员通过将构造型应用于图元素启动，如图 5 所示。这些构造型使图组件与网络安全相关，因此需要开发人员进行进一步评估。例如，在图 5 中，对块 ESP 应用构造型 <<Process>>，这是因为 ESP 象征着一个逻辑电子控制单元（ECU）系统，根据基于 HEAVENS 的数据流模型，这是一个过程元素。同样，考虑网关：它与 HEAVENS 中数据流模型中的数据流元素相关，因此使用构造型 <<DataFlowBlock>>。此类图表还可用于为网络安全相关元素着色。

这些图元素是 HEAVENS 模型中与评估目标相关的资产。构造型在资产中生成作为 SysML 标签的威胁。在图 6（a）中，资产 ESP 是一个过程实体，映射到 STRIDE 威胁列表，见表 1。与每个威胁相关的网络安全属性作为威胁内的标签生成。同样，所有具有网络安全相关构造型（Process、DataFlow、ExternalEntity、DataStore 和 DataFlowBlock）的元素都会生成威胁。

图 6：（a）基于开发人员的输入，在块 ESP 中列出并存储样本威胁（左侧）。（b）使用辅助工具确定威胁的影响级别、威胁级别和安全级别（右侧）

进一步说明见图 6（b）。威胁 1 “欺骗” 具有内部标签 “安全属性”，其值设置为真实性和新鲜性，见表 1。风险评估步骤包括开发人员根据相关参数为威胁分配影响级别和威胁级别。风险评估的结果是为威胁推导出安全级别。辅助工具 “计算安全级别” 计算影响级别、威胁级别、安全级别，并根据开发人员的输入将这些值分配给相应的标签，见图 6（b）。

最后，图 7 的样本表格视图截图给出了开发人员确定的网络安全需求、其分配的资产、相关威胁、安全属性和安全级别的样本前景。

图7：网络安全要求的表格视图

共使用大约 30 张图表进行联合功能安全和网络安全评估。一些模型元素（如块、标签、需求等）虽然不属于所列图表，但也参与了实施：3 个 BDD、3 个 IBD、1 个 UCD、12 个 AD、2 个 RD、2 个图表视图、8 个表格视图、32 个构造型和 4 个查询。SysML 在单个 Rhapsody 项目中建模，该项目处理从系统开发、功能安全评估到网络安全评估的所有事情。请注意，通常作为文档（通常在结构化表格中）提供的描述性信息（如安全 / 安保案例）也可以使用描述字段、标签、属性和注释在模型中管理，直接在图表中进行。另一方面，当然可以从扩展了功能安全和 IT 安全 SysML 扩展的原型模型中生成此类汇总表，如前所述。因此，满足了第 1 节中提出的 MBSE 要求。

表 5 中的工作量估计检查表明，对于现实世界的应用，假设已经存在根据 SPES 的 MBSE SysML 系统模型，开发人员进行 SysML 支持的联合功能安全和网络安全评估的额外工作量相当有限。

表 5：不同阶段的实施工作量和应用估计（小时）

网络安全实施的优势如下：通过扩展的 SysML 模型、标签、构造型和辅助工具，提出并实现了无缝工作流程，这些工具支持开发人员进行网络安全评估，以及基于输入的自动化和模型检查器。系统开发人员在满足 HEAVENS 过程方面以正式方式实现了网络威胁评估的完整性。该方法通过 SPES MBSE 框架确保了系统开发所有层的可追溯性。使用辅助工具的模型检查器和自动化增强了扩展的 SysML 模型的可用性，并提高了记录开发人员进行的 HEAVENS 评估过程的效率。功能安全方法的形式化和实施方式与网络安全评估过程类似。该方法的实施只需进行一次，因此具有可复用性。系统开发、功能安全和网络安全评估使用单一模型源并行进行。

该方法的缺点包括：仅通过点击威胁和输入评估来正式进行功能安全和安保评估存在风险。构造型提供了许多潜在威胁，用户需要小心删除非重要威胁并识别相关威胁，更普遍的是，可能完全缺乏更新的威胁类型。该方法要求功能安全和网络安全专家至少具备中级 SysML 知识。可能未考虑到真实系统 SysML 建模所需的所有有用 SysML 模型来完整描述系统。

这项工作的主要实施成果包括支持 SPES 配置文件并与之兼容的功能安全和网络安全配置文件，以及构造型、标签、模型元素、辅助工具、模型检查器等。使用这些成果的原型 SysML 图表（原型的扩展 SysML 模型）也是最终产品。它们由不同层和视角中基于 SPES 的模型组成。使用视觉范式来表示项目中与功能安全和网络安全相关的工件，例如项目、评估目标、资产、功能安全概念、网络安全需求等。

总之，与基于文档的方法相比，该方法在可追溯性、部分自动化和复杂项目场景管理方面，帮助功能安全、网络安全和系统工程师更好地进行人工评估。此外，还研究了如何有效利用 SysML 模型来支持汽车行业环境中的国际标准。

列出了一些可行的未来范围和扩展。直接扩展包括：可以根据新的 IT 架构和不断变化的威胁环境（如无线传感器网络），（适度）更新 HEAVENS 方法中的项目和威胁类别。在 HEAVENS 方法中的网络安全评估中，可以实施从该方法中提出的高级需求派生的技术网络安全概念的创建和应用。从 SysML 模型自动生成文档是可行的（例如，借助 Rhapsody 发布引擎接口）。可以考虑网络威胁的额外输入和分类，包括对策。更复杂的扩展包括：确定使该方法成为学习系统的选项，例如向开发人员提出额外的潜在输入建议，并挑战人工输入决策，例如要求提供可由使用该系统的其他专家评级的论据，或者集成用于网络安全分析的基于模型的攻击树（半自动生成）。