用于测试和验证应用程序的系统和方法与流程

1.本发明通常涉及一种用于测试软件应用程序的系统和方法，并且更具体地涉及一种用于利用物理系统测试软件应用程序的运行的系统和方法。


背景技术：

2.开发用于运行和自动化诸如涡轮机、火车、工厂等产品的软件解决方案可能具有挑战性，因为必须在通常不可预测的不同的运行条件下对软件进行测试。应用程序可能在一种情况下在云上令人满意地运行，或者在另一种情况下在基于雾的平台中然而同一应用程序可能无法运行，除非它本地寄存在与其控制的过程或机器相连的嵌入式控制器中。由于大型工业系统中的运行变化很大，因此必须在条件变化很大的情况下进行重要的测试。


技术实现要素：

3.一种对包括软件和硬件的物理系统进行测试的方法包括：开发软件应用程序，该软件应用程序被布置为用于运行物理系统的至少一部分；并且在测试生态系统内构建物理系统的模拟，该模拟包括对物理系统的控制输入进行模拟的输入端和对控制和信息输出进行模拟的输出端。该方法还包括将软件应用程序连接到物理系统的模拟，以测试软件应用程序的运行，以及在测试生态系统内对物理系统和软件应用程序的运行进行模拟，测试生态系统可运行地用于对软件应用程序作为云应用程序、网络应用程序和本地应用程序中的每一个的运行进行模拟。
4.在另一构造中，对包括软件和硬件的物理系统进行测试的方法包括：建立基于云的测试生态系统，该基于云的测试生态系统对操作系统和系统布置进行模拟；并且通过从模拟元件库中选择元件来在测试生态系统内构建物理系统的模拟，每个元件对物理部件进行模拟并且包括对每个物理部件中固有的延迟进行模拟的推迟值。该方法还包括：将软件应用程序放置在测试生态系统内，该软件应用程序连接到物理系统的模拟，以将输入传送到物理系统的模拟并且从物理系统的模拟接收输出；运行物理系统的模拟；并且输出与软件应用程序的运行和物理系统的模拟相关的性能数据。
5.前面已经相当宽泛地概述了本技术的技术特征，从而本领域技术人员可以更好地理解下面的详细描述。随后将描述形成权利要求的主题的本技术的附加的特征和优点。本领域技术人员要理解，他们可以容易地使用所公开的方案和具体实施例作为修改或设计其他的结构以实现与本技术相同的目的的基础。本领域技术人员还将认识到，这种等效的构造不脱离本技术在其最广泛的形式中的精神和范围。
6.此外，在下面进行详细的描述之前应当理解，本说明书提供了某些词语和短语的各种定义，并且本领域技术人员要理解，这种定义在许多(如果不是大多数)情况下适用于这样定义的词语和短语的先前和未来的使用。虽然一些术语可以包括多种实施例，但所附的权利要求可以明确地将这些术语限制为特定的实施例。
附图说明
7.图1示出了对新的应用程序进行测试的测试生态系统的示意图。
8.图2示出了说明应用程序测试过程的流程图。
9.在详细解释本发明的任何实施例之前应当理解，本发明在其应用方面并不局限于在以下描述中阐述或在以下附图中示出的构造的细节和部件的布置。本发明能够实现其他的实施例并且能够以各种方式实践或执行。此外应当理解，在此使用的措辞和术语是为了描述的目的，而不应被视为限制性的。
具体实施方式
10.现在参考附图来描述与系统和方法有关的各种技术，其中相同的附图标记始终表示相同的元件。下面讨论的附图以及本专利文本中用于描述本技术的原理的各种实施例仅作为说明，而不应以任何方式解释为限制本技术的范围。本领域技术人员要理解，本技术的原理可以在任何适当布置的装置中实施。要理解的是，描述为由特定的系统元件执行的功能可以由多个元件执行。类似地，例如，元件可以被配置为用于执行描述为由多个元件执行的功能。将参考示例性的非限制性的实施例来描述本技术的众多的创造性的教导。
11.此外应当理解，除非在一些示例中被明确限制，否则应当宽泛地解释本文使用的词语或短语。例如，术语“包括”、“具有”和“包含”以及它们的派生词意味着包括但不限于。单数形式也旨在包括复数形式，除非上下文另有明确说明。此外，本文使用的术语“和/或”是指并且涵盖一个或多个相关联的列出的项目的任何和所有可能的组合。除非上下文另有明确说明，否则术语“或”是包含性的，即意味着和/或。短语“与
……
相关联”和“与之相关联”及其派生词可能意味着包括、被包括在其中、相互连接、包含、被包含在内、连接到或与其连接、耦合到或与其耦合、可与其通信、合作、交错、并列、接近、绑定到或与其绑定、具有、具有...的属性等。
12.此外，虽然术语“第一”、“第二”、“第三”等可以在本文中用于指各种元件、信息、功能或动作，但这些元件、信息、功能或动作不应受这些术语限制。准确地说，这些数字形容词用于区分不同的元件、信息、功能或动作。例如，第一元件、信息、功能或动作可以被称为第二元件、信息、功能或动作，类似地，第二元件、信息、功能或动作可以被称为第一元件、信息、功能或动作，而不脱离本技术的范围。
13.此外，术语“邻近”可以指：一个元件相对靠近但不与另外的元件接触；或者该元件与另外的部分接触，除非上下文另有明确说明。此外，除非另有明确说明，否则短语“基于”旨在表示“至少部分基于”。术语“大约”或“基本上”或类似术语旨在涵盖在针对该尺寸的正常的工业制造公差内的值的变化。如果没有可用的行业标准，那么20％的变化包含在这些术语的意义中，除非另有说明。
14.图1示意性示出了用于软件应用程序15和尤其是与硬件系统20一起使用的控制应用程序进行测试的系统或环境10。所示出的系统10特别适用于对在实际的运行中不容易测试的硬件20的应用程序进行测试。例如，发电涡轮机是高能机器，如果在正常运行参数之外运行，该高能机器可能会被严重损坏。在实际的机器上对软件15进行测试可能会导致这种不期望的运行，并且因此执行起来很困难并且可能成本很高。
15.图1示出了非常适合利用现有的硬件20对新的软件应用程序15进行测试的测试环
境或测试生态系统10。所示的测试生态系统10优选基于云，但也可以基于网络或在用户的计算机上本地维持。测试生态系统10为用户提供环境以构建物理系统30的虚拟模型25，其包括硬件模型35和软件模型40。提供公共的物理属性或部件(例如阀门、液压装置、涡轮机、马达等)的数据库或库45，以允许用户构建虚拟模型25。此外，当用户开发新部件的模拟时，这些模拟可以添加到库45中。每个虚拟模型25或部件对物理系统30或部件的实际的运行、包括该系统30或部件的运行中的预期的推迟或延迟进行模拟。例如，对物理液压阀的模拟可能会收到表明希望打开阀门的信号。模拟可以立即将阀门移动到希望的位置，但这并不现实。作为每个模拟的一部分的推迟值通过延迟模拟中的阀门的移动来解释真实世界的物理延迟。模拟可以包括机器学习以及基于现实世界中的这种系统的运行的历史数据提供类似的或相同的输出的人工技术。
16.测试环境10还提供对容器50的库的访问，以与要测试的软件应用程序15一起使用。容器50是接收软件应用程序15以允许软件应用程序15在包括linux、windows、ios、qhx、bsd等的任何操作系统上运行的软件包。简单来说，容器50包括根据需要连接代码段70或输入/输出模块75的内部连接65。容器50还包括用于任何操作系统的外部连接。当从代码段70或输入/输出模块75输出时，容器50因此从代码段70或输入/输出模块75获取一个内部信号，并且根据任何可用的操作系统的要求调整该信号。随后，适当的输出信号可用于任何具有如下信号的操作系统，该信号对于所使用的操作系统来说是唯一的外部连接。当将信号输入时，过程是相反的。该信号来自所使用的操作系统，并且通过适当的外部连接进入容器50。随后，信号被调整并且传送到代码段70或输入/输出模块75。
17.仿真模块55提供应用模型40、更具体地容器50或多个容器与硬件模型35之间的连接。仿真模块55可以被配置为用于对应用模型4 0和硬件模型35的多种不同的布置进行模拟。例如，仿真模块55可以被布置为用于对作为与硬件系统20交互的基于云的应用程序的应用程序15进行模拟，或者可以对在远离硬件20的服务器上或在相同的物理地点上运行的应用程序15进行模拟。仿真模块55根据硬件系统20和应用程序15之间所选择的架构来模拟两者之间的预期的延迟。虚拟模型25随后可以对在基于云的配置、基于网络的配置、作为本地存储的应用程序、或可能有利的任何其他的布置中的应用程序15进行模拟。生成的数据可以被发送到虚拟化管理系统60，并且被收集用以进一步分析。
18.如图1所示，物理系统30的虚拟模型25或数字孪生构建在提供可扩展的开发和纯数字部署环境的基于云或离线的生态系统10中。可以基于允许在实现物理系统30和控制应用程序15之前创建目标物理系统30的数字孪生25所需的系统来提供库45。数字孪生25可以由真实物理系统30的小型和大型的模拟以及数字实体模型(mock
‑
up)构成。数字孪生25根据需要在云或其他环境中的虚拟化的基础设施中运行。数字孪生25包括允许编程和测试从简单到复杂的控制系统(例如scada、mes等)的暴露的接口。随后，在测试生态系统10中部署应用程序15，用以在容器50和重新创建物理系统30的虚拟机中一起测试应用程序15和物理系统20。应用资源和负载可以被测量和量化，同时与物理系统30的仿真的数字孪生25密切协作地运行。
19.在测试运行之后，应用程序在计算算力和其他资源方面的需求是已知的。系统10还测试和测量应用程序15与仿真的物理系统35交互的推迟界限。这些延迟和性能界限可以提供给虚拟化管理系统60(例如dmtf redfish)，其可以将相同的容器55和虚拟模型25重新
部署到正确类型的计算元件(例如边缘云、服务器机架或plc数量)，同时满足所描述的要求。这同样适用于最能影响延迟的通信需求，该延迟可以在描述物理系统30的配置需求之前从系统10导出。可以给诸如软件定义的网络之类的技术提供这样的信息。由tricentis提供的tosca是一种示例性的说明性语言，用于描述应用程序15在部署在任何计算和网络环境中时的要求。
20.虚拟模型25和容器50应按原样复制，并且放置在满足利用测试生态系统10确定的推迟和资源要求的计算元件中。
21.本文描述的测试生态系统10极大地提高了利用诸如涡轮机、火车等工业设备实施的软件15的可靠性。此外，系统10降低了设备20的在新的软件部件15的测试或初始运行期间经常发生的损坏或不正确运行的可能性。
22.图2示出了使用图1的测试生态系统10的过程。该过程中的初始步骤是在测试环境内构建物理系统的模型(步骤110)。该构建可以利用构建和存储在部件库45中的先前的部件。可以在构建物理系统的数字孪生或虚拟模型的同时、之前或之后开发新的应用程序(步骤115)。随后，将应用程序与物理系统30的硬件部分的数字孪生35一起放置在测试生态系统中(步骤120)。随后，应用程序40通常在步骤125中通过仿真模块55连接到系统模型35。在测试之前，任何测试参数、例如操作系统、应用环境(例如基于云的、本地的等)和任何其他的推迟参数通常通过仿真模块55应用于系统(步骤130)。随后，在步骤135中运行模拟并且在步骤140中输出结果。如果希望改变测试参数并且重新运行测试，那么改变这些参数并且从步骤125开始重复该过程(步骤145)。一旦收集到希望的数据，那么模拟结束。
23.控制系统可以(独立于我们想要控制的内容)被分解为传感器、致动器和控制器逻辑。代表控制器逻辑的软件通常读取致动器和传感器的状态，并且推断过程状态的下一个变化，该变化作为输入被转换为并且发送到各种致动器。
24.该模拟允许软件开发者编写正确的控制逻辑，但可以测试在不同条件下运行控制软件的行为、例如在控制应用程序与其过程(执行器/传感器)之间添加延迟以找出最优的执行和通信条件。如果没有按时传输传感器值，或者太晚接收发送到致动器的命令(“打开阀门”)，那么给定的推迟阈值可能会导致过程处于错误状态或失败。模拟可以在运行的开发期间捕获这样的运行范围。
25.随后，其也用于描述关于如何部署应用程序的要求。在推迟方面，执行环境和网络端到端qos都在实现在上述模拟步骤中描述的最低推迟水平方面发挥作用。
26.容器化的应用程序或运行在虚拟机中的应用程序的部署管理包括：分配并保证给定的容器或虚拟机的计算和内存；并且还能够通过例如软件定义的网络控制器或某些网络管理系统来预测网络延迟，该网络管理系统需要关于延迟和带宽的某些要求作为输入；并且根据通往云或边缘服务器或本地嵌入式控制器的网络路径是否最佳来做出响应。
27.只要满足要求，容器和虚拟机可以部署在任何地方。
28.可能存在成本函数来决定，延迟容忍应用程序不应该利用边缘和本地化的控制器设备上的宝贵且有限的资源。因此，有利于将负载转移到云。
29.在允许控制逻辑运行真实的系统之前，还可以在部署发生之后针对过程的模拟再次测试部署。
30.这变得更加重要，因为控制器软件正朝着更现代的编程和执行基础、例如过程和
应用程序之间的通信的事件驱动和发布/订阅的类型发展，并且也用于基于ai的控制逻辑，其需要更多的只有边缘服务器或云环境才能提供的计算和存储资源。
31.虽然已经详细描述了本技术的示例性的实施例，但是本领域技术人员应当理解的是，在不脱离本技术在其最广泛的形式中的精神和范围的条件下，可以进行对本技术的各种改变、替换、变化和改进。
32.本技术中的任何描述均不应被理解为暗示任何特定的要素、步骤、动作或功能是必不可少的要素，其必须包含在权利要求范围内：仅通过授权的权利要求限定专利主题的保护范围。此外，这些权利要求中没有一个旨在涉及装置加上功能权利要求的结构，除非确切的词语“装置用于
…”
后跟一个动词。