Introduction
A schedule is a description of a series of discrete time periods, which occur within the overall validity time of an Event. Some examples of schedules are:
- daily from 09:00 to 17:00;
- every Monday from 13:00 to sunset;
- every week from Friday 17:00 till Monday 07:00;
- etc.
AIXM supports the encoding of schedules that contain both repetitive time periods and occasional occurrences. The coding guidelines concerning the schedules/timetables topic and how it is addressed in AIXM can be found in: AIXM Coding Overview - Common Coding Rules - Schedule [TSH].
With respect to Digital NOTAM, only a subset of schedules is allowed to be used for temporary events published by NOTAM, as detailed in the OPADD document and in this current Digital NOTAM Specification. The limitations are described further down in this section.
Digital NOTAM Model overview
In orange color is indicated the part of the AIXM UML model diagram which is used by Digital NOTAM:
The data type or the list of allowable values associated with each Timesheet attribute in a Digital NOTAM encoding are marked in orange in the following diagram:
Digital NOTAM Model principles and limitations
Digital NOTAM encoding is in line the AIXM 5.1(.1) Model principles and limitations described in AIXM Coding Overview - Common Coding Rules - Schedule [TSH]. Additional limitations are described in this document.
Schedule data
Supported schedules
There are three types of schedules supported for Digital NOTAM Events:
- daily schedules, e.g. "daily from 09:00 to 17:00";
- date based schedules, e.g. "1/10 09:00-15:00 and on 3/10 10:00-12:00"
- weekday based schedules, e.g. "every Monday from 13:00 to sunset".
The information items that may occur in the definition of schedules are identified in the diagrams below. Each of these schedule types is detailed in one diagram.
...
The table below provides more details about each information item shown in the diagrams. It also provides the mapping of each information item within the AIXM 5.1 structure. The name of the variable (first column) is recommended for use as label of the data field in human-machine interfaces (HMI).
| Data Item | Description | AIXM mapping |
|---|---|---|
| daily | An indication that the time schedule defined further applies every day. | Timesheet.day with the value "ANY" |
| start time | The time of the day (hour and minute) when the period included in the schedule starts. | Timesheet.startTime |
| start event | An event (like sunset or sunrise), the occurrence of which indicates when the period included in the schedule starts. | Timesheet.startEvent with this list of values CodeTimeEventType |
| rel. start | A number of minutes indicating the start of the period included in the schedule, relative to the event. | Timesheet.startTimeRelativeEvent and Timesheet.startEventInterpretation |
| end time | The time of the day (hour and minute) when the period included in the schedule ends. | Timesheet.endTime |
| end event | An event (like sunset or sunrise), the occurrence of which indicates when the period included in the schedule ends. | Timesheet.endEvent with this list of values CodeTimeEventType |
| rel. end | A number of minutes indicating the end of the period included in the schedule, relative to the event. | Timesheet.endTimeRelativeEvent and Timesheet.endEventInterpretation |
| on date | A specified date of a month that is included in the schedule, such as 02 FEB, 30 JUN, etc. | Timesheet.startDate and Timesheet.endDate Note that both startDate and endDate get the same value. |
| date range | A series of consecutive days of a year that are included in the schedule, such as 02-15 FEB, 23 MAR - 04 APR, etc. | Timesheet.startDate and Timesheet.endDate |
| on weekday | A specified day of the week that is included in the schedule, such as MON, TUE, etc. | Timesheet.day with this list of values CodeDayType |
| from weekday | A day of a week that, combined with a start time or event, indicates the start of the period included in the schedule. For example, "From MON 09:00...", etc. | Timesheet.day with this list of values CodeDayType |
| to weekday | A day of a week that, combined with an end time or event, indicates the end of the period included in the schedule. For example, "...till FRI 17:00", etc. | Timesheet.day with this list of values CodeDayType |
| exc. date | A specified date of a month that is fully excluded from the schedule. | Timesheet.startDate and Timesheet.endDate;in addition, the Timesheet.excluded shall get the value "YES". Note that both startDate and endDate get the same value (see also further data encoding rules). |
| exc. weekday | A specified day of the week that is fully excluded from the schedule. | Timesheet.day with this list of values CodeDayType;in addition, the Timesheet.excluded shall get the value "YES". |
Not supported schedules
Combining different schedule types in a single NOTAM is forbidden. It is considered that such combined schedules could become too complex for being understood and would have a high potential for providing conflicting information. For example, "daily 0900-1700 and each MON 1900-2300" would not have a clear meaning. Is the schedule for Mondays just 1900-2300, or is it both 0900-1700 and 1900-2300? Therefore, such combined schedules are not supported.
Note that the concept of "weekday ranges" (such as "MON-WED") is also not supported in this specification because it does not have a direct mapping in the current AIXM model for Timesheets and because sometimes there are confusions between MON-FRI and "working days". However, the automatic NOTAM generation rules for item D ensure that a set of consecutive weekdays with a similar start/end time will generate a "weekday range", according to the OPADD recommendations. 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 weekday records in AIXM.
Finally, schedules in the form "from date & time" - "to date & time" (such as "MAR 02 09:00 - 09 16:00") are definitively not supported. This type of schedules do not fit easily in the Timesheet class of AIXM, because the startTime and endTime properties are, by definition, related only to day and/or dayTill. The AIXM definitions could be changed, but that would also change the meaning of the existing schedules, already encoded for AIXM 4.5 static data. Such semantic changes would significantly complicate the mapping between AIXM 4.5 and AIXM 5.1 data sources. It is also highly questionable if such schedules are really needed, as they can easily be seen as individual occurrences of similar Events.
HMI recommendations
Some schedules may be relatively complex and this may lead to difficulties for the operator when trying to get the global picture of what is being encoded. The purpose of this section is to give some recommendations for the developers of schedule coding interfaces, based on the experience gathered in this area through trials and previous projects.
It is recommended that the HMI for schedules encoding enables both:
- "forms based" input - where the operator enters values in pre-defined fields, and
- "text based" input - where the operator types directly a textual description of the schedules and the application automatically decodes that into structured data; the text based input is expected to be used for simpler but frequently used schedules;
When the form based input is used, the application should generate a text based description of the schedule in real time, in the form that it would appear in a NOTAM item D or E. This would give confidence to the operator that the schedule was correctly encoded.
Additional versus complete hours
According to the AIXM Temporality document, a TEMPDELTA shall contain a complete description of the operating times.
Schedules are usually used when encoding availability or activation information, such as in the SAA.ACT, RTE.CLS, AD.CLS, etc. scenarios. In this situation, it is recommended that the input interface provides a "calendar/level" view of the activation/availability, enabling the operator to graphically visualise the status of the feature different times and levels (if applicable), such as in the example below:
In the calendar view, the BASELINE information that remains valid during the Event validity time shall be visibly identified from the information that is specific to the Event, for example by using a different color and fill pattern.
The TEMPDELTA shall contain the complete definition of the activity times, including any eventual time ranges that are recuperated from the BASELINE schedules. Note that according to the OPADD, notification of a schedule modification by NOTAM shall be done by including the new schedule in item E, not in item D. Therefore, the list of Event Scenarios has to include separate scenarios for such situations.
Data encoding rules
The data encoding rules provided in this section shall be followed in order to ensure the harmonisation of the digital encodings provided by different sources. These rules shall be used as complementing the General coding rules for Schedules defined in AIXM Coding Overview - Common Coding Rules - Schedule [TSH]. In case of contradiction, the rules described below are superseding the general ones.
The compliance with some of these encoding rules can be checked with automatic data validation rules (see next section).
| Identifier | Data encoding rule |
|---|---|
| ER-01 | Each use of "daily", "on date", "date range", "on weekday", or "from weekday...to weekday" shall be encoded as a single Timesheet, according to the mapping table. |
| ER-02 | All Timesheets shall get timeReference=UTC and daylightSavingAdjust=NO. |
| ER-03 | If "on date" is used, then both the Timesheet.startDate and the Timesheet.endDate shall get the value specified for "on date". |
| ER-04 | If "on date" or "date range" are used, then Timesheet.day shall get the value "ANY" and Timesheet.dayTill shall be left empty. |
| ER-05 | If "daily", "on weekday" or "from weekday...to weekday" are used, then in the corresponding Timesheet(s) both startDate and endDate shall be left empty. |
| ER-06 | If "on weekday" is used, then Timesheet.day shall get that value and Timesheet.dayTill shall be left empty. |
| ER-07 | If "exc. date" is used, then it shall be encoded as one Timesheet that has excluded=YES, startTime=00:00 and endTime=24:00; startDate and endDate shall both get the value specified for "exc. date". |
| ER-08 | If "exc. weekday" is used, then it shall be encoded as one Timesheet that has excluded=YES, startTime=00:00 and endTime=24:00; day shall get the value specified for "exc. weekday"; startDate and endDate shall be left empty. |
| ER-09 | The values WORK_DAY, BEF_WORK_DAY, AFT_WORK_DAY, HOL, BEF_HOL, AFT_HOL and BUSY_FRI cannot be used in Timesheet.day or Timesheet.dayTill. |
| ER-10 | According to the OPADD, item D is not allowed to exceed 200 characters. The application interface should check the length of the item D that results from the schedule encoding and invite the operator to split the NOTAM into two separate events in case this limit is exceeded. The HMI should allow copying a draft event into a second draft event. |
| ER-11 | It is not allowed to use "overnight" time periods in Event Schedules, e.g. 2200-0600. These shall be split into two separate time periods, e.g. 2200-2400 and 0000-0600. |
| ER-12 | If a schedule is more complex than the ones supported by the Templates provided for this scenario, then it shall be described in as a free text "note". |
Suggested for inclusion in common coding rules
When encoding schedules, the following needs to be taken into account (maybe as a new rule?):
- there should be no times left unspecified during the validity time of the TimeSlice. The schedule shall explicitly state when a feature is, for example operative and non-operative, if that is important for the recipient of the information. According to AIXM Temporality concept, it is recommended that BASELINE Timeslices contain only fully defined properties with schedule, which indicate explicitly what the property value is at every moment within the validity time of the TimeSlice. If one or more Timesheets are associated with a property with schedule, than the value of the property shall be considered as undefined at any moment not covered by a Timesheet.