As discussed in data architecture call May 21, this page shall serve as a collection of topics that we could discuss in an dedicated workshop session regarding next steps in CDSP after Berlin AMM 25. 

Topic Collection:

Nr	Title	Description	Expected Outcome in Workshop

Nr	Title	Description	Expected Outcome in Workshop
1	Blueprint examples	How to make blue print example a bit more formal / user friendly https://github.com/COVESA/cdsp/tree/main/examples
2	Showcase Spring AMM 26 (see as well table below)	As discussed at Berlin AMM one option would be to have a setup with real hardware including Cloud, ECU and Customer devices. Do we find Use Case that: involves all three hardware touchpoints touches all aspects of playground components encourages even new contributors (Open Souce Reasoners, data bases, sync technologies etc) to contribute and be part of final end-to-end showcase
3	Clean docu with Hextra template
4	Proposed to CDSP for use cases involving data from multiple vehicles	Open
5	Open source Reasoner	Currently the Knowledge Layer Server supports a single Reasoner RDFox. RDFox is a proprietary product that provides a short term evaluation license. It would be good to support an additional reasoner that does not have the license restrictions and to test the implementation with more than one Reasoner.
6	MCP Server prompts	Consider the usefulness of defining prompts for MCP Server connected to Playground data stores	Roadmap/scope for MCP prompts if deemed useful
7	AI related connections between DIKW layers	@Christian Mühlbauer has proposed considering standardised orchestration of intelligent components connecting through the Information Layer. Can MCP, A2A and UTCP protocols help?

Topic Detailing:

Regarding workshop item 2 "Showcase Spring AMM 26":

The data architecture working group, as part of the preparations for the Showcase Spring AMM 26, agreed to systematically identify a suitable use case by first compiling a comprehensive list of aspects that a data-centric architecture use case should encompass. This collaborative effort will enable the group to prioritize the most valuable use case, especially in terms of how it can help the CDSP (Connected Data Services Platform) evolve and become a more valuable platform for all stakeholders who wish to experiment with or build upon the proposed architecture. This a first proposal, it is still work in progress.

Logical and Implementation Concepts

COVESA members will make different technology decisions when implementing their own systems. So generally the data architecture group describes logical and implementation concepts for its work. This allows the logical architecture work to be useful on its own and flexible technology choice in implementation. For example the logical implementation might call for a MQTT broker and whilst a specific broker might be chosen for the implementation it can be seen that a different choice could be made. This separation is illustrated in the simplified diagram below.

Open

Use Case aspects list:

Use Case proposals:

Use Case 1: Insurance (data semantics, possibly AI LLM and Semantic Reasoning)

Some possible aspects to be refined and mapped to the categories above:

• Data reduction before off-boarding (not specific to insurance).

  • What: reduce size of data set or move result to higher DIKW level, e.g. info->knowledge

  • How: conventional data processing, e.g. sampling, or AI.

  • Biz view:

    • Transmission cost reduction

    • Reduction of processing and storage costs in cloud

    • Privacy or IP concerns (secrets stay on-board)

• Use rules-based Semantic Reasoning to define business logic

  • What:

    • Use existing Knowledge Server functionality to implement insurance knowledge rules

      • Show ability to update without changing underlying layers

    • Technical growth potential:

      • Implement subscription between Information Layer and DBs using DB functionality - currently IL polls.

      • Optional: explore OSS reasoner

      • Optional: explore patterns of how knowledge graph can be integrated with other data, e.g. timeseries, rather than use binary solutions, e.g. must use knowledge OR timeseries database.

  • Biz view:

    • Allow insurance companies to concentrate on 'value' via the rules independently of southbound systems

Use Case 2: Fuel management for fleet efficiency

Use Case 3: Predictive Maintenance

Use Case 4: Driver identity

ML could be used to identify driver by image and or voice. This could illustrate a separation of concerns between indentification (data layer) and identity (information/knowledge layer)

Use Case 5:

@Stephen Lawrence It would be useful to ensure we have use-cases that utilize different categories of data. For example, an OEM app may mostly use VSS state/actuator data, e.g. HVAC or seating, that is low frequency and need low latency. Whilst a fleet or telematics use case such as maintenance or position may mostly use VSS timeseries data that is high frequency.