EFB: To buy or to build?

The decision to build their own and the logic behind it are explained by Captain Andy Jones, EFB Project Team and Shaun Landy, Flight Operations Manager, Thomas Cook Airlines

Thomas Cook Airlines operates four European carriers; in Scandinavia, Belgium, United Kingdom and Condor in Germany. There are 96 long-haul and short-haul aircraft serving destinations everywhere from Anchorage to Auckland.

A pioneering EFB program
To understand what lay behind the decision on an EFB (electronic flight bag) solution and the subject of this case study, we’ll need to go back to 1995 when Condor was the leisure arm of Lufthansa. These close links had led to the beginnings of an EFB solution which aimed to automate documentation and remove paper from the pilots. That two year process included issuing laptops to pilots so that by 1997 they no longer needed paper manuals.

Also, with a laptop now in service, we could move to exploit its other features. Condor had been developing a take-off performance calculation tool since 1995 and in 1997 that was rolled out to all pilots so that paper performance charts were also disappearing from aircraft and computers were being used to do some of the things that we read about from EFB providers today. By 2000-2001 CBT (computer based training) had moved forward and instead of using a classroom based tool that took pilots into a non-productive ‘out-of-roster’ environment, we used the laptop to deliver their CBT requirements and offline training requirements needed as part of their annual recurrent processes.

By the early two thousands, we had a pretty mature product; then in 2008, Lufthansa’s involvement in the Thomas Cook Group ended and, with it, the Lufthansa systems link that was, in effect, providing the backbone of the laptop based system. Condor faced a difficult decision on how to proceed with an EFB solution. But we started with the advantage that we already had a system that was a grandfather among EFBs; by 2008, Thomas Cook Airlines already had 13 years’ experience of EFB operation with pilots trained to use the tools and business processes set up to work with technology that was, by then, very mature in the organization.

Reasons to build our own solution
So, when we started to talk with EFB providers available in 2008, it quickly became clear that they were at much earlier point in their development cycle than we were with the solution that we’d been used to and that the inflexible products on offer at the time weren’t going to give us what we needed. Most of the interfaces were a little bit ‘clunky’ and some of the problems associated with EFBs (update processes and integration with the applications that we wanted to use) were not even familiar to the providers. We quickly decided there was nothing available on the market that could take us forward; so we had to move to the ‘build’ solution. Having something that worked and with which all our users were familiar made it easy for us to simply emulate what we’d become used to through the Lufthansa platform.

We could also embrace new opportunities: Lufthansa had a legacy product with a technology dating probably as far back as 2002 whereas, by 2008 there were new technologies coming forward: not only could we emulate what we already had but we could also look at opportunities available with the coming technologies – 3G was starting; mobile data was beginning to get off the ground… But we still needed to find a partner which we did in Bergfeld Software, who had experience of managing remote devices and managing paper documentation. So, we took their experience and put together a package.

The solution
In practice, there was a year in which we could remain part of the Lufthansa platform; so our main concern was the time challenge. If we were going to take on a development project like this, we were acutely aware that we couldn’t afford to get the development side wrong. Thankfully, the first CUBE laptop appeared towards the end of 2008 to early 2009 and with it, from day one, we were able to prepare for a touch-sensitive screen, which was relatively rare at the time, and we could insert a SIM Card into the device.

Having got a SIM Card, and a LAN connection, we set out to establish whether 3G was going to work for us. Each month we move about 2GB of data for manuals, performance data, aeronautical charts, flight plans and training materials. Particularly when we were talking to departments that were working with aeronautical charts and LIDO (Lufthansa Integrated Dispatch Operation) who were looking at a gigabyte or more, nobody believed we were going down a path that would work. Who, they wondered in 2009, could use the mobile data network to maintain all the charts on pilots’ laptops? Thankfully, the 3G network was developing and we’d got some good ideas through Bergfeld to work on data compression: the solution proved itself very quickly. We also had LAN connection back up if people had got out of date or perhaps been on leave, and we could demonstrate that everything worked; so much so that by 2010 we could look towards putting this technology not just on Class 1 laptop EFB solutions but also to be rolling out the navAero platform and using CUBE with that.

Working with regulators; ensuring redundancy
We were at a great advantage in 2010 as we moved to the next level. All the pilots knew how to use the device; and the same software they’d had for two years on their laptops, was presented to them in a Class 2 set-up on board the aircraft. The great thing about having the laptop and the Class 2 solution on the aircraft is that, when we started to talk with the regulator, we had four devices on board. Redundancy wasn’t an issue because the pilots each had fully up-to-date systems and the aircraft also were to have fully up-to-date systems. The confidence we had in the update process allowed us, in 2011, to remove paper from the German Boeing fleet. We were also able to develop new opportunities to ensure that data is updated very effectively and quickly by using a cross-link system between the two devices on the aircraft; so, in effect, if one device received information one way and the other device received it from the opposite end, when the whole aircraft had a complete set of data, it was able to pass it over.

