Semantics in Sensor Networks

Semantics in Sensor Networks Workshop on Semantics and Future Internet Berlin, 1 Sep 2009 Oscar Corcho Facultad de Informática Universidad Politécnica de Madrid Campus de Montegancedo sn 28660 Boadilla del Monte, Madrid http://www.oeg-upm.net [email_address] Phone: 34.91.3366605 Fax: 34.91.3524819

Sensor Networks Increasing availability of cheap, robust, deployable sensors as ubiquitous information sources Dynamic and reactive, but noisy, and unstructured data streams Source: Antonis Deligiannakis

Parts of a Sensor Sensing equipment (sensor and data acquisition boards) Internal (“built-in”) vs external sensing capabilities CPU Memory Battery Radio to transmit/receive data from other sensors Source: Antonis Deligiannakis

Some examples of sensors and sensor parts Maximizing network lifetime is the main target Cost-effective only if sensor networks last long Sensor-based applications without power constraints are much easier to handle Source: Antonis Deligiannakis Passive RFID tag Berkeley Mica2 Stargate (Intel PXA255 cpu) Constraint Battery -- 2 ΑΑ Li-Ion Conserve to increase network lifetime CPU -- 7.38 MHz 400 MHz Computationally cheap algorithms Memory 1Kb 4KB SRAM, 512 KB EEPROM up to 256 MB FLASH Algorithms with low memory requirements Radio A few feet 30 0 μέτρα Depends on radio model Transmission range, bandwidth (bits/sec)

The Sensor Web Sensor networks may be networked, mostly wireless, hence global and integrated Universal, web-based access to sensor data Each network with some kind of authority and administration Sensor networks vs robust networks Source: Adapted from Alan Smeaton’s invited talk at ESWC2009

Sensor Web: Is this part of the Web/Internet? Source: SemsorGrid4Env consortium

You haven’t done sensor networks research until... You have fallen in the river/mud/glacier/... You have felt the excitement of data arriving. And uncertainty when it stops. The data has had an impact. Methodologically, this research must be conducted in the wild. Well, yes and no: there is a need for all types of research (pure, basic, applied, cross-discipline, etc.) But the first three bullets have to be kept in mind all the time. Source: Adapted from Dave de Roure

Energy Constraints 3-5% battery yearly increase CPU speed increases much faster However, energy per cpu instruction decreases Some applications: unattended deployment Eg: Disaster scenarios, military environments… Often hard or impossible to replace batteries Maximizing network lifetime is the main target Cost-effective only if sensor networks last long Applications with sensors without power constraints are much easier to handle

Sources of Energy Drain CPU computations Measurements from sensing equipments (cost depends on what you sense) Very small energy consumption in sleep mode Radio is main source cost(Transmitting) > cost(Receiving) ≥ cost(idle listening) Popular goal: reduce #transmitted bits Synchronization + communication protocols equally important I.e., cost of transmitting K bits depends on duty cycle (percentage of time sensor is awake to listen for data) Idle listening for too long is extremely costly

Assumptions and Goals in Subsequent Algorithms Research Emphasis on more constrained environments Wireless communication, short transmission ranges One or more base stations with increased capabilities may exist Candidates for gateways to the semantic sensor web Energy limitations (battery powered sensors) Goal of algorithms: Preserve Energy Organize sensors and their schedules Good schedules allow sensors to power down their radios/cpus and go into a sleep mode Reduce size of transmitted data Processing (esp, aggregation) focuses on numeric measurements Implication of having a strict schedule on when to collect data: base stations knows when quantities are collected Such metadata may not even need to be transmitted

Who are the end users of sensor networks? Source: Dave de Roure The climate change expert, or a simple citizen

And what do these users want? Long lived sensors Real time readings and prediction Integration across sensors and sensor sources Events

But why is it worth falling in mud? Sensor networks address an important set of “grand challenge” Computer Science issues including: Scale, scalable Autonomic behaviour versus control Persistent, heterogeneous, evolving Holistic approach including information systems Deployment challenge Some mobile devices Source: Dave de Roure

A set of challenges in sensor data management Provisioning Complexity of acquisition: distributed sources, data volumes, uncertainty, data quality, incompleteness Pre-processing incoming data: calibration on instruments (specific), lack of re-grid, calibration, gap-filling features Tools for data ingestion needed: generic, customizable, provide estimates, uncertainty degree, etc. Spatial/temporal Analysis, modeling Discovery: identify sources, metadata Data quality: gaps, faulty data, loss, estimates Analysis models Republish analytic results, computations, Workflows for data stream processing Source: Data Management in the WorldWide Sensor Web. Balazinska et al. IEEE Pervasive Computing, 2007

