The minutes of the meetings for the Data Architecture and Infrastructure pillar of the Data Expert Group.

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

5th March 2025

Agenda:

• Status sharing including Playground Kanban
  • CAN feeder progress
  • Christian's Docker proposal for examples
• Spring AMM planning for Data Architecture
  • The deadline for technical track talks is end of next week so we need to finalise our plans in the next week. Based on our discussions I drafted three sessions for CDSP as a starting point. @Christian Mühlbauer @Haonan Qiu I'll need your input on what you want to do in the Semantic Reasoning session.
  • We should discuss how we see the cross-group workshop
• AoB

Minutes:

• Status

26th February 2025

Meeting cancelled

19th February 2025

Agenda:

• Status sharing including Playground Kanban
  • Personally I've given some thought to feeders and docker modularity (see above)
  • KL
• Spring AMM planning for Data Architecture
• AoB

Minutes:

• Status
  • Knowledge + Information Layers
    • Christian reports that the team succesfully tested connection between RemotiveLabs and triples being created/stored.
    • Next step is Reasoner testing
    • Steve asks Christian to remind team about Github attribution for the work
  • Steve reports on some feeder investigations
    • VISSR feeders
      • Steve talked to VISSR team in their Moday call. Ulf recommended supporting v3 feeder template.
      • Template handles mapping and scaling of data model conversion.
      • Project does not provide reference low level adapters for auto protocols such as vsomeip, but EVIC feeder does have something for CAN (limited data points)
      • Looking at code should be relatively straight forward to add IoTDB and Information Layer support to v3 template.
    • CAN
      • Kuksa-val CAN Provider project leverages upstream Python CAN support to provide read/write between CAN and VSS with DBC support.
      • Currently it supports kuksa databroker gateway and kuksa server (deprecated by kuksa project) northbound. By providing implementations of the abstract interfaces IoTDB and Information Layer could be added. Steve has asked Erik if kuksa team open to merging support for more northbound clients, but no reply so far.
  • Last week there was some discussion of Docker modularity and how to implement deployment of larger use-cases.
    • Steve posted following notes on Slack about that:

Hi @Christian Mühlbauer re the discussion in last week's call about docker modularity you might find these links useful in the Docker doc:

• • • • • How-to on using INCLUDE, MERGE and EXTEND https://docs.docker.com/compose/how-tos/multiple-compose-files/
        • Use of PROFILES https://docs.docker.com/compose/how-tos/profiles/

Rough example of one possible approach using extend:
We currently have docker/docker-compose-cdsp.yml as a reference compose for a single logical instance of CDSP-core. Assume the Knowledge and Information Layer services have been added. The question is how to use/re-use it in more expansive use-case examples?

Lets say we want to create a use-case blueprint in the examples folder that illustrates a larger touchpoint involving in-vehicle, mobile and cloud. For this example we can create a compose that uses extend to create services in those three domains using the base service defined in docker-compose-cdsp.yml. It might be a simple duplicate and rename, or it might in addition modify the service.

To illustrate let's take the first service in CDSP-core iotdb-service and create three instances in our new blueprint compose example/vehicle-cloud-mobile/docker-compose-cdsp-vehicle-cloud.yml:

name: cdsp-vehicle-cloud-mobile

services:

# In-vehicle HPC Apache IoTDB
  vehicle-iotdb-service:
    extends:
      file: docker-compose-cdsp.yml
      service: iotdb-service

# Cloud Apache IoTDB
  cloud-iotdb-service:
    extends:
      file: docker-compose-cdsp.yml
      service: iotdb-service
    build:
      # Use cluster environment

# Mobile Apache IoTDB
  mobile-iotdb-service:
    extends:
      file: docker-compose-cdsp.yml
      service: iotdb-service

Now for our blueprint we have three services vehicle-iotdb-service, cloud-iotdb-service and mobile-iotdb-service all based on the service definition in docker-compose-cdsp.yml.

We can optimise further by configuring each service appropriately for their domain. Using cluster in the cloud for example.

I don't think there is one pattern that will fit all use cases. It might make sense to use merge or include rather than extend in some cases. We should also be wary of making things so complex that a high level of docker knowledge is required. Ideally these should be useable to a wide range of end users not just infrastructure experts. Some good compromises as to how to modularise should emerge as we go.

Anyway hope that helps.

• Spring AMM
  • Sketch of possible approach for Data Arch sessions:
    1. Playground Intro session - perhaps shorter than before, or more quickly getting into the practical
    2. KL + IL session - As major new feature need to spend time describing it, possibly split into users and technical
       1. Blackbox intro focused on users, e.g. insurance
       2. Perhaps more detailed on internals
    3. Workshop - ideally cross group

19th February 2025

Agenda:

• Status sharing including Playground Kanban
  • Personally I've given some thought to feeders and docker modularity (see above)
  • KL
• Spring AMM planning for Data Architecture
• AoB

Minutes:

• Status
  • Knowledge + Information Layers
    • Christian reports that the team succesfully tested connection between RemotiveLabs and triples being created/stored.
    • Next step is Reasoner testing
    • Steve asks Christian to remind team about Github attribution for the work
  • Steve reports on some feeder investigations
    • VISSR feeders
      • Steve talked to VISSR team in their Moday call. Ulf recommended supporting v3 feeder template.
      • Template handles mapping and scaling of data model conversion.
      • Project does not provide reference low level adapters for auto protocols such as vsomeip, but EVIC feeder does have something for CAN (limited data points)
      • Looking at code should be relatively straight forward to add IoTDB and Information Layer support to v3 template.
    • CAN
      • Kuksa-val CAN Provider project leverages upstream Python CAN support to provide read/write between CAN and VSS with DBC support.
      • Currently it supports kuksa databroker gateway and kuksa server (deprecated by kuksa project) northbound. By providing implementations of the abstract interfaces IoTDB and Information Layer could be added. Steve has asked Erik if kuksa team open to merging support for more northbound clients, but no reply so far.
  • Last week there was some discussion of Docker modularity and how to implement deployment of larger use-cases.
    • Steve posted following notes on Slack about that:

Hi @Christian Mühlbauer re the discussion in last week's call about docker modularity you might find these links useful in the Docker doc:

• • • • • How-to on using INCLUDE, MERGE and EXTEND https://docs.docker.com/compose/how-tos/multiple-compose-files/
        • Use of PROFILES https://docs.docker.com/compose/how-tos/profiles/

Rough example of one possible approach using extend:
We currently have docker/docker-compose-cdsp.yml as a reference compose for a single logical instance of CDSP-core. Assume the Knowledge and Information Layer services have been added. The question is how to use/re-use it in more expansive use-case examples?

Lets say we want to create a use-case blueprint in the examples folder that illustrates a larger touchpoint involving in-vehicle, mobile and cloud. For this example we can create a compose that uses extend to create services in those three domains using the base service defined in docker-compose-cdsp.yml. It might be a simple duplicate and rename, or it might in addition modify the service.

To illustrate let's take the first service in CDSP-core iotdb-service and create three instances in our new blueprint compose example/vehicle-cloud-mobile/docker-compose-cdsp-vehicle-cloud.yml:

name: cdsp-vehicle-cloud-mobile

services:

# In-vehicle HPC Apache IoTDB
  vehicle-iotdb-service:
    extends:
      file: docker-compose-cdsp.yml
      service: iotdb-service

# Cloud Apache IoTDB
  cloud-iotdb-service:
    extends:
      file: docker-compose-cdsp.yml
      service: iotdb-service
    build:
      # Use cluster environment

# Mobile Apache IoTDB
  mobile-iotdb-service:
    extends:
      file: docker-compose-cdsp.yml
      service: iotdb-service

Now for our blueprint we have three services vehicle-iotdb-service, cloud-iotdb-service and mobile-iotdb-service all based on the service definition in docker-compose-cdsp.yml.

We can optimise further by configuring each service appropriately for their domain. Using cluster in the cloud for example.

I don't think there is one pattern that will fit all use cases. It might make sense to use merge or include rather than extend in some cases. We should also be wary of making things so complex that a high level of docker knowledge is required. Ideally these should be useable to a wide range of end users not just infrastructure experts. Some good compromises as to how to modularise should emerge as we go.

Anyway hope that helps.

• Spring AMM
  • Sketch of possible approach for Data Arch sessions:
    1. Playground Intro session - perhaps shorter than before, or more quickly getting into the practical
    2. KL + IL session - As major new feature need to spend time describing it, possibly split into users and technical
       1. Blackbox intro focused on users, e.g. insurance
       2. Perhaps more detailed on internals
    3. Workshop - ideally cross group

12th February 2025

Agenda:

• Status sharing including Playground Kanban: IoTDB and C4 Model updates are merged. Knowledge Layer first pass review completed.
• Spring AMM planning for Data Architecture
• AOSP emulator
• AoB

Minutes:

• Status sharing including Playground Kanban: IoTDB and C4 Model updates are merged. Knowledge Layer first pass review completed.
  • Christian has merged the Apache IoTDB v1.3.3 PR
  • Steve has merged Christian's updates to the C4 Model to add the Knowledge and Information Layers
  • Steve completed his first pass review of the Knowledge Layer PR
  • Discussion of how to handle Docker expansion for KL + IL and in more complex example cases such as touchpoints that have vehicle, mobile and cloud.
    • KL + IL
      • Christian will post his idea for KL + IL
      • Steve thinks it will be ok to include KL+IL in 'core' docker compose. Using docker features that allow services to be specified as optional would give end users ease of definition for what they want.
    • Complex examples
      • Christian is wondering about how to handle complex examples. Which parts go where
      • Steve feels we can trial and evolve as we go. Docker has many features for expanding and combining dockerfiles and compose. Which is best fit likely will depend on requirements for use-case. He thinks it will be ok if an example has a unique compose. It will help if we make the core compose and dockerfiles as configurable as possible.
• Spring AMM
  • Agreement that it would be useful for a cross-group workshop on tie work together. Issue will be framing it in a way that is productive during the workshop.
• AOSP emulator
  • Further discussion of how it might be fed.
  • Sven articulated a player that acted as a dispatcher for an input data set. He will create a diagram for the idea.

5th February 2025

Agenda:

• Status sharing including Playground Kanban
• Central Data Service Playground: High level discussion of moving the Knowledge Layer merge forward, e.g. review
• Spring AMM planning for Data Architecture
• AOSP emulator
• AoB

Minutes:

• Status sharing including Playground Kanban
  • Steve reminds Christian about Apache IoTDB update PR review
  • Knowledge Layer
    • Steve has spent time this week reviewing the PR and added comments to Github. Discussion of some high level points.
    • Discussion about RDFox licensing. Christian reminds that a free one month license is available currently - that would be fall back if the vendor does not offer anything else. Shows need to add an OSS Reasoner as a second option in the future.
    • Topic of getting contributor attribution correct before merging was discussed. Steve noticed some of Haonan's commits don't appear in Github's list. Are there others?
• Spring AMM planning for Data Architecture
  • Paul has posted the page for people to make technical proposals. As before Paul is happy to ring fench space for the COVESA groups, e.g. Thursday morning slots we had before.
  • Steve: We need to come to a conclusion over next few weeks. As it is Europe I have a working assumption that we will have more team members present and so can consider a fuller schedule.
  • First thought is to have a mix like in Porto and Gothenburg, e.g. Playground Intro. KL Intro (user perspective). Technical internals. Workshops, e.g. using Playground.
  • Showcase
    • Steve is expecting Renesas to have a booth. Might show Playground there.
    • BMW plans not clear yet.
    • Paul says there is the possibility of having a seperate booth for COVESA projects, but if we want to do that then he needs to know sooner rather than later to talk to Mike N.
  • Sven: would be good to discuss how groups can use re-use others work.
• AOSP Emulator
  • Sven explains how in this workstream he proposed connecting Emulator to Playground and the Data marketplace/Cloud.
  • Needs further discussion but interesting possibility.
  • Richard says he is happy for AOSP Leads to support comms between the two groups.

29th January 2025

Agenda:

• Status sharing including Playground Kanban
• COVESA
  
  • AOSP Data workstream
• AoB

Minutes:

• Status sharing including Playground Kanban
  • Knowledge Layer
    • Christian/Haonan have addressed the action item to add high level task tickets for remaining tasks to the Kanban
    • Haonan: coding is now almost complete - about 90%
    • Haonan summarised recent work and walked us through the rules definition for the current use-case example
    • Steve: Is the rules file semantics a standard?
    • Haonan: There is no current open standard. Reasoners have rule semantics specific to them due to differences in feature sets. Other parts of the system however use standards where possible, e.g. SHACL
  • Apache IoTDB update to v1.3.3
    • Steve has completed Docker update, sanity tested RemotiveLabs feeder/bridge, VISSR and Grafana. RemotiveLabs and VISSR required no changes. Online doc is also updated. Final task is to fix some links in the down-sample example.
    • Expects to send PR this week.
• Steve talked about using Data Mesh principal concepts (domain orientated decentralised data, data as a product, federated governance) in COVESA and asked for input?
  • Swen likes the concepts, but adds the 4th concept (self service data platform) is also important.
  • Discussion of data needs
• Summarised AOSP Data workstream kickoff meeting from last Thursday

22nd January 2025

Agenda:

• Status sharing including Playground Kanban
• COVESA
  
  • EU Data Act
  • AOSP Data
  • Meta-data
  • VISS v3
• AoB

Minutes:

15th January 2025

Agenda:

• Status sharing including Playground Kanban
• C4 Model for KL
• AoB

Minutes:

• Playground Kanban
  • VISSR update
    • Steve has sent PR https://github.com/COVESA/vissr/pull/79 upstream to fix the VISSR Dockerfile for the current VISSR codebase. Once merged he will update CDSP to take the latest VISSR code which includes it. That will move CDSP from VISSR v2 to v3.
      • VISSR feeder and AGT support currently not tested. See PR for details.
    • Steve notes VISSR is still changing at a high rate. Approach will be to update to what it is now and update again in several weeks when v3 finalises.
  • Closed the ticket related to the VSS DB schema generation proposal as done
  • Knowledge Layer
    • Christian has met with Haonan to discuss a delivery plan towards the Spring AMM. He will create high level tickets in the Kanban board to document the steps.
• C4 Model for Knowledge Layer (KL)
  • Christian walked us through updated C4 Model for KL where the knowledge components have now been added. He will send a PR to add the diagrams to github.
  • Discussion about where a C4 Model Dynamic diagram would help explain the flow. Christian will consider whether adding one will help.
• CES
  • COVESA networking event was a success. Interest in COVESA artifacts remains high.

8th January 2025

Minutes:

