Ouster’s Engineering Gauntlet: Building Automotive-Grade Lidar from Scratch

The lidar industry spent most of the 2010s solving a physics problem: how to get enough photons back from a target at 200 meters, fast enough to matter, reliably enough to trust. By the mid-2020s, the physics problem is largely solved. The problem that remains is considerably less glamorous and considerably harder to shortcut: automotive qualification.

Ouster — the company formed by the 2023 merger of Velodyne Lidar and Ouster Inc. — is one of the clearest case studies in what happens when a sensor technology transitions from prototype darling to automotive supply chain reality. That transition demands something the lidar industry never had to build during its formative years: rigorous systems engineering maturity, documented to standards written for technologies that existed decades before lidar entered a car.

The Automotive Supply Chain Didn’t Wait for Lidar

ISO 26262, the functional safety standard for road vehicles, was first published in 2011. It was built around well-understood automotive components — brakes, steering systems, powertrain controllers — with established failure mode libraries and decades of field data. Lidar showed up to that framework as an uninvited guest with no historical FMEA data, no agreed-upon diagnostic coverage metrics, and no tier-1 supplier willing to vouch for it.

What that means practically is that automotive lidar manufacturers have to construct their safety cases almost entirely from first principles. An automotive brake supplier arguing for ASIL D compliance can reference decades of field data and supplier precedent. An Ouster engineer arguing for ASIL B compliance on a digital-MEMS lidar is writing much of the supporting argument from scratch.

This isn’t a regulatory criticism — it reflects the genuine challenge of integrating a novel sensing modality into a framework designed for well-understood electromechanical systems. But it does mean the qualification work is disproportionately heavy. Every sensor variant, every new wavelength architecture, every change to the ASIC that drives the laser array potentially reopens the safety case. At a company managing multiple simultaneous product lines — as Ouster does across its REV7 and automotive-targeted platforms — the requirements management burden compounds quickly.

What the Merger Actually Created

The Velodyne/Ouster merger made strategic sense on paper. Velodyne brought brand recognition, an established customer base across industrial and automotive pilot programs, and rotating-polygon mechanical lidar designs with genuine field hours. Ouster brought a differentiated digital-MEMS architecture and a more modern software stack. Combined, the company gained scale and eliminated a direct competitor.

What the merger also created was a systems engineering challenge that doesn’t show up in merger press releases: two distinct product families, built on different physical architectures, with different safety documentation histories, now being managed under a single engineering organization accountable to automotive OEM customers who want coherent qualification packages.

Mechanical spinning lidars and solid-state MEMS lidars fail differently. They have different diagnostic coverage requirements, different thermal behavior, different susceptibility to EMI. Writing a common HARA (Hazard Analysis and Risk Assessment) that covers both architectures without papering over the real differences between them is legitimate engineering work. Maintaining traceability from top-level safety goals down to component verification across two physically distinct product families simultaneously — while also responding to OEM requests and competitive pricing pressure — is the kind of work that either gets done carefully or becomes technical debt that surfaces during supplier audit.

Post-merger integration of engineering processes is always harder than integration of headcount or product portfolios. In a regulated industry like automotive, it’s harder still, because the documentation artifacts from each legacy organization carry legal and contractual weight. You cannot simply deprecate a Velodyne FMEA and replace it with an Ouster one without potentially invalidating existing customer qualification work.

The Solid-State Pressure

Solid-state lidar — primarily based on FMCW (frequency-modulated continuous wave) or OPA (optical phased array) architectures — has been “three years away” from automotive-grade deployment for roughly a decade. That running joke has less punch now. Companies including Aeva, Innoviz, and Luminar have demonstrated automotive-grade solid-state or near-solid-state sensors with OEM design wins, and the cost trajectories are no longer speculative.

For Ouster, the competitive pressure from solid-state isn’t primarily about point cloud resolution or range. It’s about cost and reliability narrative. Solid-state sensors have fewer moving parts. Fewer moving parts means simpler FMEA arguments, lower infant mortality in early production runs, and an easier story to tell an OEM procurement team. A MEMS-based design, even a well-engineered one, requires more detailed argumentation around the long-term reliability of micro-mechanical components at automotive temperature and vibration cycles. That argumentation isn’t impossible — MEMS components are used throughout automotive systems — but it’s work, and it takes time that a competitor with an inherently simpler reliability story doesn’t have to spend.

