陸劍峰 韓調(diào)娟 俞耀平

同濟(jì)大學(xué)CIMS研究中心，上海，201804

0 引言

近些年，隨著產(chǎn)品復(fù)雜程度的提高以及個(gè)性化需求增多，產(chǎn)品全生命周期中不同組織、企業(yè)和部門之間的協(xié)同愈加明顯，產(chǎn)品價(jià)值創(chuàng)造中心從組織內(nèi)部協(xié)作演變?yōu)榭缃M織的協(xié)同與創(chuàng)新。以云制造為代表的基于工業(yè)互聯(lián)網(wǎng)的制造服務(wù)協(xié)同成為新一代智能制造的一個(gè)重要模式。云制造服務(wù)呈現(xiàn)多樣化、分散化、動(dòng)態(tài)性、不確定性以及數(shù)量龐大等特點(diǎn)，需要將這些分散的生產(chǎn)、軟件、數(shù)據(jù)、計(jì)算等資源集中整合編排，構(gòu)建成邏輯上的資源整體[1]，將云制造服務(wù)以一種松耦合的形態(tài)進(jìn)行組合和執(zhí)行，才可以很大程度上保證制造過程的高效、穩(wěn)定運(yùn)行，實(shí)現(xiàn)企業(yè)/工廠制造業(yè)務(wù)協(xié)同、服務(wù)協(xié)同。

云制造主要包括服務(wù)供應(yīng)商、服務(wù)需求方和云制造服務(wù)平臺(tái)三個(gè)角色。服務(wù)供應(yīng)商擁有制造資源和制造能力，通過在云平臺(tái)上注冊(cè)和發(fā)布形成制造服務(wù)能力。服務(wù)需求方發(fā)布服務(wù)需求，經(jīng)過云平臺(tái)的撮合，雙方實(shí)現(xiàn)供需對(duì)接，進(jìn)行服務(wù)能力交易。

由于產(chǎn)品的復(fù)雜性，一個(gè)制造服務(wù)需求往往會(huì)被分解成多個(gè)子服務(wù)需求，以尋求最佳供應(yīng)商，這樣一個(gè)制造服務(wù)需求會(huì)由多個(gè)服務(wù)供應(yīng)商參與。各個(gè)供應(yīng)商提供的制造服務(wù)形成一個(gè)服務(wù)組合來為客戶提供個(gè)性化制造服務(wù)。服務(wù)組合形成一個(gè)服務(wù)流程，需要對(duì)這個(gè)服務(wù)流程進(jìn)行有效管理，才能協(xié)同各服務(wù)方資源，保證服務(wù)按期完成。

客戶制造服務(wù)需求趨于多樣化、個(gè)性化、隨機(jī)化，從而造成生產(chǎn)制造的復(fù)雜化、分散化、柔性化，云制造服務(wù)存在顯著的異構(gòu)性、動(dòng)態(tài)性和多樣性[2-5]。傳統(tǒng)的供應(yīng)鏈制造協(xié)同模式側(cè)重于制造企業(yè)之間針對(duì)特定產(chǎn)品或項(xiàng)目的業(yè)務(wù)協(xié)同，主要用于服務(wù)單一用戶或訂單任務(wù)，在滿足用戶個(gè)性化方面存在局限性[6]。而云制造服務(wù)的流程管理有以下特點(diǎn)：

(1)流程的多變。不同需求方的制造服務(wù)需求可能是不同的，針對(duì)該需求匹配得到的服務(wù)組合可能是具有差異性的，形成了多變的服務(wù)流程。參與到服務(wù)流程的服務(wù)主體只有在供需匹配完成后才明確，給流程管控帶來了難度。

(2)無法集中管控。云制造服務(wù)流程涉及多個(gè)服務(wù)供應(yīng)商，是跨組織的協(xié)同。云制造平臺(tái)只提供服務(wù)匹配和交易平臺(tái)服務(wù)，無法對(duì)各個(gè)制造服務(wù)供應(yīng)商的行為集中管理。因此，基于服務(wù)編制思想、在企業(yè)內(nèi)部實(shí)現(xiàn)的流程管理模式(如business process execution language,BPEL)不適合云制造服務(wù)流程管理。

(3)制造服務(wù)流程管理的必要性。與普通的面向服務(wù)架構(gòu)(service-oriented architecture,SOA)中計(jì)算服務(wù)不同，制造服務(wù)往往依靠實(shí)體制造資源實(shí)現(xiàn)，每個(gè)制造資源(如機(jī)床)在某段時(shí)間內(nèi)只能服務(wù)一個(gè)服務(wù)訂單，而且由于制造的特點(diǎn)，切換生產(chǎn)不同產(chǎn)品需要一定的加工制造準(zhǔn)備時(shí)間。因此，制造服務(wù)供應(yīng)商會(huì)預(yù)先對(duì)制造服務(wù)訂單排程以實(shí)現(xiàn)其制造資源的高效利用。制造服務(wù)流程如果缺乏有效管理，前序的拖期會(huì)導(dǎo)致后序服務(wù)無法按時(shí)進(jìn)行，造成后續(xù)制造服務(wù)商資源的空閑，降低了服務(wù)執(zhí)行的效率。如果前序延期信息能及時(shí)告知相關(guān)服務(wù)商，則相關(guān)服務(wù)商可以通過重調(diào)度來安排完成其他服務(wù)訂單，減少資源的不必要等待。

