How Systems Engineering, AI-Augmented Requirements, and Scalable E/E Architecture Are Unlocking the Next Era of Autonomous Mobility
Spend enough time building autonomous vehicle systems and you develop a fairly strong opinion about where the real difficulty lies. It's not in the algorithms — at least not primarily. The perception stacks have matured enormously over the past decade, compute is cheaper and faster than ever, and the simulation infrastructure at leading AV companies now runs at a scale that would've seemed implausible ten years ago. But moving a program from a working prototype to something you can actually deploy, at volume, in multiple markets — that's where a different set of problems surfaces. And they're not glamorous problems. They're systems engineering problems.
I've built my career at that unglamorous frontier — requirements engineering, E/E architecture, system-level validation — across autonomous vehicles, industrial robotics, trucking, and mining. What I've found, consistently, is that teams who invest in this foundation move faster everywhere else. Teams that treat it as an afterthought spend the back half of their programs untangling integration problems that were baked in from the start.
The Requirements Problem Is Also an Opportunity
Here's the part that doesn't get talked about enough: a production-intent Level 4 autonomous vehicle has to satisfy an enormous number of overlapping regulatory frameworks simultaneously. ISO 26262 for functional safety. ISO 21448 (SOTIF) for intended functionality. ISO/SAE 21434 for cybersecurity. FMVSS in the US, UNECE WP.29 for European markets — and that's before you factor in the customer's own internal standards, which every OEM has in abundance. Every one of those standards is written in natural language. Dense, cross-referential, sometimes contradictory natural language that someone has to translate into actual testable system requirements.
At scale, that translation process becomes a genuine bottleneck. A mid-complexity AV program can carry tens of thousands of individual requirements. Keeping bidirectional traceability between regulatory source, system requirement, subsystem requirement, and verification evidence — manually — is slow, expensive, and error-prone in ways that tend to surface at the worst possible time.
The most promising response to this bottleneck is applying NLP directly to regulatory source text. Instead of asking engineers to draft requirements from scratch by reading dense standards documents, a well-designed framework can parse obligation language, resolve cross-references automatically, and produce structured requirement candidates for engineers to review and approve. The cognitive load shifts from transcription to judgment — which is a much better use of an experienced engineer’s time. And when regulations change, which they do, impact assessment against the existing baseline becomes something you can do systematically rather than hoping you caught everything manually. One implementation of this approach, developed during requirements work at Cruise, is documented in US12223559B1 — but the technique is applicable anywhere the same translation problem exists.
Architecture That Scales Across Domains
Requirements tell you what the system has to do. Architecture is the bet you make on whether it can. The vehicle's E/E architecture — how compute is distributed, how the networks are structured, where the zone controllers sit, how power states are managed — determines whether your latency budgets are achievable, whether your redundancy concept actually provides the fault tolerance it's supposed to, and whether a hardware change in one domain creates ripple effects everywhere else.
The industry's shift from domain-based architectures to centralized and zonal designs has been genuinely exciting to work through. It opens up capabilities that weren't practical before: consolidating high-performance compute, enabling meaningful over-the-air updates, building the hardware substrate that a real autonomy stack needs. At Applied Intuition, my team has developed unified ADAS hardware and functional architectures spanning L2++ through full Level 4, across programs with Porsche, Isuzu, and Komatsu.
That last part — three very different customers, three very different domains — has taught me something I don't think you can learn any other way. The redundancy principles that apply to a premium passenger vehicle and to an underground mining hauler are the same at the level of theory. The actual implementation has almost nothing in common. Different failure mode assumptions, different network topologies, different power constraints, GPS-denied environments on the mining side. You can't port an architecture across those boundaries; you have to re-derive it from the requirements each time. What model-based simulation gives you is the ability to validate that re-derivation before you've committed to any hardware — running network traffic models, latency simulations, power state analyses — so that the decisions you make early don't become expensive surprises during integration.
“Autonomous vehicles don’t just drive themselves — they’re built on a foundation of meticulously engineered systems, architectures, and requirements. That foundation is what I build.”
— Kunal Mehta
Simulation as Engineering Infrastructure
Everyone in this industry knows that you can't road-test your way to a sufficient safety case. The scenario space is too large, the tail events too rare, the cost of physical miles too high. Simulation is how the bulk of verification evidence actually gets generated. But simulation infrastructure is itself an engineered system — it has requirements, it has architecture, it has failure modes — and it rewards being treated that way.
At Cruise, I led a workstream to restructure how simulation was integrated into the development pipeline. The most consequential insight from that work wasn't the efficiency gain — it was what inefficient utilization had been masking. Redundant scenario coverage, CI/CD bottlenecks, test libraries organized by volume rather than coverage — none of these show up as line items on a program budget, but together they meant engineers weren't getting verification feedback quickly enough to act on it. When you fix that — structuring simulation as a tightly integrated part of the development pipeline rather than a post-design verification step — a requirements change can produce a verified simulation result in hours rather than days. That feedback loop changes how engineers make decisions: they take more careful requirements decisions when they can immediately see the verification consequences. The $2.3 million in annual savings that came out of this work at Cruise was a byproduct. The more durable result was a development pipeline where the cost of a wrong decision is measured in hours, not weeks.
Safety as a Fleet Property, Not Just a Vehicle Property
There’s a class of safety problem the AV industry hasn’t fully reckoned with yet: what happens when autonomous vehicles share an environment with other autonomous vehicles that are degraded? A vehicle with a failed sensor or a constrained operational domain doesn’t just behave less capably; it behaves differently from what surrounding systems would predict if they assumed nominal operation. That gap between predicted and actual behavior is a safety risk that individual vehicle safety cases don’t fully capture — and as deployments scale, it becomes harder to ignore.
Consider a concrete scenario: a robotaxi loses its forward lidar mid-mission. Its motion planning is now constrained — shorter following distances, reduced speed, limited ability to handle certain cut-in scenarios. Vehicles around it, however, continue to model it as a nominal agent with full sensing capability. In a high-density deployment, that mismatch between assumed and actual behavior is a latent hazard no individual vehicle safety case was designed to catch. The solution is for degraded vehicles to communicate their constrained state to peers in real time, so surrounding vehicles can widen their own safety margins accordingly — responding to actual system state rather than worst-case assumptions baked in at design time. One approach to formalizing this mechanism is documented in US20250095412A1, but the broader implication is architectural: as AV deployments scale from dozens to thousands of vehicles sharing corridors, fleet-level safety properties will need to be explicitly engineered. That’s requirements engineering applied to inter-vehicle interfaces, and it’s the kind of problem that only becomes tractable when architecture, requirements, and software are designed together from the start.
Where This Is All Going
Waymo is now running fully driverless commercial service across multiple U.S. cities. Aurora launched its commercial trucking operations on the Dallas-to-Houston corridor. Nuro has permits for uncrewed delivery in multiple states. These aren't prototypes — they're production operations, and the engineering bar they represent is categorically different from anything the industry was doing five years ago. The challenge ahead isn't proving that autonomous vehicles can work. It's proving they can work reliably, at scale, across diverse environments, for the full life of the product — and doing it fast enough that the business case holds before the next funding cycle tightens.
That challenge is a systems engineering challenge. The methods exist — MBSE, AI-augmented requirements analysis, simulation-in-the-loop validation, formally specified inter-vehicle protocols. What they need is consistent investment and the organizational recognition that getting the foundation right is what makes everything built on top of it possible. The companies that treat this as a first-class engineering investment — not a compliance exercise, not an afterthought — are the ones that will still be operating at scale in ten years. The foundation determines everything built on top of it. That has always been true in engineering. In autonomous vehicle technology, we’re finally in a position to prove it.
About the Author
Kunal Mehta is Engineering Manager of Architecture and Systems at Applied Intuition, leading systems architecture programs for global OEM customers across automotive, trucking, and mining. Previously a Staff Systems Engineer at Cruise GM LLC, he contributed to one of the first ground-up Level 4 autonomous vehicles tested in the United States. He holds seven U.S. patents in autonomous vehicle technologies, is a Certified INCOSE Associate Systems Engineering Professional (ASEP), and holds an M.S. in Systems Engineering from the University of Maryland, College Park.