...

• Agenda discussion - anything that needs to be added?
• Prioritized Topics:
• Decision on old open PRs
• Open Pull Requests VSS
• Open Pull Requests VSS-Tools
• Issues VSS
• Issues VSS-Tools
• Discussions VSS
• Discussions VSS-tools
• Prioritized topics for next meeting

Meeting notes  2024-04-18 (April 2024 AMM Working Session on Raw vs. Derived signals):

• The definition of derived signals is not as straightforward as the definition of raw signals
  • Distraction levels of 0% and 100% are clear but what does 66% or 34.5% distracted really mean?
  • Should distraction really be represented as a percentage? Or, perhaps an enum?
• Units are one way in which clarity can be achieved
  
  • Requires introspection (ability to ask the model) support in the API or equivalent
• Even if enums are used to "bucketize" or categorize the values, interpretation of what each bucket means is still important or not necessarily clear
  • For example, what is a crash and severity of crash can have different interpretations depending on culture, context, etc.
    
  • Same for aggressiveness
• How could we make available information on how a signal is derived?
  • Where it may be needed or useful
  • How can this be expressed to the user?
  • Does it need to be digital?
• Margins of error and calculations may vary in time
  • Remaining distance based on fuel consumption varies over time
  • Some signals from which a derived signal is generate may become unavailable or become available again
  • The rate of incoming signals may affect the derivation
  • How do we plan to repesent this?
• Even an OEM may not know how some signals are derived
  • The Tier-1 may have their own way of doing the derivation and this is not available to the OEM
• What is a raw signal?
  • Is there such a beast?
  • Clearly there are some, but perhaps the great majority of signals are derived?
• Would adding all the information discussed above impact simplicity?
  • One main goal of VSS is simplicity
  • Perhaps less precise definitions of signal values is actually simpler
• Should we define the set of parameters to evaluate in order to decide if a derived signal should be added to the signal catalog?
  • Is portability of applications (where they can rely on a "standard" definition of a signal) a concern?
    • And therefore should the signal catalog only contain clearly defined signals as opposed to leaving definition to interpretation?
  • Options to consider:
    • Determine if the signal should be made part of the catalog or left for manufacturers to add using overlays
    • Require that signal definitions refer to a standard
    • Allow liberal interpretation, but mention in signal definition comments that interpretation is left to the implementation

Meeting notes  2024-04-09:

• Crash detection/events - car immobilized
  • Stefan: Do we have anything?
  • Adnan: PRs welcome
  • Erik: Sometimes we create a temporary *.md file and add it to PR for discussion.. PPB to put down initial thoughts in *.md
• AMM
  • No regular VSS meeting next week
    • Erik has asked Paul to delete
  • VSS Deep Dive being prepared by Sebastian Schildt
• Head& Eye
  • https://github.com/COVESA/vehicle_signal_specification/pull/731
  • Idea - use Occupant as top branch, like Vehicle.Occupant.Row2.PassengerSide.MidEyeGaze.Azimuth
  • PPB: Instance handling
• VSS-tools
  • A lot ...

...