針對(duì)跨組織云制造服務(wù)的協(xié)同，國內(nèi)外學(xué)者做了較多研究。CHITUC等[7]為解決分布式環(huán)境下資源分配問題，研究了多智能體系統(tǒng)的協(xié)同決策機(jī)制，建立了分布式協(xié)同網(wǎng)絡(luò)模型。李京生等[8]針對(duì)異地分布多車間協(xié)同生產(chǎn)計(jì)劃的關(guān)聯(lián)協(xié)調(diào)問題，開發(fā)了一種基于動(dòng)態(tài)制造資源能力服務(wù)化的分布式協(xié)同生產(chǎn)調(diào)度技術(shù)。ZHANG等[9]基于教學(xué)-學(xué)習(xí)優(yōu)化算法評(píng)估和選擇子任務(wù)的候選分布式制造資源。譚偉等[10]為了加強(qiáng)區(qū)域協(xié)同制造，提出了一種基于地理分區(qū)與制造資源分類樹的多粒度制造資源自適應(yīng)組織與發(fā)現(xiàn)機(jī)制。李益兵等[11]從企業(yè)利益出發(fā),考慮生產(chǎn)成本、加工資源、加工效率等,建立集團(tuán)分布式制造資源配置優(yōu)化模型。以上研究大都是通過數(shù)學(xué)模型，直接對(duì)制造資源進(jìn)行協(xié)同，但該協(xié)同方式相對(duì)固化，很難解決動(dòng)態(tài)、多樣的云制造服務(wù)協(xié)同，因此很難適用于基于Web服務(wù)的云制造服務(wù)的協(xié)同。

目前，很多學(xué)者對(duì)傳統(tǒng)Web服務(wù)的協(xié)同進(jìn)行了研究。Web服務(wù)作為云制造服務(wù)的一種服務(wù)化表現(xiàn)形式，是一種通過可標(biāo)記擴(kuò)展語言(extensible markup language，XML)所描述、發(fā)布、查找和調(diào)用的軟件實(shí)體。姜久雷[12]通過業(yè)務(wù)流程建模與標(biāo)注(business process model and notation, BPMN)來圖形化描述跨組織服務(wù)編排協(xié)作流程，并說明可通過形式化建模語言π演算進(jìn)行驗(yàn)證。OLIVER等[13]基于WS-BPEL(web service business process execution language)協(xié)議，提出了一種標(biāo)準(zhǔn)化描述服務(wù)編排過程的建模方法。尤殿龍[14]針對(duì)大粒度Web服務(wù)，基于大粒度組合服務(wù)的特征提出了在設(shè)計(jì)階段面向服務(wù)編排的組合演化的技術(shù)框架。另外，也有學(xué)者從建立數(shù)學(xué)模型的角度進(jìn)行研究。李健[15]針對(duì)用戶Web服務(wù)請(qǐng)求有即時(shí)性、定制性以及模糊性的特點(diǎn)，提出了基于粒度的網(wǎng)絡(luò)服務(wù)聚合和協(xié)同方法。薛霄等[16]基于服務(wù)質(zhì)量(quality of service，QoS)評(píng)價(jià)模型，提出了一種Web服務(wù)質(zhì)量可定制的服務(wù)組合方法。以上針對(duì)Web服務(wù)的協(xié)同方法研究主要是在Web服務(wù)的組合階段，往往忽略了服務(wù)的執(zhí)行過程，而云制造服務(wù)的協(xié)同在服務(wù)執(zhí)行過程中也十分重要。云制造服務(wù)的實(shí)現(xiàn)需要依賴現(xiàn)實(shí)環(huán)境，如機(jī)床加工的云制造服務(wù)，它最終依賴處于某地的某臺(tái)或某些機(jī)床及相關(guān)配套，因此，Web服務(wù)協(xié)同方法無法直接應(yīng)用到云制造服務(wù)協(xié)同中去。這對(duì)云制造服務(wù)的協(xié)同提出了更高的要求。

還有較多研究人員通過傳統(tǒng)流程管理模型去實(shí)現(xiàn)云制造服務(wù)的協(xié)同。WEI等[17]提出了一種云平臺(tái)業(yè)務(wù)協(xié)同邏輯引擎，但未給出實(shí)現(xiàn)途徑，且缺少對(duì)服務(wù)協(xié)同過程中服務(wù)交互規(guī)則的描述方法。對(duì)此，鄭姜[18]引入Web服務(wù)編排描述語言(web service choreography description language，WS-CDL)，并設(shè)計(jì)相應(yīng)圖形化標(biāo)記，為實(shí)現(xiàn)業(yè)務(wù)流程協(xié)同提供了一種建模工具?；诹鞒坦芾砟Ｐ腿パ芯吭浦圃旆?wù)的協(xié)同是一個(gè)有效的途徑，但同時(shí)需要考慮引入合適的協(xié)同描述協(xié)議。

