基于模型开发的嵌入式软件质量指标分析与研究

崔梦洁 杨涛 刘在强 徐高祥 胡江舟

摘要： 本文旨在提出基于模型开发的汽车嵌入式软件的模型质量指标。当前，汽车电控系统产品的开发主要采用基于模型设计的开发过程。在此过程中，对开发的模型质量进行评价，建立统一的评价标准，能够更有效地把控软件质量，从而确保开发出的控制软件符合规范要求、无设计缺陷，并完全满足功能需求。

关键词：嵌入式；模型开发；质量指标

中图分类号：U467 DOI ：10.20042/j.cnki.1009-4903.2024.01.009

0 引言

当前各大主机厂主要采用V 流程开发模式来开发汽车嵌入式电控单元。在这一开发过程中，基于模型设计的软件开发及测试技术得到了广泛应用。在控制策略模型的开发阶段，依次进行MIL、SIL、PIL、HIL 等测试验证，以确保软件质量的有效控制。这种开发模式相对于传统开发方式，显著提升了软件开发效率，缩短了项目开发周期，从而增强了产品的竞争力。尤其是在模型测试阶段，若进行完整充分的测试，可以解决绝大多数的软件问题，有效降低后续的控制器台架测试、实车测试等阶段的测试成本，为后续测试环节提供基础的软件功能保障。

1 模型质量评价方法

模型的开发质量通过MIL 测试过程来衡量和评级。MIL测试即模型在环测试，被测对象是控制器的算法模型。在Simulink 模型中，我们建立控制算法模型和被控对象模型，将二者连接形成闭环，进行模型层面的闭环测试。

模型测试的目的在于验证控制模型是否满足预期设计需求，同时对设计的模型进行规范性检查，力求达到最优配置，检查模型设计的冗余和缺陷，评估模型质量，以保障控制器软件产品的开发质量，确保所有问题在开发前期得到测试验证。

该阶段是在模型开发完成，运行仿真通过后进行的测试环节，其目的在于对开发的功能模型进行规范性、功能性测试，确保模型合规、无设计缺陷、满足完整功能需求。

基于以上要求，通过模型测试过程，我们可以评价模型的开发质量，具体从模型的合规性、复杂度、覆盖度、鲁棒性、功能性等方面对模型质量进行评价。

1.1 模型合规性评价

模型合规性是用于验证模型是否符合编码规范。编码规范是开发工程师应该遵循的规则，涉及命名约定、建模外观、信号数据，以及建模模式、模型架构、代码生成配置与已知的建模缺陷等。引入编码标准有助于实现控制系统模型的简单、共同理解，同时降低软件维护成本。

1.2 模型复杂度评价

模型复杂度是衡量模型中各模块的结构复杂程度，表现为独立路径的数量，即覆盖所有可能情况所需的最少测试用例数。

复杂度高的模型判断逻辑复杂，可能质量低且难于测试和维护。

复杂度与程序中可能出现的错误和高的圈复杂度密切关系。复杂度指标的阈值约束有助于指导模型优化，降低模型负载率。

复杂度度量的是程序中线性独立路径的数量。

降低模型复杂程度的方法包括：

（1） 模型重构：使用可重用库重构重复部分，提高可维护性并降低设计复杂度。

（2） 模型逻辑更改：重新组织函数逻辑，改变算法控制；简化條件表达式；简化函数调用。

1.3 模型覆盖度评价

模型覆盖度基于分支路径判断，重点在于评估模型是否存在永不可达分支路径，以在满足功能前提下简化设计，提高结构覆盖。覆盖度反映测试用例对模型逻辑结构路径测试的完成程度，适用于结构测试用例。完整的结构测试用例应对模型或状态机内的每条路径进行唯一条件测试，且与其他路径条件不冲突。

模型覆盖的类型主要包括决策覆盖（DC）、条件覆盖（CC）和改进覆盖/ 决策覆盖（MCDC）。这些方法用于度量模型结构覆盖率，反映和识别未经测试的模型设计、不可测试的设计以及一些非预期的模型设计。

1.4 模型鲁棒性评价

模型鲁棒性主要针对设计缺陷进行检查评估，在仿真前检测运行时和建模错误，如数据溢出、除零、数组越界、死逻辑、浮点错误等。采用形式化的检测方法，在静态环境下评价功能模型的基本模块，重点检测Add、增益、限幅、查表等模块，确保模型健壮性。鲁棒性验证可防止数值边界或错误使用导致的意外结果或仿真错误。

1.5 模型功能性评价

