来自汽车、铁路、航空电子、国防、航天、能源或医疗等关键安全领域的所有行业标准，都将需求置于开发和验证流程的核心，其中需求工程工具通常用来管理以文档为主的需求规格的生命周期。为了克服纯文本需求规格在处理系统日益增加的复杂性方面的限制，我们推出了基于模型的系统工程（MBSE）[1]和基于模型的设计（MBD）[2]工具，并在大多数行业中进行了大规模的采用。仿真显然是成功实现上述需求的关键因素，因为其为早期分析和验证打开了机遇之门。

然而，基于模型的系统工程和需求工程工具之间的耦合仍然十分微弱。当前的行业实践通常仅限于需求和模型之间的可追溯性流程。从仿真的角度来看，需求的执行语义基本上还尚未得到利用，尽管我们已在这个领域开展了一系列的研究工作[3]。

需求在环仿真[4]旨在将实时功能需求转变为形式化的，但仍然是文本的，可执行的模型。这些模型可以作为更大模型的一部分进行整合，通常是作为原理图捕获的系统架构，并与其他行为模型协同仿真。执行引擎依赖于约束求解技术来生成离散时间仿真，其中我们通常将需求解读为信号上的约束。

需要值得注意的是，需求和其他行为模型通常携带互补信息，因为它们捕获了不同的抽象级别。举例来说，安全需求可能会指定系统应该做什么，例如，在给定的延迟内对环境中的某些STIMULUS做出反应。因此，需求通常是部分的且非确定性的。相比之下，传统的行为模型，如状态机等，可能会更专注于如何进行反应，从而以更确定性的方式确保这种反应延迟。

需求在环仿真的应用包括两个方面。一方面，形式化需求可以作为系统的许多不同行为的生成器，以调试和验证在开发流程的早期阶段的"内容"。另一方面，一旦模型可用，无论是详细的需求规格还是实现模型，相关需求都可以作为观察者用来开展测试和验证的"方法"与"工具"。

在本文中，我们介绍了需求在环仿真的基本要素，并且我们在起落架客户案例[5]中阐述了它的使用，该案例提供了一个具有代表性大小和复杂性的现实系统。我们展示了识别错误的，缺失的和冲突的需求以及验证可执行模型与其需求的能力。由于起落架的需求规格同时使用了文本需求，状态机以及原理图的混合信息，因此我们利用STIMULUS工具捕获了完整的需求规格，并探讨了其与第三方工具（如需求管理，MBSE或MBD工具等）的集成。

需求在环仿真致力于解决动态系统的功能需求。起落架客户案例中的一个典型示例是以下的高级需求：“当操作杆命令为放时，所有起落架均应在15秒内完全展开，并且所有舱门应关闭。”此类需求通常描述了系统随时间变化的逻辑和数值属性的组合。它们与非功能需求（如可用性或可靠性等）形成鲜明对比，后者并不受需求在环支持。

进行需求在环仿真的前提是能够捕获此类需求的精确语义。为此，STIMULUS提供了一套预定义的句子模板，可以自由组合以构建文本需求，如图1所示。句子模板可支持多种语言版本，用户可以扩展预定义模板集以适应特定领域的需求。

图1. 使用模板需求规格化的起落架系统需求

模板参数既可以参考标量表达式也可以参考语句，例如，“当......时”模板的条件和<主体>参数。每个模板的语义都通过等式和/或状态机进行形式化定义。例如，“是”模板定义了多态的数学等式，而“当......时”模板定义了状态机，当条件为真时，激活<主体>语句，如图2所示。

图2. “当......时”模板的语义

执行需求的形式化语义的能力是需求在环仿真面临的主要挑战。STIMULUS的执行引擎源于Lutin[6]，这是一种原创语言，其完美结合了约束和正则表达式，以指定通用测试场景，以及Lurette[7]，这是一种执行引擎，可以从Lutin模型自动生成许多测试向量。此外，作者还指出了在需求工程中使用此类工具的巨大优势[12]。

在此背景下，仿真意味着生成满足需求约束的执行追踪，即可能的系统行为。由于需求规格本质上通常是部分的，因此并非确定性的，这样的行为并非唯一。运行多次仿真将产生多种不同的行为，这对于测试自动化至关重要，相关内容将在第4节中进行深入探讨。

