CN107885487A - 一种信息物理融合系统的测试及需求满足性检验的方法 - Google Patents

Abstract

本发明公开了一种信息物理融合系统的测试及需求满足性检验的方法，其特征是，包括如下步骤：1）明确用户需求；2）根据用户需求进行建模；3）扩展问题图；4）根据因果关系生成因果关系链；5）生成测试序列；6）生成CSP脚本。这种方法采用因果关系在需求建模中找到多条因果关系链，能将复杂的需求拆分为多个子需求，从而简化了问题的规模、并且把需求可满足性的验证通过数学公式进行验证，既严谨又可以提高自动化程度。

Description

一种信息物理融合系统的测试及需求满足性检验的方法

技术领域

本发明涉及软件工程领域中需求分析技术，具体是一种信息物理融合系统的测试及需求满足性检验的方法。

背景技术

信息物理融合系统(Cyber-Physical System，简称CPS)是一系列计算进程和物理进程组进的紧密集成，通过计算进程和物理进程相互影响的反馈循环实现深度融合和实时交互，以监控物理实体的运行，而物理实体又借助于网络和计算组件实现对环境的感知和控制。根据功能和所属领域的不同，将CSP系统一体化模型可以划分为物理实体，计算实体和交互实体三部份。由于现在是大数据时代，信息物理融合系统越来越复杂，而单一的计算领域或控制领域的建模仿真工具难以满足其系统异构性的要求。目前的一些研究都是把异质模型融合技术实现信息物理融合计算系统和物理系统的融合。例如：UML、Modelica及Simulink等建模语言基础上进行建模元素的扩展。目前的信息物理融合系统的建模技术和仿真技术，体现了在CPS系统仿真验证技术上的一些进步，但是还远不能满足大型的CPS系统设计过程中的仿真验证需要。对CPS系统的设计需要有一套方法，贯穿需求文档获取，到需求分析，需求建模，系统实现，系统测试的整个过程。

在真实的CPS系统的设计时，我们不能仅靠功能来设计用户需求模型，更应该考虑计算系统与物理系统的交互。大型的CPS系统，或因计算系统的缺陷会导致物理系统故障，甚至是毁坏。因此，需求获取和分析阶段，我们需要明确计算系统需求的同时，要考虑物理物理环境，验证物理系统是否满足用户需求是永远不够的，还应该验证计算系统与物理系统融合后是否满足用户需求，从而尽最大的可能避免系统缺陷。而CPS系统实现后，面对细如蜘蛛网的物理设备，系统的测试和维护就变非常困难。因此，更需要有一套方法辅助CPS系统设计和研发。

发明内容

本发明的目的是针对现有技术得到不足，而提供一种信息物理融合系统的测试及需求满足性检验的方法。这种方法采用因果关系在需求建模中找到多条因果关系链，能将复杂的需求拆分为多个子需求，从而简化了问题的规模、并且把需求可满足性的验证通过数学公式进行验证，既严谨又可以提高自动化程度。

实现本发明目的的技术方案这是：

一种信息物理融合系统的测试及需求满足性检验的方法，包括如下步骤：

1)明确用户需求：分析用户需求之间的共享现象，以及共享现象间的因果关系，结合需求背后的真实场景，明白系统的业务流程；

2)根据用户需求进行建模：采用问题框架对用户需求进行建模，用问题框架建模绘制出来的模型图也称为问题图，它是由一组机器领域、问题领域和需求组成，明确的表达出计算组件和物理组件之间的交互关系；

3)扩展问题图：给问题图添加因果关系属性和约束属性，扩展所设计的问题图，将各共享现象之间的因果关系也表现在问题图中，同时将真实场景中可能遇到的约束用表达式描述方式添加到问题图中，定义：向问题图中的机器领域添加的因果关系属性的值为共享现象a导致共享现象b，记为a->b，约束属性的值为共享现象a需要满足的条件，假设共享现象a中是用户指令，仅当共享现象a满足条件用户指令才会发出，问题框架接口、需求引用和需求约束上可以用共享现象描述，并且共享现象是由控制前缀和因果现象集合组成，控制前缀指明每个现象集合由哪个领域控制，在此基础上，需对每个领域添加一条因果关系属性，以记录与该领域有关的共享现象之间的触发关系也即因果关系；

