CASE STUDY: Transforming repetitive defect detection at TUI Airline with Artificial Intelligence

Author: Niklas Kropp, Head of Business Development & Fleet Performance, TUI Airline and Dr. Jan Philipp Graesch, Product Lead Reliability Suite, AVIATAR, Lufthansa Technik

Subscribe

Niklas Kropp, Head of Business & Fleet Performance at TUI Airline and Dr. Jan Philipp Graesch, Product Lead Reliability Suite, AVIATAR at Lufthansa Technik, recall how TUI Airline is driving digital transformation by exploring GenAI to improve the technical reliability of its fleet.

Niklas Kropp

Operating a fleet of more than 125 medium- and long-haul aircraft, TUI Airline is working closely with Lufthansa Technik’s Digital Tech Ops Ecosystem partners, AMOS, flydocs and AVIATAR, to take advantage of the newest digital technologies. Being part of TUI Group, a leading global tourism company headquartered in Germany, TUI offers integrated travel services, including over 400 hotels, 18 cruise ships and five airlines with home bases in the United Kingdom, the Nordics, Belgium, the Netherlands and Germany.

The technical reliability of its fleet is key to TUI Airline, operating a large Boeing fleet with 787-8/9, 737-800 and 737-8 as well as the Embraer E195-E2 as you can see in figure 1.

Figure 1

In its partnership with AVIATAR, TUI is co-creating the new solution, Technical Repetitives Examination, called T.REX, to enable the targeted analysis of technical logbook write-ups through a combination of Artificial Intelligence (AI) with the engineering knowledge of Lufthansa Technik and, most importantly, the experience of TUI Airline’s European engineering team. As a key driver within the AVIATAR Customer Community, TUI Airline is working with more than 20 airlines and the AVIATAR team of digital engineers, developers and data-scientists to continuously improve T.REX for various Airbus and Boeing aircraft types

TUI Airline’s Engineering & Maintenance team, with its long-term operational experience, is a key co-creation partner for AVIATAR. The smart combination of human and artificial intelligence will be a critical success factor for TUI’s fleet performance in the future. A continuous evolvement of digitizing TUI’s operation enables pro-active and predictive decision-making to safeguard on-time performance.

THE JOURNEY WITH AVIATAR

TUI Airline’s journey with AVIATAR started with Swiss-AS, a key partner for our digital transformation roadmap and in Lufthansa Technik’s Digital Tech Ops Ecosystem. The implementation of Swiss-AS’ AMOS in 2009 is the foundation for the digitalization of our maintenance and engineering data, which is required to perform data analytics with AVIATAR. The whole journey is described in Aircraft IT MRO Issue 57: Autumn 2023.

Our partnership with AVIATAR started around 2020 with an ideation process and we introduced the first solutions in 2022. Since then, TUI has been shaping various product solutions and is pioneering digital operations. From the beginning, the AVIATAR team has been very customer centric and listened to us and other Boeing and Airbus operators in the AVIATAR Community. The outcome is remarkable and it’s great to see how our engineering team is enjoying the opportunity to co-create and use AVIATAR applications. We are using the Predictive Health Analytics suite of AVIATAR across all fleets and, in 2024, we kicked off the T.REX suite, which we discuss in this article, and selected the AVIATAR Technical Logbook for our entire fleet. Our journey with AVIATAR is shown in figure 2 and the picture at bottom right shows the Digital Tech Ops Customer Community. Together with other operators using digital solutions of AVIATAR and the Ecosystem, we regularly meet up to discuss the operator challenges with the developers, engineers and data-scientists to prioritize product roadmaps.

Figure 2

Building on the partnership with the Digital Tech Ops Ecosystem we have already digitized about 80 percent of our technical operations with AVIATAR and the Digital Tech Ops Ecosystem. Now it’s more about those final 20 percent, what we can get out of our aircraft data and, even more, what we can get out of semi-structured data; our manuals, the text data we have in work orders and so on. Figure 3 offers a glimpse of the feedback we get out of our engineering maintenance community within TUI.

