slide1 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Sensor & Computing Infrastructure for Environmental Risks PowerPoint Presentation
Download Presentation
Sensor & Computing Infrastructure for Environmental Risks

Loading in 2 Seconds...

play fullscreen
1 / 29

Sensor & Computing Infrastructure for Environmental Risks - PowerPoint PPT Presentation

  • Uploaded on

Sensor & Computing Infrastructure for Environmental Risks. Integrated Platform for Autonomic Computing. Vassilis Papataxiarhis Department of Informatics and Telecommunications University of Athens – Greece "WSNs in the Real-World" Workshop,

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Sensor & Computing Infrastructure for Environmental Risks' - apria

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Sensor & Computing Infrastructure for Environmental Risks

Integrated Platform for Autonomic Computing


Department of Informatics and Telecommunications

University of Athens – Greece

"WSNs in the Real-World" Workshop,

ZigBee Alliance Fall 2011 Members Meeting, October 2011, Barcelona


Sector of Computer Systems and ApplicationsPervasive Computing Research Group( Coordinator: Stathes Hadjiefthymiades(3 Faculty Members, 4 Post Doc Researchers, 7 Ph.D. - 10 M.Sc. Students)

  • 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
scier objectives
SCIER Objectives
  • Sensornetworkinfrastructuresforthedetectionandmonitoringofdisastrousnaturalhazards.
  • Advancedsensorfusionandmanagementschemes.
  • Riskevolution modelssimulatedon GRID.
  • Multi-risk platform.
  • Public-private sector cooperation.
scier architecture

Computing System

Public infrastructure

Local Alerting Control Unit LACU



private infrastructure






SCIER architecture
scier sensing subsystem
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
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

Remote Administration console

Local Alerting Control Unit

Alerting Infrastructure

Sensor Infrastructure

Computing Subsystem

Sensing system proxy








Data flow

Control flow

lacu fusion component ff
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.
2 nd level fusion process ff in cs
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.
ff simulation modeling
FF simulation modeling
  • 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.
fl modeling
FL 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


Metadata Catalog

Sensor input data

Condition evaluation engine

Fusion Decision

scier grid and fl with web services
SCIER GRID and FL with web-services


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


SCIER central point

User interface


Forwards data to storage

Issues simulation jobs

Runs web server with UI

Executes fire modelling jobs



File share, SQL


Web services


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

Simulation PC(s)

Executes 1D flood modelling jobs

Incorporates pre-calculated flood maps lookup

system validation evaluation
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 evaluation1
System Validation & Evaluation
  • Gestosa, Portugal (experimental and controlled burns)
system validation evaluation2
System Validation & Evaluation
  • Stamata, Attica, Greece (fires, system deployed)
system validation evaluation3
System Validation & Evaluation
  • Aubagne, Bouches du Rhone, S. France (fires and floods)
ipac objectives
IPAC Objectives
  • Integrated Platform for Autonomic Computing
  • Main goals
    • Middleware for autonomic computing
    • Application Creation Environment







IPAC Applications




Application Creation Environment


Middleware Services



Visual Sensors



OSGi Platform


Short Range Communication Interfaces

Sensing Elements



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...


ieee1451 in ipac
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
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
SEC hardware platform


- Dimensions 41 x 23 x 70 mm54 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


- 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
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
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
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
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:

SCIER website: