Simulink模型的持续集成验证
作者:David Boissy, Paul Urban, Krishna Balasubramanian, Pablo Romero Cumbreras, Colin Branch和Jemima普利帕蒂,MathWorks
本文 是由 两部分组成的系列文章的第一篇。第1部分介绍如何利用GitLab®版本控制和詹金斯®用于持续集成(CI)。第2部分,持续 集成验证 Simulink模型 使用GitLab, 介绍了如何使用GitLab进行版本控制和CI。
持续集成(CI)越来越受欢迎,并成为基于模型的设计的一个组成部分。但什么是CI?它的好处是什么?它试图解决什么问题?如何仿真软件®能否融入CI生态系统?如何在项目中最好地利用CI ?
如果您熟悉基于模型的设计但不熟悉CI,您可能会问自己这些问题。在这篇技术文章中,我们将探讨一个通用的CI工作流,并将其应用到基于模型的设计中。然后,我们使用Jenkins、GitLab和Simulink Test™完成该工作流的一个示例。
本例中使用的项目是可以下载.
词是什么?
CI是一种敏捷方法的最佳实践,开发人员定期提交并合并他们的源代码更改到一个中央存储库中。这些“变更集”随后被自动构建、限定并发布。图1演示了这个基本的CI工作流和开发工作流。
在工作流的开发部分,模型和测试被开发、验证、合并、审查,并提交给开发人员桌面上的版本控制系统。然后,版本控制系统触发工作流的自动化CI部分。CI工作流程的关键部分是:
构建:源代码和模型成为目标文件和可执行文件。
测试:测试作为质量检验关来执行。
包:可执行文件、文档、工件和其他可交付成果被打包交付给最终用户。
部署:包被部署到生产环境中。
这四个步骤一起被称为CI“管道”。该管道通常是自动化的,根据系统的不同,完成它可能需要几分钟到几天的时间。值得注意的是,在这些步骤中,创建了大量的工件,例如材料清单、测试结果和报告。
CI工作流经常与版本控制系统相关的开发人员工作流配对。在这些工作流中,开发人员通常将更改保存在本地存储库中,并在部署之前使用本地CI管道对更改进行限定。
CI的好处是什么?
实现了CI的团队通常报告以下好处:
- 可重复性。CI管道为构建、测试、打包和部署提供了一致的、可重复的自动化过程。可重复的自动化允许开发人员专注于必要的工作,并节省项目时间。这也是降低风险的一个重要方面,通常是认证的要求。
- 质量保证。手动测试是有效的,但是它通常基于几天前的快照,并且缺乏可重复性。使用CI,更改总是根据最新的代码库进行测试。
- 减少开发时间。具有内置质量保证的可重复过程导致了高质量产品的更快交付。2022世界杯八强谁会赢?自动部署意味着您的代码总是可以用于生产。
- 改进的协作。有了CI,开发人员就有了一个已定义的过程来管理变更集并将他们的代码合并到生产线中。一致的过程使得管理大型团队成为可能,并降低了增加新开发人员的成本。
- Audit-ready代码。CI工作流提供了广泛的审计跟踪。对于通过CI管道进行的每个更改,都有可能确定是谁进行了更改、谁审查了更改、更改的性质、依赖性、测试及其结果,以及在此过程中生成的任何数量的相关报告和工件。
基于模型的设计如何适应CI?
按照设计,CI工作流和工具是与语言和领域无关的。这意味着挑战是教CI工具、系统和过程说话基于模型的设计——换句话说,就是制作Simulink®及相关工具通用语CI工作流程。
这可以通过将基于模型的设计的三个关键组件集成到CI工作流中来实现:验证、代码生成和测试(图2)。基于模型的设计强调早期验证,它映射到CI管道,在构建阶段之前有一个验证阶段。代码生成发生在构建阶段。通过模拟的动态测试和生成代码的静态分析可以在测试阶段完成。
这里是我们如何教CI工作流程说话基于模型的设计:
发展。MATLAB®、Simulink、编码器和工具箱用于开发活动。MATLAB项目用于组织工作、协作以及与版本控制系统的接口。
测试。Simulink Check™用于在模拟和代码生成之前执行模型质量检查。Simulink测试用于开发、管理和执行基于模拟的测试。Simulink Coverage™用于测量覆盖率和评估测试有效性。然后,质量检查、测试结果和覆盖率度量可以作为开发人员检验他们工作的质量闸门。
合并。MATLAB的比较文件和文件夹功能用于比较和合并MATLAB文件。模型比较工具用于比较和合并Simulink模型。
审查。审核是质量过程中变更提交给版本控制系统之前的最后一步。这里回顾了MATLAB脚本和Simulink模型的更改。在提交之前,资格预审的测试结果也作为最终的质量闸门进行审核。
提交。MATLAB项目为版本控制系统提供了一个接口。
核实。Simulink Check是用于本地验证的相同工具,用于CI系统内的自动验证。
构建。MATLAB编码器™,Simulink编码器™和嵌入式编码器®用于为软件在循环(SIL)测试生成代码。
测试。Simulink Test,本地测试使用的相同工具,用于CI系统内的自动测试。
打包和部署。打包是将可执行文件、文档、工件和其他可交付成果打包以交付给最终用户的地方。部署是打包软件的发布。在基于模型设计的工作流程中,这些阶段在组织和组之间差别很大,并且经常涉及到将不同的构建和认证工件捆绑到准备交付给其他团队的产品中。
现代开发工具和实践使开发人员能够创建更健壮的系统,并尽早和经常地测试功能。当CI系统集成到工作流中时,单元级测试和系统级测试就会自动化。这意味着开发人员可以专注于开发新的特性,而不是验证特性已经正确集成。
下面的案例研究描述了集成CI和基于模型的设计的工作流。
案例研究:在CI系统中验证、构建和测试Simulink模型
在本例中,我们使用基于模型的设计和CI对汽车车道跟踪系统执行基于需求的测试(图3)。
我们将使用的管道(图4)在每次Jenkins构建时都要执行。
正在进行的阶段如下:
- 验证标准遵从性:一个MATLAB单元脚本运行一个简单的Model Advisor检查。评估标准确保模型没有未连接的线。
- 构建模型:一个MATLAB单元测试文件为我们的模型构建生产SIL代码。如果构建成功而没有警告,则评估标准通过。
- 执行测试用例:Simulink test中的测试套件使用几个驾驶场景来测试车道跟随控制器。三个评估标准用于验证控制器的满意运行:
- 避免碰撞:自我车在驾驶过程中的任何一点都不会与领头车相撞。
- 安全距离维护:自我车与领跑车的时间间隔在1.5秒以上。两辆车之间的时间差距定义为计算的车头时距与自我车速度的比值。
- 随道:与车道中心线的横向偏差不超过0.2米。
- 包工件:前面的每个阶段都会产生工件,包括一个Model Advisor报告,一个生成的可执行文件,以及一组测试结果,这些结果可以被存档以供将来使用或参考。
工作流步骤
工作流程包括以下步骤(图5):
- 触发在Jenkins中进行构建,观察验证和构建阶段通过。
- 检测Jenkins的测试用例失败。
- 繁殖该问题在我们的桌面MATLAB。
- 修复这个问题在模型中通过放宽评估标准。
- 在本地测试以确保测试用例通过。
- 合并和审查测试分支上的更改。
- 提交更改Git并在Jenkins中触发构建。
- 验证、构建和测试詹金斯。
我们通过CI循环的第一次失败的传递如图左上角所示。它显示了CI测试失败、本地复制、标准放松以及CI工作流的成功完成。
工作流细节
- 我们首先触发在詹金斯选择一个构建现在构建.Simulink Check检查和代码生成通过。
- 接下来,我们检测第二个验证阶段的测试用例失败。测试用例
LFACC_Curve_CutInOut_TooClose
在测试套件LaneFollowingTestScenarios
不符合评估标准。
- 为了更好地理解失败,我们繁殖利用Simulink测试对故障进行局部测试。我们打开测试文件
LaneFollowingTestScenarios.mldatx
并运行测试用例LFACC_Curve_CutInOut_TooClose
.注意,它不符合安全距离评估标准。需要更灵活地确定领头车和自我车之间的时间差距。
- 有了对问题的理解,我们现在修复这个问题.我们打开
LaneFollowingTestBenchExample.slx
模型并导航到碰撞检测/测试评估测试序列块。第一个评估断言,自我和领头车之间的时间差距不应低于1.5秒,每次不应超过2秒。
GlobalAssessments确保自我车和领头车之间的时间间隔不低于% 1.5s,每次持续2秒以上。验证(持续时间(time_gap < 1.5,证券交易委员会) < 2);验证未检测到碰撞验证(~碰撞);验证与车道中心线横向偏差的绝对值一次不超过5s不超过0.2m %。验证(持续时间(abs (lateral_deviation) > 0.2,证券交易委员会) < 5);
这种评估对正在测试的侵略性驾驶机动的限制太大。出于本例的目的,我们放宽了评估标准,以确保时间间隔不会在每次超过5秒的情况下下降到0.8秒以下。
GlobalAssessments确保自我车和领头车之间的时间间隔不低于% 0.8s,每次不超过5秒.验证(持续时间(time_gap < 0.8,证券交易委员会) < 5);验证未检测到碰撞验证(~碰撞);验证与车道中心线横向偏差的绝对值一次不超过5s不超过0.2m %。验证(持续时间(abs (lateral_deviation) > 0.2,证券交易委员会) < 5);
- 在我们的模拟中,这个问题似乎是固定的。确认,我们在本地测试,保存模型并在测试管理器中重新运行测试。注意,它通过了新的评估标准。
- 我们已经解决了这个问题,并在当地进行了验证。我们现在使用模型比较工具来审查在将更改提交给版本控制之前。
我们还可以使用模型比较工具的发布特性来检查代码。
- bug修复后,我们将这些更改推到带有MATLAB项目的GitLab中,添加一个提交消息来注意评估标准的更改。
然后我们注意到GitLab中的最新提交。
GitLab在Jenkins中自动触发构建。Jenkins项目仪表板显示构建状态和进度。
- Jenkins构建运行。我们看到验证、构建和测试现在通过管道阶段。
我们现在可以启动一个合并请求,将测试分支中的更改合并到主分支中。在GitLab,下存储库我们选择分支机构然后单击合并请求在测试分支上的最新提交旁边。
我们完成表单并提交合并请求。
作为分支的所有者,我们可以通过单击合并按钮。所有更改现在都在主分支上捕获。
举例说明:工具、资源和需求
以下部分概述了帮助您入门的资源、您将需要的工具以及应该如何配置它们。
配置系统
Jenkins是我们的CI系统,GitLab是我们的版本控制系统。MATLAB、Jenkins和GitLab必须配置为一起工作。下面的教程将帮助您进行设置。
这些教程专门针对GitLab和Jenkins,但这些概念也可以应用于其他版本控制和CI系统。
所需的工具
本示例需要以下工具:
- 詹金斯安装版本为2.7.3或以上。Jenkins用于持续集成。
- Jenkins的MATLAB插件版本1.0.3或更高版本。MATLAB、Simulink和Simulink Test都利用这个插件与Jenkins进行通信。在GitHub上了解更多.
- 额外的插件要求:
- GitLab帐户。GitLab用于源代码控制,并作为云服务提供。MATLAB项目包括一个与GitLab通信的Git接口。
CI的许可考虑
如果您计划在多个主机或云上执行CI,请联系continuous-integration@mathworks.com寻求帮助。注意:像MathWorks这样的转换产品2022世界杯八强谁会赢?®编码器和编译器产品可能需要客户端访问许2022世界杯八强谁会赢?可证(cal)。
点击将项目添加到源代码控制中.
- 点击转换.
- 点击开放项目当完成。
该项目现在处于本地Git源代码控制之下。
步骤2。提交更改并将本地存储库推到GitLab
- 在Project选项卡上,单击远程.
- 在GitLab中指定远程源的URL。
点击验证要确保成功连接到远程存储库,请单击好吧.该项目现在配置为使用GitLab推送和拉取更改。
- 点击提交执行初始提交。
- 点击推将所有更改从本地存储库推送到远程GitLab存储库。
- 刷新GitLab仪表板并观察MATLAB项目的内容。
步骤3:创建测试分支
在此步骤中,我们创建一个测试分支,用于在与主分支合并之前测试和验证更改。
- 点击分支机构.
- 扩大分支和标签的创建部分,将分支命名为“Test”,然后单击创建.
- 观察测试在分支浏览器中。从Test分支单击开关然后关闭.
- 在MATLAB选择推将这些更改推送到GitLab,并观察GitLab中的Test分支。
- 将生成触发器配置为在向测试在GitLab分支。在Build Triggers部分中选择先进的>秘密令牌.GitLab使用这个令牌来请求构建并使用Jenkins进行身份验证。记下秘密令牌和GitLab的webhook。
- 配置构建环境。选择使用MATLAB版本并输入MATLAB根。
- 配置构建步骤。
点击添加构建步骤并选择运行MATLAB命令.输入的命令openProject(“SltestLaneFollowingExample.prj”);LaneFollowingExecModelAdvisor
打开项目并运行模型顾问检查。
点击添加构建步骤并选择运行MATLAB命令一次。输入命令:openProject(“SltestLaneFollowingExample.prj”);LaneFollowingExecControllerBuild
点击添加构建步骤并选择MATLAB运行测试.选择利用测试结果而且Cobertura代码覆盖率以完成构建配置。
此操作解析TAP测试结果,并在选择TAP扩展测试结果时使其可见。输出包含执行的测试用例的概述,结果摘要,以及来自MATLAB控制台的日志。
TAP插件还收集最新测试执行的结果,并显示如下所示的运行状况图。您可以通过单击图表访问以前的任何构建。
步骤6。发布HTML报告
点击添加构建后操作>发布HTML报告.输入将在其中发布HTML报告的相对根路径,以及该路径中索引页的文件名。
添加要发布的HTML报告的数量。在这个场景中,有两个web报告:模型顾问摘要和代码生成报告。这些是用MATLAB内置函数创建的标准报告。您可以添加自定义HTML报告。
您将在主Jenkins作业页面上找到一个报告链接,对应于每个HTML报告的最后一个构建。如果你激活了发布选项下的“总是链接到上一次构建”复选框,插件将发布最后一次构建的报告,而不管构建状态如何。如果这个复选框没有被激活,插件将只链接到最后一个“成功”的构建。
步骤7。配置GitLab在Jenkins中触发构建
配置GitLab,当主分支上出现新推送时,在Jenkins中触发自动构建。要做到这一点,请导航到设置>人则.在Build Trigger配置中使用webhook URL和Jenkins提供的秘密令牌并进行选择推动事件.
注意:在URL部分使用完全限定的域名来代替localhost,以便GitLab能够找到Jenkins安装。
在测试下拉,选择推动事件测试集成。GitLab将显示“Hook executed successfully: HTTP 200”的消息,Jenkins将开始构建。
步骤8。配置Jenkins-to-GitLab身份验证
要在GitLab上自动发布Jenkins构建状态,必须配置Jenkins- To -GitLab身份验证。
- 在GitLab上创建一个选择API范围的个人访问令牌。
- 复制令牌并在Jenkins配置系统下创建GitLab连接。
注意:连接可以在多个Jenkins作业上重用,如果用户至少具有“维护者”权限,则可以全局配置连接。
第9步。将Jenkins整合到GitLab管道中
要将Jenkins集成到GitLab管道中,必须在Jenkins中配置GitLab连接,并将作业状态发布到GitLab。
- 在Jenkins作业的General部分选择GitLab Connection。
- 添加一个构建后操作,将构建状态发布到GitLab。
注意:该操作没有参数,将使用现有的GitLab连接在GitLab上发布构建状态,并为每个提交和合并请求创建双向跟踪。
步骤10:可视化基于需求的测试度量(R2020b)
基于需求的测试指标让您评估基于需求的测试活动的状态和质量。使用模型测试仪表板可以可视化度量结果。
- 创建一个名为
collectModelTestingResults.m
基于下面所示的函数。该函数将初始化度量引擎基础结构,并收集所有可用的模型度量。
如果存在('metric'), R2020a中增加了% metric功能。“ConditionCoverageBreakdown”“CoverageDataService”…“DecisionCoverageBreakdown”“ExecutionCoverageBreakdown”…“MCDCCoverageBreakdown”“OverallConditionCoverage”…“OverallDecisionCoverage”“OverallExecutionCoverage”…“OverallMCDCCoverage”“RequirementWithTestCase”…“RequirementWithTestCaseDistribution”“RequirementWithTestCasePercentage”…“RequirementsPerTestCase”“RequirementsPerTestCaseDistribution”…“TestCaseStatus”“TestCaseStatusDistribution”…“TestCaseStatusPercentage”“TestCaseTag”… "TestCaseTagDistribution" "TestCaseType"... "TestCaseTypeDistribution" "TestCaseWithRequirement"... "TestCaseWithRequirementDistribution" "TestCaseWithRequirementPercentage"... "TestCasesPerRequirement" "TestCasesPerRequirementDistribution"... ]; % collect all metrics for initial reconcile E = metric.Engine(); execute(E, metricIDs); end end
- 将此文件添加到项目和路径中。
- 配置Jenkins通过调用new来收集度量结果
collectModelTestingResults
函数两次。第一个调用初始化与Simulink Test Manager的度量集成。第二部分使用导出的Simulink Test Manager结果收集度量结果。- 点击添加构建步骤并选择运行MATLAB命令一次。输入命令:
openProject(“SltestLaneFollowingExample.prj”);collectModelTestingResults
将此构建步骤定位在MATLAB运行测试构建步骤。 - 点击添加构建步骤并选择运行MATLAB命令一次。再次输入命令:
openProject(“SltestLaneFollowingExample.prj”);collectModelTestingResults
将此构建步骤定位在MATLAB运行测试构建步骤。
- 点击添加构建步骤并选择运行MATLAB命令一次。输入命令:
- 检查Simulink测试管理器结果在MATLAB运行测试构建步骤。
- 将度量结果存档到派生目录中。您还必须归档导出的测试管理器结果,因为当加载回MATLAB中时,它们将允许Metric结果的完整导航。
点击添加post-build行动并选择存档的工件。输入路径/ * *, matlabTestArtifacts / * .mldatx
将保存到该目录的所有文件存档。
注意:要在MATLAB中查看这些结果,请执行以下操作:
- 下载存档的工件(派生目录和测试结果.mldatx文件)。
- 提取并复制到用于运行CI作业的同一版本的项目的本地副本中。
- 在MATLAB中打开项目并启动模型测试仪表板。
CI生成的结果将显示在指示板.
詹金斯®是LF Charities Inc.的注册商标。
2022年出版的