This folder contains the ten-file deep dive for the NOTAM Modernisation topic. The files cover the transition from legacy free-text NOTAM to structured Digital NOTAM (AIXM 5 event model), the regulatory framework under Annex 15 and PANS-AIM (Doc 10066), and the path toward data-centric Aeronautical Information Management (AIM) within SWIM.

Files and reading order#

The modules.md file is best consulted after reading overview.md and components.md. enablers.md and performance_objectives.md are reference files for planning use.

Source basis#

Primary sources used in this deep dive:

• Annex 15 (Aeronautical Information Services), sixteenth edition, Amendment 40, applicable 8 November 2018.
• Doc 10066 (PANS-AIM), first edition, applicable 8 November 2018; Amendment 1, applicable 4 November 2021.
• Doc 8126 (Aeronautical Information Services Manual), latest edition; NOTAM Selection Criteria (Appendix G), pre-flight information services (Chapter 10), Digital NOTAM context.
• ICAO Circular 329 (AIS/AIM) — Digital NOTAM definition and early deployment history.
• Doc 10007 (AN-Conf/13 Report) — DAIM thread, Module B0-DAIM and B1-DAIM.
• AIXM 5.2 specification (EUROCONTROL/FAA joint governance).

What NOTAM modernisation is#

NOTAM modernisation is the global programme to replace the legacy free- text, teleprinter-era NOTAM with a structured, machine-readable Digital NOTAM encoded in AIXM 5, distributed via SWIM, and capable of automated filtering, validation, and graphical rendering.

The problem it addresses is commonly called "NOTAM overload" or the "NOTAM crisis." A pre-flight information bulletin (PIB) generated for a typical long-haul flight may contain several hundred NOTAMs. A significant proportion of those items are of low direct relevance to the specific operation: administrative changes, distant taxiway works, or miscellaneous airspace reservations outside the flight's radius of concern. Safety-critical items — ILS out of service, runway reduced width, hazard at destination threshold — compete for attention within this volume.

ICAO documentation directly acknowledges the problem. Doc 8126 (the AIS Manual) §6.3.9.1.1 records explicit user feedback that "the text of NOTAM is cryptic and difficult to interpret." PANS-AIM §5.5.2 notes that all NOTAM are provided for briefing by default and that "content reduction should be at user's discretion" — a recognition that the system does not yet have the semantic tools to apply relevance at source.

Where it sits in the ICAO/ATM framework#

NOTAM modernisation is a component of the broader AIS-to-AIM (Aeronautical Information Services to Aeronautical Information Management) transition mandated by Annex 15 and operationalised through PANS-AIM (Doc 10066).

PANS-AIM §1.3 states: "The PANS-AIM contains provisions in support of the transition from product-based AIS to data-centric AIM." The shift is conceptual as well as technical: from a publication paradigm (AIP, NOTAM as products distributed on a schedule or on demand) to a data paradigm (a managed aeronautical data environment from which any product can be generated on demand and to which any authorised consumer can subscribe).

Within the ASBU (Aviation System Block Upgrade) framework, NOTAM modernisation sits in the DAIM (Digital Aeronautical Information Management) thread of the Globally Interoperable Systems and Data performance improvement area:

• B0-DAIM: Initial AIS-to-AIM transition. AIXM adoption, electronic AIP, quality-managed digital data sets. This is the Block 0 baseline already achieved or in progress across most ICAO regions.
• B1-DAIM: Full Digital AIM. All ATM information — including Digital NOTAM — encoded in standard formats (AIXM, FIXM, IWXXM), integrated, and shared through SWIM services.

The SWIM thread (B0-SWIM, B1-SWIM, B2-SWIM) provides the distribution infrastructure: Digital NOTAM is an AIXM data service within SWIM rather than a message sent over the aeronautical fixed service (AFS).

The three-layer model#

NOTAM modernisation operates at three interdependent layers:

1. Format and coding — the legacy NOTAM format (PANS-AIM Appendix 3) and ICAO NOTAM Code (PANS-ABC Doc 8400) provide the current operational vocabulary. The Q-line fields are the machine-readable portion; Item E) is free text and the primary source of readability and filtering problems.

2. Digital NOTAM event model — the AIXM 5 temporality model encodes aeronautical changes as structured, bounded TimeSlice events on named features. This is the core technical innovation. An event object is semantically queryable, graphically renderable, and automatically convertible back to a legacy text NOTAM for legacy consumers.

3. Distribution architecture — moving from point-to-point distribution over the AFS (aeronautical fixed service) to a SWIM publish/subscribe model where consumers pull the Digital NOTAM data they need, filtered to their area of interest and operational role.

Relationship to other topics in this workspace#

• AIM — NOTAM modernisation is the dynamic-data component of the AIS-to-AIM transition. PANS-AIM governs both.
• AIXM — AIXM 5.2 is the encoding standard for Digital NOTAM. The temporality model is the specific AIXM mechanism used.
• SWIM — SWIM is the target distribution architecture for Digital NOTAM services.
• ASBU — DAIM thread captures NOTAM modernisation as a formal ASBU deliverable within the information modernisation pillar.
• FF-ICE — as flight data becomes more digital (FIXM trajectory), the aeronautical environment data the FMS uses must also be digital; Digital NOTAM is the complementary data stream.

References#

• Annex 15 (Aeronautical Information Services), Chapter 5, §5.2.6 — NOTAM as an element of the integrated aeronautical information package.
• Annex 15, Chapter 6, §6.3.3.4 — Recommended Practice tying Digital NOTAM to the aeronautical information model (AIXM).
• Doc 10066 (PANS-AIM), Foreword §1.3 — Transition from product-based AIS to data-centric AIM as the overarching purpose of PANS-AIM.
• Doc 10066, Chapter 5, §5.5.2 — NOTAM briefing default and content reduction provision; identifies the filtering gap.
• Doc 8126 (Aeronautical Information Services Manual), Chapter 6, §6.3.9.1.1 — User feedback on NOTAM text readability; the "cryptic" formulation.
• Doc 10007 (AN-Conf/13 Report), DAIM Thread, Modules B0-DAIM and B1-DAIM — ASBU positioning of Digital AIM and Digital NOTAM.
• ICAO Circular 329 (AIS/AIM), §6.29–6.33 — Digital NOTAM definition, AIXM5 encoding, EUROCONTROL/FAA deployment history (authoritative source — not in local library).

The NOTAM format (legacy)#

PANS-AIM (Doc 10066) Appendix 3 defines the current NOTAM format. Every NOTAM consists of the following elements in order:

• Header: priority indicator, address block, date-time of filing, originator identifier
• Type indicator: NOTAMN (new), NOTAMR (replacing), NOTAMC (cancelling)
• Series and number: letter-series + four-digit number + slash + two- digit year (e.g. A0023/26)

The Q-line (machine-readable qualifier block)#

The Q-line is the primary machine-readable element of the legacy NOTAM and the basis for automated filtering and PIB generation. It is structured as follows:

Q) FIR/NOTAM Code/Traffic/Purpose/Scope/Coordinates,Radius/Lower/Upper

• FIR — ICAO location indicator of the FIR in which the subject is located. If it spans multiple FIRs within one State, the nationality letters plus "XX" are used.
• NOTAM Code — five-letter code starting with Q; the second and third letters identify the subject, the fourth and fifth letters denote the condition or status (from PANS-ABC, Doc 8400). Example: QFAXX (Q = NOTAM Code; FA = aerodrome/helipad; XX = condition unspecified).
• Traffic — I (IFR), V (VFR), or K (checklist). Combined qualifiers such as IV are permitted.
• Purpose — N (immediate attention), B (PIB entry, operationally significant), O (flight operations), M (miscellaneous, not for briefing by default), K (checklist). Combined: NBO, BO.
• Scope — A (aerodrome), E (en-route), W (warning area), K (checklist). Combined: AE, AW.
• Coordinates, Radius — latitude/longitude of the approximate centre of the area of influence plus a three-digit radius in NM.
• Lower/Upper — altitude limits in hundreds of feet AMSL (for airspace-relevant NOTAMs).

Items A through G#

• A) — ICAO location indicator(s) of the aerodrome(s) or FIR(s) affected.
• B) — Start of validity: six-digit date-time group (YYMMDDHHMM).
• C) — End of validity: date-time group, PERM (permanent), or EST (estimated).
• D) — Time schedule (optional): days of week and time ranges.
• E) — Free text: the substance of the NOTAM, composed of NOTAM Code phraseology, ICAO abbreviations, and plain language. PANS-AIM requires it to be as brief as possible; Doc 8126 recommends a maximum of 300 characters to improve readability and filtering.
• F)/G) — Lower and upper limits (optional): for airspace, obstacle, and activity NOTAMs.

Special series NOTAMs#

• SNOWTAM — PANS-AIM Appendix 4 format; surface condition report for runway contamination (snow, ice, slush, frost, standing water). Notifies RWYCC (runway condition code) per contamination type and runway third.
• ASHTAM — PANS-AIM Appendix 5 format; volcanic activity and ash cloud notification. Significant to aircraft operations, particularly engine and airframe vulnerability.
• Trigger NOTAM — issued when an AIRAC AIP Amendment or Supplement is published; contains a brief description, effective date, and reference number; remains valid in the PIB for 14 days from effective date (PANS-AIM §6.1.4.7).

The NOTAM Code#

The ICAO NOTAM Code is contained in PANS-ABC (Doc 8400). All five-letter NOTAM Code groups start with Q. The second-third letters identify the subject (aerodrome, navaid, approach procedure, airspace, obstacle, etc.) and the fourth-fifth letters identify the condition or status (available, not available, commissioned, unserviceable, restricted, etc.).

The NOTAM Selection Criteria (Doc 8126, Appendix G) provides the tables of valid combinations of subject, condition, traffic, purpose, and scope qualifiers for each type of aeronautical information. It is the governing reference for NOTAM origination quality and for PIB filter configuration.

Pre-flight information bulletin (PIB)#

The PIB is the presentation of current NOTAM information of operational significance prepared prior to flight. PANS-AIM defines three types (Doc 8126, Chapter 10): area PIB, route PIB, and aerodrome PIB. Each type applies different geographic and categorical filters from the NOTAM Selection Criteria to generate a tailored output.

Automated pre-flight information systems are required by PANS-AIM. They must support self-briefing (PANS-AIM Chapter 10) and apply selection criteria and filters at the flight crew's discretion. The system may apply tiered filters: default (all NOTAM in the area/route/ aerodrome scope), user-defined (exclude administrative, include only safety-of-flight), or custom queries.

The NOTAM checklist#

A checklist of valid NOTAM must be issued at intervals of not more than one month per series (PANS-AIM §5.2.5.3). It references the latest AIP Amendments, AIP Supplements, and AIC internationally distributed. The checklist does not cancel NOTAMs omitted from it.

Integrated aeronautical information package#

Annex 15 §5.2.1 defines the integrated aeronautical information package: AIP, AIP Amendments, AIP Supplements, AIC, NOTAM, and aeronautical charts. NOTAM is the only element with no fixed schedule. Its interface with the AIP is governed by the three-month incorporation rules (PANS-AIM §6.1.4.4 and §6.1.4.5):

• Permanent NOTAM must be incorporated into the AIP within three months.
• Temporary NOTAM of long duration (expected to exceed three months) must be incorporated into an AIP Supplement.

Digital NOTAM event — the AIXM 5 component model#

A Digital NOTAM is an AIXM 5 event object composed of one or more TimeSlice elements applied to one or more AIXM features. The key structural elements are:

• Feature — the aeronautical entity being changed: RunwaydirectionTimeSlice, AirspaceTimeSlice, NavaidComponentTimeSlice, RouteSegmentTimeSlice, etc.
• TimeSlice — a bounded temporal interval on a feature. The AIXM temporality model uses:
  • beginPosition and endPosition (ISO 8601 datetime) for validity
  • interpretation attribute: BASELINE (static data), TEMPDELTA (temporary change), PERMDELTA (permanent change), SNAPSHOT (point in time query result)
  • sequenceNumber and correctionNumber for version management
• Event — the AIXM event object that groups one or more TimeSlices belonging to the same operational change, carries the NOTAM text in a structured Note element, and provides the link from the Digital NOTAM back to the underlying feature data.
• Scenario — a Digital NOTAM scenario defines the set of AIXM features and TimeSlice types needed to express a specific class of change (e.g. "Runway Closure," "NavaidOutage," "AirspaceActivation"). EUROCONTROL has published a library of Digital NOTAM scenarios.

The event model enables:

• Graphical rendering: the affected feature and its change are locatable on a moving-map display.
• Automated validation: the TEMPDELTA is checked for consistency with the BASELINE (e.g. a runway closure cannot extend beyond the declared runway end).
• Legacy interoperability: the NOTAM text is generated from the structured event by a rules engine, ensuring PANS-AIM format compliance without manual authoring.
• Filtering by feature type: a flight planning system interested only in runway, taxiway, and ILS status can subscribe to those feature types and ignore obstacle and airspace NOTAMs.

AIRAC and the NOTAM interface#

The AIRAC system (28-day cycle, PANS-AIM §6.2) governs pre-planned operationally significant changes. Digital data sets under PANS-AIM are updated on AIRAC dates. Non-AIRAC changes occurring between the publication and effective date are incorporated into the data set updates (PANS-AIM §6.1.5.2). Trigger NOTAMs bridge the gap between the AIRAC publication date and the effective date.

In a mature Digital NOTAM environment, the Trigger NOTAM becomes a pointer to the AIXM TEMPDELTA that is already in the data service, rather than a standalone text message.

References#

