Ouster and the Systems Engineering Reality of Production LiDAR

The merger of Velodyne and Ouster in early 2023 created the largest independent LiDAR company by unit volume, combining two product philosophies that had competed head-to-head for years. Velodyne built its reputation on spinning, multi-channel sensors that defined the research and early autonomous vehicle ecosystem. Ouster had pursued a digital LiDAR architecture — a receiver chip design that promised a clearer path to automotive-grade manufacturing yields. Together, the merged company inherited multiple active product lines, a diverse customer base spanning automotive OEMs, robotics integrators, and infrastructure operators, and an engineering challenge that goes well beyond optics or semiconductor design: how do you manage product development at this scale with the rigor that automotive customers now demand?

That question is fundamentally a systems engineering question, and the answer the LiDAR industry is converging on is not flattering to how the sector has historically operated.

The Portfolio Problem

Ouster’s current product portfolio spans two fundamentally different sensor architectures. The REV7 spinning sensors (heritage Ouster digital LiDAR) use a rotating head with a CMOS-based receiver array. The DF series targets solid-state and semi-solid configurations. Across both lines, Ouster serves customers whose requirements are structurally incompatible.

An automotive OEM integrating LiDAR into a Level 3 highway pilot system needs ISO 26262 functional safety compliance, IATF 16949 manufacturing quality, ASPICE-aligned development processes, and environmental qualification to AEC-Q standards. A robotics integrator deploying warehouse autonomous mobile robots needs none of that — they need a reliable point cloud, a competitive price, an SDK that works, and a vendor that will ship in volume. An infrastructure customer monitoring a highway corridor for traffic analytics needs long service life, remote management, and vibration tolerance for pole mounting.

These are not variations on a theme. They represent different qualification regimes, different documentation requirements, different customer audit expectations, and — critically — different requirements engineering disciplines.

Managing this in a single engineering organization means the same hardware platform must simultaneously be specified against automotive-grade hazard analysis requirements and against a robotics customer’s ROS2 integration checklist. The requirements architectures for those two deliverables look nothing alike, and the tooling that most LiDAR teams have historically used — which is to say, a combination of spreadsheets, Confluence wikis, and whatever engineers could agree to maintain — does not scale to that combination.

What Automotive Qualification Actually Demands

The LiDAR industry spent years competing on sensor performance: range, angular resolution, field of view, point density, latency. Those remain real differentiators. But the automotive supply chain measures suppliers on a different set of dimensions, and the gap between where most LiDAR companies started and where Tier 1 qualification requires them to be is significant.

ISO 26262 compliance for a LiDAR sensor used as a safety-relevant input to an autonomous driving system requires that the sensor’s functional safety requirements be derived from a system-level hazard analysis and risk assessment (HARA). That HARA lives at the vehicle or platform level, which means the OEM or Tier 1 system integrator is generating safety goals that flow down to the sensor as safety requirements. The LiDAR supplier is then responsible for demonstrating that their hardware and software architecture satisfies those requirements — and for maintaining traceability from the safety goal through the technical safety requirements, to the hardware design, to the verification tests, to the production process controls.

This is not a documentation exercise that can be performed retrospectively. It requires that requirements be managed as a living artifact throughout the development process, that design decisions reference the requirements they satisfy, and that any requirement change triggers a formal impact analysis. An automotive OEM quality audit will pull that thread. If the traceability breaks — if a functional safety requirement exists in a requirements management tool but the design decision that supposedly satisfies it lives in an engineer’s email thread — the audit fails.

For Ouster, achieving this on the automotive product lines while simultaneously running separate, less formal development processes for robotics and infrastructure products creates organizational and tooling complexity that most LiDAR startups were not built to handle. The Velodyne/Ouster merger exacerbated this: two engineering organizations with different development cultures, different internal tools, and different customer-facing quality processes now need to operate as a coherent product development function.

The Shared-Platform Constraint

The economics of LiDAR at scale push hard toward shared hardware platforms. You cannot economically maintain separate ASIC designs, separate optics supply chains, and separate manufacturing lines for every market segment. The business logic is to build a core hardware platform — receiver ASIC, laser array, mechanical design, embedded firmware — and differentiate at the configuration and software layer for different markets.

This is sound engineering economics. It is also a systems engineering problem that requires explicit management.

When automotive requirements drive a design change to the shared ASIC — say, a latch-up immunity improvement required by AEC-Q100 qualification — that change propagates to every product built on that silicon. The robotics and infrastructure products are now carrying that change too. If the change affects timing behavior, power consumption, or thermal characteristics, the robotics product team needs to evaluate the impact on their own requirements even if automotive qualification was never their concern.