A set of challenges in sensor data management Interoperability Data aggregation/integration Uncertainty, data quality Noise, failures, measurement errors, confidence, trust Distributed processing High volume, time critical Fault-tolerance Load management Stream processing features Continuous queries Live & historical data Source: Data Management in the WorldWide Sensor Web. Balazinska et al. IEEE Pervasive Computing, 2007

A semantic perspective on these challenges Sensor data querying and (pre-)processing Data heterogeneity Data quality New inference capabilities required to deal with sensor information Sensor data model representation and management For data publication, integration and discovery Bridging between sensor data and ontological representations for data integration Ontologies: Observations and measurements, time series, etc. Event models User interaction with sensor data

Final Discussion: Hot Topics and Open Problems

Challenges. A 1000-feet architectural perspective http://www.semsorgrid4env.eu/

Challenge 1: Querying and (pre-)processing For a model of surface water drainage, every 15 minutes, and within 24 hours of their being taken, we wish to obtain time-correlated measurements of the river depth now and the rainfall at the top of the hill 15 minutes before, provided that it is now raining less in the river than it was in the hill top and that the rainfall in the hill top was above 5mm. Assume that: sink (0) river (rain : int, depth : int) at sites (5, 6, 7, 9) hilltop (rain : int) at sites (4) Then: SELECT RSTREAM river.time, hilltop.rain, river.depth FROM river[NOW], hilltop[AT NOW-15 MINUTES] WHERE hilltop.rain > 5 AND river.rain < hilltop.rain ACQUISITION RATE=EVERY 15 MINUTES, MAX DELIVERY TIME=24 HOURS 29-30 Sep 2008 SemsorGrid4Env, Kick-Off, Madrid 0 2 1 3 4 5 6 7 8 9

SNEE as a Decision-Making Sequence Is the query well-formed and well-typed? Which algebraic translation of the query is, heuristically, most efficient? Which algorithms will reduce the evaluation cost? Which physical routes should be used to transport tuples from sources to sink? Given the logical data flow paths, are there sites where the amount of data flowing through is getting smaller? Given the transport paths, which sites should get which fragments, given that acquisition, (some) processing and delivery must be carried out in specific places? Given the space and time estimation models, when should each fragment in each site execute, when should communication take place, and when should the node go to sleep? Given a target language, how to generate node-specific source code that correctly executes the distributed computation specified in the agenda? SemsorGrid4Env, Kick-Off, Madrid routing parsing/type checking translation/rewriting algorithm assignment partitioning where-scheduling when-scheduling code generation <query, QoS-expectations>, <schemas, description(node,network), cost parameters> <N 1 , …, N m > nesC code abstract-syntactic tree logical-algebraic form physical-algebraic form PAF routing tree RT fragmented-algebraic form agenda 1 2 3 4 5 6 7 8 RT distributed-algebraic form RT DAF single-site phase multi-site phase

Challenge 1: Querying and (pre-)processing Collecting all data ( SELECT * queries) Entire network or a subregion, periodically or frequently Collect aggregates of data Report AVG, SUM, MAX quantities in an area/network Data Reduction based on user-specified data quality In all types of queries: (historical, aggregate…) Minimize bandwidth based on quality (or the dual problem) Detecting Outliers “ Strange” readings: Interesting phenomenon or malfunction? Joins Report information based on combined readings of sensors (i.e., report when a lion is close to a deer) Harder to optimize. Naïve solution of sending potential joining tuples (or projected attributes of them) to base station is often not far from best case Source: Antonis Deligiannakis

Challenge 1: Querying and (pre-)processing Requires additional information ( metadata ) for collected data Location/orientation of sensor, time, authority, measured quantities, units, errors etc Some of them are static, some may change (time, location…) Additional info may significantly impact volume of transmitted data Query execution still needs to be optimized within each network Tradeoff between the logical correctness of results and statistical models Deliver the right information at the right time

Challenge 2: Sensor Data Modelling and Management The “easy” part Agree on a network of sensor network ontologies Use these ontologies to annotate SensorML readings Use registries to publish available sensor networks

Challenge 2: Sensor Data Modelling and Management Data publication and integration SensorLocation:stored ( id:int , locx:int, locy:int) TreeSensor:sensed ( id:int , ts:time , smoke:boolean, temperature:float, relHumidity:float) SoilSensor:sensed ( id:int , ts:time , moisture:float) WindSensor:sensed ( id:int , ts:time , speed:float, direction:float) RainGauge:sensed ( id:int , ts:time , level:float) Streaming SPARQL, C-SPARQL, etc. Linked Stream Data (ISWC2009 semantic sensor wokshop) http://www.linkeddatastreams.org/sensor/heartrate/1/50.60242,-2.5225/1

