A Device Configuration Management Tool for Context-Aware System

Transcription

1 A Device Configuration Management Tool for Context-Aware System Anna Kuutti*, Aleksandra Dvoryanchikova*, Andrei Lobov*, Jose Luis Martinez Lastra*, Tommi Vahtera Tampere University of Technology, Tampere, Finland*, THT-Control Oy, Tampere, Finland, {anna.kuutti; tut.fi; {lobov; ieee.org; thtcontrol.com Abstract Automation industry is moving towards more complex systems which are posing new challenges for operation from both machine and human perspectives. A group of challenges is related to management of the overwhelming information flow and to usability of the systems, and context-aware solutions have been recently introduced to the automation field in order to cope with challenges of this kind. The context awareness is seen as a solution which would allow to both the technological system and the human operator to infer the optimal decisions and to behave in the most effective way. In order to reach this capability, the external physical world and the system must be described in a way both interpretable for humans and machines. Ambition of this paper is to contribute to the context-aware (re)configuration of the system with a tool, which is designed to improve the efficiency of the configuration phase of a context-aware system. The tool provides a solution to configure and model the field devices of a system via automatically generated ontologies. This research is a part of a device management framework for a building automation use case, which is targeting to support controlling decisions of dwellers, technical support and social services. Keywords context-awareness, context modelling, ontology, device configuration, building automation I. INTRODUCTION The development of automation industry increases the amount of heterogeneous devices integrated to an automated system. This is due to the increase of complexity of IT environment. To manage the overwhelming information flow and to improve usability of the automated systems, to make systems adaptive and flexible, more sophisticated automation solutions are wanted. The context-aware solutions are seen capable to increase adaptability and pro-activeness of technological systems. Context-aware systems could act situation accordingly without user involvement into low level of the information inferring, and manage and present the information about current situation facilitating the decision making for humans. To enable the system to be aware of its context, the physical world needs to be described in a machine understandable way. A tool is needed to provide simultaneously the configuration and the modelling of the various field devices, to improve the efficiency of the configuration phase of a context-aware system. Context-aware systems gather context data and adapt the system behaviour accordingly. There has been steady adoption of context-awareness in a number of automation domains such as smart environments [1], manufacturing [2] and health care systems [3]. In combination with mobile devices this approach is valuable, and is used to improve usability [4]. In building automation, the trend can be seen within the growing demand of smart environments. Services e.g. automated garage doors, windows, heating and lighting that were seen as luxury a few years ago, are now considered as necessities of everyday living. Building automation system consists of hundreds to several thousands of field and automation devices, like sensors, operating units, controllers, and actuators. Configuration of these devices, let alone modelling, easily becomes a taunting task for a system installer. The more different devices are involved, the more knowledge is required from the installer. The knowledge background of the installers varies tremendously, and for this reason a tool, which provides an easy and effective configuration at the highest level of abstraction possible is required. This paper focuses on description of a tool, which is designed to provide a solution to configure and model the field devices of an automation system. Sensors and actuators are enhanced with a semantic description of their capabilities. The context models created are based on ontology models and more specifically on Web Ontology Language (OWL). The tool models context information of the devices and offers management of configuration files to the user at the highest level of abstraction possible, hence primary knowledge of ontology is not required. The logic behind the tool is provided by Jena framework, which is responsible of manipulating the OWL data. The current implementation was done for a SCADA/HMI application ( Ignition SCADA system). The main challenge for the tool was to provide a sufficiently detailed semantic description of the physical world for the system, and to provide data to enable the configuration of the devices for the application. The work is targeting to contribute to improving usability of embedded systems. The tool is part of a device configuration management framework, which is able to manage device information for a context-aware decision support solution which key interest is to define an adaptive human-machine interface (HMI) to monitor and control complex environments via mobile devices. The capability of the designed tool was /12/$ IEEE

2 tested in a use case from the domain of building automation. The use case addresses technical monitoring and control in automated building with several apartments, where i.a. airconditioning, heating, lights and doors are automated to improve the safety and quality of life. The paper is structured as follows. Chapter two provides the background; chapter three explains the selected methodology. Chapter four is dedicated to the tool description and the examples of the context models for the use case. Chapter five provides the conclusions and topics for further research. II. BACKGROUND A. Context-aware system The word context-aware can be related to terms: adaptive, reactive, responsive, context-sensitive and environmentdirected [5]. This relation enables context-aware system to be perceived as a system, which uses context to provide relevant information and/or services to the user, where relevancy depends on the user s task [5]. Context-aware systems adapt their behavior according to the current context information without explicit user intervention. This improves usability and makes the system operate more efficiently. To enable the system to be aware of its context, the physical world needs to be described in a machine understandable way. The physical world of an automation system includes i.a. people, places and things. Things can be considered as devices, sensors and actuators of the field level. System configuration is needed to set up these devices and assign resources, to enable a smooth operation of the system. Device configuration is an important aspect since it resolves resource conflict problems, and makes the system flexible and easier to upgrade in the future. In a context-aware system device configuration is done by modeling these components for the system. This modeling process is called context modeling. B. Context modeling A well designed model is a key to the context in any context-aware system. Previous models address the modelling of context with respect to one application or an application class, but nowadays generic context models are of interest since many applications can benefit from them. The key interest of today s research projects is to develop uniform context models, representation and query languages as well as reasoning algorithms that smooth context sharing and interoperability of applications [6]. The most relevant context models, which are based on the data structures used for representing and exchanging contextual information in the respective system, are following according to Baldauf [4]: Key-Value models, Markup scheme models, Object oriented models, Logic based models and Ontology based models. Key-Value models represent the simplest data structure for context modelling. They are frequently used in various service frameworks, where the key-value pairs are used to describe the capabilities of a service. All markup scheme based models use a hierarchical data structure consisting of markup tags with attributes and content e.g. the Unified Modelling Language. Modelling context by using object-oriented techniques offers to use the full power of object orientation. Existing approaches use various objects to represent different context types, and encapsulate the details of context processing and representation. Logic-based models have a high degree of formality. Facts, expressions and rules are used to define a context model. A logic based system is used to manage the mentioned terms, and to allow adding, updating or removing new facts. The reasoning process can be used to derive new facts based on existing rules in the systems. Ontologies represent a description of the concepts and relationships. Ontologies are a very promising method for modeling contextual information due to their high and formal expressiveness, and the possibilities for applying ontology reasoning techniques. [4]. 1) Ontologies Ontologies provide a method to store, analyse and present knowledge, which ultimately leads to domain specific models. In domain models the concepts and their relationships are defined in a generic way, and with a help of a reasoner the stored data can be interpreted, thus enabling automatic generation of new information [7]. Use of ontologies provide an uniform way for specifying the model core concepts as well as an arbitrary amount of sub-concepts and facts, enabling contextual knowledge sharing and reuse in an ubiquitous computing system [6]. III. METHODOLOGY A. Conceptual framework The Device Configuration Management Tool (DCMT) is placed to the context of the device configuration management framework which conceptualizes how to model the field devices, to enable a way to access the context of the devices, and to provide a graphical presentation of the system for a user in accordance to his/her role and preferences. The framework aims to contribute to context management in an automated system which supports decision making of a user in complex environments via designed human-machine interface in accordance to user role, intentions, state and situational context. The framework is divided into three following levels: installation, configuration and configuration management of the devices of the system (Figure 1). The bottom level, installation, includes the components of the physical world e.g. sensors and actuators. The installer connects the devices accordingly with the help of several manuals, guidelines and circuit diagrams to the system. After the installation, information associated with the installation process is documented. This installation document (e.g. excel table) acts as a gateway to the next section of the framework. This gateway is indicated with a letter A in the figure 1. The middle level, configuration, withholds the designed application DCMT and a generic device ontology template. The installation document done by the installer in the previous section is imported to the DCMT application. The application configures the installed devices by modifying the defined generic device ontology template for each device. The application provides an ontology based model of each device, which is represented with a device configuration file. These

3 Figure 1. Device configuration management framework files act as a gateway to the next section. This gateway is indicated with a letter B in the figure 1. The top level, configuration management, includes the extension of the DCMT application and a database. The device configuration files from the previous section are stored into this database, called ontology database, which withholds all the semantic models of the devices of the configured system. With the DCMT extension application, the ontology models are updated, modified, combined and linked to form a coherent semantic model of the installed physical world. This model acts as a gateway to other frameworks and is indicated with a letter C in the figure. The modifications of the ontology models are done with added SPARQL and Semantic Web Rule Language (SWRL) [8] modules of the DCMT application. B. Methods and Tools 1) Web Ontology Language Choosing the right ontology language is crucial for implementing ontology. Unconsidered selection may cause problems during the modelling of ontology and application [2]. The language should be expressive enough for defining the relevant concepts in enough detail, but not too expressive to make reasoning infeasible. Standard ontology language Web Ontology Language (OWL) is a development from international community W3C [9] and it has achieved a great success. OWL is a knowledge representation language with rich expressive power that is adequate for modelling various types of contextual information such as information associated with events, devices, places, time, and space [10]. OWL is designed to be used in situations where the information contained in the document is targeted to be presented for machines instead of humans. OWL represents the meaning of terms in vocabularies and the relationships between those terms. OWL has more functions for expressing meaning and semantics than other standard ontology languages such as XML, RDF, and RDF-S do [9]. The OWL language recommended by W3C represents the semantics of domain with three elements: classes, individuals and properties. The OWL specification includes the definition of three variants of OWL, with different levels of expressiveness. These are OWL Lite, OWL DL and OWL Full. Every sublanguage is a syntactic extension of its simpler predecessor. The chosen OWL sublanguage to model the context of the automation system is OWL DL. OWL DL was designed to provide the maximum expressiveness possible while retaining computational completeness, decidability, and the availability of practical reasoning algorithms [9]. OWL DL was the perfect solution to use due to the added expressivity of the description logics, and the language can carry out automated reasoning better than the other two levels. 2) Protégé Protégé [11] is an ontology editor and knowledge-base framework tool that allows generation, visualization and manipulation of ontologies. Protégé is open-source software, where the users are actively involved in their continuous development providing value feedback and solutions in various wikis, mailing lists and conferences. The ontology designing was done with Protégé editor Protégé-OWL version 4.2.alpha. It was chosen because it provides intuitive and easy-to-use graphical user interface, is an open-source application and has an extensible plug-in architecture. 3) Java The Java Programming Language [12] is defined as a general-purpose, concurrent, strongly typed, class-based object-oriented language. Java is considered as a simple language, because it doesn t have complex features such as pointers, unions or enumerations. It is object-oriented, distributed, has a built-in support for multithreading and most importantly is platform independent. The listed characteristics prove the benefits of this language over other alternative languages e.g. C++ [12]. As a programming environment Eclipse 3.7 (Indigo) was used. Eclipse is a multi-language software development environment comprising an integrated development environment and an extensible plug-in system. One of the plug-ins used was a WindowBuilder, which is a GoogleJava Developer Tool. WindowBuilder allows developing Java graphical user interfaces for Swing, SWT, RCP, XWT and GWT with drag-and-drop interface [13].

