1. 课程导入与Rhapsody定位

在复杂系统研发中，真正困难的往往不是“把图画出来”，而是让不同专业、不同工具、不同阶段的工程信息保持一致。一个典型的嵌入式控制系统可能同时包含机械结构、电子硬件、控制软件、通信协议、安全约束和验证用例。传统文档驱动方式下，需求写在Word里，架构画在Visio里，接口定义散落在Excel中，测试用例又存在于另一套管理工具中。一旦需求变更，影响范围只能靠人工追踪，遗漏和误解几乎不可避免。这正是系统工程建模要解决的核心问题。

基于模型的系统工程（MBSE）把“模型”而不是“文档”作为工程信息的唯一权威来源。模型不是一张静态图片，而是由需求、结构、行为、参数和验证等元素及其关系构成的可查询、可追溯、可仿真的知识库。SysML（系统建模语言）是MBSE最常用的标准建模语言，它定义了块定义图、内部块图、活动图、状态机图、序列图、参数图、需求图等九类图。这些图不是彼此孤立的“画法”，而是从不同视角描述同一个系统。

IBM Engineering Systems Design Rhapsody（简称Rhapsody）是业界成熟的MBSE建模与仿真工具。它在SysML工具链中的定位可以用“建模—仿真—代码—追溯”四个环节来理解。Rhapsody支持SysML和UML两套语言，允许团队用块定义图建立系统架构，用内部块图定义部件与接口，用状态机图和活动图描述行为，用序列图刻画交互时序，用参数图约束性能指标，用需求图建立需求与设计之间的追溯关系。更关键的是，Rhapsody的模型不是“死”的：状态机和活动图可以直接仿真执行，观察事件流、状态迁移和变量变化；在嵌入式场景中，还可以从模型生成C、C++或Java代码框架，把设计模型与实现代码保持同步。

与纯绘图工具相比，Rhapsody的差异在于模型具有语义。在普通绘图工具中，一个矩形只是一个矩形；在Rhapsody中，一个Block带有属性、操作、端口、流接口和约束，端口之间的连接遵循类型规则，状态机中的迁移必须由事件触发。这种语义约束使得模型可以被工具检查、被仿真驱动、被代码生成器消费。与同类SysML工具相比，Rhapsody的优势集中在行为仿真深度、代码生成能力、与需求管理工具（如IBM DOORS）的集成，以及对实时嵌入式系统的支持。

理解Rhapsody的定位，还需要把它放回真实的工程流程中。假设我们要开发一个“电池管理系统（BMS）”，典型的工作顺序是：先从需求图导入“过压保护阈值4.25V”“过温保护阈值60℃”等需求；然后在块定义图中建立BMS、电芯监控单元、主控单元、继电器等Block，用端口和流接口定义它们之间的电压、电流、温度信号；接着用状态机图描述主控单元的“待机—预充—运行—故障—切断”状态迁移，用活动图描述均衡算法的执行步骤；再用参数图把“采样周期≤10ms”“均衡电流≤200mA”等约束绑定到具体属性上。完成这些后，可以在Rhapsody中直接仿真：注入一个“电压=4.3V”的事件，观察状态机是否从“运行”迁移到“故障”并触发继电器切断；仿真日志会记录事件顺序、状态变化和变量值，用来判断逻辑是否符合预期。最后，通过代码生成器导出C++框架，把状态机逻辑映射为可编译的类结构，并保留模型与代码之间的追溯链接。

本课程的目标不是让读者记住每个图标的含义，而是建立“用模型思考”的习惯，并能在Rhapsody中独立完成从需求建模到行为仿真、再到代码生成的完整链路。学习路径分为四个阶段：第一阶段建立SysML与MBSE的概念框架，理解九类图的语义和适用场景；第二阶段掌握Rhapsody的建模操作，包括项目组织、块与端口定义、状态机绘制、活动图建模；第三阶段进入仿真与验证，学习事件注入、断点设置、变量观测和序列图生成；第四阶段聚焦工程化，包括需求追溯、模型组织、代码生成配置和团队协作。每个阶段都配有可操作的示例，建议读者在Rhapsody中同步练习，而不是只阅读文字。

需要特别提醒的是，MBSE和Rhapsody都不是“银弹”。模型的质量取决于建模者对系统本身的理解，工具只能保证一致性，不能替代工程判断。一个常见的误区是把Rhapsody当成高级绘图工具，只画图不仿真、只建模不追溯，这样得到的模型和Visio图没有本质区别。真正发挥价值的前提是：模型中的每个元素都有明确语义，每条关系都有工程含义，每次变更都能通过工具传播和检查。这也是本课程反复强调“可执行、可追溯、可验证”的原因。