Integration of Semantic Web Services and ... - Semantic Scholar

4 downloads 120 Views 306KB Size Report
Keywords—Industrial / Building Automation, Web Services,. Ontologies, OWL-S. ... between industrial heterogeneous environments, hosting various dissimilar ...
Integration of Semantic Web Services and Ontologies into the Industrial and Building Automation Layer Konstantinos J. Charatsis*, Athanasios P. Kalogeras†, Manos Georgoudakis* and Professor George Papadopoulos* *

University of Patras /Department of Electrical and Computer Engineer, Patra, Greece † Industrial Systems Institute, Patra, Greece

Abstract—Industrial and Building Automation Environments feature great heterogeneity, implementing a large number of cooperating devices and applications originating from different vendors. Pioneer designs founded on open technologies, emerging in Industrial, Information and Computer Technology can provide key solutions to the above. Conceptually, the Semantic Web technologies’ cluster constitutes an ultimate tool in designer hands, enabling the development of interoperable and flexible middleware applications, resolving above issues in the automation field. Web Services, empowered with Ontologies and other related technologies, are gaining dominant position in the above domain, promising seamless integration in the automation field. Keywords—Industrial / Building Automation, Web Services, Ontologies, OWL-S.

I. INTRODUCTION A. Backround Technologies and applications in industrial and building automation sector constitute an attractive research domain. In the recent past, many technologies have been explored and adopted in numerous applications development. Authors delves, for some years, have been focused on the design of a platform operating as a web gateway, facilitating multi-directional communication and transfer of industrial data to the exterior environment of an enterprise. Predominant technologies were initially employed for the accomplishment of pioneer and qualified designs, applied to automation systems in both industrial and building environments. Relevant technologies used were automation networking technologies such as Object Link and Embed (OLE) for Process Control (OPC), LonWorks and ProfiBus, and middleware technologies managing communication and data exchange between objects such as the Common Object Request Broker Architecture (CORBA) [1], the Distributed Component Object Model (DCOM) [2] and the JAVA Remote Method Invocation (JAVA RMI) [3]. Efforts, focused in the seamless integration of the above to a real time monitoring and control application platform [4-5]. The complexity of the above directed towards the adoption of more “light” and open middleware and message oriented technologies, such as XML, SOAP, and

Web Services [6]. Finally, greater flexibility and reusability of systems was added by integration of two emerging technologies: Ontologies and Workflows. Resultant system architectures integrating the above technologies render to a fundamental platform design for e-services provision to industrial and building automation sector [7]. B.

Research Challenges Designing systems for industrial and building automation systems, complying with their continuously evolutionary course, presets technological challenges to researchers. Interoperability Installed automation systems comprise a plethora of devices, such as smart appliances, sensors, actuators, controllers (PLCs) and network controllers. Above devices, implement dissimilar operational and communication code, thus obstructing flow of information within the automation devices level and overlaying levels of an industry automation stack. Flexibility Enterprises are integrating numerous industrial / building devices and systems that implement various network technologies. From the engineering perspective, such implementations lack significantly in terms of flexibility and reusability, since the process applications are tightly connected to the actual enterprise infrastructure at a given instance of time. Configuration Since their initial installation, industrial automation systems perform various re-configurations and multiple module update cycles are taking place. Automated configuration and remote management are needed concepts, allowing for easy maintenance and updating / enhancement of an enterprise system. Systems in the automation field must be open for extensions by additional modules and interoperable with additional devices of arbitrary manufacturers. General architecture models of such systems must be characterized by their flexibility, openness and vendor-independence. C.

Semantic Web and Web Services Semantic Web and its technologies offer a new approach to managing information and applications, where creation and use of semantic metadata is fundamental. Semantic Web envisages the ability of creating and capturing knowledge in machine understandable format, developing agent grids that can integrate that knowledge, reason about it, and forward

results both to humans and other agents. Semantic Web is a cluster of technologies, techniques, protocols and processes, whilst a significant piece of this puzzle are Web Services [8]. Service provisioning platforms, used either in industrial or IT environments, implement Web Services (WSs) oriented architectures, in order to maintain their flexibility and openness, and be highly interoperable with services distributed in the World Wide Web. WSs seem to be the future ubiquitous middleware solution for high interoperable distributed software network environments. Service oriented computing is becoming the predominant factor in current IT and Industrial application development. Web Services are a key component of the emerging, loosely coupled, Web based computing architectures. WSs are autonomous, standards based components, whose public interfaces are defined and described using XML. Systems may interact with Web Service in a manner prescribed by its definition, using XML based messages conveyed by Internet protocols. W3C WSs specifications offer a communication bridge between industrial heterogeneous environments, hosting various dissimilar applications. Future applications require this “bridging” ability to perform complicated, peer-topeer collaborations between participating automation units, within or across trusted domains of an enterprise. The specification aims at the composition of interoperable collaborations between any type of participant, regardless of the supporting platform or programming model used by the implementation of the hosting environment. The multi-participant contract that describes this composition is technically described as a “Choreography Description”, and uses the Web Services Choreography Description Language (WS-CDL) as a means to describe this contract [8]. II. BACKROUND AND RELATED WORK A. Research Work The work presented in this paper is the outcome of extensive research on technologies supporting Service Oriented Architectures (SOA) in the industry and building automation domain. More specifically, it presents the development of an open services platform, designed for the aggregation and provision of bundled Web Services in the above domain. The platform design turned out after a broad study of emerging and dominant technologies in the automation and computational fields. In order to ensure openness of the platform, the whole approach was based both on prevailing technologies and emerging standards. This was mandatory for the integration and interoperability of all the systems / applications that participate in the automation domain, independently of their level. Elements of the architectural approach are presented in the following sections, describing the platform’s applications that utilize the technologies of Web Services, Ontologies and related technologies being integrated in the industrial and building automation network systems, making available their functionalities.

B. Related Work The OSGi Alliance introduced the Open Services Gateway Initiative (OSGi) [10] specification, defining a component oriented execution environment for Java applications, running on networked devices. A networked device with an implemented OSGi Service Platform, embedded as well as servers, gives the ability to manage the life cycle of its software components from anywhere in the network. The core of OSGi is a framework that manages the life cycle of bundles, as well as providing important common services. Bundles can be installed, updated, or removed without stopping the platform. Bundles can share code by exporting and importing packages and use functionality by other bundles at runtime through a service registry. Both libraries and bundles are software components, implemented in a standard Java ARchive (JAR) file, and can provide servlets, which become available over the HTTP protocol. OSGi bundles can extend from standard component interfaces like HTTP servers, configuration, logging, security, user administration, XML, to APIs that can interface networked enabled devices such us UPnP, LonWorks, X-10, CEBus and HomePlug. The OSGi specifications allow multiple, Java based, components to dynamically discover and efficiently use other components, in a single Java Virtual Machine (JVM). A similar concept on services provisioning, focused on home care services, is presented in the MATCH project [12]. The MATCH approach can be seen in the context of home network architectures. The work on smart houses tends to concentrate on home automation (e.g. appliances, entertainment and security). Its approach is vendorneutral, device independent and focused on service provision. For this project the OSGi platform has been selected as an industry recognized approach to service provision. The PABADIS'PROMISE [13] project extends the idea of distributed control to an innovative architecture, which incorporates both resource and product. The project develops a new control architecture, based on distributed intelligence, and a manufacturing ontology of a new generation field control devices, and building blocks for a new generation of Enterprise Resource Planning (ERP) systems. New functions and interfaces are developed, enabling direct access from ERP level to the automation field systems following the project’s ontology, which provides a framework for product and production process description and comparison [14]. C. Domain’s Relative Technologies Services on an automation network must be available to everyone who can reach them, and this must be done in a safe and robust way. Discovering services in OSGi is limited to finding an implementation of a given service. LDAP (Lightweight Directory Access Protocol) can be used to discriminate among multiple implementations. However, standard OSGi approach to service discovery uses simple key/value property pairs, registered with the framework, along with the service implementation. This method restricts the description to the service implementation, i.e. its technical characteristics. Furthermore, ambiguities may arise due to inconsistency in concepts.

