VSS profile

[erikbosch]

Related to #436

This is an example on how VSS-tools possible could define a profile syntax and collect contributed profiles. Published as an example to be discussed at VSS meeting March 4th

[sschleemilch]

I think the idea is valid.
I would have the following proposal for specifying a profile and reusing the Vehicle.Speed location example:

source:
  scope:
    - "*"
  mandatory: true
  schema:
    type: object
    required:
      - xpos
      - ypos
    properties:
      xpos:
        type: array
        items:
          type: object
          properties:
            a:
              type: number
            b:
              type: number
      ypos:
        type: number

Explanation

Having the element name itself as a key would be fine for me.

scope

Defines on what parts that thing should apply to. I was thinking about either specifying branch types here (branch, attribute, sensor) or a list of wildcard paths (Vehicle.*, Vehicle.Cabin.Door.**.Window) or maybe both. Opinions welcome.

mandatory

Probably makes sense to keep like in your proposal

schema

Here I thought since we are not talking about VSS things anymore, we could just use a normal JSON schema description.
This would introduce the complete power of expressiveness of JSON schema and is pretty simple to validate.

[SebastianSchildt]

I want to suggest to take the chance to define profiles in a "existing" language instead of rolling our own.

GraphQL interfaces come to mind, they even seem to be composable

interface QualityProfile {
   quality: Int! //maybe uint16!....
   qualityDescription: String
}

interface DBCProfile {
   DBCSignal: String
   DBCtransform: DBCTransform
   DBCdescription: String
}

type DBCTransform {
  transform: String
  mapping: ...
}

The advantage being: It seems a simple way to specify what a metadata you want, it IS defined, so in case of corner cases (what are the rules when field names collide?), we can look them up instead of making new ones.

While this would of course fit with somebody using GraphQL, I think it is not contingent on that: This works fine with VSS as is, and I think it is not harder to parse than the custom format suggested in the PR.

Taking the example from the PR

  source:
    mandatory: true
    description: "Gives some info"
    xpos:
      list: True # Indicates that children may be in a list
      a:
        datatype: uint8
        description "A value"
      b:
        datatype: uint8
        description "B value"
    ypos:
      datatype: uint8
      description "Y value"
  quality:
    datatype: uint8
    description "Q value"

Might translate to sth like

interface QualityProfile {
   Quality: uint16!
   source: QualitySource!
}

type QualitySource {
  xpos:  [Int2Tuple!]!
  ypos:  uint8!
}

type Int2Tuple {
  a: Int!
  b: Int!
}

As I am not an expert in this technology I'd like an opinion @jdacoello , whether this is feasible or should be considered "misuse".

[sschleemilch]

I want to suggest to take the chance to define profiles in a "existing" language instead of rolling our own.

GraphQL interfaces come to mind, they even seem to be composable

interface QualityProfile {
   quality: Int! //maybe uint16!....
   qualityDescription: String
}

interface DBCProfile {
   DBCSignal: String
   DBCtransform: DBCTransform
   DBCdescription: String
}

type DBCTransform {
  transform: String
  mapping: ...
}

The advantage being: It seems a simple way to specify what a metadata you want, it IS defined, so in case of corner cases (what are the rules when field names collide?), we can look them up instead of making new ones.

While this would of course fit with somebody using GraphQL, I think it is not contingent on that: This works fine with VSS as is, and I think it is not harder to parse than the custom format suggested in the PR.

Taking the example from the PR

  source:
    mandatory: true
    description: "Gives some info"
    xpos:
      list: True # Indicates that children may be in a list
      a:
        datatype: uint8
        description "A value"
      b:
        datatype: uint8
        description "B value"
    ypos:
      datatype: uint8
      description "Y value"
  quality:
    datatype: uint8
    description "Q value"

Might translate to sth like

interface QualityProfile {
   Quality: uint16!
   source: QualitySource!
}

type QualitySource {
  xpos:  [Int2Tuple!]!
  ypos:  uint8!
}

type Int2Tuple {
  a: Int!
  b: Int!
}

As I am not an expert in this technology I'd like an opinion @jdacoello , whether this is feasible or should be considered "misuse".

JSON Schema would be an "existing language".
How would you connect the GraphQL Types to the VSS Elements?

[SebastianSchildt]

".

JSON Schema would be an "existing language". How would you connect the GraphQL Types to the VSS Elements?

Agreed on JsonSchema.

For bindng/limiting GraphQL Types: Basically I would only allow „primitive VSS“ Types as member datatypes. So the „Int“ in the tuple toy example was probably not good, should have been one of the VSS types (similar lije in JSONSchema you would likely not limit yourself to native JSON datatypes only.

Nesting of Types (if we allow it) woul easily transfer to the vspec yaml view, similar to how in current VSS vanilla overlay for DBC everything is grouped under dbc2vss or vss2dbc

[jdacoello]

I fully agree that an established language with enough community tools should be the way to go instead of implementing this feature with yet another extension to the proprietary vspec language.

@SebastianSchildt: the purpose of an interface in GraphQL is to define a structure that could be reused. Such that other types that implement the interface must contain the exact same fields plus the extra ones. Here is a nice example of it. So, in one way or another, it is possible to represent in GraphQL the information that is being discussed in this threat.

As @sschleemilch said, json schema is another valid alternative (for a language with standard syntax) that has plenty of open-source tools. It is actually more expressive and powerful than GraphQL. However, json is verbose while GraphQL SDL is simple and compact (i.e., friendly for non-experts).

So, standard and well adopted languages exist. The question is how to keep the link between current vss approach and these alternatives? This is also one of the reasons why I have been suggesting the enforcement of unique names for branches in the current vspec. Because they would make the transition smoother. For example:
The concept Charging in vspec, and
type Charging in GraphQL would be the same as there cannot exist two items called Charging within the same namespace.

At least we are agreeing that the language must be anything but a proprietary custom extension.
I personally like the GraphQL SDL. I analysed the feature set and tried to be as objective as possible. I could conclude that it offers the best trade-off for the features that are currently part of vspec and for those that are under discussion. Nevertheless, if the majority of contributors prefer another alternative, I would also be in favor as long as we are moving forward.

[sschleemilch]

In the end I am also fine with GraphQL also regarding the possible future of VSPEC being modelled completely using GraphQL...

[erikbosch]

I agree that if we want to define a syntax for defining profiles. it should better be something that would work in GraphQL, as that seems to be the language that most are interested in for "VSS next gen". For now there anyway does not seem to be anyone that has interest in developing a profile validator for vss-tools, it rather seems that the validation (if any) will happen in the tool using the info (Kuksa, VISSR, ....)

The new PRs that recently has been submitted focus on vspec/json examples and informal definition of the profiles, so that is maybe a sufficient scope for now.

[slawr]

Re the CAN mapping I can think of a few projects defining something in that regard:

1. Kuksa CAN provider - presumably the mapping used here
2. VISSR feeder template has a CAN capability
3. AoS Edge has a boardnet to VSS feature in its VISS implementation - can't recall the details
4. Possibly something from the work Tietoevry did for the early Autosar gateway PoC?
5. Do Autosar WG Cloud have something from their work subsequent to 4?

I wonder also if there is something useful to be taken from the upstream CAN eco-systems? Projects such as Kayak and CANMatrix and the SocketCAN family, or groups such as CANopen