白 燚，魚 瑛

（金航數(shù)碼科技有限責(zé)任公司（航空工業(yè)信息技術(shù)中心），北京 100028）

關(guān)鍵字：OSLC；跨領(lǐng)域模型關(guān)聯(lián)；數(shù)據(jù)集成；元數(shù)據(jù)；元數(shù)據(jù)架構(gòu)

1 引言

隨著近年來航空產(chǎn)品復(fù)雜程度的不斷增加，伴隨而來航空產(chǎn)品及系統(tǒng)的復(fù)雜性都在不斷增高，目前行業(yè)多采用MBSE模式支撐高復(fù)雜系統(tǒng)，在產(chǎn)品各生命周期階段會跨多個工程領(lǐng)域，各階段利益相關(guān)人使用不同的領(lǐng)域工具來解決領(lǐng)域遇到的問題，進而出現(xiàn)了各階段軟件之間的異構(gòu)問題，導(dǎo)致前設(shè)計端和后物理端之間數(shù)據(jù)的割裂。另外，由于異構(gòu)數(shù)據(jù)不能完全整合，導(dǎo)致企業(yè)內(nèi)部信息孤島的產(chǎn)生，成為進一步提升企業(yè)研發(fā)能力的障礙。對航空復(fù)雜裝備各階段模型數(shù)據(jù)進行整合，可以打破產(chǎn)品研發(fā)過程中遇到的不同領(lǐng)域間的數(shù)據(jù)和工作流的壁壘，可以極大地幫助企業(yè)進行信息化改革，降低研發(fā)過程中的交流、管理成本，從而加快產(chǎn)品研發(fā)效率。

2 國內(nèi)外研究現(xiàn)狀

為了解決各平臺之間的異構(gòu)問題，像達索、IBM和西門子等大型公司，多是通過收購、整合多個平臺/工具到自己的大平臺中，實現(xiàn)統(tǒng)一大平臺的全生命周期數(shù)據(jù)、模型處理。另一種做法是一些小型的工具/軟件使用OSLC（Open Services of Lifecycle Collaboration，開放式生命周期協(xié)作服務(wù)）標(biāo)準(zhǔn)接口，采用鏈接數(shù)據(jù)核心思想，實現(xiàn)異構(gòu)系統(tǒng)的互聯(lián)互通。對比以上兩種做法，第二種異構(gòu)系統(tǒng)集成的方式，能更好地保護現(xiàn)有企業(yè)的資產(chǎn)，未來應(yīng)用拓展具有更好的靈活性。

OSLC是由IBM提出的一套技術(shù)規(guī)范，主要用于解決產(chǎn)品生命周期內(nèi)各種工具的集成問題，消除不同工具之間數(shù)據(jù)交互的障礙[1]。Kennedy Sean[2]等詳細(xì)介紹了OSLC的域規(guī)范的基礎(chǔ)就是OSLC核心規(guī)范，此規(guī)范以實現(xiàn)鏈接數(shù)據(jù)的應(yīng)用集成來提供一種普遍適用機制。徐萬磊[3]提出了基于JAZZ 框架采用OSLC的集成方法，通過設(shè)計與實現(xiàn)統(tǒng)一的服務(wù)接口，可以在各個模塊之間直接查詢和使用數(shù)據(jù)。Biehl Matthias[4]等討論了OSLC作為工業(yè)工具集成計劃的標(biāo)準(zhǔn)，在構(gòu)建一個工具集成解決方案中，解決工具之間的必要數(shù)據(jù)交換。綜上所述，本研究將基于OSLC標(biāo)準(zhǔn)進行集成環(huán)境構(gòu)建，以支持多域模型關(guān)系的管理及追溯。

3 集成環(huán)境構(gòu)建研究

為了實現(xiàn)異構(gòu)平臺、多領(lǐng)域模型之間的集成，本研究選取航空復(fù)雜裝備需求模型、功能架構(gòu)模型和聯(lián)合仿真模型的協(xié)同作為典型業(yè)務(wù)場景，經(jīng)過OSLC數(shù)據(jù)接口設(shè)計，通過對各領(lǐng)域模型的元數(shù)據(jù)架構(gòu)的表達，構(gòu)建基礎(chǔ)模型庫平臺，開展集成環(huán)境構(gòu)建研究。

3.1 OSLC數(shù)據(jù)接口設(shè)計

