Facoltà di Ingegneria dell’Informazione
Corso di Laurea Magistrale in Ingegneria Informatica
Context Management in
a Pervasive System
Relatore: Prof. Fabio A. Schreiber
Tesi di Laurea di: SABATINO RACHELE Matr. 819191
Chapter 1 Introduction
1.1 Pervasive computing . . . 1
1.2 The notion of Context . . . 3
1.3 Thesis objectives and organisation . . . 4
Chapter 2 State of the Art 2.1 Contextual Information . . . 7
2.1.1 Context model . . . 8
2.2 Short survey of Context-Aware Middleware . . . 9
2.3 Examples of Context-Aware Frameworks . . . 13
2.4 The PerLa System . . . 15
2.4.1 FPC . . . 16
2.4.2 Communication . . . 17
2.4.3 Script and Operations . . . 18
2.4.4 PerLa Language . . . 18
2.4.5 Low Level Queries . . . 19
2.4.6 Java object representation of the Query Language . . . . 22
Chapter 3 Context-Awareness at Design Time 3.1 Context-aware system overview . . . 25
3.2 Initial steps for a Context-Aware PerLa . . . 26
3.3 Context Model . . . 26
3.3.1 The basic structure of the context model . . . 26
3.3.2 Example of a CDT . . . 27 3.4 Context Language . . . 29 3.4.1 CDT Declaration . . . 29 3.4.2 Context inference . . . 32 3.4.3 Context creation . . . 32 3.5 Partial components . . . 33 3.5.1 CDT Declaration example . . . 34 3.6 Final consideration . . . 37
Chapter 4 Parser for Context Language 4.1 Utility classes . . . 40
4.2 CDT Creation . . . 42
4.2.1 Create Dimension clause . . . 42
4.2.2 Create Attribute clause . . . 44
4.2.3 Create Concept clause . . . 45
4.3 Context Definition . . . 48
4.4 UML . . . 49
Chapter 5 Context Awareness at Run Time 5.1 Context Manager . . . 53
5.1.1 The Composer Manager . . . 54
5.1.2 Mapping raw data to contextual information . . . 56
5.2 Context Detector Component . . . 59
5.3 Context Executor . . . 60
5.3.1 Context history . . . 61
5.3.2 Context distribution . . . 62
5.4 Conflict management . . . 65
5.4.1 Conflict Detection in PerLa . . . 67
Chapter 6 Study case 6.1 A ski resort application . . . 69
6.1.1 Description of the environment . . . 70
6.2 Database . . . 72 6.3 CDT schema . . . 72 6.4 Netowork topology . . . 77 6.5 Context . . . 78 Chapter 7 Conclusions 7.1 Final consideration . . . 81 7.2 Open points . . . 83 Chapter 8 Appendix 8.1 XLM Device Description of a snow sensor . . . 85 Bibliography
1.1 An example of a context-aware system . . . 2
2.1 Layered conceptual architecture for context-aware systems . . . 9
2.2 Cassowary Deployment Architecture . . . 11
2.3 CASS architecture . . . 12
2.4 The Runtime Architecture of the JCAF Framework . . . 14
2.5 Sentient object model . . . 15
2.6 PerLa achitecture . . . 16
2.7 Execution of a user request in a FPC . . . 19
2.8 Query partial internal representation . . . 23
3.1 An example of CDT Schema . . . 28
3.2 An example of useless context constraints . . . 28
3.3 Contextual block components . . . 33
3.4 Division of the enable component into enable partial components 34 4.1 Expression partial UML . . . 41
4.2 ParserContext class . . . 42
4.3 Internal representation of the CDT . . . 50
4.4 Internal representation of a Context . . . 50
5.1 New context-aware PerLa . . . 51
5.2 Procedure flow of context-aware PerLa . . . 52
5.3 Sequence diagram of an asynchronous query execution operation 58 5.4 Example of the cache containing the current state of the CDT . 59 5.5 Sequence diagram of the distribution of context events . . . 64
6.1 ER diagram for a ski resort . . . 71
6.2 Example of a CDT for a ski resort . . . 73
2.1 LLQ Selection Definition . . . 20
2.2 Example of a Create PerLa Query . . . 22
2.3 Example of a Selection PerLa Query . . . 22
3.1 CDT declaration syntax . . . 29
3.2 Example of use of clauses when/evaluated on . . . 30
3.3 Context creation syntax . . . 32
3.4 CDT declaration of the wine production monitoring . . . 35
3.5 Concept Frost definition . . . 36
3.6 Concept Overheat definition . . . 36
3.7 Concept Growth definition . . . 36
3.8 Context Frost Alert definition . . . 37
3.9 Context Transport Monitoring definition . . . 37
4.1 Start of CDT grammar production . . . 42
4.2 Creating a Dimension . . . 44
4.3 Creating an Attribute . . . 45
4.4 Creating a Concept . . . 46
4.5 Context Production . . . 48
4.6 Active if Production . . . 48
4.7 Simple Context Element Production . . . 49
4.8 Complex Contect Element Production . . . 49
5.1 The ContextManager class . . . 53
5.2 The IComposerManager Interface . . . 55
5.3 The Query Executor class . . . 57
5.4 The StatementHandler class . . . 57
5.5 The StatementTask interface . . . 58
5.6 The ContextExecutor class . . . 61
Negli ultimi anni, il paradigma di ubiquitous computing ha mirato alla creazione di ambienti intelligenti tramite l’uso di dispositivi embedded che forniscono con-nettivit`a e servizi in ogni momento nascondendo la loro presenza e migliorando in questo modo l’esperienza dell’utente. Essere percepito come invisibile `e lo scopo ultimo di un sistema pervasivo che si adatta a nuove situazioni senza il bisogno di un diretto intervento dell’utente. Adattarsi a cambiamenti nell’ambiente richiede l’abilit`a di distinguere diverse situazioni o contesti. I sistemi context-aware migliorano il comportamento di un’applicazione: raccolgono dati dall’ambiente, li interpretano riconoscendo il contesto in cui stanno operando e adattano il sistema di conseguenza. Il comportamento context-aware pu`o influenzare sia l’esecuzione di azioni specifiche, sia il filtraggio, tailoring, delle informazioni sulla base delle preferenze dell’utente riducendo cos`ı il cosiddetto information noise. La tesi presente descrive le fasi del design di caratteristiche context-aware e il loro sviluppo integrato ad un middleware pervasivo chiamato PerLa. Originariamente concepito solo per la gestione e l’interrogazione di una rete di sensori, PerLa `e stato espanso con funzionalit`a per: 1) definire l’ambiente con uno modello adatto; 2) creare un contesto sulla base del modello definito; 3) acquisire dati da sensori e input esterni che definiscono uno specifico contesto; 4) attivare o disattivare un contesto a run-time a seconda dei valori attuali delle variabili di contesto; 5) eseguire le azioni di un contesto sul sistema.
In recent years, ubiquitous computing aimed at creating intelligent environments by embedding devices that provide connectivity and services all the time hiding their presence, improving in this way the human experience. The ultimate goal of a pervasive system is to be perceived as invisible, adapting to new situations without the direct intervention of the user. Adapting to changes in the environment requires the ability of distinguishing different situations or contexts. Context-aware systems enhance the behaviour of an application by gathering data from the environment, interpreting them recognising the context in which the system operates and adapting the system accordingly. The context-aware behaviour can affect both the execution of specific actions and the tailoring of information on the base of the user’s preferences reducing the information noise. The present thesis describes the phases of design of context-aware features and their development to a pervasive middleware called PerLa. Originally conceived only for managing and querying a network of sensors, PerLa has been integrated with functionalities to: 1) define the environment with a suitable model; 2) create a context on the defined model; 3) acquire the sensor readings and external inputs which define a specific context; 4) activate or deactivate a context at run-time depending on the actual values of the context variables; 5) perform the context actions on the system.
Introduction
1.1
Pervasive computing
The aim of developers in creating applications or systems, is the easiness of use for the final user which depends on a number of factors like the intended user, his experience or the technical constraints; the set of these aspects is called the context of use. In earliest days of computing, the context in which systems were used was strongly limited by the place in which computers were set, they did not change easily location, hence, there was no need to adapt to different environments. With the advent of mobile computers and ubiquitous computing, this limitation disappeared as users carried computers with them and used them in many different situations.
In the early 90s, starting with the initial effort of providing the same services to the user independently of his environment, a new approach started to attract the attention of researchers. Bill Schilit [1] introduced the concept of context-aware computing as a software able to adapt itself according to the location of use, nearby people, devices as well as time. In short, a system that can examine, sense the environment and react to changes detected in the environment. The concept of context-awareness expanded and integrated another computing paradigm, presented a couple of years before, called ubiquitous computing.
Widely regarded as the father of ubiquitous computing, Mark Weiser, in his work “The Computer for the 21st Century” [2] envisaged a world where computers would have gradually disappeared into the everyday life background until they would have been indistinguishable from it. Weiser was aware that this vision was, at that time, too far away from becoming reality as in order to achieve such disappearance, technologies had to evolve and produce: cheap, low-power
computers, communication networks and ad-hoc software systems.
Nowadays developments in technologies such as wireless communications and networking, mobile computing and handheld devices, embedded systems, wear-able computers, sensors, RFID tags and similar, have led to make real Mark Weiser’s vision. However, advanced hardware technologies are not sufficient by themselves to fully disappear, technologies have to anticipate the user’s need freeing him from a direct intervention and acting accordingly. This means to be aware of the surroundings, to have a context-aware behaviour.
Ubiquitous computing, or pervasive computing has been one of the fastest-growing research areas. It aimed at creating intelligent environments by embed-ding devices which provide connectivity and services all the time, improving in this way human experience and quality of life. In this environment, the world around us is interconnected as a pervasive network of intelligent devices that cooperatively and autonomously collect, process and transport information, in order to adapt to different situations. An example of a pervasive system is the Wireless Sensors Networks (WSN), a network composed of spatially distributed sensors nodes. Each node is a low-power device that integrates processing, sensing and wireless communication abilities. Sensor nodes acquire information from the surrounding environment, process locally the data, and/or send them to one or more collection base stations. They are useful for the monitoring of physical environment conditions like temperature, pressure, light or location.
1.2
The notion of Context
In order to consider context effectively, it is important to understand what it is and how it can be used. It can be difficult to give a precise definition; in the years, many researchers have considered context differently according to their field of research. In literature, the first attempt of definition was given by Bill Schilit as the location of use, the collection of nearby people, hosts, and accessible devices, as well as to changes over time [1]. A system with these capabilities can examine the computing environment and react to changes in the environment. He developed one of the first pioneer context-aware systems called PARCTAB [3] where he tried to integrate the notion of context to mobile computers used into an office network with the goal of demonstrating the potential for innovation in that area. The device registered the user’s id and rough location and on the base of this data, different information and control choices where available.
In [4] the author Dey complained about the lack of a clear definition with the result that it was difficult to have a clear idea of what context was and how it could be effectively used as a source of information in a real operational application. This was due to the fact that the majority of authors [5] defined context by examples or synonyms and, as consequence, the practical usefulness of these definitions was limited. For this reason, Dey presented his definition: ”Context is any information that can be used to characterize the situation of
an entity. An entity can be a person, place or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves”.
Context enables to guide the user through the vast amount of information that surrounds him by helping him in discriminating what it is important from what can be ignored. Since the amount of information can grow rapidly and generate confusion, information needs to be filtered adequately so that only relevant information is presented to the user. In addition to prevent useless information to be provided to the user, tailoring the data allows reducing the devices’ computational effort and hardware physical constraints in dealing with manageable amount of data. Probably, one of the most significant and widely used context-aware service is Google search engine which returns query results with an order based on many factors like the user’s location, web history and navigation, in a word, his context. Another system that can be considered as context-aware are the automatic lights in a building. The contextual parameters taken into account are the current light conditions and if there is motion in the vicinity. The adaptation mechanism is fairly simple. If the situation detected is
that it is dark and that there is someone moving, the light will be switched on. The light will then be on as long as the person moves, and after a period where no motion is detected, the light will switch off again.
For a human being, context is often implicit (who I am talking to, where I am, what I am talking about), but an application needs a conceptual model to rely on and translate the information into a meaningful context on which to act. A typical context-aware system acquires data gathered from the real world through sensors, processes the data with some perception algorithm on the base of the context model, recognizes in which context it runs and finally it triggers specific actions.
1.3
Thesis objectives and organisation
Researchers have been investigating many issues of context-aware computing: sensing the environment, context modelling, representation, context inference, knowledge sharing and developing tools and architecture to choose the best way to effectively acquire, represent, and make use of sensed data for providing context-aware services to applications. However, developing context-aware middleware is still a great challenge.
This thesis describes the design and implementation of components which provide context-aware services to allow an existing middleware for pervasive systems called PerLa, to be context sensitive. PerLa is a project born at the Politecnico di Milano in 2005 when two students worked on a common thesis about the definition of a language, called PerLa Language, for the interrogation of sensors belonging to a WSN. In the following years, other students collaborated in the implementation of the software needed to manage a network of sensors and to query it by exploiting the PerLa Language. As a result, today PerLa can be fully considered as a language and infrastructure for data management in pervasive systems, able to gather data sensed from various heterogeneous devices, to query them and to easily add a new device to the sensor network. Nevertheless, there is still space for improvement with the addition of new features like energy reduction strategies or the expansion to support context-aware applications, the last topic is the main topic of this thesis. The basic idea is to rely on the data sensed from the underlying sensor network already managed by the existing middleware and used this information to recognize a context and change the behaviour of the devices accordingly.
The rest of this thesis is organised as follows:
• Chapter 2 presents part of the literature concerning the concept of context and some of the most recent and interesting context-aware systems. Then, a full overview of the architecture and main features of PerLa is described which acts as the basis for a fuller understanding of the pervasive system which will be the main actor during the rest of this work.
• Chapter 3 describes the formal context model and language used by PerLa to define and store context data in a machine processable form.
• Chapter 4 and 5 focus on the components which are responsible for the flow of operations required to manage the context-awareness from the building and storing of the context model to retrieve the relevant contextual information which allows to distinguish the context in which the system is operating and finally to execute the actions defined in the active context.
• Chapter 6 contains a simulated and simplified example of a scenario where the context-aware PerLa middleware can be deployed showing the advantages and potential use of this system.
State of the Art
2.1
Contextual Information
Context-awareness represents an important evolution of distributed computing. Awareness of the environment state helps applications to adapt their function-alities depending on context changes without the direct interaction with the user. A system becomes aware of its surroundings when it receives some inputs which make it possible to detect determined situations. It needs contextual information, that is any data gathered at a given point in time from sensors, applications or users, that enables the system to perceive a specific context. Information have many characteristics: it can be static or dynamic, about the past or the present, inconsistent or incomplete due to a faulty transmission and has many alternative representations. Typical questions that a developer must consider before starting to implement a context-aware system concern the choice of the type and number of sensors needed, how often query or retrieve data from the several sources or how to represent different kinds of values trying to make uniform the information in a common format. With regard to the method of acquisition, as suggested by Chen in [6] there are three different approaches: • Direct sensor access. The client software gathers the desired information
directly from sensors; this means that there is no additional layer for gathering and processing sensor data. Due to its tightly coupled nature, this approach is not suitable for distributed systems where there is the need of a component capable of managing multiple concurrent sensor accesses.
• Middleware infrastructure. The middleware-based approach introduces a layered architecture which hides the low-level sensing details and manages
the data retrieval, processes the data, recognize context changes and execute the context behavior.
• Context server. The next logical step is to permit multiple clients access to remote data sources. This distributed approach extends the middleware-based architecture by introducing a remote component, called context server, that is responsible for providing an access point for sharing context data.
2.1.1
Context model
Context-aware applications adapt their behavior to changing context informa-tion gathered from a variety of sources that differ in the quality and type of information they produce. As indicated in [7] there is usually a significant gap between sensor outputs and the type of information that is useful to applications and this gap may be bridged by adequate reasoning techniques and context information processing and modelling. For example, a location sensor supplies raw coordinates, whereas an application is interested in which building or room a user is. A context model has the aim of representing in a compact, but exhaustive method, which environment characteristics, information or data identify and give a meaning to a specific context. The works presented in [8] and [9] give an overview on various common context models, in particular:
• Key-Value: use unstructured set of simple key value pairs to define attributes and their values describing context information, for example [User = ’John Black’, Place = ’Office1’, Time = ’Y’ ]. Due to its simplicity, this model is often used.
• Markup: use a hierarchical data structure consisting of markup tags (like XML tag) with attributes and content to create profiles. This approach extends the key-value model as it also contains the relationship between the stored information, called context features.
• Graphical: use a graphical model which represents context’s elements and their relationships; the standard is the Unified Modelling Language. • Object-oriented: use various objects to represent different types (such as temperature, location, etc.), and encapsulate the details of context processing and representation. Access to the context and to the context processing logic is provided by interfaces
An ontology is the most complete model that guarantee a high degree of expressiveness and semantic richness. The major drawback is the complexity of implementation and the heaviness of reasoning on their facts and entities.
2.2
Short survey of Context-Aware Middleware
During the development of context-aware systems, several challenging require-ments must be taken into consideration such as the location of sensors, the number of possible users, the type and limitations of used devices, the scalability of the system and data acquisition. In order to cope with these challenging requirements, during the past years, many layered context-aware systems and frameworks have been developed, each using several solutions and tools to effectively acquire, represent and reason on sensed and inferred data. Baldauf [10], after the analysis of various design approaches, concludes that, apart from minor differences in functionalities, naming of the main components or the use of optional agents, it is possible to identify a common architecture structured in five layers as represented in Figure 2.1:
Figure 2.1. Layered conceptual architecture for context-aware systems
• Sensors: It consists of every data sources which provide usable context information. The term sensor does not refer only to sensing devices but designated any data source that is able to produce context information. They are usually categorized in physical sensors if they capture physical data, virtual when they provide data from software applications or logical when data is retrieved from databases.
• Raw data retrieval : It is responsible for the retrieval of raw context data by means of appropriate drivers for sensors.
• Preprocessing: It deals with reasoning, aggregation and interpretation of data retrieved by sensors that are not appropriate to be directly used by application designers.
• Storage/Management : It stores and organizes the gathered data and offers them to the client via a public interface. Usually, it is possible to query the system either synchronously by sending a request of asynchronously by subscriptions.
• Application: It implements the actions on different events and context changes.
Based on these design principles, some of the most significant and recent context aware middlewares and frameworks are presented, with a focus on how they follow the mentioned conceptual architecture. A very comprehensive analysis of other projects active in this research field can be found in [11].
Cassowary
Cassowary is a middleware platform for smart buildings that relies on a Software-Defined Sensor Network (SDN) in order to coordinate and connect the smart devices and sensors to a logically centralized controller and messaging broker [12]. The communication used to propagate the details sensed by the sensors of the heterogeneous devices depends on the message oriented middleware (MOM). It designs and builds a sensor network, connecting each of the devices in the smart building.
The goal of Cassowary is to leverage the contextual information derived from the sensor readings to satisfy system requirements such as energy and carbon efficiency, user preferences and to give more control to user tenants. Configura-tion details such as profiles and policies are stored inside an in-memory data store and they are parsed and managed by specific components.
Cassowary has been designed with a layered architecture consisting of two core layers. The network layer, which consists of the SDN controller and data sensors and the appliance layer, which is responsible for the integration and execution of the smart appliances. This means that the network layer groups the conceptual layers Sensors, Raw Data Retrieval and Storage, while the appliance layer corresponds to the Application layer ( 2.2).
Figure 2.2. Cassowary Deployment Architecture
SOCAM
The Service-Oriented Context-Aware Middleware project introduced in [13], is an architecture for building and rapid prototyping of context-aware mobile services. It converts physical spaces into contexts using an ontology-based model that leverages Semantic Web technology and OWL. Architecturally, SOCAM consists of the following components which clearly map to the conceptual architectural layers:
• Context providers abstract useful contexts from heterogeneous sources and convert them to OWL representations.
• The context interpreter provides logic reasoning services to process context information.
• The context database stores context ontologies and past contexts. • Context-aware applications use different levels of contexts and adapt the
way they behave according to the current context.
• The service-locating service (SLS) provides a mechanism so that context providers and the context interpreter can advertise their presence and users and applications can locate these services.
Inter-preter, gathers context data through distributed context providers and offers it in mostly processed form to the clients, the communication between components is implemented using Java RMI.
SOCAM’s key feature is its ability to reason about various contexts and through the reasoning process, high-level contexts can be derived from low-level ones. It also incorporates the notion of uncertain contexts: sensed or deduced context information that is likely, but not definitive. This is realized by introducing a probability measure to predicates that can be reasoned about with Bayesian networks.
CASS
Context-Awareness Sub-Structure (CASS), presented in [14], is a centralized server-based middleware that supports context-aware applications on mobile and other small computers connecting over wireless networks. The middleware supports the use of large numbers of context inputs and provides for high-level context abstractions while placing no additional processing or memory load on constrained mobile platforms. A key feature of CASS is the separation of context based inferences and behaviors from the application code.
Figure 2.3. CASS architecture
In Figure 2.3, the system architecture is presented. The middleware contains an Interpreter, a ContextRetriever, a Rule Engine and a SensorListener. The SensorListener listens for updates from sensors, then the gathered information is stored in the database by the SensorListener. The ContextRetriever is responsible for retrieving stored context data. Both of these classes may use the services of an interpreter. The ChangeListener is a component with communication capabilities that allow a mobile computer to listen for notification
of context change events. Mobile clients connect to the server over wireless networks.
The use of the database makes it easier to handle large volume of data and it has also the key advantage to store not only context, application and user data but also domain knowledge in the form of context awareness rules and behaviors relevant to specific applications. An inference engine uses the rules contained in the knowledge base to find a matching goal when a change in context is detected.
CAMPS
CAMPS [15] is an agent-based middleware that provides support for applications to make use of contextual information in a smart space environment. It consists of individual, collaborating agents:
• Context Wrapper. It acquires various types of raw context data from different sources both physical and virtual, such as software agents. • Context Provider. It abstracts and represents contextual information
using ontologies.
• Inference Engine. It provides an inference mechanism to infer high-level context from low-level data.
• Knowledge Base. It stores inference rules, observed facts and ontologies for context data management and maintenance.
• Query Filter. It provides query interface to upper applications to query or subscribe the context-aware services using a formal query language. As context model, it uses a combination of First Order Probabilistic Logic with OWL ontologies with the aim to reason about imperfect and ambiguous contextual information and to enable context knowledge sharing and reuse.
2.3
Examples of Context-Aware Frameworks
Together with middlewares which usually address a specific situation or environ-ment like smart buildings in Cassowary or mobile devices in CASS, frameworks focus on providing a systematic approach and guidelines that ease the de-velopment for general context-aware applications. Following there are two well-defined example of frameworks.
JCAF
JCAF [16] is a Java-based, lightweight and robust framework which programmers can extend in support of the creation of context-aware applications. JCAF is divided into two parts: a Runtime Infrastructure and API.
The first part consists of a range of Context Services, long-lived processes analog to a J2EE Application Server, which are connected in a Peer-to-Peer setup. Running inside a context service, a small Java program is called Entity and it responds to changes in its context. An Entity with its Context information is managed by the service’s Entity Container. The entity container handles subscribers to context events and notifies relevant clients on changes to entities. The Entity Environment allows communication and access to shared resources among the Entity components in a Context Service. Context Clients can access Entities and their Context information in two ways: either requesting entities and their context data, or by subscribing as an Entity Listener, listening for changes to specific entities.
Figure 2.4. The Runtime Architecture of the JCAF Framework
The JCAF API enables the programmer to create context-aware applications that are deployable in the JCAF infrastructure. A Context Service enables clients to access entities and to set, get, and subscribe to changes in context information for entities. The basic modeling concepts in the JCAF API are a set of core interfaces such as Entity, ContextService, ContextClients and EntityEn-vironment, which developers of context-aware applications must implement. Sentient object model Framework
This framework [17] eases the development of mobile context-aware applications by supporting the application developer in many important aspects such as
providing an abstraction for sensors and actuators, reasoning on contexts, event-based communication between components and an easy visual programming tool for reducing the amount of code written by the developer.
The abstraction of the low-level hardware devices is implemented by the defini-tion of the sentient object model which is an entity with sensors and actuators as its interface, as shown in Figure 2.5. Once sensor inputs are received, the internal control logic is evaluated, consisting of event filtering, sensor fusion and intelligent inference and actuators are activated if needed. The inference mechanism relies on CLIPS (C Language Integrated Production System), an inference engine built into the language which, given a set of facts and rules, is able to decide which rule to fire in different contexts. Sensor fusion addresses the problem of the uncertainty of sensor data and derives higher level context information from multi-modal data sources by employing Bayesian networks. An application designer can use the provided programming model which allows to easily specify sensors, actuators, sentient objects and inference rules.
Figure 2.5. Sentient object model
2.4
The PerLa System
As extensively presented in [18], the PerLa system is a middleware to configure and manage pervasive systems and wireless sensor networks. The development of Perla focused on the design and implementation of the following features:
• data-centric view managing the system as a database where all the data generated by the sensing network are accessible by means of SQL-like query language, called PerLa language;
• homogeneous interface to heterogeneous devices realized my means of a Functionality Proxy Component;
• minimal coding effort for new device addition thanks to a Plug & Play device addition mechanism. After the Perla system receives from a node an XML Device Descriptor (a document containing all the information needed to interact with the already existing sensing network), it autonomously assembles every software component needed to handle the new node.
Figure 2.6. PerLa achitecture
From an architectural point of view, PerLa is composed of different modules that interact, as it is shown in Figure 2.6, where components are divided into two macro-layers:
• Low level support that provides homogeneous API to manage and operate all the different devices that compose the pervasive system;
• High level support that implements data management and query execution services needed to interface end-users and applications with the pervasive system.
2.4.1
FPC
The main software module of the low level support layer is the Functionality Proxy Component (FPC). An FPC is a Java object that provides a functional
abstraction of a given device or a group of them. It is used by other PerLa middleware components to interact with the sensing node itself. The PerLa language is completely oblivious and independent with respect to the hardware and software of the nodes. This means that the language is not tied to any particular type of sensing devices and the types of nodes are not limited to physical ones but also virtual ones like REST services.
The information generated by the sensing node are abstracted as FPC Attributes. They can be used to retrieve the node state (like battery status or memory occupation), to access sampled data (like temperature or pressure) or to change some parameters on the device (sampling frequency, node parameters, etc.). Attributes can be classified in three categories: static, probing dynamic and non probing dynamic. Static attributes represent constant values that describe immutable characteristics of the sensing node. They are commonly used to define properties like device name or location of stationary nodes. Probing dynamic attributes require the interaction of the FPC with the device to produce the value; they can be real sensors (e.g., temperature, humidity) or a real actuator. When a non probing dynamic attribute is read, the FPC returns the value stored in its local cache without an actual reading on the physical device.
A hardware device can host an FPC only if: • it runs a Java Virtual Machine (JVM)
• it is connected to the PerLa Middleware via TCP/IP
The addition of new sensing devices to an existing network is facilitated by a Plug & Play connection system, a runtime factory that generates all the software components needed to query new sensor nodes. The information required to automatically assemble a device driver are stored in a XML file created by the node developer. This file, the Device Descriptor, contains the details all the node’s characteristics in terms of data structures, protocols of communication, computational capabilities, and behavioral patterns. All running queries will automatically make use of every new node added in the system.
2.4.2
Communication
The PerLa middleware deals with the problem of the network heterogeneity (different physical means and communication protocols) with components called Channels. These software modules perform I/O operations and are employed to manage the communication between PerLa and the sensing nodes. Each Channel corresponds to the implementation of an existing communication protocol and it is bundled with a collection of IORequest objects to initiate
I/O tasks on the sensing nodes. For example, the HTTPChannel contains four types of requests, one for each of the principal HTTP methods. To interpret byte streams received from a communication channel, Mapper objects are used for the marshalling and unmarshalling.
2.4.3
Script and Operations
Scripts and Operations bind high-level data requests to processing tasks performed on the remote device. The first objects are programs for interacting with the sensing nodes and for mapping low-level data structures to Attributes generated by an FPC. Operations are entities that regroups one or more Scripts dedicated to a specific purpose. Every Operation is associated with the set of Attributes that can extract or set; there are four types of operations:
• Get: retrieves a single sample from the remote device; • Set: transmits data to the remote device;
• Periodic: periodically retrieves the collection of data samples generated by a node;
• Async: handles the reception of asynchronous events emitted by the node.
Figure 2.7 illustrates the execution flow generated when a user requests some Attributes to a FPC. The FPC selects an Operation which initializes the Scripts, in order to configure the remote device and start the collection of data. The request is marshalled into a Message which travels on the Channel to the physical sensor node. The data sample produced by the sensor travels back and it is then processed by a Script which is tasked with unmarshalling the information and create an output record.
2.4.4
PerLa Language
The other fundamental component is the PerLa Query language, (designed by Marco Fortunato and Marco Marelli in their master thesis [19]) a declarative SQL-like language, to query the system. It has been designed in order to fully exploit the capabilities typical of sensing networks. PerLa queries allow:
• to retrieve data from the pervasive system with Low Level Queries (LLQ); • to define data manipulation operations on streams generated by a LLQ
or other High Level Queries (HLQ). The syntax and semantics of these statements are similar to standard SQL.
Figure 2.7. Execution of a user request in a FPC
• to send asynchronous behavior requests with Actuation Queries (AQ) for setting parameters of the devices or for sending commands to actuators. User queries are received by the Query Parser that parses them and sends them to the Query Executor component that uses the abstraction of the physical nodes (FPCs) to access the Attributes.
2.4.5
Low Level Queries
Low Level Queries define the behavior of every single node or of a homogeneous group of nodes and specify the data selection criteria, the sampling frequency and the computation to be performed on sampled data. When a LLQ is injected into the system, the set of FPCs possessing the requirements to execute it is computed and an instance of the query is deployed on each element of the set. Data produced are stored in a database with the possibility of further manipulation or sent to the user or to the component who requested it.
A LLQ can be:
• a creation statement that defines the name of the data structure to be created and the list of fields (it is similar to the CREATE TABLE in SQL)
• an insertion statement that defines the destination data structure and the real query to be done on the sources
• a general selection statement that expresses the query to be sent to the nodes
The selection statement has the role of specifying when data should be collected from the logical object acting as a query source and how it is manipulated to produce output records. The grammar for producing a selection statement is shown in the Listing 2.1. Notice that the square brackets are used for optional clauses and the notation of a clause is <Name Clause>.
< E v e r y Clause > < S e l e c t Clause > [ < G r o u p By Clause >] [ < Up To Clause >] [ < H a v i n g Clause >] [ < On E m p t y S e l e c t i o n Clause >] < S a m p l i n g Clause > [ < E x e c u t e If Clause >] [ < T e r m i n a t e A f t e r Clause >]
Listing 2.1: LLQ Selection Definition
A low level query can be decomposed in three main blocks: • Data management section
• Execution conditions section • Execution conditions section
The SELECT clause specifies which data (FPC’s Attributes) have to be col-lected from the sensing network and how they have to be aggregate to produce some records as result. Ideally, the selection should be executed on the local device buffer that is infinite, which it is simply impossible. To overcome this problem, in the SELECT clause it is required to specify the attribute on which the aggregation should be computed and the duration of a number of records
which represents the portion of the buffer used to calculate the aggregation. The UP TO clause allows retrieving more than one record from the local buffer, default is 1 record. The GROUP BY clause allows a grouping of the records in the local buffer before the selection process, described above, is computed. The HAVING clause allows a filtering operation on the records identified by the UP TO clause, before output records are produced. This last clause may produce an empty result record so, the EMPTY SELECTION clause is useful to allow the user to specify the behavior of the query when the selection process doesn’t produce any output record.
The Sampling section specifies when the sensors must be sampled for the reading of the attributes specified with the SELECT clause. The obtained record is inserted into the node’s local buffer and it is transferred to the central server when the EVERY clause is triggered. Two types of sampling are supported:
• event based that allows the acquisition of a data sample each time a specific event is triggered
• time based that are employed to collect data at periodic intervals
The SAMPLING event based clause can be completed appending a WHERE clause, that allows the definition of a filtering condition. If specified, this condition is evaluated whenever a record is produced, before the insertion into the local buffer. If the condition is not satisfied the record is discarded.
The Execution conditions section defines the rules to establish the set of logical objects that will participate to the execution of the query. The rules usually consider which sensors the device possesses, so that the selection of a specific attribute, for example temperature, will be requested only to the FPCs that have a temperature sensor. The last clause is the TERMINATE AFTER one, that can be used to set the timeout after which the query will stop.
The selection statement may seem quite complex as it is composed of many clauses. However, some of them are optional and most of the common queries do not require all the clauses. The simplest query, in fact, a user can write contains only the EVERY, SELECT and the SAMPLING clauses.
The following query initiates a temperature sampling operation on all temper-ature sensors located in room number five. Data records are produced every 1 minute and stored inside the device’s local buffer. The MAX aggregation expression is evaluated on the temperature values collected in the previous 10 minutes of sampling.
This query performs a 10 minutes monitoring of the tag with ID [tag]. At the end, it inserts a single record in an output stream to report how many times
C R E A T E O U T P U T S T R E A M T a b l e ( T e m p e r a t u r e F L O A T ) AS : E V E R Y 10 M I N U T E S
S E L E C T MAX ( temp , 10 M I N U T E S ) S A M P L I N G E V E R Y 1 M I N U T E
E X E C U T E IF E X I S T S ( t e m p ) AND E X I S T S ( r o o m ) AND r o o m = 5 Listing 2.2: Example of a Create PerLa Query
the tag was sensed by the reader with ID [reader]. The one shot behavior is managed by the TERMINATE clause that requires the execution of the selection process only once.
C R E A T E O U T P U T S T R E A M T a b l e ( c o u n t e r I N T E G E R ) AS E V E R Y 10 m S E L E C T C O U N T (* , 10 m ) D E F A U L T 0 ON E M P T Y S E L E C T I O N I N S E R T D E F A U L T S A M P L I N G ON E V E N T l a s t R e a d e r C h a n g e d W H E R E l a s t R e a d e r I D = [ r e a d e r ] E X E C U T E IF ID = [ tag ] T E R M I N A T E A F T E R 1 S E L E C T I O N S
Listing 2.3: Example of a Selection PerLa Query
2.4.6
Java object representation of the Query Language
Starting from the grammar, a Java object structure of the query has been implemented. A complete description of the classes and methods is beyond the scope of the present work, but a synthetic exposition is necessary to better understand the entire PerLa System.
The QueryParser receives the textual query from the user, parses it, performs syntactic checks and some preliminary semantic ones and eventually generates the specified Java code. Since it is hard to monitor all the faults during the query parsing, the QueryParser first generates a set of temporary objects. In this way, it is possible to have a full view on the query and secondary inconsistency checks are performed which result in the creation of the final and valid objects. The resulting query is represented by a general interface Statement which is implemented by the four type of available query: CreationStatement, Inser-tionStatement, SelectionStatement and SetStatement. Each Statement is a container for all the optional and mandatory clauses that appear in a query. The following UML diagram quickly shows the fields and main method of a
SelectionStatement. The object names immediately evoke the corresponding clauses that represent.
Context-Awareness at Design
Time
3.1
Context-aware system overview
A system becomes context-aware when it is able to recognize and distinguish among contexts and act accordingly. Generally, the identification of contexts is done in stages. At design time it is necessary:
• to analyse the environment in order to choose the characteristics rele-vant for the application and identify the possible situations (the feasible contexts) the system may incur in.
• to link the actions that will be executed and the data that may be re-quested once a context is recognized as active;
At run time the system must:
• sense the context with physical measurements from the environment and virtual inputs sent from various software modules. For instance, a temperature sensor gives us a room’s temperature and a request to a REST service gives us the day’s weather.
• recognize the context transforming the values and data received in the previous phase into contextual information. For example, the temperature reading can be transformed into “Hot” or “Cold” which is the symbolic value associated with the temperature the sensor has sensed.
corresponds to a defined context and, in that case, label the context as active.
• execute the actions defined in the active context.
3.2
Initial steps for a Context-Aware PerLa
As the original PerLa was unable to deal with context, starting from the idea of “pushing” context knowledge to the PerLa middleware, the authors in [20] presented an initial design of two features:
• an extension of the existing PerLa language syntax, called Context Lan-guage (CL), in order to declare the CDT context model (presented in the following section), the contexts as well as the actions to be performed accordingly;
• the Context Manager (CM), a component able to maintain and manage the declared CDT, detect active contexts and performs the desired actions accordingly;
From this initial design, a real implementation has been developed and will be presented during the rest of this thesis.
3.3
Context Model
A well-designed context model plays an important, probably fundamental, role to represent and access the context in any context-aware systems. In our approach, an original context model was used, called the CDT. Presented in the work “CARVE: Context-aware automatic view definition overrelational databases”
[21], the CDT is a formal description of the environment characteristics which extends the key-value context model.
3.3.1
The basic structure of the context model
As implied by the name, the CDT describes the environment in a structured labeled tree composed of two different types of nodes: dimension and concept. A dimension node expresses an environment characteristic and it has as chil-dren concept nodes which represent the set of possible values the dimension can assume. Both dimensions and concepts can be enriched using attributes. Graphically a dimension node is colored in black while a concept node in white. The designer can increase the granularity of the scheme by expanding nodes with the only constraints that every dimension can only have concept children
and vice-versa. This approach combines the simplicity of representing the environment with the sensibility of the designer who can add more levels in order to explore some aspects of the CDT more in depth.
The constraint in the CDT definition is graphically visible as the node colors alternate starting from the root and descending. Attributes are represented as square nodes.
To denote that a dimension has assumed a certain value we use the notation <Dimension = Value>
called a context element.
A context is formalized as the conjunction of one or more context elements and it can graphically be seen as choosing subsets of the initial CDT. It is important to underline the fact that not all possible subsets are valid contexts, as a matter of fact it is not possible to use more than one concept children of one dimension in the context definition. This logic constraint simply means that an environment feature can only assume one single value from the set of its possible values.
Moreover, the designer can specify the context element combinations that are not significant and which represent semantically meaningless context situations or are irrelevant for the application. This constraint, called useless context constraint is represented by a line linking the concept nodes that cannot appear in the condition which defines a context.
According to the CDT authors, this context model is flexible and well supports the designer in the definition of the elements that affect data selection in different situations.
3.3.2
Example of a CDT
An example of usage will clarify the concepts previously presented, taken from [22], where it was adopted to model a wine monitoring scenario. With the data collected from sensors is possible to control the factors involved in the delicate production process and prevent possible risks that endanger the quality of the final wine. The production can be divided in three main phases: the grape’s growth and maturation, the ageing of the wine and the transport to the final users. Each of these phases is influenced by external agents.
For example, in the vineyard, humidity and temperature values or parasites attacks concur in the development of wine flavour. On the basis of these
considerations, it is easy to identify the main environment characteristics relevant for the situation: Phase, Risk and Role dimension. The Phase reflects the separate stages of the wine production process (Growth, Ageing and Transport) while Role expresses which actors are involved (Farmer, Driver or Oenologist). The Risk dimension models a feasible threat to which the wine may be exposed: Overheat from overexposure to sunlight or a Disease from bacterias. The Disease can be further analyzed considering its Type or the Affected hectares.
The resulting CDT is shown in the Figure 3.1.
Figure 3.1. An example of CDT Schema
Knowing that the Driver is never involved during the Growth Phase, the combi-nation of these elements is meaningless and pointless for a context condition. For this reason, the designer can graphically express this useless constraint by drawing a line between the concept nodes that cannot appear in the same context definition, as shown in Figure 3.2.
Figure 3.2. An example of useless context constraints
Among all possible contexts, we can consider Frost Alert and the Transport -Monitoring ones that are particularly important for the wine monitoring example.
The first context is used in the first phase of the production process: temperature and humidity are critical attributes that must be kept under constant control by the farmer. The second context is relevant for the transport phase. The bottled wine must not be kept under direct sunlight for more than a certain amount of time in order to avoid overheat and a consequent alteration of the wine flavour. Formally:
Frost Alert = (Role = Farmer) ∧ (Phase = Growth) ∧
(Risk = Frost)
Transport Monitoring = (Role = Driver) ∧ (Phase = Transport) ∧
(Risk = Overheat)
3.4
Context Language
The syntax of the Context Language has been divided into two parts: • CDT Declaration for the definition of the CDT,
• Context Creation for the creation of a context.
3.4.1
CDT Declaration
With this part of the language, the designer defines the CDT, by listing all the dimensions of interest for the application together with the values they can assume. The syntax, slightly different from the original version, is shown in the Listing 3.1. C R E A T E D I M E N S I O N < D i m e n s i o n _ N a m e > [C H I L D OF < P a r e n t _ N o d e >] [C R E A T E A T T R I B U T E $ < A t t r i b u t e _ N a m e > [E V A L U A T E D ON " < P e r l a _ Q u e r y > " | AS < F u n c t i o n > ] | {C R E A T E C O N C E P T < C o n c e p t _ N a m e > [W H E N < C o n d i t i o n >] [E V A L U A T E D ON " < P e r l a _ Q u e r y > " ] [W I T H E N A B L E C O M P O N E N T: " < P e r l a _ Q u e r y > " ] [W I T H D I S A B L E C O M P O N E N T: " < P e r l a _ Q u e r y > " ] [W I T H R E F R E S H C O M P O N E N T: " < P e r l a _ Q u e r y > " ] [C R E A T E A T T R I B U T E $ < A t t r i b u t e _ N a m e > E V A L U A T E D ON " < P e r l a _ Q u e r y > " | AS < F u n c t i o n >]* }* Listing 3.1: CDT declaration syntax
The intuitive syntax eases the CDT definition by means of creation clauses for the dimension and its concepts. The CREATE DIMENSION clause is used to add a new dimension identified by a unique symbolic name and by a concept father node. As the CHILD OF clause is optional, if no father node is specified, the dimension is a direct child of the tree root. A dimension can have a single attribute or one or more concept children.
The CREATE ATTRIBUTE clause adds an attribute to a dimension or a concept. An attribute is a parameter whose value can be evaluated at run time or retrieved as a static system value. In the first case, the designer specifies with the EVALUATED ON clause the query that the system will inject at run time to estimate the attribute numeric value. It is worth mentioning that from the CDT parser point of view, the Query is treated as a constant string that will be parsed by the Query Language Parser. In the second case, the non terminal <Function>has been introduced to allow the user to call an external function from the language. A function can have an arbitrary number of parameters and the designer is tasked with the definition of the set of external functions and their implementations.
The CREATE CONCEPT clause creates a concept object identified by a symbolic name. Because the concept represents a value a dimension can assume depending on the occurrence of a condition, such condition is expressed in terms of numeric observables with the WHEN clause. These numeric observables must map to existing sensor features, the Attributes, of the FPC’s or to existing methods. The EVALUATED ON clause allows to specify with a query how the condition must be evaluated and to limit the number of nodes involved in the Query execution to the devices with special features.
The designer should always make use of the EVALUATED ON clause as it is useful in two important aspects. On one hand it allows saving energy and computational power of the sensing nodes as the condition is evaluated only on the specified nodes. On the other hand, it allows the user to inject an aggregation query that considers not just the single value of a node, useless in a distributed environment, but a combined significant value.
An example should clarify these advantages:
C R E A T E D I M E N S I O N T e m p e r a t u r e
C R E A T E C O N C E P T Hot W H E N t e m p e r a t u r e > 35
E V A L U A T E D ON " S E L E C T MAX ( T e m p e r a t u r e ) E X E C U T E IF E X I S T S ( t e m p e r a t u r e ) "
The designer creates a dimension Temperature and the concept Hot with the condition that the temperature must be greater than 35 degrees. By specifying the clause evaluated on, the designer tells the system that the condition must be evaluated only on devices that have the temperature sensor. Moreover, for the designer is enough that a single device senses a temperature over 35 degrees to make the dimension Temperature assumes the value Hot.
Since to explicitly define all EVALUATED ON clauses for the concepts is demanding for a designer, the system provides a default one. The condition is evaluated on all network devices possessing the sensor for the desired Attribute and it will compute the average of the sensed samples (in this case the average temperature). This design choice has been made because it makes sense that the designer is generally interested in average values, like the average temperature in a room, and he has the task of specifying detailed clauses only in special scenarios. The only constraint is that the clause must contain only a Select Statement from the PerLa Query Language as the other statements (Create, Set and Insertion) are not evaluable conditions.
The role of the clauses WITH ENABLE, WITH DISABLE and REFRESH COMPONENT will be explained in the next section.
Finally, a concept can have one or more attributes created with the same logic of a dimension attribute.
During the parsing of a user CDT declaration, the following semantic controls are performed:
• two dimensions cannot have the same symbolic name;
• two concepts children of the same dimension cannot have the same sym-bolic name;
• attributes of concepts of the same dimension cannot have the same sym-bolic name;
• existence check of the declared function calls;
• a dimension chooses only existing concept nodes as the “parent node”; • parsing and validation of queries expressed with the EVALUATION ON,
3.4.2
Context inference
The most delicate phase in the CDT definition is the association to a WHEN clause to each concept. Practically, the clause expresses the inference process needed to translate raw data coming from the sensor network to the symbolic concept value.
As said in the previous chapter, raw data gathered from context inputs are rarely directly useful for an application mainly for two reasons. On one hand the system must account for uncertain data, especially when context data are produced by sensors or acquired from external sources that can be intermittently connected to the network. Therefore processing of raw data should discard a single reading coming from a single sensor and instead considering aggregate data coming from a set of sources, possibly applying techniques such as noise reduction or mean calculation in order to produce higher quality data.
Data collected must then be extracted, catalogued into conceptual information. In the CDT model, this transformation is possible with the use of the WHEN condition and the associated EVALUATED ON clause. Used in combination, they are an effective way of combining the symbolic high level concept value with the physical computation of low level data. The conversion is performed by means of a suitable query PerLa.
3.4.3
Context creation
With the syntax in the Listing 3.3, the designer can define as many contexts as desired. He only needs to choose a suitable name and declare the ACTIVE IF condition in terms of a conjunction of dimensions belonging to subtrees of the previously declared CDT.
In particular, a condition can use pairs • <Dimension = Value>
• Dimension.Attribute OP expression where “OP” indicates an operational operator.
C R E A T E C O N T E X T < C o n t e x t _ N a m e > A C T I V E IF < D i m e n s i o n > = < Value > [AND < D i m e n s i o n > = < Value >]*
During the parsing of the creation of a context, some logical controls are performed:
• a context must have a unique name;
• every dimension, concept and attribute used in the ACTIVE IF condition must refer to an existing object in the CDT;
• the ACTIVE IF condition must be well defined this means that it does not contain the useless contexts constraints neither brother concept nodes.
3.5
Partial components
In the early stages of the context creation syntax design, the language was virtually divided into four block components: activation, enable, disable and refresh.
Figure 3.3. Contextual block components
The activation component corresponded to the still existing ACTIVE IF clause. The other components allowed the designer to express which actions, expressed in terms of PerLa queries, the middleware had to perform when the context was active, when it stopped to be active and how frequently the system had to check the ACTIVE IF condition.
So, it was up to the designer to explicitly list the actions and the refresh period with dedicated clauses for each context. However, it soon became evident that this approach had scalability limits due to the possible high number of contexts. In particular, the total number of contexts grows exponentially with the number of nodes, and, even for middle-sized CDTs, the task of declaring all the con-texts using the aforementioned syntax would become rapidly unfeasible for the designer. As a result, a new strategy has been adopted: instead of considering the activation, deactivation and refresh blocks as monolithic block for each context, they can be divided into smaller blocks called partials. This separation
is possible thanks to the precise syntax of the PerLa Language which allows deconstructing a complex query into smaller queries, as shown in Figure 3.4.
Figure 3.4. Division of the enable component into enable partial components
Even if the division is very significant for ENABLE and DISABLE components, also the REFRESH component can be associated with its own partial refresh component, although formed only of the REFRESH clause.
Having introduced the concept of partials, it is now possible to give an expla-nation of the role of the WITH ENABLE COMPONENT, WITH DISABLE COMPONENT and WITH REFRESH COMPONENT clauses, which was post-poned from the previous section. The intent of these clauses is to give the designer the chance of associating smaller PerLa Queries for each concept that will be automatically composed and assembled by the system. These clauses are optional because it is not necessary that every context element should be associated with each partial component. In case of absence, the missing components are considered as formed by empty clauses.
How the system performs the composition of the context blocks will be explained in Chapter 5.
3.5.1
CDT Declaration example
Referring to the CDT shown in Figure 3.4, a possible grammar definition is presented focusing first on the listing of all dimensions and relative concepts and attributes. As the reader can see all concepts and attributes are associated with a suitable expression that associate their symbolic name to numeric observables that can be measured from the environment or retrieved from other sources.
C R E A T E D I M E N S I O N R o l e C R E A T E C O N C E P T F a r m e r W H E N g e t U s e r R o l e () = ’ f a r m e r ’ C R E A T E C O N C E P T O e n o l o g i s t W H E N g e t U s e r R o l e () = ’ o e n o l o g i s t ’ C R E A T E C O N C E P T D r i v e r W H E N g e t U s e r R o l e () = ’ d r i v e r ’ E X C L U D E S P h a s e . G r o w t h /* U s e l e s s c o n t e x t c o n s t r a i n t */ C R E A T E D I M E N S I O N R i s k C R E A T E C O N C E P T D i s e a s e W H E N g e t I n t e r e s t T o p i c () = ’ d i s e a s e ’ C R E A T E C O N C E P T O v e r h e a t W H E N t e m p e r a t u r e > 30 AND b r i g h t n e s s > 0 . 8 0 C R E A T E C O N C E P T F r o s t W H E N t e m p e r a t u r e < 5 AND h u m i d i t y > 0 . 7 5 C R E A T E D I M E N S I O N T y p e C H I L D OF D i s e a s e C R E A T E A T T R I B U T E $id AS g e t I d D i s e a s e () C R E A T E D I M E N S I O N A f f e c t e d _ h e c t a r e s C H I L D OF D i s e a s e C R E A T E A T T R I B U T E $ s q u a r e _ m e t e r s AS g e t S q u a r e M e t e r s () C R E A T E D I M E N S I O N P h a s e C R E A T E C O N C E P T G r o w t h W H E N g e t P h a s e () = ’ g r o w t h ’ E X C L U D E S R o l e . D r i v e r /* U s e l e s s c o n t e x t c o n s t r a i n t */ C R E A T E C O N C E P T A g e i n g W H E N g e t P h a s e () = ’ a g e i n g ’ C R E A T E C O N C E P T T r a n s p o r t W H E N g e t P h a s e () = ’ t r a n s p o r t ’
Listing 3.4: CDT declaration of the wine production monitoring
Following, some fragments that integrate the CDT definition are listed for the sake of completeness.
The frost phenomenon is known to show itself when the temperature is near 0oC and the amount of water vapour in the air is significantly high, so the dimension Risk assumes the value Frost whenever the temperature decreases below 5oC and the humidity in the air is over 75%. This query evaluates the average value of temperature and humidity of the last 10 minutes samples in order to remove unwanted noise. If the frost condition becomes true in an active context, the Query PerLa defined with the ENABLE clause increases the sampling rate.
C R E A T E C O N C E P T F r o s t W H E N t e m p e r a t u r e < 5 AND h u m i d i t y > 0 . 7 5 E V A L U A T E D ON ’ E V E R Y ONE S E L E C T AVG ( h u m i d i t y :10 m ) , AVG ( t e m p e r a t u r e : 10 m ) S A M P L I N G E V E R Y 1 m E X E C U T E IF E X I S T S ( h u m i d i t y ) OR E X I S T S ( t e m p e r a t u r e ) ’ W I T H E N A B L E C O M P O N E N T: ’ E V E R Y ONE S E L E C T MAX ( h u m i d i t y ,5 m ) , MAX ( t e m p e r a t u r e ,5 m ) S A M P L I N G E V E R Y 1 m E X E C U T E IF E X I S T S ( h u m i d i t y ) OR E X I S T S ( t e m p e r a t u r e ) ’ W I T H R E F R E S H C O M P O N E N T: 15 m
Listing 3.5: Concept Frost definition
The overheat risk may appear when the wine is exposed for a long time under the sunlight so that the temperature increases to more than 30oC. In this event, it is best to raise a warning signal by setting an overheat alarm to true. When the risk is no longer present, the alarm can be turned off. The REFRESH clause states how often the context condition definition that includes the Overheat concept must be evaluated.
C R E A T E C O N C E P T O v e r h e a t W H E N t e m p e r a t u r e > 30 AND b r i g h t n e s s > 0 . 8 0 E V A L U A T E D ON ’ E V E R Y ONE S E L E C T AVG ( t e m p e r a t u r e :10 m ) , AVG ( b r i g h t n e s s : 10 m ) S A M P L I N G E V E R Y 1 m E X E C U T E IF E X I S T S ( t e m p e r a t u r e ) OR E X I S T S ( b r i g h t n e s s ) ’ W I T H E N A B L E C O M P O N E N T: ’ SET o v e r h e a t _ a l a r m = t r u e ’ W I T H D I S A B L E C O M P O N E N T: ’ SET o v e r h e a t _ a l a r m = f a l s e ’ W I T H R E F R E S H C O M P O N E N T: 15 m
Listing 3.6: Concept Overheat definition
C R E A T E C O N C E P T G r o w t h
W H E N h u m i d i t y > 5 AND t e m p e r a t u r e > 0 . 7 5
E V A L U A T E D ON ’ E V E R Y ONE S E L E C T AVG ( h u m i d i t y :10 m ) , AVG ( t e m p e r a t u r e : 10 m ) S A M P L I N G E V E R Y 1 m E X E C U T E IF E X I S T S ( h u m i d i t y ) AND E X I S T S ( t e m p e r a t u r e ) ’ W I T H E N A B L E C O M P O N E N T: ’ E V E R Y ONE S E L E C T MAX ( h u m i d i t y , 5 m ) , MAX ( t e m p e r a t u r e , 5 m ) S A M P L I N G E V E R Y 1 m E X E C U T E IF E X I S T S ( h u m i d i t y ) AND E X I S T S ( t e m p e r a t u r e ) ’ W I T H R E F R E S H C O M P O N E N T: 15 m
During the Growth Phase, the wine process monitoring requires to collect temperature and humidity from all the nodes located in the vineyard storing their values in a suitable table (Listing 3.7).
The context listed in section 3.3.2 is translated with the formal syntax.
C R E A T E F r o s t _ A l e r t
A C T I V E IF R o l e = F a r m e r AND P h a s e = G r o w t h AND R i s k = F r o s t
Listing 3.8: Context Frost Alert definition
C R E A T E C O N T E X T T r a n s p o r t _ M o n i t o r i n g
A C T I V E IF R o l e = D r i v e r AND P h a s e = T r a n s p o r t AND R i s k = O v e r h e a t
Listing 3.9: Context Transport Monitoring definition
3.6
Final consideration
In this chapter the necessary steps to add context-awareness to a system at design time have been illustrated. Since an application needs more meaningful and higher level information rather than raw data gathered directly from sensors, it is advisable to create a context model. The context model should represent: the relevant characteristics of the environment, how the combination of these characteristics maps to a defined context and specific behavior to raise when a context is detected as active. The context model chosen for PerLa is the CDT, a powerful yet simple tool that allows representing the main features of the environment playing with the adding of new sub-dimensions and concepts. Although this flexibility allows exploring more in detail some aspects, it may lead to a very high number of contexts which are not actually used or significant. Even if the use of constraints reduces the number of admissible contexts, still the cardinality of the valid contexts with respect to the most used ones is a limitation. The only solution is to rely on the designer’s expertise in grasping a deep understanding of the environment so that he can balance between the right level of detail and the right number of dimensions most appropriate to the several application cases.
