2. Simulink模型测试基础

在Simulink中设计测试用例,第一步不是打开Test Manager或编写脚本,而是先读懂模型本身。测试用例的输入端口、观测点、判据阈值、执行时机,全部由模型的层次结构、信号语义、采样时间、状态迁移和子系统边界决定。如果对模型结构理解偏差,测试用例即使运行通过,也可能没有真正覆盖目标逻辑。本节围绕模型层次、信号线、采样时间、状态机、子系统五个基础对象,说明测试用例在模型级验证中的位置与关注点。

一、模型层次决定测试的“作用域”

Simulink模型天然是分层的:顶层(Top Level)通常只保留输入输出接口、信号路由和若干子系统;功能细节被封装在下层子系统中。测试用例的作用域必须与模型层次对齐。对顶层做测试,关注的是接口时序、信号范围、整体功能是否满足需求;对某个子系统做测试,关注的是该子系统内部算法、状态逻辑和边界条件。两者不能互相替代。

例如一个电机控制模型,顶层包含“指令解析”“电流环”“PWM输出”三个子系统。若测试用例只从顶层注入转速指令并观测PWM占空比,那么电流环内部的限幅、抗积分饱和逻辑是否被触发,是无法判断的。此时需要把测试用例下沉到“电流环”子系统,直接给定Id/Iq参考值和反馈值,观测PI输出与限幅状态。因此,测试用例设计前必须明确:本次验证的目标对象位于哪一层,输入从哪里注入,观测点在哪里采集。

二、信号线是测试用例的“接口契约”

信号线不只是连线,它携带了数据类型、维度、采样时间、单位、是否虚拟总线等属性。测试用例的输入信号必须与模型端口属性一致,否则会出现类型不匹配、维度错误或采样时间冲突。常见关注点包括:

  • 数据类型:double、single、int8、boolean、fixdt等。测试用例的激励信号若用double去驱动boolean端口,Simulink会报错或自动转换,可能掩盖真实问题。
  • 维度:标量、向量、矩阵。向量端口需要按元素给定激励,不能只给一个标量。
  • 总线信号:虚拟总线与嵌套总线在测试中需要按Bus Object逐元素赋值,观测时也要按元素解析。
  • 信号单位与物理量:转速[rpm]、电流[A]、电压[V]等,测试用例的判据阈值必须带单位理解,避免量纲错误。

在测试用例中,建议把每个输入端口和观测端口整理成“端口—数据类型—维度—采样时间—单位—有效范围”的接口表,作为用例设计的基础依据。

三、采样时间决定测试的“时间分辨率”

Simulink支持多采样率模型:不同子系统可以运行在不同采样周期,例如控制器1 ms、被控对象10 ms、监控模块100 ms。测试用例的激励步长、仿真步长和观测采样必须与模型采样时间协调。若测试激励的更新周期大于模型采样周期,模型会在多个采样点保持同一输入,可能漏掉快速动态;若激励更新周期远小于模型采样周期,则大量激励点不会被模型真正采样,造成无效计算。

测试用例中应明确:仿真求解器类型(定步长/变步长)、基础采样时间、各子系统采样时间、测试激励的更新周期。对于定步长离散模型,激励更新周期通常取基础采样时间的整数倍;对于变步长模型,需要设置最大步长以保证不跳过状态迁移。采样时间冲突是多速率模型测试中最常见的失败原因之一。

四、状态机与子系统:测试关注点的分界

Stateflow状态机与子系统是模型中最需要“针对性测试”的对象。状态机的测试关注点包括:状态迁移条件是否在边界值下正确触发、默认迁移是否合理、并行状态是否互斥、历史节点是否恢复正确、状态动作与条件动作的执行顺序。子系统的测试关注点则包括:使能/触发子系统的激活条件、重置行为、原子子系统与虚拟子系统的执行语义差异、函数调用子系统的调用时机。

测试用例在模型级验证中的位置可以概括为:以模型层次为作用域,以信号线为接口契约,以采样时间为时间基准,以状态机和子系统为覆盖重点,最终形成从激励注入到结果判读的闭环。下面用一张结构关系图表示这些对象与测试用例之间的对应关系。

Simulink模型测试基础对象与测试用例对应关系 模型基础对象 模型层次 顶层 / 子系统 / 原子子系统 信号线 类型 / 维度 / 总线 / 单位 采样时间 基础周期 / 多速率 / 求解器 状态机 迁移 / 默认 / 并行 / 历史 子系统 使能 / 触发 / 函数调用 测试用例 激励注入(输入端口) 观测采集(输出端口) 判据与阈值 执行时机与步长 测试关注点 作用域对齐 顶层接口 vs 子系统内部 接口一致性 类型 / 维度 / 总线匹配 时间分辨率 激励步长与采样周期协调 状态覆盖 迁移边界 / 默认 / 历史 激活与重置 使能 / 触发 / 调用时机 结果判读 → 覆盖评估 → 用例迭代

五、测试用例在模型级验证中的位置

把上述对象串起来,测试用例在模型级验证中处于“承上启下”的位置:向上承接需求与模型接口定义,向下驱动仿真执行与结果判读。一个完整的模型级测试用例至少包含以下要素:

要素 说明 与模型对象的对应
测试目标 本次验证的功能点或状态迁移 模型层次、状态机
输入激励 端口值、时间序列、更新周期 信号线、采样时间
观测点 输出端口、内部信号、状态变量 信号线、子系统输出
判据 期望值、容差、时序约束 信号单位、采样时间
执行配置 求解器、步长、仿真时长 采样时间、模型配置

以“使能子系统重置行为”为例,测试用例可以这样设计:在t=0.5 s时使能信号由1变为0,观测子系统输出是否在下一个采样点归零;若模型采样时间为10 ms,则期望归零时刻应在0.51 s以内。若实际输出在0.52 s才归零,说明重置逻辑存在一个采样周期的延迟,需要进一步检查使能端口的采样时间是否与子系统内部一致。这个例子说明,测试用例的判据必须结合采样时间和子系统语义,不能只看最终数值。

实践建议:在建立测试用例之前,先用Simulink的“Model Explorer”或“Signal Properties”检查每个端口的采样时间、数据类型和维度,并记录到接口表中。对于Stateflow,使用“Stateflow Editor”的“Coverage”视图确认状态和迁移是否被覆盖。测试用例的输入激励建议用Signal Builder或Signal Editor组织,便于按时间片段管理。
常见误区:把顶层测试通过等同于所有子系统测试通过;忽略虚拟子系统与原子子系统的执行顺序差异;在多速率模型中用单一采样时间设计激励,导致快速子系统激励不足或慢速子系统激励冗余。这些都会使测试用例的覆盖结论不可靠。

总结来说,模型层次、信号线、采样时间、状态机、子系统这五个对象,分别对应测试用例的“作用域、接口、时间基准、覆盖重点、激活条件”。测试用例不是独立于模型之外的脚本,而是模型结构在验证维度上的映射。只有先把模型读清楚,才能把用例设计得准、跑得稳、判得明。