CASE STUDY: Air Caraïbes and French bee step up to the latest flight planning

Author: Justinien Lelion, OCC Flight Ops Engineer, Air Caraïbes

Subscribe

Justinien Lelion, OCC Flight Ops Engineer for Air Caraïbes shares the story of implementing a 5D Flight planning and flight management solution for automated cost driven route optimization

Before detailing our selection and implementation of a 5D Flight planning and flight management solution in Air Caraïbes and French bee, I’ll first briefly introduce myself and the airlines at the heart of this case study. I am part of French airline Air Caraïbes Flight Ops engineering department, specialized in OCC related questions, and, in recent years, I have been the Flightkeys project manager. We went live in November 2024 so it’s still a recent change. In this case study, I want to show you what were the main challenges, and how we carried out the project. But first of all, let me introduce you to the airlines (figures 1.1 and 1.2).

AIR CARAIBES AND FRENCHBEE

Figure 1.1

Figure 1.2

Air Caraïbes is a French airline founded in 2003 and based at Paris Orly. We fly Airbus A330s and a A350s and operate more than 3700 ETOPS flight a year. We fly to all the French islands in the Caribbean, including Guadeloupe and Martinique, but also Cancun or Dominican Republic. The other airline is French bee which is the sister company of Air Caraïbes, and was founded in 2016, also based at Paris Orly flying exclusively Airbus A350s and also an ETOPS operator. French bee mainly operates from Paris to the US, also to La Réunion, a small French Island next to Madagascar, and to Tahiti, with ETOPS 370 flights.

PROJECT TIMELINE

Looking now at the project timeline, you can see that there were some major milestones along the way (figure 2), starting with the kick-off, in September 2023.

Figure 2

During the period following the kick-off, we had to configure the system to set-up the databases, define and set-up the fuel policy – a major component for a flight planning system – and we had to define our IT architecture. There were a lot of things to do. In January we moved on to make the product environment ready; it didn’t mean that we could use the system, just that the system was ready to be used, but not 100% functional. Before UAT (User Acceptance Testing), which was in April 2024, we had to carry out training. Flightkeys first trained the Airlines’ internal trainers, and those trainers then trained all of the dispatchers and Flightkeys end-users.

We defined all the interfaces, because Flightkeys allows us to have a lot of interfaces with all of our third-party applications, and then it was time for the UAT. It was not only a dispatch test, but also interfaces and databases tests, leading to the approval phase, which was very important – and mandatory for being able to use the system in production; I’ll come back to that later. Summer, was a smoother phase, because we had the high peak season, but we still had to carry on with the project. It was during this period when we fine-tunned the global system, by doing some small changes and adjustments to our EFFs (Electronic Flight Folders) and our EFB (Electronic Flight Bag) applications. We also conducted some test flights; that was important because it was where we had first actual feedback. And then we moved, on the 28th of October, into the parallel-run for two weeks, where we dispatched 20% of our flights on Flightkeys. That was a major milestone, as for us, it was the opportunity to get a good idea of how Flightkeys works in production and to validate things like the architecture and the compliance with our approvals and our procedures. But also, one of the main priorities was to validate the fuel figures. As I said, this is a very important topic. So, if the computations are wrong, we would completely lose the benefit of a new flight planning system and to have live flight feedback, not just test flights but real prod flights, was very important. During that period, we were the very first operator to have operated a flight with an A350 dispatched on Flightkeys but also the very first ETOPS 370 flight computed by Flightkeys. We finally moved into fully production use on the 12th of November, after validation of the parallel-run phase.

OPERATIONS WITH FLIGHTKEYS

As readers will probably know, there are three main considerations that have to be taken into account when you dispatch flights (figure 3.1).

Figure 3.1

There is the weather optimization, the cost optimization and then there are the restrictions. If you just remove one of those circles, flight planning just becomes too easy, so that’s why Flightkeys is positioned right in the middle here, where it covers all three circles, the three main considerations, to ensure the most optimized flights possible.

