1. 课程导入与全景认知

在基于模型的系统工程（MBSE）实践中，模型逐渐取代文档成为系统设计信息的唯一权威来源。当SysML模型从几十个元素增长到数千个元素、由多个专业团队并行维护时，一个隐蔽却致命的问题会浮现：模型内部与模型之间开始出现不一致。需求元素指向了已被删除的用例，活动图的输入输出与块定义图（BDD）中的端口类型不匹配，参数图里的约束方程与状态机中的转移条件互相矛盾。这些不一致不会让工具报错，却会在下游仿真、代码生成或评审中集中爆发。

所谓模型一致性检查，是指依据明确的规则集，对模型元素、关系、属性、约束以及跨模型引用进行系统化验证，识别出违反规则或相互矛盾的建模结果。而模型治理则是在检查之上建立的长效机制：定义谁在什么阶段、依据什么规则、对哪些模型范围执行检查，如何记录问题、分派修复、验证闭环，并持续优化规则本身。检查是“发现病灶”，治理是“建立体检制度与治疗流程”。二者缺一不可。

为什么一致性在MBSE中如此关键？因为模型的价值在于可追溯、可仿真、可复用。一旦一致性被破坏，追溯链断裂，仿真输入失真，复用组件带着隐藏缺陷扩散到新项目。更严重的是，当团队对模型失去信任，就会退回到文档和口头确认，MBSE的投入随之贬值。因此，一致性不是锦上添花的质量指标，而是模型能否作为工程依据的准入门槛。

然而，实际项目中一致性检查面临多重挑战。第一，规则来源分散：建模规范、行业标准、项目约定、工具约束各自成文，缺乏统一的形式化表达。第二，检查时机滞后：多数团队在评审前才集中检查，问题堆积且修复成本高。第三，误报与漏报并存：规则过严产生大量噪声，规则过松则放过真实缺陷。第四，跨模型边界模糊：需求模型、架构模型、参数模型分属不同工具或仓库，引用关系难以自动追踪。第五，治理责任不清：发现问题后无人认领，修复状态无法跟踪，规则更新缺乏反馈闭环。

为应对这些挑战，本课程设计了一条从认知到落地、从单点检查到体系治理的学习路径。整体分为四个阶段：基础认知（理解一致性维度与治理框架）、规则构建（将规范转化为可执行的检查规则）、检查执行（在模型生命周期中嵌入自动化检查）、治理闭环（问题管理、度量与持续改进）。每个阶段都配有真实建模场景中的示例参数、规则片段和判断依据。

上图展示了四个阶段的递进关系与各自的关键产出。需要强调的是，这四个阶段并非严格串行：在实际项目中，规则构建与检查执行往往交替迭代，治理闭环的度量结果会反向驱动规则优化。但作为学习路径，按此顺序推进有助于建立完整的知识结构。

本课程的目标不是让读者记住若干检查命令，而是培养三种能力：第一，识别能力——看到一段模型或一组规则，能判断哪些不一致风险最高；第二，构建能力——能把项目规范、行业标准转化为可执行、可维护的检查规则；第三，治理能力——能设计并运行一套让一致性持续受控的机制，而不是依赖个人经验临时排查。

在后续章节中，我们将逐一展开：一致性维度的具体分类与判定标准、规则的形式化表达方式（包括OCL约束、查询脚本和工具原生规则）、检查在需求评审、设计评审和集成测试等节点的嵌入方式，以及如何用缺陷密度、规则命中率、修复周期等指标衡量治理效果。每一部分都会给出可参考的示例参数和判断依据，帮助读者在自己的项目中快速落地。

最后需要明确一个基本立场：一致性检查与治理的最终目的，是让模型成为可信的工程决策依据。工具和规则是手段，信任才是目标。当团队能够放心地基于模型做仿真、做权衡、做验证，MBSE才真正发挥了它应有的价值。本课程将围绕这一目标，提供从理念到操作的系统化指引。