CASE STUDY: Ten years of ‘eLog’ operations at British Airways

Author: Scott Falkiner, ELB Manager – Engineering, British Airways

Subscribe

Scott Falkiner, Electronic Logbook Manager – Engineering, British Airways shares the implementation of a new ELB and the migration process that avoided any aircraft delays.

THE ELB AT BRITISH AIRWAYS

You cannot underestimate the size of the aircraft tech log. It’s a tool that’s carried onboard every aircraft, it’s used by almost all the different areas of an airline in one way or another and that tool is almost consistently being used when an aircraft is on the ground.

Figure 1 – BAW Ultramain ELB 2.0 Dashboard

BAW are now a full ELB airline, with 130 long-haul tails and 144 short-haul tails; and our logbook is tailored specifically to each fleet.

Our very first Electronic Logbook/eTechLog/ETL aircraft was the Boeing 787 which arrived in 2013 from Boeing with an integrated logbook. BA operated ULTRAMAIN ELB installed on Class III Electronic Flight Bag on the B787’s for eleven years before transitioning to ELB v2 Mobile in early 2024. In total, we migrated 218 tails from a paper-based logbook to the iPad ELB. The last of our fleet to migrate to ELB was our A320 fleet.  

That roll out over the last few years was just one part of the £7 billion transformation investment in British Airways, which means that we’ve had the support of the board of directors to roll out at speed.

The ELB is universally liked by everyone, not just Engineering. It reaches so many different parts of the airline: Engineering, Flight Ops, Cabin crew, CAMO, ground services, safety; everyone touches the logbook at some point.

BA’S FIRST eLOGBOOK WITH THE BOEING 787

As already mentioned, in June 2013, we first took delivery of our first Boeing 787 with an integrated eLogBook (ELB) as you can see in figure 2, as part of the Class III Electronic Flight Bag.

Figure 2 – Boeing 787 Class 3 – Electronic Logbook

This was a very user-friendly solution which was built-in for the pilots, with access for engineers. It had offline authentication available by using the built-in printer and it had automated data transfer using the aircraft’s ACARS connection. We could see defects being raised in flight and we were able to integrate it with our MRO system, SAP, from the very beginning. The M&E integration is the most critical integration.
The ELB itself had the unique British Airways tech log workflows so that we didn’t have to reinvent our processes for a single fleet. It also had a robust station copy solution; if connectivity is lost, there is a requirement to leave a station copy and so on the 787 you just printed it out. It’s simple, and compatible with the in-flight connectivity using ACARS. That said, it did have its limitations and, eleven years later, was showing its age.

This logbook ran on the EFB hardware and when you had a hardware failure it could easily affect the logbook operation. The most common failure was losing connectivity, the ELB wouldn’t be able to see the ground server so that you’d be printing and signing every entry just to leave that station copy. At that point, there’s also no signature validation, losing the benefits of a digital signature. Eventually, the 787 architecture changed so that one of these hardware failures meant that not only did you lose comms, you also lost the ability to print on board. At that point, you’ve lost the electronic logbook. If that happens, it’s an extremely laborious process from that ELB get it onto paper, because you’ve essentially got to write or print everything out in the meantime, fix the defect itself and data-enter everything from the paper logbook before you can reinstate the ELB.

If you wanted to change software, such as to update the MEL or change some defect classification you had to do an aircraft software load. That’s a full software modification for Engineering – having managed this system for five years I can tell you it was extremely resource heavy just to keep running, and that was on only 33 tails at that time.

AN ELECTRONIC LOGBOOK FOR EVERY FLEET

Thinking into the future, we wanted something that other fleets could use, a standalone, agnostic solution. An improvement on what we already had and that would support BA long into the future. At the time, the first new aircraft type, due for delivery in 2019, was the Airbus A350 so that was the target we picked. It gave us three years from 2016 to go through with this program. We went through an RFP (Request for Proposal) process, selecting the ULTRAMAIN version 2 product (the iPad solution) which could be configured to replicate our existing paper log workflow, following the mantra that you don’t have to reinvent the wheel. Use your existing processes; you just want an electronic, digital logbook.

