Jherrod ThomasThe Lion of Functional Safety™

May 22, 2026 · 13 min read

ISO 26262-3 HARAISO 26262-9 DFAFMVSS 101

Three Recalls, One Dark Cluster: Stellantis's Instrument-Panel Software Failures Through an ISO 26262 Lens

I have written here about a flooded road, a frozen transponder, and a pacemaker latched into safety mode. Today's story is duller, and for exactly that reason it is more useful: a dashboard that goes dark. It is not a dramatic failure. It is a quiet one — and quiet failures are the ones that survive an entire development program because nobody rated them as anything worth chasing.

In a six-month window, Stellantis's North American arm, FCA US, issued three separate recalls for the same behavior: the instrument panel cluster — the IPC — fails to render. No speedometer, no telltales, no gear indicator. Three recalls, three different cluster hardware variants, three different model families, one root behavior. That repetition is the engineering story. A single blank-cluster recall is a bug. Three is a pattern, and a pattern is a process artifact that was never written.

The public record: three recalls, one root behavior

The first wave landed in December 2025. FCA US recalled 72,509 Ram trucks — 1500, 2500, and 3500 pickups plus 3500/4500/5500 cab-chassis units, all model year 2025 and 2026 — fitted with the 12-inch digital IPC. NHTSA logged it as recall 25V-826. The defect description is blunt: the IPC display "may fail to appear at startup or while the vehicle is in motion," which prevents the driver from seeing the brake-system warning light and other critical indications (WardsAuto; autoevolution). Owner letters went out in January 2026.

The second wave arrived in April 2026. This time the count was 65,348 Ram trucks across the 1500 through 5500 lines, built between August 9, 2024 and July 4, 2025 — but the part was different. The affected cluster was the 3.5-inch IPC supplied by Marelli North America, and FCA assigned it recall code 35D. Same symptom: "can become inoperative at startup and/or while driving because of a software issue." FCA estimated only about 1 percent of the recalled population would actually exhibit the fault, and the remedy is, again, a dealer software reprogram (MoparInsiders; Autoblog).

The third wave, also April 2026, crossed brands and powertrains entirely: 20,271 electric vehicles — 11,743 Jeep Wagoneer S and 8,528 Dodge Charger Daytona units, model years 2024 and 2025. FCA's internal Technical Safety and Regulatory Compliance organization opened an investigation on March 10, 2026; on April 16 its Vehicle Regulations Committee determined that the affected vehicles did not comply with several Federal Motor Vehicle Safety Standards. When the cluster blanks on these EVs, the driver loses the brake warning, electronic stability control, tire-pressure, occupant-restraint, and gear-selection indications simultaneously (Detroit News; Kelley Blue Book).

One detail is worth pausing on. All three were filed, in substance, as noncompliance recalls — the vehicles fail to meet FMVSS — not merely as defect recalls. That is a procedural fact with an engineering meaning, and it points straight at the standards lens.

The standards lens: a QM display carrying ASIL C warnings

Start with the regulatory floor. The instrument cluster is not decoration. FMVSS No. 101 ("Controls, Telltales and Indicators") governs the identification and illumination of telltales, and the telltale provisions embedded in FMVSS Nos. 105/135 (brake systems), 126 (electronic stability control), 138 (tire-pressure monitoring), and 208 (occupant restraints) all require that a specific warning be presentable to the driver. A cluster that renders nothing presents nothing. That is why FCA's Vehicle Regulations Committee reached a noncompliance finding rather than a discretionary defect call: a blank IPC is, on its face, several standards out of conformance at once.

Now the functional-safety lens, which is where the more interesting mistake lives. Run the IPC display function through ISO 26262-3 §7 (HARA) as its own item and you get a surprisingly mild result. The malfunction "loss of IPC display" rarely rates above ASIL A, and the at-rest variant — cluster never wakes up at ignition-on — often lands at QM, because the driver can see the dark screen before moving and decline to drive. Many programs stop there. The cluster software gets developed to a QM process, the supplier is held to a QM flowdown, and everyone moves on.

That is the trap. The IPC is a low-ASIL item, but it is the annunciation channel for functions that are not low-ASIL. The ESC malfunction telltale belongs to a stability-control function. The brake-system warning telltale belongs to the brake function. The SRS readiness telltale belongs to the airbag function. Those functions carry their own, far higher, integrity targets — and every one of them relies on the cluster as the last link in a safety mechanism whose entire job is to tell the driver that something is wrong.

ISO 26262 has a precise name for what happens when a safety mechanism fails silently and nobody notices: a latent fault. ISO 26262-5 makes hardware programs compute a Latent Fault Metric exactly to bound this. The blank cluster is the latent failure of a driver-warning safety mechanism. When the display is dark, an ESC fault that should have raised a telltale raises nothing — and the higher-ASIL function it belongs to is now operating with one of its risk-reduction measures defeated, undetected.

