Jherrod ThomasThe Lion of Functional Safety™

May 14, 2026 · 13 min read

ISO 21448ISO 26262UL 4600

The Car Saw the Flood and Drove In Anyway: Waymo's Untraversable-Lane Recall Through an ISO 21448 Lens

The detail that should keep AV safety engineers up at night isn't that a Waymo drove into a flood. It's the sentence in the recall filing that says the vehicle detected the flooded lane first — and then proceeded into it anyway. That is not a perception bug. That is the intended functionality doing exactly what it was specified to do, in a scenario nobody specified it for.

On May 12, 2026, Waymo filed a voluntary software recall with NHTSA covering its entire U.S. driverless fleet. The headline writes itself — robot car drives into creek — but the engineering content is unusually clean, and it lands squarely in ISO 21448 (SOTIF) territory rather than ISO 26262 fault territory. Let me walk through it the way I'd walk through it in a safety review.

1. The public record

On April 20, 2026, an unoccupied Waymo robotaxi in San Antonio encountered what the recall paperwork calls "an untraversable flooded section of a roadway" during heavy rain. Rather than stopping or routing around it, the vehicle continued forward at a reduced speed, entered the standing water, lost traction, and was swept into Salado Creek. Nobody was aboard and nobody was injured (Houston Public Media, May 13, 2026).

Roughly three weeks later — well inside the regulatory clock — Waymo filed a voluntary recall covering 3,791 vehicles equipped with both its fifth- and sixth-generation automated driving systems, across every city it operates: Phoenix, San Francisco, Los Angeles, Austin, San Antonio, and Atlanta (Electrek, May 12, 2026). The remedy is an over-the-air software update; no vehicle needs to visit a depot (TechCrunch, May 12, 2026).

The most important line is the one Waymo put in the NHTSA filing itself. Paraphrased across the coverage: on higher-speed roadways, the Waymo AV may slow but not stop in response to detecting a potentially untraversable flooded lane (CNBC, May 12, 2026). Waymo's own framing was that it had "identified an area of improvement regarding untraversable flooded lanes specific to higher-speed roadways" (Bloomberg, May 12, 2026).

As interim containment, before the full OTA fix was finalized, Waymo tightened weather-related operational constraints and updated its map data to restrict vehicle access to roads prone to flooding (San Antonio Report, May 13, 2026). Note what that interim measure actually is: a hand-edited ODD restriction and a map patch. That tells you the original ODD definition had a hole in it.

So: perception worked. The vehicle saw the flooded lane. The detection-to-classification chain produced "potentially untraversable flooded lane." And the behavior layer's response to that classification — on a higher-speed road — was slow down and keep going. That is the whole story, and it's a SOTIF story.

2. The standards lens

Reach for ISO 26262 first and you'll come up mostly empty, and that's the instructive part. ISO 26262 governs hazards caused by malfunctioning behavior of E/E systems — a sensor that lies, an actuator that sticks, a bit that flips. Nothing here malfunctioned. The radar, lidar, and cameras correctly sensed standing water. The classifier correctly labeled it. The planner correctly executed its policy. Every component met its spec. The system still drove into a creek.

That gap — where every element is fault-free and the vehicle is still unsafe — is the exact gap ISO 21448 (SOTIF) exists to close. The relevant concepts:

Then there's UL 4600, the standard for the evaluation of autonomous products, which is the right lens for the meta-question: why was this scenario absent from the safety case at all? UL 4600 doesn't tell you how to detect flooding. It demands that your safety case explicitly enumerate environmental conditions, ODD boundaries, and — critically — that you have a defensible argument for scenario completeness, including a process for the scenarios you haven't thought of yet. A UL 4600 assessor reviewing Waymo's pre-April safety case would have asked one question: "Show me the hazard analysis entry for standing water on the roadway, broken out by road-speed class." If that entry doesn't exist, the safety case has a hole, and the standard's "argument by completeness" clauses are where it gets caught.

One more framing, because it matters for how you write the requirements: this is not an ISO 26262 ASIL story at its core, but you should still run the HARA row, because the consequence — loss of vehicle control, vehicle leaves the roadway — is a classic 26262 hazard. SOTIF and 26262 aren't competitors here; SOTIF tells you the scenario was missing, and the HARA tells you how bad it is when it isn't.

3. A worked snippet

3a. HARA row (ISO 26262-3 §7) — the consequence side

