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

Antitrust
Before we begin, we would like to make clear that COVESA is committed to compliance with the antitrust laws in all of its activities, and that it expects all participants to similarly comply with the antitrust laws.  We will not engage in--and members must refrain from--any discussion of, or understandings regarding competitively sensitive topics. If you have any doubts regarding whether a matter is appropriate for discussion, please consult with your antitrust counsel.

Open and Royalty-Free
Further, COVESA aspires to be an open and royalty-free organization. The discussions and contributions made during this session are governed by the COVESA Intellectual Property policy. If you are unfamiliar with that policy, please review it in detail prior to making any contribution that reads upon a patent.

Participants:

Late joiners:

• Richard Fernandes
• Achim Henkel

Agenda and MoM

• Welcome and introduction (10 minutes)
  • Paul introduced the background
• Round the table - how do you use APIs today?, what are your general expectations
  • Paul: Would like to hear your thoughts
  • Gunnar: My focus is on implementation/results, not aligning all OEMs, willing to discuss actual contributions. Intends to do a presentation on what has been done any why.
  • Adnan: Has prepared an overview of how things can be done in standardized way, but most important to get alignment on IFEX
  • Halim: Clarify/Align on strategy of interface pillar. Like the separation between IFEX (syntax) and catalog (VSC). Would really like to see a catalog
  • Achim: Interesting in how we can make use of VISSv2 - do we need a VISSv2 light?
  • Neil: VSS successful, but standardized way of exchanging data would be good, no need for separate integration effort
  • Tim: We see a possibility for standardization on lower levels, like zone controllors, device abstraction layers. For example, good if you can control seat heater plates.
  • Erik: In some areas like wipers we already touch "lower levels" with "system" signals
  • Stephen: Wants anti-fragmentation. Interesting in capability discussion, service orchestration
• BMW Idea: OpenAPI/AsyncAPI presentation
  • Concerns Zone ECU to Integration layer
  • Focus on Client-Server and event driven
  • Adnan presented API example
  • EriK: So you can use VSS as catalog, and then let vspec2jsonschema have attributes/variants to for example support history read, timestamps to be included
  • Adnan: yes
  • Adnan: AsyncAPI include queuing concepts
  • Mariusz: How is deployment described
  • Adnan: Have tested both integrated and separate files
  • Gunnar: AsyncAPI supports pub/sub, OpenAPI more for REST. In AsyncAPI some deployment details, like channels, but they are described in abstract manner. In IFEX even strict(er) split between interface description and transport methods / deployment
  • Adnan: You can specify

• Gunnar: Update on IFEX and VSC
  • Presented IFEX as "common" denominator when moving from one API to another.
  • Erik: Do we want "IFEX" (whatever that is) to be a subset of most other IDLs, or rather a superset, both gives challenges
  • Gunnar: It is doable to do something that converts from "expressive" to "simple". Like if the target cannot handle constraints you drop it, perhaps the tool give warnings if certain details are dropped.
    
  • Gunnar: ARXML and D-Bus prioritized areas
• GM/Halim: GM collaboration and contribution to Vehicle Services
  • Halim presented  uServices - SOA 2.0, Resiliency, ...
    
    • uProtocol, Protobuf
  • GM interested in contributing to a "uServices" catalog.
  • Possibly also a Mock service implementation and BDD feature Files
  • We have a vSS→Protobuf. Rely on protobuf custom options, can annotate topics we want to publish.
  • VSC / IFEX License discussion. Is it possible to switch to Apache?
    • Erik: We need guidance on the process from the board. So the board can make the decision, as the board will be the one that will be in problem
    • Gunnar: Will do some investigations (for IFEX)
      
• RTI: Expanding VSS beyond present footprint
  • Neil: A lot of domains, would it be possible to extend scope outside telematics.
  • Current scope limits the reach
  • There is an integration effort, could COVESA extend the scope. Control-signals, Alarm-signal
  • Create datatypes that match datatypes used in the industry
  • Improves open source story
  • Could possibly be a common language for others like SOAFEE.
  • Sebastian: Is it only a model question - more signals but on lower levels, or do we miss features
  • Halim: GM wants to see service catalogs with those types
  • Sebastian: Should this be done like EV charging, a group that spins off
  • Stephen: Need to be careful to make a distinction between VSS catalog and VSS syntax
• Conclusion - next steps
  • Achim: For the RTI proposal, would like to see a slide/deepdive
  • Halim: Want to work on the catalog part
  • Gunnar: There is Mercedes (long term) interest in catalog
  • Erik: Having some realistic services defined in VSC/IFEX would be great. Could it be an idea to try to find a few "areas" for services and see if multiple organizations are interested in any of those areas.
  • Halim: We could look at standardized VHAL properties
  • Sebastian: If you have some services already defined, it is good to put it "out" to get Feedback
  • Halim: Plan for October
  • Let us discuss hands on activities and next meetings on DEG meeting on Thursday this week
