Case Study: Building innovative route optimizing flight planning platform at Qantas

Author: Mike Riegler, Manager Business Innovation and Support Flight Operations, Qantas

Subscribe

Building innovative route optimizing flight planning platform

ABOUT QANTAS

Let’s start by introducing you to Qantas, which turns 100 in November 2020. Qantas group includes Jetstar, our low cost carrier (LCC), QantasLink, regional operations  and Qantas Mainline including international and domestic operations. The fleet currently stands at nearly 320 aircraft flying 180,000 flights a year and carrying 56 million passengers. That generates revenue of $17.9 billion against which, the cost of fuel alone is $3.8 billion. The solution covered in this article is currently only deployed in Qantas mainline but the intention is to expand that across the group as the solution evolves.

Qantas first embarked on the flight planning journey in 2010 by visiting all major global flight planning system vendors in order to better understand the state of play. We discovered that all systems had core route optimization algorithms that were conceived in the eighties. These systems used techniques that excluded results after great circle fuel and time estimations were made. For example, Qantas’s legacy mainframe system would only take four of the best answers through to the fuel and navigation calculation process meaning that optimal answers might have been excluded early in the process. A lot of systems were built tightly coupled to this algorithm and broader system design was influenced by this close integration. This made most systems difficult to change.

WHAT QANTAS WANTED TO ACHIEVE WITH FLIGHT PLANNING

The objective was to create a cutting-edge route optimization engine that would find the best route every time. The engine needed to model aircraft performance capabilities for specific aircraft tails and assess fuel and navigation constraints up front in the flight planning calculation process.

The new solution allows Qantas to protect and evolve our unique fuel policy: The Australian continent is separated from other major continents by thousands of miles of ocean, because of this, free flight capability is important. The advanced free flight algorithm allows Qantas to take advantage of favorable tail winds and avoid headwinds and therefore optimize fuel and payload uplift.

Qantas wanted the flight planning solution to be future-proofed; therefore we chose to adopt emerging data standards as part of the design. In 2010 Qantas engaged with ICAO and IATA to learn about emerging System Wide Information Management (SWIM) based data standards. What we saw was revolutionary; we wanted to adopt the concepts discussed in documents such as FFICE (Flight and Flow Information in a Collaborative Environment) as we saw that these concepts had the potential to deliver benefits for our organization. For an airline, data interoperability with Air Navigation Service Providers (ANSP) sets the foundations for automation thus enabling Trajectory Based Operations (TBO). As airspace rules become more complex and aviation traffic volumes continue to increase, we see efficient data management as key to reducing costs while maintaining high compliance and safety standards.

In designing the system, it was important that Qantas used off-the-shelf products where practical to take advantage of the community model that encourages product evolution. Our IT project management also wanted to adopt the latest cloud-based IT platforms to take advantage of features such as scalability and redundancy.

The system that emerged from this was implemented in October 2018. The Qantas Airbus A380 fleet was the first fleet to be dispatched with the new system. Over the course of eight months the remainder of the Qantas fleet was gradually rolled out, last fleet being the Boeing 737. The implementation started with long-haul because we knew we would encounter complex data problems that we wanted to solve for early in the process. We then deployed medium range operations, completing the deployment with the higher volume domestic operation. The higher volume operations were deployed with our automated Airport Suitability Module designed and built with our partners at Smart4Aviation. This module is the cornerstone to system automation, which we continue to build out and integrate to the S4A event management framework expanding the automation capabilities of the solution.

The decision to build rather than buy a flight planning system was a tough one for Qantas but following unsuccessful attempts to adapt off-the-shelf flight planning systems to the Qantas operation, the executive was finally convinced that building in-house was the best long-term investment decision for the business. We started very small, embarking on a six month proof of concept and, once the results had been proved positive, that enabled us to move forward and start the flight planning system replacement project. In the early days of the project, the business was inexperienced and somewhat naïve thinking that everything could be done in-house. However, Qantas lacked the project management discipline and soon learned the value of utilizing specialists in that field.

