内容提要：本文探讨了在安全关键型汽车嵌入式软件背景下使用基于模型的安全方法。我们提出了一种方法建议，即依赖于软件架构模型来构建专用的安全模型，并可以从该模型中自动导出安全分析。该方法在案例中进行了实验。

摘要

随着自动驾驶的发展，汽车在各个汽车专业领域正在经历巨大的多维创新。特别是，嵌入式安全关键系统中使用的软件数量正在快速增加从而实现新功能。因此，今天必须根据汽车标准进行安全分析来保证软件的安全。这些分析使工程师能够评估设计的安全性，并确定是否需要进行修改以满足安全目标。然而，面对当今汽车软件架构的复杂性，执行这些分析的传统方法既麻烦又有限。目前安全分析是手动执行的，结果取决于安全专家的经验。因此，它们非常主观，不能保证详尽无误。为了克服这些问题，本文探讨了在安全关键型汽车嵌入式软件背景下使用基于模型的安全方法。我们提出了一种方法建议，即依赖于软件架构模型来构建专用的安全模型，并可以从该模型中自动导出安全分析。该方法在案例中进行了实验。

1.简介

我们的社会正在经历深刻的技术和社会变革，车辆（汽车、无人机……）变得越来越自动化。它们的架构涉及多个网络物理系统，这些系统大量嵌入软件组件以实现这种自主性。在此背景下，社会需要确保和保障车辆安全，从而确保系统和软件安全。在汽车领域，软件安全分析目前基于传统的手动技术。以通用质量为导向的标准作为参考，分析的质量主要取决于安全专家的经验。安全分析并不是真正形式化的，甚至不允许部分重用，有时提供近似的安全保证。因此，在这种不断变化的背景下，有必要改进当前的工业实践，以便更好地应对社会和经济问题。

另一方面，当前工程的趋势是采用基于模型的方法。它们可以实现形式化分析、跨学科团队之间更好的沟通和协作、快速原型设计和模拟，并提高重用性。因此，使用基于模型的方法来评估软件安全似乎很有前途，因为它将有助于解决当前与安全关键软件分析相关的问题。

因此，本文的目的是探索使用基于模型的方法对嵌入式汽车软件进行安全分析的可能性。为了实现这一目标，本文首先概述了基于模型的方法，并强调了它们对软件工程和安全评估的兴趣。它将汽车软件工程领域的科学知识状态与工业实践状态进行比较，以确定软件安全分析实践中需要改进的领域。我们提出了一个方法建议，其中包括根据专门构建的安全模型自动生成软件安全分析。然后，我们给出了该提案在实际案例研究中的应用结果，该横向控制软件组件是自动驾驶软件的一部分，其作用是使车辆保持在车道上。我们最后指出了一些有趣的研究途径来进一步发展这项工作。

2.软件工程和安全中基于模型的方法

不断增长的系统复杂性需要实施开发方法来控制成本、时间和质量。传统的、以文档为中心和基于测试的方法不足以开发多学科和分布式智能系统。基于模型（或模型驱动）的方法通过以模型为中心、前端加载的工程方法来解决这种复杂性，该方法侧重于创建和利用领域模型作为工程师之间信息交换的主要手段，而不是基于文档的信息。本节快速回顾了软件工程中基于模型的方法的原则和热点，然后介绍了它们在安全分析中的使用。

2.1 基于模型的软件工程

基于模型的系统工程（MBSE）被定义为“建模的形式化应用，以支持系统需求、设计、分析、验证和确认活动，从概念设计阶段开始，一直持续到开发和后期生命周期阶段。这个定义也适用于软件工程，其中MBSE被提出作为一种有前景的软件开发方法来克服传统基于编程的方法的局限性。MBSE提倡使用建模语言以抽象的方式描述软件；它用于建模需求、功能和物理体系结构，但它还通过提供从模型自动生成不同开发工件（如代码和文档）的方法来支持仿真、代码生成和验证。

2.2 基于模型的安全评估

基于模型的安全分析（MBSA）是应用MBSE技术来支持安全分析。然而，尽管MBSE对系统的标称（非失效）功能行为进行建模，但MBSA对其故障（功能失调）行为进行建模。事实上，安全分析的目的是确定建模的系统是否存在弱点。执行它们可以分析系统组件失效是否会导致系统级别的严重失效，或者确定系统失效的可能根本原因是什么。为了实现这一目标，安全工程师从传统模型（例如FMEA或FTA）中得出结论，这些模型是他们根据设计阶段产生的可用系统规范和设计工件手动详细阐述的。