Managing this demands a requirements architecture that explicitly separates what is shared across product lines from what is segment-specific, and that maintains bidirectional traceability between shared platform requirements and segment-specific derived requirements. Without that architecture, change management becomes a forensic exercise. Engineers have to manually figure out what requirements live where and what downstream effects a change carries. At the scale of a merged organization with multiple active product lines, that process is slow, error-prone, and invisible to program management until something breaks.

The tooling question here is not trivial. Traditional requirements management platforms were designed around single-program, document-centric models. A requirements document for the automotive product. A separate document for the robotics product. Change control happens through document revision control. This approach cannot efficiently model the shared-platform/derived-requirements structure that multi-market LiDAR development requires. What the structure actually calls for is a graph model: nodes for requirements, edges for derivation and allocation relationships, with the shared platform requirements as a substrate from which market-specific requirements branch. Changes to shared nodes propagate visibly through the graph. Market-specific branches can be qualified independently without duplicating the shared foundation.

The Maturation Signal

The broader LiDAR industry’s shift from research-grade to production-grade is legible in the audit trails. In 2019, an automotive OEM evaluating a LiDAR supplier for a development program would run a technology assessment: point cloud quality, range, weather performance, form factor. By 2024, those same OEMs were running supplier quality audits that looked indistinguishable from audits of established Tier 1 electronics suppliers. PPAP documentation. Control plans. DFMEA. Process capability data. Functional safety argument packages.

Most LiDAR startups were not built for that. The founding teams came from research labs and consumer electronics, not from automotive Tier 1 organizations. The organizational instinct was to build the sensor, write the datasheet, and let the customer figure out integration. That model worked when automotive customers were running development programs with low-volume research sensors. It stopped working when programs moved to pre-production validation and the procurement organization got involved.

Ouster’s position in this transition is complicated by its merger legacy. Velodyne had been in the automotive supply chain conversation longer and had built more of the associated process infrastructure. Ouster’s digital LiDAR architecture had strong arguments for manufacturability and yield that Velodyne’s legacy spinning designs could not match. The merged company needs both: the process maturity and the manufacturing architecture. Building that combination out at scale, across a portfolio serving three structurally different markets, is the central systems engineering challenge the organization is working through.

Requirements Management as a Competitive Moat

There is an argument — not widely made in the LiDAR trade press, which tends to focus on sensor benchmarks — that requirements management discipline is itself a competitive differentiator in the automotive LiDAR supply chain.

When an OEM’s systems engineering team is conducting a source selection for a production LiDAR supplier, one of the evaluation dimensions is development process confidence. Can this supplier demonstrate that their requirements are managed, that their design is traceable to those requirements, and that their change management process will not introduce uncontrolled risk into the OEM’s vehicle program? A supplier that can answer yes to those questions with evidence — actual tooling, actual traceability reports, actual change impact analyses — is a different risk profile than a supplier whose answer is “we can produce that documentation.”

Tools like Flow Engineering, which implement graph-based requirements modeling with AI-assisted traceability, are increasingly appearing in the evaluation stack of engineering teams trying to close this gap. The ability to model a multi-product-line requirements architecture in a connected graph rather than a collection of documents, and to use AI assistance to surface traceability gaps or flag requirements that have no associated verification — these capabilities are directly relevant to the LiDAR industry’s current qualification challenge. Teams that are simultaneously managing automotive safety requirements, shared platform constraints, and market-specific derived requirements need tooling that reflects the actual structure of the problem.

The document-centric tools that dominated requirements management in traditional automotive suppliers are not well-suited to the shared-platform, multi-market model that Ouster’s portfolio represents. The question is not whether modern tooling matters — it clearly does — but whether organizations can absorb the process change required to use it effectively while simultaneously delivering against active program milestones.

Honest Assessment

Ouster is a real company doing real engineering in a market that has been oversold and under-delivered for a decade. The merged entity has genuine technical assets: a defensible digital LiDAR architecture, meaningful unit volume, and a customer base that spans the application landscape in ways that give the organization real signal about where the market is actually going.

The systems engineering challenge they face is not unique to Ouster — it is the challenge facing every LiDAR supplier trying to cross from the research/robotics market into the automotive supply chain while simultaneously not abandoning the revenue base that funded the company to this point. Managing requirements across architecturally divergent product lines, maintaining automotive-grade traceability without imposing automotive-grade process overhead on robotics and infrastructure programs, and building the organizational muscle to survive a Tier 1 quality audit — none of this is solved by sensor performance improvements.

The suppliers who figure out the systems engineering discipline first will be harder to displace when automotive programs move to high-volume production contracts. The ones who treat it as a documentation problem to be solved at audit time will remain in permanent qualification limbo. Ouster has the portfolio and the market position to be in the first group. Whether their internal systems engineering practice matches that ambition is the more important question, and it is one that sensor benchmarks will not answer.