Service-Oriented Architecture for Distributed ... - Semantic Scholar

IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 2, NO. 4, NOVEMBER 2006

281

Service-Oriented Architecture for Distributed Publish/Subscribe Middleware in Electronics Production Ivan M. Delamer, Student Member, IEEE, and Jose L. Martinez Lastra, Member, IEEE

Abstract—The Computer Aided Manufacturing using XML (CAMX) framework enables integrating electronics production systems using message-oriented middleware, offering standards-based communication among machines and control software applications. CAMX frameworks implement publish/subscribe of XML messages through an entity called the message broker (MSB), which provides the messaging service using a web-based interface. A challenge for MSB-based systems is that they must scale to handle large volumes of messaging traffic, which is a characteristic of modern information-intensive manufacturing systems. This paper first tackles this challenge by presenting an array of architecture patterns for creating distributed MSB frameworks, focusing mainly on globally distributed federations and locally distributed clusters. A unified architecture is subsequently presented that leverages the different patterns by combining federated frameworks with locally distributed clusters into a unified set of architecture elements and interactions. A service-oriented approach is followed to provide a uniform interface for distributed MSB elements, whether federated or locally distributed. The service-oriented approach is also used to dynamically discover resources and automatically invoke the (re)configuration and messaging services. The services are enriched with semantics in order to facilitate automatic discovery and selection of services using the semantic web services formal ontology. Semantic service advertisements are propagated using a peer-to-peer discovery protocol. The approach presented in this paper is not limited to the CAMX case and is generally applicable to distributed event-based manufacturing systems. Index Terms—Electronic equipment manufacture, manufacturing automation, manufacturing automation software, message systems, service-oriented architecture.

I. INTRODUCTION

D

URING the late 1990s, the International Electronics Manufacturing Initiative (iNEMI) identified through its technology roadmapping activity a number of technology gaps in existing factory information and communication systems, specifically in the domain of middleware technologies required to integrate communicating machines and factory information systems [1]. This technology gap made the cost and time required to configure and ramp up new assembly lines excessively high, especially considering the short product life cycle

Manuscript received September 2, 2005; revised April 3, 2006; accepted June 8, 2006. This work was supported by TEKES—National Technology Agency of Finland—and participant companies: Nokia Mobile Phones, Perlos, FlexLink Automation, Cencorp, Metso Panelboard, and Photonium under the IMPRONTA applied research project. Paper no. TII-05-09-0047.R1. The authors are with the Institute of Production Engineering, Tampere University of Technology, FI-33101 Tampere, Finland (e-mail: [email protected]; [email protected]). Digital Object Identifier 10.1109/TII.2006.885188

and frequent new product introduction that are characteristic of the electronics manufacturing industry. Responding to this roadmap, joint research and development activities between leading industrial and academic organizations proposed an open-standards web-based framework for exchanging XML messages among communicating machines and software applications. The standardized XML messages are exchanged through standardized message-oriented middleware that implements an entity called the message broker (MSB). The standards are endorsed by IPC, Association Connecting Electronics Industries, and are referred to as the Computer Aided Manufacturing using XML (CAMX) framework [2]. As CAMX implementations evolve from pilots and prototypes to real systems operating in demanding factory environments, several implementation challenges have been identified [3]. One of these challenges is that the messaging frameworks based on MSB entities scale appropriately to handle large, information-intensive manufacturing systems with associated large volumes of real-time message exchange. A framework implemented by a single MSB server is not capable of efficiently supporting factory-wide communications for medium to large enterprises and must therefore be distributed among several MSB servers. Another challenge is to enable CAMX manufacturing systems to be machine-configurable, in order to automate system (re)configuration and avoid costly reprogramming during plant setup and maintenance. This paper addresses the aforementioned challenges by enhancing the current CAMX framework and implementing a service-oriented architecture (SOA) approach [4]. First, two alternative architecture patterns for making CAMX middleware distributed and thus provide scalability are considered. These two contrasting approaches are based on globally distributing or federating and on locally distributing or clustering middleware servers. Subsequently, a unified architecture that leverages the two patterns is considered. The unification of both patterns is facilitated by the use of a service-oriented approach to provide interoperability between different types of middleware nodes and to facilitate the discovery of middleware services. Finally, a peer-to-peer infrastructure for the propagation and discovery of services is presented. Service descriptions of production machines, automation software, and middleware resources are enriched with semantics using formal ontology, thus facilitating the service selection process. The rest of this paper is structured as follows. Section II reviews the historical evolution of CAMX and the resulting technology framework. Section III discusses the two fundamental strategies to distribute CAMX frameworks, based on

1551-3203/$20.00 © 2006 IEEE

282


federations of scattered MSB nodes and based on centralized clusters of MSB nodes. Section IV presents a unified architecture that leverages both strategies, enabled by the use of service-oriented architecture. Section V presents the peer-to-peer conversational infrastructure that is used to propagate service advertisements enriched with semantic content using semantic web services. Section VI discusses prototype implementation details of the proposed service-oriented architecture. Finally, Section VII summarizes this paper and presents some concluding remarks and future research directions. II. CAMX HISTORY AND TECHNOLOGY REVIEW CAMX refers to a set of standards that specify web-based communication protocols for the electronics production industry. The standardization activities for communications and data exchange interfaces were initiated by the iNEMI, formerly the National/North American Electronics Manufacturing Initiative [5]), an industry-led consortium of over 60 large electronics manufacturers and other organizations, and carried out by an ad hoc conglomerate of leading research institutions and industrial organizations. CAMX comprises the IPC-25xx family of standards, which are endorsed by IPC, Association Connecting Electronics Industries, an ANSI accredited standards body with membership of over 2000 companies and 1000 individuals [6]. A. CAMX History In 1996, the iNEMI roadmapping activity [1] revealed that factory information and communication systems were too expensive, hardly interoperable, required huge integration efforts, and did not provide enough visibility. Estimates showed that integrating equipment and factory information systems cost as much as 4 to 20 times the cost of the software itself. iNEMI subsequently launched the Plug&Play Factory Project in December 1997, with the goal to design, develop, and demonstrate a technical infrastructure to enable the deployment and replacement of both electronics assembly equipment and electronics assembly software in a fraction of the time and at a fraction of the cost normally associated with those activities. The resulting infrastructure is based on asynchronous XML message passing between equipment and software applications, accommodating for the required data complexity, and multivendor and multiplatform systems existing in factories [2]. The work initiated in the Plug&Play Factory Project was continued by several follow-up projects starting in 1999, which targeted at standardizing the syntax, content, and semantics of XML messages. These projects were mostly industry-led but coordinated by research organizations in Europe and the United States and are an ongoing effort to accommodate the most current requirements. The CAMX concept was initially demonstrated by pilots at Georgia Tech in the United States and Tampere University of Technology in Finland [7]. Followed by several pilots in industrial environments, CAMX is being used in production in several factories since 2004. During that year, Flexlink Automation Oy has deployed four assembly lines with 40+ interconnected CAMX machines and software applications [8], and the NACOM Corporation has reported savings of $400 000 for a $130 000 investment in CAMX [9]. During 2005, Flexlink Automation Oy was commissioned with the