在安全工程中采用基于模型的方法包括构建系统功能失调模型，该模型显示发生失效时的系统行为（通过失效传播进行推理），从中可以得出传统的分析（最小切割、FTA和FMEA）。这尤其允许在系统架构发生变化的情况下轻松快速地生成新的安全分析，从而降低成本并提高安全分析过程的质量。

2.2.1 MBSA方法

MBSA方法可以根据两个主要标准进行分类：功能失调的模型构造和组件接口的语义。

第一个标准与定义安全模型的过程及其与系统设计模型的关系有关：功能失调的模型可以是设计模型的扩展，也可以是专用模型。我们发现了一个扩展模型的示例，其中在设计过程中首先构建了标称功能模型，为了安全分析的目的添加了失效模式。模型扩展方法的主要优点是，安全分析和系统设计模型在构造上的一致性。此外，开发和安全流程可以共享通用的建模环境、语言和工具。然而，它有一些缺点。一是它不允许系统和安全模型之间独立。在专用模型的情况下，安全工程师根据对设计文档和功能模型中可用信息的理解，构建了一个独特的“独立”功能失调模型。这种方法的主要优点是实施起来更加务实，因为它确保了独立性和关注点分离（安全和工程学科之间）。然而，其缺点之一是需要补充手段来确保与设计模型的一致性。

第二个标准与功能失调的模型语义（组件行为）和通过组件接口传递的信息类型（名义流或失效流）相关。该标准导致区分失效逻辑建模 (FLM)（使用失效流）和失效影响建模 (FEM)（使用标称流）。早期的提案采用了FEM方法，但随着学科的发展，FLM已经普及，并且大多数开创性的MBSA方法（例如FPTN、HiP-HOPS和AltaRica）都依赖于它。

多种建模语言支持MBSA。有些致力于安全，例如AltaRica、SAML或Figaro。其他是多用途建模语言（例如UML）和架构描述语言（例如AADL或EAST-ADL），它们扩展其核心语义和语法，以支持通过配置文件和错误附件进行安全分析。

2.2.2 AltaRica语言

AltaRica是一种专用于风险分析的高级建模语言，支持安全性、可靠性和性能分析。在AltaRica中，模型元素以节点表示。每个节点由状态、事件、转换和断言组成。状态是使用域来声明的。域是包含多个状态的枚举。目前有几个工具支持AltaRica：OCAS、Simfia和SimfiaNeo、Open AltaRica和AltaRica Studio。

总之，在当前的MBSA方法中，我们发现使用专用模型和FLM方法是最有趣的，因为它采用面向安全的建模；当与专用模型结合使用时，这可以确保系统设计和安全性之间的独立性（这是关键系统认证的重要标准）。对于案例研究分析，我们选择AltaRica是因为它的简单性和在系统环境中经过验证的实用性。然而，AltaRica是否能够很好地适应软件失效建模仍有待澄清。

3.软件工程和安全评估的汽车实践

3.1 基于文档的软件开发过程

汽车软件开发流程以两个标准为中心：ASPICE（质量）和ISO 26262（功能安全）。ASPICE（汽车软件性能改进和能力测定）是一项标准，为改进软件开发流程和评估供应商提供指导。ISO 26262“道路车辆功能安全”是汽车生产中电气和/或电子系统功能安全的标准。为汽车安全生命周期提供参考。它还定义了汽车安全完整性等级（ASIL），代表汽车危害程度以及在指定和实施安全要求和安全措施时应用的严格程度。ASIL的范围从A到D，其中D代表最严格的级别，A代表最不严格的级别，而QM（质量管理）则分配给对安全没有影响的项目。ISO26262分为11个部分；第6部分讨论软件级别的产品开发（更具体地针对软件工程环境）。

图1显示了软件级别产品开发的ISO 26262阶段模型。周期的左侧涵盖“软件安全需求规范”、“软件架构设计”和“软件单元设计和实现”阶段。软件安全需求通常是非形式化的，用自然语言表达，并通过Rational DOORS等工具进行管理。在软件架构设计阶段，使用半形式化建模语言（如UML）来支持设计和分析仍然相当不成熟和不熟练。因此，软件架构设计过程主要依赖于非正式模型和自然语言描述。然而，在软件单元设计阶段，Simulink等工具可有效用于原型设计、仿真和代码生成。

