[AGS.UNS] Airport Ground Service unserviceable - coding
Definition
The notification that an airport ground service is temporary unserviceable at an airport.
Notes:
this scenario shall be used to notify that one of airport ground services is temporary unserviceable at an airport.
- this scenario does not cover the situation when the aircraft ground service is operating normally, but subject to a reason for caution.
- this scenario does not cover notifications on changes to FireFightingService, those are addressed in a separate FFS.CHG.
Event data
The following diagram identifies the information items that are usually provided by a data originator for this kind of event.
The following table 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.1 structure. The name of the variable (first column) is recommended for use as label of the data field in human-machine interfaces (HMI).
Data item | Description | AIXM mapping |
---|---|---|
designator | The published designator of the airport/heliport concerned. This information, in combination with eventually the name is used to identify the airport/heliport. | AirportHeliport.designator |
name | The published name of the airport/heliport. This information, in combination with the designator is used to identify the airport/heliport. | AirportHeliport.name |
type of airport ground service | The type (class) of airport ground service which is temporary unserviceable. | One of the specific services as listed below:
|
operational status | The indication of an airport ground service unserviceability. | AircraftGroundService/ServiceOperationalStatus or AirportSuppliesService/ServiceOperationalStatus or PassengerService/ServiceOperationalStatus with value = 'UNSERVICEABLE'. |
start time | The effective date & time when the unserviceability of one of the airport ground services starts . | AircraftGroundService or AirportSuppliesService or PassengerService/TimePeriod.beginPosition, Event/EventTimeSlice.validTime/timePeriod.beginPosition and Event/EventTimeSlice.featureLifetime/beginPosition |
end time | The effective date & time when the unserviceability of one of the airport ground services ends. Note: the end time can also be estimated. | AircraftGroundService or AirportSuppliesService or PassengerService /TimePeriod.endPosition, Event/EventTimeSlice.validTime/timePeriod.endPosition and Event/EventTimeSlice.featureLifetime/endPosition |
schedule | A schedule might be provided, in case the predicted interruption of one of the services is only active according to a timetable, within the period between the start of life and the end of life. | AircraftGroundService or AirportSuppliesService or PassengerService .ServiceOperationalStatus/Timesheet according to the rules for {{Schedules}} |
note | A free text note that provides further details concerning the unserviceability of one of the airport ground services. | AircraftGroundService or AirportSuppliesService or PassengerService .annotation with purpose=WARNING. The annotation is for the attention of a human users on the client side, which justify the use of purpose=WARNING Note: In AIXM 5.1.1 - coding guidelines for AIP data set - interoperability rules - WARNING is reserved for notifications for operator. |
Assumptions for baseline data
It is assumed that information about the aerodrome already exists in the form of AirportHeliport BASELINE TimeSlice(s) covering the complete period of validity of the event, for which the baseline availability is coded as specified in the Coding Guidelines for the (ICAO) AIP Data Set.
It is assumed that information about the airport ground services at the aerodrome already exists in the form of subclasses of AirportGroundService BASELINE(s) TimeSlice covering the complete period of validity of the event, which contain as a minimum:
- aixm:type (for AircraftGroundService, AirportSuppliesService.Oxygen, PassengerService) or aixm:category (for AirportSuppliesService.Fuel, AirportSuppliesService.Oil)
- aixm:availability with ServiceOperationalStatus=NORMAL
- aixm:airportHeliport referencing the airport/heliport where the service is provided.
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.
Identifier | Data encoding rule |
---|---|
ER-01 | The unserviceability of one of the airport ground services at an airport shall be encoded as:
|
ER-02 | One ServiceOperationalStatus element having operationalStatus=UNSERVICEABLE shall be included in the AircraftGroundService, AirportSuppliesService or PassengerService TEMPDELTA. |
ER-03 | If the end of the event is estimated, gml:endPosition shall have the attribute indeterminatePosition="unknown". |
ER-04 | If one of the airport ground services 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 ServiceOperationalStatus of the AircraftGroundService, AirportSuppliesService or PassengerService TEMPDELTA Timeslice. See the rules for Event Schedules. |
ER-05 | In accordance with the AIXM Temporality Concept, the ServiceOperationalStatus elements included in the TEMPDELTA completely replace all the BASELINE ServiceOperationalStatus information, during the TEMPDELTA time of applicability. Therefore, if the unserviceability only concerns certain times, then the other times, when the AircraftGroundService, AirportSuppliesService or PassengerService eventually remains subject to the availability conditions of the Baseline data, shall be explicitly included in the TEMPDELTA (associated with an ServiceOperationalStatus with status= ‘NORMAL’). The calculation of the necessary additional ServiceOperationalStatus elements to be included in the TEMPDELTA shall be automatically done by the applications implementing this specification. All ServiceOperationalStatus 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" view of the service unserviceability, enabling the operator to graphically check the availability 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. |
ER-06 | The Event BASELINE shall have event:textNOTAM with attributes xsi:nil="true" and nilReason="inapplicable". |
ER-07 | The system shall automatically identify the FIR where the AerodromeHeliport is located. This shall be coded as corresponding concernedAirspace property in the Event |
ER-08 | The AirportHeliport concerned by the closure shall also be coded as concernedAirportHeliport property in the Event. |
Examples
Following coding examples can be found on GitHub (links attached):