Fig. 1. Example scenario of CAMX publish/subscribe messaging through a message broker.

integration of a further five manufacturing lines using CAMX technology, which was adopted as standard communication technology for their dynamic assembly system line of products [10]. B. CAMX Technology Framework CAMX defines an event-based conversational framework based on exchange of standardized XML messages through Ethernet networks. In order to share a common interface that can be supported by a wide range of manufacturing equipment, in vendor- and platform-independent fashion, the IPC-2501 standard defines the middleware specification used to exchange CAMX data [11]. The IPC-2501 standard is used to build the framework on which CAMX production systems are built. The framework makes use of a message-oriented middleware approach utilizing a central element, the MSB, for distribution of messages and leverages the SOAP [12] with attachments [13] specification for the formatting and syntax of messages. The MSB supports both publish/subscribe messaging for event distribution [14], as illustrated in Fig. 1, and point-to-point messaging for commands, request/responses, and service invocations. The standard syntax, content, and semantics of CAMX messages is defined in the IPC-25xx series of standards. In particular, the IPC-254x series of standards define unidirectional messages associated to shop-floor equipment events. The IPC255x series in turn defines messages for bidirectional communication between equipment and software applications, mostly used for supervisory control functions. Generic messages exist that are applicable to all equipment, including those for board assembly, for final assembly and packaging, and for testing, as well as specific messages for specific types of equipment, suck as pick-and-place machines, screen printers, reflow ovens, final assembly equipment, and so on. IPC/CAMX standards leverage the shortcomings of SECS/GEM and proprietary interfaces currently used in electronics production equipment. CAMX also considers domains of electronics productions other than manufacturing. Design of electronics products is facilitated by the IPC-251x series, known as GenCAM, that provide a standard format for computer-aided design (CAD)

DELAMER AND LASTRA: SERVICE-ORIENTED ARCHITECTURE FOR DISTRIBUTED PUBLISH/SUBSCRIBE MIDDLEWARE IN ELECTRONICS PRODUCTION

files. The new IPC-2581 standard leverages the GenCAM and ODB++ formats for a revised CAD file format, called OffSpring. The computer-aided manufacturing (CAM) domain is considered by the IPC-2531 standard, which specifies a file format for process recipes known as the standard recipe file format (SRFF), and leverages the work done by the Surface Mount Equipment Manufacturers Association (SMEMA) council of the IPC [15]. Finally, the supply-chain aspects are considered in the IPC-257x series of standards. These standards leverage the work done by RosettaNet and specify the supply-chain interactions that occur between electronics production factories. III. FUNDAMENTAL APPROACHES FOR DISTRIBUTED MESSAGE-ORIENTED MIDDLEWARE CAMX is intended to provide factory-wide communications for information-intensive manufacturing systems. Accordingly, the MSB system implementing the CAMX framework needs to scale to handle large volumes of data in real time. A framework implemented by a single MSB server is not capable of efficiently supporting factory-wide communications for medium to large enterprises. Therefore, it needs to be architected in a way that it can be distributed across multiple servers while maintaining the same service interface for equipment. Previous research has suggested two different approaches for implementing a distributed framework [3]. One approach proposes a federated infrastructure, with MSB nodes servicing localized domains and providing transparent interconnection between domains. The alternative approach proposes maintaining a centralized infrastructure but implemented by a cluster of locally distributed servers that increase the capacity of the centralized node. A. Topological Distribution of CAMX Messages There are two types of real-time CAMX messages at the factory floor: those related to process events and those related to control and commands. Process event messages are contemplated in the IPC-2541/6/7 standards and are typically exchanged using the publish/subscribe pattern. Control messages are contemplated in the IPC-2551/6/7 standards and are typically exchanged through point-to-point channels. CAMX process event messages always belong to a given manufacturing process and therefore are of interest to other machines, devices, and control software applications that participate in the same process. Such processes are typically implemented by a manufacturing structure such as an assembly cell or an assembly line. As a consequence, the majority of messages are typically exchanged within restricted sets of clients that share a process. A reduced number of events that bear increased significance are also propagated to higher enterprise levels for tasks such as line balancing, resource planning, scheduling, and preventive maintenance. CAMX control messages are typically exchanged between cell or line controllers with machines within that same cell or line. Only automation software applications such as line balancing applications exchange a smaller volume of control messages across different lines and cells.

283

The distribution of CAMX message traffic is therefore mostly clustered within logical production structures such as assembly cells and assembly lines, with a component of hierarchical traffic to higher level enterprise applications, and a small component of inter-cell or inter-line traffic. B. Federated Frameworks When following the federation-based approach for building distributed CAMX frameworks, each MSB node that is deployed services a local domain but is still interconnected with other federated nodes to enable communication between localities. This approach where messages are routed through several intermediate nodes, also called rendez-vous-based message distribution, has been analyzed and surveyed by Pietzuch and Bacon [16]. The federation-based approach is especially well suited for factories running several independent processes (e.g., several independent assembly lines), given that the majority of CAMX messages are typically exchanged locally. A local MSB node will efficiently service the messaging requirements of the local equipment and applications and will transparently exchange through other federated MSB nodes the smaller volume of messages destined for other localities. Servicing the majority of messaging volume locally eliminates large amounts of converging traffic at a centralized node, which can potentially incur in delays and increased network infrastructure costs, and also simplifies administration and configuration functions, whether performed by operators or autonomously. An architecture for federated CAMX frameworks was presented by the authors in [17]. Making use of this architecture, frameworks can easily scale in order to handle increased volumes by adding more nodes to the federation. The interactions between equipment and software applications with a local MSB node maintain the standard IPC-2501 service profile, so the federation is viewed from the client perspective as a single entity and is therefore interoperable with legacy MSB systems. This type of architecture transparency ensures that no changes are needed on the client-side of the interface, whether interacting with a single-server MSB or a federated framework. Moreover, the standard IPC-2501 client-to-MSB service interface is recursively used for MSB-to-MSB interactions in order to propagate messages through the federation, so both clients and federated MSB nodes are interoperable from the viewpoint of a given MSB node. C. Locally Distributed Frameworks The locally distributed cluster-based approach is extensively used in the domain of web servers in order to upgrade the capacity of websites when they need to handle increasing numbers of clients and access hits, as well as when increasing complexity of dynamic content and services offered. The goal of locally distributed web servers is to distribute the processing load among multiple server instances but still provide clients a single virtual interface. The most prominent architectures for locally distributed web servers have been surveyed by Cardellini et al. [18]. The most relevant concepts from the web server domain are briefly reviewed in the immediate subsection. Subsequently, an architecture that uses these concepts and has been adapted for the CAMX case is presented.