Building on the exciting progress we have made so far with the digitalization of tech ops, our engineering team is keen to reach the 100% goal. With the introduction of the AVIATAR electronic Technical Logbook (eTLB), we are replacing the paper-based process of capturing technical issues and simplifying the communication between cockpit crew and maintenance staff. Another big topic is getting a better grip on repetitive items. You want to make sure to understand them quickly, eliminate the problem and, finally, effectively fix the issue also from a CAMO perspective. A challenge we have within TUI, and I think we share this with other operators as well, is that fleet composition is not always homogeneous in the sense that we operate both e-enabled aircraft and legacy models requiring different management approaches to optimize operations, as you can see in figure 3.

Figure 3

For e-enabled aircraft we are not limited to only using semi-structured data; we can utilize the aircraft data, the fault messages we get from the aircraft. Within TUI, we have also made sure that, from an infrastructure point of view, we are able to retrieve the data, centralize it in the back end and then use it for those purposes and applications within AVIATAR, to make them available in a user-friendly way.

Using data to improve maintenance planning

This all links into a philosophy we’ve developed within TUI, when we said that we need to make more use of our data for our engineering teams; there’s also a sound commercial reason behind it. When we looked at the costs of our maintenance, we saw, an industry wide issue, that those costs escalate more than inflation. So, if you do not get on top of them, that could create a challenge for your operation at some point. Hence, we want to get ahead of the curve, plan our maintenance and turn unscheduled events into scheduled events by using digital solutions.

T.REX expands the scope of the AVIATAR Reliability Suite launched last year. The new AVIATAR solution is to make recurring defects (so-called repetitives) within an aircraft’s technical logbook write-up more transparent and easier to monitor. In the past, the required transparency was often affected by various factors compromising the quality of the logbook entries. These are usually created manually and in free text fields, and hence often suffer from misspellings, or different languages, or incorrect assignments to the individual technical system groups (so-called ATA chapters). An AI-based solution will significantly relieve our maintenance control center and engineering department of a very time-consuming task, while at the same time enabling them to perform maintenance activities more efficiently. Thus, it fits perfectly into the existing product portfolio of the Digital Tech Ops Ecosystem.

Within TUI, we outlined four strategic building blocks. It’s not only about predictive maintenance; that might be the current buzzword, but we need to consider the full maintenance cycle. In figure 4, you can see how we’ve put this into practice together with AVIATAR.

Figure 4

The first block in figure 4 is reactive maintenance, fixing it when something has broken down. We focused on getting full flight data available and accessible to our engineering & maintenance team in the MCC (Maintenance Control Center), predominantly for them to be faster with troubleshooting, because in those instances speed is key. With AVIATAR’s Full Flight Data Viewer the team has a user-friendly environment to do that. Moving on, we want to quickly understand what has happened and what we need to do. Proactive maintenance (second block) is more what people understand about health monitoring nowadays, to understand when potentially something could happen and how could we prepare ourselves to fix it before it escalates. That’s what we do with AVIATAR’s Condition Monitoring and Event Analytics. When we then jump into the predictive maintenance sphere, we try to combine all the best of the previous two and add our Predictive Health Analytics use cases on it to tell us when it will break.

We have a team of key users who constantly, together with AVIATAR and the AVIATAR Community, look at our main delay drivers and, based on them, jointly create additional predictive use cases if required. We don’t do it the other way around. We’re driven from our main delay drivers. The final block is prescriptive maintenance where we use data not only to predict failures but also to tell us how to fix them proactively before they become a problem.

The above building blocks drive further strategic conversations among the TUI team with its partners. Questions like: How do we fix an issue in the end? Does the fix turn into a modification of a part? Do we undertake a modification campaign within our fleet or the global fleet? And how do we also measure the effectiveness of a fix we have put in place for a predictive maintenance use case? All these questions are discussed with AVIATAR and Lufthansa Technik engineers in order to develop methods and digital solutions to introduce more and more prescriptive maintenance tasks.

Repetitive items

