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

同濟大學CIMS研究中心，上海，201804

0 引言

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

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

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

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

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

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

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

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

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

還有較多研究人員通過傳統(tǒng)流程管理模型去實現(xiàn)云制造服務的協(xié)同。WEI等[17]提出了一種云平臺業(yè)務協(xié)同邏輯引擎，但未給出實現(xiàn)途徑，且缺少對服務協(xié)同過程中服務交互規(guī)則的描述方法。對此，鄭姜[18]引入Web服務編排描述語言(web service choreography description language，WS-CDL)，并設計相應圖形化標記，為實現(xiàn)業(yè)務流程協(xié)同提供了一種建模工具。基于流程管理模型去研究云制造服務的協(xié)同是一個有效的途徑，但同時需要考慮引入合適的協(xié)同描述協(xié)議。

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

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

1.1 服務的編制與編排

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

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

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

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

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

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

綜上所述，服務編制和服務編排的對比如表1所示。

表1 服務編制與編排對比Tab.1 Comparison of service orchestrationand choreography

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

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

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

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

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

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

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

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

2.1 云制造服務交互接口規(guī)范設計

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

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

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

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

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

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

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

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

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

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

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

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

在云制造服務協(xié)同過程中，某些服務交互活動需在一定的前提下進行，而某個服務編排活動的執(zhí)行受后續(xù)交互活動的反饋的影響。通常情況下，一個復雜服務的完整執(zhí)行需要多種交互方式。因此，基于WS-CDL協(xié)議中標準的三種編排規(guī)則(順序交互，并行交互，選擇交互)，設計了條件交互、反饋交互和混合交互3種編排規(guī)則。混合交互是將串行交互、并行交互、選擇交互等各類交互方式混合使用。圖5中虛線框表示擴展的描述節(jié)點。

2.3 服務供應商對服務訂單的跟蹤

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

圖6 服務供應商訂單跟蹤流程Fig.6 Order tracking process of service provider

服務供應商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表示該接口的動作類型，request表示詢問，respond表示回復，request-respond表示復合接口；④〈send〉、〈receive〉節(jié)點表示信息的傳遞過程及方向。信息的獲取通過WS-CDL協(xié)議標準支持的getVariable方法實現(xiàn)，該方法可實現(xiàn)從全部的編排文檔中獲取相應對象的變量值。

服務供應商對服務訂單的跟蹤流程定義文檔如下：

〈!—服務供應商X與Y之間的跟蹤交互，服務供應商X在服務開始時刻向服務供應商Y詢問訂單信息—〉

〈infoTrack name=“ServiceProviderTrack”

point=“0”

unit=“hour”〉

〈interaction name=“P-QuoteOrder”

channelVariable=“tns:ProviderX-YChannel”

operation=“getQuote”〉

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

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

fromRoleTypeRef=“tns:ProviderX”

toRoleTypeRef=“tns:ProviderY” /〉

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

〈/interaction〉

〈/infoTrack〉

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

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

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

3.1 云制造服務案例設計

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

表4 訂單信息Tab.4 Order information

現(xiàn)對服務供應商A和B作如下假設：

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

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

表5 各服務供應商訂單信息Tab.5 Order information of each service provider

表6 各服務供應商切換時間Tab.6 Switching time of each service provider h

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

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

圖7為訂單order_2的服務供應商之間的交互設計示意圖，各服務供應商以及云平臺之間都存有交互通道。其中橢圓標注的是A毛坯加工服務與B粗加工服務之間的交互通道，二者之間可形成圖8所示的交互時序圖。

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

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

圖8 服務供應商A與B交互時序Fig.8 Interaction sequence between service provider A and B

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

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

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

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

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

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

圖9 服務供應商的智能體模型Fig.9 Agent model of the service provider

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

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

各服務供應商訂單實際執(zhí)行順序見表8。對比原訂單順序，可發(fā)現(xiàn)服務供應商A精加工服務和服務供應商B粗加工服務、精加工服務的訂單實際到達時間順序不同于初始訂單下單時間順序。這是因為每個供應商按照先來先服務的策略執(zhí)行。

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

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

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

order_2到達B精加工服務時需等待4 h(等待order_4加工完成3 h和B精加工切換時間1 h)才能進入B精加工(6h)。這是因為order_4較order_2早5.5 h到達B精加工服務(表8中B精加工服務下的訂單order_2、order_4會互換順序)。order_4完成毛坯加工和粗加工總計用時14.5 h(B毛坯加工6.5h和A粗加工8h)。

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

3.3.2云制造服務供應商的協(xié)同建模

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

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

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

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

(a)粗加工服務商模型

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

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

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

3.4 仿真結(jié)果分析

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

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

4 結(jié)論

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

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