Mobileye: The Systems Engineering Machine Behind ADAS at Scale

Mobileye ships silicon and software inside roughly 800 million vehicles. That number is frequently cited as a market achievement. It is more accurately understood as a systems engineering problem of unusual difficulty — one that the company has been solving, revising, and re-solving since Amnon Shashua founded it in 1999.

The engineering challenge is not just building perception that works. It is building perception that works across a product line spanning basic lane-keep assist, through multi-function ADAS, all the way to robotaxi-grade full autonomy — and deploying each tier across dozens of distinct vehicle platforms per year, each with its own sensor placement constraints, compute budgets, and OEM-specific functional requirements. Understanding how Mobileye approaches this problem is a useful case study for any organization that needs to manage safety-critical requirements at product-line scale.

The RSS Foundation: Formal Models as Requirements Infrastructure

Most automotive safety programs start with ISO 26262 and work outward. Mobileye did something structurally different when it published the Responsibility-Sensitive Safety (RSS) model in 2017. RSS is a mathematical framework that formalizes the conditions under which an autonomous vehicle can be considered “not at fault” in a collision scenario. It defines safe longitudinal and lateral distances as functions of vehicle kinematics and assigns clear blame attribution when those envelopes are violated.

For engineers outside Mobileye, RSS is often discussed as a philosophical statement about AV safety. Inside a systems engineering workflow, it functions as something more operationally useful: a formal model that converts informal driving intuitions into verifiable conditions against which requirements can be checked.

This matters because one of the persistent failure modes in ADAS requirements engineering is specification drift — the gap between what a requirement says in natural language and what the system must actually do in a physical scenario. A requirement like “the system shall maintain a safe following distance” is untestable as written. RSS replaces that with parameterized expressions involving reaction time bounds, maximum braking deceleration, and sensor latency. Those parameters become system requirements. They flow down to component specifications. They can be verified against simulation and physical test data.

The practical implication is that RSS gives Mobileye a stable formal substrate that sits beneath their entire product line. When a new OEM integration changes the sensor suite — a different camera field of view, a radar with different update rates — the engineers can propagate those changes through the RSS model and identify which downstream safety margins are affected. That is a requirements management capability, not just a safety philosophy.

RSS has also influenced ISO/PAS 21448 (SOTIF) and the ongoing IEEE P2846 standardization effort, which is codifying RSS-style formal models into an internationally recognized framework. Mobileye essentially used their scale as a forcing function to move industry standards in the direction their internal engineering required.

SOTIF and the Perception Envelope Problem

ISO 26262 addresses systematic and random hardware failures. SOTIF — Safety of the Intended Functionality — addresses something different: hazards that arise not from failures but from functional insufficiency. A camera-based pedestrian detector that works correctly but cannot detect pedestrians in heavy rain is not failing. It is operating at the boundary of its performance envelope, and in the wrong conditions that boundary kills people.

Mobileye’s approach to SOTIF in perception systems is worth examining in detail because it treats performance envelope characterization as a first-class requirements engineering activity rather than an afterthought addressed in validation.

The core engineering problem is that perception system performance is a function of an enormous operational design domain (ODD) parameter space: illumination conditions, weather, occlusion patterns, object type distribution, road geometry, sensor degradation modes, and more. You cannot test every combination. You cannot write requirements that enumerate every combination. What you can do is build a model of the performance function and specify requirements against that model’s structure rather than against individual test cases.

Mobileye does this through what they describe as a data-driven safety case methodology. The safety case for a perception function defines the ODD explicitly, characterizes detection probability as a function of ODD parameters, specifies minimum acceptable performance at ODD boundaries, and allocates portions of that performance budget to camera, radar, and mapping subsystems. Those allocations become interface requirements between subsystems. They are testable, they are traceable, and they can be updated when a new sensor configuration changes the allocation.

This is a significant departure from how traditional automotive tier-1 suppliers have handled perception requirements. The older pattern was to specify perception performance in terms of detection rates at fixed test conditions — essentially describing the system at one point in ODD space and hoping coverage generalized. SOTIF has forced the industry to confront the inadequacy of that approach, and Mobileye’s scale means they have had to solve it rigorously.

The challenge compounds when you add mapping. Mobileye’s Road Experience Management (REM) system crowdsources map data from production vehicles to create the Road Book — a high-resolution map layer that provides prior expectations to the perception system. That map layer is now a functional dependency. Its freshness, coverage, and accuracy are performance parameters that affect the perception system’s safety case. Managing those as requirements — with defined staleness bounds, coverage minimums, and degradation modes — requires connecting mapping infrastructure to the vehicle-level safety architecture in a way that most requirements tools were not designed to handle.

OEM Interface Requirements at Scale

Mobileye’s customer base includes almost every major global OEM. Each integration is different. BMW, Volkswagen, GM, Nissan, Geely, and dozens of others all have distinct mechanical packaging constraints, different sensor positioning, different camera specifications, different CAN and Ethernet topologies, and different functional requirements from their own product teams. Managing interface requirements across this landscape is an organizational and tooling problem as much as a technical one.

The approach Mobileye has evolved — inferred from their public technical documentation, patent filings, and engineering disclosures — follows a layered architecture that is worth understanding as a pattern.

