Insights / Automotive & Mobility
How to Connect and Program a Car for the Internet of Vehicles
What connects a car to the Internet of Vehicles: ECUs and the CAN bus, central computers, the telematics unit and radios, and the rules automotive code must follow.
The short answer
A car joins the Internet of Vehicles through its electronics. Dozens of electronic control units (ECUs) run individual functions and share data over the CAN bus. A telematics control unit (TCU) collects that data and connects the car to the cloud over cellular, while Wi-Fi, Bluetooth and V2X radios handle phones and nearby vehicles. Programming the car means writing embedded software for these units to automotive standards such as MISRA, AUTOSAR, ISO 26262 and ISO/SAE 21434, and testing it in simulation, on the bench and on the road.
What it takes to put a car on the Internet of Vehicles
The Internet of Vehicles is the network formed when cars exchange data with the cloud, with each other and with road infrastructure. It promises less congestion, automatic payments at chargers and car parks, and earlier warnings of hazards. Every one of those services depends on what is inside the car: the computers that run it, the networks that link them, and the unit that talks to the outside world.
It also raises a question every programme must answer early: who can access the data the car produces, and how is it protected? Driving habits and location are personal data, and remote commands touch safety-critical systems.
For the business view of use cases and V2X, see IoT in automotive and transportation. This article stays inside the vehicle.
Under the hood: electronic control units and the CAN bus
Electronic control units (ECUs) are the backbone of a car's electronics. Each runs one function or a group of them: engine, transmission, brakes, airbags, body control, climate, infotainment. A dedicated CAN bus links them into the vehicle's internal network, so the brakes, the stability control and the dashboard all see the same wheel-speed data.
Safety-critical ECUs must be completely dependable. They are qualified for wide temperature ranges, vibration and electrical noise, and are usually built on automotive-grade microcontrollers using proven processes rather than the newest consumer chips. Most have modest processors and small amounts of memory: enough for control loops, not for rich media or driver-assistance workloads.
- Telematics control unit (TCU)
- The on-board module that gathers data from the vehicle's ECUs and sensors, stores and processes it, and connects the car to a remote server over cellular and other wireless links.
From many ECUs to central computers
Infotainment and advanced driver-assistance systems (ADAS) changed the compute budget. Drivers expect a car that keeps updating after purchase, with navigation, music, calls and new features as apps or add-on services. ADAS has to fuse radar, lidar, camera and ultrasonic data around the car in real time. Neither fits into a small control-unit processor.
The answer is consolidation: powerful central computers, and zonal controllers that gather the inputs from one area of the car. This shift moves value towards semiconductors and software, and makes over-the-air updates a core capability rather than an extra.
How the car connects: TCU, radios and the cloud
- Vehicle networkSensors, ECUs and actuators exchange data over the CAN bus and other in-vehicle networks.
- Telematics control unitThe TCU collects vehicle state, adds GPS position, stores and pre-processes the data.
- Wireless linksCellular carries data to the cloud; short-range Wi-Fi and Bluetooth connect the driver's phone.
- Back endServers and databases in a telematics operations centre store and process the data.
- ServicesEmergency and call centres, service providers and apps act on it, and send commands and updates back.
Modern cars support cellular (including 5G), Wi-Fi, Bluetooth and NFC, and increasingly C-V2X. Automotive radios have their own constraints:
- Modules must survive heat, humidity and vibration inside the vehicle.
- They must stay supported for the life of the car, which is often more than ten years, far longer than a phone.
- Several radios in one vehicle need filtering and antenna design so they do not interfere with each other.
- Proven, automotive-qualified modules avoid most of these problems.
With the TCU in place, the same data stream supports remote diagnostics and automatic crash notification, prediction of faults from subtle changes in readings, fleet management, and insurance priced on how the car is driven. For what the TCU should collect and how it copes with lost coverage, see vehicle telemetry.
Programming the car: requirements and standards
Automotive software is embedded software with higher stakes. It must integrate with the car's own computers and buses, often through specialist equipment. Access control and security need special attention. And testing happens in stages: in a virtual environment, on a lab bench or test vehicle, and on the road.
| Standard | What it governs | What it means for developers |
|---|---|---|
| MISRA C / C++ | Coding guidelines for safety-related C and C++ from the Motor Industry Software Reliability Association | A restricted language subset, enforced by static analysis |
| AUTOSAR | A standard software architecture for ECUs (Classic) and high-performance computers (Adaptive) | Common interfaces and basic software, so components can be reused across suppliers |
| ISO 26262 | Functional safety of road-vehicle electrical and electronic systems, with Automotive Safety Integrity Levels (ASIL A–D) | Requirements, design, testing and traceability rigour set by the risk of each function |
| ISO/SAE 21434 | Cybersecurity engineering across the vehicle lifecycle | Threat analysis, secure design and ongoing vulnerability management for connected functions |
On the infotainment side, Apple CarPlay and Android Auto project phone apps onto the car's display and controls, so music, calls, navigation and a voice assistant are available with steering-wheel buttons or speech. Some manufacturers also run Android Automotive OS on the head unit itself. Either way, the interface must let the driver keep attention on the road: large targets, voice control, and physical buttons where a touchscreen would distract.
What this changes for a product team
A connected-car feature is never just an app. It spans an ECU or TCU firmware change, a radio link, a back end and a user interface, each with its own constraints and test regime. Teams that treat the vehicle side as a black box discover late that the signal they need is not on the bus, the update path cannot carry their change, or the feature distracts the driver.
Before you build a connected-car feature
Work through these first
- Find out which vehicle signals you need and where they live: which ECU, which bus, which message.
- Decide whether the logic runs in an ECU, the TCU, the cloud or the phone, and why.
- Identify the standards that apply to the function: MISRA, AUTOSAR, the ISO 26262 safety level and ISO/SAE 21434.
- Plan how the software is updated over the air and how a failed update rolls back.
- Design the driver interaction for minimal distraction: voice and physical controls first.
- Staff the team with engineers who know vehicle data: what it is, where it comes from and how to control it.
- Budget for simulation, bench and road testing.
Was this useful?
Where this shows up in our work
ExpertiseEmbedded and firmware engineeringTelematics and control-unit software, from modem handling and RTOS design to safe over-the-air updates on automotive-grade MCUs, is embedded work our firmware engineers own.For how this in-vehicle work fits vehicle, fleet and mobility programmes, see Automotive & Mobility.
Apply this to your product
Discuss your vehicle data system
Sources
- AUTOSAR – standards overview accessed 1 October 2026
- ISO 26262-1 – Road vehicles: functional safety accessed 1 October 2026
- ISO/SAE 21434 – Road vehicles: cybersecurity engineering accessed 1 October 2026