摘要：

行业从基于文档的系统工程到基于模型的系统工程方法的持续转变揭示了对验证和确认系统的新方法的需求。用于测试实际系统的传统方法变得越来越昂贵。基于模型的环境可以显著减少测试，最重要的是可以减少验证和确认过程的成本。它允许通过应用各种技术对系统模型进行测试，例如模拟、分析、回顾、实物模型等。然而，目前很少有详细说明如何进行整个系统的验证和确认（将其组件和子系统计算在内）的方法。本文提出了一种基于系统建模语言(SysML)开发的系统模型并按照MagicGrid(以前称为MBSE Grid)框架执行系统验证和确认的方法。该方法涵盖了整个系统的测试活动，从根据系统需求验证最低层级模型的系统元素，到最后根据涉众的需求验证整体系统。

一、引言

验证和确认(V&V)是独立的过程。验证的目的是为了提供一个系统或系统元素满足其指定的要求和特征的客观证据。确认过程的目的是提供客观证据，证明系统在使用时满足了其业务或任务和涉众需求，在其预期的运行环境中实现了预期的用途。两者一起使用，是系统测试的关键步骤。

测试实际的系统是昂贵的，不仅体现在无法实现对现实条件的测试，而且在不具有成本效益的情况下也是如此。基于模型的系统工程(MBSE)提供了一种更有效的方法来显示理论合规性。它允许在特定的条件下使用模型或实物模型(而不是实际/物理系统元素)进行模拟测试。尽管听起来很有希望，但是在基于模型的环境中系统架构并不能自动测试系统的功能。在系统工程(SE)中有一个常见的误解，认为系统建模语言(SysML)足以实现MBSE的承诺。(Silingas et al. 2009)指出建模语言只是语言本身，必须与方法论相结合才能发挥作用。在MBSE环境中，诸如验证和确认之类的测试活动在很大程度上依赖于用于开发系统架构的方法。因此，为特定的环境找到正确的方法是非常困难的，或者说在最好的情况下方法和框架需要裁剪和定制。

本文提出了一种新的基于模型的V&V方法。该方法涵盖了系统测试活动，从针对系统需求的最低层级模型系统元素的验证开始，一直到针对涉众需求的整个系统的验证。该方法与SysML语言和MagicGrid(以前称为MBSE Grid)框架一致。该方法通过将V&V支柱引入现有支柱并演示它们之间的相互关系来扩展框架。最后以车辆模型为例，验证了所提方法在系统工程全生命周期中的有效性。

本文结构如下：第二部分对相关工作进行了分析；在第三部分中给出了所提出的方法；在第四部分中，描述了所提出的方法的应用；在第五部分中，提出了已取得的成果、结论和今后的工作方向。

二、相关工作

(Hazle et al. 2020)分析了系统、软件和需求工程中关于验证和确认的文献。本文研究了它们与MBSE中使用的SysML模型的相关性。作者利用他们的文献综述、经验和MBSE工作组(INCOSE UK MBSE WG, 2019)的意见，编制了一份他们认为应该用于建模V&V的有效和稳健方法的技术和原则列表。核心原则之一是模拟和参数求解的重要性。通过模拟验证模型行为通常比通过检查描述性视图更容易(debbabe et al. 2010)。在应用模拟时，使用MBSE方法来取代分离的规范和模拟的优点是，由于所有的工程工件都在同一个模型中，它允许从涉众需求到被模拟的元素的可追溯性(Stevenson et al. 2018)，从而改进验证和影响分析。

虽然V&V方法和MBSE方法可以单独分析，但相比之下与我们的工作最接近的是使用V&V方法和MBSE方法的组合。这种方法可以直接比较等效工作，不会使研究过于复杂。下面将分析支持V&V活动的MBSE方法:面向对象的系统工程方法(OOSEM)，用于系统工程的IBM Rational Harmony，以及UML测试概要文件。

• OOSEM

