Page History

...

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

30th April 2025

Agenda:

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

Minutes:

• Status

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:

...

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

...