• 2025 kick off. Recap of Playground Kanban status and major work items.
  • Christian: Knowledge Layer about 85% done. Will talk to Haonan about getting a C4 Model Component diagram for the KL part.
  • Ulf reports VISS/VISSR v3 almost done
• Discussion about Rami's proposal and when/where he wants to present it.
  • Christian: Daniel may be interested.

11th December 2024

Agenda:

• Status sharing including Playground Kanban
• Heads up on Rami's VSS Data Modeling for NoSQL Document Databases proposal
• Taking stock and thinking ahead to early 2025

Minutes:

• No meeting. Only Steve and Iyaz joined.

4th December 2024

Agenda:

• Status sharing including Playground Kanban
• Christian has an updated Knowledge Layer C4 Model to share
• Any input on VSS Database schema generator proposal
• Data Architecture Team confluence page updates
• Need to start considering Xmas breaks

Minutes:

• Xmas breaks
  • Steve last day is Friday 13th.
  • Decisions: Next weeks call 11th Dec is last of the year. First meeting of 2025 is 8th Jan.
• Playground
  • Kanban:
    • Steve went through his changes:
      • Add initial C4 Model diagrams to Github. See \diagrams\*.drawio.svg. The google drive file with multiple tabs is now a working copy for the newer diagrams.
      • Document Playground online documentation site. See \doc\readme.md
      • Redid the Data Architecture team confluence landing page. Further future improvements possible. Christian likes that it summarises the focus on data-centric arch and the info layers.
      • Following the topic coming up again last week drafted a proposal for DB Schema generation for VSS based on the existing diagram. Proposal can be found in the Data Arch confluence wiki VSS Database Schema Generator. Asked for feedback on slack. Daniel Alvarez provided some input on VSS channel regarding handling of VSS instances and whether working from an API spec would help.
    • Christian summarised BMW team changes:
      • Some updates to the RemotiveLab feeder to limit the inputs. Made for the current code base and use-case. Expect to improve this in the future.
      • He has updated C4 Models for the KL and IL changes.
        • Extended CDSP Container diagram. Added L3 for IL and KL.
        • He will ask Haonan to fill out KL container components.
        • Steve will add the diagrams to the google drive file.
• NoSQL Document DBs
  • Rami Pinto explained that MongoDB have a draft proposal for the work he mentioned last week to describe best practices for integrating VSS data into a NoSQL DB.
  • They will present this in an upcoming meeting. He's away next week. May wait till next year.

27th November 2024

Agenda:

• Status sharing including Playground Kanban
  • C4 Model pull request is ready for review
• We can continue Knowledge Layer discussions from last week
• Rami from MongoDB wanted to discuss DB enablement, automation and best practices

Minutes:

• Playground
  • Status
    • Christian is absent from the meeting (travelling)
    • Haonan is back from vacation and summarises her recent work on the knowledge layer.
    • Steve summarises the short term backlog for Haonan.
  • DB enablement, automation and best practices
    • Rami explains how MongoDB is looking to become more involved again. How does Atlas fit in?
    • In terms of the Knowledge Layer work the proposed sync meeting with Christian is needed.
    • Some additional possibilities are discussed:
      • Rami suggests best practices for Document databases. They had a customer conversation recently where they asked about how best to integrate VSS
      • Example showing how to integrate with Atlas
      • Steve outlined the previous discussions about a DB DDL schema generator for VSS.
      • Rami is encouraged to bring proposals.

20th November 2024

Agenda:

• Playground
  • C4 Models
    • PR for Github - readme, location, discoverability
    • Christian Container model extension
    • Deployment diagram - dev vs live
  • IoTDB version update
  • VISSR version update
  • Christian:
    • Discussion RealmOS instead of RealmSDK within Information Layer
    • MongoDB Atlas as additional backend?

Minutes:

• Playground
  • Answering questions from newcomes from Cobrasphere and MongoDB
  • C4 Models
    • Christian introduces his draft extension of the CDSP Container diagram to include the Knowledge Layer components
      • Steve: great to see this. Very helpful for discussion. We might remove the Fleet and Insurance example boxes to simplify. Also some minor points about connectors.
    • Steve has a WIP PR to add the L1 Context Diagram and L2 Container Diagram to the source
    • Steve shows some hacking he did for a Deployment diagram for the CDSP core in a development environment.
  • IoTDB version update
    • Steve was targetting v1.3.2, but v1.3.3 dropped a couple of hours ago which adds AINode (LLMs in SQL) and improvements in sync and subscriptions. So will likely refocus on that.
    • Also need to schedule the sync discussion with their community.
  • Knowledge Layer
    • Christian suggests that with deprecation of RealmSDK that KL will move to adopt Realm OSS community edition instead. This will leave a unfufilled requirement for DB sync.
    • MongoDB interested in how Atlas can be utilised in cloud side implementation. Christian wonders if it should be an additional backend to the DB abstraction (Information Layer)?
      • Conclusion: Further discussion needed.

13th November 2024

Agenda:

• Playground kanban and status exchange
• Data-arch discussion in Monday's AOSP call
• Capabilities API

Minutes:

• Steve summarised data-arch discussion in Monday's AOSP call that Richard gave us the heads-up about.
  • Steve mentioned to them work elsewhere in COVESA they could leverage, e.g. Capabilities API Seat as a source.
  • Conclusion: They are very early in their discussions. Should monitor and input where possible.
• Steve summarised status of Capabilities API work

6th November 2024

Minutes:

• Playground
  • Knowledge Layer
    • Input from Christian before meeting:
      • Knowledge Layer Connector is now largely finished. Now they are testing triple formatting and writing rules.
      • They are also starting to connect the RemotiveLabs feeder to the Information Layer Connector.
    • Steve has started to look again at the code as preparing for review. He sees some topics in the IoTDB integration that need aligning with what already exists, e.g. database paths and handling of VSS path naming.
  • Steve has started to look at the VISSR and IoTDB version upgrades.
• AOSP
  • Richard summarises the result of the AOSP group survey about what should be next. One of the findings relates to southbound data transformation. What that may mean in terms of work streams will be discussed in the AOSP call this Monday.
• Ulf reported that the CVIS work for Commercial vehicles has restarted in recent weeks.

30th October 2024

Agenda:

• Catch-up after two week hiatus
• KL updates from Christian
• Data sets
• OEM news

Minutes:

• Playground
  • Knowledge Layer
    
    • Christian gave a summary of updates to the Knowledge Layer pull request over the two week hiatus, including a walk through of the document for the hello world example
    • The example requires one additional data key that is not in VSS. Ulf mentions work on HIM merged in current VISSR that could be used to model the two data models (VSS and personal data)
    • Christian: Has RDFox been in contact about licensing?
    • Steve: not seen it yet, but not completely through my email backlog.
    • Christian will ask.
  • Data sets
    • Whilst in Japan Steve recorded some travel data (speed, location and elevation) on the bullet train with an eye on transforming them into VSS for use as an open data set.
  • OEMs
    • Steve mentions that during a Honda keynote at the recent Open Source Summit in Japan by Tsubouchi-san there was mention of an in-vehicle data lake that appears to support the approach of the Playground for hybrid in-vehicle and off-board data processing.
      
      Source:

23rd October 2024

Meeting cancelled due to holidays

16th October 2024

Meeting cancelled due to holidays

9th October 2024

Agenda:

• Christian is back at work after his break and has some points to discuss related to the Knowledge Layer
• From there I would like to continue the process of discussing what's next.

• • Reminder at the AMM I presented the following high level list that we discussed previously:

• • • Complete Knowledge Layer initial development
    • VISSR, IoTDB version update
    • General:

• • • • Outreach
      • Data sets
      • Use-cases / Examples / patterns / etc.
      • Improving guides
      • Expanding Feeders

• AoB

• • I will be on holiday for two weeks from next Tues 15th to Tues 29th. So we need to decide if we cancel the next two calls or if you still wish to meet.

Minutes:

Minutes:

• Playground
  • Catch up on Knowledge Layer.
    • Haonan now adding Knowledge components to PR
    • Discussion of documentation and impact of MongoDB announcing deprecation of embedded components
      • Christian favours merge, then looking for alternatives.
    • Discussion of use-cases. Christian will create Github task ticket to outline the use-case and its development.
  • Version updates
    • Steve outlines benefits (improvements to stream and sync) of moving to 1.3.x IoTDB
    • Ulf informs that his updates to VISSR to speed up subscriptions (feeder can inform server of a change, rather than server use polling) are now merged
• AoB
  • Discision taken to cancel Weds 16th and 23rd meetings. Next will be Weds 30th.

2nd October 2024

Agenda:

• Fall  AMM wash-up
• Start the process of discussing what's next. At the AMM I presented the following high level list that we discussed previously:

• • Complete Knowledge Layer initial development
  • VISSR, IoTDB version update
  • General:

• • • Outreach
    • Data sets
    • Use-cases / Examples / patterns / etc.
    • Improving guides
    • Expanding Feeders

• AoB

Minutes:

• AMM
  • Discussed feedback and themes, e.g:
    • Cloud
    • Coalesching understanding around APIs
    • AOSP future workstreams
• Playground next steps
  • Steve: please consider over coming weeks what interests you, what can be tackled etc.
  • High level list from AMM presentation:
    • Complete Knowledge Layer initial development
      • Need to align with BMW on the MongoDB announcement that they are deprecated embedded components, e.g. Sync and Device SDK (Realm).
    • VISSR, IoTDB version update
      • VISSR
        • Ulf suggests waiting for merge of his changes to allow feeders to inform the server when data has changed in a subscription, which removes need for polling.
        • Steve mentions that he would like to tackle the issue of a pre-built VISSR docker image.
      • IoTDB
        • Currently 1.2.x is used. 1.3.x has useful improvements including in sync and streaming.
        • Further out AI support for LLM execution in SQL is coming in AINode support.
    • General:
      • Outreach
        • Paul: consider having a standalone webinar
        • Steve: good idea. Was also intending to do a series of blogs on Playground both general and specific (e.g. down-sample example)
      • Data sets
        • Steve: Talking to James Hunt from Aicas at AMM he suggested looking at the motorsport set they use
        • PIVOT project the other likely hunting ground
        • RemotiveLabs announced new VSS features in their data sets at the AMM.
      • Use-cases / Examples / patterns / etc.
      • Improving guides
        • Improve Introduction/Overview section using Detroit Playground Presentation as input, e.g. C4 Model diagrams.
        • Would like to add Integration Guides that tell ppl what they need for succesful connections, e.g. feeder integration, without needing to be an expert on complete system.
      • Expanding Feeders
        • Steve discussed uProtocol Simulator with Halim (GM) and DDS with Neil (RTI) at AMM
• AoB
  • Steve will be on holiday 15th-22nd of this month.

25th September 2024

• Cancelled due to Fall AMM

18th September 2024

Agenda:

• Fall  AMM
• Continuation of the Knowledge Layer Connector discussion if BMW are present and there are topics to discuss
• AoB
  • Ulf: VISSR feeder improvements

Minutes:

• Fall AMM
  • Steve outlines the Playground session presentation
  • Paul: Are you happy to present the 10min section about experimentation in the Tues workshop?
  • Steve: Yes
  • Richard: Halim will be present at the AMM.
• AoB
  • VISSR
    • Ulf outlined the work the VISSR project is doing to improve efficiency for subscriptions. Rather than polling, the feeder informs the server when there is a change. See PR for details https://github.com/COVESA/vissr/pull/43
  • AOSP
    • Richard: the AOSP group is looking for ppl interested in working on making VSS signals available to AOSP apps.
    • Steve: Is that mapping to Android VHAL or a parallel server for greater range of properties/signals?
    • Richard: Both of interest.
    • Discussion of the pluses and minuses and some of the prior work.
    • Ulf: VISS could be used for that case.

11th September 2024

Agenda:

• Playground Kanban "stand-up meeting": In-progress task status, major new items
• Fall  AMM
• Knowledge Layer Connector update: BMW want to give an update on their work on the Knowledge Layer components
• AoB

Minutes:

• Playground Kanban
  • Steve has fixed issue #57 (online doc ToC not rendered correctly).
  • Updates from BMW - see below
• Fall AMM
  • Steve and Haonan will discuss Knowledge Layer slides offline
• Knowledge Layer components
  • Andre reports that BMW have made good internal progress on engineering the knowledge layer components and wants to discuss how to progress publically in terms of PRs etc.
  • Steve suggests following:
    • 1st step would be concentrating on getting the Knowledge layer components public as the info layer ones currently are so we can all see what is being talked about. This could be in the existing PR or a new one if you prefer.
    • Commits can be added as you go to get early feedback. No need for "big bang" single push at the end of development.
    • With AMM coming that gives you some weeks to prepare.
    • Suggested 2nd step would be to consider the modelling of the components, e.g. extend C4 model, to support discussion and review
  • Steve's non-exhaustive list of related topics to be discussed during and after this process as input:
    • Information Layer abstraction
      • data get/set limitations vs data tablet and higher level queries.
        • Need: Agree how to document current limitations and not limit research in higher level and faster queries.
      • database path consolidation for the various containers, e.g. VISS access vs information layer set need to coordinate (now) where to get the data in the DB
        
        • Need: out of the box components work together
    • Use cases for online documentation
      • Currently intended for more general abstracted documentation and guides that need a lot of cross-referencing, e.g. integration guides
        • Need: Add appropriate doc for the newly introduced features
    • Architecture communication / arch visualisation / C4 model
      • Need: Need arch view of the Playground and how the new features are integrated at different levels of abstraction to be able to discuss within the group and outside.
    • Docker images and packaging of CDSP Core building blocks
      • Pre-built images?
      • Need: Agree on how to handle the dockerisation of Core building blocks in a consistent manner.
  • Discussion:
    • Agreement that current naming of Knowledge and Info layer 'boxes' in current C4 Model are not correct (Steve just added them as placeholders).
      • Collectively need to come up with what is 'better'.
      • Haonan says that Knowledgebase would be traditional way from knowledge perspective but it is also perhaps a little outdated.
      • Ulf suggests "Knowledge Server" as starting point for KL part and both Haonan/Steve agree that is better. Steve changes diagram.
    • Andre happy to add appropriate online documentation
    • Docker
      • Andre wonders about flexibility in selecting docker containers to include when using docker compose.
      • Sebastian says as end user he would simply consume Dockerfiles and deploy with kubernates but sees desire for 'easy' starting point
      • Steve agrees balance needed between out of box experience and both flexibility and maintainability. Docker compose does not preclude someone from really doing some bespoke for themselves.

4th September 2024

Agenda:

• Playground Kanban "stand-up meeting": In-progress task status, major new items
• Fall  AMM
• Playground C4 Model

• • Prior to working on the fall AMM presentation I have been experimenting with various architecture visualisations from the viewpoint of needing to communicate with a wide diversity of job types. The simplicity of the C4 Model looks very promising in the way it combines ease of understanding, useful abstractions and sufficient guide rails.
  • I have drawn a C4 Model of the Playground at the first two levels of abstraction, which you can find on the Data-Arch google drive here and I would like to discuss and get feedback in the meeting.

• • • Open the file in draw.io
    • There are 3 pages:

• • • • L1 Context diagram - Playground System context
      • L2 Container diagram - Major parts of the Playground
      • Speculative draft variation of L2 that adds the Knowledge Layer Connector - I did that just to explore how well the abstraction layering works. You can see for example that containers can be added whilst seperation of concerns maintains existing structures. Also that abstraction allows discussion of the Knowledge Layer Connector interfaces without getting lost in details of SHACL etc.

• AoB

Minutes:

• Playground Kanban
  • Steve has merged the online doc Example page changes. Now working on a fix for the ToC indention issue.
  • Did C4 Model diagraming as prep for Fall AMM presentaton. See next.
• Playground C4 Model
  • Steve presented the Level 1 and Level 2 C4 Model summarised in the agenda above. He feels it shows a lot of promise for communicating the Playground.
  • Main feedback came from Ulf who liked the multi-level abstraction of the approach.

28th August 2024

Agenda:

• Playground Kanban "stand-up meeting": In-progress task status, major new items

• • Done some work on improving the listing of examples in the online documentation

• Fall  AMM: https://wiki.covesa.global/x/WgBSBgFall  AMM: https://wiki.covesa.global/x/WgBSBg.
• AoB

Minutes:

• Playground Kanban "stand-up meeting"
  • uProtocol Simulator: Richard will report back if a future strategy emerges from internal GM discussion. Input from the uProtocol community also possible of course. Agreement to place on hold until next steps from developers of the technology becomes clearer. Playground team remains interested if something emerges.
  • Online doc Examples page:
    • Steve shows WIP of updated Examples page that adds the down-sample example and reworks the page to make example discovery a little easier through the use of tables in the categories.
    • Discussion of the WIP. Haonan: a more descriptive heading for the table than "Description" that links the text to the category might be helpful.
  • Knowledge Layer Connector:
    • Haonan requests meeting with Steve to discuss the Connector and AMM
• Fall AMM
  • Discussion of the Playground presentation and incorporating the KL Connector slides

21st August 2024

No meeting due to holidays.

14th August 2024

Agenda:

• Playground Kanban "stand-up meeting": In-progress task status, major new items
  • Data Processing PR now merged. Considering what's next

• Fall  AMM: https://wiki.covesa.global/x/WgBSBg.
• AoB

• • I will be on holiday next week. So we either need to cancel next week or someone hosts.

Minutes:

• Playground Kanban "stand-up meeting"
  • Steve's Data Processing pull request is now merged. He's considering what's next.
  • Halim (GM) reported the team is making progress on dockerising the uprotocol simulator
  • Further commits added to the Knowledge Layer connector PR. Haonan has been working on the RDF Converter.
    • Steve mentions that the IoTDB project is adding Machine Learning support to SQL Queries.
    • Haonan discussed how this could be complimentary to the Rules based Semantic Reasoning. ML could determine some higher value information that is then used by Rules Reasoning to derive the higher level knowledge.
• Fall AMM
  • Current Introduction session outline:

    • Title:  Introduction to the COVESA Central Data Service Playground Short Description: Discover what the COVESA Central Data Service Playground (CDSP) is, what has been done and where it is going. Description:   In this session we will introduce the COVESA Central Data Service Playground (CDSP) a project of the COVESA Data Architecture and Infrastructure group. CDSP What / Why / How What has been done since the Spring AMM What’s next / roadmap

• AoB
  • Steve is off next week. Decision taken to cancel meeting.

7th August 2024

Agenda:

• Playground Kanban "stand-up meeting": In-progress task status, major new items

• • Data Processing PR is done
  • Outreach and blogs
• Digital.auto alignment
• Fall  AMM: https://wiki.covesa.global/x/WgBSBg.
  • Data Arch session, Showcase
  • Pre-conf tech day
• AoB

Minutes:

• Playground big picture
  • Since Spring AMM
    • CDSP v0.1.0 release
    • RL feeder
    • Data Quality / Grafana + examples
    • KL Connector WIP
    • Second maintainer added
  • Roadmap – next 3 months or so
    • Data Quality Library extensions
    • KL Connector
    • Examples / patterns / etc.
    • Data sets
    • Outreach
    • Improving guides
    • VISSR, IoTDB version update
• Insurance data campaign: https://docs.google.com/spreadsheets/d/1Np9uLvwEESZ09dMcXoSvoyoyj5L_Le0k/edit?gid=1250108163#gid=1250108163
• Potential meeting to discuss rules for Insurance data?

31st July 2024

Agenda:

• Playground Kanban "stand-up meeting": In-progress task status, major new items
• Fall  AMM: https://wiki.covesa.global/x/WgBSBg.
• AoB

Minutes:

• Playground Kanban
  • No change on uProtocol Simulator
  • Knowledge Layer Connector
    • Christian updates on Information Layer component:
      
      • Further updates in the PR for the IoTDB support in the DB Router.
      • The Router uses Node.js and IoTDB has no Node wrapper for its Thrift rpc API so they have had to work with low level Thrift aspects for get/set.
      • Steve says that IoTDB maintainers are very active on Github Discussions or Slack. Might be worth asking about Node there. Perhaps someone has something.
  • IoTDB timeseries data processing example
    • Steve has pushed substantial updates for the example readme. Walked through readme to discuss structure as possible template for other examples
• Commercial Vehicle EG outreach
  • Ted explains that the EG is on summer break for two weeks
  • Discussion about data sets, meta-data and collaboration

24th July 2024

Agenda:

• Playground Kanban "stand-up meeting": In-progress task status, major new items
• Fall  AMM: https://wiki.covesa.global/x/WgBSBg.
• First feedback from outreach to Commercial Vehicle EG about their guidelines and meta-data additions.
• AoB

Minutes:

• Playground Kanban
  • Waiting for update from GM on uProtocol Simulator.
  • Knowledge Layer Connector
    • Christian has updated the PR to add connection support for IoTDB to the DB Router. No data access yet.
    • Haonan summarised the tasks for the components interfacing Reasoner to Information Layer.
      • Use case for write-back to information layer is when the decision results in values that can be mapped, e.g. driving behaviour results in driver management system alert.
    • Discussion concludes that it is fine for multiple data models to be combined. It's illustrative of a concept, not a prescription as how to implement. Others are welcome to extend with their approach as well.
  • IoTDB Data Quality Processing Example
    • Steve has the data set and the operations worked out. Currently creating the documentation to tie it together.
• Fall AMM
  • BMW not expected to send several engineers. To be discussed in coming weeks but Steve may present high level view of Knowledge Layer
  • Given attendance of Playground contributors from EU it appears rather than Data Arch specific workshop it may be better to join a more open discussion about scaling and illustrating VSS.
• Commercial Vehicle EG outreach
  • Steve summarised discussion on their slack channel about their Guidelines and Meta-data:
    • Guidelines have no versioning yet. Location and format may also change.
    • meta-data in the github vspec has no guidelines for how they are be used. Unclear what is required in-vehicle with the data.
  • Further discussion required with them.

17th July 2024

Agenda:

• Playground Kanban "stand-up meeting": In-progress task status, major new items
• Fall  AMM: https://wiki.covesa.global/x/WgBSBg. We need to firm up plans as the end of month is approaching. This is in part also a discussion of the group roadmap towards the AMM.
• AoB
  • Christian: Simulators

Minutes:

• Playground Kanban 
  • Christian expects to make greater progress on Knowledge connector next week
  • Steve is working on an example for the IoTDB data processing PR. He's got ok from RemotiveLabs to use some of their data.
  • Steve has been contacted by Halim from GM. He is checking the uProtocol Simulator status
  • Knowledge Layer Connector
    • Christian asks about connecting to IoTDB in the Playground
      • During development phase can simply connect to the iotdb-service container running the IoTDB server either from host or another containers as you wish.
      • For deployment we will need to discuss how to integrate the connector, but for example it could be a knowledge-layer image that becomes a service in the playground compose.
• Fall AMM
  • BMW internal meeting was pushed back. Christian should have news next week.
  • Steve: Chicken and egg on workshops. Holding workshop on playground internals will depend on participation else it might make more sense to join the verticals (commerical, safety, insurance) and discuss use-cases and playground use.
• Simulator
  • Christian: we have been thinking internally about connecting simulators to the Playground, including the information layer and I wanted to discuss this publically.
  • Discussion:
    • Various simulators will be needed.
    • It's agreed its helpful if only minor glue code is needed to make connections. For that to be possible appropriate documentation is needed for interface integration.
    • Some 'playback' will be as simple as ETL style operations of loading data sets into the DB
    • Standalone collection of data sets reusable across examples is a need.

10th July 2024

Agenda:

• Playground Kanban "stand-up meeting": In-progress task status, major new items
• Knowledge Connector
• DB Schema generation: I will like to briefly present the generator diagram from slack to both get early feedback and to progress the discussion
  • https://drive.google.com/file/d/14cxCzfcIVgJA3yyStnjcu1D4PxQFE3M9/view?usp=drive_link
• Fall  AMM: https://wiki.covesa.global/x/WgBSBg
• AoB

Minutes:

• Kanban meeting:
  • Waiting on GM to return from break for uProtocol simulator update
  • IoTDB Data Processing functions: Steve has updated the PR to add online documentation for the changes.
    • Next is Grafana, plus an example
  • Knowledge Connector: Christian explained updates to the PR, e.g. DB router changes.
    • Discussion in the DB Schema section about challenges of maintaining a single source of truth when relating data models as is typically needed with knowledge layer.
    • For the connector itself it seems ok if it uses a particular approach to communicate the wider idea of using Rules based reasoning. That is internal to the blackbox and other approaches could be used in implementation.
• DB Schema:
  • Continued last weeks discussion.
  • Steve explained a diagram that communicates the thoughts he had last week. Diagram here: https://drive.google.com/file/d/14cxCzfcIVgJA3yyStnjcu1D4PxQFE3M9/view?usp=drive_link
  • Discussion of some ideas there and the challenges when representing relationships between models as needed in knowledge layer.
• Fall AMM
  • Steve has created a brain storming page https://wiki.covesa.global/x/WgBSBg
  • Christian will check internally what BMW want to do and who will attend.
• Summer holidays:
  • Ulf: off next week and 1 after. Probably some further break later in summer.
  • Sven: 3 week break coming up.
  • Christian: Long break from 8th Aug.
  • Steve: will take 1-2 week break, probably in Aug, to match when others are off.

3rd July 2024

Agenda:

• Playground Kanban "stand-up meeting": In-progress task status, major new items
• Docker: Brief summary of my PR above.
• DB Schema generation: I had some discussion with Gunnar in CVI about this. Basically keeping the meta-data for it with VSS as a layer, rather than dislocated in for example a template language config file. I think ultimately I need to write a fuller proposal that can be discussed, but it perhaps warrants a short discussion if people have input to help form the ideas.
• Fall AMM: deadline for talks is end of the month. We need to discuss what we want to do, including the possible extra technical day.
• AoB

Minutes:

• Kanban stand-up meeting:
  • Knowledge Layer Connector, Christian: Started on skeleten PoC DB router in information layer
  • IoTDB Data Processing, Steve: A WIP PR has been added https://github.com/COVESA/cdsp/pull/52 which adds the optional IoTDB Data Quality Library to the Playground IoTDB docker image and configures IoTDB for access from Grafana.
  • uProtocol Simulator: waiting for update from GM
• DB Schema Generation:
  • Discussion of providing a mechanism for DB Schema generation for VSS nodes. This would accelerate users ability to more quickly get started with the Playground as it could automate the generation of all nodes.
  • Steve and Christian think this could be useful. Christian in addition raises a similar use-case for the knowledge layer, e.g. SHACL generation. There was some conversion to SHACL in the past.
  • Idea brainstorming:
    • Rough requirements:
      • Input: VSS vspec (a reduced vspec could be input if only a few nodes are required)
      • Generation:
        • Template language + config (config is the description needed to match VSS to the DB)
      • Output: schema for DB X
        • Example: Series of lines to create schema for each VSS node e.g CREATE timeseries.Vehicle.Speed (datatype=INT, compression=X, encoding=Y, meta-data=Z)
    • Steve: In discussion with Gunnar in CVI it was considered that this mapping meta-data could be held in a VSS layer/overlay (closed to the source) rather than in an isolated stand-along config file. If the existing VSS overlay mechanism did not support it, then evolving VSS overlays to be something closer to IFEX layer mechanism could.
  • VSS layer:
    • vehicle.speed DB meta-data=> data-type=INT, compression=squashy, encoding=super-encoding, meta-data="some attribute"
  • Generation / vss-tools:
    • Christian asks about doing this in vss-tools.
    • vss-tools has good set of meta-model functions now, which means generator largely just needs to contemplate output side so could have:
      • vspec2iotdb
      • vspec2realm
      • vspec2shaql
• Fall AMM
  • COVESA wants technical session proposals by end of the Month.
  • So we need to contemplate:
    • Weds/Thurs Main Conf: Technical Sessions
      • e.g. Outreach etc.
    • Tues Smaller Conf: Workshops
      • e.g. Playground internals
  • Steve will put up the usual page for ideas
  • Paul: COVESA page here All Member Meeting Planning

26th June 2024

Agenda:

• Playground Kanban "stand-up meeting": In-progress task status, major new items
• Docker: I have been working on integrating the IoTDB Data Quality library and Grafana. That raises some questions about configuration of Docker containers and the source for the parts we integrate. That may be worth a discussion to get some feedback. Particularly from the BMW team who may be doing similar work at the moment.
• @Swen Schisler (Endava) mentioned last week wanting to discuss some of his proposal to the CVI group
• AoB

Minutes:

• One possible set of container images for the Playground compose:
  • Image1: iotdb
  • Image2: VISSR
  • Image3: playground-tools/extras
    • Knowledge Connector
      • Info Layer
        • Realm backend widget
      • Knowledge

19th June 2024

Agenda:

• Playground Kanban "stand-up meeting": In-progress task status, major new items
• GM uProtocol Simulator update: two weeks ago GM said they would update us on progress of dockerising the simulator. This would also be an opportunity to advance the integration discussion.
• Continuation of the two topics @Ulf proposed last time and briefly introduced
  • Playground documentation structure
  • Proposal for integration of VISS into the Knowledge Layer connector