The Jini technology is a simple infrastructure for providing services in a network of devices, and creating spontaneous interactions between programs that use these services [15-16]. A Jini system can be thought as a collection of services that can be used for the performance of particular tasks. A lookup service maintains a flat collection of service items and provides a set of methods to enable exploration of the collection. Each service represents an instance of a service available within the networked devices. A variety of user interfaces can be built by using these methods, allowing users and administrators to browse. From the service client’s point of view, there is no distinction between same services offered by different similar devices. The Jini architecture does not define specific attributes to distinguish between services. The Universal Description, Discovery and Integration (UDDI) specifications define a way to publish and discover information about WSs. In UDDI specs the term “Web Service” is thought of as describing specific business functionality, exposed by a company (or a software application), usually through an Internet connection, for the purpose of providing a way for another company (or software program) to use the service. The UDDI specification is a set of rules that tells XML Web Services and their clients how to look for each other. The UDDI rules are simply XML [17] schemas that define how discovery messages should be formatted. There are elements to describe the business’s name, the type of service it offers, and the names and URLs of those services, along with blobs of other information. Web Services and the initiatives that support its foundations SOAP [24], WSDL [17] and XML have added a new level of functionality to the current Web, making the approach towards seamless integration of distributed components. Work in the area of Semantic Web [18] is being applied to Web Services in order to keep the intervention of the human user to the minimum. In contrast to former distributed computing technologies that lacked in terms of interoperability, ease of use and deployment, WSs’ technology benefits due to the fulfillment of the peer to peer communication, using standard XML messaging scheme. Semantic markup can be exploited to automate the tasks of discovering services, executing them, composing them and enabling seamless interoperation between them, thus enabling intelligent Web Services. The description of WSs in a machine-understandable fashion is expected to have a great impact in the area of enterprise application integration, as it can enable dynamic and scalable cooperation between dissimilar systems and organizations. OWL-S is a major initiative that must be considered in this context. OWL-S [18] is a definition of an ontology semantic markup of Web Services to enable automation of WSs discovery, invocation, composition, interoperation and execution monitoring by providing appropriate semantic descriptions of services. OWL-S part of the DAML [20] program aims at providing building blocks for encoding rich semantic service descriptions, in a way that builds naturally upon OWL. OWL-S ontologies provide a vocabulary that can be used to create service descriptions and is meant to support both categories of simple and complex services. OWL-S is expected to enable:

• Automatic Web Service discovery, involving the automatic location of WSs that provide a particular service and that adhere to requested constraints • Automatic WS invocation, involving the automatic execution of an identified WS by a computer program or agent. Execution of a WS can be though of as a collection of function calls • Automatic WS composition and interoperation, involving automatic selection, composition and interoperation of WS to perform some task, given a high level description of an objective • Automatic WS execution monitoring Processes, relevant to industrial and building automation, need efficient management, in order to have full control of generated layers’ process data. Workflows maintain the technology that enables this management, being automatically coordinated and controlled. A workflow actually is a form of automation process processed by Workflow Management System (WFMS). A workflow represents a model of the automation process that comprises all the necessary and essential information in order to implement it. Such information includes: number of steps, steps order, data assignment, devices (appliances, PLCs) designation, etc. In a more abstract sense, workflow systems tie together the three fundamental aspects of an automation system: automation processes, Web Service provision and Information Technology (IT). Broad acceptance of WSs due to their ease of deployment and the increase in the degree of interoperability that they result in, as well as their widespread support by vendors, made workflows technology the best choice for application integration within and across enterprise automation systems. The combination of such an interoperable system, based on the WS technology, and workflows is challenging. Several efforts were made in order to define Web Services workflow standards. These rendered to WSFL (Web Services Flow Languages) [21], XLANG [22] and BPEL4WS (Business Process Execution Language for Web Services) [23]. III. THE PROPOSED ARCHITECTURE The architecture proposed in our system consist a platform for the provision of Web Services in an Enterprise and Building automation environment. Automation processes usually comprise a number of actions associated with numerous functional blocks or modules ranging from the automation level up to the service provision layer. Such systems are in need of interoperability between applications and had led to a transition from vendor dependent systems to more open ones, utilizing middleware internet technologies and infrastructure. The proposed architecture in this paper builds upon this general trend, presuming that industrial and building automation infrastructure is compliant with semantic web predominant technologies and systems / applications expose their functionalities using WSs technology. The presented architecture introduces a further step towards interoperability regarding the semantics of the involved applications / systems.

