View source for SolutionsUseCase Health-Disaster Fire-Wildfire-Observation-Coverage 1a

Return to: [[Use_Cases]]
----
==Plain Language Description==
===Short Definition===
 
A user is responsible for tactical planning, analysis, and operations to combat fires of national importance, especially near inhabited areas or critical infrastructure assets.

===Purpose===

A user searches for and finds specific types of fire data available from multiple sensor assets, such as satellites, unmanned aerial vehicles, and in-situ instruments, and creates user specified data products that are automatically generated and delivered to the user local client. At present, a user needs to know a lot about the types, locations and operating modes of instruments and their platforms to be able to locate, retrieve and use their data.  This is especially true when the desired data is to be obtained from discrete locations sometime in the future instead of from the archives or via a continuous sensor readout from a fixed location.  A user would prefer to subscribe to their area of interest (AOI) for sensor web coverage, receive daily alerts for fire data available in their area, request specific taskings for future data collects, and be provided the latest imagery, derived data products, and in-situ sensor readings for fires in their AOI automatically, even for observations that will occur over the next few days.

The user does not necessarily have to know what assets are available to support sensor readouts in each region in their domain,...they are more focused on the task at hand (fire management/firefighter dispatch, etc.).  The sensor web will identify large fires in the user AOI, locate the current locations of those fires, task various observing assets to target those fire locations in an optimized fashion, execute detection algorithms that process user-specific classification products and post alerts based on those observations, and deliver all products to a web map client for overlaying with other infrastructure and geographical information of the AOI.

===Describe a scenario of expected use===

Users subscribe to daily alerts from the National Interagency Fire Center (NIFC) called the ICS209.
The sensor web system goes to the Advanced Spaceborne Thermal Emissions Radiometer (ASTER) thermal readout site at the United Stated Geological Survey (USGS) Center for Earth Resources Observation and Science (EROS) in Sioux Falls SD and retrieves ASTER Level 1 data products at 30m resolution and browse images for fires within the AOI.  The browse data is processed for display on a web map of the region.  The user is alerted that imagery is available.  ASTER Level 1G data is then retrieved and a web processing service will provide selected bands from ASTER as input to a thermal detection algorithm.  Hot pixel locations are delivered as a thermal summary product that is overlaid on a web map client.  An alert is posted for the updated fire locations to link in future observation coverage.

The sensor web system queries the MODerate-resolution Imaging Spectro-radiometer (MODIS) rapid response data and gets updated fire locations at 1,000m resolution for other fires in the AOI not covered by ASTER.  Some of the images may be inconclusive or cloudy.  The sensor web system requests imagery from the sensor web model for fire coverage in the area to acquire additional coverage as needed to clarify the status.
*The model queries the catalog registry to discover potential assets such as NASA’s unmanned aerial system (UAS) for fires and the Earth Observing-One (EO-1) satellite.
*The model calls an optimizer/scheduler to determine feasibilities of both assets for the fires of interest and to make target selections.
*If a particular fire can be imaged by the UAS, but another one cannot because it is out of authorized flight path 
**Sensor web tasks the UAS to image the particular one in its flight path by computing new target way points and issuing data acquisition commands to the instrument
**System retrieves UAS imagery and processes it for overlaying on a web map client
**User is alerted that imagery is available and alerts are posted for detections within the UAS data.
**System tasks EO-1 for one or more of the remaining fires in the AOI
**Fire classifier runs onboard EO-1 to produce a thermal summary product
**Sensor web will allow user to select coverage type to either maximize spatial coverage of AOI fires by available assets, or concentrate available assets on a particular fire for repeat coverage.  For the repeat coverage scenario, sensor web will select the image within view of the EO-1 overflight which most closely coincides with the flight window for the UAS.  For the maximum spatial coverage scenario, the system will cover the most targets in the shortest time. 
**The user is allowed to select to screen out data for which no hot pixels are detected onboard EO-1 so no image is downloaded or processed on ground.
**If hot pixels are detected, the image is downloaded and processed.  User is alerted that imagery is available.  An alert is posted that a positive detection has occurred.  Thermal summary is automatically delivered for overlaying on a web map client.
**On-going tasking of EO-1 and UAS over a 24-48 hours period is automatically controlled using workflows that sequence the activities of several sensor web processing nodes to accept new taskings and data requests, process the user-driven alerts, thermal summary, and other customized data products, and deliver them back to the user client.
**User queries Remote Access Weather Station (RAWS) data in vicinity of selected fires.  Selected data is displayed on same map as satellite imagery.  Based on wind reading from RAWS, more ground assets are dispatched to particular events that could threaten nearby infrastructure (chemical plant, power lines, telecom, houses/buildings etc.). 
**User can request updated run of a smoke prediction model based on the updated observation data made available by the sensor web.  Smoke model can also trigger subsequent observations through the sensor web based on model sensitivity reduction techniques.
Secure authentication is only enforced after data is found and accessed (i.e. not required for plotting the data).

===Definition of Success===

Success is proven by demonstration of the capability to identify fires of national importance within an AOI, compute their latest locations, retrieve relevant data from ASTER and MODIS, task EO-1 and UAS assets to image wildfires within the given AOI, produce and deliver a series of data products and alerts that trigger subsequent observations within the AOI.  The data products include MODIS browse image JPEG’s, MODIS Hot Pixel readout (level 2) ASCII, ASTER Level 1 georectified data, ASTER thermal summary TIFF, on-board thermal summaries from the UAS and EO-1 in TIFF, Level 1G data from both the UAS and EO-1 in GEOTIFF (HDF also available from EO-1), ground-based thermal classifier output for Level 1G images from both the UAS and EO-1 data.

==Formal Use Case Description==
=== Use Case Identification===

:Use Case Designation

::<Health-Disaster>.<Fire-WildFire-Observation-Coverage>.<1a>

:Use Case Name
::<Sensor Web for Wildfire>

Detection and classification of thermal properties on land can be made using passive spectroscopy from multispectral and hyperpsectral remote sensing instruments.  Sensor control and data delivery are executed by web services based on open source geo-spatially-enabled software.

===Revision Information===
:Prepared by:
::<Stuart Frye>

::<Noblis under contract to NASA GSFC as part of the AIST Sensor Web team >

::<17 April 2007, 15:30>

:Draft

:Modified by:
::<Modifier Name/Affil>, <Date/time>, <Brief Description>

===Definition===
 The web services implemented to enact the fire scenario are based on standard Open Geospatial Consortium standards.  A Sensor Observations Service, Sensor Planning Service, Sensor Alert Service, Web Feature Service, and Web Coverage Service are implemented for each node supplying sensor data.  Web Map Service is implemented for the client.  Web Processing Serice and Web Coordinate Transformation Service are implemented for nodes that produce classifier outputs.  Catalog Service for the Web is implemented for the registry.  RESTful approach is implemented where appropriate.  Web2.0 and other open source elements are employed.

===Successful Outcomes===
*1.Operation succeeds and user obtains QQQ.

===Failure Outcomes===

*1.Operation fails to return any XXX. Should instead YYYY.
*2.Illegal input of AAA, Should instead ZZZZ 

==General Diagrams==

===Schematic of Use case===

 A diagram of how the different elements and people/processes
 may fit together in the use case (if possible do not refer to 
 specific technologies).

==Use Case Elaboration==

 This section is intended to be completed with the details of the use case that
 are required for implementation. This section is not intended to be filled in by 
 an application user.

===Actors===

 Always identify primary actors, may be more than one. Also identify other actor
 including any other systems or services which are important. Primary actors 
 are usually ones that invoke the use case and are beneficiaries of the
 result. They may be human or computer. They are actionable. Other actors
 are those that support the primary actor, i.e. would be part of the use case
 without the tasks, work flow, resource, or requirements implied by the needs
 of the primary actor.

====Primary Actors====
The actor that initiates this use case is the portal User. 
Providers may also initiate this use case as a precursor to use case EIE05, Manage Collections/datasets.

====Other Actors====
Security actor, who authenticates the user requests and issues authorizations
for access to relevant data/resources.
 
===Preconditions===
*1.Collection metadata have been entered into the system
*2.Collection metadata have been validated
*3.Collection metadata have been published

===Postconditions===
*1.Datasets or granules have been identified within the system for further action
*2.Appropriate action (i.e. Map, download, process) controls have been provided to the user to initiate that action.
*3.Controls are provided to the user to refine the criteria used to 'discover' the dataset.

===Normal Flow (Process Model)===
*1)The user selects the 'dataset discovery' tool collection from the user interface
*2)The user performs a 'simple' search using a simple interface that searches commonly queries dataset attribute fields for matching text/terms.
*3)The results of the search are presented to the user with appropriate action controls associated with the datasets. 
*4)The user selects one of the action controls to 'use' the identified dataset(s) in a specified action (i.e. Visualization, download, processing)

===Alternative Flows===
*1)The user selects the 'dataset discovery' tool collection from the user interface
*2)The user selects a control that provides access to an advanced search tool that supports spatial, temporal, and parametric search methods. Flow then extends to EIE11-EIE14.

===Special Functional Requirements===
None

===Extension Points===
*<Cluster>.<SubArea>.<number>.<letter+1> something added or a variant.
E.g. AQ.Smoke.1.b something added or a variant
*<Cluster>.<SubArea>.<number>.<letter+2> something added or a variant
*<Cluster>.<SubArea>.<number>.<letter+3> something added or a variant

==Diagrams==

===Use Case Diagram===

===State Diagram===

===Activity Diagram===

===Other Diagrams===

==Non-Functional Requirements==

===Performance===

===Reliability===

===Scalability===

===Usability===

===Security===

===Other Non-functional Requirements===

==Selected Technology==

===Overall Technical Approach===

===Architecture===

===Technology A===

====Description====

====Benefits====

====Limitations====

===Technology B===

====Description====

====Benefits====

====Limitations====

==References==
None