Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The AIXM data model, in particular for the airport and navaid related data, enables the coding of usage/availability/status both for individual aeronautical information features (such as an aircraft parking stand, etc.) and for "global" features (such as an apron, a runway or the airport/heliport itself). Thus, if a 'child' feature (such as an aircraft stand) is unavailable, it is also possible to code a 'limited availability' situation for the 'owner' feature. This would unnecessarily increase the complexity of the coding scenarios and could give unnecessary "limited availability' warnings to some data users, for which maybe the unavailability of the lower-level elements is irrelevant. Therefore, the principle applied in the coding scenarios is that the usage/availability/status is coded only on the aeronautical information feature affected, without duplicating the information at the level of the parent feature. It is left for the data users to derive the necessary information, according to their operational needs, with regard to the usage/availability/status of the parent aeronautical information features.

Event

...

There exist many operational dependencies between situations that can affect various aeronautical features. For example:

  • navaid outages can trigger the unavailability of certain routes or procedures;
  • the creation or the activation of restricted areas can trigger the closure of certain route segments or the deactivation of other areas;
  • the displacement of a runway threshold can trigger changes in the runway declared distances and landing minima;
  • etc.

In the current version, no work has been done yet in order to identify the rules that control such dependencies between events. Discussions in the Digital NOTAM Focus Group have enabled to identify the following aspects in relation with dependencies between events:

  • First, a question of principle - should the identification of dependencies be done by the data originator or by the end user? For example, in case of a navaid outage, should the Digital NOTAM originator also issue notifications about the unavailability of certain procedures/routes? Or should this be left for the end user, based on the technical/operational capabilities of the aircraft/crews involved?
  • It is expected that Digital NOTAM will enable to more efficiently identify situations where an event in a neighbouring State has consequences on the availability of routes or procedures in their area of responsibility. Today, such dependencies are difficult to identify as they would require a manual monitoring of the NOTAM issued by neighbouring States. With digital data, such monitoring and alerts could be easier and less expensive to put in place.

Usage principles

Graphical presentation of Digital NOTAM

One of the major advantages of Digital NOTAM (as compared with the current text NOTAM) is that it enables the automatic creation of more precise graphical representations of the event. In the case of an ad-hoc restricted area, a navigation warning, a temporary obstacle, a taxiway closure, etc. the real location and geometry of the feature can be presented graphically. 

...

operational location

An Event may be associated with one or more airports or with Flight Information Regions (FIR), in the same way that a NOTAM location is declared in item A. The main purpose of this association is to support the selection of events that need to be presented in the airport or route sections of Preflight Information Bulletins (PIB). This association expresses an "operational location", which may be different or more complex than the simple geographical location of the aeronautical feature change of the Event. For example, a temporary restricted area might have an operational significance for an airport that is not directly in its vicinity. The Event may in this case be explicitly associated with the airport concerned, in order to ensure that the information about the airspace restriction is communicated in the PIB for that airport.

Event dependencies

There exist many operational dependencies between situations that can affect various aeronautical features. For example:

  • navaid outages can trigger the unavailability of certain routes or procedures;
  • the creation or the activation of restricted areas can trigger the closure of certain route segments or the deactivation of other areas;
  • the displacement of a runway threshold can trigger changes in the runway declared distances and landing minima;
  • etc.

In the current version, no work has been done yet in order to identify the rules that control such dependencies between events. Discussions in the Digital NOTAM Focus Group have enabled to identify the following aspects in relation with dependencies between events:

  • First, a question of principle - should the identification of dependencies be done by the data originator or by the end user? For example, in case of a navaid outage, should the Digital NOTAM originator also issue notifications about the unavailability of certain procedures/routes? Or should this be left for the end user, based on the technical/operational capabilities of the aircraft/crews involved?
  • It is expected that Digital NOTAM will enable to more efficiently identify situations where an event in a neighbouring State has consequences on the availability of routes or procedures in their area of responsibility. Today, such dependencies are difficult to identify as they would require a manual monitoring of the NOTAM issued by neighbouring States. With digital data, such monitoring and alerts could be easier and less expensive to put in place.

Usage principles

Graphical presentation of Digital NOTAM

...

One of the major advantages of Digital NOTAM (as compared with the current text NOTAM) is that it enables the automatic creation of more precise graphical representations of the event. In the case of an ad-hoc restricted area, a navigation warning, a temporary obstacle, a taxiway closure, etc. the real location and geometry of the feature can be presented graphically. 

The Q line of an ICAO NOTAM message includes a geographical position and a radius, which were originally intended as NOTAM filtering parameters, for selecting NOTAM geographically. This is commonly exploited in order to represent the NOTAM graphically, as a circle. For airport NOTAM, the circle is typically centered on the Airport Reference Point (ARP) location and has a radius of 5 NM. Also, many NOTAM are issued with a maximum radius of 999 NM in order to ensure that they appear in all PIB. These aspects limit significantly the use of this location/radius as graphical representation of a NOTAM.

...

This could be supported through reports that contain the list of all valid TimeSlices - sequence number and correction number for each feature, identified by UUID or by a SNAPSHOT TimeSlice containing feature identifying properties (natural key). An AIXM BasicMessage could be used for this purpose.Another aspect that requires the attention of Digital NOTAM receivers is the risk of duplicate information, in particular for data situated in the vicinity of two or more areas of responsibility. This duplication already exists today in the form of different NOTAM messages issued by different States for the same facility or situation. With Digital NOTAMs, this risk to happen as well because of potential difficulties in coordinating the data publication between neighboring States, also taking into consideration the need for rapid data dissemination. With Digital NOTAMs, the risk should be reduced at least when it concerns updates to existing facilities, as the TEMPDELTA is expected to be issued by the same authority who has issued the BASELINE data. However, for situations when a new temporary item is announced (such as a temporary obstacle in the vicinity of the boundary), there is still a risk of lack of coordination. This may result in duplicate data being issued. Therefore, Digital NOTAM recipients should foresee appropriate actions for dealing with both potentially duplicate PERMDELTA and BASELINE data.be used for this purpose.

Another aspect that requires the attention of Digital NOTAM receivers is the risk of duplicate information, in particular for data situated in the vicinity of two or more areas of responsibility. This duplication already exists today in the form of different NOTAM messages issued by different States for the same facility or situation. With Digital NOTAMs, this risk to happen as well because of potential difficulties in coordinating the data publication between neighboring States, also taking into consideration the need for rapid data dissemination. With Digital NOTAMs, the risk should be reduced at least when it concerns updates to existing facilities, as the TEMPDELTA is expected to be issued by the same authority who has issued the BASELINE data. However, for situations when a new temporary item is announced (such as a temporary obstacle in the vicinity of the boundary), there is still a risk of lack of coordination. This may result in duplicate data being issued. Therefore, Digital NOTAM recipients should foresee appropriate actions for dealing with both potentially duplicate PERMDELTA and BASELINE data.

Discrepancies between digital data and NOTAM text

TBD

  • explain that this is a general issue, it may concern all AIS products
  • Annex 15 says that it is the obligation of AIS to ensure consistency
  • it is an error, it is not possible to indicate in advance which of the products (the digital or the pre-formatted takes precedence)