The Event also has a "self-association" that allows encoding event trees, in which one event is the cause of other events. Therefore, the same event and its single AIXM 5 encoding may have several associated NOTAM. This ensures that the corresponding NOTAM will appear in the airport section of the Pre-Flight Information Bulletins (PIB), for the concerned airport. For example, if a navaid is used for approach/departure/arrival procedures at several closely located airports, then the current practice in many States is to publish a "navaid unserviceable" NOTAM for each airport that is affected, with the corresponding airport designator in item A. There are current NOTAM practices that can lead to situations where several NOTAM are associated with one Event. The issuing NOTAM office is modelled with the issuedBy association to the Unit class. These classes have all the attributes and associations necessary for coding the elements of the current messages as defined by ICAO - such as series, number, FIR, purpose, traffic, etc. The airports and/or FIR airspace affected by the Event may be identified through the direct " concerns" associations between the Event class and the AirportHeliport or Airspace class respectively. For example, the establishment of a new obstacle (temporary or permanent) might require two AIXM features TimeSlice to be encoded: (1 ) a new VerticalStructure ' BASELINE ' and (second) an additional ObstacleArea TimeSlice including the association to the new VerticalStructure, if relevant.Ī NOTAM, SNOWTAM or ASHTAM message may be generated and associated with the Event. There might exist events that require several AIXM feature TimeSlice to be encoded in different AIXM features. For example, the activation of a temporary restricted area will require a single Airspace TimeSlice of type ' TEMPDELTA '. Most events will need a single AIXM feature TimeSlice to be provided. In order to relate the AIXM feature TimeSlices with the Event, the belongsTo association is used, as visible on the top-right side of the diagram. This is the genuine “digital NOTAM” side of the schema. The information about the actual change brought by the operational situation for which the Digital NOTAM is issued is encoded as TimeSlice(s) of the relevant AIXM features. The elements of the Event Extension that are relevant for Digital NOTAM encoding are presented in the following UML class diagram. To enable the further updates of a previously issued event and of the corresponding NOTAM messages. This should enable the digital data users to work with a single source of data and will avoid the need to consult text NOTAM for those information items that are not yet available digitally
#EXAMPLWS OF TIMESLICE FREE#
To enable a basic digital encoding of the data contained in the NOTAM messages that are not digital such NOTAM can be encoded as free text notes associated with the feature affected. This should facilitate the migration from Text NOTAM to Digital NOTAM and the issuing in parallel of the two, during the transition period To enable the automatic generation of the NOTAM fields and the association of the event with the corresponding Text NOTAM message.
#EXAMPLWS OF TIMESLICE VERIFICATION#
To specify the operational situation for which the Digital NOTAM is encoded, in order to enable specific verification and processing rules to be applied to the associated feature TimeSlices
![examplws of timeslice examplws of timeslice](https://i.pinimg.com/originals/b2/29/94/b2299425638108246d70cc8c142c37fc.png)
Thus, the coding of Digital NOTAM uses the AIXM Event extension, which enables: A runway closure, the unavailability of a navaid or a temporary new obstacle are examples of such situations.
![examplws of timeslice examplws of timeslice](https://blogs.sw.siemens.com/wp-content/uploads/sites/51/2018/05/RR.png)
The purpose of the Event Extension is to enable the digital encoding of the aeronautical data that concerns identifiable operational situations, which result in the temporary or permanent alteration of one or more aeronautical information features or of their properties. These pages, once finalised, will be moved in the General Rules for coding/decoding of the Digital NOTAM Specification 2.0 Event extension