...
These coding guidelines concern the schedules/timetables topic. These are repetitive/cyclic time periods, which are associated in AIXM with the values of one or more properties of an aeronautical feature. For example, the working hours of a service, the activation times of an airspace, etc.
A schedule/timetable is a description of a series of discrete time periods, which occur cyclically within the overall validity time of a feature TimeSlice. Some examples of schedules are:
- "daily from 09:00 to 17:00"
- "every Monday and Friday from 13:00 to sunset"
- "every week from MON 07:00 till FRI 17:00, except HOL"
- etc.
AIXM supports the encoding of schedules that contain both:
- repetitive time periods, such as "daily...", "every MON...", "SAT 09:00 - SUN 19:00", etc.
- occasional occurrences, such as "on 1, 2, 15 and 25 of October", "on 1/10 09:00-15:00 and on 3/10 10:00-12:00", etc.
These coding guidelines are intended to be applied for both static data sets and dynamic data updates. However, only a subset of schedules is allowed to be used for temporary events published by NOTAM, as detailed in the OPADD document and in the Digital NOTAM Specification
...
Model principles and limitations
...
There is no explicit "priority indicator" attribute for a Timesheet. However, there exists a natural order of priorities that shall be applied when Timesheet are interpreted. This concerns:
- the day attribute, where the values shall be interpreted in the following order of priorities (values that are first in the list overrule values that are later in the list): 'HOL', 'BEF_HOL', 'AFT_HOL', 'WORK_DAY', 'BEF_WORK_DAY', 'AFT_WORK_DAY', 'BUSY_FRI', 'MON', 'TUE', 'WED', 'THU', 'FRI', 'SAT', 'SUN', 'ANY'
- the excluded attribute, where Timesheet that are have excluded="YES" take precedence over other Timesheet.
...
If two or more non-excluded timesheets refer to the same date, day and/or time period, then the resulting time period shall be derived by applying the order of priority rules.
...
According to ICAO Annex 15, Appendix 6, NOTAM Format, "the end of a day shall be indicated by '2359'". In static data (AIP) the end of the day is usually indicated by "2400". ICAO Annex 10 states that "3.4.1 Universal Co-ordinated Time (UTC) shall be used by all stations in the aeronautical telecommunication service. Midnight shall be designated as 2400 for the end of the day and 0000 for the beginning of the day."
In addition, feedback from developers having used the AIXM Temporality Concept show that using "23:59" as end of day in digital data is problematic because it requires a special interpretation for comparison operators: 23:59:01 is numerically higher than 23:59 and therefore is numerically after the end time. However, in the NOTAM practice, 23:59:01 is still considered inside a time interval that ends at 23:59.
To avoid such problems, the end of the day in digital data shall be indicated as 24:00. However, in order to remain compliant with the ICAO Annex 15 requirements for NOTAM format (item C in particular), this shall be translated into "2359", when the NOTAM is generated automatically.
...
The concept of "weekday ranges" (such as "MON-WED") is not directly supported in AIXM because sometimes there are confusions between MON-FRI and "working days".This does not exclude implementing an HMI that allows the input of weekday ranges, for efficiency reasons. They will have to be converted into individual week days in AIXM.
...
Schedules in the form "from date & time" - "to date & time" (such as "MAR 02 09:00 - 09 16:00") are not supported. The startTime and endTime properties are, by definition, related only to day and/or dayTill. It is also highly questionable if such schedules are really needed, as they most likely correspond to feature lifetimes, which need to be encoded as timeslice validity times, not as schedules.
...
It is not possible to indicate that a Timesheet with excluded="YES" concerns only another (not excluded) Timesheet or just a subset of other Timesheet. The exclusion is general, it has to be subtracted from all not excluded timesheets.
...
The encoding of operational dependencies, such as a service having the same working hours as the airport administration, etc. are not supported. When considered necessary to be modelled, such operational dependencies are indicated with explicit associations between the features concerned.
...
There is no code for "twilight" in the current model, only sunrise/sunset can be used. The explicit SR/SS +/- 30 minutes (or another value) needs to be encoded.
...
This section provides the rules that are common to all schedules. For categories of schedules that are frequently encountered in aeronautical information, more specific coding rules are provided later in this document.
...
Identifier
...
Data encoding rule
...
Justification
...
Data verification rules (UID)
...
TSH-01
...
The timeReference attribute is mandatory
...
To avoid any doubts with regard to the applicability of the schedule, such as local time versus UTC
...
RULE-1A3399
...
TSH-02
...
The dailightSavingAdjust is mandatory for Timesheet associated with features located in States/Territories that apply daylight saving concept.
...
To avoid doubts with regard to the eventual adjustment of the time values in summer.
...
To be developed
...
TSH-03
...
The dailightSavingAdjust shall be left empty and shall have nilReason="inapplicable" for Timesheet associated with features located in States/Territories that do not apply daylight saving concept.
...
To confirm that the times are not affected by the daylight saving concept, because it is not applicable in that area.
...
To be developed
...
It is not allowed to combine ädjustable" with SDLST/EDLST. tpo be added as rule.
...
Example:
- UTC+1, adjustable,
- from SDLST to EDLST, 09-18
- from EDLST to SDLST, 09-19
...
TSH-04
...
The day attribute is mandatory
...
To avoid doubts about the applicability of the schedule
...
RULE-1A3397
...
TSH-05
...
If day has one of the values ('HOL', 'BEF_HOL', 'AFT_HOL'), then dayTill shall be either empty or have one of the values ('HOL', 'BEF_HOL', 'AFT_HOL')
...
Other combinations do not make sense or could lead to misinterpretations
...
TSH-06
...
If day has one of the values ('WORK_DAY', 'BEF_WORK_DAY', 'AFT_WORK_DAY'), then dayTill shall be either empty or have one of the values ('WORK_DAY', 'BEF_WORK_DAY', 'AFT_WORK_DAY')
...
Other combinations do not make sense or could lead to misinterpretations
...
TSH-07
...
If day has one of the values ('MON', 'TUE', 'WED', 'THU', 'FRI', 'BUSY_FRI', 'SAT', 'SUN'), then dayTill shall be either empty or have one of the values ('MON', 'TUE', 'WED', 'THU', 'FRI', 'BUSY_FRI', 'SAT', 'SUN')
...
Other combinations do not make sense or could lead to misinterpretations
...
TSH-08
...
If the day attribute has one of the values 'HOL', 'BEF_HOL', 'AFT_HOL', 'WORK_DAY', 'BEF_WORK_DAY', 'AFT_WORK_DAY', 'BUSY_FRI', then the PropertiesWithSchedule shall be associated with an OrganisationAuthority and that one shall have an association with SpecialDates
...
To be sure which are the legal holidays to be considered for the timesheet
...
TSH-09
...
If day='ANY', then dayTil shall be left empty
...
This will make it clear that endTime or endEvent occurs on the same day, Any other interpretation of the end time could lead to confusions
...
TSH-10
...
If endTime is not specified, then endEvent must be specified
...
Data completeness, a timesheet without end time or end event is unclear (open ended)
...
TSH-11
...
If startTime is not specified, then endEvent must be specified
...
Data completeness, a timesheet without start time or start event is unclear
...
TSH-12
...
If both startTime and startEvent have an assigned value, then startEventInterpretation is mandatory
...
Otherwise it is unclear which one takes precedence
...
To be developed
...
TSH-13
...
If startEvent is not specified, then startTimeRelativeEvent should also be empty
...
TSH-14
...
If both endTime and endEvent have an assigned value, then endEventInterpretation is mandatory
...
Otherwise it is unclear which one takes precedence
...
To be developed
...
TSH-15
...
If endEvent is not specified, then endTimeRelativeEvent should also be empty
...
TSH-16
...
There must exist at least one Timesheet with excluded set to "NO" or unspecified (which is assumed to mean "not excluded")
...
It does not make sense if all Timesheets are "excluded"
...
TSH-
...
If dayTill is not specified, then startTime shall be before endTime.
...
It does not make sense to have a Timeslice such as FRI from 17:00 to 09:00
...
This section describes the most frequently encountered types of schedules used in the aeronautical information domain. Application developers might consider offering HMI templates for such situations, in order to facilitate a correct and harmonised encoding of such common schedules.
...
The following codes are sometimes used in aeronautical information publications and messages in order to indicate the opening hours of a facility or the operating times of a service: H24, HJ, HN, HX, HO, NOTAM
H24: shall be encoded explicitly if the service or facility is explicitly provided H24. How it is exactly encoded might remain a local decision. Recommendation: a single Timesheet with 00:00-24:00 local time (UTC +/-xx hours)
HJ: Meaning: sunrise to sunset. Recommendation: a single Timesheet with only startEvent = 'SR', endEvent = 'SS' and excluded = 'NO'. Any exceptions should be encoded with excluded = 'YES'.
HN: Meaning: sunset to sunrise. Recommendation: a single timesheet with only startEvent = SS, endEvent = SR and excluded = NO. Any exceptions should be encoded with excluded = YES.
HX: Meaning: no specific working hours. Recommendation: A note, propertyName = timeInterval, purpose = WARNING and note = HX (no specific working hours). If limited to a specific time period add timesheets with excluded = NO.
HO: Meaning: service available to meet operational requests. Recommendation: A note, propertyName = timeInterval, purpose = WARNING and note = HO (service available to meet operational requests). If limited to a specific time period add timesheets with excluded = NO.
NOTAM: Meaning: activity periods to be published by NOTAM. Recommendation: A note, propertyName = timeInterval, purpose = WARNING and note = activity periods to be published by NOTAM. If limited to a specific time period add timesheets with excluded = NO.
...
This applies to schedules that occur every day during the validity period of the data, without distinction between weekdays. However, it is possible to exclude specific dates from the applicable times of the schedule. For example:
- "daily from 09:00 to 17:00"
- "daily from SR+30 min until SS or 18:00, whichever is earliest"
- "daily from 07:00 to 23:00 except for 25 Dec and 1st Jan"
...
Item
...
Coding
...
Comments
...
[TS] and [/TS]
...
All the elements that appear between [TS] and [/TS] are encoded as a single timesheet
...
start date
...
Timesheet.startDate
...
end date
...
Timesheet.endDate
...
start time
...
Encoded as Timesheet.startTime
...
start event
...
Encoded as Timesheet.startEvent
...
rel. start
...
Encoded as Timesheet.startTimeRelativeEvent
...
Positive values indicate that the actual start time is after the event.
...
switch
...
Encoded as startTimeRelativeEvent
...
Indicates which one takes precedence between the start/end time and the start/end event (including the eventual time relative to the event)
...
end time
...
Encoded as Timesheet.endTime
...
end event
...
Encoded as Timesheet.endEvent
...
rel. end
...
Encoded as Timesheet.sendTimeRelativeEvent
...
Positive values indicate that the actual end time is after the event.
...
note
...
Encoded as Timesheet.annotation
...
Examples of such notes:
"Departures till 2000 LT. However, latest ready time (with explanation of what that implies) is then often 15 minutes earlier or the departure"
...
excluded date
...
Encoded as a separate Timesheet with excluded="YES", startDate equal to endDate equal to the "excluded date" value, day='ANY', startTime='00:00' endTime='24:00', timeReference='UTC+/-X' (local time as UTC zone).
...
schedule note
...
Encoded as Note associated with the class that owns the schedule, with propertyName='timeInterval' and purpose='REMARK'.
...
This applies to schedules that occur with a weekly pattern, during the validity period of the data. It is possible to specify both individual weekdays (MON, TUE, etc.) and weekday ranges (from FRI 17:00 to MON 07:00). It is possible to exclude specific dates or special days (such as holidays) from the applicable times of the schedule. For example:
- "MON, TUE, WED, THU, FRI from 13:00 to sunset; SAT, SUN. from 13:00 to 15:00"
- "SUN, 2300 (2200) to MON, 0500 (0400)"
- "MON to FRI, 09:00 to 17:00, excluding HOL"
...
- "daily from 09:00 to 17:00"
- "every Monday and Friday from 13:00 to sunset"
- "every week from MON 07:00 till FRI 17:00, except HOL"
- etc.
AIXM supports the encoding of schedules that contain both:
- repetitive time periods, such as "daily...", "every MON...", "SAT 09:00 - SUN 19:00", etc.
- occasional occurrences, such as "on 1, 2, 15 and 25 of October", "on 1/10 09:00-15:00 and on 3/10 10:00-12:00", etc.
This section describes the most frequently encountered types of schedules used in the aeronautical information domain. Application developers might consider offering HMI templates for such situations, in order to facilitate a correct and harmonised encoding of such common schedules.
Coded value schedules
The following codes are sometimes used in aeronautical information publications and messages in order to indicate the opening hours of a facility or the operating times of a service: H24, HJ, HN, HX, HO, NOTAM. The following table contains the coding recommendations for these coded values:
Coded value (meaning) | AIXM coding | Remarks |
|---|---|---|
H24 (continuous service, 24/7) | A single Timesheet:
| According to the AIXM rules for PropertiesWithSchedule, a property that has a constant value (such as an AirspaceLayerClass that does not change according to a schedule) does not need a schedule to be coded. However, some data providers might considers necessary to give an explicit indication that the service or facility is explicitly provided H24, by coding a "H24 schedule" |
HJ (sunrise to sunset) | A single Timesheet with:
| It is assumed that HJ means 'sunrise to sunset'. If HJ actually means 'sunrise minus xx minutes' to 'sunset plus xx minutes', then the additional minutes should be coded as startTimeRelativeEvent and endTimeRelativeEvent respectively. For States that apply the "SERA Regulation" (European Union Commission Implementing Regulation (EU) No 923/2012), ‘night’ might actually mean "the hours between the end of evening civil twilight and the beginning of morning civil twilight. Civil twilight ends in the evening when the centre of the sun’s disc is 6 degrees below the horizon and begins in the morning when the centre of the sun’s disc is 6 degrees below the horizon." In this case, different values should be use for start/end event:
|
HN (sunset to sunrise) | A single Timesheet with:
| It is assumed that HN means 'sunset to sunrise'. If HN actually means 'sunset plus xx minutes' to 'sunrise minus xx minutes', then the additional minutes should be coded as startTimeRelativeEvent and endTimeRelativeEvent respectively. For States that apply the "SERA Regulation\'",different values should be used for start/end event:
|
HX (no specific working hours) | No Timesheet. Use an associated Note with propertyName = 'timeInterval', purpose = 'DESCRIPTION' and note='HX (no specific working hours)' | |
HO (service available to meet operational requests) | No Timesheet. Use an associated Note with propertyName = 'timeInterval', purpose = 'DESCRIPTION' and note='HO (service available to meet operational requests)' | |
NOTAM (activity periods to be published by NOTAM) | No Timesheet. Use an associated Note with propertyName = 'timeInterval', purpose = 'DESCRIPTION' and note='activity periods to be published by NOTAM' |
"Daily" schedules
This applies to schedules that occur every day during the validity period of the data, without distinction between weekdays. However, it is possible to exclude specific dates from the applicable times of the schedule. For example:
- "daily from 09:00 to 17:00"
- "daily from SR+30 min until SS or 18:00, whichever is earliest"
- "daily from 07:00 to 23:00 except for 25 Dec and 1st Jan"
The data elements that are specified for such schedules are indicated in the diagram below:
| Code Block | ||||
|---|---|---|---|---|
| ||||
Template_Daily = "[TSH]" ["start date" "end date"] ("start time" | "Start_Event") ("end time" | "End_Event") {note} "[/TSH]" { "[TSH]" ["start date" "end date"] ("start time" | "Start_Event") ("end time" | "End_Event") {note} "[/TSH]"} \n
{"[TSH]" "excluded date" {note} "[/TSH]"} {"schedule note"}.
Template_Start_Event = "start event" ["rel. start"] ["start time" "switch"].
Template_End_Event = "end event" ["rel. end"] ["end time" "switch"].
|
The graphical elements included in this diagram have the meaning explained in the following table:
Item | Coding | Comments |
|---|---|---|
[TS] and [/TS] | All the elements that appear between [TS] and [/TS] are encoded as a single timesheet | |
start date | Timesheet.startDate | |
end date | Timesheet.endDate | |
start time | Encoded as Timesheet.startTime | |
start event | Encoded as Timesheet.startEvent | |
rel. start | Encoded as Timesheet.startTimeRelativeEvent | Positive values indicate that the actual start time is after the event. |
switch | Encoded as startTimeRelativeEvent | Indicates which one takes precedence between the start/end time and the start/end event (including the eventual time relative to the event) |
end time | Encoded as Timesheet.endTime | |
end event | Encoded as Timesheet.endEvent | |
rel. end | Encoded as Timesheet.sendTimeRelativeEvent | Positive values indicate that the actual end time is after the event. |
note | Encoded as Timesheet.annotation | Examples of such notes: |
excluded date | Each excluded date is coded as a separate Timesheet with excluded='YES', startDate equal the "excluded date", endDate equal to "excluded date +1 day", day='ANY', dayTill='ANY', startTime='00:00', endTime='00:00', timeReference='UTC+/-X' (local time as UTC zone). | |
schedule note | Encoded as Note associated with the class that owns the schedule, with propertyName='timeInterval' and purpose='REMARK'. |
"Days of the week" schedules
This applies to schedules that occur with a weekly pattern, during the validity period of the data. It is possible to specify both individual weekdays (MON, TUE, etc.) and weekday ranges (from FRI 17:00 to MON 07:00). It is possible to exclude specific dates or special days (such as holidays) from the applicable times of the schedule. For example:
- "MON, TUE, WED, THU, FRI from 13:00 to sunset; SAT, SUN. from 13:00 to 15:00"
- "SUN, 2300 (2200) to MON, 0500 (0400)"
- "MON to FRI, 09:00 to 17:00, excluding HOL"
The data elements that are specified for such schedules are indicated in the following diagram: 
where Start_Event and End_Event are detailed in the following diagrams:
| Code Block | ||||
|---|---|---|---|---|
| ||||
Template_Weekdays = "[TSH]" ["start date" "end date"] ("on weekday" {"on weekday"} ("start time" | "Start_Event") ("end time" | "End_Event") | "from weekday" ("start time" | "Start_Event") "to weekday" ("end time" | "End_Event")) {note} "[/TSH]" {"[TSH]" ["start date" "end date"] ("on weekday" {"on weekday"} ("start time" | "Start_Event") ("end time" | "End_Event") | "from weekday" ("start time" | "Start_Event") "to weekday" ("end time" | "End_Event")) {note} "[/TSH]"} \n
{"[TSH]" ("excluded date" | ["start date" "end date"] "excluded day") {note} "[/TSH]"} {"schedule note"}.
Template_Start_Event = "start event" ["rel. start"] ["start time" "switch"].
Template_End_Event = "end event" ["rel. end"] ["end time" "switch"]. |
The graphical elements included in this diagram have the meaning explained in the following table:
Item | Coding | Comments |
|---|---|---|
[TS] and [/TS] | All the elements that appear between [TS] and [/TS] are encoded as a single timesheet | |
start date | Timesheet.startDate | |
end date | Timesheet.endDate | |
on weekday | Encoded as Timesheet.day | Any weekday values is allowed, including HOL |
from weekday | Encoded as Timesheet.day | Any weekday values is allowed, including HOL |
to weekday | Encoded as Timesheet. |
...
dayTil | Any weekday values is allowed, including HOL | |
start time | Encoded as Timesheet.startTime | |
start event | Encoded as Timesheet.startEvent | |
rel. start | Encoded as Timesheet.startTimeRelativeEvent | Positive values indicate that the actual start time is after the event. |
switch | Encoded as startTimeRelativeEvent | Indicates which one takes precedence between the start/end time and the start/end event (including the eventual time relative to the event) |
end time | Encoded as Timesheet.endTime | |
end event | Encoded as Timesheet.endEvent | |
rel. end | Encoded as Timesheet. |
...
endTimeRelativeEvent | Positive values indicate that the actual end time is after the event. | |
note | Encoded as Timesheet.annotation | Examples of such notes: |
excluded date |
...
Each excluded date is coded as a separate Timesheet with excluded= |
...
'YES |
...
', startDate |
...
equal the "excluded date", endDate equal to |
...
"excluded date +1 day" |
...
, day='ANY', dayTil='ANY', startTime='00:00', endTime=' |
...
00:00', timeReference='UTC+/-X' (local time as UTC zone). | |
excluded day | Encoded as a separate Timesheet with excluded= |
...
'YES', day equal to the "excluded day" value, startTime='00:00', dayTil equal to the "next day after the excluded day" value, |
...
endTime='00:00 |
...
' |
...
, timeReference='UTC+/- |
...
XX' (local time expressed as an as UTC zone). | It does not make sense to use the normal days of the week in this case, only 'HOL', 'BEF_HOL', 'AFT_HOL', 'WORK_DAY', 'BEF_WORK_DAY', 'AFT_WORK_DAY', 'BUSY_FRI' make sense here |
schedule note | Encoded as Note associated with the class that owns the schedule, with propertyName='timeInterval' and purpose='REMARK'. |
...
Use the following document for examples: AIXM Coding - Schedules - Examples.xlsx
...