MBSE 系列 — Ran Wei

模块 7：MagicGrid

一种通过抽象层次和关注点来组织 MBSE 模型的结构化矩阵方法 — 以电动汽车充电站为贯穿示例。

MagicGrid 起源

MagicGrid 由 No Magic（现属 达索系统 Dassault Systèmes）开发，是一种实用且具有规范性的 MBSE 方法学。与停留在抽象原则层面的学术框架不同，MagicGrid 从一开始就以直接可用为设计目标 — 为填充 MBSE 模型提供清晰的、逐步执行的操作指南。

该方法学源于多年来使用 Cameo Systems Modeler 的咨询实践经验，最初由 No Magic 在 MBSE Grid-Based Approach 技术论文中公开发表。它要回答的核心问题非常直接："我已经打开了建模工具 — 应该先建什么模型？每张图放在哪里？"

设计理念

MagicGrid 基于两个组织原则：

抽象层次 — 将系统必须做什么（问题域）与如何做（解决方案域）以及用什么实现（实现域）分离。
关注点列 — 将需求、结构、行为和参数化分析分开，使系统的每个方面都有专属区域。

行（抽象层次）与列（关注点）的交叉单元格精确告诉你应创建哪些 SysML 图和模型元素。这使得 MagicGrid 对 MBSE 新手团队非常友好。

说明

尽管 MagicGrid 是配合 Cameo Systems Modeler 开发的，但其底层概念是工具无关的。网格结构、抽象层次和关注点列可以在任何支持 SysML 的工具中使用 — 包括 Eclipse Papyrus 等开源选项或新兴的 SysML v2 工具生态。

网格结构

MagicGrid 的核心是一个 3 × 4 矩阵。行代表抽象层次，列代表工程关注点。你创建的每个模型元素在该网格中都有明确的"地址"。

类比

把 MagicGrid 想象成一张电子表格：行是"缩放级别"（你看到多少细节），列是"视角"（你在看哪种细节）。就像你不会在同一个电子表格列中混合收入数据和人员编制一样，你不会在同一个网格单元中混合结构图和行为图。

行 — 抽象层次

问题域（黑盒） — 系统是一个不透明的盒子；我们定义外部交互，不暴露内部结构。
解决方案域（白盒） — 打开盒子，描述逻辑内部架构。
实现域 — 将逻辑架构映射到物理组件、硬件、软件和服务。

列 — 工程关注点

需求 — 系统必须做什么或满足什么。
结构 — 系统由什么组成（部件、连接、接口）。
行为 — 系统如何随时间运行（活动、状态、交互）。
参数化 — 定量约束、方程和效能度量。

3 × 4 网格一览

	需求	结构	行为	参数化
问题域（黑盒）	利益相关方需求、系统级需求	系统上下文图、外部参与者	用例、高层活动图	效能度量（MoE）、关键性能参数
解决方案域（白盒）	子系统需求、派生需求	逻辑架构、内部块图	状态机、详细活动图、序列图	约束块、权衡方程
实现域	接口需求、组件规格	物理架构、已分配组件	实现层交互、部署序列	验证约束、测试参数

表 1 — MagicGrid 3 × 4 矩阵及各单元示例工件

通常自上而下（从问题域到实现域）遍历网格，每行内部大致从左到右推进，但跨单元的迭代是预期且鼓励的。

问题域（黑盒）

在问题域这一行中，系统被视为一个不透明的盒子。我们定义它必须做什么，而不决定如何做。这迫使工程团队在跳到解决方案之前充分理解问题。

贯穿示例：电动汽车充电站

在本模块中，我们以一个电动汽车充电站作为贯穿示例。该系统为电动汽车充电、处理支付、与电网通信，并向站点所有者提供状态信息。

利益相关方

问题域的第一步是识别谁与系统交互、谁对系统有利益关切：

电动汽车驾驶员 — 主要用户，为车辆充电并支付费用。
电网运营商 — 电力供应方，供电并需要负载管理数据。
充电站所有者 — 拥有和运营充电基础设施的商业实体，关注正常运行时间、收入和维护。

用例

用例捕获系统的外部可见功能：

为车辆充电 — 主要功能；驾驶员插入充电枪，充电站输送电能。
监控状态 — 站点所有者（或自动化系统）检查实时状态 — 可用性、故障状态、已输送电量。
处理支付 — 系统处理非接触式支付、授权和交易记录。

系统上下文

此层级的系统上下文图将电动汽车充电站显示为一个单独的块，周围是参与者（电动汽车驾驶员、电网运营商、站点所有者）和外部系统（支付网关、电网、云监控平台）。所有接口都是外部的 — 我们尚未展示站内结构。

效能度量

问题域中的参数化捕获高层性能目标：

充电功率：50–350 kW（直流快充）
支付处理时间：< 3 秒
系统可用性：≥ 99.5%
平均修复时间：≤ 4 小时

提示