At the same time, AVIATAR approached us with an idea of what to do about repetitive defects and to gain more insight into that. And there was a question of how to utilize those semi structured data, especially in our 737NG fleet; it is very important to us to get ahead of this. So, we worked with AVIATAR to develop a use case for our Boeing 737 fleet where we try to model and create new insights from the data, find the mechanism, and then also, hopefully, go back to our idea of trying to get everything into one system for our engineers. That’s one AVIATAR view where our engineers can, in the end, experience the full journey from reactive maintenance all the way to getting the data into the system for prescriptive maintenance, when utilizing different modules of AVIATAR, each with a different focus and specific to a role in the engineering process, but still as a One-Stop-Shop solution. We have five AOCs and that’s complex enough. On the IT side we need to make sure that we consolidate as much as possible.

Dr. Jan Philipp Graesch

WHAT TUI AIRLINE AND AVIATAR HAVE DONE

Regarding the use case and following what Niklas has outlined, there are already some great tools and solutions on AVIATAR; also, for structured data, like aircraft messages, we have Condition Monitoring for aircraft data, which is used by many operators around the world. We already have those solutions, but we now look at that semi structured data, as we call it. They are, for example, write-ups like Pilot Reports (PIREPs), Maintenance Reports (MAREPs), Cabin Reports and more. We would also like to integrate other engineering notes, because there’s a lot of knowledge in this semi structured data, which the airline needs to retrieve. We started with write-ups and decided on the name Technical Repetitives Examination, in short we call this application T.REX. With T.REX we analyze those write-ups, but they can contain spelling mistakes, different languages, i.e. if you’re at an out station, there might be a Spanish word or in Germany a German word in between.

There are several tools you might use to analyze these write-ups. You might use Excel; always the second-best solution. You might write an email to your station or to your engineering division containing these write-ups. You might have a solution like Tableau or something else in place, where you can do analytics. We’ve even seen engineering departments just write the write-up on a Post-it note and hand it over to the engineer. The MCC and the engineering department are facing a time-consuming task with those spelling mistakes and incorrect ATA chapter assignments.

For example, the root cause might be in a different ATA chapter or the cockpit crew simply didn’t know what is the correct one and just wrote something down. Furthermore, scheduled maintenance is usually ATA chapter 05. Thus, the problem is that it’s never certain whether all the write-ups have been collected. Some may have been overlooked due to a spelling mistake or an incorrectly assigned ATA chapter. That is why we put a lot of knowledge into those write-ups, as a good foundation for a repetitive item tool.

We decided for a large language model (LLM) as well as adding algorithmic models, with our AVIATAR engineering team on top of it. At the beginning, we looked for the data processing.

Figure 5

The large language model translates everything into English. In addition, we used another model on top of it to exclude non-defect servicing tasks, because we only want to look at defects, not something like oil fill-up etc.

AVIATAR worked together with TUI Airline as you can see in figure 6 to bring T.REX to life.

Figure 6

An aircraft specific model for the Boeing 737 and 787 fleets was used and we trained it with a lot of knowledge such as labeling ATA chapter concrete components and systems in these write-ups. We then enabled the algorithm to correct also those ATA chapters where appropriate. And together with TUI Airline, we established a harmonized list of specified components’ names, because there are often several names for the same item. If you write ‘beverage maker’, ‘coffee maker’, ‘espresso maker’, ‘espresso machine’ on your write-up – while it’s all correct – ideally you want to have one single term for it, because otherwise all your filters don’t work. For that we formulated some harmonized wording. For example, in figure 7, ‘light’ and ‘lamp’.

Figure 7

When it comes to a solution for repetitive defects, the only thing we still need is a visualization, the possibility to define clusters on top of that and then have customized rules. We found that a big USP for AVIATAR is that we allow users to set up rules like ‘what does repetitive mean?’ Because there are maybe departments in airlines looking at long term repetitives that you might want to look at in 30 days interval, while the MCC is looking on a shorter time frame. In short, what the write-up already contains, is of course the written defect record, the ATA chapter as well as the station. What we extract now with our algorithms is what we call an AI ATA chapter (a corrected one) and the component name from the write-ups, the location, which we haven’t yet implemented but working on it. For example, for cabin items the location will be very relevant, e.g. on seat 23F. Or if you look at an engine, it was engine one or engine two… so the location will make a difference when it comes to repetitive. However, we put more knowledge into that, because during troubleshooting you might swap components locations to fix problems. We also extract the defect and the defect description in a harmonized way, because the coffee maker can have a broken jar, power outage, spill over, leakage or other. There can be different defects, and we want to enable the user to cluster the defects in the way they want.