284


1) Relevant Practices in Locally Distributed Web Server Clusters: Locally distributed web servers are typically composed of a set of front-end servers performing presentation functions, middle-tier application servers for processing the business logic for dynamic content, and back-end database servers. Additionally, a switching mechanism is needed to route user requests to one of the front-end servers. A variety of routing mechanisms exist, and the choice of this mechanism has the biggest influence on the type of architecture that can be implemented. The three mechanisms that are most commonly found are DNS routing, layer-4 switch routing, and layer-7 switch routing. In DNS routing, a web server from the cluster is assigned to a web client at the beginning of a long-lived transaction, by providing an IP address of one of the front-end servers when resolving the URL of the website. The authoritative DNS resolution server for the website must be implemented within the cluster. The IP address returned to the client is typically accompanied by a time-to-live (TTL) value after which the IP address mapping expires and clients must re-resolve the server IP address, so the system can redistribute long-lived connections. The DNS routing mechanism was the first mechanism to be deployed on a large scale. It is simple to implement and needs no specialty hardware. It provides a very coarse mapping as all requests from a given client are mapped to the same server. In the case of very complex websites with dynamic content and multiple services distributed in separate servers, this approach is suboptimal. In layer-4 switch and layer-7 switch routing mechanisms, a dedicated hardware device is placed at the front of the cluster, routing every packet received to a selected front-end server for processing. Layer-4 switches are content blind, and their complexity lies in forwarding all IP packets for a given TCP session to the same web server. Layer-7 switches take the complexity a step further by routing according to the content of the transactions, such as different requested URLs or HTTP header content types. Therefore, different servers can specialize in a different type of content (e.g., static pages, dynamic content, encrypted connections, etc.). 2) Tier-3 Caching in CAMX Message Brokers: A CAMX message broker can be classified as a web server providing a dynamic web service, the IPC-2501 publish/subscribe messaging service, where each invocation needs some business logic processing and data storage/retrieval operations. As such, it could be implemented using the type of architectures previously described, utilizing a routing mechanism, replicated application servers, and a large back-end database. However, the particulars of the CAMX case enable designing an optimized architecture that takes full advantage on the knowledge available from the publish/subscribe domain configuration and the knowledge that can be inferred about the clients invoking the service. These advantages are, first, by routing all requests from a given client to the same server, the server can keep a cache of the message queue for the client and therefore reduce latencies caused by data retrieval from databases. Second, the topology characteristics can be exploited to group related clients to be serviced by a same server in order to reduce latencies caused by data storage to databases by keeping published messages in the local cache.

Fig. 2. Locally distributed MSB cluster using front-end router.

The use of message queue caches reduces the latencies in delivering a message to a client that are due to database retrieval times, a major component. Additionally, network traffic in the cluster LAN is significantly reduced, as is the loading of the database server. The only requirement for implementing a cache is that client requests are consistently routed to the same server; otherwise, the cache needs to be replicated and synchronized across the cluster, which would greatly increase the complexity and lose all benefits of caching. During the process of publishing messages, a copy of that message needs to be placed in the queue of each subscriber. If the messages are to be placed in a cached message queue, then a copy of the message needs to be sent from the server associated with the publisher to the server that is holding the cached queue associated with the subscriber. By analyzing the configuration of subscriptions, groups of clients that exchange messages among themselves can be serviced by a particular server in the cluster. These groups typically arise in CAMX scenarios and are formed by machines and software applications that share a process. By grouping these clients together, the interactions between servers in the cluster are reduced, reducing the load on the network as well as the processing overhead. 3) Architecture for Locally Distributed Cluster-Based CAMX Framework: In order to create scalable CAMX frameworks using locally distributed server systems, four types of elements are proposed in this paper. These are brokers, routers, routing policy optimizers, and broker address resolvers. These elements are described in the following paragraphs and are illustrated in Fig. 2. Broker elements are in charge of offering the IPC-2501 publish/subscribe service to CAMX machines and software applications. A broker will hold cached message queues for the set of clients it services and can optionally be connected to a back-end database for fault recovery capabilities. A broker will process published messages by placing copies in local cached queues, for serviced subscribers, and delivering copies to other broker


elements, for subscribers serviced by another node. If a client that was previously serviced by a given node invokes the service on another node, whether by own choice or by a change in distribution policy, the invoked broker will automatically acquire ownership of the message queue cache from the original node and service subsequent service requests. Broker elements are typically deployed on a dedicated application server. Router elements are in charge of dispatching client service requests to the appropriate broker element servicing the invoking client, using a one-to-one correspondence. If a layer-4 switch approach is followed, then the invoking client is identified by its IP address and subsequently dispatched to the associated server. If a layer-7 switch is used, the XML field in the SOAP request header that identifies the client is parsed, so that the associated server can be determined. XML switches that can perform this functionality are already available in the market [19], [20]. If a web-switch approach is used, then the presence of one router element deployed on a dedicated hardware platform is mandatory. As an alternative to the web-switch approach, which requires the inclusion of expensive dedicated hardware, an approach that assimilates concepts from DNS routing can be employed. In this case, when a client attempts to discover the CAMX framework service through the broker address resolver element, described later, the address of the corresponding broker is given, together with a time-to-live expiration parameter. The client will therefore directly invoke the assigned broker element, without passing through a web switch. The expiration parameter is implemented so that the system can react to changes in routing policy. When this approach is followed, the router is deployed in the same system resource than the broker address resolver. Routing policy optimizer elements are in charge of determining the optimal configuration of client to broker assignments. The optimization process considers the settings of the publish/subscribe domain configuration, in order to determine which clients should be grouped together. The optimizer also considers the capacity of different broker elements and the frequency for the different published messages. This can be achieved either by using known typical values or by monitoring activity in the brokers. The optimization algorithm has been implemented using a multiobjective evolutionary algorithm, which is comprehensively documented in [21]. The optimized policy is continuously updated to the router element as required. Broker address resolver elements are used by clients to discover a CAMX framework. This function can be offered as a web service or can be performed manually by a system administrator during system set up. If the router uses a web-switch approach, the resolved address is the address of the switch itself. Otherwise, the address of a matching broker element is to be resolved utilizing the latest policy determined by the optimizer. 4) Recommended Implementation Strategy: When comparing the domain of application of traditional web servers, for which relevant practices in cluster-based web servers were reviewed in Section III-C1, with the domain of application of CAMX frameworks, there are several significant differences that influence the decisions for adopting one of the available implementation strategies. Web servers typically service a varying, unpredictable population of users. The changes in the serviced population are manifested in millisecond range.

285

Fig. 3. Locally distributed MSB cluster with assimilated routing, optimization, and address resolution functions.

