Schedule (Overview)

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/dayTil: 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 dayTil are used.
  
  • If both day and dayTil have the same value, then dayTil is interpreted as meaning "the next of same kind". For example, if day='ANY' and dayTil='ANY', then dayTil designates "the next day".
• startTime/endTime: indicate the start/end of the timesheet period. The meaning of the endTime depends on the presence of the dayTil: if present, then the end time occurs on the day indicated by dayTil, 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 may 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.

Model limitations

Weekday range

The concept of "weekday ranges" (such as "MON-WED") is not supported in the AIXM 5.1(.1) version. The following coded values can be used in such cases for day:

• OTHER:MON_FRI
• OTHER:SUN_THU
• OTHER:SAT_WED
• OTHER:SAT_THU

Weekly non-working days

In the AIXM 5.1(.1) version it is not possible to indicate which are the weekly holidays. 

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 dayTil. 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. The following coded values can be used in this case as startEvent or endEvent:

• OTHER:START_MORNING_CIVIL_TWILIGHT
• OTHER:END_EVENING_CIVIL_TWILIGHT

The data type or the list of allowable values associated with each Timesheet attribute are listed in the following diagram.