LESSONS LEARNED

There were some key lessons learned over the course of the project. We realized that there is a range of complex skills required to complete a project such as this – it’s necessary to understand the right team structure needed for the job. From program managers who manage up and keep the executive body engaged to project managers who build the plan and keep everyone honest in sticking to the plan as well as solution architects designing the solution and business analysts getting ‘into the weeds’ and understanding the detail of the problem. Test managers, testers, change managers and training managers all contributed a diverse set of skills to create a great team.

Another thing learned was that the team must evolve over the course of the project and that different disciplines have different focuses at various times. Early on, the solution architect, project manager, business analysts and the SMEs (subject matter experts) need to define the solution; later in the project, the communications and the change managers step up and help to implement the change. One constant throughout this project was that SMEs were always needed and were always working at full capacity – we always struggled with finding SME capacity.

When this diverse range of individuals comes together with the strong culture, great things can be achieved. One of the key human factors of the project has been resilience. We came across so many barriers; every week there was a major hurdle that we had to get around and the ability of the team to navigate through that was critical to the success of the project.

WHAT WAS ACHIEVED

The flight planning algorithm

Figure 1

We initially developed this (figure 1) with the Australian Centre for Field Robotics (ACFR) at Sydney University. The ACFR are path optimization specialists who helped automate mining operations in Western Australia, delivered automated straddle carriers for Australian shipping ports, and worked with the military and in the agricultural domain. Over a period of six months Qantas and the ACFR jointly developed a proof of concept route optimization engine. Probabilistic roadmap techniques and up-front consideration of performance, fuel and navigation constraints ensured that the algorithm considered all possible paths. Data is broken down to a set of nodes and costs are assigned to these nodes. Path search algorithms then plot optimum routing through these nodes at all possible weights solving for the search criteria specified.  

Cost, Fuel or speed analyses ensure that the best path is found based on the preconfigured set of inputs. The cost function is expandable and can be adapted to any set of costs that an airline can model, which is a challenge in itself.

Navigation constraints are modelled in the data; users do not drive the system, it’s a data driven solution. These principles form the foundation of automation.

The system can accept multiple requests for a flight plan and receive multiple answers. The ability to ask multiple questions of the optimizer and receive multiple responses enables our business to model all the different constraints for a sector and have the answers precomputed so that the dispatcher simply analyses the results.

The engine workers in the flight planning algorithm can scale up in a cloud environment when flight plan request loads require. So, in the mornings with peak domestic traffic, there can be more workers and then that can be scaled down in quieter times, optimizing capacity and cost.

FLIGHT PLANNING APPLICATION

Figure 2

The custom built flight planning application (figure 2) was designed and developed with our partner Smart4Aviation. The flight planning application is the user’s window to the flight planning algorithm: it controls all the inputs and the outputs both to the engine and to other modules in the solution. The solution combines existing Smart4Aviation applications; Smart BRIEF, Smart MET, Smart NOTAM MANAGER, Smart VIEW+ and Smart COMM with the bespoke flight planning application. The solution is highly configurable and adaptable. The solution allows Qantas to define engine inputs and outputs and can in fact be adapted to any engine.

As I’ve already mentioned, the Qantas group includes multiple airlines with multiple fuel policies. As previously mentioned we wanted to future proof the solution; in this context meaning the ability to plan multiple fuel policies. This is achieved through the configuration of inputs and outputs external to the engine. Inputs are abstracted from the flight planning engine, allowing for multiple airline configurations. The configuration framework allows an airline to manage their own fuel policy for different fleets, flights, sector and times of day as well as for different airlines.

