6 deus leaflet wp5
0 likes260 views
The Deus platform aims to handle data from wireless sensor networks in a distributed manner. It uses ontologies and semantic web technologies to classify sensor data and deal with issues like missing or faulty readings. A key challenge is the quality of unpredictable sensor data. The Deus architecture includes distributed reasoning, a service registry, and a policy framework to label data quality and determine appropriate actions. It was implemented and tested on a realistic sensor network, showing it can draw more accurate conclusions than without the quality control measures.
6 deus leaflet wp5
- 1. DEUS Deployment and Ease Use of wireless Services Pervasive reasoning platform for WSMN Main challenges Deus targets a service platform capable of dealing with geographically dispersed systems connected through a Wireless Sensor and Mesh Network. The platform uses a variety of devices and delivers services that cross device, platform and system administration boundaries. Efficient handling and quality-aware processing of the enormous amount of data coming from a wireless sensor network (WSN) is extremely difficult: data samples are often lost during transmission, many irregular and faulty measurements are produced, and sensor nodes are frequently unavailable. Figure 1 illustrates a temperature management application that drives an air conditioning system based on temperature samples from the WSN installed in a building. Given the unpredictable and unreliable nature of WSNs, the application must specify and enforce quality requirements: (1) the maximum period between consecutive samples, (2) the minimum coverage (#samples/#available nodes) per room, or (3) the maximum deviation from previous samples from the same sensor. Deus approach: The adoption of ontology technology supported by distributed reasoning mechanisms facilitates transparent monitoring in this heterogeneous environment. The concept definitions in the ontology and the rules according to which nodes and the environment variables need to classified can be changed according to the locally deployed hardware, specifications and environment. The developed platform demonstrates that, by introducing intelligent and advanced technologies, such as ontologies and principles from the Semantic Web, great improvements can be achieved both in extendibility and maintainability. Changes over time to classification rules are easily implemented through adaptation of the ontology deployed on the mesh nodes. New hardware can also be included with minimal effort if new ontology graphs are created modelling the new hardware. The inclusion of this new information, or the adaptation of local rules based on the local environment is achieved transparently for the monitoring application. Observations from a realistic test bed (iLab.t Wireless Lab) confirm the need for quality control and show that aggregating faulty temperature samples can be highly problematic for the aggregated end result.
- 2. DEUS Deployment and Ease Use of wireless Services To handle this problem, we studied and evaluated an approach to attach quality labels to suspicious data samples. By describing (1) patterns of interest, (2) logic that associates these patterns to application specific quality requirements, and (3) actions to pursue in case of a positive match, we can resolve the problems stated above; in addition, by handling the problems at the spot where they occur (for example dropping data) we can avoid unnecessary (and power consuming) network communication. Figure 1: The Quality of Data problem Deus solutions: A distributed platform needs a mechanism to deploy and connect collaborating agents that run on the different processing nodes. Deus uses a service registry, advertisement and discovery service that is based on an enhanced nameserver. The naming service should support the dynamicity, abundance and transient behaviour of sensor devices. There are two steps in the discovery process. First the necessary information needs to be fed into the discovery service. Secondly, entities needing to find devices/services should be able to query the available information. An important aspect is the maintenance of the information managed by the discovery service. The information in the discovery service needs to reflect the actual status of the published devices/services. The best way to achieve this is by assigning a lease period to the published information. The standard DNS service has already most of the properties that are needed for a naming and discovery service, except for 2 features: • In DNS all inserted entries need to be explicitly removed • DNS has no notification system By extending the DNS server with a frontend supporting “lease time”, we are not forced anymore to explicitly remove entries. By extending it with DNS Long Lived Queries (LLQ), we implement a kind of subscription mechanism for DNS that solves the notification problem.
- 3. DEUS Deployment and Ease Use of wireless Services The building blocks of the architecture presented in Figure 2 that are related to the reasoning functionality are the Reasoning Distribution Module and Reasoning Engine Module. Additionally, to improve the transparency to the outside world, an extra indirection layer has been included at the interface level, namely the Interface Module. This layer is introduced to facilitate multiple reasoning technologies without the need for the clients to be aware of this. As such, only generic interface operations should be defined, avoiding the use of reasoning technology dependent query and invocation mechanisms, e.g. SPARQL. Additionally, to decouple the reasoning from the data storage, two extra modules are introduced, namely the Data Provider/Resource Module and the Aggregator Module. The Data Provider/Resource Module will collect the data from the resources on which it has been deployed or for which it is responsible and feed it to the Aggregator Module. Upon request of the Reasoning Engine Module, the Aggregator Module will feed this collected data to the reasoning process. This way of working allows including sensor devices in the workflow and thus facilitates the monitoring of the sensor network, by means of sensor information generated from the Data Provider/Resource Modules deployed on the sensor devices. Figure 2: Distributed Reasoning Architecture
- 4. DEUS Deployment and Ease Use of wireless Services Figure 3: Distributed Reasoning Workflow The Quality of Data aspects are covered in the architecture by means of a policy-based approach based upon two key elements (see Figure 4): • a component model that allows for easy inspection of data flows between components that compose applications. • a policy framework that allows for fine-grained control of data flows and ensures that relevant policies are enforced on the data passing between a pair of components. In this context, various Event-Condition-Action (ECA) policies can be defined to describe the actions to take when a particular pattern is recognized in the data flow between two components; each policy can be dynamically installed, uninstalled, enabled, and disabled.
- 5. DEUS Deployment and Ease Use of wireless Services Figure 4: The Quality of Data policy framework Deus Proof-of-Concept implementation: The DEUS naming and discovery server is using the Apple implementation (dnsextd) of update leases and long lived queries. This implementation uses a front-end to a regular BIND dynamic DNS server. The regular DNS server listens on a non-standard UDP/TCP port and only accepts updates coming from the front-end server. This front-end server listens on the regular DNS UDP/TCP port 53. All regular DNS queries are forwarded to the regular DNS server. The dynamic DNS server is authoritative for a domain within the DNS hierarchy and handles all operations for this domain. Queries for other domains are forwarded throughout the DNS tree as is done in regular DNS. The front-end server intercepts all update and LLQ requests. Updates and LLQ without an associated lease time are rejected. This requirement excluded the use of standard DNS update tools (e.g. nsupdate) that do not supply an update lease with an update request. The architecture defined for the DEUS project can be deployed on the different nodes of heterogeneous networks, such as the WiLab.t infrastructure, facilitating a distributed monitoring platform which can be tuned to the needs of each individual deployment. Figure 5 illustrates this deployment. Although only a single type of sensors is currently deployed on the testbed, future extensions with different types of hardware are possible. After the integration of this new hardware, the addition of new ontology models and data providers will suffice to include them in the monitoring workflow. After all, the specific definitions of the concepts against which the observations are checked to realise the correct Fault and Solution classification, can be changed independently from the end monitoring application.
- 6. DEUS Deployment and Ease Use of wireless Services Figure 5: Distributed Reasoning Deployment Diagram The DEUS proof-of-concept shows the Quality of Data policy framework in combination with the underlying component model; it is provided for (1) SunSPOT sensor nodes, (2) ALIX mesh nodes, and (3) back-end infrastructure, and leverages on SquawkVM on SunSPOT, and OSGi on the ALIX nodes and in the backend. The Quality of Data policy framework can deal with various qualities such as inaccurate or missing sensor readings, by applying actions such as labeling, filtering, reporting, and substitution of inaccurate readings by regularly approved readings. In addition, the Quality of Data policy framework is integrated with reasoning solutions; if local rules fall short, the policy framework can query the reasoning engine to determine the most appropriate action to take for a particular observation in the data flow. Results are promising: when compared to the original observations and data processing quality achieved at the iLab.t Wireless Lab, backend applications can draw substantially more accurate end-conclusions for a particular data flow when the data has been inspected and processed by the Quality of Data policy framework.
- 7. DEUS Deployment and Ease Use of wireless Services Project partners In cooperation with IBBT research groups UGent - IBCN http://www.ibcn.intec.ugent.be UGent - WiCa http://www.wica.intec.ugent.be UA - PATS http.www.pats.ua.ac.be KU Leuven – DistriNet http.www.distrinet.cs.kuleuven.be KU Leuven – CUO http://ww.soc.kuleuven.be/com/mediac/cuo UHasselt - EDM http://www.edm.uhasselt.be/