1. SysML功能行为联合建模导论

在复杂系统研发中，需求、结构、行为与验证往往分散在不同文档和工具里：需求写在Word里，结构画在CAD中，行为逻辑藏在工程师的脑子里，验证用例又散落在测试平台。SysML（Systems Modeling Language，系统建模语言）正是为弥合这些割裂而生的标准化建模语言。它基于UML扩展而来，但去掉了软件工程的强绑定，增加了面向系统工程的硬件、能量、物质、连续量等表达手段，成为MBSE（基于模型的系统工程）的核心载体。

一、SysML语言概览：九种图，两类视角

SysML 1.x 定义了九种图，按“结构”与“行为”两大视角划分。结构视角包括：块定义图（BDD）描述系统组成与分类层次；内部块图（IBD）描述部件之间的连接与接口；参数图（PAR）描述约束参数之间的数学关系；包图（PKG）组织模型元素。行为视角包括：活动图（ACT）描述控制流与数据流；序列图（SD）描述对象间按时间顺序的交互；状态机图（STM）描述对象生命周期中的状态迁移；用例图（UC）描述系统与外部参与者的功能边界。此外还有需求图（REQ），用于把需求与其它模型元素建立可追溯关系。

需要特别注意的是，SysML并不要求“每张图都画”。图是模型的视图，模型才是唯一数据源。一个块（Block）可以同时出现在BDD、IBD、状态机中，它们描述的是同一对象的分类、连接与生命周期，而不是三份独立数据。理解这一点，是后续联合建模的前提。

二、功能与行为建模的定位

“功能”回答系统“做什么”，通常由需求与用例界定；“行为”回答系统“怎么做、按什么顺序做、在什么条件下切换”，由活动、序列、状态机描述。二者不是并列关系，而是“意图—实现”的映射关系。例如，无人机“自动返航”是功能，其行为可能由“触发返航→爬升到安全高度→航向归位→降落”的活动流，加上“待机/返航/降落”的状态机共同实现。

在SysML中，功能通常落在用例图与需求图上，行为落在活动图、序列图、状态机上，而结构落在BDD/IBD上。若只画结构不画行为，模型是“静态骨架”；只画行为不画结构，模型是“无宿主剧本”。这正是联合建模要解决的问题。

三、联合建模的必要性

联合建模的核心思想是：让结构、行为、需求、参数在同一模型仓库中互相引用、互相约束。具体价值体现在三方面。第一，一致性：当IBD中某个端口被删除时，引用该端口的活动图数据流会立即暴露为悬空引用，避免文档间“各说各话”。第二，可追溯：需求图中的“自动返航时间≤30s”可被参数图约束、被活动图的时间约束引用，验证时直接定位。第三，可仿真：活动图与状态机可被执行引擎驱动，在早期发现死锁、资源冲突、状态不可达等问题，而不是等到实物测试。

四、课程项目背景与工具链准备

本课程以一个“四旋翼物流无人机”为贯穿项目。系统级需求包括：载重2kg、巡航速度12m/s、自动返航时间≤30s、低电量自动触发返航。结构上包含飞控块、动力块、电池块、导航块、通信块；行为上包含“起飞—巡航—投递—返航—降落”活动流，以及“待机/起飞/巡航/投递/返航/降落/故障”状态机。

工具链方面，推荐使用支持SysML的开源或商业建模工具，例如Capella（配合Arcadia方法）、Papyrus、MagicDraw/Cameo Systems Modeler、Enterprise Architect。若以教学和快速验证为主，可选择Papyrus + Moka仿真插件，或Capella + 其内置的Arcadia活动/状态建模。工具选择不影响方法，关键是模型元素命名规范统一，例如块统一用“BLK_”前缀，活动用“ACT_”，状态用“ST_”，需求用“REQ_”。

下面这张图给出本课程后续章节将反复使用的“联合建模锚定关系”：需求、结构、行为、参数四类模型元素如何通过SysML关系互相引用，形成可追溯、可仿真的闭环。

从图中可以看到，需求通过 satisfy/derive 关系锚定到结构与行为，结构通过 allocate 关系承载行为，参数通过 bind/constrain 关系把需求中的指标变成可计算的约束。四类元素不是四张孤立的图，而是同一模型仓库中的四个视图。后续章节将依次展开：如何用BDD/IBD建立结构骨架，如何用活动图与状态机描述行为，如何用参数图把“≤30s”变成可验证的数学约束，以及如何用需求图把一切串成可追溯的链条。

在开始建模前，建议先完成三项准备：一是确定项目命名规范，块、活动、状态、需求前缀统一；二是选定建模工具并确认其支持活动图仿真与需求追溯；三是明确模型仓库的目录结构，例如按“需求/结构/行为/参数/验证”分包含组织。这三项准备看似琐碎，却直接决定后续30章能否顺畅推进。