In order to talk to the regulator, we had to prove that these remote devices, that never saw a crew room and hadn’t got anybody watching over them, were actually going to be up-to-date. Below is map of Frankfurt airport with which we can see how this was achieved.

The airplanes shown are Condor Aircraft on the ramp. The data above the map has to be green and, from that, we know that the aircraft is doing what it should. Also the technology uses GPS from on-board the aircraft to give its position back to the web management system. This offers a number of advantages, especially on an enormous airfield such as Frankfurt, when moving an aircraft from one side of the field up to a gate on the other side, because you’re planning a departure. It’s also valuable to the operations team to know where the aircraft is positioned before getting clearance to tug it to where it’s needed.

That is looking at a one aircraft scenario. But naturally we were a little nervous about how the data would be collected, how much data there would be, was the update process going to work, would we actually be able to keep the aircraft up-to-date… So, right from the outset, the technology was designed to maximise the 3G availability of the update process. The yellow areas on the map are where the aircraft realizes that it’s taxiing into an area where it needs to shut down 3G. As the aircraft taxis out, it has update capability; as it enters the orange area, internet connection is terminated and the aircraft continues its flight. The other way, as an aircraft lands and as it clears the active surface, 3G is re-initiated automatically. So the ability to keep data flowing through every opportunity was designed in right from the beginning.

The image below…

… is another look at how the management screens work and again, there is mainly green but some red. The red tells us that we need to go and do something. So, from a regulator’s point of view, back in 2011, we could say that we had a product with which we understood what was happening on the aircraft and where we could rely on the data that the pilot was seeing for all his documentation, charting, flight planning and other means, being in place. The red items are dealt through a call to engineering or a call to the pilot if something needs rebooting or is not quite right.

Fleet renewal
Come 2012, we had reached an interesting point because we were looking at the fleet roll-over process (we’d just placed a large order with Airbus) and, as part of that process of specifying the aircraft, the Rockwell Collins solution became our preferred choice for electronics, creating further opportunity.

When undertaking a development process and building something yourself, it’s important to take stock of the market occasionally and just establish ‘are we going to the right place?’ ‘Have we become unaware of what opportunities are available?’ So, as part of the line-fit Rockwell Collins solution, although Airbus were keen to show us FlySmart, when we compared what we had, rather than abandoning our CUBE solution it became very clear that we still felt comfortable and that our, by then, eighteen years’ experience had a lot of value; everything was still embedded and we didn’t feel that we had got a legacy system; we’d kept it fresh and up-to-date. So we went ahead and used CUBE, adapting it for the Rockwell Collins solution.

Previously, using navAero, we’d had a very basic GPS USB device that had given us our moving map capability – it had been functional and effective. Now with Rockwell Collins and a line-fit solution we were able to gain access to the ARINC bus to get position from that, and, in the future, a whole host of extra data feeds. The great thing was, having the history that we had with navAero and lap-tops, we were able to roll out the very first aircraft, into the fleet from day one with Class 2 paperless EFB; which was pleasing.

Using the capacity to improve the solution
Because of the way we dealt with the 3G connectivity and technology to maximize the update cycle (see above), it was very clear that we had a tremendous amount of excess capacity. That allowed us to move into exploring avenues like the paperless flight deck; all our performance data which had been done through the EFRAS take-off tool, has been sent back to the Mother Ship so that we had the opportunity to start taking more and more paper away from the crews and to hold the records in an auditable manner. And, because we’ve got so much data, the opportunities are incredible. We’re able to use those things to build links to the data warehousing; tools that are being used for the company or for Aviaso, which is our fuel management analysis solution: plus, the GPS on the devices records where the aircraft is every second; so we not only know where an aircraft is planned to go, but also we know exactly where the aircraft has been. Because we’ve now got the keys, we can make the decisions.

All this has been happening within the German airline; however, for various reasons, up to this point, the other three airlines in the Group had not been involved. 2013, though, saw the roll-out to the UK business. We needed an affordable solution in the UK and there was a lot of board pressure to come up with an EFB solution, when our German colleagues had already developed one. Ultimately we wanted to remove paper from the aircraft in the UK fleet. In 2011, we had given iPads to all our pilots, which was an added difficulty for us if we were to move to a Windows based solution; and we had to retrofit a varied fleet.

AMC 20-25 opened the floodgates for airlines to retrofit tablet solutions to airplanes. We won’t go over the rules here, readers will be familiar with them, but as long as we could find a way to retrofit our aircraft and comply with AMC 20-25, we could fit a cheap, no-frills solution to our retrofit fleet. And if we could find a mount (removable stowage) we could house a device as long as it weighed less than a kilogram. We would not require an STC (supplemental type certificate) as long as we didn’t bolt it or screw it to the aircraft but used clips. CUBE had been developed for tablet solutions on a Windows 8 operating system.

