Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: 17th July minutes

...

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

...

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:


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:
  • Fall AMM
  • 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
  • AoB: related projects etc.

8th May 2024

Agenda:

  • Playground Kanban
    • In-progress task status
    • 0.1.0 release
    • Completing project setup
  • Backlog generation
  • 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
  • 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:

Image Added

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


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:

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


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:


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:

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

12th October 2023 - AMM Data Architecture Workshop

  • (these are incomplete notes made after the event) 
  • Workshop delivered as planned, except for compression of timne 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:
        • End Group shot after the end of the session group shot:
    • 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.

...