图3显示了图1中由STIMULUS生成的高级需求可能的执行追踪。由于我们并未指定起落架的伸出序列，舱门和起落架可能会经历不同的状态（定义为枚举类型），但一旦HandleCommand输入切换为放，舱门和起落架在预期的延迟内达到他们预期的状态（分别为关闭和展开）。

本文的一个主要目标是展示如何将这个高级需求细化为更低级别的需求，这些需求将指定起落架收回和伸出序列的详细信息。

图3. 图1中需求的可能的执行追踪

尽管需求的声明性质可提供如原子性、可组合性或可测试性等的众多优势，但是，声明性语言通常更难以进行调试。由于找出bug的原因比修复它需要花费时间更长，因此STIMULUS提供了多种调试功能来探索仿真的空间和时间维度。

一些其他建模特性提高了形式化需求规格的一致性，以及它们在第三方工具中的集成。

原理图语言可允许定义系统架构，这与任何MBSE或MBD工具类似。系统定义接口（输入、输出、参数）和行为，既可以是原理图，也可以是需求和状态机的组合，或者是外部的FMI组件。原理图可以从其他工具导入，而形式化的需求可以与需求管理工具同步。

术语表允许定义可以在不同组件之间进行分享的系统变量。对于每个变量，术语表可选地指定数据类型、物理单位和/或物理维度、数值范围或某些默认行为。类型系统支持推断和多态性，这对于构建通用库，以及在不提供任何类型信息的情况下检查需求的一致性都是非常实用的。

起落架系统[5]旨在根据航空器驾驶员的指令，控制三个起落架的伸出和收回序列。其主要由三部分组成。航空驾驶员界面提供了一个操纵装置来指挥起落架的位置，以及作为显示机械状态的显示器。数字部分负责将航空器驾驶员的指令转化为电子命令，传递给物理部分。物理部分由三套起落设备组成，包括起落架、舱门，以及一些如电磁阀、模拟开关、液压缸，以及用于捕获机械状态的传感器等的电机设备。

图4. 起落架系统架构

图4的原理图介绍了航空器驾驶员、数字部分和物理部分之间的交互。考虑到安全原因，数字部分是一个冗余系统，其运行两个实例的相同计算模块。这个模块包括伸出和收回序列的控制器，以及负责识别和消除无效传感器的健康监控系统。

整个架构在STIMULUS中以层次化的原理图进行指定。术语表定义了所有的连接/接口信号，并且结构类型允许信号的复用，例如，DoorsClosedSensors是一个3x3的布尔矩阵，用于捕获每个起落架套装的三重传感器。

形式化的需求可以分配给系统架构的任何级别。例如，图1的高级需求分配给了数字部分，并且详细的细化需求可以分配给基础组件，如控制器和物理设备等。

原始需求规格以自由文本的形式介绍了物理设备的行为。对于每台设备，此行为已经被捕获为一组形式化的需求，在此可以单独进行仿真。例如，模拟开关的自由文本描述如图5所示。

图5. 模拟开关非形式化需求规格

图6. 模拟开关的形式化需求

图6给出了模拟开关的形式化需求，而图7显示了一个可能的仿真。HandleMove信号的行为受到约束，以发出随机脉冲，而输入信号是具有随机值的自由变量。每次发出HandleMove信号时，开关都会关闭，输入信号会传输到输出信号。

然而，对仿真图进行深入观察会发现一个错误的行为，因为在t=50s时的HandleMove脉冲应该将开关保持在关闭状态，直至t=70s。将第二个需求的条件替换为“状态变为关闭或HandleMove变为真”可以解决这个问题。

图7. 可能的模拟开关需求的仿真结果

原始的伸出序列需求规格在图8中给出。其本身并不是一组需求，而是一个标准的情景，因为其描述了在完成一个完整的伸出序列过程中，数字控制器发送的命令序列以及物理部分的反应。此外，附注特别说明，这个标准的序列可以在任何时候被反向命令打断，而且这个序列会在被打断的地方恢复。

尽管这个需求规格非常全面，但其并没有提供统一且可测试的需求来描述系统在任何时间点应执行的操作。深入分析此类需求是一个非常艰难的过程，并没有什么神奇的简单方法：我们是通过不断地试验、错误和修正进行的。然而，事实证明，仿真在检测连续的错误和向图9中的形式化需求集合进展的过程中是至关重要的。

图8. 传出序列的非形式化需求规格

图9. 伸出序列的形式化需求