在此方法中，验证和确认系统活动验证系统设计是否满足系统需求，然后验证这些需求是否满足涉众的需求。为此，相关人员制定了验证计划、流程和方法。测试用例和相关验证过程的主要输入是系统级的用例、场景和相关的需求。验证系统可以使用前面描述的用于对操作系统建模的相同活动和工件。需求管理数据库在此过程期间更新，以跟踪系统需求和设计信息到系统验证方法、测试用例和结果(INCOSE, 2015)。

OOSEM提供了在执行V&V时需要执行哪些步骤的清晰流程;然而，它没有定义在实践中实现它的方法。

• 用于系统工程的IBM Rational Harmony

IBM方法涵盖了与实时嵌入式系统和软件相关的验证部分。在模型驱动的系统开发环境中，从系统工程过渡到子系统开发的关键工件是可执行模型。Harmony/SE Deskbook推荐使用模型执行的交互式验证，包括模型动画，以及和预期行为相关的“as-is”行为的可视化比较。集成测试场景将是每个子系统的一部分。这些测试场景可用于根据需求验证已开发的子系统(Hoffman, 2015)。

Harmony方法被证明是侧重于面向工具的，并且用于执行V&V的建模语言结构没有被清楚地描述。此外，该方法是面向嵌入式系统的，并且没有描述如何在系统层次结构的更高级别和不同类型的系统中进行测试。

• UML测试概要(UTP)

UTP是UML生态系统的一部分，因此，它可以与该生态系统的其他概要文件相结合，以便将测试相关的工件与其他相关的系统工件相关联，例如，需求、风险、用例、业务过程、系统规范等。这使得需求工程师、系统工程师和测试工程师能够弥合不同工程学科之间的沟通鸿沟(OMG, 2019b)。UTP提供了一组概念来描述测试计划、测试体系结构、测试行为和数据。相反，SysML只有一个用于测试的概念，称为测试用例。在SysML中，测试用例被定义为“验证需求被满足的方法”(OMG, 2019a)。它有一个名为verdict的返回参数，由枚举Verdict Kind输入。注意这与UML测试概要是一致的。

尽管UTP是一种定义明确的语言，可用于捕获测试概念，但它不是一种方法论，也不是一种方法。UTP的应用取决于在特定项目或组织的环境中用于系统工程的方法。

对相关工作的分析有助于我们理解V&V在当今基于模型的工程环境中是如何处理的。它还有助于确定在MBSE上下文中使用的核心原则、模型执行的重要性，以及可以通过我们建议的方法来解决当前存在的问题。

三、建议的方法

本节介绍一种使用SysML模型执行系统验证和确认活动的方法，SysML模型是根据MagicGrid框架定义的建模工作流开发的。在此基础上，我们提出了支持V&V框架的相关扩展。

1.MagicGrid方法论介绍

MagicGrid是一个纯粹的基于SysML的MBSE框架(Mazeika et al. 2016)。框架的结构可以描述为一个2-D网格，如图1所示。

网格的行表示不同的抽象层，也称为域：问题域、解决域和实现域。每个组织都必须处理它们，除非他们开发的系统非常小和简单，例如，一些没有任何嵌入式软件的机械组件。在复杂系统开发的情况下，它们是不可避免的(Morkevicius et al. 2017)。

网格的列代表SysML模型的不同方面，也被称为四大支柱(Friedenthal et al. 2008)，它们是需求、结构、行为和参数，以及最近添加的安全和可靠性支柱。

图 1 MagicGrid方法论框架

位于特定行和列交集的单元格表示视图，它决定在访问特定单元格时应该使用哪些SysML图和元素来捕获信息。访问单元格的顺序由MagicGrid框架的建模工作流定义。它是基于ISO 15288中定义的SE最佳实践和技术流程(Morkevicius et al. 2020)。

2.基于MagicGrid扩展的验证与确认

