We use cookies on this site to enhance your user experience. By using this site, you are giving your consent for us to set cookies.


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:

NrTitleDescriptionExpected Outcome in Workshop
1Blueprint examples How to make blue print example a bit more formal / user friendly https://github.com/COVESA/cdsp/tree/main/examples
2Showcase 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

3Clean docu with Hextra template

4


5



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.

Use Case aspects list:

Criteria

Weight

(1 nice to have - 5 essential)

Use Case 1Use Case 2Use Case 3Use Case 4Use Case 5
Deployment Aspects





Includes In-Vehicle ECUs/Components





Includes Customer Devices (e.g., Smartphones, Tablets)





Includes Cloud/Backend Infrastructure





Includes connections between domains (e.g. V2C, Device2V, Device2C)





(Input) Data Layer Aspects





Includes Vehicle Sensor/Diagnostic Data





Includes User/Driver Data (e.g., Preferences, Behavior)





Includes External Data Sources (e.g., Traffic, Weather)





Information Layer Aspects





Includes Standardized Vehicle Signal Definitions (e.g., VSS)





Includes abstracted User/Driver Profile Data





Includes Bidirectional Data Synchronization





Includes Unified Data Access Mechanisms (VISS, Information Layer API etc.)





Handles Vehicle/User State Synchronization





Includes Time Series Data Management





Includes Schema DDL generation (e.g. DB schema)





Knowledge Layer Aspects





Includes Semantic Rule based Reasoning Capabilities





Supports Real-time Conversion between Information and

Knowledge Layer data representation







Integrates Machine Learning Models





Combines Deterministic and Probabilistic Approaches (Symbolic AI)





Includes Agentic AI Capabilities (e.g., A2A, MCP)





Wisdom Layer Aspects





Includes User-facing Applications/Interfaces





Provides Action Recommendations/Decision Support





Other Important Aspects





Involves Hardware Vendors/Suppliers





Involves different Database/Storage Vendors





Involves different AI/Reasoning Engine Providers





Ensures Secure and Privacy-preserving Data Handling





Demonstrates Scalability and Performance





Includes Comprehensive Error Handling and Diagnostics





Provides Extensibility and Adaptability to Future Requirements





Aligns with Industry Standards and Regulations





Includes Support for Multi-Cloud and Edge Computing Deployments





Demonstrates Interoperability between Heterogeneous Components





Provides Comprehensive Monitoring and Diagnostics Capabilities





Supports Efficient Data Ingestion and Processing Pipelines





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

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.



  • No labels