基于以上需求和文獻(xiàn)分析，云制造服務(wù)需要一個(gè)有效的協(xié)同管理方法，該方法能對(duì)服務(wù)流程預(yù)先定義，并且能有效跟蹤服務(wù)訂單執(zhí)行過程。為此，本文提出一種基于WS-CDL的云制造服務(wù)編排方法。為實(shí)現(xiàn)云制造服務(wù)供應(yīng)商在服務(wù)執(zhí)行過程的信息交互，服務(wù)供應(yīng)商在服務(wù)發(fā)布時(shí)，需要滿足一定的信息交互接口規(guī)范，通過服務(wù)本體描述語言(web ontology language for service,OWL-S)并結(jié)合Web服務(wù)描述語言(web services description language, WSDL)來定義。在充分利用傳統(tǒng)Web服務(wù)協(xié)同管理方法的基礎(chǔ)上，考慮云制造服務(wù)的特點(diǎn)，通過擴(kuò)展傳統(tǒng)WS-CDL協(xié)議，將云制造服務(wù)訂單與服務(wù)供應(yīng)商協(xié)同信息加入服務(wù)編排文檔中，實(shí)現(xiàn)云制造服務(wù)的編排協(xié)議描述。服務(wù)供應(yīng)商通過該編排協(xié)議獲取合作服務(wù)供應(yīng)商業(yè)務(wù)的實(shí)時(shí)信息，以實(shí)現(xiàn)云制造服務(wù)的協(xié)同執(zhí)行。

1 基于WS-CDL服務(wù)編排的制造服務(wù)協(xié)同

1.1 服務(wù)的編制與編排

基于工作流程的服務(wù)組合協(xié)同方法可以大致分為兩類：一類是基于服務(wù)編制(orchestration)的協(xié)同，一類是基于服務(wù)編排(choreography)的協(xié)同。

服務(wù)編制往往是從單個(gè)服務(wù)參與主體的視角去描述自身服務(wù)內(nèi)部的業(yè)務(wù)流程以及執(zhí)行過程，其描述標(biāo)準(zhǔn)最主要是WS-BPEL。通常的服務(wù)編制是指集中式管理，即組織中存有一個(gè)對(duì)所有服務(wù)具有控制作用的中心控制引擎——“中心協(xié)調(diào)者”，它控制和協(xié)調(diào)組織內(nèi)所有成員服務(wù)之間的信息流和業(yè)務(wù)流，并且，它也是所有成員服務(wù)間交流的“傳遞者”。

如圖1所示，中心控制引擎在依次調(diào)用相關(guān)成員服務(wù)后，成員服務(wù)將相關(guān)數(shù)據(jù)結(jié)果返回給中心控制引擎，在中心控制引擎調(diào)用下一個(gè)服務(wù)的同時(shí)，將相關(guān)數(shù)據(jù)一同傳遞給下一個(gè)服務(wù)。另外，中心控制引擎還負(fù)責(zé)業(yè)務(wù)流程的異常處理和用戶交互。服務(wù)編制的優(yōu)勢(shì)是服務(wù)流程簡(jiǎn)單明了、直觀，但是由于中心控制引擎承擔(dān)著大量的業(yè)務(wù)流控制、數(shù)據(jù)處理等任務(wù)，因此當(dāng)成員服務(wù)數(shù)量多到一定程度時(shí)，過大的負(fù)載會(huì)導(dǎo)致業(yè)務(wù)流程控制和業(yè)務(wù)數(shù)據(jù)通信產(chǎn)生瓶頸問題。因此這種方式很難適用于復(fù)雜的云制造環(huán)境，只適用于一個(gè)企業(yè)內(nèi)部或少量外部服務(wù)之間的協(xié)同。

圖1 基于編制的服務(wù)流程示意圖Fig.1 Service process diagram based on orchestration

服務(wù)編排的思想是從全局視角去協(xié)同服務(wù)各方之間的合作流程和交互，通過定義各服務(wù)方之間的通信協(xié)議來實(shí)現(xiàn)多主體之間的服務(wù)協(xié)同，如圖2所示。

通過對(duì)服務(wù)的角色類型、關(guān)系類型、交互通道類型、交互數(shù)據(jù)類型和交互規(guī)則等的描述，實(shí)現(xiàn)服務(wù)之間的公共行為，即由服務(wù)編排協(xié)議去完成服務(wù)編制中中心控制引擎的作用，服務(wù)編排的一個(gè)標(biāo)準(zhǔn)協(xié)議是由W3C制定的WS-CDL協(xié)議。

綜上所述，服務(wù)編制和服務(wù)編排的對(duì)比如表1所示。

表1 服務(wù)編制與編排對(duì)比Tab.1 Comparison of service orchestrationand choreography

1.2 基于WS-CDL服務(wù)編排的制造服務(wù)協(xié)同框架

針對(duì)云制造服務(wù)流程協(xié)同管理的需求，本文設(shè)計(jì)整體框架如圖3所示。

首先，在服務(wù)發(fā)布時(shí)，設(shè)計(jì)服務(wù)協(xié)同所必要的服務(wù)接口規(guī)范，方便后續(xù)服務(wù)執(zhí)行過程跟蹤。該服務(wù)接口規(guī)范基于網(wǎng)絡(luò)本體語言(ontology web language for service，OWL-S)建立，配合制造服務(wù)的WSDL描述規(guī)范實(shí)現(xiàn)。

其次，在服務(wù)交易關(guān)系構(gòu)建完成時(shí)，根據(jù)服務(wù)組合定義，建立服務(wù)流程編排定義文檔。該文檔定義了服務(wù)執(zhí)行過程的參與方(需求方、供應(yīng)商、云平臺(tái))以及信息交互規(guī)范。該文檔會(huì)發(fā)送給服務(wù)各參與方。

