Articles
Name | Author | |
---|---|---|
CASE STUDY: Successful eTechLog implementation at TAP Air Portugal and Portugália Airlines | Luís Marques, Maintenance Operations Center Manager, TAP and Joana Arina, Director of Technology, Portugália | View article |
CASE STUDY: Transforming repetitive defect detection at TUI Airline with Artificial Intelligence | Niklas Kropp, Head of Business Development & Fleet Performance, TUI Airline and Dr. Jan Philipp Graesch, Product Lead Reliability Suite, AVIATAR, Lufthansa Technik | View article |
CASE STUDY: Rolls-Royce uses engine performance data to improve service | Richard Swallow, Head of Data Services, Aftermarket Operations, Rolls-Royce | View article |
CASE STUDY: The digitalization of MRO services at GAES | Dmytro Neschetnyi, Director of IT, GAES, Adeliia Platonova - Sr Manager Business Systems & Digital Solutions, GAES, Ege Sumerol, Director of Operations, WINGS Software Vendor (ADT) | View article |
CASE STUDY: Rolls-Royce uses engine performance data to improve service
Author: Richard Swallow, Head of Data Services, Aftermarket Operations, Rolls-Royce
Subscribe
Richard Swallow, Head of Data Services, Aftermarket Operations at Rolls-Royce shares how a digital engine data exchange platform has delivered value for Rolls-Royce and its customers
As the standfirst explains, this is an article about how a digital engine data exchange platform has added real value both for Rolls-Royce and for our customers. But, before going into the details, I want to first set the context with the big questions that we ask in Rolls-Royce for our operational services; you can see them in figure 1.

Figure 1
The first question is, how can we extend our engines’ time on wing; how can we keep our engines flying for longer? The second question is, when we do overhaul the engines, how can we minimize the time that they’re out of service and return them to flying? These are critical success factors for Rolls-Royce where we’re constantly looking for improvement, innovation and new approaches. This article is about how we’ve done that by focusing on data first. The case study considers what opportunities we would gain if we had more accurate, timely and complete data as well as a better level of visibility about our engines in service, how they’ve been operated and maintained, and what other ideas might help us to answer those big questions.
MAKING DECISIONS THAT MATTER
We make lots of decisions every day at work; scale that up across all the decisions that our teams make and our organizations, our companies, and scale that up for time. It’s not just the decisions we make this moment, today, this week, this year; over the life cycle of engine countless decisions are made. We sometimes make those decisions based on experience or instincts, but we have the best chance of making the best decisions where they are supported by the data that gives us real understanding. It’s fairly obvious that, where we have a clear understanding of the situation that we’re in and the different options that are available to us, then we have the best chance of making the right decisions for our business.
That’s where I’m coming from, that’s what I’m trying to do and that’s my role, my motivation. What this article will show is that, if we can make all those countless decisions as good as they could possibly be, because the data that we support them with is as good as it should be, then that is transformational for an organization. If every decision we make is that little bit better because the data it’s based on is that little bit better, that’s huge gain for our performance.
THE ROLLS-ROYCE STRATEGY
Thankfully, all of the above fits perfectly with the Rolls-Royce strategy as illustrated in figure 2.

Figure 2
This isn’t controversial. Every company in the world recognizes that a strategy is key to success; and a data driven understanding is how we drive innovation in our engineering and operational spaces. To do that, we need two things. First, we need to have the data available to us: this isn’t always within the Rolls-Royce estate of course, the data for engines is generated by airlines, not within Rolls-Royce. Second, the data needs to be consumable. This, again, goes for every company, I think. The data needs to be accessible to us, within the normal cost of business. It needs to be in the systems that we access day-to-day to operate our business. That’s the vision, that’s where we’re trying to get to with a strategy. We want all of the data to be available at the fingertips of the people that need it and when they need it. As is often the case, the concepts are very simple, it’s the execution that’s the challenge.
What’s prevented us realizing that strategy up to now is simply that we haven’t had the capability in place to share data with airlines in both directions, from airlines to Rolls-Royce and Rolls-Royce to airlines, with the level, volume and scale that we need to make that vision a reality. I’m sure that readers will be very familiar with this. Historically, data is manually extracted from a digital system; it’s then emailed to a counterpart in the receiving organization and, when that eventually gets to the top of somebody’s inbox, there’s another manual action to get into another digital system, where it can finally be used. That’s what’s between the vision and actual achievement. It’s too much hard work; it’s not fast enough and, because it’s a human process, it’s prone to error. We’re never going to get to where we want to be while we’re working like that. Figure 3.1 shows the flow of data between Rolls-Royce and the airlines who use Rolls-Royce engines, what Rolls-Royce calls the Blue Data Thread.

