Orchestration of Service-Oriented Manufacturing Processes François Jammes, Harm Smit Schneider Electric, Corporate Research 38050 Grenoble Cedex 9, France
[email protected],
[email protected] Abstract This paper outlines the perspectives opened by the application of the service-orientation paradigm for realizing high-level communications between next-generation, increasingly intelligent embedded devices – it indicates how this approach can benefit the manufacturing industry – and outlines the issues and approaches for cohesively coordinating manufacturing services at various levels of the manufacturing device hierarchy.
1
Overview
After a description of the rapidly expanding acceptance of the service-orientation paradigm and its essential characteristics (chapter 2), an introduction is given on how service-orientation can be applied in the device space and implemented using standard Web Services communication protocols (chapter 3). Chapter 4 then describes how a communication framework, based on device-level service orientation, can be beneficial for networking of industrial automation devices. Chapter 5 discusses the associated issues of service orchestration and choreography, as well as corresponding standards and technologies. Finally, chapter 6 describes the challenges for reconfigurability and discusses the benefits of using Web Semantics in agent-based systems.
2
The advent of SOA
The concept of service-oriented architecture (SOA) has gained significant traction in just a few years and it is sometimes claimed that 2005 will be "the year of SOA". Despite the associated hype factor, there is very little doubt that SOA will have a major impact in many branches of technology, not only in the Information and Communication Technologies (ICT) sector where it originated, but also in many technological areas into which ICT techniques can be transposed. This tendency is particularly significant for the device space, where the usage of a high-level service-based communications infrastructure opens entirely new perspectives. The following section outlines some of the essential characteristics of SOAs.
Jose L. Martinez Lastra, Ivan M. Delamer Institute of Production Engineering, Tampere University of Technology PO Box 389, 33101 Tampere, Finland
[email protected],
[email protected]
2.1 SOA in a nutshell There are many definitions of the concept of a service-oriented architecture. For the purpose of this paper, we use the following basic definition: A service-oriented architecture (SOA) is a set of architectural tenets for building autonomous yet interoperable systems. Although definitely incomplete, this definition includes two key words: autonomous and interoperable. The principal characteristics setting apart autonomous systems are that: they are created independently of each other, they operate independently of their environment, they provide self-contained functionality, i.e., this functionality would be useful even if it was not associated with any higher-level systems. Interoperability is favored by clearly abstracting the interface that a service exposes to its environment, from the implementation of that service. Autonomy and interoperability are contradictory properties. One of the challenges of SOA is, therefore, to reconcile these opposing principles. The architectural principles for achieving combined autonomy and interoperability can be summarized as follows. The design of a service interface follows an outside-in approach: rather than deriving it from the details of its implementation, the interface of the service is defined by focusing on how the service may fit in a larger business process context. Indeed, SOA is business process centric rather than technology centric – a service usually represents a business task. This property induces the granularity of services: a service interface is mostly coarse-grained and stateless, and is based on the exchange of documents. This is one of the aspects differentiating service-oriented from object-oriented design; the latter usually involves a conversation-style interaction pattern addressing individual object attributes. In a SOA, communicating entities are loosely coupled, by virtue of the fact that a service's functionality is exposed at its interface. Thus, the
implementation of the service may be modified without the service's users being affected. In contrast, the tightly coupled, context-related and stateful interactions typical of distributed object architectures create dependencies between the communicating entities, resulting in rigid and fragile systems. SOA-based communications are of an asynchronous nature: when a service is requested to perform a certain action, the result – if any – is returned to the invoking application entity without the latter suspending its operations. In addition to its interface description, a service can have requirements, properties or capabilities – expressed through "policies" – that can be negotiated at run-time. This is particularly useful for specifying characteristics like quality-of-service (QoS) level, security support, performance requirements, etc.
3
SOA for devices
3.1 Device-level SOA interaction patterns The interaction patterns of a device-level SOA can be categorized according to six levels of functionality: Addressing, Discovery, Description, Control, Eventing and Presentation. Such device-level SOA interaction patterns are quite generic, i.e., applicable to a wide variety of application domains. Devices are categorized as either controlling devices or controlled devices, but a given device may embody both roles, thus enabling peerto-peer interactions. The foundation for device networking is addressing. Assuming the device network is based on IP, the addressing capacity is provided by the IP protocol, either IPv4 or IPv6. Once addressing is established, the next phase in device networking is discovery. When a device is added to the network, a discovery protocol enables a device to advertise its services on the network and perform a search for other devices and services. Next comes the description phase. Once a controlling device has discovered a controlled device, the former must retrieve a description (“metadata”) to learn more about the latter and its capabilities or to interact with it. Once devices know each other, a controlling device can exert control over a controlled device by invoking an action on a device's service. In addition, devices may communicate through asynchronous eventing, usually implemented by a "publish-subscribe" mechanism. Finally, a device may expose a presentation interface, typically an (X)HTML page that enables device control or status monitoring from a Web browser. 3.2 Device-level SOA using Web Services Several device-level SOA technologies have been proposed, most notably Jini [2] and UPnP (Universal Plug and Play) [5]. Jini is strongly rooted in Java and therefore lacks platform-neutrality and is ill-adapted to
usage in resource-restricted devices. Leveraging Internet and Web technologies including IP, TCP, UDP, HTTP, SOAP and XML, the UPnP architecture is platformagnostic, but it includes specific protocols for device discovery and eventing and uses a specific language for device and service description. The most promising approach seems to be that proposed by the Devices Profile for Web Services (DPWS) [7]. It combines the advantages of UPnP with full Web Services compatibility. DPWS is actually expected to form the foundation for the next major upgrade of UPnP (usually referred to as UPnP V2), but for reasons of market strategy related to the lack of backwards compatibility, no date is set for this transition. Web Services technology constitutes indeed the preferred implementation vehicle for service-oriented architectures. Web Services are totally platform-agnostic and can communicate with and/or be aggregated with other Web Services. Besides the standardization and wide availability of the Internet itself, Web Services are also enabled by the ubiquitous use of XML as a means of standardizing data formats and exchanging data. As more fully documented in [6] and [9], the core Web Services standards are the following. WSDL (Web Services Description Language) for the abstract description of service interfaces and their binding to transport protocols. XML Schema for the definition of the data formats used for constructing the messages addressed to and received from services. SOAP, the protocol for transporting service-related messages formatted in accordance with the corresponding WSDL definitions. SOAP plays a pivotal role due to its extensibility features that make the Web Services architecture highly composable, allowing for the various Web Service protocols to be integrated individually and incrementally, as well as to be improved and versioned in isolation, without affecting the rest of the protocol stack. WS-Addressing is closely associated to SOAP and concentrates all message addressing information into the header of the SOAP message envelope, thereby allowing the message content to be carried over any transport protocol (HTTP, SMTP, TCP, UDP, …). WS-Policy is used to express policies associated to a Web Service in the form of "policy assertions", complementing the WSDL description of the service. WS-MetadataExchange allows for dynamical retrieval of metadata associated to a Web Service (description, schema and policy), thus providing a Web Service introspection mechanism. WS-Security is an optional set of protocols and mechanisms for ensuring end-to-end message integrity, confidentiality and authentication. The DPWS protocol stack, depicted in fig 1, integrates all the above Web Services protocols. To the
above-mentioned Web Services core protocols, it adds Web Services protocols for discovery and eventing. WS-Discovery is a protocol for plug-and-play discovery of network-connected resources. Leveraging the SOAP/UDP binding, it defines a multicast protocol to search for and locate so-called target services. WS-Eventing defines a publish-subscribe event handling protocol allowing one Web Service ("event sink") to subscribe with another Web Service ("event source") in receiving event notification messages.
Application-specific protocols WS-Discovery
WS-Eventing
WS-Security WS-Policy WS-MetadataExchange WS-Addressing SOAP 1.2 WSDL 1.1, XML Schema HTTP 1.1
UDP
TCP IPv4/IPv6
Fig. 1 – Devices Profile for Web Services protocol stack
4
SOA for manufacturing devices
4.1 Tendencies favoring adoption of SOA The environment of future manufacturing enterprises will be characterized by frequently changing market demands, time-to-market pressure, continuously emerging new technologies and, above all, global competition. Therefore, next-generation manufacturing strategies must support global competitiveness, innovation and introduction of new products, and strong market responsiveness. Resultantly, if cost and quality remain vital concerns, manufacturing systems need to become more strongly time-driven and time-oriented. This evolution requires considerably more flexibility and adaptability to change than present-day manufacturing systems can afford. Currently, one third of the total cost of a manufacturing plant over its lifetime is spent on installation and set-up. Maintenance downtime accounts for another substantial portion of the operating costs. If a plant has to be adapted to new products by changing its process flow and introducing new or replacing obsolete or non-competitive equipment provided by different makers, then the downtime and installation costs rise considerably. The principal roadblocks are the inflexible
communication infrastructure among the manufacturing process components and the difficulty of porting existing application software to new configurations. Today, machine controls – programmable logic controller (PLC), motion control, regulators – are programmed separately to execute sequences of commands as function primitives. Communication between the individual controls is supported by a central system in a hierarchical network. This traditional design approach presents major deficiencies when used as a basis for an intelligent manufacturing control structure. An open, flexible and agile environment with plugand-play connectivity is desperately needed. Despite several proposals put forth by a variety of consortia and standards bodies to adopt open solutions for manufacturing plants, reality today still shows the dominance of proprietary standards that severely impede the progress towards flexibility and agility. As documented in [8], the fundamental requirements to be satisfied by the manufacturing plants and control systems of the future include the following: Intra-enterprise dynamic integration capabilities Cross-enterprise cooperation Support of heterogeneous yet interoperable hardware and software environments Agility through adaptability and reconfigurability Scalability by adding resources without disrupting operations Fault tolerance and graceful recovery from failures The issues at stake far exceed the technological challenge per se: in today's global economy, optimizing manufacturing processes is certainly more important than in the past to maintain productivity and competitiveness. In the manufacturing community, multi-agent and holonic systems have been the subject of great attention, but despite their promise, they have not made significant inroads in manufacturing plants yet. In addition to the lack of widely accepted standards, one of the reasons for this situation seems to be that implementations only cover part of the manufacturing landscape, whilst other areas remain subjected to proprietary standards, methods and mechanisms, resulting in a rigid patchwork of technology islands with poor scalability. 4.2 Benefits of using SOA Applying device-level SOA is expected to contribute to the creation of the open, flexible and agile environment referred to above, by extending the scope of the holonic architecture approach through the application of a unique communications infrastructure, down from the "shop floor" to the "top floor" (i.e. the manufacturing enterprise's high-level business process management systems). In turn, this evolution is enabled by the emergence of higher-performance microprocessors allowing the incorporation of ever more intelligence into ever tinier devices.
By achieving combined autonomy and interoperability, SOA allows to fulfill many of the above-mentioned needs of the manufacturing system of the future: Integration capability: services can be readily composed with other services, either statically or dynamically, so as to create higher-level services. Thus, devices can be integrated into higher-level subsystems, possibly at various architecture levels due to their self-reliance. A subsystem can itself be exposed as a device that can, in turn, be integrated into more complex (sub)systems. Legacy technology can be encapsulated through service façades, according to a "wrap-and-re-use" rather than a "ripand-replace" approach. Owing to the abstraction between service interface and service implementation, services can be materialized on heterogeneous software and hardware platforms. This opens an unprecedented perspective of being able to mix and match automation equipment from disparate vendors. Agility, flexibility and adaptability to change are greatly increased as services can be easily reconfigured or replaced, service deployment can be conducted incrementally and scaling can take place over time. Communicating entities can share and exchange resources and collaborate with each other through direct, peer-to-peer communication, i.e. without depending on the assistance and control of some higher-level entity. Decision-making can thus be driven down to the source of the information acted upon. This in turn enhances responsiveness and efficiency, while improving configurability. Development cost is reduced as re-use of services is facilitated and application programming is done at the highest possible level of abstraction. As each service encapsulates its own complexity, scalability becomes a built-in feature. By the same token, manageability and maintainability are greatly enhanced, especially as each device presents a highlevel management interface in order to facilitate configuration, monitoring, fault diagnosis, etc. Building fault-tolerant systems using a collection of self-reliant components is far less cumbersome than if using a set of tightly inter-related components. 4.3 Example usage of SOA This section more concretely illustrates some of the above benefits of SOA in the manufacturing device space through the description of an experimental setup using the SIRENA communication framework. Given the tendencies outlined above towards the adoption of high-level communication functionality in intelligent devices, the SIRENA project (ref. [1], [9]) has decided to adopt the DPWS as its foundation technology. The SIRENA vision is illustrated by fig. 2, showing a
subsystem made up of two SIRENA-enabled devices. In the industrial automation sector, application of the SIRENA framework will enable new forms of device networking, breaking away from traditional master-slave architectures. Adoption of a high-level, universal access interface enables connection of devices from different vendors, which is a great stride forward with respect to the status quo in the industrial sector. Physical interfaces
SubSub-system
Physical interfaces
Automatic discovery and startstart-up Direct interoperable communication
Device
Device
Web Service IPIP-based network Common universal access interface
Fig. 2 – The SIRENA vision in a nutshell Some of the anticipated benefits can be highlighted through a very simple but real-world example, the "dosemaker" device. Its role is to fill small bottles with granules flowing from a tank. It comprises a motor that causes the granules to leave the tank and a trap situated between the tank and the bottle to be filled; when the trap is opened, the granules can flow through. Sensors allow to determine when the trap is opened or closed, the tank is empty, the carter opened, etc. In order to fill a bottle, the dose-maker needs to open the trap, run the motor for a certain period of time, then close the trap. When SIRENA-enabled, the dose-maker device may be organized as in fig. 3. The dose-maker is a composite device made up of the following logical components: a "Smart Motor", exposing a service that includes an operation of the type 'RunMotor(duration)', and that asynchronously notifies the completion of this operation; a "Smart Trap", exposing a service that comprises operations like 'OpenTrap' and 'CloseTrap', and that sends asynchronous notifications when the trap is opened or closed, respectively; a "Dose-maker control" that orchestrates the operations of the Smart Trap and the Smart Motor, exposing itself a service that includes a command message of the type 'MakeDose(volume)', where 'volume' can be either "HALF" or "FULL", and that asynchronously notifies the completion of the dose making process. In turn, the Smart Motor and the Smart Trap are themselves composite devices constructed in a similar manner, as illustrated for the Smart Trap. The latter encompasses the actuator that actually controls the
physical mechanism for opening and closing the trap, as well as the sensors that determine the trap's actual state. This example illustrates how device-level services can be composed and aggregated into higher-level services, much in the way of "Russian dolls". Its principle is congruous to the holonic structuring paradigm: the Smart Trap is a holon in that it is both an autonomous entity (useable as such in devices other than dose-makers) and a subsumed part of a higher-level entity, viz. the Dosemaker.
Dose-maker
Dose-maker control
Smart Trap
Smart Motor
Smart Trap
Trap control
Trap sensor
Trap actuator
Fig. 3 – Dose-maker logical constituents The holonic structuring principle is greatly beneficial to scalability: hiding all the intricacies of dose-making and those of controlling a trap behind the high-level service interfaces of the Dose-maker and the Smart Trap, respectively, grants extensibility without interference with other system components. Scalability is further favored by the fact that event-driven communications are substantially more efficient than polling-based communications – in terms of both bandwidth usage and processing demands. By virtue of using DPWS, devices are able to automatically discover each other's presence. In simple cases, devices can thus start to communicate once connected. For example, if all logical entities in fig. 3 are implemented as separate devices, the Dose-maker device becomes operational as soon as it has recognized the presence of the Smart Motor and Smart Trap devices, which themselves have gone through a similar discovery phase. In more complex scenarios, e.g. with multiple devices of the same type, some initial configuration may be required. It is worth noting that the services exposed by the logical entities shown in fig. 3 – such as 'MakeDose', 'RunMotor' and 'OpenTrap' – are, in fact, business processes at the device level, in the same way that order
handling is a business process at the enterprise or plant level. As noted before, this is a major characteristic of SOA: a service is directly related to a business task. In the case of the Dose-maker device, the coordination of elementary (or "atomic") processes is fairly straightforward and may therefore be hand-crafted. In more complex, higher-order devices, it may be much more elaborate. A major opportunity created by using Web Services at the device level is to also use Web Services orchestration technology at the device level. The following chapter addresses this subject in greater detail.
5
Orchestration of manufacturing services
As introduced above, a typical feature of manufacturing systems is that several processes are composed and executed in given sequences in order to create complex processes of a higher order. This pattern is repeated at several levels: composition of field devices to create machines; composition of machines to create work cells and lines; composition of machine-level processes to create manufacturing systems and factories. Once processes are composed, a single interface encapsulating the complexity associated with atomic process coordination is desirable. The practice of sequencing and synchronized execution of services, which encapsulate business or manufacturing processes, is denominated orchestration. An orchestration engine implements the application logic necessary to orchestrate atomic services, and provides a high-level interface for the composed process. Thus, in the Smart Trap device of fig. 3, the Trap Control incorporates an engine for orchestrating the Trap sensor and Trap actuator and exposes the composite Smart Trap service. Similarly, the Dose-maker control incorporates an engine that orchestrates the Smart Trap and the Smart Motor, and exposes a single service for the composite device. A complementary concept to service orchestration is that of service choreography. The orchestration level is concerned with the workflow-oriented execution and sequencing of atomic processes, but does not take into account the different types of conversation patterns required to invoke the services associated with those atomic processes. The choreography level considers the rules that define the messages and interaction sequences that must occur in order to execute a given process through a particular service interface. The Smart Trap device may serve again to illustrate the choreography concept. In this case, a number of choreographies can exist between the Trap control and the Trap sensor. The controller might periodically read status information from the sensor, or the sensor might asynchronously notify the sensor status, either periodically or whenever a status change occurs. An acknowledgement message might follow a sensor status
message, but it will never precede it. The choreography defines the rules governing these interactions for a particular service implementation. Many different types of choreography can exist for different service interfaces implementing the same business process, e.g., same type of devices from different vendors. 5.1 Orchestration engines The composition and orchestration of Web Services has received significant attention over the past five years, especially from the Enterprise SOA community [10]. Within that domain, the predominant goal was to create complex processes by composing Web Services that are deployed throughout dispersed enterprises. Such type of orchestration envisions motivating scenarios such as simultaneously booking multi-stop flights on multiple airlines’ Web Services, renting a car, and booking a hotel room. This type of scenario introduces intricate orchestration requirements such as conditional branching of the workflow. In order to provide flexibility, a Web Service orchestration language can be used to describe workflows. These orchestration descriptions can be interpreted by engines that interpret the workflow, obviating the need for ad-hoc, hard-coded implementations. The SOA community has produced two competing specifications for Web Services orchestration. The Business Process Management Language (BPML) was the first mature specification available [11]. Although it contemplates any type of process, BPML leverages the Process Specification Language (PSL), developed by NIST as a neutral representation for manufacturing processes [12]. However, industry has almost unanimously adopted the BPEL4WS (Business Process Execution Language for Web Services, [13]), also known as WS-BPEL or BPEL for short. Initially created by merging IBM's WSFL and Microsoft's XLANG, WSBPEL is now being standardized by OASIS. It is a technology-neutral, XML-based language for expressing the interaction patterns of a collection of Web Services. It is supported by large companies like Microsoft, Sun, Oracle, SAP and BEA. Several WS-BPEL-compliant orchestration engines are currently available as commercial products and open source packages. A limitation of currently available orchestration engines is that they are intended for enterprise-level systems. These implementations run on top of an application server, and exhibit binary footprints in the order of 10 MB. For device-level service coordination, the orchestration engine must run on an embedded device with limited resources. Hence, a compact orchestration engine is required, but no such implementation is yet available. This work is therefore being considered for upcoming European projects, in particular, as an extension to SIRENA.
5.2 Choreography specifications When a Web Service is used to encapsulate a given process, countless different service implementations can be provided. The most distinctive feature of different implementations is the interaction sequence or conversational skills required in order to execute the associated process. An execution system that wishes to interact with the service, for example an orchestration engine, must be able to interpret the rules that define the required interaction choreography. In order to specify these rules, a choreography description language is required. In order to integrate choreography description, the WS-BPEL specification defines abstract processes, which are used together with the executable processes used for orchestration. For its part, BPML relies on the Web Services Choreography Interface (WSCI) [14]. However, the overlap between BPML and WSCI has sprouted much criticism, one of the factors influencing industry preference for WS-BPEL. In addition, the W3C chartered a specific work group to produce the Web Services Choreography Description Language (WS-CDL) [15]. The purpose of this specification is to provide a description language that is composable with other WS-* specifications, and that can be used by non-BPEL applications.
6
Agent-based self-orchestrating manufacturing systems
Web Services orchestration enhances the benefits introduced by SOA by composing and encapsulating complex processes into a single service interface. However, systems that are exclusively based on the "Russian dolls" orchestration model are inherently hierarchic and centralized, and therefore introduce some of the same shortcomings that centralized control architectures have experienced in the past. Additionally, orchestration and choreography description generators, for use in execution systems, currently need intensive human-tool interaction. The need for manual programming efforts, although significantly reduced compared to traditional PLC programming, and a purely centralized approach would jeopardize rapid reconfigurability. In order to cope with such challenges, the use of intelligent and distributed systems implementing peer-topeer interactions has long been proposed. Within this context, the orchestration and choreography functions of SOA and potential solutions for reconfigurability are contemplated in the following sections. 6.1 Reconfigurability challenges The increasing number of intelligent components and the dynamism introduced by reconfiguration will create manufacturing systems that, from an ICT perspective, are chaotic. From a communications topology viewpoint,
manufacturing systems will be organized as dynamic peer-to-peer infrastructures, autonomously restructuring in response to changes in the environment. From an information viewpoint, manufacturing systems will constantly modify their operational data and knowledge in response to real-time changes in schedule, goals, and decision criteria [16]. One of the greatest challenges foreseen for implementing intelligent industrial environments that are simultaneously complex, rapidly deployable, rapidly reconfigurable, dynamic, and chaotic, is to seamlessly integrate heterogeneous intelligent components rapidly and with no loss of functionality. The question to answer can be formulated as: how to get two devices with no previous knowledge on each other’s type, conceived using different paradigms and interaction models but still with complementary skill sets, to interact autonomously? The presented problem is expected to gain significance based on three current trends. Firstly, a homogeneous solution to manufacturing technology is unlikely to arise, given the wide variety of domains of application, of varying benefits of different approaches, and of vendors who seek to avoid commoditization of their solutions. Secondly, the variety of devices for manufacturing is likely to increase as more specialization fields arise. Thirdly, technological evolution and introduction of new tools will continuously add unknown elements to the existing technology base. Given these three trends, potential causes for the problem at hand include: the infeasibility of incorporating into a device sufficient knowledge on all other existing types of devices; the inflexibility to adapt to new types of devices that are introduced into a system, and that are unknown to existing devices.
leading to system self-orchestration and execution of complex manufacturing processes on demand. The Smart Trap example may again serve to illustrate the issues at hand. If the conversational skills of the Trap sensor are described semantically, the Trap controller can infer the invocations that must occur and the messages to be exchanged. Additionally, if the ontology of the Trap sensor is provided, the controller can reason about its skills and determine whether or not the device is the correct type of sensor for the Trap process. The ontology description of the sensor skills enables the controller to discover other types of Trap sensors supplied by other vendors, which are also suitable for the job but would not be immediately recognized as being of the correct type. Semantic matching is needed should different syntax or terms coexist. An established or standardized language for this type of explicit description of skills and semantics is needed. An essential requirement for this description language is that it be ubiquitously accepted, so a mature specification is needed. A further essential requirement is that the description language be suited for distributed environments, as semantic relationships are needed between knowledge on multiple components of the distributed industrial/factory environment. Within this domain, the Web Ontology Language (OWL) has emerged as a mature knowledge representation language for the Web [17]. Based on XML and the Resource Description Format (RDF), OWL can be used to provide Web Semantics mark-up to describe any resource anywhere on the Web, with the potential to truly create distributed repositories of machine-interpretable knowledge. Several different levels of semantics are supported. In particular, the OWL-DL subset implements the Description Logics formalism, which has been developed to describe elements and their semantic relationships.
6.2 Future knowledge-based manufacturing In order to overcome the aforementioned challenge, a new paradigm is needed in terms of how intelligent components represent and process knowledge about themselves, about other components, and about the environment. The mandate for this new paradigm is that knowledge be made explicit and be given machineinterpretable semantics. Through machine-based reasoning and inference, components previously unknown to each other can gain understanding about their respective skill sets, goals and interaction models, and therefore interact intelligently. The conversational skill set of the component is one fundamental part of this knowledge, and is used for interaction choreography purposes. The remaining necessary knowledge is the skill set for executing production processes, which is combined with complementary knowledge on goals and the environment
6.3 Semantic Web Services in manufacturing Given that Web Services can provide a suitable infrastructure for interactions and encapsulation of processes and skills and that OWL ontologies can provide the necessary machine-interpretable semantics, an approach that unifies these technologies is required. This task has been tackled by numerous research projects, which have converged to create the Semantic Web Services Initiative (SWSI) [18]. The converged efforts have resulted in the OWL-S service ontology, an OWL ontology that specifies the concept of a Web Service [19]. Web Services described by an OWL-S ontology become Semantic Web Services (SWS), which enable agents to reason using the explicit semantics to automatically discover, invoke, compose and monitor the associated processes. In effect, reasoning about SWS enables agents to interact with services that might have been previously unknown or disregarded.
Automatic discovery is accomplished by semantic matchmaking of a description of a required or sought process with available descriptions of SWS profiles. Because matchmaking is done using inference rather than one-to-one mappings, discovery can be performed based on skill sets rather than on device types. This approach enables finding non-trivial solutions such as new specialized devices with overlapping skill sets. Furthermore, enhanced semantic descriptions can facilitate selection among multiple candidate solutions by reasoning about Quality of Service (QoS) and Trust parameters. Automatic invocation is accomplished by interpreting the supported conversational semantics for discovered services. Consequently, agents can select the appropriate choreography for service interactions. Moreover, by understanding the sequence of steps required for executing a process, agents can monitor process status and execution progress in real time. Automatic composition is achieved by semantic matchmaking of atomic operations in a complex process workflow to the skills described in discovered service ontologies. Industrial agents can thus execute complex processes by composing individual processes, enabling autonomous manufacturing system orchestration. In this domain, Web Semantics enable the chain of reasoning to traverse several distributed ontologies in order to match post- and pre-conditions and compose services. Service composition enhances the automatic discovery functionality by enabling one-to-many matchmaking of requirements to complex processes, where one-to-one matchmaking fails to find adequate solutions.
7
Conclusion
The evolution of and the convergence between computing and networking technology, fuelled by advances in semiconductor and transmission technology, are bound to revolutionize the way communications are organized between systems and devices, in particular, embedded devices. Indeed, the emergence of increasingly powerful, network-connected devices will allow to drive the intelligence of computing and communications down to the device level, paving the way for new, higher-level communication paradigms supported by open Internet protocol standards. Homing in on this tendency, and leveraging the widespread adoption of service-oriented architectures using Web Services standards, enables novel device networking architectures and allows seamless integration of devicelevel and enterprise-level networks. It thus holds the promise of prolonging the paradigm of holonic manufacturing systems and creates an opportunity for pervasively applying high-level service orchestration and choreography techniques across the entire spectrum of industrial networks.
8
Acknowledgements
This work is partly supported by the SIRENA project [1] in the framework of the European R&D program ITEA [2], and by the IMPRONTA TEKES R&D project. Further benefits result from exchanges originating in the IEEE IES Technical Committee on Industrial Agents [3]. References [1] [2] [3] [2] [5] [6]
[7]
[8]
[9]
[10] [11] [12] [13] [14] [15] [16]
[17] [18] [19]
The SIRENA project: http://www.sirena-itea.org The ITEA initiative: http://www.itea-office.org IEEE IES Technical Committee on Industrial Agents. http://www.tcia.ipb.pt The Community Resource for Jini technology. http://www.jini.org The UPnP Forum. http://www.upnp.org An Introduction to the Web Services Architecture and its Specifications. http://msdn.microsoft.com/library/default.asp?url=/librar y/en-us/dnwebsrv/html/introWSA.asp Devices Profile for Web Services. http://msdn.microsoft.com/library/default.asp?url=/librar y/en-us/dnglobspec/html/devprof.asp, August 2004 W. Shen, D. Norrie, Agent-Based Systems for Intelligent Manufacturing: a State-of-the-Art Survey, International Journal on Knowledge and Information Systems, Vol.1(2), pp. 129-156, 1999. F. Jammes, H. Smit, Service-Oriented Paradigms in Industrial Automation, IEEE Transactions on Industrial Informatics, Vol.1(1), pp. 62-70, February 2005. C. Peltz, “Web Services Orchestration and Choreography”, IEEE Computer, Vol.36(10), pp. 46-52, October 2003. Business Process Management Language (BPML). http://www.bpmi.org/bpml-spec.htm Process Specification Language (PSL) http://www.mel.nist.gov/psl/ Business Process Execution Language for Web Services. ftp://www6.software.ibm.com/software/developer/library /ws-bpel.pdf, Version 1.1, May 2003 Web Service Choreography Interface (WSCI). http://www.w3.org/TR/wsci/ Web Service Choreography Description Language (WSCDL). http://www.w3.org/TR/ws-cdl-10/ Jose L. Martinez Lastra, “On Future Self-Orchestrating Manufacturing Systems”, Position paper for the FP7 Workshop on The Agile, Wireless Manufacturing Plant, Brussels, February 10th, 2005. M. Dean et al., “OWL Web Ontology Language 1.0 Reference,” W3C www.w3.org/TR/owl-ref, 2003 Semantic Web Services Initiative. http://www.swsi.org/ The OWL Services Coalition, “OWL-S: Semantic Markup for Web Services”, DAML-S Home Page http://www.daml.org/services/owl-s/, 2005.