最后，在服務(wù)執(zhí)行時(shí)，服務(wù)供應(yīng)商根據(jù)服務(wù)流程編排定義形成自身任務(wù)執(zhí)行的服務(wù)編排文檔，實(shí)現(xiàn)任務(wù)執(zhí)行情況在供應(yīng)商中共享。需求方和云平臺(tái)也可以利用服務(wù)編排文檔進(jìn)行服務(wù)任務(wù)執(zhí)行的追蹤管理。

具體方法在第2節(jié)說明。

圖3 云制造服務(wù)編排方法Fig.3 Chorography method to cloud manufacturing service

2 云制造服務(wù)編排關(guān)鍵過程實(shí)現(xiàn)

2.1 云制造服務(wù)交互接口規(guī)范設(shè)計(jì)

在傳統(tǒng)制造模式中，上下游制造服務(wù)之間的生產(chǎn)交互往往是同一層次的，如生產(chǎn)部門與部門之間的對(duì)接。而云制造模式下，云制造服務(wù)之間的交互存在跨粒度和跨層次服務(wù)之間的交互，如機(jī)床主軸生產(chǎn)中，毛坯生產(chǎn)服務(wù)完成后，既可與同粒度/層次的粗加工生產(chǎn)服務(wù)銜接，又可與細(xì)粒度/層次的銑加工服務(wù)等銜接。所以，有必要設(shè)計(jì)交互接口規(guī)范。交互接口能夠?qū)崿F(xiàn)不同粒度/層次服務(wù)之間的輸入輸出銜接，以滿足各類層次服務(wù)之間的順利交互。

根據(jù)云制造服務(wù)信息交互特點(diǎn)，采用了包含表征接口、查詢接口、功能接口、技術(shù)接口的4個(gè)接口類型，如圖4所示。

圖4 交互接口類型Fig.4 Classification of interaction interface

在云制造服務(wù)定義、發(fā)布的時(shí)候，需要實(shí)現(xiàn)并提供云制造服務(wù)接口規(guī)范，一般使用OWL-S語言并結(jié)合WSDL語言來定義，從而實(shí)現(xiàn)各類服務(wù)交互邏輯編排中的交互接口描述。另外，需要根據(jù)不同服務(wù)之間的實(shí)際交互需求，設(shè)計(jì)不同的交互時(shí)序。對(duì)應(yīng)的接口規(guī)范如表2所示，這些接口會(huì)在后續(xù)的服務(wù)編排文檔中應(yīng)用到。

為了解決不同粒度/層次服務(wù)之間的輸入輸出銜接問題，在接口規(guī)范中擴(kuò)充定義了“服務(wù)輸入”和“服務(wù)輸出”接口。通過上游供應(yīng)商的服務(wù)輸出信息與下游供應(yīng)商的服務(wù)輸入信息的匹配，實(shí)現(xiàn)不同粒度/層次服務(wù)之間的銜接。其中，服務(wù)的輸入輸出信息可根據(jù)服務(wù)產(chǎn)品(族)/在制品在各生產(chǎn)流程階段的標(biāo)志進(jìn)行定義，如零件生產(chǎn)過程“毛坯加工—粗加工—精加工”中，針對(duì)完成毛坯生產(chǎn)階段的產(chǎn)品狀態(tài)標(biāo)志，定義毛坯生產(chǎn)服務(wù)的輸出信息和粗加工生產(chǎn)服務(wù)的輸入信息，這樣保證一個(gè)服務(wù)結(jié)束后可以和下一個(gè)服務(wù)對(duì)接。

2.2 基于WS-CDL協(xié)議的制造云服務(wù)流程描述

WS-CDL是一種基于 XML 的語言，通過從服務(wù)交互的全局角度定義其共同和互補(bǔ)的行為約束來描述參與者的點(diǎn)對(duì)點(diǎn)協(xié)作，從而在沒有集中控制引擎的前提下，保證各服務(wù)節(jié)點(diǎn)消息交互和協(xié)同工作的有序進(jìn)行。但是，基礎(chǔ)的WS-CDL標(biāo)準(zhǔn)不包括對(duì)云制造服務(wù)等特殊服務(wù)的描述，因此對(duì)基礎(chǔ)的WS-CDL標(biāo)準(zhǔn)進(jìn)行擴(kuò)展。

WS-CDL編排協(xié)議主要分為靜態(tài)定義和動(dòng)態(tài)編排兩部分，如圖5所示。靜態(tài)定義對(duì)編排協(xié)議中出現(xiàn)的角色類型、關(guān)系類型、消息通道等作出定義；動(dòng)態(tài)編排在標(biāo)簽〈Choreography〉中，描述各類服務(wù)交互過程中的消息動(dòng)作和方法調(diào)用的執(zhí)行順序及流程控制。