Figure 3.1
Improving this is the Blue Data Thread challenge, and the Blue Data Solution is how we’re improving and solving this, as you can see in figure 3.2.

Figure 3.2
Again, the concept is really simple; looking at the difference between the figures, all we’ve done is removed those manual steps and replaced them with automation.
Introducing automation means that we can share data as frequently as we wish, so everybody, both parties, can have access to the very latest, most up to date information that we need. It means there are no restrictions on the volume of data that we can share, or specifically, the detail of data that we can share. When it’s being done manually, we can’t really share more than a summary, because it takes too long and too much effort to give all the detail. Now that we’ve taken a lot of the human elements out of the loop, and there’s less scope for human errors, the quality should be better than it would otherwise be. That’s the concept.
When we first started to research the market about finding a solution to take this concept and make it a reality, one name that came up frequently was QOCO as identified in the middle of figure 3.2. It very quickly became clear to us that QOCO was already the partner of choice for a lot of the airlines that we were talking to. So that’s where our relationship with QOCO began, and it’s been extremely successful. We’ve been working with them for a number of years now to make that concept a reality. QOCO is working between Rolls-Royce and our customers to provide the data transfers that we need in order to automatically exchange data in both directions.
ROLLS-ROYCE WORKING WITH QOCO
We have just over half of the Rolls Royce, modern, large engine fleet connected by this method of sharing maintenance data now. It’s been growing over the years as we’ve seen more and more opportunities for this concept which you can see in figure 4.

Figure 4
We began by using the concept to enable a new lifing service for Rolls-Royce, something that was only practical because we could exchange data in these volumes. We’ve been able to use something we call the On and Off Log service, a way of automatically exchanging pre and post shop visit data, but which doesn’t require up to three days of manual effort, post shop visit, to type whole pages into the system. Now, we can instead achieve that electronically. We started to use it to remove the manual effort around sharing utilization data into the Rolls-Royce systems every month. We can automate that a lot more and we’ve piloted a program called Predictive Work Scoping; again, something that’s only possible because of the extra information we now have on how our engines are operating in service. This is now the standard for the Rolls-Royce way of working, which we try to introduce for every new airline that we do business with; we also have a program to roll it out to all of our existing customers. It’s become standard, given that our business aviation colleagues have adopted the same approach as we pioneered in the large engines space. Because the overall concept has been so successful and so well received by airlines, we’re looking to continue to build on it and grow it.
The latest version of the solution looks like the illustration in figure 5.

