Aircraft IT Operations – March / April

Aircraft IT Operations – March / April Cover


Name Author

Building an EFB program on experience at airBaltic



This article appears in Issue 37: the March / April 2019 edition of the Aircraft IT Operations eJournal. For your own free subscription to the eJournal – click on ‘SUBSCRIBE FOR FREE’ for full details.

Building an EFB program on experience at airBaltic
Andrejs Cupecs, EFB Specialist, airBaltic shares the never ending story of an evolving process
In this article I want to share with readers some pertinent facts and milestones from the EFB Project at airBaltic. Internally, we have come to call it the never ending story and I’m sure that most readers will understand why the EFB story is never ending. Let’s start, though, with some background information about airBaltic.
Based in Riga, Latvia and a comparatively young company at just 23 years old with 1,500 employees, the mainstay of the airBaltic fleet is the Airbus A220-300. There were fourteen in service at the time of writing with a plan to grow that to 80 aircraft in the next seven years. Also in the fleet are Dash 8 Q400 aircraft and Boeing 737 Classics. We’re proud of awards that airBaltic has received, particularly ‘Most Punctual Airline in the World’ in 2014, 2015, 2017 and, we hope, 2018.
Figure 1 represents airBaltic’s route network and shows the extent of flights to 70 destinations, excluding ACMI or charter flights.

