The following AIXM UML model diagram shows the classes involved in modelling the "properties with schedule" concept:

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. As a general rule, 'UTC' shall be used for encoding of aeronautical information.
  • 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.


Model principles and limitations

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.

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.

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.

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.

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.

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.

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.

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.