Vehicle Data Capture Architecture for Heterogeneous Fleets
Jun 29, 2026 Sandeep Kumar
A vehicle data capture architecture is the layered system that acquires, transmits, decodes, normalizes, stores, and serves vehicle data from every asset in a fleet. At Resolute Dynamics, we build this architecture across seven functional layers: the edge layer, the connectivity layer, the ingestion layer, the normalization layer, the storage layer, the analytics and application layer, and a security and operations layer that protects all of them.
This guide explains how each layer works and how to design one that handles a fleet of mixed makes, models, and protocols without losing data fidelity.
What Is a Vehicle Data Capture Architecture?
A vehicle data capture architecture is a pipeline that turns raw signals from a vehicle’s electronic control units into clean, comparable records in a central platform. The pipeline starts at a device on the vehicle and ends at a dashboard, an alert, or an API call.
Each stage has one job, and the data becomes more structured as it moves from the wires inside the vehicle toward the people and software that use it.
The Seven Functional Layers at a Glance
The architecture separates into seven layers, each responsible for one transformation of the data:
- Edge layer reads raw signals from the vehicle bus and sensors.
- Connectivity layer moves messages from the vehicle to the platform.
- Ingestion layer receives, authenticates, and decodes those messages.
- Normalization layer translates every protocol into one shared format.
- Storage layer keeps both live and historical records.
- Analytics and application layer delivers dashboards, alerts, and APIs.
- Security and operations layer encrypts, authenticates, and monitors the whole system.
Splitting the work this way keeps each part replaceable. We add a new vehicle type at the edge without rewriting the dashboards, because the normalization layer absorbs the difference.
What Makes a Fleet “Heterogeneous”?
A heterogeneous fleet is a fleet built from mixed makes, models, model years, weight classes, and communication protocols operating together. A single operator might run light delivery vans, heavy trucks, passenger cars, school buses, and electric vehicles at the same time.
Each of those categories speaks a different data language, and that difference is the core design problem this architecture solves.
Vehicle-Class Diversity
Fleets cover at least six vehicle classes, and each one reports data differently. Common examples include light-duty cars and SUVs, medium-duty vans, Class 6 to Class 8 trucks, passenger and school buses, off-highway and construction equipment, and battery electric vehicles.
A pickup reports a small set of emissions parameters, while a Class 8 truck broadcasts engine hours, fuel rate, aftertreatment health, and torque requests across dozens of control units.
Protocol Diversity: OBD-II vs CAN vs SAE J1939
Three standards dominate vehicle data, and they are not interchangeable. CAN (Controller Area Network) is the low-level bus that defines how bits travel over the wires, while OBD-II and SAE J1939 are higher-level standards that give those bits meaning.
OBD-II is the emissions-focused diagnostic standard mandated on US light-duty vehicles since the 1996 model year, and it uses a 16-pin SAE J1962 connector. SAE J1939 runs on top of CAN for Class 6 to Class 8 commercial vehicles, buses, and off-highway equipment, and it commonly uses a 9-pin Deutsch connector.
| Standard | Relationship | Vehicle Class | Fault-Code Format | Connector |
|---|---|---|---|---|
| CAN | Underlying serial bus | All modern vehicles | Raw frames | Varies |
| OBD-II | Diagnostic standard on CAN | Light-duty cars and SUVs | DTCs (P-codes) | 16-pin SAE J1962 |
| SAE J1939 | High-level protocol on CAN | Class 6–8 trucks, buses, equipment | SPN + FMI pairs | 9-pin Deutsch |
A scanner built for a passenger car cannot read a heavy truck, because the code format and data structure differ. Our capture architecture solves this by reading the correct standard for each vehicle and converting the result into one shared format.
Why Diversity Breaks Naïve Data Capture
Naïve data capture fails on mixed fleets because every manufacturer, and often every model, defines its own diagnostic trouble codes. A fault code from one engine maker means something different on another, and without translation the fleet cannot compare maintenance issues across vehicles.
The result is siloed dashboards, mismatched units, and key metrics that cannot be added together. A proper architecture removes these gaps by standardizing the data before anyone reads it.
What Data Does the Architecture Capture?
The architecture captures four categories of data: location and motion, engine and energy, driver behavior, and safety-system status. Each category answers a different fleet question, and together they form a complete operating picture of every vehicle.
Location and Motion
Location and motion data covers GPS position, speed, and heading, sampled continuously. This is the foundation of fleet visibility, and it powers route tracking, geofence alerts, and historical playback. Our GPS Tracking Systems collect this stream from a GNSS receiver on each vehicle and tag it with a precise timestamp.
Engine, Powertrain, and Energy
Engine data covers RPM, fuel rate, diagnostic trouble codes, and engine hours for combustion vehicles, plus battery state of charge and charging status for electric vehicles. On a heavy truck, this data arrives as SPN and FMI pairs over J1939.
On a light vehicle, it arrives as OBD-II trouble codes. Electric vehicles report battery state over their own CAN frames, which the architecture decodes the same way it decodes every other source.
Driver-Behavior Events
Driver-behavior data covers harsh braking, harsh acceleration, and speeding events detected from motion and engine signals. These events feed safety scoring and coaching programs. We capture each event with the location and time it occurred so the fleet can review the full context, not just a count.
Safety-System and Compliance Data
Safety-system data covers speed-limiter status and Intelligent Speed Adaptation events. This category records whether a vehicle’s speed control is active and logs each time the system intervenes. For regulated fleets, this data forms the compliance record that proves vehicles operate within set limits.
The Layers of the Architecture
The architecture processes data through six working layers in a fixed order, with security wrapped around all of them. Data enters at the edge and gains structure at each step until it reaches the people and systems that act on it.
Edge Layer: Reading the Vehicle
The edge layer is the on-vehicle hardware that reads raw signals, and it includes a telematics control unit, a GNSS receiver, and sensors connected to the vehicle’s CAN bus. This hardware decides which parameters to sample and how often. A well-designed edge device filters noise on the vehicle so the connectivity layer carries only useful data.
Connectivity Layer: Moving the Data
The connectivity layer transmits messages from the vehicle to the platform over cellular, satellite, or short-range links. It also buffers data when coverage drops. This store-and-forward behavior keeps a vehicle’s record complete even when it drives through a tunnel or a remote area with no signal.
Ingestion Layer: Receiving and Decoding
The ingestion layer receives messages, authenticates the device, decodes the payload, and enriches it before passing it on. This is the platform’s front door. It confirms each message comes from a trusted vehicle, converts the raw payload into readable fields, and adds context such as the vehicle profile.
Normalization Layer: One Shared Format
The normalization layer translates every protocol into one canonical schema so the rest of the system never sees a raw protocol again. This is the layer that makes a heterogeneous fleet manageable. It maps an OBD-II trouble code and a J1939 SPN to the same internal field, so a fuel-level reading means the same thing whether it came from a van or a Class 8 truck.
Storage Layer: Live and Historical
The storage layer keeps current records for live tracking and historical records for analysis, usually in a time-series store paired with a relational database. Live data drives the map; historical data drives reports and trend analysis. Separating the two keeps real-time dashboards fast while preserving years of history.
Analytics and Application Layer: Delivering Insight
The analytics and application layer turns stored data into dashboards, alerts, and APIs that people and other systems use. This is where the fleet manager sees a map, receives a speeding alert, or pulls data into a maintenance system. Because everything below this layer is already normalized, the same dashboard works for every vehicle in the fleet.
How to Handle Protocol and Signal Heterogeneity
The architecture handles protocol heterogeneity with an abstraction layer that maps each vehicle’s protocol to one canonical model, so downstream systems stay protocol-agnostic. The abstraction layer holds the rules for reading each bus type.
A generic request for “engine speed” reaches the abstraction layer, which knows whether to read an OBD-II parameter or a J1939 SPN for that specific vehicle, then returns the value in a standard form.
Decoding OBD-II DTCs vs J1939 PGN/SPN Pairs
Decoding differs by standard, so the architecture keeps a decoder for each. OBD-II reports faults as diagnostic trouble codes such as P-codes, while J1939 reports faults as SPN and FMI pairs, where the SPN identifies the parameter and the FMI describes the failure. The normalization layer reads both and writes them into one fault record with a shared structure.
Building an Abstraction Layer for Make and Model Independence
An abstraction layer lets one application read parameters from many makes and models by separating the request from the protocol. The application asks for a parameter by name. The abstraction layer looks up the bus configuration for that vehicle, extracts the value, interprets it, and returns it. Adding a new make means adding its configuration to the abstraction layer, not changing the application.
Handling EV CAN Frames and Proprietary OEM Signals
Electric vehicles and proprietary systems extend the same pattern. EVs report battery state of charge, charging status, and energy use over CAN frames defined by the maker, and some manufacturers add proprietary parameter groups beyond the public standards. We document each custom group and add a decoder for it, which keeps the canonical schema complete as the fleet grows.
Preparing for the OBDonUDS Transition
The architecture stays current by supporting the OBDonUDS framework. The OBDonUDS transition moves light-duty diagnostics from SAE J1979 to SAE J1979-2 starting in 2027, built on the Unified Diagnostic Services framework. Fleet platforms that read light-duty data add support for J1979-2 to keep full access to newer vehicles. We design the ingestion and normalization layers to add this support without disturbing existing decoders.
Edge Processing vs. Cloud Processing for Mixed Fleets
The architecture splits work between the edge and the cloud based on latency, bandwidth, and connectivity needs. Time-critical and bandwidth-heavy tasks run on the vehicle; aggregation and long-term analysis run in the cloud. Most mixed fleets use both, with the balance set per vehicle type.
| Factor | Process at the Edge | Process in the Cloud |
|---|---|---|
| Latency | Immediate safety responses | Reporting and trends |
| Bandwidth | Filtering raw high-frequency signals | Aggregated summaries |
| Connectivity | Works offline, then forwards | Requires a live connection |
| Analysis | Single-vehicle events | Whole-fleet patterns and model training |
When to Process at the Edge
Edge processing fits tasks that need a fast response or that generate too much data to send raw. A harsh-braking detection runs on the vehicle so the event is recorded the moment it happens. Filtering also runs at the edge, which cuts the volume the connectivity layer carries and lowers cellular cost.
When to Process in the Cloud
Cloud processing fits tasks that combine data from many vehicles or that look across long time spans. Whole-fleet route optimization, maintenance trend analysis, and driver-scoring models all run in the cloud, because they need data from the entire fleet at once. The cloud also trains the models that the edge later uses.
Designing a Canonical Data Model
A canonical data model gives every vehicle one consistent record structure regardless of its source protocol. This shared model is the contract between the messy world of vehicle buses and the clean world of dashboards and APIs. Once data fits the canonical model, no downstream system needs to know where it came from.
Entity–Attribute–Value Structure for Vehicle Records
The canonical model organizes data as entity, attribute, and value triples. The entity is the vehicle or a component, the attribute is the measured characteristic, and the value is the reading. A record states the vehicle, the parameter such as coolant temperature, and the measured figure with its unit. This structure scales cleanly as new attributes appear.
Identifiers, Timestamps, Units, and Data Lineage
Every record carries a vehicle identifier, a precise timestamp, a standard unit, and a record of its source. The identifier links the reading to the right asset. The timestamp orders events. The standard unit removes confusion between, for example, liters and gallons. The lineage records which protocol and device produced the value, so the fleet can trace any number back to its origin.
Security, Privacy, and Compliance
The architecture protects data with encryption in transit and at rest, device authentication, and defined retention rules. Vehicle data includes location and driver behavior, so the security layer treats it as sensitive from the moment it leaves the vehicle. Security is not a final step; it wraps every layer of the pipeline.
Securing the Device-to-Cloud Path
The device-to-cloud path is secured with authenticated devices and encrypted connections. Each vehicle device proves its identity before the ingestion layer accepts data, which blocks spoofed messages. The connection is encrypted so location and engine data cannot be read in transit.
Regional Data-Handling Considerations
Data handling follows the rules of the region where the fleet operates. For operators in the UAE and the wider GCC, this means storing and processing fleet data in line with local data-protection requirements. We design retention and access controls so a fleet meets these requirements without giving up the visibility it needs.
Integrating Data Capture with Speed-Limiter and ISA Systems
The capture layer connects directly to vehicle safety hardware. Our GPS tracking feeds location-based speed-limit data to the speed limiter to create an Intelligent Speed Adaptation solution. This turns passive data capture into active safety control, because the same data that fills a dashboard also keeps the vehicle within the legal limit for its location.
How Our GPS Trackers and Speed Limiters Share One Data Layer
A shared data layer lets the GPS Tracking Systems and the speed limiter / speed governor act on the same information. The tracker supplies the vehicle’s position, the system matches that position to the local speed limit, and the limiter enforces it.
For fleets that run mixed terrain or mixed vehicle types, our dual speed limiter and adaptive speed limiter extend this control to vehicles that need more than one fixed limit. This integrated approach reflects the engineering work behind our R&D projects.
A Reference Implementation Roadmap
A fleet builds this architecture in five phases, in order: device selection, connectivity setup, ingestion and normalization, storage, and dashboard rollout. Working through the phases in sequence keeps each layer stable before the next one depends on it.
- Select edge devices that read the right standard for each vehicle class in the fleet.
- Set up connectivity with store-and-forward so no data is lost in low-coverage areas.
- Build ingestion and normalization to decode every protocol into the canonical schema.
- Configure storage with separate live and historical stores.
- Roll out dashboards and APIs that present a single view across the whole fleet.
Frequently Asked Questions
How do you capture data from vehicles that use different protocols?
Data from different protocols is captured by reading each vehicle with the correct standard, then normalizing every reading into one shared schema. The edge device reads OBD-II, J1939, or a proprietary bus as appropriate, and the normalization layer converts the result into a canonical record. Downstream systems then see one consistent format for the entire fleet.
What is the difference between OBD-II, CAN, and SAE J1939?
CAN is the low-level bus that carries the bits, while OBD-II and SAE J1939 are higher-level standards that give those bits meaning. OBD-II covers emissions diagnostics on light-duty vehicles and has been mandated in the US since the 1996 model year. SAE J1939 runs on CAN for Class 6 to Class 8 trucks, buses, and off-highway equipment, and it uses SPN and FMI fault codes.
Can one platform support diesel trucks, light vehicles, and EVs?
One platform supports all three when it uses an abstraction layer that maps each vehicle’s protocol to a canonical model. Diesel trucks report over J1939, light vehicles report over OBD-II, and EVs report battery data over CAN. The abstraction layer reads each source and returns standardized values, so a single dashboard covers the mixed fleet.
How is driver-behavior data standardized across vehicle types?
Driver-behavior data is standardized by detecting events from motion and engine signals, then writing them as common event records. A harsh-braking event from a van and one from a truck both become the same record type, tagged with location and time. This lets a fleet compare driver behavior fairly across very different vehicles.
What changes with the OBDonUDS 2027 transition?
The OBDonUDS transition moves light-duty diagnostics from SAE J1979 to SAE J1979-2 starting in 2027, built on the Unified Diagnostic Services framework. Telematics platforms add support for J1979-2 to keep full access to data from newer light-duty vehicles. A well-designed architecture adds this decoder without changing the rest of the pipeline.