The second clause this implicates is ISO 26262-9 §7 — Dependent Failure Analysis (DFA). Every telltale in that cluster is rendered through one graphics pipeline, one rendering task, one piece of cluster firmware. A single software defect in that pipeline is a common-cause failure that takes down the brake telltale, the ESC telltale, and the SRS telltale together. The safety architecture probably assumed those warnings were independent. They share a component. A DFA would have asked: what single software fault disables all of these annunciations at once? The honest answer — the render task — is the answer three recalls just confirmed.

And because the cluster firmware is a Marelli-supplied software item, this is also an ISO 26262-8 §5 question. The Development Interface Agreement is where the OEM specifies what the supplier must verify and what evidence must come back. If the cluster was scoped as QM, the DIA never demanded the one test that mattered: fault injection against the render pipeline.

Worked analysis: HARA, fault tree, and the FMEA row that should have fired

Here is the HARA, written the way it usually gets written — and note where it stops.

| ID | Item function | Malfunction | Operational situation | S | E | C | ASIL | |----|---------------|-------------|------------------------|---|---|---|------| | HARA-IPC-01 | Indicate vehicle status and faults to the driver | Total loss of IPC display at ignition-on (cluster never renders) | Driver about to depart; no telltales, no gear indicator shown | S1 | E4 | C1 | QM | | HARA-IPC-02 | Indicate vehicle status and faults to the driver | Total loss of IPC display while driving (render task hangs in motion) | Highway driving; speedometer and all telltales blank | S1 | E4 | C2 | A | | HARA-IPC-03 | Annunciate a fault originating in another function | IPC cannot raise the ESC / brake / SRS telltale because the display is dark | A genuine higher-integrity fault is developing and goes unwarned | — | — | — | Latent |

Rows 01 and 02 are the rows most programs write, and they explain why the cluster gets a QM-to-ASIL-A process. Row 03 is the row most programs do not write, because it is not a standalone hazard with its own S/E/C — it is the latent failure of a safety mechanism that belongs to a different, higher-ASIL item. It does not get a clean ASIL letter in isolation; it gets inherited integrity from the function whose warning it carries. Leave row 03 off the HARA and the cluster looks like a QM part. Put it on, and the cluster inherits the integrity of the most critical telltale it is responsible for showing.

The fault tree makes the dependency explicit. The top event is not "the screen is blank" — it is the thing a driver actually cares about:

TOP: Driver receives no warning of a developing brake / ESC / SRS fault
                               |
                             [AND]
            +------------------+-------------------+
   A genuine fault exists in       IPC annunciation channel
   a higher-integrity function     unavailable to the driver
   (brake / ESC / SRS)                         |
                                             [OR]
                  +----------------+-----------+----------------+
          IPC blank at boot   IPC render task   Safety telltales   No independent
          (never initializes) hangs while       share the graphics fallback warning
                              in motion         stack with infotn. path exists
                                                widgets (common    (single point)
                                                cause)

Three of the four basic events on the right branch are software faults in one component. The fourth — "no independent fallback warning path exists" — is an architecture decision. Together they are the whole recall.

A design FMEA should have caught the render-task hang long before any of this reached a customer. Here is the row, scored on the AIAG-VDA scale with Action Priority rather than RPN:

| Item | Failure mode | Effect | S | Cause | O | Detection control | D | AP | |------|--------------|--------|---|-------|---|-------------------|---|-----| | IPC graphics render task | Render task hangs / deadlocks at runtime | All telltales, speedometer, and gear indicator freeze or blank; multiple FMVSS telltales unavailable | 8 | Unbounded wait on a shared resource; no task-level watchdog on the render loop | 4 | Functional test exercises nominal boot path only; no fault injection on the render stack | 7 | High |

Severity 8, Detection 7, Action Priority High. An AP-High row is not a row you accept — it is a row you act on. The action is a render-loop watchdog and a fallback path, and it is cheaper than three recalls.

Derived requirements (excerpt)

Five requirements close the gap. Each is traceable to a clause and carries a numeric threshold a verification engineer can actually test.

None of these is exotic. A render-loop watchdog, a separated telltale path, and an audible fallback are standard cluster engineering. They were skipped because the item was scoped as QM, and a QM scope does not ask for them.

What the headline really tells us

The headline says "software glitch blanks the dashboard." Read it as an engineer and it says something narrower and more fixable: a safety mechanism — the driver-warning channel — was treated as a display feature instead of as the last link in several higher-integrity safety functions. The cluster was rated on what it is (a screen) rather than on what it carries (warnings for braking, stability, and restraints). That single classification error is upstream of all three recalls, across two cluster suppliers and three model families, because it was never an item-level bug — it was a HARA that stopped at row 02.

The missing artifact is not a line of code. It is row 03: the line that says the cluster inherits the integrity of the most critical telltale it is responsible for showing, plus the DFA that says all those telltales share one render task, plus the DIA clause that turns that into a supplier test obligation. Write those three things and the watchdog, the separated path, and the audible fallback follow automatically. Skip them and you get a dark dashboard — quietly, repeatedly, and across your whole lineup.

Sources

— Jherrod Thomas, The Lion of Functional Safety™