图1.软件级别产品开发的参考阶段模型

周期的右侧包括“软件单元验证”、“软件集成和验证”和“嵌入式软件测试”阶段。每个阶段的目的都是验证和确认相应的左侧（设计阶段）阶段是否按要求实施。如图1中的箭头所示，相关阶段之间保持可追溯性。

3.2 基于文件的安全评估流程

在当前的汽车实践中，基于文档的安全评估过程作为设计过程的组成部分进行，并按照ISO 26262进行。该过程包括在文档模板（Excel、Word、PowerPoint格式）中手动构建安全档案和安全分析。不幸的是，这些分析非常主观并且依赖于工程师的技能。它们对设计工件的可追溯性主要通过命名约定，有时还通过协作工具中的超链接来维护。最终的FTA通常是通过系统和安全工程师之间的审查和共识建立过程来产生的。即使达成共识，分析结果也不太可能完整、一致且无错误，部分原因在于用作分析基础的非正式模型。事实上，缺乏系统架构及其失效模式的精确模型，常常迫使安全分析师投入大量精力来收集有关系统架构和系统行为的信息，并将这些信息嵌入到FTA等安全工件中。在这些条件下，很难确保严格的安全分析和可追溯性。

理想情况下，这种情况可以得到显著改善，例如，如果工程师生成正在开发的系统的正式模型，然后用功能失调的模型扩展该模型，然后通过从后者导出FMEA和FTA来执行安全分析。然而，由于目前的设计模型还不够正式，无法利用，我们认为，弥合与这种理想情况之间差距的第一步可能包括手动但可追踪地构建功能失调模型。这一目标的实现构成了我们方法论建议的动机。

4.方法论建议

我们的建议包括构建一个功能失调的软件模型，从中可以自动生成最小割集、FTA和FMEA。参考第2.2.1节阐明的内容，它依赖于专用模型的使用以及失效逻辑建模技术和支持语言的使用。

该提案的概要如图2所示。它分为3个步骤：①功能失调建模，②功能到功能失调逻辑转换，以及③安全分析。

图2.所提议方法的概要

步骤①包括从软件功能架构构建一个功能失调的软件层次架构。对于每个软件组件，步骤②将软件功能逻辑转换为失效传播逻辑。此步骤允许编写每个组件的输出状态，不仅考虑组件的内部状态，还考虑输入的状态。步骤②产生一个功能失调的模型，在步骤③中使用该模型来执行安全分析，并生成经典安全模型（例如最小割集、FTA和FMEA）来自失效条件和约束。

4.1 步骤1：功能失调建模

我们建议从软件功能架构中构建一个正式的功能失调模型，以捕获软件的故障行为。

使用从软件架构文档（包含非正式设计模型及其功能描述）捕获的各种信息，我们定义并分配抽象状态（例如活动、失效或瞬时失效）和相关转换（例如失效、部分失效、停用、取消）到软件组件。我们对分配抽象状态（例如，正常、无数据、丢失、错误数据）的组件之间的接口（输入和输出）执行相同的操作。这导致了一个功能失调的模型，该模型以软件组件以及它们如何通过失效依赖链接进行连接为特征。由于其图形表示，该模型很容易理解；作为形式，它可以用于仿真、分析和证明。为了构建此模型，可以使用多种形式，包括状态/转移图以及其他专用安全建模语言，例如AltaRica或AADL。

为了说明这一建议，图3中给出了一个示例。它显示了三个软件组件A、B和C，为其分配了内部状态变量（表示它们的可能状态）。每个组件都有2种状态（正常或失效）。输入和输出也使用状态来表示（正常、无数据、错误）。在此示例中，如果软件组件B发生失效（由于其内部状态或错误输入），则其输出可以将此失效复制到C软件组件，而C软件组件又可以将其中继到失效条件。

图3.功能失调的架构图示

步骤①的完成导致了一个功能失调的体系结构，该体系结构包括软件组件（其行为是使用状态建模的）及其互连。

4.2 步骤2：功能逻辑到功能失调逻辑的转换

为了完成功能失调模型，步骤②的目标是表达组件输入和输出之间的依赖关系，这就是失效如何通过软件架构传播。为了确保功能模型和功能失调模型之间的一致性，我们建议将功能逻辑转换为功能失调逻辑。

