DVN: Hi, Axel. Tell us about yourself and how you found your way to Ottometric, will you?
Axel Gern.: I’m a member of Ottometric’s Board of Directors, and Strategic Advisor for AD & SDV. I’ve spent more than 20 years in ADAS, autonomous driving and automotive software, including leadership roles at Mercedes-Benz, Daimler Truck, Torc Robotics and Aeva Technologies.
What attracted me to Ottometric was the opportunity to help established manufacturers make greater use of data in development. At Mercedes-Benz and Torc Robotics, we had to build much of the supporting capability ourselves. Manufacturers have more options today, and I don’t think they should build everything internally.
DVN: Why was your company founded?
A.G.: Ottometric was founded in 2019 as it became clear that engineering teams were struggling to keep up with the volume of data their ADAS programs generated. Much of the work to organize, annotate, and review sensors and vehicle data was still manual. Engineers spent too much time getting the data ready before they could understand what it was telling them. Ottometric was created to automate more of that preparation so teams developing and validating these systems could investigate results sooner and keep pace as their programs grew.
DVN: What problem in ADAS and automated-driving development are you trying to solve?
A.G.: We help engineering teams get useful answers from their fleet, and test data soon enough to act on them. A team may have collected thousands of hours and still discover that an important situation is missing, a recording is unusable, or a result needs further investigation. Finding that out late can mean another collection campaign or less time to improve the system.
ADAS development has used data for years, including training neural networks for perception. As these models take a larger role in system behavior, the choice and balance of training data become more important. Teams need everyday driving as well as difficult and unusual situations. Collecting more examples of the same conditions will not fill the gaps.
Teams need usable recordings and reliable results to investigate behavior and validate changes. For model development, they also need appropriate training data and separate test data for evaluation. The data flywheel connects collection, development and validation: findings from testing and real-world operation inform which data to collect, how to improve the model or what to test next. Ottometric helps teams find, organize, and qualify the data needed for that work.
DVN: What is Ottometric’s place in the ADAS/AV ecosystem?
A.G.: Ottometric connects fleet and test data with the engineering work that follows. Customers can be overwhelmed by the volume of data they have paid to collect. We work within their existing toolchain, helping teams organize that data, check whether recordings are usable, find relevant situations, and assess how a function performed. That lets engineers focus on solving engineering problems, test a wider range of conditions and investigate individual events in greater detail. For an established manufacturer, our role can begin with improving validation and expand into support for model development. Customers can build on the tools and expertise they already have.
For AI and software-defined vehicle programs, our ambition for Active DataOS is to support the data needs of OEMs and tier-1s using hybrid AI architectures and end-to-end models. We organize that broader role around the Active 4Cs – collection, curation, compliance, and continuous learning. Our aim is to connect relevant data and engineering results across the customer’s data flywheel, so findings from one development cycle inform the next.
DVN: Are you primarily a validation company, then? A data platform, an AI company…?
A.G.: All three descriptions apply, and the boundaries are increasingly disappearing. Ottometric brings data management, AI-based analysis and validation workflows together in an engineering platform for ADAS and automated-driving development. AI plays a significant role in the analysis within that platform.
We use AI in computer-vision, fusion and analytics modules to enrich recordings with metadata, generate reference data and extract useful information. For example, the scenario module takes video, radar, lidar, GPS, and vehicle data and generates tags identifying scenarios relevant to Euro NCAP assessments. Those tags help engineers find recordings for the evaluation they need to perform.
In a feature-validation workflow the platform checks recording quality, combines sensor information to generate reference data and compares the ADAS function’s outputs against that reference to calculate KPIs. Low-confidence scenes are flagged for human review. Engineers can inspect a deviation alongside the recordings and check whether the problem lies in the function or the reference data.
The platform also supports selecting data for model development. Training and test datasets must remain strictly separate, so models are evaluated on data that were not used to train them.
DVN: How do Nvidia’s open Alpamayo ecosystem and companies like Foretellix, Applied Intuition, and Cognata fit relative to Ottometric?
A.G.: I view them as essential complementary infrastructure. Nvidia’s open Alpamayo ecosystem is pushing AI development forward. Training these models requires balanced datasets containing everyday driving conditions as well as rare, safety-critical situations. One example of an important situation is not enough; data augmentation and simulation can provide additional variations. Active Curation helps engineers select the relevant real-world data for that work.
Similarly, companies such as Foretellix, Applied Intuition, and Cognata provide simulation and validation capabilities. While there is naturally some capability overlap in data management, our core focus is the real-world data that supports those workflows. We interface with their tools as part of the customer’s development environment.
We act as the Active DataOS that organizes and analyzes large volumes of unstructured fleet and test data, identifying relevant events and assembling useful datasets. Those real-world events can feed simulation and validation workflows. Our contribution is to help customers make effective use of their AI compute and simulation tools through better-selected data. That supports development and validation across automation levels, from current ADAS functions to Level 4 systems.
DVN: What do you mean by ‘evidence-first validation’? How is it different from the KPI dashboards and validation reports OEMs and tier-1s have been using for years?
A.G.: For us, evidence-first validation means keeping every KPI tied to the data and context behind it. Dashboards and reports are useful for trends, thresholds and pass/fail status; the difference is how far the engineer can move from that result into the underlying evidence. With Ottometric, an engineer can go to the relevant drive segments, synchronized sensor and vehicle data, ground truth, operating conditions and software version. If an AEB false-positive rate rises, the team can inspect the events and see whether they share a sensor issue, a ground-truth problem, a particular condition or a change in feature behavior.
That gives engineers more detailed and transparent insight into the KPI and helps them decide what to reproduce, investigate or test next. It applies to rule-based ADAS as well as functions that use machine-learning models. In those cases, traceability alone does not explain why a model produced a particular output, but it gives engineers the evidence needed to evaluate behavior and compare versions.
DVN: ADAS programs generate enormous amounts of camera, radar, lidar, vehicle-bus and system data. Where’s the bottleneck? Collecting the data, finding the relevant scenarios, generating ground truth, computing KPIs, or making the final release decision?
A.G.: All of those stages can become bottlenecks. Collecting data is expensive and time-consuming, and processing everything collected is already a substantial challenge. Teams need to check that recordings are complete, signals are synchronized and the data are usable. They also need to find relevant scenarios, generate ground truth and calculate KPIs before they can use the results to support a release decision. Discovering missing coverage or unusable recordings late can mean repeating collection after storage, annotation, compute and engineering time have already been spent.
The role of the Ottometric platform is to support the teams throughout that work. It helps them manage the volume of data, identify quality and coverage gaps, and organize the processing needed for development and validation. Machine learning automates much of the preparation and analysis, including characterizing recordings and generating reference data, so engineers can concentrate on investigating results and improving the system. The final release decision remains with the customer.
DVN: Ottometric says intelligent data selection can pare down 99 per cent of a huge training dataset to a small, high-value subset. How do you pick the valuable data, and how do you ensure rare but safety-critical edge cases aren’t filtered out?
A.G.: The useful reduction depends on how repetitive the original collection is and what the selected data needs to support. Around 1 per cent should not be treated as a general target.
Ottometric uses scenario prioritization & ranking, or SPR, to assess how much additional diversity each sample contributes. Take a vehicle driving the same highway repeatedly under similar conditions. Many recordings may add little new information, but ordinary highway driving still needs adequate representation. The aim is to retain representative examples of those conditions while preserving meaningful variations and rare situations.
The method is designed to preserve the original dataset’s ratios across object classes while surfacing rare cases. Engineers can also choose how much data from different groups to retain for their particular task. That combines automated selection with engineering control.
Preserving the original distribution does not establish that the collection contains everything the program needs. Engineers still need to check the selected subset against coverage requirements and retain safety-critical cases those requirements demand. A useful training dataset needs everyday driving as well as difficult situations; the reduction percentage follows from that selection.
DVN: Increasingly, AI is being used to generate annotations, ground truth, and validation results. How do you validate the validator? How can an OEM trust AI-generated evidence for a safety-critical ADAS function?
A.G.: An automatically generated label or reference is still a measurement that can be wrong. To trust it, an engineering team needs to compare it with an independently checked reference across the conditions relevant to the function. It also needs to understand the errors that remain.
In Ottometric’s feature-validation workflow, low-confidence scenes are flagged for human review. Engineers can correct the reference data, and deviations between the ADAS output and that reference receive a further check to establish which one is wrong. The recordings and KPI results are available together so reviewers can investigate the event.
That concentrates human effort, but automation can also be confidently wrong. Accepted results therefore need checks as well as flagged cases. Whether review scales depend on how many cases need attention, how long they take and what errors those checks uncover. The OEM or tier-1 uses that evidence in its safety assessment and retains responsibility for release.
DVN: Where are the hardest validation problems? Is the main challenge still validating camera, radar, or lidar performance, or is it in sensor fusion, system behavior, and identifying the cause of failures across the complete stack?
A.G.: Individual sensor validation remains essential, but some of the hardest problems appear when the components work together. If an AEB function brakes unexpectedly, the cause could involve a sensor measurement, calibration, timing, object association, fusion, or the feature logic. Engineers need to reconstruct the event across those stages to narrow down the cause.
Smart sensors and distributed processing make that harder. Some processing may happen inside the sensor, and the information available for investigation depends on what each component exposes and what the vehicle records. Responsibility may also come from different engineering teams or suppliers. The team investigating the problem needs enough context to pass a useful finding to whoever is responsible.
Ottometric brings recorded sensor data, vehicle signals, reference data and feature results together around the event. That helps engineers compare what the sensors recorded with how the function responded. Where machine-learning models are involved, this context supports investigation, but it does not explain by itself why the model produced a particular output. How far engineers can trace a failure still depends on the data available from the system.
DVN: What’s the right balance between real-world driving, proving ground testing, SIL/HIL and simulation? What evidence can realistically be generated virtually, and where is real-world data indispensable?
A.G.: The balance depends on what the team needs to establish. Simulation and SIL let engineers repeat scenarios, vary parameters and test software changes across many conditions. HIL adds the hardware, timing and interfaces. Proving-ground tests provide controlled physical measurements in a repeatable way, while road testing exposes the vehicle to conditions and combinations the team may not have anticipated.
Scenario-based testing connects these methods. An event recorded on the road can become the starting point for variations in simulation, helping engineers investigate which conditions affect the result and what to reproduce physically. The fidelity of that simulation is crucial. Real-world measurements help engineers build and check the models, and simulated results need to be checked against physical tests. Agreement in one situation does not establish that the model is reliable across every condition.
Virtual testing can provide evidence of software behavior, regressions and responses to defined variations within those modeling limits. Real-world data remain indispensable for checking how the actual sensors and vehicle behave and identifying gaps in the assumptions.
Ottometric supports that process through what we call SimBridge, which brings real-world data into simulation for fault injection and closed-loop testing, and through comparisons of KPI results across recorded, SIL and HIL data versions. Those comparisons help engineers decide what needs further investigation, physical testing or additional collection.
DVN: Can you share an example of a tier-1 or OEM program wherein Ottometric measurably reduced validation time or cost?
A.G.: One example is a front-camera validation program for a North American tier-1 supplier, covering detection of lanes, traffic signs, and traffic lights on an electric-vehicle platform. The customer had been using a semi-automated annotation service with around 200 people reviewing data.
Ottometric worked within the existing data-collection, cloud and HIL environment, automating much of the data preparation, annotation, quality control and KPI calculation. The time needed to produce the KPI results used to assess the camera functions fell from about six months to about one month, and the cost of the defined validation workflow was roughly halved. The outsourced annotation-review team went from around 200 people to approximately three to four.
These results relate to the defined front-camera validation scope. Getting the results earlier gave engineers more time before production to investigate system behavior, test more conditions and examine individual problems in greater depth.
DVN: Validation requirements are growing more demanding with the move from L2/2+ toward L3 and eventually L4, while Euro NCAP and regulatory requirements are also stiffening. How does this change the validation methodology? What must an evidence platform be able to prove that was not necessary five years ago?
A.G.: The underlying validation principle is the same: demonstrate that the function behaves safely within its intended use and handles its limits appropriately. Scenario-based testing, adverse-weather testing and system-level validation were already important five years ago, including for L2 systems. As automation takes on more of the driving task, the safety argument has to reflect the different responsibilities of the driver and the system.
For L2, that includes the interaction between driver supervision and vehicle assistance. For L3, it includes the conditions under which the system operates and how a transition back to the driver is managed. For L4, the system must handle fallback within its defined operational design domain (ODD) without relying on a driver to take over. Engineers need to test relevant scenarios and parameter variations against those responsibilities.
In addition to significantly broader testing, the growing challenge is keeping the evidence consistent as software, operating conditions and assessment requirements change. A platform should let engineers trace a result to the requirement, test conditions, data, and software version behind it, compare results after a change, and see where coverage or uncertainty needs attention.
Ottometric provides tools to organize and compare the results so engineers can decide what to investigate or test next. The customer owns the safety argument and the release decision.
DVN: Validation and homologation requirements differ around the world. How do you build a platform that scales across these regulatory regimes without duplicating effort for every market?
A.G.: Although regulatory requirements differ, manufacturers must meet a high safety bar in every market. The platform needs a common engineering foundation with evaluations configured for each program. Qualified recordings, scenario descriptions and analysis methods can be reused where applicable, with the relevant KPI definitions, test conditions, and reporting requirements. Each recording’s suitability must still be checked: differences in road conditions, traffic behavior or test procedures may require additional collection or testing.
Ottometric supports this through configurable KPIs, dataset selection and versioned results, so engineers can trace the data and settings behind an evaluation and rerun the relevant analysis when requirements or evaluation settings change. This reduces repeated preparation while keeping market differences visible. The customer’s engineering and homologation teams determine whether the evidence is sufficient and what further work is needed.
DVN: With end-to-end AI, continuously updated vehicle software, and increasingly data-driven development, what will ADAS validation look like in five years? What part of the value chain does Ottometric want to own in the future?
A.G.: Over the next five years, I expect continuous testing and validation to support faster development iterations and more frequent software updates. As end-to-end AI and other machine-learning approaches become more common, engineers will need to identify improvements, regressions and conditions that remain insufficiently tested. An overall improvement can still hide a weakness in a critical safety scenario.
Evidence from fleet operation, road tests, simulation and controlled physical tests must inform each development cycle. Teams need to compare versions and use the findings to decide what data to collect, what to change in the software or model, and what to test next. Releasing decisions remain essential.
The customer owns the process and should retain control of its data and engineering history as tools and technology partners change. Ottometric’s role is to provide tools that qualify recordings, select relevant data and help engineers evaluate results within their existing toolchain. Automation is key to shortening those cycles, so teams can investigate problems, test changes and make well-supported software-update decisions sooner.
DVN: Thanks for your time and thoughts!