4 4) Jena API Jena API [14] is a Java framework for building Semantic Web applications. It provides a programmatic environment for RDF, RDFS, OWL, and SPARQL and includes a rule-based inference engine. Jena is open source and a result of the HP Labs Semantic Web Programme. The framework is used to create and manage ontologies. Jena framework was chosen because it allows finding, modifying and adding new data. Jena API is the most flexible, when compared to other APIs e.g. OWL API, as it covers all of RDF and therefore can be used to create OWL constructs, axioms and run inferences [14]. The Jena API is the main building block of the designed tool, since it handles the management of the created device ontologies. 5) SPARQL SPARQL [9] is a protocol and a query language for RDF. SPARQL contains capabilities for querying required and optional graph patterns along with their conjunctions and disjunctions. SPARQL also supports extensible value testing and constraining queries by source RDF graph [9]. SPARQL was chosen to be used because it s open-source, simple and intuitive, and Protégé has a plug-in for SPARQL queries. SPARQL queries were used in this thesis to validate the ontology and to generate the virtual sensors of the system. IV. DEVICE CONFIGURATION MANAGEMENT TOOL The designed DCMT generates configuration files of each device, to enable semantic representation of the field level. The configuration of the devices is done by an installer of the system. For this reason a graphical user interface was developed, which provides a smooth device configuration to the installer, regardless of his or hers engineering background, especially in the field of ontology. The realization of the software framework consists of graphical applications or user interfaces (GUI) called Configuration file Manager (ConMan) and Olingvo. These interfaces work parallel and provide an access to the ontologies for the user. The logic behind the applications is based on Jena Framework. Jena Framework is responsible of the manipulation of the OWL data. Semantic language defining OWL data is OWL DL. Figure 2 represents the realization of the software framework. ConMan is a graphical application that models context information of the devices and offers management of configuration files to the user at the highest level of abstraction possible, hence primary knowledge of ontology is not required. The user inputs the configuration information either by typing or importing the information from excel workbook to the application. The application creates, based on this input information, the ontology file for the device. The Generic device ontology is used as a base for the created ontology. Each device has the same general device ontology, which means that the classes and properties are same for every device, only the individuals differ. ConMan allows the user to manage these created configuration files by adding, editing and deleting functions. Olingvo is a graphical application for creating and editing OWL models. This interface is working parallel to ConMan and provides the opportunity to see the ontology created with Figure 2. Realization of the software framework the ConMan graphically. The main features of Olingvo have been inspired by Protégé. To use Olingvo, the user needs to have preliminary knowledge of ontologies. Accustomed user of ontologies can create the configuration information also with this application. The logic in the software framework is based on the use of Jena API to manipulate OWL data. This API is the most flexible OWL API available, as it covers all of RDF, and therefore can be used to create OWL constructs, axioms and run inferences. The Jena API is low-level API, which manipulates the ontology models directly [14]. The software framework is platform independent, since it is programmed with Java. Integration of the software framework with the control system was achieved with vertical software integration method. The software framework produces an ontology file as an output for the common database of the system, where the reasoner and the SCADA/HMI applications can utilize them. The implementation method used between the applications is file transfer method, which makes the software framework independent and flexible. The produced configuration file provides needed information of the device e.g. ID, device description, connectivity information, default visualization information and operational information. The configuration file is saved as an ontology file (.owl) to a database. The information in the configuration file is used by the reasoner of the system, which based on rules decides what to do in a situation, and what to show to the user in the HMI on a certain time. 1) Generic device ontology To enable the control and monitoring of the devices of the system in a context-aware way, a formal representation of the physical world is required. The representation should be understandable by both machines and their operators, and

