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 JPL and gets updated fire location and intensity readings at 30m resolution for fires within the AOI. The browse image is retrieved for any data posted in the last 24 hours. 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 250m 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 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

Quick test that would show whether or not the case is working as described.

Formal Use Case Description

Use Case Identification

Use Case Designation

<ApplicationArea>.<SubArea>.<ReferenceNumber>

Use Case Name

<Insert short name and long name>

Revision Information

Prepared by:

<Author(s) with responsibility>

<Affiliation>

<Date/Time created>

Version X.N.a (can be labeled draft if X=0)

Modified by:

<Modifier Name/Affil>, <Date/time>, <Brief Description>

Definition

First paragraph is short description, second paragraph, etc. may contain
further details.

Through this use case, the system User locates and identifies datasets (collections of related
grandules) for use or processing. This process results in the User having access to a subset of
the datasets in the portal that meet the requirements of the User. Individual datasets, and their
constituent granules, may then be identified for further action or processing (e.g. Visualization,
analysis, download). 

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

References

None