Electronic Techlogs (ETLs) or Electronic Logbooks (ELBs) seem to be flavour of the month at the moment. At the recent Aircraft Commerce Airline & Aerospace MRO & Operations IT Conference in Heathrow we were inundated with requests for demonstrations and enquiries regarding our solution. We were not the only provider exhibiting, but certainly our solution is probably the most mature and heavily used system that was being demonstrated at the show. It strikes me that there is a lot of interest coming from operators and MROs regarding electronic techlogs and there are a lot of providers who are offering solutions (or working on one), but there is still a major shortfall in live, working systems. Buyer beware! There is a significant effort to take a proof of concept to a practical solution – don’t under estimate the effort required to get your paperless techlog procedures approved and flying. In order to provide some insight to what goes in to running a paperless techlog airline I’ve prepared some questions you should consider asking your potential vendor.

How many aircraft are flying with your solution?
There are a number of great looking systems available from reputable providers which on the surface seem to be off the shelf ready for use electronic techlog solutions. However the reality may be that system is undertaking limited trials with one or two aircraft, or even not flying at all. In my opinion an extended trial of several years in 3 aircraft for a major carrier does not represent a working solution. Why has the solution not already been adopted across the entire fleet? Admittedly every system has teething problems – ours included, but if a system has been on trial already for several years, how much more effort and investment is required to achieve tipping point. Our electronic techlog is used on board all Thomas Cook UK aircraft in a mixed fleet of 31 aircraft as has been the case since we took over the contract 12 months ago.

How many sectors are flown with your system?
A trial solution may not be in permanent use or may be only used on certain sectors or at certain destinations. A mature solution like ours will be in permanent use on all aircraft on all routes regardless of destination or operational constraints. Our system has successfully transmitted over 30,000 sectors from dozens of destinations in the past 12 months.


This is what 30000 sectors looks like when overlaid on a map of the world. Blue dots show destinations with 100% transmission reliability, whilst traffic light colours show airports that have had issues with comms.

What procedures are in place in case of poor comms?
Although it is true that mobile communication networks are becoming more and more sophisticated and ubiquitous, there are still a significant number of challenges with running any kind of mobile IT system in areas outside of your own control. Connecting to your servers from your own hangar or your base airport is one thing, but achieving this 100% of the time from far flung parts is the world is something that cannot be relied upon. It is our belief that mobile applications for aviation need to work natively in an offline mode and only connect during synchronization or transmission mode. In the case of an electronic techlog your procedures need to reflect this and provide a backup solution when a transmission is not possible. UK regulations dictate that the techlog needs to be “left on the ground”. A successful transmission satisfies this requirement, but if a transmission is not successful then an alternative is required. Our procedure is to connect a printer and leave a printed copy on the ground. In the very rare occasion that this fails then a stand by paper techlog is used. If the hardware device that the electronic techlog is running on should fail, what procedures are in place to restore the techlog on another device? Our solution involves the local client database being mirrored onto an SD memory card, which if removed will disable the software on the host device and when inserted into an alternative device will automatically promote that unit to the electronic techlog.

In all my years working with mission critical software I have learnt that procedures are way more important than lines of code. The electronic techlog is no exception, and with such a heavily regulated system the procedures that you and your vendor have in place to allow you to migrate to a paperless techlog are doubly important. If you would like to find out more about the Conduce electronic techlog solution, please get in touch to request a demonstration.