Figure 1
While most flights are from Riga, capital of Latvia, airBaltic also flies from Tallinn and Vilnius, respectively capitals of Estonia and Lithuania, and carries around 4 million passengers each year.
The airline’s EFB adventure started several years ago and, while the program has been running, there have been constant changes in the industry; shifts in opinions; good and bad times for airlines; moves towards smarter processes and more. As well as experience, the program has also taught us patience.
Underpinning the timeline for the EFB program was a further timeline charting the company’s progress because, of course, the company and any program are inextricably tied together. In particular, around 2012 airBaltic was on the brink of collapse. A new management team took the decision to radically restructure the company: reduce headcount, shrink operations, optimize fleet numbers and type variations, and optimize costs – looking for any savings possible.
At the time, airBaltic was running paper only Operations with three documentation revision coordinators and two data keepers plus paper to be paid for, processed and stored. As the basis for a business process, paper was costly, time consuming and hard to administer and so we started to consider ways to optimize those costs. That was when the EFB program was started.
2013: regrouping and looking to the future
By 2013, airBaltics operations had shrunk considerably from nearly 50,000 flights a year to just 45,000 but, notwithstanding the changes and rationalization, the management made a strategic decision to order the then Bombardier CS300 aircraft which is now the Airbus A220-300. Also in 2013, in a first visit by airBaltic to an Aircraft Commerce conference, we learned about the possibilities for EFB and, by the end of year, had built a business case for an EFB to be approved by management. 
The case included having 100 iPads to be shared among the pilots so that, for each duty time, a pilot collected a specific iPad, syncing the applications for the duty and then, at the end of the duty, synced all data to the Operations servers and returned the iPad. We also issued a request for proposal (RFP) for an EFB solution across multiple all-in-one solution providers to establish a best price. At the same time, the iPad second generation was selected as the device to carry a solution based on cost from the RFP results. But we still did not, at that time, have an EFB. The expectation was that we would be able to remove all paper from the process; remove those administration positions involved with data keeping and documentation administration from the payroll and, as a result, optimize costs. With the benefit of hindsight, we were, perhaps, optimistic.
2014: further reductions, underestimates and iPad configuration
In 2014, reality bit home. The business had to be further reduced in size but was, at least, coming close to stabilization. That said, when the EFB project was launched we assumed that we had, in-house, all the resources to undertake the implementation without any additional human resources. We thought we could delegate EFB functions to some employees as a workload that they could manage alongside their everyday jobs. However, it became apparent that this project needed much more commitment and, as a result, we had a slow deployment. 
For a start, all the devices had to be configured; somebody had to physically configure all of them. Furthermore, to support these devices, there needs to be somebody picking up the phones and troubleshooting problems. That’s where we failed for the first time. And the second thing was that we had not been that careful during the initial RFP because we were benchmarking all the offers based on a checklist which gave us some impression about the product but not the real feel and touch of what it was like to use. It seemed that many functionalities promised by suppliers were only on paper. Of course, in the IT world, it’s possible to develop anything but it’s a matter of time… and money.
As a result, there were only two functionalities delivered to airBaltic initially, large documentation and electronic reporting, with a list of functionalities still to be activated within the project during the first year and a half. Also, there were just one core application and two supplementary applications. We adopted a RAM mount using double suction cups to support crew during critical phases of flight. And we only allocated one person to this process, responsible for support and for configuring all the iPads.
2015: EFB wider values, electronic reports, large documentation and more tools
By 2015, we faced the first changes in the EFB program and started rethinking the route to success. Initially, we had been thinking of the program purely in terms of cost saving and the tangible results of simply removing paper and replacing it with an electronic solution for a positive impact. But, in reality, there appeared to be many intangible things which are there but cannot be put into the business case because they cannot be quantified. So we started to re-think the process. Unexpectedly, we got help from our documentation office which was, at the same time, selecting a document management system and they had chosen Web Manuals as the best solution for them. We then realized that Web Manuals also had an iOS application and so we decided to try it for our EFB purposes. It seems that the only additional functionality that our original EFB provider offered was ‘Reports’. But those reports were static and we disliked them because each time we wanted to update a report definition, it was necessary to re-install the application. For readers involved in EFB projects, you’ll understand how difficult that is with iPads to deliver certain application versions in a timely manner.
We decided on electronic reports as well and analyzed the market to understand the alternatives for our electronic reporting with the main focus on dynamic reports, i.e. where it isn’t necessary to reinstall the application for every update but just to update the report definition on the server and synchronize the device to get everything updated. Our market analysis identified that this was quite costly at a time when the company’s status was only just achieving stability; we had just completed the restructure and were still concerned with costs which meant we still wanted a cost-efficient solution.
As a result, we decided to build our own application, to invest in development so that, when the development was complete, we wouldn’t need to pay license costs because the software belongs to us. This was quite successful.
Also in 2015, we improved functionality on the EFB: we introduced a performance application to deliver precise calculations to crews, but that was only possible if SCAP (Standard Computerized Airplane Performance) is run directly. The problem is that it’s almost impossible to run Fortran code on iOS: no official compiler exists. However, one company, Dynamic Source, is able to run Fortran directly on iOS so airBaltic signed an agreement with them and got the performance application. 
We then realized that EFB was something more than just a one or two application device and that we could put some extra tools on it. That’s where we found out that we could put the Cost Index application on for the Q400; an application that allows the crew to extract torque and fuel flow factor data more easily than with traditional methods of using tables from AFM (Aircraft Flight Manual), etc. We had increased the number of EFB applications so where to go next?
2016: growth resumed, EFB growing, iPad and iOS issues
This year brought about a paradigm shift in the project. In the first place, the company had started to grow again plus we had started to feel that, with the help of the EFB, not only could we save money from the elimination of printed paper but we could also get some improvement in pilot training and the availability of information at the right time for the right person. Also in 2016, we faced the problem that iOS 9 had been released and, if you had iPad second generation, which we initially had, with iOS 9 it was a disaster, it ran so slowly that no-one was appreciating the EFB project. The crews were using it but no-one liked it because it was so slow. We needed an update and upgrade.
We’ve realized that in 2013 we should have chosen the iPad fourth generation which was available but, on cost saving grounds again, we chose the less costly option as it seemed, at the time, and it quickly has become outdated In order not to make the same mistake again, in 2016 we chose the iPad Pro 9.7 which was supported by Zendure A5 power bank; and we issued these devices to all pilots. We ran a business case for all this process and had it approved financially.
2017: a ‘thank you’ year
This was a ‘thank you’ year because many good things happened to airBaltic for which we are grateful. The first A220-300 aircraft were delivered and turned out to be much more efficient. Management had taken a bold decision to get this aircraft ordered, while it existed only on paper and while the airline was going through its major restructuring program. But the aircraft performs really well, saving fuel and money. Also, while it’s hard to prove the link, passenger numbers increased at the same time that this aircraft came into service because everybody liked it so much.
In 2017, we finally launched electronic charts on the EFB. We organized a trial for the pilots, and their feedback showed that, out of all the proposed applications, they liked the Jeppesen JeppFD-Pro the most for content, for application interactions and other things.
We were also thankful for the arrival of the cheaper  iPad fifth generation which had, unfortunately not been available in 2016 when we purchased 300 devices for pilots but luckily, we now have an opportunity to also introduce cabin Crew EFB in response to cabin crew requests. It was a hard business case to make but we already had Web Manuals for large documentation, we had airBaltic’s own BT EFB reports for e-reporting; so we decided to buy the new devices, put the software onto them, dynamically define forms in our application and get the thing done to replace all the paper for the cabin crew with an electronic equivalent. We managed it successfully.
We already had four operational applications, two supplementary applications plus pilots were allowed to install some other applications at their discretion (not for operational use, of course). With this set-up we were far away from an all-in-one solution that we had chosen initially; but the reality turned out a bit different that we had initially envisaged. All-in-one solutions were too costly for us at the time of cost-saving and restructuring.
Now we had almost everything we needed but we still were not happy with how it all interacted. Each application had its unique interface and all these user interfaces passed our ‘human machine testing’. Basically, it passed AMC 20-25 testing that it works, it is safe to use, etc., so technically is OK as stand-alone solution.
But, if you put all these applications together, workflow for crew turns out not to be very good. All devices have to be synchronized for each duty and the user has to log-in for two of those applications and, with one application, the user has to use a virtual private connection. It’s messy. In light of that, we found ourselves once again considering what to do next. Also, more importantly, we still didn’t have electronic Operational  Flight Plan (eOFP), e-Weight & Balance (eW&B) or eTechLog. That meant that we still might need three more applications and that would be a nightmare. That is why we’re now we have returned to considering an all-in-one solution again.
2018: a ‘thinking year’ and sharing EFB benefits in the business
This year, no changes were introduced to the EFB project apart from adding some additional reports at the request of Flight Operations and other departments, which started to value EFB possibilities. 2018 was a ‘thinking year’ when we ran an RFP for our eOFP application and benchmarked many companies, just in order to understand what kind of options are available to us currently.
Figure 2
… for A220-300 and Q400 aircraft while, for the Boeing 737s we have FlyPad trays because there are side clips available in the 737 cockpits; so it makes sense to use them. We also provide Zendure Power Bank back-up power but we use it only on the ground. On an application level, we have Web Manuals, BT EFB, Jeppesen FliteDeck Pro, DS Performance and Cost Index. 
One thing that our back office and pilots both like is the Web Manuals facility to move between manuals (figure 3)…
Figure 3
… where the user just presses on the hyperlink of a page in another manual and is redirected straight to the specific page. 
Figure 4 is unique to airBaltic, it is our own BT EFB reports application (figure 3).
Figure 4
It features the dynamic form builder which means that we can dynamically define everything: how the label will look, how the content will look, what kind of fields are accepting only numbers and which fields accept only letters; we can also define some conditions, meaning that, if the user is specifying one set of information in one field, the other field renders this information; so it’s kind of a look-up thing. If, as on the figure, the pilot enters flight BT 107 at the top, the system automatically prepopulates all relevant information for this flight on the screen. That’s a functionality alongside the dynamic forms which we are utilizing and with which we are planning to replace standard printed Briefing Sheet.
Figure 5
… the application that our crews most appreciate because of the subtle thinking around it, for the content in the charts and  for the user interface. Plus working with Jeppesen is easy – they listen and respond to feedback.

