NASA Unmanned Aerial Vehicle (UAV)

User Story

NASA and NOAA use UAVs to observe hurricanes. These automated aircarft fly around and into hurricanes to get up to date and accurate observations, not available by any other means, to improve the forecast of the future hurricane track and possible destructive landfall. The observations are relayed back to the ground station via satellite and the aircaft navigates using GPS. The longer that the aircraft can fly, the more observations it can collect and the better the hurricane forecast.

A regional meteorological forecast model can forecast the winds, turbulence, temperature and humidity with a resolution of a few kilometres horizontally and 100m vertically, with time resolution of at least hourly or perhaps every 15min.

By receiving turbulence forecast, the aircraft could alter its flight path to reduce mission risk.

By receiving wind, temperature and humidity values for the surrounding 100km, the aircraft can optimise its flight path to minimise fuel consumption and maximise flight duration.

The different phases of the flight: take-off, ascent, outward, target area, homeward, descent and landing; have different requirements and may need different 'tilesets', whether content, resolutions or even service provider.

Actors

  1. Authorised server supplying data tiles covering Volume and Period Of Interest.
  2. One client UAV, of many, receiving data tiles local to its trajectory of Points Of Interest.
  3. Internediate web caches to allow other clients to receive the same tiles if appropriate.

Preconditions

The server and client have negotiated a tile service for an Volume and time duration Of Interest.

Main Success Scenario

As the client UAV moves in space and time, the client's local copies of data tiles are replaced and unneeded data tiles are deleted. The data tiles received allow the client to make informed decisions and alter course, speed and elevation.

Alternative Paths

  1. Client UAV moves out of volume, or out of time, of service and must negotiate a new service with another or the same supplier for new Volume Of Interest.
  2. The offered service does not have data of the appropriate (high enough) resolution to make sensible decisions.
  3. The Client UAV needs to take emergency action and follow a backup route involving a different Volume of Interest.

Postconditions

  1. The recently used/requested tiles remain in the client's local store for resilience.
  2. Time expired tiles are deleted from the client's local store and the web cache.
  3. The recently used/requested tiles remain in the web cache, unless the service enforces no cacheing.

Requirements Issues/Discussion

  1. Each tile could have a time extent with several data times, or each tile could have data only for one instant and separate tiles must be requested to cover a time period.
  2. Each tile could have a vertical extent with several data altitudes/levels, or each tile could have data only for one level and separate tiles must be requested to cover a vertical extent.
  3. It is envisaged that tiling is primarily horizontal (x,y) in extent, with z and t coordinates 'added'.
  4. Each tile could contain several different parameters of interest, or each tile could have data only for one parameter and separate tiles must be requested to cover that dimensional extent. E.g. Vector or tensor valued parameters, such as wind components or current speed and direction should probably be in the same tile, so a 'scanning pattern' is needed.

-- Main.clittle - 16 Jun 2015
Topic revision: r5 - 23 Jun 2015, clittle
 

This site is powered by FoswikiThe information you supply is used for OGC purposes only. We will never pass your contact details to any third party without your prior consent.
If you enter content here you are agreeing to the OGC privacy policy.

Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding OGC Public Wiki? Send feedback