initial proposal on VSS to dopplegänger mapping

[lulf]

Readable version: https://github.com/drogue-iot/rfcs/blob/vss-mapping/active/0023-covesa-vss-adapter.md

[ctron]

What about having the following mapping instead:

Vehicle:
  type: branch
  description: High level vehicle data
Vehicle.Speed:
  datatype: float
  type: sensor
  unit: km/h
  description: Vehicle speed.
Vehicle.Cabin:
  type: branch
  description: All in-cabin components, including doors.
Vehicle.Cabin.DoorCount:
  datatype: uint8
  type: attribute
  default: 4
  description: Number of doors in vehicle.

To:

metadata:
  name: mycar/vehicle
  annotations:
    vss/type: "branch"
    vss/description: "High level vehicle data."
schema:
  json: {
    "version": "draft7",
    "schema": {
      "type": "object"
      "properties": {
        "$children": {
          "type": "array"
        },
        "$parent": {
          "type": "string"
        }
        "speed": {
          "type": "object",
          "properties": {
            "ts": {
              "type": "string"
            },
            "value": {
              "type": "string"
            }
          }
        }
      }
    }
  }
---
metadata:
  name: mycar/vehicle/cabin
  annotations:
    vss/type: "branch"
    vss/description: "All in-cabin components, including doors."
schema:
  json: {
    "version": "draft7",
    "schema": {
      "type": "object"
      "properties": {
        "$parent": {
          "type": "string"
        },
        "doorcount": {
          "type": "object",
          "properties": {
            "ts": {
              "type": "string"
            },
            "value": {
              "type": "string"
            }
          }
        }
      }
    }
  }

I guess this approach would mean turning each "branch" into a thing, and "attributes" and "sensors" into properties.

On the pro-side, I would see that data is more coherent.

[lulf]

@ctron I like the approach, but I think we also need to add a "datatype" metadata value for the 'speed', which I felt could be put in the metadata of that node, whereas with this approach we'd have to put it in the 'payload' which feels wrong.

Also, there is no way to know if a node is a sensor, actuator or attribute because the node type is also not encoded.

[ctron]

I think the issue of the datatype could be solved by encoding this in the JSON schema?!

The node type is a different questions. Maybe can come up with an idea.

[adobekan]

Hi All,

On the VSS repo we have open issue related to conversion of vspec into JSON schema. We are looking for a setup where VSS json-schema could be used for validation in setup with openapi or asyncapi.

COVESA/vehicle_signal_specification#457

Maybe it would make sense to discuss this in one of the VSS sessions. As well it would be cool to learn about your project.

Cheers

[lulf]

Hi @adobekan ,

Thanks for reaching out!

On the VSS repo we have open issue related to conversion of vspec into JSON schema. We are looking for a setup where VSS json-schema could be used for validation in setup with openapi or asyncapi.

COVESA/vehicle_signal_specification#457

I did have a look at that issue, but wasn't sure exactly if it was a schema for describing the data/values of the VSS signals, or for specifying the signals themselves. It seemed to me that VISSv2 is also defining some kind of schema for the wire protocols.

Maybe it would make sense to discuss this in one of the VSS sessions. As well it would be cool to learn about your project.

I think that makes sense, I'd be happy to join a VSS session to learn more. Do you have some more information about when/how these sessions take place?

[adobekan]

Hi @lulf,

We have weekly VSS session, bellow you can find the details. In these sessions we are discussing PRs, issues and new ideas. If needed we can organize general exchange session where we can provide some insides about VSS.

https://wiki.covesa.global/display/WIK4/VSS+-+Vehicle+Signal+Specification#VSSVehicleSignalSpecification-WeeklyMeeting

Usual setup for VSS:

• We specific VSS (data model) in vspec files.
• We use tools to create various conversion. e.g. json, protobuf, bin etc.

If I remember correctly VISSv2 is using JSON for serialization. VSS(vspec file) define data model -> Tooling for JSON conversion -> API implementation (ViSSv2).

Also, it would great to learn about your project and how you are using json schema.

Cheers,