Versions Compared

Old Version 7

changes.mady.by.user Daniel Alvarez

Saved on

compared with

New Version Current

changes.mady.by.user Daniel Alvarez

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

What?

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.

Why?

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

Panel
titleVehicle?

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.

Panel
titleSignal?

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.

Panel
titleSpecification?

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.

How?

Image Added

Evolution plan

Image Removed

:

  • Roundtrip compatibility - Improve the current structure of the GraphQL export and provide a mechanism to move back from the schema to a vspec. 
  • Transition phase - Support both workflows by keeping them synchronized (i.e., deprecate the current VSS modelling approach).
  • Unified modelling approach - Discontinue the use of the current VSS modelling approach for the weekly maintenance meetings.
  • Semi-automated processes - Extend the tools to foster the adoption of the community in- and out-side COVESA. 
  • Features' addition