基于MBD 的软件品质保证技术

基于MBD的软件是什么？
基于MBD的软件是基于模型开发的软件，主要应用于汽车、电子电气、机器人、航空、航天等行业。
​​​
与使用现有代码开发程序的方法不同，MBD 方法包括首先开发模型，将模型转换为代码，然后基于转换后的代码开发软件。
​​​
基于MBD的软件开发过程首先收集需求、执行、执行规范，对其建模，通过建模生成自动代码，并根据生成的自动代码创建目标代码。

<图1> MBD开发流程
这种基于 MBD 的 SW 开发具有以下与现有 SW 开发方法不同的优点。
​​​

1. 通过在系统开发的各个阶段不断地进行测试和验证，可以降低冗余实施的成本。
   2）可以在建模和仿真阶段测试系统算法
2. 可以利用已经设计好的模型
3. 可以减少实施阶段所需的（人力、时间）

基于MBD的软件质量保证方案

<图2>基于模型的软件开发认证流程
<图2>摘自MathWorks提供的文档，该工具开发了MATLAB工具，主要用于模型开发，与模型质量验证有关，可以查看是否有。
​​​
<图2>中M2对应的部分可以进行模型级别的模块测试验证，M1对应的部分可以进行模型级别的模型审查和静态验证。
​​​
转码后有C1和C2。 在C1中，通过模型和代码之间的背靠背测试进行验证，在C2中，当需要的功能从模型转换为代码时，测试该功能在该功能中是否正常执行.可以保证质量。

模型静态与动态验证
模型验证方法可以分为静态验证和动态验证。
​​​
模型静态验证，是一种通过 MAAB 和 dSPACE 等建模公司提供的建模规则指南来验证模型规则是否符合的方法。此外，还有一种模型质量指标检查方法，可以分析模型中实际使用了哪些组件以及使用了多少。
​​​
综上所述，在模型静态验证部分，可以看出有两种方法：建模引导规则检查和模型质量指标检查。
​​​
与模型静态验证不同，模型动态验证可以通过比较在执行实际模型时的输出值来进行验证。
​​​
通过根据用户输入预期结果值是否与实际模型结果值匹配来动态验证模型。此外，通过检查模型的覆盖率，可以调查未完成的部分并通过模型习惯或方法来确保质量，以确保该部分的覆盖率。

[ ISO 26262 ]

<图3> ISO 26262汽车功能安全国际标准

ISO 26262汽车功能安全国际标准文件中也规定了模型质量的保证。
​​​
表 1 的第 1a 项共有 12 个部分，规定了通过模型度量检查进行质量保证的需要，表 12 的第 1e 项和 1f 项分别规定了模型动态验证和模型静态验证的需要。

<图4> Overview of the intensity of tests on function model level

您可以看到许多实际开发模型的开发人员都在进行大量称为 MIL 测试的动态验证和称为 Guideline Checker 的模型静态验证。
模型品质保证方法(静态测试)
模型静态验证是衡量建模规则的合规性和质量指标。
​​​
在各个学科中，汽车行业的行业标准建模规则如下：

• MISRA AC SLSF
• MISRA AC TL
• MathWorks Automotive Advisory Board (MAAB, Mathworks, ~ 2019b)
• MathWorks Advisory Board (MAB, Mathworks, 2020a ~)
• Modeling Guidelines for High-Intergrity System (Mathworks)
• Modeling Guidelines for Code Generation (Mathworks)
• dSPACE Modeling Guideline

[01.标准模型的规则]

<图五> MISRA AC SLSF, 标准模型的规则

▶ MISRA AC SLSF 012 规则提供了在模型中使用Switch块时如何设置Switch块的选项和初始值的指南。
​​​
▶ MISRA AC SLSF 053 规则提供了关于如何设置状态和流中转换位置以及转换中代码位置的指南。
​​​
▶ 建模规则提供了在使用模块时如何使用模块选项以及在开发模型时如何使用模块以提高可读性和便利性的指南。

[02.模型质量指标]

