COVESA

COVESA (Connected Vehicle Systems Alliance) is an industry alliance developing open standards and code for connected vehicles. Formerly GENIVI (founded 2009 around in-vehicle infotainment), it rebranded in 2021 to focus on vehicle data and connected services. Its best-known deliverable is the Vehicle Signal Specification (VSS): a standardized, hierarchical data model naming vehicle signals — speed, battery state, door status and thousands more — independent of any manufacturer’s internal formats.

VSS gives apps, cloud services and fleet systems a common vocabulary for vehicle data, and underpins related work on data expression and API layers. In a sector where every OEM historically named and encoded the same physical quantities differently, that shared vocabulary is the alliance’s core contribution to the software-defined vehicle.

What COVESA produces

COVESA’s output is primarily specifications and data models rather than production software. The center of gravity is VSS, which describes vehicle data as a tree of named nodes — Vehicle.Speed, Vehicle.Powertrain.TractionBattery.StateOfCharge and so on — in files that are both human- and machine-readable, with tooling to convert the model into common serialization and interface formats.

Around VSS sit several related work streams. A service-interface track, developed together with the W3C, defines how VSS data is accessed over standard protocols. Expert groups work on vehicle data models beyond signals, on commercial-vehicle and fleet telematics, and on application frameworks for Android-based in-vehicle systems. The alliance also runs regular all-member meetings where this work is coordinated in public view.

The GENIVI heritage matters for understanding the scope: the organization spent a decade on open infotainment platforms before concluding that the durable, industry-wide problem was not the head unit but the data. The 2021 rename formalized that shift.

The Vehicle Signal Specification in practice

VSS is deliberately narrow. It standardizes what signals are called and how they are structured — not how they are transported, stored or priced. That narrowness is why it travels well: the same model can sit behind an in-vehicle data broker, a cloud fleet API or a regulatory data-access interface. OEMs extend the standard tree with proprietary overlays for signals they do not wish to expose, which keeps the common core stable while leaving room for differentiation.

According to COVESA, manufacturers including BMW, Ford, General Motors, Honda and Hyundai contribute to and use VSS, alongside suppliers, cloud providers and software vendors. Open-source implementations exist as well — most visibly in Eclipse SDV projects that use VSS as their vehicle abstraction layer — which gives the specification something many standards lack: freely available running code.

Who is behind it

COVESA is a member-funded, nonprofit alliance. Its membership spans vehicle manufacturers, Tier 1 suppliers, semiconductor companies, cloud and software vendors, and fleet and mobility players, with tiered membership programs that include startups. Work happens in open expert groups and on public repositories, and decisions are made by member consensus rather than by a single sponsoring company — a governance profile closer to a classic standards body than to a vendor consortium.

How it fits in the landscape

The alphabet soup of SDV consortia is genuinely confusing, and the cleanest way to place COVESA is by what each body standardizes:

• COVESA standardizes data: what vehicle signals are called and how they are modeled.
• Eclipse SDV produces code: open-source building blocks for the vehicle software stack, several of which implement VSS.
• SOAFEE defines a compute architecture: how cloud-native workloads are built, orchestrated and deployed on vehicle hardware.
• AUTOSAR — in its Classic and Adaptive platforms — standardizes the in-vehicle software architecture itself: interfaces, methodology and runtime behavior of ECU software.

These are complements more often than competitors. A production stack can plausibly run AUTOSAR-based ECUs, expose their data through a VSS model, use Eclipse SDV components in the middle, and deploy service workloads following SOAFEE patterns. The overlaps that do exist — data access APIs, service interfaces — are handled through liaisons between the groups rather than open rivalry.

Adoption reality

As of 2026, VSS is the closest thing the industry has to a default vocabulary for vehicle data, and it is hard to find a vehicle-data platform announcement that does not reference it. But adoption is uneven by layer. VSS is strongest at the vehicle-to-cloud boundary — fleet APIs, data marketplaces, telematics — where a neutral model is directly monetizable. Deep inside the vehicle, signal handling still runs on proprietary and AUTOSAR-defined formats, with VSS applied as a translation layer at the edge rather than as the native in-vehicle model. Membership breadth, as with every consortium in this space, should not be read as production deployment; contributing to a specification and shipping it in vehicles are different commitments.

What to watch

Regulation is the accelerant. The EU Data Act gives users rights to data their vehicles generate, and standardized signals like VSS are the practical route to serving such data across brands — which is why COVESA output shows up in OEM platforms, fleet APIs and regulatory discussions alike. Watch how far VSS moves from the cloud boundary into the vehicle itself, whether the W3C-aligned access interfaces gain regulatory standing as data-access mechanisms, and how tightly COVESA’s model work couples to the open-source implementations growing in Eclipse SDV. The more the industry’s data plumbing standardizes, the more the competitive question shifts to who does something useful with the data — exactly the shift COVESA’s founders bet on when they renamed the alliance.