A Semantic-based Architecture for Sensor Data Fusion UBICOMM

A Semantic-based Architecture for Sensor Data Fusion UBICOMM ‘ 08 Stamatios Arkoulis, Ph. D Candidate National Technical University of Athens UBICOMM '08

Outline Introduction Ø Existing Systems & Applications Ø Data Transformation & Semantic Representation Ø Motivation Ø The Proposed Architecture Ø Ø Data Layer Ø Processing Layer Ø Semantic Layer Ø Conclusions Ø Future Work UBICOMM '08

Introduction Ø Sensor networks (wireless) Ø attract a lot of attention → research → innovation Ø Many implementations worldwide (why? ) Ø Nature: smallness, price, energy-efficiency, reliability Ø IPv 6: no number limitations Ø huge address space for networking purposes Ø Improvements in resource management (battery life, computation & communication capabilities, memory) Ø What about the future? Ø sensors everywhere Ø accessible via the Internet UBICOMM '08

Introduction Ø Main scientific attention Ø networking of distributed sensing Ø But what about… Ø management, analysis, understanding of collected data Ø Current sensor deployments Ø Huge number of sensors Ø Heterogeneity Ø Rawness of data Ø little, if any, meaning by themselves Ø Enormous amounts of data stored We have many “Data” but little “Information” UBICOMM '08

Introduction The Solution ? Ø Proper data management (for event detection) Ø Data interpretation Ø considering final user requirements / needs / scope Ø Data heterogeneity Ø special aggregation schemas Ø combination / comparison / correlation Ø Data Aggregation & Processing Ø render them helpful to applications Key Technology: “The Semantic Web” UBICOMM '08

Introduction Ø The Semantic Web Ø despite the heterogeneity and amount of collected data Ø “meaningful” events extraction Ø interoperability “Connection of Sensory Data to their environmental features” Ø “Semantic Annotation” → What? Ø metadata added to any form of content Ø well-defined semantics ease its use Ø “Semantic Annotation” → How? Ø content description languages Ø query languages Ø annotation frameworks UBICOMM '08

Existing Systems & Applications Ø Sensor Web Enablement(SWE) initiative [by OGC] Ø Goal → Development of Standards Ø discovery/exchange/processing of sensor observations Ø Common encoding/transport protocol used by services Ø no explicit ontological structure proposed yet Ø no formal conceptual model → no interoperability Ø ES 3 N architecture Ø Semantic Web technologies on top of sensor networks Ø sensor observations’ ontology-based storage Ø mechanisms – RDF Repository Ø end-user posts semantic queries (SPARQL) Ø scalability – large data volumes Ø questionable performance / efficiency UBICOMM '08

Existing Systems & Applications Ø Iris. Net Architecture – Software infrastructure Ø data collection/storage organization (XML) → Agents Ø end-user queries vast quantities of data (XPath) Ø Scalable – Powerful – Efficient Ø million/distributed/high bit-rate/heterogeneous sensors Ø No semantics → No data reusability Ø SWAP 3 -tier architecture (framework) Ø sensory data combination (for high-level tasks) Ø unified end-user view of underlying sensor network Ø Sensor / Knowledge / Decision layer → Agent-based Ø services semantically description to end-users Ø multiple agents and ontologies → Complexity UBICOMM '08

Existing Systems & Applications ØPriamos Middleware – Architecture Ø automated Ø real time Ø unsupervised annotation of low-level context features Ø mapping to high-level semantics Ø rules composition through specific interfaces Ø content annotation without need of technical expertise Ø context awareness challenges easily addressed UBICOMM '08

Data Transformation & Semantic Representation Ø Specific interpretation models Ø makes raw sensory data meaningful Ø apps’ scope / kind of information dependent Ø OGC specifications → Models & XML Schema: Ø O&M: sensor observations and measurements (both archived or/and real-time) encoding Ø Sensor. ML: sensor systems (i. e. location) and sensor observations’ associated processing description Ø Formal semantic representation offers… Ø structured knowledge (concerning a certain domain) Ø specify a domain’s important concepts/relations UBICOMM '08

Motivation Ø Existing Sensory Data Management approaches Ø no support for distributive sensor deployments Ø inability to scale well in today increasing environment Ø no applicable to large sensors network Ø small amount of data can be transferred Ø lack of context annotation / semantic data representation Ø absence of ontological infrastructures for rules & queries Ø Such limitations obstruct end-users to… Ø fully exploit the acquired information Ø match events from different sources Ø deploy smart apps able to follow semantic-oriented rules “Solution: A completely new architecture” UBICOMM '08

The Proposed Architecture Ø Data management Ø Ø Gathering Ø Real-time Ø Recorded Aggregation Ø Heterogeneity Processing Ø Meaningfulness User defined rules Ø alarms - actions Ø Ø Modularity Ø UBICOMM '08 Flexibility Scalability

Data Layer Ø Central entities Ø sensor discovery Ø data acquisition (+policies) Ø event-based → data sent directly Ø polling-based → data periodical queried Ø raw-data collection Ø Location Sensors (Smart Phones, PDAs, etc. ) Ø positioning interfaces (Bluetooth, GPS, Wi-Fi) Ø location-sensitive data Ø next layer reached either directly or via special infrastructures Ø Wireless Sensors UBICOMM '08