5 therefore ontology based models to create the context models of the system arise as the best solution. There has been an effort amongst the researchers to come up with a semantic representation of devices e.g. [15], [16]. FIPA Device Ontology [15] defines a frame-based structure to describe devices, and is intended to simplify agent communication for purposes such as content adaptation. Devices like PC s and smart phones can be described by using this ontology, but it does not provide an effective description of devices like sensors. The Device ontology proposed in [16] provides a description of devices, which aims to simplify semantic service discovery. The ontology enables a more generic semantic description of a device than the FIPA ontology. The two ontologies reviewed were used as a guideline to design the Generic device ontology. The two ontologies describe device information along with the service information, which is not needed in building automation use case. Although the purpose of the ontologies differs, the class hierarchies of the FIPA and Device ontology provided a good example for the ontology design phase. The main interest of the designed device ontology was to provide context-awareness for the system, and especially provide a semantic description of the field level for the adaptive HMI of the building automation system. The final solution was to design the ontology from scratch to ensure the compatibility with the system and to provide exact context of the devices. The context to be modeled is the field devices of the system from the perspective of monitoring. Field devices consist of sensors and actuators e.g. IR sensors, temperature sensors and magnetic switches, which control and sense building automation appliances e.g. lighting and heating. The created ontology was designed with an ontology editor and knowledgebase framework called Protégé, and the chosen ontology language to be used was OWL DL due to the added expressivity of the description logics. The OWL is constructed of three components: classes, properties and individuals. Classes represent the formal description of concepts in the domain and properties describe the features and attributes of the domain. Figure 3 illustrates a section of the designed Generic device ontology template. The ellipses represent classes and the edges represent properties of the ontology. The device information is derived from device manuals, product data sheets and installation documents. The information related to a device is divided into four main classes Device Information, HW, Operational and Visual. The ontology was designed as generic as possible and all the domain specific details are hidden in the sub-classes. The ontology can be extended with classes and properties, which ensures a comparability of different devices. 2) Example of the tool application The DCMT was tested in the domain of building automation. The selected use case is a Senior House, where the Figure 3. Generic device ontology. dwellers could lead self-dependent lives with accessible health, social, and technical supports. The system consists of several automated buildings with multiple embedded devices, which should support living conditions, care services and security. The system is used by three groups of users: dwellers, maintaining personnel, and social/health care personnel. The whole system withholds 25 apartments, and approximately 16 devices are embedded to each. There are IR sensors to control the lighting, temperature sensors to control the heating, magnetic switches to determine the door status, leak sensors to detect water leakage, just to name a few. To enable the system to manage and to reason the context for proactive, decision supportive HMIs for different types of users, the physical world needs to be described in a formal way to be machine understandable, yet with natural semantics in order to facilitate the further reconfigurations for maintaining personnel with various engineering skills. Table 1 shows the ontology classes and individuals of an IR sensor device ontology model. The model was created with the defined DCMT tool by importing the configuration information from a configuration documentation, which was a xlsx-file. The ontology model of the IR sensor is based on the defined Generic device ontology template reviewed in the previous chapter. The left columns of the table represents the main classes and their subclasses, and the rightmost column the individuals of these classes. Device Information class withholds the device description information a.i. device name, tag and model. In HW class, information concerning connections, hardware and location are defined. With this information the reasoner can clarify the connections of the devices, hence map the field level of the system. In Operational class, states, control and measurement parameters of the device are defined. This is the most important information for the system from the control point-of-view. In Visual class, the default visual module for the device is determined. The determined visual modules are use case -software specific. In the building automation system the selected SCADA/HMI application is Ignition, hence the visual modules are specific for this application. The visual module defines the graphical presentation for the device and colors or shapes for state representation.

