Page tree

Versions Compared

Key

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

Coding principles

Baseline Data - ICAO Digital Data Sets

...

The Digital NOTAM encoding is based on the general temporality rules of AIXM 5, as detailed in the Temporality Concept document. Thus, most Digital NOTAM encodings will produce TEMPDELTA TimeSlices for the affected AIXM features. For example, a temporary navaid out of service event will be encoded as a new TimeSlice with interpretation equal-to 'TEMPDELTA' for the corresponding Navaid and including a property operationalStatus with value 'UNSERVICEABLE'.

...

The dependency on the availability of static (baseline) data in a specific data set is indicated for each Digital NOTAM event scenario concerned. Although it is theoretically possible to manually create the baseline data when needed, such an approach would significantly increase the risk of data encoding errors and reduce the quality of the Digital NOTAM data. Therefore, it is considered a critical prerequisite that all BASELINE data necessary for the encoding of the Event Scenarios described in this Specification is available in AIXM 5 format.

AIXM version

...

In general, the Digital NOTAM Specification does not need to be linked with a particular AIXM 5 version. Therefore, the term "AIXM 5" is used in this specification where discussing general principles. However, the coding and decoding rules for each particular scenario and the Event schema need to be linked to a particular AIXM version in order to avoid inconsistencies, which might occur due to attributes and list of values that change in new AIXM versions. Therefore, each edition of the Digital NOTAM Specification indicates a reference AIXM version:

  • the 1st edition of the Digital NOTAM Specification was developed using AIXM 5.1;
  • the 2nd edition is based in the AIXM version 5.1.1, which is also the reference for the provision of the baseline Digital Data Sets discussed previously.

Digitisation level to match the intended use

...

Digital NOTAM will be provided as AIXM 5 data sets. The logical data model of AIXM defines features and properties that enable the provision as separate data items of numerical values, coded values and textual elements. Therefore, many of the information items contains in a NOTAM message can also be provided as individual data elements, such as: names/identifiers of the item affected, operational status, schedules, levels, etc.

...

  • flight planning;
  • pilot briefing and in-flight awareness;
  • calculation of engine-out procedures (obstacle data);
  • graphical presentation of the airspace status for VFR/IFR activities;
  • graphical presentation of the aerodrome surface and services status;

Solution Completeness

...

In order to balance the implementation costs with the expected benefits, an incremental approach is likely to be followed by a large majority of the Digital NOTAM adopters. This raises a potential difficulty, as data users might need to consult two data sources:

...

To avoid this difficulty, the Digital NOTAM Specification needs to support from the beginning a complete solution. The NOTAMs that are not yet provided as fully structured digital encodings shall also be made available through the AIXM 5 data source. As a minimum, all text NOTAM shall be provided as "text notes" of the AIXM 5 feature concerned. This is supported by the AIXM Event Schema, with a dedicated NOTAM object, which can also be used as data source for text in NOTAM briefing applications.

Automatic text NOTAM generation

...

As a general principle, the encoding of the Digital NOTAM shall occur first and the application that supports the encoding shall be able to automatically generate the corresponding text NOTAM message, which complies with the ICAO requirements. The NOTAM shall also comply with eventual regional guidelines, such as contained in the European Operating Procedures for AIS Dynamic Data (OPADD).

...

In addition, developers of Digital NOTAM encoding application shall be aware that in particular situations the operator might need to adjust the content of the Q line (code, purpose, area of influence, etc.) in order to ensure a certain processing for that NOTAM for pre-flight purpose. Therefore, it might be necessary to allow modifications in the items A and Q of an automatically generated text NOTAM. Manual intervention in the other NOTAM items is strongly discouraged.

Use of upper and lower case text

...

The Event schema allows the automatic generated NOTAM text to be coded and provided as part of the Digital NOTAM data set. As for its distribution it is possible to use more advanced channels than AFTN, there is no constraint for this text to be only in upper case. As demonstrated by several human factors studies, the use of the usual "sentence case" mix of lower and upper case improves the readability of the information. This is particularly important for Pre-flight Information Bulletin (PIB) applications. Therefore, the Digital NOTAM Specification provides rules for generating the NOTAM text using lower case in general, while upper case is used only in specific cases, such as start of a sentence, place names, certain abbreviations and acronyms, etc.For NOTAM transmission over AFTN, the conversion into full upper case will still have to be done, but it is straight-forward.