4)根据因果关系生成因果关系链：因果关系链是由机器领域和需求之间多个共享现象组成的集合，且集合中的相邻元素之间存在相同方向的因果关系，根据扩展后的问题图，可以从问题图中得出因果关系链，过程如下所述：若问题图中有一个共享现象a导致另一个共享现象b，且共享现象b导致共享现象c，那么可以得到共享现象a导致共享现象b导致共享现象c的因果关系链，记为a->b->c，领域之间的共享现象存在因果关系，而用户的一个需求往往涉及多个领域，但由于CPS系统中，计算系统是核心部分，所以在一系列因果关系形成了因果关系链，因果关系链方法可以将复杂的需求转化成多个简单子需求，每条因果关系链即是一个子需求；

5)生成测试序列：因果关系链中包含的计算组件和物理组件，需要融合起来进行测试，而单单测试某一个组件无法得知融合起来的系统是否能够正常运行，因此，因果关系链是组件之间共享现象有因果关系的集合，测试序列则为因果关系链中所覆盖的领域元素；

6)生成CSP脚本：将因果关系链用数学公式形式表示，通信进程CSP是一个行为验证的语言，因果关系链可以用CSP表示，通过CSP验证工具完成验证，验证的工具如故障偏差精炼检测器(Failures-Divergences Refinement Checker，简称FDR)，生成的CSP脚本的验证即是问题图中的需求可满足性验证。

步骤2)中所述模型图包括问题框架方法的提供的用表示的机器领域machine domain、用表示的问题领域problem domain和用表示的需求requirement，所述问题领域包括用表示的设计领域designed domain和给定领域given domain，机器领域与问题领域之间的连线用表示，称为接口交互(interface)，需求与问题领域之间的连线用表示，称为需求引用(reference)，需求与问题领域之间的连线用表示，称为需求约束(constraint)。

5)中所述的测试序列是因果关系链所覆盖的问题图中机器领域、问题领域和需求组成的集合，每条因果关系链可以转化成一条完整的测试序列，测试人员可以根据因果关系链和约束生成的测试序列来设计测试用例，让测试人员从复杂的系统测试的困境中摆脱出来，一但系统发生故障，仅需要测试与该故障有关的物理系统和计算系统，并不需要把不相关的物理系统和计算系统一起来测试，从而简单了测试工作，很大程度提高了效率，如果系统工作正常，仅运行结果与预期的不同，则可以根据测试序列中的前置和后置约束条件进行测试用例的设计，这正是本方独到之处，从而便利了测试和后期系统的维护；

在步骤6)中，利用因果关系链方法将CPS系统的需求转化为多个子需求，具体可以在问题框架方法建模后，先将模型利用因果关系链进行拆分，然后再转化成通信顺序进程(CSP)脚本，最后使用相应检测软件对CSP脚本描述的需求进行满足性验证，这种处理方法是将用户需求精化，然后再验证被精化的需求是否满足。

这种方法通过利用软件工程领域著名学者Michael A.Jackson提出一种面向问题的建模语言即问题框架方法(Problem Frame，简称PF)，来创造性的提出信息物理融合系统的测试及需求满足性验的方法。

问题框架方法很适合信息物理融合系统的建模，因此这种方法采用问题框架进行需求建模，扩展问题图的因果关系属性和约束属性，同时这种方法把因果关系链转化成带约束的测试序列和不带约束的测试序列，类似黑、白盒测试的两种测试方法，为工业设计提供辅助方法，有效消除系统设计缺陷，完善系统，更利于大型CPS系统的维护，节约开发和维护成本，给企业带来显著的好处。