Data Layer Ø Wireless Sensors (MICA 2, e. Ko, Imote 2) Ø Measure and monitor environmental metrics Ø Architectures, routing protocols and schemes exist Ø efficient energy consumption & congestion avoidance Ø Data reaches the next layer Ø routed to specific nodes & forwarded to central entities Ø send directly to central entities Ø Audiovisual Sensors (microphones, cameras, etc. ) Ø rich, real-time content Ø special networking requirements to be satisfied Ø bandwidth (huge amount of bits to be transmitted) Ø packet loss (destroyed content / wrong order) Ø jitter (glitches) Ø Data reaches the upper layer → Web services etc. UBICOMM '08

Data Layer – Security Issues Ø Security Requirements Ø Data confidentiality/integrity/freshness/authentication Ø Secure time synchronization / localization Ø Anonymity (hide location of sensor-observed aspects) Ø Secure transmission between Sensors-Aggregators Ø Secure Web Services, SSL, X. 509, PKIs, XML encryption Ø Obstacles to Security Ø resource / computing constraints Ø communication reliability Ø unattended operation Ø Optimality: Safety – Efficiency “trade-off” Ø Sensors’ type & Deployment scenario dependence UBICOMM '08

Processing Layer Ø Aggregators (due to sensors’ limited resources) Ø raw data processing Ø data transformation to useful (“standard”) formats Ø XML generation Ø dynamic system configuration through XML schemas Ø sensors’ capabilities/location/interfaces formal descriptions Ø specification of different data significance for users’ apps Ø XML files re-transformation (XSLT Module) Ø XML files forwarding to the upper layer Ø GSN (Open Source – Java) Ø user-defined wrappers (based in a data model) Ø incoming data encapsulation to the data model UBICOMM '08

Semantic Layer Abstraction of received “XMLs” Ø Context capturing in varying conditions Ø “Automatically” configured context annotation Ø Ø by application specific ontologies Ø This layer consists of Ø an exported Web Service interface Ø ontology Models Ø Mapping and Semantic Rules Ø …and the corresponding actions / notifications Ø the external Reasoning Server UBICOMM '08

Semantic Layer Ø Web Service interfacing module Ø messages (from the lower layer) manipulation Ø any arbitrary well-formed XML document Ø knowledge is transferred Ø Ontology models Ø Ø Database Model → Jena internal graph engine Ontological Model → Triple statements Knowledge Base → Annotation (separate from data) Incoming XML files stored Ø transformation in another XML template UBICOMM '08

Semantic Layer Ø Rules (syntactic and semantic homogeneity) Ø Knowledge conversion into semantic information → KB Ø XML Mapping Rules Ø fetch data from XML message Ø storing in ontology model as ontology class individuals Ø Semantic Rules Ø modify the ontology model Ø Distinction inspired by Rule. ML Ø RDF-only and RDF-XML-combining subsets Ø common syntax Ø different conditions & actions in each case Ø Event-Condition-Action pattern followed Ø “on event if condition then action” UBICOMM '08

Semantic Layer Ø Mapping Rule Ø IF EXISTS /sensor/temperature/@value THEN INSERT INDIVIDUAL IN CLASS Temperature AND SET DATATYPE PROPERTY has. Value /sensor/temperature/@value Ø Consecutive Semantic Rule Ø IF DATATYPE PROPERTY IN CLASS Temperature HAS VALUE GREATER THAN 40 AND DATATYPE PROPERTY IN CLASS Humidity HAS VALUE GREATER THAN 0. 3 THEN Alert (”Surveillance area under unusual conditions!”) Ø Trigger Alerts based on KB awareness of the world Ø Semantic-based intelligence added Ø reasoning procedures deduce implicit knowledge based on the current explicit facts UBICOMM '08

Semantic Layer Ø Reasoning server Ø Knowledge Base is Ontology-Reasoner combination Ø Reasoner (essential) Ø Onto. Broker, KAON 2, Pellet etc. Ø DIG interoperability / Stand alone DIG servers Ø HTTP message exchanging with calling programs Ø Jena supports biding of external reasoners “choice is up to the user” UBICOMM '08

Conclusions Ø Modular architecture for deploying WSNs Ø ease end-user to take advantage of collected data Ø facilitate developers Ø deploy new useful applications Ø exploit the Semantic Web advances Ø add flexibility to the sensor world Ø form associations over the raw data Ø extract meaningful information and valuable results Ø create specific management & notification rules Ø based on the nature of applications UBICOMM '08

Future Work Ø Implementation of different scenarios Ø combine aggregation/security/processing methods Ø Evaluation of architecture’s discrete components Ø Scalability & Performance issues Ø Study energy efficiency trade-offs under Ø proposed routing schemes Ø data aggregation architectures UBICOMM '08

Questions? Thank you for your attention !! Stamatios Arkoulis stark@cn. ntua. gr UBICOMM '08