We use cookies on this site to enhance your user experience. By using this site, you are giving your consent for us to set cookies.


You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

This is a consolidated view that merges some ideas from different approaches that have been presented so far to improve and evolve VSS into a more expressive model. The overview of the proposed approach might be consulted in this slide deck.


This proposal aims to evolve and improve the Vehicle Signal Specification (VSS). The current VSS has important limitations or misleading aspects, such as:

Vehicle?

Only passenger Car has been covered so far. However, a Vehicle can also be a Motorcycle, a Bicycle, a Plane, a Train, etc. As connected vehicles go beyond passenger cars, the COVESA model has to cover at least some of those options with proper handling of concept schemes.

Our aim: To broaden the scope of the model to cover connected vehicles apart from passenger cars and fix the handling of hierarchies.

Signal?

A signal is more commonly used in the context of signal processing, communications, and control systems, where the emphasis is on capturing, transmitting, and analyzing variations in physical quantities or patterns of data. In the realm of data processing, the emphasis is on the values and manipulation of variables or data elements rather than the concept of signals. Variables are used to store and represent data, and operations are performed on those variables to manipulate, analyze, or transform the data as needed.

Our aim: To focus the specification from the data perspective, where variables are either read or written.

Specification?

Current VSS is descriptive (informative only) and not prescriptive. A specification is typically considered a prescriptive document. It outlines specific requirements and guidelines that need to be followed in order to achieve a particular outcome. Specifications provide detailed information about how a product, system, or process should be designed, implemented, or operated. They often include technical details, measurements, performance criteria, and other specific instructions that must be adhered to.


Our aim: To have a prescriptive document to foster interoperability instead of a descriptive one.

Tasks

Update the vspec2graphql exporter in vss-tools.

  • Use click package for up-to-date CLI
  • Change the mapping
    from (current): (VSS leaf → Specific GraphQL type)
    to (desired): VSS leaf → Specific field within a GraphQL type, where a type is then the immediate parent branch

  • Support current VSS feature set functional requirements:

Functional requirement

VSS item

GraphQL correspondance

  • Model can be specified in multiple files.

Include

  • It is possible to specify schema across multiple files.
  • Command Line tool has to include all files/links.
  • Human-friendly context is provided.

Concatenated path

  • docs/_TYPE
  • Hierarchy outside GraphQL (context, field...)
  • Properties can be grouped. Hierarchical concept scheme to group properties belonging to the same area of interest is supported.

Branch type

Aggregate

Struct

  • type based
  • grouping is implicit
  • Properties whose values do not change often can be specified.

Attribute type

  • A field is specified.
  • Properties whose value might change often can be specified as observable or actuatable.

Sensor type

Actuator type

  • A field is specified. The associated value is assigned with the instance data
  • Definitions can be reused when there are multiple occurrences.

Instances

  • It is possible to specify that a field can have multiple instances. 
    enum CarDoorPosition {
  FRONT_L
  FRONT_R
  REAR_L
  REAR_R
}

type Car {
  id: ID!
  make: String!
  model: String!
  doors: [CarDoor!]!
}

type CarDoor {
  id: ID!
  position: CarDoorPosition!
}
  • Arrays or lists are supported.

Arrays (i.e., datatype[])

  • supported by the language with [ ]
    type Vehicle {
  id: ID!
  make: String!
  model: String!
  doors: [String!]!
}
  • Extended list of primitive datatypes is supported.

(u)intX, boolean, float, double, string

  • Custom scalars can be defined as an extension. In the GraphQL schema we might have something like:
    scalar Int8 @specifiedBy(url: "xsd:byte")
scalar UInt8 @specifiedBy(url: "xsd:unsignedByte")
scalar Int16 @specifiedBy(url: "xsd:short")
scalar UInt16 @specifiedBy(url: "xsd:unsignedShort")
scalar UInt32 @specifiedBy(url: "xsd:unsignedInt")
scalar Int64 @specifiedBy(url: "xsd:long")
scalar UInt64 @specifiedBy(url: "xsd:unsignedLong")

    # Here xsd is the namespace <http://www.w3.org/2001/XMLSchema#>.
  • Units and quantity kind can be specified.

Unit

Dimension

  • via types and enums
  • Default values can be specified.

Default

  • handling of default values depends on your server-side implementation
  • It can be added for informative purposes as a comment in the schema
  • Allowed values can be specified.

allowed: [‘value1’, ..., ‘valueN’]

  • Use enums
    enum Color {
  RED
  GREEN
  BLUE
}

type Car {
  id: ID!
  make: String!
  model: String!
  color: Color!
}
  • A custom redefinition of the concepts is possible.

Overlay

  • schema stiching
  • schema extension
  • Min and max expected values can be specified.

min: 0

max: 100

  • custom scalar type and directive
  • implementation of the necessary validation logic on the server-side
  • Alternative: include the information in the comment.
  • Concepts in the model can evolve.

deprecation

  • @deprecated directive



 

  • Create a graphql2vspec mechanism for backward compatibility



  • No labels

Privacy Policy | Cookie Policy