Home / Building Automation Environment Architecture Enabling Interoperability, Flexibility and Reusability

Transcription

1 Home / Building Automation Environment Architecture Enabling Interoperability, Flexibility and Reusability K. Charatsis 1, A.P. Kalogeras 1, M. Georgoudakis 2, J. Gialelis 2, and G. Papadopoulos 2 1 Industrial Systems Institute, Patras Science Park, Rio Patras, Greece 2 Applied Electronics Laboratory, Department of Electrical and Computer Engineering, University of Patras, Rio Patras, Greece Abstract The home / building automation environment is characterized by a high degree of heterogeneity with a large number of systems that need to interoperate, comprising different devices provided by various vendors. A need for greater integration, flexibility and interoperability is increasingly expressed. The current paper presents an architecture that utilizes three predominant state-of-the-art technologies, namely workflows, ontologies and web services in order to address the above need in an efficient way. I. INTRODUCTION Modern design in Building and Home automation has revolutionized the home environment, introducing a plethora of smart appliances as well as various network technologies, mandating an increase in the level of flexibility and interoperability. A great number of systems and applications exist with reference to this technological area, covering the whole range of the home - building automation system hierarchical model. This model comprises three different levers: the automation layer, the control layer and the service provision layer. The model that is described in this paper applies both to home automation and building automation applications; thus henceforward a reference to anyone of them is valid for both of them. The model is depicted in figure 1. The automation layer comprises the building automation equipment, such as sensors, actuators, smart devices and modules, controllers (PLCs) and network controllers. Automation level devices provide device relevant application code, that handles the required preprocessing, supporting the lower layer code for integrated systems addressing the provision of building and home services related to BMS, safety, security and disease management processes. The flow of information between automation level devices is usually characterized by time constraints, thus mandating the utilization of special communication protocols such as Lonworks, EIB, WorldFIP. The control layer includes devices that play the role of the control point of the home systems, wherein reside applications that are traditionally characterized as control automation applications. Control layer devices need to interconnect both with the indoor individual networks of the automation layer, as well as provide the necessary entry point through the internet to the upper layer for the provision of services to the home / building environment by third party Service Providers. The upper layer of our model refers to the various services offered by independent Service Providers that a building automation system can be a client of. A service can be offered either for free or be billed to its clients / users. Each user can be simultaneously a client of various services, while each service provider may have a bundle of services provided to each client. Internet plays a significant role in the overall communications for the enforcement of the presented model. The ubiquity of the internet has led to the emergence of standards that allow the creation of a unifying infrastructure that makes possible the integration of the different systems at whatever layer they may reside in. Nevertheless a conceptual dividing line exists between applications at the lower and the higher levels. The work presented in this paper is associated with a view of the home environment that mandates the integration and interoperability of all the systems / applications that participate in it, independently of their level. Architectural elements of this approach are presented describing home automation integrated services as processes by means of workflows, utilizing the state-of-the-art technology of Web Services in order to open up building automation systems and make available their functionalities. Our approach introduces innovation in the home environment through the incorporation of semantic information related with the home automation process, described in ontologies, increasing the overall degree of interoperability and flexibility. Our paper makes reference to the state-of-the-art technologies utilized by the proposed architecture, then it presents the aforementioned architecture and finally it showcases an example process as well as its deployment according to our proposal.

