Already a Member?
     ▷Sign Up for Member Newsletter

     ▷Request Wiki Account (Needed for Write Access)


COVESA Getting Started

COVESA Community Calendar - Weekly Meeting Schedule

COVESA Communication Channels (Slack, Mailing Lists)

COVESA Github Repository

Project Launch Process

COVESA Briefing/Overview Deck


Data Expert Group
▶︎ Data Models and Ontologies
     ▷ Vehicle Signal Specification (VSS)
     ▷ Vehicle Signal Specification Ontology (VSSo) - W3C Collaboration
▶︎ Architecture and Infrastructure
     ▷ Data Architecture Terminology (including Logical Components)
▶︎ Interface Definition
     ▷ Vehicle API
     ▷ Vehicle Service Catalog (VSC)
     ▷ Vehicle Information Service Specification (VISS) - W3C Collaboration
▶︎ Best Practices
     ▷ Governance
     ▷ Privacy and Identity
     ▷ Data Model Definition
     ▷ API First
Data Expert Group Workshop 2023Q428 at Spring AMM
Data Expert Group Workshop 2023Q1

Electric Vehicle Charging Expert Group
▶︎ EV Charging Event Data Aggregation Project
▶︎ EV Optimization - Increase Travel Range for Fixed Battery
▶︎ Private Cross OEM Joint Compute for EV Charging

Android™ Automotive SIG
▶︎ Automotive AOSP App Framework Standardization

Security Team

Simulation and Tooling

Vehicle Experience and Content - Entertainment BoF
▶︎ In-vehicle Payment SIG

Commercial Vehicle BoF


Common Vehicle Interface Initiative

Cloud & Connected Services Project

SDV Telemetry Project - On Hold


Industry Events

Industry Events 2023


April 2023 All Member Meeting

October 2022 All Member Meeting

April 2022 All Member Meeting

October 2021 All Member Meeting

May 2021 All Member Meeting

October 2020 All Member Meeting

May 2020 Virtual Technical Summit

November 2019 Technical Summit

May 2019 All Member Meeting

Contact Us

Skip to end of metadata
Go to start of metadata

It was over a year ago that the first version of the Automotive Virtual Platform Specification (AVPS) was released, and during the pandemic year the AVPS has made slow but steady progress, leading to a new release.

The contributors to this specification are now proud to present version 2.0. This version carries significant updates in many critical chapters including Graphics, IOMMU, cryptography features, and introduces some new device areas as well.

The AVPS v2.0 is around 50 pages long and keeps its original style of including both a Discussion section and a formal Requirements section for each topic:

The discussion sections make up the bulk of the text so that the requirements can be succinct. Because of the complexity of the subject matter and the fast moving state-of-the-art, the discussion sections provide an overview of the current situation and important context for the requirements. This is not so common for requirement specifications, but seems very useful in this case. That introduction to each topic clarifies the rationale for the requirements and can also be a starting point for any discussions among buyers/users and providers/sellers of virtualization technology.  The requirement section is the normative part and the document includes a specific chapter about what it means to follow / be compliant with, the specification. Regarding the content, the overwhelming industry standard for kernel-to-hypervisor APIs (virtual device APIs) is VIRTIO. For that reason the AVPS requires the use of VIRTIO in many areas, by referring to specific parts of the VIRTIO specification rather than repeating or rewriting those requirements.

AVPS serves a purpose in addition to the existing VIRTIO specification document as follows:

  • AVPS selects and specifies which parts of the full VIRTIO specification (some of which is applicable to servers and desktops) are applicable in an automotive environment.  We think it is important that the automotive industry takes charge of its own destiny when it comes to virtualization technologies, and define what it means to have an automotive virtual platform.
  • In addition to virtual device APIs that are covered by VIRTIO, AVPS adds platform requirements outside of the device API.  As an example, the boot-protocol defines how operating systems in Virtual Machines (VM) are booted on a virtual platform and is very important for VM portability across implementations. The AVPS is similarly a place where other automotive-specific requirements can be collected, including non-functional requirements (such as performance or other characteristics).
  • For features that do not fit into the VIRTIO specification or are not planned to be covered, the AVPS is a place to define another solution and for areas that are not yet completed in VIRTIO, an alternative stopgap solution could be written. In some cases the AVPS is already requiring VIRTIO-related proposals that have been generally agreed, but not yet released into a versioned VIRTIO document.
  • Finally, in certain specific areas, automotive products might not be able to avoid specific solutions, such as hardware-specific support.  In certain cases, the only reasonable choice is one that might not match any proposed generic abstraction API.  Graphics is currently one such example where using hardware-assisted features is desired and unavoidable. To be truly useful, and not simply circumvented, an industry-specific requirement specification like AVPS must take into account the design choices that are most likely in automotive products.  This means writing reasonable, tailored requirements. In certain selected areas these may include compromises to better reflect the reality of the industry.

The team is proud of the achievement of getting version 2.0 out the door, and it is time to again spread the word of its existence and welcome further additional community input!   The AVPS document has an open-source (Creative Commons) license which is a guarantee for your time investment.

In combination with VIRTIO, the automotive industry industry now has a strong starting point for a shared virtualization standard, and additional input can increase its scope and quality even further.   Join the work to improve this important area of automotive technology!

      – Gunnar Andersson - Technical Lead, GENIVI Alliance