
An Embedded TCU Is a Different Animal
A connected vehicle programme cannot run on a bolt-on tracker. The telematics control unit is part of the vehicle electrical architecture, wired onto the bus, tied to ignition and vehicle power, and held to automotive EMC, environmental, and functional safety requirements. It has to carry a certified eCall stack, an always-on connectivity strategy, a secure OTA path, and bus access that respects the OEM gateway. Building that demands embedded hardware, automotive firmware, and a cloud platform working as one. That is the scope covered for OEMs and Tier-1 suppliers.
One layer of the full Telematics and GPS Tracking platform, working closely with GPS Tracking Device Development.
WHAT'S INCLUDED
The Embedded Telematics Unit and Its Services
TCU and Embedded Telematics Unit
The telematics control unit hardware and firmware include an automotive-grade modem, multi-constellation GNSS, CAN and J1939 interfaces, an internal backup battery, and a defined wake and sleep behaviour tied to ignition. The unit is built to the OEM environmental, EMC, and reliability targets rather than as a generic tracker.
eCall and Emergency Call Stack
The automatic emergency call is built in. On a severe crash detected from the airbag signal or an internal sensor, the TCU places a voice call and transmits position, vehicle identity, and heading to the response centre, with the in-band data transfer and self-check behaviour required for type approval.
Remote Diagnostics
The bus is read, CAN on passenger vehicles and J1939 on commercial, with signals and DTCs decoded against the vehicle database. The platform surfaces vehicle health, fault codes, and service triggers so the OEM and the owner see problems before they become breakdowns.
Stolen Vehicle Recovery
The recovery path covers immobiliser interaction within the OEM security model, geofence and movement alerts, and a high-priority tracking mode that the operator can trigger to follow and recover a stolen vehicle.
OTA Updates
Over-the-air updates use an A/B partition scheme, signed images, verification before switchover, automatic rollback, and resumable transfers over unreliable cellular. This covers the TCU and, where the architecture allows, other ECUs through it.
Digital Key and Owner App
The connected car owner app and a digital key let the user lock, unlock, locate, and check the vehicle, and share access securely. The app ties into the same platform that handles diagnostics, recovery, and notifications.
VEHICLE INTEGRATION
Designed Into the Electrical Architecture
A TCU lives on the bus and on vehicle power, so it has to behave like an ECU, not a peripheral. The integration is designed to the OEM rules for bus access, power states, and security from the start.
CAN and J1939 Bus Access
The unit interfaces to CAN on passenger vehicles and J1939 on commercial and off-highway, subscribing only to the messages the function needs and respecting the gateway and security boundaries the OEM defines.
Always-On Connectivity
The connectivity strategy is designed for an always-reachable vehicle, including low-power standby on ignition-off, network selection, and the data path that keeps eCall and recovery available when the vehicle is parked.
Type Approval and Homologation
The design targets automotive EMC, environmental, and regional regulatory requirements, including eCall mandates and radio approvals, with the homologation process supported so the unit ships in a production programme.
WHO IT'S FOR
OEMs, Tier-1s, and Aftermarket Programmes
OEMs Building a Connected Platform
The embedded TCU and the connected services for a vehicle programme are built as one stack across hardware, firmware, and cloud, so the pieces fit instead of being stitched across vendors.
Tier-1 Suppliers
Development takes a TCU from concept to a type-approved, production-ready unit, including the eCall stack and OTA path that the OEM customer requires.
Aftermarket and Retrofit
Where an embedded TCU is not feasible, a robust aftermarket telematics unit delivers the same connected services within the constraints of a retrofit install.
Commercial and Off-Highway
J1939 fleets, trucks, buses, and off-highway machines are covered, where remote diagnostics and uptime matter as much as the connected features on a passenger car.
FAQ
Common Questions
What is a TCU and how is it different from an aftermarket tracker?
A telematics control unit is an embedded module designed into the vehicle, wired onto the CAN or J1939 bus and the vehicle power and antennas, rather than plugged into an OBD port. It has automotive-grade components, a defined wake and sleep behaviour tied to ignition, and it has to meet the OEM environmental, EMC, and functional safety requirements. An aftermarket tracker is a bolt-on; a TCU is part of the vehicle electrical architecture.
How does eCall work in a TCU?
eCall is the automatic emergency call. On a severe crash, detected from the airbag deployment signal on the bus or an internal sensor, the TCU places a voice call to the emergency number and transmits a minimum set of data, position, vehicle identity, and direction of travel, to the response centre. The eCall stack is built to the regional specification, including the in-band data transfer and the test and self-check behaviour required for type approval.
How do you read vehicle data from the bus?
Vehicle data is read from the CAN bus on passenger vehicles and J1939 on commercial and off-highway vehicles. The TCU subscribes to the relevant messages and DTCs, decodes them against the vehicle database, and reports the signals needed for remote diagnostics, health monitoring, and the owner app, while respecting the gateway and security boundaries the OEM sets on bus access.
How are OTA updates handled safely on a vehicle?
An A/B partition scheme writes a new firmware image to the inactive partition and only switches over after verification, with automatic rollback if the new image fails to come up. Updates are signed and checked before install, staged so they never run while the vehicle is in an unsafe state, and resumable over an unreliable cellular link. This applies both to the TCU itself and, where the architecture allows, to other ECUs through it.
Do you support type approval for OEM programmes?
Yes. A TCU has to meet automotive EMC, environmental, and regional regulatory requirements such as eCall mandates and radio approvals. The unit is designed to those targets from the start, with the homologation and type approval process supported so it can ship in a production vehicle programme.
Build Your Connected Vehicle Platform
Share your vehicle programme, the bus and connectivity targets, and the connected services you need to get a scoped TCU, the eCall and OTA path, and the platform that gets you to a type-approved unit.
Schedule a Free Consultation