In CAMX systems, the population of clients is composed of production equipment and software applications and therefore changes infrequently, and a reconfiguration response time of seconds to a few minutes can be considered acceptable. This scenario in which connections are long-lived has traditionally been successfully implemented in the web server domain using DNS routing, discussed in Section III-C1. Considering this precedent, the recommended approach to implementing the proposed architecture is to assimilate the routing functions to the address resolver functions, eliminating the need for costly front-end XML routers. The response of the system to changes is then dominated by the time-to-live settings of the MSB address resolution response, which can be set to a few minutes without significant performance impact. This approach has the added value of tight coupling of the routing functions to the policy optimizer, simplifying the structure of the system. The optimized architecture is illustrated in Fig. 3. The proposed architecture is suited when the traffic load is distributed among several producing and consuming clients. The approach fails when there is either one client producing the majority of messages or one client consuming the majority of messages (e.g., a monolithic line controller). In such cases, the overhead incurred in inter-broker communication within the cluster exceeds the processing requirements for having a single node, i.e., the distributed approach offers worse performance than a system that is implemented by a single node. This case is not only challenging for the proposed architecture but also for the message broker pattern itself. If such a scenario were to arise, it is recommended that the dominating client assimilates the MSB functionality. D. Embedded Frameworks The permanent increase in computational power of embedded and PC-based controls is enabling the introduction of additional functionality implemented in the controllers themselves. One of the new potential capabilities is embedding MSB nodes in equipment with sufficient computational resources, which would reduce the load of MSB nodes that are deployed

286


TABLE I SUMMARY OF ARCHITECTURE PATTERNS FOR DISTRIBUTED CAMX MIDDLEWARE

on dedicated servers by distributing it among the machines themselves. If sufficient MSB nodes can be embedded, the need for introducing supplementary web servers into a manufacturing system in order to provide the messaging framework is eliminated. Moreover, when the number of MSB nodes of the distributed framework approaches (or matches) the number of clients, most nodes need to service only one client (themselves) and can therefore easily be embedded into that client. However, embedding the MSB business logic might become too expensive in computational resources for some embedded systems with limited capabilities. Moreover, a device that previously only interacted with an MSB node might need to interact with several other devices, increasing the requirements on computationally expensive XML parsing and network operations. Taking into account the current state of the art in embedded computing, embedded MSB nodes should only be considered for implementation in high-end equipment with powerful embedded CPUs and in high-end PC-based workstations running CAMX software applications such as MES software. E. Comparative Analysis of Distributed Framework Patterns The different architectural patterns for implementing distributed MSB frameworks are summarized in Table I, together with their strengths and limitations. For small systems ( messages/second), a traditional single-server approach is still well suited. Larger systems that are composed of several independent assembly lines can be efficiently serviced by federation-type frameworks. If there are large concentrations of messages in a single assembly line or in higher enterprise levels where messages from multiple lines are concentrated, a cluster-type framework can resolve the potential bottlenecks. If small structures are present such as assembly cells composed of a few machines and a PC-based cell controller, the cell controller can implement an embedded MSB node and efficiently service the local set of machines.

IV. UNIFIED SERVICE-ORIENTED ARCHITECTURE FOR DISTRIBUTED MESSAGE-ORIENTED MIDDLEWARE The different architecture patterns described in the previous section need not be merely alternative solutions but can complement each other. For instance, a locally distributed cluster can be used to increase the capacity of a federated node. However, this approach as it stands today still requires the use of two different software architectures: one for implementing the federated framework and one for implementing high-capacity nodes based on clusters. It is desirable to develop a unified architecture for dynamically self-reconfigurable CAMX messaging frameworks, where physically/logically distant MSB nodes are automatically incorporated to the framework as federated nodes, and MSB nodes in physical/logical proximity dynamically join or compose a locally distributed cluster. Under close scrutiny, the proposed architecture for locally distributed, cluster-based CAMX frameworks bears significant resemblance to federated frameworks, since each locally distributed broker element services a relatively static set of clients that is similar to the static set of clients in a federated locality. This resemblance suggests that a unified architecture that uses the same type of basic elements, and that is applicable to both federating message brokers and to creating locally distributed clusters, can be achieved. The advantages for having a unified architecture are manifested as simplifications of both design and implementation and as improved flexibility and agility at run time. Having a single architecture simplifies the development of systems because a reduced set of element types needs to be developed and integrated. At run time, the ease of scaling up the framework is enhanced by deploying the same type of elements for adding messaging resources as needed, whether dynamically adding localities to a federation or dynamically adding to (or forming) a locally distributed cluster.


287

Fig. 4. UML sequence diagram illustrating the Standard IPC-2501 Publish/Subscribe service provided by the message broker.

Fig. 5. UML sequence diagram illustrating the recursive use of the IPC-2501 publish sequence for inter-domain message routing.

A. Converged Service Interfaces The most significant commonalities between the two architectures to be unified are the type of interactions between elements, more than the rationale for those elements. Federated or locally distributed systems, or a combination of both, can equally be achieved by maintaining the set of service interfaces previously proposed for federated frameworks, namely, IPC2501 Publish/Subscribe service, configuration service, and resolver service. All broker nodes in the CAMX framework implement the IPC-2501 Publish/Subscribe messaging service, which is the service dictated by the CAMX standard to provide messaging capabilities (see Fig. 4). The service interface is the same whether implemented by a locally distributed node, a federated node, or a single MSB system, thus providing architecture transparency to clients. Additionally, all broker nodes use the same IPC-2501 service interface recursively to propagate messages to other broker nodes, whether within a locally distributed cluster or a federated framework indistinctively, as illustrated in Fig. 5. The configuration service is typically implemented by all nodes that also implement the messaging service, enabling

clients to autonomously change settings in their publishing capabilities and subscription interests. This service is also recursively used by the service providers to propagate configuration changes through the distributed framework, indistinctively for locally distributed nodes or federated nodes. The resolver service is implemented by at least one node in every locality and provides the client with an address for a messaging service implementation and a configuration service implementation. In the case of purely federated frameworks, the resolver service always returns the address of the broker node servicing the locality. In the case of a locally distributed system servicing a locality, the resolver service incorporates the cluster routing functions and, utilizing the policy created by the optimization algorithm, resolves the address of the matching broker node for the client. B. Analysis The proposed approach is a generalized approach for distributed CAMX frameworks, where there is no difference in the type of interactions for either locally distributed or federated frameworks. This is possible by utilizing service-oriented

288


Fig. 6. Production system based on distributed CAMX framework. The framework has been federated to create two localities, each serviced by a locally distributed cluster of dedicated and embedded MSB nodes.

