Sensor & Computing Infrastructure for

Environmental Risks

Vassilis Papataxiarhisvpap@di.uoa.gr

Department of Informatics and TelecommunicationsUniversity of Athens – Greece

"WSNs in the Real-World" Workshop, "WSNs in the Real-World" Workshop, ZigBee Alliance Fall 2011 Members Meeting, October 2011ZigBee Alliance Fall 2011 Members Meeting, October 2011, Barcelona, Barcelona

Integrated Platform for Autonomic Computing

Research interests: Pervasive Computing, Mobile Computing, Wireless Sensor Networks, Context- and Situation-Aware ComputingInformation Fusion, Distributed Computing, Semantic Web, Intelligent MultimediaActivities: Multi-layered Data Fusion, Inform. Dissemination, Distributed Intelligence,Context Prediction, Quality of Context, Optimal Stopping, Context DiscoveryPublications: Ph.D. dissertations: 7IEEE / ACM Transactions: TMC, TAAS, TSMC, TITBTop Conf.: WWW, MDM, COMPSAC, MobiDE, ICPADS, Globecom175 publications, 14 book chapters, 1050 citationsCollaborators/Projects: ICT/IST (IDIRA, IPAC, SCIER, PoLoS), GSRT (Polysema, Mnisiklis, Pythagoras)CSEM, Uni. Geneva, Frequentis, Ministry of Defense, Fraunhofer, FIAT, Uni.Cyprus

Sector of Computer Systems and Applications

Pervasive Computing Research Group

