Automotive IoT: V2X, OBD-II Telematics, Fleet Management

Modern vehicles are rolling IoT nodes: a well-equipped car carries dozens of ECUs — often 70 to more than 100 — on a CAN, LIN, and automotive-Ethernet backbone, plus a cellular modem reporting to a fleet or OEM cloud. Automotive IoT ties three distinct technology stacks together — vehicle-to-everything (V2X) wireless, OBD-II-based telematics, and fleet management platforms — and each has different latency, security, and data-volume requirements. Getting the architecture wrong (e.g., routing safety-critical V2X messages through a cloud round trip) is not just an inefficiency, it's a safety defect.

V2X: Vehicle-to-Everything Communication

V2X is the umbrella term for vehicles exchanging data with other vehicles, infrastructure, road users, and networks. The safety-critical links work directly between radios, without going through a cellular network core, so they can meet tight latency budgets; V2N is the exception that uses the mobile network:

Two radio technologies implement the direct links:

• DSRC / ITS-G5 (IEEE 802.11p): 5.9 GHz band, operating outside the context of a BSS (OCB mode, used by the WAVE stack), so there is no association or handshake. A message can go out within a few milliseconds because there's no network join delay. In the US the message set is SAE J2735, with the Basic Safety Message (BSM) broadcast at 10 Hz; Europe uses ETSI CAM and DENM messages over ITS-G5, the European 802.11p profile.
• C-V2X (3GPP): also in the 5.9 GHz ITS band in most regions, built on cellular baseband IP. It has two interfaces: PC5 sidelink for direct communication, which works without network coverage (radio resources are either picked by the vehicle itself or scheduled by the base station when in coverage), and Uu, the ordinary cellular link used for V2N. 5G NR-V2X adds higher-throughput sidelink modes for sensor sharing and platooning, alongside LTE-V2X for basic safety.

Regulation has largely settled the choice by region. In the US, the FCC moved the lower 45 MHz of the band to unlicensed use in 2020 and reserved the upper 30 MHz (5.895–5.925 GHz) for C-V2X; rules adopted in November 2024 gave DSRC two years to phase out, so new US designs are C-V2X. China standardized on LTE-V2X. Europe's band is technology-neutral, and deployed systems such as Volkswagen's Car2X use ITS-G5.

Latency budget matters concretely. A Basic Safety Message must propagate and be processed well within 100 ms for a collision-avoidance use case to be actionable at highway speeds. At 100 km/h (≈27.8 m/s), 100 ms of total latency already corresponds to ≈2.8 m of travel per vehicle — twice that between two vehicles closing head-on. That's why V2X uses direct broadcast instead of a server round trip, which alone can add 50–150 ms over LTE and far more over LTE-M or NB-IoT.

Security relies on a Security Credential Management System (SCMS) in the US, or the EU C-ITS PKI defined by the European C-ITS Certificate Policy. Each message is signed (IEEE 1609.2 in the US, ETSI TS 103 097 in Europe, typically ECDSA P-256) with a short-lived pseudonym certificate, rotated frequently to prevent long-term tracking while still allowing misbehaving senders to be revoked. Verification load is the hidden cost: with 100 vehicles in range each sending 10 messages per second, a receiver may face up to about 1,000 signature checks per second, which is why V2X modules carry hardware crypto acceleration and many implementations verify only the messages a safety application actually acts on.

OBD-II Telematics: Reading the Vehicle's Own Diagnostics

Every light-duty vehicle sold in the US since model year 1996 has a standardized 16-pin SAE J1962 diagnostic connector within reach of the driver, usually under the dash; in the EU, EOBD has been required on petrol cars since 2001 and on diesel cars since 2004. This is the easiest, most universal entry point for retrofit telematics — no integration with the OEM's telematics control unit (TCU) is required.

• Physical/link layer: ISO 15765-4 (CAN-based), mandatory on US vehicles from model year 2008; older vehicles also used SAE J1850 PWM/VPW, ISO 9141-2, or ISO 14230-4 (KWP2000).
• Application layer: SAE J1979 defines standardized Parameter IDs (PIDs) — Mode 01 PID 0C is engine RPM, PID 0D is vehicle speed, PID 05 is coolant temperature, and Mode 03 retrieves stored Diagnostic Trouble Codes (DTCs). New vehicles are moving to SAE J1979-2 (OBD on UDS), driven by California's OBD rules from around the 2027 model year: the same data is read with UDS ReadDataByIdentifier (0x22), with engine speed, for example, at DID F40C. Dongle firmware should support both.
• Typical dongle architecture: an OBD-II plug-in device polls PIDs at 1–10 Hz, buffers samples, and uplinks over LTE-M or LTE Cat 1, or via Bluetooth to a paired phone app. NB-IoT is a poor fit for moving vehicles because it lacks connected-mode handover, and 2G/3G networks are being switched off in many countries.

PID decode example — vehicle speed, Mode 01 PID 0D, response byte A:

Response: 41 0D 32
  41 = Mode 01 response
  0D = PID (vehicle speed)
  32 (hex) = 50 decimal → 50 km/h directly, no scaling

Engine RPM, PID 0C, uses two bytes A and B:

Response: 41 0C 1A F8
  A = 1A (hex) = 26, B = F8 (hex) = 248
  RPM = (256·A + B) / 4 = (256·26 + 248) / 4 = 6904 / 4 = 1726 RPM

The encoding spans 0–16,383.75 rpm in 0.25 rpm steps. On CAN, the same exchange travels as single ISO-TP frames, with the first byte giving the payload length:

Request  ID 0x7DF (functional, all ECUs): 02 01 0C 00 00 00 00 00
Response ID 0x7E8 (engine ECU):           04 41 0C 1A F8 00 00 00

Padding bytes vary by ECU (0x00, 0x55, and 0xAA are all common).

Limitations engineers should account for: OBD-II only exposes powertrain- and emissions-related signals reliably; body, chassis, and ADAS signals are usually absent or manufacturer-proprietary, and many newer vehicles put a security gateway behind the connector that blocks anything beyond the legally required data without authentication. OBD requests use low-priority CAN IDs (0x7DF, 0x7E0–0x7E7), so they lose arbitration to normal traffic, but every request still costs bus bandwidth and ECU processing time (see CAN bus frame format and arbitration). Where the connector sits directly on a powertrain bus, aggressive polling raises bus load and delays lower-priority frames, so production dongles rate-limit requests and cache slowly changing values such as the VIN (Mode 09) and, where supported, the odometer (PID A6) rather than repolling them.

Fleet Management: From Raw Signals to Operational Decisions

Fleet management platforms consume telematics streams (OBD-II PIDs, GPS, driver ID, sometimes raw CAN) from many vehicles and turn them into aggregate metrics. The architecture is a classic device → gateway → cloud IoT pipeline:

[Vehicle ECU/CAN] --OBD-II/J1939--> [Telematics Unit] --Cellular (LTE-M / LTE Cat 1)--> [Cloud Ingestion] --> [Time-series DB] --> [Fleet Dashboard/API]
                                      |          |
                              GNSS receiver    Local buffer (store-and-forward
                              (position/speed)  during coverage gaps)

For heavy-duty trucks, the equivalent of OBD-II is SAE J1939 over CAN (typically 250 or 500 kbit/s, through a 9-pin Deutsch connector): a higher-layer protocol with Parameter Group Numbers (PGNs) instead of PIDs. Each PGN carries one or more Suspect Parameter Numbers (SPNs), such as engine hours and fuel rate, and active fault codes travel in DM1 messages, all over 29-bit extended CAN IDs.

Core telematics data categories a fleet platform tracks:

• Location & routing: GPS trace, geofencing events, route deviation.
• Vehicle health: DTCs, battery voltage, engine hours, fault codes — feeding predictive maintenance.
• Driver behavior: harsh braking/acceleration (from accelerometer or OBD-II speed derivative), idling time, hours-of-service compliance.
• Fuel/energy: fuel consumption or, for EVs, state of charge and charging events (usually from OEM data rather than standard PIDs).

Configuration such as reporting intervals and geofences is usually pushed to each unit through a device shadow or digital twin, so a vehicle that was offline picks up the latest settings when it reconnects.

Store-and-forward design is non-negotiable. Cellular coverage is never guaranteed (tunnels, rural routes, parking garages), so the telematics unit must buffer telemetry locally in a flash-backed queue sized for the longest expected outage (typically hours to days, with wear leveling). Timestamp every record when it is captured (GNSS time is a good source) and upload buffered records with their original timestamps after reconnecting — never stamped with the upload time, and never silently dropped.

Bandwidth/cost trade-off example: streaming raw CAN at even a modest 50 kbit/s is about 22.5 MB per driving hour, or roughly 4.5 GB per vehicle per month at 200 driving hours — far too expensive across a large fleet. Periodic summaries (one ~200-byte record every 30 s under normal driving, plus event-triggered records on harsh braking or a new DTC) come to about 5 MB per month, nearly a thousand times less. Encoding those records in a compact binary format (Protobuf, or CBOR with integer keys) instead of JSON typically shrinks them several-fold again.

Practical Design Implications

• Separate the safety path from the fleet path. V2X safety messages must never depend on cloud connectivity; fleet analytics can tolerate seconds-to-minutes of latency and intermittent connectivity.
• Choose the connector layer to match integration depth. OBD-II retrofit dongles are fast to deploy but limited to standardized data; deep integrations (OEM factory-fit TCUs or OEM cloud APIs) get richer signal access but require per-OEM agreements. Whether the fleet service is sold as a subscription or as a managed device changes the hardware priorities too — see IoT business models.
• Budget for certificate/PKI overhead in V2X designs. Pseudonym certificate rotation, revocation handling, and signature verification add real compute and storage requirements to the V2X module, distinct from the telematics unit's TLS-based cloud authentication.
• Design for intermittent connectivity everywhere. Telematics and V2N links need local buffering. Direct V2V/V2I messages are near-real-time but best-effort broadcasts with no acknowledgments, so applications must tolerate lost packets — one reason BSMs repeat at 10 Hz.

Key Takeaways

• V2X uses direct 5.9 GHz broadcast — C-V2X in the US and China, ITS-G5 in deployed European systems — specifically to avoid cloud round-trip latency, keeping safety messages such as the SAE J2735 BSM within a sub-100 ms budget.
• OBD-II/SAE J1979 gives universal, standardized access to core powertrain data (RPM, speed, DTCs) over CAN, but not to body, chassis, or ADAS data; new vehicles are moving to J1979-2 (OBD on UDS), and heavy-duty vehicles use SAE J1939.
• Fleet management platforms are a standard device→gateway→cloud IoT pipeline: telematics units summarize and buffer data locally, then uplink over LTE-M or LTE with store-and-forward to survive coverage gaps.
• Bandwidth and cost constraints push fleet telemetry toward periodic, event-triggered summaries in compact binary formats, not raw CAN streaming or verbose JSON.
• Security architectures differ by layer: V2X signs every message with PKI-issued pseudonym certificates (SCMS in the US), while telematics and fleet links use standard TLS-based device authentication to the cloud.