Sensor & Computing Infrastructure for Environmental Risks

1. Sensor & Computing Infrastructure for Environmental Risks Integrated Platform for Autonomic Computing VassilisPapataxiarhis vpap@di.uoa.gr Department of Informatics and Telecommunications University of Athens – Greece "WSNs in the Real-World" Workshop, ZigBee Alliance Fall 2011 Members Meeting, October 2011, Barcelona

2. Sector of Computer Systems and ApplicationsPervasive 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) • 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

3. Sensor & Computing Infrastructure for Environmental Risks

4. SCIER Objectives • Sensornetworkinfrastructuresforthedetectionandmonitoringofdisastrousnaturalhazards. • Advancedsensorfusionandmanagementschemes. • Riskevolution modelssimulatedon GRID. • Multi-risk platform. • Public-private sector cooperation.

5. Computing System Public infrastructure Local Alerting Control Unit LACU LACU LACU private infrastructure LACU LACU LACU LACU control SCIER architecture

6. SCIER Sensing Subsystem • Sensor Infrastructure • In-field sensor nodes (humidity, temp, wind speed/direction) • Out-of-field vision sensors (vision sensor) • Sensor Data Fusion

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

8. Remote Administration console Local Alerting Control Unit Alerting Infrastructure Sensor Infrastructure Computing Subsystem Sensing system proxy LACU Software modules XML OSGI JDBC DataBase Data flow Control flow

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

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

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

12. 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 conditions Metadata Catalog Sensor input data Condition evaluation engine Fusion Decision

13. SCIER GRID and FL with web-services Sensors • Collect data (location+time+value): • precipitation • temperature • humidity • wind Fusion SCIER central point User interface GRID Forwards data to storage Issues simulation jobs Runs web server with UI Executes fire modelling jobs HTTP ArcGIS File share, SQL SQL Web services 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

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

15. System Validation & Evaluation • Gestosa, Portugal (experimental and controlled burns)

16. System Validation & Evaluation • Stamata, Attica, Greece (fires, system deployed)

17. System Validation & Evaluation • Aubagne, Bouches du Rhone, S. France (fires and floods)

18. IPAC

19. IPAC Objectives • Integrated Platform for Autonomic Computing • Main goals • Middleware for autonomic computing • Application Creation Environment Visual Editor Code Generation Emulator Debugger IPAC Applications Textual Editor Developer Application Creation Environment IPAC Middleware Services GPS SunSPOTs Visual Sensors WiseMAC WiFi OSGi Platform H/W, OS, JVM Short Range Communication Interfaces Sensing Elements IPAC Node

20. IPAC Node

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

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

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

24. SEC hardware platform Hardware: - 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 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

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

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

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

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

29. Thank you! IPAC website: http://ipac.di.uoa.gr SCIER website: http://www.scier.eu