因此，我们继续使用失效真值表。我们将(FTT)称为“失效真值表”，它系统地将正常流程（来自功能逻辑）映射到失效流程（功能失调逻辑）。为了构建失效真值表，我们首先分析组件的功能逻辑。然后使用步骤①中定义的状态（标称、错误、丢失），我们设置输入（标称、错误或丢失）并推导相应的输出（标称、错误、丢失）。重复此过程允许使用功能失调流中的输入和相应输出的所有可能组合来构建FTT。

图4.软件组件的简单功能逻辑

为了说明FTT的构造，图4提供了软件组件功能逻辑的简单示例（方框中）。这是一个简单的函数，根据标记为1和2的两个输入的值返回输出。使用我们的建议，我们将内部状态设置为输入，并向表报告相应的输出状态。我们对输入状态的所有可能组合重申这一点。

表1.失效真值表

结果如表1所示。在本示例中，如果两个输入均为“标称”，则输出也为“标称”。如果任一输入为“丢失”，则输出状态为“丢失”。否则，输出状态为“错误”。

为了获得该逻辑的可计算表达式，我们将FTT的信息转换为输出的功能失调的逻辑表达式：

这种FTT的优点是它允许改变观点（从功能到功能失调），并以语法和形式的方式表达失效行为，可用于编写输出的逻辑表达式（对于软件工程师）以及用自然语言（交流）。此外，当设计逻辑发生变化时，FTT可以相应更新，从而有助于保持一致性。从长远来看，它们还可以重复使用以捕获更复杂的逻辑。

步骤②的完成产生了由FTT产生的表达良好的失效逻辑和完整的功能失调模型，可以在步骤③中使用该模型来执行安全分析。

4.3 步骤3：安全分析

此步骤包括利用步骤②产生的功能失调模型进行仿真和生成安全分析，例如FMEA、最小割集和FTA。为了实现这一目标，将代表违反安全软件相关目标的失效条件添加到架构中。

总之，步骤③可以通过仿真和生成经典模型（最小割集、FTA、FMEA）来帮助评估系统安全性。这可以节省时间并帮助安全工程师完成任务。

4.4 讨论

该提案提供了多种好处，并显著改进了当前的实践，这主要归功于采用基于模型的方法。通过自动从功能失调的软件模型生成安全分析，如果模型发生修改，它可以轻松快速地处理新的分析。假设功能失调模型是根据功能模型正确建立的，该方法可以防止由于安全分析师的潜在解释而在手动构建FTA或FMEA时引入偏差。为了最好地执行功能到功能失调的模型转换，通过失效真值表确保了模型之间的一致性和可追溯性。此外，该方法允许在设计发生变化时维护安全分析。

然而，该提案仍然有一些局限性。首先，如果软件组件的某些行为属性已经在设计模型中得到阐明，则可以改进手动建模。在这种情况下，可以考虑部分导入。这突出了在设计方面改进基于模型的实践的需要。第二个限制在于通过失效真值表进行手动逻辑转换，如果使用基于一种自动模型转换的自动化形式，则可以改进这一点。

5.案例研究

在汽车中，高级驾驶员辅助系统(ADAS)和自动驾驶(AD)实现基于软件的功能，帮助驾驶员并改善他们的驾驶体验。所选案例研究是AD软件系统的一个子系统。如图5所示，它由三个主要软件组件组成：脱手检测(HOD)、纵向控制和横向控制。本案例研究是更广泛系统的一部分，我们还考虑了必须包含的系统的其他组件（例如状态输入），以执行分析并根据其环境定位软件组件。

图5.案例软件架构概要

在自动驾驶级别1（对应于辅助驾驶）下，即使AD功能已激活，驾驶员仍需要将手放在方向盘上。在这种情况下，脱手检测（HOD）的作用是检测驾驶员的手是否离开了方向盘。为了确保有效可靠的检测，使用了两种冗余策略，一种是基于电容传感器的电容式脱手检测，另一种是基于驾驶员施加在方向盘上的力的测量值的基于扭矩的脱手检测。这两种策略都为横向和纵向控制提供了统一的HOD状态。纵向控制管理加速、减速和制动。横向控制使车辆保持在车道上。它参与关键功能、转向和用户警报。其激活取决于HOD和纵向控制状态，以及通过状态输入（向HOD、纵向和横向控制提供数据的软件组件）的各种环境和车辆数据（车道、方向盘角度、车速）。

5.1 选择支持方法的工具

让我们记住，我们选择使用专用的功能失调模型和FLM方法。这使我们能够对系统有一个更加以安全为导向的观点，并加强独立性和关注点分离（功能特性与安全考虑）。

我们选择基于AltaRica的解决方案是因为它的简单性和形式方面。AltaRica允许通过明确定义的语义来表达功能失调的行为。此外，该语言已被证明在许多情况下都很有用（例如航空系统安全评估）。在基于AltaRica的工具中，我们选择了SimfiaNeo，因为它具有更具创新性的功能和基于eclipse的友好用户界面。SimfiaNeo具有内置的步进模拟器，提供FMEA生成器和内置模型检查器，用于直接从功能失调的架构生成最小割集和FTA。

5.2. 应用方法论

然后，我们应用了该方法的不同步骤：首先，在步骤①中，我们定义并建模了软件组件状态和基本失效，然后在步骤②中，我们使用将输出连接到输入以及内部状态的逻辑表达式对失效传播进行建模；最后在步骤③中，我们使用由此产生的功能失调的架构来执行安全分析。

5.2.1 步骤1：功能失调建模

我们使用AD软件功能架构（文档和非正式模型）中的信息来构建基本的功能失调模型。首先，使用SimfiaNeo图形建模界面，我们用模型块对软件组件进行建模。

图6.案例研究模型的顶层视图

然后，使用AltaRica，我们定义了组件的域（参见第2.2.2节）以及每个组件的输入/输出、状态和相关转换（在AltaRica中表示为事件）。该模型的顶级视图如图6所示。红色矩形界定了案例的范围。

我们现在需要使用失效传播逻辑来完成这个功能失调的模型，以便能够执行安全分析。

5.2.2 功能到功能失调的逻辑转换

逻辑转换用于协助构建失效传播并确保功能失调模型与设计模型更好的一致性。为此，使用FTT将从Simulink模型检索的逻辑转换为Al-taRica逻辑。

图7说明了这种转变。功能逻辑来自HOD软件组件的子组件。从功能角度来看，该逻辑根据两个信号（HandsOff和HandOff_mirror）是否相等返回状态（HODConsolidationHandsOn）。输出(HandsOffState)捕获此状态。

图7.使用失效真值表将功能逻辑转换为功能失调逻辑

从功能到功能失调的逻辑转换的目标是从功能的观点转向功能失调的观点。为此，我们将状态（在步骤①中预定义）分配给输入（在功能逻辑上），并在FTT上写入相应的输出状态。我们对所有可能的输入状态组合重申此过程。这将创建相应的失效表，其中包含所有可能的输出状态，如图7所示。使用FTT，我们现在可以在AltaRica中编写（相应功能失调的砖块的）输出表达式。

对AD的所有软件组件重复此步骤。这些表可以用作模板来对更复杂的组件和系统进行建模。这有助于通过重复使用来节省时间。总体而言，步骤②完成了步骤①中启动的功能失调模型。因此，功能失调模型与功能模型更加一致，可以用于步骤③中的安全分析。

5.2.3 步骤3：安全分析

此步骤包括使用SimfiaNeo模型检查功能从功能失调模型生成经典安全模型，例如FMEA、最小割集和FTA。为了实现这一目标，我们使用了步骤②中的功能失调模型以及安全生命周期早期阶段确定的失效条件。我们继续通过软件组件输出的直接连接或通过AltaRica中表达的断言组合，使用AltaRica观察器添加失效条件。完成此操作后，我们现在可以进行安全分析。首先，我们进行了仿真。然后我们直接从功能失调的架构生成FMEA。之后，我们计算最小割集，从中我们能够立即生成FTA。

为了执行仿真，我们使用SimfiaNeo内置模拟器。它使我们能够交互式地评估系统的功能失调行为。为此，我们手动触发基本失效事件（在组件级别），并通过颜色变化观察它们对其他组件和失效条件的影响（之前通过AltaRica观察者添加）。