• Topics below not covered
• 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?)
• 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?
  • Service Capabilities as an abstraction mechanism (input from Stephen Lawrence )
    • MBition, BMW and GM have all expressed interest in defining interfaces (in a technology agnostic manner) that describe 'basic' capabilities (e.g. move seat to X) on which value added services are built and can be reconfigured.
    • Just as VSS can be considered an abstraction mechanism for data, interfaces (VSS+methods) describing Service Capabilities could be considered an abstraction mechanism for implementation details below. Abstracting away 'small ECU' real time or ASIL implementations for example.
      
    • Do we see value in discussing Capabilities as an abstraction mechanism? Two potential topics come to mind:
      • Grounding discussion in likely deployment scenarios. Where they sit in the stack and what is around them to meet the design goals. I mean that largely as a verticality discussion in the stack as to what it may be interfacing too (e.g. Vehicle API) rather than a transport, protocol or system architecture selection discussion. In this way powerful, but overly complex approaches can be avoided if the problem space is simpler. It also naturally links discussion to other work streams in Covesa such as Vehicle API and data architecture.
      • Grouping Capabilities into Catalogs - this is related to the Service Catalog topic as the interfaces for the capabilities may be bundled into functional groups that form the basis for a catalog that is either unique to the provider (internal + trusted partners) or in its more open form a cross industry catalog. I list the topic separately from a Common Service Catalog as if a decision to not pursue a Common Catalog is made Capabilities remains a useful organising concept.
  • 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

Notes from Ulf

Hi,

As I am missing the Interface Pillar Alignment meeting next week I would like to provide some comments that I would have liked to be brought up at the meeting.

So if you see an opportunity to bring it up I would appreciate it. If you do not find a suitable opportunity I will not hold you to it .

It is Ok for me if you think it could be added to some page related to the meeting.

BR

Ulf

HIM:

• I think that if VSS is discussed, then HIM should be part of that discussion. HIM is a superset of VSS. It is backwards compatible with VSS, as shown in the Common Rule Set and the Resource Data Rule Set in the HIM documentation https://covesa.github.io/hierarchical_information_model/.
• HIM provides two significant additions in comparison with VSS, a structured model for handling of multiple trees, AND the ability to represent not only “signal data” but also “service data”.
• The “service data part” provides support for definition of a “common catalogue for services”. An example is shown on this link https://github.com/COVESA/hierarchical_information_model/blob/master/examples/HIM_Service.v1.0.0.him.
• Ford is interested in participating in populating a “common catalogue for services” using the HIM model.

VISSv2 evolution:

• 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)

Full workshop at AMM

AMM is Oct 10-12th, possibly on Monday 9th

General Discussions Below

Open Issues:

• 4 Hour Online Workshop:  July 21? 24? 25?
• 4 Hour Online Workshop:  Sept?
• F2F at AMM 
• Number of days/date?  1 or 2?  18th or 19th?  18th allows for some to participate 1/2 day.  Due to conflict with Board meeting, they will not be able to attend on the 19th.
• Need a place/room.  Ford has some but requires a Ford employee to be present.  Currently no Ford employees are available to attend in person.
• Who can attend in person?  Do we have enough people?

Workshop Purpose

• Achieve consensus and alignment at a high level on the purpose/why of the following Interface Pillar projects. 
• Drill into interface definition, translation and exchange and emerge with a focused collaborative plan for execution with near term wins

Overview

There are 4 projects/initiatives in the DEG Interface Pillar that have emerged over the years with varying level or agreement by members.  Common agreed service and interfaces specifications that align around a common data model have become increasingly important to the connected vehicle ecosystem, as such, they have become central to COVESA.  These common interfaces and data model are critical to enabling the future.  It is time to come to agreement and align this pillar and projects in the industry.

Projects

IFEX - general interface description and transformation technology

Vehicle Services Catalog - service/API descriptions for vehicles in a standard catalog

Vehicle API - expose vehicle data as defined and described by COVESA's Vehicle Signal Specification to a  variety of agreed upon touch-points in and out of the vehicle 

W3C VISS - service for accessing vehicle information, signals from sensors on control units within a vehicle's network.

VSS - vehicle data model.

Architecture

Data Centric Architecture 

Data Expert Group Architecture Diagram

Topics

The above projects fall into these four topics:

• Service Capabilities - what does the service do?  For example, adjust seat, adjust hvac, play media, monitor driver, etc...
  • VSC 
• Service Catalog - a list of service capabilities
  • VSC
• Interface definition, translation and exchange
  • IFEX
• Data servers (pub/sub, get/set service and data model they serve) 
  • VISS
  • Vehicle API

High Level Proposed Agenda Items: (Please Comment/Propose Items)

9-10am - Overview of Interface Pillar and Purpose of Current Projects

10-12am - Drill into the requirements of interface definition, translation, and exchange

12-2pm - Execution planning for interface definition, translation, and exchange

2-5pm - Drill into requirements of Service Capabilities and Catalog

Location:

(TBD)

Cologne, Germany