Design Deep Dive

Problem 1: Data fragmentation

How I designed a solution for data fragmentation across thousands of vehicle types

Modern vehicles generate thousands of signals, but each manufacturer structures and names them differently.

OEM A

engineRPM

OEM B

EngineSpeed

OEM C

Proprietaryfmt021x

No Universal Schema

Customers can not rely on consistent data structure across their fleet

Broken Analysis

Cloud applications can not consume or compare data consistently

Fragmentation is more than a naming issue. It breaks cross-fleet analysis, increases onboarding time, and forces teams to manually decode signals before any meaningful work can begin.

How I investigated the problem space

Key insights

Automotive Engineers

Workshops to unpack how raw signal files were defined, maintained, and handed off internally

Internal SMEs

Whiteboard sessions with experts who had previously worked inside major OEMs

These sessions helped me map the entire signal lifecycle, from creation inside embedded systems to consumption inside cloud pipelines.

Amazon Fleet Teams

Conversations with teams who consume telemetry at scale and deal with inconsistent signal definitions

1/ The Data Language Divide

While engineers typically think in mechanical terms, cloud developers require structured, typed, and hierarchical schemas. Historically, no translation layer exists to bridge these two worlds.

2/ Team structure creates massive variation in file quality

Large OEMs have full signal-definition teams, while smaller manufacturers rely on one developer juggling everything end-to-end.

3/ Different stakeholders care about different categories of signals

Diagnostics, safety, behavior, drivetrain, battery health—the priorities change depending on who is consuming the data.

Vehicle data was inconsistent, and for legitimate, structural reasons.

What I could not assume

One mental model

One use case

One team size

One structure

Respect workflows

Design solution

Cloud-ready

All team sizes

Low friction

Industry standards

Team alignment

Ownership of signal standardization was initially unclear. I introduced a shared responsibility model:

Engineers

maintain control over their source files

FleetWise

ensures structural consistency

Both Sides

contribute to clean onboarding

This model aligned embedded engineers, cloud architects, PMs, and SAs around a workflow that was fair, scalable, and technically sound.

The solution

1/ The Fast-Track: OBD-II Starter Catalog

To drive immediate value, I curated a "fast-start" OBD-II signal list. This allows customers to validate their data pipelines and begin testing instantly, bypassing the friction of manual configuration during initial setup.

  • Strategic Domain Expertise: By pre-integrating these common industry standards, we positioned AWS as a domain expert that understands the technical baseline of automotive telemetry.

  • Immediate Confidence: Providing out-of-the-box support for the most critical vehicle signals proved that AWS speaks the same language as the hardware, establishing trust from day one.

2/ The Bridge: Local Conversion Engine

I designed a downloadable conversion script that allows engineers to standardize proprietary signal files into the industry-standard Vehicle Signal Specification (VSS) format locally.

  • Full Spectrum Ingestion: The solution standardizes traditional mechanical telemetry (RPM, speed) alongside rich environmental sensor data (LiDAR, Radar).

  • Workflow Integration: By running locally, the tool respects the existing habits of embedded engineers while ensuring cloud developers receive structured, standardized outputs.

3/ Unified Onboarding Experience

I designed a signal import workflow that scales from solo developers to large OEM teams, ensuring a seamless transition from raw files to cloud-ready assets. The system automatically validates metadata and suggests auto-fills, reducing human error and significantly speeding up the path to data activation.

  • Automated Duplicate Detection: To maintain a clean "Source of Truth," the service automates the detection of duplicate signals. This eliminates the need for engineers to manually cross-reference files, effectively reducing noise in the signal catalog and preventing downstream data conflicts.

  • Intelligent Validation: By surfacing metadata inconsistencies during the import phase, the UI ensures that only high-fidelity, VSS-compliant data enters the system.

North star v/s Phase 1

North Star vision: The 3D digital twin and seamless ecosystem

As a "North Star" for the product, I proposed a shift from a list-based management tool to a visually rich, interconnected ecosystem that aligns with the mechanical mental models of automotive engineers.

  • The 3D Digital Twin: A high-fidelity visualization where engineers can define and explore the vehicle network in 3D, making the relationship between hardware and data immediate and intuitive.

  • Seamless Ecosystem Mapping: A fully connected architecture that allows users to map network interfaces, create models, and organize fleets and campaigns in a single, unified view.

  • Global Context & Control: Users can instantly see which vehicles are associated with specific models and fleets, and identify exactly which campaigns are currently running on them.

  • Dynamic Dissociation: The interface empowers users to easily associate or disassociate vehicles from campaigns and fleets from anywhere in the ecosystem, ensuring total operational flexibility as fleet needs evolve.

Phase 1 Release

A lean, dependable foundation:

  • All resource creation flows

  • Conversion script

  • OBD started set

  • Basic validation surfaces

  • Lightweight documentation

Strategic trade-offs and product thinking

In a 0 → 1 environment, choosing what not to build is as critical as the build itself. My decision-making was guided by three core priorities

Learnings and reflections