1. 课程导入与MBSE全景

当我们面对一架飞机、一颗卫星、一套自动驾驶系统或一条智能制造产线时，真正棘手的往往不是某个零件做不出来，而是成千上万个部件、软件、接口、约束和人员决策必须同时正确。这类系统被称为复杂系统：它的行为不由单个部件决定，而由部件之间的交互、时序、能量流、信息流和失效传播共同决定。传统“先写文档、再画图、最后集成”的方式，在需求频繁变化、接口数量爆炸、验证周期拉长时，会迅速暴露三个典型问题：需求散落在文档中难以追踪，设计与需求脱节，验证只能在物理样机阶段才发现问题。

MBSE（Model-Based Systems Engineering，基于模型的系统工程）的核心价值，是把系统工程的“语言”从自然语言文档，转为形式化、可追溯、可执行、可验证的模型。这里的“模型”不是一张装饰性示意图，而是对系统结构、行为、参数和需求的精确表达。它让需求、功能、逻辑、物理、接口、测试用例之间建立显式链接，使“为什么这样设计”“这条需求由谁实现”“改动会影响哪些部件”能够被机器和团队同时读懂。

复杂系统的四个典型挑战

• 需求爆炸与变更：一条顶层任务需求可能派生数百条子需求，变更时若靠人工维护，遗漏几乎不可避免。
• 跨学科接口耦合：机械、电气、控制、软件、热、电磁等专业各自优化，接口不匹配常在集成阶段集中爆发。
• 行为与结构不一致：功能在逻辑层能跑通，但分配到物理架构后出现资源冲突、时序超限或冗余不足。
• 验证滞后：问题发现得越晚，返工成本越高。MBSE强调左移验证，在模型阶段就运行检查与仿真。

为应对这些挑战，本课程采用一条清晰的主线：需求 → 功能/行为 → 逻辑架构 → 物理架构 → 接口与参数 → 验证。这条主线不是一次性瀑布，而是迭代循环。每一轮迭代都回答四个问题：系统要做什么（需求）、系统如何行为（功能与状态）、系统由什么组成（逻辑与物理结构）、我们如何证明它做对了（验证与追溯）。

需求到架构的建模主线

在MBSE中，需求不是孤立文本，而是模型中的可追踪元素。典型做法是：用需求图表达需求之间的包含、派生、满足、验证关系；用用例图或活动图描述系统与外部角色的交互；用状态机描述模式切换与异常处理；用块定义图（BDD）和内部块图（IBD）描述架构组成与接口；用参数图绑定性能约束。这样，当一条需求变更时，可以沿模型链路快速定位受影响的架构元素和测试用例。

以本课程贯穿的项目为例：我们要为一台“自主移动巡检机器人”建立需求—架构模型。示例性顶层需求包括：续航不低于4小时、最大速度1.2 m/s、具备避障与紧急停止、支持远程任务下发、定位误差小于10 cm。这些需求将逐步分解为功能（导航、感知、决策、驱动、通信、电源管理），再分配到逻辑组件（激光雷达、IMU、轮式底盘、计算单元、电池组、无线模块），最后形成物理架构与接口定义。所有参数均为教学示例，用于演示建模方法，不代表真实产品指标。

课程项目说明与学习方式

本课程以一个可扩展的自主移动巡检机器人作为贯穿项目。你不需要真实硬件，但需要按工程逻辑完成模型。每章会围绕一个建模任务推进：第1章建立全景认知；后续章节依次完成利益相关者与用例、需求分解与追溯、功能行为建模、逻辑架构、物理架构、接口定义、参数约束、验证与确认。最终交付物是一套相互链接的模型视图，而不是零散图片。

建议的学习方式是“边学边建”：每学完一个建模元素，就在自己的工具中建立对应元素并连接到已有模型。工具不限，只要支持需求、结构、行为、参数和追溯关系即可。判断自己是否掌握的标准不是“画得像”，而是能否回答：这条需求由哪个功能承载？这个功能分配到哪个组件？组件之间的接口参数是否满足约束？如果顶层需求变化，哪些元素需要修改？