Page History

...

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

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:

...