The solution is designed for automation and exception handling: we want to ensure that flight plans are refreshed with timely operational data to ensure that the changing operational environment is reflected in all operational flight plans. Working with Smart4Aviation, Qantas has now built an extensive event management framework with event triggers based on time, receipt of data or changes in data impacting a flight. Event triggers that have been created include, new or changed Zero Fuel Weight, estimated departure time changes, atmospheric weather or GRIB data refreshes, TAFOR changes (Terminal Aerodrome Forecast) impacting an airport used in a flight plan, operational fuel requirement changes to what was originally planned. A new flight plan can be automatically generated when any of these events are received. The system automatically describes the event in the name of the new scenario, letting the user know why the new scenario was created. As a result, the dispatcher moves away from driving the system and configuring inputs to analyzing the output; more of an operational analyst rather than a flight planning system driver. The solution has a comprehensive airport suitability module which automatically reads Terminal Area Forecasts (TAFOR) messages and applies the configurable airline policies defining the operational restrictions for the flight plan. So, once again, the TAFOR is read and runway directions are automatically selected for departure and arrival. So, we’re getting very close to the concept of runway direction to runway direction flight planning.

Qantas calculates flight plans ten hours before departure so the crew can get an early indication of what their narrow route briefing package and the route of the day will look like. Similar to the flight object concept, this route and briefing package is refreshed closer to departure. The Flight Object concept discusses the creation of the flight object a long way out and then, as data gets more accurate closer to departure, you feed that data into the flight object and update the crew and dispatcher as required. This automated calculation is achieved through time-based event triggers.

We’re currently working on building the exception-based User interface. User interaction is very different in an automated flight planning system. There are benefits to be achieved if the optimizer can plan and choose the best flight plan. The concept of exception handling means that the user just needs to be alerted to exceptions or choices as they surface. If it’s a CAVOK (Cloud and Visibility OK) day and flight plans are being generated with no issues, they should just go through to the pilot without any intervention from the dispatcher. However, when there are weather or political issues that were not forecast, then user intervention may be required. We’re also working on integrating the Aircraft Situational Display (ASD) with the system so that we enhance the operational picture that is presented to the dispatcher. The concept of exception handling means that the dispatcher is not in the detail of flight plan production and therefore is not across all the detail in every flight plan; therefore the dispatcher needs the ability to step out and have a broader view of the operational environment that they are working in as well as dive into the detail when required. A graphical tool that overlays weather, navigation data and flight plan trajectories, gives them that situational awareness.

The Navigation database

Figure 3

The third component of the solution is the navigation database (figure 3). Once again, Qantas used off-the-shelf components which have been built out with airline specific requirements. The navigation database is supplied by our partner Frequentis, an Austrian company who also supply EuroControl with the EAD (European Aeronautical Database). From the Qantas perspective, this is our SWIM (System-Wide Information Management) hub; we’ve selected this consciously as we want to future proof the solution. We’ve seen the emerging standards and want to talk the same language as Air Traffic Control or ANSPs (Air Navigation Service Providers). In the Constellation solution we used the AIXM (Aeronautical Information Exchange Model) extensibility to cater for airline specific data features. Therefore, the solution is an AIXM based navigation database which was designed by ANSPs for ANSPs but extended for airlines. The data model was extended for the following airline features; company routes, custom airspace, runway direction minima, airport classification or usage, taxi fuel and time, arrival allowance and custom connections between route segments.

The AIXM data model includes an extensive temporality model that allows our business to model future constraints. For example, AIRAC (Aeronautical Information Regulation And Control) cycle changes can be planned on and operational impact assessed well in advance of effective date. NOTAM constraint linkage is another key improvement in the system. In the old legacy system, there was no linkage between a NOTAM and the underlying navigation data that it impacted. So, we’ve used the AIXM 5 event feature (designed for digital NOTAMs) to introduce this linkage. Basically, an xml tag is added on top of the raw ICAO NOTAM, which includes the impacted entity information and the effectivity of the NOTAM. When the NOTAM is sent across to the navigation database, this temporal information is then attached to the feature that is impacted by the NOTAM thereby automatically processing the temporality and creating the linkage between the NOTAM and underlying navigation data. This provides a key benefit when processing subsequent updates to that NOTAM transmitted as NOTAMR or NOTAMC. The subsequent updates come in and identify that the NOTAMs previously being applied to a feature in the navigation database and can automatically remove or update the constraint on that feature. When ANSPs or data originators start publishing NOTAMs in xml, something we’re all hoping for, these NOTAMs will be able to come through the Qantas system and automatically attach to the data constraints: once again, removing the human from driving the system and freeing them to concentrate on analyzing the results.

