When building a fleet's telematics system, the first decision is hardware. Do you use the systems already built into the vehicles by the Original Equipment Manufacturer (OEM), like Ford Pro or GM's OnStar, or do you install third-party, aftermarket devices from companies like Geotab or Samsara?

OEM systems come factory-installed, offering deep integration with vehicle diagnostics. Aftermarket hardware is brand-agnostic, providing a consistent experience across a mixed fleet. Each path has significant trade-offs in data access, cost, and operational flexibility.

Imagine your fleet has Fords, Toyotas, and Mercedes vans. The Ford system calls harsh braking "Rapid Deceleration," while Toyota calls it a "Hard Braking Event." The Mercedes might just provide raw g-force data. This is the core problem of a multi-brand fleet: you get different data "dialects" that don't speak the same language.

To make sense of it all, you need a process called data normalization to translate these disparate inputs into a single, unified format. This means creating a rule that says, for example, any g-force reading above 0.5g or any event labelled "Hard Braking" gets categorised as a single event type in your central dashboard. Without this, comparing driver safety across your fleet is nearly impossible. This is where an API-driven integration strategy becomes essential. By using APIs, you can programmatically pull data from each manufacturer's platform into your own system, where you control the normalization rules.

The goal is to build an open architecture. Instead of being locked into one provider's dashboard, you create a central hub that can ingest data from any source, whether it's an OEM platform or an aftermarket device. This gives you the strategic flexibility to add any vehicle to your fleet without worrying if its data will fit into your system.

The hardware at the heart of any telematics system is the Telematics Control Unit (TCU). This is the small box, often hidden away, that contains the GPS receiver, accelerometer, and a SIM card for communication. Modern TCUs use low-power cellular technologies like LTE-M or the high-speed connectivity of 5G to transmit data efficiently. Many now feature eSIMs (embedded SIMs), which can be provisioned and switched between mobile networks remotely, a huge advantage for international fleets.

But how does the TCU talk to the vehicle's internal systems? It uses standardised diagnostic protocols. Two key standards you'll encounter are:

• ISO 14229 (UDS): Unified Diagnostic Services. This is the language used to request diagnostic information (like engine fault codes or sensor readings) from a vehicle's Electronic Control Units (ECUs).
• ISO 13400 (DoIP): Diagnostics over Internet Protocol. This standard defines how UDS messages can be sent over an IP network, like the one created by the TCU's cellular connection. It essentially puts the diagnostic language onto the internet.

These protocols ensure a degree of interoperability, allowing aftermarket devices to communicate effectively with vehicles from various manufacturers.

So, how do you combine all these elements? You design a hybrid architecture.

This hybrid approach allows you to leverage the deep data from your newer, OEM-equipped vehicles while maintaining a consistent data platform for older or more varied assets using aftermarket hardware. By controlling the normalization layer, you retain strategic control, avoid vendor lock-in, and build a system that can scale with your fleet, no matter what vehicles you add next.