云制造服務(wù)的執(zhí)行流程往往是由需求方個(gè)性化的訂單驅(qū)動(dòng)的，不同訂單的編排策略有所不同。云制造服務(wù)存在于實(shí)際制造過程，該過程依賴于具有生產(chǎn)能力限制的生產(chǎn)組織或生產(chǎn)設(shè)備。該組織或設(shè)備無法同時(shí)響應(yīng)兩個(gè)或多個(gè)訂單的請(qǐng)求，因此不同訂單需要對(duì)應(yīng)不同編排文檔。一個(gè)服務(wù)訂單中，服務(wù)供應(yīng)商的交互前提是分辨出對(duì)方與自身執(zhí)行的訂單是否是同一個(gè)訂單對(duì)象。而基礎(chǔ)的WS-CDL語言并不完全適應(yīng)和支持對(duì)云制造服務(wù)的編排描述，因此，針對(duì)WS-CDL語言進(jìn)行信息描述擴(kuò)展，且這類信息描述與編排文檔唯一對(duì)應(yīng)，屬于文檔靜態(tài)部分。通過在靜態(tài)定義部分增加節(jié)點(diǎn)對(duì)〈OrderInfo〉〈/OrderInfo〉說明每個(gè)WS-CDL文檔對(duì)應(yīng)的具體訂單，以實(shí)現(xiàn)服務(wù)供應(yīng)商在不同訂單中與其他服務(wù)供應(yīng)商的不同編排交互，具體的描述代碼如表3所示。

表2 服務(wù)接口規(guī)范Tab.2 Specification of service interface

圖5 靜態(tài)定義和動(dòng)態(tài)編排Fig.5 Static definition and dynamic choreography

表3 擴(kuò)展的WS-CDL描述方法Tab.3 The description of extended WS-CDL

在云制造服務(wù)協(xié)同過程中，某些服務(wù)交互活動(dòng)需在一定的前提下進(jìn)行，而某個(gè)服務(wù)編排活動(dòng)的執(zhí)行受后續(xù)交互活動(dòng)的反饋的影響。通常情況下，一個(gè)復(fù)雜服務(wù)的完整執(zhí)行需要多種交互方式。因此，基于WS-CDL協(xié)議中標(biāo)準(zhǔn)的三種編排規(guī)則(順序交互，并行交互，選擇交互)，設(shè)計(jì)了條件交互、反饋交互和混合交互3種編排規(guī)則?；旌辖换ナ菍⒋薪换?、并行交互、選擇交互等各類交互方式混合使用。圖5中虛線框表示擴(kuò)展的描述節(jié)點(diǎn)。

2.3 服務(wù)供應(yīng)商對(duì)服務(wù)訂單的跟蹤

云制造服務(wù)協(xié)同過程中的服務(wù)交互是通過交互接口實(shí)現(xiàn)的。服務(wù)供應(yīng)商按照接口規(guī)范發(fā)布了所提供云服務(wù)的接口，并被某服務(wù)組合匹配選中后，云平臺(tái)需要對(duì)該服務(wù)組合中的各服務(wù)進(jìn)行服務(wù)編排，其中包含了對(duì)各服務(wù)接口的描述。服務(wù)供應(yīng)商X跟蹤服務(wù)訂單流程如圖6所示，其中加紅線為定義的交互過程。服務(wù)供應(yīng)商X在執(zhí)行訂單前會(huì)首先向上游服務(wù)供應(yīng)商Y詢問訂單的狀態(tài)，若出現(xiàn)異常則切換訂單；否則繼續(xù)詢問訂單進(jìn)度信息，并判斷是否等待當(dāng)前訂單到達(dá)。根據(jù)以上跟蹤信息可以選擇最符合自身服務(wù)策略的訂單進(jìn)行加工。

圖6 服務(wù)供應(yīng)商訂單跟蹤流程Fig.6 Order tracking process of service provider

服務(wù)供應(yīng)商X和Y的交互接口在基于WS-CDL協(xié)議的編排文檔中具體描述如下：

〈exchange name=“getServiceID”

informationType=“ths:string” action=“request”〉

〈send variable=“cdl:getVariable(‘tns:serviceID’, ‘’ , ‘’)” /〉

〈receive variable=“cdl:getVariable(‘tns:serviceID’, ‘’, ‘’)” /〉

〈/exchange〉

〈exchange state=“getServiceState”

informationType=“ths:boolean” action=“request”〉

〈send variable=“cdl:getVariable(‘tns:serviceState’, ‘’ , ‘’)” /〉

〈receive variable=“cdl:getVariable(‘tns: serviceState’, ‘’, ‘’)” /〉

〈/exchange〉

〈exchange process=“getServiceProcess”

informationType=“ths:decimal” action=“request”〉

〈send variable=“cdl:getVariable(‘tns:serviceProcess’, ‘’ , ‘’)” /〉

〈receive variable=“cdl:getVariable(‘tns:serviceProcess’, ‘’, ‘’)” /〉

〈/exchange〉

文檔中：①參數(shù)name表示該接口方法名；②參數(shù)informationType表示該方法的返回值類型；③參數(shù)action表示該接口的動(dòng)作類型，request表示詢問，respond表示回復(fù)，request-respond表示復(fù)合接口；④〈send〉、〈receive〉節(jié)點(diǎn)表示信息的傳遞過程及方向。信息的獲取通過WS-CDL協(xié)議標(biāo)準(zhǔn)支持的getVariable方法實(shí)現(xiàn)，該方法可實(shí)現(xiàn)從全部的編排文檔中獲取相應(yīng)對(duì)象的變量值。

服務(wù)供應(yīng)商對(duì)服務(wù)訂單的跟蹤流程定義文檔如下：

〈!—服務(wù)供應(yīng)商X與Y之間的跟蹤交互，服務(wù)供應(yīng)商X在服務(wù)開始時(shí)刻向服務(wù)供應(yīng)商Y詢問訂單信息—〉

〈infoTrack name=“ServiceProviderTrack”

point=“0”

unit=“hour”〉

〈interaction name=“P-QuoteOrder”