这种方法采用因果关系在需求建模中找到多条因果关系链，能将复杂的需求拆分为多个子需求，从而简化了问题的规模、并且把需求可满足性的验证通过数学公式进行验证，既严谨又可以提高自动化程度。

附图说明

图1为实施例的流程示意图；

图2为实施例中糖尿病患者胰岛素注射的问题图；

图3为实施例的问题图扩展；

图4为实施例的问题图CSP脚本；

图5为实施例的问题图CSP脚本校验结果图；

图6为实施例的测试用例。

具体实施方式

下面结合附图和实施例对本发明内容作进一步的阐述，但不是对发明的限定。

实施例：

参照图1，一种信息物理融合系统的测试及需求满足性检验的方法，包括如下步骤：

1)明确用户需求：分析用户需求之间的共享现象，以及共享现象间的因果关系，结合需求背后的真实场景，明白系统的业务流程；

2)根据用户需求进行建模：采用问题框架对用户需求进行建模，用问题框架建模绘制出来的模型图也称为问题图，它是由一组机器领域、问题领域和需求组成，明确的表达出计算组件和物理组件之间的交互关系；

3)扩展问题图：给问题图添加因果关系属性和约束属性，扩展所设计的问题图，将各共享现象之间的因果关系也表现在问题图中，同时将真实场景中可能遇到的约束用表达式描述方式添加到问题图中，定义：向问题图中的机器领域添加的因果关系属性的值为共享现象a导致共享现象b，记为a->b，约束属性的值为共享现象a需要满足的条件，假设共享现象a中是用户指令，仅当共享现象a满足条件用户指令才会发出，问题框架接口、需求引用和需求约束上可以用共享现象描述，并且共享现象是由控制前缀和因果现象集合组成，控制前缀指明每个现象集合由哪个领域控制，在此基础上，需对每个领域添加一条因果关系属性，以记录与该领域有关的共享现象之间的触发关系也即因果关系，本例使用对象约束语言(Object Constraint Language,OCL)的语法，描述共享现象需要满足的条件并记录此约束属性；

4)根据因果关系生成因果关系链：因果关系链是由机器领域和需求之间多个共享现象组成的集合，且集合中的相邻元素之间存在相同方向的因果关系，根据扩展后的问题图，可以从问题图中得出因果关系链，过程如下所述：若问题图中有一个共享现象a导致另一个共享现象b，且共享现象b导致共享现象c，那么可以得到共享现象a导致共享现象b导致共享现象c的因果关系链，记为a->b->c，领域之间的共享现象存在因果关系，而用户的一个需求往往涉及多个领域，但由于CPS系统中，计算系统是核心部分，所以在一系列因果关系形成了因果关系链，因果关系链方法可以将复杂的需求转化成多个简单子需求，每条因果关系链即是一个子需求；

5)生成测试序列：因果关系链中包含的计算组件和物理组件，需要融合起来进行测试，而单单测试某一个组件无法得知融合起来的系统是否能够正常运行，因此，因果关系链是组件之间共享现象有因果关系的集合，测试序列则为因果关系链中所覆盖的领域元素；

6)生成CSP脚本：将因果关系链用数学公式形式表示，通信进程CSP是一个行为验证的语言，因果关系链可以用CSP表示，通过CSP验证工具完成验证，生成的CSP脚本的验证即是问题图中的需求可满足性验证，本例验证的工具为FDR。

步骤2)中所述模型图包括问题框架方法的提供的用表示的机器领域machine domain、用表示的问题领域problem domain和用表示的需求requirement，所述问题领域包括用表示的设计领域designed domain和给定领域given domain，机器领域与问题领域之间的连线用表示，称为接口交互(interface)，需求与问题领域之间的连线用表示，称为需求引用(reference)，需求与问题领域之间的连线用表示，称为需求约束(constraint)。

