This page intends to contain the agenda for next CVIS meeting (Mondays 16.00-17.00 CET) and notes from previous meeting. Below is a template for the agenda. General agenda points like discussion on PRs and issues may be skipped if discussion on prioritized topics takes too long time.

See COVESA Common Meeting Schedule for meeting link. The meeting is open to anyone.

Policies

• 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 making signal objects reusable by other signal specifications. 

Specification development page

The writing of the signal specifications are done at https://github.com/COVESA/commercial-vehicle-information-specifications.

Welcome and Compliance statement

Welcome to the COVESA CVIS Meeting!

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.

Agenda Template

• Compliance statement
• Welcome and agenda discussion - anything that needs to be added?
• Prioritized Topics:
  • xxx
• General topics:
  • Open Pull Requests CVIS
  • Issues CVIS
  • Discussions CVIS
• Other
• Prioritized topics for next meeting

Meeting notes  2024-06-17

• Compliance statement
• Welcome and agenda discussion - anything that needs to be added?
• Prioritized Topics:
  • Present the initial documentation at https://covesa.github.io/commercial-vehicle-information-specifications/
  • Discuss documentation layout.
    • Ted: looking to jumpstart the signaling work, leverage other existing work (eg FMS J1939 already mapped to VSS by Bosch) 
      Wally: centerline approach is a better way. fleet doesn't think centerline - how to represent
      ... VRMS uses driver side, front, back etc instead of centerline
      ... body type
      ... data in cargo area growing extensively
      Ted: on history of node location - which is driver side, etc. I like the center line but we also need a representation humans are more likely to use - we can potentially support more than one path 
  • Discuss 'first level' of branches for the respective trees (Tractor/Trailer).
    
    • Driver branch o separate tree? 
      • AP:Put tgether info about this for next meeting.
    • Sergey: Standards for where package is stored?
      • TMC can help?
    • Rename Tractor to Truck. Wait until checked.
    • Diagnostics - branch or tree?
  • HIM configurator demo (if time permits). 
• General topics:
  • Open Pull Requests CVIS
  • Issues CVIS
  • Discussions CVIS
• Other
• Prioritized topics for next meeting

Meeting notes  2024-06-03

At this very first CVIS meeting the framework that has been developed and proposed to be used in the development of CVIS signal specifications was presented. 

The HIM rule set for signals is used in this project, and since it is identical to the VSS rule set this framework inherits "patterns" from VSS

• The vspec file format.
• The usage of VSS-tools to transform from the vspec format to other exporter formats.

The CVIS signal trees are defined in two directory structures -

• objects directory structure: This is where the common "tree objects" are stored that may be shared between multiple trees.
• trees directory structure: Thisis where the unique trees for different domains are stored.

The directory structure for a single tree follows the VSS pattern with "#include" links in the vspec files that logically links to other files of the tree. However, to link to a file in the common objects structure the corresponding file in the trees structure is realized as a symbolic link file. This means that when the content of the file is accessed the underlying file system follows the symbolic link to the file in the objects structure for the actual content of the file. This is transparent to the entity accessing the file, so e. g. the exporter tools from VSS-tools will when used for a transformation of a specific tree access file content from the common objects files tranparently.

The framework also contains a new tool, the HIM configurator. In its current version it provides support for two types of tree configuration:

• Variation point configuration: If the tree defined by the vspec files contains data structures that are not typically used together in a specific deployment of the tree, then these can be tagged as a variability point, and the HIM configurator can be used to pick the desired structure(s).
• Instance configuration: This is an extension of the existing VSS-tools instance support that provides the possibility for a two dimensional instantiation to have unique "column instantiation" for each "row instantiation".

If this new tool is found to be useful it is planned to add support for "default configuration" later.

Wally Stegall pointed out that the example of instance configuration was not aligned with the naming conventions for axles and wheels from standards used in the industry. He will provide input for an updated example that follows these conventions.