This proposal is just that, a proposal. So, contributors are very welcome. If you think that any of the ideas or assertions presented in this draft is incorrect, do not hesitate to share your own view by commenting the page or contacting the author. The principal intention of sharing these ideas is to find synergies and common agreement on the best possible next steps for the data modelling group.

This page describes the proposal to restructure the data modelling activities within COVESA. First, the current state is presented to provide the necessary context. Then, the proposal is introduced.

Current state: no clear distinction of conceptual and application areas

So far, the data modelling activities in COVESA have been mostly centred in the continuous development and maintenance of the Vehicle Signal Specification (VSS) and the tools that parse VSS into different formats. In the current setup, there is no clear description on what requirements (i.e., functional and non-functional) are driving the design of the data model. It seems that the main purpose of VSS is to serve as a naming convention for the properties of the vehicle. Nevertheless, there is little attention given to the separation of concerns:

On the one hand, there is the "conceptual area", where the controlled vocabulary has to be described and properly documented. Data models belong to this area because they describe the entities of interest in a particular domain and the possible relationships that might exits between those entities.
On the other hand, we have the "application area", where a data model is used in specific implementations (e.g., databases, applications, etc.).

Wiki Front Page > Defining the COVESA data modeling strategy and its associated artifacts > today.jpg

The figure above shows how VSS modelling belongs to the conceptual area. In order to use the specification described in VSS (i.e., a "vspec" file), one has to parse it into a specific format (e.g., JSON) by using the VSS-tools. The tools are indeed the mechanism that is making the VSS data model usable in the application area. From the practical point of view, the application area needs a specific schema that determines the structure in which the data is to be stored. By storage, in this context, we mean either long-term storage (e.g., a database) or short-term storage (RAM memory and variables' allocation during application execution).