1. FPL2012 Message Conversion and Migration
SP/7 (Revised)
FPL2012 Message Conversion and Migration
AIDA-FPL
FPL 2012 Flight Plan Conversion

2. The new ICAO flight plan format is introduced world-wide
DOC 4444 – Amendment 1 – A global Issue
The new ICAO flight plan format is introduced world-wide
It will be distributed on international level
ANSPs in all ICAO Regions are involved
Due Date: November 15, According to ICAO State Letter AN 13/2.1-08/50, each ANSP is obliged to receive flight plans according to ICAO amendment 1 to DOC th Edition
Migration Phase April November During this phase the coexistence of the present and the new format is tolerated
In upcoming years airlines, air navigation service providers and military organisations will benefit from the improvements of the new flight plan. Until then, however, coordinating the transition from present to new format poses a tremendous challenge as the simultaneous transition of all flight plan processing systems worldwide is simply not a realistic scenario.
Therefore, ICAO defined a time frame in which the coexistence of both present and new format will be tolerated. But it stays realistic to assume that even after 15 November quite a number of flight plan processing systems won’t be running with the new format for eclectic reasons.
Not least, because the highly specialised systems comprise costly investments that should be protected. It should be avoided to replace these systems before end of their scheduled lifespan.
According to recent polls, by far not all affected organisations worldwide have made specific plans to transfer all their systems up to target date. Even if many central systems will be modified until the deadline it is likely that some subordinate systems won’t make the date for lack of time or budget.
Consequently, the transition will most likely not be completed after a few weeks but there will be an extended period of time in which users and systems will have to face two coexisting format types.
To sum up, we should be prepared for a co-existence of both formats. 2

3. The present and the new Format
Meaning of items/coding within the new flight plan has significantly changed
Items 7, 8, 10,13,15,16, 18 and 22 are concerned
Items 10 and 18 (and therefore 22) have experienced the most considerable changes
Present and new format are incompatible
During Migration Phase:
Conversion “New  Present” is required
On first sight the new and the present flight plan format appear to be as alike as two peas in a pod which is due to the fact that all flight plan fields actually stay unamended in Amendment 1.
However, the meaning of these items and their coding within the new flight plan will significantly change in comparison to the present format, making them incompatible with each other.
The revision of the format had primarily become necessary due to its lack of possibilities to express modern equipment and capabilities of aircraft.
Differences between both formats are widely spread throughout fields 7, 8, 10,13,15,16 and 18, however, field 10 and 18 have experienced the most considerable changes.

4. Conversion - New to Present Format
Conversion may not lead to a loss of data
ICAO has published guidelines for the conversion, which can be used by states (ICAO state letter AN 13/2.1-09/9)
Regions have developed regional guidance material:
EUR Region EUROCONTROL has provided specific guidelines (CFMU v1.43)
ASIA/PACIFIC Region
APANPIRG FPL&AM/TF has developed regional guidance material (Guidance Material v3)
In upcoming years airlines, air navigation service providers and military organisations will benefit from the improvements of the new flight plan. Until then, however, coordinating the transition from present to new format poses a tremendous challenge as the simultaneous transition of all flight plan processing systems worldwide is simply not a realistic scenario.
Therefore, ICAO defined a time frame in which the coexistence of both present and new format will be tolerated. But it stays realistic to assume that even after 15 November quite a number of flight plan processing systems won’t be running with the new format for eclectic reasons.
Not least, because the highly specialised systems comprise costly investments that should be protected. It should be avoided to replace these systems before end of their scheduled lifespan.
According to recent polls, by far not all affected organisations worldwide have made specific plans to transfer all their systems up to target date. Even if many central systems will be modified until the deadline it is likely that some subordinate systems won’t make the date for lack of time or budget.
Consequently, the transition will most likely not be completed after a few weeks but there will be an extended period of time in which users and systems will have to face two coexisting format types.
To sum up, we should be prepared for a co-existence of both formats. 4

5. The Standard - ICAO Migration Phase (< November 15th 2012)
The Triangle sign indicates where conversion is necessary in this scenario.
We need a converter from New to Present.
Otherwise they are misinterpreted or the respective system may experience a significant malfunction which is extremely critical to flight safety. 5

6. Potential Situation after November 15th 2012
In case systems sends flight plans in present format, these flight plans need to be also converted to ‘new’ in order to be interpreted correctly by other systems expecting to receive their flight plans in new format.
As of November 2012, systems do not necessarily need to be capable of accepting the present format; and, as a matter of fact, there are implementations of flight data processing systems on the market that exclusively master the new format.
There is a high risk that systems won’t be interoperable when new flight plans are used. 6