channelVariable=“tns:ProviderX-YChannel”

operation=“getQuote”〉

〈!—定義此次跟蹤是下游服務(wù)供應(yīng)商X向上游服務(wù)供應(yīng)商Y發(fā)起的—〉

〈participaterelationshipType=“tns:ProviderX&Y Relation-ship”

fromRoleTypeRef=“tns:ProviderX”

toRoleTypeRef=“tns:ProviderY” /〉

〈exchange〉…〈/exchange〉+ 〈!—交互信息—〉

〈/interaction〉

〈/infoTrack〉

〈infoTrack〉節(jié)點(diǎn)有name、point、unit等屬性：①屬性name表述該節(jié)點(diǎn)的名稱；②屬性point表示執(zhí)行該〈infoTrack〉節(jié)點(diǎn)下交互(〈interaction〉)的時(shí)刻，以設(shè)定時(shí)間pointTime占執(zhí)行總時(shí)間T的比值確定交互時(shí)刻，如設(shè)定時(shí)間pointTime為4 h，執(zhí)行總時(shí)間T為20 h，則此次數(shù)據(jù)監(jiān)控交互時(shí)刻為該訂單已完成20%時(shí)刻；③屬性u(píng)nit表示時(shí)間單位，天(day)或小時(shí)(hour)或分鐘(minute)。類似地，可以完成云平臺(tái)、需求方對(duì)服務(wù)訂單跟蹤的流程定義。

通過WS-CDL格式的流程定義文件，各個(gè)服務(wù)參與方可以在各自管理流程中接入服務(wù)交互信息，明確交互節(jié)點(diǎn)和交互內(nèi)容，以提高不同組織業(yè)務(wù)流程的耦合程度。

3 云制造服務(wù)協(xié)同案例

3.1 云制造服務(wù)案例設(shè)計(jì)

某零件加工有如下步驟：毛坯加工(Blanking)、粗加工(Roughing)、精加工(Finishing)。服務(wù)供應(yīng)商A和B均能完成以上各步驟制造任務(wù)，即提供每種云制造服務(wù)或者相應(yīng)組合服務(wù)?，F(xiàn)假設(shè)有8個(gè)訂單需求，已確定的服務(wù)供應(yīng)商如表4所示(按下單時(shí)間先后排序)。其中，時(shí)間為生產(chǎn)制造的加工時(shí)間。

表4 訂單信息Tab.4 Order information

現(xiàn)對(duì)服務(wù)供應(yīng)商A和B作如下假設(shè)：

(1)假設(shè)服務(wù)供應(yīng)商A和B服務(wù)的業(yè)務(wù)流程為：等待訂單—準(zhǔn)備加工—加工制造—訂單完成或訂單異?！袚Q訂單。

(2)假設(shè)下游服務(wù)供應(yīng)商與上游服務(wù)供應(yīng)商沒有交互獲取服務(wù)跟蹤信息，則各服務(wù)供應(yīng)商初始訂單順序如表5所示。加工不同的訂單假設(shè)需要一定的生產(chǎn)準(zhǔn)備時(shí)間，即服務(wù)切換時(shí)間，如表6所示。若在服務(wù)執(zhí)行過程中存在雙方有效交互，服務(wù)供應(yīng)商可以預(yù)先知道上游服務(wù)商的完成時(shí)間，因此可以安排提前做好加工準(zhǔn)備，則下一訂單的準(zhǔn)備時(shí)間可忽略。

表5 各服務(wù)供應(yīng)商訂單信息Tab.5 Order information of each service provider

表6 各服務(wù)供應(yīng)商切換時(shí)間Tab.6 Switching time of each service provider h

3.2 WS-CDL編排文檔實(shí)現(xiàn)

為有效協(xié)同每個(gè)訂單的加工制造流程，不同服務(wù)供應(yīng)商需要根據(jù)每個(gè)訂單編排信息與上下游服務(wù)供應(yīng)商進(jìn)行訂單加工信息交互。以訂單order_2為例，對(duì)訂單order_2進(jìn)行信息交互協(xié)同設(shè)計(jì)，并給出對(duì)應(yīng)的編排文檔。

圖7為訂單order_2的服務(wù)供應(yīng)商之間的交互設(shè)計(jì)示意圖，各服務(wù)供應(yīng)商以及云平臺(tái)之間都存有交互通道。其中橢圓標(biāo)注的是A毛坯加工服務(wù)與B粗加工服務(wù)之間的交互通道，二者之間可形成圖8所示的交互時(shí)序圖。

首先，服務(wù)供應(yīng)商B會(huì)向服務(wù)供應(yīng)商A詢問當(dāng)前訂單的狀態(tài)，服務(wù)供應(yīng)商A返回相應(yīng)訂單的狀態(tài)信息；然后，服務(wù)供應(yīng)商B詢問當(dāng)前訂單的進(jìn)度，同樣服務(wù)供應(yīng)商A返回相應(yīng)訂單的進(jìn)度信息；若order_2訂單發(fā)生異常，則服務(wù)供應(yīng)商A會(huì)

圖7 order_2的服務(wù)流程和交互示意圖Fig.7 Service flow and interaction of order_2

圖8 服務(wù)供應(yīng)商A與B交互時(shí)序Fig.8 Interaction sequence between service provider A and B

隨時(shí)向服務(wù)供應(yīng)商B發(fā)送訂單異常的信息，以實(shí)現(xiàn)服務(wù)供應(yīng)商B對(duì)自身訂單的安排更新。