architecture to encapsulate the functionality of distributed brokers and keeping identical service interfaces for different elements, which possibly implement similar but nonetheless differing business logic. The only remaining difference between locally distributed and federated frameworks is that locally distributed systems can have a tighter coupling and improved capacity and responsiveness. An example distributed framework is illustrated in Fig. 6. Given that the same type of broker elements is used for federations and local clusters, the decision of whether to include a new broker node as a federated node or as part of a locally distributed system can be made based on the concept of logical and physical proximity. Elements that are contained within a same local area network (LAN) are in physical proximity and are eligible to form a locally distributed cluster. Likewise, elements that share a manufacturing process and therefore exchange the majority of information among themselves are in logical proximity and are therefore eligible to be serviced within a same locality, possibly forming a locally distributed cluster. Elements that are at physical or logical distance are candidates to form a federated locality. An embedded MSB node in a distributed CAMX framework can be considered as any other MSB node deployed on a dedicated server. If located in proximity to other nodes, it can join a locally distributed cluster; otherwise, it can become a federated node. The concepts of purely federated or purely locally distributed frameworks can be considered as two special cases of the generalized approach. If a single locality is considered, then the framework is a purely locally distributed system. If there are several localities that are efficiently serviced by single broker nodes, then the framework is a purely federated system. The proposed approach enables deploying messaging service providers in order to dynamically add or increase framework capacity where it is needed, whether for integrating a new subsystem or for expanding an existing subsystem.

V. PEER-TO-PEER INFRASTRUCTURE FOR SERVICE ADVERTISEMENT PROPAGATION One of the cornerstones for any service-oriented architecture is the mechanism by which advertisements for services are published by service providers and subsequently located by service requestors [23]. In order to support the discovery of the middleware services provided by the distributed CAMX framework described in the previous section, as well as to support the discovery of machines, control applications, and other factory components, a service discovery protocol is required. This section will present a service discovery protocol that is based on peer-to-peer interactions and therefore does not require a centralized service registry [24]. The service advertisements are enriched with semantic content by building on portions of the semantic web services upper ontology [25], facilitating the selection of semantically interoperable services through the use of hierarchically classified service types. A. Semantic Web Services Basics In order to publish service advertisements, a service description format must be adopted. When using web services, the de facto standard is the web service description language (WSDL) specification [26]. However, WSDL files contain no information on the semantics of the described operations. It is up to the programmer or engineer to interpret the semantics from available descriptions in natural language. This type of interpretation becomes a challenge because the human factor inhibits automation of service discovery, selection, invocation, and composition. Only the set of services that has been pre-programmed can be used by a service requestor. As a consequence, other services that are semantically similar or equivalent need to be manually programmed into the requestor. Additionally, natural language descriptions are informal and can lead to different interpretations or even to failure to understand. This challenge can be overcome if formal and declarative semantic markup is used to complement service descriptions [23]. This task has been tackled by numerous research projects,


which have converged to create the semantic web services initiative (SWSI) [27]. The converged efforts have resulted in the OWL-S service ontology, an OWL ontology that specifies the concept of a web service [25]. Web services described by an OWL-S ontology become semantic web services (SWS), which enable reasoning over the explicit semantics to automatically discover, invoke, compose, and monitor the associated processes [23]. SWSs are described by a service profile, which specifies the type of the service, a process model, which defines the input and output messages and invocation sequences in case of complex/composed services, and a service grounding, which specifies the syntax of messages and the invocation address. The OWL-S ontology makes use of the description logics (DL) formalism in order to classify service types defined in the service profile as concept hierarchies or terminologies [28]. By describing services types using formal and declarative semantic markup, a DL inference engine can automatically place new service descriptions at the correct place in the concept hierarchy. Likewise, by describing service instances using formal and declarative semantic markup, a DL inference engine can also infer whether a particular service implementation is an instance of a given service type. B. Requirements The objective considered hereafter is to develop a protocol for dynamically discovering SWSs. The following design goals are considered. • The protocol must be sufficiently lightweight to be implemented in embedded devices with limited memory and processing power. • The protocol should be designed to operate in peer-to-peer topology and should not rely on centralized registries or directories. • Peers should exchange information related to SWS implementation advertisements that include service types, protocol binding information, implementing peers, resolved invocation addresses, and scope information. • The service advertisements exchanged by peers should also include known or inferred hierarchic relationships to other service types, in order to facilitate the selection of semantically interoperable services. • The service advertisements propagated by peers should enable constructing a local acquaintance network that represents partially or fully the manufacturing system. • The protocol should enable responsive behavior to the liveness of services, so that information on newly available or recently unavailable services is propagated through the system in a time frame of a few seconds. • The protocol should be implemented with asynchronous SOAP messaging, adhering to web services standard practices. The protocol is intended for deployment in factory environments. Considering this type of environment, the following key assumptions are made. • Peers are well behaved. • Even though the system must be quick in order to rapidly reconfigure respond to changes, these changes are sporadic and might occur with a period measured in hours or days in steady-state behavior.

289

C. Service Discovery Protocol Considering the design goals, a peer-to-peer protocol for the discovery of SWSs was implemented. Peers propagate information on available services through asynchronous query and response messages. Query messages target the discovery of services: in specific scopes, of specific types, or resident in specific peers. The semantics of query and response messages resemble the FIPA Query and FIPA Inform Communicative Acts [29]. The description data of particular service endpoints leverage the WS-addressing specification [30]. The WS-discovery protocol [31] was also leveraged as bootstrapping mechanism to discover an initial set of peers that implement the discovery protocol. 1) Discovery Interaction Protocols: The interaction protocol consists of three types of query XML messages and two types of response XML messages. The first type of query message resembles the FIPA Query Ref message and is used to query for any peers that implement a given namespace-qualified service type. The second type of query message also resembles the FIPA Query Ref and is used to query for all the service types that a given peer implements. The third type of query message resembles the FIPA Query If and is used to query whether a given peer implements a given service type. The first type of response message resembles the FIPA Inform Ref message and is used to respond to the two Query Ref messages. The second type of response message resembles the FIPA Inform If message and is used to respond to Query If type of messages. The Inform Ref messages contain information on one or more peers. These peers might be other than the responding peer, so peers can share information they have on other peers. For each peer included in the message, the following data are included: • peer name as a unique resource identifier (URI); • URI for an OWL-S ontology [25] that describes the peer; • list of implemented service types, each of which is described by • namespace-qualified service type name; • invocation address for the endpoint; • invocation protocol; • list of semantically interoperable service types (namespace-qualified); • liveness information, which represents the responding peer’s belief on whether the described peer is operational or down. The XML syntax used to reference service endpoints leverages the WS-addressing specification [30]. A key feature of the exchanged data on implemented services is the list of semantically interoperable services. These are services that have different namespace-qualified service type names and can even have different invocation morphology and syntax but that implement the same process at the semantic level [32]; i.e., there is an overlap in the semantic domain of the functionality implemented by the two services. The information of semantic interoperability is complemented by an interoperability-type attribute. This attribute can take three values: “explicit” is used to signal that the two services are semantically equivalent and provide the same interface syntax; “implicit-direct” is used to signal that one service is a subclass of the other;

290


