告别 Excel 手算：用 SysML 参数图 Par 把牛顿定律写进设计

一篇讲清：参数图（Par）为什么是 SysML 区别于 UML 的核心武器、约束块三件套怎么搭、从 BDD 到可求解模型的完整流程，以及新手最容易踩的 4 个坑。

一、为什么设计评审总在"拍脑袋算性能"？

先看一个几乎每个硬件项目都会遇到的场景。

某电动无人机团队在做续航评审。电池容量 6800mAh，电机功率 240W，整机质量 12kg——这些数字散落在 BOM 表、电机规格书和电池 datasheet 三份文档里。

评审会上有人问了一句："如果质量加到 14kg，续航会掉多少？"

全场沉默了五分钟。因为没人能立刻回答这个问题——续航 = f(电池能量, 质量, 功率, 空气阻力) 这个关系只存在于总师的脑子里，没有写在任何文档里，更没有跟模型关联起来。最后只能说"我们回去算一下"，一算就是两天。

这不是个例。有行业数据支撑：

差别不在于"算得更认真"，而在于换了一种载体——SysML 的参数图（Parametric Diagram，简称 PAR）。

二、参数图不是"画出来的公式"，而是给设计装上的物理法则引擎

很多人第一次看参数图会说：这不就是 F=ma 写在图上吗？Excel 里也能写公式啊。

关键区别在这里：

• Excel 里的公式是死的：你改了 A1 单元格的值，B2 会自动更新——但前提是你得记得把所有相关单元格都串上公式链。一旦项目有 300 个参数、20 条物理规律，这个 Excel 就变成了没人敢动的"雷区"。
• 参数图里的约束是活的：约束块（ConstraintBlock）封装了一条数学或物理规律，它的参数通过绑定连接器（BindingConnector）精确地连到块的值属性上。改任何一个值，整条约束链自动重算，而且每一步都有模型元素可追溯。

一个类比：

一句话记住：参数图 = 把物理定律写成模型元素，让性能可算、可追溯、可验证。

参数图 vs 其他 SysML 图表

注意最后一行：UML 没有参数图。这是 SysML 最核心的差异化价值之一——如果你做的系统需要量化分析（几乎所有工程系统都需要的），SysML 是比 UML 更自然的选择。

三、参数图的三件套：拆开讲

参数图虽然看起来复杂，但本质上只有三个核心概念。掌握这三件套，就能画出任何参数图。

① 约束块 ConstraintBlock —— 封装一条规律

约束块是一种特殊的块，专门用来封装数学表达式或物理定律。它内部包含若干「约束参数」（ConstraintParameter），相当于这条规律的"输入/输出引脚"。

«constraintBlock» 牛顿第二定律
┌─────────────────────────────┐
│ parameters                   │
│   F : Real [N]              │    ← 输出引脚：力
│   m : Real [kg]             │    ← 输入引脚：质量
│   a : Real [m/s²]           │    ← 输入引脚：加速度
│                             │
│ { constraint : F = m · a }  │    ← 规律本身
└─────────────────────────────┘

类比：约束块就像一个函数定义 F(m, a) = m * a。它本身不存储具体数值，只描述"量之间应该满足什么关系"。

② 约束参数 ConstraintParameter —— 规律的引脚

约束参数就是约束块内部的 typed 属性，声明了这条规律涉及哪些量以及它们的类型和单位。

要点：

• 每个参数都要显式声明类型和单位（如 Real [N]），否则求解器无法做单位换算；
• 参数没有固定方向（输入/输出），取决于你怎么绑——这给了建模者很大灵活性；
• 一个约束块通常封装一条规律，不要塞太多参数进去（详见陷阱 #4）。

③ 绑定连接器 BindingConnector —— 把参数"钉"到属性上

这是参数图的灵魂操作。绑定连接器用 = 或 «equal» 记法，把约束块的一个参数等于某个块实例的一个值属性。

F ─────=───── :vehicle.force
m ─────=───── :vehicle.mass
a ─────=───── :vehicle.accel

一旦三条绑定都建好，求解器就知道：vehicle.force = vehicle.mass × vehicle.accel。改 mass 或 accel，force 自动重算。

四、分步实战：从零画一张可求解的参数图

下面用一个完整的例子演示：给一辆电动车建立"驱动力 = 质量 × 加速度"的参数约束。

Step 1：在 BDD 定义带值属性的块

首先在块定义图（BDD）中定义你的系统块，并给它加上值属性（values）——这些就是后续要参与计算的变量。

«block» 整车 Vehicle
┌──────────────────────────┐
│ values 值属性             │
│   mass   : Real [kg]     │   ← 车重
│   force  : Real [N]      │   ← 驱动力
│   accel  : Real [m/s²]   │   ← 加速度
│   power  : Real [W]      │   ← 功率
│                           │
│ constraints 约束          │
│   Newton2nd               │   ← 引用约束块
└──────────────────────────┘

操作要点：

1. 值属性的命名要有业务含义（mass 比 v1 好 100 倍）；
2. 类型统一用 Real（浮点数），单位写在方括号里 [kg] [N]；
3. 在 constraints 隔间引用你要用的约束块（如 Newton2nd）。

Step 2：定义约束块

在同一张 BDD（或单独的包）中创建约束块：

«constraintBlock» Newton2nd
┌──────────────────────────┐
│ parameters               │
│   F : Real [N]           │
│   m : Real [kg]          │
│   a : Real [m/s²]        │
│                          │
│ { F = m · a }            │
└──────────────────────────┘

