Marine - 'Submarine Gliders' Use Case

User Story

One of the most important components of the earth's climate is the deep sub-surface flow of the oceans and seas. There are now about 3000 automated devices routinely deployed to measure temperature, salinity and currents at depth. These devices regularly surface and transmit their collected obs via satellite and then descend again for another submarine descent and ascent. When they reach the end of their battery life, they surface and request to be picked up by any appropriate research ship.

To maximise their voyage horizontal extent, some devices, called 'submarine gliders' have stubby wings or vanes that allow them to glide from the ocean surface to depth as slowly as possible and thus traverse long distances. Their trajectory follows a saw-tooth pattern. Typically, they may be descending and ascending between depths of 25m down to more than 1000m several times beofre surfacing. Journeys of more than 100 days and 1000s of kilometers are possible, usually at speeds of less than 1knot.

There are a number of global and regional oceanographic modelling centres that forecast the sub-surface structures of the oceans and seas. These structures consist of thermoclines (temperature determined 'weather fronts') and haloclines (salinity determined 'weather fronts') and the flows and circulations ('gyres') are driven by these combined density contours (called isopyknics).

If a submarine, while surfaced, can recieve a gridded dataset specifying the structures and currents nearby, it can either optimise its traverse, or make detours to verify and observe the forecast structures. Generally, the submarine cannot communicate while under water and must be autonomous. Typically a 4D grid of temperature, salinity and 3D current (u,v,w, in the x,y,z directions) would be needed. A global ocean model would have a horizontal grid spacing of 25km, ~100m in the vertical and forecast for up to 5 days.


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


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

Main Success Scenario

As the client submarine 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.


  1. The recently used/requested tiles remain in the client's local store for resilience.
  2. The recently used/requested tiles remain in the web cache, unless the service enforces no cacheing.

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 allow sensible decisions.
  3. On surfacing, the glider cannot recieve an updated set of relevant tiles. It could progress using prestored low resolution climatological set.

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 depths/levels, or each tile could have data only for one level and separate tiles must be requested to cover a vertical extent.
  3. Each tile could have a different, dimensional, extent with several data dimension values, or each tile could have data only for one dimension value and separate tiles must be requested to cover that dimensional extent. E.g. wavelength of sonar data.
  4. It is envisaged that tiling is primarily horizontal (x,y) in extent, with z and t coordinates 'added'.
  5. 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 3-D current speed and direction should probably be in the same tile, so a 'scanning pattern' is needed.

-- Main.clittle - 16 Jun 2015
Topic revision: r3 - 17 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