Round the table - how do you use APIs today?, what are your general expectations
BMW Idea: OpenAPI/AsyncAPI presentation
Gunnar: Update on IFEX and VSC
GM/Halim: GM collaboration and contribution to Vehicle Services
Discussion on work-areas for the interface pillar. Target is to identify the work-areas and how important they are considered by participating organizations. Some possible work-area proposals below
Common IDL
Is there a value in agreeing on a "common IDL format" (existing or new) that could be used for describing services?
If so, why? Some possible reasons:
Foundation for a common catalog
Foundation for implementation of reference cliensts/servers/SDKs
Simplifies translation/mapping between other IDLs,
IDL translation capabilities
What type of translations are of interest?
What do you need? Just a specification (like ARXML to Protobuf), or actually also tooling?
What are you willing to work-on?
Common service catalog
Do you see a value in a common catalog for services (like for example FOTA, diagnostics, ...)?
Do you think it actually is feasible? What is needed for success? The catalog part of VSC has so far not really been any success!
Do you see any candidate areas where chances of success is bigger than for others?
Reference implementations
Do you think COVESA shall be active doing reference implementations for Client/Servers/SDKs? Or is that better handled by other downstream projects (like W3C and Eclipse SDV)
VSS relationship
Shall COVESA define one or more APIs (using the "Common IDL") for accessing VSS data?
As a real API definition, or just as requirements on an API definition. Potential requirements include:
Support for atomic read/write/subscribe of multiple signals
Support for both "south" (the one providing values or actuating requests) and "north" (the one reading values and requesting actuation) i.e. support both for reporting actual value and for setting wanted value.
Metadata to be provided (like timestamp)
Error codes or scenarios - why was an actuation not fulfilled?
If so, focusing on thin API (like VISS and KUKSA.val) or fat (one method per signal)
Need for possibility specifying services that references VSS-signals, for example service to set 3 VSS signals in a single call
Relationship to COVESA-AUTOSAR Vehicle API discussion
Target: Agree on what is feasible to focus on in the short term