Technical Components Combined with Data Logging

Historically, the early forms of data logging came from human-based observations that would be recorded in paper-based systems, such as the technical log. For example, during each of the engine starts, the pilot would carefully watch the indicators in the flight deck, and record the temperatures during the moment at which the engine accelerates when a second set of fuel injectors opens, in addition to the post-start ground idle Exhaust Gas Temperature (EGT) values. These values would enable an office-based technical service engineer to compare the engine performance, with additional data (such as engine use since overhaul, oil lubrication consumption, etc.) to estimate the optimal time that the engine should remain in service. An excessively worn engine consumes much higher quantities of fuel and/or oil, produces less thrust and operates at hotter temperatures, while the internal components wear-out much faster. Based on these data collected, the staff in the offices need to carefully balance when it is most effective and commercially advantageous to change either the engine or the relevant components. However, it is worth noting that the paper-based data recording and evaluation system would always be several days late due to the paper processing and normal working office hours. Moreover, if any long weekends or public holidays occured, the closure of the usual office working hours added up to seven days in the delay between the paper recording of the data and the electronic interpretation of the performance.

With the development of the DFDR technologies, it became possible to download this operational data via non-protected recorders known as acquisition units. Early technologies used a device known as a Quick Access Recorder (QAR) (Figure 5.2).

The QAR allowed for the data to be transferred to a removable cartridge, thus allowing the data collected at a given interval, and then the cartridge's data (Figure 5.3), to be uploaded to a database. The drivers for this change were the improvements in technologies (i.e. data storage), but the real driver was the ability to collect live flight data to better optimise the maintenance schedule; hence it was financially driven. If an operator can delay an engine change by a few days to fly the aircraft in revenue service, this will result in a financial gain for the operator. If the maintenance was extended too far, then

FIGURE 5.2

Boeing B737 (classic) Quick access recorder module. (ATM PP Ltd.)

the engine or component may fail, resulting in unscheduled landings and significant extra expense. Thus the duty of reliability engineering and the predictive optimisation of maintenance was shown to be worthwhile.

The limitations of earlier recording devices included the storage capacity of the aircraft-based device. Early units had limited resolution (the ability to record a given data set per unit time) and may had to be downloaded once a day. However, technology and recording capabilities have improved exponentially since the 1970s: operators in the late 1990s were able to download a weeks' worth of on-wing performance data each time, making the retrieval of the data more effective in terms of man hours. In 1999, it was possible to download the flight performance data with a laptop (or desktop) computer module using cables that were connected to the acquisition unit in around 25 minutes (Figure 5.4).

While the recording of data quantity had improved up until around 2001, the task still required a licensed aircraft engineer to book the laptop and cable from the stores, go to the aircraft and download the data weekly.

On 11 September 2001, there was a significant act of terrorism in which multiple commercial aircraft were flown into buildings across the USA. The importance of this event was later reflected in the financing of plane engines. Before 9/11, the majority of carriers leased their aircraft, and likewise leased

FIGURE 5.3

The Quick Access Recorder module and memory cartridge. (ATM PP Ltd.)

the engines fitted to these aircraft. The drawback of leasing an engine is that the leaseholder (i.e. the airline) is liable for the financial costs of the engine, regardless of whether it is working or not. If the engine was being overhauled at a repair station, the lease payments were still liable, and the payments continued until the lessor agreed to accept the asset back from the creditor, and only at this time did the payments stop. The financial liability of airlines post 9/11 was immense, and many airlines changed their engine leasing arrangements with manufacturers to a different financial purchasing arrangement, known as 'power by the hour'. Effectively, the engine remains the property of the manufacturer, and the carrier pays an agreed hourly rate for the operational engine; thus reliability concerns held by carriers were shifted to the engine manufacturer. Engine manufacturers circa 2001 quickly established modern communication equipment, and in order to better maintain their engines they required a new means of technology to monitor engine performances. The engine, after all, is the asset of the manufacturer: how many

FIGURE 5.4

A desktop computer and cable capable of downloading the data from the DFDR. (ATM PP Ltd.)

licensed aircraft engineers, working for the likes of GE, Pratt and Whitney or Rolls Royce are available at a commercial airport?

The simple solution chosen by many engine OEMs was to use the data storage that was part of the Full Authority Digital Engine Control (FADEC), a computer device to control the gas turbine engine. The FADEC records all the operational parameters of the engine, in addition to other performances (altitude, airspeed, temperature, power requested, etc.). The data were obtained by the manufacturer by fitting a communications module to the FADEC. A GSM phone attached to the FADEC would dial the manufacturer's server when the aircraft was on the ground and the park brake was applied, thus allowing the transmission of the data via GSM networks. Many of the major OEMs offering Power by the Hour mandated the fitting of this technology as part of their terms of agreement. The introduction of this communication module allowed the manufacturers to access all the flight performance, trends. This has proven to be a very valuable tool in ensuring that the asset is used correctly, and for maintenance to be optimised.

Live Streamed Data and Radio Communication Technologies

ACARS

In 1978, a new ground to air communication system known as Aircraft Communications Addressing and Reporting System (ACARS) was developed by the Aeronautical Radio Incorporated company as a tool to send data from the ground to the pilots without the use of voice communications. Initially, ACARS services used VHF or HF radio communication, producing paper printouts (Figure 5.5) in the flight deck using thermal paper that looked very similar to till receipts or fax machine printouts.

