Flight Object - time for a rethink

Written by: Isabel Franke-Chaudet
Back to insights

Trajectory-based operation is the holy grail of tomorrow's ATM and is expected to transform flight management. Flight Object is the key enabler of the concept and as such it is one of the main pillars of global and European initiatives, such as ICAO, NextGen and SESAR.

Its primary objective is to enable interoperability, which is at the heart of smooth and seamless air traffic management. Currently ATM systems are developed in isolation, they are often "monolithic" systems built to national specifications, talking different languages and so struggle to understand each other. Even the use of common languages such as OLDI can result in varying interpretation by the different systems in use. This leads to technical as well as operational issues.

What is Flight Object?

Flight Object is the result of a data-centric approach to flight information management, not dissimilar to Aeronautical Information Management. The fundamental idea is based on a common "virtual" flight object containing all the relevant information about a flight, which is then shared amongst all stakeholders. The flight object is then updated with the latest information whilst the flight is in progress, thereby ensuring that all systems have the most up-to-date and consistent 'view' of the flight data. This enables enhanced coordination, situation awareness and collaborative decision making.

A short history of the concept

The concept has been in development since 2005 and a lot of money, energy and time has been invested by all involved parties. Efforts to harmonize flight information on a global scale are led by ICAO, with document 9965. It presents a concept for Flight and Flow Information for a Collaborative Environment (FF-ICE). It is complemented by the Flight Information eXchange Model (FIXM) to be implemented by 2025. FIXM describes data formats only, in the same way as AIXM for aeronautical data and WXXM for weather data. In Europe the ED-133 standard is at the centre of the development. The standard describes both data formats as well as protocols in contrast to the FIXM model. Global harmonisation is essential, with alignment between FIXM and ED-133 at its core, foreseeably enabled through a definition of ED-133 as an extension of the FIXM model. Development of both is thus interdependent, although alignment is still a work in progress.

In Europe there are two main initiatives working towards Flight Object solutions, the iTEC and Coflight collaborations, which are centred around Indra and Thales/Selex respectively. This means that ANSPs face a semi-monopolistic situation, with limited competing solutions. And ANSPs that have not joined any of the main collaborations, especially smaller ones that are not as involved in SESAR, fear being left behind and find that their choices are limited.

But even as the ATM system market is focussing more and more on two single suppliers, things are moving at a snail's pace and Flight Object remains out of reach. The concept is not mature and there is no common working solution. Commitment to the concept is still strong – stakeholders see the value of it, and with all the money and effort that has been invested it seems like a solution needs to be found. But as it is unclear how current hurdles can be overcome, the frustration is building, particularly amongst stakeholders who are not involved in the main initiatives.

What are the main issues Flight Object is facing?

Although both the iTEC and Coflight collaborations have been working on developing Flight Object solutions, the ED-133 standard is not mature and initial validations within SESAR have not been successful. This means that full concept validation, due to be undertaken as part of SESAR 2020, has had to be shifted and redefined and an update of the standard will not be available until late 2021 at the earliest, leaving very limited time for industrialisation.

This slow development also accentuates the issue ANSPs are facing with respect to supplier choice. The standard will only be available at a point where ANSPs will most likely already be locked in with a supplier due to the deployment mandate, further reducing the possibility for other suppliers to enter the market.

The problem at the heart of the issue is that the development of the standard was approached with a technical/systems view rather than an operational view. This bottom-up approach resulted in a set of requirements that was then interpreted in very different ways by the main suppliers involved. This means that we have now reached a point, not dissimilar to the other interoperability problems we see in systems today, where two different technical solutions struggle to talk to each other. This also gives rise to operational challenges as ANSPs will need to align their operational concepts to ensure Flight Object is successful. Given the differences in how ANSPs operate, the systems developed to accommodate their needs will differ, and seamless operation will be difficult.

Should we consider a new approach?

A new approach to Flight Object could consist of two dimensions, firstly lower the end objective and move toward a more pragmatic solution that provides most of the benefits in a shorter time frame. Secondly, approach the development of a Flight Object solution from a top down view, focussing initially on the operational concept and requirements of the users rather than technical systems.

This is not proposing to discard the Flight Object concept, but rather to rethink how we can solve the issues we are currently facing.

Let's look closer at what would be involved:

In parallel to the measures above it is important to develop standardisation and funding, encourage common requirements and increase operational harmonisation. We need to find ways to accelerate standards programmes and potentially fund the industrialisation of a key part of the architecture. We also need to further develop industrial partnerships (expansion of current ones, formation of new ones), with a particular focus on providing funding incentives to groups with common system requirements. And funding should be provided to groups focussed on common operational harmonization. This could include funding certain FAB activities but might be better focused on operational collaborations that are "like-minded" (for example, COOPANS).

By generating some 'quick wins' at the same time as increasing the resourcing of longer term solutions, the outcomes would be better for all.

Call us to discuss your next project: +44 1252 451 651

Contact us