...

Digital data more precise than NOTAM text

...

Digital data coding comes with the possibility to be more precise on the spatial location of an event as compared to the current NOTAM text messages. For example, a work in progress area on the apron can be provided as a polygon, thus eliminating any ambiguities with regard to its location. For users of the digital data the exact geographical location of the event or object is beneficial, because it can be used to automatically render it on a map or for other calculations. However, such information is difficult to provide as NOTAM text and also not very useful when provided in a NOTAM text. For example, the list of coordinates of a new 'polygon' obstacle in NOTAM text would an apron work area could require a very long and very complex E field , with no real benefit, as the data would be very anyhow difficult to extract and use in automated processeautomatically. The NOTAM messages were not intended to contain such detailed geometrical information. Only the information necessary for

Therefore, for certain events, only the information necessary for a human to identify the event will continue to be published location or extent is provided in the NOTAM text generated from the event data. The very detailed geometrical information could be is provided by in the Digital NOTAM (AIXM encoded data) only. This principle is applied to several Digital NOTAM coding scenarios, such as runway portion closure, new obstacle, apron portion closure, etc.

Even more, certain information updates could be made available just as digital data, if it is decided that a NOTAM does not need to be issued. For example, the GNSS outages could be encoded as digital events. However, if it is decided agreed that they are not needed as NOTAM messages, they could either stay just as digital data or could be published for human consumption in another format, such as a table on a Web site, a map, etc.

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.

A Digital NOTAM can be represented graphically much more precisely, showing the extent of the area or the feature affected. This is exemplified in the following two pictures, which compare the display of a restricted area as a circle (based on the NOTAM Q line) versus the real geometry of the airspace (as made possible by Digital NOTAM).

                  Text NOTAM  (center/radius)                              Digital NOTAM (real geometry)

Image RemovedImage Removed

Graphical visualisation of Digital NOTAM usually requires data which goes beyond strictly the features affected by the event. For example, a taxiway closure Digital NOTAM will provide the information about the closure status, eventual exceptions and schedules of the closure. In order to graphically display this closure on an airport map, the geometry of that taxiway is necessary. This might not be available in the message that contains the Event data and might require querying a source of reference database. A system providing Digital NOTAM data to consumer application might include the provision of ‘reference data’, to support applications such as graphical visualisation. Such data might be included directly in the Digital NOTAM messages (as an option) or be provided as a separate service.

The graphical capabilities offered by Digital NOTAM can be exploited in the provision of digitally enhanced Preflight Information Bulletin services and products. Such a specification was developed through the SESAR Research projects.

Event filtering capabilities

In AIXM, it was not possible to have a unified handling of the locations of features because many aeronautical features have specific geometries or even no geometry at all. An airspace is a collection of polygons, an airport has a reference point but also a "boundary" polygon, an instrument approach procedure has a complex 3D flying trajectory, while services typically do not have any geometry of their own, etc.

Obviously, this complicates the spatial queries. However, a spatial query alone will probably not satisfy the future Digital NOTAM client applications. The text NOTAM messages of today and their Q Line already enable spatial filtering. The result is what is called a "narrow route bulletin". However, the current pre-flight information bulletins contain, on average, 50% NOTAM messages that are irrelevant because it is currently not possible filter out all information that is not pertinent for the affected aircraft or flight, for example. Filtering out such information requires interpreting the feature properties affected by the event. In the future, more intelligent queries will be needed in order to better filter the information that is presented to the pilot, beyond the basic spatial queries. It is possible that each AIXM feature type will need its own selection criteria.

Pure spatial filtering might still be applied as an initial pre-selection of the Events that need to be transmitted to a client. Therefore, the AIXM Event Schema needs to support the provision of a basic "bounding box" geometry, to be used in those scenarios that require basic spatial filtering. This is already supported in the model, because the Event is an AIXM feature and therefore has a bounding box as any other GML feature. Details about the calculation of the {{Bounding Box}} size are provided in a specific data encoding rule.

Data synchronisation requirements

Missing a pertinent NOTAM can cause a significant safety hazard and missing a Digital NOTAM is no different. To prevent such risks, the text NOTAM production and distribution systems have mechanisms (sequential numbering, checklists, etc.) that enable a user to check if they are in possession of all applicable NOTAM messages. Similar mechanisms must be put in place when working with Digital NOTAMs. However, these mechanisms are allowed to be different from the mechanisms used for the synchronisation of NOTAM text message sets. The requirements may also be different, as Digital NOTAM synchronisation requires both:

  • the synchronisation of the BASELINE data, without which the TEMPDELTA TimeSlices cannot be processed correctly;
  • the synchronisation of the PERMDELTA and TEMPDELTA data itself;

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 neighbouring 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.

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?

...

Event coding only on feature concerned

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 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.

A Digital NOTAM can be represented graphically much more precisely, showing the extent of the area or the feature affected. This is exemplified in the following two pictures, which compare the display of a restricted area as a circle (based on the NOTAM Q line) versus the real geometry of the airspace (as made possible by Digital NOTAM).

                  Text NOTAM  (center/radius)                              Digital NOTAM (real geometry)

Image AddedImage Added

Graphical visualisation of Digital NOTAM usually requires data which goes beyond strictly the features affected by the event. For example, a taxiway closure Digital NOTAM will provide the information about the closure status, eventual exceptions and schedules of the closure. In order to graphically display this closure on an airport map, the geometry of that taxiway is necessary. This might not be available in the message that contains the Event data and might require querying a source of reference database. A system providing Digital NOTAM data to consumer application might include the provision of ‘reference data’, to support applications such as graphical visualisation. Such data might be included directly in the Digital NOTAM messages (as an option) or be provided as a separate service.

The graphical capabilities offered by Digital NOTAM can be exploited in the provision of digitally enhanced Preflight Information Bulletin services and products. Such a specification was developed through the SESAR Research projects.

Event filtering capabilities

...

In AIXM, it was not possible to have a unified handling of the locations of features because many aeronautical features have specific geometries or even no geometry at all. An airspace is a collection of polygons, an airport has a reference point but also a "boundary" polygon, an instrument approach procedure has a complex 3D flying trajectory, while services typically do not have any geometry of their own, etc.

Obviously, this complicates the spatial queries. However, a spatial query alone will probably not satisfy the future Digital NOTAM client applications. The text NOTAM messages of today and their Q Line already enable spatial filtering. The result is what is called a "narrow route bulletin". However, the current pre-flight information bulletins contain, on average, 50% NOTAM messages that are irrelevant because it is currently not possible filter out all information that is not pertinent for the affected aircraft or flight, for example. Filtering out such information requires interpreting the feature properties affected by the event. In the future, more intelligent queries will be needed in order to better filter the information that is presented to the pilot, beyond the basic spatial queries. It is possible that each AIXM feature type will need its own selection criteria.

Pure spatial filtering might still be applied as an initial pre-selection of the Events that need to be transmitted to a client. Therefore, the AIXM Event Schema needs to support the provision of a basic "bounding box" geometry, to be used in those scenarios that require basic spatial filtering. This is already supported in the model, because the Event is an AIXM feature and therefore has a bounding box as any other GML feature. Details about the calculation of the {{Bounding Box}} size are provided in a specific data encoding rule.

Data synchronisation requirements

...

Missing a pertinent NOTAM can cause a significant safety hazard and missing a Digital NOTAM is no different. To prevent such risks, the text NOTAM production and distribution systems have mechanisms (sequential numbering, checklists, etc.) that enable a user to check if they are in possession of all applicable NOTAM messages. Similar mechanisms must be put in place when working with Digital NOTAMs. However, these mechanisms are allowed to be different from the mechanisms used for the synchronisation of NOTAM text message sets. The requirements may also be different, as Digital NOTAM synchronisation requires both:

  • the synchronisation of the BASELINE data, without which the TEMPDELTA TimeSlices cannot be processed correctly;
  • the synchronisation of the PERMDELTA and TEMPDELTA data itself;

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.