therefore, OO-style substitution can be applied with direct invocation (no changes in syntax); and “implicit-translate” is used to signal that the services are semantically equivalent but use different syntax and therefore require ontology translation by a specialized mediator service as described in [33] and [34]. Semantic interoperability of services can be determined by reasoning agents that process SWS OWL-S ontologies. The agents implement inference engines that are able to process the service descriptions based on description logics [28]. The ontologies of discovered SWSs implemented by peers are dynamically incorporated into the agent’s knowledge base and classified accordingly. The agent can then respond to queries from peers and include inferred semantic interoperability information. The semantic interoperability information exchanged by the discovery protocol is intended to be rich enough to alert peers on different yet interoperable services and to be simple enough to be implemented by embedded devices with limited processing power. Peers that learn about semantically equivalent services can store this information in memory and propagate it by responding queries from other peers, without implementing semantic reasoning or inference engines. It is sufficient that a few peers are able to reason at the ontology level in order to infer semantic interoperability of services, and this information will be memorized and propagated by peers that are not able to reason. In the protocol specification, the exchange of Query and Inform messages is entirely asynchronous, and no mandatory interaction pattern is imposed. Rather, peers must interpret Inform messages independently of the Query messages sent out, without considering Query/Inform pairs as conversational units. It is expected that in most cases, peers will correspond a Query with an Inform. However, unexpected situations might impede this, so asynchronism guarantees fault tolerance at the protocol level. In addition, the lack of mandatory interaction patterns enables implementing different types of behaviors, such as talkative peers that spontaneously Inform others on service information or even cognitive peers that can anticipate the needs of other peers and advance Inform messages. The XML schema, WSDL, and OWL-S documents that specify the discovery protocol are available from [35]. 2) Bootstrap for Discovering the Discovery Service: Given that the discovery protocol for SWSs is itself implemented as a web service, a bootstrapping mechanism needs to be implemented for the discovery of peers that implement the discovery protocol itself. It is sufficient that a given peer discover a single other peer in order to bootstrap the discovery mechanism. After that, the peer can build its acquaintance network through the peers he discovers through the bootstrapping peer. In its simplest form, the bootstrapping peer could be manually configured to be a known peer that is assured to be always online at a fixed address. The adopted mechanism to bootstrap discovery is to use the web services dynamic discovery (WS-Discovery) specification [31]. This specification is based on sending Hello and Bye messages to a multicast address whenever a service, in this case the discovery protocol, comes online or goes offline. Similarly, peers can send Probe multicast messages searching for a given service type, and matching services respond with a ProbeMatch message. The scoping mechanism of WS-dis-

covery was adapted to probe and match CAMX federation localities. The WS-discovery mechanism provides the advantage that no hard coded configuration such as the location of a known peer at a fixed address is needed, and that it is resilient to temporarily unavailable services. Also, it is simple enough to discover service types that are well known and not likely to change, such as the discovery protocol. However, it does not support SWSs, hence the need for the discovery protocol described above. 3) Discovery Sequence Example: Fig. 7 illustrates an example interaction sequence for the dynamic discovery of SWSs implemented by multiple peers. In the first step, Peer A sends a WS-discovery multicast probe message in order to discover any available peers in the network. Immediately, Peer B responds directly to Peer A with a ProbeMatch message, so that Peer A knows about its existence. Once that Peer A knows Peer B, it no longer requires WS-discovery, and further interactions occur using the SWS discovery protocol. Peer A now sends a Query Ref message to Peer B, searching for an implementation of a service of type XYZ. Peer B responds with an Inform message asserting that Peer C implements a service of type XYZ. Subsequently, Peer A invokes the XYZ service from Peer C. Once that Peer C is in the list of peers known by Peer A, which is Peer A’s acquaintance network, and can also interact using the discovery protocol. sends a Query Ref message to searching for an implementation of a service of type PQR. responds with an Inform message asserting that Peer D implements a service of type PQR. Subsequently, invokes the PQR service from Peer D. In an alternative situation, might respond with an Inform message stating that implements service type RST, which is semantically interoperable with type PQR but is syntactically different and needs translation. Then, invokes the known PQR service from a mediator, and the mediator translates and invokes the RST service from . VI. PROTOTYPE IMPLEMENTATIONS A set of trial implementations was carried out in order to validate the proposed service-oriented architecture. First, the proposed services for the unified messaging architecture and for the discovery mechanism were implemented. In addition, a set of software modules was implemented in order to manage and invoke the available services. A. Distributed Messaging Infrastructure The proposed architecture for distributed CAMX middleware was implemented as a set of extensions to a commercially available CAMX MSB, originally developed by the authors and currently developed and marketed by Nematron Corp. [36]. The services proposed in the unified architecture were implemented into the available MSB package. In addition, a module was implemented in order to manage the interconnections between MSB nodes and the routing of messages. 1) CAMX Framework Services: Three services that are made available to CAMX machines and factory information systems needed to be implemented into MSB nodes, according to the


291

Fig. 7. Example sequence diagram for the semantic web service discovery protocol.

proposed unified architecture. The messaging service used for publishing and receiving messages required no extensions to the existing software package, as it uses the standard CAMX interface. The messaging service is used by clients that are sending and receiving messages and is also used by MSB nodes to propagate messages from one node to another. The configuration service was implemented by creating a bridge between the configuration messages received from clients and the existing manual configuration console used by MSB administrators. The configuration messages were linked to the existing actions for adding and removing clients, published messages, and subscription interests. When a change is recorded, the updated domain configuration, which is a standard CAMX message for representing data about all clients in a CAMX domain and their messaging configuration, is delivered to the other MSB nodes using the messaging service. The resolver service was implemented utilizing an evolutionary algorithm for the optimization of the network topology. The design and implementation of the algorithm is reported in [21]. Additional trials and simulations of the topology optimization service for a scenario consisting of 138 CAMX machines and complemented by 20 CAMX factory information systems is reported in [22]. 2) Message Routing Manager: An extension module, called the message routing manager, needed to be implemented into the existing software package in order to manage the connections between MSB nodes, the clients assigned to each MSB node, and the routing of messages through multiple MSB nodes. The message routing manager keeps a list of other available MSB nodes, which are either introduced manually or through the use of the discovery protocol. Every given remote MSB node is associated with an instance of the messaging service, called

the next-hop messaging service, through which messages that are destined to the given MSB node are delivered. The next-hop messaging service may correspond to the implementation referenced MSB node itself or may correspond to another remote MSB node that is used as an intermediary, when one or more intermediate hops are needed to route the messages. The next-hop messaging service is currently introduced manually in the prototype implementation but could be extended with existing protocols such as distance-vector or link-state routing protocols to acquire this information autonomously. The message routing manager also maintains a list of the CAMX clients that are serviced locally, i.e., the clients that send and receive messages utilizing the messaging service provided by the local MSB node. Messages that are received by the MSB node and that should be delivered to local clients are kept in local message queues, which are implemented without any modification to the existing software package. However, messages that are destined to clients serviced by remote MSB nodes are forwarded utilizing the configured next-hop messaging service. MSB nodes periodically announce the list of clients that are serviced locally to other known MSB nodes. Due to the topology optimization process of the resolver service, clients can dynamically change from one MSB node to another. When a client is reassigned by the resolver service, it will immediately stop invoking the formerly assigned MSB node and start using the messaging service provided by the newly assigned MSB node. The client is therefore added to the local client list of the new MSB node, which is announced to all other nodes. When the former MSB node detects that another node has acquired the client, it forwards all the messages held in the local queue to the new MSB node through the next-hop messaging service and then relinquishes the local queue.

292


Fig. 8. Functional overview of the acquaintance manager.

B. Service Discovery Infrastructure The discovery protocol was implemented as a reusable component in the Java 2 Micro Edition CLDC language and was deployed in a Java-enabled Industrial Embedded Controller, the Nematron PTC5800 [36]. This section reports challenges and solutions for implementing the WS-discovery protocol, necessary for the bootstrapping mechanism, and also reports the developed Acquaintance Network Management Module, which manages the information acquired through the discovery protocol. 1) WS-Discovery Implementation: One challenge that had to be overcome when implementing the WS-discovery protocol for the bootstrapping mechanism was to support IP multicast in embedded controllers with limited capabilities. In order to support multicast, the IP stack needs to implement a set of IGMP control messages to request IP routers to forward multicast traffic for a particular address. These messages were not implemented in the embedded controller due to limited memory. However, the WS-discovery protocol is able to operate properly using IP multicast without IGMP given the following two conditions. • There is at least one IGMP-implementing node in the subnet, such as a PC-based controller, which uses the WS-discovery multicast address. • The Ethernet switches must treat multicast traffic as broadcast traffic (i.e., forward multicast packets to all ports). This is the default behavior for the great majority of commercial Ethernet switches. An alternative approach is to use IP broadcast. This, however, presents other challenges, such as dependency on subnet mask configurations, limited scope of use, and also that many IP stack implementations will forward broadcast data to both open unicast and broadcast UDP sockets simultaneously, creating duplicate received messages. 2) Acquaintance Manager: The goal of the Acquaintance Network Management Module is to construct and maintain a table of discovered services implemented by known peers. This function is performed by generating appropriate query

messages and by processing incoming inform messages. In addition, the acquaintance manager processes incoming query messages from other peers and produces inform responses based on the knowledge contained on the acquaintances tables. The main components of the manager are illustrated in Fig. 8. The key function in the manager module is the query dispatcher. According to the functionality of the CAMX machine that is running the discovery protocol, it will search for other CAMX machines and CAMX software applications that match two criteria: • implement required service types, which encapsulate manufacturing activities that are part of the same process as the machine searching for services; • are within the scope of the CAMX machine searching for services (i.e., in the same assembly line). The query dispatcher analyses the peer information repository in order to construct and maintain a partial model of the system that includes the machines and devices that implement required assembly processes and that are within physical/logical scope. Accordingly, it produces query messages in order to obtain or update missing information. VII. CONCLUSIONS AND FUTURE DIRECTIONS The IPC/CAMX standards define a conversational framework in which electronics manufacturing equipment and related software applications can interoperate seamlessly, in a platformand vendor-independent fashion. In this paper, the authors considered enhancing the CAMX middleware to enable distributed messaging frameworks and self-configuration. A unified architecture that encompasses both federation-type and cluster-type topologies was presented. Using this architecture, the capacity of the messaging frameworks can be scaled up as needed by adding additional middleware resources that are automatically assimilated by the existing framework. A service-oriented approach was adopted in order to facilitate the autonomous (re)configuration of the middleware layer resources according to application layer semantics. SWSs were


used in order to enrich service descriptions with semantics and facilitate automatic discovery, automatic selection, and automatic invocation of resources. A peer-to-peer protocol was introduced in order to propagate semantic service descriptions. While the motivation and use case for the middleware architecture described in this paper has been scoped to CAMX electronics manufacturing systems, it is generally applicable to event-based middleware and service-oriented architectures in networked manufacturing systems. Future research directions involve extending the utilization of the SWSs ontology, which in this paper was limited to the use of the hierarchical service profile taxonomies. It is expected that the current architecture will be enhanced with services for classifying new service types and with services for mediation and translation of semantically equivalent messages that are implemented with incompatible syntax. Finally, it is expected that service descriptions will be enhanced using the process model ontology, which will enable agents to orchestrate multiple services and to infer the required invocation choreography of unknown services. ACKNOWLEDGMENT The authors would like to thank the anonymous reviewers for their valuable comments and suggestions. REFERENCES [1] “Roadmap for board assembly,” in NEMI Technology Roadmaps 1996 Edition. Herndon: INEMI, Dec. 1996. [2] A. Dugenske, A. Fraser, T. Nguyen, and R. Voitus, “The national electronics manufacturing initiative (NEMI) plug and play factory project,” Int. J. Comput. Integ. Manufact., vol. 13, no. 3, pp. 225–244, 2000. [3] I. M. Delamer, J. L. M. Lastra, and R. Tuokko, “Ubiquitous communication systems for the electronics production industry: Extending the CAMX framework,” in Proc. 2nd IEEE Int. Conf. Industrial Informatics, Berlin, Germany, Jun. 24–26, 2004. [4] F. Jammes and H. Smit, “Service-oriented paradigms in industrial automation,” IEEE Trans. Ind. Informat., vol. 1, no. 1, pp. 62–70, Feb. 2005. [5] International Electronics Manufacturing Initiative, Mar. 2006. [Online]. Available: http://www.inemi.org. [6] IPC—Association Connecting Electronics Industries, Mar. 2006. [Online]. Available: http://www.ipc.org. [7] N. Siltala, R. Tuokko, J. L. M. Lastra, and H. Ronkainen, “Advances in information system integration in final assembly and packaging,” in Proc. Automation Days, R. Tuokko, Ed., Helsinki, Finland, Sep. 9–11, 2003. [8] J. L. Martinez Lastra, O. Karhumäki, K. Karppinen, I. M. Delamer, and R. Tuokko, “Concurrent deployment of flexible production systems for final assembly,” Int. J. Agile Manuf., vol. 9, no. 1, pp. 53–58, 2006. [9] IPC Workshop on CAMX Use and Strategy for Electronics Assembly. Griffin, GA: NACOM, Oct. 20–21, 2004. [10] M. Sjöstrand, Ed., “Profitable production logistics solutions,” in Flexlink News. Goteborg, Sweden: Flexlink, 2005, no. 43. [11] Definition for Web-Based Exchange of XML Data, IPC-2501, Jul. 2003. [12] D. Box, D. Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H. F. Nielsen, S. Thatte, and D. Winer, “Simple Object Access Protocol (SOAP) 1.1,” W3C Note, May 08, 2000. [Online]. Available: http:// www.w3.org/TR/2000/NOTE-SOAP-20000508. [13] J. J. Barton, A. Thatte, and H. F. Nielsen, “SOAP messages with attachments,” W3C Note, , Dec. 11, 2000. [Online]. Available: http:// www.w3.org/TR/2000/NOTE-SOAP-attachments-20001211. [14] P. T. Eugster, P. A. Felber, R. Guerraoui, and A.-M. Kermarrec, “The many faces of publish/subscribe,” ACM Comput. Surv., vol. 35, no. 2, pp. 114–131, Jun. 2003. [15] Surface Mount Equipment Manufacturers Association, SMEMA Standards, Mar. 2006. [Online]. Available: http://www.smema.org/smemastandards.htm.

293

[16] P. R. Pietzuch and J. M. Bacon, “Hermes: A distributed event-based middleware architecture,” in Proc. 22nd Int. Conf. Distributed Computing Systems Workshops, Jul. 2–5, 2002. [17] I. M. Delamer, J. L. M. Lastra, and R. Tuokko, “Extending the CAMX middleware architecture for reconfigurability using services and enabling distributed deployment,” in Proc. IASTED Int. Conf. Parallel Distributed Computing Networks, Innsbruck, Austria, Feb. 15–17, 2005. [18] V. Cardellini, E. Casalicchio, M. Colajanni, and P. S. Yu, “The state of the art in locally distributed web-server systems,” ACM Comput. Surveys, vol. 34, no. 2, pp. 263–311, Jun. 2002. [19] Sarvega Inc., Mar. 2006. [Online]. Available: http://www.sarvega.com. [20] Datapower Technology Inc., Mar. 2006. [Online]. Available: http:// www.datapower.com. [21] I. M. Delamer and J. L. M. Lastra, “Evolutionary multi-objective optimization of QoS-aware publish/subscribe middleware in electronics production,” Int. J. Eng. Appl. Artif. Intell., vol. 19, no. 6, pp. 593–607, 2006. [22] I. M. Delamer, J. L. M. Lastra, and O. Perez, “An evolutionary algorithm for optimization of XML publish/subscribe middleware in electronics production,” in Proc. IEEE Int. Conf. Robotics Automation, Orlando, FL, May 15–19, 2006. [23] J. L. M. Lastra and I. M. Delamer, “Semantic web services in factory automation: Fundamental insights and research roadmap,” IEEE Trans. Ind. Informat., vol. 2, no. 1, pp. 1–11, Feb. 2006. [24] C. Schmidt and M. Parashar, “A peer-to-peer approach to web service discovery,” World Wide Web: Internet Web Inf. Syst. J., vol. 7, no. 2, pp. 211–229, Jun. 2004. [25] OWL-S: Semantic Markup for Web Services, The OWL Services Coalition, DAML-S, 2005. [Online]. Available: http://www.daml.org/services/owl-s. [26] Web Services Description Language (WSDL) Version 1.1, Sep. 2005. [Online]. Available: http://www.w3.org/TR/wsdl. [27] Semantic Web Services Initiative. [Online]. Available: http://www. swsi.org. [28] F. Baader and W. Nutt, “Basic description logics,” in Description Logic Handbook, F. Baader, D. Calvanese, D. McGuinness, D. Nardi, and P. Patel-Schneider, Eds. Cambridge, U.K.: Cambridge Univ. Press, 2002, pp. 349–372. [29] “FIPA communicative act library specification,” in FIPA Standard 00037. Geneva, Switzerland: Foundation for Intelligent Physical Agents, 2002. [30] D. Box, “Web services addressing (WS-addressing),” in W3C Member Submission, Aug. 10, 2004. [Online]. Available: http://www.w3.org/ Submission/ws-addressing. [31] Web Services Dynamic Discovery (WS-Discovery) Specification, Sep. 2005. [Online]. Available: http://msdn.microsoft.com/ws/2004/10/wsdiscovery. [32] A. W. Colombo, F. Jammes, H. Smit, R. Harrison, J. L. M. Lastra, and I. M. Delamer, “Service-oriented architectures for collaborative automation,” in Proc. 31st Annu. Conf. IEEE Ind. Electron. Soc., Raleigh, NC, Nov. 6–10, 2005. [33] M. Obitko and V. Marik, “Integrating transportation ontologies,” in Proc. 2nd Int. Conf. Applications Holonic Multi-Agent Systems, Copenhagen, Denmark, Aug. 22–24, 2005. [34] M. H. Burnstein, “Dynamic invocation of semantic web services that use unfamiliar ontologies,” IEEE Intell. Syst., vol. 19, no. 4, pp. 67–73, Jul.–Aug. 2004. [35] [Online]. Available: http://www.pe.tut.fi/impronta/xml. Mar. 2006 [36] Nematron Corp., Mar. 2006. [Online]. Available: http://www.nematron.com.

Ivan M. Delamer (S’04) received the Ingeniero Electrónico degree (with Diploma and Medal of Honor) from the Instituto Tecnológico de Buenos Aires, Buenos Aires, Argentina, in 2003. He is currently pursuing the Dr.Tech. degree in automation engineering at the Tampere University of Technology, Tampere, Finland. He is with the Institute of Production Engineering, Tampere University of Technology, as a Research Scientist. Previously, he carried out research at the Manufacturing Research Center of the Georgia Institute of Technology, Atlanta. His main research interests are in web-based technologies, semantic web services, and networked embedded devices, applied to the field of factory automation.

294


Jose L. Martinez Lastra (M’00) received the Ingeniero Técnico Industrial degree (with Honors) in electrical engineering from the Universidad de Cantabria, ETS de Ingenieros Industriales y de Telecomunicación, Cantabria, Spain, and the M.Sc. degree (with Distinction) and the Dr.Tech. degree (with Commendation) in automation engineering from the Tampere University of Technology, Tampere, Finland. He joined the Institute of Production Engineering, Tampere University of Technology, in 1999 and became a Full Professor of factory automation in 2006. Previously, he carried out research at the Departamento de Ingeniería Eléctrica y Energética, Santander, Spain, the Institute of Hydraulics and Automation, Tampere, Finland,

and the Mechatronics Research Laboratory, Massachusetts Institute of Technology, Cambridge. He has published over 100 original papers in international journals and conference proceedings. His main research interest is in the application of information and communication technologies in the field of factory automation. Prof. Lastra is a member of the IEEE Industrial Electronics Society, the Finnish Robotics Society, the Open Modular Architecture Control (OMAC) User Group, the OPC, and IPC organizations. Since 2003, he has been a member of the Board of Directors of OOONEIDA Inc. (Canada). He is also an active member of the IEEE-IES Technical Committee on Industrial Agents, serving as Chair for the Intelligent Components and Systems Architecture Subcommittee.