Agenda July 25th (Virtual),  14:00 -18:00 CET / 8am - 12pm ET / 5am - 9am PT

Please add items to agenda

• Two goals
  1. Aspect of common catalog
  2. Tooling for translation
• Decide on subsequent meetings
• How will we relate to the COVESA-AUTOSAR Vehicle API discussion

Use them as base for the discussion

Erik 2023-07-18: Trying to provide a more detailed agenda proposal, to be discussed at DEG meeting this week

• Welcome and introduction (10 minutes)
• Round the table - how do you use APIs today?, what are your general expectations
• BMW Idea: OpenAPI/AsyncAPI presentation
• Gunnar: Update on IFEX and VSCWelcome and introduction (10 minutes)
• 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
  • What is possible to achieve until Spring AMM
• Way forward
  • F2F September - next to ETAS connection?
    • If so - time and agenda
  • Session at AMM (Monday?)

...

• The existing VISSv2 uses VSS as the data model. It lends itself very well to being evolved to use HIM instead. This combination would provide a comprehensive interface standard for both signals and services.
• The VISSv2 reference implementation (https://github.com/w3c/automotive-viss2/tree/master) now has support for using gRPC for the transport of protobuf encoded VISSv2 messages. This could be added to the VISSv2 evolution specification, which then very well could become the “common IDL format” (= the protobuf part).
• Ford is interested in participating in driving the work on evolving VISSv2 to use HIM instead of VSS. Which can be hosted by either W3C or COVESA.
• Ford is also interested in participating in a reference implementation of the evolved VISSv2 spec. Which can be hosted by either W3C or COVESA.
  • (Could start from VISS ref impl, target protocols could be as for VISS; gRPC, Websocket, mqtt, HTTPS, current programming language is Go, could be different.)

September Session

Candidate date and place is Sept 26 Stuttgart-area (before ETAS connection, Bosch/ETAS can most likely arrange a room)

...