Fundamental idea of the presented platform is that an automation process can be represented as a sequence of different application / system function calls. The platform implements a set of application modules that utilize respective SOAP clients (servers), each of which acts as a proxy, in order to access (be accessed by) the particular functionality of an appliance, a device or an automation subsystem residing at the underlying layer. Each device pertaining in the automation layer is included to the systems ontology. The device ontology maintains process semantic information depicting in terms of classes and instances, the roles, tasks and the exchange of parameter data of each automation device. In order to use an ontology that can be interpreted unambiguously and used by software agents, a syntax and description language is needed. OWL being a vocabulary extension of RDF provides a language that can be used to describe these device classes and relations between them. The device ontology defines a separate class for the description of each device and its properties, while each physical device corresponds to an instance of its respective class.

Fig. 1. The proposed Architecture

Furthermore, each module is service oriented, meaning that for each provided service a corresponding module with an OWL-S interface and Service Profile exists and maps to specific WSs of the automation layer. An OWL-S Profile describes a service as a function of three basic types of information: what organization / module / device provide the service, what functions the service computes and a host of features that specify characteristics of the service. In the automation layer processes are implementing a sequel of actions that relegates to the idea of a workflow associated with the automation functional calls. Workflow, in our proposed system, renders an abstraction of the enterprise process. It comprises a sequence of logic steps (known as tasks or activities), dependencies among tasks, authorization rules, and system users. In a workflow, tasks can represent an activity configured by the system user or from a software unit. Most workflow standards support sub-processes, which allow tasks within a workflow to be implemented as another workflow. A

workflow can be thought of two complementary parts: the control flow and the data flow. Control flow defines the sequencing of different activities in the process. Data flow defines how information flows between activities. A workflow describing an automation process established either in an enterprise or a building system, actually prerequisites a means for expressing an automated control procedure in a standardized way. Given an automation process workflow, it is required that its tasks are associated with the diverse application / system services that must be called during the execution of the workflow, so that its incorporated procedure logic is successfully applied. In our work, we emphasized in the association of a workflow task with Web Services available in the automation infrastructure. This association is mandatory in order the prescribed system to work efficiently. Nevertheless, binding a specific workflow to a specific automation system and its WSs is static. Viewing it from the system engineering perspective, the system lacks significantly in terms of (re)configuration flexibility and reusability, since the process workflow is tightly connected to the actual time instance of the automation infrastructure. Thus, workflows would need significant redesign whenever changes in the automation infrastructure would take place. A solution for the above issues that increases interoperability and utilization of semantic information relevant to automation processes is introduced, by means of semantic industrial process expression and introduction of its relevant ontology. Ontologies consolidated as a means to represent knowledge. In our presented work, we propose the use of ontology semantics to describe automation layer device characteristics, system functionalities, and Web Services relative to process of the system. Implementing the above solution actually introduces an intermediate layer between workflows and the automation layer. Thus automation processes workflows instead of using the actual automation devices that implement its functionality, use the Ontologie description terms of devices and their WSs. The introduction of a full ontological representation leads to: • A flexible description of an automation process by means of both its ontology and workflow • A significant increase of automation process interoperability, since workflows need to be altered only whenever associated process logic is changed. Therefore, potential device or systems alterations influence is significantly reduced, improving system’s reconfiguration time and flexibility. The implementation of the above architecture involves the following functional elements: The Ontology – Web Service Association Tool that provides the ontology semantic knowledge of automation layer devices description and their implemented Web Services. OWL and OWL-S ontology files describe in terms of classes and instances, devices (properties, hardware inputs and outputs, software functional modules), WSs (Service Profiles) and Service Modules (attributes, services’ inputs and outputs and process preconditions). Output of this tool is XML formatted files, using RDF vocabulary and contain / describe all associations of classes and instances of attached

