多域模型协同及集成环境构建技术研究

白 燚，鱼 瑛

（金航数码科技有限责任公司（航空工业信息技术中心），北京 100028）

关键字：OSLC；跨领域模型关联；数据集成；元数据；元数据架构

1 引言

随着近年来航空产品复杂程度的不断增加，伴随而来航空产品及系统的复杂性都在不断增高，目前行业多采用MBSE模式支撑高复杂系统，在产品各生命周期阶段会跨多个工程领域，各阶段利益相关人使用不同的领域工具来解决领域遇到的问题，进而出现了各阶段软件之间的异构问题，导致前设计端和后物理端之间数据的割裂。另外，由于异构数据不能完全整合，导致企业内部信息孤岛的产生，成为进一步提升企业研发能力的障碍。对航空复杂装备各阶段模型数据进行整合，可以打破产品研发过程中遇到的不同领域间的数据和工作流的壁垒，可以极大地帮助企业进行信息化改革，降低研发过程中的交流、管理成本，从而加快产品研发效率。

2 国内外研究现状

为了解决各平台之间的异构问题，像达索、IBM和西门子等大型公司，多是通过收购、整合多个平台/工具到自己的大平台中，实现统一大平台的全生命周期数据、模型处理。另一种做法是一些小型的工具/软件使用OSLC（Open Services of Lifecycle Collaboration，开放式生命周期协作服务）标准接口，采用链接数据核心思想，实现异构系统的互联互通。对比以上两种做法，第二种异构系统集成的方式，能更好地保护现有企业的资产，未来应用拓展具有更好的灵活性。

OSLC是由IBM提出的一套技术规范，主要用于解决产品生命周期内各种工具的集成问题，消除不同工具之间数据交互的障碍[1]。Kennedy Sean[2]等详细介绍了OSLC的域规范的基础就是OSLC核心规范，此规范以实现链接数据的应用集成来提供一种普遍适用机制。徐万磊[3]提出了基于JAZZ 框架采用OSLC的集成方法，通过设计与实现统一的服务接口，可以在各个模块之间直接查询和使用数据。Biehl Matthias[4]等讨论了OSLC作为工业工具集成计划的标准，在构建一个工具集成解决方案中，解决工具之间的必要数据交换。综上所述，本研究将基于OSLC标准进行集成环境构建，以支持多域模型关系的管理及追溯。

3 集成环境构建研究

为了实现异构平台、多领域模型之间的集成，本研究选取航空复杂装备需求模型、功能架构模型和联合仿真模型的协同作为典型业务场景，经过OSLC数据接口设计，通过对各领域模型的元数据架构的表达，构建基础模型库平台，开展集成环境构建研究。

3.1 OSLC数据接口设计

为支持复杂装备的研制，在各阶段会使用到不同的软件/工具，会涉及到不同的标准。OSLC的规范中也对通用数据接口进行了明确的定义和要求，目前已经被大多数工具所支持，因此本文也针对OSLC的通用数据接口规范进行了设计，对不同的工具进行了集成，以满足不同领域模型、不同场景下对于集成环境的需求。

（1）OSLC数据接口模型 OSLC规范中，对于数据接口的模型如图1所示。

图1 OSLC数据接口模型

OSLC的数据接口模型分为三个层次：

1）基础服务（Service）是模型最基础的功能集合，例如增、删、改和查等细粒度的操作。

2）资源容器（资源提供者）（Service Provider）代表了具体的资源对象，例如一个Web服务、一个数据库对象等，它通过URI进行标识，使用URI：//ServiceProvider/Service的方式就可以对一个具体的资源对象进行不同的操作。

3）资源容器目录（Service Provider Catalog），它是资源容器的集合，例如一个大型系统的所有服务、一个数据库的所有对象表等，它不仅可以涵盖Service Provider，也可以涵盖别的Service Provider Catalog。

以上三个层次的所有组件之间，均可通过RESTful风格进行数据交互，用户端无需关注底层实现逻辑，只要构造请求-发送请求-接收返回，即可以完成基于Web的异构访问，无论是开发还是使用，效率均进行了大规模的提高。

（2）异构数据集成接口模型 根据OSLC提供的核心规范定义，基础服务、资源容器和资源容器目录是软件协同开发的三大要素，URI是最底层的标识，通过URL对系统中的资源进行具体操作。针对不同的要素，本文设计了如下接口：