The decision was taken to trial the Ultramain solution; at the time, it wasn’t a finished product but it was close. It was tested on four of our Airbus A380s in 2018, the first time Ultramain v2 flew anywhere, providing the necessary feedback to polish the product. One of the other important steps we’ve had in engineering is that I maintain extremely close collaboration with the UK CAA (Civil Aviation Authority, telling them all of our design changes, why we’ve made the change, what regulations are impacted and why we’ve made that decision. That was two and a half years of constantly talking to the CAA to make sure that, when it came to the A350 approval stage, everything was lined up.

In June 2019, we introduced the iPad ELB, as we in BAW now know it, and the feedback that we got from our A380 trial ensured a product that could be operated instantly onboard the new A350 fleet.

Our very first A350 from Airbus was delivered out of Toulouse using the ULTRAMAIN ELB. As required by the CAA, we did still have a parallel paper logbook on board and, even though we’d gone through everything with the CAA, it still took six months for them to approve all our processes and procedures – particularly the backup procedures. Don’t underestimate how much effort you’ll need to put in with your local authorities. CAA approval came in early 2020 just after four aircraft deliveries and just before COVID happened…

VALUE OF THE ELB

There are five principles to any technology that we use in British Airways and generally they apply for any ELB product, not just ULTRAMAIN ELB.

1. Is it going to remove handwriting issues?
2. Can it prevent human entry issues?
3. Can you automate data entry?
4. Will it remove ‘lost’ paper log sheets?
5. Can it control your defects?

Within British Airways, we integrate our ELB with many of our systems. As mentioned previously, the most critical integration you can have with any electronic log is integration with your MRO system. In British Airways case, it’s SAP. As some readers might know, it’s not very easy to work with and the integration was a substantial amount of work. Do not underestimate the integration with your MRO system. If you get it right, your ELB will work; if you get it wrong, your ELB won’t work.

We also decided to add our Flight Operations systems to ULTRAMAIN ELB because, if we can pre-populate our ELB/ETL with (for example) the known flight details, we reduce the workload for our Flight Crew; we’re just trying to speed the process up and simplify it. In a similar manner, we capture OOOI times automatically from the aircraft with the ULTRAMAIN ELB automatically updating before Flight Crew have even opened the app.

You also need some form of user management; for BAW that came in the form of Active Directory integration. That allows us to properly control access to the ELB. It allows us to give flight crew the rights to view our ELB but make sure only engineers are able to issue a CRS (Certificate of Release to Service).

The final integration is with the archiving system. Traditionally, all engineering records are kept in a single master archive; so, if we can also feed the ELB golden copy into the same archiving system, there’s no change to normal processes.

AN ELB GIVES CONTROL AND DATA QUALITY

With ULTRAMAIN ELB v2 specifically, the solution is driven by a list of faults. We don’t do free text entry anymore; everything is driven by the list of faults we’ve got pre-populated in the ELB as shown in figure 3.

Figure 3 – ULTRAMAIN ELB 2.0 iPad application, and Excel resource

The benefits of ULTRAMAIN ELB include that, for the airline manager, the application can be amended very simply and quickly. A spreadsheet is used by the airline logbook manager that contains all the possible defects that can be raised. It’s simple to edit, and simple to load when changes are completed. Coming from the old 787 ELB, this method no longer requires an aircraft modification and it leaves the airline in control of its own ELB.

If you’ve got something urgent, maybe a NOTAM that you want linked to a tech log entry, you can put it in yourself and you can turn it around in two hours; it’s very easy. An example of this is BAW specifically using this functionality during the period when NOTAMs were being issued in the USA for possible 5G interference. A special ELB workflow was put in place to identify when a defect may clash with the NOTAMs.

The benefit of having this level of control over the defect listing is that once you’ve removed free text entries, you’ve suddenly got structured data. You’ve got fault codes linked to everything; you’ve got ATA chapters linked to everything; everything is driven from a defined dataset. This means that, as we move into the age of AI and data analysis, you’ve got the perfect data to start the process with. That’s where an ELB can really help your operation.

Figure 4 is an example, of what we know in BAW as the mismatch report. It’s when we have highlighted a discrepancy between the aircraft Tech Log, and our M&E system.

Figure 4 – BAW Mismatch status – M&E Data does not match Logbook

In the figure the red bars are December 2023 and the blue bars are June 2024 -approximately six months later.

By looking at the red bars, you can see that in December we had three fleets already on ULTRAMAIN ELB, with the 777 and A320 still on a paper logbook.
Six months later, when our 777 ELB rollout was complete, the blue bar shows the seismic reduction in our 777 mismatches.

This is one of the metrics we’ve used to judge the success of the ELB. That’s almost 80 mismatches on a single fleet that no longer needs a resource to go and investigate why it is a mismatch. Now it’s an automated data flow; it just works. There will still be mismatches; that’s the nature of working in the M&E system, but look at the order of magnitude they’ve reduced by.

It’s a similar story with the A320: in June, we still had the BA EuroFlyer A320 fleet running on paper log, accounting for the size of the blue bar. The reduction from the Mainline BA fleet though still highlights the order of magnitude of difference between ELB and the old paper logbook. From an operations perspective, this has had a massive impact but one that you can’t put in a business case; so, this is a non-quantifiable benefit, which you only see after deploying.

As you can see in figure 5, the ELB is connected worldwide. This shows a defect, raised on an aircraft inflight, with a photo attachment.

Figure 5 – BAW Ground Server Dashboard, showing aircraft defects whilst aircraft is in flight

We’ve got 4G, we’ve got 5G and we’ve got Wi-Fi where available; the ground system is updated in virtually real time.

Because we’ve got passenger Wi-Fi on our aircraft and we’ve whitelisted the ground server, our iPads will connect in flight: we can see defects as they are raised, we can see the aircraft’s progress and we’ve got a web interface so users don’t just need the aircraft iPad. Anyone working in the office can view the ELB; they just log on and the data is there as soon as you’re in the ground system. We have a list of all recent defects showing on our dashboard – as soon as a defect is raised it can be seen by Maintrol – it’s a very useful tool. Maintrol see the defects coming without having to rely on the pilots to call defects in. Similarly, for engineers, if an aircraft’s en-route – going to a line station or coming back to main base, the engineers can see when there’s a defect raised, and there’s a photo attachment so they know exactly what part is needed. They can get the part ready at the aircraft stairs before the passengers have even come off.

We’ve recently allowed our Flight Crew to have access to the ELB before their flight. This has saved them time before briefing; they know the status of the aircraft, reducing the time to review the aircraft, because they can do it in advance. Another big one; you might never be able to quantify the delay that was never taken, but once you’re getting feedback from pilots that have actively avoided delays because of the ELB/ETL visibility, you know you’re onto something. One of those was an A380 and you can imagine what an A380 cancelation would cost. So having that feedback come in has proven the business case retrospectively. It’s not all about ROI, it’s about your operational benefits too.

NEXT STEPS

From a British Airways perspective, we started small. You’ve got to start small; you cannot do this in a big bang, the logbook is such a massive beast. Our next step is to put damage charts in. We still record damage on a massive piece of paper and a Microsoft Access database but now the whole fleet has a uniform ELB we can expand on and add features.

Currently, the ELB talks to SAP, but SAP doesn’t talk back. If you’re an AMOS customer, ULTRAMAIN ELB offers a two-way feed AMOS. We also want to introduce part validity checks; if an engineer is changing a part, the ETL/ELB should be able to talk to SAP, check whether it’s a valid part for this specific tail, this MSN (Manufacturer’s Serial Number), and feed it back to ELB in real time.

These small enhancements are why we want to go with two-way communication next.

We want to start feeding more of our data into the various aircraft health systems in use. There’s a lot of systems for that, like AVIATAR, and we want to feed these systems directly from the ELB source. You can never have too much data, just as long as it’s being used correctly and the systems out there will make use of it. It’s not necessarily a logbook product, but it’s a benefit you can take from having an ELB. You feed more systems with the better-quality data from which all can benefit.

Again, the data warehouse styles of analysis. We’ve got all these clever AI algorithms but, as we go forwards, we can really build upon the data we’ve got and, because it’s structured and consistent, you’ve got the same defect being reported the same way, time after time, you can start trending from that correctly.

THE ROLLOUT PROCESS

We’ve recently completed the rollout on 218 aircraft that were previously paper based. Figure 6 sets out the process that we followed.

Figure 6 – Process for BAW migration and final BAW long-haul paper tech log entry

Because we were doing this after COVID, the supply chain was decimated and a lot of our aircraft were carrying higher than usual numbers of deferred defects. We didn’t want to have to do the migration manually because of these higher numbers would need significant resource. We needed to try and do this automatically somehow. Again, if you’re an AMOS customer, you just turn it on in ULTRAMAIN ELB but that’s not the case with SAP.

We specifically got Ultramain Systems to create an Excel import tool; we could extract all of our TechLog data from SAP and feed it straight into ULTRAMAIN ELB. The benefit was that we could prepare the aircraft without it being on the ground, we could do all our preparation work in the M&E system and didn’t need to touch the aircraft. Once we made sure the aircraft were clean and tidy, it meant there were fewer paper log mismatches to sort out on migration day.

We would target an aircraft the day before, ensure the data was as clean as possible and then begin the migration during a normal aircraft turnaround. The data import to be sent to ULTRAMAIN ELB was reviewed, new open Tech Log entries accounted for and then everything was imported to ULTRAMAIN ELB. A simple process which minimised aircraft touch time, keeping BA Operations happy.

Summary of the migration

Over 15 months 218 aircraft were migrated with no operational downtime; it was all done on normal inputs as you can see in figure 7.

Figure 7 – BAW summary of ELB rollout

In order to perform such a successful migration, without any impact to the operation, we used dedicated teams whose job was to tidy each aircraft up, get it ready for the migration and put the ELB/ETL on with two different approaches for the long-haul and short-haul operations.

At Heathrow, we’ve got the night jet ban so our aircraft cannot fly or depart overnight. This means half of our A320s are on the ground at Heathrow pretty much every night, the perfect time to do this task. Our short-haul team would engage the aircraft after the last flight of the evening and there’d be no maintenance carried out, only the migration team was allowed on the aircraft. Because of the nature of the short haul operation with frequent taking off and landing, that preparation couldn’t be done in advance. Fortunately, short-haul aircraft carry less defects. They’d resolve the paper log issues and make sure they were good to go with the ELB. The migration team verified it, migrated everything, put the ELB on board, took the paper logs off and returned to the office. Maintenance picked up the aircraft about 11pm to 12pm as normal but it was an ELB aircraft at that point. The migration team was back in the office, closing down the paper log and doing their double checks. For a short-haul operation, it was focused on the night, and you had to be flexible. It just needed a weather issue anywhere in Europe, to cause a delay.

Long-haul aircraft often fly through the night, so the migration process had to be different. BA has three primary fleets that we had to work around, plus there are aircraft at Heathrow and Gatwick which led to two separate migration teams. There was minimal downtime on these aircraft: some Boeing 777s turn around in less than two hours. How could we do an ELB migration in, say, 90 minutes? This was where preparation came in, preparing for the specific aircraft the day before, ensuring that the paper log was spotlessly clean, and the next day, when the aircraft arrived, it was cut over to the ELB.

The aircraft landed, passengers disembarked and the migration team isolated the logbooks. This ensured maintenance could continue but kept the aircraft logbook in a known state. The team would check for new entries, perform the data import and verify. As soon as ELB was ready we passed it over to the maintenance teams, and they’d start writing their entries directly into ELB. Once the aircraft departed, the migration team could tidy up and close down the old paper log, and showing how a long-haul tail can be migrated from paper log to ELB with less than 90 minutes of touch time.