CASE STUDY: Condor gets a better view of its fleet

Author: Patrick Frey, Fleet Chief Boeing, Condor

Subscribe

Patrick Frey, Fleet Chief Boeing at Condor shares the experience of implementing a new Aircraft Fleet View application into Condor

Before launching into the substance of this case study, implementation of Aircraft Fleet View into Condor’s operations, it might be useful to include a few words about the airline itself.

CONDOR

As Germany’s most popular leisure airline, Condor has been operating flights to the most beautiful holiday destinations since 1956. Every year, more than nine million guests fly from the eight largest airports in Germany and from Zurich in Switzerland to more than 90 destinations in Europe, Africa and the U.S. Even after the compulsory liquidation of the Thomas Cook Group plc in 2019, flight operations continue on a regular basis. Condor is released from joint liability for the accountabilities of the Thomas Cook Group with the aid of a protective shield procedure. In 2021, the investor Attestor Capital took over Condor and has launched a substantial transformation of the airline. The Boeing 767 long-haul range fleet is being replaced with 21 brand-new Airbus A330neo, following a complete fleet renewal of the short-medium haul fleet by Airbus A32Xneo. In fact, nearly every aspect of Condor is being transformed including the operations sector with all its flight relevant IT applications; hence the topic of this case study.

LEGACY PROCESSES USED TO ASSESS FLEET STATUS

We realized that we had to work on the challenge that Condor’s electronic flight bag (EFB) system relied on Windows. The entire operations system, our software, the tools we used had all been developed in-house or with an external partner. It made sense, when we went through the restructuring process in 2019, that we considered, before we continued on this path, to take a look at current industry standards and solutions. At that time, I was part of a small project team who went out to assess the market. We’d first had contact with CrossConsense where we were talking about an electronic Technical Log Book (eTLB) and that was when we first discovered their Aircraft Fleet View. We introduced it in Flight Operations as part of a small trial just to see if, instead of creating and printing out PDF versions of the aircraft status, it would make more sense to have a live view. In my former role as Boeing Technical Pilot, this particularly came in handy when supporting flight crews dealing with technical problems in-flight or on outstations, since the information was readily available.

As kick-off for this project, we decided to move to iOS for the EFB platform. The German national aviation authority requires that, whenever an aircraft is released, the technical status of that aircraft has to be checked in two ways: it has to be cross-checked at the aircraft and back at base. That requirement was implemented in our legacy system with a button that the pilot pushed to confirm that on his/her side, everything was ready to go, and the people in the back-office at Maintrol pushed another button also saying that, from their point of view, the aircraft was good to go. That function had to be reproduced in the new solution. However, instead of simply reproducing the legacy traffic light system, we thought about integrating the real aircraft status with the CAMO release and introducing a dialogue function with the pilot so that the Maintrol personnel in Frankfurt always have a clear and up-to-date picture of the current state of the aircraft.

Something else that is common in the leisure and tourism industry is seasonal dependency and the switching between summer and winter flight routes. This also comes with the challenge of working with numerous contracted maintenance partners. Thus, we have to rely on good communication between the crew and the staff on site as well as with our back office in Frankfurt, ensuring the continuous airworthiness of our aircraft. That was our requirement for the Aircraft Fleet View App. Pretty much, the raw version was there but we wanted to combine it with the CAMO and other functions.

THE BUSINESS CASE FOR CROSSCONSENSE FLEET VIEW

Again, the business case was as part of the entire EFB project. We presented the board with the entire roll-over to the electronic flight bag. It wasn’t a specific business case for CrossConsense but what we are doing now is replacing our former processes with Aircraft Fleet View. For example, the hold item list (HIL) and the status of the aircraft used to be a PDF print-out and is now a more live view. This brings the advantage of a better status overview of the respective aircraft before arriving at it. This is part of the entire rationale presented to the board with the focus on digitalization, reducing workload, speeding up turnaround processes and briefing processes, more information and therefore better decision making. The system having been live since 2022 and, at the time of writing, fully operational with no paper for six months, it already shows that there has been a huge improvement.

AIRCRAFT FLEET VIEW

Aircraft Fleet View gives an overview of the whole fleet (figure 1) …

… the aircraft and the overall status (figure 2).

