3. 系统生命周期数据分类与建模
在MBSE项目中，数据管理失败往往不是因为工具不够强，而是因为五类核心数据——需求、架构、仿真、测试、配置——被混在同一个“文件池”里，缺少清晰的分类边界和统一的元模型约束。结果是：需求变更后找不到受影响的架构元素，仿真结果无法回溯到具体模型版本，测试用例与需求之间的追溯链断裂。本节要解决的就是这个问题：先建立分类方法，再为每类数据设计可落地的元模型。
一、分类方法：按“语义角色”而非“文件格式”划分
常见的错误分类是按文件扩展名划分，比如把 .reqif 归为需求、把 .xml 归为架构。这种分法在跨工具协作时会立刻失效，因为同一个 .xml 可能承载架构模型、仿真参数或测试配置。正确的做法是按数据在生命周期中承担的语义角色来分类，判断依据有三个：
- 回答什么问题：需求回答“系统必须做什么”，架构回答“由哪些部件、以什么接口实现”，仿真回答“在给定条件下行为是否满足指标”，测试回答“实物或模型是否真的满足”，配置回答“当前基线由哪些版本组成”。
- 变更驱动源：需求由利益相关方诉求驱动，架构由需求分解驱动，仿真由架构方案与验证目标驱动，测试由需求验收条件驱动，配置由上述任何一类数据的版本发布驱动。
- 生命周期跨度：需求与架构贯穿全生命周期，仿真数据通常集中在设计验证阶段，测试数据集中在集成与确认阶段，配置数据则贯穿始终并作为基线锚点。
基于这三个判据，可以给每类数据定义一组“分类标签”，例如需求数据标签为 REQ-FUNC、REQ-PERF、REQ-IF；架构数据标签为 ARCH-LOG、ARCH-PHY、ARCH-IF；仿真数据标签为 SIM-MODEL、SIM-CASE、SIM-RESULT；测试数据标签为 TEST-CASE、TEST-PROC、TEST-RESULT；配置数据标签为 CFG-BASE、CFG-CHANGE、CFG-REL。标签不是装饰，而是后续元模型中外键关联的依据。
二、元模型设计：五类数据的核心实体与关联
元模型是分类的“结构化落地”。每类数据至少需要一个核心实体、一组属性、以及与其他类数据的关联边。下面给出一个可直接用于建模工具或数据仓库的元模型骨架。
| 数据类 | 核心实体 | 关键属性 | 对外关联 |
|---|---|---|---|
| 需求数据 | Requirement | reqId、text、type、priority、verificationMethod、status | satisfiedBy → ArchitectureElement；verifiedBy → TestCase |
| 架构数据 | ArchitectureElement | archId、name、layer、interface、allocatedTo | realizes → Requirement；simulatedBy → SimulationCase |
| 仿真数据 | SimulationCase | simId、modelRef、parameters、solver、resultRef | validates → Requirement；uses → ArchitectureElement |
| 测试数据 | TestCase | testId、procedure、expected、actual、verdict | verifies → Requirement；covers → ArchitectureElement |
| 配置数据 | Baseline | baselineId、timestamp、items[]、changeRef | contains → 上述任意实体版本 |
这个骨架的关键在于：配置数据不是第五类并列数据，而是其他四类数据的版本容器。一个基线（Baseline）通过 contains 关联到具体版本的需求、架构、仿真用例和测试用例。这样当需求变更时，配置管理可以精确回答“哪些基线受影响、哪些仿真和测试需要重跑”。
三、从分类到可执行：一个需求变更的追溯示例
假设某无人机项目有一条需求 REQ-PERF-012：“最大巡航速度不低于 25 m/s”。在元模型中，它关联到架构元素 ARCH-PHY-003（动力系统），并关联到仿真用例 SIM-CASE-007（巡航速度仿真）和测试用例 TEST-CASE-015（飞行速度实测）。当该需求从 25 m/s 提升到 30 m/s 时，配置管理触发变更流程：
- 在需求实体上更新
text和status=changed，生成新版本REQ-PERF-012-v2。 - 通过
satisfiedBy边找到ARCH-PHY-003，检查其allocatedTo是否仍满足新指标，若不满足则标记架构变更。 - 通过
validates边找到SIM-CASE-007，将其parameters中的目标速度从 25 改为 30，并标记为“待重跑”。 - 通过
verifies边找到TEST-CASE-015，更新expected值，并标记测试用例需重新评审。 - 创建新基线
BL-2025-03-01，将上述四个实体的新版本纳入items[]，旧基线保持只读。
这个过程中，元模型的价值在于：每一步追溯都是通过实体间的显式关联边完成的，而不是靠人工翻文件夹。判断变更是否闭环的标准也很明确——所有受影响的仿真和测试用例都产生了新版本，并且新基线中不再引用旧版本实体。
四、五类数据的元模型关系总览
下面的SVG以关系图形式呈现五类数据的核心实体、关键属性和关联方向。图中用不同颜色区分数据类，用带箭头的连线表示元模型中的引用关系，箭头旁标注关联名称。这张图可以直接作为建模工具中元模型定义的参考草图。
从图中可以读出三个关键设计决策：第一，需求是追溯链的起点，架构、仿真、测试都通过显式关联边指向需求；第二，架构同时被仿真和测试覆盖，但关联名称不同（simulatedBy 与 covers），语义不能混用；第三，配置基线以虚线包含所有实体版本，说明它是跨类的版本锚点，而不是与需求并列的第五类“内容数据”。
五、落地检查要点
在工具中实现上述元模型时，建议逐项确认：每类数据的核心实体是否都有唯一标识属性（如 reqId、archId）；跨类关联是否都定义了方向明确的关联名；配置基线是否只引用版本而不复制内容；仿真和测试结果是否都保留了指向具体模型版本和需求版本的引用。如果这四点都满足，后续的需求变更影响分析、覆盖率统计和基线审计就可以基于元模型自动完成，而不需要人工维护追溯矩阵。