2 Security Energy Management Safety Figure 1.Model s Layers Provider Layer Disease Management Control Layer Home Home Home Home Automation Layer II. RELATED WORK Several approaches handle integration issues relevant to the building automation domain. We present herein two such approaches that present similarities to our proposed architecture, being an emerging and a commercial standard. The OSGi Alliance [1] introduced the Open Services Gateway Initiative (OSGi) specification, which defines a standardized, component oriented, computing environment for networked services. The OSGi Service Platform is a Java based application server, where software components can be installed, updated, or removed, while a device is on operation. Software components are libraries or application packages (bundles) 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 be interfaced to networked enabled devices by means of such protocols as 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). However, it is only with proper permissions that different components can reuse each other and cooperate. The OSGi technology introduces an architecture that is tightly coupled to Java language and demands an extra implementation of the OSGi Service Platform to the networked devices. The Panoramix platform [2], a commercial standard launched by Echelon, is a scalable enterprise software designed to reside in a corporate-owned or hosted data centre and communicate across the Internet or a private IP network with remote sites containing networks of LONWORKS smart devices. The platform provides a Web Services interface and SOAP calls functions, enabling its integration with other systems. However, the Panoramix platform is quite restrictive, since its underlying automation layer supports devices based on the LONWORKS technology. III. PREDOMINANT TECHNOLOGIES The architecture that is proposed in this paper is based on the use of three predominant highly-accepted technologies, more specifically web services, workflows and ontologies. Their proposed combination results in a highly interoperable and flexible system that effectively addresses the needs of the home automation environment. In the following paragraphs an introduction to the three technologies is elaborated and the relevant technological state-of-the-art is presented. A. Web Services Web Services (WSs) [3] represent a new paradigm for applications. They utilize capabilities which are inherent to other applications and exposed by them via open standard application interfaces and protocols. The capabilities of a Web Service may be used through its invocation over a communication infrastructure, without any need for integration. Thus, a Web Service represents a reusable software building block that is URL addressable. WSs are implementation independent, by exposing their capabilities, rather than their implementations to client applications. Nevertheless, they remain compatible with all client applications. Some of their utilization benefits are: the reduction of application development costs, the integration of both data and system processes, the reduction of errors, the simplification of application maintenance and reusability. WSs are a technology for distributed computing and it is ascertained that an application built on WSs may be easily accessed and used. WS technology main benefit is the anybody-toanybody communication that it makes possible. Former distributed computing enabling technologies lacked in terms of ease of use and deployment, as well as in terms of interoperability. The request for a distributed computing application environment, that would be easier to deploy than CORBA, DCOM or JRMI, while on the other hand it would offer a greater degree of interoperability, led to the WS technology. The key enabler for the WSs technology is XML and the initiatives that form its foundations are SOAP, WSDL, UDDI. The Simple Object Access Protocol (SOAP) [4] is a lightweight protocol intended for the exchange of structured information in a decentralized, distributed environment. Although not tied to any particular transport protocol, SOAP usually uses HTTP. XML technologies are utilized for the definition of an extensible messaging framework that provides message constructs exchangeable over a variety of underlying protocols. This messaging framework has been designed in such a way as to be independent of any particular programming model or any other implementation specific semantics. This means that the only requirement for the communication of a client and a server is that they can both forward and understand SOAP messages. SOAP

