Any OBU, any vendor. One data model, one set of rules.
Position, CAN and battery frames, camera events, sensor readings and button presses arrive from whatever is fitted to the vehicle. RouteSync authenticates them, resolves them into one structure, reconciles the gaps, and pushes the statutory record to the state — without asking you to change the hardware.
Eleven stages between the sensor and the screen.
Nothing here is specific to a make of device. The same eleven stages run whether the unit on the vehicle is ours, yours or a closed import.
- SensingDevices produce data — position, CAN and BMS frames, camera events, sensor readings, button presses.
- AcquisitionThe OBU reads connected devices over CAN, OBD-II, serial, GPIO or IP, applies local rules, and buffers when the network is unavailable.
- TransportEncrypted transmission to platform endpoints, with store-and-forward replay of buffered records on reconnection.
- IngestionDevice authentication, message validation, rate handling and acknowledgement at the platform boundary.
- NormalisationProtocol and payload mapping into a common data model, so data from any device, vendor, make or model resolves to one structure.
- ReconciliationOrdering of delayed and buffered records, de-duplication, gap detection, and trip reconstruction across connectivity losses.
- ProcessingTrip building, geofencing, alert and exception rules, driver scoring, energy and range analytics.
- Storage & retentionEncrypted at rest and in transit, with defined retention per data class, resident per the deployment's jurisdiction.
- PresentationControl room console, dashboards, reports, mobile applications and documented APIs.
- Statutory pushAIS-140 formatted push to the state VLTD backend, and panic routing to 112 / ERSS.
- Device managementInventory, serial-to-VIN binding, heartbeat and health, and read-only reporting of firmware and configuration state as the device declares it.
The vendor decides its protocol. We decide what it becomes.
Normalisation is source-agnostic, protocol-agnostic and hardware-agnostic. That is the whole argument for putting a platform above the device layer rather than beside it.
A documented interface
Where the vendor publishes its protocol, we consume it directly. Nothing is reverse-engineered, and nothing depends on a behaviour the vendor has not committed to.
An undocumented one
Where it is not published, we obtain the specification from the vendor and map it at onboarding. The mapping is part of the deployment, not a change request afterwards.
One structure at the end
Two devices from two suppliers reporting the same event produce the same record. Reports, rules and dashboards are written once, against the model rather than the make.
Mixed fleets are the normal case
A fleet accumulated over ten procurement cycles has a dozen device types in it. That is the condition the model is designed for, not an exception to it.
Replacing a device
Swapping a supplier changes the mapping at the boundary. It does not change the trip record, the historical series or anything built on top of them.
What is not normalised away
The raw frame is retained alongside the resolved record, so a disputed event can be traced back to what the device actually sent.
The record the state requires, in the format it requires.
AIS-140 push
The statutory record is formatted and pushed to the state VLTD backend from the platform, on the schedule and in the structure the backend expects.
Panic to 112 / ERSS
A panic press is routed to the emergency response system as well as to your own control room, so the statutory path and the operational path are not the same single point of failure.
Per-state onboarding
Each state backend is onboarded separately, with its own certification testing. We treat that as a defined piece of work per state rather than a switch that is either on or off.
Knowing which unit is in which bus, and whether it is still talking.
Stage eleven of the data path, expanded. A fleet's device estate is an asset register that moves, and it goes wrong quietly.
Inventory
Every unit on the estate, by type, model variant, batch and current state — in stock, fitted, faulty, returned or retired.
Serial-to-VIN binding
A device is bound to the vehicle it is fitted to. Moving a unit between buses is a recorded event, not a silent one, so history follows the right vehicle.
Heartbeat and health
Last contact, reporting rate, storage and thermal state, and connectivity quality per unit — so a silent device is a finding rather than a gap someone notices weeks later.
Firmware and configuration state
Read-only reporting of what firmware and configuration the device declares it is running. We report what it says; where the firmware is the vendor's, we do not change it.
A unit that works on the line, not one that is discovered on the road.
These are platform capabilities. The work happens on your assembly line or at your fitment centre, against interfaces the platform exposes.
Zero-touch provisioning
The device is pre-registered against its VIN before it is fitted, so it is recognised and live on its first report rather than needing a manual registration step afterwards.
Reference configuration profiles
A version-controlled configuration per model variant. A unit that comes up carrying something other than its profile is flagged as a deviation rather than quietly accepted.
End-of-line verification
A defined pass/fail check before the vehicle leaves the line, with the evidence retained against the VIN.
Line-side quality reporting
First-pass yield and a failure Pareto by device type, so a batch problem is visible while the batch is still being fitted.
The warranty clock starts when the device is commissioned, not when it is dispatched.
The gap between those two dates is months of warranty on a shelf, and on a large fitment it is the difference between a covered failure and an argued one.
Asset registry
Serial to VIN, with the fitment date, the batch and the supplier — the record every warranty conversation starts from.
Warranty terms per component
Separate terms per component category, because a camera, a modem and a display do not carry the same cover and should not be tracked as though they do.
RMA workflow
Raised, shipped, received, diagnosed, replaced, returned — with the evidence attached at each stage rather than reconstructed at the end.
SLA engine
Response and restoration commitments tracked per contract, with an alert when a case is heading for a breach rather than a report after it.
Spares and reverse logistics
Stock position, units in transit and units at the vendor, so a spare shortfall is visible before it grounds a vehicle.
AMC renewal pipeline
What falls out of cover, and when, by fleet and by component category — far enough ahead to do something about it.
MTBF and MTTR
Reliability and restoration time measured from the RMA record, by device type and by batch, rather than asserted by the supplier.
Failure Pareto
Which device types and which batches are producing the failures. Usually a small number of both, which is what makes the analysis worth doing.
Evidence, not recollection
Commissioning record, health history and RMA trail sit against the same asset, so a warranty claim is supported by what the platform already holds.
Where this stops.
The rest of the vehicle layer.
OBU Software Stack
The on-board layer itself — abstraction, runtime, drivers, FOTA and security — where RouteSync supplies it.
ShieldSync
Endpoint protection running inside the on-board unit, monitored from a cloud console.
In-Vehicle ITS
Displays, announcements, video, driver assistance and emergency response on the vehicle.
Integrations
The standards and systems RouteSync speaks, including the Indian statutory set.
Developers
Authentication, tenant addressing, the API families and the feeds — the integration surface itself.
Bring us the device you are already fitting.
Tell us the make and model on the vehicle and we will tell you what is documented, what is not, and what that means for scope — before anything is bought.