1. 课程导入与全景认知
在复杂装备与系统研发中，需求、设计、仿真、验证往往分散在不同工具和不同团队中：需求写在文档里，架构画在建模工具里，性能算在仿真软件里，验证结论又回到另一份报告里。结果是“模型”和“仿真”各自成立，却难以证明二者描述的是同一个系统。MBSE（基于模型的系统工程）模型与仿真联动验证，正是为解决这一断层而提出的工程方法：以系统模型为单一可信源，把仿真模型与系统模型建立可追溯的映射关系，使仿真结果能够反过来验证系统模型中的需求、结构与参数是否自洽。
一、什么是MBSE模型与仿真联动验证
MBSE强调用形式化模型（通常以SysML等语言表达）承载需求、结构、行为与参数。仿真则用数学求解或离散事件推进的方式，计算系统在特定工况下的响应。所谓“联动验证”，包含三层含义：
- 模型联动：系统模型中的参数、接口、状态机与仿真模型中的变量、端口、事件建立明确映射，而不是靠人工抄写。
- 数据联动：仿真输入来自系统模型的参数实例，仿真输出回写到系统模型的属性或验证用例中，形成闭环数据流。
- 验证联动：把仿真结果与需求指标比对，自动或半自动地判定“满足/不满足/不确定”，并把证据关联到具体需求条目。
需要强调的是，联动验证不是“用仿真替代试验”，也不是“把模型导出成仿真代码”这么单一的动作。它的核心价值在于可追溯性：任何一条验证结论，都能沿“需求—系统模型元素—仿真模型—仿真结果—判定依据”这条链路回溯，从而在评审、变更和适航/安全认证中提供结构化证据。
二、为什么需要联动：一个典型场景
以某型电动舵机控制系统为例。需求规定：在额定负载2.5 N·m、母线电压28 V条件下，舵面从0°转到15°的调节时间不大于0.35 s，超调量不大于8%。传统做法是：控制工程师在MATLAB/Simulink中搭建控制回路仿真，得到调节时间0.31 s、超调6.2%，写一份仿真报告；系统工程师在SysML模型中描述该需求，但二者之间没有机器可读的关联。一旦需求变更（例如负载改为3.0 N·m），仿真报告是否仍然有效、需要重跑哪些用例，往往依赖人工判断。
引入联动验证后，SysML参数图（Parametric Diagram）中定义约束：ts ≤ 0.35 s、σ ≤ 8%，并把负载转矩、母线电压作为可配置参数。仿真模型通过接口读取这些参数实例，运行后把ts、σ回写。当负载参数被修改为3.0 N·m时，系统能识别出受影响的验证用例并触发重跑，最终在模型上直接显示“需求R-012：不满足（ts=0.41 s）”。这就是联动验证带来的工程效率与证据完整性。
三、典型应用场景
联动验证并非只适用于飞行控制。以下几类场景收益最明显：
- 多物理场耦合系统：如机电液一体化作动器，SysML描述结构与接口，Simulink/AMESim计算动态响应，联动后可自动检查接口变量量纲与取值范围是否一致。
- 需求频繁变更的预研项目：参数化需求与仿真用例绑定后，变更影响分析从“人工排查”变为“模型查询”。
- 安全关键系统的验证证据管理：每条需求对应仿真用例、结果文件和判定结论，形成可审计的证据包。
- 数字孪生与在环测试：系统模型作为孪生体的语义骨架，仿真模型作为实时计算内核，联动机制保证二者状态同步。
四、课程目标与学习路径
本课程共30章，目标是让学习者能够独立完成一条“从需求到仿真证据”的联动验证链路。学习路径按能力递进组织：
- 认知与建模基础（第1～6章）：理解MBSE与仿真的关系，掌握SysML需求图、块定义图、参数图、状态机的基本表达，能建立可被仿真引用的系统模型骨架。
- 联动机制与接口（第7～14章）：学习参数绑定、端口映射、状态机与仿真事件的对应、FMI/FMU等交换标准，掌握模型导出与集成的具体操作。
- 验证用例与判定（第15～22章）：编写可执行的验证用例，定义通过准则，处理边界工况与不确定性，生成验证矩阵与证据报告。
- 工程化与综合实战（第23～30章）：版本与变更管理、自动化回归、多工具链协同，并以一个完整案例贯穿需求、建模、仿真、判定与复盘。