SDVDiag: Diagnosis for Software-Defined Vehicles
- SDVDiag is a diagnosis platform that automates the path from telemetry collection to root-cause ranking in distributed vehicle–edge–cloud systems.
- It integrates multimodal inputs—such as metrics, logs, and human feedback—to construct refined causal graphs that isolate failures hidden across multiple dependencies.
- The platform demonstrates improved precision and continuous online diagnosis capabilities, making it a valuable research tool for complex connected vehicle functions.
SDVDiag is a diagnosis platform for connected and software-defined vehicle functions that automates the path from telemetry collection to root-cause ranking in distributed vehicle–edge–cloud systems. Across its published iterations, it is presented as a modular, graph-based, and later multimodal diagnosis framework that combines distributed tracing, metrics, anomaly detection, causal discovery, human feedback, and domain-specific context to localize failures whose visible symptoms may be several causal hops away from the underlying defect (Weiß et al., 25 Jul 2025, Weiß et al., 3 Apr 2026, Weiß et al., 14 Jun 2026).
1. Origins and problem formulation
SDVDiag was introduced to address a diagnosis problem created by connected and software-defined vehicles: when a function fails or degrades, the responsible root cause may be embedded in a chain of dependencies spanning vehicle software, edge services, cloud services, and networking infrastructure (Weiß et al., 25 Jul 2025, Weiß et al., 3 Apr 2026). The motivating assumption throughout the line of work is that manual analysis becomes too slow when engineers must inspect metrics, logs, and traces from many components, especially under high reliability and availability requirements (Weiß et al., 25 Jul 2025).
The platform’s target domain is not generic automotive fault diagnosis in the classical ECU-centric sense. Rather, it focuses on connected vehicle functions deployed across distributed infrastructures, including cloud-only computation, edge-only computation, and hybrid cloud-edge computing, with dynamic dependencies, frequent updates, and fragmented observability (Weiß et al., 25 Jul 2025). Later work makes this focus more explicit by situating SDVDiag in software-defined vehicles, where failures propagate through service dependencies and the surface symptom is often several causal hops away from the underlying defect (Weiß et al., 14 Jun 2026).
A recurring theme is that single-modality and purely data-driven approaches are insufficient in this setting. The 2026 context-aware extension states that automated analysis techniques are predominantly data-driven and struggle with hidden relationships and the integration of context information, while the multimodal extension argues that metrics-only or logs-only reasoning yields incomplete causal graphs and that offline, operator-driven workflows do not match continuous vehicle operation (Weiß et al., 3 Apr 2026, Weiß et al., 14 Jun 2026). This suggests that SDVDiag evolved from an initially modular diagnosis platform into a broader framework for continuous causal diagnosis under observability heterogeneity and concept drift.
2. Baseline platform architecture
The 2025 formulation presents SDVDiag as a modular, service-based diagnosis platform organized as a pipeline of interchangeable modules (Weiß et al., 25 Jul 2025). The architecture is divided conceptually into four main subsystems: data aggregation and storage, graph creation, learning environment, and incident analysis. This decomposition establishes the platform’s core design principle: diagnosis is treated as an end-to-end operational pipeline rather than a single inference model (Weiß et al., 25 Jul 2025).
In the data aggregation and storage layer, SDVDiag collects telemetry from vehicles, edge nodes, and cloud services. At minimum it requires traces and metrics, while also supporting logs and application-specific data. The implementation described in the 2025 paper uses OpenTelemetry for telemetry collection, Apache Kafka for streaming and transport, and Delta Lake for storage and preprocessing (Weiß et al., 25 Jul 2025). The later multimodal extension retains the Kafka-based streaming idea and emphasizes that a data bridge publishes metrics, logs, pod metadata, and traces on separate topics, enabling deterministic time alignment between metric and log windows (Weiß et al., 14 Jun 2026).
Graph creation is the central representational layer. The platform uses a graph-based system view in which nodes represent system components or monitored metrics and edges represent relationships or dependencies (Weiß et al., 25 Jul 2025). Two graph types are distinguished: a dependency graph and a causal graph. These are combined into an extended causal graph that serves as the substrate for incident analysis and root-cause reasoning (Weiß et al., 25 Jul 2025).
The learning environment supports continuous maintenance of diagnosis models. In the 2025 version, two continuously updated models are emphasized: a Causal Model Encoder based on Amortized Causal Discovery (ACD), and an Anomaly Detection Model Selector that chooses and deploys detectors from a pool using features extracted from each time series (Weiß et al., 25 Jul 2025). The platform also supports self-adaptive runtime module exchange, so causal discovery models, anomaly detectors, graph pruning modules, sampling methods, and traversal methods can be swapped without redesigning the full system (Weiß et al., 25 Jul 2025). A plausible implication is that SDVDiag was designed not only as a diagnosis tool but also as an experimental systems framework for evolving diagnosis strategies.
3. Graph construction, causality, and anomaly-driven analysis
The dependency graph is inferred from runtime information, especially distributed traces, and is continuously updated with recent trace data (Weiß et al., 25 Jul 2025). Its purpose is to capture which services communicate or depend on each other. The platform stores these interactions in a graph database and can attach additional context such as timestamps of recent communication, performance metrics, and domain knowledge from engineers (Weiß et al., 25 Jul 2025).
The causal graph aims to capture causal strength between monitored variables, especially metrics. In the 2025 platform, ACD is used to infer weighted causal edges from time-series data, producing metric nodes and weighted causal edges whose weights represent causal strength (Weiß et al., 25 Jul 2025). These causal edges are then pruned when the corresponding services are not related in the dependency graph, so the extended causal graph retains only causal relations consistent with service relationships (Weiß et al., 25 Jul 2025).
Incident analysis is organized around snapshotting and graph traversal. When an incident is detected or manually triggered, SDVDiag creates a snapshot containing the latest extended causal graph, anomalies detected within a configurable time window, and optional modifications via modules (Weiß et al., 25 Jul 2025). The platform then performs root-cause analysis using first-order random walks, second-order random walks, or Fault Tree Analysis; the 2025 evaluation uses first-order random walk as the default for smaller systems (Weiß et al., 25 Jul 2025). The traversal starts at anomaly metric nodes, moves along causal edges with transition probability proportional to edge weight, counts node visits, and ranks nodes by visit frequency. In the notation given, if denotes the neighbors of , the transition rule is
and rankings are derived from aggregated visit counts (Weiß et al., 25 Jul 2025).
The 2026 multimodal paper changes the operational mode of this process. Instead of requiring an engineer to manually choose a suspicious service before root-cause analysis begins, SDVDiag adds an anomaly-driven trigger: the anomaly detector continuously monitors metric streams, emits per-service anomaly scores, and uses the service with the highest sustained anomaly score as the trigger target (Weiß et al., 14 Jun 2026). False-trigger suppression combines a -continuous alarm filter requiring the score to exceed threshold for at least 5 seconds and a UI confirmation prompt that can be disabled for full automation (Weiß et al., 14 Jun 2026). This converts SDVDiag from a manually operated batch tool into a continuously running online system.
4. Human feedback, trace validation, and context injection
A major 2026 extension reframes SDVDiag as a platform for context-aware causality mining rather than only graph-based diagnosis (Weiß et al., 3 Apr 2026). In this version, the telemetry inputs are performance metrics from Prometheus, distributed traces from Zipkin, and expert or domain context through rules and feedback. Metric data are fed into a Graph Neural Network encoder trained with contrastive learning using triplets consisting of an anchor node, a positive node, and a negative node. The encoder supports GCN and GAT variants and is trained initially using conventional causal discovery algorithms such as PC or GES to generate pseudo-ground-truth graphs (Weiß et al., 3 Apr 2026).
The base causal reconstruction policy estimates an edge probability between nodes and as
where is the frozen GNN encoder and is the sigmoid (Weiß et al., 3 Apr 2026). An edge is included if the similarity exceeds a threshold . The paper characterizes this base policy as intentionally high-recall, but prone to many false positives (Weiß et al., 3 Apr 2026).
To reduce human labeling effort, SDVDiag introduces Hierarchical Reinforcement Learning from Human Feedback. Instead of exhaustive edge annotation, experts answer pairwise comparison queries: for a target node 0, the system presents two candidate predecessors 1 and 2, and the expert chooses which is more likely to be a causal predecessor (Weiß et al., 3 Apr 2026). The low-level policy 3 is trained with Deep Deterministic Policy Gradient because the action is a continuous edge probability in 4. Feedback data are stored as triplets 5, and a reward model 6 provides the edge-level reward
7
The high-level policy 8, trained with Q-learning and 9-greedy exploration, prioritizes which target nodes deserve attention through the neighborhood-aggregated reward
0
All expert feedback is retained in a persistent database to support incremental learning across restarts and updates (Weiß et al., 3 Apr 2026).
After human feedback, SDVDiag applies trace-based refinement using Zipkin distributed tracing. The pruning pipeline has three filters: confidence filtering, trace validation, and duplicate aggregation (Weiß et al., 3 Apr 2026). A key technical issue is the mismatch between pod-metric granularity in the causal graph and service-level dependencies in traces. The system therefore extracts service names from metric labels, strips metric suffixes and Kubernetes deployment identifiers, validates metric-level edges against service-level communication, and corrects edge direction if the reverse direction is seen in the trace graph (Weiß et al., 3 Apr 2026).
A final refinement stage allows injection of known causal relationships that are not visible in telemetry. This is done through a rule-based interface that can add hidden nodes and edges under specified conditions. The example given is a rule that injects a hidden causal node parking_queue and an edge from parking_queue to valetparking_cpu_by_pod when valetparking_cpu_by_pod exceeds 80.0 (Weiß et al., 3 Apr 2026). The platform checks whether an injected edge would create a cycle and rejects it if so, because the causal graph must remain a DAG (Weiß et al., 3 Apr 2026). This stage addresses hidden causal factors such as queue overflow that may not appear as ordinary monitored services.
5. Multimodal extension: logs and metrics in a shared causal representation
The 2026 multimodal extension adds a second major axis to SDVDiag by combining logs and metrics before graph construction (Weiß et al., 14 Jun 2026). The paper argues for pre-fusion rather than post-fusion: instead of building separate graphs per modality and combining them later, SDVDiag aligns modalities first and then learns a single graph, preserving cross-modal correlations early (Weiß et al., 14 Jun 2026).
The log pipeline begins by sanitizing raw logs: timestamps, UUIDs, IP addresses, and other variable tokens are replaced by placeholders (Weiß et al., 14 Jun 2026). The sanitized lines are parsed by Drain3, which clusters logs into structured templates. Templates are grouped by service and fixed-width time window, typically 300 s, and repeated consecutive occurrences of the same template are collapsed into quadruplets
1
Each template is embedded with all-MiniLM-L6-v2 into a 384-dimensional vector. Event vectors are then formed from template embedding, service embedding, repetition count, and normalized timestamp, and the resulting sequence is encoded by LogBERT with bidirectional self-attention, 8 attention heads, feedforward dimension 1024, GELU activation, residual connections, and layer normalization (Weiß et al., 14 Jun 2026). Weighted attention pooling produces a single service-level log embedding per window. LogBERT is pretrained by Masked Event Modeling on normal logs using three heads: template reconstruction, service identification, and count estimation, combined by a weighted loss (Weiß et al., 14 Jun 2026).
The metric path reuses the earlier SDVDiag metric encoder, in which metrics are encoded by a Graph Neural Network and yield node embeddings for each service-metric pair, such as valetparking_cpu_usage and valetparking_ram_usage (Weiß et al., 14 Jun 2026). Because the two modalities have different shapes, the service log embedding is duplicated to each metric node of that service before fusion (Weiß et al., 14 Jun 2026).
Fusion is implemented by an autoencoder that concatenates metric and log embeddings, linearly projects them into a common dimension, applies multi-head self-attention to model intra-modal and inter-modal interactions, compresses them into a bottleneck vector 2, and reconstructs both modalities with a symmetric decoder (Weiß et al., 14 Jun 2026). The printed fusion objective is malformed in the provided text, but the intended form is stated as a reconstruction loss over metric and log inputs weighted by 3 and 4 (Weiß et al., 14 Jun 2026). Once fused embeddings are obtained, the causal graph is built by computing cosine similarity between node embeddings, using similarity scores as edge confidences, and thresholding them to generate a base causal graph. The graph is then refined by the existing SDVDiag stages: RLHF-based refinement, trace-based pruning, domain knowledge enrichment, and random-walk root-cause ranking (Weiß et al., 14 Jun 2026).
The multimodal extension is presented as compatible with continuous online operation. The analysis path continuously builds and updates the causal graph from aligned windows while the detection path continuously computes anomaly scores from metric windows. When an incident is confirmed, root-cause ranking runs on the current enriched graph rather than on a stale historical snapshot (Weiß et al., 14 Jun 2026).
6. Evaluation results, interpretability, and limitations
The 2025 platform paper evaluates SDVDiag in a 5G vehicle test track at the University of Stuttgart using a smart charging application with multiple Unmanned Ground Vehicles, LiDAR, depth cameras, designated parking spots with charging stations, and a local Kubernetes-based compute cluster with 1 control node and 3 worker nodes (Weiß et al., 25 Jul 2025). For root-cause evaluation, the authors inject a fault in which one charging station service experiences increased CPU usage. This produces propagation effects on colocated charging station services, remote charging station services, and vehicle services. The reported outcome is that injected faults were detected reliably, false positives decreased over time as the anomaly model selector learned, and the correct root cause was isolated despite a dense anomalous subgraph (Weiß et al., 25 Jul 2025).
The context-aware causality mining paper evaluates SDVDiag on an Automated Valet Parking application operated in a connected vehicle test field, with a Kubernetes cluster consisting of 1 control node, 5 worker nodes, and 1 node dedicated to the analysis platform (Weiß et al., 3 Apr 2026). The scenario simulates parking request overload causing a queue overflow and synchronization issues between parking lot management and parking spot manager services; externally, this appears as a UGV stopping at the drop-off point even though parking spots are free (Weiß et al., 3 Apr 2026). Using an expert-estimated service dependency graph as ground truth, the paper compares a raw base-policy graph, a feedback-adjusted graph, and a pruned final graph. The reported results are:
- Raw base-policy graph: 137 edges, 14% precision, 100% recall, 24% F1.
- Feedback-adjusted graph: 49 edges, 32% precision, 84% recall, 47% F1.
- Pruned final graph: 16 edges, 100% precision, 84% recall, 91% F1 (Weiß et al., 3 Apr 2026).
The headline improvement is precision from 14% to 100% for causal-edge detection, with graph size reduced from 137 to 16 edges. The final graph is described as more interpretable because it has fewer spurious edges, clearer service hubs and dependency structure, better alignment with actual service communication, and the ability to represent hidden mechanisms such as queue overflow explicitly (Weiß et al., 3 Apr 2026). Root-cause analysis via random walk correctly identifies queue overflow as the actual cause of the observed behavior (Weiß et al., 3 Apr 2026).
The multimodal online paper evaluates the fused system on an Autonomous Valet Parking testbed with seven microservices, OpenTelemetry instrumentation, and storage or aggregation via Prometheus, Loki, and Zipkin, with Kafka aligning all streams into 300 s windows (Weiß et al., 14 Jun 2026). Ten disjoint log batches are processed; the average raw log count is 42,611, the average run-length-encoded length is 16,495, and the mean reduction is 61.3%, with standard deviation below 0.8 percentage points (Weiß et al., 14 Jun 2026). For base-graph sparsity, the metrics-only baseline has approximately 182 edges on average, whereas multimodal SDVDiag has approximately 134 (Weiß et al., 14 Jun 2026).
Graph quality is measured by an edge-weighted reward against an expert knowledge graph. At 60 feedback queries, the metrics-only method reaches reward 0.271 with 92 edges, while the multimodal method reaches reward 0.651 with 56 edges, corresponding to about a 2.4-fold improvement over the baseline (Weiß et al., 14 Jun 2026). The multimodal method also outperforms the baseline at every feedback checkpoint, including zero feedback (Weiß et al., 14 Jun 2026). In an end-to-end fault injection, an oversized map payload in the map service causes control service deserialization overhead, CPU and RAM spikes, delayed callbacks, request accumulation in valetparking, and elevated valetparking RAM usage. The anomaly detector identifies the valetparking RAM anomaly, and random-walk traversal on the enriched graph recovers the upstream chain valetparking 5 control 6 map, correctly identifying map service RAM usage as the top non-target root cause (Weiß et al., 14 Jun 2026).
The limitations reported across the papers are consistent. The 2025 paper notes that SDVDiag currently performs well for failures observable in metrics, but many real-world failures require expert domain knowledge, and that causal discovery quality can degrade quickly with system changes (Weiß et al., 25 Jul 2025). The 2026 context-aware paper states that the evaluation system is small, with only seven services, that causal ground truth is expert-estimated, and that realistic failure simulation is difficult (Weiß et al., 3 Apr 2026). The multimodal paper likewise evaluates on a relatively small seven-service backend and reports only one end-to-end fault scenario (Weiß et al., 14 Jun 2026). These constraints indicate that SDVDiag is best understood as a research platform for online diagnosis of distributed vehicle functions whose central contributions lie in modularity, causal graph refinement, multimodal fusion, and the integration of human and domain knowledge into diagnosis workflows.