Unified data infrastructure
GitHub Let's talk

Automotive

Vehicles, lines and warranty claims share one key.

A vehicle is a record while it is built and a time series after it leaves the plant. The data that describes it has to survive both phases.

See Digital Twins All of Industrial

One vehicle, two lives: the build record and the years of telemetry after it.

The story

One vehicle, two lives: the build record and the years of telemetry after it.

Where it starts

Vehicle telemetry

State of charge, drivetrain measurements, fault codes and usage counters. It is the first of 4 workloads running in Automotive.

The question it raises

As-built to as-used

A telemetry anomaly is read against the configuration the vehicle was actually built with, not the nominal one.

Why one question is hard

From Design to Service

Automotive data moves through 5 stages — Design → Build → Delivery → In service → Service. The shapes in play are Time series, SQL, JSON / documents, Events, Objects, and answering one question means reading across all of them.

What PLOMID contributes

The same identifier has to mean the same thing at build time and in service. These are the parts that keep that true.

  • One data layer Rows, documents and time-ordered events live in one system, so a question is asked once instead of once per store.
  • Time-ordered storage Measurements and events are stored beside the records and documents they describe, so history and current state agree.
  • Every client, one layer Applications, AI clients, services and background jobs reach the same data through the same interfaces.
The environment

Vehicle telemetry, build records, connected-fleet data and service history.

Build records, component identifiers and quality documentation are structured and document data. After delivery, the same vehicle produces telemetry and service events for years. PLOMID holds the build record and the operational history in one layer, so a fleet question does not start with an identifier matching exercise across systems.

One environment · many workloads

What runs against automotive data.

4 workload families over one set of shapes. Choose one to see what it moves and where it lands.

State of charge, drivetrain measurements, fault codes and usage counters.

  • Planned once against the layer, not once per store
  • Read beside the records it shares a key with
  • Persisted under one storage contract
The data journey

How automotive data reaches one layer.

Walk the path the data takes, from the environment that produces it to the questions it answers. Select a station, or a shape, to read each step.

One vehicle, two lives: the build record and the years of telemetry after it.

Environment

The vehicle

A VIN that has to mean the same thing on the assembly line and on the road.

SQL

Where the data goes to work

Questions the field asks daily.

Each one is a workload over the shapes above, answered from the same layer rather than from a purpose-built copy.

As-built to as-used

A telemetry anomaly is read against the configuration the vehicle was actually built with, not the nominal one.

  • JSON / documents
  • Objects

Warranty decisions

Warranty claims join the service record, the component lot and the usage history in one request.

  • SQL
  • JSON / documents

Fleet reporting

Usage and reliability aggregates compute over operational data, so the numbers reported match the numbers served.

  • SQL

Software update tracking

Update events are stored beside the vehicle record, which is what makes an update cohort knowable later.

  • Time series
  • Events
Data models in play

The shapes, in one layer.

5 shapes carry this domain. Choose a stage to read the operation, or a shape to see every stage that handles it.

PLOMID · Automotive design · build · delivery · in service · service Select a stage
Stage

Design

Specifications, BOM and change documents

JSON / documents · Objects

Workload map Automotive workload map. Every shape on it is a surface of the layer, and each stage names the part of the operation it carries.
  • Time series Measurements and events in time order
  • SQL Records, keys and joins
  • JSON / documents Documents and nested objects
  • Events Operational events as they happen
  • Objects Large assets with queryable metadata
Workload architecture

Which workload touches which model.

The work, the shapes it names and the path a request takes — from the field to the control room.

Automotive · workload architecture
Workloads

What runs against this data.

  • Vehicle telemetry
  • Build and component records
  • Service history
  • Fleet events
Data models

The shapes those workloads read and write.

  • Time series
  • SQL
  • JSON / documents
  • Events
  • Objects
The layer

One path from a request to the data it names.

  • Planning Predicates narrow the work before it runs
  • Execution Records, fields and windows answered together
  • Transactions Readers and writers do not block each other
Surfaces

How the work reaches the layer.

  • SQL surface The query language the layer is documented in
  • Applications Services and jobs writing and reading as they run
  • Analytics & AI clients The same layer, the same access path
Deployment & residency

Where this data is allowed to run.

Connected vehicles write from unpredictable places, so ingestion has to tolerate latency and loss at the edge.

Deployment, residency and control
What you build next

Digital Twins

An asset model that is read from operational data instead of synchronised with it.

If As-built to as-used is your question, start here.

See Digital Twins Every solution
Next

Where to go next

Solutions The workload answers this industry leans on, with their models and status. Platform The data models in the product today, and the ones extending the layer. Architecture How a request is planned, executed and persisted once it reaches the layer.