The move from paper – Part 2

Rob Woods, Head of Engineering, Air Arabia Maroc and Dave Cooper, Line Maintenance Manager, British Airways Cityflyer share their experience with digitizing the Aircraft Technical Log

In Part 1, we considered what an electronic techlog has to do, some of the challenges involved in switching to a digital electronic format plus the benefit and values that can be realized for airlines that do make the change. In this Part 2, we’ll look at the process of implementation with some practical advice gleaned from our own experience of introducing electronic techlog solutions into working airlines.

Assuming there is sign-off on the internal business case there is only the small matter of how to go about implementing an ETL.

Project Scope

There are many airlines that embark on an ETL project that never manage to get passed the initial assessment stage because the project team ends up juggling the competing requirements from within the organization. These are often based on good ideas but are essentially new requirements. That is to say, not something that was done with the paper techlog. This causes unnecessary problems for the Project Team and the changing requirements become an insurmountable issue. And that is even before the local Aviation Authority becomes involved. Many of the good ideas may also cause problems from their point of view.

So, our advice is:

• The first step is to replace the paper techlog with an ETL – that’s all. Don’t make the brief any more complicated than this (Bells and Whistles can come later).
• Find a solution that does that well and offers flexibility for the future. The first hurdle is implementing a replacement techlog that is acceptable to the airline and the authorities. Keep it simple.
• At each juncture, when asked to add more functionality, compare it to the paper techlog. How does the airline accomplish the same thing at the moment? Does it need to change? If it is not needed place it outside the scope of the initial project.

This is not to say that certain changes cannot be introduced from the outset. However, these should be a conscious divergence from the current process and for specific business reasons. Once those changes are agreed, the scope should not change. It is also worth noting that the internal project team will make a huge difference to the success of the implementation. The right team will be able to drive the project with a clear vision and will not be side-tracked by scope creep. Sometimes the key stakeholders are not the obvious choices. Perhaps involve both a ‘champion’ and a ‘sceptic’. As long as it is approached in a professional manner this can provide balance. As an aside, in our experience, a converted sceptic is often the best project champion you can have.

Choosing a Solution

There are a few ETL solutions in the market and many more EFB solutions that claim to have an integrated techlog component. What should an airline look for?

The fundamental requirement is that the solution is fit for purpose. This is why the focus of the project is important. If you are looking for a solution that is a hybrid of a Flight Bag, a techlog and a handful of good ideas, then you are creating a headache. Not just in finding a solution but also in having it accepted by the Authority. If, on the other hand, you are focused on replacing the paper techlog with an ETL, the question of whether a solution is fit for purpose becomes somewhat simpler. It also becomes simpler to talk about internally (within the airline) and with the Authority.

As has been highlighted earlier, there are a few areas which are different for an ETL and have to be considered to determine whether a solution is fit for purpose (see Potential Problems). Questions to ask to cover these are:

• How is the tablet PC (or laptop etc.) going to be charged? On the aircraft? Via battery swap? If by battery swap, are there charging banks available to have at the line stations? What issues does that cause at the line stations?
• What happens if there is a software failure? The solution must provide multiple mechanisms to recover from problems such as software freezes and data corruption.
• What happens if there is a hardware failure? Again, how the solution copes with these situations is vital. It is a quick thing to replace an ETL? Is there a backup and recovery mechanism? Should there be a store of spare units and where should that store be?
• How does the solution cope with not being able to transmit data? Whilst software crashes and hardware failures may be rare, it is almost guaranteed that some locations will be impossible to transmit from.

It is not always possible, but ideally a solution with a proven track record should be sought. This should ensure that the solution has been tested in real world situations. It also means that the supplier knows how to support a solution in service. This latter point is key. It is one thing to write a software solution that captures some data. It is quite another to create a solution that is globally supportable in an operational environment.

A Solution that Fits

We are not going to discuss the specifics of the ETL solutions in the market. When we say ‘a solution that fits’, we really mean ‘a solution provider that fits’. You do not have to dig deep to find examples of airlines with bad experiences. The relationship with an ETL supplier is going to be long term. The airline wants it to be long term because they want stability, but it should also be a good experience. You want as little to go wrong as possible, which means looking for a supplier that takes pride in what they offer.

Choose wisely.

Plan your rollout

On the one hand, introducing an ETL has similarities to any project implementation, so we will not focus on the general activities. However, there are some specific considerations for an ETL rollout and these are discussed below.

This is obvious, but the timing is the important thing. Each authority has a slightly different stance on solutions like the ETL, and each local representative also has their own view. So the decision on when to engage the Airworthiness Authority has to be up to the airline because they will already have a working relationship. However, earlier involvement in the project will help ensure that the solution meets their requirements and will simplify the acceptance of the new approach. As mentioned above, focusing on a replacement of the paper techlog should simplify discussions.