5)中所述的测试序列是因果关系链所覆盖的问题图中机器领域、问题领域和需求组成的集合，每条因果关系链可以转化成一条完整的测试序列，测试人员可以根据因果关系链和约束生成的测试序列来设计测试用例，让测试人员从复杂的系统测试的困境中摆脱出来，一但系统发生故障，仅需要测试与该故障有关的物理系统和计算系统，并不需要把不相关的物理系统和计算系统一起来测试，从而简单了测试工作，很大程度提高了效率，如果系统工作正常，仅运行结果与预期的不同，则可以根据测试序列中的前置和后置约束条件进行测试用例的设计，这正是本方独到之处，从而便利了测试和后期系统的维护；

在步骤6)中，利用因果关系链方法将CPS系统的需求转化为多个子需求，具体可以在问题框架方法建模后，先将模型利用因果关系链进行拆分，然后再转化成通信顺序进程(CSP)脚本，最后使用相应检测软件对CSP脚本描述的需求进行满足性验证，这种处理方法是将用户需求精化，然后再验证被精化的需求是否满足。

具体地，结合图2的问题图，本技术方案的步骤如下：

1)明确用户需求:本例为是糖尿病患者胰岛素注射问题的需求，深入了解胰岛素注射仪器的工作原理及糖尿病相关知识，以便对需求能够准确的掌握；

2)根据用户需求进行建模：对胰岛素注射问题的需求进行建模，采用问题框架建模如图2所示；

图中控制器是胰岛素注射控制器，泵是胰岛素泵，注射装置是注射针管装置，感应器是检测人体胰岛素含量仪，病人是总个系统中数据的输入，警报器是胰岛素超低时警报装置，显示器是总个CPS系统的显示屏，电源是系统的供电设备；

3)扩展问题图：向图2的各个领域中添加因果关系属性和约束属性，如图3所示，感应器检测病人的胰岛素含量值，控制器获取检测值，因为感应器检测到了病人的胰岛素含量值，所以控制器获取到了检测值，可以把这样的因果关系记录为检测胰岛素含量->获取检测值，控制器获取检测值不是病人所需要的安全值的时候，控制器就会发出注射命令给泵，因果关系记为获取检测值->注射命令，泵收到注射命令就会给注射装置加进相应量的胰岛素，因果关系记为注射命令->注射量，控制器获取到低于安全值的胰岛素含量值时，会给警报器发出命令，警报器接收命令响起警报器，因果关系记为获取检测值->接收警报命令，控制器获取到胰岛素含量值，会交给显示器显示结果，因果关系记为获取检测值->接收显示信号，在控制器上启动设备，电源接收到开关信号来启动或关闭电源，因果关系记为接收开关信号->电源开启、关闭；

在控制器中添加一条约束属性，内容为：

前置条件：胰岛素含量<3.0uU/ml且注射量>＝0

后置条件：注射量＝3.0-胰岛素含量且胰岛素含量＝3.0

此约束的意思当胰岛素含量值低于3.0uU/ml，控制器就会发起注射命令,让泵工作，泵会让注射装置向病人注射控制好的3.0-胰岛素含量剂量的胰岛素，且约束注射量要大于等于零，注射量为3.0-胰岛素含量，注射后，置胰岛素含量为3.0，表示胰岛素含量又恢复正常值；

4)根据因果关系生成因果关系链：扩展了问题图后，依据因果关系，可以得到此系统的多个因果关系链，此问题图的因果关系链如下：

(1)检测胰岛素含量->获取检测值->接收警报命令->警报开启；

(2)检测胰岛素含量->获取检测值->接收显示信号->屏幕显示；

(3)检测胰岛素含量->获取检测值->接收开关信号->电源开启、关闭；

(4)检测胰岛素含量->获取检测值->注射命令->注射量->正确注射量；

5)生成测试序列：由因果关系链，可以生成带约束的测试序列如下：

1、需求->病人->感应器->控制器[@胰岛素含量<3.0uU/ml且注射量>＝0@注射量＝3.0-胰岛素含量且胰岛素含量＝3.0]->警报器；

2、需求->病人->感应器->控制器[@胰岛素含量<3.0uU/ml且注射量>＝0@注射量＝3.0-胰岛素含量且胰岛素含量＝3.0]->显示器；

