...
...
...
...
Coding
...
Definition
The temporary "complete" closure of aircraft stand(s).
...
Notes:
- this scenario includes the closure of one or more aircraft stands (could be all aircraft stands at the airport)
...
- ;
- more than one aircraft stand can be included only if the closure conditions (closure exceptions) applies equally to all. Otherwise, separate NOTAM shall be issued;
- this scenario
...
- includes only a "complete" closure of an aircraft stand, a "partial" closure except for flight and/or aircraft categories or temporary addition of a supplementary restriction to the aircraft stand availability, such as "closed for aircraft heavier than..." is included in STAND.LIM scenario.
- this scenario does not cover the temporary change of the operational hours of an aircraft stand;
- this scenario does not cover the situation when the aircraft stand is operating normally, but subject to a reason for caution.
Event data
The following diagram identifies the information items that are usually provided by a data originator for this kind of event.
...
Code Block | ||||
---|---|---|---|---|
| ||||
input = "airport designator" ["airport name"] "aircraft stand designator" {"aircraft stand designator"} \n
|
...
"status=CLOSED" ["closure reason"] \n "start time" "end time" [schedule] \n |
...
[note |
...
]. |
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).
Data item | Description | AIXM mapping |
---|---|---|
airport designator | The published designator of the airport where the aircraft stand is located, used in combination with other elements in order to identify the aircraft stand concerned. | AirportHeliport.designator |
airport name | The published name of the airport where the aircraft stand is located, used in order to identify the aircraft stand concerned. | AirportHeliport.name |
aircraft stand designator | The designator of the aircraft stand to be closed. | AircraftStand.designator |
status=CLOSED | The operational status of the aircraft stand. In this scenario, it is only possible to indicate a complete closure. | AircraftStand/ApronAreaAvailability.operationalStatus |
closure reason | The reason for the aircraft stand closure. | AircraftStand/ApronAreaAvailability. |
...
annotation with propertyName= |
...
'operationalStatus |
...
' and purpose= |
...
'REMARK |
...
'. Note that the property "warning" of the ApronAreaAvailability class is not used here because it represents a reason for caution when allowed to operate at the aircraft stand, not a reason for a closure. |
...
PPR details
...
Additional information concerning the prior permission requirement.
...
AircraftStand/ApronAreaAvailability/..Usage.annotation with propertyName="priorPermission" and purpose="REMARK"
...
aircraft
...
The description of one or more aircraft (such as "acft with wingspan less than") types that are exceptionally permitted at the aircraft stand during its closure.
...
AircraftStand/ApronAreaAvailability/..Usage/../AircraftCharacteristicsNote that only certain properties can be used in this scenario. See data validation rules for details.
...
flight
...
The description of one or more type of flight categories (such as "emergency") that are exceptionally permitted at the aircraft stand during its closure.
...
AircraftStand/ApronAreaAvailability/..Usage/../FlightCharacteristics
...
other combination
...
Another combination of aircraft/flight characteristics that are excepted from the closure.
...
AircraftStand/ApronAreaAvailability/..Usage/ConditionCombination.logicalOperatorwith its value set to "OR".
...
The value (minutes, hours, days) of the advanced permission request associated with the permitted operation.
...
AircraftStand/ApronAreaAvailability/..Usage.priorPermission with uom attribute
start time | The effective date & time when the aircraft stand closure starts. This might be further detailed in a "schedule". | AircraftStand/AircraftStandTimeSlice/TimePeriod.beginPosition, Event/EventTimeSlice.validTime/ |
...
beginPosition and Event/EventTimeSlice.featureLifetime/beginPosition | ||
end time | The end date & time when the aircraft stand closure ends. | AircraftStand/AircraftStandTimeSlice/TimePeriod.endPosition, Event/EventTimeSlice.validTime/endPosition and Event/EventTimeSlice.featureLifetime/endPosition also applying the rules for |
...
...
schedule | A schedule might be provided, in case the aircraft stand is effectively closed according to a regular timetable, within the overall closure period. | AircraftStand/ApronAreaAvailability/Timesheet/...according to the rules for |
...
...
note | A free text note that provides further details concerning the aircraft stand closure. | AircraftStand/ApronAreaAvailability.annotation |
...
with purpose='REMARK' |
Assumptions for baseline data
It is assumed that
...
the related ApronElement, Apron and AirportHeliport and BASELINE Timeslice covering the entire duration of the event exist
...
. In addition the information about the aircraft stand
...
(s) concerned by the event already exist in the form of a AircraftStand
...
BASELINE TimeSlice, which contains as a minimum
...
:
- designator, and
an
...
- the operationalStatus has the value "NORMAL" (meaning that the facility operates with nominal parameters) for all AircraftStand.ApronAreaAvailability that are part of the BASELINE data;
- operations that are explicitly permitted have been encoded as ApronAreaUsage with type=PERMIT or type=CONDITIONAL (in case a PPR is necessary);
- operations that are explicitly forbidden have been encoded as ApronAreaUsage with type=FORBID;
- if the airport is exclusively reserved for certain operations, then the ApronAreaAvailability that describes this condition contains only ApronAreaUsage elements with type=RESERV;
- in case of conflicts
- the usages of type FORBID take precedence over usages of type PERMIT or RESERVE;
- the usages of type PERMIT take precedence over the usages of type RESERVE;
Data encoding rules
association with the ApronElement, which is associated with an Apron, which is associated with an AirportHeliport;
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. The compliance with some of these encoding rules can be checked with automatic data validation rules. When this is the case, the number of the encoding rule is mentioned in the data validation rule.
Identifier | Data encoding rule |
---|---|
ER-01 | The temporary closure of an aircraft stand shall be encoded as:
|
...
|
...
|
ER-02 |
...
First, all the BASELINE availability.ApronAreaAvailability (with operationalStatus='NORMAL'), if present, shall be copied in the TEMPDELTA (see Usage limitation and closure scenarios) Then, an additional availability.ApronAreaAvailability element having operationalStatus='CLOSED' shall be |
...
- either type=PERMIT, if there is no prior permission requirement;
- or type=CONDITIONAL, if a prior permission requirement was specified. Note that this implies that a "closed" aircraft stand can still allow certain particular operations.
...
ER-03
...
If a unique flight or aircraft are specified as being excepted, they shall be encoded as one ConditionCombination with logicalOperator="NONE".
...
ER-04
...
Each pair of flight and aircraft conditions specified as being excepted shall be encoded as one ConditionCombination with logicalOperator="AND".
...
ER-05
...
If the "other combination" branch is used, then a root ConditionCombinations element shall be encoded having logicalOperator="OR" and each pair of flight/aircraft included as a sub-condition (with logicalOperator="AND", see ER-04).
...
coded in the AircraftStand TEMPDELTA. Editorial note: there is no mistyping - ApronAreaAvailability is the actual name of the object containing information about the operational status of an AircraftStand. | |
ER-03 | If the aircraft stand closure 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 ApronAreaAvailability (with operationalStatus='CLOSED') of the |
...
TEMPDELTA Timeslice. See the rules for Event Schedules. |
ER- |
...
In accordance with the AIXM Temporality Concept, the ApronAreaAvailability elements included in the TEMPDELTA completely replace all the BASELINE ApronAreaAvailability information, during the TEMPDELTA time of applicability. Therefore, if the closure only concerns certain times, then the other times, when the aircraft stand eventually remains subject to the availability conditions of the Baseline data, shall be explicitly included in the TEMPDELTA. The calculation of the necessary additional ApronAreaAvailability elements to be included in the TEMPDELTA shall be automatically done by the applications implementing this specification.
All ApronAreaAvailability 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 each taxiway element closure, 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.
Decoding
Text NOTAM production rules
This section provides rules for the automated production of the text NOTAM message items, based on the AIXM 5.1 data encoding of the Event. Therefore, AIXM specific terms are used, such as names of features and properties, types of TimeSlices, etc:
- the abbreviation AST.BL. indicates that the corresponding data item must be taken from the AircraftStand BASELINE;
- the abbreviation AHP.BL. indicates that the corresponding data item must be taken from the AirportHeliport BASELINE associated with the Taxiway that is associated with the TaxiwayElement concerned;
- the abbreviation AST.TD. indicates that the corresponding data item must be taken from the AircraftStand TEMPDELTA that was created for the Event.
In general, the ICAO DOC 8126 and the OPADD rules shall be followed. These have not been copied in this document in order to avoid duplication with those documents. Only instructions that are specific to the AIXM encoding of this event are stated here.
Item A
The item A shall contain the AHP.BL.designator if AHP.BL.locationIndicatorICAO='YES'. Otherwise, the nationality letter(s) as defined in ICAO Doc 7910 followed by “XX” or “XXX”.
Q code
The following mapping shall be used:
...
Availability.usage
...
Corresponding Q codes
...
none specified
...
QMPLC
...
there exist associated ApronAreaUsage.type PERMIT or CONDITIONAL
...
QMNLT
Scope
Insert the value ‘A’.
Lower limit / Upper limit
Use “000/999”
Geographical reference
Insert the coordinate of the ARP (AHP.BL.ARP.ElevatedPoint) of the airport, formatted as follows:
- the set of coordinates comprises 11 characters rounded up or down to the nearest minute; i.e. Latitude (N/S) in 5 characters; Longitude (E/W) in 6 characters;
- the radius value is “005”.
Items B, C and D
Items B and C shall be decoded following the common production rules.
If at least one AST.TD.availability.ApronAreaAvailability.timeInterval exists (i.e. the Event has an associated schedule), then all such Timesheet(s) shall be represented in item D according to the common NOTAM production rules for {{Item D, E - Schedules}}. Otherwise, item D shall be left empty.
Item E
The following pattern should be used for automatically generating the E field text from the AIXM data:
Code Block | ||||
---|---|---|---|---|
| ||||
template = ["(1)" "AHP.BL.type (2)" ("AHP.BL.name (3a)" | "AHP.BL.ARP (3b)")] \n "Acft stand" "AST.BL.name" ["(4)" ("and"|",")]{"AST.BL.name" ["(4)" ("and"|",")]}
\n "closed" [ "due to" "AST.TD.availability.annotation (5)"]\n
["(6)" "\n" "except" ["AST.TD.usage.PPR(7)"] ["AST.TD.usage.flight(8)"] ["AST.TD.usage.aircraft(9)"] {"(10)" "," ["AST.TD.usage.PPR(7)"] ["AST.TD.usage.flight(8)"] ["AST.TD.usage.aircraft(9)"]} ] \n
{"\n" "AST.TD.availability.annotation(11)" "."} ["."]. |
...
Reference
...
Rule
...
(1)
...
If AHP.BL.locationIndicatorICAO=YES, then ignore this branch.
...
(2)
...
Insert here the type of the airport decoded as follows
AHP.BL.type | Text to be inserted in Item E |
---|---|
AD or AH | "AD" |
HP | "Heliport" |
LS or OTHER | "Landing site" |
...
(3)
...
a. If AHP.BL.name is not NIL, then insert it here. Otherwise
b. insert here the text "located at" followed by the AHP.BL.ARP.ElevatedPoint decoded according to the text NOTAM production rules for aixm:Point.
...
(4)
...
If more than one AircraftStand has a TEMPDELTA associated with the Event, then insert the designator of each additional AircraftStand designator preceded by ",". The word "Acft stand" need not be repeated. Insert "and" before the last entry.
...
(5)
...
If there exists a AST.TD.availability.annotation having propertyName="operationalStatus" and purpose="REMARK", then translate it into free text according to the decoding rules for annotations.
...
(6)
...
If there exist one or more TD.availability.usage then decode them following this branch, in the following order of priorities:
- TD.availability.usage that have operation="ALL"
- TD.availability.usage that have type="PERMIT"
- ... other situations ...
- TD.availability.usage that have priorPermission which is not NIL shall be decoded last.
...
If TD.usage.priorPermission is not NIL, then insert here the decoding of the PPR information as detailed in the following diagram:
Code Block | ||||
---|---|---|---|---|
| ||||
template_PPR = "PPR " "AST.TD.usage.priorPermission(7.1)" ["AST.TD.usage.annotation(7.2)"]. |
Reference | Rule |
---|---|
(7.1) | Insert here the value of the priorPermission attribute followed by its unit of measurement decoded according to the {{text NOTAM production rules for duration}} |
(7.2) | Decode here the annotation with propertyName="priorPermission" and purpose="REMARK", according to the decoding rules for annotations. |
...
(8)
Decode here each FlightCharacteristics property that was specified, as detailed below. If more than one FlightCharacteristics property was used, insert blanks between consecutive properties.
...
FlightCharacteristics.type*
...
Text to be inserted in Item E
...
OAT
...
"Operational Air Traffic"
...
GAT
...
"General Air Traffic"
...
ALL
...
"Operational Air Traffic/General Air Traffic"
...
OTHER:MY_TEXT
...
"my text" (replace "_" with blanks)
*Note: type is unlikely to be used in a NOTAM, its decoding is provided for completeness sake.
...
FlightCharacteristics.rule
...
Text to be inserted in Item E
...
IFR
...
"IFR"
...
VFR
...
"VFR"
...
ALL*
...
"IFR/VFR"
...
OTHER:MY_TEXT
...
"my text" (replace "_" with blanks)
*Note: value is unlikely to be used in a NOTAM, its decoding is provided for completeness sake.
...
FlightCharacteristics.status
...
Text to be inserted
...
HEAD
...
"Head of State"
...
STATE
...
"State acft"
...
HUM
...
"HUM"
...
HOSP
...
"HOSP"
...
SAR
...
"SAR”
...
EMERGENCY
...
"EMERG"
...
ALL
...
"State acft/HUM/HOSP/SAR/EMERG"
...
OTHER:MEDEVAC
...
“MEDEVAC”
...
OTHER:FIRE_FIGHTING
...
“fire fighting”
...
OTHER:MY_TEXT
...
"my text" (replace "_" with blanks and convert to lowercase)
...
FlightCharacteristics.military
...
Text to be inserted in Item E
...
MIL
...
"MIL acft"
...
CIVIL
...
"civil acft"
...
ALL*
...
"civil/MIL acft"
...
OTHER:MY_TEXT*
...
"my text" (replace "_" with blanks)
*Note: value is unlikely to be used in a NOTAM, its decoding is provided for completeness sake.
...
FlightCharacteristics.origin
...
Text to be inserted
...
NTL
...
"domestic"
...
INTL
...
"intl"
...
HOME_BASED
...
"home based"
...
ALL*
...
"domestic/intl"
...
OTHER:MY_TEXT*
...
"my text" (replace "_" with blanks)
*Note: value is unlikely to be used in a NOTAM, its decoding is provided for completeness sake.
...
FlightCharacteristics.purpose
...
Text to be inserted
...
SCHEDULED
...
"scheduled"
...
NON_SCHEDULED
...
"not scheduled"
...
PRIVATE*
...
"private"
...
AIR_TRAINING
...
"training"
...
AIR_WORK*
...
"aerial work"
...
PARTICIPANT
...
"participating acft"
...
ALL*
...
"scheduled/not scheduled/private/training/aerial work/participating acft"
...
OTHER:MY_TEXT*
...
"my text" (replace "_" with blanks)
*Note: value is unlikely to be used in a NOTAM, its decoding is provided for completeness sake.
...
(9)
Decode here each AircraftCharacteristics property that was specified, as detailed below. If more than one AircraftCharacteristics property was used, insert blanks between consecutive properties.
...
AircraftCharacteristics.type
...
Text to be inserted in Item E
...
LANDPLANE
...
"landplanes"
...
SEAPLANE*
...
"seaplanes"
...
AMPHIBIAN
...
"amphibians"
...
HELICOPTER
...
"hel"
...
GYROCOPTER
...
"gyrocopters"
...
TILT_WING
...
"tilt wing acft"
...
STOL
...
"short take-off and landing acft"
...
GLIDER*
...
"gliders"
...
HANGGLIDER*
...
"hang-gliders"
...
PARAGLIDER*
...
"paragliders"
...
ULTRA_LIGHT*
...
"ultra lights"
...
BALLOON*
...
"balloons"
...
UAV*
...
"unmanned acft”
...
ALL*
...
"all acft types"
...
OTHER:MY_TEXT
...
"my text" (replace "_" with blanks)
*Note: value is unlikely to be used in a NOTAM, its decoding is provided for completeness sake.
...
AircraftCharacteristics.engine
...
Text to be inserted in Item E
...
JET
...
"jet acft"
...
PISTON
...
"piston acft"
...
TURBOPROP
...
"turboprop acft"
...
ELECTRIC**
...
“electric engine acft”
...
ALL
...
"all engine types"
...
OTHER:MY_TEXT
...
"my text" (replace "_" with blanks)
**Note: new in AIXM 5.1.1.
AircraftCharacteristics.wingSpan - insert the value followed by the value of the uom attribute. Prefix with the value of AircraftCharacteristics.wingSpanInterpretation, decoded as indicated in the following table:
...
AircraftCharacteristics.wingSpanInterpretation
...
Text to be inserted in Item E
...
ABOVE
...
"acft with wingspan more than"
...
AT_OR_ABOVE
...
"acft with wingspan equal to or more than"
...
AT_OR_BELOW
...
“acft with wingspan equal to or less than"
...
BELOW
...
"acft with wingspan less than"
...
OTHER:MY_TEXT*
...
"my text" (replace "_" with blanks)
*Note: value is unlikely to be used in a NOTAM, its decoding is provided for completeness sake.
AircraftCharacteristics.weight - insert the value followed by the value of the uom attribute. Prefix with the value of AircraftCharacteristics.weightInterpretation, decoded as indicated in the following table:
...
AircraftCharacteristics.weightInterpretation
...
Text to be inserted in Item E
...
ABOVE
...
"acft mass heavier than"
...
AT_OR_ABOVE
...
"acft mass equal to or heavier than"
...
AT_OR_BELOW
...
"acft mass equal to or lighter than"
...
BELOW
...
"acft mass lighter than"
...
OTHER:MY_TEXT*
...
"my text" (replace "_" with blanks)
*Note: value is unlikely to be used in a NOTAM, its decoding is provided for completeness sake
...
(11)
...
Annotations of TD.ApronAreaAvailability shall be translated into free text according to the decoding rules for annotations.
Note: The objective is to full automatic generation, without human intervention. However, the implementers of the specification might consider reducing the cost of a fully automated generation by allowing the operator to fine-tune the text in order to improve its readability (with the inherent risk for human error, when re-typing is allowed).
Items F & G
Leave empty.
Event Update
The eventual update of this type of event shall be encoded following the general rules for {{Event updates or cancellation}}, which provide instructions for all NOTAM fields, except for item E and the condition part of the Q code, in the case of a NOTAMC
If a NOTAMC is produced, then the 4th and 5th letters (the "condition") of the Q code shall be "AK", except for the situation of a “new NOTAM to follow, in which case “XX”shall be used.
Code Block | ||||
---|---|---|---|---|
| ||||
template_cancel = "AHP.BLtype (1)" ["(2)" ("AHP.BL.name (3a)" | "AHP.BL.ARP (3b)")] \n
"Acft stand" "AST.BL.name" ["(4)" ("and"|",")]{"AST.BL.name" ["(4)" ("and"|",")]} ["resumed normal operations."]\n
["New NOTAM to follow.(12)"]. |
The following pattern should be used for automatically generating the E field text from the AIXM data
...
Reference
...
Rule
...
(12)
If the NOTAM will be followed by a new NOTAM concerning the same situation, then the operator shall have the possibility to specify "New NOTAM to follow" and this text shall be appended at the end of item E of the NOTAM C.
...
04 | The system shall automatically identify the 'FIR' where the AirportHeliport is located. This shall be coded as corresponding concernedAirspace property in the Event |
ER-05 | 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):
- To be provided