...
| Info |
|---|
| 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. |
Abstract requirement| Criteria | Business Requirement | Product Requirement | Current (VSPEC) | Desired |
|---|
NotesMust be easy to understand and adopt. |
| - Must be human-readable.
- Must be easily understood by Subject Matter Experts (SMEs), even when they have little to no knowledge of data modelling 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 |
The approach for describing data structures is human-friendly and easy to understand and contribute to. | Ease of adoptionEase of contribution| ✅ Yes |
| Technology Agnosticism |
| |
work with a variety of widely industry adopted tools for adoption and cost.- be compatible with little effort to other artefacts and must not be a constrainer.
|
- Must work with a variety of technologies
|
Yes | Specification offers a vocabulary only. It can be exported into multiple formats and could be potentially used in any downstream system, as long as there is a tool for exporting it as desired. | Yes | ✅ Yes Via vss-tools. | ✅ Yes |
| Modularity |
| - Must allow the use (or contribution) of
|
Modularity | Adopt and contribute Ease of adoptionEase of contribution- 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 |
that will be read as a whole during the export.. However, not all components are reusable (e.g., allowed values). | ✅ Yes |
| Scalability & Maintainability |
- Ease of adoption
- Ease of contribution
- Flexibility
- Cost
|
| - 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 re use of existing models or vocabularies.
| ⚠️ 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. | ✅ Yes |
| Metadata Resource Uniqueness |
Partly
| - 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 |
| Support for Multiple Classification Schemes |
| |
No❌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 |
| Support for Cross Domain References |
No
|
| ❌No VSS tree has one dimension only. One could have multiple trees, but (currently) each tree would continue to be an independent domain. | ✅ Yes |
| Support for the Specification of Capabilities |
NoThere is the concept of Actuators and Sensors. Actuators do something when set.
|
| ❌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 | | ✅ Yes |
| Community and Tools | - Must scale across Automotive and adjacent industries
- Cost
- Ease of Adoption
- Ease of Contribution
|
No
| ❌No Limited to COVESA community and the vss-tools (mainly exporters). Any change in the modeling language requires rework of the tools. | ✅ Yes |
| Support for Automated Reasoning |
No
|
| ❌No No mechanism for semantic correctness and consistency. (e.g., what distinguishes a Car from a Motorcycle? etc.) |
Partly⚠️Partly This is a nice-to-have feature only. Thus, listed as optional. Add-ons possible. |
| Other? <Add here> |
|
|
|
|
Proposed Solutions
...
