Page Comparison

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

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

.