為支持復(fù)雜裝備的研制，在各階段會使用到不同的軟件/工具，會涉及到不同的標(biāo)準(zhǔn)。OSLC的規(guī)范中也對通用數(shù)據(jù)接口進行了明確的定義和要求，目前已經(jīng)被大多數(shù)工具所支持，因此本文也針對OSLC的通用數(shù)據(jù)接口規(guī)范進行了設(shè)計，對不同的工具進行了集成，以滿足不同領(lǐng)域模型、不同場景下對于集成環(huán)境的需求。

（1）OSLC數(shù)據(jù)接口模型 OSLC規(guī)范中，對于數(shù)據(jù)接口的模型如圖1所示。

圖1 OSLC數(shù)據(jù)接口模型

OSLC的數(shù)據(jù)接口模型分為三個層次：

1）基礎(chǔ)服務(wù)（Service）是模型最基礎(chǔ)的功能集合，例如增、刪、改和查等細(xì)粒度的操作。

2）資源容器（資源提供者）（Service Provider）代表了具體的資源對象，例如一個Web服務(wù)、一個數(shù)據(jù)庫對象等，它通過URI進行標(biāo)識，使用URI：//ServiceProvider/Service的方式就可以對一個具體的資源對象進行不同的操作。

3）資源容器目錄（Service Provider Catalog），它是資源容器的集合，例如一個大型系統(tǒng)的所有服務(wù)、一個數(shù)據(jù)庫的所有對象表等，它不僅可以涵蓋Service Provider，也可以涵蓋別的Service Provider Catalog。

以上三個層次的所有組件之間，均可通過RESTful風(fēng)格進行數(shù)據(jù)交互，用戶端無需關(guān)注底層實現(xiàn)邏輯，只要構(gòu)造請求-發(fā)送請求-接收返回，即可以完成基于Web的異構(gòu)訪問，無論是開發(fā)還是使用，效率均進行了大規(guī)模的提高。

（2）異構(gòu)數(shù)據(jù)集成接口模型 根據(jù)OSLC提供的核心規(guī)范定義，基礎(chǔ)服務(wù)、資源容器和資源容器目錄是軟件協(xié)同開發(fā)的三大要素，URI是最底層的標(biāo)識，通過URL對系統(tǒng)中的資源進行具體操作。針對不同的要素，本文設(shè)計了如下接口：

1）資源內(nèi)部接口。Service Provider與Service的通信接口。該接口為原子性接口，由于在系統(tǒng)內(nèi)部，Service Provider可以對所有Service提供的服務(wù)進行調(diào)用，使用URI進行直接通信，例如URI：//inert，URI：//delete等。

2）資源間接口。Service Provider與Service Provider的通信接口。系統(tǒng)與系統(tǒng)之間會發(fā)生頻繁的交互，但又由于資源間的相互不透明性、安全性等原因，無法相互暴露具體實現(xiàn)細(xì)節(jié)，因此本文設(shè)計了事物性的資源間接口。Service Provider通過一系列的事務(wù)性定義，在各個系統(tǒng)內(nèi)部維護一個事務(wù)性的動作列表，通過統(tǒng)一的通信接口進行交互，以完成一系列的復(fù)雜性任務(wù)。

事務(wù)的定義，例如找出需求模型的某個屬性，在URI上可以表示為，URI：//demand_model_service_provider/some_attributes。這種事務(wù)性的接口抽象了具體的業(yè)務(wù)流程，即簡化了相互之間的交互規(guī)則，又保護好各個系統(tǒng)內(nèi)部的獨立性、可靠性。

3）資源容器目錄接口。Service Provider Catalog與Service Provider的通信接口。資源容器目錄對資源容器發(fā)起訪問請求，這種交互多為項目級別的，例如獲取需求模型和功能架構(gòu)模型某參數(shù)，進行關(guān)聯(lián)，若需求模型參數(shù)發(fā)生變更，則同步功能模架構(gòu)模型參數(shù)。這種請求涉及多個Service Provider和一系列的交互操作，根據(jù)資源容器接口的設(shè)置，只需維護一個項目級業(yè)務(wù)流程、結(jié)合資源間接口的事物流程，就可以完成這種復(fù)雜的操作。所以該例子的接口可以設(shè)計為，URI：//demand_model_service_provider && function_architecture_provider/ association_if_change_sync_functional_framework_parameters，即本文設(shè)計的項目級的資源容器目錄接口。

4）用戶交互接口。OSLC Service通過HTTP對資源進行操作。用戶在通過HTTP請求即可以對整個系統(tǒng)進行項目級別的操作，接口如圖2所示。

圖2 OSLC用戶交互接口模型

3.2 各模型的元數(shù)據(jù)架構(gòu)

