Abstract: When the AI in a driverless car can’t handle the situation, does the industry have a coherent emergency-management playbook? It doesn’t — and worse, no reference standard exists. Starting from the March 31, 2026 Wuhan Apollo Go incident, this post walks through three recent body blows to the Robotaxi industry, scans every gap in the ISO / SAE / IEC / China standards landscape on remote operations, traces the fundamental regulatory pivot after Wuhan, and introduces ROAM (Remote Operations & Anomaly Management) — an open-source reference architecture with four modules, ten future operating models, and a 52-standard scan that confirms the void.

March 31, Wuhan.

During evening peak hours, nearly a hundred Apollo Go robotaxis went dead at the same time on an elevated highway. Passengers were trapped inside. SOS buttons unresponsive. Customer hotlines unreachable. The eventual solution?

Traffic police, one car at a time, by hand.

The whole thing took two hours.

That same day, on the other side of the Pacific, U.S. Senator Markey released a report titled Remote Back Seat Operators. He had asked seven leading AV companies (Aurora, May Mobility, Motional, Nuro, Tesla, Waymo, Zoox) one simple question:

How often does your driverless car require remote human intervention?

All seven gave a uniform answer: business secret, decline to respond.

Figure 1: Senator Markey’s Remote Back Seat Operators report

Put these two events together and they point at the same problem: when the AI in a driverless car can’t handle the situation, does the industry have a coherent emergency-management playbook?

It doesn’t. And more disturbingly, no reference standard exists.

1. Three Body Blows for Robotaxi

Pull the timeline out a little. From late 2025 through early 2026, the industry took three body blows in a row.

December 13, 2025 — San Francisco grid outage. More than 20 Waymo vehicles lost connectivity and stalled across the city. Emergency services dialed Waymo’s hotline 31 times, accumulating 2 hours and 36 minutes on hold. Waymo later admitted: with the network down, they had no way to recall the area’s vehicles as a fleet.

March 31, 2026 — Wuhan Apollo Go incident. Bigger in scale — nearly a hundred vehicles failed simultaneously, with passengers trapped on an elevated road. Every remote channel collapsed at once: SOS, customer service, remote intervention.

Earlier, October 2023 — Cruise dragged a pedestrian six meters in San Francisco. Remote operators failed to intervene in time. NHTSA fined Cruise 1.5 million USD; the entire fleet was recalled.

Three incidents, three countries, three companies, three technology stacks. But the exposed problem is uncannily identical: when systemic failure hits, no one knows what to do.

This isn’t one company’s mismanagement. The whole industry is missing a piece.

2. What Exactly Is Missing?

It isn’t technology. It’s governance.

For SOTIF we have ISO 21448. For functional safety, ISO 26262. For scenario-based testing, ISO 34502. For cybersecurity, ISO/SAE 21434.

But — remote operations and anomaly management?

I ran a systematic scan. The result:

ISO — zero. SAE — zero. IEC — zero.

SAE J3016 even explicitly refuses to define the term “remote operation,” citing “lack of consensus across stakeholders.”

China’s standards landscape is slightly better, but the problem is “four parallel tracks, each in its own silo”:

  • The telecom track has the YD/T 4778–4783 series (5G remote driving)
  • The automotive track has a mandatory GB under draft
  • The transport track is working on credentialing for remote safety operators
  • The cybersecurity track is on whole-vehicle cyber

Across the four, there is no integrating reference architecture.

To put it plainly: everyone is writing “technical-requirement” standards — telling you what to achieve. But no one is writing the “reference-architecture” standard — telling you how to do it, who is accountable, and how to measure it.

It’s like fire codes mandating an extinguisher in every building, but never specifying where it goes, who inspects it, or how often.

The Markey report disclosed an interesting data point: communication latency for remote assistance varies wildly between operators. Some companies report ~100 ms domestically; overseas sites jump to 250 ms. Academic consensus puts 300 ms as the threshold beyond which remote-operator driving performance degrades sharply — and some companies’ numbers are already close to that line.

But because no federal latency standard exists, every company is effectively setting its own safety thresholds. It’s like having a highway with no speed limit and asking each driver to pick their own.

3. After Wuhan, Regulation Changed

The aftershock from Wuhan went well beyond what most observers expected.

Within 14 days, three Chinese ministries (MIIT, MPS, MOT) convened an emergency national safety regulatory meeting. More than 10 pilot cities tightened admission, paused expansion, and ran full audits in parallel.

The whole regulatory logic of the industry pivoted:

From “tolerant and prudent, encouraging innovation through trial and error,” to “rigid safety floors, end-to-end accountability.”

Concretely, the new direction includes:

  • Regulatory scope expanded from individual-vehicle safety to “cloud-network-edge-vehicle” systemic safety
  • Vehicles must carry an independent minimum-safety system that, with cloud and network fully down, can autonomously slow, pull over, hazard-light, and unlock doors
  • “Admission–operation–exit” lifecycle dynamic regulation
  • Companies that experience a major systemic failure lose their license and cannot reapply for three years

