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.
Source prototype with software and firmware boundaries
Source through 2026-04-20
Inspectable artefacts
Explicit claim boundary
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.
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
From raw OBD-II data to actionable intelligence
Source scope only: a card can describe implemented code, a documented adapter, or a configured workflow. It is not a statement that a production service is active.
60+ OBD-II PIDs across 6 OBD-II modes (current data, freeze frame, DTCs, VIN), GPS via NMEA, and 6-axis IMU at 100Hz — all streaming via dual WebSocket + SSE architecture.
Auto start/end detection, route recording, trip stats, and replay. Full trip history with cost analysis.
0-100 safety score from 5 event types: hard braking (0.45g threshold), rapid acceleration (0.40g), sharp cornering (0.35g), and impact detection (2.5g). Sub-scores for smoothness, speed, eco-driving, and more.
DTC read/clear, freeze frame analysis, vehicle health score, and predictive maintenance alerts.
Ask natural-language questions about your vehicle data. Powered by a large language model with streaming SSE responses.
ESP32-S3 (dual-core 240MHz) with CAN/TWAI, u-blox GPS, MPU6050 6-axis IMU, WiFi 802.11 b/g/n, and BLE GATT. Supports all fuel types: gasoline, diesel, hybrid, PHEV, BEV, hydrogen. OTA A/B rollback.
Tech Stack
Named technologies identify repository dependencies or adapter surfaces; they do not assert a live integration or deployment.
Fastify, TypeScript, Prisma, PostgreSQL + TimescaleDB, Redis
LLM API, streaming SSE, natural-language vehicle queries
Next.js 14, Tailwind CSS, shadcn/ui, real-time data visualization
React Native, Expo, NativeWind, BLE pairing, Detox E2E tests
ESP32-S3, ESP-IDF 5.x, FreeRTOS, CAN/TWAI, ISO-TP, GPS NMEA, MPU6050
Docker, GitHub Actions CI, Vitest, JWT auth, Swagger API docs
Source Code
The Vectis AI platform — backend, frontend, mobile app, and firmware — is available upon request.
To access the source code, please sign our Non-Disclosure Agreement. This is a standard legal formality.
Need strategic AI guidance for your fleet or IoT platform? Our consulting services can help.
Partnership
Whether you're a fleet operator, automotive OEM, or IoT partner looking to bring AI to vehicle data.
Most AI pilots stall before production. Get the playbook for the ones that ship.
Unsubscribe anytime. No spam, ever.
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.
Mistral-grounded assistant interprets raw CAN data in plain English: predictive maintenance, anomaly detection, trip summaries, driving-behaviour scoring. The translation layer between sensor noise and an operations decision.
What Vectis sees
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 0CEngine load proxy. Predictive-maintenance models flag drift from the per-vehicle RPM baseline as a leading indicator for misfire, lambda drift, transmission wear.
PID 11% throttle. Combined with RPM + Speed for aggression scoring, behaviour coaching, and harsh-acceleration event detection.
PID 05Represents coolant-temperature input and anomaly hypotheses. It is not an early-warning guarantee or diagnostic conclusion.
PID 0FAir-density input to the ECU's fuel calculation. Useful for diagnosing power loss complaints and validating modifications like cold-air-intake performance claims.
PID 0BEngine load measurement (NA + turbo). Boost-curve visualisation for turbo cars; load-vs-RPM heatmap for tuning analysis and tow-vehicle stress logging.
PID 2FTank % at 0.5 Hz. Drives refuel detection, theft alerts (sudden drop), and per-trip MPG calculation cross-referenced with distance from speed integration.
PID 14Air-fuel ratio. Long-term drift flags catalytic converter degradation, lambda sensor aging, and unauthorised fuel-system modifications.
MODE 03Represents diagnostic-code ingestion and plain-language explanation workflows. Supported modules and suggested causes require vehicle-specific and expert validation.
ONBOARDESP32-side 9-axis IMU. Detects harsh braking, sharp cornering, collision events, road-surface roughness. Independent of CAN data so it works on older non-OBD vehicles too.
GNSSGPS + cellular fusion. User-defined zones (home, depot, customer site) fire alerts on entry/exit. 72 h offline buffer when cell coverage drops.
OTARepresents firmware-version, staged-update, and rollback design surfaces. No signed production release or device-fleet update record is asserted.