Getting started with AmbiV2X — evaluation setups, dependencies and scope.
To evaluate AmbiV2X, Ambimat's proprietary V2X communication stack, start with one AmbiOBU for your own application, two AmbiOBUs for vehicle-to-vehicle, or an AmbiOBU and an AmbiRSU for vehicle-to-infrastructure. This page sets out what each setup shows, what you provide, what is verified today and how to scope a quotation.
An evaluation answers one question: does AmbiV2X do what your application needs?
AmbiV2X is Ambimat's proprietary V2X communication stack, developed and owned by the Ambimat V2X team. It runs on two development platforms: AmbiOBU, the on-board unit, and AmbiRSU, its roadside counterpart. An evaluation puts those platforms in front of your engineers so they can see AmbiV2X's verified capabilities working with the application, scenario and region they care about.
Three things an evaluation is not, stated first so the plan does not rest on them:
- Not a software download. AmbiV2X is not open source and not a public SDK. Integration documentation, permitted access, licensing and software delivery scope are agreed individually for each customer engagement.
- Not certification. AmbiOBU and AmbiRSU are development platforms. AmbiV2X is not a certified production automotive V2X stack, and nothing in an evaluation is conformance testing, type approval or homologation. How V2X certification actually works →
- Not a field deployment. The standard configurations are development hardware. No operating-temperature range or ingress rating is published for them, and outdoor or in-vehicle installation is separately scoped engineering.
Four starting points, chosen by what you need to see.
These are recommended setups, not boxed SKUs. Each is quoted to the configuration you ask for. The setup table on the products page →
| What you want to evaluate | Setup | What your team sees | What it cannot show |
|---|---|---|---|
| Your own application on the platform | One AmbiOBU | Your application running on the unit beside AmbiV2X and ROS 2 Humble, using GNSS, IMU and LTE backhaul, with V2X messages generated and received in host-based testing | A radio link. One node has nobody to talk to |
| Vehicle-to-vehicle (V2V) | Two AmbiOBUs | Two moving participants, each with its own 5.9 GHz C-V2X PC5 subsystem, and AmbiV2X generating and receiving awareness and hazard-event messages such as CAM and DENM | Over-the-air PC5 operation of AmbiV2X is the next integration step and is not yet claimed; confirm in the quotation what the current evaluation covers |
| Vehicle-to-infrastructure (V2I) | One AmbiOBU and one AmbiRSU | A roadside node at a known position originating signal-phase and intersection messages such as SPATEM and MAPEM, and an example vehicle-side signal-awareness application receiving them | A live traffic-signal controller: signal state comes from a source you provide or a simulated one. Over-the-air status as for V2V |
| Several participants | Additional AmbiOBU and AmbiRSU nodes | Multi-vehicle and roadside scenarios, relative geometry and message load, scoped to the node count quoted | Fleet- or corridor-scale behaviour; that is a deployment programme, not an evaluation |
Where AmbiSEC fits. AmbiSEC is the device-side security component: it holds identity keys inside a hardware security boundary and performs cryptographic operations there. AmbiOBU and AmbiRSU are AmbiSEC-capable, and AmbiSEC is populated when specified in the quoted configuration: add it, and confirm it in the quotation and bill of materials, when your question is about key custody on the device. It is not a certificate authority, it does not issue credentials, and secured (signed) V2X messaging is not claimed for AmbiV2X today.
A moving node that really moves. AmbiOBU can be run on an optional 1:10-scale movable development platform, so relative motion between two nodes is real rather than modelled. A full-scale vehicle is yours to provide; AmbiOBU has no CAN interface, so it does not read vehicle-bus data.
Five levels of evidence, and where AmbiV2X sits on each today.
The commonest way a V2X evaluation goes wrong is treating one kind of evidence as another. Keep them apart.
| Level | What it means | AmbiV2X today |
|---|---|---|
| Standards-defined behaviour | What a published standard says a message or station does. True of the standard, not of any product | Explained across this site as public education, for example on the message sets page |
| Available feature | A capability Ambimat publicly states AmbiV2X has | European development profile: CAM, DENM, SPATEM and MAPEM; CPM partial. US engineering demonstration: the SAE J2735 BSM. The status table → |
| Host-based software testing | Verified in software on a host, without the radio in the path | Where the available features are verified today. Detailed test results are shared, where appropriate, within an engagement |
| Over-the-air PC5 | Messages exchanged between nodes over the 5.9 GHz C-V2X sidelink | The next integration step. Not claimed |
| Interoperability, qualification and certification | Working with other vendors' stations; environmental qualification; conformance certification and type approval | None is claimed or implied. Each is a separate programme with an accredited body or a test event |
The supporting equipment and permissions that are usually yours.
Most delays in a V2X evaluation come from this list rather than from the units. Settle it before the units arrive.
| Item | Why it matters |
|---|---|
| Authorisation to transmit at 5.9 GHz | Radio rules are national. In India, on-board units are licence-exempt in 5875–5905 MHz under G.S.R. 466(E); roadside units and other countries need checking against the local rules. Spectrum, jurisdiction by jurisdiction → |
| A site and its owner's permission | A closed test area, campus or private site where nodes can move and be observed safely |
| Vehicles or a movable platform | For V2V, two moving participants: your vehicles, or the optional 1:10-scale movable platform |
| Power, mounting and antenna placement | GNSS needs open sky; the V2X and LTE antennas need placement you control |
| A SIM and data plan | Only if you use the 4G LTE backhaul for telemetry or data upload. The LTE module is not the V2X radio and does not provide PC5. Two radios, two jobs → |
| A signal-state source, for V2I | Signal phase and timing come from a controller interface you provide or from simulated state |
| Certificates, for security work | Production V2X credentials come from an authorised PKI operator; Ambimat does not operate a Root CA. PKI test environments → |
| Your application, and your ROS 2 graph if you have one | ROS 2 Humble runs beside AmbiV2X on the unit. The AmbiV2X–ROS 2 integration interfaces are on the platform roadmap; no AmbiV2X ROS 2 package ships today |
What is in scope today, and what is not.
- Radio. 5.9 GHz LTE C-V2X PC5 at 3GPP Release 14. NR-V2X (Release 16 and later) is out of the current product scope, and Ambimat does not offer a DSRC or IEEE 802.11p product. LTE-V2X and NR-V2X compared →
- Regions. A European (ETSI) development profile and a US engineering demonstration. An India development configuration exists; it is provisional until AIS-230 is final, which is still a draft. Draft AIS-230 →
- Security. Secured (signed) V2X messaging, certificate lifecycle and PKI integration are not claimed today. AmbiSEC, where it is populated when specified in the quoted configuration, provides device-side key custody.
- ROS 2. Coexists with AmbiV2X on the NVIDIA Jetson Orin Nano Super; the integration interfaces between them are roadmap.
- Hardware. Development configurations. No CAN or lidar in the standard AmbiOBU; AmbiRSU's roadside interfaces are scoped per programme.
Seven things to send, and what comes back in writing.
- The question the evaluation has to answer, in one or two sentences
- The setup you are aiming at — single node, V2V, V2I or several participants — and the node count
- The region and message profile you care about: European, US or India
- Whether your team uses ROS 2, and what your application is written in
- Whether AmbiSEC is required — it is fitted only when the quoted configuration specifies it
- Where you will test, and who holds the authorisation to transmit there
- Your timeline, and who on your side will run the evaluation
The quotation then states, in writing, the hardware configuration, the AmbiV2X software and licence terms, the level of documentation and access, the evaluation scenarios, the engineering support, and what is explicitly out of scope. Price, lead time and delivery terms are quoted per enquiry and are not published.
Before you write.
AmbiV2X Developer Stack
How AmbiV2X and ROS 2 Humble share the platform, and what a customer receives.
The V2X stack
The layers, the India, Europe and US profiles, and AmbiV2X's status row by row.
Development setups
AmbiOBU, AmbiRSU and AmbiSEC, and how each setup is ordered.
V2V
What vehicle-to-vehicle communication does, and what it needs.
V2I
Roadside units, signal phase and the infrastructure side of V2X.
C-V2X
PC5 and Uu, and the Release 14 baseline.
Ready to scope an evaluation?
Send the seven points above. Enquiries go to the V2X engineering team directly, with no reseller in between. Software access, documentation and licensing are agreed in the quotation, not assumed.
Questions this page answers.
What do I need to evaluate AmbiV2X?
One AmbiOBU to run your own application beside AmbiV2X; two AmbiOBUs for vehicle-to-vehicle; an AmbiOBU and an AmbiRSU for vehicle-to-infrastructure. You usually provide the test site, authorisation to transmit at 5.9 GHz, the vehicles or a movable platform, and any signal-state source or certificates the evaluation needs.
Does the evaluation run over the air on C-V2X PC5 today?
Not yet. AmbiV2X's available features are verified in Ambimat's host-based software testing, and over-the-air PC5 operation is the next integration step, so it is not claimed. Each AmbiOBU and AmbiRSU carries its own 5.9 GHz C-V2X PC5 subsystem; the SIMCom A7672 LTE module is for backhaul and does not provide PC5.
Is AmbiV2X open source, or available as an SDK download?
No. AmbiV2X is Ambimat's proprietary V2X communication stack, developed and owned by the Ambimat V2X team. Integration documentation, permitted access, licensing and software delivery scope are agreed individually for each customer engagement. Open-source components on the platform, such as Ubuntu and ROS 2, remain under their own licences.
Do I need AmbiSEC for an evaluation?
Only if device-side key custody is part of your question. AmbiSEC holds identity keys inside a hardware security boundary. It is not a certificate authority, and secured (signed) V2X messaging is not claimed for AmbiV2X today.
Is an evaluation a certification or type approval?
No. AmbiOBU and AmbiRSU are development platforms and AmbiV2X is not a certified production automotive V2X stack. Conformance testing, type approval and homologation are separate programmes with accredited bodies.
What should I send to get a quotation?
The question the evaluation must answer, the setup and node count, the region and message profile, whether you use ROS 2, whether AmbiSEC is in scope, where you will test and who holds the authorisation to transmit, and your timeline. Price, lead time and delivery terms are quoted per enquiry.
Last updated 2026-10-14 · Technical reference maintained by Ambimat Electronics, Ahmedabad, India. Corrections: v2x@ambimat.com