Insights / Automotive & Mobility
IoT in Automotive and Transportation: Use Cases, Architecture and Challenges
How IoT is used in cars and transportation, how vehicle data travels from sensor to cloud, and the security and connectivity problems a programme must solve.
The short answer
An IoT car is a vehicle whose sensors and control units are connected, through an on-board telematics unit, to a network and the cloud, so its data can be monitored and it can receive commands and software updates remotely. IoT in the automotive industry and transportation builds services on that data: remote control, fleet tracking, predictive maintenance, usage-based insurance, EV battery and charging management and V2X safety messages. This guide is for product and engineering teams at vehicle makers, fleet operators and mobility companies who need the whole chain, from sensor to cloud, to work securely and when the network drops.
Key takeaways
- Automotive IoT is a chain: in-vehicle sensors and buses, a telematics unit, connectivity, cloud and apps.
- Most use cases reuse the same data; design the pipeline once and build services on it.
- Vehicles lose coverage constantly, so the on-board unit must buffer and reconcile.
- Security is a safety issue here: signed updates, protected keys and authenticated commands are baseline.
Why vehicles became connected products
A vehicle used to be finished when it left the factory. Today much of what a car, truck or e-bike does is defined by software that can change after sale, and by data it sends back. That shifts where the work is: from the mechanics of a single model to systems that collect data from many vehicles, keep them updated and turn their data into decisions.
- Manufacturers get field data on how components behave, instead of learning only from warranty claims.
- Fleet operators move from reacting to breakdowns to planning maintenance, routes and driver coaching.
- Insurers can price on how a vehicle is actually driven.
- Mobility services such as car sharing, rental and micro-mobility depend on live location, state and remote access.
What is an IoT car, and how does it differ from a connected car and the Internet of Vehicles?
An IoT car is a vehicle whose sensors and control units are connected to a network and the cloud through an on-board telematics unit, so its data can be monitored and acted on remotely. It is the vehicle end of a wider system:
- Automotive IoT
- The layered system of vehicle sensors, embedded computing, wireless links, cloud platforms and software that collects data from vehicles and acts on it.
Every IoT car carries this chain: sensors and control units, an on-board unit that connects to a network, and services that use its data. The three terms below overlap, but they imply different engineering scope.
| Concept | Scope | Primary focus | Examples |
|---|---|---|---|
| Connected car | One vehicle linked to a phone or the cloud | Driver convenience and in-cabin services | Smartphone mirroring, remote start, emergency call |
| Internet of Vehicles (IoV) | A network of vehicles, roads and city systems | Communication between vehicles and their surroundings | Traffic-signal coordination, hazard warnings, platooning |
| Automotive IoT | The full hardware-to-cloud system | End-to-end data collection, processing and services | Fleet telematics, battery health monitoring, predictive maintenance |
For what happens inside the vehicle itself, the ECUs, the vehicle bus and the telematics unit, see how a car is connected and programmed.
How does automotive IoT work, from sensor to service?
- SenseSensors and electronic control units (ECUs) monitor engine or motor load, tyre pressure, battery charge, braking and position.
- Aggregate in the vehicleData travels over the vehicle's internal networks, mainly the CAN bus, to a telematics control unit (TCU).
- Process at the edgeThe TCU filters, decodes and summarises time-sensitive data locally, cutting bandwidth and delay.
- TransmitCellular links carry data to the cloud; short-range links handle phones, depots and chargers.
- Analyse and actCloud services combine fleet data, run models, trigger alerts, feed APIs and dashboards, and push over-the-air updates.
Commands and over-the-air updates flow back down the same chain, so it must be secured in both directions.
For a closer look at what the on-board unit collects and how it copes with lost coverage, see vehicle telemetry.
How is IoT used in automotive and transportation?
Most use cases draw on the same few data sources. What changes is who consumes the data and how fast they need it.
| Use case | How it works at system level | Who benefits |
|---|---|---|
| Remote vehicle services | A secure on-board unit keeps an encrypted link to the cloud, authenticates each command (unlock, pre-condition, immobilise) and passes it to the vehicle network. | Owners, car-sharing and rental fleets, OEMs selling feature subscriptions |
| Tracking and telematics | GPS and on-board diagnostics stream position and operating state, sending updates when something changes: a stop, a harsh turn, a speed threshold. | Delivery and logistics fleets; geofencing against unauthorised use |
| Fleet management | Fleet software pulls telemetry from mixed vehicles into one system, scores driving, tracks fuel or energy use and automates compliance logs. | Fleet operators managing cost, safety and compliance |
| Predictive maintenance and remote diagnostics | Vibration, temperature, pressure and fault data are compared with expected wear; drift outside the normal range triggers a service recommendation. | Fleets avoiding unplanned downtime; OEMs improving components |
| V2X communication | Vehicles broadcast short safety messages about position, speed and braking directly to nearby vehicles and roadside units. | Road safety, traffic management, cooperative driving |
| Usage-based insurance | Mileage, driving times and braking patterns from an app, an OBD-II dongle or an OEM data feed set the premium. | Insurers and the drivers they price more fairly |
| EV battery monitoring and smart charging | The battery management system reports cell temperature and voltage; the cloud estimates health and range and coordinates with chargers and energy prices. | EV owners, fleets and charging operators |
| Manufacturing and quality control | Sensors on assembly robots and inspection systems stream to factory edge servers; each vehicle's electronics are checked against its build record. | Plants reducing defects and keeping traceability |
Transportation beyond the car follows the same patterns: public transit uses vehicle location and passenger information, and freight adds cargo condition and security. For shipments and containers, see IoT in logistics and shipping.
What infrastructure does IoT vehicle integration need?
Integrating vehicles into an IoT system takes four layers of infrastructure: in-vehicle sensors and buses, a telematics control unit with edge processing, connectivity, and cloud platforms with APIs, apps and dashboards.
1. In-vehicle sensors, OBD-II and the CAN bus
The CAN bus is the vehicle's main internal network, linking engine, transmission, brakes and body functions. The simpler LIN bus handles low-priority functions such as windows, and automotive Ethernet increasingly carries camera and radar data. On cars, the OBD-II port gives standardised access to diagnostic codes.
2. Telematics control unit and edge processing
Sending raw bus traffic to the cloud is too slow and too expensive. The TCU decodes proprietary CAN messages into structured data, filters and summarises it, and can run light on-board analysis, such as detecting a crash or driver fatigue from a cabin camera.
3. Connectivity
Cellular (4G and 5G) carries long-range traffic to the cloud. C-V2X connects vehicles directly to each other and to infrastructure. Wi-Fi and Bluetooth cover short-range jobs: bulk upload at a depot, or keyless entry from a phone. Keeping the integration layer independent of the link lets you change radios without rebuilding the back end.
4. Cloud platforms, APIs, apps and dashboards
Data pipelines feed storage and live dashboards. APIs pass the same data to fleet tools, insurance and billing systems and consumer apps. This layer is where telemetry becomes something drivers, fleet managers and engineers can use.
What is V2X, and how do vehicles talk to their surroundings?
V2X (vehicle-to-everything) is what turns individual connected cars into a coordinated network, the Internet of Vehicles. Cameras and radar only see what is in their line of sight; V2X lets a vehicle learn about a hazard around a corner or a braking car several vehicles ahead.
| Type | Connects the vehicle to | Typical use |
|---|---|---|
| V2V (vehicle-to-vehicle) | Nearby vehicles | Warning trailing cars of sudden braking; platooning |
| V2I (vehicle-to-infrastructure) | Traffic lights, tolls, roadside units | Adaptive signal timing, road-works and speed warnings |
| V2N (vehicle-to-network) | The mobile network | Routing, weather, dispatch and traffic information |
| V2C (vehicle-to-cloud) | Cloud services | Telemetry, remote services and over-the-air updates |
| V2P (vehicle-to-pedestrian) | Phones or wearables carried by people | Alerting drivers to pedestrians and cyclists in blind spots |
| V2G (vehicle-to-grid) | The electricity grid via the charger | Coordinated charging and, where supported, returning energy to the grid |
What are the main challenges and security risks of automotive IoT?
Connecting a safety-critical machine to a public network raises the engineering bar.
- Cybersecurity and privacy: a breach can become a physical safety risk if commands can be spoofed. Automotive cybersecurity engineering is framed by ISO/SAE 21434, and in many markets type approval requires a cybersecurity and software-update management system under UNECE Regulations 155 and 156. Keys belong in a hardware security module, and driving data falls under privacy law such as GDPR.
- Coverage gaps: vehicles pass through tunnels, garages and dead zones. The on-board unit must buffer data and reconcile it when the link returns.
- Mixed and older vehicles: each make and model year can use different proprietary CAN messages, so a fleet-wide layer needs firmware that maps them into one data model.
- Over-the-air update security: the update channel is also an attack surface. Images must be signed and checked before install, ideally into a separate memory partition with automatic rollback.
- Scale and cost: moving from thousands to millions of vehicles changes the cost of data. Edge filtering, compact formats and autoscaling pipelines keep it in check.
Where automotive IoT is heading
- Software-defined vehicles: functions are consolidating from many single-purpose ECUs into a few central and zonal computers, with features delivered and updated as software.
- Edge AI in the vehicle: more machine-learning inference, such as vision and driver monitoring, runs on board without a network round trip.
- 5G, C-V2X and connected infrastructure: cities and road operators are connecting signals and parking to vehicles to manage traffic flow.
- Digital twins: fleets and manufacturers keep live models of vehicles, updated from telemetry, to simulate wear and plan maintenance.
All four raise the importance of the same foundations: a reliable data pipeline, secure updates and an on-board unit that behaves well when it is offline.
Indeema has delivered engineering programs for enterprises including Siemens, Nokia and IBM, and a new engineering engagement can start in as little as 10 days.
Engineering trade-offs
Off-the-shelf telematics dongle vs custom on-board unit
- You gain
- A dongle or standard tracker is fast to deploy and fine for location and basic diagnostics.
- You pay
- It limits which signals you can read, how data is processed on board and who owns the data.
- Choose it when
- Start with standard devices for tracking; build a custom unit for non-standard vehicles, edge processing, strict security or a proprietary data platform.
OEM data feed vs your own on-board hardware
- You gain
- An OEM feed needs no installation and can expose signals an aftermarket device cannot.
- You pay
- Coverage varies by make and model, and you depend on each manufacturer's access terms.
- Choose it when
- Use OEM feeds for mixed private fleets where installation is costly; use your own hardware where you need consistent signals across every vehicle.
Processing on the vehicle vs in the cloud
- You gain
- On-board processing is faster, works offline and sends less data.
- You pay
- It needs more capable hardware and careful, secure updates.
- Choose it when
- Keep safety alerts and event detection on board; keep fleet-wide analytics and model training in the cloud.
When a programme needs custom IoT engineering
Standard trackers cover basic location. Custom engineering is usually justified when you need:
- Hardware for non-standard vehicles, such as proprietary EVs, e-bikes or industrial vehicles, that generic gateways were not built for.
- Real-time processing on board: safety alerts or inference a generic gateway cannot run.
- Security and compliance designed in: hardware-backed keys, authenticated commands and a documented update process.
- Your own data platform, without being locked into a device vendor's cloud.
- One team across the stack, from circuit design and firmware through cloud and mobile.
Common mistakes
Buying consumer-grade connectivity for a fleet-grade job
The device cannot read the signals, process data on board or meet the security bar the service needs.
Instead: Decide the use cases and the data they need first, then choose hardware.
Assuming the vehicle is always online
Data gaps and failed commands appear exactly in garages, tunnels and rural areas.
Instead: Design store-and-forward and command retries into the on-board unit.
Bolting key management on later
Security reviews fail because the architecture has nowhere safe to hold keys.
Instead: Plan hardware-backed identity and signed updates with the first hardware revision.
Building each layer with a separate team and no shared data model
Signals change meaning between bus, cloud and app, and integration drags on.
Instead: Own one data contract from vehicle signal to API field.
Where we've built this
The on-board layer of this architecture is where we built a telemetry unit for an electric bike maker, extending an existing board and back end with connectivity, maintenance features and updates over the air.
Case studyTelemetry and over-the-air update firmware for an electric-bike control unitA telemetry unit for electric bikes: firmware on an automotive-grade MCU with cellular reporting, a queue for coverage gaps and safe over-the-air updates.Questions engineers ask
What is an IoT car?
A vehicle whose sensors and control units are connected, through an on-board telematics unit, to a network and the cloud, so its data can be monitored and it can receive commands and software updates remotely.
How is IoT used in transportation?
For vehicle and fleet tracking, remote diagnostics and predictive maintenance, driver behaviour and usage-based insurance, EV charging, V2X safety and traffic management, and monitoring cargo condition and security in transit.
What is automotive IoT?
The combination of vehicle sensors, embedded computing, wireless connectivity, cloud platforms and software that collects data from vehicles and turns it into services and decisions.
How does IoT improve vehicle diagnostics and maintenance?
Sensors and control units stream component data such as vibration, temperature, pressure and fault codes. Analytics compare it with expected wear, so a service can be scheduled when readings drift, before the part fails.
How do you secure IoT in the automotive industry?
With layered controls: hardware-protected keys, secure boot, encrypted links, authenticated commands and signed over-the-air updates with rollback, managed under a cybersecurity process such as ISO/SAE 21434.
Was this useful?
Where this shows up in our work
SolutionConnected Product Engineering: One System, Not Isolated PartsAutomotive IoT only works when the on-board unit, firmware, connectivity, cloud and apps are engineered as one system. That end-to-end work is what our connected product engineering covers.For how we work with vehicle makers, fleets and mobility companies on these programmes, see Automotive & Mobility.
Apply this to your product
Discuss your vehicle data system
Sources
- ISO/SAE 21434 – Road vehicles: cybersecurity engineering accessed 1 October 2026
- UNECE World Forum for Harmonization of Vehicle Regulations (WP.29) accessed 1 October 2026