Difference between revisions of "E-SURFMAR definitions"

From Surfmar
Jump to navigation Jump to search
 
 
(7 intermediate revisions by 2 users not shown)
Line 1: Line 1:
This page is dedicated to the E-SURFMAR definitions such as ''Operational drifting buoys'', ''drifting buoy lifetime''...
+
{| border="1" cellpadding="2" cellspacing="0" align="center"
 +
|-
 +
| width=300px style="background:#efefef;" align="center" | This page is dedicated to the E-SURFMAR definitions of terms used in the documentation.
 +
|-
 +
|}
 +
==VOS ships==
 +
'''Conventional VOS'''
 +
* Ship or platform recruited by a National Meteorological Service to  manually collect observations which are normally reported using the ship own transmission equipment
 +
 
 +
'''Automatic Weather Station (AWS)'''
 +
* In the case of VOS, an integrated shipborne system for automatically collecting data measured by a number of sensors and for transmitting such data ashore normally using a dedicated transmission system.
 +
 +
'''Integrated AWS'''
 +
* An AWS system which typically measures a variety of meteorological and / or oceanographic parameters and which requires integration with the host ships systems (e.g. ships compass, power supply, etc). Integrated AWS should ideally also permit observers to manually add visual observations using data display and entry software prior to data transmission, although this is not essential.
 +
 
 +
'''Autonomous AWS'''
 +
* An AWS system which typically measures a reduced number of meteorological and / or oceanographic parameters, but which is independent on the host ships systems (other than the ships power supply). Autonomous AWS can generally be considered as 'plug and play' systems as they require minimal interference with the host ships infrastructure or systems, and can be quickly installed or removed. They can incorporate a static data display of the measured parameters, but do not include a facility to enable observers to manually add visual observations prior to data transmission.
 +
 
 +
'''Manned observations'''
 +
* Observations which are carried out by  ships observing officers (or by other seagoing or offshore platform personnel) and which are derived visually from meteorological or oceanographic instruments, or from direct visual observations
 +
 
 +
'''Visual observations'''
 +
* Meteorological or oceanographic observations which are carried out by  ships observing officers (or by other seagoing or offshore platform personnel) and which typically include observations of sea state, visibility clouds, present and past weather etc.
 +
 
 +
'''Automated observations'''
 +
* Measurements derived and collected by AWS sensors.
 +
 
 +
'''Active VOS'''
 +
* A VOS which has reported at least two observations during a given time period (e.g. a month or a year)
 +
 
 +
 
 +
==Data Buoys==
 +
'''Buoy period'''
 +
* The operational period for a buoy. In practice there is only one buoy period record for a drifting buoy unless it is being refurbished (or redeployed at another location after displacement, e.g. after fishing vessel pickup). For moored buoys we have as many buoy periods as periods of the buoy operations with no human intervention. In other words, whenever maintenance is being done on a moored buoy we have to create a new buoy period record.
 +
 
 +
'''Operational buoy'''
 +
* Drifting buoy: reporting at least air pressure onto GTS
 +
* Moored buoy: ...
 +
 
 +
'''Operational lifetime'''
 +
* Drifting buoy: time length of a buoy period, from deployment date  to the GTS out date when the buoy ends its buoy period due to technical failure, battery exhaustion, beach, pick up, early recovery, accidents and vandalism.
 +
 
 +
'''Technical failure'''
 +
* The buoy ends its operational period due to technical failure.
 +
 
 +
'''Battery exhaustion'''
 +
* The buoy ends its operational period due to battery exhaustion.
 +
 
 +
'''Beach'''
 +
* The buoy reaches the shoreline and is washed a shore.
 +
 
 +
'''Pick up'''
 +
* Not voluntary pick up from the sea e. g. done by fisherman
 +
 
 +
'''Early recovery'''
 +
* Voluntary pick up, e.g. buoy testing.
 +
 
 +
'''Accident'''
 +
* failure caused by sources outside the buoy which the buoy is not design to withstand, e. g. the parachute no not open during air deployment due to technical failure of the parachute, or the buoy is crushed between containers on a ship before deployment, etc.
 +
 
 +
'''Vandalism'''
 +
* damage on the buoy made on purpose
 +
 
 +
'''Early failure'''
 +
* Buoy failure within 30 days after deployment.
 +
* Is it necessary to define this term in more details? e.g. that early failure because of the way it was deployed (methods not recommended from the buoy manufacturer or accidents) that makes the buoy fail and not due to a weakness with buoy? (see comments under Calculation of average lifetime)
 +
 
 +
'''Lifetime of a buoy type/model'''
 +
* Arithmetic average of the operational lifetime of all buoys within the group that ends its operational period due to technical failure and battery exhaustion.
 +
 
 +
'''Operational lifetime of a buoy type/model'''
 +
* Arithmetic average of the lifetime of all buoys within the group except buoys being early recovered.
 +
 
 +
'''Calculation of average lifetime for buoys that ceased to operate'''
 +
* '''NB!''' A buoy that is not transmitting AP (AP sensor has failed), but is in other way functioning (reporting all other kinds of data), is defined as NOT OPERATING. In calculation of average lifetime for buoys that ceased to operate these buoys must be included.
 +
