• 1

pulsar, pulsar consulting

smartAIM

In May 2011, Pulsar was called by Eurocontrol/EAD and Frequentis to participate to the creation of the European aeronautical database EAD AIXM 5.1. This project aimed at developing procedures to transfer and map data from the AIXM 4.5 database to the new AIXM 5.1 database inside a multitier MVC/SOA architecture. Pulsar’s participation to this project occupied 1 project manager, 1 analyst, 1 technical leader and 8 developers during 1 year.

Application Scope

The whole smartAIM project was aiming at implementing the AIXM 5.x schema in the EAD system, setting up a new SDD system, where SDD stands for Static and Dynamic Data Operation by opposition to the existing SDO.

Technology

One of the challenges for Pulsar was to work remotely in full integration with Frequentis IT environment, configuring documents and mails in Frequentis Lotus Notes database, using Frequentis Trac ticketing system and centralizing source code in Frequentis SVN repository. The code itself was part of a complete Java solution based on Eclipse, Eclipse Link, Maven, Java, Oracle spatial, JAXB. Hudson was used for automatic builds at each commit with reports on failing JUnit tests.

Project Objectives

The primary objectives for Pulsar included:

  • Analysis of the AIXM 5.1 temporality implementation in the frame of its correspondence/mapping with AIXM 4.5
  • Review of a graphical interface analysis for NOTAM management
  • Specifications of functions required for NOTAM integration in the new EAD architecture and database
  • Treatment of the AIXM 4.5 to AIXM 5.1 mapping for:
    • « AirportHeliport » and associated entities
    • « Navaid » and associated entities
    • « Route » and associated entities
  • This treatment included:
    • Analysis
    • Specifications
    • Implementation of the mapping between Java Database Objects (DBO) and Java Transfer Objects (DTO)
    • Implementation of the AIXM 4.5 to AIXM 5.1 mapping
    • Unit and Integration tests
    • Limitations analysis
    • Limitations solving 

 

Main concepts and terminology

The new SDD system aims at becoming the crossing edge of Aeronautical data.

pulsar, smartaim    

 

 

 

 

SDO (Static Data Operation): The system in place at EAD and maintained by Frequentis allows managing in AIXM 4.5 format the full set of aeronautical information data published in AIP:

  • Aerodrome information, including Procedures and Obstacles;
  • Enroute information such as Airspaces, Routes, Navaids and Waypoints;
  • General information such as Organization, Authority and Units.

 

SDD (Static and Dynamic Data): This is equivalent to SDO but in AIXM 5.1 format and including dynamic information such as NOTAMs.

AIXM 4.5: The Aeronautical Information Exchange Model (AIXM) is designed to enable the management and distribution of Aeronautical Information Services (AIS) data in digital format.

AIXM 5.1: This new version released in February 2010 brought the following enhancements:

  • An exhaustive temporality model, including support for the temporary information contained in NOTAM
  • Alignment with ISO standards for geospatial information, including the use of the Geography Markup Language (GML)
  • Support for the latest ICAO and user requirements for aeronautical data including obstacles, terminal procedures and airport mapping databases
  • Modularity and extensibility.
 

DTO (Data Transfer Object): design pattern used to transfer data between software application subsystems.

JAXB (Java Architecture for XML Binding): allows mapping Java classes to XML representations.

DBO (Database Object): The DBO mapping component is responsible to transform the Database Objects that are derived from the database to the SDD Domain Model and vice versa.

RDBMS (relational database management system): Oracle 11g.

 

General Architecture

The chosen architecture was to decouple the SDD implementation from the existing SDO system and to have a dedicated system interface for synchronisation between SDD and SDO.

Data maintenance is done only in the appropriate system. This means that AIXM 4.5 data is handled in SDO while AIXM 5.1 data is handled in SDD. This includes the HMI as well as uploads via ESI (EAD System Interface) and IFS (Internet File System).

To avoid any major change in the SDO system, all of the mapping between the systems was carried out as a module in the SDD system.

The project was mainly to allow, via this architecture, downloading SDO data from SDD HMI, after conversion from AIXM 4.5 to AIXM 5.1. The reverse was architecturally foreseen but not actually planned in the implementation.

 

General Architecture Flow

 

Since SDO data management was working in slots following a defined working flow, the SDD system needs to poll SDO database views to detect new commits of data slots.

 

Generated Data Layers

The SDD Data Layer contains two main components:

  • The relational database (Oracle 11g)
  • The Data Access Layer (DAL) which handles the access to the database via:
    • Object Relational Mapping (ORM) Framework;
    • Java Persistence API (JPA);
    • Data Access Objects (DAO) split into interface and implementation;
    • Java Database Objects (DBOs) generated from the XMI export of the AIXM UML, with some artifacts (base classes, notes, metadata, geometries) skipped and handcrafted. The substitution map is applied to avoid the Oracle identifier length problematic;
    • Database Tables/Structure generated out of the DBOs using Eclipse Link, with a post processing step to compensate some Eclipse Link limitations.
 