At the base layer are core safety invariants: requirements that do not flex regardless of customer. Reaction time bounds, minimum braking authority assumptions, sensor fusion latency limits, and RSS parameter floors exist in this layer. An OEM does not negotiate these. They are derived from the formal safety model and treated as non-negotiable in the system architecture.

Above that sits a parameterization layer: requirements that are expressed as bounded variables rather than fixed values. Camera mounting angle, radar field of view, map freshness tolerance — these are parameters with defined ranges. An OEM’s specific configuration sets values within those ranges. The system architecture is designed to be correct for any valid parameter set. This is product line engineering applied to safety-critical embedded systems, and it is how Mobileye can support sensor diversity without rewriting the safety case for each customer.

Above that sits the OEM-specific layer: functional requirements that describe what the vehicle should do in the customer’s product context. Lane centering behavior, driver assistance intervention aggressiveness, human-machine interface integration — these are requirements that Mobileye implements to customer specification within constraints defined by the lower layers.

The discipline required to maintain this layering across hundreds of integrations and multiple product generations is significant. Requirements that were intended to live in the parameterization layer tend to migrate upward under project pressure. Platform engineers build assumptions about specific sensor configurations into the core. Safety margins that were supposed to be invariant get negotiated when a customer’s packaging makes the nominal camera position impossible. Managing those drifts requires tooling and process, not just intent.

Product Line Variability: From EyeQ to SuperVision to Drive

Mobileye’s current product architecture spans three distinct tiers. EyeQ SoCs power camera-based ADAS functions in high-volume vehicles — this is the foundation of their scale and the platform that accounts for most of the 800-million-vehicle install base. SuperVision is a hands-free highway driving system that adds surround cameras and Mobileye’s mapping layer. Drive is the full autonomous driving platform targeting robotaxi and unsupervised autonomy.

These three tiers do not share the same requirements architecture. They cannot. The ODD for basic ADAS is narrow, the sensor suite is constrained, and the safety argument rests on the driver remaining in the loop. The ODD for Drive is as broad as public roads, sensor redundancy is required, and the safety argument is entirely system-autonomous. The intermediate case — SuperVision — requires hands-free operation in defined highway corridors while maintaining a fallback to driver supervision.

Managing product line variability at this level requires explicit decisions about which requirements are shared across tiers, which are tier-specific, and how tier-specific variants are derived from shared parent requirements. The failure mode in product line engineering is requirement duplication: teams working on different tiers write independent requirements that diverge over time, creating integration problems when a shared software component is expected to satisfy both.

Mobileye’s approach, as evidenced by their engineering disclosures, treats the perception pipeline as a shared asset with tier-specific performance contracts. The pedestrian detection algorithm is not three separate algorithms — it is one algorithm with different performance requirements instantiated for each tier. That instantiation relationship must be represented in the requirements model explicitly. An ODD boundary that is acceptable for EyeQ is insufficient for Drive, and the requirements architecture must make that relationship traceable rather than implicit.

The Tooling Reality

Systems engineering at Mobileye’s scale and complexity puts pressure on requirements tooling that most legacy platforms were not designed to handle. A requirements model that connects formal safety parameters, OEM-specific interface specifications, ODD characterizations, sensor performance budgets, and product line variant relationships is not a document. It is a graph with heterogeneous node types and semantically meaningful edge types. Querying it, analyzing it, and maintaining consistency across it requires tools that treat requirements as connected data.

The industry’s historical reliance on document-based requirements management — spreadsheet RTMs, Word-format specifications, IBM DOORS databases that model documents rather than systems — creates compounding maintenance debt as system complexity grows. The engineers at a company like Mobileye know exactly where their requirements model is insufficiently connected: they feel it every time an OEM configuration change requires manually propagating impacts through documents rather than traversing a dependency graph.

The movement toward model-based systems engineering, and toward AI-native tools that can reason over requirements graphs rather than just store them, reflects this pressure. Tools like Flow Engineering are designed from the ground up around graph-based requirements models and AI-assisted traceability — which is the architecture that complex, multi-tier, multi-customer programs like Mobileye’s actually require, even if they have historically made do with older tooling augmented by manual process.

Honest Assessment

Mobileye has built one of the most sophisticated systems engineering operations in the automotive industry. Their formalization of safety reasoning through RSS, their treatment of perception performance envelopes as requirements artifacts, and their layered approach to OEM interface management are all genuine contributions to how safety-critical AI systems can be engineered rigorously.

The pressures they face are real: product line complexity is growing faster than the tools and processes designed to manage it. The transition from driver-assisted to driver-optional to driverless changes the requirements architecture more fundamentally than adding sensors does. Managing that transition while sustaining hundreds of active OEM programs is not a problem that admits clean solutions.

What Mobileye demonstrates is that systems engineering is not overhead in an AI-intensive hardware program. It is the substrate on which the AI capability rests. Without rigorous management of requirements from formal safety model to OEM interface to component specification, the perception algorithms — however capable — cannot be deployed safely at scale. That lesson is transferable to any organization building safety-critical AI systems, whether they ship 800 million units or eight.