Page History

...

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

25th June 2025

Agenda:

• Continue the work on the use-case examples / planning
  • Planning page: 2025 Spring to Autumn task planning
  • Review CDSP use-case action item: After Berlin AMM CDSP workshop
• AoB

Minutes:

18th June 2025

Agenda:

• Continue the work on the use-case examples / planning
• AoB

Minutes:

• Meeting closed early as there was low attendance.
• Homework is to consider use-case work.
• Steve is working on the COVESA presentation for the Apache Summit
• Ulf reported he is working on a Vehicle API solution

11th June 2025

Agenda:

• Continue planning discussions begun last week
  • Short term: Remaining work on KL/IL, in progress work on feeders etc.
  • Longer term: Example build-out, AI, Doc etc. Also topics from the workshop
  • Planning page: 2025 Spring to Autumn task planning
  • Review CDSP use-case action item: After Berlin AMM CDSP workshop
  • Ulf/Rami proposal
• AoB

Minutes:

• Short term
  • The Apache IoTDB community has asked Steve to present at their upcoming Summit in China about CDSP and its use of IoTDB in automotive.
• Longer term
  • Use-cases After Berlin AMM CDSP workshop
    • Steve presented some detail he added to the Insurance use-case proposal
    • Rami outlined some ideas for a fuel management use-case Use case 2: Fuel management for fleet efficiency
    • Ulf/Rami presented a proposal for fleet management using VISSR.
      • Vehicle2Cloud handled by cloud component "Fleet Communication Manager" which manages VISS Clients that "pull" from VISS Server running in the vehicle
      • The Playground Knowledge Server is proposed to decide what signals to read from the fleet.
      • Christian showed interest
      • Presentation:

        View file
        name VISS-VISSR-fleet-usage.pptx height 250

4th June 2025

Agenda:

• Continue planning discussions begun last week
  • Short term: Remaining work on KL/IL, in progress work on feeders etc.
  • Longer term: Example build-out, AI, Doc etc. Also topics from the workshop
  • Planning page: 2025 Spring to Autumn task planning
  • Review CDSP use-case action item: After Berlin AMM CDSP workshop
• AoB

Minutes:

• Short term
  • Christian reports that some of the feedback Steve reported about the Knowledge Server has been fixed but not yet pushed.
    • He has some questions about a couple of the points. As the list was posted in a github issue it was decided we can discuss there.
  • Once Steve has caught up with post AMM work he will look at the user documentation and CAN feeders
• Longer term
  • Rami posted some input on the planning page.
  • Christian introduced his logical apsect categories in the workshop page. General agreement its a great start and comprehension.
    • He explains whilst the use-cases are important and should be realistic, the central goal is to use them to identify needs and solutions.
  • Steve suggests some brief explanation of some of the categories may be needed to make them clearer as we go.
  • Discussion about various PoC work that is ongoing. Data Arch team can continue, but in parallel there are opportunities at higher level with other groups.
  • Ulf suggests that it would be good to use some use-cases to drive discussion of the categories.
  • Ted says the commercial vehicle artifacts could be an input to some use cases.
  • Work for next time:
    1. Read categories in the workshop table to check for agreement and any gaps. Christian suggested adding AOSP row.
    2.  Consider use-cases. As a start they do not need to be perfect. Point is to use them to check the work.

28th May 2025

Agenda:

• Continue planning discussion with a view to working towards concrete task backlog/roadmap
  • Short term: Remaining work on KL/IL, in progress work on feeders etc.
  • Longer term: Example build-out, AI, Doc etc. Also topics from the workshop
  • Planning page: 2025 Spring to Autumn task planning
• AoB

Minutes:

• Christian has drafted some possible topics for the first workshop After Berlin AMM CDSP workshop
• Discussion of encouraging collaboration and CDSP adoption. Extending the online doc with focused areas from the viewpoint of different tasks, e.g. interfacing feeders, or roles, e.g. knowledge engineer should help
• Short term
  • Christian has cleaned up the KL/IL tickets on the Kanban board
  • Discussion of some of the low hanging fruit and work already started (MCP server, CAN feeders, sync)
• Longer term
  • Rami: MongoDB can share some recent work with customers
  • Discussion of examples/patterns/use-cases
    • AI: agreement that each of us will consider the logical things to be considered to construct succesful use-cases. For example, what adapters might be needed between layers. In this way the goal is both the demonstrator and the problems to be tackled or illustrated to get there.

21st May 2025

Agenda:

• Spring AMM: feedback and any conversations that people had that feeds into the work
• Planning discussion with a view to working towards concrete task backlog/roadmap
  • Short term: Remaining work on KL/IL, in progress work on feeders etc.
  • Longer term: Example build-out, AI, Doc etc. Also topics from the workshop

Input:

• Goal: In the next 1-2 weeks determine work backlog for the next 6 month cycle. Ideally leading to a task list.
• Short term:
  • KL/IL
    • Update KL/IL existing tasks in Kanban.
    • Identify and record (in Kanban?) new short term tasks
      • Complete/cleanup tasks, e.g. doc gaps and building KL/IL using reference docker compose
      • Short term improvements, e.g. remaining review comments. The directory naming etc.
  • Sync discussion with IoTDB community
• Longer term (need decisions about what is short and long, i.e. priorities - none exchaustive list for discussion)
  • Growing examples
    • What are the major gaps to adoption?
  • Ease of development improvements to Doc so people can understand, use and integrate to the Playground
  • AI adapters
  • Data modelling
  • Sync
  • Streaming
  • VISS adapters

Minutes:

• AMM
  • Rami:
    • Discussion with Ulf about V2Cloud transfer PoC at the AMM
  • Christian:
    • Lots of AI discussions.
• Short term:
  • Christian will complete the clean up tasks for KL/IL
• Longer term:
  • Discussion of the challenges of topic selection. Such as different viewpoints and goals of wider participants. Can either dilligently advance topics on slack and working between the calls, or need workshops to really advance plans. There is recognisition that workshops help people block time.
  • Christian and Rami discussed ideas related to the cloud area. Christian wonders about timeseries there.
  • Christian agrees using the AMMs as a stretch of planning is a natural way to approach it. Final delivery of something at the AMM might not be primary goal.
  • Homework for next week is to consider nature of possible workshop topics: What is the goal etc.
  • Christian talks about Eclipse SDV Blueprints, which leads into discussion about the CDSP Examples which is the CDSP counterpart
    • Steve reminds about the prior discussions (see around 20th March 2024 in minutes) relating to improving the CDSP online doc site with getting started guides and a new Hugo theme (Hextra was a leading candidate). Including the simple mock-up he did.
    • Discussion about possible improvements.
    • Steve will distribute links on Slack.
  • Steve will add a confluence page to gather ideas and proposals as comments on slack will disappear after 90 days.

14th May 2025

No meeting due to Spring AMM in Berlin

7th May 2025

Agenda:

• Merging Knowledge and Information Layer features
• Spring AMM: session slides, showcase and workshop topics
• Status sharing including Playground Kanban

Minutes:

• Status
  • KL merge
    • After working through some issues, mainly resulting from some gaps in the KL example documentation, Steve was available to build and run the example.
    • Appear to be in acceptable shape. General feeling is that as long as it builds and runs, without impacting the existing parts if people do not want to use it, its better to merge such a large changeset and improve. Merge decision meeting scheduled for tomorrow.
• Spring AMM prep discussions

30th April 2025

Agenda:

• Status sharing including Playground Kanban
• Merging Knowledge and Information Layer features
• Spring AMM planning including workshop topics

Minutes:

• Status
  • KL merge
    • AI: After discussion the decision was taken to postpone the KL directory name cleanup till after the merge.
    • Christian has rebased on main.
    • Steve hit variety of issues sanity testing the KL/IL layer. Debugging ongoing with BMW.
  • Spring AMM planning discussion

23rd April 2025

Agenda:

• Status sharing including Playground Kanban
• Merging Knowledge and Information Layer features
• Spring AMM planning including workshop topics

Minutes:

• Status
  • KL merge
    • Awaiting input from Haonan on structure of KL source. See PR for details.
    • Steve will try and sanity test the branch
    • Christian will rebase to allow merge (docker compose and readme)
    • Based on those three things a decision on merging will be made. Hopefully early next week
    • Christian is out Thursday and Friday.
  • AI connections
    • Steve mentions that the IoTDB MCP server now supports the IoTDB tree/columnar data model. Previously it only supported the relational data model being introduced in IoTDB v2.0.x.
    • Christian mentions that Google very recently announced A2A a protocol for directly connecting Agents to each other
• Spring AMM
  • Discussion of Playground demo in the showcase. Christian thinks it would be good idea to hire a large TV. Who pays?
  • Christian informs that Haonan hopes to have an additional Semantic Reasoning example ready for the AMM.
  • Steve outlines slides that he used for recent internal Playground presentation and which he may reuse for the AMM Intro session.

16th April 2025

Meeting cancelled

9th April 2025

Agenda:

• Status sharing including Playground Kanban
• Working towards merge of Knowledge and Information Layer features
• Spring AMM planning including workshop topics
• Data store MCP and subscription support
• AoB

Minutes:

• Steve is currently tied up creating an internal presentation on the Playground
• KL/IL
  • Christian reports a succesful final integration test and thinks we can now remove the WIP from the PR and work towards merging.
  • Agreement we can concentrate on merge work from week 17.

2nd April 2025

Agenda:

• WIP status sharing including Playground Kanban
• On the Spring AMM I would like to start planning for the workshop. I went to add a wiki page to collect ideas but the wiki is currently down..
• AoB

Minutes:

• KL/IL update from Christian:
  
  • A final integration test scheduled Friday and will report the results.
  • The naming of the source of the KL and IL building blocks is now aligned with C4 component diagram
  • Then can remove WIP and work towards merge
  • Currently the inference result in IL is written into a private VSS node
• Steve is preparing an internal presentation introducing the Playground
• Spring AMM
  • A planning page for the sessions and showcase demo has been created here 2025 Spring AMM Planning (Data Architecture and Infrastructure) including some initial ideas for workshop topics. Please add your own.

26th March 2025

Agenda:

• Status sharing including Playground Kanban
  • CAN feeder
  • Data Store synchronisation example
  • Knowledge layer
  • Add Hold column to Kanban?
• Spring AMM sessions including showcase demo and workshop topic list
• AoB

Minutes:

• Status
  • Steve: might as well add CAN feeder as a WIP PR
  • Steve has added the data store sync docker example as a WIP PR https://github.com/COVESA/cdsp/pull/76
  • BMW making progress on KL/IL
  • Kanban board
    • Steve: any objections to adding a hold column?
    • None received
  • Discussion of Spring AMM sessions

19th March 2025

Agenda:

• Status sharing including Playground Kanban
  • CAN feeder update
• Data Store synchronisation example
• COVESA Blogs
• Spring AMM sessions
• AoB

Minutes:

• Status sharing
  • Christian will review PR https://github.com/COVESA/cdsp/pull/73 which adds guidelines for creating CDSP examples
  • CAN feeders
    • Steve has successfully tested using a virtual SocketCAN bus to play a can dump file into his Kuksa CAN Provider fork that integrates the Provider into CDSP.
    • He added a related note to the documentation.
    • Extending support in the VISSR feeder template will be next feeder target.
  • Data Store synchronisation (task #75)
    
    • Steve has created a simple Docker compose that creates two instances of the CDSP Apache IoTDB data store to support investigations into the IoTDB support for synchronisation between databases. Along with some notes on its use.
      • Work is currently publically available in his CDSP fork in his github in branch experimental-iotdb-sync, but he will create a WIP PR in CDSP isefl.
    • Discussion of initial findings. Agreement that more substantial discussion with IoTDB community about sync will be best deferred to after AMM. Steve will contact them and briefly update to maintain the connection.
• Spring AMM sessions
  • We need to start working on the session content and creating a workshop topic list

12th March 2025

Agenda:

• Status sharing including Playground Kanban
• COVESA Blogs
• CAN feeder progress
• Continue Spring AMM planning for Data Architecture. We need to confirm the timing so Paul can close out the schedule and can start thinking towards session and showcase demo.
• AoB

Minutes:

• Status
• AMM
  • Workshop
    • People should consider what they want to discuss ahead of time.
    • Reasoning on high frequency data

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
  • Christian summarised IL/KL:
    • Updated IL API payload schema
    • Testing showed up that SteeringAngle was not being received from RL Broker. AI: Need to investigate.
  • CAN feeders
    • Steve has a hacked version of the kuksa CAN provider working with the Playground. Christian would like to know when its public - should be end of this week
    • Steve will do VISSR v3 template as next step
  • Brief discussion of connecting IL to VISSR. Ulf would like to see VISSR connected to the KR world. Christian thinks it could be a topic for the AMM workshop - general agreement
  • Christian's presented his Docker proposal for examples. Attendees approve the general approach.
• AMM
  • Steve: we need to finalise timings by end of next week to allow Paul to create the schedule. I've drafted three sessions in the wiki proposal page. Please review.
  • Steve asks Christian to update/replace the Semantic Reasoning session description as needed.
  • Christian agrees would be good to have sessions before the showcase.
  • Currently Paul has these 2-3:40 Weds afternoon.
  • Workshop topics:
    • Connecting IL to VISS eco-system. Including connecting KL to VISS.

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 successfully 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:

...

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

...