International journal of computer integrated manufacturing , tập 23, số 2, 2010

A reference framework for a shop-floor gateway isproposed based on the three key components: Workflow management, manufacturing services universal description,discovery and integration nam

Agent-based workflow management for RFID-enabled real-time reconfigurable manufacturing

YingFeng Zhanga,b, George Q Huanga*, Ting Quaand Oscar Hoa

a

Department of Industrial and Manufacturing Systems Engineering, The University of Hong Kong;bThe State Key Laboratory for

Manufacturing Systems Engineering, Xi’an Jiaotong University, Xi’an, China(Received 22 April 2009; final version received 27 October 2009)Recent developments in wireless technologies have created opportunities for developing reconfigurable wirelessmanufacturing systems with real-time traceability, visibility and interoperability in shop-floor planning, executionand control This paper proposes to use agent-based workflow management as a mechanism to facilitate interactionsamong RFID-enabled reconfigurable manufacturing resources A production process is modelled as a workflownetwork Its nodes correspond to the work (process), and its edges to flows of control and data Nodes arerepresented as agents and edges as messages As a sandwich layer, agents wrap manufacturing services around awork-cell and their operational logics/intelligence for cost-effectively collecting and processing real-timemanufacturing data, forming so-called work-cell gateways A reference framework for a shop-floor gateway isproposed based on the three key components: Workflow management, manufacturing services universal description,discovery and integration (namely MS-UDDI) and work-cell agents Work-cell agents are packaged, registered andpublished at MS-UDDI as web services which are easily reused and reconfigured in the workflow for a specificproduction process Finally, a prototype system is presented to demonstrate how the proposed method is used todefine and execute a real-time reconfigurable manufacturing project

Keywords: workflow management; multiple agent systems; reconfigurable manufacturing; real-time wirelessmanufacturing; RFID/auto ID

1 Introduction

With the increasing competition in the global

market-place, manufacturing enterprises have to strive to

become responsive to business changes which have

further impacts upon production goals and

perfor-mance at the shop-floor level Many business problems

manufacturing enterprises are facing now are caused by

lack of timely, accurate, and consistent shop-floor

manufacturing data The infrastructure and tools need

to be designed and developed for reconfiguring a

manufacturing process to visualise, monitor and control

its real-time execution according to various production

orders Therefore, it is essential for manufacturers to

upgrade their capabilities with advanced manufacturing

technologies (AMT), in terms of both software and

hardware technologies Recent developments in wireless

sensors, communication and information network

technologies (e.g radio frequency identification –

RFID or Auto-ID, Bluetooth, Wi-Fi, GSM, and

infrared) have nurtured the emergence of reconfigurable

wireless manufacturing (WM) (Huang et al 2009) as

next-generation manufacturing systems (NGMS)

The concept of RMS (reconfigurable

manufactur-ing systems) was introduced in the mid-nineties by

Koren et al (1999) as a cost-effective response to

market demands for responsiveness and customisation

It was pointed out that RMS was designed at theoutset for rapid change in structure, as well as inhardware and software components, in order toquickly adjust production capacity and functionalitywithin a part family in response to sudden changes inmarket or in regulatory requirements The ultimategoal of RMS is to utilise a systems approach in thedesign of manufacturing process that allows simulta-neous reconfiguration of (1) the entire system, (2) themachine hardware and (3) the control software.Radunovic (1999) proposed an innovative RMSparadigm to dissolve the hard borders between hard-ware and software and join the potentials of both.Zhao et al (2000) considered a RMS as a manufactur-ing system in which a variety of products required bycustomers are classified into families, each of which is aset of similar products, and which correspond to oneconfiguration of the RMS Mehrabi (2000) proposesfive key characteristics for RMSs They are modular-ity, integrity, convertibility, diagnosability and custo-misation Yigit and Usloy (2002) describe a modularstructure to accommodate new and unpredictablechanges in the product design and processing needsthrough easily upgrading hardware and software

*Corresponding author Email: gqhuang@hku.hk

Vol 23, No 2, February 2010, 101–112

ISSN 0951-192X print/ISSN 1362-3052 online

Ó 2010 Taylor & Francis

DOI: 10.1080/09511920903440354

rather than the replacements of manufacturing system

elements such as machines

Despite of significant progress achieved in the

above researches in utilising RMS, a breakthrough is

yet to come in reality One critical hurdle is the lack of

a RMS infrastructure imminently required for

manu-facturing enterprises to achieve real-time and seamless

dual-way connectivity and interoperability between

application systems at enterprise, shop-floor, work-cell

and device levels The following questions are open for

investigation:

(1) How rapidly and flexibly to define

reconfigur-able manufacturing resources (which tasks/

processes should be allocated to which

work-cells) according to the real-time manufacturing

data when production orders are changed, and

to monitor the real-time manufacturing

pro-gress during the execution stage?

(2) How to wrap applications and services around

work-cells and their flexible manufacturing

objects so that they can be easily reused and

reconfigured for different customer orders that

require different production processes?

(3) How to capture the real-time manufacturing

data by installing Auto-ID devices as

manu-facturing services into manumanu-facturing devices?

This research adopts and develops three important

concepts in order to address the above questions in

building up an RMS infrastructure They are workflow

management, multiple agent system, and automatic

identification and data capturing technologies

Work-flow management (Elmagarmid and Du 1998) is a

well-known technology supporting the reengineering of

business and information processes, involving two

main stages: definition and execution The concept can

be readily extended to define and execute manufacturing

processes to implement reconfigurable manufacturing

Agent technologies provide necessary autonomy,

flex-ibility and reconfigurability (Sikora and Shaw 1998,

Macchiaroli and Riemma 2002) in reconfigurable

manufacturing Agents are used in this research to

wrap the work-cell applications related to

manufactur-ing objects such that they can be easily reused and

reconfigured in a manufacturing process defined as a

workflow system Auto-ID technologies, such as RFID,

can be used to capture the real-time manufacturing data

by deploying RFID devices (Readers and Tags) to

manufacturing resources (Huang et al 2007) This

RFID-enabled real-time RMS provides a new paradigm

for production systems which accommodates higher

flexibility in terms of product volumes and types

This paper discusses the challenges of integrating

the above three concepts into a coherent infrastructure

framework for implementing real-time RMS The rest

of the paper is organised as follows Section 2 reviewsthe literature of workflow management, agent-basedmanufacturing and automatic data capturing forwireless manufacturing Section 3 outlines a systematicoverview of the real-time reconfigurable manufactur-ing infrastructure A referenced framework of shop-floor gateway is proposed in Section 4 Section 5presents the concept of agent-based workflow manage-ment and its key enabling technologies A case forshop-floor assembly line is designed and demonstrated

in Section 6 Conclusions are drawn in Section 7

2 Literature reviewThree streams of literature are relevant to this research.They are workflow management, agent-based manu-facturing applications and automatic data capturingfor real-time manufacturing

2.1 Workflow managementWorkflow management is a diverse and rich technol-ogy and is now being applied over an ever increasingnumber of industries Hollingsworth (1994) definesthat a workflow process is a coordinated (parallel and/

or serial) set of process activities that are connected inorder to achieve a common business goal According

to Schal (1996), the workflow management system isused to define, manage, and perform ‘workflows’through the execution of software, whose order ofexecution is driven by a computer representation of theworkflow logic Workflow technology is increasinglyused to manage complex processes in e-commerce (vander Aalst 1999, Lazcano et al 2000) and virtualenterprises (Casati et al 1995, Liu and Pu 1998) Inmanufacturing systems, Huang et al (2000) proposes adistributed workflow management model to developdistributed manufacturing execution system Lau et al.(2000) present a methodology for the design anddevelopment of a flexible workflow supply chain(FWSC) system for achieving flexibility to cope withunexpected changes Chiu et al (2001) use an inte-grated, event-driven approach for execution, coordina-tion, and exception handling in workflow managementsystem Montaldo (2004) applies workflow manage-ment system to enhance business performance forsmall-medium enterprise Tan and Fan (2007) adopt anovel dynamic workflow model fragmentation algo-rithm to execute the distributed processes

2.2 Agent-based manufacturingAgent technology is a branch of artificial intelligence(AI) and has been widely accepted and developed in

manufacturing applications for its autonomy,

flexibil-ity, reconfigurabilflexibil-ity, and scalability (Sikora and Shaw

1998, Macchiaroli and Riemma 2002, Maturana et al

2004) An agent based concurrent design environment

(Tan et al 1996, Krothapalli and Deshmukh 1999) has

been proposed to integrate design, manufacturing and

shop-floor control activities A compromising and

dynamic model in an agent-based environment (Sikora

and Shaw 1998) has been designed for all agents

carrying out their own tasks, sharing information, and

solving problems when conflicts occur Some mobile

agent-based systems (Shin and Jung 2004) have been

applied to the real-time monitoring and information

exchange for manufacturing control Jia et al (2004)

proposed an architecture where many facilitator agents

coordinate the activities of manufacturing resources in

a parallel manner Jiao et al (2006) applied the MAS

paradigm for collaborative negotiation in a global

manufacturing supply chain network Besides, in

various kinds of applications such as distributed

resource allocation (Bastos et al 2005), online task

coordination and monitoring (Lee and Lau 1999,

Maturana et al 2004), or supply chain negotiation

(Wu 2001), the agent-based approach has played an

important role to achieve outstanding performance

with agility

2.3 Automatic data capturing for real-time wireless

manufacturing

Currently, real-time visibility and interoperability have

been considered core characteristics of next-generation

manufacturing systems (Huang et al 2006) As early as

in early 1990s, Udoka (1992) has discussed the roles of

Auto ID as a real-time data capture tool in a computer

integrated manufacturing (CIM) environment Early

RFID manufacturing applications have been briefly

quoted in Brewer et al (1999) and further promoted in

Li et al (2004) Johnson (2002) presents a RFID

application in a car production line The website http://

www.productivitybyrfid.com/ also provides a few links

to real-life pilot cases Chappell et al (2003) provides

general overview on how Auto ID technology can be

applied in manufacturing Pilot projects have recently

been implemented and reported