3.3 基于Anylogic的協(xié)同模型

本文基于Anylogic平臺(tái)對(duì)上述案例進(jìn)行仿真對(duì)比分析?；诮换ゾ幣艆f(xié)議，建立服務(wù)供應(yīng)商多智能體之間的交互行為模型，驗(yàn)證服務(wù)協(xié)同的有效性。為實(shí)現(xiàn)WS-CDL編排文檔中規(guī)定的交互通道和交互動(dòng)作，Anylogic通過“鏈接(connections)”實(shí)現(xiàn)交互通道的定義。在同一環(huán)境中可通過Java方法(表7)實(shí)現(xiàn)智能體之間的交互動(dòng)作(信息傳遞)。

表7 智能體交互建模方法Tab.7 Modelling methods of agent interaction

3.3.1傳統(tǒng)制造模式仿真建模

作為對(duì)比，首先構(gòu)建傳統(tǒng)的制造模式下的服務(wù)模型。該模式下服務(wù)供應(yīng)商之間不存在信息交互和協(xié)同過程，此時(shí)每個(gè)服務(wù)供應(yīng)商一般按照“先來先服務(wù)”的加工規(guī)則進(jìn)行生產(chǎn)制造。每個(gè)服務(wù)供應(yīng)商的智能體模型如圖9所示。

圖9 服務(wù)供應(yīng)商的智能體模型Fig.9 Agent model of the service provider

仿真模型及運(yùn)行結(jié)果如圖10所示。此時(shí)，訂單完成總時(shí)間為53.016 h，各服務(wù)供應(yīng)商的加工時(shí)間(workingTime)、異常處理時(shí)間(exceptionTime)、訂單切換時(shí)間(Switching Time)、等待(空閑)時(shí)間(waitingTime)數(shù)據(jù)見圖10,圖中，R表示粗加工，B表示毛坯加工，F(xiàn)表示精加工，如A_R-workingTime表示A的粗加工時(shí)間。

圖10 傳統(tǒng)制造模式仿真結(jié)果Fig.10 Simulation results of the traditional manufacturing mode

各服務(wù)供應(yīng)商訂單實(shí)際執(zhí)行順序見表8。對(duì)比原訂單順序，可發(fā)現(xiàn)服務(wù)供應(yīng)商A精加工服務(wù)和服務(wù)供應(yīng)商B粗加工服務(wù)、精加工服務(wù)的訂單實(shí)際到達(dá)時(shí)間順序不同于初始訂單下單時(shí)間順序。這是因?yàn)槊總€(gè)供應(yīng)商按照先來先服務(wù)的策略執(zhí)行。

表8 服務(wù)供應(yīng)商執(zhí)行訂單的實(shí)際順序Tab.8 Actual sequence of orders executed byservice providers

表9所示是各個(gè)服務(wù)訂單的開始時(shí)間和結(jié)束時(shí)間。假設(shè)訂單開始為零時(shí)刻，分析order_2的加工時(shí)間。order_2訂單需等待A毛坯加工服務(wù)6.5 h(order_1的A毛坯加工時(shí)間6 h和切換時(shí)間0.5 h),所以order_2的A毛坯加工時(shí)間總共為12.5 h。order_2到達(dá)B粗加工服務(wù)時(shí)需等待1 h。order_3經(jīng)過B毛坯加工只花費(fèi)了3 h, order_2較order_3晚9.5 h到B粗加工服務(wù)(表8中B粗加工服務(wù)下的訂單order_2、order_3會(huì)互換順序)。根據(jù)先來先服務(wù)原則, B粗加工服務(wù)會(huì)為order_3服務(wù)7 h，再考慮B粗加工服務(wù)的切換時(shí)間，所以order_2的B粗加工服務(wù)為7.5 h。order_2經(jīng)過毛坯加工和粗加工，總計(jì)用時(shí)20 h。

表9 各訂單的加工時(shí)間Tab.9 Processing time of each order

order_2到達(dá)B精加工服務(wù)時(shí)需等待4 h(等待order_4加工完成3 h和B精加工切換時(shí)間1 h)才能進(jìn)入B精加工(6h)。這是因?yàn)閛rder_4較order_2早5.5 h到達(dá)B精加工服務(wù)(表8中B精加工服務(wù)下的訂單order_2、order_4會(huì)互換順序)。order_4完成毛坯加工和粗加工總計(jì)用時(shí)14.5 h(B毛坯加工6.5h和A粗加工8h)。

通過以上分析，可知order_2結(jié)束時(shí)間為30 h,驗(yàn)證了表9中的order_2的結(jié)束時(shí)間。其他訂單分析同order_2的分析。

3.3.2云制造服務(wù)供應(yīng)商的協(xié)同建模

云制造服務(wù)供應(yīng)商協(xié)同模型如圖11所示，其中，粗加工服務(wù)商模型(圖11a)的訂單等待策略是：向上游服務(wù)商詢問訂單狀態(tài)和進(jìn)度(訂單加工剩余時(shí)間)，若上游服務(wù)商訂單加工剩余時(shí)間大于訂單切換時(shí)間，則不等待而切換其他訂單，否則繼續(xù)等待；精加工服務(wù)商模型(圖11b)的訂單等待策略是：對(duì)于每個(gè)訂單服務(wù)，若上游服務(wù)商正在加工則等待，否則切換訂單。