在模型质量指标的情况下，有几个测量项目，它们可以大致分为四类。
​​​
● 关于模型尺寸
模块数量、子系统数量、库数量、参数数量、状态流程图数量、输入数量、
输出的数量，模型中运行的功能代码行数等等……
​​​
● 模型结构相关
复杂度、相似库的数量、相似子系统的数量、模型组成比（外部库、通用块）、内聚度、
粘合等…
​​​
● 关于模型的可读性
没有描述或名称的块数，数据和模型结构层次结构的数量等…
​​​
● 指导方针
模型警告数量、违反标准指南规则的数量等。

[03.复杂度(Cyclomatic Complexity]

在代码的情况下，复杂性是通过计算生成代码中的二进制节点数加 1 来衡量的。 而在模型的情况下，复杂性是通过一个计算公式来衡量的，该公式将决策块加 1。 这里，决策块是决策分支点出现在块内的块。

<图6> Model Cyclomatic Complexity计算示例
在<图6>的例子中，由于If模块和Mulitport Switch模块中存在Decision分支，因此4的值加上对应模块的数字被测量为模型中的复杂度并向用户提供信息.
​​​
在代码复杂度的情况下，程序的风险是通过分为四类来确定的，模型复杂度也是一样的。 如果模型复杂度高，后期通过Auto Code Generation生成的代码可能会增加代码复杂度，降低模型复杂度可以保证生成代码SW的质量。

模型品质确保方法(动态测试)
模型动态验证是指将模型模拟的输出和期望值与用户提供的输入进行比较。
​​​
在模型动态验证过程中，设计测试用例，并根据数值，提前准备好称为测试工具的测试值。
​​​
然后通过仿真验证结果。
[01.测试种类]
​
动态验证测试类型包括 MIL 测试、SIL 测试、PIL 测试和背靠背测试。
​​​
● MIL（模型在环）测试
它是在设计模型上进行的测试，用于在模型单元中进行模拟测试，需要预测试环境。
​​​
● SIL（软件在环）测试
与 PIL 测试相比，目前使用的 Host PC 被用作处理器而不是实际的目标硬件，将开发的软件模型转换为适合目标硬件的代码。
​​​
● PIL（处理器在环）测试
与 SIL 测试相比，实际目标硬件（评估板）用于提升应用程序。在此过程中，可以识别编译器和处理器的问题。
​​​
● 背靠背测试
这是验证开发的模型和生成的代码之间的对应关系的测试，它是使用相同的输入数据对正在开发的模型和自动生成的代码检查输出值是否一致的测试。 Back-To-Back 测试之所以比其他测试重要一点，是因为 ISO 26262 文档中有一个项目强调 Back-To-Back 测试。

<图8>ISO 26262–Back To Back测试项目

[02.模型覆盖率]

模型覆盖率是一种度量，它允许您针对特定测试用例测量模型的执行路径，并确定它是完全通过了该块还是通过了所有用例。
​​​
模型覆盖有多种类型，如Decision、Condition和MC/DC，其中Decision和Condition的覆盖被广泛使用。
​​​
决策覆盖率可以针对其输出分支由 True/False 拆分或其分支由数据控制的块来衡量。在IF块的情况下，通过实际的IF和else进行分支，将分支分为if true和else false，这样就可以衡量通过相应分支语句的决策覆盖率。
​​​
在 Abs 块的情况下，由于分支是根据输入值的正值或负值在内部控制的，因此该块也可以作为决策覆盖的目标进行测量。

<图9>if Block/Abs Block
在条件覆盖的情况下，测量输入值为 True 或 False 的每个输入端口是否满足所有条件。
​​​
根据逻辑运算符 AND 的输入值 True/False 的输入方式，可以通过测量输出的条件值来测量可以达到多少模型覆盖率。

<图10> Logical Operator AND
结语
MBD，Model Based Design SW作为解决嵌入式行业快速发展的专家供给不足和国内解决方案缺乏的新软件而备受关注。
​​​
随着基于 MBD 的 SW 在 IT 行业中的比例逐渐增加，通过模型验证来确保 SW 的质量正在成为重要的一环。
​​​
目前，SureSoft已经建立了模型的静态/动态验证流程，并积极与OEM公司开展验证活动，降低模型验证成本，并通过自主开发工具提供高效的缺陷检测服务。