Weather optimization

First, let’s look to the weather optimization (figure 3.2).

Figure 3.2

Flightkeys optimizes the flight depending on the turbulence areas, thunderstorms, and icing. It also takes into account EDR (Eddy Dissipation Rate), which is an indication of turbulences. Finally, the system performs a full winds optimization, so if, say you are flying over the Atlantic, the system can tell you that at two flight levels below, there are more favorable winds and it will cost you less money to fly at that level than at the current level. This is something very new for us, because our previous system never did that and it was something we were a bit disturbed about at the beginning, as I’ll explain further on.

Cost optimization

Then there is the cost optimization (figure 3.3).

Figure 3.3

To make it very simple. Flightkeys is based on this formula for a given flight. There is the total cost which corresponds to the cost of time multiplied by the flight time, plus the cost of fuel multiplied by the trip fuel needed and any other costs (e.g. overflying costs or leasing costs). The cost of time takes into account crew and maintenance costs, and for the fuel one, is the fuel prices you pay in each airport. All of this is computed to give you the most optimized cost index for a given flight. For each flight there is a specific cost index which means that today, the pilot might fly with cost index 120, then tomorrow 121 and the day after 110. It depends on the conditions. And then you have on the dispatch page, outlined in orange, all the data and, if you make multiple versions of a flight plan, it will give you the total cost of each flight and tell you if it’s the most efficient or not. This is very helpful when dispatching, to have an overview of what is the cost of the flight.

Restrictions

And then you have to deal with restrictions (figure 3.4).

Figure 3.4

There are two types of restrictions, company ones and non-company ones. Company restrictions include things like, what the company has been approved to do (such as fuel policy or ETOPS). Non-company restrictions include all the information published in AIPs (Aeronautical Information Publications), AICs (Aeronautical Information Circulars), NOTAMs, etc. Also, for operators in Europe, the CFMU (Central Flow Management Unit) status, as you can’t release the flight if it’s not CFMU valid. So, the Flightkeys system takes all of those restrictions into account and uses that information for flight planning.

Use cases

Let’s look at two use cases. First, a flight from Tahiti to San Francisco. As you can see in green on the screen, there is an ETOPS 180 flight: the operator is Air Caraïbes, which is not ETOPS 370 approved. In orange is the ETOPS 370 flight made by French bee which is approved. So, just by a simple computation, the system knows which operator is operating that flight and whether that operator can or cannot do that. This is very helpful, and it helps you, for example, for all alternate airports, to take into account which one is approved for a company and which is not. The other example is on Réunion Island flights. As French operators, we have many restrictions for flying over countries in the Middle East or Africa. The system by itself, is just computing a compliant route, by considering those restrictions, as you can see on the screen. With our previous system, we were limited to using company routes, which were not the most optimized choices, whereas with Flightkeys we now trust the system one hundred percent, and we let the system decide for a better optimization. For this use case, the system found a new route with ten minutes less flight time and almost one ton of fuel less than before.

Dispatch efficiency

While we’re looking at efficiency, there is also dispatch efficiency to consider (figure 4.1).

Figure 4.1

There, right in the center again, is Flightkeys but what I want to look at here are the systems that are around that center. On the left, and in blue, there is all of the input data. We decided when we made the architecture to have everything going to Flightkeys automatically, because it’s not the dispatcher’s job to do that. A system can do it very simply. Flightkeys allows us to have many APIs, which is very good. There is only the weight & balance data, which is just in development currently, but this is something we will send to Flightkeys automatically in the future. Also, the aircraft status is something we decided to keep manually because it is sensitive data. As an ETOPS operator, you can have an MEL (Minimum Equipment List) or CDL (Configuration Deviation List) that can downgrade your ETOPS capability, so you simply will not be able to perform the flight as you want to. That’s why we keep it, manual, because we want to have a cross check with all the data.