3 comprises the following composite elements: an envelope describing the message content and the way to process it, a set of encoding rules to express instances, application-defined data types and a convention for the representation of remote procedure calls and responses. The Web Services Description Language (WSDL) [5] provides a model along with an XML format for the description of Web services. A WSDL description of a Web service is done into two fundamental stages, one of which is abstract while the other is concrete. The abstract description of a Web Service consists of the messages that it sends and receives. At the concrete level, a binding specifies the transport and wire format details for one or more interfaces. An endpoint associates a network address with a binding. Finally, a service groups together endpoints that implement a common interface. The last element needed for the WS technology implementation is the UDDI (Universal Description Discovery & Integration) [6]. It supports both designtime and run-time discovery of Web Services. B. Workflows Processes, that are relevant to home automation, need to be effectively managed, in order to have full control of their data. Workflows present the technology that makes this management capable of being automatically coordinated and controlled. A workflow actually is a form of the home automation process that is possible to be processed by a workflow management system (WfMS). A workflow represents a model of a home automation process that comprises all the necessary and essential information in order to implement it. Such information includes: number of activities, activities order, data assignment, devices (appliances, PLCs) designation, etc. In a more abstract sense, workflow systems tie together the three fundamental aspects of a home automation system: automation processes, web service provision and information technology (IT). As already mentioned, the broad acceptance of Web Services 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, has made this technology the best choice for application integration within and across home automation systems. The combination of such an interoperable system, based on the WS technology, and workflows is challenging. Several efforts are underway in order to define Web Services workflow standards. These include WSFL (Web Services Flow Languages) [7], XLANG [8] and BPEL4WS (Business Process Execution Language for Web Services) [9]. C. Ontologies Ontologies represent a way for knowledge representation that came along in the area of Artificial Intelligence. The utilization of ontologies in diverse research areas as well as their various related applications is increasingly appreciated since ontologies constitute an emerging technology of increasing penetration. Ontologies give a specific description of a domain where their terms and their relationships are clearly defined. Ontological terms are organized in a hierarchical structure and the relationships consist of HAS-A and IS- A associations. The main feature of ontologies is that the knowledge that they describe can be noticeable by different users and be used for platform independent implementation. The evolution of the Semantic Web and the arisen need for the representation of the Ontologies in semantics, has introduced a variety of semantic markup languages, based on the XML standard. The most prominent ontology markup languages are DAML+OIL and its successor OWL, which build on top of RDF Schema. It allows describing classes using description logics. Currently most ontologies use only a part of the feature set provided by the DAML language [10], thus many ontologies can be expressed in RDF Schema only [11], providing a basic ontological vocabulary to be used within a certain community. IV. THE PROPOSED ARCHITECTURE A home automation process usually comprises a number of actions that are associated with the sequential use of different applications or systems ranging from the automation level up to the service provision layer with reference to the presented model. The need for interoperability of such systems / applications has led to a transition from vendor independent systems to more open ones, utilizing middleware technologies and the internet infrastructure for integration purposes. The architecture proposed in this paper builds upon this general trend, presuming that the building automation infrastructure is compliant with the above predominant technologies and that the home 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. The basic idea behind a home automation process is that it may be represented as a sequence of different application / system service calls. This idea of a sequence of actions relegates to the idea of a workflow associated with the home automation process. A workflow, in our model, is an abstraction of a home automation system process. It comprises a number of logic steps (known as tasks or activities), dependencies among tasks, authorization rules, and system users. In a workflow, a task can represent an activity configured by the home system user or from a software system. Most workflow standards support sub-processes, which allow tasks within a workflow to be implemented as another workflow. Two complementary parts of the workflow exist: the control flow and the data flow. The control flow defines the sequencing of different activities in the process. The data flow defines how information flows between activities.

4 Ontology SOAP XML Configuration Document Ontology - Web Service Association Tool UDDI Registry Workflow Design Tool BPEL4WS Workflow Document SOAP Workflow Execution Engine SOAP Home Automation Systems Home Automation Processes Figure 2. The proposed Architecture A workflow describing a home automation process presents actually a means for expressing an automated control procedure in a standardized way. Given a home 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. Our paper emphasizes on the association of workflow tasks with web services that are available by the home automation infrastructure. As depicted in chapter III, web services allow any piece of software to communicate with one other in a standardized XML messaging scheme. They eliminate many of the interoperability issues that the traditional integration solutions have difficulty in resolving. An association of the workflow activities and the available web services is mandatory in order for the presented system to work efficiently. This association would be nevertheless static, binding the specific workflow to specific information systems and their web services. Viewing it from the system engineering perspective, this approach lacks significantly in terms of flexibility and reusability, since the process workflow is very tightly connected to the actual home automation infrastructure at a given instance of time. Thus, workflows would need significant alterations whenever changes in the home automation infrastructure take place. In order to resolve the above issues and increase interoperability, we propose the utilization of semantic information relevant to the different business processes. Business process semantic information may be introduced by means of defining ontologies. Ontologies emerged as a means to represent knowledge. In our present work, we propose the use of ontology semantics for representing home automation device characteristics, system functionalities, and home system user authorization availability, offering all the necessary information related to a home automation process. Our idea actually introduces an intermediate layer between workflows and web services. Thus home automation process workflows are described in terms of the ontology terms associated with them rather than the home information systems that they are implemented by. The introduction of ontological information leads to the description of a home automation process by means of both its ontology and workflow. The proposed separation of the process workflow and the services that are needed for the workflow execution through an ontological intermediate layer, leads to a significant increase in the level of home automation interoperability, since home automation process workflows need to be altered only whenever the associated home automation process logic is changed. Their influence by home automation information system alterations is dramatically reduced. Although the bonding between the actual web services and the workflow steps is broken, an association of the ontological information and the available web services during the design phase is mandatory. The implementation of the above architecture involves the following functional elements: The Workflow Design Tool that enables the expression of the home automation processes in terms of workflows. The Ontology Web Service Association Tool that makes possible the association of the home automation web services with ontological terms. The Workflow Execution Engine that is responsible for the implementation of the home automation process logic by executing the associated workflow. The Home / Building Automation Information Systems that provide the web services that will be called at execution time. The Ontology Web Service Association Tool consists of a UDDI registry, which comprises the descriptions of the web services provided by the Home / Building Automation Information Systems, and the Ontology file which depicts, in terms of classes and instances, the roles, tasks and the exchange of parameter data between home automation processes. WSDL documents are used for the description of WSs while the relevant Ontology utilizes the RDFS specification. The resulting tool document is XML formatted and it contains the associations of the classes and instances of the ontology and their properties to the methods and parameters of the home automation systems web services. Thus this tool provides an efficient mechanism, making the web services of an application / system easy to discover and associate with the home automation process semantic information contained in the ontology. The Workflow Design Tool needs to communicate with the Ontology Web Service Association Tool in order to get the home automation process ontology and its associated web services. The result of the tool will be a workflow document 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 is responsible for the fulfillment of two main goals, the first of which being

