7th December 2005, EUROCONTROL-EEC, Bretigny-Sur-Orge, France
White Box approach
for a Trajectory Prediction Tool
by Carlos Garcia Avello and Sip Swierstra, EUROCONTROL
Overview
The aircraft Trajectory Prediction tool (TP) is not an open source project, but it is a good example of a critical ATM element that could be shared. Sharing this tool would facilitate building a community around it. A community approach to development, validation, and verification could increase efficiency significantly. A White Box approach to the trajectory prediction tool will make the know-how applied and accumulated during the development process available to the ATM community.
A bit of background about trajectory prediction: TP is used practically everywhere in ATM systems. On the ground, it is used for preflight and real time flow management and for take off. When the aircraft is airborne, it is used in all flight data systems: for collision avoidance, guidance, and other flight tools. TP is used for multi-sector traffic, and for new tools dealing with planning and traffic separation. It is also used within airline operations centres for optimum city pair flight planning.
Future trends in ATM point toward trajectory-based ATM. Especially on the ground, the clients for this trajectory prediction have different requirements. Under the Common Trajectory Modelling Initiative, we've built a white box TP system which could be shown to clients, so that they use the white box requirements to determine the requirements for their final application they're building.
Currently, there are about 40 or 50 different systems on the ground, each with a different trajectory predictor. Airborne systems are limited by the few manufacturers who produce the systems, but there are different as well. The figures are probably even worse, since the trajectory predictor is quite often implemented within the application itself, so a single system running multiple applications can have several different TP implementations. This can lead to inconsistencies.
To address consistency, we still separate air systems from ground systems. But within the ground systems, the goal would be a single system, or at least consistent separate systems. Thus the same tool could be used both for planning and at the tactical level, and even for the new tools implementing trajectory-based ATM. However, as long as there are separate systems for air and ground, specific attention must address consistency between them.
We have attempted to define the generic structure of a trajectory predictor, in the air and on the ground. The input comes from a "flight script". This set of instructions is input into a software process, the TP engine, which interprets the script like a language. To actually compute the trajectory, it needs met data, aircraft performance data to be able to emulate the behaviour of the aircraft, and the TP function library. The output of the TP engine is a trajectory, which can be used as the input of other service routines. For example, a flight data processing system can use this as input to calculate when the aircraft will arrive in a given sector, and when it will exit.
One of the important issues we have identified is this flight script, which allows the trajectory prediction process to be decoupled from the application requirements. The script should not only specify what should be computed, but also how it should be computed. Depending on the application, various processing tradeoffs can be made. For example, for real-time flow management, many trajectories must be computed in a short period of time, for a long time in advance. However, lower accuracy is acceptable. In contrast, conflict probing requires higher accuracy. This is why a common aircraft intent description language needs to be developed, which can be used in the different applications.
The flight script must be capable of supporting different modes of operations. The new tools being developed have different needs. For example, in open loop applications, the trajectory is predicted, and the progress of the flight is compared to that prediction. On the other hand, in closed-loop systems, you apply a constraint to the trajectory prediction through the flight script interface, and run the TP until the constraint is met. You then generate advisories for the controller, to be followed in order to match the constraint.
From the white boxing process, we have identified components which could be open source. First off, the components including the preparation process, trajectory update process, and TP export process, as well as services, should be part of the proprietary application developed by the flight data processing vendor. By defining this intent description language, which can be the interface between the flight script and the trajectory engine, we have determined that the met library, TP function library, aircraft performance library and even the TP engine could be open source. This could offer large advantages in terms of interoperability.
The white boxing process started about 6 months ago. Currently, the aircraft and met functions are open sourced, and available as a library. We've also open sourced the API for decoupling the Aircraft Performance Model from the trajectory engine. The Aircraft Intent Description Language allows decoupling of the trajectory engine and the application.
We've developed a test harness to allow evaluation of multiple TP engines with the same reference data, validation strategy, and an agreed set of metrics. The major goal of this was to make the system understandable, and help other TP developers gather requirements. Thus, the client can test and determine that if they want a given level of accuracy at a given calculation speed, where they must put their TP engine development efforts, and what is the trade-off involved.
What are the benefits for us? By making one TP available publicly, we hope that will be a way of reaching the larger ATM community. Our emphasis remains improving interoperability, given the large number of different systems in Europe, and decreasing fragmentation, thus decreasing costs for the operators. Hopefully, as OSS, we will be able to benefit from improvements made by a wider community.
Some questions remain open. How can OSS in ATM systems improve efficiency, costs, and safety? Is OSS suitable for safety-critical applications? In the next 20 years, we hope to double air traffic. Humans alone will probably not be able to handle the increase, new tools are necessary. At that point, these tools will become safety-critical.
Discussion
from 16'30'' to 22'50'' (6'20'')
P. Johnson: Where can we download the trajectory predictor? >Paul>
C. Garcia Avello: It has not been released yet. But we would like to release it, not only as a TP engine, but as a test harness with a TP. >Carlos>
P. Johnson: Please "release often, release early"! If this development would become more transparent, that would be great!" >Paul>
M. Bourgois: This is probably one of the important lessons from today: it is important to release early, even if it's a risk for the quality image. >Marc>
F. Gasperoni: We seem to be very fragmented in terms of ATM here in Europe. What's the story in the US? >Franco>
C. Garcia Avello: They have a single system. The interest of the FAA participating in this TP study is that they are more worried about safety than about interoperability. They are dealing with the implementation of different tools and each of the tools has its own TP. If they have more than one tool in operation, the output of these tools could be at worst contradictory, and at least inconsistent, so they would be rejected by the controllers. >Carlos>
F. Gasperoni: In the US, is it a multi-supplier market? >Franco>
C. Garcia Avello: There's a main system (CTAS), but there is a multiplicity of tools from different vendors. The core system aims at being consistent, but on that system, the FAA wants to plug in tools for conflict detection or planning (for example EURET, recently implemented by Lockheed Martin). These tools can not use the TP embedded in the flight data processing system (FDPS), often because it's too simplistic. So they come with their own TP, and there's a possibility of inconsistencies in the output. >Carlos>
J. Feller: You have very solidly identified the most opportune parts of the system. If you think of this as a business and not just an operational flow, the value-added activities of ATM are flow planning and collision detection and avoidance. Therefore trajectory prediction, related languages and meta-functions are just utilities.
We can draw a parallel with the news media industry: there's a mark-up language called NEWSML initially developed internally by Reuters and adopted by the entire industry. Reuters footed the bill, not only for the language itself, but also to develop an open-source toolkit, which is similar to the engine that was just described. We can ask ourselves, why would an industry player do this? The news industry realized that to build value was not an internal issue but a network issue, and that they needed standardization to most effectively compete. Therefore they had to collaborate.
I see the same sort of process here: if we can agree on a data standard, on a processing standard, if we can exchange the utility software in a transparent manner, then vendors can go on adding value. It's a very hopeful endeavour. >Jo>
C. Garcia Avello: Yes, but we have to build a user community. Today, we have completely protected international IPR on software including the TP. There's no way, because of the IP rights, that you can make it work with a single TP. Without the strong community push, it will not happen. >Carlos>
J. O'Flaherty: When you say "we" do you mean EUROCONTROL or EUROCONTROL and the subcontractors? >John>
C. Garcia Avello: It's EUROCONTROL and the FAA, because this work has been done specifically on the AP16. >Carlos>
Salient points
- TP is used practically everywhere in ATM systems.
- Future trends in ATM point toward trajectory-based ATM.
- A single system running multiple applications can have several different TP implementations. This can lead to inconsistencies.
- A flight script allows the trajectory prediction process to be decoupled from the application requirements.
- The white boxing process has identified components which could be open source.
- We've developed a test harness to allow evaluation of multiple TP engines with the same reference data, validation strategy, and an agreed set of metrics.
- Our emphasis remains improving interoperability, given the large number of different systems in Europe, and decreasing fragmentation, thus decreasing costs for the operators.
- Parallels can be drawn with the industry-specific standards of the news media industry.
"Humans alone will probably not be able to handle increased air traffic, new tools are necessary. At that point, these tools will become safety-critical."
 |
 |
 |
 |
| abstract | slides | MP3 | OGG |