Weekly MeetingVSC weekly development meeting: Meeting Link
You will find recorded meetings here.
Overview
Mission
Create a standardized, extensible vehicle service catalog, and associated tools, to enable protocol-, language-and specification-agnostic interoperability between ECUs, infotainment, and cloud.
- Standardized – Version managed service specification with regular releases
- Extensible – Proprietary extensions can be added to an open-standard catalog
- Tools – Auto-generate network code and APIs from service specifications
- Specification agnostic – Translation to and from multiple specification formats
- Interoperability – Enable seamless communication in the vehicle and over the air
Presentations from April 2022 All Member Meeting
View file |
---|
name | covesa_amm_2022_-_vsc.pptx |
---|
page | COVESA All Member Meeting ~ April 26-28, 2022 |
---|
height | 400 |
---|
|
VSC And VSS Alignment
View file |
---|
name | vss-disc.pdf |
---|
page | COVESA All Member Meeting ~ April 26-28, 2022 |
---|
height | 400 |
---|
|
Widget Connector |
---|
url | https://www.youtube.com/watch?v=m-VdqYwtlqs |
---|
|
October 2021 AMM Presentation - Excellent Background on Current Thinking
Info |
---|
Jump to 8:04 for VSC. Confluence won't let you embed a YouTube link with a start time. |
Widget Connector |
---|
url | http://youtube.com/watch?v=7onbbvg_U9s |
---|
|
Goal/purpose
Repeat the idea of VSS (proposed data-description-standard, and proposed standard-catalog of data), to propose a standard interface/service description language for use with standard-catalog of services, but also to describe all other types of interface definition. One common interface language.
Meeting information
- We are in the process of setting up a new meeting structure in WebEx and/or Zoom
TODO: also link from git repo to the meeting info. Github wiki is used for VSS, do similarly for this
Ongoing design/discussion points
For details it could be best to track the GitHub issues in VSC and VSC-tools
- Stakeholder input: #1 preferred source-language for interface descriptions. e.g. Franca IDL or other, or do companies use gRPC directly, etc.?
- Stakeholder input: Interesting mapped technologies, input-and-output formats and bindings. (e.g. gRPC, SOME/IP, DDS, HTTP/REST based remote procedure call protocols, ...)
- How to reference VSS signals in VSC model
- Error handling feature built in
- Build in some support for success/error return
- Note: Method invocation errors that are related to the particular target/protocol are separate from this mechanism. Those are defined in target/protocol separate specification.
Example: "method name not found" on a web request. - Support a global error type enum. Configurable. More than one.
- Specify which errors are expected/applicable per method
- Error feature is optional but best-practice. Out-parameters still exist of course, and can be (mis)used to report invocation success
- Next: Make syntax proposal. Consider is this feature reasonable to translate/map to all IDLs, target environments that we envision. How is it mapped?
- Franca <-> VSC YAML mapping
- document, compare keywords
- Franca further development to a "next version"?
- Interesting if desired new features are not covered. E.g. error-feature might be one such thing.
- Set up documentation on GitHub Wiki instead, or as a complement
- Terminology, names. Coin a useful name for the "VSC IDL language"
- Review OpenAPI, AsyncAPI, gRPC/protobuf, Franca, etc. for syntax similarity (names of things) and feature coverage. Find alignment oppportunities.
- One stakeholder suggested: Could OpenAPI be extended to cover non-REST. I.e. "OpenAPI-next" == VSC language? Rationale: OpenAPI known outside automotive.
Frequently Asked Questions:
- Why another IDL?
- Why is adopting <insert existing choice> not enough? Or is it?Several answers can be found in previous presentations/slide decks
References, previous presentations...
Deployment: