How does that old saying go? The only thing that stays constant is change. This is true in commercial avionics, where we have seen a steady progression from analog to digital components.
Change is evolutional or revolutionary. Evolutional change is a steady progression of changes, whereas revolutionary change is a sudden leap — a staircase vs. an express elevator. Nearly all the change we experience is evolutional. This is also true for most of the changes in avionics.
Today’s avionics are a combination of distinct hardware and software parts. A software upgrade without any associated hardware modifications can change the capability and functionality of a component. Imagine, as the evolution continues, future avionics systems may be a series of identical computers differentiated only by software.
The airlines have benefited from the avionics evolution. The separation of hardware and software has reduced our spare requirements and lowered our operating costs. But I believe our on-aircraft maintenance practices have not kept pace. To catch up we need a “revolution” in our line maintenance procedures. Our procedures should include a process for troubleshooting of software.
With today’s procedures, aircrews notice an avionics event and enter the event as a discrepancy in the aircraft logbook. Maintenance will respond by accomplishing the Aircraft Maintenance or Fault Isolation Manual test procedures. These procedures will determine the functionality of the hardware. If the hardware fails, maintenance will remove and replace the failed component, successfully perform the appropriate operational tests, and clear the discrepancy.
What if the event was the result of a software anomaly and the component passes hardware test procedures? Maintenance will note the operational or systems tests were in accordance with the appropriate maintenance manual, clear the write-up, and release the aircraft for service. Often with software problems, the event will occur again, leading to another logbook entry. Maintenance performs the test procedures and the component passes again. The aircraft is again released for service. This cycle will repeat itself until, out of frustration, maintenance removes and replaces the component. Most of these components return from the shop with no fault found.
Most of today’s maintenance practices test mainly the hardware. Troubleshooting ends once the hardware passes the required tests. I believe the troubleshooting needs to continue beyond hardware testing.
I realize that software troubleshooting or analysis is not a line maintenance function. I’m not even sure it should be considered an airline function. Software troubleshooting is an engineering function, which should occur at the airframe or avionics manufacturer level.
How do we close or bridge this gap between flight line hardware troubleshooting and engineering software troubleshooting? I do not have an answer to that question. But, whatever we do, we will need to balance the troubleshooting process against the increased workload of line maintenance or engineers performing software analysis.
Soon we may be able to follow an example set by a major software manufacturer. When a software fault occurs on my desktop, a box appears explaining that a fault occurred and asking if I would like to send a report to the home office. If I click yes, a report is sent with details of the discrepancy. Maybe we could accomplish something similar on the electronically enabled aircraft/avionics of the near future. These aircraft will be able to directly connect to an airline’s wide area network. When hardware troubleshooting procedures find no faults, the mechanic could push a button and generate a software report. The aircraft would then electronically submit this report directly to the airframe/avionics manufacturer for analysis.
Adding software troubleshooting procedures to legacy aircraft is more challenging. Perhaps maintenance manual troubleshooting procedures could be updated to require fault data downloads. The airline would forward these downloads, through an established formal reporting process, to airframe or avionics manufacturers for analysis. It may be possible for airline engineering to accomplish an initial download review, using a software analysis tool. This tool, developed by the component manufacturer, would allow airline engineering to perform a quick data review to support line maintenance troubleshooting. These procedures would be added to the maintenance troubleshooting process only when technically possible.
Phil Hardy is a master engineer for avionics engineering with Continental Airlines.
To contribute to Avionics Magazine’s Perspectives column, contact Bill Carey, Editor in Chief, at (301) 354-1818 or [email protected].