(http://www.autoi-dlabs.com/research archive/) Several relevant

white-papers have been prepared to provide roadmap for

developing and adopting Auto ID-based manufacturing

technologies (Harrison and McFarlane 2003, Chang

et al 2003) More recently, the Cambridge Auto ID Lab

has launched an RFID in Manufacturing Special

Interest Group (SIG) (http://www.aero-id.org/) Huang

et al (2007, 2008) implement RFID technologies to

capture the real-time manufacturing data of employees,

machines and materials of assembly line

3 Overview of real-time reconfigurable manufacturingThe aim of the research reported here is to apply RFIDtechnologies and develop an easy-to-deploy and simple-to-use reconfigurable information infrastructure formanufacturing companies to achieve real-time andseamless dual-way connectivity and interoperabilitybetween application systems at enterprise, shop-floor,work-cells and RFID devices Figure 1 shows anoverview of the proposed infrastructure This infrastruc-ture is consistent with a normal manufacturing hier-archy That is, a manufacturing factory has one or moreshop-floor production lines A production line consists ofseveral work-cells each of which involves a variety ofmanufacturing objects, such as operators, machines,materials etc Different production lines are oftenresponsible for different production processes Accord-ing to the manufacturing hierarchy, the proposed RTMinfrastructure includes following core components: Shop-floor Gateway (SF-Gateway): SF-Gateway

is at the centre of the overall RTM FollowingService-Oriented Architecture (SOA), SF-Gate-way includes three main components, i.e work-flow management, MS-UDDI and work-cellagent These components will be further detailed

in the following sections

Work-cell Gateway (WC-Gateway): WC-Gatewayacts as a server to host and connect all RFID-enabled smart objects of a work-cell A WC-Gateway has a hardware hub and a suite ofsoftware systems The hub physically connects allRFID-enabled smart objects which are represented

as software agents in the WC-Gateway operatingsystem All smart objects are used in a ‘universalplug and play (UPnP)’ and interoperable manner RFID-enabled smart objects: Smart objects arethose physical manufacturing objects that aremade ‘smart’ through equipping them withRFID devices Those with RFID readers areactive smart objects Those with RFID tags arepassive smart objects Smart objects interact witheach other through wired and/or wireless con-nections, creating what is called an intelligentambience In addition, smart objects are alsoequipped with specific operational logics, datamemory and processing functions Therefore,smart objects are able to sense, reason, act/react/interact in the intelligent ambience community

4 Overview of reconfigurable shop-floor gatewayThe shop-floor gateway is a high-level key component

of the proposed real-time reconfigurable ing infrastructure Figure 2 shows the overall

manufactur-architecture of the reconfigurable SF-Gateway

Fol-lowing the service-oriented architecture (SOA),

work-cells, work-cell applications, equipments and smart

object in a shop-floor can all be considered as

manufacturing services The manufacturing services

(agents) are wrapped as a work-cell agent Each agent

contains the real-time information and status of the

work-cell Work-cell agents can be registered and

published at MS-UDDI while SF-Gateway can select,

add and deploy these work-cell agents for different

production process, enabling a reconfigurable facturing (Huang et al., 2008a) Specifically, processplanners use configuration facilities to search suitablework-cell agents from MS-UDDI and configure themfor a specific production process The configurationresult is a workflow among work-cell agents (i.e work-cells) which represents a manufacturing process Thisworkflow could be used for the next lifecycle stage –execution During the actual execution, shop-floormanagers could monitor and control the status and

manu-Figure 1 RFID-enabled real-time manufacturing infrastructure

Figure 2 Overview architecture of reconfigurable shop-floor gateway

progress of the manufacturing process through

SF-Gateway tools which communicate with work-cell

agents at gateway servers Real-time data are handled

centrally at the SF-Gateway repository

The proposed reconfigurable SF-Gateway is

com-posed of three major components, namely workflow

management, UDDI for manufacturing services

(MS-UDDI), and work-cell agents

4.1 Workflow management (WM)

This WM component is used to (1) define a

manu-facturing workflow based on a product’s process plan,

(2) (re)configure the manufacturing services through

using agent-based workflow model and MS-UDDI,

and (3) coordinate the involved work-cell agents to

execute real-time manufacturing according to the

defined workflow Workflow management includes

three modules, namely definition module, binding

module and execution engine They are described as

following

Definition module is responsible for defining the

workflow according to the specific production

processes

Bind module automatically records the

relation-ships between the work cell agents and the

manufacturing process after work-cell agents are

searched and chosen as production process nodes

Execution engine not only facilities the execution

of work-cell agents according to the defined

workflow and logic, but also monitor and control

the work-cell agents during the execution

process

4.2 Manufacturing services UDDI (MS-UDDI)

The function of MS-UDDI is similar to those of

standard UDDI (Universal Description, Discovery

and Integration), serving as a platform-independent

framework for describing and discovering services

through Internet MS-UDDI is composed of three

main modules, i.e publish and search module, service

model and tModel

Publish and search module is used to convert

work-cell agents into public web services, which

can be easily searched to implement flexible and

reconfigurable shop-floor manufacturing

Service model describes a group of web services

which are contained in a businessService

struc-ture For each published work-cell agent, there is

a set of web services each of which serves for

certain specific propose and can be invoked over

internet

tModel is a data structure representing a servicetype (a generic representation of a registeredservice) in UDDI

4.3 Work-cell agentWork-cell agent is responsible for wrapping the work-cell applications to process the complex real-time datacaptured from smart objects The work-cell agent can

be used to reflect the real-time manufacturing tion and status of a work cell The work-cell agentsmust be registered and published at MS-UDDI as webservices, then found and invoked via MS-UDDI sothat the proposed reconfigurable manufacturing can beachieved Along this innovative concept and structure,other users or systems can directly attain the status andreal-time information of work cell by visiting orinvoking its agents Three models, method model,data model and smart object manager (SOM) model,are involved in this component

informa- Method model is used to deal with the huge time data captured by RFID devices installed atthe work-cell Gateway based on rules andschemas For example, the ‘getMaterials’ methodwill deal with all the data relevant to materials ofthis work-cell Gateway and return detailed real-time information such as material item, quantityetc At MS-UDDI, each method can be regarded

real-as a service of the registered work-cell agent Data model describes and defines the basicstandards of input and output data of work-cellagents The data model adopts XML-basedschema that can be easily edited, transformedand extended

Smart object manager model aims at managingthe behaviors of smart objects installed at awork-cell gateway It is implemented withintelligence logics so as to sense and identifythe real-time manufacturing data of single smartagents as well as the communication betweenmultiple smart objects

5 Agent-based workflow management forreconfigurable manufacturing

5.1 Agent-based workflow management model forreconfigurable manufacturing

An agent-based workflow management (WFM) modelwill be firstly defined of its topology of processes andmanufacturing resources, i.e indicates the involvedmanufacturing resource types yet has not been assigned

to specific work cells (agents) Then, each node of theworkflow will choose its execution agent from MS-UDDI based on the actual status of the qualified agents

Figure 3 shows the agent-based WFM framework,

which is used to not only plan and control the flow of

production processes and data, but also executes any

process (work) node of the workflow from the selected

work-cell agent The WFM model is responsible for

reusing and reconfiguring the work-cell agents to

implement various production orders There are two

basic elements in the agent-based WFM model:

process and agent A process refers to a portion of a

production task and can be assigned to a specific

manufacturing resource (work cell) As mentioned in

section 3, the work-cell agent wraps the corresponding

function of a work-cell, which can execute and finish

the process

In the SF-Gateway level, the WFM is mainly

concerned with the co-ordination of distributed

work-cell agents As can be seen in Figure 3, process nodes

represent production tasks, and the logical nodes

represent the trigger conditions Edges represent the

logical relationships between production processes, i.e

the flows of control and data

WFM is built on the concept of agents An agent

represents a work package in the workflow All the

agents involved in a workflow share the same

repository and the repository becomes a common

working memory This sharing information ensures the

traceability of the decisions at different stages by

recording them in a decision tree in terms of the

contents of the decisions, the decision-makers, and

precedence decisions, etc

Agents are only used to define the work or node of

a production process workflow Relationships between

nodes are separately defined in terms of flows Without

flow definitions, agents still do not know where inputs

are obtained from and outputs are sent to Theseparation of flow definition from work definitionprovides opportunities to reuse agents for differentproduction projects once they are defined for RTM

No further changes are necessary when agents are usedfor other production projects What the project teamneeds to do is to choose the agents according to thedifferent production project and define the flows ofcontrol and data between agents to suit specificrequirements

5.2 Workflow definitionWorkflow definition has two work modes One isediting mode which means the process planner definesthe agent-based workflow for a specific productionproject The other is executing mode which means themanager monitors and controls the progress ofexecuting a production workflow Workflow definition

in turn involves the ‘work’ definition and the ‘flow’definition

Two types of flow are identified in this WFM Theyare flow of precedence and flow of data The flow ofprecedence and logic node between work-cell agentsdefines their dependencies For example, supposing asimple hypothetical product consists of two compo-nents, B and C The component B is an outsourcingand the component C is produced at work-cell 2.Finally, component B and C are assembled to formProduct A at work-cell 3 Accordingly, the production

of A is decomposed into three production processeswhich can be depicted by the directional network-topology mode Here, Agent 1 represents a ‘delivery A’work, Agent 2 represents a ‘producing B’ work and

Agent 3 represents an ‘assembling C’ work As shown

in Figure 4, Agent 3 can only start its work after Agent

1 and 2 complete their works under the and logical

condition Agents 1 and 2 may work simultaneously

The flow of data refers to the situation where

agents share their property data Some outputs from

an agent may be the inputs to other agents Such

relationships can be easily defined in a similar way that

relationships are defined between data tables in a

relational database Flows of data can be compared to

messages widely used in multi-agents system (MAS)

for communication And the message configuration

tool configures where inputs are obtained from and

outputs are send E Figure 4 combines some output

items of Agents 1 and 2 as the one input item of Agent

3 according to the real requirements

Flows of data, or message passing, are triggered bythe flow of precedence and logical condition Forexample, during the ‘and’ condition, if Agents 1 and 2have not finished with its work, flows of dataassociated with Agent 3 will not be processed

5.3 Workflow executionOnce a workflow is fully defined, it can be executed asillustrated in Figure 5 During the execution, each node

in the workflow will be translated to an agent Eachagent will invoke its manufacturing services (e.g work-cells, smart objects, etc.) of the real manufacturingenvironment to enable their intelligent management ofthe manufacturing process Explorers are provided tooperators, managers and supervisors for monitoring

Figure 5 Agent-based execution of a workflow model

Figure 4 Two types flow of work: control flow and data flow

and controlling the workflow execution lifecycle The

users can simply follow the logic and execute relevant

production tasks As a high-level user, the shop-floor

manager can have a clear overview of the progress of a

production project at the SF-Gateway At the

WC-Gateway, on the other hand, the operators of

work-cells can use this facility to check if the conditions of

their tasks are met so that they can start The general

procedure of executing a workflow is as follows:

The work-cell Agents use Service Oriented

Architecture framework to connect to the web

server where SF-Gateway is deployed;

XML-Based workflow definition file is

automa-tically downloaded to and manually activated at

the corresponding Agents;

Repository is contacted to retrieve the workflow

model defined in advance;

The first agent in the workflow is activated The

agent is executed according to the procedure

discussed in the preceding section Its incoming

messages defined as flows of data associated are

fired Therefore, this agent knows from where its

input data come;

After preparing its input data, repository is

contacted to save the input/output and other

data of the agents;

Execution engine notifies all work-cell agents

about the changes;

The work-cell agent is prompted if the output is

accepted or a backtracking is necessary;

Upon completion, the control is passed over to

subsequent agents; and

This process repeats until the last agent in theworkflow is completed

6 Case study6.1 Configuration of a representative assembly lineThis section demonstrates the usage of the proposedarchitecture with an example application of anassembly line This proof-of-the-concept test-bedserves the purpose of demonstrating how the proposedreal-time reconfigurable WM framework would work

in an industrial environment, gaining insights aboutrequirements of WM solutions, and highlightingfurther issues for research and development of WMsolutions The study is based on a simplified motivat-ing scenario shown in Figure 6

The configuration of the assembly line and cells depends upon the structure of the product(variant) to be assembled The product demonstratedhere is composed of five components assembledsequentially across three work-cells, as shown inFigure 6 At the first work-cell, two components,one of which is a critical base module, are puttogether to form the first level subassembly Twofurther components are added to the subassembly atthe second work-cell The last component is as-sembled to produce the finished product at the thirdwork-cell where an inspection also takes place todetermine if the product is acceptable or rejected Allcomponents and subassemblies are moved and main-tained in containers or pallets of appropriate sizesand shapes

work-Figure 6 Overview of the motivating assembly line

6.2 Agent publish

In order to implement the proposed agent-based

workflow management for shop-floor, work-cell agents

should be firstly registered and published to

MS-UDDI Figure 7 illustrates the main steps for

publish-ing a work-cell agent at MS-UDDI, namely

Step 1: Login MS-UDDI

The manufacturing resource manager is responsible

for registering and publishing the work-cell agents of

as web services Considering the security, the

manu-facturing resource manager needs to login the

MS-UDDI using his account for further operations as seen

in Figure 7(a)

Step 2: Register Service information of Work-cell

Agent

The MS-UDDI provides facilities, as shown in

Figure 7(b), to describe the service information of the

work-cell agent so that users (e.g shop-floor

man-ager) can easily know what services this work-cell can

provide The registered information includes agent

ID, description, process capability, access point etc

Agent ID is used to identify the each work-cell

agent; description indicates the machine type of the

work-cell agent, e.g lather, mill, assembly etc.;

process capability describes the specific machining

characters, i.e which processes can be executed at

this work-cell; access point shows the internet address

of a work-cell agent to enable users or systems to get

access

Step 3: Publish Work-cell Agent

After the registration of agent information, the

manufacturing resource manager can physically

publish the work-cell agents to MS-UDDI, as can

be seen in Figure 7(c) A published work-cell agent

can be found and invoked as web service through

internet This register and publish processes are

repeated until all the work-cell agents are published

to MS-UDDI

6.3 Workflow definitionAfter all the work-cell agents have been defined andpublished at MS-UDDI, it is important to establish theworkflow of the shop-floor level The definition of ashop-floor workflow includes four steps as can be seen

in Figure 8 The main steps are described as following:Step 1: Get the process planning of the specificproduct

A shop-floor workflow is corresponding to apractical production process Generally, differentproducts have different production processes There-fore, process planning of a product is the inputinformation for defining a shop-floor workflow Thedetailed process planning of a product ‘A’ is given atthe top of Figure 8, including three assembly processes,i.e Assembly ‘C’, ‘B’ and ‘A’

Step 2: Define workflow according to the processplanning

The workflow facility provides graphic interfacesfor shop-floor manager to edit the work and flowaccording to specific process planning As seen inFigure 8(b), the three production processes of product

‘A’ are described by graphic objects The rectangledenotes the ‘Assembly’ work, and the directed arrowrepresents the sequence of the processes

Step 3: Establish mappings between the processesand agents

This step is responsible for establishing mappingrelationships between processes and agents, as shown

in Figure 8(c) For each process, e.g the process

‘Assembly B’, there are several potential work-cellagents registered at the MS-UDDI The optimal agentcan be selected to execute a process based on itscapabilities, e.g capability and its real-time status.Then, a pop-up dialog is used to define the conditionconstraints and input/output data At this time, themapping relationship between the process and agent isestablished

Figure 7 Main steps for publishing work-cell agent at MS-UDDI

When the workflow operation is carried out, an

XML segment is created simultaneously The XML

segment stores the condition parameters and input/

output data, etc defined by user

Step 4: Create workflow definition file

The step 3 is repeated until all the condition and

data of all the processes and its agents have been

defined, and the corresponding XML-based workflow

definition file is formed at this time, as shown in Figure

8(d) So far, the definition of agent-based workflow has

been finished

6.4 Workflow execution and monitorThe defined workflow definition file will be imported tothe workflow engine for execution through coordinat-ing the involved work-cell agents During the executionprocess, agent explorer and workflow explorer could

be used for tracing and monitoring the execution status

of work-cell agents and workflow respectively Figure 9shows the two explorers

Once an agent is started by the workflow engine,the agent explorer is available for viewing the real-time

Figure 8 Main steps for definition an agent-based workflow

Figure 9 Execution and monitoring explorer Available in colour online

information of this work-cell, as shown in Figure 9(a).

Production operators can use this useful and real-time

manufacturing information to execute assembly plans

and schedules at the level of individual work-cell

Figure 9(b) shows an overall execution of all the

involved work-cell agents Each work node represents

an agent whose real-time status could be tracked In

this case, different statuses of work-cell agents are

indicated by three different colours Red status

indicates that the assigned work of a work-cell agent

has not been started; yellow status indicates the

assigned work is being processed; blue status indicates

the assigned work has been finished This explorer

provides real-time production information for high

level administrators of enterprise to improve

shop-floor productivity and enhance the rapid responsibility

in case of onsite exception

7 Concluding discussion

The shop-floor gateway presented in this paper is an

easy-to-deploy and simple-to-use infrastructure

frame-work which integrates the concept of agents into

workflow management and RFID devices to realise

real-time reconfigurable wireless manufacturing On

the one hand, RFID technologies are used to achieve

real-time manufacturing data collection, and enable

the dual-way connectivity and interoperability between

high-level (i.e shop-floor level) and work-cell level,

and create real-time visibility and traceability

through-out the entire enterprise On the other hand,

agent-based workflow management model is applied to plan,

reconfigure and monitor the flow of production

processes, data and control, and manage the

real-time manufacturing information The use of this

proposed technology will allow manufacturing

enter-prises to improve shop-floor productivity and quality,

reduce the wastes of manufacturing resources, cut the

costs in manufacturing logistics, reduce the risk and

improve the efficiency in cross-border customs logistics

and online supervision, and improve the

responsive-ness to market and engineering changes

Three contributions are important in our research

The first contribution is the integration of the agent

concept into workflow management Production

pro-cesses at the shop-floor level are represented as

workflows At the workflow definition stage, the

shop-floor manager achieves real-time reconfigurable

manufacturing by configuring work-cell agents for a

production process At the workflow execution stage,

real-time manufacturing is achieved by capturing and

collecting the real-time data of smart objects installed

at all work-cells The second contribution is the use of

agents based on service-oriented architecture to wrap

the work-cell applications as real-time manufacturing

information services Therefore, RFID-enabled facturing objects can be easily reused and reconfigured

manu-to form specific production processes from agent-basedservices registered at MS-UDDI The third contribu-tion is the overall framework for the RFID-enabledreal-time manufacturing infrastructure Through in-stalling the RFID devices including RFID readers andtags to traditional manufacturing resources such asemployees, equipments and materials, the real-timemanufacturing data of shop-floor can be cost-effec-tively captured and collected to support dynamicdecision-making activities

However, the work should be further extended inseveral ways For example, the design and develop-ment of the micro workflow management of the smartobject to manage the whole lifecycle of manufacturingservices at the level of wireless devices Micro workflowmanagement facilities facilitate smart objects so thatthey can sense, identify, communicate, decide and act

In addition, other enterprise application systems (e.g.Advanced Planning and Scheduling - APS andComputer Aided Process Planning - CAPP) should

be considered as inputs to the proposed workflowmanagement Most suitable work-cell agents (services)can then be selected based on the results of APS andCAPP services The real-time manufacturing informa-tion captured by work-cell agents can be used toenhance the real-time decisions at shop-floor andenterprise levels

Acknowledgements

The authors are most grateful to various companies whoprovide technical and financial supports to this research Theauthors would like to acknowledge financial supports ofHKSAR ITF (GHP/042/07LP) grant, HKSAR GRF (HKU/712508), National Science Foundation of China (50805116;70629002), HKU Research Committee Grants, and fromindustrial collaborators

References

Bastos, R.M., Oliveira, F.M., and Oliveira, J.P., 2005.Autonomic computing approach for resource allocation.Expert Systems with Applications, 28 (1), 9–19

Brewer, A., Sloan, N., and Landers, T., 1999 Intelligenttracking in manufacturing Journal of Intelligent Manu-facturing, 10 (3–4), 245–250

Casati, F., et al., 1995 Conceptual modelling of workflows.In: Proceedings of the International Conference on Object-Oriented and Entity-Relationship Berlin: Springer, 341–354

Chang, Y., McFarlane, D., and Koh, R., 2003 Whitepaper

on ‘Methodologies for integrating Auto ID data withexisting manufacturing business information systems.Available from: http://www.ifm.eng.cam.ac.uk/automation/publications/w_papers/cam-autoid-wh009.pdf

Chappell, G., et al., 2003 Auto ID on the line: the value ofauto ID technology in manufacturing Auto ID Center,CAN-AutoID-BC-005

Chiu, D.K.W., Li, Q., and Karlapalem, K., 2001 Web

interface-driven cooperative exception handling in

ADOME workflow management system Information

Systems, 26 (2), 93–120

Elmagarmid, A and Du, W., 1998 Workflow management:

state of the art versus state of the products In: A Dogac,

L Kalinichenko, M Tamer Ozsu, and A Shethm, eds

Workflow Management Systems and Interoperability

NATO ASI Series, Series F: Computer and Systems

Sciences 164, Springer Heidelberg, 1998

Harrison, M and McFarlane, D., 2003 Whitepaper on

development of a prototype PML server for an auto

ID enabled robotic manufacturing environment

Avail-able from: http://www.ifm.eng.cam.ac.uk/automation/

publications/w_papers/cam-autoid-wh010.pdf

Hollingsworth, D., 1994 Workflow management coalition

the workflow reference model Workflow Management

Coalition Document Number TC00-1003, UK

Huang, C.Y., 2002 Distributed manufacturing execution

systems: a workflow perspective Journal of Intelligent

Manufacturing, 13 (6), 485–497

Huang, G.Q., et al., 2008a RFID-enabled smart objects for

real-time reconfigurable manufacturing Proceedings of

DET2008 5th International Conference on Digital

France

Huang, G.Q., et al., 2008b RFID-based wireless

manufac-turing for real-time management of job shop WIP

inventories International Journal of Advanced

Manufac-turing Technology, 23 (4), 469–477

Huang, G.Q., Huang, J., and Mak, K.L 2000 Agent-based

workflow management in collaborative product

develop-ment on the Internet Computer-Aided Design, 32, 133–

144

Huang, G.Q., Wright, P.K., and Newman, S.T., 2009

Wireless manufacturing: a literature review, recent

development, and case studies International Journal of

Computer Integrated Manufacturing, 22 (7), 1–16

Huang, G.Q., Zhang, Y.F., and Jiang, P.Y., 2006

RFID-based wireless manufacturing for walking-worker

assem-bly shops with fixed-position layouts International

Journal of Robotics and Computer Integrated

Manufac-turing, 23 (4), 469–477

Jia, H.Z., et al., 2004 An adaptive upgradable agent-based

system for collaborative product design and

manufac-ture Robotics and Computer-Integrated Manufacturing,

20 (2), 79–90

Jiao, J.R., You, X., and Kumar, A., 2006 An agent-based

framework for collaborative negotiation in the global

manufacturing supply chain network Robotics and

Computer Integrated Manufacturing, 22 (3), 239–255

Johnson, D., 2002 RFID tags improve tracking, quality on

Ford line in Mexico Control Engineering, 49 (11), 16–16

Koren, Y., et al., 1999 Reconfigurable manufacturing

systems Annals of the CIRP, 48 (2), 527–540

Krothapalli, N and Deshmukh, A., 1999 Design of

negotiation protocols for multi-agent manufacturing

systems International Journal of Production Research,

37 (7), 1601–1624

Lau, H.C.W., Ning, A., and Chan, F.T.S., 2000 Design and

development of a flexible workflow supply chain system

IEEE International Conference on Management of

In-novation and Technology Proceedings, 12–15 November

2000, Singapore, 792–796

Lazcano, A., et al., 2000 WISE: process based e-commerce

IEEE Data Engineering Bulletin, 46–51

Lee, W.B and Lau, H.C.W., 1999 Multi-agent modelling ofdispersed manufacturing networks Expert Systems withApplications, 16 (3), 297–306

Li, Z.K., Gadh, R., and Prabhu, B.S., 2004 Applications ofRFID technology and smart parts in manufacturing.Proceedings of DETC’04: ASME 2004 Design Engineer-ing Technical Conferences and Computers and Information

in Engineering Conference, September 28–October 2,

2004, Salt Lake City Utah USA DETC2004–57662.Liu, L and Pu, C., 1998 Methodical restructuring ofcomplex workflow activities Proceedings of the ICDE

1998.IEEE Computer Society Press, 342–350

Macchiaroli, R and Riemma, S., 2002 A negotiation schemefor autonomous agents in job shop scheduling Interna-tional Journal of Computer Integrated Manufacturing, 15(3), 222–232

Maturana, F.P., et al., 2004 Distributed multi–agentarchitecture for automation systems Expert Systemswith Applications, 26 (1), 49–56

Mehrabi, M.G., Ulsoy, A.G., and Koren, Y., 2000 gurable manufacturing systems: key to future manufactur-ing Journal of Intelligent Manufacturing, 11, 413–419.Montaldo, E., Sacile, R., and Boccalatte, A., 2003 Enhan-cing workflow management in the manufacturing in-formation system of a small–medium enterprise: anagent-based approach Information Systems Frontiers, 5(2), 195–205

Reconfi-Radunovic, B., 1999 An overview of advances in gurable computing systems Proceedings of the 32ndHawaii International Conference on System Sciences,IEEE, 1–10

reconfi-Schal, T., 1996 Workflow management systems for processorganizations Lecture Notes in Computer Science NewYork: Springer-Verlag

Shin, M and Jung, M., 2004 MANPro: mobile agent-basednegotiation process for distributed intelligent manufac-turing International Journal of Production Research, 42(2), 303–320

Sikora, R and Shaw, M.J., 1998 A multi-agent frameworkfor the coordination and integration of informationsystems Management Science, 44 (11), 65–78

Tan, G.W., Hayes, C.C., and Shaw, M., 1996 An agent framework for concurrent product design andplanning IEEE Transactions on Engineering Manufactur-ing Management, 43 (3), 297–306

intelligent-Tan, W and Fan, Y.S., 2007 Dynamic workflow modelfragmentation for distributed execution Computers inIndustry, 58 (5), 381–391

Udoka, S.J., 1992 The role of automatic identification (Auto

ID in the computer integrated manufacturing (CIMArchitecture) Computers and Industrial Engineering, 23(1–4), 1–5

Van der Aalst, W.M.P., 1999 Process-oriented architecturesfor electronic commerce and inter organizational work-flow Information Systems, 24 (8), 639–671

Wu, D.J., 2001 Software agents for knowledge management:coordination in multi-agent supply chains and auctions.Expert Systems with Applications, 20 (1), 51–64.Yigit, A.S and Usloy, A.G., 2002 Dynamic stiffnessevaluation for reconfigurable machine tools includingweakly non-linear joint characteristics Proceedings of theInstitute of Mechanical Engineers, Part B, 216, 87–100.Zhao, X.B., Wang, J.C., and Luo, Z.B., 2000 A stochasticmodel of a reconfigurable manufacturing system, Part 1:

a framework International Journal of Production search, 38 (10), 2273–2285

Internet-based intelligent service-oriented system architecture for collaborative product

development

Yi Hu*, Xionghui Zhou and Congxing Li

National Die & Mold CAD Eng Research Center, Shanghai Jiao Tong University, Shanghai, 200030, China

(Received 31 October 2008; final version received 27 October 2009)Collaborative product development is a strategic approach for manufacturing enterprises to succeed in thecompetitive market Issues of information and knowledge sharing within the value chain are regarded as the mostsignificant aspect of collaborative product development and the sharing is based on geographically distributedbusiness domains To support this issue, this paper discusses internet-based intelligent system architecture forcollaborative product development built upon service-oriented architecture that is a profitable infrastructure forhandling distributed heterogeneous resource sharing The system utilises basic and extensible services to provideefficient and effective knowledge-sharing functionality on-demand A Java-enabled solution together with artificialintelligence techniques is employed to develop such a networked system Finally, a case study is presented toillustrate how the tool and die makers are involved and cooperate with the product designers to make an optimaldesign collaboratively

Keywords: knowledge-sharing; service-oriented architecture; collaborative product development; tool and die maker

1 Introduction

Today, the world has become more and more practical

and cost-conscious This trend has dramatically

intensified and globally expanded the competitive

environment of manufacturing in recent years These

developments require that the process of product

development continuously evolves so as to satisfy

consumer demands in a changing market and shrink

product life cycles Enterprises must boost their

flexi-bility and responsiveness in terms of product

develop-ment so as to design and produce more complex

products at lower cost and in less time In this global

environment, organisations do not possess all the

knowledge they need but instead rely on buying

tech-nologies or services through contractual and

coopera-tive partnerships with other organisations (Choo et al

2000) As a result, more and more efforts focus on

building up a new product development paradigm that

requires various domain experts to collaborate closely

and share knowledge among themselves The degree

of knowledge sharing supported by a collaborative

environment is an important parameter for its success

in the global market In response to this need, a

solu-tion called collaborative product development (CPD),

which is defined as: ‘an internet based computational

architecture that supports the sharing and transferring

of knowledge and information of the product lifecycle

amongst geographically distributed companies to aid

taking right engineering decisions in a collaborativeenvironment’’ (Rodriguez and Al-Ashaab 2002), hasbeen proposed by research community However, thelack of communication and interaction among part-ners often results in long development time, high cost,incompatible problems and other inconsistencies.Therefore, information technologies have been applied

to develop a CPD system recently to enhance theirability to share knowledge and work collaborativelyduring the whole product development lifecycle Asdifferent roles in the product development lifecycleare always with different knowledge and differentlevels of expertise, the intelligent collaboration amongdifferent roles appears to be important

In most cases, intelligent collaboration alwayscovers several different domains and platforms thatmay be heterogeneous or homogenous, structured

or unstructured, distributed or centralised so thattraditional technologies are limited To cope with thisproblem, the approach of distributed computing plat-form based knowledge-sharing, integrated witheXtensible Markup Language (XML), becomes themost likely direction XML is a standard for data rep-resentation and exchange on the Internet and provides

a common way for defining a specific format of messagethat can be transported in heterogeneous environmentwithout misunderstanding A special advantage ofXML is standard application programming interfaces

*Corresponding author Email: f29001hy@gmail.com

Vol 23, No 2, February 2010, 113–125

ISSN 0951-192X print/ISSN 1362-3052 online

Ó 2010 Taylor & Francis

DOI: 10.1080/09511920903440347

(APIs) for parsing XML documents, so XML users do

not have to develop their own parsers for the specific

XML formats they use (Jovanovic and Gasevic 2005)

There are several approaches that propose XML as the

common syntax for sharing knowledge For example,

Leff (Leff 2001) developed Jess User Functions that

load XML documents and convert their document

object model (DOM) tree into series of facts that can be

consumed by Java expert system shell (Jess) On

another side, service-oriented architecture, as one of

distributed computing platforms, exposes concrete

functionality as standards-based, shared and reusable

services This architecture is a collection of declared

services that are independent and loosely coupled, but

controlled through policies Service-oriented

architec-ture provides an infrastrucarchitec-ture to support

knowledge-sharing in geographically distributed heterogeneous

environments

This paper describes the internet-based intelligent

service-oriented system architecture for collaborative

product development in order to propose an enabler

tool used in collaborative product development and

discusses the holistic architecture, methodology and

prototype implementation The remainder of the paper

is organised as follows Section 2 presents the

back-ground of collaborative product development with

related research review and service-oriented

architec-ture Section 3 puts forward the detailed description of

the system architecture and the methodology adopted

Section 4 analyses the prototype implementation

Section 5 concludes the paper with future research

work

2 Background and related research review

2.1 Collaborative product development

Products born in the twentieth century have increased

in complexity, which implies complex product

devel-opment processes, complex organisational forms and

more complex projects for managing the process of

developing the products (Williams 1999) Twentieth

century globalisation has also brought increased

com-petition from various parts of the world Both the

increased complexity of products and the increased

competition on global market imply a need for

collaboration in product development

Collaborative product development (CPD)

con-cepts are not new and revolutionary The theoretical

concept of CPD first started to appear in 1994, in a

journal paper ‘Multimedia Comes of Age’ (Cassidy

1994) In 1995, the CPD concept appeared in many

more publications by authors such as Bruce et al

(1995) At that time, the research of CPD was around

the buyer–supplier relationships, as well as the

com-plexity and success factors of CPD Later on, CPD

appeared frequently in journal articles and conferencepapers CPD focuses on the continued responsibility ofdifferent disciplines and lifecycle functions for productdevelopment specifications and their translation into aproduct that satisfies the customer Thus, during thelifecycle of CPD, every stage is an iterative process andincludes some sub-processes, tasks, and activities Forexample, during product definition, collaborative de-sign, collaborative simulation and product evaluationare involved in the product design stage, which takestime and is costly This in turn demands a more holisticview and supporting tools, in the form of methods,models, or processes

A number of research initiatives related to CPDhave been undertaken by several authors before.Several technological requirements that must beaddressed in order to develop enabling technologiesfor CPD are summarised below:

(1) System architecture: To have a holistic view ofthe CPD system architecture, models and appli-cations should be integrated within a framework

in a structured and transparent manner priate system architectures should be designed tosupport collaborations and coordinate CPDactivities effectively and efficiently

Appro-(2) Communication and collaboration: During theproduct development, there are always manykinds of changes, such as a design requirement,

an unanticipated simulation or testing result, theavailability of a component, or an improvement

to the manufacturing process It is essential forquality and productivity to react quickly to suchchanges Knowledge management, knowledge-sharing mechanisms, the documentation oflearning lessons and other generic rules arealso the concerns of this requirement

(3) Model and management: The models of duct and process are the basic features ofCPD The product model should support andfacilitate the integration of every phase ofCPD process, like between design and simula-tion, testing and evaluation, i.e., the integrationbetween different CAD models, between CADmodels and CAE/CAM models, etc Managing

pro-a CPD model pro-and process is much morecomplex

(4) Implementation methodologies: Suitable CPDmethodologies are helpful and critical for betterunderstanding and successful implementation

of CPD and provide enabling tools for CPD

To develop a CPD system meeting all the aboverequirements, it is necessary to have a distributed,platform-independent and intelligent architecture

based on new information technologies to cope with

these challenges

2.2 Related research

Authors from various areas have addressed

collabora-tive product development in different ways

Integrated product models contain all product data

needed during product lifecycles in order to support

collaborative development Many works have been

done before, such as FBS model (Gero 1990), Krause

et al (1991), Tichkiewitch et al (1993), the CPM

model (Sudarsan, et al 2004, Noel et al 2004), the

IPPOP intiative (Roucoules, et al 2006) and the PPO

design model (Noel et al 2008)

Research on information technologies applied in

CPD is rather extensive Examples include Huang,

et al (2000), Kumar and Midha (2001), Toerlind

(1999), Ramesh and Tiwana (1999) and

Oehrwall-Roennbaeck (2002) Web based technologies

(includ-ing Java, JSP, ASP, servlet and XML) have been

widely used in the implementation of CPD systems

(Roy et al 1991, Qiang et al 2001, Shen et al 2001,

Tay and Ming 2001, Zha and Du 2002, Mok et al

2008) Distributed object technologies (including

CORBA, COM/DCOM/COMþ, and Java RMI)

have been used in commercial software to develop

sophisticated solutions for the industry Research

on agent-based systems within the area of artificial

intelligence (AI) has also emerged during the last

decades (Shen and Wang 2003, Dunbing Tang 2004)

Apparently, research on computer supported

colla-borative work is well covered and is now the focus of

many established research groups

Decision support systems (DSS) are used in virtual

collaborations between organisations (e.g virtual

enterprises (VE)) or within an organisation among

organisational functions (Huang et al 2000) (e.g CE

or IPD) to support the everyday work and facilitate the

decision-making

Content management (Gsell 2006) is an additional

emerging area and unquestionably an important

part of a collaborative product development Systems

that manage product content or data have been

referred to as product data management systems

(PDM) In related PDM application projects,

com-mercial PDM tools (SmartTeam, Motiva) are used to

implement enterprise integration Similarly, a generic

template for CPD is presented (Zhang et al 1999),

which adopts PDM as its universal integration

platform

Supply chain issues have been extensively

ad-dressed within the purchasing area (Fraser et al

2003) However, recently, the focus of supplier

collaboration has also been addressed from the

product development perspective (e.g Peter 1996,Culley et al 1999, Handfield et al 1999, Wynstra

et al 2001, Fagerstroem and Jackson 2002)

A distributed collaborative environment is required

to achieve concurrent and cooperative product opment Recently emerged web services, semantic web,and grid computing technologies are promising inthe implementation of more flexible and scalableCPD systems (Chung et al 2000, Beiter and Ishii

devel-2003, Johanson, and Krus 2003) As the SOA withWeb service is inherently distributed and scalable, aSOA-based collaborative environment with knowl-edge-sharing for product development is developed inthis research to enable the inter-communications,negotiations, coordination and cooperation betweenthe participants for joint and concurrent productdevelopment

2.3 Service oriented architecture

In recent years, service-oriented architecture (SOA)has emerged as a key strategy for improving informa-tion technologies performance In fact, Gartner, Inc.(the world’s leading information technology researchand advisory company) projects that by 2010 SOAwill be the design standard in more than 80% of newmission-critical applications and processes SOA isbecoming a leading paradigm for information planningand application integration

Adopting the practice of SOA delivers importantbenefits as follows:

(a) Faster time-to-market for new applicationshelps organisations achieve competitive advan-tage by rapidly seizing new opportunities andresponding to threats

(b) Flexible applications create flexible processes,making the organisation more agile and adap-table in the face of changing marketrequirements

(c) Service reuse creates greater efficiency andlowers maintenance costs

(d) The ability to respond quickly to new tory requirements or specific compliance issueshelps companies avoid governmental penalties.Thereby, SOA dramatically improves the flexibilityand adaptability of enterprises by accelerating thetime to market for new applications and processes,driving down costs by making services highly reusableand building processes to support changes As a result,enterprises can react faster, seize new opportunitiesand respond more quickly to competitive threats,which are the same requirements of collaborativeproduct development and have shown great

regula-potential in distributed and collaborative design and

manufacturing

Until now, little research has been found to apply

the SOA approach into collaborative product

devel-opment, which still deserves extensive research In this

paper, intelligent SOA system architecture is

con-structed to integrate die-maker’s activities into

custo-mer product development process in the distributed

and collaborative environment It has functions to

assist participants to communicate easily and

con-veniently and to be aware of the mutual requirements

during the early design stage

3 Internet-based intelligent service-oriented system for

CPD

3.1 Overall system architecture

The internet-based intelligent service-oriented system

architecture is depicted in Figure 1 In general, the

system architecture can be divided into six main

components: Base Resource, Integration, Service

Re-pository/Registry, Orchestration, Governance &

Man-agement and Presentation

The Base Resource is the physical environment that

consists of packaged or internally developed

applica-tions and data sources, such as a knowledge base,

database or other legacy applications It is the

founda-tion of the system and provides the informafounda-tion

and capabilities of various entities for the upper

components to repackage and expose as reusable

services, so that services can meet functionality,

performance and availability requirements

The Integration plays as an intermediary betweenthe underlying Base Resource and the upper compo-nents that need to access and share resources in thesystem Integration enables the efficient and flexibleutilisation of resources across and beyond the bound-aries of organisations and enables them to interoperateseamlessly, despite the existence of multiple andpossibly heterogeneous platforms and protocols, whileleveraging the potential of the Internet It typicallyincludes integration technologies, such as data integra-tion, enterprise services bus (ESB), Enterprise applica-tion integration (EIA), enterprise informationintegration (EII), etc

The Service Repository/Registry consists of ble and self-contained services and information

reusa-or meta-date of them, providing the capability ofregistering, searching and finding services A service isprovided by an entity for use by others In this system,

a service is created to enable access to one or morecapabilities in the Base Resource through the Integra-tion A service is accessed by means of a serviceinterface, where the interface comprises the specifics

of how to access the underlying capabilities There are

no constraints on what constitutes the underlyingcapability or how access is implemented Thus, theservice could carry out its described functionalitythrough one or more processes and they could invokeother available services It represents the new paradigmfor commercial software development and delivery and

is often prominent in SOA strategy

The Orchestration provides tools for creatingapplications, defining workflows and assembling

Figure 1 Internet-based intelligent service-oriented system architecture

processes by combining and composing services from

Service Repository/Registry to meet the specific needs

of various requirements It describes how services can

interact with each other, including the logic and

execution order of the interactions and then constructs

an executable process that may result in a long-lived,

transactional, multistep process plan With it, the

interactions are always controlled from the perspective

of one of the participants involved in the process The

Orchestration is the focus of the process management

(PM), workflow, activity monitoring (AM), rules

vendors, etc

The Governance & Management provides

govern-ance and management functionality for the other

components mentioned above Usually, they include

a trusted and authoritative system of record for

the discovery of services, capabilities for managing

collaboration between technical and business

stake-holders in an SOA, tools for enhancing the quality

and conformance of services, capabilities for

forma-lising consumer and provider relationships,

enfor-cing policies within an operational environment to

permit conforming and reject nonconforming service

behaviours at run time and other security problems,

etc

The Presentation is how services and the

applica-tions are displayed to end users Examples include web

portals, composite application frameworks, mobile

devices, etc

3.2 Core functionalities

A practical application of SOA requires an

under-standing of the complexities and interrelationships of

the SOA concept Based on the system architecture

proposed above, there are two major functionalities:

governance and management functionality and

knowl-edge-sharing functionality They are core

functional-ities that operate together upon the proposed system

architecture to ultimately enable the realisation of

collaborative product development

3.2.1 Governance and management functionality

The focus of governance and management

function-ality relies on visibility, trust and control within SOA

This means creating a foundation that balances the

flexibility and agility with the control and

predict-ability of hardware or software resources There is

often confusion centred on the relationship between

governance and management Governance is

con-cerned with decision making, which aims to determine

who has the authority and responsibility for making

decisions and the establishment of guidelines for how

those decisions should be made Management, on the

other hand, is concerned with execution, referring tothe actual process of making, implementing andmeasuring the impact of those decisions Conse-quently, governance and management work in concert

to ensure a well-balanced and functioning organisation

to discover and publish reusable services.Repository that provides a way to capture,catalogue and discover all of the metadata,artifacts and relationships in SOA andcapabilities for rich reporting, impact analysisand synchronisation with other repositories.Service catalogue that simplifies the process

of publishing and discovering services with astraightforward and intuitive application forproviders to publish and consumers to dis-cover services

(b) Creating policies and validating conformance

so that services put into production are of highquality Policy management that takes the timeand complexity out of service validation andimproves the quality and conformance ofreusable services

(c) Creating consumer and provider contracts tolessen conflict and set appropriate expectations.Contract and consumer management thatpromotes consumer and provider trust andconditions that bind service providers and theconsumers who reuse services

(d) Managing the lifecycle of services to controlservices from introduction to retirement.Lifecycle management that provides controlover versioning and state change of servicesfrom initial introduction to final retirement.Service level management that manages andprovides visibility into how an SOA isdelivering the actual service in real time andover time

(e) Reporting on various dimensions, includingimpact analysis to understand how servicechanges affect other services and ultimatelybusiness processes Problem resolution thatfacilitates fast problem detection and notifica-tion so that despite SOA complexity, perfor-mance issues can be diagnosed quickly andmean time to repair is reduced Change impactthat decreases the risk of frequent changes inSOA environments by quickly detecting themand establishing their impact

3.2.2 Knowledge-sharing functionality

In this system, capabilities are exposed as

standards-based, shared and reusable services Services are

self-describing, independent and loosely coupled, but

controlled through policies, and they can be assembled

ad hoc to orchestrate complex processes, which means

services can be shared among applications despite the

heterogeneous environment

SOA is based upon the service concept and there

are three main components of SOA standards:

(1) Simple object access protocol (SOAP) provides

the envelope for sending the services messages

(2) The web services definition language (WSDL)

forms the description for services A service

provider describes its service using WSDL

(3) Universal description, discovery and

integra-tion (UDDI) registries can be searched to

quickly, easily and dynamically find and use

services

Based on these standards, there are three roles acting

in SOA; named service provider, service registry and

service consumer Service provider creates services and

generates service description as service interface

according to WSDL, then registers the services to

service registry using UDDI; service registry maintains

information of services that providers created; and

service consumer (client) finds these services in service

registry using UDDI and interacts with service

provider by SOAP to bind the services for usage

This is illustrated in Figure 2 below

On the basis of Figure 2, this system can realise

knowledge-sharing functionality with the mechanism

as: based upon the Base Resource, such as database,knowledge base and expert system, or other legacyapplications, the Integration gives interfaces to connectand utilise these entities; through the interfaces, serviceproviders can wrap the capabilities of these entities,such as domains’ knowledge or other information theywant to share, as services and register the services tothe Service Repository/Registry; furthermore, complexprocesses can be composed in the Orchestration byvarious services from the Service Repository/Registry;then clients use the Presentation to find the services

or processes they need, and get the detail servicedescriptions to directly communicate with serviceproviders to acquire the capabilities of the entities,for example domain knowledge or other information.Consequently, it makes for true knowledge-sharingamong participants of this service-oriented system.This research is concerned with the collaborativeproduct development in which tool and die makers areinvolved Quite typically, the tool and die industrycomprises a complete process chain, starting with tooland die design and leading to tool and die assemblyand tryout, to act as a connecting link between productdesign and serial production Thereby, collaborativework among them is needed Figure 3 describes asimple example of the collaborative work in tool anddie industry In Figure 3, the information generatedfrom the customer requirements is passed to designers.According to the information, designers construct partmodels and then tool and die makers take charge oftool and die design Especially, there need to beevaluation activities to make sure that the part,designed by designers according to customers require-ments, is possible and suitable for future manufactur-ing by tool and die designed by tool and die makers,

Figure 2 Web service sharing mechanism in SOA

and the same to simulation activities that mainly

validate the tool and die model for the future

manufacturing usage, so that collaborations are

required among these activities and knowledge is

shared among the partners In this research, the need

of capturing and delivering knowledge in the

colla-borative work is fulfilled by providing specific advice in

accordance with relevant expertise

Knowledge can be represented in various ways:

rule-based representation, logic, semantic networks,

frames and model-based representation, etc The

rule-based representation consists of conditions evaluating

to true or false and actions to be taken depending on

the results of the conditions, which form rules in a

certain domain In this way, knowledge is represented

in the form of production rules and rules are written as

IF-THEN statements to provide a formal way of

representing strategies, knowledge and

recommenda-tions This method is the most popular and versatile of

all the representation schemes, and a rule-based

knowledge-representation method was adopted to

develop the knowledge base in this research As the

research is for tool and die industry, there are

abundant items of rules related to tool and die design

and part manufacturability For example (Dunbing

Tang 2004):

(1) The diameter d of a hole should be greater than

the part thickness t by a factor k dependent

upon the part thickness, namely, d 4 k*t

(2) The width of a slot or projection should begreater than the part thickness by a factordependent upon the part thickness

(3) The notch angles in a profile should always berounded

(4) The inside bending radius of a rib should begreater than, or equal to, twice the sheetthickness

(5) As to the extruded hole with screw threads, theheight of the extrusion is limited to the stockthickness

(6) Set-outs should be limited in height to one-halfthe stock thickness If the set-out is madehollow, it is possible to obtain a height ofapproximately 1.5 times that of the stockthickness

(7) The distance between the subtractive tures such as holes and slots should be aminimum of two times the stock thickness;three times is preferable from a die-strengthstandpoint

fea-(8) The minimum distance from the edge of asubtractive feature (such as a hole) to theadjacent edge of the blank should be at least thestock thickness, but preferably 1.5 or 2 timesthe stock thickness

(9) The minimum distance between the lowest edge

of the subtractive hole and the other surfaceshould be 1.5 times the stock thickness plus theradius of the bending

Figure 3 The collaborative work process in tool and die makers involved development

Figure 4 is an example rule in the knowledge base In

the real world, rule sets are always huge and stored

in files, for example, in our research, rules are stored in

.drl files With object-oriented technology, rules can be

integrated with applications made by object-oriented

languages like Java, which is to customers’ advantages

Figure 5 shows the whole process to integrate rules

with objects

Rules stored in drl files are fed into the object

KnowledgeBuilder, and then a new

KnowledgePack-age is created by the KnowledgeBuilder After the

package is built, it is added to a newly created

KnowledgeBase It can then be used to create

Knowl-edgeSession Customers use the object

Knowledge-Session to fire rules

To bind the rules of domain knowledge with part

models, an XML-based messaging method is adopted

Usually, part models are often created by commercial

CAD software in different formats, which make it

difficult to share part models among different systems

However, in many conventional CAD software, part

models now can be described as well-organised feature

trees that can be subsequently transformed as XML

format files and outputted to external applications

Thus, XML is used for representing the information of

features of part models Figure 6 shows an example of

the feature-based XML representations In Figure 6, a

part model was built in Inventor and then transformed

into a feature-based XML representation According

to the features containing in the XML representation,

the part model could be rebuilt in NX after the NX

received the XML representation

XML promotes standardisation of data format andinteroperability among different computing systemsover the Internet With the standard of interoperability

of XML, the rules of domain knowledge and theservice-oriented mechanism presented above, servicescan receive XML representations as input data for therules of domain knowledge to judge the design of partmodels The features of part models in the term ofXML representations can be shared and analysedcollaboratively in CPD participants by servicesover the Internet A simple generic example of thiscollaborative work in tool and die industry is illustrated

a process of design evaluation that is involved inthe collaboration with Die Design, due to PartModel needs the evaluation knowledge retained byDie Design Evaluation service can be invoked byreceiving a request from design evaluation withthe part model in the term of feature-based XMLrepresentations According to the rules of domainknowledge, the expert advices about the features

of part models can be generated based on XMLrepresentations and exposed to outside by the serviceand then design evaluation can acquire the expertadvices through the service interface from outsideand make any modifications if necessary to optimisethe part model

4 System implementation4.1 The implementation details

A prototype system has been implemented based

on JBoss SOA platform, and is combined with acommercial 3D CAD system (Pro/E) and a commercialdatabase (Microsoft SQL)

Figure 4 An example rule created in the knowledge base of

the case study

Figure 5 The whole process to integrate rules with objects

The JBoss SOA platform enables enterprises to

integrate services, handle business events, and

auto-mate processes more efficiently, linking data, services

and applications across the value chain In the

prototype system, JBoss SOA platform is the

infra-structure that provides the SOA fabric, integration

and management to build SOA JBoss SOA platform

facilitates participation in collaborative works, and

connects the full value chain

In the prototype system, a part model is created by

Pro/E Pro/E is a popular CAD system and can

construct the feature tree of the part model Based

on Pro/E system, we redeveloped a test function to

transform the feature tree of part model into XML

representations and output the representations as

XML files These XML files are platform-independent

and can be sent as requests to evaluation services

The implementation of evaluation services is based

on object-oriented technologies, such as Java languageand we develop service interfaces exposed on theInternet by service registry, such as UDDI Throughthese interfaces users can invoke evaluation servicesand send their feature-based XML representations

as requests and based on the requests, rules in theknowledge base are called by evaluation services tofulfill the evaluation tasks

The knowledge base is implemented by oriented language based upon the JBoss Rules(Drools) that is also a rule engine However, theXML document is an ASCII text file, and it can not

object-be used as an object for Drools To parse XMLformat files for Drools, Java Architecture for XMLBinding (JAXB) was introduced in our research JAXBcan map Java classes to XML representations, which

Figure 6 An example of the feature-based XML representation

provides two main features: the ability to marshal Java

objects into XML and the inverse, i.e to unmarshal

XML back into Java objects With JAXB, Drools can

judge if a rule is satisfied or not in the term of

feature-based XML representations Afterwards, feature-based on the

judgments, specific expert advices are generated and

can be sent back to the requester

To make the illustration clear, we choose a simple

case between one part designer and one die-maker

without complex processes The next section describes

the prototype system by the case study

4.2 A case studyUsing an example part, the following case studyillustrates how the part designer cooperates with thedie-maker in the intelligent service-oriented collabora-tive environment

The die-maker maintains the knowledge about themanufacturability of part design, and based on theprototype system, the die-maker constructs a knowl-edge base by the rule-based knowledge-representationmethod and wraps the knowledge as evaluation

Figure 7 A simple generic example of collaborative work in tool and die industry

Figure 8 A sample interface of the registry facilitator

Figure 9 An example part evaluation.

services and then registers them into service registry to

be accessible for external partners Through the SOA

registry facilitator (its UDDI Browser in JBoss SOA

exampled in Figure 8); the part designer as a customer

can search and find suitable published die-maker’s

evaluation services After choosing appropriate

ser-vices, the part designer makes an agreement with the

die-maker about the collaborative evaluation work and

gets the service interface Then the part designer

transforms the feature tree of part models into

XML-based representation files and sends the XML

repre-sentations to the die-maker partner via service

inter-face as evaluation requests After receiving the feature

information and part model from the part designer, the

die-maker parses the XML representations and carries

out the manufacturability evaluation and other

eva-luation if needed on the design according to the rules

stored in the knowledge base Any design flaw detected

in the process is notified back to the part designer to

make necessary modification (Figure 9)

5 Conclusion

In this work, internet-based intelligent service-oriented

system architecture for collaborative product

develop-ment has been proposed Identification of the aim and

methodology of this architecture is carried out and

some primary capabilities have been discussed Based

on features, a case study has been carried out oriented

to part analysis

The proposed architecture does not aim to replace

existing systems in companies but rather to be an

enabler tool for communicating and sharing

knowl-edge among the geographically distributed CPD

participants Achieving higher quality, lower cost and

short cycle time is the goal of collaborative product

development The result shows that service-oriented

architecture platform is considerable promise for

collaborative product development

The advantages of collaborative product

develop-ment system architecture proposed in this research are

as follows:

(1) The architecture is based on SOA

infrastruc-ture and works in distributed pattern Through

conventional user interface, remote users can

share design and manufacturing knowledge in

real-time

(2) The architecture could be used in the early

stage of product design

(3) Platform independent and heterogeneous

compatible

(4) With the knowledge base, collaborative

pro-duct development is supported in tool and dies

industry

For future research activities, emphasis will be putupon refining the architecture, integrating it withservice-oriented engineering, like automated and dy-namic service composition, and constructing autono-mous service-based collaborative product developmentenvironment

AcknowledgementThe authors are grateful to the anonymous referees forthe critical but constructive comments on the originalmanuscript

References

Beiter, K.A and Ishii, K., 2003 Integrating producibilityand product performance tools within a Web-serviceenvironment Proceedings of ASME DETC/CIE 2003,DETC2003/CIE-48237, Chicago, IL, 2003

Bruce, M., Leverick, F., and Littler, D., 1995 Complexities

of collaborative product development Technovation, 15(9), 535–552

Cassidy, P., 1994 Multimedia comes of age CIO, 7 (14), 58–64

Choo, W.C., Detlor, B., and Turnbull, D., 2000 Web Work:information seeking and knowledge work on the world wideweb Dordrecht: Kluwer Academic Publishers

Chung, M.J., Kwon, P., and Pentland, B., 2000 MIDAS:

A framework for integrated design and manufacturingprocess In: Proceedings of the SPIE the InternationalSociety for Optical Engineering, Vol 4192, 348–355.Culley, S., Boston, O., and McMahon, C., 1999 Suppliers innew product development: their information and inte-gration Journal of Engineering Design, 10 (1), 59–75.Dunbing Tang, 2004 An agent-based collaborative designsystem to facilitate active die-maker involvement instamping part design Computers in Industry, 54, 253–271

Fagerstroem, B and Jackson, M., 2002 Efficient tion between main and sub supplier Computers inIndustry, 49 (1), 25–35

collabora-Fraser, P., Farrukh, C., and Gregory, M., 2003 Managingproduct development collaborations – a process maturityapproach Journal of Engineering Manufacture: Proceed-ings of the Institution of Mechanical Engineers, Part B,

217 (11), 1499–1519

Gero, J.S., 1990 Design prototypes: a knowledge tion schema for design AI Magazine, 11 (4), 26–36.Gsell, H., 2006 A content management framework forproduct development In: Fourth Seminar and Workshop

representa-on Engineering Design in Integrated Product Development,Zielona Gora, Poland

Handfield, R.B., et al., 1999 Involving suppliers in newproduct development California Management Review, 42(1), 59

Huang, G.Q., Huang, J., and Mak, K.L., 2000 Agent-basedworkflow management in collaborative product develop-ment on the internet Computer-Aided Design, 32 (2),133–144

Johanson, B and Krus, P A Web service approach formodel integration in computational design In: Proceed-ings of ASME DETC/CIE 2003, QETC2003/CIE-48196,Chicago, IL, 2003

Jovanovic, J and Gasevic, D., 2005 Achieving knowledge

interoperability: an XML/XSLT approach Expert

Sys-tems with Applications, 29, 535–553

Krause, F-L., Kramer, S., and Rieger, E., 1991 PDGL – A

human and computer readable language for efficient

feature-based designing Annals of the CIRP, 40 (1), 135–

139

Kumar, R and Midha, P.S., 2001 A QFD based

methodol-ogy for evaluating a company’s PDM requirements for

collaborative product development Industrial

Manage-ment and Data Systems, 101 (3), 126–131

Leff, L., 2001 Automated reasoning with legal XML

documents In: Proceedings of the Eighth International

Conference on Artificial Intelligence and Law ACM

Press, 215–216

Mok, C.K., Chin, K.S., and Lan, H., 2008 An internet-based

intelligent design system for injection moulds Robotics

and Computer-Integrated Manufacturing, 24, 1–15

Noel, F., Roucoules, L., and Teissandier, D., 2004

Specification of product modeling concepts dedicated to

information sharing in a collaborative design context In:

Proceedings of the Fifth International Conference on

Integrated Design and Manufacturing in Mechanical

Engineering, IDMME, Bath, UK, April 5 ¨ C7

Noel, F and Roucoules, L., 2008 The PPO design model

with respect to digital enterprise technologies among

product life cycle International Journal of Computer

Integrated Manufacturing, 21 (2), 139–145

Oehrwall-Roennbaeck, A., 2002 Inter-organizational IT

support for collaborative product development Linkoping:

Linkoping University

Peter, M., 1996 Early supplier involvement (ESI) in product

development Thesis (PhD) Universitat St Gallen

Qiang, L., Zhang, Y.F., and Nee, A.Y.C., 2001 A

distributive and collaborative concurrent product design

system through the WWW-internet International Journal

of Advanced Manufacturing Technology, 17 (5), 315–322

Ramesh, B and Tiwana, A., 1999 Supporting collaborative

process knowledge management in new product

devel-opment teams Decision Support Systems, 27 (1–2), 213–

235

Rodriguez, K and Al-Ashaab, A., 2002 A review of internet

based collaborative product development systems In:

Proceedings of the International Conference on Concurrent

Engineering: Research and Applications, Cranfield, UK

Roucoules, L., et al., 2006 IPPOP: an opensource borative design platform to link product, design processand industrial organisation information In: Proceedings

colla-of the International Conference on Integrated Design andManufacturing in Mechanical Engineering, Grenoble,France

Roy, U., et al., 1991 Product development environment in acollaborative design Concurrent Engineering Researchand Applications, 5 (4), 347–365

Shen, W and Wang, L., 2003 Web-based and agent-basedapproaches for collaborative product design: an over-view International Journal of Computer Applications inTechnology, 16 (2/3), 103–112

Shen, W., Norrie, D.H., and Barthes, J.P., 2001 Multi-Agentsystems for concurrent intelligent design and manufactur-ing London: Taylor and Francis

Sudarsan, R., et al., 2004 Information models for productrepresentation: core and assembly models NISTIR 7173,NIST, Gaithersburg, MD 20899, December

Tay, F.E.H and Ming, C., 2001 A shared multi-mediadesign environment for concurrent engineering over theinternet Concurrent Engineering: Research and Applica-tions, 9 (l), 55–63

Tichkiewitch, S., Boujut, J.F., and Marin, Ph, 1993 Toward

a fast simulation system of stamping deformation In:Proceedings of 14th International Forging Congress,Venise, 27–29 September, 53–64

Toerlind, P., 1999 Products models and environment fordistributed engineering Thesis (PhD) Lulea University ofTechnology

Williams, T.M., 1999 The need for new paradigms forcomplex projects International Journal of Project Man-agement, 17 (5), 269–273

Wynstra, F., Van Weele, A., and Weggemann, M., 2001.Managing supplier involvement in product development.European Management Journal, 19 (2), 157–167.Zha, X.F and Du, H., 2002 Product web-based knowledge-intensive support framework for collaborative design ofMEMS Journal of Micromechanics and Micro Engineer-ing, 12 (5), 512–524

Zhang, J., Chen, J., and Mounayri, H.E., 1999 A generictemplate for collaborative product development Indus-trial Virtual Reality: Manufacturing and Design Tool forthe Next Millennium ASME 1999, pp 163–170

Web services-based automation for the control and monitoring of production systemsPunnuluk Phaithoonbuathong*, Robert Harrison, Andrew West, Radmehr Monfared and Thomas Kirkham

Wolfson School of Mechanical and Manufacturing Engineering, Loughborough University, Leicestershire, UK

(Received 4 February 2009; final version received 27 October 2009)Autonomous and intelligent control devices within the context of factory automation are seen as an essentialingredient in making time and cost savings in factory automation environments In moving to mass customisationscenarios where production lines are subjected to frequent changes and mixed types of products, the agility andreconfigurability of automation systems are prime requirements to support changes in manufacturing lifecycles Inaddition, intelligent functionalities including process monitoring, diagnostics and process reconfiguration are alsodesirable factors to facilitate an effective production unit with competitive costs and ease of use and maintenance Inthis context, the adoption of Web Services on the distributed embedded control devices to enhance reconfigurabilityand integrability with supported manufacturing and business applications is proposed

This paper demonstrates the use of Web Services (WS) both in building device control functionality of controlcomponents and in business application integration This WS approach offers the ability to integrate pervasiveenterprise applications (e.g process monitoring and planning systems) as well as the ability to reconfigure andmanage lower level devices from higher manufacturing and business control levels through unifying WS interfaceand neutral Simple Object Access Protocol (SOAP) message communication between control systems and businessapplications

Keywords: component-based design; Device Profile for Web Services (DPWS); distributed control system

1 Introduction

Traditional manufacturing automation systems are

often constructed in a rigid, centralised, hierarchical,

and proprietary manner These factors have

contrib-uted to implementation complexity, resulting in an

often time-consuming and error-prone processes for

automation system alteration and validation These

factors also have a direct impact on increasing the

process ramp-up time and often lead to process

performance degradation Specifically, current

auto-mation systems are deemed to require experts in order

to be commissioned and maintained This is often

owing to complex and unstructured programming and

use of vendor specific technology It is therefore

difficult for end users to support and optimise their

automation systems effectively (Phaithoonbuathong

et al 2007)

It has been reported by Colombo (2004) that

centralised and sequential manufacturing planning,

scheduling and control mechanisms are increasingly

being found insufficient for the current market

environment This is mainly attributable to a lack of

agility in the control system to respond to changes

from new product specification and dynamic variations

in the product In response to these rapid, continuous

and unpredictable changes, organisations need to

embrace more adaptive, collaborative and responsiveautomation paradigms A number of works haveproposed solutions towards this problem as outlined

in section 4 Out of these paradigms developed inrecent years the concept of the agile and collaborativemanufacturing approach as reported by severalauthors (Gunasekaran 1998, Colombo et al 2004,Wang 2004) has gained considerable attention in manyresearch institutions and organisations Efforts toexplore and develop a new manufacturing environment(Molina et al 2005) in various domains such as shopfloor automation control, enterprise control, andglobal control (e.g supply chain and outsourcingcompanies) are now evident According to Bu¨yu¨ko¨zkan(Bu¨yu¨ko¨zkan et al 2004), the key enabler of the agileand collaborative paradigm is the easy integration ofautomation systems with other business entities (includ-ing marketing, engineering, product design, businessprocess management and personnel) that support thelifecycle of the business The approach aims to reducethe cost of product changeovers, time to market,machine down-time, and machine ramp-up time throughthe utilisation of appropriate and effective solutions forreconfigurable automation systems as well as for shop-floor to business system integration In relation to thiscollaborative enterprise development, it has been

*Corresponding author Email: p.phaithoonbuathong@lboro.ac.uk

International Journal of Computer Integrated Manufacturing

Vol 23, No 2, February 2010, 126–145

ISSN 0951-192X print/ISSN 1362-3052 online

Ó 2010 Taylor & Francis

DOI: 10.1080/09511920903440313

proposed by Weston (1999) that fragmented and

heterogeneous design of the industrial systems has

impeded interoperability among manufacturing and

business entities This problem has caused major

difficulties and complexity in developing enterprise

systems in this context

Recently, the development of Service-Orientated

Architecture (SOA) has been intrinsically linked to the

growth of e-Businesses Many current e-Business

computing models rely on the presentation of

applica-tions and access to data by common standards based on

Web Services Using these services, composite

applica-tions can be developed that span computing domains

and organisational boundaries For businesses, this

added pervasiveness in terms of data management

and utilisation has yielded greater accessibility and

wider integratablity to supply chains and business

collaborators It is not only e-Business systems that

have become more comprehensive at the

‘business-to-business’ application level A similar trend is now

beginning to establish itself at the factory floor device

level Applying Web Services (WS) to define machine

control components and how they interact as the

neu-tral platform is attractive both to the manufacturers

and to enterprise system vendors New engineering

method for reconfiguration based on WS-enabled

technologies will save manufacturers time and

re-sources in developing manufacturing systems for new

products WS-enabled control devices can facilitate

device installation, reconfiguration and integration to

higher control applications both in manufacturing

and business contexts

The implemented Web Services approach in this

research is based on a discrete event-driven and control

device interlocking machine application The research

aims to build the foundation that could be applied with

further development to handle more complex

applica-tions (e.g CNC, CMM machines) The authors’ work

in this paper is in line with the ongoing work within the

SOCRADES EU project framework and in

collabora-tion with Ford Motor Company to address reliability,

robustness and error recovery of the engine assembly

line control systems In this paper, a SOA capable of

supporting reconfiguration of production lines and

Enterprise level device management is presented, along

with the results and findings of developments on a

prototype system at Loughborough University This

research has created an engineering environment for

reconfigurable component-based control in a

distrib-uted environment that aims to support agile

manu-facturing systems

The following section describes the modular design

of the component-based automation architecture

reconfigurable manufacturing systems The need and

related work in the field of collaborative and agile

automation systems are presented in section 3 and 4respectively Section 5 describes the core implementedtechnologies and methodologies employed by WebServices which will be integrated into control devices

In section 6, the implementation of a Web based distributed embedded controller is presented.Finally, the early results related to network perfor-mance and input/output (I/O) reaction speeds arepresented along with plans for future work andconclusion is discussed

Services-2 A modular component-based design approachThere is an earlier attempt proposed by McLean(McLean et al 1982) to solve the problem of rigidmanufacturing systems by introducing the virtual cell

to monitor, control and manage machine tools indistributed manufacturing environment The cell func-tion (reporting, scheduling, dispatching and monitor-ing) is defined as an abstract object, organised by thehigher cell control, to enable dynamic changes in themanufacturing process Additionally, the early work atthe authors’ institution proposed by Weston (Weston

et al 1989) on modular design of distributed ulator system demonstrated the decomposition andcomposition of machine functions for flexible design ofcontrol systems

manip-Previous work leading up to the research presented

in this paper has been conducted on the tion of modular automation systems for powertrainassembly machines at Ford Motor Company Thisresearch has applied a component-based design ap-proach for the distributed automation system pre-sented by Harrison (2004) The main characteristic ofthe proposed modular system was the design of generichardware and control software components that could

reconfigura-be reconfigured to form new machine configurations tosuit different production types (Harrison et al 2004).The modular component-based architecture enablesefficient machine build and re-use of designs in order tooptimise the machine’s lifecycle across supply chainpartners

As depicted in Figure 1, the typical based (CB) layout of the assembly machine system forthis research is built from various machine subsystems.These include a hopper unit, buffering unit, processingindex table unit, and handling arm unit, which arelinked together via Ethernet communication systems toform the completed work process These subsystemsare constituted from sets of components which containmechanical units, electrical units (sensors, actuator,I/O interface) and control software

component-In the previous research at Loughborough versity, a machine component is defined with theconstitution of: (1) controller unit which includes

Uni-network communication, hardware configuration, and

control application, (2) electronic interface, and (3)

physical inputs and outputs The physical view of the

control component is defined in Figure 2

The required functionalities of the component for

manufacturing tasks, i.e device network

communica-tion, operating mode, device behaviour, local control

application logic and error information are

encapsu-lated in the controller unit

Within this CB design approach, the low-level

control functionality has been encapsulated as a black

box and exposed to the developers via the process

engineering tool to define machine configuration data

for the machine application

In this distributed control application, a machine

application (e.g a manufacturing function) is a

combination of distributed services on components

for execution in a specific order The driving state is

achieved by formulating a behaviour model for each

machine component The reconfiguration of the

process can therefore be oriented to the higher level

alteration of the machine application/function design

In the CB design architecture, these componentsare pre-built with the required functional and integra-tion capabilities to enable effective composition intoinstances of machines based on the required specifica-tion of machine end-users To provide flexibility andreconfigurability, user applications are composed by

a higher level engineering tool (process definitioneditor tool previously developed for the COMPAGproject presented in Harrison et al 2004) Thedevelopment and reconfiguration of component-basedautomation systems at the abstract level allows alarge number of I/O systems and communicationfunctions to be realised for independently developedcomponents

In addition to the CB approach, the control systemcan be seen as a set of mechatronic components witheach device responsible for a basic operation then themore complex manufacturing tasks can be createdfrom the combination of basic components (Harrison

et al 2006) It can be observed that the complexity ofthe control system in relation to build and reconfigura-tion is reduced by managing the decomposition of the

Figure 1 A distributed CB design of a powertrain assembly machine

machine system accommodated by the process

en-gineering tool

3 Need for Web Services in automation

The CB approach is valuable in enabling flexible and

reconfigurable automation systems to more effectively

support manufacturing lifecycles However, with the

movement of manufacturing systems towards agile

and collaborative manufacturing driven by mass

customisations as discussed by various research groups

(Tseng et al 1997, Gunasekaran 1998, Colombo et al

2004, Harrison et al 2006, Assen et al 2000), new

automation systems and integrated engineering

ap-proaches need to capture a broader view of system

integration in enterprise, supply-chain and machine

and process control dimensions throughout the

man-ufacturing lifecycle

The utilisation of the CB approach within

manu-facturing is somewhat limited in terms of its ability to

deliver the agile and collaborative engineering

envir-onment required This is because integration from

higher level systems to production lines is limited

owing to differing technologies and the complexity of

integrating diverse automation peripherals In

addi-tion, this integration is still reliant on proprietary

solutions from different vendors preventing effectiveinter- and intra-enterprise integration

From this viewpoint, it has been discussed inJammes and Smith (2005) and SOCRADES EUproject (2006) that the use of Service-OrientatedArchitecture (SOA) implemented through Web Ser-vice technologies can facilitate the adoption of aunifying technology for all levels of the enterprise.Web Services are based on common communicationstandards such as HTTP, XML and SOAP, thusenabling homogenous linkage from the control levels

to enterprise business processes The use of SOA-WebServices technologies with the modular CB manufac-turing approach can provide an open, standardapproach for nonvendor specific control systems aswell as enabling seamless enterprise integration

4 Related work

In recent years a number of projects have proposedopen modular solutions suitable for manufacturingautomation plants ESPRIT III OSACA (Sperling1997) in the area of controls within automationsystems, proposed an objected-oriented architecture

to develop independent modular software structurewithin controls The recent ITEA SIRENA project(Jammes and Smith 2005) has proposed a newapproach using Web Services based on DPWS (DeviceProfile for Web Services standards) to support ‘plug-and-play’ devices In more recent projects, the SO-CRADES project (SOCRADES.EU project 2006) isdeveloping an open-platform for automation systemsusing this technology The project has created themiddleware technology presented in a SOA to enableinteroperability between heterogeneous devicesdeployed on various platforms, as well as seamlessintegration into enterprise systems

5 Web Services methodology and integrationapproach

This section presents the core technology of WebServices in the context of the assembly machine controlsystem to which it is being applied

5.1 Serviced-Oriented Architecture (SOA)Barry (2000) presented the conceptual definition ofSOA as:

‘A service-oriented architecture is essentially a tion of services These services communicate with eachother The communication can involve either simpledata passing or it could involve two or more servicescoordinating some activity Some means of connectingservices to each other is needed.’

connec-Figure 2 Schematic of a component hardware (based on

Lee et al 2004a)

where as Nickull (2005) describes SOA as:

‘SOA is an architectural paradigm for components of a

system and interactions or patterns between them A

component offers a service that waits in a state of

readiness Other components may invoke the service in

compliance with a service contract.’

SOA-based applications are predominantly developed

using Web Services, thus providing a standard

information and communication infrastructure

en-abling data passing between field devices (Jammes

and Smith 2005) Many opportunities exist to integrate

Web Services enabled devices particularly in the

domain of high-level enterprise and manufacturing

systems As discussed by Jammes (2005) and Machado

(2006), SOA can be seen to have evolved the design of

control systems into distributed application paradigms

and ubiquitous computing environments to enable

flexible, reusable, reconfigurable manufacturing

sys-tems based on self-reliant, interconnected smart

embedded devices

5.1.1 Web Services and an SOA enterprise integration

framework

Extending the SOA-focused Web Services approach to

low level automation devices has been proposed by a

number of researchers (Harrison et al 2004, Jammes and

Smith 2005, Machado and Mitmann 2006, Harrison et al

2006) The attraction from a business perspective is the

inclusion of plant activity into enterprise computing

applications, to facilitate work synchronisation between

the high- and low-level applications as this concept was

earlier introduced by McLean (1982)

In this context, a simplified manufacturing model

of SOA and Web Services derived from Nickull (2005),

Hung et al (2005), Machado and Mitmann (2006) is

illustrated in Figure 3 The basic principle of enterprise

integration and communication based on a

consumer-producer model is described below

(1) The service provider publishes (produces) the

available services to the services broker, which

is a repository for registered applications from

producers

(2) The consumer finds the provided services from

the broker

(3) The broker returns the service descriptions and

policies of how to interact with the required

services

(4) The consumer, then, invokes the remote service

on a service provider

Based on this model, Web Services ensure

distri-buted interoperability across platforms, programming

languages and applications that enable end-users tooperate and maintain the supplied systems easilythrough SOAP, WSDL and UDDI, as described inTrifa et al (2008), Liu et al (2008), Yu and Chen(2003), Graham et al (2004), W3C (2004), Jammes

et al (2007), Cachapa et al 2007, and Boritz and Gyun(2005) Data transfer between distributed components

is central to Web Services and is enabled via the use ofthe SOAP standard, and various XML meta-dataformats (Hung et al 2005)

However, central to our application of WebServices-based automation system, an approach tothe development of a Web Services enabled controldevice is needed in the SOA integration framework.The approach not only encompasses the solution forenterprise integration but also the need of processreconfigurability and delivered performance of thecontrol system to meet end-user requirements Theimplementation, demonstration and assessment workwill be presented in this paper

5.2 Devices Profile for Web Services (DPWS)

In the design of WS for a connecting device, a webcapability has been realised for low level controlsystems The core network capability has been imple-mented with the standard and well-defined protocolstack: Device Profile for Web Services (DPWS)

As presented in Figure 4, the full descriptions of theWeb Services protocol stack are reported by otherresearch works in Jammes and Smith (2005), Barry(2000) The introduction of DPWS paves the way forthe usage of a unifying technology base, via WebServices, across entire heterogeneous enterprise appli-cations, from the sensor/actuator level up to ERP/MES level

In order to enable Web Services-based automationsystems, the typical device logical functionality of thecontrol application, such as setting outputs ON/OFF

or reading sensors status of the component, is mapped

to the Web Services logical function presented by theDPWS call function via the creation of DPWSinterfaces on devices (referred to Figure 7 for imple-mented codes) that enable device-to-device and device-to-control communications for state information ex-change, and device to control level and businessapplication integration for services invocation andstatus monitoring

In the authors’ research, the implementation of theDPWS protocol stack for control devices was devel-oped in C language An embedded microcontrollerhosts the DPWS stack The embedded controller inthis research is an ARM9-based device (for informa-tion, please refer to Advantys FTB: System user guide

on the Schneider Electric website) developed and

provided by the project collaborator, Schneider

Electric, suitable for use in an industrial automation

environment The DPWS as well as its associated

machine control applications are built and uploaded to

ARM-based control devices by means of the ARM

development suite tool In addition to the control

operation, the real-time operating system and the TCP/

IP stack are ported to the embedded device providing

the core control functionality (e.g control thread,

networking and control task scheduling) The software

architecture for components is shown schematically in

Figure 5

In our approach, predefined component ality is presented by services to compose manu-facturing tasks at the higher level supported byprocess engineering tools The hard coding of devicebehaviours (local control application) implemented

function-by the component builder is encapsulated at thelow-level application The alteration of the processfunctionality (e.g., process workflow and addingnew machine components) is only done at theservice level without changing the low-level devicecode that makes the system more flexible andagile

Figure 3 SOA-Web Services basic integration framework

5.3 Web Services integration

Based on the previous work on the component-based

(CB) design approach for agile automation completed

at MSI research institute, Loughborough University

(Harrison 2004, Lee et al 2004a and 2004b), a machine

component has been defined with the I/O functionality

(device state behaviour) of machine elements (sensors

and actuators) The component is contained within its

own independent control application The operation of

these distributed components is based on their defined

interlocking sequence The work has provided the

automation framework for implementation of the

reusable and reconfigurable control system described

here

In order to create an effectively integrated Web

Services capability on the embedded controller devices

in the SOA architecture, the development of the Web

Services enabled device has complemented the CB

approach with the capability to build machine

compo-nents, which provides a manufacturing function (e.g

device execution, device information, and present device

working state) as services to the business application

integration through interface of service references

The novel implementation of Web Services-basedcomponent is shown in Figure 6 as an instance ofbuilding a Web Services machine component Thehopper component is constituted of elements (Ejectoractuator, Magazine sensor and MagazineXfer sensor)which each contain their own state behaviour Thehopper component is represented by the Web Servicescomponent (described by WSDL– Figure 7(a)) whichincludes the information of the component based oncontained elements such as Component name, Name-space location (reference web location by servicedomain name), Binding port type (a collection of anabstract set of element operations and messageexchange methods), and Metadata (component de-scriptions) required for the devices allocation on thenetwork

In respect to device operations, the operations ofthe component are encapsulated by DPWS callreferences In simple terms, these call references areconcerned with services (operations) commands, statepropagation (element states) of the event state changenotification, and operating modes (Auto/Manual).These operations are multitasking handled by theRTOS The implemented Web Services interfaces andI/O operations of the control system are shown inFigure 7(b)–7(e) A Web Services component is defined

by a WSDL (Web Services Description Language –Figure 7(a)) file that defines the component specifica-tion, a network service, and DPWS interfaces fordevice programming in an XML language structure Inbuilding the Web Services control and businessapplication integration, the WSDL file is used for thegeneration of interface files for a client–server serviceinvocation (stub and skeleton files) by the DPWStoolkit (SODA–ITEA Consortium 2007)

In the process of building a machine applicationenabled by the Web Services components in an event-driven control system, components are aggregated intothe complete control system according to defined finitestate transition conditions To demonstrate the viabi-lity of Web Services in automation, the movement ofWeb Services control elements is managed by the PCbased upon its control of finite state transitionconditions (control logic) running in the DPWSapplication, which invokes the embedded servicesprovided by the component The following sectionpresents the service aggregation methodology for amachine application in the control system

5.4 Service orchestration methodologyService aggregation allows the formation of complexand business-centric composite services/applicationswhich are composed by often simpler and elemen-tary services The manufacture of products can be

protocol stack (Jammes and Smith 2005)

Figure 5 WS component software architecture

represented by a single abstract service which contains

the appropriate stripped down statements for the

invocation of the required sub-services (Bepperling

et al 2006) Production steps are represented in the

behaviour of the service functions/operations that

would be tied to real configuration in the control

device That means the process orientation of control

levels is dependant on understandings of the lower

level processes The execution/reconfiguration of a

production line can be seen as a wider application and

the device level services in the SOA (Service-Oriented

Architecture) constitute this wider application

Central to the success of the applications execution

is the composition of the services in terms of execution

order The element functionality at the device level

needs to be mapped and captured to the device

management and self organisation Web Services-based

application Particularly in this research, this process

of composing atomic components’ services, when their

execution sequences are initiated by the control logic

operated outside the control device boundary, is

known as ‘Service orchestration’

Service functionality of a device in the machine

application is defined as a service to represent a more

abstract production operation which can be created by

combining simpler production operations This process

is referred to as orchestration and is achieved through

the combination of these services to create the process

application (manufacturing task) From a

manufactur-ing system behavioural perspective, the process can be

formed by defining a set of internal and external state

conditions of distributed components in the control

system

As illustrated in Figure 8, the state transition of

components is a result of current states of internal and

external elements, including the error state, in controllogic applications which command the output of thedistributed components hosted on controller devices.The simplified example of the control logic can beschematically presented by the ladder logic schemawhich has defined the component state transitioncondition through the use of Boolean logic of inputevents in the discrete manufacturing environment Inthis case, internal element state inputs are local statevariables of the component, and external element stateinputs are state variables of other associated compo-nents (e.g interlocking components) These variableschange their state in response to the movement ofactuators (e.g., state feedbacks)

The composition of this component state transitionhas formed the machine sequences that determine thebuild of a machine application and a process workflow In the machine operation of components, thecomponent service is dictated by the control logicapplication known as ‘Service Orchestration Engine’necessary to orchestrate the service on the components

to achieve desired manufacturing tasks

In the distributed Web Services-based controlsystem implementation, the distributed control deviceshost the service of components (e.g hopper and swivelarm component) which provide the Web Servicesoperation and element state propagation functionality

to the service orchestration engines based on a subscribe approach in an event-driven architecture Asshown in Figure 9, there are four service orchestrationengines running as a client (client 1, 2, 3, and 4) Eachone is responsible for controlling each specific stationhosted by the servers (server 1 to server 10) of thecomponents to perform manufacturing tasks in thecontrol system

publish-Figure 6 A Web Services-based design component

For the control system operation, each client (via

the service orchestration engine) subscribes to the

specific server at start-up for the published state

information of components required by the control

logic application (C in Figure 8) as presented earlier

in this section When any I/O (sensor and actuator)state changes occur, new I/O states are published tosubscribers–clients (A, B and E in Figure 8) Thecomponent operation (i.e extend or retract theejector element of the hopper component) as shown

Figure 7 Sample fragment codes of WSDL, DPWS component and Device I/O interfaces

Figure 7 (Continued).

by D in Figure 8 is based upon the state transition

behaviour/logic of controlled elements It should be

noted that the movement of the control device has

resulted in the I/O state changes of associated sensor

and actuator elements which are propagated back to

the clients for the new control event This process of

the service orchestration cycle runs repeatedly by the

servers and the clients to perform the complete cycle

of the machine application

In addition to the system reliability with respect

to safety of the operation on machine components,

the heartbeat monitoring system and fault recovery

routine (see //Fail safe routine in Figure 7(e)) have

been implemented within the control system In case

of error occurrence on the device detected by

cooperated sensors during the conditioning process

(e.g EJECTOR_ERROR in Figure 7(e)), the

pre-defined fail safe routine will be enabled automatically

to safely recover from the hazard condition, and

then it reports the error state condition to the

responsible client application to handle the fault by

sending the DPWS reset command to shutdown the

failed device The periodic heartbeat message (F in

Figure 8) sent by the components will be used to

monitor and ensure that all the control device

operations (DPWS applications and I/O functions)

are functioning normally The heartbeat system is

enabled by the DPWS function using a device state

notification method This function is planned to be

implemented in future work

6 Implementation of Web Services automationThe FTB (Field Terminal Block) control device, which

is industrially packaged to IP 67 (please refer toMeDiSolTM website for specifications), provides theprocessing capability, local I/O and a standardembedded Ethernet connection

As illustrated schematically in Figure 5, the ware structure of control devices or components isconstructed with a layer of Web Services application

soft-at the top The component also requires a suitableRTOS and IP stack laid underneath to handle theDPWS task with TCP/IP communication in order toperform the real-world manufacturing tasks TheRTOS layer is responsible for the real-time multitaskscheduling in the control system However, theresearch scope here does not include the examination

of the methodology and techniques for control tasksscheduling For information on this topic, please refer

to Barry (2003)

Based on this architecture, encapsulated services ofdevices have been implemented using the DPWStoolkit provided by Schneider Electric to generate the

C stub and skeleton files from the component WSDLfile so as to build component services on the embeddedFTB devices and service invocators (for orchestration)

On the FTB, each service is interfaced to the actual I/Ooperation of components defined in the local controlapplication layer This DPWS component code isimplemented with the Realview debugger tool and the

Figure 8 Component state transition diagram

ARM suite development platform (please refer to

ARM1 website for information)

The services orchestration engine running the

component state transition logic (C in Figure 8) is

implemented with both C and Java language to

investigate interoperability of the implemented

DPWS control platform The engine is used to

manipulate the action on embedded controllers

(FTBs) by sending out the DPWS invocation

com-mand in SOAP message (Figure 10) format through

the Ethernet to the target component using XML

transport

The Web Services-based automation system is

implemented with the DPWS on the distributed

FTB devices executed by the distributed DPWS

clients on PC-based orchestration of each station In

Figure 11, the Web Services application of station 1 is

demonstrated

0: Server applications (S1, S2 and S3) start up;

control devices initialise hardware/software

con-figuration and DPWS applications of

components

1: The client application (running DPWS utility)

sends probe messages to discover required

components hosted by server applications; the

match component returns the message with

the address The client application keeps the

location of components as an endpoint

reference based on Universally Unique

Identifier (UUID) format (i.e urn: uuid:13814002-1dd2-11b2-bc3d-0040af000032) inmemory for the DPWS application, such asservice subscriptions and invocation

2–3: The client (client 1) of the station 1 whichcontained 2 components subscribes to theDPWS components of station 1 (Hopper-S1 and Swivel drive-S2) and station 2(Conveyor-S3) for the contained elementstates used by the service orchestrationengine The subscriber (the client) loca-tion/address is saved in the device registryhandled by WS-Eventing

4–5: During the machine operation, when theelement has changed its state (i.e workpiece present), it publishes the state infor-mation to the client 1 The message is sent

to the receiver addressed (allocated at thesubscription process) by Uniform ResourceIdentifier (URI) scheme (i.e IP: Port/UUIDà http://150.1.0.201:8873/158cb99e-693b-11dd-8abd-001c42935fe4) in theSOAP Header

6–7: Orchestration engine on the client 1 gates the action according to the definedstate transition behaviour Like state noti-fication method, the addressing scheme forthe service invocation is provided by URIscheme Please see Figure 10 for a sample ofUUID format and URI scheme

aggre-Figure 9 A PC-based orchestration engine application

In this application, having completed step 1 and 2–

3, only step 4–5 and 6–7 have been run repeatedly

throughout a machine cycle To ensure system

robust-ness in terms of sending and receiving the SOAP

message, the acknowledgment of the DPWS operation

receipt has been implemented in addition to a TCP

packet synchronisation (see TCP/IP networking and

DPWS transaction time in the next section) to

guarantee that every DPWS message has been

success-fully received at application level For the

implementa-tion, the incremental order ID variable has been

defined in the DPWS application to identify and

keep track every message received by the components

(please see //Message received acknowledgement in

Figure 7) The RTOS timer task on the sender (client)

will be initiated and response expected from the

receiver within a time limit When the client receives

this message, it notifies the sender with the SOAP

message (i.e., ACK) In this case, missing

acknowl-edgement messages will result in a timeout after 50

milliseconds to raise a suitable error However, this

acknowledgment process has been currently

imple-mented on only one side from the server to client

application (refer to Figure 11 in ACK: Processing or

Retry) Acknowledgement in both directions (refer to

Figure 11 in ACK: Message Receive and ACK:

Pro-cessing or Retry) will be next implemented

In addition to the process control and visualisation,

the system HMI provides an environment to allow users

to collate data from and send command to distributed

components in the system via a simple browser interface

For the visualisation, the HMI application interacts withthe test rig through the service orchestration enginewhere live data of components are gathered

7 Testing and preliminary result

In this section, component-based design of intelligentdevices as discussed/described in section 6 will bepreliminarily evaluated in the real automation envir-onment to measure the performance in terms ofcommunication speed and response time In addition,the reconfiguration of the test rig process is determined

to assess the degree of complexity in terms of activitiesinvolved in reconfiguring component configurations,and control logic An assessment on the businessapplication integrability of the approach is alsopresented

7.1 TCP/IP networking approach and DPWStransaction time

Based on our implemented Web Services controlsystem, the protocol analyser has been installed tocapture the network performance during the test rigoperation These analysis data (shown in Tables 1 and2) are average values derived from a measurement ofaround 2,000 packets out of ten cumulated experi-ments In this Web Services environment, presentSOAP messages of the DPWS operations are stateinformation, service call functions, discovery probeand metadata return These SOAP messages packet

size are 750 bytes up to a maximum TCP/IP packet size

of 1514 bytes In the DPWS service invocation (Table

1) and the device state notification (Table 2), there are

nine packets sent and received between Host A (FTB

device as a server) and Host B (Orchestration engine

application as a client) for each of the DPWS

operation According to a TCP byte-oriented

sequen-cing protocol (InetDaemon Enterprise 1996a and

1996b, Bentham 2000), the analysis of packet

synchro-nisation as shown in Tables 1 and 2 is included the

TCP connection (3-way handshake) for a connection

negotiation, the SOAP message, and a connection

synchronisation and termination In order to measure

the DPWS processing (marshalling and demarshalling)

time on the embedded device, the timer in the

resolution of microsecond has been initiated in the

DPWS application The DPWS processing time

on the embedded ARM 966 core control device with

96M Hz CPU speed is around 8 to 9 milliseconds

In the implemented WS control system, the I/O

response time (the delay between the occurrence of an

input event and the corresponding of an output event

as described by Denis (2007) is accounted by thesummary delivery time of:

(1) The packet time on a network,(2) The DPWS processing time(2.1 DPWS encoding and decoding on theFTB control device and 2.2 OrchestrationEngine),

(3) The local I/O processing time on the FTBand,

(4) Processing time on the orchestration engine

In the experiment, separated analysis works have beencarried out on the server and the client side to measureconsumption time of each task for the controloperation In this case, Tables 1 and 2 have coveredthe time analysis on the server tasks (included 1, 2.1and 3) The time analysis on the orchestration engine(client) application has been captured by settingstopwatch (micro-second resolution) in processing

Figure 11 Test rig WS control system use case