2. MBSE核心建模语言与工具链
MBSE（基于模型的系统工程）之所以能替代以文档为中心的传统系统工程，核心在于两件事：一是有一套语义严谨、面向系统工程的建模语言，二是有一套能承载这套语言、并支撑团队协作与模型追溯的工具链。当前工业界事实上的标准语言是 SysML（Systems Modeling Language），而工具链则围绕 Rhapsody、MagicDraw/Cameo Systems Modeler、Capella 等主流平台展开。理解 SysML 的图类型分工，以及各工具在系统设计流程中扮演的角色，是搭建 MBSE 数字线程的第一块基石。
SysML 的图类型：按“问什么问题”来分工
SysML 是 UML 在系统工程领域的扩展，它保留了 UML 的部分图，又新增了需求图与参数图，并改造了活动图、块定义图等。学习 SysML 图类型，最有效的方式不是背清单，而是按“这张图回答什么问题”来归类。SysML 的图大致分为四类：结构类、行为类、需求类和参数类。
结构类图回答“系统由什么组成、如何连接”。其中块定义图（BDD）定义系统的模块、属性、端口与操作，是模型的骨架；内部块图（IBD）描述块内部各部件之间的连接与接口，是装配关系的表达；包图用于组织模型结构，管理命名空间与依赖。BDD 与 IBD 配合，构成从“类型定义”到“实例装配”的完整结构视图。
行为类图回答“系统如何运行、状态如何变化”。活动图描述功能流程与数据流，适合表达系统级的功能分解与信号/物料流转；序列图描述参与者之间按时间顺序的交互，适合接口时序与消息顺序验证；状态机图描述对象在事件驱动下的状态迁移，适合模式管理、故障处理等逻辑；用例图则从外部视角界定系统边界与使用场景。
需求图回答“需求是什么、由谁满足、如何验证”。它把文本需求建模为可追溯的模型元素，并通过 «satisfy»、«verify»、«derive» 等关系，把需求与设计、测试用例连接起来。这是 MBSE 区别于传统建模的关键，也是数字线程中“需求—设计—验证”追溯链的起点。
参数图回答“性能约束如何绑定到结构”。它通过约束块与约束参数，把数学方程（如 F=ma、功耗=电压×电流）绑定到系统属性上，使工程计算可以随模型参数变化而联动。参数图是 MBSE 与 CAE 集成的语义桥梁，也是后续章节中模型传递与联合仿真的基础。
工具链的角色差异：不是替代关系，而是分工
Rhapsody 的强项在于嵌入式与实时系统。它把状态机作为一等公民，支持从模型直接生成 C/C++/Java 代码，并能在模型层面进行仿真与断点调试。对于控制器、飞控、车载 ECU 这类“行为密集、代码交付”的系统，Rhapsody 的模型即代码能力可以显著缩短从设计到实现的链路。它的典型用法是：用状态机图定义模式切换逻辑，用 IBD 定义软硬件接口，再通过代码生成把模型落到目标平台。
MagicDraw（及其系统工程版 Cameo Systems Modeler）则以“全图类型覆盖 + 需求追溯 + 团队协作”见长。它完整支持 SysML 九种图，内置需求管理、矩阵追溯、参数图求解与模型版本控制，适合复杂系统、多学科团队在同一模型仓库上协同。在数字线程语境下，MagicDraw 常被用作“系统模型中枢”：需求从上游导入，结构、行为、参数在此建模，再通过接口把模型导出给下游 CAE 工具。
Capella 基于 Arcadia 方法，强调分层建模：从运行分析、系统分析、逻辑架构到物理架构，逐层细化。它把“架构设计”放在中心位置，图类型经过裁剪，更贴近系统架构师的工作习惯。Capella 是开源工具，适合希望以较低成本引入 MBSE、并遵循 Arcadia 方法论的团队。它的模型可以直接导出为多种格式，便于与下游工具衔接。
从建模到数字线程：SysML 模型如何成为追溯载体
SysML 图类型与工具链的价值，最终体现在“模型能否被追溯、被复用、被传递”。在系统设计中，一条典型的追溯链是：需求图中的需求项，通过 «satisfy» 关系指向结构类图中的块；块通过分配关系指向行为类图中的活动或状态机；活动中的关键性能参数，又通过参数图绑定到约束方程上。这样，当需求变更时，工程师可以沿追溯链快速定位受影响的结构、行为与参数，而不是在文档堆里人工搜索。
以无人机续航需求为例：需求图中有一条“续航时间 ≥ 30 min”的需求。结构类图中定义“电池包”块，其属性包括容量、放电效率；参数图中建立约束“续航时间 = 容量 × 放电效率 / 平均功耗”；行为类图中的“巡航”活动引用平均功耗参数。当电池容量从 5000 mAh 调整为 6000 mAh 时，参数图可联动计算续航时间，需求图上的 «verify» 关系则指向对应的验证用例。这条链就是数字线程在 SysML 层面的最小闭环。
建模工具在系统设计中的实际角色
工具不是画图软件，而是“模型仓库 + 语义引擎 + 协作平台”。具体来说，它承担四类角色：第一，语义承载，保证每个模型元素都有明确的 SysML 类型与关系，避免“图形正确、语义错误”；第二，追溯管理，通过关系矩阵与影响分析，把需求、设计、验证串成可查询的网络；第三，仿真与计算，参数图求解、状态机执行、活动图仿真，让模型在早期就能回答“性能是否达标”；第四，接口输出，把模型转换为下游 CAE、代码生成、测试管理工具可消费的格式。
在实际项目中，建议先明确“模型要回答哪些问题”，再选择图类型与工具。例如，若当前阶段的核心问题是“系统由哪些子系统组成、接口是否清晰”，就应以 BDD 和 IBD 为主；若核心问题是“模式切换是否完备”，就应以状态机图为主。图类型的选择服务于问题，而不是追求“把所有图都画一遍”。工具链的引入也应循序渐进：先在一个子系统上跑通“需求—结构—行为—参数”的追溯闭环，再逐步扩展到全系统。这样，SysML 模型才能真正成为数字线程的起点，而不是另一堆难以维护的图形文件。