在此阶段要抵制跳入内部设计的冲动。黑盒纪律确保每一条需求都可追溯到真正的利益相关方需求 — 而非某个假定的技术方案。如果你发现自己在讨论具体的硬件或软件选择，说明已经过早进入了解决方案域。

解决方案域（白盒）

在定义了系统必须做什么之后，我们现在打开盒子，描述它如何实现这些目标。解决方案域引入逻辑架构 — 子系统、内部接口、状态机和详细行为。

逻辑分解

对于我们的电动汽车充电站，逻辑子系统包括：

充电控制器 — 管理充电协议（CCS、CHAdeMO 或交流 Type 2），控制功率输出，处理安全联锁。
支付处理器 — 处理 NFC 读卡、在线授权和交易记录。
能源管理 — 与电网运营商通信以进行负载均衡，监控功率消耗，实施智能充电调度。
用户界面 — 引导驾驶员完成充电过程的显示屏和物理控件 — 插枪说明、充电进度和收据。

内部结构

此层级的内部块图展示四个子系统如何连接。充电控制器与能源管理交换功率指令；支付处理器向充电控制器发送授权状态（仅在确认付款后才开始充电）；用户界面与其他所有子系统通信以显示状态。

行为建模

状态机描述充电会话的生命周期：空闲 → 认证中 → 充电中 → 已完成 → 空闲，任何状态都可以因故障转换到故障状态。活动图详细描述每个状态转换内的操作序列。

约束块

解决方案层级的参数化约束表达工程权衡。例如，一个约束块可以关联充电功率、电缆温度和会话时长，以确保永远不超过热极限。

说明

解决方案域中的每个元素都应追溯回问题域的需求。充电控制器的存在是因为有"为车辆充电"用例。支付处理器的存在是因为有"处理支付"用例。如果某个解决方案域元素没有指向问题域的可追溯性，就需要质疑它是否必要。

实现域

实现行在逻辑架构与现实世界之间架起桥梁。在这里，逻辑子系统被分配给物理组件，接口规格变得具体。

从逻辑到物理

电动汽车充电站从解决方案域子系统到实现域组件的分配：

充电控制器 → 专用嵌入式 ECU（例如基于 ARM Cortex 的工业控制器），运行实现 CCS/CHAdeMO 协议栈的实时固件。
支付处理器 → NFC 读卡器（站点物理硬件）与云支付服务（远程软件）的组合，通过 4G/5G 连接。
能源管理 → 站点的智能电表和电力电子模块，通过 OCPP（开放充电点协议）与云端能源管理平台通信。
用户界面 → 加固型触摸屏显示器、LED 状态指示灯，以及可选的手机 App 配套应用。

接口规格

在实现层级，接口变成具体的协议和物理连接器：

充电控制器 ↔ 能源管理：CAN 总线（物理层）、OCPP 2.0.1（应用层）
支付处理器 ↔ 云服务：基于 4G 的 HTTPS/TLS、ISO 8583 报文格式
用户界面 ↔ 充电控制器：内部以太网、MQTT 状态更新

验证约束

此层级的参数化约束直接映射到测试规程。例如："NFC 读卡器应在 500 毫秒内完成非接触式交易"是分配给支付处理器硬件的可测试约束。

提示

实现域是 MagicGrid 连接采购和制造的地方。此行中的每个物理组件都应可向上追溯到逻辑子系统（解决方案域），最终追溯到利益相关方需求（问题域）。这种端到端的可追溯性是 MBSE 最大的优势之一 — 而 MagicGrid 的网格结构使其一目了然。

MagicGrid 与 OOSEM

模块 6 介绍了 OOSEM（面向对象的系统工程方法）。OOSEM 和 MagicGrid 都是广泛使用的 MBSE 框架，但它们在理念、组织方式和侧重点上有所不同。下表从六个维度进行比较。

维度	MagicGrid	OOSEM
起源	No Magic / 达索系统 — 源于工具厂商咨询实践	INCOSE / 洛克希德·马丁 — 源于系统工程实践
过程风格	基于网格，规范性强："填充每个单元格"	面向过程，迭代式："遵循生命周期步骤"
模型组织	高度结构化 — 3×4 矩阵精确定义每个工件的位置	灵活 — 围绕过程阶段组织（利益相关方需求分析、需求分析、逻辑架构等）
语言依赖	为 SysML 设计，但原则上工具无关	语言无关；常与 SysML v1 和 v2 配合使用
最适用于	需要清晰、可重复操作指南的团队；MBSE 新手组织	需要灵活性的资深系统工程团队；利益相关方关系复杂的项目
复杂度	学习曲线较低 — 网格提供即时结构	学习曲线较高 — 需要更强的过程纪律，但适应性更强

表 2 — MagicGrid 与 OOSEM 对比

在实践中，两种框架并非互斥。许多组织采用 MagicGrid 的模型组织方式（3×4 网格），同时在每个单元格内遵循 OOSEM 的过程步骤。关键是选择最适合团队成熟度和项目情境的方法 — 或两者的组合。

模块 8 — IBM Harmony — 一种以用例驱动、以架构为中心且强调行为的方法。