Jherrod ThomasThe Lion of Functional Safety™

July 18, 2026 · 13 min read

ISO 21448 SOTIFUL 4600 / SAE J3016NHTSA Part 573 / AVEP

When the Regulator Wrote 'Functional Insufficiency': The Zoox Heavy-Smoke Recall (26E044) Through an ISO 21448 and UL 4600 Lens

Safety engineers have spent years explaining the phrase "functional insufficiency" to program managers who wanted to file everything under "software bug." On July 8, 2026, the NHTSA Administrator did it for us — in a letter to every driverless-AV developer in the country, about vehicles that drive into emergency scenes. Eight days later Zoox filed an equipment recall for exactly that: a robotaxi that met heavy smoke over an active fire scene in Las Vegas and treated it as something to drive through. When the regulator starts using ISO 21448's vocabulary unprompted, the standard has stopped being optional reading.

I covered a structurally similar story in May — the Waymo flooded-lane recall — and I promised myself I wouldn't write the same post twice. I'm not going to. The flood story was about a behavior policy applied outside its specified context. This one is about something different and, I think, harder: a triggering condition that degrades your perception and carries the semantic meaning your perception was supposed to extract, at the same time. Plus a regulatory development that changes the exposure argument for every HARA row in this class.

1. The public record

On June 20, 2026, an unoccupied Zoox robotaxi in Las Vegas "encountered heavy smoke that obscured an active emergency fire scene that was not cordoned off with cones." The chronology in the Part 573 filing is unusually specific about what happened next: the vehicle entered the scene, then "braked hard while attempting to steer away before coming to a stop." A remote operator — Zoox's term is a teleguidance tactician — reversed the vehicle out, "after which the first responders placed traffic cones at the scene blocking two of the three through-lanes." No injuries. (NHTSA Part 573 Safety Recall Report 26E044.)

The defect description is one sentence: "In certain situations, the software may not detect and respond to heavy smoke, particularly in active emergency scenes." The stated safety risk is two-sided — "increase the risk of a crash, or impede first responders" — and that second clause matters, because it is the first time I can recall a Part 573 filing treating interference with emergency response as a co-equal safety risk alongside collision. (NHTSA 26E044.)

The process timeline is worth laying out, because the mechanics are unusual:

Note the "E" in 26E044. This is an equipment recall, not a vehicle recall — the recalled article is the ADS software itself, as a piece of motor vehicle equipment. And because "Zoox solely owns, operates, and directly controls the affected equipment," there are no owners or dealers to notify. The Part 573 machinery, built in the 1960s around the assumption of a dispersed owner population, executes here as: push the update, file the paperwork. The remedy description even says the quiet part: "As is the nature of ADS software development, Zoox will continue to monitor field performance and make updates to improve its driving behavior." That sentence is a continuous-deployment pipeline wearing a recall notice as a hat.

Now the second document, which is the reason this story is bigger than 105 vehicles. On July 8, 2026 — the same day Zoox closed its investigation window — NHTSA Administrator Jonathan Morrison sent a letter to all driverless ADS developers stating the agency "has identified a clear pattern of driverless AVs interfering with law enforcement and other first responders," documenting "multiple instances in which AVs drove directly into active emergency scenes, blocked the paths of ambulances and firefighters, or failed to recognize and respond to basic safety conditions like flashing lights, flares, smoke, fire, and traffic cones." Then two sentences every AV safety engineer should pin above their desk: "Let me be clear: the inability to detect and appropriately respond to such situations represents a functional insufficiency. Emergency scenes are not rare or extreme 'edge cases.'" Developers are expected to present their solutions in meetings scheduled by the end of July. (NHTSA ADS Developers Letter, July 8, 2026; NHTSA press release; TechCrunch, July 8, 2026.)

"Functional insufficiency" is not regulator boilerplate. It is a defined term of art — ISO 21448 clause 3.2 territory — and its appearance in an enforcement-adjacent letter means someone at NHTSA is reading the same standard we are, and expects developers to answer in its language.

2. The standards lens

ISO 21448 Clause 7 — a triggering condition that attacks twice. Heavy smoke is a strange and instructive entry for the triggering-condition catalog, because it plays two roles simultaneously. Role one: it is an environmental degradation of perception — an obscurant that attenuates camera contrast and returns lidar backscatter, shrinking effective sensing range exactly the way fog and heavy rain do. Role two: it is a semantic cue — the observable evidence of the hazard (an active fire scene) that the vehicle needed to classify in order to stay away. The insufficiency compounds: the condition that should have triggered "emergency scene ahead, do not enter" is the same condition that was busy degrading the sensors that would detect it. Contrast the Waymo flood case, where perception worked fine and the behavior policy was the gap. Here, the recall language — "may not detect and respond" — puts the shortfall at the detection-and-classification layer itself. A triggering-condition analysis that lists "smoke" only under perception degradation (next to fog, in the weather section) and not under scene semantics (next to flares and cones, in the emergency-response section) will pass review and still produce this event.

SAE J3016 / minimal risk condition — achieved, in the worst possible place. Look at what the vehicle actually did: braked hard, attempted to steer away, came to a stop. By the letter of a fallback specification, that could be scored as achieving a minimal risk condition. It stopped inside an active fire scene, blocking an uncordoned lane that first responders then had to cone off around it. An MRC is a condition, not a location — and this event is the cleanest demonstration I've seen that MRC placement is a safety requirement of the same rank as MRC achievement. A stationary robotaxi is only "minimal risk" relative to where it is stationary. Stopping in the path of a fire crew converts the vehicle from a traffic participant into scene furniture that emergency services must work around — which is precisely the "impede first responders" risk the filing names.

The teleguidance credit. The actual mitigation on June 20 was not the ADS. It was a human teleguidance tactician who reversed the vehicle out of the scene. Fine — but then the safety case must carry that dependency explicitly: what is the claimed time from vehicle-initiated stop to tactician engagement? What is the comms-availability assumption near an active fire, where incident command may be saturating spectrum? Is the tactician's situational awareness (through the same smoke-degraded cameras) sufficient to reverse safely? UL 4600 is blunt about this: every credit taken for remote assistance needs supporting argument and evidence — latency budgets, availability figures, and a bounded claim about what the remote operator can actually perceive. If teleguidance is load-bearing for the emergency-scene hazard class, it belongs in the safety case as a quantified element, not as an operational garnish.

UL 4600 — the safety case already has a section for this. UL 4600's hazard prompt lists explicitly include interaction with emergency responders, emergency scenes, and non-standard road-user behavior. An assessor working through the safety case would ask: show me the claim for "vehicle shall not enter an active emergency scene," the argument, and the evidence — including for scenes not yet cordoned (the filing is specific that no cones were down). "We respond to cones and flashing lights" is an argument about scene markers, not scene presence, and June 20 is the counterexample: the scene announced itself with smoke before responders had marked it. The Administrator's letter is, functionally, a regulator demanding that section of everyone's safety case at once — by the end of the month.

The exposure argument just moved. Morrison's "not rare or extreme edge cases" sentence has a technical consequence beyond rhetoric. Every risk assessment in this class contains an exposure estimate for emergency-scene encounters, and fleet-scale operation makes them routine: a fleet doing hundreds of thousands of trips per week in a metro area encounters emergency scenes daily somewhere in the fleet. Rating that exposure low because any single vehicle rarely meets one is the classic per-vehicle fallacy; the hazard population scales with fleet miles. When the regulator states on the record that these situations are not rare, an E1/E2-style rating in anyone's analysis becomes indefensible in hindsight — and plaintiff's counsel reads NHTSA letters too.

And yes, Clause 13 worked. Fair is fair: field monitoring detected the event day-of, AVEP reporting put it in front of the regulator within five days, containment (operational avoidance of fire scenes) went in while root cause ran, and the fleet fix shipped 25 days after the event. That is ISO 21448's operation-phase loop functioning as designed, at a speed the traditional recall system never contemplated. The critique is not the response. The critique is the catalog row that should have existed before April 23, when this software release started carrying passengers-adjacent traffic in a desert city where structure fires and vehicle fires are a weekly fact.

3. A worked snippet — the triggering-condition rows and the tree

3a. ISO 21448 Clause 7 triggering-condition analysis (excerpt)

| TC ID | Triggering condition | Functional insufficiency exposed | Hazardous behavior | Scenario class (pre-Jun 20) | Class (post-remedy target) | |---|---|---|---|---|---| | TC-ES-01 | Heavy smoke plume crossing the roadway, source fire not visible, scene not yet cordoned | Smoke not classified as scene-semantic cue; treated as generic visibility reduction | Vehicle proceeds into obscured emergency scene at speed | Unknown / Unsafe | Known / Safe | | TC-ES-02 | Emergency scene marked with cones, flares, or flashing lights | (Existing capability per filing — detection of active EV scenes) | — | Known / Safe | Known / Safe | | TC-ES-03 | Smoke dense enough to degrade camera contrast and lidar returns below planning thresholds | Perception-degradation handling not coupled to traversability decision | Vehicle continues at speed with shrunken effective sensing range | Partially known | Known / Safe | | TC-ES-04 | Vehicle already inside scene perimeter; fallback triggered | MRC placement not constrained by scene geometry | Vehicle stops inside scene; blocks responder access | Unknown / Unsafe | Known / Safe |