模型功能性评价验证软件实现的功能是否满足功能规范及需求程度。功能性可细分为完备性和正确性。完备性指模型功能完整、齐全，应不少于且符合需求规定的明确和隐含功能。正确性指模型应得到正确或相符结果。功能性评价依据MIL测试结果，针对每种功能需求设计典型测试用例，评价实际结果与预期结果的符合程度。因此，测试用例的全面性、正确性、典型性及权威性是功能性评价的关键。功能是模型实现的基础，模型功能性是模型最重要的质量特征之一。

2 模型质量实例应用

本文以某制动系统功能为例， 根据功能规范， 使用MATLAB 2022b 中的Simulink 进行仿真模型搭建。模型搭建完成后，采用上文所述的方法对模型的开发质量进行测试。

2.1 模型质量测试工具介绍

在本文中，我们利用Simulink 工具箱中的Simulink Test工具箱对模型功能性进行评价测试。

2.2 模型功能性测试

根据功能规范，制动功能的逻辑如下：

激活条件（ 同时满足） ：

1） 当钥匙ON 档有效且车速大于0 ；

2） 制动使能信号有效。

执行动作：

制动激活信号（BrkActSig） 置为有效。

退出条件（ 满足任一条件） ：

1） 钥匙ON 档无效且车速小于3 ；

2） 制动使能信号无效。

退出动作：

制动激活信号（BrkActSig） 置为无效。

在模型功能性测试阶段，我们搭建测试框架并编写测试用例以验证模型功能。具体测试用例如下：

测试步骤一：

在0.6～1.2 s 内，满足激活条件，输入钥匙ON 档有效信号，设置车速为10 m/s，同时提供有效的制动使能信号。

预期结果一：

在0.6～1.2 s 内，制动激活信号（BrkActSig） 设置为有效状态。

测试步骤二：

在1. 2～1. 4 s 时，满足退出条件一，输入钥匙ON 档无效信号，并将车速降低至1 m/s。

预期结果二：

制动激活信号（BrkActSig） 应置为无效状态。

测试步骤三：

在1.4～1.6 s 时，再次满足激活条件，输入钥匙ON 档有效信号，设置车速为8 m/s，并提供有效的制动使能信号有效。

预期结果三：

在1.4～1.6 s 内，制动激活信号（BrkActSig） 应再次置为有效状态。

测试步骤四：

在1.6～2.0 s 时，满足退出条件二，将制动使能信号设置为无效状态。

预期结果四：

制动激活信号（BrkActSig） 应置为无效状态。

如圖1，其中蓝色为预期测试用例结果，棕色为实际输出。

实际在测试结果中发现在1.6 s 时测试用例未通过，测试结果制动激活信号为有效。

通过分析测试用例，我们定位到问题根源在于使能子系统中Outport 模块在默认禁用状态下，其输出会保持上一时刻的状态。这导致了制动激活信号在使能子系统未使能后仍然保持有效。为了解决这一问题，我们将Outport 模块的禁用时输出设置为了重置，并设置了初始输出为0，如图2 所示。经过模型修改后，我们重新进行了测试，结果显示测试通过，如图3 所示。

在完成模型的功能测试后，我们进一步进行了模型的功能测试覆盖度评价。决策覆盖度（DECISION） 用于分析模型中表示决策的元素，它是遍历的条件与仿真总数的百分比。条件覆盖度（CONDITION） 则用于判断测试中的条件是否涵盖了所有情况，当测试用例使模型中逻辑的每个输入的条件在仿真期间至少一次满足，至少一次不满足，表示测试用例实现了完全覆盖。

测试结果显示，所有测试用例均被执行并通过测试。如图4 所示，决策覆盖度为88%，条件覆盖度为100%，改进覆盖/ 决策覆盖度为100%，这些指标均满足测试覆盖度的要求。

3 总结

本文所提出的基于模型设计的嵌入式软件模型质量指标，具有全面且细致的特点。这些指标从模型的规范性、功能完备性等多个维度进行综合评价，从而实现对软件模型质量的准确评估。在具体的项目开发中，可以根据不同的开发目标，灵活设计相应的指标值，从而确保模型的开发质量达到预定标准。这种做法不仅能够保障整个项目的软件质量，也为后续的软件更新迭代提供了坚实的质量保障。

参考文献

[1] 刘杰等编著.基于模型的设计MCU 篇[M].北京航空航天大学出版社.2011.1.

[2] 李军龙.一种基于SIMULINK 模型的测试用例生成子系统的设计与实现[J].北京大学.2014.

[3] 李哲帅.基于ISO 26262 标准的高压共轨ECU 控制模型设计及测试研究[J].浙江大学.2018.3.1.

[4] 李勇等.新能源商用车控制软件质量提升研究[J].客车技术与研究，2020（3）：12-15.