Page History

...

• AMM reminder: upload slides here COVESA All Member Meeting ~ October 10-12, 2023
• Central Data Service Playground
  
  • Goal: kick-off and work breakdown

Minutes:

• Christian input:
  • It would be good to define problems to be tackled down to guide project.
  • Similarly find use cases to illustrate/investigate problems
  • The group might maintain a set of use cases as a set of validation cases for the playground, e.g. made change but validation still passes.
  • Steve: Christian Muehlbauer please consider adding (better version of my poor notes) this to the project page as input
• Ulf: VISS designed for wide range of use cases. This flexibility means that use cases may not be critical.
• Ulf: Simulation only or deploy on h/w in a car?
  • Steve: personally I think both is possible depending on what is being investigated.
• Humza: To what extent will the Playground contain application code to allow experimentation? Would there be controls demonstrating different setups for example.
  • This lead to discussion of resources vs goals.
  • Steve: we are resource constrained. Personally I would have the base code implementing the playground, e.g. VISS+store and then alongside have the PoCs etc that show it being exercised. Then you have a seperation of intent and you avoid problems of maintaining use case PoCs over time if that is not required.
    • Writes following tree to illustrate:
    • Playground functional base block: e.g. VISS + store
    • PoCs, e.g:
      
      • Large ECU sync PoC
        • Multi instance of the containers representing ECUs
        • With some marshal app code to exercise it
      • Internal trial PoC
        • Figure out the latency of cool new protocol
  • Christian draws good point to his earlier comment about validation cases. We might have some official 'exercise cases' that are maintained. Others agree based on discussion. The project/data-arch group may have some validation use cases that are maintained along with functional base block for validation and as they illustrate useful concept. Examples used for illustration in the discussion (not agreed list)
    • High frequency data feed
    • Medium frequency data feed
    • Hello World
  • Above discussions show that maintaining doc along side is important. Doc for use of functional base block, but also doc for the use cases. Supports understanding and adoption.
• Project management / operations
  • PM task tool
    • Steve: what do we use?
    • Paul: suggest github. JIRA hard to discover and hidden away.
    • Richard: we intend to use github in AOSP project.
    • Ulf: github
    • Steve: I dislike that github kanban boards have poor support for comments and know JIRA well, but happy to go with majority.
    • Steve: how do rest feel?
    • BMW, MongoDB happy with github
    • Decision: Start with github kanban for project management
    • Action: Steve to create. Others to fill in their backlog ideas once announced.
  • Comms
    • Steve: what to use? We should try and move more of the day to day discussion online to support 24/7 and different time zones.
    • Decision: Covesa Community Slack. Create a new data-architecture channel.
    • Action: Steve to create new channel and announce it.
  • Phases
    • In workshop we talked about using incremental delivery to iterate the playground. What are the major early phases?
    • Discussion favours doing simple early PoC code to help decide on source and project organisation.
    • Decision: Needs refinement in the kanban board but first phase is 'create Playground PoC' along lines above.

18th October 2023

Agenda:

• Meeting invite: Christian, Sri
• AMM wash-up
  • Goal: what went well, could be better, sessions/input we should be aware of
  • General including input from related sessions, e.g. Ulf's southbound session
  • Data Architecture workshop
    • Upload slides here COVESA All Member Meeting ~ October 10-12, 2023
• Central Data Service playground proposal
  • Goal: move towards project kick-off and work breakdown
  • Further input?
  • Agree next steps
    • Do we have general agreement/understanding on what we are doing regarding the service itself initially (the big picture What) and can move to getting the ball rolling on the details (e.g. checking docker status and choosing requirements of some use cases) of the how?
  • How to organise? e.g. Kanban, JIRA. Account for schedules and time zones by doing what we can online.
• AoB
  • Adnan: serialisation
    • Looking at msg serialisation between vehicle and car. Requirement to keep flexibility in terms of what is sent.
    • BMW will have a researcher looking into this. Can something be done in open? Payload only.
    • Looking for input.

...