5 the execution of the home automation web services according to their association to the individual workflow steps, and the second being the monitoring of the progress of the home automation process workflow execution. The proposed architecture consists of two parts, the Workflow Configuration and Design and the Home Automation Process Execution, as depicted in figure 2. The Workflow Configuration and Design phase comprises the following steps: I. the association of home automation process ontological information with the available home automation web services. This association is done using the Ontology Web Service Association Tool resulting in a configuration XML document. II. the design of the home automation process workflow. This design utilizes the Workflow Design Tool which retrieves information from the XML configuration document, which is related to the implementation of the workflow tasks. This design tool has as an output a BPEL4WS document that is stored in a workflow repository. For the purposes of Home Automation Process Execution phase, the Workflow Execution Engine accesses the workflow repository and retrieves the workflow corresponding to the home automation process that needs to be executed. For all workflow tasks the engine calls in sequence the appropriate web services using the SOAP protocol for the interconnection of the home / building automation applications / systems. When a web service is called, the corresponding process of the relevant home automation application / system is executed and its results give feedback to the execution engine, which proceeds to the next task until the home automation process is complete. V. EXAMPLE USE CASES The present chapter of this paper depicts an example case study in order to further elaborate the proposed architecture. The main goal of this architecture is the integration of the different systems / applications which exist in the home environment. Our presented scenario involves a large number of buildings each one of which is equipped by a number of controlled systems and applications. Our example focuses on how an energy provider could use our model in order to provide its energy management service in an effective way. A. Scenario Description This scenario involves an energy provider that provides interactively its service to a number of clients. The Interactive functionality lies in the fact that the service provider can both monitor and control the energy consumption of its clients. In order to maintain the description compact, we provide an overview of a simplified and reduced version of the control process that needs to be executed when the overall power consumption must be reduced. Whenever a need for consumption reduction is decided by the service provider, a relevant request is forwarded to all controlled homes. This request must utilize automation layer information through the control layer. More specifically, the control layer will acquire from the automation layer the current energy state and will calculate the overall energy consumption of the building. Based on the current state and taking into account the building energy audit, the provider can estimate the potential reduction that may be asked for by each client. In addition to the audit, the client availability to the asked reduction must be also taken into account. For example some clients may be running on a scenario that does not allow the interference of service provider with their systems for a certain period of time. A specific scenario that a client may be running determines and may provide client availability to changes at a given instance of time. All the above information will be taken into account, in order to determine the consumption scenario that each client should follow. The activation of these scenarios may alter the energy scenarios of some clients, leading to changes to their control system functionalities. Upon the acceptance of the scenario change, a client will have to appropriately configure / initialize the associated processes and their relevant workflows for each affected automation subsystem (e.g. water heater, HVAC, elevators, etc.) in order to reduce their consumption. This configuration step needs the downloading of the necessary files to the different controlling devices, e.g. PLCs, NCs, as well as the required initialization and the necessary program invocations. This scenario clearly requires the involvement of different systems being employed on different levels of the home automation hierarchical 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 achieved over the proposed architecture some prerequisites concerning the needed infrastructure must be fulfilled. First of all, a common communication infrastructure to all participant buildings is required, so that different applications / systems can interoperate above it. This infrastructure will be based on standard protocols and the openness of existing applications / systems via the Web Services technology. During the design phase of the energy management procedure, its scenario logic that is described in V.A. has to be analyzed by means of an ontology and a workflow. The ontology will provide all the semantic information concerning roles, tasks and their relationships of both applications / systems and home users involved in the provisioned energy management service.

