JOIN/SIGN UP
Already a Member? |
GET INVOLVED
Understanding and Engaging in COVESA Expert Groups & Projects |
COLLABORATIVE PROJECTS
HISTORICAL
SDV Telemetry Project |
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. |
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.
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.
Criteria | Requirement description | Current (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 |
| ✅ Yes | ✅ Yes | Must have | |||||||
Technology Agnosticism* Interoperable and flexible across various platforms, devices, or environments, not tied to specific vendors, technologies, or frameworks. |
| ✅ Yes Via vss-tools. | ✅ Yes | Must 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. |
| ⚠️ Partly Specification can be split into multiple files. However, not all components are reusable (e.g., allowed values). | ✅ Yes | Must have | |||||||
Scalability & Maintainability* Ability to grow and and handle increasing demands while being easily understood, modified, and maintained. |
| ⚠️ Partly
| ✅ Yes | ||||||||
Metadata Resource Uniqueness* See note |
| ⚠️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:
Examples:
Practical usage in data modeling:
Importance: Having clearly defined concept identifiers ensures:
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* |
| ❌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* |
| ❌No VSS tree has one dimension only. One fixed hierarchy! | ✅ Yes | Examples are needed. | |||||||
Support for the Specification of Capabilities* |
| ❌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* |
| ❌No Limited to COVESA community and the vss-tools (mainly exporters). Any change in the modeling language requires rework of the tools. | ✅ Yes | Must Have | |||||||
Support for Automated Reasoning** |
| ❌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
| ⚠️Partly | ✅ 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 |
| ⚠️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 |
| ❌No | ✅ Yes | Already covered above. See "Scalability & Maintainability" Should be added explicitly to "Scalability & Maintainability" Paul Boyes | |||||||
Non-Functional |
| ⚠️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 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.
Criteria | VSPEC | GraphQL | SKOS (RDF) | GraphQL + SKOS | UML (XMI) | OMG IDL | Protobuf | OpenAPI | SHACL (RDF) | JSON Schema | OWL (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 | |||||||||||
https://www.omg.org/spec/IDL/4.2/About-IDL
https://www.dds-foundation.org/omg-dds-standard/
https://marketplace.visualstudio.com/items?itemName=RTI.omg-idl
Driven by technical considerations there are clear business reasons to move to VDM from VSS with any of the solutions lined out above.