JOIN/SIGN UP
Already a Member? |
GET INVOLVED
Understanding and Engaging in COVESA Expert Groups & Projects |
COLLABORATIVE PROJECTS
HISTORICAL
SDV Telemetry Project - On Hold |
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. |
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. 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:
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 and natively support cross-domain references.
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.
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.