• Doc 10066 (PANS-AIM), Chapter 5, §5.2.5.1 — General NOTAM specifications: format, language, one subject per NOTAM, 300-character guidance.
• Doc 10066, Appendix 3 — Complete NOTAM format with Q-line field definitions and instructions for completion.
• Doc 10066, Chapter 5, §5.2.5.3 — NOTAM checklist requirements: monthly interval, series-by-series basis.
• Doc 10066, Chapter 5, §5.5.2 — PIB rules; default briefing provision; purpose qualifier "M" exception.
• Doc 10066, Chapter 6, §6.1.4.4 and §6.1.4.5 — Three-month rules for incorporating permanent and long-duration temporary NOTAM into AIP and AIP Supplement.
• Doc 10066, Chapter 6, §6.1.4.7 — Trigger NOTAM specifications; 14-day validity for AIRAC announcements.
• Doc 10066, Chapter 6, §6.2 — AIRAC system; 28-day cycle; circumstances requiring AIRAC notification.
• Doc 8126 (Aeronautical Information Services Manual), Appendix G — NOTAM Selection Criteria: valid combinations of NOTAM Code, traffic, purpose, and scope for automated filtering.
• Doc 8126, Chapter 10 — Pre-flight information services; automated PIB generation; filter levels and self-briefing.
• ICAO Circular 329 (AIS/AIM), §6.30–6.33 — Digital NOTAM component model; AIXM5 as encoding format; event and scenario definitions (authoritative source — not in local library).
• Annex 15 (Aeronautical Information Services), §5.2.1 — Integrated aeronautical information package elements.

What a "block" means for NOTAM modernisation#

Unlike ASBU Blocks (which have fixed six-year notional dates), the evolution stages of NOTAM modernisation are technology-maturity stages rather than time-boxed windows. They map loosely to the ASBU DAIM thread Blocks (B0-DAIM, B1-DAIM) and to the SWIM implementation trajectory, but also include a pre-ASBU legacy stage and a near-term transition stage not captured in a single ASBU module.

The four stages below represent the real-world progression from the original teleprinter NOTAM to SWIM-distributed Digital NOTAM. Most ICAO States currently sit in Stage 2 or Stage 3.

Evolution stages#

Stage 1 — Legacy free-text teleprinter NOTAM#

Character: Analogue-origin. NOTAM originated in plain language, sent over the aeronautical fixed telecommunication network (AFTN) as telex messages. Format standardised by ICAO from 1947 (PANS-NOTAM, later PANS-AIS, then Annex 15 SARPs). No structured metadata beyond the basic header and location indicator.

Distribution: Point-to-point AFTN distribution from the international NOTAM office (NOF) to subscribers based on predetermined distribution lists. Manual management of NOTAM series and checklists.

Limitations: No machine-readable content. PIB assembly was manual or semi-automated at best. No validation at origination beyond human review. All filtering was geographic and administrative, not semantic.

ASBU alignment: Pre-ASBU baseline. Annex 15 Amendment 1 (1953) introduced the first SARPs; the ICAO NOTAM Code emerged with Amendment 8 (1964).

Stage 2 — Structured/coded NOTAM with Q-line filtering#

Character: Digital message with structured metadata. The Q-line (introduced progressively through Annex 15 amendments) provides machine- readable qualifiers: FIR, NOTAM Code, traffic, purpose, scope, and geographic radius. Automated pre-flight information systems use the Q-line to generate PIBs without manual selection.

Distribution: AFTN (increasingly AMHS — Aeronautical Message Handling System) with digital NOF databases. Regional pooling through multinational NOTAM processing units (e.g. EUROCONTROL SITA NOTAM Service in Europe, EAD as the European master repository).

Quality programmes: Annex 15 Amendment 40 (2018) incorporated AIM requirements including data quality management. Doc 8126 NOTAM Selection Criteria (Appendix G) codify the correct NOTAM Code / qualifier combinations. National and regional quality audit programmes check compliance, brevity, and duration appropriateness.

Key enablers: PANS-AIM first edition (2018) consolidates all NOTAM specifications; automated pre-flight information systems required (PANS-AIM Chapter 10); NOTAM checklist discipline enforced.

ASBU alignment: Partially within B0-DAIM (initial digital data provision, electronic AIP, quality management). Most States have completed or are completing this stage.

Stage 3 — Digital NOTAM (AIXM 5 event, parallel legacy output)#

Character: The origination step produces an AIXM 5 event object rather than a free-text message. A rules engine automatically generates the legacy NOTAM text from the structured event, ensuring PANS-AIM format compliance and enabling backward compatibility. The event object is stored in the authoritative data service; the text NOTAM is a derived product.

Key capabilities:

• Automatic validation of the event against the BASELINE AIXM feature data (e.g. runway dimensions, ILS categories) at origination.
• Graphical rendering of the affected area or feature directly from the event object.
• Feature-type filtering: flight planning systems can subscribe to specific AIXM feature types (runway, navaid, airspace) rather than receiving all NOTAM in a geographic area.
• Automated scenario libraries: published event templates (EUROCONTROL Digital NOTAM scenarios) guide originators through structured data entry for the most common NOTAM types.

Representative deployments:

• FAA NOTAM Management System (NMS): AIXM5-based digital NOTAM submission, deployed progressively from 2008. The January 2023 NMS outage led to a nationwide ground stop; post-event review reinforced the case for architectural redundancy and quality assurance.
• EUROCONTROL EAD (European AIS Database): Digital NOTAM capability for European States; AIXM5 event submission; gateway to legacy format for non-AIXM consumers.

Annex 15 §6.3.3.4 is the normative hook: digital NOTAM for temporary changes should use the same aeronautical information model as the complete data set (Recommended Practice).

ASBU alignment: B1-DAIM (full Digital AIM, AIXM 5 data products; Block 1, from 2019). Progressive deployment in Europe and North America; ongoing in other regions.

Stage 4 — SWIM-distributed AIXM data service (native subscription)#

Character: Digital NOTAM is no longer a message at all. It is a temporal change to the authoritative AIXM feature data set, published as a SWIM data service. Consumers subscribe to the service for their area of interest, feature types of concern, and purpose (flight planning, ATM automation, EFB). No PIB assembly step is needed — the consumer's system queries the authoritative data in real time.

Key capabilities:

• Pull model (request/response or event-driven subscription) replaces the push model (AFTN/AMHS distribution list).
• Quality of service: SWIM policy-based access and data quality guarantees ensure that safety-critical consumers receive high- integrity, low-latency data.
• Integration with flight object: the AIXM event for a runway closure can propagate automatically into the FF-ICE flight object as a trajectory constraint, without human re-entry.
• Near-elimination of the relevance problem: a consumer subscribes only to features on its route, at its airports, within its sector — the distribution system enforces topical scope at source.

ASBU alignment: B1-SWIM and B2-SWIM (operational SWIM services; policy-based access and quality of service). Full Stage 4 is a medium- term target (ASBU Block 1/2 horizon, 2019-2031).

Stage summary table#

References#

• Annex 15 (Aeronautical Information Services), Chapter 6, §6.3.3.4 — Recommended Practice: Digital NOTAM for temporary changes should use the aeronautical information model (AIXM).
• Doc 10066 (PANS-AIM), Foreword §1.3 — Transition from product-based AIS to data-centric AIM; the overarching driver.
• Doc 10007 (AN-Conf/13 Report), Module B0-DAIM — Initial AIS-to-AIM ASBU module; AIXM adoption and electronic AIP as the Stage 2/3 boundary.
• Doc 10007, Module B1-DAIM — Full Digital AIM; integration of all ATM information in standard digital formats; Stage 3/4 boundary.
• ICAO Circular 329 (AIS/AIM), §6.29–6.33 — Digital NOTAM concept; EUROCONTROL EAD and FAA NMS as Stage 3 deployments; transition strategy (authoritative source — not in local library).

Functional axes#

NOTAM modernisation spans six functional axes (threads). Each thread is a coherent body of work with its own standards, tools, and implementation milestones. Progress in one thread enables the next: you cannot have effective Digital NOTAM (Thread 3) without a quality origination process (Thread 1) and a mature coding vocabulary (Thread 2). The SWIM distribution thread (Thread 5) requires both the event model (Thread 3) and stable governance (Thread 6).

Thread 1 — Origination and quality#

What it covers: The processes and systems by which aeronautical data originators (airport operators, airspace managers, CNS facility managers, national AIS offices) create NOTAM. Quality at origination determines everything downstream.

Current state: In Stage 2 (structured NOTAM), originators typically send a change request to the national AIS/NOF, which translates it into a NOTAM using the NOTAM Code vocabulary and PANS-AIM format rules. Human translation introduces errors. Doc 8126 §6.3.9.1.1 records that "the text of NOTAM is cryptic and difficult to interpret" partly because originators are not always NOTAM-trained specialists.

Modernisation target: In Stage 3/4 (Digital NOTAM), originators use guided forms based on AIXM scenario templates. The scenario constrains the input to the semantically correct structure. Automatic validation checks the event against the BASELINE data before submission. The AIS/NOF role shifts from transcription to quality assurance and approval.

Key requirements: PANS-AIM §5.2.5.1.9 — one subject and one condition per NOTAM; §5.2.5.1.2 — text composed of NOTAM Code phraseology and ICAO abbreviations; Doc 8126 §6.3.9.2 — Item E) limited to 300 characters recommended maximum.

Thread 2 — NOTAM Code and structure#

What it covers: The ICAO NOTAM Code (PANS-ABC, Doc 8400) and the NOTAM Selection Criteria (Doc 8126, Appendix G). These are the controlled vocabularies and combination rules that make the Q-line machine-readable.

Current state: The NOTAM Code has approximately 300 subject- condition combinations covering most operational change types. The Selection Criteria tables specify which subject-condition pairs are valid and what traffic, purpose, and scope qualifiers are appropriate. Where no code exists, "XX" placeholders are permitted but reduce automated classification.

Modernisation target: The NOTAM Code vocabulary must be kept current with emerging operational changes (e.g. UAS operations, new approach types, satellite-based augmentation changes). In the Digital NOTAM environment, NOTAM Code assignment is generated automatically from the AIXM event type rather than selected manually by the originator.

Key requirements: PANS-AIM Appendix 3 — Q-line field definitions and valid qualifier combinations; PANS-AIM §5.2.5.1.2 — NOTAM Code phraseology as the normative vocabulary; PANS-ABC (Doc 8400) — the master code list.

Thread 3 — Digitalisation and AIXM event model#

What it covers: The core technical work of encoding aeronautical changes as AIXM 5 events rather than free-text messages. This is the central innovation of NOTAM modernisation.

AIXM temporality model: The AIXM 5 temporality model uses TimeSlice objects with four interpretation types:

• BASELINE: the static authoritative data for a feature.
• TEMPDELTA: a temporary change applied on top of the BASELINE for a bounded validity interval (beginPosition / endPosition). This is the encoding used for Digital NOTAM.
• PERMDELTA: a permanent change to the BASELINE. Used for AIRAC permanent updates, not for NOTAM.
• SNAPSHOT: a point-in-time view of the feature state, generated by merging BASELINE with applicable TEMPDELTAs. This is what a consumer retrieves.

Scenario library: A Digital NOTAM scenario defines the set of AIXM features and TimeSlice attributes needed to encode a specific type of operational change. EUROCONTROL has published a Digital NOTAM scenario library covering runway closures, reduced runway length, taxiway closures, navaid outages, ILS categories, airspace activations, and more. Scenario libraries reduce origination time and ensure semantic consistency.

Legacy bridge: The rules engine that generates legacy NOTAM text from an AIXM event is a critical transition component. It enables States at different modernisation stages to interoperate: an AIXM-native originator generates an event; the bridge produces a compliant text NOTAM for AFTN distribution to States not yet consuming AIXM.

Key requirements: Annex 15 §6.3.3.4 — Digital NOTAM Recommended Practice; AIXM 5.2 specification (EUROCONTROL/FAA, current version); PANS-AIM Appendix 1 — aeronautical data catalogue (the BASELINE features that TEMPDELTAs modify).

Thread 4 — Filtering, briefing, and relevance#

What it covers: The mechanisms by which the vast NOTAM dataset is reduced to the operationally relevant subset for a specific flight, crew, controller, or system.

Current tools: NOTAM Selection Criteria (Doc 8126, Appendix G); Q-line qualifiers (purpose, scope, geographic radius); automated pre- flight information systems; PIB types (area, route, aerodrome); user- defined filter settings.

Current limitations: Item E) is free text and cannot be semantically queried. A flight crew reviewing a PIB must read each entry manually to assess relevance. Purpose qualifier "B" (PIB entry) is liberally applied, resulting in PIBs dominated by low-consequence items.

Modernisation target: With Digital NOTAM (Thread 3), filters operate at the feature and attribute level rather than the text level. A crew interested in ILS Category II availability can query for NavaidComponent features of type ILS with TEMPDELTA interpretation within a radius of the destination. The PIB becomes a structured query result rather than a text document.

Key requirements: PANS-AIM §5.5.2 — user-discretion content reduction; PANS-AIM Chapter 10 — automated pre-flight information service specifications; Doc 8126 Chapter 10 — filter types and self-briefing capability.

Thread 5 — Distribution and SWIM#

What it covers: The infrastructure by which NOTAM — legacy or digital — is distributed to consumers.

Legacy architecture: AFTN/AMHS point-to-point distribution from the originating NOF to subscribing NOFs and multinational processing units (PANS-AIM §5.4.2). Predetermined distribution lists control routing. Selective distribution reduces AFS traffic (Doc 8126 §9.1.4.1).

Transition architecture (Stage 3): The EAD/NMS model: Digital NOTAM submitted to a centralised database; legacy NOTAM text generated and distributed over AFTN to non-AIXM consumers; AIXM queries available to authorised digital consumers via web services.

Target architecture (Stage 4): SWIM publish/subscribe. The Digital NOTAM data service is a SWIM service providing AIXM event data. Flight planning systems, ATM automation, and EFBs subscribe to the data service with geographic, feature-type, and purpose filters. No PIB assembly; consumers pull what they need on demand. This aligns with ASBU B1-SWIM (operational SWIM services) and B2-SWIM (full SWIM with policy-based access).

Key requirements: PANS-AIM §5.4.2 — NOTAM distribution rules and AFS use; B0-SWIM and B1-SWIM ASBU modules (Doc 10007 and GANP Portal); SWIM technical infrastructure (ICAO SWIM panel publications).

