Vehicle-to-device and vehicle-to-cloud — useful terms, not standards terms.
Neither V2D nor V2C appears as a defined mode in any SAE or ETSI deliverable. They are industry shorthand, and they are worth defining precisely because they are used loosely everywhere else.
Vehicle-to-device — anything personal or peripheral.
The vehicle exchanging data with an arbitrary personal or peripheral device: a smartphone, a smartwatch, a helmet, an aftermarket dongle, trailer telematics. Usually over Bluetooth or Wi-Fi rather than 5.9 GHz. It overlaps V2P in practice; the useful distinction is that V2D is not necessarily safety-of-life and carries no standardised safety message set.
Vehicle-to-cloud — a commercial framing of V2N.
The vehicle talking to an OEM back end. Functionally a subset of V2N, framed commercially: fleet telematics, predictive maintenance, usage-based insurance, EV charge planning, digital-twin ingestion, over-the-air updates, aggregated probe data. Where it does intersect the ITS standards, it does so through SAE's probe messages — ProbeVehicleData (35), ProbeDataManagement (42), ProbeDataConfigMessage (41), ProbeDataReportMessage (34).
A large fraction of what is marketed as V2X is V2C.
A vehicle sending data to its manufacturer's cloud is a real and valuable capability. It is not cooperative ITS, it does not interoperate with anyone else's vehicles, it participates in no shared PKI, and it should not be counted in V2X deployment figures. Volvo Trucks' one million connected trucks is the clearest example — a genuine and impressive telematics milestone, and explicitly not a V2X claim in Volvo's own announcement.
Where V2C does touch the standards.
Four SAE J2735 messages exist specifically so that a back office can collect and manage data from vehicles in a standardised way. They are the one point at which the commercial cloud path and the ITS message dictionary meet.
| Message | Acronym | ID | What it is for |
|---|---|---|---|
| ProbeVehicleData | PVD | 35 | A vehicle reporting collected snapshots of its own travel — the data a traffic authority or fleet back office aggregates |
| ProbeDataManagement | PDM | 42 | The back office telling vehicles what to collect and how often |
| ProbeDataConfigMessage | PDC | 41 | Configuration of the probe data collection behaviour |
| ProbeDataReportMessage | PDR | 34 | The report structure returned against a management request |
Everything else in a typical V2C deployment is proprietary. That is not a criticism — an OEM back end has no interoperability requirement — but it is the reason V2C traffic cannot be counted as cooperative ITS. The full message dictionary →
Four questions that classify any announcement.
Trade coverage routinely reports V2C capability as V2X deployment. These four questions separate them without needing a datasheet.
| Question | Cooperative ITS | V2D / V2C |
|---|---|---|
| What radio? | 5.9 GHz, PC5 sidelink or ITS-G5 | Cellular, Bluetooth or Wi-Fi |
| What message? | A standardised message from SAE J2735 or the ETSI ITS set | Proprietary, or probe data at best |
| Who can act on it? | Any compliant device from any manufacturer | Only the operator of the back end |
| Whose certificate signs it? | An authorisation ticket or pseudonymous certificate from a shared V2X PKI | A private TLS identity, or nothing beyond transport security |
The fourth question is the decisive one. Participation in a shared PKI is what makes a message actionable by a stranger's vehicle, and it is the property that no amount of cloud infrastructure substitutes for. How that PKI works →
None of this makes the cloud path unimportant. V2N carries certificate batches, trust-list updates, firmware and long-horizon hazard information, and two of the most successful deployed cooperative services in the world run entirely over it. The distinction is about what a message is, not about which path is more valuable.