ADAS & Autonomous Driving Data

Context & Challenge

Autonomous driving doesn't happen without data — and not just any data. The Machine Learning models that power Advanced Driver Assistance Systems (ADAS) are only as reliable as the labeled datasets they are trained on. At diconium, I own the end-to-end delivery of these labeled datasets, coordinating a global network of suppliers to ensure the right data reaches the right place, at the right quality and volume, on time.

The core challenge is one of precision at scale: ML models must perceive the environment around a vehicle with enough accuracy to make safety-critical decisions. That means the data feeding those models — camera frames, LiDAR point clouds, radar sequences — must be labeled with surgical accuracy, governed by strict technical requirements, and continuously refined as the model evolves.

How the ML Pipeline Works — and Where I Fit

The labeling workflow begins long before a single image is annotated. An AI Developer and a Requirements Specialist jointly define the technical specifications for what the model needs to learn. From there, data is collected from specially equipped test vehicles, then selected, pre-processed, and sent for labeling. My role sits across this entire chain: translating engineering requirements into supplier briefs, validating quality at each stage, and ensuring datasets are delivered within agreed timelines and thresholds.

Data preparation involves several decision points: choosing between real-world recorded data and synthetic data, applying filters to extract the most relevant edge cases, anonymizing faces and license plates, and generating pre-labels — AI-assisted detections that reduce manual effort while still requiring human validation. Each of these steps involves trade-offs between cost, speed, and accuracy, and I work closely with engineering and supplier teams to navigate them.

Case Study: Traffic Sign Recognition

Traffic sign recognition is one of the most technically demanding labeling tasks in the ADAS space — and a strong example of how I approach complex, multi-stakeholder challenges. Signs vary by country, condition, and context. A speed limit sign partially obscured by a branch, a faded warning sign, or a sign that applies only to other road users — all of these require precise, rule-based annotation that accounts for local legislation and real-world degradation.

The labeling output for traffic signs is not a single annotation but a structured set of properties: sign type and action category (restriction, warning, directional), text and numeric values (e.g. speed limit), relevance to the Ego vehicle, and visible defects such as faded paint or graffiti. Getting this right requires highly trained annotators, well-maintained tooling, and clear, unambiguous requirement documentation — all areas I actively manage.

On the model side, an effective architecture for traffic sign recognition uses two ML models in parallel: one for detection (identifying where a sign is in the camera frame, drawing on input from multiple sensors to resolve position accurately) and one for classification (determining exactly what kind of sign it is, trained on image crops rather than full-frame data). The labeled data I deliver feeds both. Bridging that technical architecture with the operational reality of supplier workflows — different tools, formats, and expertise levels across teams — is where a lot of the product management work happens.

Iteration, Feedback Loops & Prioritization

One of the core rhythms of this work is the model-data feedback loop. After each training cycle, engineers evaluate the model's performance against agreed threshold values. Where the model underperforms — producing false positives, missing detections, or misclassifying edge cases — I work with the development team to prioritize which data gaps to address first, whether through targeted extraction from the existing data bank or by commissioning new collection campaigns.

This requires constant stakeholder alignment: engineering teams have performance targets, suppliers have capacity constraints, and the product roadmap has delivery commitments. My job is to hold all of those in balance — making data-driven decisions about where to invest labeling effort, and communicating clearly across all parties so that the iteration cycle stays efficient and no team is blocked.

Tooling & Operational Efficiency

Beyond the content of the data, I focus heavily on the health of the system that produces it. Using Databricks and SQL, I monitor dataset performance metrics and track delivery status across suppliers. I have also introduced Python-based automation for documentation workflows — reducing manual reporting overhead and giving the team faster visibility into bottlenecks.

These operational improvements aren't just about efficiency. In a domain where the quality of labeled data directly impacts vehicle safety, having reliable, real-time visibility into what's been delivered, validated, and integrated is a product requirement in itself.