Page Comparison

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.

Anchor
_i64xdp8q37nv _i64xdp8q37nv

AIXM model for schedules

Anchor
_mkhpap7aryxi _mkhpap7aryxi

Overview

The following AIXM UML model diagram indicates the scope of these coding guidelines:
Image Modified
The main class in this model is PropertiesWithSchedule, which is used through inheritance in all the situations that need a schedule to be associated with a specific group of properties, such as NavaidOperationalStatus, AirportHeliportAvailability, etc. A schedule is then modelled with one or more Timesheet occurrences, which enable the encoding of elements such as start/end time, start/end date.
It is possible that one or more Timesheet composing a schedule depend on public holidays or other special dates. The model allows to indicate explicitly the authority for such special dates, through the appliesSpecialDatesOf association with the OrganisationAuthority class. Note that this is typically a State, but could also be a local authority, such as a military authority which has distinct non-working days from the public holidays of the State.
The Timesheet class has a number of attributes that can be grouped as follows:

• timeReference: indicates the time reference system or reference system offset, in relation with the Coordinated Universal Time ('UTC'). Its list of values does not support directly "local time". Instead, values such as 'UTC+1', 'UTC-2', etc. have to be used;
• day/dayTill: used to indicate the applicability day(s) of each timesheet. If a single day is concerned, then only day is used. If a period of several consecutive days is concerned, then both day and dayTill are used;
• startTime/endTime: indicate the start/end of the timesheet period. The meaning of the endTime depends on the presence of the dayTill: if present, then the end time occurs on the day indicated by dayTill, otherwise it occurs on the day indicated by the day attribute.
  • startEvent is an alternative to startTime, which allows to indicate the start time of the timesheet by using events such as sunrise, sunset, etc. This nay be complemented by startTimeRelativeEvent, which can be used to encode values such as "15 minutes before sunrise". Even further, it is possible to provide both a startTime and a startEvent, in which case the startEventInterpretation is necessary in order to indicate which of the two takes precedence (earliest or latest);
  • A similar concept applies to endEvent, endTimeRelativeEvent and endEventInterpretation, in relation with endTime
  • daylightSavingAdjust indicates that the startTime and endTime values of a timesheet have to be decreased by one hour when Daylight Saving is in force ("summer time");
• startDate/endDate are used to indicate an eventual applicability period of the timesheet during the year, such as "from 15th of October until 15th of March";
• the excluded attribute allows to indicate that the period encoded in the timesheet has to be subtracted from the overall period covered by the union of all timesheets associated with the same object.

Annotations may be associated with both individual Timesheet and the classes that are derived from PropertiesWithSchedule, the later being used for annotations (remarks) that concern the whole timetable.
The data type or the list of allowable values associated with each Timesheet attribute are listed in the following diagram.
Image Modified

Anchor
_w2rzu8cnvrvt _w2rzu8cnvrvt

Model principles and limitations

Anchor
_7romtv7t8z6q _7romtv7t8z6q

Order of priorities

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.

Anchor
_undgg6uv19sm _undgg6uv19sm

Overlapping times from different timesheets

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.

Anchor
_ukwfszu2wo34 _ukwfszu2wo34

End of day format

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.

Anchor
_edrfuxb73rft _edrfuxb73rft

Weekday range

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.

Anchor
_p26sfkiepwqw _p26sfkiepwqw

From date & time to date & time

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.

Anchor
_smyfaf9gt971 _smyfaf9gt971

Excluded timesheets

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.

Anchor
_feub6wyuofh _feub6wyuofh

To be clarified

If a timesheet is provided with a timezone and SDLST / EDSLT, the timesheet timezone shall be ignored and the definition of the SDLST / EDSLT shall be used.

Anchor
_tncloo15a76e _tncloo15a76e

Same hours as..

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.

Anchor
_xcrkd7dmc65u _xcrkd7dmc65u

Twilight

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.

Anchor
_lgj2cm9qv4jv _lgj2cm9qv4jv

General coding rules

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.

Anchor
_pksg8njf5ot4 _pksg8njf5ot4

Common coding patterns

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.

Anchor
_9wmmnft0makm _9wmmnft0makm

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

Anchor
_19cyfec1tpe4 _19cyfec1tpe4

"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:
Image Modified
where Start_Event and End_Event are detailed in the following diagrams:
Image Modified
Image Modified
The graphical elements included in this diagram have the meaning explained in the following table:

Anchor
_i8kfj6gz6hkh _i8kfj6gz6hkh

"Weekday" 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:
Image Modified
where Start_Event and End_Event are detailed in the following diagrams:
Image Modified
Image Modified

The graphical elements included in this diagram have the meaning explained in the following table:

Anchor
_clqqfd9d212f _clqqfd9d212f

"Date range" schedules

For example:

• "from 01/03 till 30/10, daily from 08:00-16:00"

Image Modified

Anchor
_jdrjy3vmgaf0 _jdrjy3vmgaf0

Examples

Use the following document for examples: {+}https://drive.google.com/folderview?id=0BxlGN-YBj-q0UWdNaXM4V1dRMjA&usp=sharing+

Anchor
_szvp65lrgj8x _szvp65lrgj8x

References

\[1\] Digital NOTAM Event Specification, version 1.0, 08 June 2011, ([<span style="color: #1155cc">{+}<a href="http://www.aixm.aero/page/digital-notam+" class="external-link" rel="nofollow">http://www.aixm.aero/page/digital-notam+</a></span>|http://www.aixm.aero/page/digital-notam])
\[2\]