* '''?''' Consequent labelling of EGOS buoys in respect of time. Is the buoy defined as an EGOS buoy before deployment? Can one make a definition that clarifies which buoys that is taken into account, e.g. to avoid that sometimes the buoys that fail immediately after deployment is not taken into account depending on who is doing the registrations and calculations. Maybe there are incidents where it is clearly the way it was deployed that makes the buoy fail and not due to a weakness with buoy. Could these cases be identified? Would it be right to exclude these buoys from the calculation of average lifetime?
 +
* Other cases that needs to be clarified?
 +
 
 +
 
 +
==Communications==
 +
'''Real time mode data'''
 +
* Data which are sent immediately after the observation time and inserted onto the GTS soon thereafter - typically within one hour to meet  model cut-off time limits.
 +
 
 +
'''Delayed mode data'''
 +
* The original or raw data collected by, or transmitted from, a marine observing platform. In the case of an observing ship this would normally be the  log  files which are stored in the ships electronic logbook software for subsequent download, and in the case of a drifting buoy this would normally be the raw transmitted Argos or iridium data prior to data processing.
 +
 
 +
'''GTS Station Identifier'''
 +
* An identifier assigned to report real time weather observations onto the GTS. This identifier may be an assigned WMO number (e.g. for a data buoy, offshore platform, glider etc), a call sign assigned by the ITU to a ship, or a WIGOS identifier (under development). A Masked Station Identifier or an Encrypted Station Identifier may also be used for sending data to the GTS.
 +
 
 +
'''Masked Station Identifier'''
 +
