Vehicle Telematics Platform Development Using NXP S32K

In order to maintain the new demands of fleet and logistics today, they require accurate real time data about the fleet's location, vehicle health and driver behaviour.

Telematics is being used by logistics and fleet managers, as well as insurance providers, to help reduce operational costs and improve compliance and safety.

This case study presents the complete development pathway for a production-ready VTT (Vehicle Telematics Tracker) IoT solution that leverages real-time tracking via GPS, provides CAN bus data collection, including engine diagnostics and fuel usage, provides geo-fence alerts, and tracks driver behaviour.

The VTT is based on an automotive-grade NXP S32K344 MCU, a mobile application developed in React Native, and a Java Spring Boot application that runs in the cloud, providing a scalable and reliable connected vehicle platform.

The VTT is based on a three-tier IoT architecture: the embedded hardware node installed in the vehicle, a cloud backend for ingestion and business logic, and a mobile application for fleet operators and drivers.

The NXP S32K344 is the central processing unit at the edge. The MCU was selected specifically because of its automotive pedigree – it natively supports multiple CAN FD and LIN interfaces, operates across the full automotive temperature range (−40°C to +125°C) and is designed with an ISO 26262 ASIL-D capable ecosystem, making it suitable for safety-relevant automotive applications.

The S32K344 handles the GPS NMEA parsing, CAN frame decoding, sensor fusion, alert calculation and sends data out over the cellular network using an attached modem.

A Java Spring Boot backend exposes REST APIs for device onboarding, telemetry ingestion, geofence management, alert processing, and reporting. The cloud layer uses Apache Kafka as a high-throughput message broker between the gateway that ingests data from devices and the services that process it downstream.

PostgreSQL can provide structured storage for fleet and device data, and TimescaleDB (a time series extension for PostgreSQL) can efficiently store high-frequency telemetry records.

At the client layer, a React Native app is focused on Android and iOS fleet managers and drivers, allowing them live vehicle tracking on maps, trip history, alert logs, driver scoring and geofence configuration.

Using an optional hardwired interface, the hardware node is an OBD-II plug-in device. The computing portion of the device is contained within a single NXP S32K344 MCU and interfaces with Subsystems as described below:

GPS module

The u-blox M10 GPS module is suitable for its high sensitivity (-167 dBm tracking), low current requirements and compactness. The GPS module connects to the S32K344 over UART at 115200 baud rate and delivers NMEA 0183 sentences (GPRMC, GPGGA) as parsed into the firmware for obtaining the position, speed, course, and quality of fix.

CAN Bus Interface:

The S32K344 integrates up to six CAN FD controllers. Two CAN FD channels are used — one for standard OBD-II PID polling (ISO 15765-4 compliant) and one reserved for proprietary OEM CAN frames in fleet vehicle deployments. A TJA1462 automotive CAN FD transceiver provides the physical layer interface, offering partial networking support to reduce standby power when the vehicle is parked.

Cellular Modem:

A Quectel EC21 LTE Cat-1 module provides primary connectivity via UART and AT command interface. Cat-1 was selected over NB-IoT for its balance of throughput, latency, and global band coverage suitable for vehicle mobility scenarios.

IMU:

A Bosch BMI088 6-axis IMU (accelerometer + gyroscope) connected via SPI enables rash driving detection — sudden braking, harsh acceleration, and sharp cornering detection through threshold-based and rolling-window analysis of lateral and longitudinal g-forces.

Power Management:

The device gets its power via the vehicle battery power (12v or 24v) through an automotive DC/DC converter that supplies power backwards to 5v through an LDO regulator, which supplies 3.3v to the MCU. It has reverse pole protection and transients that are protected using TVS diode arrays which meet the specifications for automotive transients per ISO 7637-2.

The PCB consists of six layers, to support the S32K344 LQFP package's complexity and include RF communication (GPS, LTE) antenna routing and automotive-grade electrical isolation.

The LTE and GPS communications antennas are routed as 50 ohm controlled impedance microstrip traces with grounded planes to provide isolation from digital noise through copper pours and careful component placement.

The CAN bus is routed as a face-to-face pair of wires with a termination resistor on each end of the CAN system. Shock absorbing devices are installed in close proximity to the pins of the OBD-II connection.

