基于服务编排的云制造服务协同

陆剑峰 韩调娟 俞耀平

同济大学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生成、解释和执行的服务组件，以便对已经确定的服务组合自动生成流程定义文档，并且在服务执行过程中自动执行。