In order to provide an efficient use of energy in buildings, the IMPReSS Systems Development Platform (SDP) must know what happens inside the buildings so that opportunities to save energy can be identified and effectively fulfilled. In other words, the IMPReSS SDP must be context aware.
The IMPReSS SDP is divided into IDE and Middleware, where the IDE contains a series of GUI modules and the Middleware contains modules with background management responsibilities for their IDE counterparts. The IMPReSS Middleware consists of four main modules: a Context Manager, a Data Manager, a Resource Manager, and a Communication Manager. In this article we will describe the Context Manager in more detail.
IMPReSS Context Manager Architecture
The IMPReSS Context Manager encompasses all background software components that a typical context-aware middleware offers to its users, such as context templates, context models, context reasoning engine, and algorithms for sensor and data fusion. It also interacts with storage modules to be able to store and retrieve context data. Resources might be accessed directly or preferentially through the Resource and Communication Managers.
Based on research of the state of art in context modelling and reasoning, the design of the IMPReSS Context Manager architecture is based on object-oriented context modelling and rule-based context reasoning. The figure below shows the Context Manager architecture and its relationships with other components of the IMPReSS architecture:
The IMPReSS Context Manager Architecture
As illustrated in the figure, the Context Manager Architecture can be divided into two main planes inside the IMPReSS Middleware, namely Control Plane and Event Plane. The Control Plane comprises the two main components that operate in real time, i.e. the Fusion and the Reasoning module, receiving and processing data coming from sensors and sending commands to actuators. The Control Plane comprises modules for context template configuration, storage and notification, which are needed for the features of the event plane to work properly.
The IMPReSS Context Manager Modules
The IMPReSS Context Manager consists of nine modules. A summary description of three of the modules is presented here. A complete description of the IMPReSS Context Manager Architecture and the modules in the figure can be found in the deliverable D6.3 Context Manager Framework Architecture and Design of Context Templates which is available for download via the
project website.
Context API: The Context API is part of the IMPReSS Middleware API and exposes an interface, allowing other modules, both belonging to the IDE and Middleware, to interact with the Context Manager. Through the Context API the entity templates are configured in the Context Storage. The Context Manager learns about Resources through the Context API used by the application in the IMPReSS IDE.
Reasoner: The Context Reasoner is the piece of software able to infer logical consequences from a set of asserted facts. The Reasoner performs its function by reading entities from the Context Storage, i.e. Entity Templates such as Rule, Place, Resource and Action. Having all entities, whenever it is invoked with a set or parameters it searches the entire set of rules for a match. In some situations the Reasoner may find two or more rules that match the parameters, i.e. there may be a rule conflict. Whenever a conflict happens, the Reasoner must select only one rule to be executed based on some conflict resolution mechanism. The Reasoner is invoked by the Fuser whenever Fusion criteria are met. As a result of firing a rule, one or more actions are performed and they usually refer to changing the configuration of devices or equipment for dynamically adapting behavior, e.g. turning off an elevator or lowering the temperature of an air conditioner.
Fuser: This module is responsible for data fusion, i.e. a set of techniques that combine data from multiple sources such as sensors and gather that information in order to achieve inferences, which will be more efficient and potentially more accurate than if they were achieved by means of a single source. The Fuser is directly connected to the Communication Proxy for receiving real time sensor data and when fusion criteria are met it activates the Reasoner and stores the fused results in a data storage using the Data Proxy. Multiple fusion criteria may be active concurrently and therefore this module plays a key role for the performance of the Context Manager, because in a real scenario hundreds or thousands of sensors may send data values with a high frequency. The Fuser reads the fusion criteria from the Context Storage and that is how it finds out which data must be requested from the Communication Proxy. Whenever a new fusion criteria is configured the Fuser registers the corresponding resources to be monitored, e.g. sensors, in the Communication Proxy and the latter starts sending data to the former.
More information
The IMPReSS Context Manager, including a definition the entities and their templates for context modelling of energy efficiency scenarios and implementation guidelines, is described in detail in D6.3 Context Manager Framework Architecture and Design of Context Templates. Please visit the project website for access to the deliverable.
to
the top
|