Thread 6 — Governance and standards evolution#

What it covers: The institutional and regulatory work needed to sustain NOTAM modernisation across States, regions, and global programmes.

ICAO mechanisms:

• Annex 15 SARPs evolution: Amendment cycle governed by the AIS-AIM Study Group (AIS-AIMSG). Amendment 40 (2018) restructured Annex 15 to facilitate AIM. Further amendments address Digital NOTAM obligations.
• PANS-AIM evolution: Managed by the Secretariat; Amendment 1 (2021) updated runway surface condition provisions; further amendments expected to strengthen Digital NOTAM requirements.
• GANP/ASBU: DAIM thread modules (B0-DAIM, B1-DAIM) in the GANP Portal define the implementation expectations and readiness criteria.

Regional bodies:

• Europe: EUROCONTROL coordinates the EAD and Digital NOTAM programme; EASA provides regulatory framework for ANS.
• North America: FAA leads the NMS programme; ICAO North American and Caribbean (NACC) office coordinates regional harmonisation.
• APAC: APANPIRG monitors DAIM implementation under the APAC Seamless ATM Plan.

Standards bodies:

• AIXM Change Control Board (EUROCONTROL / FAA, joint) — AIXM 5.2 version governance; Digital NOTAM scenario library maintenance.
• WMO: For SNOWTAM and ASHTAM, the interface with meteorological services and volcanic ash advisories requires coordination with WMO standards.

Key requirement: Annex 15 §1.1 — global application; all Contracting States obligated to provide AIS/AIM per these SARPs.

References#

• Doc 10066 (PANS-AIM), Chapter 5, §5.2.5.1.2 — NOTAM Code phraseology as the normative vocabulary; machine-readable Q-line.
• Doc 10066, Chapter 5, §5.5.2 — Briefing default and user-discretion content reduction.
• Doc 10066, Chapter 10 — Automated pre-flight information systems; self-briefing; filter application.
• Doc 10066, Chapter 5, §5.4.2 — NOTAM distribution over AFS; predetermined distribution system.
• Doc 8126 (Aeronautical Information Services Manual), Appendix G — NOTAM Selection Criteria; valid code/qualifier combinations for filtering.
• Annex 15 (Aeronautical Information Services), Chapter 6, §6.3.3.4 — Recommended Practice for AIXM-based Digital NOTAM.
• ICAO Circular 329 (AIS/AIM), §6.31–6.33 — Improvements from Digital NOTAM: graphical visualisation, quality validation, filtering; EUROCONTROL/FAA deployment details (authoritative source — not in local library).

Focus of this file#

This file gives a detailed worked example of one Digital NOTAM strand: creating a Digital NOTAM for a runway closure as an AIXM 5 event. It illustrates the transition from legacy text origination (Stage 2) to structured event origination (Stage 3) and shows how both outputs are derived from a single structured record.

A second, shorter example covers an ILS out-of-service notification to contrast a navaid Digital NOTAM with the aerodrome-surface case.

Worked example: Runway closure Digital NOTAM#

Operational scenario#

Karachi/Jinnah International Airport (OPKC) needs to close Runway 25L for a 4-hour maintenance window from 0200 UTC to 0600 UTC on a given date. The declared length of Runway 25L is 3,400 m. The closure applies to both IFR and VFR traffic.

Stage 2 output (legacy NOTAM text)#

Using the NOTAM Selection Criteria (Doc 8126, Appendix G) and the PANS-AIM Appendix 3 format, the AIS/NOF would originate:

(A0103/26 NOTAMN
Q) OPKZ/QMRLC/IV/NBO/A/000/999/2459N06710E005
A) OPKC
B) 2601150200
C) 2601150600
E) RWY 25L CLSD FOR MAINT.
)

Q-line breakdown:

• OPKZ — Karachi FIR
• QMRLC — NOTAM Code: MR (runway), LC (closed)
• IV — IFR and VFR traffic
• NBO — purpose: immediate attention + PIB entry + flight operations
• A — scope: aerodrome
• 000/999 — lower/upper limits (full range for aerodrome scope)
• 2459N06710E005 — coordinates of OPKC centre, radius 5 NM

Stage 3 input (AIXM 5 event origination)#

In a Digital NOTAM system, the originator accesses a guided form corresponding to the "Runway Closure" scenario. The form presents structured fields derived from the AIXM model:

Scenario:      Runway Closure
Airport:       OPKC (Karachi/Jinnah International)
Runway:        25L
Validity from: 2026-01-15T02:00:00Z
Validity to:   2026-01-15T06:00:00Z
Reason:        Maintenance
Traffic:       IFR + VFR

The system constructs an AIXM 5 event object. The core structural elements are:

Feature affected: RunwayDirection (OPKC RWY 25L)

TimeSlice (TEMPDELTA):

interpretation: TEMPDELTA
sequenceNumber: 1
beginPosition: 2026-01-15T02:00:00Z
endPosition:   2026-01-15T06:00:00Z
timeSlice.status: CLOSED

Event annotation:

Note (translationNote): "RWY 25L CLSD FOR MAINT."
Note (purpose):         N, B, O
NOTAM Code:             QMRLC (generated from feature type + status)
Traffic:                IV (generated from scope of change)

BASELINE linkage: The system validates the event against the OPKC BASELINE data set: Runway 25L exists, its declared length is 3,400 m, it has a valid RunwayDirection record — the TEMPDELTA is consistent.

Stage 3 output (generated legacy NOTAM)#

The rules engine takes the AIXM event and generates:

(A0103/26 NOTAMN
Q) OPKZ/QMRLC/IV/NBO/A/000/999/2459N06710E005
A) OPKC
B) 2601150200
C) 2601150600
E) RWY 25L CLSD FOR MAINT.
)

This is identical in format to the Stage 2 NOTAM. Legacy consumers receive the same NOTAM text. Digital consumers receive the AIXM event object.

What Digital NOTAM adds#

A flight planning system consuming the AIXM event can:

1. Render Runway 25L as a closed feature on an airport moving-map display for the validity period, colour-coded closed.
2. Check whether any filed arrival is scheduled into OPKC on Runway 25L between 0200 and 0600 UTC and alert the dispatcher.
3. Cross-reference the event with the approach procedure database: the ILS 25L approach is affected; the FMS database update service flags the event as relevant to approach planning.
4. Exclude the event from a PIB requested by an operator routing only through the en-route airspace, not to OPKC.

None of these actions are possible from the text NOTAM alone without additional processing.

Worked example: ILS Category I out of service#

Scenario#

The ILS for Runway 07L at Lahore (OPLL) is unserviceable for a 24-hour period.

Legacy NOTAM (Stage 2)#

(A0211/26 NOTAMN
Q) OPLR/QILAS/IV/NBO/A/000/999/3134N07421E010
A) OPLL
B) 2601200000
C) 2601210000
E) ILS RWY 07L U/S.
)

Q-line: QILAS — NOTAM Code: IL (ILS localiser), AS (unserviceable).

Digital NOTAM event (Stage 3)#

Feature affected: NavaidComponent (ILS for OPLL Runway 07L)

TimeSlice (TEMPDELTA):

interpretation: TEMPDELTA
beginPosition: 2026-01-20T00:00:00Z
endPosition:   2026-01-21T00:00:00Z
timeSlice.operationalStatus: UNSERVICEABLE

The system can further decompose: the localiser is unserviceable but the glidepath status is unchanged (or also unserviceable). This granularity is not possible in the text NOTAM without additional free-text clauses.

Consumer benefit: An EFB with AIXM awareness can display the ILS status directly on the approach chart overlay. A flight planning system can automatically add the "no CAT I ILS" constraint to OPLL for the validity period and recalculate alternate requirements.

Key design principles illustrated#

These worked examples illustrate three core Digital NOTAM design principles:

1. Single source, multiple outputs. The AIXM event is the authoritative record. Legacy NOTAM text, PIB entries, graphical overlays, and flight-object constraints are all derived outputs. There is no separate authoring step for each format.

2. Validation at origination. Checking the TEMPDELTA against the BASELINE at the moment of origination catches errors before they enter the distribution system. A NOTAM closing a runway that does not exist, or specifying an ILS category not published for that runway, is rejected immediately.

3. Semantic subscription replaces volume distribution. A consumer interested in OPKC runway status subscribes to RunwayDirection TEMPDELTAs for OPKC, and receives only those. A consumer interested in all ILS outages in the OPLR FIR subscribes to NavaidComponent TEMPDELTAs with operationalStatus = UNSERVICEABLE within the FIR polygon. Neither consumer needs to download and parse the full regional NOTAM dataset.

References#

• Doc 10066 (PANS-AIM), Appendix 3 — NOTAM format; Q-line field definitions and instructions for completion; Items A–G.
• Doc 10066, Chapter 5, §5.2.5.1 — General NOTAM specifications; one subject per NOTAM; NOTAM Code usage; brevity requirement.
• Doc 8126 (Aeronautical Information Services Manual), Appendix G — NOTAM Selection Criteria; QMRLC and QILAS as valid code-condition combinations; traffic and purpose qualifier guidance.
• Annex 15 (Aeronautical Information Services), Chapter 6, §6.3.3.4 — Recommended Practice: Digital NOTAM should use the AIXM aeronautical information model.
• ICAO Circular 329 (AIS/AIM), §6.31 — Radical improvements from Digital NOTAM: graphical visualisation, automatic data quality validation, improved filtering (authoritative source — not in local library).

Overview#

Digital NOTAM cannot be delivered by technology alone. Six categories of enablers must mature together: CNS infrastructure, procedural frameworks, data quality culture, training, regulation, and institutional arrangements. The ASBU DAIM and SWIM threads make enabler readiness explicit through their global readiness checklists.

1. CNS and infrastructure#

AFTN/AMHS to IP transition#

Legacy NOTAM distribution runs over the AFTN (Aeronautical Fixed Telecommunication Network) or its successor AMHS (Aeronautical Message Handling System). Both are point-to-point message systems unsuited to SWIM's publish/subscribe model. The transition to internet-protocol (IP) based services — part of the COMI thread (communications modernisation) — is a prerequisite for Stage 4 SWIM-based Digital NOTAM distribution.

States that have not migrated AFS communications to IP-based services cannot natively consume SWIM data services. They require gateways that bridge AIXM data services to AFTN/AMHS distribution.

Authoritative aeronautical database#

Digital NOTAM TEMPDELTAs are validated against a BASELINE AIXM feature dataset. The BASELINE must exist: it must be maintained, quality-assured, and accessible to the NOTAM origination system. Establishing and maintaining the national aeronautical database in AIXM format — a prerequisite for Digital NOTAM — is itself a significant infrastructure investment. This is part of the B0-DAIM task.

Pre-flight information system#

Automated pre-flight information systems are required by PANS-AIM Chapter 10. Without an operational automated system, self-briefing (including Digital NOTAM consumption) cannot be delivered to flight crews. The system must support NOTAM Selection Criteria filtering and, ultimately, AIXM query interfaces.

2. Procedures#

NOTAM origination procedures#

Current procedures route aeronautical change notifications from operational departments (airport ops, ATC, navigation aids) through AIS/NOF for translation into NOTAM text. In a Digital NOTAM environment, originating departments must work directly with structured templates. Procedural re-engineering is needed to remove the human-translation bottleneck while preserving the AIS/NOF quality-assurance function.

AIRAC/change management integration#

AIRAC (28-day cycle) governs pre-planned changes. Digital NOTAM procedures must integrate with AIRAC so that planned TEMPDELTAs are pre-loaded as pending events, automatically activating and deactivating at the correct times without manual intervention on the effective date.

Data originator engagement#

Airport operators, ATC units, instrument procedure designers, and CNS maintenance teams are the ultimate sources of aeronautical data. Their procedures must include data origination steps that feed directly into the digital chain rather than producing paper notifications for AIS to transcribe. This requires memoranda of understanding (MOUs) or regulatory obligations between AIS providers and data originators.

3. Data quality and integrity#

Data quality is the most frequently cited barrier to Digital NOTAM adoption. The ICAO SARPs requirements include:

• Accuracy and resolution: PANS-AIM Appendix 1 defines accuracy and resolution requirements for each aeronautical data element. The BASELINE must meet these requirements before TEMPDELTAs can be validated against it.
• Timeliness: PANS-AIM §6.1.4.1 requires NOTAM to be published with sufficient lead time. In the digital environment, events must enter the data service with correct beginPosition values reflecting the operational effective time.
• Completeness: A scenario-based Digital NOTAM approach requires that all referenced features (runways, navaids, airspace, procedures) are already in the BASELINE dataset. Incomplete datasets produce validation failures that block origination.
• NOTAM quality audit: National and regional quality audit programmes — assessing NOTAM duration, purpose qualifier correctness, text length, and NOTAM Code correctness against the Selection Criteria — are a prerequisite for transition because they reveal gaps in data originator training and system compliance before digitalisation.

4. Training#

AIS personnel#

AIS/NOF staff must transition from NOTAM text composition to Digital NOTAM quality assurance. The core skill shifts from "how to write a NOTAM Code for a runway closure" to "how to validate an AIXM TEMPDELTA against the BASELINE and ensure scenario compliance." Training must cover the AIXM data model at a working level.

Data originators#

Airport operations personnel, CNS maintenance staff, and procedure designers need training in the structured data entry tools. The goal is to reduce the dependency on AIS as an intermediary and enable direct digital origination.

Flight crew and dispatcher#

Even with Digital NOTAM infrastructure in place, the transition to fully structured pre-flight products takes time. Flight crew training must address both the improved graphical and filtered PIB products and the continued need to interpret legacy text NOTAM during the transition period.

5. Regulation and certification#

National AIP obligations#

Annex 15 §1.1 requires all Contracting States to establish and maintain an AIS meeting the SARPs. The SARPs do not yet mandate Digital NOTAM (§6.3.3.4 is a Recommended Practice) but increasingly frame quality management, data exchange, and digital data set obligations as Standards. States must align their national regulations with Annex 15 amendments.

Liability and authority#

Digital NOTAM raises new questions about the authority and liability of derived NOTAM text generated from AIXM events. Regulators must clarify which version — the AIXM event or the generated text NOTAM — is the authoritative record in case of dispute. PANS-AIM provisions do not yet resolve this explicitly.

EASA applicability (European region)#

In Europe, EASA Commission Regulation (EU) 2017/373 (Common Requirements for ATM/ANS providers) requires AIS providers to meet specific data quality and service obligations aligned with PANS-AIM and the EUROCONTROL Digital NOTAM programme. EAD participation is a regional expectation for EU Member States.

6. Institutional arrangements#

International NOTAM exchange#

PANS-AIM §5.4.2.5 requires that international NOTAM exchange between NOFs is mutually agreed. In a Digital NOTAM environment, bilateral or multilateral data service agreements are needed to govern SWIM AIXM service access, quality-of-service obligations, and fallback to legacy distribution when services are unavailable.

Multinational NOTAM processing units#

Multinational processing units (e.g. the EUROCONTROL SITA NOTAM Service; EAD for Europe) aggregate national NOTAM data and provide centralised distribution. These units must evolve into AIXM data service hubs in the Stage 4 architecture.

ICAO SWIM governance#

The ICAO SWIM panel and its Technical and Operational Working Groups define the service interface specifications that Digital NOTAM services must conform to for SWIM interoperability. Participation in these groups by States and ANSPs is essential to ensure that national Digital NOTAM implementations are globally interoperable rather than bilateral point- to-point systems.

Resilience and redundancy#

The January 2023 FAA NMS outage demonstrates the risk of a centralised, single-system NOTAM architecture. The Digital NOTAM target architecture must include geographic redundancy, fallback to legacy distribution, and graceful degradation mechanisms. This is both an infrastructure and a governance requirement.

References#

• Doc 10066 (PANS-AIM), Chapter 10 — Automated pre-flight information system requirements; self-briefing capability obligation.
• Doc 10066, Chapter 5, §5.4.2 — NOTAM distribution; AFS obligations; multinational processing unit interface.
• Doc 10066, Appendix 1 — Aeronautical data quality requirements: accuracy, resolution, integrity classifications.
• Doc 10066, Chapter 6, §6.2 — AIRAC system; advance notification requirements; change management integration.
• Annex 15 (Aeronautical Information Services), Chapter 3 — Quality management requirements for AIS; data accuracy, timeliness, and completeness obligations.
• ICAO Circular 329 (AIS/AIM), §6.29 — Transition strategy for real-time, quality-assured aeronautical information; AIS-to-AIM transformation (authoritative source — not in local library).

Performance framework#

NOTAM modernisation is measured against the eleven Key Performance Areas (KPAs) defined in the Global ATM Operational Concept (Doc 9854) and the Manual on Global Performance of the Air Navigation System (Doc 9883). The primary driver is Safety — the overload and readability problem is a safety issue. Secondary drivers are Efficiency (briefing time, flight planning quality), Interoperability (AIXM as a global standard), and Cost-effectiveness (reduced manual handling).

Performance objectives#

PO-1 — Reduce safety-relevant NOTAM miss rate. Target: Reduction in runway-incursion and approach-related incidents attributable to missed or misread NOTAM. Measured by: incident reports citing NOTAM misinterpretation; percentage of safety-relevant NOTAM correctly identified in self-briefing tests.

PO-2 — Reduce PIB volume and improve relevance ratio. Target: Average PIB NOTAM count reduced by 30% at equivalent safety coverage, through improved Q-line coding and purpose qualifier discipline. Measured by: average NOTAM per PIB for a reference route set; user-assessed relevance score in standardised surveys.

PO-3 — Reduce NOTAM origination error rate. Target: NOTAM with coding errors or non-compliant format reduced to below 2% of total active NOTAMs per State. Measured by: national/ regional quality audit results; NOTAM duration violation rate; incorrect purpose qualifier rate.

PO-4 — Achieve Digital NOTAM origination coverage. Target: 100% of safety-critical NOTAM types (runway status, ILS serviceable, airspace restriction) originated as AIXM events in operational systems. Measured by: percentage of NOTAM types with operational Digital NOTAM origination capability; Stage 3 deployment penetration in ICAO regions.

PO-5 — Reduce NOTAM system outage impact. Target: Demonstrate operational continuity during NOTAM distribution system degradation; maximum acceptable outage impact of 30 minutes before fallback system activates. Measured by: system availability metrics; fallback activation time in exercises.

KPA contribution by implementation stage#

The matrix below scores each KPA by principal benefit at each modernisation stage (1 = some benefit, 2 = clear benefit, 3 = primary driver).

Key Performance Indicators (KPIs)#

Safety KPIs#

• Percentage of safety-critical NOTAM (purpose N) correctly identified in standardised pre-flight briefing proficiency assessments.
• Rate of incidents where NOTAM misinterpretation is a contributing factor, per million movements.
• Time-to-distribution for unplanned safety-critical NOTAM (target: under 30 minutes from the operational event to PIB availability).

Interoperability KPIs#

• Percentage of States with operational AIXM 5 capability for at least one Digital NOTAM scenario type.
• NOTAM Code compliance rate per region (measured by audit programmes against NOTAM Selection Criteria, Doc 8126 Appendix G).
• Percentage of NOTAM origination systems generating valid Q-line qualifiers per the Selection Criteria tables.

Cost-effectiveness KPIs#

• Average pre-flight briefing time per sector of flight (target: measurable reduction with Digital NOTAM/graphical PIB).
• AIS staff time per NOTAM originated (target: reduction through structured origination; reduction in NOTAMR/NOTAMC correction cycle frequency).
• Percentage of NOTAM with duration over 90 days (proxy for "zombie NOTAM" — items that should have been incorporated into the AIP).

Efficiency KPIs#

• Average number of NOTAM items in a representative route PIB (reference route set, measured before and after Digital NOTAM adoption).
• Percentage of NOTAM items assessed as directly operationally relevant by a reference review panel.

Descriptive KPA mapping#

The following table maps KPAs to the specific operational benefits of NOTAM modernisation and their primary evidence base.

References#

• Doc 9883 (Manual on Global Performance of the Air Navigation System) — KPA definitions and performance measurement methodology (authoritative source — not in local library).
• Doc 9854 (Global ATM Operational Concept), Chapter 2 — Eleven KPAs as the canonical performance framework for ATM.
• Doc 10066 (PANS-AIM), Chapter 5, §5.2.5.1 — NOTAM quality requirements: brevity, one subject, NOTAM Code compliance; basis for quality KPIs.
• Doc 8126 (Aeronautical Information Services Manual), Appendix G — NOTAM Selection Criteria; compliance with these tables is the basis for coding accuracy KPIs.
• ICAO Circular 329 (AIS/AIM), §6.31 — Digital NOTAM improvements: data quality (automatic validation), filtering capability; primary evidence for safety and interoperability KPA claims (authoritative source — not in local library).
• Doc 10007 (AN-Conf/13 Report), Module B0-DAIM performance summary — KPA-03 (Cost-effectiveness), KPA-05 (Environment), KPA-07 (Global Interoperability), KPA-10 (Safety) as the primary performance impacts of the initial DAIM module.

