3. 模型一致性核心概念体系
在MBSE项目中，模型一致性检查之所以困难，根本原因在于“一致性”本身不是一个单一概念。同一个模型，从不同视角审视，可能同时存在“语法正确但语义错误”“结构完整但行为矛盾”“需求覆盖但验证缺失”等不同性质的问题。如果检查人员不先厘清一致性的层次与边界，就容易把不同性质的问题混为一谈，导致检查规则设计失焦、问题定位偏差、治理措施错配。因此，建立一套分层的一致性概念体系，是开展模型一致性检查与治理工作的前提。
一、五个层次的内涵
语法一致性关注的是模型是否符合建模语言本身的规则。以SysML为例，语法一致性包括：每个元素是否属于合法的元类型、属性是否满足多重性约束、连接器两端端口类型是否兼容、命名是否符合规范、是否存在悬空引用等。语法一致性是“模型能不能被工具正确解析”的底线，通常由建模工具的解析器和校验器自动检查。例如，一个活动图中的对象流连接到一个不接收该类型令牌的动作节点，就属于语法层面的类型不匹配。
语义一致性关注的是模型元素所表达的含义是否自洽、是否与领域约定相符。语法正确不等于语义正确。例如，一个模块的端口类型定义合法，但该端口所承载的物理量单位与接口控制文档不一致；或者一个状态机中两个状态被定义为互斥，但迁移条件却允许同时进入。语义一致性往往需要结合领域知识、单位体系、命名约定和建模规范来判断，难以完全自动化。
结构一致性关注的是模型内部各结构视图之间的对应关系。在MBSE中，同一个系统通常会用多种结构视图描述：块定义图（BDD）描述类型层次，内部块图（IBD）描述实例组合，包图描述组织关系。结构一致性要求这些视图对同一组元素的数量、层次、接口和连接关系保持一致。例如，BDD中定义了一个模块包含三个子模块，IBD中却只出现了两个；或者IBD中两个部件之间的连接在BDD的端口定义中找不到对应端口，都属于结构不一致。
行为一致性关注的是模型动态语义之间的协调。行为视图包括活动图、状态机图、序列图等。行为一致性要求：同一系统在不同行为视图中的交互顺序、状态迁移、事件响应不矛盾；行为模型与结构模型之间的触发关系、数据流方向一致。例如，序列图中消息A在消息B之前发送，但状态机中触发B的事件却先于A到达；或者活动图的输出对象在结构模型中没有对应的流属性。
需求-设计-验证一致性是跨模型、跨生命周期的纵向一致性。它要求：每一条需求都能追溯到至少一个设计元素；每一个设计元素都能追溯到其来源需求；每一条需求都有对应的验证用例或验证方法；验证结果能够回溯到需求并给出通过/不通过的判定。这种一致性不是模型内部的自洽，而是模型与需求库、验证库之间的闭环关系。
二、五个层次的边界与关系
这五个层次并非彼此独立，而是存在明确的依赖与递进关系。语法一致性是其他一切一致性的前提：如果模型无法被工具正确解析，后续检查都无从谈起。语义一致性建立在语法正确的基础上，但它的判断标准来自领域而非语言本身。结构一致性和行为一致性分别从静态和动态两个维度检查模型内部的自洽性，二者相互约束：结构模型定义了“谁和谁连接”，行为模型定义了“何时发生什么”，二者必须协调。需求-设计-验证一致性则把检查范围从模型内部扩展到模型与外部工程信息之间，是最高层、也最难完全自动化的一致性。
理解边界的关键在于：不同层次的一致性问题，需要不同的检查方法和治理策略。语法问题通常由工具自动报错，修复成本低；语义问题需要领域专家介入，往往涉及建模规范的完善；结构问题可以通过模型查询和比对脚本批量发现；行为问题需要仿真或形式化验证；需求-设计-验证问题则需要打通工具链和追溯机制。如果把语义问题当成语法问题去写校验规则，或者把需求追溯问题简化为模型内部检查，都会导致治理失效。
三、实际检查中的层次判定示例
以一个简化的卫星姿态控制系统模型为例。假设建模人员在IBD中为“姿态控制器”添加了一个“推力器指令”输出端口，但BDD中“姿态控制器”模块并未定义该端口。工具解析时不会报语法错误，因为端口本身定义合法；但结构一致性检查会发现IBD与BDD的端口集合不匹配。进一步检查语义一致性时，可能发现该端口的单位被定义为“N”而非“N·m”，与接口控制文档中的力矩指令不符。再检查行为一致性时，序列图中该指令的发送顺序与状态机中的迁移触发条件矛盾。最后检查需求-设计-验证一致性时，发现“姿态控制精度”需求没有对应的验证用例覆盖该指令通道。同一个模型缺陷，在五个层次上呈现出不同性质的问题，需要分别记录、分别治理。
四、检查项与判定依据对照
| 一致性层次 | 典型检查项 | 判定依据来源 | 常见问题示例 |
|---|---|---|---|
| 语法一致性 | 元类型合法性、多重性、端口类型兼容、命名规范 | 建模语言规范（SysML/UML元模型） | 活动图对象流类型不匹配、悬空引用 |
| 语义一致性 | 单位体系、物理量含义、互斥关系、领域命名 | 领域本体、接口控制文档、建模规范 | 端口单位错误、状态互斥条件矛盾 |
| 结构一致性 | BDD/IBD元素对应、端口-连接匹配、包组织 | 模型内部跨视图约束（OCL/QVT） | IBD部件数量与BDD不一致、连接无对应端口 |
| 行为一致性 | 事件顺序、状态迁移、触发关系、数据流方向 | 行为语义、仿真结果、时序约束 | 序列图消息顺序与状态机迁移矛盾 |
| 需求-设计-验证一致性 | 需求追溯、设计覆盖、验证用例覆盖、结果回传 | 需求管理计划、验证矩阵、追溯规范 | 需求无设计元素、验证用例未覆盖关键需求 |
需要强调的是，这五个层次并不是要求每个项目都必须完整实施全部检查。实际项目中，应根据系统复杂度、安全等级、团队成熟度和工具链能力，选择适当的检查深度。例如，概念设计阶段可能只需保证语法和结构一致性；详细设计阶段需要加入语义和行为一致性；进入验证阶段后，需求-设计-验证一致性成为重点。分层体系的价值在于提供一套共同语言，让建模人员、检查人员和项目管理者能够准确描述问题性质、协商治理优先级，而不是把所有不一致都笼统地称为“模型有问题”。