A conformally coated PCB after assembly protects against moisture and vibration and is required for installations under an engine hood or on the floorboard. DFM automotive manufacturing rules were used to design this board in Altium Designer; ANSYS SIwave was used to validate the integrity of the high-speed signals.

Firmware development was conducted using NXP's S32 Design Studio IDE and the S32K3 SDK (RTD - Real-Time Drivers). The firmware runs on AutoSAR-inspired RTOS layering using FreeRTOS as the kernel, with tasks organized by priority and function.

Five key tasks run at the same time. These include: acquiring the GPS and locating the user, polling the CAN bus for PID decoding, using the IMU sample to detect driving events, the management of cellular uplink data, and maintaining the system (watchdog, power management, and NVM logging).

The method of polling the OBD-II PIDs will be done per the ISO 15765-4 request/response specification and can be configured for: speed (PID 0x0D), RPM (PID 0x0C), coolant temp (PID 0x05), and fuel level (PID 0x2F).

A sliding window algorithm is used to detect driving events using the accelerometer data from the BMI088. Events are created for breaches of thresholds (set by fleet policy) and geo-stamped with GPS location and timestamp. All telemetry and event data are buffered in SPI NOR flash if a cellular outage occurs (in tunnels and areas with no signal) and then flushed when the connection is restored to guarantee there is no data loss.

MQTT over TLS 1.2 was selected for telemetry uplink, with the Quectel EC21 modem handling TCP/IP and TLS termination offloaded via AT commands.

An embedded MQTT subscriber (Eclipse Paho) within the Java Spring Boot back end consumes and forwards messages to partitions of Apache Kafka topics defined by device id for parallel processing of downstream processes. All configuration management, user authentication (OAuth2 / JWT), geofence management, and historical data retrieval will use REST over HTTPS.

Microservices architecture backs backend; multiple services are loosely coupled: ingestion consists of a service that consumes telemetry streams from Kafka, stores them in TimescaleDB.

Geofence evaluates new position updates relative to stored polygon boundaries using PostGIS, alert processes event streams and sends push notifications through Firebase Cloud Messaging.

Reporting service creates trip summaries, estimates fuel usage and assigns driver behaviour scores.

Spring Security with OAuth2 resource server enforces JWT-based authentication across all API endpoints. Redis caches frequently accessed device configurations and live position data for the map dashboard, reducing database read load under concurrent user sessions.

The entire backend stack is containerized with Docker and orchestrated on Kubernetes (AWS EKS), with Horizontal Pod Autoscaling configured on the ingestion and alert services.

The React Native App utilizes TypeScript and Redux ToolKit to provide predictable state management. Real-time updates for live tracking of vehicles are accomplished with web sockets from the Spring Boot Back-end (Spring WebFlux reactive endpoint).

Users can also create Geofences by drawing shapes on the map while editing them in real-time.

A hi-tech dashboard providing a weekly score for a driver's behaviour based on the frequency of harsh braking, speeding and idleness, presented using Victory Native charts. It also provides notification alerts about breaches of the geo-fence and aggressive driving with one touch access into the detail of that event.

Testing included CAN bus simulation using Vector CANalyzer to validate PID decoding accuracy, GPS accuracy benchmarking against reference coordinates, load testing with Gatling simulating 2,000 concurrent vehicle streams into Kafka, and React Native UI testing with Detox.

Key Challenges:

• CAN bus message filtering required careful DBC file mapping per vehicle make/model, handled through a cloud-side DBC library configurable per fleet.
• Cellular reconnection during high-speed highway travel demanded aggressive retry logic with session persistence.

Scalability:

Kafka provides an ingestion pipeline that can be easily scaled by adding consumer instances (i.e. horizontally). Retention of multi-year telemetry in TimescaleDB is managed efficiently by partitioning hypertables through the use of Kafka brokers and Kubernetes node groups, making it simple to expand up to 100,000+ active devices without needing to change firmware.

The VTT prototype proves that the NXP S32K344 automotive MCU combined with React Native and a Java Spring Boot microservices backend can provide a strong, standards-compliant telematics platform.

The design and engineering decisions made for CAN FD integration, cellular resiliency, automotive power design, and cloud-scale data ingestion support the prototype to serve as the commercially viable base for fleet management, UBI insurance, and logistics monitoring applications.