Three Headlines, Three Engineering Fixes

Every news cycle brings another autonomous-vehicle headline that sounds like a technology problem but reads, to anyone who's run a HARA, like a process problem. The public sees a recall, an investigation, or a CVE. We see a missing safety goal, a fault-tree leaf no one expanded, or a TARA risk that was accepted when it should have been mitigated.

This post takes three of the most-discussed stories of the last six months — Tesla's escalated NHTSA Full Self-Driving probe, Waymo's school-bus software recall, and a pair of Nvidia Jetson Orin CVEs — and re-frames each one as a solvable engineering deliverable. For each, I show:

1. The public record (what actually happened, with sources).
2. The standards lens — which clause, which work product would have caught it.
3. A worked snippet — a HARA row, a fault tree, an FMEA line, a TARA scenario, a derived requirement.
4. The downloadable artifact — an audit-style workbook attached to the post.

If you take one thing from this piece, take this: every one of these stories has a clean engineering answer that fits inside the standards we already have. The work isn't invention — it's discipline.

1. Tesla FSD: When "Vision-Only" Meets a Foggy Morning

The public record

In March 2026, NHTSA upgraded its Tesla FSD investigation from Preliminary Evaluation PE24031 to Engineering Analysis EA26002, the procedural step that historically precedes a recall. The probe now covers an estimated 3,203,754 vehicles. NHTSA's letter cites nine crashes in reduced-visibility conditions (sun glare, fog, airborne dust) — including one that struck and killed a pedestrian — and calls out a specific defect mode: "the [degradation detection] system did not detect common roadway conditions that impaired camera visibility and/or provide alerts when camera performance had deteriorated until immediately before the crash occurred." (Electrek, NHTSA upgrades Tesla FSD visibility investigation, March 2026.)

This is not a perception-accuracy story. It is a monitoring-of-monitoring story: the system that is supposed to know when the primary sensing channel is compromised is itself silently failing.

The standards lens

If we treat the Tesla FSD camera array as the item, ISO 26262-3 §7 (HARA) gives us the right starting place. The hazard is not "camera fails" — it's "vehicle continues to provide automated driving capability while the camera-based perception is degraded below the level required for the maneuver." That maps to malfunction guide-word M07 (incorrect output) combined with M11 (loss of monitoring) in a standard HARA grid.

The right answer in the FSC (ISO 26262-3 §8) is a pair of safety goals enforced by a fail-operational degradation strategy: a) detect degradation within a bounded time, b) reduce the function's authority (hand-off, slow, MRC) before the function makes an unsafe commitment.

ISO 21448 (SOTIF) then carries the load that ISO 26262 cannot: glare and fog are not random hardware faults — they are triggering conditions in the ODD that the intended functionality must recognize and respond to. Camera blinding is the textbook SOTIF triggering condition.

Worked snippet — HARA row

| ID | Operating scenario | Malfunction | S | E | C | ASIL | Safety Goal | |---|---|---|---|---|---|---|---| | HZ-CAM-01 | Highway, low sun, FSD active at posted speed | Vision pipeline degraded by direct glare; degradation monitor fails to alert within FTTI | S3 (life-threatening) | E4 (high probability) | C2 (alert driver could control, but Level 2/2+ context implies inattention) | ASIL D | The system shall detect camera-perception degradation and either (a) issue a take-over request and reduce vehicle authority, or (b) execute a minimum-risk maneuver, before any planned trajectory is committed under degraded perception. |

Worked snippet — Fault Tree (top event: pedestrian collision under degraded vision)

Top: Pedestrian collision while FSD active in low-visibility
        OR
        ├── A. Camera-blinded condition not detected
        │       OR
        │       ├── A1. Glare detector saturation thresholds set above realistic glare flux
        │       ├── A2. Fog/dust detection relies on a single feature (contrast loss) without redundancy
        │       └── A3. Detection latency > FTTI (function commits maneuver before alert fires)
        ├── B. Detection occurs but no MRC executed
        │       OR
        │       ├── B1. HMI take-over request rate-limited / suppressed
        │       ├── B2. Lateral control unwilling to release without driver torque
        │       └── B3. No fall-back planner with conservative ODD bounds
        └── C. Driver assumed to be the safety mechanism but cannot be (Level 2/2+ inattention drift)

Derived technical safety requirements (excerpt)