The system itself, computes a full route and airport suitability check, to confirm whether the route or the airports being used are suitable, based on the weather, your approvals, etc. to give a good idea of whether it’s good or not. It’s the same for the CFMU (Central Flow Management Unit) validation, it’s done by itself. At the end, the only manual task the dispatcher has is to file the ATC (Air Traffic Control) flight plan and publish the EFF with just two clicks on Flightkeys. So, it’s very efficient.

Just to give you an idea, here you have a flight on Flightkeys (figure 4.2).

Figure 4.2

Just by clicking a button, the user can have the CFMU status which here is in green, so everything is good. If it’s in red, there is a problem, and the system tells us what is the problem and proposes some alternatives to avoid the problem. From my experience, something like 99% of the flights are CFMU valid; so, this is very efficient on that side. On the other side, we have the airport suitability menu. For example, here we have airports used as ETOPS alternate, and we have everything which is analyzed by the system to know if the airport is suitable or not: the RFFS (Rescue and Fire Fighting Services) level, the runway length, ACN (Airport Classification Number), PCN (Pavement Classification Number), many data from the runway, but also from the weather. It will compare the actual weather with the minima we are approved to use.

If there is a NOTAM saying that there’s a runway closure, the system will automatically block that runway from using it, even for airport closure or a curfew, the system will analyze it for you, and it take it into account for the flight preparation.

Also, other parameters, such as target arrival time, can be factored into the company restrictions element of the optimizations, but we did not configure it because it was not so useful for us. Again, we are a small company, so if there is adjustment to do, we can do it manually, whereas in bigger airlines, it’s something that can be done through the solution.

PROJECT RETROSPECTIVE

Now let’s have a look to the top three challenges that we faced during that project (figure 5).

Figure 5

In third position was the system customization and fine tuning; Flightkeys have brought a very new philosophy compared with what we had before, something automatic and more self-controlled than what we had in the past. It was a bit disturbing at the beginning, to let the system do whatever it wants, but it was done well. It was very disturbing, and to customize everything sometimes took a lot of time but in the end, we reached it, which was good.

The second challenge I want to highlight is the compliance and approval requests, everything which is touching to the CAA (Civil Aviation Authority). That was a very big topic for us. We had to do 10 approval requests (5 per airline), which represents a large amount of time. However, again, at the end, we have managed it and that’s what matters.

The top challenge was the change management. Changing habits for dispatchers and pilots who have been using a system for 20 years is very hard. But it has turned out well because we now have a lot of reports from pilots, which drives day-to-day improvement. We also now have more flights than before, so we are able to continue improving the system every day.

CONCLUSION

Air Caraïbes and French bee are very new to Flightkeys, so we don’t yet have a lot of experience with it. But we have already checked a few data and those computations are much more accurate than it was previously the case. We also see that the fuel figures are quite accurate whereas before, as I said, it was not so. We trust the system, and we know that in the future release, for example, we will be able to apply cost for CO₂ emissions so you can reduce or adjust your cost index based on that, making the airline more efficient and greener. Our overall conclusion is that the Flightkeys system has brought us many good things and improvements in our daily flight operations (figure 6).

Figure 6

We now have a more accurate fuel figure computation which is very important and a higher degree of automation, which is very useful. The cost optimization philosophy is also something new to us but which, again, is very helpful. As mentioned earlier, the system will compute the most cost-efficient flight for a given day. Also, the routes and airport suitability checks are something that’s greatly appreciated by the dispatchers, as that used to take a lot of time and now the system just does it. If it’s green, that’s good, there is nothing alerting. We still have a few things to check because there is a human behind the process to validate everything, but that’s much quicker than before. And there is a system evolution every three or four months when there is a new release, a new version with new features. That is something that, as a customer, we really appreciate.

And if you have any specificities, Flightkeys will endeavor to address them; as I said, we are the first A350 and ETOPS 370 operator using Flightkeys. They listen to you, and that made the whole process quite easy to be honest. This is why we decided to choose Flightkeys, for all of those reasons, and we are very happy with it. If you are considering a similar project, then I hope that you’ll find it useful to refer to our experience as part of your own research.