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.


Overview

The primary purpose of this page is to provide requirements the COVESA Vehicle Data Model's modeling language.  However, there are project level requirements as well.   Business Rationale  for a Vehicle Data Model and Pain Points with the current model are listed below as well.  In addition, you can find a detailed presentation on moving towards a Vehicle Data Model here.

VSS Modeling Language Requirements

The following table represents a zoomed-out view of the essential requirements that the VSS modeling language should satisfy. They are based on the different stakeholders' desires which have been collected through multiple exchanges. 

If you consider that a particular criterium or aspect is missing, feel free to contribute. Bear in mind that any contribution must be framed in a collaborative way to foster community support and future adoption.
CriteriaRequirement descriptionCurrent (VSPEC)Desired

PoC Phase 1 (June)

PoC Phase 2 (July 11)

Renesas

Geotab

Bosch

Ford

BMW

Notes/Questions

Simplicity*

The quality or condition of being easy to understand, use or do

  • Must be human-readable.
  • Must be easily understood by Subject Matter Experts (SMEs), even when they have little to no knowledge of data modeling best practices.
  • Must be useable by new comers within a reasonable period of time (e.g., a few hours).
  • Must be easy to contribute (i.e., to extend the controlled vocabulary).

✅ Yes

✅ YesMust have






Technology Agnosticism*

Interoperable and flexible across various platforms, devices, or environments, not tied to specific vendors, technologies, or frameworks. 


  • Must be compatible with little effort to other artifacts and must not be a constrainer.
  • Must work with a variety of technologies

✅ Yes

Via vss-tools.

✅ YesMust have





More detail/examples are needed.

Modularity*

Quality of being composed of separate, interchangeable units or modules that, when combined, form a complete whole, facilitating flexibility, scalability, and ease of maintenance.


Having independent components (modules) that can be developed, managed, and modified separately yet seamlessly integrated or combined.

  • Must allow the use (or contribution) of only the pieces needed.
  • Must be able to adopt only parts of the model that matter to the user.
  • Must be able to extend and override parts of the model as needed for internal and external use.

⚠️ Partly 

Specification can be split into multiple files. However, not all components are reusable (e.g., allowed values).

✅ YesMust have






Scalability & Maintainability*

Ability to grow and and handle increasing demands while being easily understood, modified, and maintained.

  • Vocabulary of a domain can grow with constant effort.
  • Must support a wide variety of vehicle domains (e.g. Seating, HVAC, Entertainment, Engine, etc...).
  • Must support the reuse of existing models or vocabularies.
  • Should extend beyond passenger cars (e.g., Semi-Trucks, Motorcycle, Ambulances, etc...).
  • Support Metadata such as units, precision, allowed ranges, default values, sample-rate, accuracy, privacy class, security level.
  • Machine-readable annotations, not free-text comments.

⚠️ Partly

  • Yes in the sense that the vocabulary of vehicle properties can be further extended. However, its expressivity is limited and covering more features requires significant work on the tools.
  • Via overlays, one can add arbitrary metadata. This extra metadata is probably not covered by some of the existing tools.
✅ Yes







Metadata Resource Uniqueness*

See note

  • Elements in the domain model must provide explicit future-proof identifiers.
  • Supports versioning. 

⚠️Partly

Just the Fully-Qualified Name (fqn) and the UUID that can be constructed from the metadata are unique. Specification of a concept can appear multiple times.

✅ Yes






This sounds like a concept identifier:


A concept identifier in data modeling is a unique and stable reference (often called an identifier or key) that represents a specific concept or entity within a data model. It's used to clearly distinguish one concept from another and to enable reliable referencing and linkage of data across different contexts or systems.

Key characteristics of a concept identifier:

  • Uniqueness: Each identifier uniquely references one concept or entity.

  • Stability: The identifier remains consistent over time, even if the concept’s attributes change.

  • Non-descriptive: Often identifiers are abstract (e.g., numerical or UUID), so they don't carry inherent semantic meaning, which prevents misinterpretation or ambiguity.

  • Interoperability: Enables consistent referencing across multiple systems or data sets.

Examples:

  • UUID: Universally Unique Identifier, e.g., 550e8400-e29b-41d4-a716-446655440000

  • Primary Key: Database-generated auto-incrementing IDs, e.g., CustomerID = 12345

  • Standardized Codes: e.g., ISO country codes (US, DE), or standardized identifiers in medical contexts (SNOMED CT IDs).

