COVESA Getting Started

COVESA Community Calendar - Weekly Meeting Schedule

COVESA Communication Channels (Slack, Mailing Lists, Calendar)

COVESA Github Repository

Project Launch Process

Request Wiki Account


COVESA Briefing/Overview Deck


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

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

Android™ Automotive SIG
▶︎ Android Automotive White Label App Store

Security Team

Simulation and Tooling

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


Common Vehicle Interface Initiative

Cloud & Connected Services Project

SDV Telemetry Project - On Hold


Industry Events

Industry Events 2023


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

Child pages
  • Vehicle Service Catalog (VSC) - Common Interface Description Model

We use cookies on this site to enhance your user experience. By using this site, you are giving your consent for us to set cookies.

Skip to end of metadata
Go to start of metadata

Weekly Meeting

VSC weekly development meeting:  Meeting Link

Recorded Meetings

You will find recorded meetings here.



Create a standardized, extensible vehicle service catalog, and associated tools, to enable protocol-, language-and specification-agnostic interoperability between ECUs, infotainment, and cloud.

  • Standardized – Version managed service specification with regular releases
  • Extensible – Proprietary extensions can be added to an open-standard catalog
  • Tools – Auto-generate network code and APIs from service specifications
  • Specification agnostic – Translation to and from multiple specification formats
  • Interoperability – Enable seamless communication in the vehicle and over the air

Presentations from April 2022 All Member Meeting

VSC And VSS Alignment 

October 2021 AMM Presentation - Excellent Background on Current Thinking

Jump to 8:04 for VSC.  Confluence won't let you embed a YouTube link with a start time.

Ongoing design/discussion points

For details it could be best to track the GitHub issues in VSC and VSC-tools

  • Stakeholder input:  #1 preferred source-language for interface descriptions.  e.g. Franca IDL or other, or do companies use gRPC directly, etc.?
  • Stakeholder input:  Interesting mapped technologies, input-and-output formats and bindings.  (e.g. gRPC, SOME/IP, DDS, HTTP/REST based remote procedure call protocols, ...)
  • How to reference VSS signals in VSC model
  • Error handling feature built in
    • Build in some support for success/error return
    • Note: Method invocation errors that are related to the particular target/protocol are separate from this mechanism.  Those are defined in target/protocol separate specification. 
      Example: "method name not found" on a web request.
    • Support a global error type enum.  Configurable.  More than one.
    • Specify which errors are expected/applicable per method
    • Error feature is optional but best-practice.  Out-parameters still exist of course, and can be (mis)used to report invocation success
    • Next:  Make syntax proposal.  Consider is this feature reasonable to translate/map to all IDLs, target environments that we envision.  How is it mapped?
  • Franca <-> VSC YAML mapping 
    • document, compare keywords
  • Franca further development to a "next version"? 
    • Interesting if desired new features are not covered.  E.g. error-feature might be one such thing.
  • Set up documentation on GitHub Wiki instead, or as a complement
  • Terminology, names.  Coin a useful name for the "VSC IDL language"
  • Review OpenAPI, AsyncAPI, gRPC/protobuf, Franca, etc. for syntax similarity  (names of things) and feature coverage.  Find alignment oppportunities.
    • One stakeholder suggested: Could OpenAPI be extended to cover non-REST.  I.e. "OpenAPI-next" == VSC language?  Rationale: OpenAPI known outside automotive.

Frequently Asked Questions:

  • Why another IDL?
  • Why is adopting <insert existing choice> not enough?  Or is it?Several answers can be found in previous presentations/slide decks 

References, previous presentations...


  • No labels