ontologies. An association of the ontological information and available WSs during the design phase is mandatory. Thus, this tool provides an efficient mechanism, enabling processes of an application to discover and bind easily WSs of the automation process and associate them with the underlying automation devices. The Workflow Design Tool enabling the expression of the automation processes in terms of workflows. This element needs to communicate with the Ontology – Web Service Association Tool in order to get all relative automation process semantic information from the associated ontology files. Outputs of the element are workflows documents in BPEL4WS format. This document will be the input to the Workflow Execution Engine, at run time in order to make workflow execution possible. The Workflow Execution Engine that is responsible for the implementation of the automation process logic by executing the associated workflow. This element comprises the system responsible for two main actions: the execution of the automation Web Services according to their association to each individual workflow step, and the monitor of the progress of the automation process workflow execution. During the automation process run time, each respective workflow is retrieved from a workflow repository. Each workflow presents an autonomous functional procedure of the whole automation process. For all workflow tasks the engine calls in sequence the appropriate WSs using the SOAP protocol for the interconnection of the industrial / building automation applications / systems. Each time a WS is called the corresponding process of the relevant automation application / system is executed, while outputs and process status results are given as a feedback to the execution engine, which proceeds to the next task until the whole process is complete. IV. USE CASE SCENARIO An example use case depicting the proposed architecture is described below. Main goal of the architecture is the integration of systems / applications that exist in the automation environment making use of their semantic description. Our scenario being a light version of an automation process, involves a number of devices, control systems and applications constituting a lighting application. An abstract of the use case scenario ontology can be seen in Fig.2 which is a screenshot of Protégé [25], while the Functional Profile of an Echelon Occupancy Controller as described in the respective OWL file can be seen in Fig.3. Our example focuses on how an energy saving process could use our model in order to provide its energy management service efficiently to a building. A. Scenario Description This scenario involves an energy management service that provides interactively its service to a Building Management System (BMS). Interactive functionality lies in the fact that the service can both monitor and control the energy consumption of the building. In order to maintain the description compact, we provide an overview of a simplified control process that needs to be executed when the overall consumption of lighting devices must be controlled.

Whenever a need for control is decided by the process, a relevant request is forwarded to all controlled devices. This request must utilize automation layer device information. More specifically, the process will acquire from the automation layer the current devices state and will calculate the overall energy consumption of the building. Based on the current state and taking into account the building energy audit and all related parameters, the energy process can estimate the potential reduction that may be asked from the automation layer. Calls are performed to respective WSs by the workflow Execution Engine claiming function configuration of specific automation level devices.

Fig. 2. Protégé Screenshot

The energy saving logic of the automation process determines the consumption scenario that should be followed and activates the respective workflow application from the workflow repository. The workflow will establish communication with the automation layer in order, to perform needed configuration to devices and controllers. This scenario clearly requires the involvement of different devices being employed by the building automation infrastructure, and their integration so that interoperability and flexibility of the overall process is achieved. B. Process Design Phase In order for the above scenario to be implemented over the proposed architecture some prerequisites concerning the needed infrastructure must be fulfilled. First of all, the need of a common communication infrastructure is obvious, in order different applications / systems to interoperate on it. This infrastructure must be based on standard protocols and open applications / systems using the Semantic Web technologies. During the design phase of the energy management process, its scenario logic has to be analyzed by means of ontologies and a workflow. Ontologies will provide all the semantic information concerning description of devices, inputs, outputs and service profiles.

For each predesigned workflow the Ontology – Web Service Association Tool associates it with the specific WSs, found in ontology description files. The resulting BPEL4WS workflow description file contains all the necessary information that is relevant to the workflow as well as the real actions required to be taken by each of the participating building automation system / application during the energy management process execution phase. The process execution is based on the Workflow Execution Engine, which uses the workflow BPEL4WS description to call the adequate WSs from the different automation devices of the building. In this context the overall building environment is successfully integrated independently of what devices may reside in. This integration introduces a high degree of interoperability and flexibility and allows the process to effectively employ its energy management strategy without any concern of underlying software and hardware.