Practical usage in data modeling:

  • Used as a primary key in database tables to uniquely identify records.

  • Supports linking data from multiple sources through foreign keys or reference identifiers.

  • Facilitates interoperability and integration among different data systems and external sources.

Importance:

Having clearly defined concept identifiers ensures:

  • Data integrity and consistency.

  • Simplified integration and interoperability between systems.

  • Improved traceability and data governance.

In summary, a concept identifier is foundational in robust data modeling because it provides clear, stable, and unambiguous references to concepts within data systems.

Support for Multiple Classification Schemes*
  • Concepts of interest in a domain model can be classified with arbitrary hierarchies.
  • Allow several orthogonal hierarchies (domain, physical location, power-train, legal category, …) rather than a single tree by location.

  • A concept can live in, or be discovered through, multiple views.

❌No

One tree has one dimension only. Paths of the expanded tree create dependencies and moving a concept to another part in the tree is usually painful.

✅ Yes






Daniel Alvarez Would you please elaborate on this and provide an example?

Answer: Similarly to the filter categories (aka., facets) in an online shop, a concept might appear under multiple ones making it findable. 

Support for Cross Domain References*
  • Elements of the model can be re used and nested arbitrarily.

❌No

VSS tree has one dimension only. One fixed hierarchy!

✅ Yes






Examples are needed.
Support for the Specification of Capabilities*
  • Not only the data structure is specified, but also the allowed operations on the data are formalized (e.g., API-oriented).

❌No

VSS focuses on the data structure (e.g., datatypes, units, etc.) But, no possible interactions with the specified data are formally described (e.g., Concept Seat is modeled but not the possible operations on that property).

✅ Yes






Examples are needed.
Community and Tools*
  • Must scale across Automotive and adjacent industries.
  • Lower development and maintenance costs.
  • Based on a well-established set of stable open-source tools.
  • Specified domain models should be usable outside COVESA.

❌No

Limited to COVESA community and the vss-tools (mainly exporters). Any change in the modeling language requires rework of the tools.

✅ YesMust Have






Support for Automated Reasoning**

  • Resulting domain models could implement basic inferences. 

❌No

No mechanism for semantic correctness and consistency. (e.g., what distinguishes a Car from a Motorcycle? etc.)

⚠️Partly

Only via add-ons.








Examples are needed

OTHER - Non (Some of them can sorted in above categories) 

Separation of Concerns

Data vs Interface

  • conceptual domain data model describes “what it is”.
  • Transport bindings like REST, GraphQL, gRPC,  file export) describe “how to ask for it”.
  • Either layer evolves without forcing changes to the other.

⚠️Partly
VSS is only a controlled vocabulary without inference on how the data is actually stored in the physical layer. Via the tools, one can select the desired format. However, tools are limited and some rework is often needed to use in actual systems.

✅ Yes








This is not an issue of the modeling language, but rather an agreement on the operational workflow of the project.

Regarding the above response, it would seem you are both getting at the same point.  That said, the Support for the Specification of Capabilities* touches on this as well.  It is important to keep this separation. Paul Boyes 

Versioning Support

  • Supports semantic versioning

⚠️Partly

There are different releases in VSS.

✅ Yes








This is not an issue of the modeling language, but rather an agreement on the operational workflow of the project.

Already covered above. See "Scalability & Maintainability"

It is not currently called out explicitly in "Scalability & Maintainability".  It should be. Paul Boyes 

Evolving

  • Deprecation, aliasing support is defined.
  • Backward compatibility.

❌No

✅ Yes








Already covered above. See "Scalability & Maintainability"

Should be added explicitly to "Scalability & Maintainability" Paul Boyes 

Non-Functional

  • Generation of multiple formats
  • IDE support
  • Validation
  • Linting

⚠️Partly

✅ Yes








Already covered by the other criteria. Add items to "Scalability & Maintainability", "Community and Tools", "Technology Agnosticism", etc.

Should be added explicitly if not already done.  Paul Boyes 

Works with VSS
  • Must be roundtrip-able with VSS
  • Must be able to generate VSS VSPEC files
  • Must be able to accept or edit concepts/term from VSS


Must Have






Other? <Add here>












* = Must-have feature!

** = Nice-to-have feature that is not seen as essential by the members in COVESA. Possible limited support of it via add-ons. 

VSS modelling language alternatives


CriteriaVSPECGraphQLSKOS (RDF)GraphQL + SKOSUML (XMI)OMG IDLProtobufOpenAPISHACL (RDF)JSON SchemaOWL (RDF)
Simplicity*

