The Autonomous Trucking Shakeout and What It Means for Safety-Critical Systems Engineering

The autonomous trucking industry spent five years producing demonstrations, securing funding, and making announcements. It is now doing something harder: deploying trucks commercially on public highways, building safety cases that must satisfy federal regulators, and managing requirements across vehicle fleets that accumulate operational data faster than most engineering teams can process it.

Several well-capitalized companies did not survive the transition. The ones that remain — Aurora, Waymo Via, Torc Robotics (embedded within Daimler Truck), Kodiak Robotics, and a handful of others — are no longer startups in the conventional sense. They are regulated entities approaching commercial scale, and the engineering practices appropriate for a prototype phase are structurally incompatible with what comes next.

This article is not about which companies will win commercially. It is about what commercial-scale autonomous trucking actually demands from systems engineering teams — and why many of those teams are facing a reckoning with tooling, process, and safety argumentation infrastructure that they deferred during the prototype years.

The Gap Between Prototype Practice and Fleet Reality

During the prototype phase, requirements management at most AV companies was informal by design. The priority was iteration speed. Requirements lived in Confluence pages, Notion docs, shared spreadsheets, or the heads of senior engineers. Traceability between requirements, design decisions, and test evidence was approximate at best. Safety analysis was episodic — conducted before major milestone reviews, then set aside.

This is not unusual or blameworthy. Startups optimize for survival. Rigid process at seed stage is a competitive disadvantage.

The problem is that the habits of prototype engineering calcify. Teams that survived by moving fast built cultures and tooling stacks that reward fast movement and penalize rigor. Transitioning those teams to the level of engineering discipline required for FMVSS compliance, NHTSA safety reports, and ISO 26262 automotive safety integrity levels is not a process improvement — it is a cultural and infrastructure transformation.

The surviving autonomous trucking companies are mid-transformation right now. Understanding the specific systems engineering challenges they face clarifies what that transformation actually requires.

ODD Documentation at Scale Is a Systems Engineering Problem

Operational Design Domain — the structured description of the conditions under which an automated driving system is designed to function safely — was a manageable artifact at the prototype stage. A few dozen pages describing geographic bounds, weather constraints, speed ranges, road types, and infrastructure dependencies was sufficient to support early demonstrations.

At fleet scale, ODD documentation becomes a living system. A commercial fleet operating across defined freight corridors accumulates operational data continuously: edge cases encountered, weather events logged, infrastructure changes recorded, near-miss events analyzed. Each of these creates potential pressure on the ODD boundary. Either the boundary holds and the event is explained as within-ODD performance, or the ODD itself must be revised and the safety case updated accordingly.

This is not a documentation problem. It is a traceability problem. Every ODD constraint should trace to one or more safety claims. Every safety claim should trace to evidence — test results, simulation data, operational miles under defined conditions. When the ODD changes, the safety engineer needs to know immediately which claims are affected, what evidence gaps open up, and what re-validation is required before the updated ODD is operationally active.

Manual management of this traceability chain breaks down at scale. A fleet of 500 trucks operating across six states, logging incidents across varying weather and traffic conditions, cannot be safely managed with spreadsheet-based RTMs and quarterly safety reviews. The engineering infrastructure has to be capable of continuous update.

ISO 26262 and SOTIF Applied to Class 8 Trucks

ISO 26262 was developed for passenger vehicles. The standard is mature, well-understood, and widely implemented — but applying it to Class 8 autonomous trucks requires careful interpretive work that should not be treated as boilerplate.

The most significant differences are mass and stopping distance. A loaded Class 8 truck can weigh 40 tons. Stopping distances at highway speeds are substantially longer than passenger vehicle assumptions embedded in many ASIL derivation examples. Hazard analysis and risk assessment (HARA) must account for these physical realities explicitly — the severity ratings for many failure modes are higher than equivalent passenger vehicle scenarios, which drives ASIL levels up and therefore increases the rigor required across the entire development lifecycle.

SOTIF (ISO 21448), which addresses safety of the intended functionality — specifically, the hazards arising from the limitations of sensors, algorithms, and machine learning systems rather than hardware failures — presents a different challenge. SOTIF was designed for advanced driver assistance systems at SAE Level 2. Applying its framework to SAE Level 4 highway automation requires extension. The standard’s approach to defining unknown unsafe scenarios and measuring their reduction over operational miles is conceptually sound, but the practical methodology for closing SOTIF cases at fleet scale has not been standardized. Each company is currently developing its own approach, subject to regulatory review.

The emerging NHTSA FMVSS framework for automated driving systems adds another layer. Federal motor vehicle safety standards were written for human-driven vehicles. The agency has been developing updated provisions for ADS-equipped vehicles, including requirements for ADS failure response behavior, event data recording, and safety reporting. Companies deploying commercial fleets are navigating a regulatory environment that is still partially under construction, which means their safety cases must be written to current standards while remaining structurally extensible as those standards evolve.

Safety Case Development as Continuous Engineering

The Goal Structuring Notation (GSN) safety case is increasingly the expected artifact for demonstrating that an autonomous system is safe for deployment. Regulators, OEMs, and major fleet customers are beginning to require structured safety arguments — not just test reports, not just simulation data, but explicit argumentation showing how evidence supports safety claims.

A safety case developed once and submitted is a compliance document. A safety case that functions as a living engineering artifact — updated as evidence accumulates, revised as the ODD evolves, extended as new scenarios are validated — is something different. It is an operational safety system.

The distinction matters because autonomous trucks will encounter scenarios their developers did not anticipate. When a novel event occurs, the engineering team needs to be able to trace it: Does this event fall within the current ODD? Which safety claims are relevant? What is the current evidence basis for those claims? Is the evidence still adequate given this new data point?

A safety case architecture that can answer those questions in near-real time requires several things to be true simultaneously: requirements must be structured and machine-readable, not buried in prose documents; traceability links must be explicit and maintained, not implied; safety claims must be versioned and auditable; and evidence must be formally linked to claims rather than referenced loosely.

Most AV companies built their safety cases in tools not designed for this use. Word documents, PowerPoint decks, and PDF submissions are adequate for milestone reporting. They are not adequate for continuous operational safety management at fleet scale.

The Engineering Infrastructure Gap

The consolidation of the autonomous trucking industry has created a specific engineering talent dynamic: the survivors absorbed many of the engineers from companies that failed, concentrating expertise but also concentrating technical debt. Many of those engineers built their early safety cases in whatever tooling was available. Migrating that work to more rigorous infrastructure is expensive, and the pressure to maintain deployment timelines creates resistance to migration.

This is where tooling becomes a strategic question rather than a procurement decision. The systems engineering infrastructure a company builds now will determine whether it can sustain its safety argument across ten million operating miles, across fleet updates, across regulatory changes, and across the inevitable incidents that will require safety case revision under public scrutiny.

Tools like IBM DOORS and DOORS Next are mature, widely audited, and familiar to safety engineers trained in aerospace and defense contexts. Their strength is regulatory credibility — if your safety case is in DOORS, a regulator who has reviewed DOORS-based cases before will have a consistent review experience. Their limitation at autonomous trucking scale is that they are fundamentally document-centric and require significant manual effort to maintain traceability as requirements evolve rapidly. They were not designed for the volume of operational feedback that a commercial AV fleet generates.

Jama Connect offers better usability and has made inroads in automotive contexts, but the traceability model remains relatively linear — requirements trace down to test cases, not across to dynamic operational evidence or continuously updated safety claims. For teams managing static requirement sets against fixed product releases, Jama is effective. For teams managing an ODD that may change quarterly based on operational data, the workflow becomes strained.

Codebeamer, with its lifecycle management scope, handles more of the ASPICE process integration that automotive OEM partnerships require. Companies like Torc, embedded within Daimler, have regulatory and process obligations that extend into OEM supplier requirements — Codebeamer’s strength in that context is real.

What the autonomous trucking context specifically demands — graph-based requirement relationships, AI-assisted impact analysis as the ODD changes, and traceability that connects operational evidence to live safety claims — is where newer, AI-native tooling has a structural advantage. Flow Engineering, built around a graph model of requirements and their relationships, is designed for exactly the kind of dynamic traceability that fleet-scale safety case management requires. The ability to propagate a change to an ODD boundary and immediately surface every affected safety claim, every open evidence gap, and every requirement that needs review is not a workflow feature — it is the core capability that separates safety case management from safety case documentation.

For teams rebuilding their systems engineering infrastructure in preparation for commercial scale, the choice of foundation matters more than almost any other infrastructure decision they will make.

What Regulators and Insurers Will Actually Look For

NHTSA’s current posture on autonomous trucks emphasizes three things: systematic safety processes, transparent incident reporting, and demonstrable safety improvement over operational miles. The third point is structurally important. The agency is not expecting zero incidents at initial deployment. It is expecting companies to demonstrate that their safety argument improves as operational data accumulates — that the system becomes provably safer as miles increase, and that the engineering infrastructure can demonstrate that improvement rigorously.

Insurers are developing similar frameworks. Commercial fleet operators considering autonomous truck deployment will face actuarial requirements that demand structured safety evidence. The insurance market for autonomous heavy vehicles is immature, which means underwriters are currently building their own risk models. Companies that can provide structured safety case evidence, traceability to operational data, and systematic incident analysis will access better coverage at lower cost than those presenting safety narratives in unstructured form.

This creates a direct commercial incentive for rigorous systems engineering that did not exist during the prototype phase. A well-structured safety case is not just regulatory compliance — it is a financial asset.

Honest Assessment

The autonomous trucking companies that survived the shakeout are genuinely capable. Their perception stacks are mature. Their operational performance on defined corridors is strong. The engineering talent concentrated in the survivors is world-class by any reasonable measure.

The risk is not technical capability — it is engineering infrastructure. Companies that built prototype-phase tooling and processes and have not yet made the structural investment in safety-grade systems engineering are carrying a debt that will become visible under the scrutiny of commercial deployment. A safety case that cannot be updated continuously, a requirements model that cannot trace to operational evidence, and an ODD that cannot propagate changes to downstream safety claims are not adequate foundations for fleets operating at commercial scale.

The companies that will define the industry over the next five years are not necessarily those with the highest-performing perception systems. They are the ones that can sustain a coherent safety argument across millions of operating miles, multiple regulatory regimes, and the inevitable public incidents that will require those arguments to hold up under scrutiny.

That is a systems engineering problem. It deserves to be treated as one.