• AoB

Minutes:

• Playground Kanban stand-up
  • 0.1.0 blog will be published any day now.
  • Steve reports that he has introduced COVESA and the Playground project to the Apache IoTDB community. Received positive interest in the Playground and willingness to support IoTDB.
• GM were scheduled to update us on the uProtocol Simulator but no GM representatives attended.
• Continuation of the two topics @Ulf proposed last time and briefly introduced
  • Playground documentation structure
    • Ulf described his proposed updates to layout of the landing page and organising the examples.
    • Screenshot: Ulf-CDSP-doc-layout.png
    • Steve described original was modelled after the Docker landing page which does a nice job of enabling both newcomers and experts: https://docs.docker.com/
    • Ulf's point about seperating the user/ref manuals of the core components would be useful
  • Proposal for integration of VISS into the Knowledge Layer connector
    • Agreement that the pluggable architecture in the WS component for DBs would allow Ulf to attach some of his idea, e.g. he feels he could use OVDS to attach VISS in the cloud.
    • Discussion of other aspects
• AoB
  • Swen mentioned he could discuss some of his ideas for his project next week

12th June 2024

Agenda:

• Playground Kanban "stand-up meeting": In-progress task status, major new items
• @Christian Mühlbauer @Haonan Qiu will present their idea of a Knowledge Layer connector example
• AoB
  • @Ulf has proposed two agenda items today:
    • Playground documentation structure
    • Proposal for integration of VISS into the Knowledge Layer connector
  • If there is time at the end of the meeting we can get an overview with a view to progressing discussion next week and or in slack

5th June 2024

Agenda:

• Playground Kanban "stand-up meeting": In-progress task status, major new items
• uServices mocker integration discussion with GM team
• Time permitting or uServices discussion does not proceed: Knowledge Layer connector example
• AoB

Minutes:

• Playground Kanban stand-up
  • Steve has made the 0.1.0 release. Currently working with COVESA marketing to publicise
• uServices Mocker discussion
  • Halim set the big picture. Mocker in question is the Eclipse uProtocol Simulator. Mocker seems a good fit for the concept of the Playground.
    
    • From project README.md: The up-simulator is a user-friendly web tool designed to make developing uProtocol services and Apps on PCs easy. Its intuitive interface empowers users with features such as Publish-Subscribe, RPC invocation, and the simulation of COVESA Vehicle Services. With a focus on a user-friendly graphical interface (GUI), users can easily navigate through the development and testing phases of uProtocol Apps, ensuring a smooth experience from start to finish.
      
  • GM engineers demonstrated the simulator for uProtocol and vsomeip traffic.
  • Halim: whilst the simulator supports uProtocol and uServices it can be used to simulate pure SOME/IP traffic.
  • Steve: as the simulator already exists it seems to be a question of how the 'tool' would be integrated and connected to other components to add value. Is it containerised?
  • Simulator is implemented in Python, but not yet containerised.
  • Halim suggests that GM containerises the simulator and that is then used to guage wider interest. This seems like a sensible way forward.
  • Halim: there will be a company stop in around a month for a summer break, so I would like to push the GM team to make some progress in the next two weeks. Let's plan for a progress update from the GM team in the Data Arch call for 19th June.
• Knowledge Layer Connector example
  • Ran out of time. Pushed back to next week.

29th May 2024

Agenda:

• Playground Kanban "stand-up meeting": In-progress task status, major new items
• Knowledge Layer connector
• GM uServices mocker meeting next week
• AoB

Minutes:

• Playground Kanban
  • After discussion with Arnaldo decision taken to move https://github.com/COVESA/cdsp/issues/15 back to the backlog as its currently more narrowly defined as being about Realm as a backend to VISSR. Work on Realm support for other use is currently a part of the Knowledge Connector.
  • Steve has started on the 0.1.0 release. After that he may continue with the work on Grafana and IoTDB data quality functions.
  • BMW have started public work on the Knowledge Connector in their fork.
• Steve has confirmed with Halim that we will discuss integration of the GM uServices mocker into the Playground in next weeks call.
• AoB
  • Paul asks for input on marketing projects for outreach
    • Steve: I have been talking to Mary about utilising the COVESA Blog and social accounts. General idea is to semi-regular post updates as new features added or releases made.

21st May 2024

Agenda:

• Playground Kanban: In-progress task status, major new items
• Knowledge Layer connector: code directory layout
• CVI call to discuss GM uServices mocker
• RL meeting
• AoB

Minutes:

• Began Kanban stand-up meeting.
• Pivoted into longer discussion about Knowledge Layer Connector
  • Ulf and Christian discussed VISS relationship
  • Discussion of code layout and the components. Christian showed update list of components and their functionality.
  • Discussion of upcoming code commits from BMW. They will create a PR. Possibly starting with READMEs for the various parts
• Ulf discussed earlier work in CCS OVDS database in cloud. Thinks it can be reused.
• Steve will confirm with Halim about when the discussion with GM team regarding integrating the uServices Mocker will take place and report on Slack
• Steve outlined positive meeting he had with RemotiveLabs introducing the Playground to them. Follow up required on areas of collaboration.

15th May 2024

Agenda:

• Playground Kanban: In-progress task status, major new items
• 0.1.0 release: I would like to make an initial release soon, but would like opinions if anyone has input on what/how
• Knowledge Layer connector
• Backlog generation
  • Use cases
    • Data processing/analytics
      • Commercial Vehicle BoF guidelines
      • CV Slack discussion incl. meta-data
    • Inquiry from GM about integrating a mocker
• AoB: related projects etc.

8th May 2024

Agenda:

• Playground Kanban
  • In-progress task status
  • 0.1.0 release
  • Completing project setup
• Backlog generation
  • Use cases
    • Data processing/analytics
      • Commercial Vehicle BoF guidelines
• AoB

Minutes:

• Playground status
  • Steve has a WIP PR to add the RemotiveLabs feeder/bridge he created for the Spring AMM. Documentation is next major step
  • Christian presented latest thinking on the Knowledge Layer connector. Extensive discussion of that.
  • Steve: we should look to make 0.1.0 release soon and complete project setup
• Limited timing remaining but some discussion of backlog generation and the need for use cases for data processing/analytics
  • Steve: Commercial Vehicle BoF has some guidelines
• AoB:
  • Ulf:
    • VISS/VISSR weekly project meetings starting Monday at 4-5pm CET
    • Commercial Vehicle Information Specifications project under Commerical Vehicle BoF being scoped. Starting with Tractor/Trailer trees.

1st May 2024

Minutes:

• May national holidays in EU meant missing active members so informal discussion held.
• General discussion of data sets, data processing and need for functional requirement input from industry.

24th April 2024

Agenda:

• AMM feedback
• Team backlog

Minutes:

• AMM
  • Feedback
    • Paul: Digital.auto came up a few times. Uncertain about what relationship to playground
      
      • Steve: Personally I see the core digital.auto functionality as being the visual ideation. For that part it could be both a data feeder of VSS data to the playground and a client which uses the playground as a source.
    • Swen: was useful as first time attendee. From CVI discussion yesterday will be sharing mental model of what I perceive as the bigger picture. We need to understand each other to design the right architecture.
    • Haonan: good conference. Good to meet people finally.
    • Steve: Had some interesting conversations in the Showcase with the Playground demo. Some people really got the concept and even talked about using it in their upcoming hackathon. Also had interest from an academic.
  • Thursday workshop
    • Whiteboard:

• Backlog
  • Playground backlog slide from AMM:
    • Next (goal: enhance and use the playground):
      • Review 0.1.0 release and fill obvious doc gaps
      • Socialisation: COVESA groups, Webinars etc.
      • Concrete backlog generation (high lvl points below)
        • Main focus of Thurs Data Architecture team workshop
        • Feeders: VISSR feeder component, RemotiveLabs, etc.
        • Examples: agree data arch team early focus.
          • Data processing, touchpoints etc.
        • Connections to COVESA eco-system, e.g. CVI southbound, AOSP northbound
        • Embedded App DB (Realm)
        • DIKW Knowledge layer connector
        • Auto h/w deployment (mid term)
        • Complete project setup: release process etc
• Discussion in meeting:
  • Need data sets (at rest):
    • VSS data sets (real or simulated)
    • Other data models and rule sets.
  • Next week or two Steve will do some documentation polishing and publish the RemotiveLabs bridge sample code as an example (source is available in his github so ask if you want to know sooner)
  • Discussion of knowledge layer
    • Christian/Haonan are continuing to work on the connector
    • Discussion of rules example Haonan posted to the slack.
    • She explained she's currently bypassing some steps in the processing chain, but is just directly looking at the applicability of processing the timeseries data in RDFox to confirm approaches.

17th April 2024

No meeting due to AMM

10th April 2024

Agenda:

• 2024 Spring AMM Planning (Data Architecture and Infrastructure)
• Central Data Service Playground
  • Status reports
  • Release/preview tagging
  • AMM presentation
    • High level near-mid term backlog, e.g:
      • Feeders: VISSR feeder component, RemotiveLabs
      • Examples: agree data arch early focus. see workshop
      • Connections to COVESA eco-system, e.g. CVI southbound, AOSP northbound
      • Embedded App DB (Realm)
      • Knowledge layer connector
      • Auto h/w deployment (mid term)
      • Quality of life improvements: review 0.1.0 release and fill obvious getting-started or doc gaps
      • Agree on and complete project setup: release process, testing etc

Minutes:

• Spring AMM sessions
• Central Data Service Playground
  • Status reports
    • Steve:
      • Rebase on upstream VISSR complete and merged.
      • Quality of life Docker Compose improvements (code and doc) complete and merged.
      • Main branch now represents 'playground-core' of 0.1.0 release
      • Current: Now completing IoTDB guide for doc-site (preview here)
      • Next: showcase demo and AMM presentations
  • AMM presentation
    • Agreement on general high level themes for the backlog. Of course list to be actually debated in the workshop
    • Discussion of knowledge layer slides
  • Christian agrees it would be good idea to tag a release.

3rd April 2024

Agenda:

• 2024 Spring AMM Planning (Data Architecture and Infrastructure)
• Central Data Service Playground

Minutes:

• Spring AMM sessions
  • Agreement to shorten session on Playground use in favour of discussing it in workshop segment
  • Discussion of workshop topics
    • Steve: add your ideas to the list on the planning page
    • Swen: interested in cloud
    • Christian/Haonan agree to present a few slides to kick-off discussion of knowledge layer
  • Steve has posted a note on LinkedIn advertising the session
• Central Data Service Playground
  • Status reports
    • Steve has published the Implementation overview page on the doc site.
    • Next steps: point playground to use current upstream VISSR, some clean up and retest, before tagging 0.1.0 release.

27th March 2024

Agenda:

• Spring AMM sessions
  • Weaving in other sessions? Workshop at end of Playground 'use' session?
  • 2024 Spring AMM Planning (Data Architecture and Infrastructure)
• Central Data Service Playground

Minutes (retrospective summary):

• Central Data Service Playground
  • Status reports / Kanban review
    • Steve: Baseline documentation has been published on site. Main content is the logical concept overview. Next will be implementation
    • Steve: Had a look at integrating RemotiveLabs virtual signal platform as a feeder. On hold whilst address issues accessing their cloud system via their CLI through corporate systems.
    • Ulf gave summary of VISSR feeder template
    • Steve: Thanks. I was planning to enable that for IoTDB as part of the backlog.

20th March 2024

Agenda:

• Spring AMM sessions
  • Weaving in other sessions? Workshop at end of Playground 'use' session?
• Central Data Service Playground
  • Status reports / Kanban review
  • Documentation site: content, theme
  • 0.1.0 release
  • Knowledge Layer Connector

Minutes:

• Spring AMM sessions
  • Paul: can make changes to the timings if you need.
  • Discussion of making the end of the morning a working session.
  • AI: Need to calculate the timings. Three playground sessions, then working session.
• Central Data Service Playground
  • Status reports / Kanban review
    • Steve:
      • WAII VISS Server IoTDB documentation and runtime configuration for connector merged upstream. Will rebase Playground on upstream after spent some time on playground documentation.
      • Working on content for Playground doc site to add baseline why/why/how introduction and getting started. Work taking place on my fork and presented as WIP PR here https://github.com/COVESA/cdsp/pull/27
    • Arnaldo:
      • Continuing work on Realm integration.
  • Documentation site
    • Brief discussion of Hugo themes. Steve seems some limitations in the current Learn theme and has done some experiments with Hextra that adds useful features like Cards and has more normal heading type size scaling. Small example here https://slawr.github.io/cdsp-doc-hextra-trial/docs/
  • Discussion of 0.1.0 release around time of AMM release

13th March 2024

Agenda:

• Spring AMM sessions
  • Weaving in other sessions?
• Central Data Service Playground
  • Covesa Board
  • Status reports / Kanban review
  • Continue discussion of Knowledge Layer Connector. One related aspect is the topic of schemas on the data layer side.
  • Roadmap/backlog/work package definition.
    • What does AMM release look like?
    • Feeders
  • Possible online hosting of Playground

Minutes:

• Sml group: Swen, Steve, Paul, Haonan
• Central Data Service Playground
  • Steve presented the development status to the Covesa board today
  • Status
    • Steve has sent PR upstream documenting use of Apache IoTDB as WAII Data Store backend. Covers for example runtime assumptions, e.g. schema, that a feeder or client developer would need to know about. Also how to seed the DB.
    • Content will be reusable in Playground.
    • He also rebased the code to add runtime configuration of the IoTDB connector through a config file on current upstream master and sent PR
  • Discussion of Swen's idea for online hosting
  • Discussion of app embedded DB schema
  • Steve summarised what the content of the likely first 0.1.0 release will be and plans for roll out.

6th March 2024

Agenda:

• Spring AMM sessions
• Central Data Service Playground
  • Status reports / Kanban review
  • Continue discussion of Knowledge Layer Connector. One related aspect is the topic of schemas on the data layer side.
  • Roadmap/backlog/work package definition.
    • What does AMM release look like?
    • Feeders
  • Possible online hosting of Playground

• AoB

Minutes:

• Sml group: Ulf, Swen, Steve
• Central Data Service Playground
  • Status reports
    • Apache IoTDB
      • Now upstream WAII VISS git rep move is complete Steve will rebase and upstream the config file support.
      • Extending WAII tutorial to document IoTDB connector is almost complete. Will send PR upstream.
  • Knowledge Layer Connector: Haonan has reported that Artifact JSON-RDF Converter outline has been updated.
  • Discussion of the likely content of the pre-AMM release.
  • Discussion of the current thinking for roll-out: get initial documentation in place, roll-out to active Covesa devs, then wider membership/community using blog/e-blast.
  • Swen outlined the benefits and possible method for online hosting of the Playground.
    • Wide ranging discussion of the possibilities: costs, connecting to other systems, scaling, flexibility etc.
    • Interesting idea that needs further discussion.

28th February 2024

Agenda:

• Spring AMM sessions
• Central Data Service Playground
  • Status reports
    • Upstreaming Apache IoTDB support into WAII VISS Data Server
    • Apache IoTDB runtime configuration support
    • Online documentation
  • Continue discussion of Knowledge Layer Connector. One related aspect is the topic of schemas on the data layer side.
  • Roadmap/backlog/work package definition. What does AMM release look like?
  • Feeders
• AoB

Minutes:

• Central Data Service Playground
  • Status reports
    • Online documentation: Steve has merged Ulf's online documentation PR to add the Hugo setup. Next step is enabling the workflow to automatically build and publish any content.
    • Apache IoTDB state storage: Steve has added runtime configuration (where to find DB, what database path to use etc) support for the WAII IoTDB connector. It's available in his PR https://github.com/COVESA/cdsp/pull/20. He will send a PR upstream to WAII once its moved to its new home.
    • Realm state storage:
      • Arnaldo had questions about how best to handle the paradigm difference between the typically complex documentation schema used in Realm and the key/value pair schema of VISS/WAII. A second challenge is Realm has C++, but no Go client/binding so how best to interface to WAII get/set methods in Go?
      • Discussion about possible approaches:
        • Complex schema
          • Steve: Same problem exists I think for the JSON-schema to RDF connector for the knowledge layer. We've started with simple with key/value pairs in the store for maximum flexibility, but approaches will need to be found for more complex schema as we go along.
          • Swen: I saw this problem when working with Realm cases. We added accessor methods to our solutions to allow interfacing to other systems.
          • Discussion wondering how BMW VISS implementation had addressed the same issue. Arnaldo/Haonan could look for internal suggestions.
        • WAII connector
          • Steve showed the three WAII methods to be supported (init, get, set) which have straight forward parameters.
          • Two ideas suggested:
            • Use Go binding to other languages. Ulf had succesfully used a package that provided type conversions and binding for C.
            • If Realm has IPC support then it could be used form the Go methods. Ulf explains the Redis connector uses a unix socket.
    • Out of time to discuss Knowledge Layer Connector this week.

21st February 2024

Agenda:

1. Spring AMM sessions
2. Central Data Service Playground
   1. Status reports
   2. Upstreaming Apache IoTDB support into WAII VISS Data Server
   3. Continue discussion of Knowledge Layer Connector. One related aspect is the topic of schemas on the data layer side.
   4. Online documentation
   5. Roadmap/backlog/work package definition. What does AMM release look like?
   6. Feeders incl WAII, Volvo/Remotive
3. AoB

Minutes:

• Spring AMM sessions: Paul would like any updates. Currently abstracts are missing.
• Central Data Service Playground
  • Status reports
    • Apache IoTDB support
      • Steve created PR #110 in WAII upstream to add the Apache IoTDB support into WAII VISS Data Server. This was merged by the maintainers. Need to add documentation.
      • Steve also created Playground PR #20 to make it available in a WAII fork. Now changes are upstreamed this can be changed to update submodule to the upstream instead.
    • Realm support: No update this week
    • Online documentation
      • Hugo changes were merged but an issue was found in the signoff. Now updated, this will be merged again this week.
  • Knowledge Layer Connector
    • Some background noise on Haonan's end hampered discussion somewhat.
    • Haonan talked about generators to and from SHACL.
    • Work needed to understand how to connect existing tool, which uses web socket as transport and JSON-schema for message, to the VSS State Storage.
    • Some discussion of schemas in state storage. Danger is becoming bog downed in system design discussions of for example VSS tree vs graph. For know the KISS of VSS key/value pairs is beneficial in its flexibility.
  • In coming weeks we need to consider roadmap/backlog/work package definition, in part so we know what we want to say at the AMM.
  • Steve outlined eco-system discussions related to EU Horizon and with Volvo/RemotiveLabs related to feeders.
• AoB
  
  • Paul mentions the work on Covesa website related to project descriptions. Data Arch will need to check their entries.

14th February 2024

Agenda:

1. Spring AMM sessions
2. Central Data Service Playground
   1. Status
   2. Knowledge layer connector
3. AoB

Minutes:

• Central Data Service Playground
  • Status
    
    • Online doc: AI for Steve to work with Ulf on his Hugo PR remains open
    • Steve has brought the Playground Kanban up to date.
    • Apache IoTDB: Steve has implemented 'set' connector for WAII locally. Code is available in his github fork. Preparing PR to both Playground and WAII.
    • Realm:
      • Steve met with Humza/Arnaldo last Friday to show his integration into WAII
      • Currently Arnaldo considering how best to do the integration. Options include adding Realm as a State Storage backend for all data, e.g. like Redis and IoTDB, or using it in a supporting role where it makes sense, e.g. sync or in Example.
  • Ulf announced he is adding https://memcached.org/ (fast simple key/value pair in-mem store) as an additional State Storage backend to the WAII VISS Data Server.
  • Knowledge layer connector
    • Haonan has posted first draft of problem outline for the connector to slack in document form whilst she sort out Confluence access:
      Covesa Playground Piece_ Data Converter between DM and Reasoner-v21-20240214_101149.docx
    • Group needs to do background reading to come up to speed on the topic.

7th February 2024

Agenda:

1. Spring AMM sessions
2. Central Data Service Playground
   1. Based on discussion with Christian Muehlbauer kick off discussion of Connector in the Playground between the data and knowledge layers
   2. Ulf has sent a PR to add the Hugo online doc: Any discussion needed related to that, e.g. workflow, review
   3. Database connectors: status, handling WAII changes
   4. Feeders (time allowing)
3. AoB

Minutes:

• Spring AMM sessions: nothing to discuss this time
• Central Data Service Playground
  • New feature idea: Connector between the data and knowledge layers in the DIKW pyramid
    • Kick off of discussion first discussed in previous weeks.
    • Possibility to use BMW Research WS to RDF Converter (see Christian presentation below). Christian has some personal leave in coming weeks. Haonan will step in.
    • Haonan offers to do technical overview presentation of converter.
    • Steve suggests using the proposed Artifact design methodology (simplified) as a means to working through what such a Connector should achieve for the Playground. No dissentors. Haonan agrees.
    • Way forward:
      • Haonan will do a technical overview presentation in a future meeting. Goal: group better understands the converter. Date TBD once she is ready.
      • Haonan kindly agreed to do a first draft using the design methodology to define what a Playground Connector should be from her perspective (domain expertise). This can then be used as a basis for wider discussion in the group.
      • AI: Track in meetings.
  • Online documentation
    • Ulf has posted PR to add Hugo static website generator. He needs support to add github workflow to automatically build the doc and publish. AI: Steve to work with Ulf on that.
    • Requst to review PR. Will look to merge in next week.
  • Database Connectors
    • Steve has the 'get' connection between WAII and Apache IoTDB done. Preparing to make code public. He expects 'set' to be added this week.
    • Humza reports that the Realm DB C++ process is done. Just need to integrate into WAII. After discussion Steve will meet with Humza/Arnaldo to do a quick return of experience with his integration to accelerate adding Realm.
    • Answer to question of how to manage WAII changes before they are upstreamed becoming more urgent. Steve will likely create WAII fork so they can be managed in the submodule to keep us moving.
  • Feeders
    • Short discussion of feeders

31st January 2024

Agenda:

1. WAII update
2. Spring AMM sessions
3. Central Data Service Playground

Minutes:

• WAII update
  • Ulf gave an update on WAII improvements related to the new feeder mechanism.
  • Code is merged to master and documentation can be found in the tooling section of the on-line documentation in the tutorial
• Spring AMM
  • Ulf has added some topics to related to WAII and Commerical vehicles to Paul's Proposal page
  • Arnaldo/Christian have sent a title topic related to touchpoints and the knowledge layer
    • Abstract to be created
    • They say this is possibly less of a readout of existing work and could lead into the discussion of examples and using the Playground
  • Discussion of the third part of the Playground session covering examples and using it and how to incorporate the other sessions
  • Thought needs to be given as to whether to have a formal workshop session in the programme or an informal one with involved members outside the programme
• Central Data Service Playground
  • Status
    • Steve has done initial integration of IoTDB connector into WAII. Builds and runs. Now need to debug integration issues.
    • Arnaldo continues to work on Realm integration. C++ backend nearing completion. Connecting to WAII after that.
  • Phase 1 PoC
    • What are the big picture things in the backlog?
      
      • Source license
      • On-line (Hugo) doc PoC
        • Christian: It would be useful to paint the big picture of relationship to other projects. I can perhaps contribute something in that regard
    • Contributor outline
    • Source documenation

24th January 2024

Agenda:

1. Spring AMM sessions
2. Central Data Service Playground
3. AoB
   1. (Ulf): WAII update

Minutes:

• Spring AMM sessions
  • Steve has added an outline for the three Playground sessions to the planning page.
  • Agreement in meeting to propose those as placeholders in Paul's planning
  • Ulf will add some sessions on his WAII work
• Playground
  • Decision taken to merge Steve's PR to give the project master branch some structure. This will make it easier for others to parallel work.
  • Status
    • Adding Realm: Arnaldo says he has the C++ process written to act as a Realm instance orchestrator
    • Adding IoTDB: Steve is working on connecting WAII to IoTDB using the IoTDB Golang client.
  • Christian presents his initial thoughts overlaying the work BMW have presented in recent AMMs onto the Playground
    • Christian Proposal.pptx
    • General agreement that additional viewpoints are needed to logical and implementation in presenting the Playground and that shared diagrams are useful.
    • Discussion on what components might be open sourced and could be integrated. RDF converter would be a good candidate to examine for providing a connector between data and knowledge layers.
    • Christian will be taking some time off in coming weeks but is hoping Haonan can substitute as she is very familiar with the RDF converter.
  • Open decision: need to agree how to handle WAII changes. Upstream, fork for git submodule or git subtree for example?
• AoB
  • Ran out of time. Ulf prefers to defer WAII update to next time.

17th January 2024

Minutes:

• Discussion of Spring AMM sessions.
  • AMM Commitee wants to make schedule public end of Jan
  • Data Arch planning page here 2024 Spring AMM Planning (Data Architecture and Infrastructure). Feel free to add your ideas there.
  • Steve proposes three linked themes for sessions on the Playground
    • High level intro (why, what)
    • Technical overview (more detailed on how and the code)
    • Focus on using the playground through examples. Akin to the BMW presentations in prior AMMs.
  • General agreement that would be good approach.
• Central Data Service Playground
  • Steve summarises Friday meeting with Arnaldo and Christian/Haonan. Succesfully worked through Arnaldo's issues with WAII Docker bring up.
  • Arnaldo documented list of gaps in instructions for a clean build.
  • Steve used this to raise additional issues in WAII github with doc or code gaps.

10th January 2024

Agenda:

• Central Data Service Playground
• Database abstraction and feeders
• AoB
  • Ulf has WAII update

Minutes:

• WAII update from Ulf
  • VISS specification contains consent meta-data mechanism in addition to security control. This consent mechanism is now implemented in WAII.
  • PoC demo of WAII consent together with AIDEN consent framework at Spring AMM. Ulf intends also to present.
  • Work continuing on new feeder architecture he presented in Detroit. He also intends to present update at AMM.
• Central Data Service Playground
  • Steve outlined status:
    • Been working with WAII maintainers to work through some some issues in upsteam documentation and docker configuration. Thanks to them for support.
    • Steve PR has a basic (incomplete) Playground docker deployment that now works.
    • Apache IoTDB is running as VSS Data Store. Can execute IoTDB CLI client in IoTDB container and communicate with the server.
    • WAII is running as VISS Data Server. Can execute WAII javascript HTML client in WAII container and communicate with the server.
    • Steve did live demo of above.
  • Realm
    • Arnaldo still planning to create a runtime app that can act as admin process for a Realm DB based backend.
    • He asks if C++ is best fit for client API?
    • Initial discussion suggests it would be. Other SDK options in Realm are orientated towards mobile development.
    • Christian makes good point that Flutter support would be useful for reusing the existing BMW code and supporting the mobile/cloud deployment.
      • Christian needed to drop 30 mins in. Follow up on discussion of adopting existing BMW code to Playground required.
  • Arnaldo suggests side meeting with Steve to accelerate his work.
    • Steve happy to meet.
    • Christian would also like to attend such a meeting so he can get up to speed. Early next week (post CES) best for him.
    • Steve will send invite. Arnaldo would like meeting Friday.
  • DB abstraction / feeders
    • Steve reports he has looked at kuksa CAN provider and thinks it could be interfaced.
    • Discussion of possible DB abstraction
      • Steve: is there something we can do to encourage more joint work on feeders by making it easier to interface them northbound.
      • Gunnar suggests doing some native code to see if there is similarity

3rd January 2024

• Small scale meeting kicking off new year.

13th December 2023

Agenda:

• Central Data Service Playground: progress, roadmap
• End of year holidays: When to end and restart?

Minutes:

• Apologies: Ulf, Christian
• Central Data Service Playground
  • Progress: Steve reports some problems were found with WAII Docker support, but now addressed. Now working on IoTDB. Currently blocked by runtime issue. Asked for input upstream. We will not achieve the hope of having the base Docker up by 2023 work stop. Will need to push on with that at start of 2024.
  • Roadmap
    • Covesa Board and officers are looking to build roadmaps early in 2024 for strategic development. Playground will be part of that. Suggest we get the Phase 1 PoC working asap in 2024, then use the review of that both to define Phase 2 as planned, but also seed the ideas for this Roadmap request.
• End of year holidays:
  • Richard informs GM will be finishing next week as well.
  • No meeting Weds 20th and 27th of December.
  • In 2024 do we restart on Weds 3rd or 10th of Jan? As 10th will be CES and many people will be there decision to restart on 3rd for those who can make it.

6th December 2023

Agenda:

• Central Data Service Playground
• Autosar Vehicle API
• BMW Knowledge Layer paper
• AoB
  • End of year holidays

Minutes:

• Apologies: Humza, Arnaldo
• Steve summarised the status update given by Autosar Cloud WG earlier this work on their work on Autosar Vehicle API.
  • Good work done on Autosar to VSS conversion.
  • Current concept is focused more on translation, with greater freedom on northbound protocol compared to the API Gateway concept they expressed before project setup. They are looking at VISS northbound for instance.
  • Look at the Cloud WG artifacts (Autosar membership required) for details.