到目前为止，MagicGrid框架已经适用于V模型左侧的SE活动，支持从涉众需求提取到系统组件的高级(逻辑)设计的系统开发。然而，它并没有提供太多关于如何执行V&V活动的信息。

图2说明了如何扩展框架以支持系统早期的V&V。这种V&V在开始系统实现之前进行，对于检测设计早期存在的问题非常有用。早期的V&V不仅适用于在现实条件下无法实现系统测试的情况（如航天器、卫星），而且适用于成本不高的情况。

由于早期V&V中物理系统不存在，其解决域模型由遵循MagicGrid框架而形成，并且作为两个活动的输入。解决方案域模型指定了所选系统配置的精确逻辑体系结构和高级（逻辑）设计，包括UI模型。因此，如果它通过了针对系统需求和涉众需求的V&V，那么系统也可以被认为是被验证和确认的。

• 验证

验证方法是自底向上的：从组件级别逐步执行到系统级别（在本文中，组件级别被认为是包含系统结构原生元素的最低级别细节）。

图 2 MagicGrid扩展的V&V活动

一旦组件模型完成，就可以执行第一次验证迭代。一旦这些模型通过了针对组件级需求的验证，它们就可以在子系统级进行集成。需要注意的是，可以为每个组件提出各种设计解决方案;同时在子系统级别上可以产生多个配置（或候选解决方案）模型。子系统模型可以根据子系统级别的需求进行验证。在这些模型通过验证之后，就可以在系统级别集成它们了。与子系统级一样，可以构建整个系统的多个配置，这些配置随后根据系统级需求进行验证。为了评估可选配置并在每个细节级别为物理实现选择首选架构，将执行权衡分析(Morkevicius et al. 2021)。

根据MagicGrid的定义，不同层次上的模型通常由不同的工程团队甚至组织创建。因此，组件和子系统的验证可以彼此分开进行。

每个细节级别上的验证都是通过使用测试用例来执行的，因为单个测试用例允许用户检查相关的模型或其片段是否满足相关的需求。该信息能作为测试用例的判决并被捕获。

可以在模型中以SysML序列、活动或状态机的形式捕获测试用例。每个测试用例必须通过利用«verify»关系与相关的系统、子系统或组件级需求相关联。系统的早期验证可以通过执行其模型来实现自动执行。

为了执行系统的早期验证，可以在解决方案域模型中的每个系统层次结构级别应用相同的验证方法。如图3所示，执行早期验证的典型SysML模型包括：

• 验证系统/子系统/组件的模型。它在这里表示为N级模型块，状态机作为它的分类器行为。在这里和图3中其他地方的模块名称中，级别N可以用系统、子系统或组件替换。
• 系统/子系统/组件必须验证的要求。这里表示为N级需求，并将测试指定为其验证方法。
• 分析上下文。这里表示为N级模型分析模块。分析上下文模块负责在系统层次结构的特定级别上编排测试用例和执行行为模型。它包括:(i)验证模型/和(ii) 测试模块，它表示通过向适当的模型元素发送外部触发器来执行验证的人员。如图3所示，外部触发器可以是消息提供的信号，并作为可执行测试用例的一部分。
• 测试用例以捕获用于验证的步骤。它在这里表示为在模型中捕获的N级模型测试用例测试用例，并使用SysML序列图的基础结构进行显示。由于测试用例是由分析上下文模块所拥有的，相关序列图的生命线表示参与这个分析模块的两个模块:(i)要验证的模型;和(ii)测试模块。测试用例有一个名为verdict的参数(如下图所示)，如果模型通过了测试用例的步骤，它就被设置为通过，如果模型没有通过，它就被设置为失败。当判定通过时，可以认为该模型满足了相关要求。

图 3 使用MagicGrid执行早期验证的典型模型

• 确认

