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.
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.
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.
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:
- 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.
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:
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:
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.
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 Business Layer is also partially generated:
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.
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