Innoviz connects automotive lidar with perception and infrastructure sensing

Explore InnovizTwo, InnovizSMART and perception software, with practical guidance on product variants, software scope and commercial evaluation. This is a public-source assessment with a proposed evaluation, not a hands-on test.

01 / ProductInnoviz offers more than one route from lidar to useful perception

Innoviz develops lidar sensors and perception technology for automotive and other physical applications. Its current site describes vehicle programs involving BMW and Volkswagen, giving it a clear role in the automotive sensing market. Those company statements support editorial relevance; they are not an independent assessment of vehicle safety or proof that every advertised capability is deployed in every program.

InnovizTwo is an automotive lidar product whose public page describes configurable regions of interest, multiple returns and an embedded InnovizAPP perception platform. These features address different parts of the pipeline: acquiring spatial observations, allocating sensing detail and interpreting what the sensor observes. A project needs to identify which of those functions it expects the supplier to deliver.

InnovizSMART targets applications including traffic intelligence, robotics and site monitoring. Its current page lists Gigabit Ethernet and power through PoE or 12V. The Ultra Long-Range variant addresses wider-area sensing. These are distinct product choices, not interchangeable names for a universal lidar with every specification combined.

02 / AudienceThe right reader owns a sensor or integration decision

Innoviz is relevant to a vehicle engineering team selecting a sensing component and to a systems integrator building an infrastructure application. Both need to understand the physical view and the software output, but their integration constraints differ. Automotive packaging, vehicle data interfaces and program qualification are not the same work as mounting sensors around a fixed site.

A buyer seeking a complete self-driving product should define the remaining system responsibilities before treating a lidar purchase as the solution. Perception is one stage in a longer chain that includes prediction, planning, control and operational fallback. A sensor's ability to detect a target does not establish the complete system's ability to respond appropriately.

The Mobileye blueprint is a useful comparison at the broader driving-system layer. The NVIDIA blueprint explains compute and development infrastructure that may surround a custom perception project. Innoviz is most useful to evaluate when the missing decision concerns the sensing and interpretation layer, rather than a general desire to add AI to a vehicle or facility.

03 / WorkflowA proposed infrastructure pilot should test coverage before classification

Consider an integrator evaluating the movement of vehicles through a large logistics entrance. The proposed pilot begins with a coverage plan and recorded observations, not an immediate automated intervention. Define the boundaries that matter: entry, waiting area, exit and any adjacent pedestrian route. Identify which events an operator needs to know about and how quickly the information must arrive.

Select a product against that geometry. InnovizSMART's current page specifies a 3-to-450-meter detection range and a 120-by-24-degree field of view. Those numbers describe the product page's envelope, not guaranteed detection of every target across the entire area. Ask for the relevant target and environmental conditions, and test the closest required observation as carefully as the farthest.

Place the sensor in the intended mounting position and inspect occlusions from parked vehicles, structures and queues. A long-range sensor can still miss an object behind a nearby obstruction. Consider whether the site needs another viewpoint rather than a larger headline range. Keep the proposed system simple enough that a missed observation can be traced to its cause.

Next, establish the software output and its provenance. Determine whether the trial receives raw point-cloud data, an object list, a packaged detector or a partner's application. Use an agreed sample record to document coordinates, timestamps, object identities and confidence information where available. Do not assume that a feature described on one automotive product page appears in an infrastructure package.

Run a reference set containing vehicles that stop, reverse, overlap and enter close together. Review whether one physical vehicle retains a consistent identity across the relevant area. An event counter may appear correct while the system loses and recreates tracks, which can corrupt dwell-time analysis or create repeated alerts. Inspect the sequence, not just the final count.

The InnovizTwo page's configurable region of interest is particularly relevant to vehicle projects. In a separate proposed automotive evaluation, compare the observation detail inside and outside the selected region and record how the configuration changes. A focused region may help a defined task, but the rest of the scene still needs a deliberate sensing strategy.

Only after the observations and interpreted events are understood should the pilot connect to an operational workflow. Keep initial outputs advisory and record how staff handle an uncertain or missing event. The result should be a documented acceptance decision for that installation, not a general assertion that a named lidar has solved the site's autonomy problem.

04 / PricingCommercial scope must identify the sensor and the software separately

The current product pages and contact route direct prospective buyers to a sales discussion. They do not establish a universal public currency price for a sensor program, a perception license or an installed infrastructure application. Quote requests should identify the exact product, intended volume and application rather than ask for an undifferentiated Innoviz price.

The software boundary is especially important. The perception software page describes much of the company's work in historical language. The current InnovizTwo page, however, lists embedded InnovizAPP and explicitly offers the sensor alone or paired with advanced perception software. That is a documented paired route, although it does not establish a universal standalone subscription or its contract terms. Its marketing description of a complete autonomous-vehicle solution does not independently establish the capabilities or safety of an integrated vehicle.

Ask the supplier to state which perception outputs, tools and support are included in the proposed unit or contract. If an integrator supplies additional interpretation, list that separately. A low sensor quote can be a poor comparison with a supported application package, and the presence of a public product page does not settle current delivery dates or production commitments.

05 / DistinctionsConfigurable sensing creates useful engineering choices

InnovizTwo's documentation describes allocating detail through a region of interest and supporting multiple reflections. These are meaningful reasons for an engineering team to investigate the sensor. Their value depends on the scene and downstream use: more useful observations in one part of a view may improve a specific task, but the complete sensing configuration needs to remain visible during evaluation.

The company spans vehicle-oriented and infrastructure-oriented hardware. In our assessment, that gives readers a useful set of choices without requiring them to assume that the same enclosure or interface belongs everywhere. A fixed site may value installation and networking options that are less central to a deeply integrated vehicle program.

The Ultra Long-Range page specifies detection up to one kilometer while also listing a minimum range of 15 meters. This is a reminder that distant observation and close coverage are different requirements. A buyer choosing that variant should map the near region explicitly and avoid treating the largest distance as evidence of universal coverage.

06 / QuestionsCurrent software availability is the first unresolved question

The historical suite description and current InnovizTwo pairing offer should be reconciled at the package level before implementation. Determine which software is supported for the new project, which hardware it accompanies and whether the buyer receives an application interface or particular outputs. The published pairing offer is useful evidence of a route to discuss; it does not settle license transfer, update rights or ongoing support for a specific contract.

Product families also require disciplined specification handling. The standard InnovizTwo, InnovizSMART and Ultra Long-Range pages show different ranges, viewing angles and frame-rate statements. Keep a single agreed configuration attached to the evaluation. Combining the best number from each page would create a misleading description of a product that was never offered.

For a vehicle program, obtain the actual qualification and integration documentation for the chosen unit. Public references to functional-safety standards should not be read as approval of the whole vehicle or of a particular driving function. The acceptance evidence must cover the installed system and its intended conditions, including what happens when observations are unavailable.

For a fixed-site system, ask how blockage, altered mounting and network interruptions become visible to operators. An apparently quiet dashboard can mean no activity or missing observations. Those states should be distinguishable in the proposed workflow. The source review establishes product descriptions, not the behavior of a deployed system under those failures.

07 / DecisionChoose a supported configuration before designing around the brand

Innoviz is a credible company to investigate for automotive lidar and infrastructure perception projects. Its relevance comes from defined sensing products and documented automotive involvement, rather than an invented ranking. Select the product against the physical task, obtain explicit software scope and test the complete observation-to-event path before expanding the project.