7. COMSOFT – Support of the Bidirectional Conversion
New F10a
New F18 J1 J3 J4 R
PBN/C1
PBN/C2
Present F10a
Present F18 J
DAT/V COM/J1
DAT/V COM/J3
DAT/V COM/J4 R
NAV/RNAV2 C1
NAV/RNAV2 C2
e.g. Asia/Pac. Specs.
COMSOFT
COMSOFT supports the conversion in both directions
Conversion Present to NEW is based on the information in field 18
J1, J3, J4, C1 and C2 are some of the new capabilities introduced by ICAO in the new format.
In its specifications for converting those capabilities to the present format, the ICAO Asia/Pacific Regional Office (and also CFMU) decided not to remove this new capabilities but to put them in a free text indicator of field 18 (in this example COM/ and NAV/), i.e. as additional information.
AIDA-FPL can make the conversion back to the new format by means of this additional information.
Today, an operator filing an FPL in the present format is not used to provide this additional information, so that the converter wouldn’t know how to convert the FPL to the new format.
As consequence, operators filing FPLs in the present format after November 2012 will have to get used to provide this additional information in order to make their FPLs convertible.

8. Special Case of the Conversion: Date of Flight (DOF)
New Format allows to file flight plans 5 days in advance
Present Format allows to file flight plans 24 hrs in advance
Some existing Flight Data Processing System implementations do not understand the „Date of Flight“ (DOF) feature
Risk of misinterpretation of the flight date
The converter has to delay Flight Plans with DOF set for those end systems that are not capable of the DOF feature.
A peculiarity when converting flight plans is the specification of Date of Flight (DOF) in the new format, which allows filing flight plans up to five days in advance.
Although this procedure has been common practice in various regions for quite some time, there are flight data processing systems that fail to interpret DOF and thus mistakenly expect the departure time to be within the next 24 hours.
Without its proper conversion this would lead to a fundamental misunderstanding regarding the DOF and made the respective flight plan worthless.
In case the DOF is set for any time later than one day in the future messages have to be stored temporarily after being converted from ‘new’ to ‘present’ and may be sent out at the earliest 24 hours before the actual departure time.

9. Special Case of the Conversion: Date of Flight (DOF)
New Format allows to file flight plans 5 days in advance
Present Format allows to file flight plans 24 hrs in advance
Some existing Flight Data Processing System implementations do not understand the „Date of Flight“ (DOF) feature
Risk of misinterpretation of the flight date
The converter has to delay Flight Plans with DOF set for those end systems that are not capable of the DOF feature.
A peculiarity when converting flight plans is the specification of Date of Flight (DOF) in the new format, which allows filing flight plans up to five days in advance.
Although this procedure has been common practice in various regions for quite some time, there are flight data processing systems that fail to interpret DOF and thus mistakenly expect the departure time to be within the next 24 hours.
Without its proper conversion this would lead to a fundamental misunderstanding regarding the DOF and made the respective flight plan worthless.
In case the DOF is set for any time later than one day in the future messages have to be stored temporarily after being converted from ‘new’ to ‘present’ and may be sent out at the earliest 24 hours before the actual departure time.

10. DOF Handling – On Hold Queue
In this approach, AIDA-FPL is a complementary conversion module of the main AFTN switch and interfaces to the main AFTN switch only. It converts the flight plans received by the main switch and returns the converted flight plans back to the main switch. In this case AIDA-FPL provides conversion services to the main system.
This layout allows that all systems remain directly connected to the main AFTN system.
Important Note: For this approach it is required that the routing algorithms of the main switch can perform a dedicated routeing for messages received from AIDA-FPL. The main AFTN switch has to route all messages bound to system which need FPL conversion to AIDA-FPL. However, messages which have been transformed by AIDA-FPL should be routed to appropriate circuits leading to the end systems. It is important to note that these mechanisms are not supported by many existing AFTN switches.

11. AIDA-NG FPL Conversion – Inconvertible Messages
In this approach, AIDA-FPL is a complementary conversion module of the main AFTN switch and interfaces to the main AFTN switch only. It converts the flight plans received by the main switch and returns the converted flight plans back to the main switch. In this case AIDA-FPL provides conversion services to the main system.
This layout allows that all systems remain directly connected to the main AFTN system.
Important Note: For this approach it is required that the routing algorithms of the main switch can perform a dedicated routeing for messages received from AIDA-FPL. The main AFTN switch has to route all messages bound to system which need FPL conversion to AIDA-FPL. However, messages which have been transformed by AIDA-FPL should be routed to appropriate circuits leading to the end systems. It is important to note that these mechanisms are not supported by many existing AFTN switches.

12. AIDA-NG Converter – Extended Conversion
In this approach, AIDA-FPL is a complementary conversion module of the main AFTN switch and interfaces to the main AFTN switch only. It converts the flight plans received by the main switch and returns the converted flight plans back to the main switch. In this case AIDA-FPL provides conversion services to the main system.
This layout allows that all systems remain directly connected to the main AFTN system.
Important Note: For this approach it is required that the routing algorithms of the main switch can perform a dedicated routeing for messages received from AIDA-FPL. The main AFTN switch has to route all messages bound to system which need FPL conversion to AIDA-FPL. However, messages which have been transformed by AIDA-FPL should be routed to appropriate circuits leading to the end systems. It is important to note that these mechanisms are not supported by many existing AFTN switches.

13. Management Framework
The AIDA-NG FPL Converter includes the outstanding features of COMSOFT’s Flagship Message Handling System AIDA-NG
Fully redundant system with shortest switchover times between operational and standby server (< 5 seconds)
Ultimate connectivity by LAN and WAN-based circuits (Async, TG, X.25, TCP/IP, FDE- ICD, FTMP, AIDC, OLDI, AFTN, AMHS )
Online configuration of all parameters
Flexible AFTN routing features allowing to integrate the system in any environment
Additional routing features for diverting or copying messages
High sophisticated event and alarm handling for all system elements (Hardware components, Circuits, Queues, conversion algorithm, etc.)
High sophisticated message queue management
Universal retrieval of incoming/outgoing messages using multiple filter criteria and direct tracing of the conversion
Configurable statistics
A peculiarity when converting flight plans is the specification of Date of Flight (DOF) in the new format, which allows filing flight plans up to five days in advance.
Although this procedure has been common practice in various regions for quite some time, there are flight data processing systems that fail to interpret DOF and thus mistakenly expect the departure time to be within the next 24 hours.
Without its proper conversion this would lead to a fundamental misunderstanding regarding the DOF and made the respective flight plan worthless.
In case the DOF is set for any time later than one day in the future messages have to be stored temporarily after being converted from ‘new’ to ‘present’ and may be sent out at the earliest 24 hours before the actual departure time.

14. AIDA-FPL: Summary CFMU Specifications V1.41
ASIA/PACIFIC Specifications V3
Conversion in both directions
Doc4444, ADEXP, AIDC (V2.0 and V3.0)
OLDI
DOF-Queue
Alarms + Inconvertible-Queue or Unchanged Forwarding
Full Management by high sophisticated operator working position
AIDA-FPL is compliant with last CFMU and Asia/Pacific specifications (the region for the conversion can be chosen based on the recipients/originators).
Conversion over OLDI protocols (FMTP and FDEICD).
When a message is queued because of its DOF, all messages associated to this flight are also queued.
When a message can’t be converted, an alarm can be displayed. The message can then be queued (intervention of an operator is necessary) or forwarded without change.
An error position displaying all necessary information (description of the error and associated messages) is provided to the operator so that he/she can correct it easily.
When a message can’t be converted, a SVC message can be sent back to the originator.

15. Now !! It is available COMSOFT AIDA-FPL – The Universal Converter
AIDA-FPL Flight Plan Converter
Mature solution applying elaborate algorithms for conversion and error handling mechanisms
Based on COMSOFT‘s extremely reliable aeronautical message handling technology
Support of regional implementations (CFMU V1.4.1, Asia/Pacific V3)
Conversion New to Present
Conversion Present to New
Support of DOF Buffering
Extended conversion functions (AIDC, OLDI, ADEXP)
Extensive testing and proof of concept with real-life test data
Now !!
It is available
COMSOFT has, at an early stage, identified the necessity for a powerful flight plan converter that not only provides a makeshift workaround for the impending transition but actually embodies a permanent and comfortable solution to cater for the coexistence of both formats.
Hence, the flight plan gateway AIDA-FPL was designed to apply elaborate algorithms for the automatic conversion with minimum manual intervention.
Particular attention was paid to suitable error handling mechanisms for the treatment of erroneous flight plans. On the one hand these algorithms require a certain degree of resistance to errors in flight plans to avoid extensive manual cleaning up. On the other hand errors in flight plans need to be identified in order to report to the system administrator and, if configured accordingly, to the originator to avoid their reoccurrence in subsequent flight plans.
That way the converter also contributes to an automatic quality control and thus is capable of constantly increasing the quality of flight plans.
To ensure the accuracy of the conversion algorithms the converter was 100 % counterchecked for conformance with ICAO’s conversion rules and was further scrutinised with a multitude of possible combinations of flight plan contents. To prove its stability under real circumstances, COMSOFT’s experienced engineers tested the converter with numerous randomly picked flight plans in present format.
As a final point, it turned out that exclusively such flight plans were not automatically converted that were particularly erroneous and therefore unusable for final processing anyway. 15

