• 1

pulsar, pulsar consulting

Digital NOTAM Trial

 

 

Technologies

  • Linux Debian
  • Apache Web Server
  • Apache Tomcat
  • GIDPlus, Struts2, Spring, Hibernate, Velocity, Apache Commons
  • Oracle 10g, Spatial Option, SDO API
  • Google Maps
  • AIXM5-XML
  • HTTP, HTTPS, SMTP, UTF8, XHTML
  • J2EE, Java, JavaScript, PL/SQL
  • Web 2.0, (D)HTML, ExtJS, DHTML Goodies, Ajax, JQuery

The Air Traffic Management (ATM) system is increasingly becoming information-driven and requires access to quality managed aeronautical information. Aeronautical Information Management (AIM) is the successor of AIS and envisages transition from product centric to data centric, in order to provide the “right information at the right place and the right time”.

The aim of the xNOTAM trial is to demonstrate the maturity of the “digital NOTAM” concept, which is a fully data modeled NOTAM, by providing the standards, the framework, resources and a substantiated proof-of-concept for the full ECAC-wide implementation of the digital NOTAM concept, necessary to all ATM actors in order to support an accurate and always up-to-date common situational awareness of the aeronautical operations environment.

 

Project Objectives

The main objectives of the trial are to:

  • demonstrate the maturity of the “digital NOTAM” concept
  • validate the AIXM 5 timeslice model for managing permanent and temporary changes
  • check the completeness of (selected) AIXM 5 feature definitions
  • involve AIS Offices from ECAC State as test digital NOTAM data providers
  • identify potential digital NOTAM users and applications.

 

Application Scope

In order to achieve these objectives, Pulsar has developed and hosted a complete set of applications, including:

  • an Oracle Database entirely modeled against the AIXM 5.0 Model, including Spatiafunctionalities and an implementation of the Temporality Model
  • an AIXM 4.5 Mapping Software for automatically importing static data (baselines) into the application from EAD (through an SDO connection)
  • a user friendly web based Data Provider Interface allowing Data Providers to:
    • encode existing NOTAMs in an AIXM 5.0 format
    • select impacted features through a graphical map (on a subset of selected AMDB features)
    • preview the horizontal projection of airspaces on a satellite map
  • a user friendly web based Data User Interface allowing Data Users and system implementers to:
    • view encoded data in textual and AIXM formats
    • compare the temporary change with the initial valid baseline
    • preview the horizontal projection of airspaces on a satellite map
    • subscribe to email notifications to automatically receive new data (events, features and timeslices in AIXM 5.0 format)
  • an AIXM 5.0 Mapping allowing the application to export the database content into valid AIXM 5 XML files.

 

Main Concepts

AIXM Data Related Flow

 

Pulsar's Extranet and xNOTAM Specific Integration

 

Oracle Spatial and interactive Google Maps

  • Transparent overlays use polygons coming directly from the database
  • Data managed with JavaScript
  • Visual/interactive selection of RunwayElements and TaxywayElements on a map

  • 5 GB data export/import -> 8h/conversion scripts, 1h export, 3h import x all environments
  • Conversion of spatial data

-> database corruption : upscaling the server was necessary

-> Oracle doesn’t like virtual machines (VM Ware or ESX server), it become slow, we switched on a quadri-core/4GB physical server

  • No arcs & circles in geodetic coordinates system -> management by polygons: 1 circle realised with aprox. 1 000 points
  • Spatial GML not fully compliant with AIXM 5 GML -> translation procedures.

 

Main Functionalities

Airspace Restriction Template 

  • Allows encoding of new airspace restrictions, including their usage and timetables in one single step
  • Ability to encode multiple points at once to define an airspace (allows copy/paste from NOTAM Messages)

Temporality

  • Implemented according to Temporality Document
    • ‘Continuity’ (Feature) only contains immutable data: UUID
  • Identification not straightforward
    • Required information may be missing in delta timeslice
    • The natural key (human readable) evolves in time
    • Sometimes built on a parent’s natural key, also evolving in time
    • Runway Centreline Point is identified by
      • Associated Airport Heliport designator and name
      • Associated Runway Direction designator
      • Role

Temporality issues:

  • Dimensions of time: actual time (4th dimension) - modeled with START and END dates
  • Allows knowing since when the information on a particular event was available
  • Could be critical in historical investigations

Timeline, States and Snapshots 

Permanent Timeslices calculations are time consuming and processor intensive process; we created the States concept for better performances 

  • Stored in the same table as other timeslices (same « kind »)
  • Easier developments
  • May slow the search of timeslices
  • In average, 4 snapshots for 1 timeslice
  • Varies from 2:1 to 15:1 (the more over- lapping timeslices, the more snapshots)

 

Web Feature Service (WFS)
Geoserver v1.5.0 (GML 2.1.2)

  • Compatible with SkyView

Flattening AIXM5 to one level FeatureStates

  • Implemented as database views

Geometries calculation/aggregation

  • Bounding box queries require a spatial index
  • Materialized views
    • Updated on regular time interval (no real-time queries)
    • Geometries may become out of date between 2 updates
  • Triggers
    • Development time depends on the complexity of the feature.

 

Facts & Figures

AIXM Files and Database Size

  • Generated AIXM5 XML Files:
    • 35.600 files (email notification system and the reporting functionalities)
    • 110 MB of XML files
  • Production database:
    • Database size (tablespace total of the 3 main schema): 30 GB compressed
    • 58 GB of cached AIXM XML (events and timeslices)(length of extracted string with Select statements)
    • Including 18 GB from Session 1 timeslices
  • Project of 700 MD, 2 to 6 FTE (Full Time Equivalent), depending on project phase
  • Duration: 17 months, from July 2007 to December 2008
  • More than 135 screens
  • 5 databases instances & 7 separate environments
  • 21 Oracle Schemas to manage
  • 110.000 lines of code