Embedded product-boundary experiment
A vehicle-data source prototype
A vehicle-data prototype spanning API, user surfaces, embedded source, and a Rust signal-normalisation core. The implemented record supports trace and fixture work; vehicle, hardware, and fleet validation remain outside it.
Business ↔ technology bridge · Embedded product-boundary experiment
Explores the boundary from vehicle acquisition and canonical signals to operator-facing product decisions.
This is a portfolio and source interpretation—not a customer, deployment, certification, or outcome claim.
Vehicle telemetry is only useful when acquisition, signal semantics, connectivity, diagnostics, user experience, and operational responsibility form one product boundary.
Separate embedded acquisition, canonical signal mapping, application APIs, and user surfaces before adding assistant or predictive behaviour.
Embedded source, API and user surfaces, a Rust normalisation core, and a trace-replay fixture for DBC, CAN, and canonical mapping.
Signal quality, offline behaviour, update safety, hardware limits, and user validation return to feature scope, architecture, support, and release criteria.
Source evidence
A vehicle-data prototype spanning API, user surfaces, embedded source, and a Rust signal-normalisation core. The implemented record supports trace and fixture work; vehicle, hardware, and fleet validation remain outside it.
Repository evidence is not client, deployment, certification, or outcome evidence.
Architecture
Three source boundaries: embedded acquisition, canonical signal mapping and APIs, and user-facing telemetry and assistant surfaces.
Source map only: a layer can represent implemented code, an adapter boundary, or documented design. It does not assert a configured production service.
Embedded source represents OBD-II/CAN acquisition, selected signals, motion inputs, buffering, and update boundaries. No production hardware or vehicle validation is asserted.
Mobile, web, streaming, and ingest surfaces are represented in source. Their end-to-end latency, reliability, and field usability require validation with target hardware and networks.
The source represents a Mistral-grounded assistant for plain-language explanation of raw CAN data: trip summaries, driving-behaviour scoring, and predictive-maintenance and anomaly hypotheses. Its outputs require separate data-quality and operational validation.
The Problem
Why vehicle data is untapped
Modern vehicles generate rich OBD-II data, but drivers and fleet managers have no accessible tool to interpret it.
Separate apps for diagnostics, trip tracking, fuel economy, and safety scoring. No unified intelligence layer.
Breakdowns happen before problems are detected. No predictive alerts, no health scoring, no trend analysis.
Can't ask your car questions. No natural-language interface to understand driving patterns or vehicle health.
Features
Source surfaces from raw OBD-II data to user-facing telemetry
Source scope only: an entry can describe implemented code, a documented adapter, or a configured workflow. It is not a statement that a production service is active.
01
The source represents selected OBD-II PIDs and modes (current data, freeze frame, DTCs, VIN), GPS via NMEA, IMU input, and WebSocket + SSE streaming. Coverage and rates are not validated.
02
The source represents automatic start/end detection, route recording, trip statistics, replay, and trip history with cost analysis. None is validated on vehicles.
03
The source models a safety score from driving events such as hard braking, rapid acceleration, sharp cornering, and impact, with sub-scores for smoothness, speed, and eco-driving. Thresholds are not validated on vehicles.
04
The source represents DTC read/clear, freeze-frame analysis, and a vehicle health score. Predictive-maintenance outputs require separate validation.
05
The source represents an assistant for natural-language questions about vehicle data, using a large language model with streaming SSE responses. Its outputs require separate validation.
06
Embedded source targets an ESP32-S3 (dual-core 240MHz) with CAN/TWAI, u-blox GPS, an MPU6050 IMU, WiFi 802.11 b/g/n, and BLE GATT. Fuel types (petrol, diesel, hybrid, PHEV, BEV, hydrogen) and OTA A/B rollback are modelled in source. No hardware or vehicle validation is asserted.
What the source models
The reviewed code models selected OBD-II/CAN signals and a canonical mapping layer. Availability, rate, units, and meaning vary by vehicle and require fixture, bench, and vehicle validation.
Repository surface only: availability, completeness, performance, and operational fitness require separate validation.
PID 0DRepresents vehicle-speed input for trip, threshold, and geofence logic. Rate and accuracy are not asserted across vehicles.
PID 0CRepresents engine-speed input as an engine-load proxy, with baseline-drift hypotheses for misfire, lambda drift, and transmission wear. It is not a validated leading indicator.
PID 11Represents throttle-position input (%) for aggression scoring, behaviour coaching, and harsh-acceleration event logic with RPM and speed. It is not validated on vehicles.
PID 05Represents coolant-temperature input and anomaly hypotheses. It is not an early-warning guarantee or diagnostic conclusion.
PID 0FRepresents the air-density input to the ECU's fuel calculation. Diagnostic uses such as power-loss analysis or checking cold-air-intake claims require vehicle-specific validation.
PID 0BRepresents manifold-pressure input as an engine-load measurement (NA + turbo). Boost-curve, load-vs-RPM, and tow-vehicle stress views are design scope, not validated analysis.
PID 2FRepresents tank-level input (%) for refuel detection, sudden-drop theft alerts, and per-trip MPG logic against distance from speed integration. Rate and accuracy are not asserted.
PID 14Represents air-fuel-ratio input. Long-term drift is a hypothesis for catalytic-converter degradation, lambda-sensor ageing, or unauthorised fuel-system modification, not a diagnostic conclusion.
MODE 03Represents diagnostic-code ingestion and plain-language explanation workflows. Supported modules and suggested causes require vehicle-specific and expert validation.
ONBOARDRepresents ESP32-side IMU input for harsh-braking, sharp-cornering, collision, and road-roughness event logic, independent of CAN data. Detection and use on non-OBD vehicles are not validated.
GNSSRepresents GPS and cellular position inputs for user-defined zones (home, depot, customer site), entry/exit alerts, and offline buffering. Field behaviour is not validated.
OTARepresents firmware-version, staged-update, and rollback design surfaces. No signed production release or device-fleet update record is asserted.
Tech Stack
Named technologies identify repository dependencies or adapter surfaces; they do not assert a live integration or deployment.
Source Code
The Vectis AI source prototype — backend, frontend, mobile app, and firmware — is available upon request.
To access the source code, please sign the Non-Disclosure Agreement. This is a standard legal formality.
Need strategic AI guidance for your fleet or IoT platform? My consulting services can help.
Partnership
If you are a fleet operator, automotive OEM or IoT partner exploring AI for vehicle data, contact me to discuss the decision.
From demo to dependable operation. Subscribe for new Physical AI reading.
Unsubscribe anytime. No spam, ever.