The Business Layer is also partially generated:

  • JAXB classes are generated from the AIXM 5.x XSD;
  • Java Domain Objects (DTOs) are generated from the XMI export of the AIXM UML, with some artifacts (base classes, notes, metadata, geometries) skipped and handcrafted;
  • The Mapping between JAXB classes and DTOs is generated from the XMI export of the AIXM UML;
  • TOAs (Transfer Object Assembler) between DTOs and DBOs could also have been generated but were not by lack of time.

 

The generator approach is used in a pragmatic way, not trying to get everything 100% generated, but doing some minor adjustments after generating, especially for the DBO annotations. Nothing that is related to AIXM extensions was generated because they are not fully modeled.

 

 

Calls between Packages

To have a better view of the content of each package, Pulsar built a flow diagram of the main calls between packages taking place around download and mapping processes.

 

 

  • Replication calls Synchronisation which calls 4.5-to-5.1 Mapping before storing data in the database via Temporality;
  • Replication also inform Scheduler about newly committed data;
  • Scheduler can start Download on newly committed data;
  • Download interrogates the database via Queries and DAO, before calling the dbo-dto Mapping, followed by the 5.1-JaxB Mapping;
  • When downloading pending data, the download module also requires the 4.5-to-5.1 mapping, via the synchronisation module.

 

Mapped Packages

Mapping types of AirportHeliport Package

Mapping types of Navaid Package

 

Dependencies in NavaidEquipment mapping

Mapping types of Route Package

 

RTE_SEG to ChangeOverPoint structure mapping

 

Procedure and ADQ compliancy

Pulsar needed to stick to procedures as defined by Frequentis:

  • Configuration Management (CM) providing the means for formal control of items (i.e. documents, correspondence, IT components, hardware, software, CRs etc). The selected CMDB was a Lotus Notes database that allows local replication of the CM data.
  • Configuration Items used by Pulsar during this project:
    • DOC : Word documents such as Contracts, Reports, Procedures, Plans, Proposals, Specifications, Technical Notes, Manuals, Standards, Templates.
    • COR: correspondence items such as Faxes (incoming and outgoing), Lists (if they need no version), Letters, E-mails
    • RID: Excel records for Review Item Discrepancy and Change Request
  • Naming and Versioning conventions
  • Document information mandatory fields
  • Guidelines for writing a document
  • Document status flow:

 

 

  • Quality Assurance (QA) Service providing a framework to deliver the EAD IT Service in accordance with the required quality standards, such as levels of performance and capacity.
    • Delays might lead to a decrease in the quality of the deliverables. Therefore, the activities shall be planned appropriately.
    • The deliverables shall meet the specified requirements.
    • Each problem (error) that has been identified (and is related to the product) shall be treated appropriately.
  • Quality Demand on each developer
    • Code Conventions for the Java™ Programming Language
    • Review his own results before transmitting them to someone else,
    • Make Technical Reviews of the deliverables,
    • Report problems that might pose a risk or increase the probability of a risk to the QM and PM.
  • Responsibilities spread among Roles: Change Control Board, Sub-system manager, Sub-system technical lead, Sub-system developer, Sub-system test manager, Sub-system quality manager, Sub-system software configuration, manager, Sub-system safety manager, Sub-system documentation engineer, Customer, System V&V, Head of development, System configuration manager.
  • Development Plan
    • The development process was organised into a staged pipeline of 2-months slots. Note that it was very difficult for Pulsar team to stick to the 2 months cycle, much too short for the defined tasks.

     

    • Test Phases
      • Planning: Tests have to be defined in written form and in an agreed format (e.g. test case/procedures, test scripts) and the inputs as well as the outputs have to be recorded.
      • Implementation & Component tests: Most detailed testing (manual or automated) to ensure the functionality of software components, including Unit Testing;
      • Sub-system Integration Tests: When these tests are successful, all components of a sub-system are combined and integrated into one sub-system. During the sub-system integration tests, the sub-system itself is verified (checked to see whether the sub-system has been built correctly);
      • Sub-system QT smoke Tests: The main purpose of this stage is to ensure that only stable and well tested software is deployed on the dedicated sub-system QT environment;
      • Sub-system QT dry-run: At this stage the sub-system is tested in an integrated environment against the requirements defined in the Change Proposals. Usually the test takes place in a dedicated test environment and is performed with specified test data;
      • Sub-system QT: The sub-system QT is a formal test run, in presence of th users, to prove that its delivery fulfils the defined requirements/acceptance criteria and that it can be integrated into the system so that System V&V can start.

 

  • Continuous Integration platform for centralized (nightly or triggered) build & quality test

 

  • TRAC tool was used for tracking enhancements, defects, and tasks