Vehicle Diagnostics IoT Prototype Development Using NXP S32K, .NET MAUI

Every mechanic has heard the same story. A driver pulls in with a seized engine or a dead alternator, and the first question asked is always: "Were there any warning signs?" The answer, almost always, is yes, subtle ones.

An initial hesitation during ignition occurred, fuel consumption increased over the previous three months, a battery that had difficulty with cold weather starts.

The data existed at all times, only nobody was present to evaluate it. "The Smart Car Health Doctor" prototype has been specifically designed to bridge the gap between data being present and the ability to create actionable insights from that data.

Not another OBD-II dongle that mirrors dashboard lights onto a phone screen. Something fundamentally different: a device that reads the vehicle's physiology continuously, builds a model of what normal looks like for that specific engine, and flags deviations before they cascade into failures.

This is the engineering story of how that device was built.

Early hardware decisions can have serious downstream effects. One such decision was to pick the NXP S32K344 MCU as the hub for development, this was not a random choice but one made after careful consideration of alternatives.

The choice was based on several factors, but all of these were specific to automotive applications and were not negotiable. Specifically, the S32K344 has an ISO 26262 ASIL-D capable design ecosystem, which is important given that the device will be permanently connected to the electrical system of the host vehicle.

Its six integrated CAN FD controllers eliminate the need for external CAN controller ICs, reducing BOM complexity and potential failure points. The operating temperature range of −40°C to +125°C covers real-world under-dash and OBD port conditions across climates.

And the presence of NXP's EdgeLock SE050 secure element as an optional companion chip opened the door to cryptographically signed diagnostic logs — a feature that becomes commercially significant in insurance and warranty dispute contexts.

While not the lowest cost option available in the market, the S32K344 was selected due to the nature of predictive diagnostics (which require consistent, reliable real-time processing of CAN messages) such that skimping on the MCU would have compromised the entire premise of the product.

The diagnostic "intelligence" is a function of the CAN data that evaluates (interprets) the OBD-II PID of the CAN data; it does not simply measure the availability of the OBD-II PID data. The device uses ISO 15765-4 to poll through 4 groups of OBD-II PID (in greater detail).

Engine Temperature Curve Behavior

Not just the instantaneous coolant temperature value, but the rate-of-rise from cold start. A healthy thermostat and cooling system produce a predictable warm-up profile.

Deviation from that curve, too slow, too fast, or irregular plateauing is an early indicator of thermostat failure or coolant flow restriction, often weeks before the temperature warning lamp activates.

Fuel Trim Analysis

Short-term and long-term fuel trim values (PIDs 0x06 and 0x07) reveal injector health invisibly. A single injector delivering slightly lean or rich mixture shifts trim values in ways the ECU compensates for silently.

The Health Doctor software monitors long term trim drift as it appears in the vehicle. A long term fuel trim value greater than +8% on bank one observed across more than 200 drive cycles is an indication of statistical injector imbalance. It does not guarantee injector failure but does rank the risk of potential failure in front of the driver.

Battery and Charging System Profiling

Control module voltage (PID 0x42) is sampled at engine start, during load application (headlights, HVAC engagement), and at idle. The S32K344 correlates voltage sag magnitude against alternator output behavior patterns.

A reduction of a battery's cold cranking ability has a definite dip in the voltage characteristic at the beginning which then progressively increases over sampling periods; this will not be apparent as a voltage check but rather as a long term analysis across time.

RPM Stability and Misfires

Engine RPM stability at idle, combined with misfire count PIDs where supported by the vehicle ECU, provides early-stage ignition system health indicators. Coil-on-plug degradation manifests as intermittent single-cylinder RPM perturbations long before a misfire DTC is thrown.

The OBD-II module has an external low-profile housing to minimize the risk of conflicts with other components. It measures 62mm long x 38mm wide x 22mm high.

