Skip to content

Complex data structures in VSS based systems

Jump to bottom Edit New page
danielwilms edited this page Jul 26, 2022 · 2 revisions

This is intended to summarise discussion and proposals of discussions similar to there https://github.com/COVESA/vehicle_signal_specification/issues/326

Background

VSS has many (prospective) users, because it's simple hierarchal model of simple signals is a good fit for automotive signals. When applying this model (and an acompanying tech stack) in a use case, often the are requirements which exceed current VSS's scop and abilities, most often complex interactions ("RPC"s) or complex data structures.

In the case of complex interactions such as complex service or method calls, it has long been consnesuns, that a data model such as VSS is not the place for them. There several technologies for this such as GRPC or maybe COVESAs own VSC.

For complex data structures no solutions/consensus has been reached. In an vehicle one is likely to consider tech stack that work by "grouping" or nesting data items into complex structures. ROS2, DDS or protbuf-based systems are an example. When using a VSS based techstack the question is can this data sources/models be used, and if so, how.

Proposed answers fall into roughly three categories (although it is more of a continuum)

  1. "Out of scope": Limit VSS to what it is today, and declare this an pthogonal problem
  2. Show some way, how to use existing VSS mechanisms and best practices in implementation to integrate data structures from other systems
  3. Extend VSS in some form to help with this.

Is it out of scope?

Basic question is how to define interface definitions and where to place modifications. The following image argues, that the standard catalogue is free of custom needs of potential use of the standard catalog. It is the basic contract, and allows structural flexibility, while sticking to the definitions. The flexibility is defined outside the standard catalog.

Solutions suggested so far

(order of "appearance in discussion", no other meaning implied)

Note that some solutions use the following model as example

ObstacleClass
{
    uint64 class
}

Obstacle 
{
    uint64 id
    ObstacleClass class
    float64 probability
}

ObstacleList 
{
    Obstacle[] obstacles
}

This is just an example, and does not imply VSS should model sich data in the standard catalogue. It does however serve as a good example of a typical data structure one might encounter in ROS2 or similar system.

Add a custom footer
Clone this wiki locally