基于服務編排的云制造服務協同

陸劍峰 韓調娟 俞耀平

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

0 引言

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

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

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

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

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

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

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

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

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

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

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

1 基于WS-CDL服務編排的制造服務協同

1.1 服務的編制與編排

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

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

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

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

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

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

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

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

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

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

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

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

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

具體方法在第2節說明。

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

2 云制造服務編排關鍵過程實現

2.1 云制造服務交互接口規范設計

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

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

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

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

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

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

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

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

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

表2 服務接口規范Tab.2 Specification of service interface

圖5 靜態定義和動態編排Fig.5 Static definition and dynamic choreography

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

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

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

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

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

服務供應商X和Y的交互接口在基于WS-CDL協議的編排文檔中具體描述如下：

〈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〉

文檔中：①參數name表示該接口方法名；②參數informationType表示該方法的返回值類型；③參數action表示該接口的動作類型，request表示詢問，respond表示回復，request-respond表示復合接口；④〈send〉、〈receive〉節點表示信息的傳遞過程及方向。信息的獲取通過WS-CDL協議標準支持的getVariable方法實現，該方法可實現從全部的編排文檔中獲取相應對象的變量值。

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

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

〈infoTrack name=“ServiceProviderTrack”

point=“0”

unit=“hour”〉

〈interaction name=“P-QuoteOrder”

channelVariable=“tns:ProviderX-YChannel”

operation=“getQuote”〉

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

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

fromRoleTypeRef=“tns:ProviderX”

toRoleTypeRef=“tns:ProviderY” /〉

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

〈/interaction〉

〈/infoTrack〉

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

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

3 云制造服務協同案例

3.1 云制造服務案例設計

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

表4 訂單信息Tab.4 Order information

現對服務供應商A和B作如下假設：

(1)假設服務供應商A和B服務的業務流程為：等待訂單—準備加工—加工制造—訂單完成或訂單異常—切換訂單。

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

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

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

3.2 WS-CDL編排文檔實現

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

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

首先，服務供應商B會向服務供應商A詢問當前訂單的狀態，服務供應商A返回相應訂單的狀態信息；然后，服務供應商B詢問當前訂單的進度，同樣服務供應商A返回相應訂單的進度信息；若order_2訂單發生異常，則服務供應商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發送訂單異常的信息，以實現服務供應商B對自身訂單的安排更新。

3.3 基于Anylogic的協同模型

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

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

3.3.1傳統制造模式仿真建模

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

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

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

圖10 傳統制造模式仿真結果Fig.10 Simulation results of the traditional manufacturing mode

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

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

表9所示是各個服務訂單的開始時間和結束時間。假設訂單開始為零時刻，分析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經過B毛坯加工只花費了3 h, order_2較order_3晚9.5 h到B粗加工服務(表8中B粗加工服務下的訂單order_2、order_3會互換順序)。根據先來先服務原則, B粗加工服務會為order_3服務7 h，再考慮B粗加工服務的切換時間，所以order_2的B粗加工服務為7.5 h。order_2經過毛坯加工和粗加工，總計用時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結束時間為30 h,驗證了表9中的order_2的結束時間。其他訂單分析同order_2的分析。

3.3.2云制造服務供應商的協同建模

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

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

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

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

(a)粗加工服務商模型

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

圖12 服務協同仿真結果Fig.12 Simulation result of service collaboration

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

3.4 仿真結果分析

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

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

4 結論

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

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