一旦验证了系统配置模型，就该根据涉众的需求来验证它了。作为系统架构的一部分，UI模型也可以用于此。如图4所示，UI模型(或UI原型)可以通过使用UI原型概要文件来生成，该概要文件(除了SysML概要文件之外)扩展了UML 2元模型，以支持UI原型建模的原型(Silingas et al. 2010)。此外，UI原型配置文件允许用户将UI模型集成到系统架构模型中，也就是说，将它们与捕获系统架构相关概念的SysML模型元素联系起来。标准的SysML / UML关系，例如“实现”或“跟踪”，都可以用于此。

UI原型配置文件是独立于实现的，包括最小的UI元素集，以及它们的属性，以最终满足最常见的UI原型需求。这些元素扩展了某些UML元类，如Component或Class，并按类型分组到单独的包中，如图4所示(Silingas et al. 2010)。就像UML或SysML元素一样，UI模拟元素可以在语义上相互关联。元素表示取自Java Swing外部库。用户界面建模图是基于UI Prototyping概要文件，并使用典型的工作流来创建特定领域的建模环境(Silingas et al. 2009)。

图 4 UI原型建模

UI原型可以应用于工程项目的各个阶段。例如，它可以用来促进问题域分析，作为与涉众沟通的一种手段。当应用MagicGrid时，UI模型可以用来验证系统架构。与解决方案域模型中逻辑系统体系结构元素相关的UI模型也必须与相关涉众的需求相关。如图5所示，可以为此使用«refine»关系。UI元素与体系结构元素相关。

图 5 使用MagicGrid进行确认的典型模型

四、案例研究

本文的这一部分提供了一个案例研究示例来说明所提出的方法。现代汽车是一个复杂的系统，它包含了许多内部系统元素，这些元素之间错综复杂地相互作用。不同部分的整合是一个至关重要的活动；因此，该系统可以作为一个合适的例子来演示所提出的系统V&V方法。

在案例研究示例中，汽车模型是使用SysML语言和MagicGrid方法开发的，大多数模型创建活动没有公开。然而，理解所提出的兴趣系统(SoI)的结构及其内部组件仍然很重要。出于这个原因，我们利用图6来显示汽车结构。

图 6 在SysML块定义图中显示的汽车结构

图6显示了一个SoI结构，它被分为五个组成级别，从表示汽车单元的级别0开始，到描述SoI组件的级别4结束。由于现代汽车系统的范围和与之相关的范围，不可能公开所有必需的系统验证活动。因此，本案例研究示例分析了汽车内部系统的一小部分。

1.最低组成级的系统验证

所提出的方法的应用从第二级分解开始，如图6所示。在这个层次上，传动系统被选为系统验证的目标。该车辆系统本身是一个复杂的系统，由多个内部系统组成。在本文中，假设传动系统的内部子系统通过了它们在第三和第四级组成上的系统验证活动。因此，我们的主要注意力是针对传动系统的验证。

对于传动系统来说，传动控制器是最重要的元器件之一。如今，传动系统组件采用集成电路实现，其中软件代码负责该部分的正确应用。

由于阅读和理解软件需要专门的技能和知识，因此对其进行抽象化是个较好的选择。案例研究模型通过以SysML状态机图的形式分析变速箱控制器的行为来实现这一点，如图7A部分所示。图7B部分所示的SysML状态机图描述了另一个传动系统组件（离合器）的行为。每个传动系统元素（图6）都可能具有类似的行为描述，但鉴于研究的颗粒度而言，本案例研究示例忽略了这一点。验证工作也将集中在离合器和变速器控制器系统。

 为了达到目的，车辆传动系统被确定为自动手动类型。该系统是自动变速器和手动变速器的混合，具有两者的特点。例如，与手动变速器类似，自动手动变速器有一个离合器组件，需要在换挡过程中接合。然而，在这种类型的变速器中，离合器的接合不是由驾驶员完成的，而是由传动系统的电机组件完成的。因此，需要一个经过验证的系统，以确保变速器控制器的控制逻辑与正确的离合器操作保持同步。

                             A                                         B

图 7 A.传输控制器在SysML状态机图中的行为描述;

B.离合器在SysML状态机图中的行为描述

