Vehicle Health Management · A Practical Monograph
How a vehicle decides something is wrong, writes it down, lights a lamp, protects itself, and how that same machinery becomes the foundation for predicting failures before they happen. A plain-language tour from diagnostic trouble codes through residual-based detection, fault propagation, functional safety, and prognostics.
Before any algorithm, the vocabulary and the shape of the code itself.
Four ideas need separating, because using them interchangeably is the source of most bad diagnoses. Walk a problem backward through these and the real story usually appears.
The root abnormal condition. A cracked connector, a stuck valve, a sensor drifting out of physical range. The thing actually wrong.
A loss of the ability to perform a required function. A fault may sit quietly long before it produces a failure anyone notices.
What you can observe. Rough idle, a lamp, reduced power, a smell. Symptoms point toward faults but rarely name them.
A Diagnostic Trouble Code. The label an ECU stores when a monitor decides a fault is real. Evidence, not the disease.
The chain runs left to right: a fault exists, it may cause a failure, the failure produces a symptom, and a monitor translates the evidence into a DTC. A code is a hypothesis the car formed about itself. Your job is to confirm or reject it.
P0420 says the catalyst monitor is unhappy, but the cause might be an aging oxygen sensor feeding it bad data, an exhaust leak, or a genuinely dead catalyst. The code starts the investigation.The familiar five-character code (think P0301) comes from the OBD-II standard in SAE J2012 and ISO 15031. Every position carries meaning, and once you can read the positions, an unfamiliar code stops being random.
| Position | Meaning | Values |
|---|---|---|
| 1st (letter) | System group | P powertrain, C chassis, B body, U network |
| 2nd | Who defined it | 0 generic (SAE), 1 manufacturer specific, 2/3 reserved or joint |
| 3rd | Subsystem | fuel/air, ignition, emissions, speed/idle, computer, transmission, and so on |
| 4th & 5th | Specific fault index | the particular condition within that subsystem |
Interactive
Pick a code or type your own five characters. Each position lights up with what it means.
0 means the code is part of the shared OBD-II catalogue every maker must honor. A 1 means the carmaker invented it for their own ECU, so you need their service data to interpret it. That single digit decides whether a generic reader can help.Controllers that speak UDS (Unified Diagnostic Services, ISO 14229) often show the five-character code on the surface but store a richer three-byte DTC underneath, plus a failure type byte that says how the circuit failed: shorted to ground, open, signal too high, stuck. The next section unpacks the byte that travels with every code.
A DTC is never simply present or absent. In UDS, each code carries an eight-bit status byte recording its history: failing right now, failed at all this drive, confirmed, lamp requested. A scan tool reads these bits to tell a live problem from a memory of an old one.
Interactive
Click bits to toggle them, or step through a realistic scenario. The hex value updates the way a scan tool would show it.
bit0 testFailed (failing as you watch) and bit3 confirmedDTC (matured into stored memory). A code with bit3 set but bit0 clear is an old confirmed fault that is not active now. That difference decides whether you chase a live problem or an intermittent one.The mechanics inside the ECU: what it measures, when it is allowed to look, how it accumulates evidence, and how a model sharpens the judgement.
Monitors are not all the same. Underneath the variety, almost every one belongs to one of four families. Knowing which family a monitor uses tells you what it can and cannot see, and why a clever fault sometimes slips past a simple check.
Is the signal physically possible, and is it changing at a believable speed? A coolant sensor reading minus 40 C on a hot engine, or a temperature jumping 80 degrees in one sample, is impossible. Cheap, fast, catches gross electrical faults.
Do two or more signals agree? Throttle position versus airflow, two redundant pedal sensors, modeled torque versus measured acceleration. Catches faults that are in range individually but inconsistent together.
The ECU intrudes: it commands an actuator and checks the response. Pulse the EGR valve and watch manifold pressure, seal the evap system and watch for a pressure decay. Catches faults that hide during passive observation.
A model predicts what a signal should be; the difference (the residual) is watched. Observers, parity equations, and physics or data driven models live here. The most sensitive family, and the bridge to prognostics.
Inside the ECU a monitor watches one thing: a circuit, a plausibility relationship, the result of an active test. Its life follows a loop. It runs only when allowed, it does not believe a single bad reading, it waits for evidence to accumulate, and it heals when the evidence goes away.
Two choices in this loop protect the driver from nuisance and the workshop from chasing ghosts: the monitor refuses to run unless its enabling conditions hold, and it refuses to act on a single sample, instead debouncing the evidence. The next sections give a working model of each.
A monitor that ran all the time would constantly cry wolf. A catalyst check is meaningless on a cold engine; an evap leak test cannot run with the cap off. So every monitor carries enabling conditions, preconditions that must all be true before the test evaluates. Until they are met the monitor reports not ready, and no pass or fail is produced.
Common conditions: a stable running engine, coolant in a band, speed in a range, healthy battery voltage, enough time since start, and crucially no conflicting fault present. That last one is fault dependency: a downstream monitor is inhibited when an upstream sensor it relies on is faulted, so the car does not stack misleading codes on top of one real one.
Interactive
This models the catalyst efficiency monitor. Set the operating conditions. The monitor runs only when every condition is satisfied at once.
Sensors are noisy and the world is bumpy. If a monitor set a code on the first bad sample, every car would be a Christmas tree. So the monitor debounces: it accumulates evidence before it commits. The mechanism standardized in the AUTOSAR Diagnostic Event Manager is a signed fault detection counter, an eight-bit value running from minus 128 to plus 127.
Each failed evaluation steps the counter up; each passed evaluation steps it down. When it reaches the positive confirm threshold the fault matures from pending to confirmed and the lamp can light. When it falls to the negative heal threshold the fault is considered passed and begins to clear. The two thresholds are separate on purpose, so a fault confirms decisively but only heals after convincing recovery.
Interactive simulation
A noisy sensor signal (teal) drifts toward a fault threshold (dashed). The signed counter (right) climbs on failing samples and falls on passing ones. The DTC confirms when the counter tops out and heals when it bottoms out. Drag the level, the noise, and the thresholds.
Real strategies vary: simple step counters as above, fixed time above threshold, pass and fail ratios, all layered across counted drive cycles and warm-up cycles. A confirmed code typically needs several consecutive clean cycles to leave memory, with a full erase after roughly forty warm-up cycles.
The most sensitive monitors do not threshold a raw signal at all. They run a model of the system in parallel with the real hardware, predict what a measurement should be, and watch the difference. That difference is the residual. In a healthy system the residual hovers near zero, carrying only noise. When a fault appears, the residual departs from zero in a way the raw signal alone may not reveal.
The classic model is a state observer. A Luenberger observer runs the system equations and corrects its own estimate using the measurement through a gain. The residual is measured minus estimated. The art is the threshold: a fixed band must sit high enough to clear honest transients during aggressive driving, which dulls it to small faults; an adaptive band tightens when the system is quiet and widens when it is working hard, catching a small fault during steady operation that a fixed band would sleep through.
Interactive simulation
A first-order plant is driven by an input that alternates calm and aggressive phases. An observer tracks it and forms the residual (rust). Inject a sensor fault and switch the threshold strategy. Watch a small fault during a calm phase trip the adaptive band while slipping under the fixed band.
When a DTC matures, the ECU saves a freeze frame: a small record of operating conditions at the instant the fault confirmed. Engine speed, load, coolant and intake temperature, vehicle speed, fuel trim, throttle. The car photographing the scene of the crime.
This is often the most useful data in the diagnosis, because an intermittent fault you cannot reproduce in the bay still left a fingerprint. If the snapshot shows a misfire confirmed at high load, cold, low speed, you know where to drive to reproduce it. UDS extends this with multiple snapshot and extended data records per DTC, including occurrence and aging counters.
| Freeze frame field | Example | Why it helps |
|---|---|---|
| Engine speed | 1850 rpm | Idle, cruise, or hard acceleration? |
| Calculated load | 78 % | High load points to demand-related faults |
| Coolant temp | 41 °C | Cold faults behave differently than hot ones |
| Vehicle speed | 52 km/h | Locates the event in the drive |
| Short term fuel trim | +18 % | Reveals the ECU compensating for a lean condition |
| Occurrence counter | 3 | Distinguishes a one-off from a recurring problem |
No monitor is an island. Sensors feed monitors, monitors feed other monitors, and a shared resource like the battery or the data bus feeds nearly everything. So a single root fault rarely sets a single code. It propagates: it corrupts the signals downstream of it, trips the monitors that depend on those signals, and inhibits the ones that were wisely told to stand down when their inputs cannot be trusted.
This is exactly the structure a fault propagation graph captures, and it is why a knowledge graph of subsystem dependencies is such a natural tool in vehicle health management. Read the graph and the crowd of codes resolves into one cause with a wake behind it.
Interactive
Click any node to inject a fault there. The fault flows along the dependency edges: the source turns red, everything downstream that it corrupts or inhibits turns amber. Read off which codes are real and which are merely consequences. Click the same node again, or reset, to clear.
From the software that holds the codes, to the tool that reads them, to the degraded behavior that protects the car and the safe state behind it.
In a modern ECU on the AUTOSAR standard, the pieces above live in named components, and the names make service documentation readable. A monitor reports a pass or fail as a diagnostic event. The Diagnostic Event Manager (Dem) owns the debounce counters, the DTC memory, the status byte, and the freeze frames. The Function Inhibition Manager (FiM) turns a confirmed event into a degraded-operation request, where limp mode begins. The Diagnostic Communication Manager (Dcm) answers the scan tool over UDS.
FiM inhibition, it means a confirmed fault asked the car to stop trusting a function. That request is the seed of limp mode.The scan tool speaks to the Dcm in UDS services, each a numbered request. The big one for diagnostics is 0x19 ReadDTCInformation, with subfunctions to list codes by status mask, fetch a snapshot, or count them. 0x14 clears, 0x85 turns DTC logging on or off, and emissions-world Mode 06 returns the raw monitor test results behind the pass or fail.
Interactive
Send requests with the buttons or type raw hex. The console replies the way a controller would. Note that clearing does not remove a permanent DTC, and that the malfunction lamp follows two-trip logic for most emissions monitors.
Because monitors need their enabling conditions, and because clearing codes resets them all to not ready, a freshly cleared car cannot immediately prove it is healthy. It must complete a drive cycle: a sequence of operating phases that, between them, satisfy every monitor's conditions at least once. Continuous monitors (misfire, fuel, the comprehensive component checks) go ready almost immediately; the non-continuous ones each wait for their moment.
Interactive
Step through a trip. Each phase satisfies the enabling conditions for some monitors, and they flip to ready. The evaporative monitor is usually the stubborn one, needing a cold start and a quiet soak. The car is emissions-test ready only when every monitor has run.
When a serious fault confirms, the controller does not merely record it. It changes how the vehicle behaves to protect the driver, the hardware, or the emissions system. Limp mode, limp home, failure mode management, derate: the names differ, the principle does not. Trade performance for survival and get the car home or safely stopped without making things worse.
Degradation is graded by severity, not by the mere existence of a code.
Fault logged, no driver impact. Full capability, code quietly stored. Many emissions codes live here.
Lamp on, mild limit. Reduced boost, slightly capped torque, raised idle. A little less punch.
Significant power limit, a transmission may lock a safe gear, speed capped. The classic limp home: enough to reach a shop.
The affected system is disabled to prevent damage or hazard. An EV may command turtle mode then a controlled stop.
Interactive simulation
Set a fault severity. The reaction manager maps it to a torque limit and a degradation level. The torque curve shows the driver-available envelope being clipped, the way a derate feels from the seat.
Limp mode is not only convenience. For safety-relevant functions it is the controlled transition into a safe state, the central idea of the automotive functional safety standard ISO 26262. The reasoning is a budget of time. From the moment a fault occurs, the system has a fault tolerant time interval to detect it and reach a safe state before the fault could lead to a hazard. Detection time plus reaction time must fit inside that budget.
Interactive
The fault occurs at zero. Detection takes some time (debounce counts, observer settling), then the reaction takes more (entering the safe state). If the total fits inside the fault tolerant time interval, the system is safe. Push detection or reaction too slow and the budget is blown.
Electric and hybrid vehicles keep all of the above and add a high-voltage world with its own monitors, where the stakes are electrical safety rather than emissions. Three families dominate.
The high-voltage bus must stay electrically isolated from the chassis. An isolation monitor continuously measures the resistance from each HV rail to ground, expressed in ohms per volt. A drop signals insulation breakdown, water ingress, or a chafed cable, and a severe drop opens the contactors at once.
The contactors connect the pack to the drive system. They are checked for welded-closed and stuck-open faults, and a precharge circuit limits inrush before the main contactor closes. A failed precharge or a welded contactor is a no-start or a refusal to shut down cleanly.
The battery management system watches cell voltages, temperatures, and their spread. Out-of-band conditions derate charge and discharge power, and a thermal-runaway precursor commands the most aggressive safe state the vehicle has, isolating the pack and warning occupants.
Interactive
Drag the measured isolation resistance. The monitor maps it to a warning, a power derate, or an immediate contactor open. The bar shows the margin to the safety limit.
A DTC tells you it failed. Vehicle health management asks when it will, and how to act before it does.
Everything so far answers one question: has a fault occurred? That is diagnostics, and a DTC is its output. But a confirmed code usually fires late, when degradation has already crossed a failure-level threshold. By then the planning options are gone. Prognostics asks the more valuable question: given the trend, when will this fail, and how much useful life remains?
The raw material is the same health signal a residual produces. Instead of waiting for it to cross an alarm line, prognostics fits its trajectory and projects it forward to the failure threshold. The gap between now and that projected crossing is the remaining useful life, and the spread of the projection is its uncertainty.
Interactive simulation
A health indicator degrades over cycles (teal points). A DTC fires only when it crosses the high alarm line, near the end. Prognostics fits the trend (rust) and projects it to the failure threshold, estimating remaining life with a confidence band well before the code would ever set. Change the degradation rate and the measurement noise.
Which faults deserve this treatment is a question the older discipline of FMEA already answers. The AIAG-VDA Action Priority logic ranks each failure mode by the severity of its effect, how often it occurs, and how well it can be detected, and returns a priority of high, medium, or low. The pattern rhymes with everything in this monograph: a high-severity, hard-to-detect failure is precisely the one where a late DTC is not good enough and a prognostic signal earns its keep.
| Severity of effect | Occurrence | Detection | Action priority |
|---|---|---|---|
| High (safety, no warning) | any | hard to detect | High: act first, prognostics valuable |
| Moderate | frequent | moderate | Medium: monitor, plan maintenance |
| Low (minor annoyance) | rare | easily detected | Low: a DTC at failure is fine |
Four codes, read the way this monograph teaches: structure, enabling conditions, debounce, reaction.
The misfire monitor watches crankshaft acceleration between firings and detects when one cylinder fails to contribute. Enabling: running above a minimum speed, warm enough, no rough road (a bump mimics a misfire). Debounce: counts misfire events over a window of revolutions; a high rate that risks the catalyst flashes the lamp, a slower rate sets a steady code. Reaction: may cut fuel to the dead cylinder to protect the catalyst, felt as a soft derate.
Compares the downstream oxygen sensor to the upstream one. Enabling: fully warmed, steady cruise, no oxygen sensor fault present (fault dependency, since a bad sensor makes the comparison meaningless). Debounce: averaged over a long, stable window across drive cycles. Reaction: usually monitor only, lamp on, full power. An emissions concern, not a drivability one.
A model-based monitor. It estimates how warm the engine should be after a given run at a given load and compares to measured coolant. Enabling: a cold start, minimum drive time and airflow accumulated. Debounce: a single clean comparison after the window. Reaction: monitor only, but points cleanly at a stuck-open thermostat. A textbook residual check.
A pointer code. The engine controller sets it to say the transmission controller has a stored fault of its own; read the transmission module for the specific code. Reaction: the transmission often enters its own limp, locking a fixed gear so the car still drives while protecting the gearbox. A textbook Level 2 derate and a small example of fault propagation across modules.
A handful of habits that save time once the mechanism is clear.
The simulations on this page implement simplified versions of the real logic for teaching. Production monitors layer many more conditions, calibrated thresholds, and cross-checks than shown here.