Figure 6
… Performance Calculations built in SCAP Fortran Compiler on iOS meaning that, once the user presses the ‘calculate’ button, it instantly calculates everything: of course, subject to SCAP computational speed. It runs the SCAP calculations in the background to give flight temperatures, optimizers and, if there are no optimizers within the SCAP, Dynamic Source can also build their own optimizers.
Figure 7
… that’s the main screen which allows the user to select  some specific inputs like ‘flight level’, ‘wind’, ‘temperature’, ‘weight’, ‘distance’ from which, as an output there are optimum speeds, torque and fuel flow factor. The other thing that readers might notice is ‘level change’ (bottom of the screen) which allows the crew to understand the impact of flight level changes. It delivers information to pilots to help them make informed decisions.
So, what does 2019 hold for us? Fuel prices are now rising; which means that next year’s budgeting process will be a challenge and we’ll need to cut costs again; our ambitious plans for EFB might be on hold again. However, we’re OK with that now. During our EFB project years we’ve learned what is really important. Initially we were thinking that the main goal of EFB is to improve the back-office procedures with the removal of paper. Then, how to improve pilots’ lives by introducing pilot assigned EFBs and good hardware. Now we are finally smart enough to think about the whole process from the company perspective and ask ourselves – “what does company really needs at this moment”? If the company needs us to cut costs and put everything on hold again, we’ll comply.
We’re not fully electronic yet at airBaltic. Aircraft performance, large documentation, reporting and charts are all electronic while Briefing, OFP (Operational Flight Plan), W&B Loadsheet and TechLog are still paper. But we’ve learned a lot. Here are some take aways from our never-ending story:
  • Talk to your software providers, one of the most important things. We initially went for an all-in-one solution, then jumped to ‘single functionality/single application’ solutions but we’re now again searching for an all-in-one solution. If you talk to your software provider, you’ll get a better picture of what is coming which will influence your long-term decisions.
  • Talk to your colleagues because, if you’re thinking inside the box of five managers, then it might not represent the full scope of what the whole company needs. Get feedback from pilots, from cabin crew, from everyone. 
  • Consider alternatives while you go; although you might be constantly speaking to current software providers, look around; many vendors are presenting solutions on platforms such as Aircraft IT Webinars, and they’re all doing a great job because they provide many functionalities and might be the one you need. Just go, see and understand how you can combine all of those.
  • Accept changes peacefully.
  • Don’t get mad if things seem to be going in circles because you don’t know what will happen and, as I mentioned above, the main thing is what the company needs.
  • Don’t rush with decisions because the grass will always seem greener on the other side.
  • Plan long term.
  • Be ready to cancel all your careful long-term plans and make short-term adjustments.
  • Then reconsider your whole project and re-plan long-term again.
  • Don’t blame yourself for that – it’s normal.
Our EFB project at airBaltic might be not as advanced as others and we are far from calling it ultimate success. But during our never ending journey we have gained experience. Positive or negative, it is still an experience, always invaluable and we’ve been happy to share it with you in this article.
Contributor’s Details

Andrejs Cupecs
Andrejs Cupecs has joined airBaltic in 2011 as Flight Operations Engineer, responsible for Weight and Balance and aircraft Performance. Andrejs always had a passion for improvement and optimization of existing processes; therefore he decided to switch to an EFB Specialist role in 2014. Being responsible for the EFB project at airBaltic, Andrejs primarily aims for simplification of crews’ day to day activities. 


Taking the best practices both from traditional network airlines and low cost carriers, airBaltic operates direct flights out of all capitals of the Baltic States. The airline offers convenient connections via North Hub Riga to its network spanning Europe, Scandinavia, Russia, CIS and the Middle East. The fleet currently includes 34 aircraft of four types – Airbus A220-300, Boeing 737 – 500 & 300 and Bombardier Q400 NextGen.

Comments (0)

There are currently no comments about this article.

To post a comment, please login or subscribe.