Vehicle-to-Everything development services — the whole programme, not one part of it.
Can Ambimat develop my Vehicle-to-Everything product? Yes. Requirements and architecture, On-Board Unit and Roadside Unit hardware, embedded and secure firmware, the security and credential layer, prototype, demonstration, and the engineering that takes it toward manufacture.
Vehicle-to-Everything (V2X) here means the automotive kind: a vehicle exchanging safety messages with other vehicles (Vehicle-to-Vehicle) and with roadside infrastructure (Vehicle-to-Infrastructure), usually over Cellular Vehicle-to-Everything (C-V2X) radio. It is not vehicle-to-grid energy transfer, and it is not the defence contractor of the same name.
We are an OEM and ODM design and manufacturing house in Ahmedabad, established 1982, working concept to box-packaged product. V2X development draws on the same disciplines — embedded hardware, RF and cellular, secure elements, provisioning, field update — pointed at one product class. We work with vehicle OEMs, tier-1s and product teams in India and internationally.
Below: what an end-to-end programme covers, the two specialisms it draws on, how an engagement starts, and where our scope stops.
A joint development programme, not a report and not a reference design.
Ambimat works with you to build your V2X product. Not a study of whether V2X could work, and not a demonstrator that proves the radio associates — the unit you intend to fit to vehicles or mount beside a road, engineered to your requirements and taken toward something you can manufacture.
| Question | Answer |
|---|---|
| Who is this for? | Vehicle OEMs, tier-1 suppliers, and technology companies building a V2X product. In India and internationally |
| Is it a product sale or a service? | Both, in sequence. You can start on an existing development setup, then move into a joint engineering programme for your own hardware. The kit is the starting point, not the deliverable |
| Which parts of the system? | The device side: On-Board Unit and Roadside Unit hardware, embedded and secure firmware, the secure element and credential layer, provisioning, and integration of the V2X stack you have chosen |
| At what stage can I engage? | Any. Most programmes arrive with one constraint already fixed — a cost ceiling, a fitment date, a chosen chipset, a contract manufacturer — and the work starts from there |
| What happens in between? | Architecture, prototype, integration, security design, design for manufacture, provisioning line, and submission support toward production — the eight stages set out in the next section |
| Who owns the result? | Your own prior intellectual property stays yours. IP Ambimat owns or develops stays Ambimat’s unless otherwise agreed, and can be licensed to you on programme-specific terms — defined in the proposal and the contract, not assumed either way |
Intellectual property — the default, stated. What you bring to a programme remains yours. Ambimat’s background technology and the intellectual property Ambimat develops remain Ambimat’s unless something else is expressly agreed — and Ambimat is open to licensing that IP for use in your product. The rights that actually matter to a programme — field of use, territory, term, exclusivity, and what is delivered in what form — are structured around your commercial requirement and written into the proposal and the contract rather than assumed by either side. Third-party and open-source components remain subject to their own licences, and general engineering know-how stays with the engineers who hold it. This is the starting position rather than the finished agreement, and like the rest of the scope it is settled in writing before anybody starts building.
How this differs from research material and reference implementations
India has a genuinely useful V2X research base. Public research programmes, university testbeds and standards work establish that the technology functions, publish results others can build on, and de-risk the parts nobody should have to solve twice. That work matters, and this site cites it throughout — including India's first V2X research demonstration in May 2022, whose own announcement was explicit that it was a research project rather than product planning.
Reference implementations and open-source stacks do a related job: they show a working example. What is maintained, and what each project is for →
Neither is the same as having a product. Between a validated concept and a unit you can fit to a vehicle sit the questions research is not trying to answer: what the thermal envelope is in a sealed enclosure at 48 °C, where the private key lives when the attacker can hold the device, how the unit is personalised on a manufacturing line rather than at a desk, what the bill of materials closes at in volume, and who is accountable when the certificate policy changes in year four. That engineering is what Ambimat is engaged to do — alongside your team, on your requirements, as a commercial development partner.
Stated plainly so there is no ambiguity: Ambimat is an independent commercial engineering company. Nothing on this site implies endorsement by, partnership with, or any other relationship to a government body, research institution or standards organisation. Where such organisations are referenced, they are referenced as published public sources.
What to look for in a V2X development partner.
These are the questions worth asking whoever you are evaluating, including us. They are written so you can put them to anyone; the right-hand column is how we answer them, with links to the evidence rather than to a claim.
| What to check | Why it matters | How Ambimat answers it |
|---|---|---|
| Does the partner cover both ends of the link? | Almost nothing interesting in V2X happens at one node. Range, message handling and every trust decision only appear when two participants exchange signed messages across a real radio link | Both ends, developed against each other: an On-Board Unit kit and a Roadside Unit kit. Where the two genuinely diverge → |
| Do hardware and embedded software come from the same engagement? | The decisions that break an on-board unit sit across that boundary — antenna placement against enclosure, thermal budget against board, personalisation against the manufacturing line | One engagement covers both. AmbiLogistics is a shipped example of the same combination, with its specification published |
| Is security designed in or bolted on? | Key custody, provisioning and the update path cannot be retrofitted cheaply. A certificate-policy change in year four is either a software release or a recall, and that is decided at architecture time | Secure element, applet structure, enrolment and authorisation handling and the provisioning line, designed with the hardware. The specialism → Device side only — we do not operate a trust authority |
| Does the partner understand the RF chain, not just the modem? | Two units on identical silicon can differ by hundreds of metres of usable range on antenna choice, ground plane and feed loss alone. The modem is the part you buy; the rest is designed | Our working reference on it, and dated antenna work in the published engineering record. It is not a record of 5.9 GHz V2X antenna design, and we do not present it as one |
| Is GNSS treated as timing, not just position? | A C-V2X unit takes its position claim and its sidelink timing reference from GNSS. Degrade the receiver and you degrade the radio, not just the map | A published receiver specification with GAGAN augmentation and built-in spoofing detection, and NavIC vehicle-tracking units built in 2018 and 2020. The published rows → |
| Can you engage at the stage you are actually at? | Most programmes arrive with one constraint already fixed — a cost ceiling, a fitment date, a chosen chipset, a contract manufacturer. A partner who can only start at the beginning is no use in year two | Any stage, including a single subsystem. The work starts from whatever is already decided |
| What happens after the prototype? | This is where most V2X efforts stall. The distance between a demonstrator and a unit that can be built ten thousand times, personalised securely and submitted for approval is the expensive part | Design for manufacture, the personalisation line, and documentation and submission support. No Ambimat V2X platform has completed that journey yet — the stages are what we do, not a track record we are claiming |
| Can a specification be traced to a source? | A figure you cannot check is a risk you inherit. It matters most where a number came from a different product | Every row of the AmbiOBU table is labelled either published — quoted from a specification you can open — or development configuration. The two are never mixed |
| Who actually does the manufacturing? | “We do everything” is rarely true, and finding out late is expensive | One organisation accountable across the design-to-manufacture boundary. PCB fabrication runs through a qualified global partner ecosystem rather than an in-house fab, which the parent company states itself |
| What does the partner refuse to do? | A short list of capabilities you can verify is worth more than a long one you cannot. The refusals tell you where the real boundaries are | Four of them, published and unhedged, in section 6 below: no trust authority, no protocol stack, no accredited testing, no corridor-scale integration |
Where this is the strongest fit. Not every V2X programme needs an engineering partner, and we would rather say so than pretend otherwise. This engagement earns its place when a programme needs hardware built or adapted rather than bought, when embedded software and the trust layer have to be designed together with the board, when a unit has to survive a specific vehicle and a specific market, and when somebody has to stay with it past the demonstrator. A programme that needs a finished certified box today, a protocol stack, or a corridor integrated end to end is better served elsewhere, and we will say so on the first call.
From a development setup to your own vehicles and roadside.
Most customers start in the middle. The point is that the same team can carry it through, across the phases included in the agreed scope, rather than handing you off at the prototype.
| Stage | What happens |
|---|---|
| 1 · Development setup | Start on real hardware: AmbiOBU for the vehicle side, AmbiRSU for the roadside side, AmbiSEC for the security layer |
| 2 · Architecture and proof of concept | Use cases, message sets, radio and positioning strategy, the trust boundary, and a working unit to demonstrate against |
| 3 · V2V and V2I integration | Get two participants exchanging signed messages — vehicle to vehicle, and vehicle to roadside — and behaving correctly when one of them should not be trusted |
| 4 · Security integration | Secure element, key custody, credential handling, provisioning and signed update designed in rather than added later. The security specialism → |
| 5 · Custom product engineering | Your On-Board Unit or Roadside Unit rather than our development platform — your form factor, interfaces, cost target and environment. The hardware path → |
| 6 · Your actual environment | Integration into your vehicle, your roadside equipment and your application context, rather than a bench |
| 7 · Real-world evaluation | Running the scenario where it will actually be used, and finding what a lab does not show |
| 8 · Toward manufacture | Design for manufacture, provisioning line, documentation and submission support for FCC, CE and MTCTE, and production, where that is the goal |
Where this stops: type approval and certification remain with ARAI or the appropriate authorised body. We are not a certification consultancy, a homologation agent or an accredited test laboratory, and we do not deliver corridor-scale systems integration. "Real-world" here means your vehicles, your roadside equipment and your application — not a claim to have deployed public V2X corridors.
From a requirement to a unit you can build.
Not every programme needs every stage. Most arrive somewhere in the middle, with a constraint already fixed. About Ambimat →
| Stage | What we do |
|---|---|
| Requirements and architecture | Use cases, message sets, radio and positioning strategy, the trust boundary, and the block diagram that follows from them |
| OBU development | The vehicle node: hardware, cellular and GNSS integration, sensing, power, thermal and enclosure — developed against a real moving platform rather than a bench mock-up |
| RSU development | The roadside node: outdoor enclosure, mounting, power and surge resilience, backhaul, and an update path that cannot strand a unit on a gantry |
| Embedded and firmware | Board bring-up, drivers, secure boot, application firmware, the ROS 2 application and development environment on the unit, and integration of the V2X protocol layers — whether from a stack vendor you license or built against a programme-selected profile. The AmbiV2X Developer Stack → |
| Security and credentials | Secure-element selection, key custody, applet structure, enrolment and authorisation handling, pseudonym rotation, provisioning line. The specialism → |
| Prototype and demonstration | A working unit for testing and for showing to a customer, a regulator or a board — typically 90 to 180 days |
| Toward manufacture | Design for manufacture, test strategy, personalisation line, documentation and submission support for FCC, CE and MTCTE, and production. The hardware and product path → |
The three pages below go deeper on the parts customers most often start from. They are components of the development service, not separate businesses.
V2X hardware and product development
The physical product: C-V2X on-board and roadside units from architecture to a manufacturable unit — RF and antenna, GNSS, cellular, sensing, thermal and enclosure, design for manufacture, and the provisioning line.
V2X security integration
The trust layer inside the unit: making a receiver able to establish that a message came from an authorised participant and arrived unaltered — secure elements, credentials, provisioning, rotation and signed update.
Commissioning and service tools
The local interfaces around a deployment: secure commissioning of development equipment, technician identification, diagnostics, association workflows and line-side provisioning. Not the air interface.
“Customisable” does not mean every configuration already exists.
The most common wrong conclusion about a development platform is that its current specification is its limit. It is not, and neither is the opposite. This table separates the three, because a programme plan built on either mistake fails late. The AmbiOBU specification →
| Capability | Where it stands | What that means |
|---|---|---|
| C-V2X PC5 radio | Base platform | 3GPP Release 14. Release 15, Release 16 and NR-V2X are not part of the platform and are not on offer |
| Positioning | Base platform | u-blox MAX-M10S, standard-precision multi-constellation on L1. Not RTK, not lane-level, no dead reckoning |
| Inertial sensing | Base platform | A 9-axis IMU, as a separate measurement source rather than a fusion engine |
| Cellular | Base platform | 4G LTE. The wide-area path for certificate batches and firmware, not the safety-message path |
| Compute and environment | Base platform | NVIDIA Jetson Orin Nano Super with 8 GB LPDDR5, Ubuntu 22.04 LTS and ROS 2 Humble |
| Device identity | Base platform | A key held inside the secure element and non-extractable by hardware design, so identity operations are anchored to the endpoint |
| CAN or another vehicle data bus | Custom engineering | Not in the base platform. Adding a vehicle-bus interface is programme engineering — a design task with a scope and a cost, not an unavailable feature |
| A different GNSS front end | Custom engineering | Including a higher-precision receiver class. The receiver is a design choice; changing it changes the board, and we have not built an RTK V2X unit |
| GNSS and inertial fusion | Custom engineering, feasibility first | Dead reckoning is not in the platform and is not a switch to enable. It is development work, and whether it is worth doing depends on your accuracy requirement |
| External interfaces and carrier boards | Custom engineering | Connectors, sensor interfaces, form factor and customer-specific carrier boards |
| Enclosure, ingress rating, environment | Custom engineering | Defined per programme. The development platforms carry no IP rating and no environmental qualification, and we do not imply one |
| Antenna and RF chain | Custom engineering | Dated antenna work sits in the engineering record. It is not a record of 5.9 GHz V2X antenna design, and we do not present it as one |
| Power architecture | Custom engineering | Vehicle power input, ignition handling, surge and roadside supply, against your environment rather than a bench supply |
| Application and integration software | Custom engineering | ROS 2 applications, logging, telemetry and integration components, provided according to programme scope |
| IEEE 1609.2 and SAE J2735 integration | Custom engineering | The environment is structured to integrate them and the target profile is frozen at programme configuration. That is architectural readiness, not certified conformance |
| Device-side PKI and credentials | Custom engineering | Key custody, enrolment and authorisation handling, pseudonym rotation and the provisioning line, against the PKI your programme must interoperate with |
| Root CA, Enrolment or Authorisation Authority | Not what we do | A trust-anchor function for a designated authority. We work on the device side of the chain |
| Certified production protocol stack | Not what we do | Where a deployment needs an implementation already through conformance testing, we integrate the one you license |
| Type approval and accredited testing | Not what we do | ARAI or the appropriate authorised body. We prepare hardware and documentation and support the submission |
| NR-V2X | Not what we do | Not on the platform and not offered. If your programme depends on it, another supplier is the right answer |
One thing this table is not. It is a statement of what can be designed, not a record of what has been delivered. Ambimat publishes no V2X customer references, deployments or production volumes, and no Ambimat V2X platform has yet completed the journey to type approval. The engineering disciplines are long-standing and documented; the V2X programme built on them is not a track record we are claiming. The dated engineering record →
Three development setups: vehicle, roadside, security.
A development programme goes faster when both participants exist and the trust layer is real rather than stubbed out.
OBU development kit
The vehicle participant, runnable in a 1:10-scale movable test vehicle so the moving node actually moves. AmbiOBU.
RSU development kit
The roadside participant: fixed position, known location, signing what vehicles act on. AmbiRSU.
Security development setup
The trust layer both nodes depend on: secure element, hardware-protected keys, credential storage and message signing. AmbiSEC.
Both are development kits, open to collaboration — not orderable production units, not certified, not homologated. The full development-kit line →
The security decisions are hardware decisions, taken early or paid for later.
A V2X unit has two credentials that look unrelated and are not: a V2X identity for signing safety messages over the PC5 sidelink, and a cellular identity for the Uu path that delivers certificate batches and firmware. Both are long-lived, both are provisioned at manufacture, both must be non-extractable. Decide them separately and you buy two parts, run two provisioning steps and secure two boundaries.
The same coupling runs through the rest of the design. Verification throughput sizing decides the secure element, which decides the board. The personalisation line decides what the contract manufacturer is allowed to see. The update path decides whether a certificate-policy change in year four is a software release or a recall. None of these can be retrofitted cheaply, which is why the hardware and security engagements are usually one programme rather than two.
Three ways in, depending on where your programme is.
| Engagement | What it is |
|---|---|
| Technical deep-dive | Hardware architecture and block diagrams for any one product, presented to your technical team — or to DoT, TEC or TRAI technical teams — within 30 days |
| Proof of concept | A working unit for demonstration and testing, within 90 to 180 days |
| Secure-element integration | Secure-element selection, applet structure, provisioning-line architecture and enrolment/authorisation integration patterns. Reference designs and evaluation hardware shared under NDA |
The contact page lists these alongside the wider set of ways to work with the V2X programme, and says who picks up.
From a first email to engineering work.
The sequence, so you know what you are agreeing to at each point. No timescales are promised here beyond the two already stated above, because they depend on what you bring.
| Step | What happens | What it commits you to |
|---|---|---|
| 1 · Engineering conversation | You send the requirement or the constraint. An engineer reads it and replies — there is no form and no qualification gate | Nothing |
| 2 · Context review | What you already have and what is already fixed: chosen parts, an existing board or firmware base, the vehicle or site, the target market, the stage you are at | Nothing. An NDA can be in place before this if the material is sensitive |
| 3 · Scope definition | What is in and what is out, written down. This is also where ownership, licensing and any third-party components are settled, because they change the engineering | Nothing yet, but this is the conversation that decides the commercial terms |
| 4 · Architecture and feasibility | The technical view: block diagram, part selection, trust boundary, radio and antenna plan, power and thermal budget — and an honest statement of what is uncertain | Depending on depth, this may itself be the first paid piece of work |
| 5 · Commercial proposal | Scope, deliverables and terms for the agreed piece of work | Nothing until you accept it |
| 6 · Engineering execution | The work, against the agreed scope | The agreement |
| 7 · Validation | Extended-soak and environmental testing against the target envelope, and pre-compliance work before anything is submitted. Where this sits in the hardware path → | The agreement |
| 8 · Continuing scope | Integration, further validation and production engineering can continue as subsequent phases — where they are included in the agreed scope. Ambimat does not publish a support contract, a response time or a maintenance term, because none is defined | A further agreement each time |
What is deliberately not stated here. There is no free-consultation offer, no fixed proposal turnaround, no guaranteed feasibility outcome and no support or warranty term. Those are either commercial matters settled per programme or things Ambimat has not defined, and inventing them would make this page less useful rather than more.
Enough to get a useful answer, and no more.
None of this is required. A one-line question is welcome. But an enquiry carrying two or three of these gets a technical answer instead of a request for more information.
- The application. What the system is for, and which of V2V, V2I, V2P or V2N it depends on
- Vehicle or site context. Vehicle category — L, M or N — or the roadside site, mounting and access situation
- Target market. Which conformity regime the result has to face. The jurisdictions compared →
- OBU, RSU or both, and whether you need a whole unit or one subsystem
- Where you are now. A requirement, an architecture, an existing board, a working prototype, or a product that has to be re-engineered
- What is already decided. A chosen chipset or module, a stack vendor, a contract manufacturer, an enclosure already tooled, a cost ceiling, a fitment date
- Security requirement, if you have one — the PKI you must interoperate with, or the key-custody expectation. The security specialism →
- Anything you already know is hard. The thermal envelope, the antenna position, the verification rate, the BOM target. The binding constraint is the most useful sentence in any first email
Quantities and timelines are useful if you know them and unnecessary if you do not. Where to send it, and who picks up →
No single organisation delivers a V2X deployment.
Worth setting out early, because a programme plan that assumes one supplier covers all of it will find the gaps late.
| Domain | Who holds it |
|---|---|
| Device hardware, embedded software, security integration | Ambimat, on the scope agreed — this is the part described on this page |
| The V2X protocol stack for a production deployment | A stack vendor, where the deployment needs an implementation already taken through conformance testing. Ambimat integrates the one you license. The open ROS 2 application and development environment for AmbiOBU and AmbiRSU, and the V2X protocol integration around it, come from Ambimat. The AmbiV2X Developer Stack → |
| Type approval and conformance testing | An accredited laboratory and the authorising body — ARAI or equivalent. Never the hardware supplier. How it works → |
| The trust hierarchy — Root CA, Enrolment and Authorisation Authorities | A designated national or regional authority. Ambimat works on the device side of the trust chain and does not operate any of these. The architecture, and who should run it → |
| Cellular connectivity for the Uu path | A mobile network operator, plus a subscription and its provisioning path. Why the wide-area half exists → |
| Spectrum and its licensing | The national regulator. Who has allocated what → |
| Roadside sites, power and access | The road authority, concessionaire or municipal operator |
| PCB fabrication and volume assembly | Qualified manufacturing partners, coordinated by Ambimat. The parent company describes this arrangement itself |
| Vehicle integration and homologation | The vehicle manufacturer and its approval process |
| Corridor-scale systems integration | A systems integrator. Out of Ambimat's scope, stated below |
This is not a disclaimer. It is the reason the questions further up this page are worth asking: a partner who understands where their work stops is easier to plan a programme around than one who implies they cover everything.
AIS-230, as a development input rather than a service line.
Useful if your product is going to the Indian market. Not the business we are in.
Building V2X for the Indian market? We can help a product team understand and implement the development and security implications of AIS-230 while the OBU or RSU is being designed — the band, the positioning and GNSS requirements, the EMC envelope, and the cybersecurity and communication-security provisions the standard carries. Ambimat designs and engineers V2X hardware and security systems toward applicable AIS-230 requirements, and can support OEM and Tier-1 readiness.
Certification and type approval remain outside Ambimat's role, with ARAI or the appropriate authorised body. We are not a certification consultancy, a homologation agent or a regulatory-affairs practice, and we do not offer AIS-230 compliance as a commercial service.
The regulatory position itself is not settled, and this site keeps the distinction visible rather than blurring it for effect: the MoRTH notification of 3 August 2026 is a draft, published for comment, proposing dates of 1 October 2027 and 1 October 2028. Until it is finalised nothing is mandatory. Anyone selling you certainty about the Indian timetable is selling you something. The Indian regulatory position in full →
What we do not do.
A shorter list of capabilities you can verify is worth more than a longer one you cannot.
- We do not operate a V2X trust authority. No Root CA, no Enrolment Authority, no Authorisation Authority. Our engineering view on who should run those in India is published on the PKI reference, and it does not propose us.
- We do not supply a certified production V2X protocol stack. Where a deployment needs an implementation already taken through conformance testing, we integrate one onto hardware we design. The open ROS 2 application and development environment for AmbiOBU and AmbiRSU, and the V2X protocol integration around it, do come from Ambimat. The AmbiV2X Developer Stack → · The commercial stacks available →
- We are not an accredited test laboratory, and we do not offer V2X testing as a commercial service. We prepare hardware and documentation for certification; the testing and the approval sit with the accredited body. How V2X testing and certification work →
- We do not deliver corridor-scale systems integration. We build units and the security layer inside them.
The reference material these services are built on.
Send us the binding constraint.
Whichever one is actually deciding your design — the cost ceiling, the verification rate, the fitment date, the certificate policy or the volume. Email goes to an engineer, not a form.
Questions this page answers.
Does Ambimat build complete V2X on-board units?
Ambimat designs and manufactures V2X hardware, and integrates the secure element and update path inside it. AmbiOBU and AmbiRSU are development platforms rather than orderable products — they need a partner with a deployment to become finished products. The three development setups available today are AmbiOBU for the vehicle side, AmbiRSU for the roadside side and AmbiSEC for the security layer.
How does a V2X project with Ambimat start?
With an engineering conversation, not a form. You send the requirement or the binding constraint and an engineer replies. From there the sequence is a context review of what is already fixed, a written scope definition — which is also where ownership, licensing and third-party components get settled — then architecture and feasibility, a commercial proposal, and only then engineering work. Nothing is committed until the proposal is accepted, and an NDA can be in place before anything sensitive is discussed. Ambimat does not publish a free-consultation offer or a fixed proposal turnaround, because neither is defined.
Can Ambimat work from our existing architecture, or only from a blank sheet?
From whatever is already fixed. Most programmes arrive with a constraint already decided — a chosen chipset or module, a cost ceiling, a fitment date, an enclosure already tooled, a contract manufacturer — and the work starts from there rather than proposing to redo it. That includes taking an existing board, an existing firmware base or an existing reference architecture as the starting point.
Can Ambimat develop only one subsystem rather than a whole unit?
Yes. A single subsystem is a normal engagement: the antenna and RF chain, the GNSS front end, the secure element and its provisioning, the power architecture, the enclosure and thermal design, or the embedded integration on a board somebody else designed. The full-programme path exists for teams who want it, not as a condition of engaging.
Can Ambimat work with the chipset or module we have already selected?
Yes, and that is the usual case. The V2X modem is a purchasable part, and where a programme needs a conformance-certified protocol stack that comes from a stack vendor; Ambimat integrates the parts you have chosen onto hardware it designs. Ambimat also provides its own open ROS 2 application and development environment for AmbiOBU and AmbiRSU, with V2X protocol integration against a programme-selected profile. The AmbiV2X Developer Stack. The silicon landscape a design selects from.
What does customisation actually cover?
It is engineering scope rather than a menu of stock options, and it means the dimensions a real unit varies in: form factor and enclosure, external interfaces, the antenna and RF chain, the GNSS front end, the cellular module and its subscription path, the secure element and credential handling, the power architecture, and the embedded software above all of it. Each is engineering work scoped per programme, not a variant already built and waiting.
Does the customer keep ownership of the resulting design?
Your own pre-existing intellectual property remains yours. Ambimat’s background technology and the intellectual property Ambimat develops remain Ambimat’s unless something else is expressly agreed, and Ambimat is open to licensing that IP for use in your product on programme-specific terms. Field of use, territory, term, exclusivity, and what is delivered in what form are commercial matters structured around your requirement and written into the proposal and the contract — worth settling explicitly at scope definition rather than assuming. Third-party and open-source components remain subject to their own licences.
What does a V2X development partner do?
A V2X development partner is an engineering organisation that builds a customer's V2X product with them, rather than selling a finished unit or publishing research about one. The work is the device side: requirements and architecture, On-Board Unit or Roadside Unit hardware, embedded and secure firmware, the application and development environment on the unit, integration of the V2X protocol layers — from a stack vendor where a certified implementation is required, or against a programme-selected profile — the secure element and credential layer, the provisioning line that binds identity at manufacture, and the design-for-manufacture and submission-support work that turns a prototype into something buildable. It is distinct from three neighbouring roles: a research programme, which establishes that the technology works; a stack vendor, which supplies the protocol software; and an accredited test laboratory, which certifies the result. A development partner does none of those three.
Does Ambimat operate a V2X PKI or certificate authority?
No. Ambimat works on the device side of the trust chain — key custody, credential storage, provisioning and lifecycle on the unit itself. It does not operate a Root CA, an Enrolment Authority or an Authorisation Authority. The V2X PKI reference sets out an engineering view of who should run those in India, and does not propose Ambimat.
Who certifies a device to AIS-230?
ARAI or the appropriate authorised body — never the hardware supplier. Ambimat designs and engineers V2X hardware and security systems toward applicable AIS-230 requirements and can support OEM and Tier-1 readiness. Type approval and certification remain with ARAI or the appropriate authorised body. The MoRTH notification of 3 August 2026 is also still a draft; nothing is mandatory until it is finalised. The Indian position in full.
Is V2X testing part of what Ambimat offers?
Not as a commercial service. Ambimat prepares hardware and documentation for certification and supports the submission for FCC, CE and MTCTE, but it is not an accredited test laboratory and does not market testing as a standalone offering. What V2X testing and certification actually involve.
Where is the engineering done?
Ahmedabad, Gujarat. Ambimat Electronics is an OEM and ODM design and manufacturing house established 1982, working from concept to box-packaged product, with existing government and research clients including ISRO, BARC and the Indian Army — all three named on the parent company's published client list. The dated engineering record.
Last updated 2026-09-07 · Technical reference maintained by Ambimat Electronics, Ahmedabad, India. Corrections: neel.shah@ambimat.com