Source prototype with software and firmware boundaries
A signal interpretation trace
Input
Authorised CAN trace and DBC definition
Meaning
Normalised signal and unit
Consumer
An API and operator workflow
Validation
Trace fixtures; vehicle evidence still needed
Decision logic and control flow
Explore the reasoning
Select one signal and the operator decision it should support.
Engage now
A signal-to-workflow map and the evidence needed to evaluate the connected-product boundary.
Inspect
Source prototype with software and firmware boundaries
Backend unit and integration tests for the application and telemetry boundaries.
Still to validate
Advanced multiplexing and firmware C code generation remain incomplete; build targets do not establish deployed Node, mobile or browser integrations.
Complete hardware-in-the-loop, vehicle-in-the-loop, field-fleet, update-safety, data-quality, and operational validation.
Source reviewed
The decision behind the system
How does a vehicle signal become a useful product?
A vehicle-data prototype connecting embedded acquisition, CAN/DBC signal normalisation, APIs and user-facing telemetry workflows.
Vectis explores the signal-to-product boundary for connected vehicles. Its job differs from cross-machine coordination or learned robot behaviour.
Signals with meaning
The Rust UVAL core parses DBC, decodes CAN frames and maps VSS identifiers into canonical signals. Node and WebAssembly build targets support evaluation.
Connected workflows
API and mobile surfaces explore trips, telemetry, diagnostics, geofencing and assistant interactions.
Software meets firmware
Embedded source and trace-replay fixtures expose acquisition, connectivity and update boundaries for evaluation.
Read the complete system walkthrough
Choose
Select one signal and the operator decision it should support.
Normalise
Replay an authorised trace and follow CAN/DBC interpretation into a canonical signal.
Connect
Inspect how the API and user-facing workflow consume the signal and handle missing information.
Validate
Identify data-quality, connectivity and hardware evidence required before vehicle or fleet use.
Inspect the source, test conditions and operating limits in the technical record.
Explore the technical record and evidence
Business ↔ technology bridge · Embedded product-boundary experiment
Turn raw vehicle signals into a bounded, testable product system.
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.
01
Business pressure
Vehicle telemetry is only useful when acquisition, signal semantics, connectivity, diagnostics, user experience, and operational responsibility form one product boundary.
02
Product decision
Separate embedded acquisition, canonical signal mapping, application APIs, and user surfaces before adding assistant or predictive behaviour.
03
Technical record
Embedded source, API and user surfaces, a Rust normalisation core, and a trace-replay fixture for DBC, CAN, and canonical mapping.
04
Evidence return
Signal quality, offline behaviour, update safety, hardware limits, and user validation return to feature scope, architecture, support, and release criteria.
Repository/runtime boundary
This page interprets source from a separate venture repository. Source presence does not make the venture a service running inside hyperion-consulting.io.
Visitor and client-data AI processing is restricted to Mistral through the governed EU endpoint. Owner-authorized Helio, Search and Product Council paths are enabled. A separate public-source editorial lane uses Anthropic with governed Mistral backup; it receives no website enquiries, client documents or visitor conversations. Deterministic tools remain available when remote AI is unavailable.
Source evidence
What the source actually establishes
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.
Maturity
Source prototype with software and firmware boundaries
Evidence review
Source snapshot through
Architecture and product decisions
Separate device acquisition, canonical signal mapping, APIs, and operator-facing product surfaces.
Normalise DBC/CAN inputs into a canonical signal layer before product logic consumes them.
Treat offline behaviour, update safety, and hardware abstraction as explicit architecture boundaries.
Inspectable evidence
Backend unit and integration tests for the application and telemetry boundaries.
Embedded source with C-level tests for selected firmware logic.
Rust UVAL source for DBC parsing, CAN decoding and VSS mapping, with Node and WebAssembly build targets and a trace-replay integration fixture.
Claim boundary
Advanced multiplexing and firmware C code generation remain incomplete; build targets do not establish deployed Node, mobile or browser integrations.
No hardware-in-the-loop, vehicle-in-the-loop, OEM, safety-certification, or field-fleet record is asserted.
Predictive-maintenance and assistant outputs require separate data-quality and operational validation.
Repository evidence is not client, deployment, certification, or outcome evidence.
Architecture
From OBD-II port to plain-language insights
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.
01
Layer 1 — ESP32 OBD-II Acquisition Source
Embedded source represents OBD-II/CAN acquisition, selected signals, motion inputs, buffering, and update boundaries. No production hardware or vehicle validation is asserted.
02
Layer 2 — Rust UVAL + application surfaces
The Rust UVAL core parses DBC, decodes CAN and maps VSS identifiers into canonical signals. Node and WebAssembly build targets and trace-replay fixtures are present; end-to-end mobile, browser and vehicle behaviour require separate validation.
03
Layer 3 — AI Insight Engine
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.
What the source models
Vehicle-signal paths represented in source
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 0D
Vehicle Speed
01
Represents vehicle-speed input for trip, threshold, and geofence logic. Rate and accuracy are not asserted across vehicles.
PID 0C
Engine RPM
02
Represents 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 11
Throttle Position
03
Represents throttle-position input (%) for aggression scoring, behaviour coaching, and harsh-acceleration event logic with RPM and speed. It is not validated on vehicles.
PID 05
Coolant Temperature
04
Represents coolant-temperature input and anomaly hypotheses. It is not an early-warning guarantee or diagnostic conclusion.
PID 0F
Intake Air Temperature
05
Represents 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 0B
Manifold Pressure
06
Represents 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 2F
Fuel Level
07
Represents 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 14
O₂ Sensor (Lambda)
08
Represents 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 03
ECU Fault Codes (DTCs)
09
Represents diagnostic-code ingestion and plain-language explanation workflows. Supported modules and suggested causes require vehicle-specific and expert validation.
ONBOARD
IMU (Accel + Gyro)
10
Represents 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.
GNSS
Geofence Boundary
11
Represents GPS and cellular position inputs for user-defined zones (home, depot, customer site), entry/exit alerts, and offline buffering. Field behaviour is not validated.
OTA
Firmware Status
12
Represents firmware-version, staged-update, and rollback design surfaces. No signed production release or device-fleet update record is asserted.
Tech Stack
Built With
Named technologies identify repository dependencies or adapter surfaces; they do not assert a live integration or deployment.