• Christian gave an explanation of the Knowledge Layer paper that he mentioned previously that BMW were working on and is now published.
  • Paper: https://www.scitepress.org/Documents/2023/122550/
  • Discussion of split between "query" front end language and data layer connector in backend providing data. In current implementation there is not a GraphQL Resolver style fetcher that could be connected to a DB. Instead the data schema is directly synched to the app logic.
• Central Data Service Playground
  • Steve gave quick intro to Christian on source structure.
  • Further changes pushed since last week including fuller docker compose for the Playground with Apache IoTDB backend. To make changes more visible Steve has created a WIP PR in the Covesa git rep https://github.com/COVESA/cdsp/pull/16
  • Christian has some ideas about using the Playground for Knowledge layer experiments. Will talk to Daniel about these and come back later.
  • Humza reported offline that MongoDB will look at Realm backend next week.
• End of year holidays
  • Christian: will finish around middle of wk 51 (week before xmas) and back wk 2 in '24.
  • Ted: out xmas week
  • Steve: last full week is next week. Will finish early wk 51.
  • Result: Next week will be final meeting of '23.

29th November 2023

Agenda:

• Central Data Service Playground
  • Updates
    • Basic structure
      • Doc, Examples, Docker, Source, Best Practices
    • PR
    • Docker
      • Compose structure
      • Docker Hub
• AoB

Minutes:

• Apologies: Humza, Arnaldo, Christian.
• Central Data Service Playground
  • Steve summarizes progress
    • His hacking taking place in github fork https://github.com/slawr/cdsp/tree/phase1poc
    • WIP PR pushed to Covesa rep
    • Basic directory structure in place for Doc, Examples, Docker, Source
    • Best Practices/Design Guide file started to act as a notebook as we go to record guidance.
    • Discussion of Docker Compose approach including pushing images to Docker Hub.
• AoB
  • Paul reminds about the sync call with the Autosar Cloud WG Thursday. Brief discussion about their use of VISS. Need to hear what they have to say to progress.

22nd November 2023

Agenda:

• Central Data Service Playground
  • WAII State Storage abstraction discussion
    • Source Ref:
      
      • https://github.com/COVESA/ccs-components/tree/master/statestorage
      • https://github.com/w3c/automotive-viss2/tree/master/server/vissv2server/serviceMgr
      • Redis PR: https://github.com/w3c/automotive-viss2/pull/28/files#top
    • Topics:
      • Lifecycle:
        • Init: DB, client,..
        • Data Access: Get/Set/Sub
        • Shutdown: DB, client
      • Schema sync:
        • WAII Statemanger and feeder need to understand DB schema
• AoB

Minutes:

• Central Data Service Playground
  • MongoDB can only attend first 30 mins, so state storage discussion split into two 30 mins slots.
  • 1st 30 mins (all)
    • Paul asked about peoples perceptions of production readiness.
    • Ulf began description of WAII storage implementation
  • 2nd 30 mins (UIf, Humza, Arnaldo, Steve)
    
    • Ulf completed description
    • MongoDB asked Qs.
    • Some important notes
      • Ulf has changed implementation on Master branch so Set writes directly to feeder for latency reasons
      • CCS State Storage github is just an example. It is not consumed by WAII and therefore WAII Service Manager implementation is in focus.
    • Out of time. Continue discussion in Slack.
    • Ulf on holiday next two days.
    • Humza/Arnaldo busy with show next week. Following week they will look at Realm implementation.

15th November 2023

Agenda:

• Playground big picture: Continue discussion of what/why/how
• Tasks towards the creation of the Playground PoC
• Playground use cases both for us and externally
• Spring AMM

Minutes:

• Big picture
  • Ulf: interested in helping with WAII/VISS parts. The Realm Sync work between MongoDB and BMW would be an interesting feature to add.
  • Discussion of WAII State Storage abstraction and future possibilities.
    • Ulf: Current implementation reflects needs of the VISS protocol.
    • Whilst it will not allow you access to full performance of the DBs its agreed that as a first step it makes sense to integrate to the current abstraction. Then consider internals to meet additional requirements as follow up work.
    • Realm is an application DB rather than a standalone service. Discussion of creating a thin Shim or Connector application to interface Realm to WAII State Storage abstraction.
    • Christian: Future work on the northbound state storage abstraction would be interesting topic.
• Tasks for creation of Phase 1 PoC
  • State Storage integration
    • See above for discussion on Realm
    • A side meeting will be arranged for interested parties to discuss. Steve will post on slack.
  • Steve outlines thoughts he had for source repository structure:
    • Source of Central Data Service Playground itself
      
      • Docker
        
        • DockerFile for image
        • docker-compose spinning up image
      • Yocto, SOA etc.
    • Doc
      • Playground (What, Why, How, Best Practices), Connections to other components, Dev, Use Cases etc.
    • Scripts
    • Diagrams
    • Use Cases and examples (e.g. docker-compose collection for docker deployment)
      
      • hello-world
      • Christian's case
      • Sync
      • etc.
• Use cases and use outside the group
  • Discussion of using docker-compose to organise use-case examples.
  • Discussion of possible uses of the playground within Covesa.

8th November 2023

Minutes:

• Central Data Service Playground
  • Steve summarised the work over the last week.
    • Main task tickets are now done for the Phase 1 PoC. In big picture terms main missing areas are testing and use cases.
  • Caught Christian/Humza/Arnaldo up on last weeks discussions
  • Use Cases
    • Christian posted an idea as input to slack and will add it to the Early Planning page. Some discussion of it has already taken place in Slack.
  • Road map / timings
    • Steve: It would be good to have Phase 1 running in some form by the end of year holidays. That's only 4-6 weeks away. AMM will come very quickly in 2024. Need to keep tempo up.
    • Christian: What is in Phase 1?
    • Steve: Some discussion in previous calls and the minutes but detail is not recorded. Goal was to quickly hack an early PoC that allowed us to trial somethings and have code to work with. But let's create a summary now.
    • Summary scope added to Early Planning page. Attendees agreed scope.
  • MongoDB Realm
    • Some discussion of Docker support and connecting it to WAII.
    • Arnaldo informs that like SQLite its intended to be linked to an app, rather than provide a standalone service.
    • Some discussion will be needed how best to interface it. Could create a shim to allow WAII to read/write to a Realm DB.
    • Arnaldo will consider Realm aspects.
  • Proj Mgt
    • Discussion of Github Project limitation that seems to require people to be a member of the COVESA organisation to be able to assign them in Project tickets. Paul will add missing people.

1st November 2023

Minutes:

• Central Data Service Playground
  • Holiday today in Germany
  • Project Management
    • Steve runs through what he has done for project setup. Github Project site and source rep created. Some tickets added. Links added to the project page.
    • People happy to try what has been created.
  • Source license
    • Steve: We will soon be creating code. Which license to use? There was some recent external queries about MPL-v2.
    • Paul: MPL-v2 remains the COVESA default.
    • No strong preferences expressed beyond something permissive.
    • Steve: Changing later can be a little painful so have a think and we can decide in a week or two. MPL-v2 is most likely candidate
  • DBs
    • No one present from MongoDB. DB discussed postponed. Steve will setup side meeting with Ulf and anyone interested in discuss WAII DB backend interface State Storage.
  • Related projects
    • WAII
      • Ulf: Peter Wenzell's work on updated Docker support and feeder for RemotiveLabs sim playback has been merged to Master.
  • Requests:
    • Please add any topic you think we should be investigating either to the Confluence Early Planning page or as a ticket to the Github Project.

25th October 2023

Agenda:

• 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.

Minutes:

• Serialisation
  • Adnan outlines (Adnan Bekan correct me if my summary is incorrect):
    • BMW will have a researcher looking into message serialisation between vehicle and car.
    • Scope is the payload only. Not the transport. However some flexibility in terms of what is sent in the payload is required.
    • Can something be done in the open in standardising this? Also looking for input on approaches.
    • Adnan notes the work done in the past during CVII Tech Stack days using AVRO with the esync alliance, but feels that is a heavyweight solution.
  • Various suggestions made about some possible approaches, such as encoding methods that take advantage of sparcity or lack of change.
  • Steve: the cloud connection has been cold for a while but only because its been waiting for someone to run with it. This should be of interest a wide group. I would recommend writing an outline or proposal of what problems you want to tackle down, along with some requirements. From that other inputs can be gathered along with people to work on it and a project formed. This should be of interest to the Commercial Vehicle group for example and their telematics requirements.
• AMM wash-up
  • Christian: various gateway solutions appearing, e.g. PennyBecker, HIM, Vehicle API etc. Implementations at different levels. Would be good to understand what they look to achieve as some are not directly comparable.
  • Arnaldo: difficulty for newcomers to get started. Wiki can be overcomplex to understand.
    • Data Arch landing page needs cleanup / simplification.
  • Neil: Agree. Some attendees talked to showed interest, but not everyone understands.
  • General agreement for the need for more guiding documents like HowTos.
  • Steve: I intend to remake the Data Arch landing page as discussed before the AMM to make it easier for newcomers.
  • Other sessions - Ulf southbound architecture session
    • Steve: Peter Winzell said in the W3C slack that he was working on a southbound feeder to WAII connected to Redis. Is it related to your work.
    • Ulf: Peter is using the WAII feeder framework I described in my session. His feeder connects to the RemotiveLabs simulator. As part of his work he's also updated the WAII DockerFile to use the latest code.
• Central Data Service playground proposal
  • Only 10 mins remained. Will be main topic next week.
  • Steve: Please consider what the near term next steps are, what use cases you want to explore and how we should organise the work.

12th October 2023 - AMM Data Architecture Workshop

• (these are incomplete notes made after the event) 
• Workshop delivered as planned, except for compression of time on doc proposal:
  • Mongo DB/BMW (9-9:45)
  • 10-10:15 break
  • Central Data Service Playground (10:15 on)
    
    • Part 1: Readout of the proposal
    • Part 2: Workshop the base components and the possibilities for 'spins' using it
      • As well as the names below Piotr Krawczyk Neil Puthuff and Halim Ragab actively engaged in the discussion, along with Arnaldo's colleagues. Apologies if I missed anyone from the list - let me know.
        
        • Piotr suggested MQTT as event queue (see whiteboard picture)
        • Halim was interested in the project but wanted to know the boundary performance (latency etc) of the Service to be able to understand how it would fit in the overall performance of an end to end touchpoint. He took an action to provide input on what GM requires.
      • Outcome: Ford (Ulf Bjorkengren), BMW (Christian Muehlbauer), MongoDB (Arnaldo Vera Humza Akhtar) and Renesas (Stephen Lawrence ) all expressed interest in actively contributing. Enough interest to begin the project.
      • Whiteboard Images:
      • 
      • Group shot after the end of the session:
      • 
  • Documentation proposal discussion: 30 mins to be fitted in
    • As the Playground workshop was going well this was condensed with Steve simply showing some slides on the wider eco-system need for documentation on HowTo's etc.

4th October 2023

• Christian back after a long holiday. Brought him up to speed and reconfirmed MongoDB/BMW session starting the Architecture workshop
• Central Data Service playground proposal
  • Steve had got enough of the draft outline written for the intention hopefully be clear. Ran through it with the group.
  • Little time left to discuss but Arnaldo, Christian and Ulf are postive about the discussion.
  • Once the runthrough is repeated for others in the work at the AMM an early task will be to get feedback from the Architecture members.

27th September 2023

• AMM
  • Discussion of what to report in the Data EG readout
    • Data Arch
      • Thurs AMM workshop
      • ..
      • Ulf Southbound session
  • Data Arch workshop
    • Arnaldo confirmed the MongoDB/BMW session.
    • Steve has written some of the outline for the Central Data Service playground proposal and went through it. Target will be to get more of it done for next week.

20th September 2023

• AMM planning
  • Workshop
    
    • Mongo DB/BMW input
      • Christian on holiday. Arnaldo not present.
      • Steve: Anything discussed whilst I was away?
      • Paul B: Arnaldo does not want to run a PoC specific workshop in Detroit. MongoDB session currently moved out in schedule to accomodate possible workshop. Can move back if it makes sense.
    • After discussion the running order from 6th Sept minutes still makes most sense. Basically take MongoDB/BMW sessions and Ulf Bjorkengren session on VISS southbound as input to move onto workshop the Central Data Service Playground propose.
• Discussion of the Ford data model presentation prior Tues and the Blackberry IVY showcase webinar.

13th September 2023

• Paul Boyes facilitated meeting whilst Stephen was on holiday.

6th September 2023

• AMM planning
  • AMM Planning October 10-12 2023 - Technical Session and Workshop Proposals
  • Thursday (9-12:15)
    
    • Mongo DB/BMW (9-9:30)
      
      • Christian says specifics depends on readiness of the PoC.
      • Plan A is to present evolution of the Tiered Sync they have been working on.
      • Recommends contacting Mongo DB to check what plan B is.
    • Central Data Service Playground (9:30 on)
      
      • Part 1: Readout of the proposal (9:30-9:45/50)
    • 10-10:15 Break
      • Part 2: Workshop the base components and the possibilities for 'spins' using it, e.g:
        • Data models: knowledge layer, data models, VSSo
        • Interface pillar: IFEX, service definition, Vehicle API/Autosar
        • Data Architecture: Sync, reasoning at the edge etc.
    • Documentation proposal discussion: 30 mins to be fitted in
• Knowledge Layer proposal
  • Christian will send slides for presentation he made last week
• Paul reminds about the Ford/VSSo presentation next week. See community calendar and slack for details
• Holidays:
  
  • Christian: on holiday from 11th Sept, back 4th Oct. May check email/slack time to time.
  • Steve: holiday Tues 12th-Tues 19th.
  • Paul will host meeting next week.

30th August 2023

• Debrief of Christian's presentation of his Knowledge Layer proposal Tues to VSSo group
  • Has synergy with the Central Data Service playground

23rd August 2023

• Continue work on Data Architecture Pillar Proposals
• AMM planning
• Knowledge Layer proposal presentation?
• Holidays:
  • Steve on holiday next week. Meeting? Yes, Paul will host.

10th August 2023

• With summer holidays a sparsely attended meeting this week. Started with 3, became 5 in 2nd half. As such more informal discussion.
• Some discussion of Tim Welsch's meeting yesterday on Service Registry.
• Some discussion of Christian's Knowledge Layer proposal and what he is considering in certain areas.

2nd August 2023

• Knowledge Layer proposal
  • Christian Muehlbauer has posted his first outline
  • Steve: what would you like to achieve and how best to take this forward?
  • Details in the proposal but Christian would like to explore what would be needed to have a technology agnostic seperation between knowledge and the underlying areas. How would they interact and stay in sync etc.
  • After discussion about way forward, Christian happy for people to promote its existance. Paul/Steve will mention it to other groups. Christian will think how he would present the work in a future 1 hr type dedicated meeting to the topic.
• Document and diagram storage
  • Steve was planning on creating data-arch-doc.git rep to get us started.
  • He brought topic up in Thursday call. Erik mentioned the existing (little used currently) Data EG git rep. That is probably a good place for top level diagrams like the scope diagram.
• AMM planning
  • Steve has added a planning page here 2023 Autumn AMM (Data Architecture and Infrastructure) 
  • Steve: any feedback from request last week to consider what we want to discuss?
    • Christian Muehlbauer discussing internally about what we might be able to show. Workshop could discuss knowledge layer proposal.
    • Arnaldo Vera Some possibilities we are discussing: Tooling for conversion to JSON-schema. Realm for OTA. Connected car sync.
      • Steve mentions Adnan Bekan PR for a VSS vspec to json-schema tool. Arnaldo will take a look.
    • Stephen Lawrence Store/Server playground, Design doc publishing.
    • Ulf Bjorkengren plans to present update on HIM including new additions.
  • Paul Boyes interesting to see conceptual design/requirements for connecting signals to non-signal info/knowledge in-vehicle and on to cloud.
    • Discussion of how this relates to other areas. Some topics likely best as a wider group workshop, e.g. combining data models
    • Paul will be posting table for Thursday tracks for planning purposes
• Data Pattern proposal
  • Steve has restarted completing the text. Currently working on the publishing section
• Data Arch front page redo is open AI.

26th July 2023

• Data Pattern proposal
  • No change due to the collab meetings last week. Meetings confirm the need - see below.
  • Steve will return to completing the draft.
• Knowledge layer proposal
  
  • Christian catching up after holiday. Still intends to upload the proposal for feedback.
• Topics arising from collaboration meetings (EU Horizon, SDV Summit, Covesa Board F2F) last week
  • The Covesa Scope diagram was used in EU Horizon SDV group to discuss SDV. It was also used in SDV Summit.
  • This both shows Covesa materials being used externally and their value. Basically further proof of the need being addressed in the Data Pattern proposal
  • This flags again some recent topics: where to store them and enhancing discoverability for external people
  • Christian had been considering a diagram showing how Data Arch relates to the other topics. He'll have a go at drafting it.
• Git rep / where to put diagrams
  • We have had some discussion previously but now with the external use we need to move to a solution to encourage re-use.
  • Steve: I still am not in favor of a 'big bucket' repository containing all source and docs. Source should be organised by product for reuse. I would suggest starting with a git rep dedicated to documentation, e.g. data-arch-doc.git
• Discoverability
  • Feedback from last week shows discoverability could be improved.
  • Christian: when I first came to Covesa/VSS work I found it easiest to orientate myself from the VSS (Hugo) document website.
  • We know this and had been prioritising getting the tech work going. However now need to address it.
  • Three main touchpoints immediately come to mind:
    • data-arch-doc.git
      • Holding doc, diagram source
    • Hugo data arch documentation website
      • Serving rendered documents as per the document proposal
    • Confluence Data Arch landing page
• Reforming group landing page
  • Steve: I'll try and find the time to bring the Data Arch Landing Page up to date, e.g. show the Scope diagram there. At least a draft for review by the group.
• AMM
  • Steve: we need to start considering what we want to do at the AMM.
    • I would expect a Data Arch pillar intro as usual, possibly as part of Data EG intro.
    • I would also expect somekind of combination workshop + presentations for the Thursday as we have done in the past, but need your input.
  • AI: Consider what you want to discuss/present
• Discussion on process of creating content for Hugo documentation website
  • Christian: People may think it is a single persons viewpoint if its all markdown in a single git post
  • Steve: Yes collaboration on the text will be needed in many cases. I would suggest for such documents the draft text be worked on somewhere collab is easier. Confluence has inline comments for example. Of course direct to markdown or something else is also possible. Point is to make it easier to comment and discuss.
  • Steps could be:
    • Creation stage:
      • Collab on text (Confluence, whatever)
      • Convert to markdown(github)
      • Sign-off
    • Publishing stage:
      • Move markdown to Hugo tree
      • CI Runner generates Hugo site and publishes to production
        • <Possible to have a parallel CI for WIP if needed>

19th July 2023

• No meeting due to collaboration meetings F2F in Cologne

12th July 2023

Agenda:

• Data Pattern / Arch proposal
  • Discussion of changes since last week
• Knowledge layer
  • No discussion as Christian on holiday
• Next meetings / holiday planning
  • Ulf: 2 weeks after F2F
  • Arnaldo: last two weeks
  • Richard: 18-21st Aug.
  • Meeting cancelled Weds 19th due to meetings in Cologne
• News
  • VISS WAII reference implementation
    
    • gRPC added to MQTT, WS and HTTP as transport protocol. Payload is compatiable with the others.
    • Discussion pending in W3C VISS standards group to add gRPC to VISSv2 standard.

5th July 2023

• Knowledge layer
  • Christian has made further progress on his document.
  • Discussion of some of the points.
  • It is complete enough that Christian would soon like to get feedback and input and asks about how best to do that.
  • In terms of publicity Steve says Paul can help, but he would suggest other Data EG meetings and the slack.
  • In terms of publishing Steve says he was meaning to add a "Proposals" sub-page to the Data Arch Confluence to organsie proposals under including his own Doc proposal
    • Steve creates https://wiki.covesa.global/x/fIE8B
• Data Pattern / Data Architecture proposal
  • Resolved new comment from Christian
  • The Current Situation section draft is now complete.
  • Started work on the proposal section. Added some bullets to the summary outline.
• Next few meetings
  • Steve: I may have a funeral to attend next Weds. There is also the Board F2F the following week and I will not be able to run the meeting. Do you still want to meet?
  • Holidays:
    • Christian: July 6→16th,
    • Ulf: not confirmed but expect End of July→mid Aug
    • Steve: considering a week at the end of July but would probably be around to run the meeting.
  • As only three people on the call Steve will send an email to the group to see what people want to do.

28th June 2023

• Knowledge Layer
  • Christian Muehlbauer showed the state of his work (currently in Word doc) on his Knowledge Layer ideas.
  • Positive feedback for him to continue.
  • Some discussion of the implications.
  • Arnaldo raises point about sharing knowledge decision is analogous to conflict resolution in data centric arch sync. Who decides the knowledge, communicates it and receives an update. Only want to store state when it changes.
  • Steve suggested a top down approach to the description to seperate the most generic ideas from the more specific ones. Basically to avoid a 'must adopt it all to be relevant' issue.
  • Steve asked Christian to let us know when he wanted to get a wider view on the work.
• Data Pattern / Data Architecture proposal
  • Steve has made some good progress since last week.
  • Majority of the text for the current state of play is now done.
  • Will now move onto next steps.
  • Socialised the initial proposal and the idea to use Hugo for publishing to Technical Steering Committee and Data Expert Group with no push back.
• Git rep naming
  • Steve gave some thought to this after last weeks discussion.
  • Still reluctant to have a single 'big bucket' git rep for the usability and maintainability reasons that is not normally done in engineering practise.
  • However likely don't want 20 reps either.
  • Steve: How about as a starting point to have some level of classification to narrow its scope, e.g. data-arch-doc.git or data-arch-doc-arch-patterns.git?
  • No clear answer. Team asked to think on it as we will need to make a decision fairly soon.
• News
  • Ulf Bjorkengren has published documentation in his HIM proposal
  • In VSSo call there was a heads up that Daniel Wilms had a proposal for using GraphQL schema to create VSS graphs. Intention was to present to the VSS group in a couple of weeks.
  • Adnan explains that Data Centric Architectures has been listed as a need in the topics to be tackled within the EU Horizon SDV project.

21st June 2023

• Data Arch rep naming discussion
  • Short initial discussion of how to organise git repositories for the data arch pillar.
  • Single 'big bucket' vs project specific?
  • Ulf suggests big bucket
  • Steve concerned about maintainability of big bucket.
  • Steve: please consider what you want and we will discuss again