操作要点：

1. 约束块名用英文驼峰（Newton2nd），方便工具识别；
2. 参数数量控制在 3–7 个，一个块只封装一条规律；
3. 表达式可以用 OCL（SysML 1.6 新增支持）或自然语言。

Step 3：在参数图中组装

新建一张参数图（PAR），执行以下操作：

1. 从浏览器拖入约束块 Newton2nd 的实例；
2. 从浏览器拖入块 Vehicle 的实例 :vehicle；
3. 用绑定连接器 = 把对应参数一一连接：

   • F ↔ :vehicle.force

   • m ↔ :vehicle.mass

   • a ↔ :vehicle.accel

完成！这张图现在是一个可求解的方程组。

Step 4：联仿求解

参数图本身只是"声明式"的——它告诉你量之间有什么关系，但不负责计算。计算交给外部求解器：

典型工作流：SysML 建模 → 导出参数约束 → 求解器计算 → 结果回填需求验证。

Step 5：结果回填需求验证

算出的值不是终点——终点是回答"是否满足需求"。在需求图中建立 verify 关系：

REQ-PERF-001（最大驱动力 ≥ 3500N）
      «verify»
TC-FORCE-001（测试用例）
      «satisfy»
:vehicle.force（参数图算出 3600N ✅）

这就是 SysML 的闭环：需求 → 设计 → 约束 → 计算 → 验证，全程可追溯。

五、实战案例：某卫星电源系统的重量预算

背景

某低轨卫星团队在做电源子系统设计。太阳能帆板面积受整星包络限制（最大 8 m²），但载荷功率需求在评审中从 520W 上调到 650W——增幅 25%。

挑战：

1. 太阳能帆板面积、转换效率、电池容量、放电深度、轨道周期……17 个参数散落在 5 份文档中；
2. 改一个功率需求，要手动重算：帆板够不够？电池能不能穿过阴影区？重量超不超标？
3. 每次评审都要花 2–3 天做手工计算，还经常算错。

方案

团队用 SysML 参数图做了三件事：

1. BDD 定义值属性块：电源子系统 PowerSubsystem 含 17 个值属性（面积、效率、容量、DOD 等）；
2. 创建 6 个约束块：分别封装能量平衡、重量预算、热平衡、轨道光照等规律；
3. 参数图绑定 + MATLAB 联仿：17 个参数通过 6 条约束形成可求解网络。

成效

最关键的是：当功率需求再次调整时，团队第一次在评审现场就给出了答案——而不是"我们回去算一下"。

六、最佳实践与常见陷阱

最佳实践清单

1. 保持简单：一个约束块只封装一条规律，复杂规律分层组合（如"能量守恒"调用"发电量"和"耗电量"两个子约束块）；
2. 命名一致：约束块参数名与块值属性名保持语义一致（都用 mass 而非一边用 m 一边用 weight）；
3. 显式声明单位：每个值属性和参数都带 [单位]，让求解器自动处理量纲；
4. 定期审查：参数图也是活文档——需求变了，约束也要跟着更新；
5. 先 BDD 再 Par：永远先在 BDD 中定义好块的值属性和约束块，再在参数图中连线。

⚠️ 新手必踩的 4 个坑

坑 1：把 IBD 当参数图 IBD 画的是部件之间怎么接（端口 + 连接器），参数图画的是量之间怎么算（约束 + 绑定）。两者长得有点像（都有方框和线），但语义完全不同。 → 记住：要算约束 → 用 Par；要画结构连接 → 用 IBD。

坑 2：漏写 BindingConnector 约束块参数没用 = 绑到块属性上，方程就"悬空"了——看着像参数图，实际上求解器读不到任何数据。 → 每个约束参数都必须有一条 = 连到具体的值属性。

坑 3：单位/类型不一致 F 用 N、m 用 kg、a 用 m/s²——如果某个属性漏写了单位，或者用了不同的类型（Integer vs Real），求解器要么报错要么给出荒谬的结果。 → 给每个值属性和参数显式声明类型与单位（Real [N]）。

坑 4：约束块太复杂 一个约束块塞了 30 个参数，调试时如同拆炸弹——改一个参数不知道会影响哪条约束。 → 一个约束块只封装一条规律；复杂规律拆成多个约束块，再用参数图组合。

七、速查结语：参数图的核心价值

回顾一下参数图的工作流：

1. BDD 定义值属性 — 声明"我要算哪些量"
2. 创建约束块 — 封装"它们之间满足什么规律"
3. 参数图绑定 — 用 = 把规律"钉"到具体属性上
4. 求解器计算 — 让机器替你算
5. 回填需求验证 — 算出来的值满足要求吗？

参数图的价值不只是"算得快"——它是把工程知识从人脑转移到模型里的过程。当一个人脑子里的公式变成团队共享的模型元素时，知识就不再随人员流动而流失。

掌握 SysML 参数图不仅是技术能力，更是组织竞争力——它让你的设计决策从"拍脑袋"变成"有数据支撑"，从"靠经验"变成"可复现"。

下一步建议：如果你已经在用 SysML 的 BDD 和需求图，参数图是最值得尝试的下一个图表——因为它能把你的架构设计和需求管理真正"串"成一个可量化的闭环。

本文基于 OMG SysML 1.6 规范撰写。