Case Study: Electronic TechLog – A Brave New World
Author: Dave Cooper, Line Maintenance Manager, BA CityFlyerSubscribe
Dave Cooper, Line Maintenance Manager at BA CityFlyer on an implementation that kept the faith with technology solutions
Although BA CityFlyer (BACF) bears the British Airways name it is a relatively young organisation. In the current incarnation BACF received its Air Operators Certificate on 8th February 2007 and started operations a few weeks later on 25th March. Many of the team involved during those early days remain with the company and to a degree this still exerts an influence on the culture of the organisation and its desire to innovate.
The business has always been keen to make the best use of technology and during 2009 underwent an assessment of solutions that could improve on the traditional paper techlog process. It was recognised that this would involve some internal changes; however, the internal business case clearly demonstrated the benefits of having techlog information captured digitally and for that data being automatically fed into the MRO system.
Having assessed what was available on the market, the team was convinced that the optimal solution was to have a computer dedicated to the techlog process and that travelled with the aircraft. They did not want a solution requiring hugely expensive aircraft modifications or technology infrastructure. The team also remained unconvinced about combining techlog processes with the various Electronic Flight Bag (EFB) solutions available (principally because the Class 1 and 2 flight bag solutions remained with the pilot rather than the aircraft).
The company took the decision to implement the electronic techlog (ETL) from Optimised Systems and Solutions (OSyS) at the end of 2009. The solution delivered what the organisation had been looking for:
- It was classified as a Class 1 solution, using the Panasonic Toughbook CF-19. This device had the advantage of being designed to MIL-STD-810G and IP65 standards which meant it was rugged. It could also be used as a Tablet PC or as a normal laptop.
- Data transmission was achieved through the mobile phone network using an internal SIM card.
Although the OSyS solution also had a number of EFB modules, the actual ETL application was distinct – therefore BACF could choose to use only the functionality it required. The ETL was designed to fly with the aircraft and the engineer completed the ETL in the same way that they completed the traditional techlog, with the application guiding the user through the process. Once the engineer had recorded and actioned any defects (recorded oil and hydraulic uplifts etc.) the ETL was passed to the captain to complete the fuel uplift, de-icing (if required) and sign the Aircraft Status and Captains Acceptance. The application was designed to require a signature from the engineer or captain at each stage of the process. The signature mimicked the paper process – which meant the actual hand written signature of the user was captured as an image using the Toughbook’s stylus as the ‘pen’. Just as with the paper process, the system did not prevent unauthorised users; it simply provided a way to indicate who had been completing the techlog.
The ETL sector information was transmitted to an OSyS website which allowed BACF users to monitor and view the data as it was received.
Taking the leap
The new solution was introduced in April 2009 and during the following months the OSyS team configured the ETL for BACF working practices; engineers and pilots were trained on the system and live trials were conducted with the CAA monitoring. The system was deployed during commencement of the BA CityFlyer fleet renewal programme in September 2009.
In general the deployment was successful and many of the hoped for benefits were attained. Principally, the data was being captured and validated which meant it could easily be used for analysis. Readability issues disappeared overnight and the techlog data was available almost immediately when transmissions worked. Regardless of any transmission issues it was significantly simpler to ensure a complete airworthiness record was maintained. The visibility of deferred defects made it simpler and more efficient to manage any issues, and the management of Out of Phase maintenance items was also greatly simplified.
The solution was not without its challenges:
- Data transmissions – several problems were experienced with data transmissions. Users found the connection and transmission process to be slow and failed more frequently than was ideal. Some of the failures were down to weakness in the mobile phone network at specific locations but many were not. Many of our issues were self-induced by our own Telecoms Team through the chopping and changing of tariffs.
- Application usability – the ETL became increasingly sluggish to use over time. Changing from one screen to another involved noticeable delays. The problem was identified as being associated with the ever growing application database on the Toughbook.
The ‘on-ground’ support for OSyS ETL was always very good. When required, someone arrived and assisted in any software deployments. However, during three years of deployed solution, one of the key benefits anticipated from the system, the final step of integrating the data feed in the MRO System (Commsoft’s OASES), was not achieved.
Change required but no reversion to paper
During the fourth quarter of 2011, OSyS informed its two ETL customers (BACF and Thomas Cook) that they would no longer support the EFB/ETL and the service would cease at the next contract renewal date – which was May 2012 for BACF. However, OSyS was at pains to emphasise that it would do its best to find an alternative supplier and there was no desire on the part of BACF to return to using a paper techlog. The benefits that had been realized on airworthiness management alone were too significant.
OSyS contacted several potential suppliers to continue the service and selected another UK vendor but discussions on this arrangement did not lead to any further relationship. A decision was then made to have detailed discussions with software developer and vendor NVable about whether a viable alternative solution could be created.
NVable is a small company, which has historically focused on providing bespoke software solutions across many sectors. Many members of the team had earned their aviation stripes whilst working for CoreData and latterly being part of the Rusada Group. During 2011, the company had made a strategic decision to invest in creating its own ‘large data’ handling platform called Appixo, which was ideal for managing an application like the electronic techlog.
A challenging development program
In January 2012 an agreement was reached to create a new solution using the Appixo platform. BACF would assist during the process but the final solution would belong to NVable. Time was extremely short because a solution needed to be able to go live by May 2012. However, several factors gave the project an enhanced chance for success:
- BACF had been through the process of deploying an ETL and therefore knew what was involved from a regulatory and internal team perspective.
- The airline also owned the hardware required to deploy the solution (i.e. the Panasonic Toughbooks and the SIM cards).
- BACF had already been through the process of making software reflect their processes and therefore had very specific ideas on the design of a new solution.
- NVable was familiar with the concepts of the ETL since many on the team had been involved in the very first incarnation of one via CoreData twelve years ago.
- The vendor team were also familiar with some of the specific challenges around coding for mobile phone networks and SIM card interfaces.
That said, the challenge remained significant: although the Appixo platform provided a mechanism for storing and processing large amounts of data, the ETL application had to be developed, tested and trialled for the go live target. Even at that stage there would be one final hurdle. The project required a data migration to be performed in order to give the required history (sectors, deferred defects etc.) to the new ETLs.
NVable spent time with the BACF team to understand the areas that could be improved upon from their old ETL solution. The main areas were usability, speed of the software and transmission rate (and speed). There were also some upgrades to the existing Panasonic Toughbooks that would improve the usability of the solution. The vendor’s infrastructure team worked with BACF on upgrading the hard disks to solid state drives (SSD) to reduce time taken to boot-up the system, plus the operating system was upgraded from Windows XP to Windows 7. Of course, the changes also needed to be tested for any compatibility issues – the team had to ensure that the upgraded component drivers did not create new issues.
With the hardware upgrades in hand the development team worked to create:
- The ETL which is a Windows application that would be installed on the Panasonic Toughbook.
- The accompanying website on the Appixo platform.
- The new interfaces to allow Appixo to receive the data and to forward the data into the BACF network.
Listening to the feedback of BACF the development team at NVable paid close attention to the design of the ETL user interface and included a number of new features to make life simpler:
- Controlled single sign-on across the ETL and website. After confirming the approach was acceptable to the CAA, NVable implemented a standard user/password authentication mechanism for the solution. This gave some immediate benefits. BACF now had centrally managed and complete control over the authorised users of the overall solution. The implementation allows for emergency authorisations (for times that the mobile data network may not be available) by using time-limited encryption to provide extremely controlled access.
- A new recovery facility. Although it is has never happened, it is possible for an ETL to have a complete failure such as a hard disk crash. In such circumstances the techlog will revert to paper to allow normal operation to continue. The recovery facility allows the transmitted history of an aircraft to be recreated within minutes and installed onto a replacement unit which can then be deployed at a suitable opportunity.
- A new ‘catch-up’ mode. To accompany the recovery mode, in circumstances where the aircraft has reverted to paper for a number of sectors (such as described above), catch-up mode provides a controlled mechanism, again using time limited encryption, for an engineer to record the paper data as it was intended. The system records the user performing the catch-up for audit purposes and the facility allows engineering to very quickly record any required sectors so that the ETL is up to date and ready for action with minimal delay.
- Enhanced transmission capability. One of the issues identified by the user base of pilots and engineers was the length of time it took to transmit data prior to take-off (the equivalent to leaving a copy of the techlog on the ground). As any pilot will tell you, those final five minutes are critical, and the last thing they want is to attempt a transmission that might take three minutes to complete… or, even worse, fail. The NVable team focused considerable effort on fine tuning the way the Appixo ETL establishes connections and transmits the data. The end result is that, in the vast majority of transmissions, pilots only have to wait seconds for the confirmation.
- Enhanced two-way data communication. The Appixo framework also allowed NVable to embed more capability for managing data remotely across the ETLs. This means that various data sets can be automatically sent to the ETLs in addition to the basic techlog data being sent back from the units. For example, this capability is used in the central management of users, the application of corrections etc. Generally this process is invisible to users; however, they have the ability to view the transactions if they are really interested.
- Enhanced Out-of-Phase maintenance. The Appixo ETL now provides a simpler way to manage Out-of-Phase maintenance (OOP) tasks across the fleet. Users with the appropriate authority are able create OOP templates that can be applied across one or many aircraft, or across the entire fleet. Of course, an OOP can then be changed for a specific aircraft if required.
During the development process the BACF and NVable teams worked together to ensure that the final Appixo ETL was going to deliver all the desired benefits. There is no question that it was a challenge, but it is a testament to the overall team that the Go Live date of May 12th 2012 was achieved. The Appixo ETLs were loaded with the current data for designated aircraft and went live at three locations throughout the day. Only minor hitches were experienced and, following a few weeks of bedding down, the overall system has been running smoothly ever since.
It is fair to say that the BACF team were surprised with the experience of implementing an IT project of this complexity. This has, in turn, encouraged them to feel confident in embracing new technology solutions.