|Case Study: Preparing to Implement an ETL / ELB at AeroLogic||Nils Oehlmann, Project Manager, AeroLogic||View article|
|Long-term maintenance; who will secure the future?||James Elliott, Director of the MRO Product Line, IFS A&D||View article|
|Case Study: Air Canada get an App for it||Keith Dugas, Manager of Excellence, Process & Technology, Air Canada||View article|
|Case Study: The move to a Modern Maintenance Management System at Cape Air||Isaiah Herrick, IFS Maintenix Program Coordinator, Cape Air||View article|
Case Study: Preparing to Implement an ETL / ELB at AeroLogic
Author: Nils Oehlmann, Project Manager, AeroLogicSubscribe
Preparing to Implement an ETL / ELB at AeroLogic
Nils Oehlmann, Project Manager, AeroLogic and Udo Stapf, CEO, CrossConsense share the implementation of a paperless log book
From the perspective of a small cargo airline, we’d like to share with readers the electronic log book project and implementation at AeroLogic. But first, a brief introduction to the airline that is the subject of this case study.
AeroLogic is a small German cargo airline operating ten Boeing 777 freighters. The business was founded in 2007 and flight operations commenced in June 2009 with eight brand-new B777 freighters. It’s a joint venture between DHL Express and Lufthansa Cargo, flying to 27 destinations across three continents; Europe, Asia and America. It’s an extensive network for a small airline with the mission statement ‘Efficiency, Punctuality and Innovation’. The focus in this article will be on that last point, innovation. The way the airline is structured is as a simple production platform with no sales, marketing or MRO functions. Everything is outsourced with sales and marketing all undertaken by DHL and Lufthansa Cargo. That simple structure favors the fast realization of projects although it also creates challenges.
e-Ops PROJECT HISTORY
The e-Ops project was started just over three years ago with an e-Enabled Aircraft project. However, thinking about it, the question that was asked was; while it’s nice to have an e-Enabled aircraft, what could be done with it? So the airline combined the project with its digital Ops processes and relaunched the e-Enabled project as Project e-Ops. Notwithstanding that, the question remained, why e-Enable a freighter when AeroLogic was already a successful and cost efficient cargo airline; why change what already worked? Part of the answer was that, using Boeing 777s, the airline had a very modern fleet but was using quite old-fashioned processes with paper based systems such as the Operating Flight Plan, the Techlog, load sheets, etc. Also documents and manuals were mainly paper based. It wasn’t very state-of-the-art. Communications were also dated – the ACARS protocol having been introduced back in the 1970s – which was becoming quite expensive against the likes of SMS (Short Message Service). And, last but not least, data loading was still being achieved using floppy discs… it was not at all 2020!
The scope of the e-Enablement project was, in the first place, to reduce fuel use, to reduce the complexity of processes, to enhance safety and to improve the innovation potential. As you’ll see in figure 1, the brief concept was that everything should go via the Internet with communication via Cellular and Satcomm.
It might best be categorized as three sub-projects:
- Connectivity: this covers the flight deck; data transmission from the aircraft to the company network (a basic requirement for paperless processes); ACARS over IP; and dynamic weather and route optimization which is especially important for long haul flights, in order to reduce fuel use with consequent impact on contingency fuel calculations.
- Data management: which includes storage of data on the aircraft and integration with the aircraft systems; storage of data, documents and manuals; Aircraft Integrated Data (AID) including aircraft data output (e.g. GPS); and data traffic management.
- Paperless and digital processes: which are the real value added benefits to be gained from the project with the accompanying implementation of new apps and redesigned processes such as EFB/EFF (electronic flight bag/electronic flight folder); electronic briefing package, OFP (operational flight plan) and load sheet; plus, the subject of this article, eTLB (electronic technical log book).
eTLB BUSINESS CASE
All AeroLogic aircraft are on an operating lease and so a marginal condition for the business case was to achieve break-even before the end of the lease period, i.e. within two years. It’s challenging but, as figure 2 shows, the airline expected to manage that if the implementation could be fast.
The guidelines for the business case with this project are that it has to have a commercial benefit for the shareholders and, of course, it must also offer an improvement for the Operations department. In the case of AeroLogic, because everything is sub-contracted, it’s quite easy to put figures on the real benefits, the amount of savings. The main savings in this type of project come from the reduction in manual data recording and archiving but, again, the beauty of the set-up at AeroLogic is that real figures can be attributed to these things. Also, there is the elimination of hard copy paper techlogs and the handling of the dirty fingerprints (DFP). The old process was to print out the techlogs; distribute them; then the MRO had to stamp them, remove the copies, scan them, mail them, archive them… these processes can be reduced using the electronic techlog. It all comes together as a much leaner process design that will, hopefully, be less error prone, and the availability of real-time aircraft status to support enhanced transparency.
Guiding principles for eTLB implementation
The key objective for this project is to keep it simple: AeroLogic is a small airline so more hands-on, therefore the project went for quick wins, to harvest the low hanging fruits and, from that, learn lessons. A lot of airlines and operators are always customizing their IT but sometimes it’s good to leverage the experience from a wide customer base and simply design the process according to the IT. Minimum effort is, of course, always a given but AeroLogic was also able to include access to shareholder projects, i.e. what are DHL and the Lufthansa group doing that might inform this project? Of course, there is no question that remaining safe and secure should be the primary guiding principle but, when undertaking a project like this and during the transition from one process to the next, it’s important to ensure that there are no impacts on Operations, including with IT, network safety and security. And last but not least, you don’t want to have an isolated solution; so yes, you want the quick wins and the low hanging fruits but also it is important that the new solution be scalable to support future developments in the business, to be integrated into aircraft systems or whatever.
THE SELECTION OF CROSSMOS
CrossConsense is already a business partner with AeroLogic, providing extensive AMOS support. The AMOS support is a great benefit and, because CrossConsense is delivering that, they already understand AeroLogic’s processes; which has helped with this project. Another factor was the option to join the Lufthansa group Framework agreement which is of both practical and commercial benefit. Looking to the solution itself, the concept was already proven when AeroLogic was considering it, having been live at SWISS for some two and a half years already and where the simple straightforward approach of CROSSMOS® had already been proven in SWISS’s on-board IT setup which is similar to that at AeroLogic. There was also the bi-directional AMOS interface which was very important for the airline. The CROSSMOS concept was found to be flexible and adaptive, such as in the software configuration which comes with a lot of parameter settings allowing the user to adjust it – for instance, the cabin client is unnecessary for a cargo airline. This owes a lot to the fact that CROSSMOS is an agile developed software methodology (figure 3) that anticipates the need for flexibility and applies a level of pragmatism into the delivery of the finished product.
Also, the concept is flexible in terms of the hosting and IT infrastructure. During the negotiations, the IT department at the airline came up with some rules and policies such as that some critical systems would have to be internally hosted and CrossConsense was able to comply with that, allowing CROSSMOS to be hosted internally on AeroLogic servers. Last but not least again, the Lufthansa group customer community includes a lot of airlines implementing CROSSMOS and CrossConsense solutions so it would be beneficial to share experiences, define common standards and push developments.
CROSSMOS IMPLEMENTATION AND SETUP
Overview of infrastructure
This is very straightforward for the go-live. For the initial phase the goal was to simply remove the paper TLB against an electronic version.
The plan was to put two stand-alone eTLB devices as loose equipment on-board. One as the eTLB cockpit master (figure 4) and one as a slave, used by maintenance and as spare to the master. Although there are already personal crew devices onboard the aircraft they were not involved in this first step. That ensures that AeroLogic fulfills the Part M requirement that data remain onboard and are accessible at all times plus there is a back-up solution in place as well.
However in a second step Aerologic is planning a much advanced setup to make it easier, at least for the cockpit crew, to use just one device instead of several devices and to have a platform independent client which is then installed on all kinds of devices, including external devices, while the eTLB data are stored on the aircraft itself. In this system, the eTLB devices use Windows OS with only CROSSMOS installed.
There were, as with any project, a number of challenges which had to be faced during this project
Change management is always an important part of any project. One of the challenging changes in this project has been for people to re-think digitally. Everybody was handling paper and was used to that, which can make it harder to envisage how easy it could be to move to a paperless digital format. AeroLogic was fortunate inasmuch as the people at CrossConsense had experience of this phenomenon and so were able to assist in challenging the old paper-based processes and to help users adapt to a more digital approach. During the design and definition phase, it can sometimes be really difficult to move people away from a process with which they are comfortable to something different. Then, of course and especially with the techlog, there are many stakeholders involved; so there was a cross functional project team with everyone coming with their own requirements which was sometimes a challenge in itself.
Sometimes an airline will need guidelines on how to implement, for example, sign-off procedures and, at the time of writing there were no guidelines on these sorts of things, or any real idea on how to handle these digital processes, available from the LBA (German Civil Aviation Authority) with respect to an eTLB. Several more things needed to be addressed including the paradigm shift from paper-based to digital processes and the fulfilment of Part-M requirements.
Onboard internet connectivity
This is the basis for data transfer and so the basis for any kind of digital process. That might seem obvious but the implementation still takes time and can be tricky.
Data safety and consistency
There is a master and slave setup (see above) and the airline had to be sure that the data are always reliable, that there is only one database and that there is consistent data. This also is very important for the connectivity between the aircraft network and the ground network. So a consideration has to be how to handle and how to secure this data traffic.
Electronic archiving was an issue for AeroLogic, not only with the authority but also from the lessor who had to agree to accept electronic originals. This seems to be an issue; to ensure and to confirm that the electronic documents in the system are safe from revision. Then there are the back-up procedures which we’ve called the Habituation effect; SWISS, as we’ve already mentioned, have implemented their CROSSMOS electronic techlog and the feedback was that they have connectivity for about 98% of all cases which means that users quickly get used to the connectivity. But if there is an electronic process in place, it’s still important to think about the back-up procedures and it’s also important to train on those back-up procedures because, in the event that there is not connectivity (that 2% of the time) it could become a problem. It was also important not to forget the approved paper-based processes. If there is ever a full system failure or devices get stolen or any other such incident, the crew and maintenance staff must still be able to work on a paper base; so those processes mustn’t be forgotten.
The last thing is to prevent operational impacts and delays. This refers to training; it’s important to make sure that everyone knows what to do because it is not acceptable to have a delay or Operations impact because somebody is not trained and cannot handle the new electronic device.
In some airlines, a few people have been really resistant against any type of electronic process. So, the important message to get across is that, notwithstanding all of the above, when the implementation is done and new system is in use, things will be easier and faster than they are today.
CROSSMOS AT AEROLOGIC
In figure 5 you can see a diagrammatic representation of CROSSMOS Flight Cycle as used in AeroLogic.
At the top you’ll see a module that is always accessible for the authorities, for third-party maintenance, for anyone allowed to enter the cockpit and open the techlog. That module is the aircraft status with a time line where some important information such as fuel uplift, last legs flown as well as ‘history’ can be seen. The history can be adjusted to the airline’s needs – last 60 days, last 120 days, etc. There has also been a request from the authorities in the AeroLogic case that this has to always be accessible with no login required, that is without the need for a user name or password, just as the paper logbook would be.
The Flight Cycle
The full cycle starts with the pilot’s login, at which point, the first thing he sees is the aircraft status. He can then initialize the flight, the system has usually preloaded flight data from the Ops system or, if it’s connected to the EFB on board, that will have the flight data already loaded and can simply transfer it. Once the pilot is happy with the status of the aircraft, he accepts the flight, following which there is one legally stipulated synchronization process that has to happen which is a process to leave data on the ground before take-off, and entails synchronizing the current aircraft status with the ground. If that cannot be done because there is not connectivity everywhere, there are routine back-up processes covering everything. Once the aircraft has taken off, the system is in Inflight Overview where the pilot can enter complaints, enter remaining fuel data, de-icing, whatever is required. Also during the flight, if there is a cabin device connected (not the case for AeroLogic but available for fleets that carry passengers), that can collect complaints from the cabin and send them automatically to the pilot device to ensure that the pilot gets everything; complaints from the cabin might be safety relevant. Then, after closing the flight there is another automated synchronization of data to the ground server and the back-end system, and to get fresh data from the back-end system in a full two-way interface available between the back-end system and the techlog. This can only make sense when the system is paperless.
Nils Oehlmann is Project Manager at AeroLogic CAMO department and leads the electronic logbook implementation project – as part of the paperless cockpit project e-Ops. He studied industrial engineering at Technical University of Dresden and joined AeroLogic in 2012. With the decision to implement AMOS, Nils took over the project lead for the AMOS implementation in 2015. He took over the project e-Ops, comprising e-enabled AC and digitalization of ops processes.
Udo Stapf is the founder and CEO of CrossConsense. He has worked in the aviation industry since 1990, starting as an aircraft line and base maintenance engineer and AMOS integration specialist. After he completed his degree as a business economist he worked as a logistics manager for a German charter airline until he founded CrossConsense 2002.
AeroLogic is a German cargo airline based in Schkeuditz near Leipzig. It is a joint-venture between DHL Express and Lufthansa Cargo which operates scheduled international and long-haul cargo services with its fleet of 10 Boeing 777F aircraft. AeroLogic’s operations are broadly divided in two. From Monday to Friday it mainly flies to Asia, serving the DHL Express network. On weekends, it mainly operates to the United States on behalf of Lufthansa Cargo.
CrossConsense has a long tradition in providing support for AMOS. With a background of more than 20 years’ experience assisting the aviation industry to use and apply this comprehensive software solution for maintenance, engineering (M&E) and logistics needs. CROSSMOS is an electronic technical logbook (eTL) using a service-oriented architecture with modular and exchangeable components, exchangeable interfaces and separately updateable software modules: its aim is to become the standard electronic techlog solution.