Page History

...

Historical note: the minutes for the previous project, the CVII Tech Stack, can be found here: CVII Technology Stack meeting notes

7th June 2023

• Data Architecture Terminology.
  • Following last weeks discussion Steve has moved the Data Sync description from Data Store into its own section.
• Next steps in the high level work..
  • S: There has been some useful conversations at the AMM and after that built understanding. I would like to focus a discussion on advancing the high level shared work in the group.
  • Revisiting needs
    
    • Top down
      • We know there is a need for a set of shared high level views. Both internally in the group and externally as newcomers try to understand VSS and it's eco-system.
      • As we have discussed where sensible these should use logical components to avoid getting trapped down in the weeds in system architecture, product selection etc.
      • For illustration some examples:
        • Terminology
        • Common patterns
        • Building blocks both descriptive and PoC (trial, playgrounds etc.)
        • User stories and deployment scenarios illustrating the combination of the above
    • A few of us have been illustrating some examples previously and most recently.
      • e.g. Adnan last week showed some early high level diagrams in the field of VSS+methods / services / vehicle API
        • Scenario 1: HVAC service <=> gateway (vehicle API - VSS Data model) | Autosar / RT / RTOS (southbound low level parts)
          • RT area may contain proprietary information and ASIL that is contained.
          • Gateway provides abstraction API to e.g. get/set/sub VSS data
          • HVAC service provides service API to rest of system. Acting both as an abstraction and handler for the complexities of the southbound system. e.g. something like HVAC is often CAN based which brings complexity when trying to set values.
      • Felix illustrated two data store variants last week
      • Whilst thinking about it Steve was reminded of similar high level descriptions in http://github.com/slawr/vss-otaku
      • Various earlier ones: Miro, Ulf's work, AMM etc.
  • S: I propose to combine high level description with these kind of light weight illustrative examples in diagram+text form as a way forward.
    • I think I will follow the approach Daniel Alvarez has taken to his VSSo proposal of a top down logical approach, avoiding solutions and write up a proposal for some documents that can be commented and the beginning of the next phase of shared work.
  • Brain storming some classifications:
    
    • Patterns / building blocks:
  Needs
  • Top down
    • Shared high level views
      • Terminology
      • Common patterns
      • Building blocks both descriptive and PoC (trial, playgrounds etc.)
      • User stories and deployment scenarios illustrating the combination of these
        • VSS+methods / services / vehicle API
          • Scenario 1: HVAC service <=> gateway (vehicle API - VSS Data model) | autosar / RT / RTOS (southbound low level parts)
            • / set temp
      WorkBottom upPatterns / blocks
      • Data Server, Data Store
        • Variants: Mobile App, in-vehicle app, Domain Data Service
      • Integration
        • Variants: data flow bi/uni-directional, conflict resolution, latency, volume, frequency
      • Scenarios
        • Snapshots focusing on specific areas: Vehicle API, Service + gateway (as in Adnan example above), etc.
        • Data EG Deployment scenarios: IVI, Smart device, Car2Cloud, Cloud2Cloud,
        • Touchpoints
        Area snapshots: Vehicle API, Service + gateway, etc.
        • Data EG Touchpoints

31st May 2023          

• Data Architecture Terminology.
  • Steve presented updated terminology that has a first pass approach to adding Data Store sync
    • Felix suggested moving Sync into its own component description. That matches one of the options previously discussed. Steve happy to try it that way also.
  • Wide ranging discussion of the needs and approaches to getting at a flexible, reusable set of high level component diagrams/descriptions
  • Felix diagrammed some options re the Data Server and Data Store variants. Discussion included differences between a 'fat' Data Store that might be connected to a Data Gateway, versus an in-vehicle application (e.g. following MVC design pattern) that has an API and local 'thin' Data Store dedicated to it.

...