1 / 24

SITUATIONAL AWARENESS FOR FIRE FIGHTERS (SAFIRE)

SAFIRE Project DHS Update – September 15, 2009. SITUATIONAL AWARENESS FOR FIRE FIGHTERS (SAFIRE). Goal: Improve the safety of firefighters by providing decision makers with greatly improved situational awareness during response activities. Agenda for the Day. Project Overview

darcie
Télécharger la présentation

SITUATIONAL AWARENESS FOR FIRE FIGHTERS (SAFIRE)

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. SAFIRE Project DHS Update – September 15, 2009 SITUATIONAL AWARENESS FOR FIRE FIGHTERS (SAFIRE) Goal: Improve the safety of firefighters by providing decision makers with greatly improved situational awareness during response activities

  2. Agenda for the Day • Project Overview • SAFIRE Concept / Technology • SAFIRE Streams • Testing/Validation/Outreach • Future Plans: Project Outcomes, Continuity • FEMA participation in upcoming DHS workshop on “Incident Management, Resource Management, and Supply Chain Management” Nov. 5 and 6th at CERT, UCI, Irvine.

  3. SAFIRE Concept Overview

  4. SAFIRE Core Technology Areas GIS External Data Sources hazmat occupancy FICB Visualization SAFIRE System Acoustic data Environmental sensors Sensor database Video data FF physio. & location. • Multimodal Sensing Robust Network Infrastructure • Visualization and User Interfaces (FICB) • Sensor stream processing • Integration of external data sources (Ebox) • Speech

  5. Progress: Core Technology Areas • Speech • Speech for situational awareness • Networking & Sensing • Incorporation of new sensors (Co, SpCO, motes) • New antenna array for increased coverage, multi-network & store-and-forward architecture • Stream management • ability to incorporate variety of sensors , multimodal sensor archival and retrieval functionality • FICB • New functionalities in FICB – simplified UI, annotations, ebox integration, etc. • Ebox • Prototype development, ontologies for resource selection, integration of static and dynamic data such as sensing infrastructure of buildings July 15, 2009 May 29, 2009 Today demo/video July 15, 2009 July 15, 2009

  6. SAFIRE Streams: A Semantic Middleware for Multi Sensor Applications

  7. . . . SAFIRE Streams Architecture Policy DB Query (entity, attribute, value) Query results FICB / SAFIRE Server Semantic knowledge Semantic context SATQL Convert Query -> VS -> opGraph Semantic DB (entities, Relationships, VS) SATRepository VS <opGraph> Query i VS <opGraph> context1 SATScheduler SATDeployer SATMonitor Operator DB Deployment of operators Schedule to meet QoS SATRuntime Infrastructure DB Distributed Mobile-agent based runtime Sensor and computing infrastructure Heterogeneous sensors and processing nodes

  8. SAFIRE Stream Middleware Stream Middleware Goals • Writing sensor applications is hard: • Continuous data • Sensor heterogeneity • Diversity of platforms • Tolerance to failures • Powerful programming abstractions to ease application development • Hide heterogeneity, failures, concurrency • Core Services • alerting, triggering, data & stream management, queries. • Mediation • application needs with resource constraints of devices & networks SA Applications FICB Alerts Filters Analysis Middleware – glue between H/w, networks, OS and applications Networks Networks Sensor

  9. Key Concepts Driving SAFIRE Streams SAFIRE Streams models sensor embedded spaces at two levels sentient Applications Semantic Level: • Entities -- people, appliances, and buildings, rooms; Relationships – interactions. Infrastructure Level: • sensing devices, computing devices, network devices. Virtual Sensors: • maps data captured by sensors into events in the semantic world. Event Logs: • evolution of physical world as observed by the sentient system High level stream language like CQL Virtual Sensor

  10. Key Concept: Virtual Sensors • Provide the “bridge” between sensors & the semantic “real” world concepts. WiFi fingerprints, t> AP Readings Listener AP Readings to location Translate Location to Lon./Lat. L, Room12, t> Filter [L=Room1] Location Virtual Sensor Finger print DB

  11. Virtual Sensors: Multi-Sensor Fusion to improve quality AP Readings Listener AP Readings to location Location Virtual Sensor Using fingerprints <Peter, L, PDF, t> <Person, L, Room12, t> Merge Finger print DB <Peter, L, PDF, t> Signal strength Listener Signal strength triagulation Location Virtual Sensor Using signal Strength triangulation AP locations

  12. Building Applications using Semantic Model • Virtual Sensors “hide” complexity of sensor programming from application developers • Convert heterogeneous sensor streams into semantic event streams • Hide sensor failures / imprecision through • Noise reduction (e.g., averaging over multiple samples) • multi-sensor fusion (e.g., multiple location sensing technologies provide more accurate location assessment) • Semantics (e.g., speech sensors exploit word correlation to improve on ASR) • Applications can view the system as consisting of high level concepts such as entities, events, artifacts, spaces, etc. • SAFIRE Streams supports high level query languages for implementing queries & triggers: • SQL style stream language (at design stage – not yet implemented) • Event graph based language

  13. Demo Programming Execution

  14. Multi-sensor localization in SAFIRE Streams

  15. Event Graphs in SAFIRE Streams Detect when Fire Fighter 1 is on the 1st floor Filter [L=first floor] Loc operator [FF1] <FF1, L, Room12, t> • Triggers/continuous queries are converted into an event graph network. • SATWARE Deployer submits the resulting event graph into an executable pipeline based on available resources, machines and networks. • Mediates with resources to guarantee application needs are met • Multiple optimizations possible in executing such networks. Detect when FF1 & FF2 are near each other <FF1, L, Room12, t> {<FF1, L, Room12,t> <FF2, L, Room15, t>} Near [5 Rooms] Join [t] Loc operator [FF2] <FF2, L, Room15, t>

  16. Multi-sensor store / query / visualize in SAFIRE Streams

  17. SAFIRE Streams Summary Middleware to ease multi-sensor applications provides a powerful semantic interface for complex multi-sensor applications this feature used extensively in building SAFIRE SA Applications Supports core services Alerts, triggers, storage, archival, & replay capabilities. Mediation between application needs & system resources E.g., sensor stream scheduling based on application quality requirement 5/27/09

  18. Safire Project: Outreach Presentation

  19. SAFIRE: Future Directions • Completion of Project • Creation of Robust technology • Testing • Test system with Firefighters • Outcomes • Continuity

  20. SAFIRE: Future DirectionsOutcomes • Research Products • Ebox • Speech • Networking / Sensing • Safire System Product • FICB

  21. SAFIRE: Future DirectionsOutcomes • Thoughts / Expectations on Technology Transfer? • SAFIRE Advisory Board • Newport Beach FD • LA County Fire • City of Ontario • OCFA • EH&S • Deltin Corporation

  22. SAFIRE: Future DirectionsContinuity • Future Project Directions • Ebox • Speech • Networking / Sensing • SpCO data management [FireTrack]

  23. FireTrack System • Goals of FireTrack • 1. A prototype framework for collecting, communicating, storing, and analyzing exposure data entitled FireTrack • 2. A detailed evaluation of the FireTrack system in a pilot study including specific recommendations on how to expand the system to a large scale deployment. • 3. Data collected during the pilot study including exposure information at both the level of individual firefighters as well as at the environment under different conditions. • 4. Database design to represent data captured about respiratory environments during fires including taxonomies to appropriately classify and analyze such data. • 5. Specific recommendations on interventions techniques that can be realized through exposure monitoring that minimize avoidable exposure to toxins during firefighting. • 6. Identification of long term partners who will be willing to (a) maintain such a system for capturing and managing exposure information, and (b) work with research groups to launch further (more comprehensive) data collection and analysis studies the FireTrack system will enable in the future.

  24. FireTrack System

More Related