16. References AIDA-FPL Contracted/Converter Systems in the Field
United Arab Emirates
Egypt
Georgia
Trinidad/Tobago
Australia
Bosnia/Herzegowina
Morocco
Saudi Arabia
Singapore
Switzerland
France
Qatar
COMSOFT already has provided quite a number of FPL converters and also FPL Terminals and ATM Automation systems capable of both formats to customers over the world. 16

17. AIDA-FPL Deployment Options
AIDA-FPL is an integral part of COMSOFT’s AIDA-NG AFTN/AMHS System (for AIDA-NG-Customers)
AIDA-FPL inherits AIDA-NG‘s unrivalled maturity and connectivity options.
Alternatively, AIDA-FPL can be deployed as standalone front-end processing converter for one or several end systems.
AIDA-FPL can be deployed as a fully redundant or single solution
It is important to note that AIDA-FPL is implemented based on the universal Aeronautical Message Handling System and Gateway AIDA-NG.
AIDA-NG is used in more than 50 installations worldwide and has proved to be highly mature and reliable.
If an ANSP runs AIDA-NG as a central message switch the converter comes as a simple software upgrade of the system.
AIDA-FPL can be also a small gateway attached to the main switch or to an end system.
Of course, AIDA-FPL can be deployed in redundant or single mode.
VATM already operates the AIDA-NG in the AISS (AIDA-NG FEP in GLM, NB, DAN, TSN)

18. AIDA-NG Customers – SW Upgrade incl. FPL Conversion
In this approach, AIDA-FPL is a complementary conversion module of the main AFTN switch and interfaces to the main AFTN switch only. It converts the flight plans received by the main switch and returns the converted flight plans back to the main switch. In this case AIDA-FPL provides conversion services to the main system.
This layout allows that all systems remain directly connected to the main AFTN system.
Important Note: For this approach it is required that the routing algorithms of the main switch can perform a dedicated routeing for messages received from AIDA-FPL. The main AFTN switch has to route all messages bound to system which need FPL conversion to AIDA-FPL. However, messages which have been transformed by AIDA-FPL should be routed to appropriate circuits leading to the end systems. It is important to note that these mechanisms are not supported by many existing AFTN switches.

19. AIDA-FPL as Stand-Alone System – Intermediary System
In this concept AIDA-FPL acts as a converter for all connections to systems which need flight plan conversions to be performed. In this case AIDA-FPL is an intermediary system with sub-switch functionality.
The Main AFTN Switch routes all messages for addressees which need conversion towards AIDA-FPL. AIDA-FPL acts as a sub-switch and performs the routing towards the end systems. For each end system AIDA-FPL performs the appropriate conversion of Flight Plans.
The layout of AIDA-FPL as an intermediary system doesn't impose requirements for the routing capabilities of the main switch.
This approach works in all AFTN environments.

20. AIDA-FPL as Stand-Alone System – Minimized Impact
In this concept AIDA-FPL acts as a converter for all connections to systems which need flight plan conversions to be performed. In this case AIDA-FPL is an intermediary system with sub-switch functionality.
The Main AFTN Switch routes all messages for addressees which need conversion towards AIDA-FPL. AIDA-FPL acts as a sub-switch and performs the routing towards the end systems. For each end system AIDA-FPL performs the appropriate conversion of Flight Plans.
The layout of AIDA-FPL as an intermediary system doesn't impose requirements for the routing capabilities of the main switch.
This approach works in all AFTN environments.

22. If there any questions or queries please contact me
Your COMSOFT Resources.
Uwe Kurpat
If there any questions or queries please contact me 22