为了验证系统行为集成，我们创建可执行的测试用例。测试用例应该定义一个先验的系统行为。测试用例的失败可能潜在地暗示了不完整的系统行为定义，同时暗示了在这个组合级别上存在不恰当的系统验证。图8A部分显示了用于验证的一个可能的测试用例。在这里，测试用例检查变速器控制器系统上的驾驶模式更改是否会导致正确的离合器系统行为。为了实现这一点，测试人员将外部刺激“Reverse”作为消息发送给Transmission Controller元素。在接受消息后，传输控制器元素将其状态从“停车”更改为“倒车”。变速器控制器系统上的状态变化需要传递到离合器系统，以便将其机械地连接到变速箱系统，并允许传动系统的驱动模式进行更改。因此，离合器也应该改变其状态从“关闭”到“连接”。生命线表示的元素处于失败状态表示了测试用例的失败。这是通过案例研究系统模型中的状态不变量来验证的。需要注意的是，序列图对于测试用例定义的使用并不是唯一的选择。其他的模型元素也可以被使用，这将需要相关人员利用不同的测试用例来检查相关设计和技术了。

这种方法的一个潜在限制是需要手动定义测试用例。由于系统模型中有许多可用的驾驶模式更改排列组合，所提出的测试用例因此也被简化为有限的驾驶模式更改集(图8 A部分)。尽管我们认为这超出了我们提议的方法的范围，并且我们没有探索从SysML模型中如何自动生成测试用例。然而，为了对传动系统进行完整验证，模型应该追踪所有的驾驶模式更改。

图8B部分介绍了需求和测试之间的验证关系，并按照所提出的方法以显示逻辑和可跟踪的链接。由于所提出的方法是可执行类型的，因此需要一个模块来编排模型执行。在图8B部分中，“最低级别测试用例”模块通过关联验证SoI(传动系统)和外部刺激(测试块)模块来实现这一点。

                      A                                        B

图 8 A.使用SysML序列图进行第二层级测试用例描述;B.测试用例与需求的链接

测试用例验证的裁决应保留。这是通过使用当前系统模型中的值属性元素(testResult)来实现的。如果有必要为同一个SoI运行多个测试用例，那么应该使用几个值属性来存储每个测试用例验证结果。最后，多个测试用例验证结果可能具有不同的判决值，并且可能需要对其进行仲裁，因此提出了值属性与要求之间的满足关系作为一种选择。

图 9 多个测试用例执行结果显示在实例表中

图9显示了实例表的用法，以实例元素的形式显示多个测试用例结果。值属性“testResult”的Fail代表一个测试用例失败，Pass标志着成功。在我们的方法中，Pass表示在这个组合级别上系统被正确验证。

 2.中间组成级的系统验证

在SoI结构的中间层次上，案例研究的示例将针对动力总成系统，该系统由两个子系统组成:电源和传动总成(图8)。在这里，所提出的验证方法与最低系统组成层次上的方法相同。首先，使用SysML序列图(图10 A部分)定义一个测试用例。该测试用例检查当Engine系统的参数改变时，Drivetrain系统是否改变了驾驶模式。具体来说，传动系统部分传动控制器应该监控发动机油门位置和发动机转速传感器的值。如果监控值符合系统要求中指定的预定义驱动模式更改的临界点(图10 B部分)，那么传动控制器系统应该发生驱动模式更改。在测试用例中，使用状态不变元素实现了正确的驱动模式选择。状态不变量的失败将导致测试用例的失败。引擎参数更改由外部测试人员调用，该测试人员向已验证的系统元素发送同步消息。在接受消息后，接收方调用指定操作，该操作更改了模型中所需的变量，通过操作我们可以复用系统变量的更改模式。

                 A                                          B

图 10 A. 使用SysML序列图进行中间层级测试用例描述;B.中间层级的测试用例与需求的链接