As part of the implementation, the Authority is likely to request a dual-running trial. This simply means using both the existing paper techlog and the new ETL for a defined period. The duration will vary from authority to authority and will change as more ETLs are introduced. The purpose of the dual-running period is to compare the data captured through both mechanisms and demonstrate that the ETL is fit for purpose.

The decision on how the ETL will be charged and maintained will have been taken. If the airline is charging batteries at stations, then appropriate preparation tasks should be underway:

• Battery charging banks ordered;
• Extra batteries ordered (for swap outs);
• Specific instructions to flight crew and line engineers regarding when batteries should be swapped.

If the ETL will be charged on the aircraft, then a similar set of instructions should be agreed as to when the ETL should be placed on charge.

The hardware to be used by the ETL will depend on the chosen solution. However, lead times for ordering PC Tablets, etc. need to be planned into the implementation project. This will commonly involve purchasing (with variations depending upon the solution):

The Techlog procedure will need to be amended to cater for the failure scenarios and maintenance actions (such as battery charging). The failure instructions will depend upon the chosen solution.

The degree of training required (and type) will depend upon the airline. However, the ETL solution should be relatively intuitive to use. Remember that the solution should be sympathetic to the existing techlog procedure unless the airline has chosen to alter it. So the ETL should feel familiar to the crew. The common approaches are:

• Classroom training and demonstration;
• Video or online presentations;
• Hands on use in crew rooms.

A techlog will normally have a history of sectors for the aircraft. This allows the crew to look back at sectors and defects. The ETL is no different and as part of the implementation preparation some sector history will need to be loaded for each aircraft. This will usually be sourced from the records of the Maintenance system (but may be manually entered from scanned records). The number of sectors to hold as history is defined by the airline.

We suggest going live in phases focused around a common pool of flight crew (for example, the short haul aircraft). This is really driven by the logistics of introducing change, and taking this approach allows the airline to focus training effort on a group of employees. It is not quite as simple to target a group of line engineers and the reality is that all the line engineers working at the stations (for the chosen phase) will need to be trained. During the go-live day someone (or a team depending upon the volume of aircraft) should be stationed at each hub to perform the ETL implementation. The implementation team will be responsible for the preparing the ETL for the go-live sector:

• The team will have a schedule of aircraft arrivals for the hub.
• An ETL unit will prepared for deployment on each aircraft coming through. Each unit should be charged, connectivity set up and ready for going live. Each should also be pre-populated with the appropriate aircraft history.
• The history will not be complete (because of the lag in inserting the data into the Maintenance system) and the implementation team will need to input sectors from the paper techlog in preparation for go-live.
• Once the history of the ETL is current the unit will be ready for go-live.
• The ETL is handed to the captain and the implementation team should (if possible) stay as they complete their first sector.

So the question still stands. Why is Aviation so far behind other industries when it comes to digitizing and transmitting live records? What are business leaders really scared of? The business solutions are available now and thanks to many lessons learned in the early days by industry pioneers it has all become a whole lot simpler.

Jump in… the water’s lovely!

Cameron Hood led the technology team involved in the very first implementations of electronic techlogs through CoreData which was subsequently acquired by Data Systems and Solutions (at the time, a joint venture between SAIC and Rolls-Royce, which then became Optimised Systems and Solutions and is now known as Controls and Data Services). Cameron is the founder and owner of NVable, who have developed a new platform that offers electronic techlog and more.

Rob Woods has been involved in the implementation of electronic log book solutions supplied by Data Systems and Solutions at Mytravel and, subsequently, Thomas Cook. He has experience of being involved at the leading edge of the introduction of new technology and has the battle scars to prove it which well qualifies him to understand the introduction in his position as Head of Engineering at Air Arabia Maroc.

Dave Cooper has been involved in the introduction of the Electronic Techlog (eTechlog) across a fleet (initially with the Data Systems and Solutions version) and a transition to the new eTechlog from NVable. He has experience of the challenges in managing the changes which has given him particular insight into what is important in a solution for his position as Line Maintenance Manager at British Airways Cityflyer.

Set up as a joint venture between Moroccan investors and Air Arabia, Air Arabia Maroc is a low-cost airline operating out of Mohammed V International Airport, Casablanca to mainly European destinations. The current fleet consists of four Airbus A320-200 aircraft.

BA CityFlyer, British Airways’ wholly owned subsidiary, operates a fleet of Embraer 170 and 190 aircraft from London City airport and London Stanstead airport to UK domestic and European destinations.

Clients have been placing their trust in NVable to help find and deliver real business solutions using information technology (IT) for over 10 years. The portfolio spans consultancy and software services with end-to-end solutions that work based on the company’s CoNVerge platform designed to integrate established databases and new solutions such as eTechlog.