| ID | Operating scenario | Hazard | S | E | C | ASIL | Safety Goal | |---|---|---|---|---|---|---|---| | HZ-FLD-01 | Driverless L4 vehicle, higher-speed arterial, active rainfall, untraversable flooded lane ahead | Vehicle enters standing water it cannot traverse; loss of traction / loss of vehicle control; vehicle leaves roadway | S3 (swept into waterway — potentially fatal if occupied) | E3 (flood-prone arterials are a medium-probability operating situation in TX/AZ service areas) | C3 (no driver present; remote assistance latency exceeds the maneuver window) | ASIL C | SG-FLD-01: The ADS shall not enter a roadway section classified as an untraversable flooded lane; it shall reach a minimal risk condition outside the flooded section. |

A note on the ratings, because they'll get argued: E is the debatable axis. Rate flood exposure E2 and you land at ASIL A; rate it E3 — defensible given Texas flash-flood frequency and the "higher-speed arterial" qualifier — and you land at ASIL C. I'd defend E3. C3 is not debatable for a driverless L4 vehicle: there is no human in the loop, and remote assistance cannot react inside the seconds-long window between "lane is flooded" and "vehicle is in the water."

3b. SOTIF scenario classification — where this scenario lived

| Scenario | Before Apr 20, 2026 | After Apr 20 | After OTA remedy (target) | |---|---|---|---| | Untraversable flooded lane, low-speed surface street | Known / Safe (speed reduction acceptable) | Known / Safe | Known / Safe | | Untraversable flooded lane, higher-speed arterial | Unknown / Unsafe | Known / Unsafe | Known / Safe | | Standing water of indeterminate depth, any road class | Unknown / (unevaluated) | Known / Unsafe | Known / Safe — depth-gated MRC |

The middle row is the recall. The bottom row is the one I'd be nervous about: "indeterminate depth" is the next triggering condition, and a map patch doesn't cover it.

3c. Fault tree — top event: vehicle enters untraversable flooded lane

Top: Driverless vehicle enters an untraversable flooded lane
        OR
        ├── A. Flooded lane not detected
        │       (NOT the April 20 case — perception worked — but keep the leaf)
        ├── B. Flooded lane detected, classified untraversable, vehicle proceeds anyway
        │       AND
        │       ├── B1. Behavior policy maps "untraversable flooded lane" to
        │       │        speed-reduction instead of full-stop / MRC
        │       └── B2. Policy is not gated on road-speed class
        │                (same response on a 50 mph arterial as a 25 mph street)
        ├── C. Flooded lane detected but ODD-exit handler not invoked
        │       OR
        │       ├── C1. "Untraversable flooded lane" not enumerated as an ODD exit condition
        │       └── C2. ODD-exit handler exists but has no safe-stop maneuver for
        │                "hazard is in the lane ahead, not at a map boundary"
        └── D. Map-based flood prior absent for the road segment
                (interim fix patches D — but D alone never was the safety mechanism)

The April 20 event is branch B — and B1 ∧ B2 is the precise defect. The OTA remedy has to break that AND gate and, ideally, also close C1, because relying only on the map prior (D) means every un-mapped flooded road is still live.

4. Derived requirements (excerpt)

Traceable, with stable IDs. These are the rows I'd expect to see added to Waymo's requirement set — and the rows any other L4 developer should check they already have.

REQ-FLD-005 is the one I'd fight for in review. The interim containment — "we updated the map" — is fine as containment. It is not acceptable as the remedy, because it makes map freshness a safety dependency, and maps go stale. The detection-and-stop path has to stand on its own.

5. What the headline really tells us

The headline says a robotaxi drove into a flood. The engineering record says something narrower and more useful: a correctly-functioning system executed a behavior policy that was specified for one operating context and silently applied in another. No sensor failed. No code threw an exception. The vehicle did what it was told — and what it was told was incomplete.

That is the signature of a missing artifact. Specifically: a missing ODD exit condition, a missing SOTIF triggering-condition entry, and a behavior-policy requirement that was never gated on road-speed class. The recall isn't the failure. The failure is that "untraversable flooded lane on a higher-speed arterial" was sitting in the Unknown/Unsafe quadrant of a 2×2 that the entire SOTIF process exists to empty out — and it took a vehicle in a creek to move it.

Waymo's response was, procedurally, close to a model citizen's: detect, contain within days, file voluntarily, remedy over the air across the whole fleet. Credit where due. But the cleanest version of this story is the one where the row already existed in the hazard analysis, the requirement already said "gate on road-speed class," and April 20 never generated a headline because the vehicle stopped at the water's edge. The standards to write that row — ISO 21448, ISO 26262-3, UL 4600 — were all on the shelf before the rain started.

— Jherrod Thomas, The Lion of Functional Safety™

Sources