Avionics Troubleshooting Part One: Science, Art and Tribal Knowledge
Avionics systems come in all shapes, sizes and functions. Older systems tend to be hardware intensive, whereas newer systems usually have less hardware but are loaded with software. In either case, the function of the system does not usually change too much, but the size, weight and power consumption of the newer system tends be much less than the older system it replaces. This is great from an aircraft installation point of view, as saving weight and power consumption is always a plus. It is quite another story from a maintenance perspective.
I have taught hundreds of avionics classes over the years, and one question that I am asked over and over is this: “What is the secret to troubleshooting an avionics system correctly the first time?” There really is no secret. Let’s discuss the steps/procedures one should follow to help minimize wasting time, manpower and money in troubleshooting avionics systems.
System types
The first step in any troubleshooting procedure is to identify the system believed to be at fault. In the case of avionic systems, this is important to the extent that the cause-and-effect syndrome comes into play. System B is showing a fault because it relies on an input from System A. System B is showing the effect, but System A is the real culprit. Trust this axiom: “Whichever system is understood the least will be blamed the most.” For most aircraft that have one, that would be the autopilot.
Three basic types of systems are in use in our industry and we troubleshoot them differently. The oldest systems out there are what I refer to as federated systems. These systems have several line replaceable units (LRUs) and each one has a particular task. There might be controllers, a computer, displays and in some cases, analog-to-digital converters and switching units. Lots of boxes and wires, but because each unit had a particular function, it was not too difficult to troubleshoot.
The second type of system that has evolved is called an integrated system. Imagine the federated system mentioned above — and through the marvels of very large scale integration (VLSI) and surface mount technology (SMT), you had the ability to take an LRU and reduce it in size to that of a circuit card assembly (CCA.) A system that had three or four LRUs might now have only one. Each of the older LRUs has become a CCA in a new LRU. Less weight, space, wiring ... the list goes on. On the negative side, with all that integration, it becomes more problematic to troubleshoot, as replacing the new LRU will cost more since it houses more functions.
Lastly, we come to the distributive system — the third type of system and “the new kid on the block,” if you will. This system uses a lot of commercial off-the-shelf (COTS) devices and specializes in very secular software to do specific functions. As an example, think of this system as using four Windows PCs connected together along with four displays, all running the same operating system. One PC is running Microsoft Word, another is running Excel, another running PowerPoint and the last running Outlook. Now, replace these programs with an air data function, an EFIS function, an autopilot function and a flight director function. No more separate computers, displays and in some instances, even sensors. All has been integrated into a very efficient package where hardware has become generic and minimal, while software has taken over. Again, from an aircraft perspective, less weight, less space, fewer wires, less power — this is a good thing. However, troubleshooting has become a whole other issue. The days of going out on the ramp with a TIC box are long gone. Just about all the troubleshooting has to be done on the ground with built-in test (BIT). If you do not know where to start looking, pack a lunch — you will be there a while.
Beginning to troubleshoot
To begin troubleshooting any avionics system, there are a few general rules that should always be followed.
1: The pilot has written up a squawk that a system is not working correctly or has failed. Firstly, identify the system. Remember our friends cause and effect.
2. Secondly, verify the squawk. Is the system actually operating out of its normal parameters? Are all of the switches and circuit breakers in their correct operating positions? Before we can say that a system is not operating correctly, we need to understand what correctly is. What flags and/or failure indications were displayed on flight deck displays?
3. Is the squawk specific in nature or very general in its terminology? If need be, is the pilot available to shed additionally light on the problem? I have seen write ups that were borderline ridiculous. You might have seen some yourself.
Squawk: Left engine missing.
Signoff: Found left engine on left wing.
Squawk: Noise in cabin sounds like mouse.
Signoff: Put cat in cabin, check next flight.
Squawk: Dead bugs on aircraft windshield
Signoff: Cleaned off dead bugs and put live bugs on order.
The better the information the pilot can provide, the more helpful it is in helping you determine where the problem is. Some helpful information in the write-up would be: when does the problem exhibit itself? All the time or only during a particular part of the flight? Above or below a particular altitude or airspeed? When the pilot talks on the radio? What flags or messages, if any, are in view on the flight deck displays?
4. Are the pilot and maintenance manuals on the aircraft and system the latest and greatest? Are the latest revisions to the manuals available? If your manuals are out of date, so is your ability to troubleshoot.
5. Is there a maintenance specialist who has been properly trained on the system in question? I don’t mean in a two-week aircraft familiarization class where only three hours were spent in total on all the avionics systems. I mean a technician who has attended a factory school on the system to become qualified to troubleshoot and maintain the system to the LRU level. This person has also gone for refresher training every 24 or 36 months.
If the answer to any of these five rules is no, then you have put yourself at a serious disadvantage to get it right the first time. Recognize your strengths and weaknesses. If you do not have the strengths to troubleshoot this system, then don’t. Find a maintenance technician or even another organization that is qualified to do so. Troubleshooting is a little bit science, a little bit art and a little bit tribal knowledge, depending on what type of system you are working on. The science part is pretty straight forward and is called out in the ICA. The art part comes from experience over time. The tribal knowledge part is for somethings you will never find written down in an ICA. That part will be learned the hard way, through long hours of work. I suggest you have a book in the shop where you can build this tribal knowledge base. Consider this for input:
• Aircraft serial number
• Date of squawk
• What was done procedurally?
• What was the corrective action?
Over time, this becomes a wealth of information to be built upon and becomes a valuable tool for all concerned. In our next issue, we will continue with troubleshooting tips for a variety of today’s avionics systems. Part two will focus on helpful tips to follow when troubleshooting various avionic systems.