Simple Query SNEEql RSTREAM SELECT id, speed, direction FROM wind[NOW]; Streaming SPARQL PREFIX fire: <http://www.semsorgrid4env.eu/ontologies/fireDetection#> SELECT ?sensor ?speed ?direction FROM STREAM <http://…/SensorReadings.rdf> WINDOW RANGE 1 MS SLIDE 1 MS WHERE { ?sensor a fire:WindSensor; fire:hasMeasurements ?WindSpeed, ?WindDirection. ?WindSpeed a fire:WindSpeedMeasurement; fire:hasSpeedValue ?speed; fire:hasTimestampValue ?wsTime. ?WindDirection a fire:WindDirectionMeasurement; fire:hasDirectionValue ?direction; fire:hasTimestampValue ?dirTime. FILTER (?wsTime == ?dirTime) } C-SPARQL REGISTER QUERY WindSpeedAndDirection AS PREFIX fire: <http://www.semsorgrid4env.eu/ontologies/fireDetection#> SELECT ?sensor ?speed ?direction FROM STREAM <http://…/SensorReadings.rdf> [RANGE 1 MSEC SLIDE 1 MSEC] WHERE { … Semantically Integrating Streaming and Stored Data

Challenge 3: User Interaction with Sensor Data Source: SemsorGrid4Env consortium

Vision (after some iterations, and more to come) Source: RWI Working Group on IoT: Networked Knowledge Networked Knowledge Before 2010 2010-2015 2015-2020 Beyond 2020 Today Incremental Incremental-Visionary Visionary Interoperability Middleware Sensor ontologies Intra-network cross-layer integration and optimization Sensor Internet Inter-network cross-layer integration and optimization Information & Context Relational database integration Sensor network data warehouses Stream aggregation Query processing and reasoning on sensor networks Event modelling Database-stream integration Sensor actuation (In-network processing) QoS models QoS-based information integration of DB and streams Discovery Centralised non-semantic registries (sensorbase.org) Semantic discovery of sensors and sensor data Distributed registries Sensor network location transparency Identity & Trust & Privacy RFID tags No privacy mgmnt URIs User-centric privacy and policies Virtual sensor networks through dynamic policies Provenance Data provenance (where, what and who) Data transformation processes (how) Process and problem solving understanding (why) Problem solving interpretation and explanation

Another list of R&D challenges Short-term Sensor network ontologies Spatio-temporal RDF queries RDF stream generation (RDB2RDF tools can be “easily” adapted, e.g., R2O/D2R/etc.) RDF/DB/HTML/Maps Mashup support Medium-term Semantic query-based access to sensor networks In-network processing: real-time SPARQL to [CQL, SNEEql, etc.] (Ontology-based) relational data and data stream integration Pay-as-you-go techniques for query planning Distributed RDF-based query processing and integration Usability of mashup-supporting technology

Real World: Where do we talk about this? Join us at W3C SSN Incubator Group rwi.future-internet.eu OGC Sensor Web Enablement WG A bunch of (mainly research oriented) workshops ESWC2009 workshops on stream reasoning and semantic sensor networks ISWC2009 workshop on semantic sensor networks Future Internet Symposium series

Development of an integrated information space where new sensor networks can be easily discovered and integrated with existing ones and possibly other data sources (e.g., historical databases), Rapid development of flexible and user-centric decision support systems that use data from multiple autonomous independently deployed sensor networks and other applications. SemsorGrid4Env: Objectives http://www.semsorgrid4env.eu Start date: 01/09/2009 Duration: 36 months

SemsorGrid4Env: use cases Fire Risk Monitoring and Warning in a specific area of Castilla y León Coastal and Estuarine Flood Warning in Southern UK.

SemsorGrid4Env: Technologies and Expected Results Distributed RDF-based query processing and integration Extensions of OGSA-DQP and WS-DAI-RDF Archival data and data streams ontology-based integration Sensor network ontologies Spatio-temporal RDF queries Query-based access to sensor networks (in-network processing) SNEEql Outlier detection algorithms Mashup support

Semantics in Sensor Networks

More Related Content

What's hot

Viewers also liked

Similar to Semantics in Sensor Networks

More from Oscar Corcho

Recently uploaded

Semantics in Sensor Networks

Editor's Notes