| Table of Contents |
|---|
...
| 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 valuesCodeTimeEventType |
| 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 valuesCodeTimeEventType |
| 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 valuesCodeDayType |
| 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 valuesCodeDayType |
| 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 valuesCodeDayType |
| exc. date | A specified date of a month that is fully excluded from the schedule. | Timesheet.startDate and Timesheet.endDate;in addition, theTimesheet.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 valuesCodeDayType;in addition, theTimesheet.excluded shall get the value "YES". |
...
- "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;
...
According to the AIXM Temporality document, a Tempdelta TEMPDELTA shall contain a complete description of the operating times. This has two consequences for applications that enable the encoding of schedules:
- 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;
- the concept of "additionally active..." is not supported; 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.
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.
End of day format
According to ICAO Annex 15, Appendix 6, NOTAM
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.
End of day format
...
According to ICAO Annex 15, Appendix 6, NOTAM Format, “the end of a day shall be indicated by ‘2359’”. However, in static data (AIP) the end of the day is usually indicated by “2400”. 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.
...
| 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 for Event Schedules. | ||
| 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 supported by the Template provided for this scenario, then it shall be described in as a free text "note"time periods, e.g. 2200-2400 and 0000-0600. |
| ER-12 | If a schedule is more complex than the supported by the Template 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 considerations need to be taken into account:
- 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;
- the concept of "additionally active..." is not supported; the BASELINE shall contain the complete definition of the activity times.