Page History

...

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

14th June 2023

• Knowledge layer (45 min)
  • Christian Muehlbauer has noted that in the Covesa organisation slides showing the Data EG pillars that the knowledge layer is listed under the Data Models / Ontologies. Should it be in Data Architecture instead/as well?
    • Discussion of the question. Christian has a draft diagram showing Machine Learning and Semantic Reasioning (requires ontologies like VSSo) acting on VSS data as a means for deriving high level knowledge. This is an example of how the Knowledge Layer is also applicable to Data Architecture. Ulf likes the diagram.
    • Conclusion is everyone agrees that it also applies to Data Architecture in such a context and could be considered part of the scope. Open question as to how to include it in such a summary slide. For sure it could be part of any Data Architecture pillar description that was not so space constrained.
• Data Pattern / Data Architecture proposal (15 mins)
  • As discussed last week Steve has started work on a proposal for Design Pattern and Data Architecture documentation which can be found here https://wiki.covesa.global/x/boA8B
  • Principal aim is to use it facilitate what to create.
  • Short on time so quick run through. It's still a WIP towards a draft. Please edit or add in-line comments.

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:
      • 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,
        • Data EG Touchpoints

...