The unavailability of a ground based radio navigation equipment and service, both if used for en-route or for airport.
- this scenario enables the encoding of the information about the unavailability (or limited availability) of a complete navaid or of one of its component equipments. In case a component is concerned, this is limited to the unavailability of a single component;
- in order to keep the digital encoding consistent with the current practices, the term "primary component" is used in the case of composite navaids (such as VOR/DME, ILS, etc.) The principle is that the unavailability of composite navaid is considered directly related only to the unavailability of its primary components. The unavailability of a non-primary component (such as a MKR used by an ILS) needs to be encoded separately;
- this scenario does not cover the downgrading of an ILS category;
- this scenario does not support the modification of information about navaid coverage/range. Although this data can be encoded digitally using AIXM 5.1(.1), no immediate usage has been identified and therefore that scenario is left for being defined later.
The following diagram identifies the information items that are usually provided by a data originator for this kind of event.
The table below provides more details about each information item contained in the diagram. It also provides the mapping of each information item within the AIXM 5.1 structure. The name of the variable (first column) is recommended for use as label of the data field in human-machine interfaces (HMI).
The type of navaid service. In combination with other items, this is used to identify the Navaid and/or the NavaidEquipment concerned.
Navaid.type with the list of values CodeNavaidServiceType and/or one of the non-abstract subtypes of NavaidEquipment
The published designator of the navaid. In combination with other items, this is used to identify the Navaid and/or NavaidEquipment concerned.
Navaid.designator and/or NavaidEquipment.designator
runway direction designator
The designator of the runway direction that is served by the navaid (especially for ILS). In combination with other items, this is used to identify the Navaid concerned.
A specific navaid equipment, used as part of a composed navaid service, in case the unserviceable status affects only this component. In combination with other items, this is used to identify the NavaidEquipment and eventually other Navaid(s) concerned.
One of the non-abstract subtypes of NavaidEquipment
A specific sub-signal of a composed navaid service, in case the unserviceable status affects only this signal type. In this scenario, this is limited to the Azimuth or Distance indication of a TACAN Navaid.
NavaidOperationalStatus.signalType. This can be specified only if the navaid is a TACAN or VORTAC and only the values "AZIMUTH" or "DISTANCE" may be used from its list of values (CodeRadioSignalType)
The operational status. The typical value is "unserviceable", also abbreviated "U/S". Other values are possible, such as "on test, do not use", "false indication possible", etc.
(NavaidEquipment and Navaid)/NavaidOperationalStatus.operationalStatus
The effective date & time when the event starts
(Navaid and NavaidEquipment)/TimeSlice/TimePeriod.beginPosition, Event/EventTimeSlice.validTime/timePosition and Event/EventTimeSlice.featureLifetime/beginPosition
The end date & time when the event ends. It might be an estimated value.
(Navaid and NavaidEquipment)/TimeSlice/TimePeriod.endPosition and Event/EventTimeSlice.featureLifetime/endPosition also applying the rules for Events with estimated end time
A schedule might be provided, in case the navaid status changes according to a regular timetable, within the period between the start time and the end time.
(Navaid and/or NavaidEquipment)/NavaidOperationalStatus/Timesheet/... according to the rules for Event Scheduled
A reason for the navaid operational status change
(Navaid and/or NavaidEquipment)/NavaidOperationalStatus.annotation with propertyName='operationalStatus' and purpose='REMARK'
A free text note that provides further instructions concerning the navaid operational status situation.
(Navaid and/or NavaidEquipment)/NavaidOperationalStatus.annotation with purpose='REMARK'
A reference (name, designator) to one or more airports/heliports for which the operational status of the navaid has an operational relevance and needs to be notified to the users thereof (if such information is known to the data originator)
Note: a default list of 'affected airports' might need to be maintained in the application used for the Digital NOTAM coding.
A reference (type, designator) to one or more neighboring airspace of type FIR, for which the operational status of the navaidhas an operational relevance and needs to be notified (if such information is known to the data originator).
Note: the FIR(s) within which the area is physically situated do not need to be provided by the data originator. They will be automatically identified by the application that enables the coding of the Event.
- The word "locator" is expected to be used for low power NDB in the operational language.
Assumptions for baseline data
- It is assumed that information about the Navaid and NavaidEquipments concerned covering the complete period of validity of the event exists and it was coded as specified in the Coding Guidelines for the (ICAO) AIP Data Set - Navaid [NAV].
Proposals for Coding rule:
it is assumed that no NavaidEquipment exists without being used as component for at least one Navaid;
it is assumed that all Navaid of type ILS or MLS are associated with at least one runway direction.
Data encoding rules
The data encoding rules provided in this section shall be followed in order to ensure the harmonisation of the digital encodings provided by different sources. To the maximum possible extent, the compliance with these encoding rules shall be verified with automatic data validation rules.
Note that, in the case of composite Navaid (that have more than one navaid component) the term "primary components" has the following meaning:
[for data encoding purpose in this scenario]
VOR, DME, NDB, TACAN, MKR, VORTAC, VOR_DME, NDB_DME, TLS, LOC, LOC_DME, NDB_MKR, DF, SDF, OTHER
All NavaidEquipment that compose the Navaid
Localizer and Glidepath
Localizer, Glidepath and DME
Azimuth and Elevation
Azimuth, Elevation and DME
Data encoding rule
First, create a new Event with a BASELINE TimeSlice (scenario=”NAV.UNS”, version=”2.0”) for which a PERMDELTA TimeSlice may also be provided
Second, identify the NavaidEquipment that are affected, as follows:
For each of these NavaidEquipment:
Third, identify the Navaid affected by considering all Navaid which use one or more of the NavaidEquipment identified applying ER-02 as primary component.
Important Note: if more than one Navaid is concerned, this scenario shall be applied for each such Navaid separately.
For the corresponding Navaid:
The value 'PARTIAL' can only be used only for the operationalStatus of a TACAN, if just one of its signalType ('AZIMUTH' or 'DISTANCE') is affected.
The values 'FALSE_POSSIBLE', 'CONDITIONAL' and 'DISPLACED' cannot be used in this scenario.
The value 'UNSERVICEABLE' shall be used only if the navaid does not emit any signal. Otherwise, the value 'ON_TEST' shall be used (which will be decoded as "On test, do not use. False indication possible").
In the case of a Navaid for which all its primary components NavaidEquipment are affected (have a temporarily changed operational status), then its NavaidOperationalStatus.operationalStatus attribute shall get the value specified by the "operational status" input parameter.
Note: because this scenario is limited to one Navaid and one component only, this means that ER-07 is applicable only to Navaid that have a single primary component.
In the case of a Navaid for which only some of its components (primary or not primary) NavaidEquipment are affected (have a temporarily changed operational status) but not all, then the TEMPDELTA TimeSlice of the Navaid shall have the value indicated in the following table (priority from top to bottom):
For example, if a VOR (equipment) component of a VOR/DME Navaid (service) is unserviceable, then the Navaid (of type VOR/DME) shall have a TEMPDELTA TimeSlice with operationalStatus='PARTIAL'. In the same time, the VOR (NavaidEquipment) will have a TEMPDELTA TimeSlice with operationalStatus='UNSERVICEABLE'.
Note: because this scenario is limited to one Navaid and one component only, this means that the first column of the table above refers to that single component that is affected by the temporary situation.
In the case of a Navaid that has more than one NavaidEquipment component, if only some (one, in this scenario) of its primary components NavaidEquipment are affected (have a temporarily changed operationalStatus = 'UNSERVICEABLE', 'ON_TEST', 'FALSE_INDICATION' or 'IN_CONSTRUCTION') but not all, then it is possible that the unavailability of one of the components changes the nature of the navaid service. If this is the case, then the TEMPDELTA TimeSlice encoded for the Navaid shall also temporarily change the type of the Navaid. For example, if the DME component of a VOR/DME navaid is unserviceable, then the Navaid TEMPDELTA TimeSlice shall also indicate that type="VOR" only and the operationalStatus shall be "PARTIAL". The table below provides more detailed rules:
If the Navaid or NavaidEquipment status change is limited to a discrete schedule within the overall time period between the "start time" and the "end time", then this shall be encoded using as many as necessary timeInterval/Timesheet properties for the NavaidOperationalStatus of their TEMPDELTA Timeslice. See also the rules for Event Schedules. It is recommended that the HMI of a data provider application allows to provide a schedule only in relation with active times, because only these will be translated into NOTAM text.
In accordance with the AIXM Temporality Concept (see sections 3.4 and 3.5 in version 1.0), the NavaidOperationalStatus associated with the TEMPDELTA replaces all the BASELINE NavaidOperationalStatus information, during the TEMPDELTA time of applicability. Therefore, if the modified operational status only concerns certain times, the other times when the navaid or equipment eventually remains with the same status as in the Baseline data, shall be explicitly included in the TEMPDELTA. The calculation of the necessary additional NavaidOperationalStatus elements to be included in the TEMPDELTA shall be automatically done by the applications implementing this specification.
All NavaidOperationalStatus elements that are copied from the BASELINE data for completeness sake shall get an associated Note with purpose='REMARK' and the text='Baseline data copy. Not included in the NOTAM text generation'. This is based on the current NOTAM practice which consists of including in the NOTAM only the changed information and not explicitly including the static data that remains valid during the NOTAM applicability. It is recommended that the input interface provides a "calendar/level" view of the navaid/equipment unserviceability, enabling the operator to graphically check the navaid/equipment operational status at different times, such as in the example below:
In the calendar view, the Baseline information that remains valid during the Event validity time shall be visibly identified from the information that is specific to the Event, for example by using a different colour fill pattern.
The system shall automatically identify the FIR where the Navaid is located. This shall be coded as corresponding concernedAirspace property in the Event
If any different "affected FIR" from the one determined above is provided by the data originator, then corresponding concernedAirspace property(ies) shall be coded in the Event.
|If an "affected aerodrome" is provided by the data originator, then a corresponding concernedAirportHeliport property shall be coded in the Event.
Following coding examples can be found on GitHub (links attached):