SimfiaNeo可以直接从软件功能失调模型自动生成和导出FMEA表。考虑到软件架构的复杂性和多种基本失效（在组件级别），这会导致大量的失效模式（在FMEA表中）。因此，我们发现在我们的案例中，与更紧凑和综合的最小削减和FTA相比，FMEA表的相关性较低。然而，虽然生成FMEA是立即的，但生成FTA需要（以某种方式快速且简单的）配置。在创建FTA之前，首先生成最小割集。为了生成最小切割，我们指定顶部事件的失效条件、（计算的）最大阶数和一些其他参数，例如生成类型（随机、排列或组合）。我们还可以在配置中添加一些约束，表示我们想要检查的任何条件（例如“无单点失效”）。计算启动后，它会返回一个表（如图8所示），其中列出了基本失效事件（“元素”列）、顺序（对顶级事件做出贡献的基本事件数量）及其概率。

图8.横向控制丢失最小割集

FTA基本上包含与最小割集相同的信息，但具有以更直观的方式呈现它们的优点。图9显示了FTA的示例。它由导致ADAS“横向控制丢失”功能的最小事件集构建而成。

图9.失去横向控制状态故障树

树的顶部是顶部事件（横向控制丢失）。在叶子中，我们看到基本的失效事件及其概率（在我们的例子中没有用）。FTA以图形方式显示横向控制丢失可能是由于横向控制组件(Lateral_Ctrl.failure)的单一失效或HOD(HOD.HODStateFinal)与Fusion(Fusion.failure)或Statut Input(Status_IN.failure）软件组件失效。此外，FTA可用于捕获ASIL分解中通过功能视图看不到的不一致之处。例如，横向控制组件被评为ASIL B，而此FTA中的贡献基本事件之一(Status_IN.failure)不承担任何ASIL要求。因此，对于给定的安全目标，使用FTA可以有效检查触发事件组合的ASIL是否不一致。

这一步展示了如何从我们在步骤①和步骤②中构建的功能失调的架构中生成经典安全模型。

5.3 案例研究结论

案例研究的结果表明，使用我们提出的方法，可以在汽车行业应用基于模型的软件安全分析方法并从中受益。它还展示了使用基本和实用工具功能（例如工具中提供的模拟和失效原因和后果）的有用性和效率。此外，这种方法通过基于工具的传统安全分析生成，使工程师更容易进行安全分析。总体而言，该方法通过允许工程师专注于获得正确的模型并花费更少的精力来生成分析来增强安全性，从而提高这些自动生成的分析的质量。一键生成FTA的可能性很有趣。事实上，如果软件功能模型发生变化，功能失调的模型可以更新，并且无需额外的努力即可重新生成FTA。这意味着应该维持功能失调的模型。然而，由于功能失调的模型构建和逻辑翻译是手动完成的，因此存在一些局限性。首先，手动建模和逻辑转换使得该方法在大型复杂软件系统中的应用变得不切实际。这种手动建模方法当然可以改进，以确保我们的模型与设计模型更好的一致性。其次，AltaRica语言是面向系统的，缺乏针对某些类别的软件失效的语义。表达和仿真与时间和价值相关的失效是很困难的。例如，我们无法建模和观察诸如横向控制暂时停用或值超出范围之类的失效。在这方面，我们认为需要重新评估AltaRica的使用。尽管如此，所提出的方法满足了我们当前的需求，因为它比手动技术有了明显的改进。

6.观点与结论

本文提出了使用MBSA进行汽车软件安全分析的方法建议。它包括使用兼容的语义和语法，从功能性高级软件名义架构构建汽车软件功能失调的架构，并将功能逻辑转换为功能失调的逻辑。然后，根据这个功能失调的模型，安全工程师可以自动生成最小割集、FTA和FMEA，以供解释并在需要时作为安全证明。我们将此方法应用于涉及SimfiaNeo和Al-taRica的使用的真实工业案例研究。我们得出了该方法的可实施性和有用性的结论。与我们使用的语言和工具相结合，它带来了附加值并改进了当前的手动安全分析实践。我们发现的局限性将在未来的工作中得到解决。这将包括改进功能失调的建模，为此我们将考虑模型构建和逻辑转换的部分自动化。我们还将探索对软件失效具有更好语义的语言（例如AADL EMV2）。最后，我们将致力于将所提出的基于模型的软件安全分析方法与基于模型的软件开发相结合，以确保更好的一致性和更高的安全分析质量。

会议更多信息及洽谈，详询“牛小喀”微信：NewCarRen

作者：牛喀网专栏作者
牛喀网文章，未经授权不得转载！