One software product across every device on the vehicle. Change a supplier by writing a driver.
A hardware-agnostic on-board stack — runtime, abstraction layer, drivers, over-the-air update and security — written in India and delivered as signed binaries, so that replacing a component is a purchasing decision rather than an engineering project.
Every device arrives with its own idea of how a vehicle works.
Each unit comes with its own firmware, its own protocol and its own supplier dependency. Integration happens per project, and every change of supplier starts it again.
Integration is per project
The display, the camera, the validator and the GNSS unit are integrated separately, against four different interfaces, and the result is specific to that combination of parts.
A supplier change is a project
Substituting one component means revisiting the integration, re-testing the package, and frequently going back through approval.
The dependency compounds
Every project-specific integration is a thing that has to be maintained, and the number of them grows with the number of variants in the fleet.
The same four problems, with an abstraction layer under them.
| Today | With the unified stack |
|---|---|
| Each device supplier dictates its own protocol and firmware behaviour | One abstraction layer; suppliers are swapped by writing a driver, not by re-integrating the vehicle |
| Component substitution means re-testing the whole package and often re-approval | Component substitution is a driver-level change, validated against the existing test suite |
| Field firmware updates need physical access or supplier-specific tooling | A single signed FOTA channel across every device in the vehicle |
| Diagnostics are per-device and largely reactive | One vehicle-level health model; remote diagnosis before dispatching an engineer |
Eleven parts, one product.
Hardware abstraction layer
A defined internal interface per device class — display, camera, GNSS, audio, digital I/O, CAN, storage — so application logic is written once and survives a change of supplier.
Core runtime
Linux or Android-based, with secure boot, service supervision, a watchdog, and controlled recovery on fault.
Offline resilience
Store-and-forward buffering of telemetry, events and video metadata, with defined retention and replay ordering on reconnection.
Configuration engine
Signed configuration profiles by model variant, customer and route — version-controlled, with rollback.
FOTA
Staged, signed, resumable over-the-air update of runtime, drivers and device firmware, with automatic rollback on failure.
Local application services
PIS rendering, announcement scheduling and playback, panic handling, camera event triggering — and the rules that must keep running without a network.
Vehicle bus interface
SAE J1939 / FMS CAN and OBD-II; proprietary CAN databases under NDA; EV battery, charging and energy telemetry, with ISO 15118 where the vehicle exposes it.
Diagnostics and telemetry
Device health, fault codes, storage and thermal state, and connectivity quality — reported to the platform and available locally.
Security
Secure boot, signed images, per-device identity and certificates, encrypted storage and secure factory provisioning; built to the AIS-140 requirements that fall on the OBU software layer. This is the layer that hosts ShieldSync.
Assembly-line provisioning
Interfaces for device pairing to VIN, configuration push and self-test, designed to run as a station on the line.
Documentation and SDK
HAL specification, driver development kit, test harness, integration guide and reference implementations — so writing that driver is a documented job.
Made in India.
What stays with the hardware vendor.
The rest of the vehicle layer.
OBU to Cloud
Ingestion, unification, statutory push and device lifecycle — for any OBU from any vendor.
ShieldSync
Endpoint protection running inside the on-board unit, hosted by this stack's security layer.
In-Vehicle ITS
What the local application services actually drive — displays, announcements, video and SOS.
Tenders & Procurement
Local content, eligibility documents and the scope we bid on ITMS and AFCS packages.
Give us the device list.
Tell us what is fitted, or what you are specifying, and we will say which parts of it the stack already has a driver for.