From that, users can drill down to each aircraft’s status or hold item list (Figure 3) and even further to each individual deferred item with a lot of detail.

Then the part for pilots, CAMO release, is a function where a QR code can be scanned on the aircraft and which knows which aircraft the pilot is on: then the pilot accepts the aircraft which triggers the CAMO release request. There is also a web-based application, the CAMO pops up with the request ‘approve’ or ‘reject’ and then a push notification is sent to the mobile device. The pilot sees the result and, hopefully, is good to go.

ADDRESSING THE PAIN POINTS AT CONDOR

In the old system we had the hold item list printed out and in a PDF version. For the first stage using the new solution, we just reproduced that, calling the data from AMOS, and presenting it to the flight crew in a more interactive way and better designed format. The advantage in this was that, once an item was closed in AMOS, it didn’t appear on the hold item list; there is no lag between printing, upload time and download time; the system presents a live view (figure 4).

As Condor operates a lot at outstations, we need to give more information to the flight crew when it comes to technical defects, especially in the issue of history tracking. Our setting in AMOS is that the deferred items are always presented together with the history. In case of a defective Business Class seat where, when we tried it, it worked but on the next flight it didn’t work, it had to be checked whether a part was in stock or not which generated a lot of paper. Especially with our new A330neos we put a strong focus on customer experience and therefore look for even small details and defects when it comes to the cabin interior.

What we did was to make it configurable so that now there is just the title of the deferred items but not the entire history section displayed immediately. When a flight crew member wants to get more information on the issue, s/he just clicks on it and it pops open to give the history. Instead of going through multiple pages, we now just see the defect title, the overview and, if we want to have more details on the item, we can click on it. This helps our crews to focus on the important items and taking decisions.

In the first month after introducing the App, we had three cases where flight crew noted that an item was going to be overdue during their rotation so we were able to initiate maintenance (figure 5), and repair the item before the aircraft went on another rotation simply because it was highlighted in color.  This has significantly reduced the pilots’ workload.

PROCESSES

Because we were involved in the App development with CrossConsense, we were able to define and explain our processes and the application pretty much continues to follow the same processes that we used before. We made some improvements but critically it didn’t require any new login credentials (figure 6).

That had been a learning from the past to make sure only one password is needed for the applications. We decided to work with Microsoft Azure AD (Active Directory) using our standard company login credentials. We introduced the new application in the new EFB environment plus user management was also done with the Azure AD which really made implementation smooth.

We always had the required procedure of the pilots asking for release (see above), the pilot had to open the application, push a button, ask for release and wait for the CAMO response. Once that was green, the aircraft was good to go and leave the gate. The process we have introduced now has been designed as a closed loop: after landing, the pilot is asked to give a condition statement for the aircraft; the flight is terminated and closed with or without a complaint filed depending on the status. So, when clicking on the aircraft, the complaint pops up at the back-office screen of the CAMO with a nice tiled version (figure 7).

A yellow tile indicates that the aircraft needs attention and someone has to be dispatched to the aircraft to look at the flight logbook.

Furthermore, there are two different types of actions that can be performed on an aircraft; one is an operational procedure which can be done by the flight crew and the other is one that will be carried out by maintenance staff. If there is a defect at the aircraft, it is an option to dispatch the aircraft on our own if no maintenance actions are required. In the past, this had to be entered into the technical logbook of the aircraft first.

This caused two pain points; one was workload and the second thing was the number of repetitive entries made it more difficult to get to the more important entries like a defect in the past two days that you want to look at. So, we started off with a basic traffic light system for the pilot. Now with the Aircraft Fleet Overview, we introduced a release statement. In the beginning it was nearly the same, the pilot got onto the aircraft and pushed the button. We have now changed it for a customizable version, for which Condor chose its own wording, and we now have the option to tailor this statement made by the pilot in command. This is also in line with the requested procedures and documentation processes by the national aviation authority.

This gave us the opportunity to get rid of the paper entries for operating procedures performed by crews. It meant an improved workload and awareness of the really important stuff instead of just repeating things over and over again. Also, the configurable statement can be changed and, in our next steps, we will be implementing an electronic technical logbook and will change paperwork and processes.