Figure 5
This won’t be the final version: we’re constantly looking to grow and improve it. As well as QOCO, at the center of that maintenance data transfer, we’ve also been in partnerships with, most recently, TRAX aviation and, prior to that, IFS maintenance to make this as close as we can get to a plug and play integration for airlines to make it as easy as possible to enable this level of data sharing. Similarly, we’ve got a really strong, comprehensive solution with AMOS and similar successful connections with Ultramain and SAP systems in different airlines.
Because the concept has worked so well, it’s obviously been the right thing to do; judging from the feedback we’ve received, we’ve extended the concept beyond the maintenance network into high frequency engine data. We have the same thing in place now with SITA, where we’re exchanging with the one-way transfer, plug-in to Rolls-Royce, from the QAR (Quick Access Recorder), SAR (Smart Access recorder), CPL and e-Life data, which previously consisted of files that were difficult to transfer. We have a very simple means of doing that, from airlines to Rolls-Royce now, which means we have all the data available to analyze.
The solution is now connected with more than 60 individual airlines. Not all of them have the full scope of all the data, but there are 60 individual airline connections across the maintenance connections and high frequency data scope. I think the real vote of confidence from airlines is that none of them have gone back to the old manual solution. That’s a great indicator that we’re going in the right direction here. This is the right thing we’re doing and continuing to grow. So that’s what we will be doing in future. If I go back to figure 1, I highlighted two big questions. So, it’s been really well received by airlines, but has it actually helped us to, as I said, to improve our time on wing and reduce the turnaround times for maintenance. I have three examples coming up where I think the automation has worked.
EXAMPLE 1: AUTOMATION AND TIME ON WING
The first example is around a service that was first enabled by this Blue Data Thread data exchange because of the volume of data required by our DAC (Direct Accumulation Count) service. We analyze the data from every engine for every flight, for Life Limited Part (LLP) life consumption. Because we can analyze the data for every engine for every flight, we treat them as individuals, it means that we don’t have to apply generic or worst-case assumptions to every engine. We can safely extend the time on wing for the life limited parts, because we have the data, and when the data tells us safe to leave them on, we leave them on: we don’t have to take them off just because we don’t know any better. Life limited parts are a clear driver for engine removals. So, anything that we can do and have done here to extend life limited part life is a clear link back to that first question about extending overall time on wing. This has been a great success story for us.
For airlines as well; it’s much easier to operate the service because it not only means that they don’t have to manually provide all the data but also, using the data, Rolls-Royce can calculate some answers that we can push straight back into airlines’ systems. That’s the way they need it so they can operate their own systems.
EXAMPLE 2: SHOP VISIT PLANNING
This is something that we’re starting to pilot now and we’re already seeing a clear potential for this. It’s around improving the shop visit turnaround time, because we have better visibility of what’s happening operationally in service. From a maintenance perspective, at the moment, we open an engine and get it stripped down to understand what it’s going to need in terms of the overhaul. With this digital data exchange in place, and the extra visibility that we’ve got, we have a better chance to understand in advance what it’s going to be needed so that we can prepare for it. Things like spare parts availability, or Rolls-Royce’s capacity to issue technical variances, if needed, or repair scheme availability; we can see it coming that much further away, and can see it at fleet level. It means that we’re less likely to have surprises when the engines actually do come in to be overhauled which means, ideally, no delays or, realistically, fewer delays which means an improved shop visit turnaround times.
Another benefit from that is, if you’ve got that visibility of part consumption, particularly spare part consumption, across the fleet, then, again, there’s much more chance to react earlier to changes in demand. Spare parts availability has been an issue in the past. This gives us that clear change in demand signal as early as possible, which means we can invoke the change in our own supply chain and address those issues, hopefully a lot earlier, or head them off in a way that we’ve never had the opportunity to do before, because we simply never had the data.
EXAMPLE 3: RELIABILITY AND ENGINEERING
This third example is around a service that we call Engine Health Monitoring which has been around for a long time and is based, first of all, on the high frequency data that we bring in through SITA. Again, it’s about analyzing the data from every engine and every flight, and it was traditionally based on ACARS snapshot data. As a very rough guide, we’ll get perhaps 150 parameters, five or 10 times a flight on which to base our analysis of the engine. We use that data to try and predict or to try and see if there are any issues emerging; perhaps slightly different engine behavior on this flight compared to last flight, or even, during cruise, compared to how it was during climb or in take-off. That’s been a really successful service and it’s been running for a long time, based on that ACARS data that 150 parameters, five or 10 times a flight. What we’ve now got, because we’ve made it so easy for airlines to share QAR and CPL data with us, those high frequency sources, give us access to potentially thousands of parameters, not just 100 or 150. And not five or 10 times during a flight, but thousands of parameters recorded every second of every flight. Our opportunity now to really understand what’s happening with the engines in flight, what’s changing, what issues are potentially emerging, is massive. It’s next generation.
We’ve done this already with a number of successful captures; with this high frequency data, we’ve seen things develop that just wouldn’t have been possible for us to see with the normal snapshot data. It means that we can get much earlier visibility which, in day-to-day operations, means that we give the airline a chance to schedule some maintenance at a convenient time, to not cause a disruption, delay on cancelation, because we’ve been able to say, one or two flights earlier, that this is going to need doing. Where it relates back to the big questions, our objective is that sometimes we can get the warning in advance to turn what might have been an unplanned removal into a planned removal. Going back to the previous example, a little bit of extra warning means that we can be prepared for it, and there’s less chance of delays during a busy operating schedule.
The second benefit, still in the engine help monitoring service, is the feedback loop that we get going back through the maintenance data. We said before, in both directions, this is a manual process. Obviously, we would only get a summary of what’s happened. So, when we provide that troubleshooting advice and guidance around these emerging problems that we’re seeing, we now have all of the detail about what actually happened within the airline, within the maintenance space, and what was effective. Previously, we would get a summary of that, because it was manual; now we have the detail. Obviously, if you have that better feedback loop, it gives us the opportunity to improve our guidance, our advice, next time, and give a better service to the airlines.
CONCLUSION
That’s three clear examples of where it’s where the Blue Data Thread is helping us, and helping to provide better service to our airline customers. As mentioned above, we have over 60 airlines connected, more than half our Trent fleet, but new airlines are coming on every month. The scope of the data that we’re sharing is increasing every month and we’re always looking out for new partners or things that can help us add something to this.
Before ending the article, I must give credit to QOCO Systems whose data exchange capability has made the whole Blue Data Thread idea work so well. QOCO’s strategic goal is to be the platform in the industry that enables data exchange between airlines, MROs and OEMs to where it can be used for benefit. I hope that this article has illustrated how that works in action.
Comments (0)
There are currently no comments about this article.
To post a comment, please login or subscribe.