A vehicle is already a connected device. It has been full of sensors for decades, and modern models ship with a cellular modem from the factory.
So the interesting question is not whether cars produce data. They produce plenty. The question is how you get useful data off a moving vehicle, at a cost you can afford, in a shape your software can act on.
That is where most connected vehicle projects get harder than expected. This post walks through the engineering side of vehicle IoT: where the data comes from, what the network does to it, and which decisions you cannot reverse later.
If you want the business use cases first, our post on automotive IoT solutions covers those, and the internet of vehicles piece looks at where mobility is heading.
Key Takeaways
- Four data sources exist: aftermarket devices, embedded telematics, manufacturer APIs, and the driver's phone. Each trades coverage against depth.
- The vehicle network produces far more signals than you can afford to transmit. Deciding what to send is the core design task.
- Connectivity drops constantly. Any product that assumes a live connection will lose data on day one.
- Trips, not raw signals, are the useful unit. Getting from one to the other is harder than it sounds.
- Location and driving behavior count as sensitive personal data, and regulators treat them that way.
Where the Data Comes From
You have four realistic ways to read a vehicle, and the choice shapes everything downstream.
Aftermarket Devices
A device plugged into the diagnostic port, or wired in behind the dash. Light vehicles in the United States have carried that port since the mid-1990s, so coverage across older fleets is excellent.
You get deep access. Engine data, fault codes, and speed all come off the vehicle network directly. You also get an install cost per vehicle, hardware you have to support, and a device someone can unplug.
Heavy trucks and construction equipment use different standards on the same idea. If your fleet is mixed, plan for more than one protocol.
Embedded Telematics
Newer vehicles arrive with a telematics unit and a cellular connection built in. Nothing to install and nothing to unplug.
The catch is access. That unit reports to the manufacturer, not to you. Getting the data means a commercial relationship, and what you receive is whatever the manufacturer chose to expose.
Manufacturer APIs
Most large manufacturers now publish connected vehicle APIs, and aggregators exist that put several behind one interface.
This is the fastest path to a working product. No hardware, no installs, and coverage of new vehicles across brands.
The trade-off is control. Signal availability varies by brand, model, and year. Update rates are usually slower than a device on the vehicle network. Terms and pricing sit with the manufacturer, and they change.
The Driver's Phone
A phone has GPS, an accelerometer, and a gyroscope. For driving behavior scoring, that is often enough, which is why several insurance products work this way.
You get zero hardware cost and instant scale. You also get no engine data, battery drain complaints, and a permission the user can revoke whenever they like.
Choosing
Most products end up combining sources. A practical rule: if you need engine and diagnostic depth, put something on the vehicle. If you need breadth across many vehicles quickly, start with APIs or the phone.
The Bandwidth Problem
Here is the constraint people underestimate. A vehicle's internal network carries a continuous stream of messages, and the signals you might care about update many times per second.
Sending all of that over cellular, for every vehicle, is not affordable. It is also not useful, because almost none of it changes a decision.
So you filter, and where you filter matters. Three common approaches:
Sample on change. Send a signal only when it moves past a threshold. Fuel level does not need a reading every second.
Summarize on the device. Compute what you actually need locally, then send the result. Harsh braking events, idle time, and trip distance are all better calculated on the vehicle than reconstructed in the cloud.
Buffer and batch. Hold data locally and upload in blocks, rather than streaming continuously.
This is a specific case of the general pattern in edge computing for IoT systems. The vehicle version is stricter, because the network is worse and the data rate is higher.
One warning. Whatever you discard on the device is gone. Teams routinely filter aggressively, then discover six months later that the signal they threw away was the one that mattered. Keep a raw capture mode you can switch on for a subset of vehicles.
Connectivity Is Never Continuous
Vehicles drive into tunnels, parking garages, rural gaps, and other countries. Coverage disappears constantly, and none of it is an error condition.
Design for it from the start.
Store and forward. The device holds data during outages and sends it when the link returns. Size local storage for the longest outage you expect, then double it.
Idempotent uploads. After a dropped connection, the device will resend. The platform has to absorb duplicates without double counting a trip.
Clock discipline. Device clocks drift and reset. Every record needs a device timestamp and a server receive time, or you will not be able to reassemble the order of events.
Roaming cost. Cross-border driving turns a predictable data bill into an unpredictable one. Check the terms before the fleet does it for you.
Raw Signals Are Not the Product
Nobody wants a stream of vehicle signals. They want trips, events, vehicle health, and driver behavior. Turning one into the other is the real work.
Trip detection. Deciding when a trip starts and ends sounds trivial and is not. Ignition state is not always available. Short stops, traffic, and drive-through stops all confuse simple rules. Get this wrong and every distance and duration figure downstream is wrong.
Location cleanup. GPS drifts, especially in cities and around tall buildings. Raw points produce phantom movement and inflated distances. Map matching against a road network fixes most of it.
Event detection. Harsh braking, rapid acceleration, and cornering all come from accelerometer thresholds. Those thresholds differ by vehicle type and by mounting position. A threshold tuned on a sedan will call a delivery van reckless.
Fault code translation. Diagnostic codes are part standard, part manufacturer-specific. Turning a code into a maintenance instruction takes a mapping you have to build and maintain.
Fuel and energy figures. Consumption and battery state come from different signals in different vehicles, sometimes as estimates rather than measurements. Treat reported accuracy with suspicion until you validate it.
Each of these is where a demo diverges from a product. The demo shows a map with a moving dot. The product survives a driver saying the mileage is wrong.
Security and Regulation
A connected vehicle is a safety-critical system with a network connection, so the bar here is higher than in most IoT work.
The industry has settled on some structure. ISO/SAE 21434 covers cybersecurity engineering across the vehicle lifecycle.
UN Regulations 155 and 156 go further. They require manufacturers to run a cybersecurity management system and a software update management system. That turns over-the-air updates into a governed process rather than a convenience.
If you build on top of vehicles rather than building vehicles, most of that lands on you indirectly, through what a manufacturer will let your product do. Plan for gated write access, and assume anything that touches vehicle behavior will face review.
Your own baseline still applies. Per-device identity, signed firmware, an update path you have tested, and encrypted transport. Our post on security for IoT devices covers the fundamentals.
Privacy Deserves Its Own Section
Vehicle data is location data, and location data reveals where someone sleeps, works, worships, and receives medical care. Several privacy regimes classify precise location as sensitive, and regulators have looked hard at vehicle telematics.
Practical positions that hold up:
- Collect the resolution the feature needs, not the maximum the device can produce.
- Separate vehicle identity from driver identity wherever the product allows it.
- Set retention limits per data type, and delete on schedule.
- Make consent specific and revocable, especially for behavior scoring.
- Tell drivers what is collected in language they will actually read.
Commercial fleets have a different but related problem. Drivers know they are tracked, and a program that feels like surveillance produces disabled devices and disputed reports. Usage-based insurance products live or die on this, and so do fleet safety programs.
Where Vehicle IoT Pays Off
The value shows up in a few consistent places, all of them operational.
Fleet operations. Vehicle location, utilization, and routing. This is the most established use, and our post on IoT in transportation covers the transit side.
Maintenance. Fault codes and usage data let you service on condition rather than on a fixed calendar. The gain is avoided breakdowns, not cheaper oil changes.
Insurance and risk. Driving data prices risk more accurately than demographics do.
Compliance. Hours of service, inspection records, and emissions reporting all get easier when the data collects itself.
Infrastructure. Vehicle data feeds signal timing and hazard warnings, which is the overlap with smart city IoT.
Final Thoughts
Vehicle IoT looks like a hardware problem and behaves like a data problem. The sensors already exist and the network is already there. What separates a product from a pilot is the unglamorous middle: what you send, what you keep, how you rebuild a trip from imperfect records, and how you handle the fact that the connection keeps dropping.
Get that layer right and the applications on top are straightforward. Skip it and every feature above inherits the same quiet inaccuracy.
Frequently Asked Questions
What is IoT in vehicles?
It is the use of sensors, network connections, and software to read what a vehicle is doing and act on it. That covers location, engine and battery status, fault codes, and driving behavior.
How do you get data out of a car?
Four ways. A device on the diagnostic port or vehicle network, the manufacturer's built-in telematics unit, a manufacturer connected vehicle API, or the driver's phone. Each differs in depth, coverage, and cost.
Do you need hardware in every vehicle?
Not always. Manufacturer APIs and phone sensing cover many use cases with no install. You need hardware when you need engine and diagnostic depth, or when the fleet includes older vehicles.
What happens to data when a vehicle loses signal?
A well-built device stores it locally and uploads when the connection returns. That requires local storage, duplicate-safe uploads, and timestamps that survive a clock reset.
Is vehicle telematics data personal data?
Usually yes. Location and driving behavior can identify a person, and several privacy regimes treat precise location as sensitive. Design consent, retention, and access controls accordingly.
If you are building on vehicle data and the trip numbers are not holding up under scrutiny, the fix is almost always in the ingestion and data layer rather than the application. Get in Touch and we can look at where the accuracy is leaking.