FIGURE 5.5

ACARS thermal paper print out.

FIGURE 5.6

Photograph of Airbus Multi-Function Control and Display Unit - the interface including ACARS interface.

Likewise, the flight crew could send text messages back to the base station (Figure 5.6), and these systems were able to interface with the aircraft's data- bus system or use predesignated functions to request the weather forecast or company communications. As radio and satellite communication technologies improved, it became possible to send and receive ACARS messages anywhere in the world, including the polar regions, which had previously been too far from VHF radio base stations.

ACARS became more useful to the manufacturers and operators as newer aircraft (B747-400 onwards) allowed the ACARS system to fully interface with monitoring equipment. For example, if an Airbus A320 aircraft system developed a fault in-flight, the databus would record the failure in the aircraft recording system and the ACARS would automatically send a message to the server in Toulouse. Toulouse server would then relay the details of the failure instruction to the operator, and would include details of the necessary parts required to be changed to return the aircraft to commercial sendee - all before the aircraft had landed.

Additionally, ground-based engineers could use a PC terminal connected to the internet with proprietary software to communicate, via the ground- based server, with any aircraft in the world and to interrogate the relevant system. The author has seen first-hand this technology in use in 2004, when he was engaged in research regarding the failure of air-conditioning systems. With the support of a local Airbus technical representative's kind assistance, the author was able to view the in-flight performances of various Airbus aircraft that had recently departed London Heathrow airport for the USA. None of the data requested from the aircraft required any human interaction from the flight crews of these aircraft, rather the request was made to view the air-conditioning system performance, and some three to four minutes later the data were displayed on the terminal screen. The purpose of such a ground-based interrogation was explained by the technical representative 'as being able to troubleshoot those difficult technical issues'. Previously, for some maintenance problems, the only method of fully rectifying the failure was to remove the aircraft from the flight programme, and for a licensed aircraft engineer to take the aircraft, with flight crew, for a test or maintenance flight. The financial implications for this activity were significant: thus the integration of the ACARS capabilities into the aircraft's technical recording system was financially driven.

The weakness of the ACARS system is the subscription-based nature of the service to the data carrier, as well as the quantity of data packets that can be transmitted via VHF transmission. The principle of a robust predictive maintenance system is the availability of data stored in Very Large Data Base's (VLDBs) that can be analysed using mathematical trends and computer calculations. Throttling the data transmission due to the constrictions of the VHF characteristics effectively limits the use of ACARS as a tool to transmit the full data collated from the aircraft to the ground servers that form the VLDB. Additionally, the costs of transmission for a full onboard system, broadcasting all data parameters, would be higher than what the aircraft carrier would consider to be acceptable. An example of this lean approach to data management and subscriptions was highlighted by Malaysian Airlines after the MH370 disappearance. The Malaysian Airlines B777 aircraft were fitted with both VHF and Satellite ACARS communication equipment, yet the subscription, which was around $10 USD per day per aircraft, was deemed too high, so the subscription for this service was not undertaken. In contrast, Air France used this subscription service. When the AF447 aircraft crashed off the coast the of Brazil on 1 June 2009, the transmission of flight information via the satellite systems was instrumental in locating the ditched aircraft on the seabed. While it was not possible to immediately identify the precise location of the aircraft on the seabed, a general region was provided from aircraft to satellite data. This allowed for a smaller search area to be established, and on 3 April 2011, the debris of the aircraft was located at a depth of 4,000 m.

British Airways Engineering Maintenance Management

British Airways understood the need for VLDBs to perform robust data management predictions that enhance maintenance operations. The first significant investment was around the year 2000 with the Enterprise-Wide Scheme (EWS) IT solution, contracted to EDS: some 120 separate IT systems within BA were integrated into a single system that could be interrogated by standard desktop computers (rather than bespoke terminals). In the two years that followed the introduction of EWS, the ГТ system matured, and single solution system became the backbone of BA international operations. The second, more ambitious activity coincided with the completion of Terminal 5 at London Heathrow airport, as all BA aircraft operate from this hub. The plan for data management centred around fitting all the parking stands with brouters (i.e. wireless communication ports). Additionally, BA retrofitted their entire aircraft fleet with wireless communication cards to automatically transmit operational data to their own computer servers. The principle of the British Airways system is to use the onboard data storage previously mentioned. When the BA aircraft parks at the Terminal 5 stand and applies the parking brake, the wireless communication device activates, connects to the brouter and downloads the stored data in its entirety to the BA server. Another difference with the BA maintenance management solution is the ownership of the data. The data are recorded and acquired by the carrier, namely British Airways. In other commercial solutions, the data are acquired by the ACARS subscription service, transmitted to the OEM servers (i.e. Airbus, Toulouse) where the operator may view their own airline's performance data on the Airbus server.

The UK government recognised this significant investment and cited BA's initial set-up costs at £150 million, to make better decisions on out of service dates and economic repairs. Furthermore, the system is reported to have made British Airways a cost saving of around 30%, as detailed in the UK government's report (Transforming logistic support for fast jets, National Audit office 17 July 2007).

 
Source
< Prev   CONTENTS   Source   Next >