We use cookies on this site to enhance your user experience. By using this site, you are giving your consent for us to set cookies.


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

  • CVIS-status-2024-fall.pptxIt 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. CVIS-file-repoe. 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-12-02

  • Compliance statement
  • Welcome and agenda discussion - anything that needs to be added?
  • Prioritized Topics:
    • Retrospective and planning
      • Focus on one trailer type initially?
      • Align with existing trailer interface standards
      • Leverage existing J1939 VSS mapping
    • System design
    • Experimentation
    • Presentation of the above: CVIS-retrospect-design-experimentation.pptx
      • Discussion to be continued at next meeting in January.
    • Christmas recess
      • Dec16 and Dec 30, back Jan 13

Meeting notes  2024-11-18

  • Compliance statement
  • Welcome and agenda discussion - anything that needs to be added?
  • Prioritized Topics:
    • Meeting cut short due to low participation

Meeting notes  2024-11-04

  • Compliance statement
  • Welcome and agenda discussion - anything that needs to be added?
  • Prioritized Topics:
    • VSS car tree vs CVIS truck tree.
      • Arguments for a separate truck tree
        • The HIM model supports to rename the root node so that selected parts of the tree can have identical paths with the VSS tree.
        • The objects branch in CVIS facilitates a structured model for sharing common branches.
        • Parts of the VSS tree does not relate well to Trucks, e.g. Axle/Wheel configuration.
        • The HIM configurator provides features not available in VSS-tools, such as the assymmetric matrix configuration.
      • Decision: We will continue the development of a separate Truck tree.
        • The scenario where an app developed for passenger cars should also be deployable on a truck will be supported.

Meeting notes  2024-10-21

  • Compliance statement
  • Welcome and agenda discussion - anything that needs to be added?
  • Prioritized Topics:
    • Future of the meeting 
      • Volvo: sees interest in defining trees and also in using VISS. Still internal discussion.
      • GM going through reorg, currently monitoring this group.
      • Initial conclusion: We will continue the meeting series.
    • use vsspathlist.json to vet the content of the Truck tree.
      • Maybe not the right path forward, see question below.
    • Should a truck use the VSS tree (Vehicle tree) instead of defining a separate tree?
      • Trailer, Driver, etc. could be separate trees, but Truck should use the Vehicle tree (at least as much as is feasible).
        • How to resolve major differencies, e. g. the axle/tire location definitions?
    • Plan for how to create a first version Truck tree (trailer/bus?).
    • VISSR updated with VISSv3.0 features now supports multiple trees, e. g. Truck tree plus Trailer tree(s).

Meeting notes  2024-09-09

  • Compliance statement
  • Welcome and agenda discussion - anything that needs to be added?
  • Prioritized Topics:
    • use vsspathlist.json to vet the content of the Truck tree.
    • Cargo location - to be continued.
      • Example scenario of a truck being loaded?
    • Next meeting sept 23 is cancelled as it is the same week as the AMM.
    • Todays meeting was cut short due to low participation.

Meeting notes  2024-08-26

  • Other
    • Review AMM presentation draft

Meeting notes  2024-08-12

  • Compliance statement
  • Welcome and agenda discussion - anything that needs to be added?
  • Prioritized Topics:
    • Proposal on new domain structure built on Cargo variations. 
      • Wally: No formal standardization today. Tire as location reference. Three levels, 6 "doors", compartments. Fleets interested to discuss this. TMC f2f mid Sept. We should try to come up with proposals.
    • CVIS issues
      • Data recorder/Driver data
        • Tech stack example for driver recorder use case. HIM config tree added after the meeting. Ulf to explain in next meeting.
        • Truck/Driver trees contain metadata for the represented signals, actual (transient) data is in the state storage data buffer. Driver recorder unit may contain data from multiple drivers. How represent these multiple "driver instances" in the data model?
        • Driver recorder specific data (type, version, time-to-calibration, etc) should be represented in the Truck tree.
    • HIM configurator demo. Moved to next meeting.
  • Other
    • Status update presentation at the AMM
      • Will be presented at the CV expert group presentation on Wed. Ted will sync it.
        • Ulf create first proposal.

Meeting notes  2024-07-15

  • Compliance statement
  • Welcome and agenda discussion - anything that needs to be added?
  • Prioritized Topics:
  • Other
    • Summer recess
      • Skip the meeting on July 29. Next meeting Aug 12. 
    • Status update presentation at the AMM
      • Ulf willing to present. Wally interested. Possibly Ted. Ulf to submit to Paul's request on presentation abstract.
    • Trucking Industry Overview, Urban Jonson, SERJON (includes truck categorization in NA,  see  EU truck categorization

Meeting notes  2024-07-01

  • Compliance statement
  • Welcome and agenda discussion - anything that needs to be added?
  • Prioritized Topics:
    • CVIS issues
      • Driver data - follows the driver as he goes between assets. Hours driving, time of break, driver settings,
        • Europe - driver has physical card, as above, speed...
      • Diagnostics data - OBD CARB biased term; fleet like actionable info as well as raw data; DTC plus location code important
    • Continue tree definition discussion.
      • Heavy duty Europe X tons? Class 1: < 3.5 ton, Class 2: 3.5-12 tons, Class 3 > 12 tons
        • Should Light trucks be separate tree?  One tree for all classes is likely => Do not use Heavy duty in naming.
      • Create a Bus tree as the signal set etc are quite different.
    • allowed definitions now in the common objects folder. himConfigurator can be used to substitute references to external Datatype tree with actual definitions.
    • HIM configurator demo. 

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.

  • No labels

Privacy Policy | Cookie Policy