• TSR-CAM-001 — The perception subsystem shall detect a sustained per-camera SNR / contrast / glare-flux excursion within 150 ms and assert a "perception degraded" signal to the supervisor.
• TSR-CAM-002 — The supervisor shall, upon "perception degraded," reduce the longitudinal authority to the driver-assisted band and request take-over within 300 ms, satisfying the chosen FTTI of 600 ms.
• TSR-CAM-003 — The degradation detector shall be diverse from the primary perception path (separate features, separate compute lane) to satisfy the independence claim used for ASIL D (D(B)+B decomposition per ISO 26262-9).
• TSR-CAM-004 — Driver-monitoring data shall not be used as the only mitigation for degraded forward perception (no human-in-the-loop credit for a Level 2/2+ system in scenarios where the FTTI is shorter than realistic human response).

2. Waymo: A "Polite Driver" Heuristic That Outvoted a Stop Sign

The public record

In December 2025, Waymo filed a voluntary software recall covering 3,067 robotaxis with production dates between 20 August and 5 November 2025 after the Austin Independent School District documented 20 incidents in which Waymo vehicles illegally passed stopped school buses with stop-arms extended. Atlanta Public Schools had previously documented six similar incidents, which triggered an NHTSA Office of Defects Investigation (ODI) probe in October. Reporting from TechCrunch (Dec. 5, 2025) and Axios characterised the root behavior this way: the planner had a feature designed to avoid impeding "priority vehicles" such as public buses, and it "determined that it may be impeding the school bus and reasoned that it should proceed in order to cease impeding the other vehicle."

In plain English: a courtesy heuristic for not blocking a city bus on a normal street outvoted the "stop arm extended → it is illegal to pass" rule. An interim November 2025 software push did not fully fix it, which is why the December recall was filed.

The standards lens

This is not a perception failure. The bus and stop-arm were detected. This is a behavior-planning conflict-resolution failure — a SOTIF (ISO 21448) functional insufficiency where two correct sub-behaviors interact to produce an unsafe outcome that neither, alone, would produce. SOTIF Annex B's two-by-two — "Known Safe / Known Unsafe / Unknown Safe / Unknown Unsafe" — is the right home for this. Until December 2025, this scenario was sitting in the Unknown Unsafe quadrant: nobody on the team had written it down as a triggering condition.

The right work products are:

• An ODD entry that explicitly enumerates "school bus with deployed stop-arm" as a distinct entity class, separate from "public transit bus."
• A scenario library entry with the conflict — the stop-arm rule must be a hard constraint that dominates all "courtesy / impedance" heuristics.
• A PFMEA-style table at the behavior layer for the planner's rule-precedence logic.

Worked snippet — FMEA at the behavior layer (AIAG-VDA AP scoring)

| Function (planner rule) | Failure mode | Effect | S | O | D | AP | Mitigation | |---|---|---|---|---|---|---|---| | Avoid impeding priority vehicle | Rule fires when priority vehicle is a stopped school bus with stop-arm | Vehicle moves past stop-arm; child struck risk | 10 | 4 | 6 | High | Add hard precedence: stop-arm-extended ⇒ ego must remain stopped; courtesy rules cannot override | | Detect stop-arm | Stop-arm partially occluded by bus body | Stop-arm rule not triggered | 10 | 3 | 5 | High | Multi-frame persistence + map-prior ("school zone") + V2X if available | | Resume from stop | Resume when bus indicates intent to move | Premature resume while children still crossing | 10 | 2 | 5 | High | Require N seconds clear-roadway perception and bus stop-arm retracted and bus signal indicating departure |

Derived requirements (excerpt)

• REQ-PLAN-101 — The planner shall treat "school bus with stop-arm extended" as a hard-stop precondition; no policy, courtesy, or impedance heuristic shall produce a longitudinal command that crosses the stop-arm latching line until the stop-arm is retracted.
• REQ-PLAN-102 — Rule-precedence in the behavior planner shall be expressible as a partial order, with safety-of-vulnerable-road-users rules at the top of the order and "do not impede other traffic" rules strictly below.
• REQ-PLAN-103 — The system shall log every instance where a courtesy rule was suppressed by a higher-priority rule, for SOTIF triggering-condition mining.
• REQ-VAL-104 — The closed-loop scenario library shall include parameter-swept school-bus encounters (bus orientation, stop-arm latency, occlusion fraction, child presence) as acceptance gates, not regression-only.

The recall isn't the failure — the failure is that the scenario was not in the acceptance gate to begin with.

3. Nvidia DRIVE / Jetson Orin: When the Compute Platform Itself Is the Attack Surface

The public record

Two complementary stories define Nvidia's automotive-AI position right now. On the positive side, Nvidia announced in 2025 that the DRIVE AGX Hyperion platform achieved ISO 26262 (functional safety) and ISO/SAE 21434 (cybersecurity) milestones with TÜV SÜD and TÜV Rheinland — a real and meaningful certification for an AV compute platform. On the threats side, Nvidia's own product-security program disclosed multiple vulnerabilities affecting Jetson Orin (and IGX Orin) modules in its July 2025 Security Bulletin, including CVE-2025-33182 and CVE-2025-33177, fixed in JetPack 5 / 6 / 7 updates and Jetson Linux 35.6.2 / 36.4.4. (Nvidia Security Bulletin, July 2025.)

Jetson Orin is not DRIVE Thor — but the family relationship matters: many AV development programs prototype on Jetson, robotics startups ship on Jetson, and the same Tegra-line software stack threads through both. Any honest TARA on a DRIVE-based ECU should include the supplier vulnerability cadence as an assumption that drives requirements, not as a "trust the vendor" footnote.

The standards lens

ISO/SAE 21434 Clause 15 (TARA) is unambiguous on this point. The compute platform is an asset. Its trust assumptions — secure boot, signed JetPack updates, attested firmware — are claims that can fail. The TARA must enumerate threats that target those claims, score them with the impact × attack-feasibility matrix, and either accept the residual risk (with rationale) or derive cybersecurity goals (CSGs) that mitigate it.

Worked snippet — TARA row (STRIDE-aligned)

| ID | Asset | Damage scenario | Threat (STRIDE) | Impact (S/F/O/P) | Feasibility | Risk | Treatment | Cybersecurity Goal | |---|---|---|---|---|---|---|---|---| | TH-PLT-01 | AV compute SoC firmware | Attacker exploits unpatched Orin-class CVE chain to gain root and modify perception output | Tampering, EoP | S=Severe, F=Major, O=Severe, P=Moderate | Medium | High | Reduce | CSG-PLT-01: The AV compute platform shall enforce verified secure boot, signed firmware update with rollback protection, and attested runtime firmware integrity, such that an attacker cannot persist a modified perception or planner image across a power cycle. | | TH-PLT-02 | OTA delivery channel | Forged JetPack/AV image delivered to fleet | Spoofing | S=Severe, F=Major | Low | Medium | Reduce | CSG-PLT-02: The OTA pipeline shall enforce mutual authentication, code signing with HSM-protected keys, and per-vehicle freshness/anti-rollback nonces. | | TH-PLT-03 | Diagnostic / debug interfaces | Lab-bench reuse of debug bridge in production | Information disclosure, Tampering | S=Moderate, F=Moderate | Medium | Medium | Reduce | CSG-PLT-03: Debug, JTAG, and developer interfaces shall be disabled, fused, or authenticated by ECU lifecycle state in production builds. |

Derived technical cybersecurity requirements (excerpt)

• CSR-PLT-01 — Firmware update process shall reject any image whose signature does not chain to a key resident in a hardware root of trust, in line with ISO/SAE 21434 §10 control "use of cryptographic mechanisms".
• CSR-PLT-02 — The vehicle program shall maintain a CVE-to-asset traceability workbook, updated on each Nvidia security bulletin, and shall close any HIGH/CRITICAL CVE affecting an in-fleet platform within a defined SLA before treating the residual risk as "Accepted".
• CSR-PLT-03 — Independence between the safety supervisor and the application compute domain shall be enforced at the SoC/board level (ISO 26262-9 freedom-from-interference) so that a compromise of the application domain cannot directly modify the safe-state actuator path.

What these three stories have in common

If you stack the three side-by-side, the same shape appears:

• Tesla — a missing monitor of a monitor. The right artifact is a HARA row that demands detection of perception degradation, plus a TSR with a numerically-defined FTTI.
• Waymo — a missing precedence rule between two correct sub-behaviors. The right artifact is a SOTIF triggering-condition entry plus a behavior-layer FMEA that scores "courtesy heuristic outvotes safety hard rule" as High AP.
• Nvidia — a missing platform-supplier risk in the TARA. The right artifact is a 21434 risk row and a cybersecurity goal that pulls patch cadence into the V-model rather than leaving it to IT.

None of these require a new standard. ISO 26262, ISO 21448, and ISO/SAE 21434 already say everything that needs saying. What they don't do is fill themselves out — the discipline of putting the row in the table, the leaf in the tree, and the requirement in the spec is what turns a future headline into a closed action item.

If you're an OEM or Tier-1 reading this and you don't have the equivalent rows in your live trace tooling, that gap is the actionable thing — not the headline.

If you want to walk through how either of these workbooks would slot into your program — whether you're an OEM, a Tier-1, an AV startup running Jetson on the bench, or a fleet operator — the contact link on the main site is the fastest way to reach me.

— Jherrod Thomas, The Lion of Functional Safety™