3. 模型静态检查基础

在 MBD 开发流程中，动态仿真只能覆盖被激励到的场景，而大量缺陷其实藏在模型结构本身：未连接的端口、隐式类型转换、采样时间冲突、代数环、命名不规范、子系统接口不一致等。这些问题在仿真时可能不报错，却会在代码生成、集成或后期维护时集中爆发。静态检查的价值就在于不运行模型，仅通过规则扫描模型的结构、参数与配置，提前把这类缺陷定位出来。本节围绕三条主线展开：Model Advisor 的检查机制、MAAB 规范作为规则来源、以及如何把检查结果转化为可定位、可修复的缺陷清单。

一、静态检查在 MBD 流程中的位置

静态检查通常发生在模型通过基本编译（Update Diagram）之后、动态仿真与代码生成之前。它不依赖输入激励，因此可以在模型尚未完成全部功能时就开始执行。检查对象包括：模块连接关系、信号属性（数据类型、维度、采样时间、单位）、模型配置参数（求解器、诊断设置）、命名与层次结构、以及是否符合企业或行业建模规范。检查结果一般分为三类：Pass（通过）、Warning（警告，建议修改）、Fail（失败，必须修改）。理解这三类结果的判读逻辑，是后续缺陷定位的基础。

二、Model Advisor 的工作机制

Model Advisor 是 Simulink 内置的静态检查框架，它把检查规则组织成检查树（Check Tree），按“按任务组织”或“按产品组织”两种视图呈现。每个检查项本质上是一段 MATLAB 代码，读取模型对象后返回 Pass/Warning/Fail 及定位信息。执行方式有两种：图形界面中勾选检查项后点击 Run Selected Checks；或在命令行中调用：

% 以编程方式运行 Model Advisor 检查
ma = ModelAdvisor.Root;
ma.runCheck('mathworks.maab.db_0140', 'MyModel');
% 或批量运行某个检查组
ModelAdvisor.run('MyModel', 'Configuration', 'ModelAdvisorDemo');

检查结果会给出模块的完整路径，例如 MyModel/Controller/Sum1，双击即可在模型中高亮定位。对于 Warning 类结果，需要结合设计意图判断：例如“未使用的信号”在某些调试模型中是有意保留的，此时可通过 ModelAdvisor.setCheckResult 或检查项配置将其标记为“已审查”，而不是盲目删除。

三、MAAB 规范作为规则来源

MAAB（MathWorks Automotive Advisory Board）规范是汽车行业广泛采用的建模指南，涵盖命名、接口、结构、数据类型、状态机等多个方面。它本身不是工具，而是规则集合，Model Advisor 中的 MAAB 检查项就是对这些规则的自动化实现。常见的 MAAB 规则包括：

• 命名规范：信号名使用小写字母加下划线，避免使用保留字；模块名应能反映功能。
• 接口规范：子系统输入输出端口应显式定义数据类型与维度，禁止依赖隐式继承。
• 结构规范：避免过深的层次嵌套，建议不超过 5 层；禁止在多个位置重复定义同一常量。
• 数据类型规范：禁止在信号线上出现 double 与 single 的隐式混用，必须显式插入 Data Type Conversion。

在实际项目中，企业通常会在 MAAB 基础上裁剪出项目级规则集，例如强制要求所有 Gain 模块的增益参数必须来自工作区变量而非硬编码数值。这类规则可以通过自定义检查脚本加入 Model Advisor，形成可复用的检查配置。

四、静态分析工具链与缺陷定位

除 Model Advisor 外，Simulink Check、Simulink Coverage 中的静态部分、以及第三方工具（如 BTC EmbeddedSpecifier 的静态规则）也可参与检查。它们的共同点是：输出结构化结果，包含规则 ID、严重级别、对象路径、建议修复方式。缺陷定位的关键在于把“规则 ID”翻译成“模型中的具体对象”。

以“隐式数据类型转换”为例，检查结果可能提示：

Check: mathworks.maab.na_0007
Result: Warning
Object: MyModel/Plant/Gain2
Detail: Output data type 'double' differs from input 'single'
Suggestion: Insert Data Type Conversion block or set output data type explicitly

定位到 Gain2 后，修复动作有两种：一是把 Gain 模块的 Output data type 参数从 Inherit: Same as input 改为 single；二是在其输出后插入 Data Type Conversion 模块并设置为 single。修复后重新运行该检查项，确认结果变为 Pass。这个过程就是静态检查的最小闭环：检查 → 定位 → 修复 → 复检。

五、检查结果判读与优先级

面对几十条检查结果，不能平均用力。建议按以下优先级处理：

六、把静态检查嵌入日常流程

静态检查不应只在交付前做一次。更有效的做法是：在模型提交到版本库前，通过脚本自动运行项目规则集，把 Fail 作为提交阻断条件，Warning 生成报告供评审。例如在 CI 中调用：

% 项目级检查脚本示例
proj = openProject('MyProject.prj');
results = ModelAdvisor.run('MyModel', 'Configuration', 'ProjectChecks');
failCount = sum(strcmp({results.Result}, 'Fail'));
if failCount > 0
    error('静态检查未通过，共 %d 项 Fail', failCount);
end

这样，静态检查就从“事后补救”变成了“过程防护”。结合 MAAB 规范与 Model Advisor 的规则集，团队可以在模型规模扩大之前，把结构类、类型类、规范类缺陷控制在可管理范围内，为后续的代码生成与集成测试打下可靠基础。