一旦所有软件和物理需求都已形式化并分配给系统架构中的适当组件，我们就可以仿真完整的系统行为。从建模的角度来看，这就是与现有的MBSE/MBD工具的连接发挥其全部作用的地方，因为系统架构通常可以根据相应的需求由STIMULUS导入。由于需求的分配被保留，系统架构师可以在他们的标准MBSE工具中对架构进行建模，并在非常早期的阶段在STIMULUS中对其进行仿真，而无需等待更详细的行为模型。

可能的仿真如图10所示。HandleCommand信号首先从放切换到收，然后，在收回序列完成之前，切换回放，以激活伸出序列。我们可以看到，反指令得到了妥善的管理。收起序列一直运行到所有的舱门都打开，所有的起落架都在操纵以回收。然后启动了伸出序列。由于所有的舱门都已经打开，伸出序列立即开始操纵以展开起落架，一旦展开起落架，就完成了相应的序列，关闭了舱门。

图10. 可能的起落架需求仿真

图1中的高级需求，作为数字部分的观察者，也得到了满足。换言之，伸出序列的详细需求是对其的优异细化。

然而，图11中的第一个安全性需求在时间t=10.3s处遭到违反，因为数字部分向舱门发送了相互矛盾的指令。在一个时间点，物理系统被要求同时打开和关闭舱门。STIMULUS会自动报告这个冲突，并给出精确的诊断，从而识别出一组冲突的需求和冲突的瞬间。

图11. 伸出和收回序列的安全需求

由于篇幅原因以及作者对游戏感的缺乏，读者被邀请代入系统架构师的角色，提出一个详细的修改需求以避免这种冲突的建议。在第二步中，读者被邀请在不进行任何仿真测试的情况下，思考他们对这种改变抱有多大的信心。

一旦验证通过，形式化需求可以转化为观察者，用来测试任何模型的需求规格，或者起落架的软硬件实现。对于硬件在环（Hardware-In-the-Loop）仿真，观察者被导出为FMI组件以监控测试工作台并记录违反的需求。对于模型或软件在环（Model- or Software-In-the-Loop）仿真，FMI组件被从第三方MBSE/MBD工具导入STIMULUS，以构建测试套件并自动化回归测试。

在这个客户案例中，我们已经将一些数字和物理组件建模为状态机，其中一些是由原始论文[5]提供的，以便根据需求测试需求规格模型。尤其是，我们返回到伸出序列的原始需求规格，因为人们可能认为，使用状态机对这个序列及其中断进行建模是非常直观的。

图12展示了STIMULUS的分层状态机模型，其中包含一个恢复转换（由空箭头标示）。如预期的那样，对于完整的伸出序列的名义场景，状态机工作正常。然而，这个模型并未正确处理反向指令，许多需求观察者在此类仿真中遭到违反。

与原始需求规格中的表述不同，序列不应该“从中断的地方继续”。实际上，恢复状态依赖于舱门和起落架的物理状态，并且应该为序列的每个状态都添加特定的传入转换。再次，我们让读者提出新的需求规格，并找出缺失的转换条件。最后，我们还指出，一个明智的原理图控制器实际上可以从形式化的需求中得出，并提供一个优异的备选状态机。

图12. 伸出序列的初级状态机需求规格

我们的结果显示了对初始起落架和舱门位置的广泛探索，以及它们对伸出和收回序列执行的影响，这些序列通常总是满足图1的高级需求。

本客户案例展示了对需求在环仿真的使用，对调试和验证具有实际复杂性的典型网络物理系统功能需求规格的应用。

研究结果表明，需求在环（RIL）仿真非常适合基于模型的系统工程方法，因为可以以一种一体化和一致性的方式来设计需求、架构和行为模型。尤其是，可以将给定系统的需求细化为其子系统的更低级别需求，直至定义行为模型。在细化过程的任何步骤，都会进行仿真以检查全局系统架构的一致性以及低级别需求和/或模型与高级别需求的合规性。

这提供了一个有效的基于模型的测试框架，其中需求轮流捕获被测试系统、测试预言、测试用例或测试存根。测试执行引擎充分利用约束求解技术来探索各种环境场景和被测试系统的可能反应，从而实现全自动回归测试。尽管仿真无法确保探索的穷尽性，但其似乎是手动测试的有限覆盖率和自动证明工具的有限采用率之间的有效权衡。

最后，这项研究的一个有趣结果涉及到故障分析。传感器模型已经扩展了概率故障，通过仿真验证健康监控系统的需求。这一研究工作的初步成果非常鼓舞人心，为这一领域未来工作的开展打开了机遇之门。