仿真運(yùn)行結(jié)果如圖12所示。此時(shí)，訂單完成總時(shí)間為52.001 h。

該模式下的服務(wù)供應(yīng)商實(shí)際服務(wù)執(zhí)行順序同表8，而訂單的加工時(shí)間發(fā)生了變化，如表10所示。

以order_2為例進(jìn)行分析，在表10中其結(jié)束時(shí)間較傳統(tǒng)模式下(表8)縮短了2 h。這是因?yàn)閛rder_2在B精加工時(shí)提前了2 h。在order_2進(jìn)行B精加工之前，供應(yīng)商B已完成了order_1和order_4加工。根據(jù)表4和表8可知，完成order_1的完成時(shí)間為16 h，即在16 h這一時(shí)刻供應(yīng)商B完成了order_1的精加工，而order_4到達(dá)B精加工是14 h,較傳統(tǒng)模式下的時(shí)間縮短了0.5h(order_4到達(dá)B毛坯加工時(shí)，服務(wù)商B在毛坯加工order_3時(shí)已同步完成訂單切換)。在服務(wù)協(xié)同模式下，由于B精加工服務(wù)對(duì)order_4的B毛坯加工服務(wù)和A粗加工服務(wù)可以進(jìn)行實(shí)時(shí)監(jiān)控，實(shí)現(xiàn)order_4訂單的跟蹤，那么order_4的準(zhǔn)備工作在order_1的精加工時(shí)間內(nèi)同步提前完成，因此order_4的精加工縮減了1 h(B精加工服務(wù)的訂單切換時(shí)間)。order_2到達(dá)B精加工服務(wù)時(shí)，其準(zhǔn)備工作在order_4的加工時(shí)間內(nèi)同步提前完成，所以order_2精加工提前了2 h,結(jié)束時(shí)間也由之前的30 h變成28 h。

(a)粗加工服務(wù)商模型

(b)精加工服務(wù)商模型圖11 云制造服務(wù)供應(yīng)商協(xié)同模型Fig.11 Collaboration models of cloud manufacturing service provider

圖12 服務(wù)協(xié)同仿真結(jié)果Fig.12 Simulation result of service collaboration

表10 服務(wù)協(xié)同下的訂單的加工時(shí)間Tab.10 Processing time of each order underservice coordination

3.4 仿真結(jié)果分析

分析兩種制造模式下各服務(wù)供應(yīng)商的加工時(shí)間(workingTime)、等待時(shí)間(waitingTime)、訂單切換時(shí)間(SwitchingTime)等仿真結(jié)果。選擇供應(yīng)商精加工(Finishing)服務(wù)的執(zhí)行時(shí)間進(jìn)行對(duì)比，如表11所示。WS-CDL協(xié)議能夠?qū)崿F(xiàn)各服務(wù)供應(yīng)商對(duì)訂單的實(shí)時(shí)跟蹤，即下游供應(yīng)商精加工服務(wù)能實(shí)時(shí)了解訂單在上游供應(yīng)商毛坯加工服務(wù)和粗加工服務(wù)處的狀態(tài)和進(jìn)度，能動(dòng)態(tài)更新自己當(dāng)前的生產(chǎn)安排。比如在了解到訂單即將到達(dá)精加工服務(wù)時(shí)，及時(shí)完成訂單的切換。訂單到達(dá)后就能立即安排加工，而無需等待。在服務(wù)協(xié)同模式下，精加工服務(wù)的服務(wù)等待時(shí)間和訂單切換時(shí)間減少，從而導(dǎo)致精加工時(shí)間占總服務(wù)時(shí)間的比重更大。這說明服務(wù)協(xié)同模式能夠一定程度上提高各個(gè)服務(wù)參與主體的效率。

表11 精加工服務(wù)仿真結(jié)果對(duì)比Tab.11 Simulation comparison of finishing

4 結(jié)論

本文基于服務(wù)編排思想結(jié)合WS-CDL協(xié)議的擴(kuò)展，實(shí)現(xiàn)了云制造服務(wù)協(xié)同。首先設(shè)計(jì)了云制造服務(wù)交互接口規(guī)范和基于WS-CDL協(xié)議的云服務(wù)編排規(guī)則，有效解決了云制造環(huán)境下多層次、多粒度服務(wù)帶來的復(fù)雜流程管理問題。通過進(jìn)一步擴(kuò)展WS-CDL協(xié)議，基于云制造服務(wù)編排文檔實(shí)現(xiàn)對(duì)服務(wù)執(zhí)行過程跟蹤。仿真結(jié)果證明，通過服務(wù)協(xié)同和服務(wù)跟蹤能保證每個(gè)服務(wù)供應(yīng)商有效獲取自身相關(guān)訂單的信息，以便動(dòng)態(tài)更新生產(chǎn)安排，提高服務(wù)使用率。同時(shí)，所有服務(wù)訂單的整體執(zhí)行時(shí)間減少，提高了整體的服務(wù)執(zhí)行效率。

下一步的工作是要結(jié)合工業(yè)云制造服務(wù)平臺(tái)，開發(fā)WS-CDL生成、解釋和執(zhí)行的服務(wù)組件，以便對(duì)已經(jīng)確定的服務(wù)組合自動(dòng)生成流程定義文檔，并且在服務(wù)執(zhí)行過程中自動(dòng)執(zhí)行。