JOIN/SIGN UP
Already a Member? |
GET INVOLVED
Understanding and Engaging in COVESA Expert Groups & Projects |
COLLABORATIVE PROJECTS
HISTORICAL
SDV Telemetry Project |
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:
| 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:
| |
| 3 | Clean docu with Hextra template | ||
| 4 | Proposed to CDSP for use cases involving data from multiple vehicles | ||
| 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. |
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.
Use Case aspects list:
| Criteria | Weight (1 nice to have - 5 essential) | Use Case 1 | Use Case 2 | Use Case 3 | Use Case 4 | Use 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 (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.
- Use existing Knowledge Server functionality to implement insurance knowledge rules
- Biz view:
- Allow insurance companies to concentrate on 'value' via the rules independently of southbound systems
- What:
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.
Overview
Content Tools