1. 课程导入与SysML定位
工业装备通常不是单一机械产品，而是由机械本体、液压/气动执行、电气驱动、传感器、控制器、通信网络与上位软件共同构成的复杂系统。以一台典型的六轴工业机器人为例：机械臂负责位姿运动，伺服驱动器控制各关节电机，编码器反馈角度，安全PLC处理急停与安全门信号，上位机通过EtherCAT下发轨迹指令。任何一次“抓取失败”，都可能来自机械刚度、伺服参数、通信周期、视觉标定或任务调度中的任意一环。这类问题的根源往往不在单个零件，而在跨专业接口与系统级行为。
这正是基于模型的系统工程（MBSE）要解决的核心问题。MBSE强调用统一、可追溯、可执行的模型替代以文档为中心的分散描述。而在众多建模语言中，SysML（Systems Modeling Language）是面向系统工程的通用图形化建模语言，它由UML扩展而来，专门用于描述系统的结构、行为、需求与参数约束。本课程的目标，是让学习者能够用SysML对工业装备进行从需求到验证的系统级建模，而不是停留在“会画图”的层面。
工业装备系统建模的四个典型挑战
第一是多学科语义割裂。机械工程师用三维CAD和公差表达，电气工程师用原理图和IO表表达，控制工程师用框图与状态机表达，软件工程师用类图和接口定义表达。四套语言之间缺少统一的语义桥梁，导致“接口对不上、时序说不清”。
第二是需求到实现的追溯断裂。装备研制中常见“需求写在Word里、设计画在CAD里、测试记在Excel里”，一旦需求变更，很难快速判断哪些部件、哪些测试用例受影响。SysML的需求图与追溯关系正是为此设计。
第三是行为与结构脱节。控制逻辑（状态机、活动）与物理结构（部件、端口）往往分开描述，导致“逻辑上可行、物理上装不下、时序上赶不上”。SysML通过把行为分配到结构块上，使二者绑定。
第四是验证滞后。传统流程中，系统级问题常在集成后期才暴露，返工成本高。MBSE主张在模型阶段就进行参数计算、接口检查和场景仿真，把验证左移。
SysML 在 MBSE 中的角色
MBSE 是一种方法论，SysML 是支撑该方法论的建模语言。二者关系可以这样理解：MBSE 回答“系统工程应该怎么做”，SysML 回答“用什么符号和语义把系统描述清楚”。在工业装备项目中，SysML 主要承担四类角色。
角色一：需求的结构化载体。把“节拍≤12s/件”“定位重复精度≤±0.05mm”“安全等级达到PLd”等需求写成可标识、可追溯的需求元素，并用«satisfy»、«verify»、«derive»关系连接到设计块和测试用例。这样当需求变更时，可以沿模型快速定位影响范围。
角色二：跨学科接口的契约。用块定义图定义“伺服驱动模块”“视觉定位模块”“安全控制模块”，用端口和接口块规定每个模块对外提供什么、需要什么。例如视觉模块向控制模块提供“目标位姿（x,y,θ）+ 置信度”，控制模块向驱动模块提供“关节目标角度+使能信号”。接口一旦在模型中固定，机械、电气、控制、软件就围绕同一份契约并行开发。
角色三：行为与结构的绑定。用活动图描述“上料—识别—抓取—放置”的功能流，用状态机描述设备“待机—运行—暂停—故障”的模式迁移，再通过«allocate»把活动或状态分配到具体块上。这样“谁执行、何时执行、依赖什么信号”一目了然。
角色四：参数与验证的入口。用参数图建立“负载质量—加速度—关节扭矩—电机选型”的约束关系，把工程公式写进模型，配合具体数值进行权衡分析。例如已知末端负载 m=8kg、最大加速度 a=6m/s²、力臂 L=0.65m，可估算静态等效扭矩 T≈m·a·L=31.2N·m，再叠加安全系数与动态余量，用于校核减速器与电机峰值扭矩是否匹配。这类计算在模型中可复用、可追溯，而不是散落在个人表格里。
课程目标与学习路径
本课程围绕“能建、能查、能验、能交付”四个目标展开。学完后，你应当能够：针对一台工业装备，独立完成需求模型、结构模型、行为模型和参数模型的搭建；能够用追溯关系检查需求覆盖度；能够用状态机和序列图分析异常工况；能够把模型组织成可评审、可交付的工程成果。
学习路径按“语言基础→结构建模→行为建模→需求与参数→综合案例”推进。前四阶段打基础，每个阶段都配合工业装备中的真实对象练习，例如用输送线、机械手、视觉工位、安全回路作为建模素材；最后阶段以一个完整的装备单元为案例，把需求、结构、行为、参数串起来，形成从需求到验证的闭环。
需要特别说明的是，本课程中的参数、数值和案例结果，除明确标注为实测外，均为教学示例或合理假设，用于说明建模与计算过程，不代表任何具体设备的出厂指标。学习时重点掌握“如何建立关系、如何判断结果是否合理”，而不是记忆某个具体数字。
从“文档驱动”到“模型驱动”的思维转变
传统装备研制中，信息分散在需求规格书、接口协议、PLC程序、测试报告里，一致性靠人工评审维持。模型驱动的做法是把这些信息收敛到一个有语义、有关系的模型中：需求不再是孤立段落，而是被«satisfy»连接的设计目标；接口不再是口头约定，而是带类型和方向的端口；测试不再是事后补录，而是与需求«verify»绑定的验证用例。
这种转变带来的直接收益是变更影响可计算。假设客户把节拍要求从12s/件提高到9s/件，在模型中可沿“需求→活动→分配块→参数约束”链路，快速识别出需要重新校核的环节：抓取活动时间、关节最大速度、通信周期、安全响应时间。哪些块受影响、哪些测试用例需重跑，都能从模型关系中导出，而不是靠经验回忆。