The competitive response to solid-state disruption isn’t just product engineering. It’s process engineering: how fast can Ouster generate qualification documentation for new platform variants, and how maintainable is that documentation as the design evolves? An OEM design win in the automotive space typically involves a supplier audit of engineering processes — not just product performance. A lidar company that can demonstrate mature, traceable requirements management practices is not just better organized internally; it’s a more defensible supplier choice for an OEM that is itself accountable to functional safety regulators.

Where ADAS Sensor Companies Get Stuck

The systemic challenge facing Ouster and comparable ADAS sensor companies isn’t unique to lidar physics or merger complexity. It’s a maturity gap that appears consistently across companies that grew up in the research and early-adoption phase of autonomy and are now trying to operate as automotive suppliers.

The gap looks like this: the hardware engineering is genuinely excellent. The optical design teams, the ASIC teams, the signal processing teams are doing sophisticated work. But the systems engineering layer — the processes for capturing requirements, maintaining traceability from safety goals to hardware verification, managing requirement changes across product variants — often trails behind. Not because the engineers are careless, but because those disciplines weren’t load-bearing when the customer was a university robotics lab or a Level 4 autonomy startup running prototype fleets. They become load-bearing when the customer is a Tier 1 automotive supplier with an APQP process and an expectation of IATF 16949 alignment.

This is the moment when a lot of companies reach for a requirements management tool that they probably should have adopted two years earlier, and discover that the tooling choice matters enormously. Document-based approaches — spreadsheet RTMs, Word-document specifications, even some older formal tools — struggle to maintain coherence across the multiple product lines and multiple safety standards (ISO 26262, IEC 61508, SOTIF) that an automotive lidar supplier now has to navigate simultaneously. The connections between artifacts break silently. A requirement changes, and the downstream verification evidence that should have been updated wasn’t. The problem doesn’t surface until an audit.

Building Systems Engineering Maturity in Practice

What does it actually look like when an automotive sensor company closes this gap?

The first step is usually unglamorous: requirement inventory. Before any tool can help, the engineering organization needs an honest accounting of where requirements currently live — in which documents, at what level of specification, with what traceability to design and test artifacts. For a post-merger company like Ouster, this inventory likely spans multiple legacy systems, formats, and organizational conventions. That audit is painful but not optional.

The second step is establishing a coherent requirements architecture: what are the top-level system safety goals, how do they decompose to hardware safety requirements, and how do those map to component-level specifications and verification methods? For automotive lidar, this architecture needs to accommodate the ISO 26262 part 8 requirements for hardware development as well as the SOTIF (ISO 21448) requirements that specifically address sensor performance limitations — an area where lidar’s susceptibility to edge-case environmental conditions (retroreflectors, adverse weather, direct sunlight) creates genuine SOTIF arguments that aren’t captured in a pure ISO 26262 framework.

The third step is tooling that can sustain that architecture as the product evolves. Modern requirements management platforms oriented toward systems engineering — tools that model requirements as nodes in a connected graph rather than rows in a document, that surface broken traceability links automatically, that can represent multiple product variants without forking the entire requirements tree — are meaningfully better suited to this problem than document-centric approaches. Platforms like Flow Engineering, built around graph-based requirements models with explicit support for the kind of multi-system traceability that automotive sensor development demands, represent a more appropriate architectural fit for this problem than a legacy document tool extended with compliance modules. The difference isn’t cosmetic: when a laser driver ASIC revision touches fourteen downstream requirements across three product variants, a model that can traverse those relationships automatically is not a luxury.

The Honest Assessment

Ouster is doing hard, legitimate work. Building automotive-grade lidar with a defensible functional safety case, across multiple platform architectures, in a competitive environment where solid-state alternatives are closing fast, while integrating two legacy engineering organizations — that’s a serious engineering challenge that deserves serious acknowledgment.

The company’s long-term competitive position in automotive won’t be determined solely by photon physics or ASIC performance. It will be determined in part by how systematically they build the systems engineering processes that automotive customers require and that regulatory frameworks increasingly enforce. The lidar industry spent a decade solving the sensing problem. The next phase is building the engineering discipline to move that sensing from prototype to production at automotive scale.

That transition is underway. Whether it’s moving fast enough — given the cost pressure from solid-state alternatives and the qualification timelines automotive OEMs operate on — is the question that Ouster’s engineering leadership is answering in real time, one requirements review at a time.