1）资源内部接口。Service Provider与Service的通信接口。该接口为原子性接口，由于在系统内部，Service Provider可以对所有Service提供的服务进行调用，使用URI进行直接通信，例如URI：//inert，URI：//delete等。

2）资源间接口。Service Provider与Service Provider的通信接口。系统与系统之间会发生频繁的交互，但又由于资源间的相互不透明性、安全性等原因，无法相互暴露具体实现细节，因此本文设计了事物性的资源间接口。Service Provider通过一系列的事务性定义，在各个系统内部维护一个事务性的动作列表，通过统一的通信接口进行交互，以完成一系列的复杂性任务。

事务的定义，例如找出需求模型的某个属性，在URI上可以表示为，URI：//demand_model_service_provider/some_attributes。这种事务性的接口抽象了具体的业务流程，即简化了相互之间的交互规则，又保护好各个系统内部的独立性、可靠性。

3）资源容器目录接口。Service Provider Catalog与Service Provider的通信接口。资源容器目录对资源容器发起访问请求，这种交互多为项目级别的，例如获取需求模型和功能架构模型某参数，进行关联，若需求模型参数发生变更，则同步功能模架构模型参数。这种请求涉及多个Service Provider和一系列的交互操作，根据资源容器接口的设置，只需维护一个项目级业务流程、结合资源间接口的事物流程，就可以完成这种复杂的操作。所以该例子的接口可以设计为，URI：//demand_model_service_provider && function_architecture_provider/ association_if_change_sync_functional_framework_parameters，即本文设计的项目级的资源容器目录接口。

4）用户交互接口。OSLC Service通过HTTP对资源进行操作。用户在通过HTTP请求即可以对整个系统进行项目级别的操作，接口如图2所示。

图2 OSLC用户交互接口模型

3.2 各模型的元数据架构

ISO/IEC 11179规范定义元数据是定义和描述其他数据的数据[5]。为了支撑在同一平台中多域模型的协同，采用“对象+属性”的方式定义三类模型的元数据架构。元数据架构是以数据对象为核心，将与之相关的其他信息如属性、生命周期、操作和权限等数据灵活的组织在一起，这种建模能够通过添加特定领域的扩展来发展全局元数据模型，而不会受到已有模型的现状。

需求元数据架构主要围绕需要条目，功能架构元数据架构主要围绕功能模块，联合仿真元数据架构主要围绕FMU及仿真结果进行设计和定义。

4 基础模型库平台与各领域平台间数据的协同

为了实现多域模型基于同平台各领域工具间的协同，本文基于构建的基础模型库平台，选取某需求管理平台、某功能架构平台和某联合仿真平台，通过OSLC标准的数据接口获取各平台的模型数据，在基础模型库平台同一界面中，可以对从三个平台中直接获取的需求模型、功能架构模型和仿真模型信息进行树形结构的表达和展示，支持在模型间建立关联关系及基于关系进行追溯。多域模型协同及集成环境构建如图3所示。

图3 多域模型协同及集成环境构建

4.1 基于OSLC接口模型的集成

与某需求管理平台、某功能架构平台和某联合仿真平台的集成，主要是通过OSLC接口模型的方式拉取需求管理平台、功能架构平台和联合仿真平台的数据和相关的页面，实现与三个平台的集成。在基础模型的需求库内可以查看具体的每一个需求条目的具体信息，在功能架构库内可以查看功能架构树结构，在仿真模型库中可以查看到仿真结果数据。结构树中每个节点包含了它的OSLC链接，通过该链接，可以追溯到具体的模型信息详情页。

4.2 多域模型间关系的创建及追踪

基于三类模型元数据架构的表达，通过与三个平台的集成，基础模型库获取到对应的三类模型的树形结构展示，基于三个树形结构，对各阶段模型之间建立关联关系，可进行关系链接的详细分析，进而形成一个关系网络，依据关系网络能够进行变更时关联关系的追踪和反馈，实现多域模型的协同。需求、功能架构和仿真模型之间的关联关系如图4所示。

5 结论

本研究围绕异域模型之间的协同问题，基于OSLC数据接口及各模型元数据架构进行集成研究的构建，支撑各阶段模型（需求模型、功能架构模型和仿真模型）信息的共享与关联，基于模型关联关系驱动更改影响分析互通和协同工作。该研究是全生命周期模型数据贯通使用的第一步，未来对这些数据如何高效的使用，如何让这些数据产生意义和价值，才是贯通、应用的最终目的。