✅ Yes

✅ Yes⚠️ Partly ✅ Yes❌No?✅ Yes✅ Yes❌No⚠️ Verbose❌No
Technology Agnosticism*

✅ Yes

✅ Yes⚠️ Partly ✅ Yes⚠️ Partly?❌No✅ Yes⚠️ Partly ✅ Yes❌No
Modularity*

⚠️ Partly 

✅ Yes✅ Yes✅ Yes✅ Yes?❌No⚠️ Partly ✅ Yes✅ Yes✅ Yes
Scalability & Maintainability*

⚠️ Partly

✅ Yes✅ Yes✅ Yes❌No?⚠️ Partly ⚠️ Partly ⚠️ Partly⚠️ Partly❌No
Metadata Resource Uniqueness*

⚠️Partly

⚠️ Partly✅ Yes✅ Yes❌No?⚠️ Partly ⚠️ Partly ✅ Yes❌No✅ Yes
Support for Multiple Classification Schemes*

❌No

⚠️ Partly✅ Yes✅ Yes⚠️ Partly ?❌No❌No⚠️ Partly❌No✅ Yes
Support for Cross Domain References*

❌No

✅ Yes✅ Yes✅ Yes⚠️ Partly ?❌No❌No✅ Yes✅ Yes✅ Yes
Support for the Specification of Capabilities*

❌No

✅ Yes❌No✅ Yes⚠️ Partly ?❌No✅ Yes❌No❌No❌No
Community and Tools*

❌No

✅ Yes⚠️ Partly✅ Yes⚠️ Partly ?✅ Yes✅ Yes❌No✅ Yes⚠️ Partly

Support for Automated Reasoning**

❌No

❌No

⚠️ Partly

⚠️ Partly

❌No

?

❌No

❌No

❌No

❌No

✅ Yes

OTHER

Seperation of Concerns












Metadata












Interface Capability Specification












Versioning Support












Evolving












Non-Functional


























Business Rationale to attempt VDM

Driven by technical considerations there are clear business reasons  to move to VDM  from VSS with any of the solutions lined out above.

  • Cheaper adoption than VSS due to more  standardized tooling. (Standing on the shoulders of giants instead of spinning our own)
    • Maintenance of internal tools simpler
    • More technical solutions to choose from
    • (Example: With VSS you START with a YAML parser and need to recreate all VSS specicif logic. When starting on a model e.g. based on GraphQL Schema you start at a mic higer level of abstraction when using an lib)
  • Easier extensibility: CHOSE how to use features from an existing standard/technology instead of re-inventing our own.
    • Example: How much easier would structs have been….
    • Example: We did discuss "what even is an enum" vs. allowed values in our "private universe" for an extended period of time. 


Pain points of current solution?

  • Lack of a Standard Schema Language
    • .vspec is maintained by COVESA; most mainstream developer tools (IDEs, linters, code-gen, schema registries) do not understand it.
    • Conversion into JSON Schema, ProtoBuf, or GraphQL is left to each adopter; results vary and break interoperability.
    • Need for custom tooling or translation scripts.
  • Blend of Data Model and Interface/API Definition
    • VSS tries to describe both: Data structure (tree of signals), Interfaces. Tying the two makes it hard to reuse the same model for different needs.
    • Difficulty in updating the interface layer without rewriting the signal catalogue.
  • Dot-Path Naming Without Formal Template
    • Paths are free-form text. Nothing enforces a canonical grammar like <Vehicle>.<Domain>.<Component>.<Element>.
    • Similar concepts spelled differently by different OEMs (Tyre vs Tire, Row1 vs Front).
    • Impossible to auto-infer cardinality, units, privacy levels solely from the name.
  • Interface Dependency on Attribute Names
    • Because the API layer references the full dot path as a lookup key, refactoring a name is a breaking change for every client. This inhibits evolution.
  • Custom Tooling Requirement
    • Developers must fetch and compile niche parsers just to load a .vspec file. Build-system friction slows adoption.
  • Limited Use of Mainstream, Open API Definitions
    • While sample REST snippets exist, the spec does not deliver canonical OpenAPI, GraphQL SDL or Rest API or .proto files. Each company must hand-craft them again.
  • Extension & Migration Overheads
    • Addition of new fields adds overhead to tooling and migration efforts if at custom translation layers are built.
  • Adoption constraints
    • Every existing data pipeline duplicates mapping logic
    • Nobody wants to break existing clients due to legacy feature stagnation.



  • No labels