JOIN/SIGN UP
Already a Member? |
GET INVOLVED
Understanding and Engaging in COVESA Expert Groups & Projects |
COLLABORATIVE PROJECTS
HISTORICAL
SDV Telemetry Project |
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.
Table of Contents |
---|
The overview of the proposed approach might be consulted in this slide deck. It primarily proposes to use the right tool for the job. That is, let Us use a language that natively supports cross-domain references and walk away from a proprietary language that constantly requires tooling adaptation.
This proposal aims to evolve and improve the Vehicle Signal Specification (VSS). The current VSS has important limitations or misleading aspects, such as:
Panel | ||
---|---|---|
| ||
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. |
Panel | ||
---|---|---|
| ||
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. |
Panel | ||
---|---|---|
| ||
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. |
Evolution plan:
Support current VSS feature set functional requirements:
Functional requirement
VSS item
GraphQL correspondance
Include
Concatenated path
Branch type
Aggregate
Struct
Attribute type
Sensor type
Actuator type
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 (i.e., datatype[])
type Vehicle {
id: ID!
make: String!
model: String!
doors: [String!]!
}
(u)intX, boolean, float, double, string
Unit
Dimension
Default
allowed: [‘value1’, ..., ‘valueN’]
enum Color {
RED
GREEN
BLUE
}
type Car {
id: ID!
make: String!
model: String!
color: Color!
}
Overlay
min: 0
max: 100
deprecation
@deprecated
directive