6 Classes Device Information HW Operation Tag Vendor Model Location Connection TABLE 1. IR SENSOR -ONTOLOGY Apartment Individuals DIN_001 IR sensor located in the room to detect motion, and to control lights. Celetron Oy NC H205 IP IO IO 102 Channel No 1 Connector 11 Connector + + Position IR 1 CPU IPM 1 Measurement Unit - Limits max 1 min 0 models. The users of the system need to be considered as well in the design phase of the tool, since they have different backgrounds and different level of expertise from the field. However, the approach behind the tool is seen practical and applicable to other domains of automation, and could be further extended. Ongoing research covers virtual sensors and how to include the description of these sensors within the tool. Also mobile sensors are a topic of interest, and should be taken into consideration. The current implementation is designed with regard to devices, which have predefined fixed position. The usability and appropriateness of this tool and reviewed ontology should be further investigated and refined accordingly in the future. ACKNOWLEDGMENT The research leading to these results has received funding from the ARTEMIS Joint Undertaking. Grant agreement n (ASTUTE: Pro-active decision support for dataintensive environment). REFERENCES Visual States Control Value 0 {Normal, Alert} {Lights ON, Lights OFF} 2 State Toggle V. CONCLUSION AND FUTURE WORK While the surroundings become more populated with automated devices, the more configuration, operation and interaction is required from the users. The need for intelligent systems, which act situation accordingly without user interference, is rising. The interpretation of the situation requires context-awareness from the system and the use of ontologies is a key requirement for realizing pervasive contextaware systems. In order to improve context-awareness of an automated system, the physical world of the system should be configured and described in a machine understandable form. The tool proposed in this paper contributes to improving of contextawareness via automated device configuration management support. The tool was tested within a building automation use case. The tool provides a way to configure devices in a userfriendly and expressive way thus enabling effective semantic description of the devices. The Generic device ontology proposed, enables the modeling of the context of the field devices. It is intended to provide a general ontology to describe any type of sensor or actuator in building automation domain. The currently seen limitation of the defined tool is the domain dependent outcome. The solution is designed for the SCADA/HMI application which dictates what type of information is needed to configure the field devices and in what level of detail the data should be presented with the context [1] M. C. Huebscher and J. A. McCann, Adaptive middleware for contextaware smarthomes, Toronto, [2] J. L. M. Lastra, I. M. Delamer and F. U. Lopez, Domain Ontologies for Reasoning Machines in Factory Automation, Tampere University of Technology, Tampere, [3] N. Bricon-Soufa and C. R. Newmanb, Context awareness in health care: A review, international journal of medical informatics, pp. 2-12, [4] M. Baldauf, A survey on context-aware systems, Int. J. Ad Hoc and Ubiquitous Computing, vol. 2, no. 4, pp , [5] A. K. Dey and G. D. Abowd, Towards a Better Understanding of Context and Context-Awareness, Atlanta, [6] T. Strang and C. Linnhoff-Popien, A Context Modeling Survey, [7] C. Reinisch, W. Granzer, F. Praus and W. Kastner, Integration of Heterogeneous Building Automation Systems using Ontologies, IEEE, Vienna, [8] Inductive Automation, [Online]. Available: [Accessed 6 January 2012]. [9] W3C, [Online]. Available: [Accessed 6 January 2012]. [10] H. Chen, T. Finin and A. Joshi, "Semantic Web in a Pervasive ContextAware," [11] Protégé, [Online]. Available: [Accessed 6 January 2012]. [12] Java Programming Language, [Online]. Available: [Accessed 25 January 2012]. [13] Google Java Developer Tools, [Online]. Available: [Accessed 25 October 2011]. [14] Jena A Semantic Web Framework for Java, [Online]. Available: [Accessed 6 January 2012]. [15] FIPA Device Ontology Specification, Foundation for intelligent physical agents, [Online]. Available: [Accessed 6 january 2012]. [16] A. Bandara, T. Payne, D. de Roure and G. Clemo, An Ontological Framework for Semantic of Devices, UK, 2004.