Historical evolution#

The timeline below traces NOTAM from its 1947 origins to the current Digital NOTAM transition. Two distinct threads run in parallel: the evolution of the ICAO regulatory framework (Annex 15 amendments, then PANS-AIM) and the evolution of operational systems (AFTN, EAD, NMS).

Key inflection points#

Three events most significantly shaped the modernisation trajectory:

1. 1991 Amendment 27 — Q-line introduction. The first machine- readable structure in the NOTAM format; enabled systematic PIB generation and geographic filtering.

2. 2018 PANS-AIM / Annex 15 Amdt 40 — the regulatory consolidation. For the first time, all NOTAM specifications are in a single PANS document (Doc 10066) with a dedicated AIM framework. §6.3.3.4 provides the normative basis for AIXM Digital NOTAM.

3. 2023 FAA NMS outage — the operational crisis. A single systems failure grounding all US departures accelerated institutional commitment to system resilience, redundancy, and the distributed architecture of SWIM.

References#

• Annex 15 (Aeronautical Information Services), Historical Summary — Amendment history from first edition (1953) through Amendment 40 (2018).
• Doc 10066 (PANS-AIM), Foreword — Historical background; AIS-AIMSG establishment (2008); first edition applicable date (8 November 2018).
• Doc 10007 (AN-Conf/13 Report), DAIM Thread — B0-DAIM and B1-DAIM module content, readiness status, and ASBU timelines.
• ICAO Circular 329 (AIS/AIM), §6.29–6.33 — 2004 Digital NOTAM concept; EUROCONTROL EAD 2012 target and FAA deployment (authoritative source — not in local library).
• AIXM official site (https://aixm.aero/) — AIXM version history; AIXM 5.2 published January 2025 (authoritative source — not in local library).

ICAO Annexes#

• Annex 15 (Aeronautical Information Services), Sixteenth Edition, applicable 8 November 2018, Chapter 5, §5.2.6 — NOTAM as an element of the integrated aeronautical information package; checklist of valid NOTAM required; detailed specifications in PANS-AIM.
• Annex 15, Chapter 5, §5.2.1 — Integrated aeronautical information package: AIP, AIP Amendments, AIP Supplements, AIC, NOTAM, and aeronautical charts.
• Annex 15, Chapter 6, §6.3.2.3 — Circumstances requiring NOTAM origination: unserviceability, hazards, temporary restrictions, airspace activation, and others.
• Annex 15, Chapter 6, §6.3.3.4 — Recommended Practice: digital NOTAM for temporary changes of short duration should use the same aeronautical information model as the complete data set; normative hook for AIXM-based Digital NOTAM.

ICAO PANS#

• Doc 10066 (PANS-AIM), Chapter 5, §5.2.5.1 — NOTAM general specifications: language, format, one subject per NOTAM, NOTAM Code usage, series numbering, replacement and cancellation procedures.
• Doc 10066, Chapter 5, §5.2.5.2 — NOTAM number and series allocation.
• Doc 10066, Chapter 5, §5.2.5.3 — NOTAM checklist: monthly interval, series-by-series, references to AIP Amendments and AIC.
• Doc 10066, Chapter 5, §5.4.2 — NOTAM distribution over the aeronautical fixed service; predetermined distribution; international exchange obligations.
• Doc 10066, Chapter 5, §5.5.2 — NOTAM briefing default provision; purpose qualifier "M" exception; content reduction at user discretion.
• Doc 10066, Appendix 3 — Complete NOTAM format: Q-line field definitions, Items A through G, instructions for completion.
• Doc 10066, Chapter 6, §6.1.4 — Specifications for NOTAM timing: lead time, unserviceability content, three-month rule for AIP incorporation.
• Doc 10066, Chapter 6, §6.1.4.7 — Trigger NOTAM specifications: issued for AIRAC AIP Amendments and Supplements; 14-day PIB validity.
• Doc 10066, Chapter 6, §6.2 — AIRAC system: definition, 28-day cycle, circumstances requiring AIRAC notification, advance distribution obligations.
• Doc 10066, Chapter 10 — Automated pre-flight information services: obligation, self-briefing, PIB types, selection criteria and filter application.
• Doc 10066, Appendix 1 — Aeronautical data catalogue: data elements, quality requirements (accuracy, resolution, integrity).

ICAO Manuals and Documents#

• Doc 8126 (Aeronautical Information Services Manual), Chapter 6, §6.3.9 — NOTAM text quality standards: 300-character guideline for Item E; plain language guidance; user feedback on cryptic text.
• Doc 8126, Chapter 6, §6.3.9.2 — Item E text quality; AIS responsibility for format translation; source departments instructed to limit content to bare essentials.
• Doc 8126, Appendix G — NOTAM Selection Criteria: tables of valid NOTAM Code subject, condition, traffic, purpose, and scope qualifier combinations; basis for automated filtering.
• Doc 8126, Chapter 10 — Pre-flight information services: automated system requirements; PIB types; filter levels; self-briefing architecture.
• Doc 9954 (37th Session Air Navigation Commission Report), Agenda Item 39 — AIS-to-AIM transition deliberations; EU/ECAC/EUROCONTROL proposal for Digital NOTAM global adoption; US NextGen support for NOTAM modernisation (authoritative source — not in local library).
• Doc 10007 (AN-Conf/13 Report), Module B0-DAIM — Initial AIS-to-AIM transition; AIXM adoption; electronic AIP; digital data sets as Block 0 ASBU deliverable.
• Doc 10007, Module B1-DAIM — Full Digital AIM; integration of all ATM information in standard formats (AIXM, FIXM, IWXXM); Block 1 ASBU deliverable.
• ICAO Circular 329 (AIS/AIM), Chapter 6, §6.29–6.33 — Digital NOTAM definition; AIXM5 as encoding format; improvements (graphical rendering, validation, filtering); EUROCONTROL EAD and FAA deployment history (authoritative source — not in local library).

Authoritative external references#

• https://www.aixm.aero/ - AIXM official site; AIXM 5.2 specification and Digital NOTAM temporality model documentation; EUROCONTROL/FAA joint governance
• https://www.eurocontrol.int/service/european-ais-database - EUROCONTROL EAD; Digital NOTAM capability; European States Digital NOTAM submission portal (authoritative source — not in local library)
• https://www.faa.gov/air_traffic/publications/atpubs/ntm_html/ - FAA NOTAM Management System; US Digital NOTAM origination and NMS architecture documentation (authoritative source — not in local library)
• https://www.icao.int/safety/airnavigation/AIS-AIM/Pages/default.aspx - ICAO AIS-AIM programme; PANS-AIM resources and regulatory roadmap (authoritative source — not in local library)
• https://ganpportal.icao.int/ - ICAO GANP Portal; DAIM thread modules (B0-DAIM, B1-DAIM) and readiness criteria (authoritative source — not in local library)