2. MBSE建模语言与模型组织
在MBSE中，模型不是“画出来的图”，而是由语言规则约束、由包结构组织、由视图视点表达的一组可追溯模型元素。理解这三层关系，是后续做一致性检查的前提：只有先知道模型“用什么语言说、放在哪里、给谁看”，才能判断它“说得是否自洽”。
一、三种主流建模语言：SysML、UML、OPM
SysML（系统建模语言）是MBSE最常用的语言，它由UML重载而来，但针对系统工程做了裁剪与扩展。SysML保留UML的结构与行为基础，同时新增需求图（Requirement Diagram）和参数图（Parametric Diagram），并弱化了软件实现相关的部分。典型元素包括：块（Block）描述系统结构，端口（Port）与流属性（Flow Property）描述交互点与交换项，活动（Activity）、状态机（State Machine）、序列（Sequence）描述行为，需求（Requirement）描述约束，约束属性（Constraint Property）描述参数关系。
UML更偏向软件与信息系统建模，其类（Class）、组件（Component）、用例（Use Case）、部署（Deployment）等元素在软件密集型系统中表达力强，但缺少需求与参数约束的原生语义。OPM（对象过程方法）则采用“对象—过程”二元本体：对象表示状态可被改变的事物，过程表示改变对象状态的动作，二者通过连接关系构成系统。OPM强调单一模型、无图种割裂，适合对系统行为做整体推演，但在工程生态与工具支持上不如SysML普及。
选择语言时，关键不是“哪个更先进”，而是模型要回答什么问题：若需覆盖需求—结构—行为—参数全链路，SysML更合适；若系统以软件为主，UML更自然；若关注对象状态与过程交替的整体语义，OPM更清晰。混用语言时，必须明确元素映射关系，否则一致性检查会失去基准。
二、模型包结构：一致性的“物理边界”
包（Package）是模型元素的命名空间与容器。一个可维护的MBSE模型通常按“需求—结构—行为—参数—验证”划分顶层包，再按系统层级（系统、子系统、组件）或专业域（机械、电气、控制）细分。包结构决定了元素的全限定名，例如 Root::Structure::PowerSubsystem::Battery。当两个包中出现同名块时，若未通过导入关系明确指向，工具会视为两个不同元素，这是“同名不同物”类不一致的常见来源。
包之间的依赖关系（Dependency）、导入关系（Import）和包含关系（Containment）必须显式建模。实践中建议：需求包只被结构包与验证包引用，行为包引用结构包中的块作为活动分区或状态机主体，参数包引用结构包中的值属性。若出现行为包直接引用需求包中的文本而绕过结构，追溯链就会断裂，后续变更影响分析将无法收敛。
三、视图与视点：同一模型的不同投影
视图（View）是对模型某一部分的呈现，视点（Viewpoint）是定义“该视图应回答什么问题、使用哪些元素、遵循什么规则”的规范。例如结构视点下的内部块图（IBD）应展示部件、端口与连接器；行为视点下的活动图应展示动作、控制流与对象流；需求视点下的需求图应展示需求之间的包含、派生、满足与验证关系。
一致性检查的第一层，就是检查“视图是否遵守其视点约定”。例如某IBD中出现了未在块定义图中声明的端口，或某活动图的输入对象流没有对应的流属性，都属于视图与视点、视图与模型之间的不一致。第二层是跨视图一致性：结构图中的连接器是否与行为图中的对象流方向一致，需求图中的“满足”关系是否指向真实存在的块，参数图中的约束是否绑定了正确的值属性。
四、一致性问题的来源分类
综合语言、包结构与视图视点，MBSE模型不一致主要来自四类：
- 语言语义误用：如用关联代替组合表达强归属，用流属性表达控制信号，导致结构语义与行为语义冲突。
- 命名与引用断裂：元素被重命名、移动或删除后，引用它的图、需求或约束未同步更新，形成悬空引用。
- 包边界与导入混乱：同名元素跨包重复定义、循环导入、未受控的包合并，使模型出现“看似一个、实为多个”的元素。
- 视图视点漂移：同一元素在不同视图中被赋予不同属性值、不同端口或不同行为主体，且缺少单一数据源约束。
以某车载电源系统为例：需求包中有一条“电池包应在-20℃至60℃范围内提供不低于40kW持续功率”；结构包中 BatteryPack 块定义了 maxContinuousPower: Power = 40 kW 与 operatingTemperature: TemperatureRange；参数包中约束 PowerConstraint 绑定该值属性；验证包中测试用例引用该需求。若结构包中该值属性被改为 35 kW 而需求未更新，参数图仍会通过，但需求满足关系已失效——这类不一致不会由语法检查发现，必须依靠跨视图追溯规则识别。
因此，模型组织不是“把图放进文件夹”，而是用包结构固定命名与引用、用视点固定表达规则、用语言元素固定语义。只有这三者对齐，一致性检查才有明确的判定对象和可执行的规则边界。