根据所提出的方法，需求被链接到测试用例元素以实现可跟踪性，并且为测试用例和SoI行为引入了一个模块(中级测试用例导体)。对于执行结果的存储，我们需要一个变量。因此在SysML模型中，我们使用值属性来存储结果(图10 B部分)。正如在最低的系统组成级别中，测试用例执行的通过表示系统行为被成功验证(图9)。

3.最高组成级的系统验证

在案例研究的最后一部分，我们将探讨SoI的最高组成级别。在这个层次上，汽车被认为是一个单一的单元，系统验证应该关注所有的车辆系统，并将它们纳入一个工作实体。系统验证过程与之前的方式相同:测试用例的定义，测试用例与需求的链接，可执行模型的准备和执行。

在最高组合级别上，本案例研究示例探讨了驾驶员如何通过电子杠杆模块将驾驶模式的更改调用为传动系统的档位更改(图11 A部分)。由于这两个系统位于不同的车辆结构上，因此确保它们的行为同步对于系统的正确验证非常重要。

对于测试用例定义，使用了SysML序列图。在这里，状态不变量是一个确认测试用例正确性的元素，如果系统无法处于所要求的状态将导致测试用例的失败。与前面一样，相关的需求被链接到测试用例中以达到可追溯性的目的，并且引入了一个负责测试用例和SoI行为的模块(图11 B部分)。

图 11 A.用SysML序列图描述最高层级的测试用例;B.最高层级的测试用例与需求的链接

由于与现代汽车相关的系统数量众多，在本文中不可能显示汽车系统的所有架构并验证所有的测试用例。出于这个原因，案例研究样本将系统验证限制为测试用例的成功通过，如图11A部分所示。然而，汽车系统模型理应覆盖所有的测试用例并完成验证。

此外，UI元素可以用于协调不同的系统行为，并作为验证系统模型的工具。图12A和B部分表示案例研究示例中的UI使用情况。图12 C部分显示了当驾驶者以SysML要求的形式借助电子杠杆模块改变驾驶模式时，在仪表盘上显示正确档位的必要性。所提出的用户界面也是用于汽车仪表盘和电子杠杆模块系统的抽象和可视化。然后我们使用Refine关系将它们链接到需求。由于UI是实时模型执行期间的交互式窗口，它们可以显示系统模型变量、状态或其他元素值，因此，模型用户可以使用它们作为系统模型验证的一种手段。在案例研究样本中，模型执行期间未能显示正确的驱动模式意味着涉众需求验证的失败。

图 12 A.仪表盘GUI;B.电子杠杆模块GUI;C.说明在仪表盘显示驾驶模式的必要性的需求

最后，用于系统验证的UI可以与测试用例验证一起部署，或者将其作为一种替代方案。然而应该注意到的是，与测试用例验证方法相比，这是一种不那么严格的方法，并且该方法依赖于建模者的经验。

五、结论以及未来工作

通过对相关工作的分析，目前在MBSE环境下的V&V领域的科学研究还很少。目前存在一些针对V&V的MBSE方法，如OOSEM和IBM Harmony，但是它们都没有清晰地、逐步地定义V&V元素与系统架构的关系，以及系统元素层次结构不同层级的需求。

我们所提出的方法清楚地定义了SysML在MagicGrid方法中基于模型的V&V的应用。在实际的车辆模型中，系统元素层次结构的每个层级都证明了该方法的适用性。此外，该方法使用了纯SysML，不会因扩展标准语言而增加额外的复杂性。如果有必要，应用该方法的组织可以扩展所提议的方法以支持其所需的术语。

一辆现代汽车（或任何其他现有系统）都具有相当大的复杂性。手动创建测试用例可能是一项费力的任务，可能会导致在测试用例的定义中出现无意的错误。因此，在使用所提议的方法验证系统时，事先解决这个问题是很重要的。

来源  https://incose.onlinelibrary.wiley.com/doi/10.1002/inst.12429

原文  System Verification and Validation Approach Using the MagicGrid Framework