6 For each participating home a sub-workflow will have to define the sequence of actions that need to be taken. All the sub-workflows will be invoked by a general workflow, in order for the scenario logic to be followed. This sequence of actions will be determined in terms of ontology tasks. The design of the above workflow and sub-workflows, in terms of the scenario ontology is a function of the Workflow Design Tool. As a next step, it is the role of the Ontology Web Service Association Tool to associate the workflow with specific WSs, found in the UDDI registry of the service provider. The UDDI registry contains the WSDL descriptions of the WSs of all the application / systems of all the participant client homes, such as the acquisition of each running home energy scenario parameters. 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 home system / application during the energy management scenario execution / alteration phase. C. 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 information systems of the participant client homes. It should be noted that the described scenario utilizes different web services that are relevant with home applications / systems that reside on different layers with reference to the introduced home automation model. For instance the parameters of the running energy scenario must be taken through a web service at the control level, while the current energy state should utilize information from the automation level. Furthermore the actions needed may also be discerned into either the automation or the control layers. Additionally the activation of a specific control application is a task of the control layer while the program invocation of a device functionality is a task of the automation layer. In this context, the overall home environment is successfully integrated independently of the layer that the different applications and systems may reside in. This integration introduces a high degree of interoperability and flexibility and allows the service provider to effectively employ its energy management strategy. Finally, the proposed architecture provides an integrated approach for the handling of any kind of multi client service provision, whether it integrated both the upper and the lower layers of the home automation infrastructure. Thus it results in an increased efficiency concerning home automation energy management as understood from the perspective of system engineering and design. VI. CONCLUSIONS The work presented in this paper, proposed a novel architecture for enabling interoperability of the applications / systems residing at all different levels of the home / building automation infrastructure. This architecture mixes and matches three predominant technologies, namely workflows, ontologies and web services. It specifies a standardized way for the description of home / business automation system logic associated with the relevant processes. More specifically a home / building automation process comprises an ontology and a workflow. The ontology determines the necessary semantics related to the home / building automation process, while the workflow defines the process execution steps. The association of the workflow with ontological information increases the degree of interoperability while making home / building automation applications more reusable and flexible from a system engineering level view. A set of proposed tool makes possible the implementation of the above architecture, whilst a home automation process example has been showcased. Finally our proposed architecture solution is easy to integrate devices / systems implementing commercial or emerging standard architectural and technological solutions such as OSGi and Panoramix. More specifically, the Panoramix platform with its Web Interface could easily be integrated to a system following our architecture, while OSGi could be integrated with the appropriate use of servlet parsers / rappers to freely communicate with SOAP servers / clients. REFERENCES [1] OSGi Alliance, [2] Echelon [3] W3C - Web Services Activity [4] M. Gudgin, M. Hadley, N. Mendelsohn, J.J.Moreau, H. F. Nielsen. Simple Object Access Protocol (SOAP) 1.2. W3C, 2003, [5] R.Chinnici, M. Gudgin, J.J. Moreau, J. Schlimmer, S. Weerawarana. Web Services Description Language (WSDL)2.0. W3C, 2003, [6] K. Januszewski, E. Mooney, R. Harrah, S. Lee, J. Munter, C. von Riegen. UDDI ver, 3.0. UDDI.org, 202, [7] IBM, Web Services Flow Languages (WSFL). 2003, [8] Microsoft,Web Services for Business Process Design (XLANG). (2003), [9] BEA, IBM and Microsoft. Business Process Execution Language for Web Services (BPEL4WS) 1.1 (2003), [10] Swartout B., Patil R., Knight K., Russ T Toward distributed use of large-scale ontologies. In Proceedings of the Tenth Knowledge Acquisition for Knowledge- Based Systems Workshop. (KAW 96) [11] Ogbuji U., Ouellet R., DAML Reference, [12] Brickley D., Guha R.V., RDF Vocabulary Description Language 1.0: RDF Schema, W3C Recommendation 10 February 2004,