The circuit board was designed using four layers using Altium Designer with careful consideration for two special issues (electromagnetic interference from a vehicle's ignition system and voltage stability for the 12V battery between 9V and 16V depending on whether the battery is being charged).

Power management uses the NXP MC33FS automotive power system basis chip, which handles reverse polarity protection, battery voltage monitoring, and supervised power sequencing for the S32K344, a combination that a discrete protection circuit would require significantly more board area to replicate.

For data uplink, the u-blox SARA-R4 LTE-M/NB-IoT module provides cellular connectivity. This application was built on LTE-M, not standard LTE Cat-1, because the vehicle could be parked for long periods of time with the device in low-power monitoring mode.

PSM (Power Saving Mode) on LTE-M allows the modem to sleep between upload windows without dropping the network registration, so the current draw on the vehicle battery is dramatically reduced.

The NXP EdgeLock SE050 secure element is connected via I2C and handles private key storage and payload signing. Every telemetry bundle uploaded to the cloud carries a cryptographic signature verifiable server-side, a design decision that protects the integrity of diagnostic records in contexts where they may be used as evidence.

The firmware architecture separates concerns across five FreeRTOS tasks managed within NXP's S32K3 RTD (Real-Time Drivers) SDK environment, developed in S32 Design Studio.

The most intellectually interesting task is the Health Model Task, a running statistical engine that maintains exponentially weighted moving averages (EWMA) for each monitored parameter across drive cycles.

Rather than comparing instantaneous readings against fixed manufacturer thresholds (which is what every generic OBD scanner does), this task compares current readings against the vehicle's own established baseline. A coolant temperature that reads 94°C is meaningless without knowing whether this particular engine normally runs at 88°C or 96°C. Context is everything in predictive diagnostics.

Anomaly scores are computed per parameter, normalized to a 0–100 health index, and combined into a weighted composite vehicle health score.

The weights are configurable at the server level and sent down through the cloud configuration endpoint for fleet management companies and/or insurance partners to use to customize their scoring for each of their risk models without needing to perform a firmware update.

All data stored to the device's SPI NOR flash is encrypted with a key management methodology based on the EdgeLock SE050 using AES-128 encryption to keep the data encrypted even if the device has been physically accessed.

Choosing to develop with .NET from front to back, with ASP.NET Core for the back end and .NET MAUI for mobile clients, was based on the team make-up of developers and a strong desire to share code and type definitions between the various layers.

ASP.NET Core is deployed as a collection of modular services behind an NGINX reverse proxy in the Azure cloud for hosting. A device publishes telemetry (in MQTT format) to an Azure IoT Hub acting as an MQTT broker, which is then transmitted to an Azure Service Bus queue for dependable and ordered processing.

A background hosted service (IHostedService) consumes the queue and writes telemetry into Azure SQL with TimescaleDB-style partitioning handled through table partitioning by vehicle ID and timestamp range. SignalR hubs push real-time health score updates to connected MAUI clients.

Using ML.NET, generating "anomaly scores" and "health index" is done on the server side by creating a predictive model based on labeled historical datasets of telemetry patterns prior to failure.

The model runs as a background inference job, updating vehicle health scores after each telemetry batch. This architectural choice keeps inference off the constrained MCU while still enabling near-real-time score delivery.

Azure API Management enforces OAuth2 authentication, rate limiting, and request logging across all client-facing endpoints, providing the security perimeter appropriate for a service handling sensitive vehicle and user data.

The .NET MAUI Application uses a single code base that runs natively on both Android and iOS devices. The app's primary UI metaphor, a health score gauge displayed as an animated arc that resembles a medical vital signs monitor, is intentionally different from the look of conventional OBD apps, which have a data-dump look.

Each monitored system (charging, fuel, thermal, ignition) has its own health card with trend sparklines showing trajectory, not just current state. A "Predicted Attention Window" timeline tells the driver not just that something may be degrading, but roughly when intervention becomes advisable based on current trend velocity.

SignalR client integration provides live health score updates without polling. Offline mode caches the last known vehicle state in SQLite on-device via Entity Framework Core's SQLite provider, a natural fit given the shared .NET ecosystem.

To perform hardware-in-the-loop testing, a Kvaser Memorator CAN logger was used to replay CAN traces collected from various vehicles that had previously been in service and were known to be experiencing some type of fault.

This method allowed for validation of firmware against actual degradation characteristics without having to have a physical test vehicle experiencing a fault at the time of the test.

Backend load testing with NBomber simulated 5,000 concurrent vehicle telemetry streams. ML.NET inference latency was benchmarked at under 40ms per vehicle health score update at that concurrency level, within the acceptable window for near-real-time mobile dashboard updates.

The most challenging engineering problem encountered was CAN bus message filtering across vehicle makes and models.

OBD-II PIDs are standardized, but response timing and message multiplexing behavior vary enough between ECU manufacturers to require per-make polling delay tuning, ultimately managed through a cloud-hosted vehicle profile library queried at device provisioning time.

The prototype described supports individual consumer and SMB fleet use cases. The architecture scales to three commercially distinct directions: an insurance UBI (Usage-Based Insurance) SDK integration path using signed telemetry payloads, a white-label fleet health management platform and an OEM embedded variant where the S32K344 module is integrated directly into the vehicle rather than the OBD port.

Phil, UK

Certified PCB Design & Layout Engineer with 10+ years of experience, IPC-certified expertise in EMC/EMI-compliant, high-speed, mixed-signal PCB design, signal integrity, DFM, and hardware development.