• Refining Steve's Data Pattern / Data Architecture proposal 
  • Steve outlined his idea to use online publishing paradigm already used in Covesa for VSS doc. Brings all the docs together and is useful to link to for non-engineers.
  • Feedback was positive.
  • Christian added comment about sync which is now resolved
  • In meeting added Knowledge layer as a topic to the content list
    
    • Christian working on outline based on idea he explained recently
    • Wants to know where he would put it?
    • Steve: need to resolve the question of data arch rep naming. In meantime depending on your format you can push to the google drive, create personal git rep, or I can create you one in my area.

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 Reasoning (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 and mentions he intends to explore some of this in his HIM project.
    • One area of possible interest is standardised knowledge representations. You derive some knowledge from standard data. Is there a standard way to represent the knowledge? This has benefits in loosly coupling the knowledge, from possible consumers.
    • 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

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.

24th May 2023

• Data Architecture Terminology.
  • Steve has reworked the VSS-Feeder component text to be VSS Connector as discussed last week.
  • Discussion of handling Data Sync function as its own component so it can be a part of both Data Server and Data Store. Agreement to try it that way. Arnaldo will take a look at the description based on their experience with Realm Sync.
• PoC
  • Ulf asks about the goals of the PoC. After summary from Steve (see 10th May minutes for summary) he thinks it could be useful and hopes to find some time to participate.

17th May 2023

• Minutes made a week later and so may be less complete
• Data Architecture Terminology.
  • Continued review discussion
  • Sync
    • Christian provided input offline about including Sync as he has discussed in his presentations.
    • Open question was how best to include it and preserve the fact that the functional descriptions can be combined in a product. So whilst it might be most likely in the State Storage as he has been using it, it could be elsewhere. Perhaps describe it as component itself, which can then be used by either State Storage or Server?
  • Data Feeders
    • Ulf feels Feeder suggests a uni-directional flow Northbound when it could be in both directions. Can we rename to something else? He suggests Bridge but is open to alternatives.
    • Steve also suggests Connector.
    • Steve will try rewriting the description using the suggested names.
• Diagrams
  • Steve has started recreating the Deployment Scenario diagrams from the 2023 Q1 Workshop in Miro https://miro.com/app/board/uXjVPoh2zow=/?share_link_id=262317958896 in DrawIO so they can be easily shared, and edited.
  • As a working area he has created the sub-folder Deployment_scenarios in the Data Arch scratch area of the Data Expert Group Google Drive.
  • First diagram to be converted was the top level Logical Architecture showing the Data Expert Group scope which can be found here Logical Architecture Overview.drawio.svg
    • This was a first pass conversion. Not yet looked to see if it needs resizing to fit into common use cases in A4 document or slide
  • Happy to get help in recreating the others..

10th May 2023

• Data Architecture Terminology.
  • Steve did first pass review and made some edits.
  • Got feedback from Felix.
  • Intention is that along with the diagrams this becomes the basis for 'logical component' discussion in the Data Expert Group
•  Diagrams
  • Christian: We should show that the data server/state storage combination in-vehicle can be reused in the cloud and mobile device as well, i.e. data centric architecture reuse of arch.
• PoC
  • Christian: Is this intended to be public?
  • Steve: Yes
  • Illustrations to show possibilities:
    • Covesa github all public
    • x86 docker
      • Major components of the basic 'lego':
        • VISS data server, e.g. WAII
        • State Storage, e.g. add Realm, Apache IoTDB
      • Step 1: DBs via WAII (CCS) State Storage component
      • Step M..N trials using the basic lego to prove/investigate various topics:
        • High frequency
        • Knowledge pyramid, AI at the edge
        • Multiple data models
    • Automotive H/W
      • Generic code could be implemented on Automative H/W for some appropriate topics, e.g Latency Southbound
    • Feedback:
    • Piotr: Could have a PoC variant that shows support for different OSs via vsock for example to show possibility of southbound data from various sources in the car.

3rd May 2023

• Welcome to Arnaldo Vera from MongoDB. Short overview of the work of the Data Architecture pillar.
• People report successful AMM
• Combining VSS with other data models
  • Logistically neither Ulf or Christian get to each others presentations on this subject
  • Positive discussion to look at the proposals and find commonalities for way forward
• Logical Components / Terminology
  • Discussion of the usefulness of logical component diagrams as found in the CVII Tech Stack/CCS diagrams and the Terminology Dictionary.
  • Avoids the competitive aspects of talking about products, falling into specific system architectures and gives a common approach for discussion.
  • Useful for design patterns, deployment scenarios and architecture documents.
  • How to move towards a common view?
    • Review terminology list.
    • Christian will see how the components fit the i7 showcase demo.
    • Collectively iterate both the terminology and diagrams.
• Data Server / State Storage PoC basic building block
  • Steve summarised the discussion Thursday at the AMM to create a basic building block PoC consisting of a Data Server and State Storage.
  • The aim is a reusable component that could be configured to extend it for use in various deployment scenarios, e.g. connecting Vehicle API gateway.
  • At the same time the basic block could also be used to investigate connections between server and storage, e.g. low latency data.

26th April 2023

• No meeting due to AMM

19th April 2023

• AMM planning
  • Steve added an AMM sub-folder to the group scratch Google Drive:
    • https://drive.google.com/drive/folders/1R4HJc7g-q-3WmjXm1DyJfzdaHiv0Auvj?usp=share_link
  • Tues Intro
    • Steve has merged the prior outline into the template and uploaded a new working draft to the above folder.
    • Needs completing by Steve/Christian
  • Thur Data Arch Workshop
    • After discussion agreed final workshop makeup.
    • See planning page 2023 Spring AMM (Data Architecture and Infrastructure) Workshop
    • Paul: we should invite the ontology group to the data model discussion.
    • AI: Need to ask data-science/ontology group to the session.
  • Arrivals
    • Christian arriving Sunday, but working on car Monday. Steve Sunday. Felix Monday.

12th April 2023

• AMM planning
  • Tues Intro
    • Steve/Christian discussed the outline.
    • Steve will redo the draft outline in the AMM template towards end of the week.
    • Christian will work on his Data Centric slides in parallel.
    • Aim to merge and finalise next week
  • Wed Deployment Scenarios
    • Nothing new to discuss
  • Thur Data Arch Workshop
    • No outlines yet from Christian or Felix (see last week) for their proposals, or Felix's workshop.
    • Christian: I am meeting with Felix tomorrow in Munich and should be able to finalise my session afterwords.
    • Discussion of Deployment Scenarios proposal. See workshop planning page for notes.
    • Piotr: Might be idea to put Deployment first in the running order as somewhat of an introduction.
    • Piotr: One topic for discussion could be the management of version compatibility between components
      • Piotr describes some examples. Such as Vehicle API supporting different VSS versions
      • Steve: Interesting questions. Can you create something like a summary of the problem scope and what needs to be tackled? That could then be used in various ways at the AMM, e.g. Vehicle API workshop Friday and afterwords.
      • Piotr: yes.

5th April 2023

• AMM planning
  • Intro
    • Steve: As the Intro contains slides from Christian on his views on Data Centric Arch would he like to present that part?
    • Christian: OK
  • Deployment Scenarios
    • Steve expresses concern that we (Data EG) advance the Deployment Scenarios whilst at the AMM. 1.5h session is not enough..
  • Data Arch Workshop
    • Share updates and proposals:
      • Christian thinks he can do a Different Data Domains (approx 20-30 mins)
        • Presentation on BMW experience.
        • Starting from using personal data as example of different data domain and moving to data middleware.
        • Steve: m/w may be handy bridge towards follow on discussion of persistence
      • Felix: Persistence
        • Presentation on classifying different persistence options
      • Steve: Persistence
        • Steve:  My usual topics:
          
          • Data Server to Data Store connection, including high volume data
          • How Data Store can support Data Centric Arch, e.g. Data analytics using TS DB features
          • etc.
      • AI: Add outlines for each proposed session to the planning page so ppl have an idea of what is to be discussed and what the hoped for outcome is.
  • Thurs PM/Friday
    • Return of experience: Felix proposed a workshop using tech from the work between BMW and Mongo.
    • AI (Felix): add outline to the planning page as above.
    • From discussion this could be scheduled Thurs PM

22nd March 2023

Agenda:

• Roadmap creation
  
  • Any updates on internal discussions / Action Items
• AMM Sessions: Intro, Deployment Scenarios, Workshop

• Roadmap creation
  • Updates on internal discussions / Action Items?
    • Christian summarised the result of BMW discussions about the AMM. It's not finalised by some update on results from the internal PoC work should be possible. Unclear at the moment if its a longer session, video of the PoC, or some slides.
• Organisation
  • A Data Arch Planning Page has been added into the Data Arch Confluence tree to organise planning pages. Including a sub-page for the upcoming AMM Data Arch Workshop
• AMM
  • Steve summarised the three main Data Arch sessions:
    • Tues PM: "Data Arch Intro (currently called "Data Centric Arch" in schedule)" (Steve/Adnan)
    • Weds PM : "Deployment Scenarios" diagrams (Adnan/Erik/Steve)
    • Thurs AM: 9-11am Data Arch Workshop (all)
    • In addition there is a Data Expert Group general update that will mention the Data Arch pillar (Steve) and Friday an all day Data EG Workshop which of course will include Data Arch topics
  • Data Arch Intro
    • Steve showed a rough outline of the ppt discussed previously
      • Data Arch Intro.pptx
    • Group agrees with the approach
  • Workshop
    • Steve: I would like to have a topic skeleton for us to follow to keep things on track and avoid too much unproductive tak
    • Felix suggests 3-4 topics if we have two hours
    • Felix and Steve both interested in Data Storage/Persistance.
    • Christian suggests requirements of "Different Data Domains (which means also models)"
    • Discussion of possibilities
      
      • Felix offers to do 10 mins on OSS version (minus sync) of Realm
      • Steve shows the diagram hacked on last week which facilitates discussion of relationship between storage, server and feeder (Felix away last week). Interested in possibilities that functional storage brings, e.g. alternator health example. Felix makes good suggestion to have cleaned-up version which includes high level topics to tackle down (saves jumping around slides in discussion)
    • Group agrees this is a way forward. Needs further work.
    • AI (Steve): Provide a placeholder abstract for the Thursday workshop. Website currently shows the one from last year.
    • Timings
      • Steve: Thursday PM is not packed with sessions so we may be able to expand if needed.
      • Felix: I do not leave until Sunday.
      • Steve: I am the same.
      • Steve: Friday is more a general Data Expert Group workshop but we can of course bring Data Arch topics.

15th March 2023

• Welcomed new participant from Aicas.
• AMM
  • Friday workshop
    • Paul: who can make it?
    • Christian: BMW (Christian/Adnan/Andre) has an appointment Friday. Need to have internal discussion about what we can do that day
    • Piotr: Flying later, should be available in the morning.
    • Ulf: Need to leave in the afternoon for my flight
    • Steve: available all day
  • Steve: That's useful as it shows that the Thursday morning workshop 9-11am will be important moment when we all there. Need to plan to use that time and Friday AM wisely and have an outline of what we are discussing.
• In-vehicle Data Stores
  • Steve reports that he's restarted work adding further storage options as backend to WAII VISS server. Shows rough diagram to illustrate.
  • Initial discussion of some possibilities that could enable
  • Christian: the diagram shows data store holding VSS data. Wouldn't it be useful for other data models also to be stored?
  • Steve: Completely agree. The box is a hold over from the Covesa Tech Stack in-vehicle diagram and should be amended. This is definitely about the arch supporting the various data models required.
  • Piotr brings up some possibilities using a message queue as a data feeder northbound and southbound of data server

8th March 2023

Agenda:

• Roadmap creation
• AMM organisers need to finalise schedule

Minutes:

• AMM schedule
  • Weds
    • Paul: There will me a mgt level VSSo session (as opposed to down in the weeds of VSSo syntax) to be delivered by VSSo team
      • Explain use case and ask for more..
  • Thurs technical track
    • Currently Data Architecture scheduled 9:00-11:00
      • Technical intro
      • ... <tbd>
      • Steve: We need to decide an abstract for this session ASAP
  • Friday workshop
• Discussion / updates
  • Christian summarized some internal discussion. Defining other data domains. Personal data one example. Lessons learned from a few years ago (explained in earlier AMM presentation) starting with using VSS which moved to need for VSSo. He will be talking to Daniel Alverez. BMW may present something at AMM but not yet clear.
  • Felix: Interest in data persistence in-vehicle and data models. They are interested in performant needs for query of automotive data, e.g. GPS data as an area filter.
  • Steve: we have just released v2 of our OSS Whitebox SDK for our R-Car S4 SoC. Included is a Yocto recipe for the WAII VISS Server. The OSS nature of the SDK means it will be a natural integration point for me for our work.

1st March 2023

• Ulf outlines his plan to present forest of data model idea at AMM
• Christian: Internally we have been looking at Ontologies and generation of data models. So interested to discuss Ulf's forest of data model ideas.
• Piotr: Interested in interfacing southbound native data via messaging northbound to VSS.
• Moving forward..
  • Steve: Need to keep eye on mid-term and the roadmap. What we do together. If there is not an appetite to document an architecture as a first step what are we doing instead? Work on viewpoints/touchpoints to find commonalities? Perhaps document some fragments or illustrations - I feel we there are some interesting discussions but we are not capturing.
  • Ulf will document his "VISS" viewpoint over next couple of weeks.
  • Christian will sketch some areas he is interested in. He will also discuss internally?
  • AMM
    • Intro presentation
      • What
        • Scope diagram
        • Goals/motivations and some questions
      • How
        • Documenting Viewpoints/touchpoints
        • Call to action on input/participation
    • What sessions for Thursday? Want to encourage broard input but also need to keep eye on the roadmap

22nd February 2023

Agenda:

• Workshop debrief
  • Do we have agreement on some high level points?
    • Acceptance of the zone arch diagram from Miro
    • Creation of Data Arch / Pattern
      • Outline:

        • Document Goals, Motivations, Questions - Stephen, Andre, Christian, Adnan

        • Illustrate Design Patterns - Stephen, Andre, Christian, Adnan

        • POC Definition [ongoing] - Stephen, Andre, Christian, Adnan

• Arch / Pattern outline Qs
  • General approach / form

Minutes:

• Debrief
  • General agreement around the high level arch diagram and results from the workshop.
  • Ulf: Detail - Revisit arched line from computing to HU in top level diagram
  • Ulf: More than one arch may be possible, e.g. data centric, interface centric (e.g. CCS centricity around VISS)
• Roadmap
  • Steve outlined some possible approaches to describing a data architecture and associated patterns electronically.
    • As discussed in the workshop moving from the general (Goals, Motivations, Questions) to specifics such as Design Patterns and Touchpoint illustrations.
  • Andre will have internal discussion about this
  • Goal remains to build out a work plan

15th February 2023

• Normal hourly meeting cancelled in favor of two afternoons (Weds, Thurs) of workshops to advance the general data architecture discussion.
• See Miro https://miro.com/app/board/uXjVPoh2zow=/

8th February 2023

• Two themes:

  • The general data centric data architecture pattern
    • Motivations/goals
    • Key questions to be answered
    • Data domains:
      • Autosar, Telematic, IVI, etc
    • Data characterisation:
  • More descriptive/prescriptive orientations of the pattern for specific use cases or touchpoints
    • e.g. Android touch-point:
      • Methods of signal abstraction via VHAL or VSS Data Server
      • App connection via cloud and in-vehicle
• Workshop
  • Agreement building
    • Opening
      • Motivations/goals
      • Key questions to be answered
    • Data domains:
  • Roadmap

1st February 2023

• Useful long discussion on finding common ground. Overran by 30 mins.
• Recognition that a workshop soon would be useful to facilitate longer discussion.
• Working towards this 'central text' Design Pattern
  • Data model and technology agnostic
  • Capable of supporting multiple touch points from same arch (robust, flexible etc)
  • Capable of multiple data domains sharing same data m/w
  • Explain requirements but avoid deep heavy specification setting
  • Vehicle is not a single IT blob. Need to engage with reality of requirements from different domains in outlining use cases and touch points: Hard RT vs needs of Analytics, signal read vs storage for processing.

25th January 2023

• Steve: Let's continue discussion of BMW presentation with goal of moving towards a roadmap
• Christian is waiting for permission to make presentation public
• Christian: Requirements are definitely an interesting collaboration point for us
• Felix: Alternative approaches to meet the requirements
• Ulf: I've forwarded the presentation within Ford waiting for feedback
• Christian: Slide 7
  • Important point is the architecture supporting other data models and personal data (arch not be VSS specific)
  • VSSo not just for data integration but enabling knowledge transfer
• Steve: to my mind we seem to be moving towards a central design pattern from which others and implementations may be spun off
• Proposal sketch: Design Pattern: Data Centric Arch including requirements
  • Patterns for Touchpoints
  • Implementations/PoCs proving such
    • e.g Realm showing VSS sync via middleware
• General agreement this makes sense.
• Ulf: The implementation section matches what I am working on in Ford
• Next steps:
  
  • Start to plan the central Design Pattern

18th January 2023

Agenda:

• BMW presenting input for the roadmap

• Adnan/Christian Muehlbauer from BMW presented their input into the early 2023 roadmap
  • Presentation: 2023_01_18_COVESA_Data_Middleware_V2.0.pptx
  • Initial discussion during the remaining time shows overlap in interests between participants. Needs expanding upon. Participants commit to returning next week to continue discussions.
  • Shows in part the usefulness of the proposed longer workshops which might take some of the questions and requirements raised and provide the time for longer discussion.

11th January 2023

(Paul's notes from the meeting)

• Adnan - will bring in arch and use cases for next meeting including use cases
• Goal is to settle on piece that is useful and focus on a piece of the architecture
• Setting up direction for data architecture
  • Setup high level arch
  • Requirements - like objectbox.io
  • List use cases
  • In workshop provide hands on experience
• What is the initial purpose? What are we trying to
  get?
  • Exploring solutions to data architecture
  • Learning how things are built and Thought
    leadership!
  • What solutions look like when provided requirements
  • Learn how to shape with requirements then look at what solutions
  • Community requirements
  • Let vendors show their solutions
• Christian will provide first proposal
• Ted
  • Be able to receive data from OEM - $0.60 a month - Curve logging
  • Want to work on TCU’s directly
  • Willing to work with us
• Adnan - How to improve data handling between car and cloud.
• Stephen - use 80% vss but need to be able to handle other data in addition

4th January 2023

Agenda:

• Continue roadmap discussion including possibility of virtual workshop

• Thoughts over xmas?
  • Ulf has been considering his thin API proposal over xmas and will update in the next Autosar sync call. Has proposal to extend beyond data into procedure calls for services.
  • Steve repeated his intention to resume work on extending state storage to support time series DBs including Apache IoTDB
• Discussion of connection between state storage, VSS servers and the proposed vehicle API

7th December 2022

• EG project announcements
  • Update on Autosar Collaboration
• Xmas break
  • Steve can only remotely phone in next week, which would be the last meeting before Xmas. Nic can't make it.
  • Decision taken to break for Xmas early. This is the last meeting of the year. Thanks to all who contributed.
  • Request: think about the Design Pattern goals over xmas
• Data Arch Theme discussion
  • Proposal to hold a virtual workshop for multiple hours early next year to accelerate the design pattern discussion.

30th November 2022

• 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 of interest in the tech 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 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.

16th November 2022

• Brief recap of Covesa project status
• Continuing discussion of future work
  • Paul: what would people like to see?
    • Felix: interested in GraphQL and connection of databases as data back-end. Along with what benefits data store may enable, e.g. processing at the edge.
    • Nick: ability for apps devs to discover what signals are available and on what terms, e.g. frequency.
  • Answered Felix's question about what work had gone on before.
  • Future is very much open to be set by the group. Cloud needs picking up again - with VSS/VISS now established the original work on CCS could move to other aspects. In-vehicle the component landscape is sketched but much work to be done selecting patterns based on data needs.
  • Steve showed a draft high level data arch diagram showing the proposed Autosar gateway communicating with QM data architecture.
  • Agreement that the interest around data architecture presented and discussed at the AMM is a useful starting point both for PoC investigation and likely creation of data patterns. Let's continue the discussions with a view to creating a strategy.

9th November 2022

• Introductions as we have newcomers Felix Reichenbach (MongoDB) and Francois Ozog (Shokubai.tech)
• Project updates
  • Steve summarises VSS, VSC, VSSo status and EG Leadership discussions around governance and project reporting
• Roadmap
  • Discussion of possible data patterns. What are people interested in?
    • Felix: One area is GraphQL data server shown in the architecture. Would be interesting to have embedded implementation backending to data store.
      • Steve outlines some of the work to date on that including the GraphQL libraries in the Covesa github.
    • Francois outlines his interests around function abstractions.
      • Steve summarises work in that area in Covesa and suggests background reading.