REFERENCES [1] [2]

[3] [4]

[5]

[6]

[7]

[8]

[9] [10] [11]

[12] [13] [14]

[15] [16] [17] Fig. 3. Occupancy Controller Ontology Description

V. CONCLUSIONS The work presented in this paper, proposed an architecture that enables interoperability of the applications / systems residing in the automation level of an industry / building infrastructure. This architecture mixes and matches three predominant technologies, namely workflows, ontologies and Web Services. The proposed architecture provides an approach for the design of processes execution, maintaining underlying automation layer is opaque to the designer. The latter is capable to design using exclusively ontology description files. The ontology files determine both the necessary semantics related to the automation process and the automation’s layer device descriptions. A set of proposed tools, using prevailing standards and technologies, make possible the implementation of the above architecture. Finally, a building automation process example has been showcased.

[18]

[19] [20] [21] [22] [23]

[24]

[25]

Object Management Group home page [online]. Available WWW Microsoft Corporation. Distributed Component Object Model Protocol, [online]. Available WWW Sun Microsystems Inc. Java Remote Method Invocation, [online]. Available WWW V. Kapsalis, A. Kalogeras, K. Charatsis, G. Papadopoulos, “Seamless Integration of Distributed Real Time Monitoring and Control Applications Utilising Emerging Technologies”, December 2001 V. Kapsalis, K. Charatsis, A. Kalogeras, G. Papadopoulos, “Web Gateway: A Platform for Industry Services over Internet”, July 2002 V. Kapsalis, K. Charatsis, M. Georgoudakis, E. Nikoloutsos, G. Papadopoulos, "A SOAP-based system for the provision of eservices", April 2004 K. Charatsis, A. Kalogeras, M. Georgoudakis, J. Gialelis, G. Papadopoulos, "Home / Building Automation Environment Architecture Enabling Interoperability, Flexibility and Reusability", June 2005 “Semantic Web Technologies, trends and research in ontologybased systems”, by John Davies, Rudi Studer, Paul Warren, WILLEY publications,2006 Web Services Choreography Description Language Version 1.doc, W3C, http://www.w3.org/TR/2005/CR-ws-cdl-10-20051109/ OSGi Alliance, http://www.osgi.org “Services and Policies for Care At Home”, Feng Wang, Liam S. Docherty, Kenneth J. Turner, Mario Kolberg, Evan H. Magill, Computing Science and Mathematics, University of Stirling, Nov. 2006 MATCH (Mobilising Advanced Technologies for Care at Home), http://www.match-project.org.uk/ http://www.pabadis-promise.org/ “Vertical Integration of Enterprise Industrial Systems Utilizing WSs”, A.Kalogeras, J.Gialelis, C.Alexakos, M.Georgoudakis and.S.Koubias, IEEE Industrial Informatics May 2006 “The Jini Specification” Arnold, O’Sullivan, Scheifler, Waldo, Wollrath, Addison Wesley 1999 http://java.sun.com/products/jini/, The Jini Specification “NET XML Web Services in 24 Hours” (Sams Teach Yourself) by Mark Augustyniak, Mar.2002 The Semantic Web: A Guide to the Future of XML, Web Services and Knowledge Management by Michael C. Daconta, Leo J. Obrst, and Kevin T. Smith, 2003 http://www.w3.org/TR/owl-guide, “OWL Web Ontology Language guide http://www.daml.org/services/owl-s, “OWL-S: Semantic Markup for Web Services” IBM, Web Services Flow Languages (WSFL). 2003, http://xml.coverpages.org/wsfl.html Microsoft,Web Services for Business Process Design (XLANG). (2003), http://xml.coverpages.org/xlang.html BEA, IBM and Microsoft. Business Process Execution Language for Web Services (BPEL4WS) 1.1 (2003), http://xml.coverpages.org/bpel4ws.html M. Gudgin, M. Hadley, N. Mendelsohn, J.J.Moreau, H. F. Nielsen. Simple Object Access Protocol (SOAP) 1.2. W3C, 2003, http://www.w3.org/tr/soap http://protege.stanford.edu