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.
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:
The figure above shows how VSS modeling belongs to the conceptual area. 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 the mechanism that makes 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. 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).
In the current setup, the whole data model is taken one-to-one and parsed as the schema for the application area. Then, it is up to the specific implementation to use custom mechanisms to ignore the overhead when only some concepts defined in the data model are required or used. Although this aspect has not shown any significant limitation until now, it becomes relevant when multiple domains are involved. Therefore, with the increasing interest in the addition of other domains apart from vehicle-specific data, it is important to define a data modelling strategy that can scale beyond tree hierarchies and vehicle-specific data.
The idea is to centre most of the data modelling activities of COVESA into the conceptual area. The conceptual area will be responsible for the standard definition of the controlled vocabulary. The specific aspects of the proposal are illustrated in the next figure, and explained below:
The simplicity of VSS has proven to be a successful approach for the continuous contribution of Subject Matter Experts (SMEs); just by modifying a text file, discussing the changes, and creating a pull request. The approach itself should be generalized to serve as a guideline to describe and maintain one hierarchy. The idea here is to abstract the modelling approach used in VSS and describe it with generic terms that might be re used with other domains.
Having an stablished approach to model a tree hierarchy does not mean that COVESA should motivate the arbitrary creation of multiple trees. Therefore, it is essential to define a simple set of rules that are to be satisfied before starting a new data tree that is to be developed and maintained by COVESA. Such a rule set can include, for example:
