基于需求的Simulink测试验证
概述
基于模型的设计从非正式的文本需求开始,这些需求可能包括复杂的依赖于时间的信号逻辑,在测试过程中很难形式化。本次网络研讨会解释了如何使用Simulink Test以自然语言格式编写具有精确语义的时态评估。这些评估精确地模拟复杂的时间依赖行为,包括条件、事件、信号值和延迟。我们将演示基于需求的测试的完整工作流,包括编写、管理和执行测试。
突出了
学习如何:
- 使用基于模型的设计自动化需求
- 将非正式的文本需求翻译成具有明确、定义的语义的明确的评估
- 跟踪设计和测试的需求
- 监视内部信号,而不干扰设计或生成的代码与新的观察者块
的主持人
Paul Urban是MathWorks的高级产品营销经理,负责验证和验证工具,特别是需求工具箱、Simulink测试和Simulink检查。他的经验包括在应用基于模型设计的系统工程,嵌入式软件开发和测试方面的大量工作。在2016年加入MathWorks之前,Paul在IBM Watson IoT、Telelogic和I-Logix担任产品营销、业务开发、咨询和开发职务,在那里他与Rhapsody一起致力于基于UML/SysML的解决方案。
记录:2019年8月13日
你有多少次把你的设计交付给客户,却发现它不是客户所期望的?有许多由于需求沟通不当而失败的项目的行业例子。最初的需求主要是使用容易被误解的非正式文本指定的,这些挑战是不完整的或不一致的。我的名字是Paul Urban,我在the Math的模型验证和验证产品组工作,在那里我管理Simulink需求、Simulink测试和Simulink检查产品。2022世界杯八强谁会赢?
今天,我将向您展示允许您更早地验证和验证需求的新功能。使用临时评估,您可以将文本需求转换为可以执行的明确评估。解决方案形成一个数字线程,将需求链接到模型中的实现和验证需求的测试。您可以从一位汽车客户的引用中看到,基于模型的设计如何帮助更快地分析需求,并缩短满足客户需求的设计交付时间。
基于软件的更多功能和产品的需求在不断增长。2022世界杯八强谁会赢?这增加了规模和复杂性,并给开发和测试过程带来了额外的压力。在传统的开发过程中,当您从左到右移动时,需求被细化为规范,最终在代码中手工实现。错误在开发的不同阶段被引入,但研究表明大多数缺陷是在初始设计中引入的。这些错误贯穿整个设计阶段,测试会发现其中的许多错误,但直到需要返工和进一步测试的后期才会出现。但到最后,一些潜在的错误可能仍然存在于软件中,只有在现场才能检测到。这些错误可能会导致安全问题或成本高昂的产品召回,这些都是需要解决的更大错误。
此外,研究还表明,发现漏洞的成本会随着时间的推移而增加。例如,在您的桌面PC上编写代码时发现一个软件错误要比在现场的生产硬件上发现该错误便宜。测试的成本增加了——之后在开发周期中发现了缺陷。我们需要能够尽早确定是否所有的需求都得到了实现,我是否正确地理解了需求,设计是否按照需求正确地运行?而且,我们还希望能够在不修改设计的情况下测试它。在Simulink中,图形化模型用具有精确含义的可执行模型取代了模糊的设计。
它允许您在硬件可用之前在桌面上验证您的设计,这样错误更少,更容易识别。Simulink为工程师提供了一套描述复杂系统的语言。从物理领域——比如传动系统和电机。软件领域,如框图和状态机。这些表示方式允许您抽象出不必要的细节,从而将注意力集中在最重要的内容上。
非正式的或特别的模拟测试可以通过构建您的系统的虚拟表示来完成,您可以在您的桌面上与它进行交互。这是早期了解系统、在构建硬件之前评估设计备选方案的好方法。在优化模型之后,Simulink设计可以通过共生成自动转换为生产代码。
有了这个完整的基于模型的设计过程,当您将设计模型细化到您的目标硬件中时,您可以消除代价高昂、容易出错的手动步骤。模拟是早期验证行为的一种很好的方法,但它主要是一个手工过程,而且很大程度上是临时的。为了确定是否满足了所有的需求并正确地运行,我们需要采用更严格的基于需求的测试方法,根据需求系统地测试我们的模型。这就是MathWorks验证和验证工作流帮助自动化测试模型中的手动步骤,并建立可重复的验证工作流的地方。我现在将逐步通过工作流来执行需求的验证。
需求通常以非正式的想法开始。它们可能来自Word、Excel,甚至像门这样更结构化的环境。工程师需要将这些非正式的想法解释为基于模型的设计,然后验证设计是否满足这些需求。当在不同的工具中查看和管理数据时,要做到这一点可能非常困难。很难建立需求与设计和测试之间的可追溯性。
要在Simulink中直接处理来自其他工具的需求,可以通过Simulink对Word、Excel、Doors的需求进行导入操作。还支持标准的需求交换格式——ReqIF。大多数需求管理工具都支持ReqIF。如果需求在源处发生了变化,然后执行了同步变化的更新操作,那么Simulink用户可能想要编辑需求或添加更多的细节——例如需求的自定义属性。
默认情况下是将外部需求视为只读的,但是在最近的19A版本中,解锁需求的能力启用了需求中字段的更新。此外,要导入需求——您也可以直接在Simulink中创建需求,其中Simulink是一个源。将Simulink编写的需求包含在整个项目中,并使用19A中介绍的ReqIF导出操作。
将导入、更新和导出操作与ReqIF结合起来,可以使用同样支持标准的外部需求工具实现双向工作流。在Simulink中,有两个主要的视图可用于处理需求。编辑和透视。编辑器允许您查看和编辑项目中的所有需求集。透视图同时提供了需求和设计的视图,允许您在一个视图中处理两者。
下面是对需求透视图的进一步观察——Canvas右侧的一个控件可以打开和关闭透视图。画布上的徽章显示链接存在的位置,您可以选择显示描述。浏览器将显示需求的列表摘要。它包括实现和验证状态,以显示设计和测试的完整性。Property Inspector包含了需求的所有细节,比如描述、自定义属性,它还包含了需求的链接。
通过在Simulink环境中包含需求,它允许您在设计环境中使用它们,以快速创建可追溯链接。模拟提供了一种很好的方法来尽早发现设计错误,但是需要一种更严格和自动化的测试方法来增加对设计的信心。Simulink测试为您提供了一种系统的方法来测试您的模型。
首先,您可以使用test Harness隔离被测试的组件——允许在不破坏模型的情况下编写测试。可以创建测试用例来根据基线或建模代码之间的等价性来验证设计。可以使用多种格式定义输入,例如——MAT文件、Excel、信号字母或文本序列。要评估结果,您可以与中的基线输出进行比较
MAT或Excel文件。使用MATLAB单元测试编写自定义标准。使用测试评估博客来定义在线通过不通过的条件。您可以链接到测试工件或需求,以完成需求设计和测试之间的可跟踪性。
对链接的分析显示了需求层次结构的实现和验证的完成程度。一个完整的彩色条表示在哪里存在完整的需求覆盖。缺口确定哪些地方缺少实现或测试,哪些地方需要进一步工作。我将介绍一个使用热泵的工作流程示例。它从外部工具中热泵控制器的一些结构要求开始。激活热泵的要求包括定时逻辑。当温度高于2度并持续2秒以上时,泵应激活,然后在一段时间内保持激活状态。
基于这些要求,控制器需要两个输入—一个是温度输入,另一个是室温输入。它将输出三个命令来控制总线上的泵。一个是风扇的启动,一个是水泵的启动,而第三个则指定是需要加热还是冷却。控制器打开风扇并激活泵进行加热或冷却的行为是使用状态流程图实现的。
为了确保所有的需求都在模型中实现,它们被导入到Simulink需求中。在透视中,我可以看到主动热泵的实施状况呈现出差距,它没有任何环节。要创建到模型的链接,我所需要做的就是拖放。我可以显示一个需求注释来查看模型中需求的细节。
注意,链接被创建了,实现状态被更新以显示其已实现。添加链接或注释不会破坏模型。使用单独的文件来维护这些构件。现在,我将继续对需求进行验证。该控制器包含在一个可模拟其运行的加热器和房屋热特性的植物模型中。我只想测试控制器而不破坏模型的其余部分。我将通过创建一个Test Harness来实现这一点。
我选择创建Test Harness的命令,然后您可以为该工具提供许多操作。特别是,您可以选择不同类型的源和不同的同步。我们选择一个测试序列来驱动控制器的输入,这就创建了一个新的测试集合模型,它只包含控制器和一个测试序列块。如果有任何更改,测试中的组件将与主模型保持同步。
测试序列块允许您生成测试输入,并将评估定义为一个步骤序列。您可以将其视为Stateflow的简化版本。它允许您描述复杂的时间测试序列。对于为控制器创建的Test Harness,使用斜坡功能的一系列步骤随时间改变室温的范围,以进入控制器的所有模式。
第一步初始化控制器,然后外部步骤代码降低室温,使控制器处于加热模式。外面的热步骤测试控制器如何冷却房间。最后,控制器回到空闲状态。测试序列提供了一种创建复杂的测试步骤序列以驱动测试输入的方法。
让我们看看激活热泵的要求。这是一个简单的概念——当某个条件为真,那么另一个条件一定在一段时间内为真。但形式化评估——捕捉到的时间条件可能很难。让我们看看如何使用新的时间评估编辑器来改变这个需求。在测试管理器中,我使用热泵模型的test Harness打开一个测试用例,并添加评估。我使用预定义的模式构建评估。该需求指定了触发器响应模式。我为评估命名——然后我需要为触发条件选择一个模式。
在我的例子中,我希望当温差超过某个阈值超过两秒时触发测试。我输入一个与触发条件对应的表达式,并指定条件必须为真的最短时间。注意,所有符号最初都被标记为未解析,并自动添加到符号表中。这些被映射到模型中的信号或表达式。然后,选择与必须评估响应条件的时间相对应的时间参考。最后为响应条件选择一个模式,并对条件和最小时间进行填充。
我可以分解评估,以查看需求的可读且精确的描述。我可以创建到正在测试的需求的链接。而且,为了查看需求,我可以使用链接直接导航到它。注意,创建了一个经过验证的链接,状态显示为黄色,表示测试还没有运行。所以我们将我们的评估符号映射到模型,现在就可以运行测试用例了。我们可以直接从需求运行链接的测试。
测试运行,状态自动更新,显示测试失败。有一个链接可以直接导航到测试结果。评估结果显示了预期的行为和评估失败的实际结果。文本解释告诉我们泵应该在13秒后启动。表达式树解释了关于失败的更多细节,并允许我调试它。我们可以使用数据游标来查看泵直到稍后才打开,这是不正确的。
要调试错误,我们可以从使用链接导航到模型中的实现开始。在检查转换逻辑之后,我们可以很快地看到条件使用了错误的阈值。我在模型中纠正了这一点,现在我可以从模型导航回测试,然后重新运行测试。测试通过了,现在——导航回到需求编辑器,我可以看到验证结果自动更新为绿色表示通过。
总结一下我们所看到的——使用临时评估编辑器,我们能够使用基于表单的编辑器将文本需求转换为正式的评估。该评估可以在一个可读的英语之类的句子中查看。评估结果窗口允许我检查和调试结果。然后,测试结果可追溯至需求和设计。要查看整体状态并识别差距,您可以显示实现和验证状态,以度量设计和测试的整体完整性。
实现状态:蓝色表示链路存在。浅蓝色表示有理由,闪烁表示缺少链接。对于验证状态,绿色表示测试通过,红色表示失败,黄色表示没有结果。而在眨眼之间表示一个测试的链接丢失了。测试工具是隔离被测试组件的一种方法,但是要验证设计,您可能需要访问模型层次结构中深藏的一些信号。但您不希望仅仅为了测试目的而修改设计或界面。
新的观察者块允许您监视您的模型的信号,同时保留设计的动态响应和接口。您可以将验证逻辑从设计中分离出来,并在不修改接口的情况下访问任何层次的任何信号,也不会影响系统的动态响应。它有助于避免使用仅用于测试的附加信号使模型混乱。您可以使用验证逻辑,并将其定位到与被测试模型联合模拟的独立模型中。
可以重用测试来执行SIL、PIL或HIL的等价测试。SIL,或软件在循环中测试,指的是重用来自模型的测试,以在桌面PC上执行生成的代码,然后将结果与模拟结果进行比较。您还可以测量代码覆盖率,以查看生成的代码是否经过了完整的测试。PIL或Processor In the Loop测试指的是交叉编译
为目标处理器生成代码。在目标处理器上执行该代码,然后比较来自目标处理器的结果和模拟结果。还有第三种循环中的测试,称为HIL或硬件在循环中。在这种情况下,测试使用Simulink real time和Speedgoat检查设计和代码的实时行为。
我们有许多客户使用VNV工作流。举个例子——埃利斯汽车是韩国最大的汽车开关和零部件一级供应商之一。他们需要满足oem日益增长的需求,要求更快地交付更多功能,并要求生产系统符合ISO 262标准。Ellis Automotive与The MathWorks咨询公司合作,采用基于MATLAB和Simulink的模型设计,以减少他们的镜子和动力窗控制的开发时间。
他们运行了模拟和Simulink,发现了客户的规格错误。但幸运的是,这些相对容易解决,因为它们在开发的早期就被发现了。他们能够消除手工编码错误并减少开发时间。要了解更多关于埃利斯汽车和其他客户访问我们的网站。
总之,基于模型的设计使您能够更早地点击Play按钮来验证和验证设计,并在硬件可用之前捕获错误。新的测试评估语言使您能够将非正式的文本需求翻译成具有精确语义的明确的评估。为了更好地理解,它们可以被视为自然语言句子。
有了这个解决方案,我们能够从需求到设计,再到测试——允许我们很容易地确定需求在哪里实现,以及它是如何被测试的。这也使我们能够确定如果我们的需求发生了变化,什么将会受到影响。要了解关于MathWorks验证和验证工作流的更多信息,请查看今天讨论的产品的产品页面或www.ru-cchi.com上的解决方案页面2022世界杯八强谁会赢?
您也可以从以下列表中选择网站:
如何获得最佳的网站性能
选择中国网站(中文或英文)以获得最佳的网站表现。其他MathWorks国家网站没有针对从您的位置访问进行优化。