ISO/IEC 11179規(guī)范定義元數(shù)據(jù)是定義和描述其他數(shù)據(jù)的數(shù)據(jù)[5]。為了支撐在同一平臺中多域模型的協(xié)同，采用“對象+屬性”的方式定義三類模型的元數(shù)據(jù)架構(gòu)。元數(shù)據(jù)架構(gòu)是以數(shù)據(jù)對象為核心，將與之相關(guān)的其他信息如屬性、生命周期、操作和權(quán)限等數(shù)據(jù)靈活的組織在一起，這種建模能夠通過添加特定領(lǐng)域的擴展來發(fā)展全局元數(shù)據(jù)模型，而不會受到已有模型的現(xiàn)狀。

需求元數(shù)據(jù)架構(gòu)主要圍繞需要條目，功能架構(gòu)元數(shù)據(jù)架構(gòu)主要圍繞功能模塊，聯(lián)合仿真元數(shù)據(jù)架構(gòu)主要圍繞FMU及仿真結(jié)果進行設(shè)計和定義。

4 基礎(chǔ)模型庫平臺與各領(lǐng)域平臺間數(shù)據(jù)的協(xié)同

為了實現(xiàn)多域模型基于同平臺各領(lǐng)域工具間的協(xié)同，本文基于構(gòu)建的基礎(chǔ)模型庫平臺，選取某需求管理平臺、某功能架構(gòu)平臺和某聯(lián)合仿真平臺，通過OSLC標(biāo)準(zhǔn)的數(shù)據(jù)接口獲取各平臺的模型數(shù)據(jù)，在基礎(chǔ)模型庫平臺同一界面中，可以對從三個平臺中直接獲取的需求模型、功能架構(gòu)模型和仿真模型信息進行樹形結(jié)構(gòu)的表達和展示，支持在模型間建立關(guān)聯(lián)關(guān)系及基于關(guān)系進行追溯。多域模型協(xié)同及集成環(huán)境構(gòu)建如圖3所示。

圖3 多域模型協(xié)同及集成環(huán)境構(gòu)建

4.1 基于OSLC接口模型的集成

與某需求管理平臺、某功能架構(gòu)平臺和某聯(lián)合仿真平臺的集成，主要是通過OSLC接口模型的方式拉取需求管理平臺、功能架構(gòu)平臺和聯(lián)合仿真平臺的數(shù)據(jù)和相關(guān)的頁面，實現(xiàn)與三個平臺的集成。在基礎(chǔ)模型的需求庫內(nèi)可以查看具體的每一個需求條目的具體信息，在功能架構(gòu)庫內(nèi)可以查看功能架構(gòu)樹結(jié)構(gòu)，在仿真模型庫中可以查看到仿真結(jié)果數(shù)據(jù)。結(jié)構(gòu)樹中每個節(jié)點包含了它的OSLC鏈接，通過該鏈接，可以追溯到具體的模型信息詳情頁。

4.2 多域模型間關(guān)系的創(chuàng)建及追蹤

基于三類模型元數(shù)據(jù)架構(gòu)的表達，通過與三個平臺的集成，基礎(chǔ)模型庫獲取到對應(yīng)的三類模型的樹形結(jié)構(gòu)展示，基于三個樹形結(jié)構(gòu)，對各階段模型之間建立關(guān)聯(lián)關(guān)系，可進行關(guān)系鏈接的詳細(xì)分析，進而形成一個關(guān)系網(wǎng)絡(luò)，依據(jù)關(guān)系網(wǎng)絡(luò)能夠進行變更時關(guān)聯(lián)關(guān)系的追蹤和反饋，實現(xiàn)多域模型的協(xié)同。需求、功能架構(gòu)和仿真模型之間的關(guān)聯(lián)關(guān)系如圖4所示。

5 結(jié)論

本研究圍繞異域模型之間的協(xié)同問題，基于OSLC數(shù)據(jù)接口及各模型元數(shù)據(jù)架構(gòu)進行集成研究的構(gòu)建，支撐各階段模型（需求模型、功能架構(gòu)模型和仿真模型）信息的共享與關(guān)聯(lián)，基于模型關(guān)聯(lián)關(guān)系驅(qū)動更改影響分析互通和協(xié)同工作。該研究是全生命周期模型數(shù)據(jù)貫通使用的第一步，未來對這些數(shù)據(jù)如何高效的使用，如何讓這些數(shù)據(jù)產(chǎn)生意義和價值，才是貫通、應(yīng)用的最終目的。