(http://p-comp.di.uoa.gr) Coordinator: Stathes Hadjiefthymiades

(3 Faculty Members, 4 Post Doc Researchers, 7 Ph.D. - 10 M.Sc. Students)

Sensor & Computing Infrastructure for

Environmental Risks

SCIER Objectives

• Sensor network infrastructures for the detection and monitoring of disastrous natural hazards.

• Advanced sensor fusion and management schemes.

• Risk evolution models simulated on GRID.

• Multi-risk platform.

• Public-private sector cooperation.

LACU

Computing System

Public infrastructure

private infrastructure

con

trol

Local Alerting Control Unit LACU

LACULACU LACU

LACU

LACU

SCIER architecture

SCIER Sensing Subsystem

• Sensor Infrastructure– In-field sensor nodes (humidity, temp,

wind speed/direction)– Out-of-field vision sensors (vision sensor)

• Sensor Data Fusion

SCIER Computing Subsystem

• Computation and Storage• Environmental models

– Flash Floods (FL), forest fires (FF)– GIS Infrastructure– Storage, analysis and visualization of

monitored data, spatial calibration and event localization

• Predictive Modeling• Front-End Subsystem

Local Alerting Control Unit

Data flow

Control flow

DataBase

Worker Node

Worker Node

VO Storage Disk Pool

MON:ctb30.gridctb.uoa.gr

CE,SiteBDII:ctb31.gridctb.uoa.gr

SE:ctb32.gridctb.uoa.gr

WN:ctb33.gridctb.uoa.gr

WN:ctb34.gridctb.uoa.gr

SCIER Site @ UoA

Computing Subsystem

Alerting Infrastructure

JDBC

Sensor Infrastructure

Sen

sing

sys

tem

pro

xy

XM

L

LACUSoftwaremodules

Remote Administration

console

OSGI

LACU Fusion Component (FF)

• Receives sensor data and executes fusion algorithms.

• Generates fused data with degree of reliability.

• Fused data fed to the Computing Subsystem.

2nd Level Fusion Process (FF) in CS

• Camera data and Fused sensor data from LACUs are processed .

• Algorithms:– Voting algorithm– Dempster Shafer Theory of

Evidence• Triggers simulations according

to the final probability of fire, flood, etc.

• Simulation of several possible futures through the GRID infrastructure.

• GRID used to simulate many possible future situations (1-100) under different propagation conditions

• results analyzed to identify the size and shape of the resulting burned area, and provide probabilities for each of the simulated futures.

FF simulation modeling

• Conditions stored in metadata catalog• Engine for parsing and evaluating

conditions based on incoming data.• Interface with Simulation subsystem

triggering model execution based on fusion result

Condition evaluation engine

Sensor input data

Metadata Catalog

conditions

Fusion Decision

FL Modeling

SCIER GRID and FL with web-services

Fusion

Sensors

Storage for:- fire models executables- model input data- model structural data- model output data- Pre-prepared WS + CS scenarios

Services

GRIDSCIER central point

Collect data (location+time+value):- precipitation- temperature- humidity- wind

ArcGIS

Executes fire modelling jobs

User interface

Simulation PC(s)

Executes 1D flood modelling jobsIncorporates pre-calculated flood maps lookup

Forwards data to storageIssues simulation jobsRuns web server with UI

Web services

File share, SQLSQ

L

HTTP

System Validation & Evaluation

• Testing includes both fires and flooding– Gestosa, Portugal (experimental and

controlled burns)– Stamata, Attica, Greece (fires, system

deployed)– Aubagne, Bouches du Rhone, S. France

(fires and floods)– Brno, Czech Republic (floods, system

deployed)

System Validation & Evaluation

• Gestosa, Portugal (experimental and controlled burns)

System Validation & Evaluation

• Stamata, Attica, Greece (fires, system deployed)

System Validation & Evaluation

• Aubagne, Bouches du Rhone, S. France (fires and floods)

IPAC

IPAC Objectives Integrated Platform for Autonomic Computing Main goals

• Middleware for autonomic computing

• Application Creation Environment

Application Creation Environment

VisualEditor

TextualEditor

CodeGeneration

EmulatorDebugger IPAC

Applications

IPAC Middleware

Services

OSGi Platform

H/W, OS, JVM

IPAC Node

Developer

WiseMACWiFi

Short Range Communication

Interfaces

Sensing Elements

GPSSunSPOTs

Visual Sensors

IPAC Node

H/W, OS, JVM

Alarm Chatting Monitoring Querying …

SEC

IPAC Middleware

SensingElements

WirelessNetwork

Interfaces

Application Layer

IPAC Embedded System

SR

CC

Pro

xy &

Info

rmat

ion

Dis

sem

inat

ion

SE

C P

roxy

Rea

sone

r

User Interaction Service

Rec

onfig

urat

ion

Ser

vice

Eve

nt C

heck

er S

ervi

ce

Sch

edul

er

App

licat

ion

Man

ager

Alarm

SRCC

Service Layer

OSGI Framework Service Registry Event Admin Service Tracking

Public Segment Storage

Private Segment Storage

Light-weight IPAC node• A lean version of the middleware (WiseMAC case only)• On an embedded wireless sensor node platform (WiseNode)• Targeted functionality• IPAC-compatible communication-wise• A single, customized application• To be used as relay node, simple sensor node, beacon, ... where full

IPAC complexity is not necessary

-> more nodes... -> cheaper...

WiseNode

IEEE1451 in IPAC• IEEE1451 standard has inspired the implementation of the Sensing Element Components as “smart sensor”.• The philosophy which the IEEE1451 is based on is one of the features of the IPAC system, namely the uniform treatment of all IPAC sensors.• The standard is still under development and some parts are not well defined.• Commercial products (sensors, dev kit or adapter) are no available, partially available or with very short lifetime• A Java implementation of the IEEE1451 has been performed based on the SUNSpot platform

IEEE1451 software architecture

NCAP component:- “soft NCAP”, SECproxy OSGI module that provide NCAP functionalities- embedded in the SEC Proxy service- new sensor discovery and sensor removal- sensor data retrieval- integration with Reasoner, Storage and ECS service

TIM component (Sunspot board):- SEC midlet on SUNSpot that provide TIM functionalities- physical sensor reading- respond to discovery queries- respond to transducer access requests- handle transducer management tasks- support TEDS management functions

SEC hardware platform

Hardware:- Dimensions 41 x 23 x 70 mm 54 grams- 180 MHz 32 bit ARM920T core - 512K RAM/4M Flash- 2.4 GHz IEEE 802.15.4 radio with integrated antenna- USB interface- 3.7V rechargeable 720 mAh lithium-ion battery - 32 uA deep sleep mode- General Purpose Sensor Board- 2G/6G 3-axis accelerometer- Temperature sensor- 8 tri-color LEDs- 6 analog inputs- 2 momentary switches- 5 general purpose I/O pins and 4 high current output pins

Software:- Virtual Squawk Machine - Fully capable J2ME CLDC 1.1 Java VM with OS functionality- VM executes directly out of flash memory- Device drivers written in Java- Automatic battery management- Developer Tools- Use standard IDEs. e.g. NetBeans, to create Java code- Integrates with J2SE applications- Sun SPOT wired via USB to a computer acts as a base-station

IPAC - Platooning

• Two main scenarios: Road Condition & Road Availability

• 8 applications• Applications have specific business logic• Applications react when specific events are

triggered• Events are based on: messages (data, etc)

or sensor values

Scenario 1: Road Condition

• A convoy should avoid a non safe area (e.g. ice in the road)

• Applications used: First Vehicle

• the node has a vision sensor attached on it but no temperature sensor

• reacts in an ice event. The event is triggered based on the vision sensor indication and other vehicles’ temperature indication

• in case of an ICE event is sends a warning message to the rest of the vehicles

Convoy Vehicle• has a temperature sensor

attached on it• reacts in a warning message by

presenting the ICE warning in the application interface

Scenario 2: Road Availability

• Two convoys have intersecting routes and should avoid simultaneous use of a road junction.

• Applications used:– Head Vehicle (for both convoys)

• sends a ‘data’ message containing the node ID as the convoy moves• stops or continues its route according to the message sent by the

route scheduler

– Tail Vehicle (for both convoys)• sends a ‘data’ message containing the node ID as the convoy moves

– Route scheduler• accepts ‘data’ messages (data events) and based on the Rssi values

it decides which convoy should proceed first

RSSI-based logic

• Thorough handling of RSSI measurements from convoy vehicle.

• The route scheduler assesses the absolute RSSI value to roughly determine the distance of the approaching vehicle and the time derivative to determine its speed.

• Similar approach is followed for the departure from the junction.

Thank you!

IPAC website: http://ipac.di.uoa.gr SCIER website: http://www.scier.eu