SWIM

I’ll just expand on the conversation regarding SWIM (System Wide Information Management). (figure 4). When Qantas started engaging with these concepts, we felt that it would revolutionize the way that we deal with data. Anyone who’s ever worked in a NOTAM office or a navigation back-end office will understand that it’s tedious work, pouring through reams and reams of technical data, trying to understand the meaning. What SWIM does, is allow airline data management systems to talk the same language as the ANSP data management systems allowing the system to interpret meaning and apply the intent. This interoperability delivers quality, which equates to safety; structure, which is the foundation for automation; global coverage and dynamic updates which ensures timelines of data.

Figure 4

The richness of the AIXM information exchange model is built based on AIP (Aeronautical Information Publications) information. Qantas’s current navigation data is supplied in an ARINC 424 text file. It’s nowhere near as rich as AIXM and is designed specifically for the purpose of flight planning. AIP information holds a range of other data that is also relevant to flight planning. Combining all this data into one, machine readable data model that can be exchanged directly with data originators, enables seamless data processing, delivering the benefits of data richness. This rich data set can then be delivered to the optimization engine to ensure the optimal route of the data is also compliant with navigation data constraints.

KEY ACHIEVEMENTS OF THE PROJECT

Figure 5

We have realized increased accuracy of our flight plans (figure 5) as a result of the rich data sets and improved modelling techniques. Fuel and flight time efficiencies are allowing ultra-long-haul operations and delivering cost benefits to the airline. Increased automation in the flight planning process and improved end user experience; as mentioned above, we’re changing the way in which they interact with the whole business of flight planning and to move from system drivers to become operational analysts. Systematic solutions guarantee optimum results every time.

PRACTICAL EXAMPLES

A couple of example use cases will help to illustrate how the new solution works for us.

Planning for temporality

Figure 6

Illustrated in figure 6 is the East coast of Australia with 14 hour flights coming down from the US West coast every day and every day we have special use airspace being actively turned on by NOTAMs for different times in the day. The temporality of the data allows us to set these activation times in the back end and the 4D trajectory optimization of the engine allows us to speed up or slow down and interact with these activation times and avoid the constrained area where possible. The picture on the left of the figure show a flight plan that was created without the 4D trajectory optimization which has built a route that goes around the constrained airspace. The picture on the right shows 4D optimization for a 14 hour flight which has slowed down or speeded up over the course of the flight to move through this airspace when the special use airspace is not active, therefore saving track miles and fuel.

A similar example, with route segments and airway constraints, can be seen in figure 7.

Figure 7

The airway branching off to the right is constrained; the picture on the left shows where 4D optimization is not applied, and that path or branch to the right isn’t considered in the flight planning process. In the picture on the right, the system speeds up or slows down the flight to open up routing options providing fuel saving opportunities.

Constellation Navigation Data

Figure 8

The final picture presents one of our more challenging flight planning problems and longest flights. The Perth to London sector, at 17 hours and 20 minutes presents a range of complex data problems. Departing from the West coast of Australia the flight plan can either go straight into free-flight airspace (the blue area) or, if the winds are pushing up from the South, the optimal route will be over Asia and remain within the constrained airway environment all the way to Europe. If the flight is pushed into the free-flight airspace the correct entry and exit gates are automatically selected by the system. This is because the entry and exit gates are form part of the free-flight airspace. Then there is the requirement to plan on defined direct connections in the Mali airspace. Directs are built into the data enabling the system to automatically comply with the ANSP constraints. Similar concepts can be used for European Flexible Use Airspace (FUA) with the data model temporality restricting the use to published times. All ANSPs publish pinch and catch points on the edge of free flight airspace and if that can, once again, be modelled in the data and exchanged directly with airline data management systems these constraints can be automatically ingested. At the moment we have to manually build these airspaces and update them when the state data changes.

