Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 79 Next »

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 for the ICAO Data Sets include general coding rules for Schedules [PWS].  These are also applicable to Digital NOTAM Events. However, more restrictive rules apply to NOTAM schedules, such as excluding the possibility to use 'HOL' and other special dates. These limitations lead to a smaller number of coding patterns for Digital NOTAM Event schedules, which are presented in this section.

Limitations


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, including "on date" and "date range" options;
    e.g. "1/10 09:00-15:00 and on 3/10 10:00-12:00";
  • days of the week based schedules, including "on weekday", or "from weekday...to weekday" options;
    e.g. "every Monday from 13:00 to sunset".

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. 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.

UML class diagrams representation

The limitations identified above correspond to a subset of the general AIXM model for schedules. In the following diagram, classes and properties highlighted with orange color identify the part of the AIXM UML model which may be used for Digital NOTAM coding:

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: 

Tempdelta - 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 - Common coding patterns. In case of contradiction, the rules described below are superseding the general ones. 

The information items that may occur in the definition of schedules are identified in the diagrams described in the Common Coding Rules - Common coding patterns, section Common coding patterns. For use of "daily", "on date" and "date ranges" templates please refer to Common coding patterns - "Daily" schedules diagram. For use of "on weekday" and "from weekday...to weekday" please refer to Common coding patterns - "Weekday" schedules diagram. Each diagram is accompanied by the corresponding graphical elements explanation.

The compliance with some of these encoding rules can be checked with automatic data validation rules (see next section). 

IdentifierData encoding ruleRemarks (column to be deleted at the end)
ER-01Each 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. (to be deleted)

The rule could be deleted from here. A new rule chould be put under the common coding part:

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 [TS] and [/TS] indications in the graphical elements mapping tables.

Note: There exists already an indication in the common coding patterns, that separate Timesheets are needed but they are mentioned with respect to the diagrams. Probably needs to be deleted.

TSH.EVT--01All Timesheets shall get timeReference=UTC and daylightSavingAdjust=NO. Even the periods recuperated from the baseline data to fill in the gaps need to be converted to UTC.
ER-03If "on date" is used, then both the Timesheet.startDate and the Timesheet.endDate shall get the value specified for "on date". (to be deleted)

The rule could be deleted from here. A new rule chould be put under the common coding part:

If the Timesheet is related to one single date, both the Timesheet.startDate and the Timesheet.endDate shall get the value specified for that date.

ER-04If "on date" or "date range" are used, then Timesheet.day shall get the value "ANY" and Timesheet.dayTill shall be left empty. (to be deleted)

The rule could be deleted from here. A new rule chould be put under the common coding part:

If the Timesheet is related to one single date or date range, then Timesheet.day shall get the value "ANY" and Timesheet.dayTill shall be left empty.

ER-05If "daily", "on weekday" or "from weekday...to weekday" are used, then in the corresponding Timesheet(s) both startDate and endDate shall be left empty. (to be deleted)

The rule could be deleted from here. A new rule chould be put under the common coding part:

If the Timesheet is related to one single date, a weekday or time interval spreading over multiple weekdays then in the corresponding Timesheet(s) both startDate and endDate shall be left empty.

ER-06If "on weekday" is used, then Timesheet.day shall get that value and Timesheet.dayTill shall be left empty.(to be deleted)

The rule could be deleted from here. A new rule chould be put under the common coding part:

If the Timesheet is related to a weekday then Timesheet.day shall get that value and Timesheet.dayTill shall be left empty.

TSH.EVT-02If excluded 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".

I suggest to keep the rule here due to the time reference limitation. The common rules contain already an indication regarding excluded date, but require to be coded having timeReference='UTC+/-X' (local time as UTC zone).

TSH.EVT-03The 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.
TSH.EVT-04According 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-10It 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.(to be deleted)

The rule could be deleted from here. A new rule chould be put under the common coding part:

It is not allowed to use "overnight" time periods in Schedules, e.g. 2200-0600. These shall be split into two separate time periods, e.g. 2200-2400 and 0000-0600.

ER-11If 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".(to be deleted)

The rule could be deleted from here. A new rule chould be put under the common coding part:

If a schedule is more complex than the types provided, then it shall be described in as a free text "note".




  • No labels