TC-ES-01 and TC-ES-04 are the recall. TC-ES-02 is the capability Zoox already had — the filing says the update "enhances the existing capability of detecting active emergency scenes" — which is exactly the marker-versus-presence gap described above.

3b. HARA-style consequence row (ISO 26262-3 §7 framing)

| ID | Operating scenario | Hazard | S | E | C | ASIL | Safety goal | |---|---|---|---|---|---|---|---| | HZ-ES-01 | Driverless L4 robotaxi, urban arterial, heavy smoke over roadway from active fire, scene uncordoned | Vehicle enters active emergency scene; collision with responders, hoses, apparatus, or fleeing pedestrians; obstruction of emergency access | S3 (struck firefighter or pedestrian in zero-visibility plume) | E2 per vehicle — but fleet-aggregate exposure is daily, and NHTSA has now said on the record these are not rare | C3 (no driver; teleguidance latency exceeds the entry window) | ASIL B–C | SG-ES-01: The ADS shall not enter a region classified as an active or suspected emergency scene; fallback shall achieve MRC outside the scene perimeter. |

The E column is where the July 8 letter bites. Argue E1 in a design review after that letter and you are arguing against the regulator's published position with your own fleet-mileage data working against you.

3c. Fault tree — top event: robotaxi inside an active emergency scene

Top: Driverless vehicle enters / remains within an active emergency scene
        OR
        ├── A. Scene not detected
        │       OR
        │       ├── A1. Scene markers absent (uncordoned early-phase scene)   ← Jun 20
        │       ├── A2. Marker detection insufficiency (cones/flares/lights missed)
        │       └── A3. Scene cue present but not in semantic catalog
        │                (heavy smoke as scene evidence)                      ← Jun 20
        ├── B. Scene detected, traversability decision wrong
        │       └── B1. Smoke handled as weather-grade visibility reduction;
        │                speed reduced, path maintained
        ├── C. Fallback triggered inside scene
        │       AND
        │       ├── C1. Entry already occurred (A or B upstream)              ← Jun 20
        │       └── C2. MRC selection unconstrained by scene geometry         ← Jun 20
        └── D. Recovery dependent on remote operator
                AND
                ├── D1. Teleguidance link available and within latency budget
                └── D2. Tactician situational awareness adequate through
                         degraded sensors

June 20 traversed A1 ∧ A3, then C, and was rescued at D. The software remedy addresses A3 and B1. C2 and the D-branch assumptions are the parts I'd want to see evidence for in the end-of-month meeting with NHTSA.

4. Derived requirements (excerpt)

The rows I'd expect in the requirement set of any driverless developer walking into that NHTSA meeting — with numbers, because requirements without numbers are wishes.

REQ-ES-001 is deliberately written so the vehicle does not need to know why the smoke is there. "I cannot see through it and I cannot stop short of what might be inside it" is sufficient grounds to refuse passage — the same logic a competent human driver applies, and the same logic the flood recall needed for water depth. The two recalls are one requirement pattern wearing different weather.

5. What the headline really tells us

The headline says a robotaxi got confused by smoke. The engineering record says a scenario class — early-phase, unmarked emergency scenes announced only by their own byproducts — was missing from the semantic catalog, so the vehicle handled the smoke as weather instead of as evidence. The fallback then did what fallbacks do when nobody constrains their geometry: it stopped, correctly and precisely, in the one place a stopped vehicle causes the most operational harm. The save came from a human at a console, whose latency and availability appear nowhere in the public record as quantified claims.

And this time there's a second missing-artifact story, sitting one level up. NHTSA has now told the entire industry, in SOTIF's own vocabulary, that emergency-scene interaction is a functional insufficiency and not an edge case. That letter is, in effect, a regulator-mandated addition to every developer's triggering-condition catalog, with a due date. The developers who walk into those end-of-month meetings with a TC table, a scene-perimeter MRC requirement, and a quantified teleoperation credit will have a short meeting. The ones who bring "we've enhanced our detection capabilities" will get to explain why the row wasn't there before the smoke was.

— Jherrod Thomas, The Lion of Functional Safety™

Sources