So, how does it look on the front end? Figure 8 gives an illustration.

Figure 8

We deployed our first version at the beginning of 2025 for Airbus aircraft, and now, after adding the Boeings into it, we are streamlining the front end and the usability together with TUI and the AVIATAR community. You can select the time frame and your fleet and then you can use several filters. Those filters already contain the harmonized wording and common abbreviations; if you type in ‘fmgc’, you find the ‘flight management computer’ etc. This is what the filter can do already. In the top right corner, you can define what ‘repetitive’ means for you; as a default, we have three defects in ten days.

Thus, every line displayed would be an examination of a possible repetitive item, for one particular aircraft for the same four-digit ATA chapter, you will find how often this defect happened based on your write-ups from your logbook. And then, when you click on the ‘Repetitive Defect’ line, you will see all those write-ups. You find the component name extracted from it, the defect type and the link into your maintenance system – in this case into AMOS – to directly open your work order. You find the original ATA chapter and you also find our suggestion of a corrected one, which we call AI ATA.

In this example, the description was in Portuguese, also to show you it can deal with any language. This is how the application looks like. What you now can do is save this as a repetitive, bring it on a repetitive page and then monitor this and manage your repetitive section.

What we have also introduced is a way to analyze your write-ups for the entire fleet using charts and visualizations. Since we’ve structured this semi structured data, you can make use of AVIATAR’s Engineering Analytics application – a dashboard tool that is able to compare parameters within the write-up. For example, you can compare an original ATA chapter and a corrected one.

You can also do analytics on components which don’t send any data, like in this example in figure 9, the galley items.

Figure 9

In figure 9 bottom left you can see how many times coffee makers had problems per aircraft type. But you can take any other component and do any kind of analytics based on that. Like number of defects with including defined thresholds etc. Statistics for a maintenance location; is there a problem on this particular component or system, at a certain station? I believe this is a key advantage from our joint approach with TUI here, because by structuring this data it gives a lot of possibilities of what can be done with it, way beyond repetitive monitoring.

Looking into repetitive defects is one good use case; another one is also just to do a system engineering analysis based on that. In figure 10 you can see how the solution can work for different roles in your organization.

Figure 10

Accordingly, the examination is probably more for the MCC / MOC (Maintenance Control Center / Maintenance Operations Center) as you want to react on repetitive defects right now. Furthermore, when you monitor the 737NG not sending any fault messages, this might be a next level troubleshooting for this aircraft type in your MCC, as you now can look just for defects and how often did those defects appear? If you save those repetitive defects, that’s probably more for the reliability manager, but also MCC at times. It depends on your organization. The dashboard view is maybe for the system engineering or reliability management to do broader analytics based on that.

BENEFITS, VISION AND OUTLOOK

In figure 11 you can see that we integrated our engineering knowledge and added that with a large language model and with AI, which we believe will then generate insightful analytics.

Figure 11

We made very sure that this is customizable. We are always looking for a customer centric approach to develop our products and that also comes with customizability. The data, of course, is live integrated, i.e. coming from AMOS; here we have a very well working interface. But we can also integrate other MRO/M&E systems because we only need the write-ups as one single data source. And this will bring you into the position to do repetitive monitoring on an individual basis, even within your organization. We have the ATA chapter correction and we think users will profit from this highlight identification, and will now be able to deal with this information overload you usually have if you look at all the write-ups coming in. Figure 12 describes our vision.

Figure 12

This is only the start. If we look further into the future, what we’re currently investigating is what we call fix effectiveness. With fix effectiveness, we can use a very similar algorithm and now just ask for the resolution performed in this work order, because it’s in there. You already have the task and we could compare that with a task that was performed previously. If the defect didn’t pop up anymore, it’s probably a final fix. We can do analytics based on that and extract the task description, the resolution, and give this later on as a recommendation. We believe this will be a very powerful add on to T.REX and to all other products in our Digital Tech Ops Ecosystem.