4. 数据管理标准与规范

MBSE 的生命周期数据管理不是“把文件放进一个目录”那么简单。它要解决的是：不同阶段、不同专业、不同工具产生的模型与文档，如何用共同的语言描述、用可追溯的标识关联、用可交换的格式流转。围绕这一目标，工程实践中形成了一组分工明确的标准：ISO 15288 管“过程”，ISO 10303 管“数据表达与交换”，SysML 管“系统建模语言”，OSLC 管“跨工具数据链接”，STEP AP233 管“系统工程数据的交换实现”。理解它们各自管什么、边界在哪里，比记住标准编号更重要。

一、五类标准的分工定位

可以把它们放在一条“从过程到数据、从建模到交换”的链条上理解：

• ISO/IEC/IEEE 15288（系统生命周期过程）：定义技术过程、项目管理过程、协议过程等，回答“生命周期各阶段应该做哪些活动、产出什么信息项”。它是数据管理的需求来源——先有过程定义，才知道要管哪些数据。
• ISO 10303（STEP，产品数据表达与交换）：定义产品数据的通用表达框架，包括 EXPRESS 模式语言、应用协议（AP）和实现方法。它回答“数据用什么结构描述、如何跨系统交换”。
• SysML：基于 UML 的系统建模语言，提供需求图、块定义图、内部块图、活动图、参数图等，回答“模型用什么语义表达”。SysML 模型是数据管理的核心内容对象。
• OSLC（Open Services for Lifecycle Collaboration）：基于 HTTP/RDF 的开放服务规范，通过资源 URI 和链接实现需求、设计、测试、缺陷等跨工具数据的关联，回答“分散在不同工具中的数据如何互相引用”。
• STEP AP233（系统工程数据交换）：ISO 10303 的应用协议之一，面向系统工程，规定需求、功能、行为、接口等系统建模信息如何用 STEP 结构表达和交换，回答“SysML 类模型数据如何落地为可交换的 STEP 文件”。

它们不是替代关系，而是层次互补：15288 给出过程与信息项，SysML 给出建模语义，OSLC 给出在线链接机制，10303/AP233 给出离线交换格式。一个完整的生命周期数据管理方案，往往同时用到其中多个。

二、ISO 15288 与 ISO 10303 的配合方式

ISO 15288 把生命周期划分为概念、开发、生产、使用、支持、退役等阶段，每个阶段有对应的技术过程，如利益相关方需求定义、系统需求定义、架构定义、设计定义、系统分析、实现、集成、验证、确认、运行、维护、处置。每个过程都会产生“信息项”，例如需求规格、架构描述、接口控制文档、验证报告。这些信息项就是数据管理要纳管的对象。

ISO 10303 则提供把这些信息项结构化的手段。它的核心是 EXPRESS 语言定义的模式（schema），以及在此之上的应用协议。以 AP233 为例，它定义了系统工程领域的信息模型，包括需求（Requirement）、功能（Function）、行为（Behavior）、接口（Interface）、验证（Verification）等实体及其关系。当 SysML 模型需要交付给另一个工具或另一个组织时，可以映射到 AP233 的实体结构，导出为 STEP 文件，接收方再按同一模式解析。

这里有一个关键点：15288 不规定数据格式，10303 不规定过程顺序。两者配合的方式是“过程定义信息项，信息项映射到 STEP 实体”。例如，15288 的“系统需求定义过程”产出需求规格，AP233 中的 Requirement 实体及其 Requirement_source、Requirement_derived 关系，就用来承载这些需求及其派生关系。

三、SysML 与 OSLC 的互补

SysML 解决的是“模型内部怎么表达”。需求图表达需求及其分解、派生、满足关系；块定义图表达系统结构；内部块图表达部件连接与接口；活动图表达功能流程；状态机图表达状态迁移；参数图表达约束与性能参数。这些图元在建模工具中形成模型元素，每个元素有唯一标识。

OSLC 解决的是“模型元素怎么和别的工具里的元素关联”。它不要求把数据集中到一个库，而是通过资源 URI 建立链接。例如，在需求管理工具中有一条需求 REQ-101，在 SysML 建模工具中有一个块 Block-A，在测试管理工具中有一个测试用例 TC-205。通过 OSLC，可以建立 REQ-101 satisfies Block-A、TC-205 verifies REQ-101 这样的链接。链接本身是 RDF 三元组，存储在 OSLC 服务提供者中，查询时通过 HTTP 获取。

这种机制的价值在于：需求变更时，不需要把整个模型复制过去，只需更新链接指向的资源；追溯关系可以跨工具实时查询，而不是靠人工维护表格。对于 MBSE 项目，OSLC 常被用来打通需求管理、建模、仿真、测试、缺陷管理这几类工具。

四、STEP AP233 的交换实现要点

AP233 的交换不是“导出即完成”，需要关注几个实现细节：

• 映射规则：SysML 元素到 AP233 实体的映射需要预先定义。例如 SysML Requirement 映射到 AP233 Requirement，SysML Block 映射到 AP233 Product 或 System，SysML Port 映射到 AP233 Interface。映射表应作为项目配置管理的一部分。
• 标识保持：交换前后元素的唯一标识（UUID 或项目内 ID）应保持一致，否则追溯链会断裂。建议在导出时保留源模型的 GUID，并在导入时校验。
• 版本与基线：AP233 文件应附带版本号和基线标识，接收方据此判断数据新旧。常见做法是在文件头或伴随的元数据文件中记录 baseline_id、export_time、source_tool。
• 校验：导入后应做一致性检查，包括实体数量、关系数量、关键属性是否丢失。可编写脚本对比导出前后的元素计数和链接计数。

五、标准落地时的常见问题

标准本身是框架，落地时容易遇到三类问题。第一类是“映射不完整”：SysML 的某些语义在 AP233 中没有直接对应实体，例如参数图中的约束表达式，可能需要用 AP233 的 Property 或 Representation 间接表达，导致信息损失。第二类是“标识不一致”：不同工具生成的 UUID 规则不同，OSLC 链接和 AP233 文件中的标识对不上，追溯链在工具边界处断开。第三类是“版本错配”：需求已更新到 B 版，但 AP233 文件还是 A 版，下游工具导入后产生不一致。

应对方式是在项目级建立“数据管理配置表”，明确每类数据的标准归属、标识规则、交换频率、校验方法和责任人。例如：需求数据以 OSLC 链接为主、AP233 导出为辅；架构数据以 SysML 模型为主、AP233 导出用于交付；测试数据以 OSLC 链接关联需求和模型。配置表本身也应纳入配置管理，随项目阶段更新。

总结来看，ISO 15288 回答“做什么过程、产出什么信息”，SysML 回答“模型怎么表达”，OSLC 回答“跨工具怎么链接”，ISO 10303/AP233 回答“数据怎么交换”。四者各司其职，共同支撑 MBSE 生命周期数据从产生、关联、交换到归档的完整链条。理解它们的边界与衔接点，是设计数据管理方案的基础。