"Airplanes broke," "It failed," or the system is "inop" are comments that frequently appear in aircraft flight logs or squawk sheets. This means the pilot has made an assessment based on operating procedures, aircraft feel, or past experience. All are valid in pointing to suspect anomalies. When it comes time for a technical evaluation to resolve the issue, having the right facts is often what determines if the job is completed in a timely and cost-efficient manner.
Acquiring this information has varying degrees of complexity. Many electronic systems include a self-test capability which can encompass anything from a complete system evaluation to a simple test of the means for fault recognition (lights the light). Diagnostics begin with testing and evaluation of operation and function. The best tool to facilitate testing is a proper knowledge of "How is it supposed to work?" Obtaining this simple bit of information can sometimes be more challenging than solving the actual problem.
In many cases airframe manufacturers defer specialized systems to outside vendors, who when contacted can provide an array of facts and figures regarding their equipment but have only limited knowledge on the interface with a particular aircraft. Frequently when the lack of knowledge is associated with having to return the aircraft to service, techniques such as shot-gunning components or swapping parts become the norm. This practice is employed far too often in our industry with airframe manufacturers testing and certifying returned components with as many as 60 percent finding their way back into service with "no fault found."
Knowledge is key
Once again knowledge is the key to success, with an appropriate education including a general knowledge of airframe and avionics systems. Research including device capability and function will provide direction to avenues of opportunity for problem resolution. The philosophy of "we don't have time to investigate" is a common one and most of the time goes hand in hand with "We don't have time to do it right but we do have time to do it again."
Once armed with the proper knowledge, a precise description of the malfunction, and appropriate testing devices, a plan can be created to uncover the culprit.
Living in the digital age gives us a definite advantage; technology can provide significant insight to problem resolution, and many devices have the ability to record and store faults. Unfortunately when internal diagnostic systems are used and their capabilities are not fully understood, the results may not provide the sought-after solution to the problem at hand.
Self-diagnostic systems
Of the self-diagnostic systems currently in use many utilize the "Signal Out of Tolerance" (SOT) concept to detect component faults. The principle here will program the fault detecting unit to recognize a problem with a component due to a voltage or current flow being outside the programmed range. Oftentimes this technology fails to detect wiring issues relative to remotely mounted sensors. In other words, if the wire breaks there will be no current flow in the monitored circuit and the detecting device will declare that the sensor has failed. Now when the component with the fault reported is replaced the system will still have a problem. In fact probability is high that the component installed may even have had documentation reporting that it was one of those from the "no fault found" pool.
Many newer technology systems utilize a means of artificial intelligence to form diagnostic conclusions. Programming allows the device receiving data from external sensors to make comparisons between multiple units and based on what is considered a normal situation, a conclusion is formed as to which of the sensors is providing non-accurate data.
Computer integration
The integration of aircraft systems makes an ideal platform for installing a centralized computer to make certain fault assessments, communicate with other failure reporting components, and provide a single point of aircraft interrogation.
Even fault retrieval is not a standardized method. Some aircraft require an external computer interface including a software program to download discrepancies, while others enable information retrieval from either flight deck instruments or a dedicated maintenance display. In some systems stored information is lost once power is removed, while in others fault data is recorded in a non-volatile memory where a physical action is required to erase the stored fault. On the same line, certain devices using lower capacity memories will simply over-write old information and only keep a record of the most recent faults.
Data retrieval
Information reporting is another variable. Some manufacturers elect to display their stored faults as words from the English language and then provide some instruction to assist in interpretation. More frequently data retrieval consists of reading and noting specific fault codes. Two standards referred to as Binary and Hexadecimal are frequently used and will represent malfunctions by displaying groupings of 1's and 0's or a six-place alpha numeric code. This fault history then has to be translated, which requires the use of a BITE (Built In TEst) book.
Many of the systems currently in use will expand the fault monitoring capabilities and even provide a real-time status report which will give the operating condition of various system components. Once again the intelligence of these monitoring devices may be limited, which means that if some component or part of the monitored system is selected OFF, the monitor may report it as FAILED. A status monitor is useful as a quick system test and in some cases can be used to verify proper system operation after a maintenance action. It is of course always advantageous to allow adequate stabilization time once power is applied prior to commencing with any interrogations. The fault status page is often an active display which means that within an allotted time the indications may change providing a real time preview of functionality. This is not true in all cases and certain installations will require some type of reset to trigger the next surveillance. In some cases a time delay may be incorporated in a fault detection circuit to be a deterrent to nuisance situations.
Know the history
Knowing the occurrence history of malfunctions can often provide the clues required to resolve an ongoing intermittent failure. Storage of flight anomalies is an additional capability of today's avionics devices. Retrieval of flight faults especially those that are stamped with time, date, and even flight leg can sometimes supply that last bit of allusive information necessary to finally pinpoint a malfunction. The number of devices monitored as well as the level of detection is predetermined and will often require the technician to navigate through several information screens to get to the area where the needed data is displayed. Another concern regarding fault data retrieval could be aircraft configuration. Many systems will deny access to the diagnostics when the machine is in a flight configuration. This is where familiarity with the aircraft and the system becomes essential.
A recent event in a twin engine business aircraft resulted in the flight crew reporting illumination of a Flight Director Failed annunciator prior to taxi out. The Minimum Equipment List (MEL) provided direction for flight without an auto-flight system and the crew was on a short mission so they elected to take the aircraft. Once airborne it was recognized that the autopilot could not be used. A maintenance technician speaking to the flight crew while the aircraft was inbound requested that when the trip ended to leave the auxiliary power unit (APU) operating to allow preservation of the data stored within the diagnostic memory. Once the technician interrogated the system, a fault was recorded that pointed to a faulty inertial reference unit (IRU). The mechanic did note that both attitude and heading information appeared to be working as it should and this was later confirmed by the flight crew.
So now a dilemma exists, should the IRU be replaced per the diagnostics, or should troubleshooting begin? The technician elected to try to duplicate the events that led to the fault. Aircraft power was removed and after a short interval (commonly called a coffee break) a power up sequence was initiated. This included starting the APU, and after 30 minutes starting both main engines. This particular aircraft uses electric starters on each engine and power is available from two nickel cadmium batteries connected in a parallel configuration. Battery power is supplemented by the generator installed on the APU. It was noted by the technician that during the first main engine start that the flight director failure warning illuminated and the autopilot could not be engaged. It was also noted by the technician that during the engine start that electrical system voltage dropped from the system normal 28.5v DC to something less than 20 volts. It was this excessive voltage drop that caused an inappropriate output of the IRU that was observed by the flight director and subsequently recorded in the diagnostic memory. In this case, problem resolution was recognized by replacing the main aircraft batteries. Is it hard to believe that batteries can cause an autopilot problem? Strange but true!
Data just another tool
The lesson to be learned here is that if the technician had not employed acquired knowledge of the aircraft and systems and merely used the data provided by the diagnostics probability is high that the aircraft would still be experiencing a problem and an expensive IRU which requires about four hours to replace would have been changed needlessly.
Many systems have capabilities to conduct detailed testing of many of the associated line replaceable units. And while these tests will only be able to be activated in a non-flight condition, if appropriate measures are not observed to conclude the initiated test it may proceed to completion at the most inopportune time. Anytime diagnostic systems are accessed it is imperative to be sure correct procedures are used to exit.
Diagnostic systems can be considered the greatest thing since safety wire pliers but it has to be realized that they all too often have limitations to their capabilities. The most important thing for a technician to understand is what a diagnostic system says is not always the root cause of the problem. Interrogation devices should be considered nothing more than another troubleshooting tool. In other words "How does it know"? Once this question can be answered and it is understood why the diagnostic unit reported the fault, only then are you on the appropriate path to problem resolution. Diagnostic guides are also an essential tool for proper fault analysis and it is often a justifiable procedure to get with someone knowledgeable about the specific aircraft and system and spend some time reviewing the interrogation methods in something other than an AOG situation.
Understanding the capabilities of specific diagnostic tools is the true key to success in rapid and cost-effective return to service. Remember that what it says is not always what it means. AMT