* A ‘masked’ identifier may be assigned, at the request of a shipowner of manager, to real time messages sent from a ship or an automatic weather station installed on a ship, or from an ASAP ship. It can be assigned to the message transmitted from the ship or assigned ashore using a configuration file.  Instructions for assigning Masked identifiers are maintained on [http://sot.jcommops.org/sot/vos/documents/mask_implementation_instructions.pdf the VOS website].  Masked identifiers are not included with the ship metadata required by WMO Pub no 47, but are maintained by JCOMMOPS in a confidential Mask vs Real database, access to which is  restricted to WMO approved subscribers or co-sponsored programmes with legitimate requirements.  Masked station identifiers should be unique and should not conflict with other identifiers such as a call sign.
 +
 
 +
'''Encrypted Station Identifier'''
 +
* Unique non-repeating encrypted identifiers are typically derived from  ships ITU assigned (REAL) call sign and other elements  in message such as date/time and lat/long values.  BUFR Code template TM308014 will in due course facilitate this encryption of real time ship data, and only authorised people within the will have access to the decrypted BUFR messages containing the ship’s call signs.  E-SURFMAR raw dataformats #100 and #101 contain one bit that determines whether encryption has been applied.  If required it will also be possible to encrypt a Masked identifier.
 +
 
 +
'''‘SHIP’ Station identifier'''
 +
* Some ships may be assigned a non unique SHIP identifier. This is used in lieu of the ships ITU assigned call sign and  can be sent in the real time message, or alternatively only used in the delayed mode message, depending on the requirements of the ship owner or manager.
 +
 
 +
 
 +
==References==
 +
* '''Hageberg, A. A''' (2003): Additional specification of a new relational meta database for EGOS and other DBCP Action groups, CMR-03/A10020

Latest revision as of 09:26, 29 April 2016

This page is dedicated to the E-SURFMAR definitions of terms used in the documentation.

VOS ships

Conventional VOS

  • Ship or platform recruited by a National Meteorological Service to manually collect observations which are normally reported using the ship own transmission equipment

Automatic Weather Station (AWS)

  • In the case of VOS, an integrated shipborne system for automatically collecting data measured by a number of sensors and for transmitting such data ashore normally using a dedicated transmission system.

Integrated AWS

  • An AWS system which typically measures a variety of meteorological and / or oceanographic parameters and which requires integration with the host ships systems (e.g. ships compass, power supply, etc). Integrated AWS should ideally also permit observers to manually add visual observations using data display and entry software prior to data transmission, although this is not essential.

Autonomous AWS

  • An AWS system which typically measures a reduced number of meteorological and / or oceanographic parameters, but which is independent on the host ships systems (other than the ships power supply). Autonomous AWS can generally be considered as 'plug and play' systems as they require minimal interference with the host ships infrastructure or systems, and can be quickly installed or removed. They can incorporate a static data display of the measured parameters, but do not include a facility to enable observers to manually add visual observations prior to data transmission.

Manned observations

  • Observations which are carried out by ships observing officers (or by other seagoing or offshore platform personnel) and which are derived visually from meteorological or oceanographic instruments, or from direct visual observations

Visual observations

  • Meteorological or oceanographic observations which are carried out by ships observing officers (or by other seagoing or offshore platform personnel) and which typically include observations of sea state, visibility clouds, present and past weather etc.

Automated observations

  • Measurements derived and collected by AWS sensors.

Active VOS

  • A VOS which has reported at least two observations during a given time period (e.g. a month or a year)


Data Buoys

Buoy period

  • The operational period for a buoy. In practice there is only one buoy period record for a drifting buoy unless it is being refurbished (or redeployed at another location after displacement, e.g. after fishing vessel pickup). For moored buoys we have as many buoy periods as periods of the buoy operations with no human intervention. In other words, whenever maintenance is being done on a moored buoy we have to create a new buoy period record.

Operational buoy

  • Drifting buoy: reporting at least air pressure onto GTS
  • Moored buoy: ...

Operational lifetime

  • Drifting buoy: time length of a buoy period, from deployment date to the GTS out date when the buoy ends its buoy period due to technical failure, battery exhaustion, beach, pick up, early recovery, accidents and vandalism.

Technical failure

  • The buoy ends its operational period due to technical failure.

Battery exhaustion

  • The buoy ends its operational period due to battery exhaustion.

Beach

  • The buoy reaches the shoreline and is washed a shore.

Pick up

  • Not voluntary pick up from the sea e. g. done by fisherman

Early recovery

  • Voluntary pick up, e.g. buoy testing.

Accident

  • failure caused by sources outside the buoy which the buoy is not design to withstand, e. g. the parachute no not open during air deployment due to technical failure of the parachute, or the buoy is crushed between containers on a ship before deployment, etc.

Vandalism

  • damage on the buoy made on purpose

Early failure

  • Buoy failure within 30 days after deployment.
  • Is it necessary to define this term in more details? e.g. that early failure because of the way it was deployed (methods not recommended from the buoy manufacturer or accidents) that makes the buoy fail and not due to a weakness with buoy? (see comments under Calculation of average lifetime)

Lifetime of a buoy type/model

  • Arithmetic average of the operational lifetime of all buoys within the group that ends its operational period due to technical failure and battery exhaustion.

Operational lifetime of a buoy type/model

  • Arithmetic average of the lifetime of all buoys within the group except buoys being early recovered.

Calculation of average lifetime for buoys that ceased to operate

  • NB! A buoy that is not transmitting AP (AP sensor has failed), but is in other way functioning (reporting all other kinds of data), is defined as NOT OPERATING. In calculation of average lifetime for buoys that ceased to operate these buoys must be included.
  • ? Consequent labelling of EGOS buoys in respect of time. Is the buoy defined as an EGOS buoy before deployment? Can one make a definition that clarifies which buoys that is taken into account, e.g. to avoid that sometimes the buoys that fail immediately after deployment is not taken into account depending on who is doing the registrations and calculations. Maybe there are incidents where it is clearly the way it was deployed that makes the buoy fail and not due to a weakness with buoy. Could these cases be identified? Would it be right to exclude these buoys from the calculation of average lifetime?
  • Other cases that needs to be clarified?


Communications

Real time mode data

  • Data which are sent immediately after the observation time and inserted onto the GTS soon thereafter - typically within one hour to meet model cut-off time limits.

Delayed mode data

  • The original or raw data collected by, or transmitted from, a marine observing platform. In the case of an observing ship this would normally be the log files which are stored in the ships electronic logbook software for subsequent download, and in the case of a drifting buoy this would normally be the raw transmitted Argos or iridium data prior to data processing.

GTS Station Identifier

  • An identifier assigned to report real time weather observations onto the GTS. This identifier may be an assigned WMO number (e.g. for a data buoy, offshore platform, glider etc), a call sign assigned by the ITU to a ship, or a WIGOS identifier (under development). A Masked Station Identifier or an Encrypted Station Identifier may also be used for sending data to the GTS.

Masked Station Identifier

  • A ‘masked’ identifier may be assigned, at the request of a shipowner of manager, to real time messages sent from a ship or an automatic weather station installed on a ship, or from an ASAP ship. It can be assigned to the message transmitted from the ship or assigned ashore using a configuration file. Instructions for assigning Masked identifiers are maintained on the VOS website. Masked identifiers are not included with the ship metadata required by WMO Pub no 47, but are maintained by JCOMMOPS in a confidential Mask vs Real database, access to which is restricted to WMO approved subscribers or co-sponsored programmes with legitimate requirements. Masked station identifiers should be unique and should not conflict with other identifiers such as a call sign.

Encrypted Station Identifier

  • Unique non-repeating encrypted identifiers are typically derived from ships ITU assigned (REAL) call sign and other elements in message such as date/time and lat/long values. BUFR Code template TM308014 will in due course facilitate this encryption of real time ship data, and only authorised people within the will have access to the decrypted BUFR messages containing the ship’s call signs. E-SURFMAR raw dataformats #100 and #101 contain one bit that determines whether encryption has been applied. If required it will also be possible to encrypt a Masked identifier.

‘SHIP’ Station identifier

  • Some ships may be assigned a non unique SHIP identifier. This is used in lieu of the ships ITU assigned call sign and can be sent in the real time message, or alternatively only used in the delayed mode message, depending on the requirements of the ship owner or manager.


References

  • Hageberg, A. A (2003): Additional specification of a new relational meta database for EGOS and other DBCP Action groups, CMR-03/A10020