3、需求->病人->感应器->控制器[@胰岛素含量<3.0uU/ml且注射量>＝0@注射量＝3.0-胰岛素含量且胰岛素含量＝3.0]->电源；

4、需求->病人->感应器->控制器[@胰岛素含量<3.0uU/ml且注射量>＝0@注射量＝3.0-胰岛素含量且胰岛素含量＝3.0]->泵->注射装置；

本实施例生成的测试序列应对测试需要，可以分为两种方法，一种是隐藏约束条件，仅可以看到测试线索，另一种是显示约束条件，可以为信息物理融合系统设计有边界值的测试用例，如图6中两个测试用例表中的测试序列，这方法类似于软件测试中的黑白盒测试，增加了信息融合系统中测试的新方法，因此本发明为CPS系统的设计与研发带来很大好处；

6)生成CSP脚本：问题图的CSP脚本是根据因果关系来描述的，因为CSP语法不是本方发明创新，这里不作CSP语法相关内容，本实施例的问题图根据因果关系描述的CSP脚本如图4所示，生成需求可满足性验证所使用的CSP代码后，验证CSP中问题图中需求是否满足，可以使用CSP校验工具校验即可，例如图5所示，图5为FDR校验工具，来验证需求是否满足，从图5中可以看到，本实施例问题图的需求是满足的。

Claims (3)

1.一种信息物理融合系统的测试及需求满足性检验的方法，其特征是，包括如下步骤：

1)明确用户需求：分析用户需求之间的共享现象，以及共享现象间的因果关系，结合需求背后的真实场景，明白系统的业务流程；

2)根据用户需求进行建模：采用问题框架对用户需求进行建模，用问题框架建模绘制出来的模型图也称为问题图，它是由一组机器领域、问题领域和需求组成，明确的表达出计算组件和物理组件之间的交互关系；

3)扩展问题图：给问题图添加因果关系属性和约束属性，扩展所设计的问题图，将各共享现象之间的因果关系也表现在问题图中，同时将真实场景中可能遇到的约束用表达式描述方式添加到问题图中，定义：向问题图中的机器领域添加的因果关系属性的值为共享现象a导致共享现象b，记为a->b，约束属性的值为共享现象a需要满足的条件，假设共享现象a中是用户指令，仅当共享现象a满足条件用户指令才会发出；

4)根据因果关系生成因果关系链：因果关系链是由机器领域和需求之间多个共享现象组成的集合，且集合中的相邻元素之间存在相同方向的因果关系，根据扩展后的问题图，可以从问题图中得出因果关系链，过程如下所述：若问题图中有一个共享现象a导致另一个共享现象b，且共享现象b导致共享现象c，那么可以得到共享现象a导致共享现象b导致共享现象c的因果关系链，记为a->b->c；

5)生成测试序列：因果关系链中包含的计算组件和物理组件，需要融合起来进行测试，而单单测试某一个组件无法得知融合起来的系统是否能够正常运行，因此，因果关系链是组件之间共享现象有因果关系的集合，测试序列则为因果关系链中所覆盖的领域元素；

6)生成CSP脚本：将因果关系链用数学公式形式表示，因果关系链可以用CSP表示，通过CSP验证工具完成验证，生成的CSP脚本的验证即是问题图中的需求可满足性验证。

2.根据权利要求1所述信息物理融合系统的测试和需求满足性检验方法，其特征是,步骤2)中所述模型图包括问题框架方法的提供的用表示的机器领域、用表示的问题领域和用表示的需求，所述问题领域包括用表示的设计领域和给定领域机器领域与问题领域之间的连线用-表示，称为接口交互，需求与问题领域之间的连线用........表示，称为需求引用，需求与问题领域之间的连线用表示，称为需求约束。

3.根据权利要求1所述信息物理融合系统的测试和需求满足性检验方法，其特征是,5)中所述的测试序列是因果关系链所覆盖的问题图中机器领域、问题领域和需求组成的集合。