Diagnose operation of human machine interface (HMI) systems (such as: instrument cluster, driver information, entertainment/infotainment, and navigation); determine needed repairs.
ASE A6 — Electrical/Electronic Systems. Task E.1 from the Task List.
Diagnosing HMI Systems: Cluster, Driver Info, Infotainment, and Navigation
The short version — Before you chase a sensor or a screen, remember the cluster and infotainment system are just displays for network data; pull DTCs from the affected module and its network neighbors first, because one bad module or bus fault can fake a dozen different symptoms.
The cluster is a messenger, not a source
The instrument cluster shows you speed, RPM, fluid levels, and warning lights, but it doesn't generate almost any of that data itself — it's aggregating information sent over the network from sensors and other control modules. This matters because when a gauge or telltale acts up, your first question shouldn't be "what's wrong with the cluster," it should be "what's wrong with the module or sensor feeding the cluster."
Keep that mental model running through every HMI diagnosis: the display is the last stop, not the source.
Start with DTCs, and think network-wide
Diagnosis always starts with pulling DTCs — not just from the cluster or infotainment unit, but from any related module sharing that network segment. Why cast a wide net? Because a single failed module or an open/short somewhere on the bus can produce multiple HMI symptoms at once — a dead cluster, a frozen touchscreen, and a confused nav system can all trace back to one bad connector or one module that dropped off the network.
Once you have DTCs, use the scan tool to check network communication status — look for messages like "lost communication with module X." This is how you separate two very different problems:
- Module-internal fault — the module itself is bad (power, ground, or internal failure).
- Wiring/bus fault — the module is fine, but something on the network (a wire, connector, or another module dragging the bus down) is blocking its messages.
Treating these the same way wastes time — you don't want to replace a good module because a wiring fault made it look silent.
Matching the symptom to the likely cause
Blank or frozen cluster/display: this usually points to loss of power or ground, a bus communication fault, or an internal module failure — not a sensor problem. A sensor going bad doesn't blank the whole cluster; it just messes up one reading. If the entire display goes dark or freezes, look upstream at power, ground, and network health before you start swapping sensors.
Incorrect or erratic gauge/telltale readings: this is the opposite pattern. Since the cluster only displays what it's told, a wrong or jumpy reading usually traces back to the sending sensor or its source module, not the cluster. If the fuel gauge is bouncing around, don't condemn the cluster — check the sending unit and the module that reports that data onto the bus first.
Infotainment touchscreen unresponsive or frozen: try a module reset or reflash if the issue looks software-related. If that restores normal function, you've confirmed it was a software glitch. If the reset does not fix it, you're looking at a hardware failure instead — don't keep reflashing a module with a physical problem.
Navigation position errors or GPS dropouts: several different root causes can produce this same symptom:
- Antenna connection issues — a loose or damaged GPS antenna connection.
- Module software or database faults — outdated or corrupted map data or firmware.
- Loss of related chassis data — nav modules often use wheel speed and yaw data for dead reckoning (filling in position between GPS fixes), so if that chassis data disappears from the bus, position accuracy suffers even though the antenna and GPS module are fine.
This is a good example of why the network-wide DTC check matters — a wheel speed sensor fault somewhere else in the vehicle can show up as a navigation complaint.
Easy to mix up
- Blank/frozen display vs. erratic readings — a totally dead or frozen cluster points to power/ground/bus/module failure; a single wrong or jumpy gauge points to the sensor or source module feeding that specific reading. Don't treat these as the same diagnostic path.
- Module-internal fault vs. wiring/bus fault — both can show up as "lost communication," but only the scan tool's network status check tells you which one you're actually dealing with. Guessing here leads to replacing good parts.
- Software reset fixing infotainment vs. not fixing it — if a reflash restores function, it was software; if it doesn't, it's hardware. The reset itself is the diagnostic test, not just a repair attempt.
- Nav antenna fault vs. lost chassis data — both cause position/dropout complaints, but one is a physical antenna/connection issue and the other is a missing wheel speed/yaw signal used for dead reckoning. Same symptom, different repair path.
Check yourself
Question: The instrument cluster shows a frozen fuel gauge and a flickering speedometer, but the check engine light and other telltales are normal. What should you check first, and why?
Check the sending sensors and the source modules for those two readings (fuel level sensor/module, speed source), not the cluster itself. Since the cluster only displays data it receives, an erratic or frozen individual reading — with the rest of the cluster working — points to the sensor or its source module, not an internal cluster failure.
Question: Technician A says a completely blank cluster is most likely caused by a bad individual sensor. Technician B says a completely blank cluster is more likely a power/ground, bus communication, or internal module problem. Who is right?
Technician B. A blank or frozen cluster typically indicates loss of power/ground, a bus communication fault, or internal module failure — not a sensor problem. A single bad sensor would normally only affect one reading, not blank the entire display.
Question: An infotainment touchscreen is frozen. You perform a module reset/reflash and the screen comes back to life and works normally. What does this tell you, and what would it mean if the reset had not worked?
Since the reset restored function, the problem was software-related. If the reset had not fixed it, that would point to a hardware failure instead, meaning further reflashing wouldn't help and the module or related hardware would need further diagnosis/replacement.
Task List transcribed from ASE's free published study guide (ASE Study Guide — Automobile Tests (2026), A6 Test Specifications p.33).