Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: 30th nov update

...

  • Project status
    • Majority of VSS call taken up with VSS struct support discussion. Best practices good/bad one of the focus points next.
    • Ted summarised VISS/VSSo updates
  • Data Arch Theme discussion
    • GraphQL
      • Andre: Nice for query. Problematic to have generalised set method. Have to do heavy development in schema for setter. Complicates cross vehicle model support.
      • GraphQL still interest in the landscape but VISS is the more obvious first priority
    • Discussion of existing high level in-vehicle data architecture diagram. What it was created for and its limitations.
    • Ulf showed how his V2C proposal could address data needs
    • (Data) Design Patterns
      • Discussion of in-vehicle architecture leads back to the existing topic of local data reduction at the edge/within function and smart exchange between functions
        • Local processing generating higher logic data possibly at lower frequency, e.g. engine management does local monitoring and external then externally reports decisions
        • Reduces in-vehicle network traffic
        • Reduces costs associated with data transmission to the cloud
        • This is an obvious candidate for a design pattern: benefits, how it may be done, VSS/VISS role in that.

23rd November 2022

  • Project status
    • VSS struct support heads up
    • VSSo meetings have restarted
    • Status of the collaboration between Covesa and Autosar and work on Autosar Gateway/Vehicle API
  • Data Arch Themes
    • Given prior input on peoples interest Steve outlined an early roadmap for work that could create both PoCs and data patterns and which is easily adopted into related Covesa projects such as the Autosar Gateway and Android.
      • VSS Data Server
        • GraphQL (Covesa C++)
        • VISS Data Server
        • Aim: demonstrating two possibilities
      • VSS Data Store
        • Connection to Data Server
        • Embedded app DB (e.g. Realm), 'full' DB (e.g. IoTDB)
        • Aim: demonstrating two possibilities
      • Target: x86 (e.g container) => embedded h/w
    • Discussion:
      • Piotr: suggests adding VM to x86 targets as it allows investigation of concepts like VirtIO that may be harder in containers
      • Ulf: It makes sense to follow a pluggable architecture
      • Piotr makes the good point that the data architecture diagrams will need to evolve to cover higher function needs such as the proposed Vehicle API as well as the current coverage for data.
  • AoB
    • Ulf presented his proposal for a thin API approach to the Vehicle API requirements for the Autosar collaboration.
      • This is not yet public. He will work on enabling that with goal to present it to the Autosar working group once it gets going.

...