So, when we close the flight now, there’s an information bulletin on which the pilot clicks, that means closing the flight with a technical complaint; it also shows the correct way to do it. At the moment, there is a small table displayed and the pilot sees that s/he has to enter particular rows and columns. We have a way to always configure this page according to our current processes. The handling is intuitive and provides the user with assistance where necessary taking them back to the manual or back to a particular publication when changes have been made.

IMPLEMENTATION TIMELINE AND WHO WAS INVOLVED

The implementation, planning to go-live, took us around six months. Before the implementation, it was necessary to have the entire system presented to the national aviation authority and to get the respective certification of the EFB. That’s why we had to move quite quickly as our goal was to implement the new tool and processes including all approvals within ten months – which was an ambitious target.

WORKING WITH CROSSCONSENSE

For me, it was the first time that I had worked on such a project. Normally, you just select the software and agree to it. When we first met with CrossConsense, we explained our thoughts and ideas for what we wanted to achieve. At our first meeting in our headquarter with Flight Operations and CAMO, CrossConsense showed us the idea of the flow, and we immediately got the feeling that we were in good hands especially due to the background with the CrossConsense electronic technical log. Although we faced challenges due to lack of developer availabilities the application was available for the EFB only six months later meeting all our expectations. Importantly, the good cooperation with CrossConsense, who were always available for any kind of questions and issues any time, was highly appreciated.

USER EXPERIENCE WITH AIRCRAFT FLEET VIEW

The feedback is quite positive with people across the business saying how they can easily access the aircraft’s status and the release works well (figure 8).

While we are still at an early stage of using the Aircraft Fleet View, the most measurable result that we have gained is in removing paper processes and replacing them by digital processes, for example with the operating procedures and the MEL, and also with ending the necessity to print or create PDF files. We still have them in play to issue a ‘new hold items’ list every twenty minutes but we will soon get rid of that and produce one when the flight plan is created and then completely rely on the digital hold item list.

REGULATORS

The regulator required us to get Type A applications; we had to present the application but we didn’t have to certify it on the EFB approval process. The regulatory approval we had to gain was from the maintenance section of the national aviation authority for the CAMO aspect. We also had to do some show and tell but once they saw the closed loop system and the fallback system, we got approval right away.

It would have been nice to have had more time for dry runs but we had to move fast. We underestimated that people rely heavily on colors and pop-up messages to distinguish important messages from unimportant ones. And small issues; if you were in the project, you knew where it was going and the idea behind it but you have to include more people from various parts of the company to avoid problems during live operation.

LOOKING TO THE FUTURE

From our side, the next step will be to make it part of our approved technical logbook system. Right now, if you close the flight in the system, you always have to enter, in the aircraft acceptance sheet currently certified by Condor, ‘yes, I have entered technical defect’ or ‘no, there was no defect’. Next step would be to replace it by the condition statement post-flight, that is done by the flight crew.

I hope that this has been useful for anyone considering embarking on a similar project.

Contributors’ Details

Patrick Frey

Patrick joined the aviation sector in 2007 with GAS German Aviation Service as a Ramp Agent, progressing in 2011 to IT-System. In 2018, he joined Condor as Technical Pilot, Boeing Fleet where his responsibilities included special projects within flight operations or CAMO with a strong focus on digital transformation, and then as Fleet Chief Operations in 2021. Since October 2022, Patrick has been Fleet Chief Boeing at Condor. In February 2022, Patrick gained his EASA Air Ops Training Certification.

Condor

As Germany’s most popular leisure airline, Condor has been taking its guests to the world’s most beautiful holiday destinations for over 66 years. Every year, more than nine million guests fly with Condor from the nine largest airports in Germany and from Zurich in Switzerland to around 90 destinations in Europe, Africa and America. Condor operates a fleet of over 50 aircraft, which are maintained by the company’s own maintenance operation Condor Technik GmbH.

CrossConsense

CrossConsense’s portfolio runs from AMOS Support, BI-Management, Data Migration and Hosting to the products Aircraft Fleet View, ACSIS and AviationDW. As a wholly owned subsidiary of Canadian’s FLYHT Aerospace Solutions Ltd., CrossConsense also offers solutions for Fuel Management, Turn Process Management and other software applications as well as AFIRS hardware that collects data during flight.