A trial with Westjet
In 2014, we had two 757’s operating for Westjet, a Canadian airline who needed capacity for aircraft that could operate for about four and a half months from December to April from Calgary to Hawaii and back. As a trial, we fitted both those aircraft with a tablet solution. We thought that trialling it on the Canadian Westjet operation would be the ideal solution to get feedback. We needed to test how 3G worked, would it work on the Westjet route, or would we need to obtain local SIM cards? Would we be better off activating roaming, which would increase the data costs for the contract that we had in the UK? We needed the information to test our update process to obtain regulatory approval in the UK. But the best thing about the Westjet trial was that we had a team of pilots and engineers based there throughout the four and a half months, which meant we would get the necessary feedback with a pilot and engineering perspective to test our system functionality.

Of course, it wasn’t only the aircraft. We had to roll out simulators and give the pilots devices as well. Our flight decks now have the original iPads, the new Windows devices and the installed devices as well as two Toughbooks for ETL (electronic techlog) use – these will eventually be coming off and we’ll be left with two aircraft installed devices, two pilot held devices and the ETL on board. Simulators have to emulate aircraft and so our solution will be for pilots to take their own devices with them when they’re in the simulator. The Simulator providers worked well with us and will install our EFB when our pilots are in the simulators.

The 500 pilot EFBs that we issued give us complete redundancy on the installed solution. But, with that, we have to give training as well and we’ve produced a series of training videos on the CUBE EFB.

The trial was successful in Canada so we have expanded it to the rest of the UK fleet. Currently the EFB is fully installed on 23 aircraft (our narrow-body fleet). Our nine wide-bodied aircraft were operational with the EFB before the end of 2015. UK approval has been submitted; the German airline received tablet approval in February 2015 and we’ll be in a position to remove the charts very soon.

A solution that works and will continue to serve
CUBE has worked for us; it’s coped with changes in technology over the seven years it’s been in existence. It’s never really been a simple roadmap or a single step but has taken place through a group of incremental steps and, because we own the product, we’ve been able to work out what would be the best path for us to be able to gain the maximum benefit that technology could offer us. We’ve had the keys to our own destiny. Having made it work in the UK, we’re now doing the same in Scandinavia so that, by the end of 2015 or early 2016, we plan to be paperless across all of our aircraft.

We’re pulling the four airlines together and working as one across all the markets in which our airlines operate. The great thing at the end of this will be that whichever pilot steps onto whatever aircraft from any fleet, the technology will be all the same. Because CUBE has been so flexible, we’ve been able to take the back office systems from each market and link them to the solution and devices; we haven’t been trapped by the single solution for forms or any element of it. Also, we have the opportunity, because of the excess bandwidth that we have, to take the product into the cabin or to the engineering team. We have the option to take whatever new technology appears (as with AMC 20-25).

Furthermore, we’re able to integrate with third parties to ensure we have flexibility so that if a better or more appropriate deal arises, we can develop CUBE to integrate with that. And we aren’t constrained by the needs of another airline or the inflexibility of a provider because of other commercial ties they have. It is very unlikely whether any off-the-shelf product in 2008 would have kept up with our developments and, of course, having implemented the system in the four airlines in our group, we are now looking to market it commercially.

Contributor’s Details

Captain Andy Jones

Educated to MSc in Air Transport Management at Cranfield, Andy joined Air 2000 in 1988 where he set up the Systems department and was a lead figure in the development of AIMS from Computer Data Corp. He joined Thomas Cook Group in 1997 where he is a Captain and TRE, and has held various project roles. Andy has been involved with development of the EFB solution since 2000 and is part of the EFB project team.

Shaun Landy

Shaun joined Airtours International 1996 as a member of the Ground Operations team before progressing to the Operations and Flight Planning departments in the early 2000’s. After obtaining the FAA dispatchers certification in 2004 he held roles including Flight Dispatch Manager and Flight Support Planning Manager. Shaun has been a member of the EFB project team since 2013, and last year was promoted to Flight Operations Manager, including oversight of all UK Flight Operations related systems for the Thomas Cook Airlines group.

Thomas Cook Group Airlines
The Thomas Cook Group Airlines consist of four leisure airlines: Thomas Cook Airlines UK, Thomas Cook Airlines Belgium, Thomas Cook Airlines Scandinavia and the German Airline Condor Flugdienst GmbH. The fleet comprises 89 aircraft including twelve Boeing 767-300s and ten Airbus A330 working primarily to long-haul destinations. On short- and medium-haul flights, Thomas Cook Group Airlines operate Airbus A320, Airbus A321, Boeing 757-300 and Boeing 767.