What does this say? Regulators have woken up to systemic-failure risk. But regulators draw the floor; the industry still needs an actionable reference architecture.

4. A Personal Attempt: the ROAM Open-Source Framework

Over the last few weeks, leaning hard on AI tooling, I did one thing: scaffold the missing reference architecture, push it open-source, and let everyone iterate it.

The project is ROAM — Remote Operations & Anomaly Management for L4 autonomous driving.

Figure 2: ROAM open-source framework

Apache 2.0. Use it, fork it, contribute back.

ROAM isn’t a slide deck or a white paper — it’s an executable governance kit, currently four modules:

4.1 Incident database

16 structured incident records, covering Waymo, Apollo Go, Pony.ai, Cruise. Each entry uses a common YAML schema with consistent field definitions, which lets you compare across operators.

4.2 Scenario taxonomy

6 top-level categories, 27 sub-scenarios — from systemic outages all the way down to passenger-stranding. Every scenario carries a Severity (S0–S4) and Urgency (U0–U3) tag.

4.3 Three-layer decision reference architecture

  • Layer 1: AI handles autonomously — target ~70% of anomalies
  • Layer 2: AI-assisted with human confirmation — ~25%
  • Layer 3: Remote driving or in-person rescue — ~5%

Each layer has an explicit response-time target; misses auto-escalate.

4.4 Evaluation baseline

8 KPIs — MTTR, AI autonomy rate, false-escalation rate, miss-escalation rate, operator acceptance rate, communication latency, passenger-perceived safety, compliance rate.

On top of those four modules, ROAM also does two things:

  • Maps out 10 likely operating models for L4’s next decade — not just Robotaxi, but OEM subscription, personal sharing, L4 buses, autonomous delivery, mining/port-only fleets, and more — and builds a 10 × 3 × 4 accountability matrix (model × layer × dimension) for each
  • Runs a systematic scan of 52 international and Chinese standards relevant to remote operations, confirming a complete vacuum in the “reference architecture” niche

The open-source framework is only step one. Long-term, this field needs a formal standard.

My personal call: file a recommended national standard, working title “Intelligent Connected Vehicles — Automated Driving Systems — Remote Operations and Anomaly Management Reference Architecture.”

Why “reference architecture” rather than “technical requirements”? Because plenty of standards already cover the latter (Annex C.2 of the draft GB on AD safety; the YD/T 4778–4783 series; etc.). What the industry is missing is a frame that ties those requirements together — defining scenario classes, response flows, accountability splits, and KPI systems.

This isn’t a one-shot effort. The cadence is “open-source-first, standards-second”:

  • Near-term: keep accumulating incident cases, refining the taxonomy, baselining KPIs through the GitHub project
  • Mid-term: workshop with industry experts; formally file a GB/T
  • Long-term: based on the Chinese standard, file a New Work Item proposal at ISO/TC22

The post-Wuhan regulatory pivot precisely confirms that this field’s standardization need has graduated from “academic call” to “industrial necessity.”

There’s also a trend that’s easy to miss: L4’s future is not just Robotaxi.

Tesla’s long-term roadmap sells L4 as a subscription to private owners. NIO, XPeng, Geely and others are pushing private L4 vehicles for highway use. That means OEMs are pivoting from “we make cars” to “we provide remote-operations services” — every L4 car sold becomes a 24/7 remote-support obligation.

No standard covers that role transition today. ROAM’s 10 operating models and accountability matrix are an attempt to answer the question before it gets answered for us.

6. An Invitation

Figure 3: ROAM Explorer dashboard

If you’re a safety engineer at a Robotaxi operator — ROAM’s incident database needs more real cases.

If you’re an L4 product manager at an OEM — ROAM’s 10 operating models and accountability matrix may help you answer “who owns remote operations once my car ships to a private owner?”

If you’re a standardization professional — let’s talk feasibility and timing for a GB/T filing.

If you’re an academic peer — ROAM’s 52-reference scan and six-pillar technical analysis can serve as a starting point for your own research.

Honestly, the origin of ROAM was simple. On the night of March 31, 2026, watching the Wuhan news, my first reaction wasn’t technical commentary — it was a very practical question: if this happened on a project I was part of, would I have a standardized response playbook to pull off the shelf?

The answer was no. Because the industry didn’t have one — and there’s no way one person, on their own, can complete any single ROAM module to production quality.

So I chose to open-source it. Not because open source sounds noble, but because the problems in this field are too complex and changing too fast for any single company or university to solve behind closed doors. The novel anomalies operators are seeing, the operating-model innovations OEMs are inventing, the policy concerns from regulators — that information has to converge on a public platform before it can settle into a governance framework that survives contact with reality.

When the robotaxi fails, someone has to define how it gets caught. This can’t wait any longer.