Versions Compared

Key

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

...

  • It is expected that all meeting participants have read the compliance statement. Every meeting will start with a reminder.

  • Every meeting will start with appointment of note taker. Notes can be on-line, or off-line and if so mailed to moderator within 24 hours. Fair scheduling, i. e. all should take turn. A reason for not taking it is if one expect to speak much at the meeting.

  • Strive for backwards compatibility. Non-backwards compatibility, anyone can ask for a voting, requires 2/3 of votes to be accepted.
  • VISSR deep technical discussion should be handled on the VISSR Slack channel and its Github Issues page.

Specification development page

The writing of the specification is done at https://github.com/COVESA/vehicle-information-service-specification.

Welcome and Compliance statement

...

  • Compliance statement
  • Welcome and agenda discussion - anything that needs to be added?
  • Agenda discussion - anything that needs to be added?
  • Prioritized Topics:
    • xxx
  • General topics:
    • Open Pull Requests VISS
    • Issues VISS
    • Discussions VISS
    • VISSR information
      • Major PRs
      • Q&A
  • Other
  • Prioritized topics for next meeting

Meeting notes  2024-09-16

Meeting notes  2024-09-02

Meeting notes  2024-08-19

  • Prioritized Topics: 
    • Review JSON schema addition
    • Review PRs
  • Other
    • Review AMM presentation draft

Meeting notes  2024-07-08

Meeting notes  2024-06-24

  • Prioritized Topics: 
    • Roadmap creation
    Prioritized Topics:
    • xxx
  • General topics:
    • Open Pull Requests VISS
    • Issues VISS
      • Discussions VISS
      • Open Pull Requests VISSR
      • Issues VISSR
      • Discussions VISSR
    • Other
        • Three part documentation proposal
          • Steve: In Transport doc - mention for each protocol what is the difference to primary description.
          • Versioning of Payload encoding?
          • Decision: Go with the three document structure (can be reversed if found bad).


    Meeting notes  2024-06-10

    • Prioritized Topics: 
      • Roadmap creation
        • New features for the next VISS version, continued discussion
          • Payload defintions instead of transport protocol definitions could be the first feature to add?
            • Keep the documentation structure with two docs - CORE and EXAMPLES?
            • How define the payloads? For each method (get/set/..), define the mandatory and optional payload fields of request/response/subscription messages.
            • Serialization definition? JSON in VISSv2. Needs more precise definition?
          • File transfer support? Download/Upload?
          • More filters - event when buffer is full, ...
        • VISSR issues
          • Polish documentation. Attract more users?
            • Docker containers, open data sets, 
          • AGT not well integrated with Docker
          • Complicated to generate a binary VSS tree. Pre-built?
          • Concurrency bugs in server?
        • ISO standardization of VSS (VISS)?

    Meeting notes  2024-05-27

    • Prioritized Topics: 
      • Roadmap creation
        • New features for the next VISS version, continued discussion
          • Payload defintions instead of transport protocol definitions could be the first feature to add?
      • Other
        • Low attendance due to US holiday.
      Prioritized topics for next meeting

    Meeting notes  2024-05-13

    • Intro: Names, company, contribution?
    • Prioritized Topics: 
      • Roadmap creation
      • New features for the next VISS version 
        • VISS tied to VSS and passenger vehicles. As there is a need for additional information models, maybe adapt for Hierarchical Information Model (HIM) proposal 
          • ATA TMC (several attendees from their Data Science team in attendance) express interest in additional data models
          • Question on how to accommodate VSS within HIM, explained as a higher level wrapper and backwards compliant
            • Similar rules to be applied to the other data models
            • Resistance to extend VSS beyond vehicle signals
            • Wally: either HIM, VSS overlays or perhaps a third approach could work for ATA needs
              • Suggest we define what we want the model to support to evaluate
              • Stephen: is the first goal is the semantics side - metadata?
              • Diagnostics capabilities, trailer or specialty equipment are the data models being discussed
            • Peter: there are existing services work within COVESA that need alignment with this
            • Ulf: we may end up with merging of ideas or competition and see which prevails 
            • OpenAPI approach wasn't conducive to automotive purposes, hence VISS
        • Define payload that can be transported across multiple protocols, could possibly support OpenAPI (would need to add subscriptions) 
      • Suggest we solicit input from AutoSAR (Erik) and BMW on Android (Adnan or Andre)
    • Meeting split between VISS (specification) and VISSR (Reference implementation of VISS)
      • Informational update on VISSR on regular call, deep technical as time allows or call participant warrants otherwise details will be on slack & github
      • Also welcome questions from participants, can inform the specification work as well
      • Tagged releases
    • VISSR branching/release strategy for next VISS version
    • Policy notes reviewed
      • Paul/Stephen: Reminder to please add company name in your display name.
    • CVIS Charter

    ...