7.1 静态检查与建模规范

7.1 静态检查与建模规范

本节摘要：不运行模型就能查出的问题占验证工作量的三成：数据类型隐患、采样时间含糊、参数来源不清、结构违规。本节讲清静态检查的对象与建模规范检查器的用法，重点落在两件事上：如何为团队选定并裁剪一套规范基线，以及豁免流程为什么必须正式。静态检查的产出是交付证据链的第一环。

不跑模型能查出什么

把模型交给检查器，不需要仿真就能暴露的问题清单比多数人预想的长。数据类问题：信号溢出风险（int16 通道上算出一个会越界的中间量）、精度损失点（浮点除法结果直接赋给定点变量）、混合数据类型相接。采样时间问题：连续信号未经转换接进离散域、继承链过长导致实际速率不明确——2.3 节警告过的混域含糊，在这里被机器点名。接口问题：未连接的端口、方向配错的总线、缺少定义的总线对象。配置问题：求解器选择与模型特征不符、诊断项被随手关掉、参数引用了基础工作区里的裸变量（6.1 节的封路条款在此被执行）。

这类检查的价值逻辑与编译器告警相同：便宜、快速、可全量执行。动态测试每个用例都要仿真时间，静态检查全模型扫一遍只需数秒，所以它的定位是"天天跑的门卫"而不是"交付前的大考"。团队的正确姿势是把检查器挂在持续集成里，每次提交自动跑一遍，新增告警当日清零。

规范基线：选、裁、守

建模规范（业界常用 MAAB 及其衍生风格指南）解决的是另一个层面的问题：团队内的可读性与可预测性共识。模块命名规则、子系统层数上限、迁移优先级标注要求、参数命名前缀——单看每条都是小事，合起来决定了一个陌生人打开你的模型时，是能上手还是要重修。

规范落地的三步曲。选：从行业指南起步，不要从零发明——行业指南的每条条款背后都是真实事故的学费。裁：逐条表决"本团队采纳、放弃或修改"，裁决记录写进团队规范文档；一百多条全盘照搬的规范没人执行，四十条全员认可的规范才有生命力。守：规范里可机器判定的条目录入检查器的自定义检查项，其余靠评审执行——半年回顾一次，发现某条从未被执行，要么补工具要么删条款，别留一条没人信的法律。

% 静态检查的脚本化：提交即检查
load_system('motor_speed_loop');

% 建模规范检查：按项目配置的检查集运行
% （检查项的启用与分级在检查器界面配置一次，脚本只负责跑与出报告）
res = ModelAdvisor.run('motor_speed_loop', 'MAAB');

% 更新 diagram 后跑静态一致性：维度、类型、采样时间全图推导
set_param('motor_speed_loop', 'SimulationCommand', 'update');
% 更新无告警 = 静态一致性通过；有告警则定位到具体信号修复

% 豁免登记的格式约定（写入模型注释或需求链接）
% 豁免编号 | 条款号 | 理由 | 批准人 | 复审日期
% EX-0031  | MAB.02 | 硬件接口规定此信号为单精度 | 张工 | 2026-12
​

图：静态检查的问题分级与处置路径

豁免流程：规范的泄压阀

没有豁免通道的规范会被私下绕过，有正式豁免的规范才立得住。豁免流程的三要素写在图里：理由（为什么这条不适用）、批准人（谁担这个责任）、复审日期（什么条件下重新表决）。示例代码里的 EX-0031 是个真实形态的登记——硬件接口规定了单精度信号，团队规范的双精度要求在此让位，但让位有记录、有人担责、有期限。

豁免管理的两个反模式值得点名。反模式一：豁免堆积——三十个豁免里二十个过期未复审，规范的边界已经模糊成雾。反模式二：豁免私有化——口头豁免、聊天记录豁免，验收时全变成悬案。解法都是流程性的：豁免进版本库、复审日期进日历、豁免数量进团队质量看板。

⚠️ 常见坑：为了过检查而"修复"出更大的问题。典型场景：检查器提示继承链过长，有人不问青红皂白给所有模块写死采样时间——结果速率决策被打散到几十处，改一次节拍要全局搜索。修复之前先读懂检查项为什么存在。

落地案例：一次规范导入的三个月

规范落地比规范本身更能检验团队。一个可参考的时间线：第一个月，选型与裁剪——全组逐条过行业指南，四十条入册，同时把其中机器可判定的二十六条配进检查器，剩下十四条归评审职责；第二个月，存量清理——对既有模型跑一次全量检查，按三色分级开出整改清单，强制级清零、建议级豁免登记，存量问题不带入新流程；第三个月，新规生效——提交即检查挂进持续集成，第一次全组评审按新清单走。三个月后的复盘数据：检查器平均每次提交拦下两个强制级问题，评审会上关于命名与格式之争降为零，讨论全部集中在结构合理性与假设正确性上——评审时间没有被增加消耗，而是被重新分配到了人真正该裁量的地方。

这个案例的推广结论：规范导入的成本集中在前六周，收益从第一次评审开始兑现；最忌讳的是"规范发文即生效"——没有裁剪共识、没有存量清理、没有工具兜底的三无规范，一个月内必然名存实亡。

常见问题

问：检查器报的问题太多，团队消化不动，怎么办？

按"先止血、再清创"处理。止血：新提交的强制级问题当日清零，增量立刻归零。清创：存量问题按模块的重要性排序，两周一个批次渐进消化，消化不完的走正式豁免登记——宁可白纸黑字的欠账，不要稀里糊涂的红海。切忌一次性要求全绿，那只会催生批量豁免和批量关闭检查的暗操作。

本节要点回顾

• 静态检查是门卫不是大考：数据类、采样时间、接口、配置四类问题不跑模型即可暴露；
• 挂进持续集成：全量、秒级、每次提交执行，新增告警当日清零；
• 规范三步曲：选行业基线、逐条裁剪表决、可机器化的条目录入检查器；
• 三色分级：强制必修复、建议可豁免、信息只知悉，验收单只含前两级；
• 豁免三要素：理由、批准人、复审日期，登记进版本库，过期重议；
• 修复先读懂条款：为过检查而做的表面修复，常制造出更深的结构性问题。

静态的门卫守住了结构与配置，但行为对不对要跑起来才知道。下一站：覆盖率让测试充分性第一次变得可量化。