Vehicle-to-Everything development kits — one moving node, one stationary node.
Vehicle-to-Everything (V2X) needs two participants: something moving and something stationary. Ambimat Electronics, an embedded design and manufacturing house in Ahmedabad, India, makes a development kit for each, both built on a direct 5.9 GHz Cellular Vehicle-to-Everything (C-V2X) PC5 radio — an On-Board Unit (OBU) development kit for the vehicle node, AmbiOBU, and a Roadside Unit (RSU) development kit for the roadside node, AmbiRSU — plus AmbiSEC, the security development setup that gives both of them a hardware root of trust.
AmbiOBU and AmbiRSU are mature, production-ready V2X development platforms available to order from Ambimat — supplied for algorithm development, integration, testing and demonstration, and manufacturable in quantity. No programme partner and no custom-engineering commission is required first. Production ready describes that maturity and orderability rather than environmental qualification, which is not claimed for the standard configurations unless explicitly stated, and neither platform is homologated or type-approved as a vehicle or roadside unit. Where a programme needs a deployment-specific qualified design, Ambimat can act as its IDH partner. Contact Ambimat for configuration, lead time and pricing. Choose your development setup →
One setup moves, one does not, and one secures both.
AmbiOBU and AmbiRSU are mature, production-ready V2X development platforms available to order from Ambimat. You cannot develop V2X against a single node, though — the interesting behaviour, range, latency, message handling and every trust decision, only appears when two participants exchange signed messages across a real radio link.
OBU development kit — AmbiOBU
The moving participant. Runnable in a 1:10-scale movable test vehicle so the mobile node genuinely moves rather than being simulated. GNSS, IMU, 4G LTE and the AmbiSEC secure element for signed V2X messages, on a hardware baseline validated on Indian roads.
RSU development kit — AmbiRSU
The stationary participant. Fixed position, known location, signing the infrastructure messages vehicles act on. Tamper detection, secure boot and the same secure element, developed against the OBU kit.
Security development setup — AmbiSEC
The trust layer inside both. A hardware-protected security module, based on an NXP Secure Element, for keys, credential storage and message signing — so a receiving node can establish that a message came from an authorised participant and arrived unaltered. In production.
These three are the development setups Ambimat offers today. AmbiOBU and AmbiRSU are mature, production-ready V2X development platforms available to order from Ambimat. They are supplied for algorithm development, integration, testing, research and demonstration. No programme partner, deployment or custom-engineering commission is required first — you can order the standard platforms and start. AmbiSEC is in production as a secure-element module.
Production ready describes maturity, manufacturability and orderability — it is not a claim of environmental qualification. Environmental qualification of the standard configurations for extreme temperature, high humidity, ingress, vibration, shock, vehicle-specific installation or outdoor roadside installation is not claimed unless explicitly stated, and no operating-temperature range or ingress rating is published for either. Homologation and certification for installation in a production vehicle, or for a permanent roadside deployment, remain specific to the final integrated product and its target programme. Where a programme needs a deployment-specific qualified design, Ambimat can act as its IDH partner →
The full line, and its programme status stated plainly.
AmbiOBU
Mobile sensing and V2X on-board unit. Production-ready development platform — available to order.
AmbiRSU
V2X roadside sensing unit. Production-ready development platform — available to order.
AmbiSEC
IoT and V2X security co-processor module. Shipping.
AmbiOTA
Secure over-the-air update engine — the software-lifecycle architecture behind signed field update. Not currently offered as a development setup.
Datasheets for the two development platforms, describing each development configuration and what is not claimed for it: AmbiOBU datasheet (PDF) · AmbiRSU datasheet (PDF).
Three development setups you can start with today.
AmbiSEC is in production, and is available as the security development setup. AmbiSecure has been shipping secure identity hardware since 2017.
AmbiOTA is not currently offered as a development setup. The secure over-the-air update architecture it describes remains part of how we engineer the software lifecycle on a V2X programme, and the page stays as technical reference — but it is not something you can take up today.
AmbiOBU and AmbiRSU are available to order from Ambimat. They are complete on-board-unit and roadside-unit development endpoints rather than bare radio evaluation boards: compute, positioning, direct 5.9 GHz C-V2X PC5 communication, a separate 4G LTE backhaul path, the secure-element layer and a documented ROS 2 development environment, in one node you can run your own applications and algorithms on. The vehicle-side hardware baseline is not new: it derives from a deployed and publicly specified vehicle-tracking platform.
Either platform can then become the engineering baseline for a customer-specific production OBU or RSU. That step is optional Ambimat custom engineering — the design and manufacturing and the security integration engagements — and it is a separate decision taken after, not before, you have the platform in your hands. Discuss a custom configuration.
Choose your development setup.
These are recommended setups, not boxed catalogue SKUs. Each is a standard, production-ready configuration you can order as it is; outdoor, vehicle-installed and environmentally qualified configurations are the last row, and they are separately scoped engineering and validation work rather than a qualification the standard configuration already carries. Every order is quoted to the configuration you ask for, so tell us which row you are aiming at and we will price that.
| What you are developing | Recommended setup | Why |
|---|---|---|
| Single-node application and integration development | One AmbiOBU | Bring up your own application in the ROS 2 environment, work against the V2X transmit and receive interfaces, integrate your own sensing or backend, and exercise the GNSS, inertial and LTE paths. A single node cannot show you a link, but it is enough to build against |
| V2V algorithm development and testing | Two AmbiOBUs | Vehicle-to-vehicle needs two moving participants. Two on-board units give you a real 5.9 GHz C-V2X PC5 link between them, with your own algorithms deciding what is sent, what is trusted and what is acted on at both ends |
| V2I algorithm development and testing | One AmbiOBU and one AmbiRSU | Vehicle-to-infrastructure needs a moving node and a fixed one. The roadside unit is the stationary endpoint with a known position that signs the infrastructure messages the vehicle acts on |
| Multi-participant and fleet-scale experiments | Additional AmbiOBU and AmbiRSU nodes | Channel behaviour, congestion control, relative geometry and misbehaviour scenarios only become interesting with more than two participants. Node counts are quoted per request |
| A customer-specific product | A configuration developed with Ambimat | Vehicle-bus interfaces, a different enclosure or power input, a defined operating-temperature or ingress requirement, a sensor payload, or a production build. This is optional custom engineering on top of the standard platform, not a precondition for buying one |
You can run and test your own algorithms on either platform. Both run Ubuntu 22.04 LTS with ROS 2 Humble Hawksbill and the AmbiV2X Developer Stack, with C++ and Python development against documented interface packages, worked V2V and V2I examples, and logging, recording and replay. The standards-level V2X profile is kept separate from the application environment so a programme can define the 3GPP, IEEE 1609.x and SAE J2735 profile it needs.
How to request a quotation. Email Ambimat with the setup you want, how many nodes, and what you intend to develop. Enquiries go to the V2X engineering team directly — there is no reseller in between, and no online checkout. Price, lead time and delivery terms are quoted per enquiry and are not published here.
Which existing Ambimat capability feeds which product.
| Ambimat capability | AmbiOBU | AmbiRSU | AmbiSEC | AmbiOTA |
|---|---|---|---|---|
| Embedded hardware design — PCB, MCU, power | ✓ | ✓ | ✓ | — |
| AmbiLogistics vehicle platform heritage | ✓ | — | — | — |
| AmbiSecure secure-element integration (based on NXP Secure Elements) | ✓ | ✓ | ✓ | ✓ |
| 4G / LTE / cellular radio design | ✓ | ✓ | — | — |
| GPS / GNSS integration | ✓ | — | — | — |
| Multi-sensor hardware integration | ✓ | ✓ | — | — |
| JavaCard applet development | — | — | ✓ | — |
| Secure bootloader and firmware | ✓ | ✓ | ✓ | ✓ |
| OTA update pipeline | ✓ | ✓ | ✓ | ✓ |
| PKI-signed V2X messages | ✓ | ✓ | — | — |
| Device-bound identity in the secure element | ✓ | ✓ | ✓ | — |
| Certification support — FCC, CE, MTCTE | ✓ | ✓ | ✓ | ✓ |
Where these capabilities are evidenced. Each row is an existing Ambimat discipline rather than a V2X deployment. The vehicle-platform row is backed by the published AmbiLogistics specification; the secure-element and applet rows by the AmbiSecure business unit; and the GNSS, antenna, secure-element-kit and FCC rows by dated entries in the company's published milestone record. The record, assembled and sourced →
A tick means the discipline exists and is applied to that platform. It is not a statement that the platform is finished, certified or deployed — the programme status above governs that, and it is the stricter of the two.
Need a deployment-specific production design?
The standard AmbiOBU and AmbiRSU are production-ready development platforms, available to order exactly as they are, and manufacturable in quantity. Where a programme instead needs automotive, roadside, outdoor or other environment-specific qualification, Ambimat Technologies Pvt Ltd can act as your IDH — independent design house — partner, and adapt or develop the V2X hardware around that programme's electrical, mechanical, RF, environmental, security and integration requirements.
Requirements are captured first. The qualification scope, and the evidence that closes it, are agreed and validated as part of that programme rather than assumed from the standard configuration or promised in advance. It is a separately scoped engineering engagement, and it is not a prerequisite for buying anything — the standard platforms can be ordered directly, with no IDH engagement, no programme partnership and no custom-engineering commission first.
Where this fits.
Hardware root of trust
The threat model every product on this page exists to answer.
India regulation
The AIS-230 requirements these platforms are designed against.
AmbiV2X Developer Stack
The ROS 2 V2X development environment both units run, and what a research programme receives with them.
Suppliers and ecosystem
Where Ambimat sits in the wider supply chain, and where it does not.
V2X use cases
What these platforms are built to participate in — public roads, private industrial sites and automated fleets each ask something different of an endpoint.
Questions this page answers.
What is a Vehicle-to-Everything development kit?
Hardware you can develop and demonstrate V2X on before committing to a vehicle programme. Because V2X is communication between two participants, a useful development setup needs both: something moving and something stationary. Ambimat has an On-Board Unit development kit for the vehicle side and a Roadside Unit development kit for the roadside side.
What is the difference between an On-Board Unit and a Roadside Unit?
An On-Board Unit (OBU) is fitted in the vehicle and moves with it. A Roadside Unit (RSU) is mounted beside or above the road — on a pole, gantry or signal head — and stays put. Two On-Board Units talking to each other is Vehicle-to-Vehicle (V2V) communication; an On-Board Unit talking to a Roadside Unit is Vehicle-to-Infrastructure (V2I) communication.
Do I need both kits to develop V2X?
Not always, but usually. A single node can be bench-tested, though the behaviour that matters — range, message handling, and every trust decision a receiver makes — only appears when two participants exchange signed messages over a real radio link. If you are working purely on Vehicle-to-Vehicle scenarios, two On-Board Units will do; for Vehicle-to-Infrastructure you need one of each.
Can I buy these development kits?
Yes. AmbiOBU and AmbiRSU are mature, production-ready V2X development platforms available to order from Ambimat, and AmbiSEC is in production as a secure-element module. No programme partner and no custom-engineering commission is required first, and there is no public price list — configuration, price and lead time are quoted per enquiry. They are not certified and not homologated as production vehicle or roadside units. Choose a development setup.
Which of these are actually shipping?
Three are available as development setups today: AmbiOBU for the vehicle side, AmbiRSU for the roadside side, and AmbiSEC for the security and secure-element layer. AmbiOTA is technology reference on this site and is not currently offered as a development setup. The status of each is stated plainly on this page rather than left to be inferred.
What setup do I need for V2V, and what for V2I?
For V2V, two AmbiOBUs: vehicle-to-vehicle needs two moving participants exchanging signed messages over a real 5.9 GHz C-V2X PC5 link. For V2I, one AmbiOBU and one AmbiRSU: vehicle-to-infrastructure needs a moving node and a fixed roadside node with a known position. One AmbiOBU on its own supports single-node application and integration development. Additional nodes support multi-participant experiments. These are recommended setups rather than boxed catalogue SKUs, and each order is quoted to the configuration requested. The setup table.
Can I run and test my own algorithms on these platforms?
Yes — that is what they are for. Both run Ubuntu 22.04 LTS with ROS 2 Humble Hawksbill and the AmbiV2X Developer Stack: C++ and Python development against documented interface packages, V2X transmit and receive interfaces, worked V2V and V2I examples, and logging, diagnostic, recording and replay examples. The standards-level V2X profile is kept separate from the application environment so each programme can define the 3GPP, IEEE 1609.x and SAE J2735 profile it needs.
Last updated 2026-10-01 · Technical reference maintained by Ambimat Electronics, Ahmedabad, India. Corrections: v2x@ambimat.com