In our legacy system, one dispatch shift was used to plan these two flights; Perth to London to Perth. Due to the system automation and data configuration these sectors are now less complex from a dispatcher perspective and can be dispersed amongst other flight plan allocations. We are working on enhancements now to allow users to model multiple answers so that sector variations can be created by the automation for the flight scenario. We want to model these differences so that the dispatcher doesn’t have to manually drive the system; the answer should be sitting there, already calculated.

The more options that we can define in the data means the more options that can be presented for the engine to solve. So, through 4D optimization, temporal constraints and through efficient data management, we want to open up, where possible, all the various options to the state-of-the-art optimization engine.

Continual optimization assessment is important on longer routes as time and weight information is updated. Qantas regularly re-optimizes in-flight in a process called DARPing and we’re currently building an automated DARP (Dynamic Airborne Reroute Procedure) capability. This enhancement will automatically re-optimize our long-haul flights using the latest weather, weight and time information. If a crew gets a flight plan an hour before departure, by the time when they actually depart the zero fuel weight and departure time could be slightly different. Any difference in weight or time means that the point in which the weather and aircraft performance data is integrated is different leading to a routing outcome. What we want to try and achieve is systematic DARPing once the aircraft gets to top of climb so that we have an accurate weight and time. The new information can then be uplinked to the crew, laterally, vertically and temporally re-optimized.

PROJECT SUNRISE

Figure 9

At Qantas we are looking to plan next generation aircraft to the edge of their endurance. Efficient data management is key to enabling this. Defining constraints in the data allows dispatchers to move away from driving the system which is critical for these ultra-long haul sectors. The dispatcher can be a third pair of eyes in the cockpit, providing enhanced support to crew members.

Qantas now has a cutting-edge route optimizer which enables better route optimization. Trajectory based operations supported by event triggers in the flight planning application means that the organization can be sure that the optimal route is always available and compliant with the operational environment constraints. When we create a flight plan, we don’t want it sitting there and becoming stale; as the external environment changes, we need to update that flight plan so that, at any point in time when you go to that flight, you can see the latest possible optimized and compliant result.

The solution will continue to be built out next year as we offer this new flight planning solution to the market. The automation platform will be tested and tuned by Qantas in the operational environment and expect it to be fully operational in mid-2020. ETOPS 330, statistical contingency and integrated situation awareness will also by rolled out by mid-2020. Beyond that the team will continue to build upon the SWIM foundations implementing the latest FIXM and IWXXM standards, advanced tankering, further ANSP system to system integration and graphical flight planning are some of the new features to be rolled out later in the year.

In 2020, we plan to formalize our partnership and actively begin to offer a complete flight planning solution to other airlines around the world. This will include the establishment of a data management service, flight planning optimization consultation and training services. This partnership will guide the product into the future setting an innovative strategy to allow airlines to optimize their flight operations.

We’re proud to be able to say that we have developed a state-of-the-art flight planning solution with our partners Smart4Aviation and Frequentis. The complex flight planning problem will continue to throw challenges at our organization bur we are confident that the Constellation solution will meet these challenges well into the future.  

Contributor’s Details

Michael Riegler

Michael has 30 years’ aviation industry experience. First as an air traffic control officer in the Royal Australian Air Force, then a variety of roles in a 22-year career working for Qantas, including Load Control, Flight Dispatch and Flight Dispatch Systems. Michael is now Manager Innovation and Support in Flight Operations overseeing the commissioning of the system and fleet roll out that culminated in the successful cutover of the final B737 fleet in June 2019.

Qantas

Qantas Airways Limited is the flag carrier of Australia and its largest airline by fleet size, international flights and international destinations. It is the third oldest airline in the world with a mixed fleet of Boeing 737, 747 and 787 and Airbus A330 and A380 types. Qantas is a founding member of the Oneworld airline alliance.