Testplattform

SDVA-Testplattform: Laufzeitkonfiguration, Low-Latency-Switching, Remote-Nutzung.

Die OSxCAR SDV Test Bench ist eine skalierbare, laufzeitkonfigurierbare Testplattform für Software-Defined Vehicles: Schnellere Validierung, flexible Architekturen, ein Testbench für vielfältige Einsatzszenarien. Modulare Hardware (t.RECS), Physical-Layer-Switching, Remote-Zugriff und KI-gestützte Optimierung.

Laufzeit-Rekonfiguration

Software-defined Topologien – Szenarien flexibel wechseln, keine Hardware-Umbauten.

Modulare Hardware

t.RECS mit Standard-Formfaktoren (SMARC, COM-HPC) – x86, ARM, RISC-V, GPU/FPGA-ready.

Flexible Architekturen

Legacy-Domänen, Zonen-Controller, Zentral-Computer – alle E/E-Topologien in einer Testbench.

HIL/SIL + Shadow Mode

Hardware- und Software-in-the-Loop, A/B-Testing parallel zur Produktion.

Entwicklungsziele
  • Effizientere Validierung: Testzyklen durch Software-Rekonfiguration statt Hardware-Umbau deutlich reduzieren
  • Kostenpotenzial: Eine Testbench für verschiedene Fahrzeugarchitekturen statt separater Hardware-Duplikate
  • Skalierbarkeit: Plattform wächst mit SDV-Anforderungen (L2+ bis L3+ Autonomie)
  • KI-Integration: Realistische Latenz-Daten für GNN-Training sammeln

Software-Defined Vehicles benötigen flexible Testumgebungen für unterschiedliche Fahrzeugarchitekturen (von Legacy-Domänen bis Zentral-Computer, L2+ bis L3 Autonomie). Traditionelle Setups sind fix verdrahtet – Hardware-Umbauten sind zeitaufwändig. Die OSxCAR Testbench löst dies durch Physical-Layer-Switching: Topologien dynamisch umkonfigurieren, keine Kabel-Steckerei.

Problem: Legacy-Testbench
  • Hardware-Duplikate: Jeder Partner eigene Infrastruktur → Kosten, CO₂
  • Langsam: Umbau dauert lange, verzögert Validierung
  • Daten-Silos: Keine zentrale Sammlung für KI-Training
Lösung: OSxCAR Testbench
  • Software-defined: Schnelle Umkonfiguration, keine Hardware-Änderung
  • Agil: Szenarien rasch wechseln statt langer Umbauzeiten
  • KI-ready: Zentrale Datensammlung für GNN-Training

OSxCAR-Integration: Remote-Zugriff erlaubt ortsunabhängiges Testen – Wasm-Module validieren, KI-Modelle trainieren, ohne Zielhardware vor Ort. Zentrale Bench reduziert Hardware-Duplikate und CO₂-Fußabdruck.

  • Laufzeit-Rekonfiguration
  • Remote-Zugriff
  • TISAX-konform
  • KI-Integration

Die Testbench kombiniert Physical-Layer-Switching (Schaltmatrix) mit RECS-Microservern und heterogenen Compute-Nodes. Das Kernprinzip: Signale physikalisch umschalten statt virtuell routen – minimale Latenz, realistische Jitter-Charakteristik.

  • Schalt-Matrix: Physical-Layer-Switching – Signale direkt umschalten, skalierbar von 8×8 bis 64×64 Ports, bus-agnostisch (Ethernet, CAN, LIN)
  • RECS-Microserver: Thermal-optimierte t.RECS-Module – erweiterbar mit GPU/FPGA für KI-Workloads
  • Compute-Nodes: x86 (High-Performance), ARM (Power-efficient), RISC-V (Open-Source-ISA), FPGA/ASIC (Custom Accelerators)
  • Metriken: Hardware-Timestamps, µs-Jitter-Analyse, Prometheus/Grafana-Telemetrie, ELK-Logging

Unterstützt Standard-Formfaktoren wie SMARC, COM-HPC und COM-Express – ideal für OEM-Integration und Drittanbieter-Module. Skaliert von Low-Power (ARM Cortex-A) bis High-Performance (x86). Modularer Aufbau erlaubt GPU/FPGA/ASIC-Integration. TSN-Support für deterministische Latenz.

Architektur-Support: Die Testbench unterstützt dezentrale Steuergeräte (Legacy), regionale Zonen-Controller und hochintegrierte Zentral-Computer (L3+ Autonomie).

Die Schaltmatrix verbindet ECUs, Sensoren und Aktuatoren auf Physical-Layer – laufzeitkonfigurierbare Topologien ohne Hardware-Umbau. Latenz-/Jitter-sensible Pfade werden charakterisiert (entscheidend für ISO 26262).

  • SMARC
  • COM-HPC
  • COM-Express
  • TSN

Die Testbench unterstützt alle relevanten Automotive-Bus-Systeme: Von Low-Speed-LIN über robuste CAN-Netze bis zu deterministischem TSN. Jedes Bus-System kann über die Schaltmatrix flexibel verschaltet werden.

Ethernet / TSN

Standard: IEEE 802.1 TSN
Speed: 100M / 1G / 10G
QoS: Time-Aware Shaper
Use Case: Zonen-Backbone, ADAS

CAN / CAN-FD

Speed: 1 Mbit/s (CAN), 8 Mbit/s (FD)
Robustheit: Differentiell, fehlertolerant
Payload: 8 Byte (CAN), 64 Byte (FD)
Use Case: Powertrain, Chassis

LIN

Speed: Bis 20 kbit/s
Topologie: Single-Master
Kosten: Sehr günstig
Use Case: Komfort, Sensoren

Metriken

Latenz-Messung: Hardware-Timestamps
Jitter-Analyse: µs-Auflösung
Telemetrie: Prometheus, Grafana
Logging: ELK-Stack

TSN-Integration: Die Testbench nutzt TSN für deterministische Latenz-Garantien – kritisch für ADAS und Fahrdynamik-Regelung. Time-Aware Shaper (TAS) und Per-Stream Filtering (PSFP) werden in der Bench konfiguriert und validiert.

CAN-FD-Vorteile: Höhere Datenrate als Standard CAN und größere Payloads reduzieren Bus-Last.

Software-defined Topologien sind der Kern der SDVA-Testbench: Szenarien werden per Konfigurationsdatei definiert und zur Laufzeit auf die Schaltmatrix geladen. Keine Hardware-Umbauten, keine Kabel-Steckerei – nur Software-Update.

Use Cases für Rekonfiguration:

  • L2+ → L3 Migration: Zentral-Computer hinzufügen, Zonen-Controller umkonfigurieren
  • Gateway-Tests: CAN↔Ethernet-Gateway in verschiedenen Topologien testen
  • Failover-Szenarien: ECU-Ausfall simulieren, Redundanz-Pfade aktivieren
  • TSN-Konfigurationen: Verschiedene QoS-Profile (VLAN, Prioritäten) testen
Best Practice: Latenz-/Jitter-Charakterisierung vor Szenario-Einsatz durchführen. Neue Topologien sollten im Shadow-Mode validiert werden (parallele Messung ohne Production-Impact). Dokumentiere alle Messungen für ISO 26262 Audits.

Beispiel-Workflow: (1) Topologie definieren (Knoten, Links, Bus-Typen), (2) Schaltmatrix-Config generieren (automatisch), (3) Config auf Bench deployen (REST-API), (4) Umschaltung triggern, (5) Validierung (Latenz-Messung, Connectivity-Check).

Die Bench protokolliert alle Umschaltungen (Timestamp, Config-Hash, User) – wichtig für TISAX-Audits und Reproduzierbarkeit. Configs werden versioniert (Git) und signiert.

Die SDVA-Testbench ist cloud-basiert zugänglich: Partner reservieren Zeit-Slots, deployen Software remote und greifen auf Mess-Daten zu – ohne vor Ort zu sein. Multi-Tenant-Architektur garantiert Datenisolation gemäß TISAX.

🎯 Management

Zeit-Slots: Reservierungssystem (Kalender-basiert)
Multi-Tenant: Parallele Nutzung, isolierte Datenräume
Deployment: Software-Upload via REST-API
Monitoring: Live-Telemetrie (Grafana-Dashboards)

🔒 Security (geplant, derzeit aber optional)

TISAX-konform
Datenisolatiert
Verschlüsselt
Audit-Trail

TISAX-Anforderung: Keine Produktionsdaten auf Bench! Nur Bench-generierte Daten und pseudonymisierte Test-Daten erlaubt. Produktionsdaten bleiben in OEM-Umgebung (keine Weitergabe an Dritte).

Reservierungssystem: Partner buchen Zeit-Slots (z.B. 2 Stunden) über Web-Interface. Während des Slots haben sie exklusiven Zugriff auf konfigurierbare Ressourcen (Schaltmatrix, RECS-Nodes). Gemeinsame Ressourcen (z.B. zentrale Logging-Infrastruktur) bleiben mandantenfähig.

Software-Deployment: Wasm-Module werden via REST-API hochgeladen, signiert und auf RECS-Nodes deployed. Schneller Rollback möglich. Native Binaries (x86/ARM) ebenfalls unterstützt, aber Wasm bevorzugt (Portabilität, Sicherheit).

Mess-Pfade sind essenziell für Bench-Validierung und KI-Training: Latenz, Jitter, Throughput werden auf µs-Ebene erfasst. Hardware-Timestamps (FPGA-basiert) eliminieren Software-Overhead.

Telemetrie-Stack:

  • Prometheus: Metriken-Sammlung (CPU, Memory, Bus-Load, Latenz)
  • Grafana: Live-Dashboards (Zeitreihen, Heatmaps)
  • ELK-Stack: Log-Aggregation (Elasticsearch, Logstash, Kibana)
  • Jaeger: Distributed Tracing (für Wasm-Module)
Telemetrie-Stack: Prometheus scrape alle RECS-Nodes (15s Intervall), Grafana zeigt Live-Dashboards. Alerts bei Schwellwert-Überschreitungen (z.B. Latenz > 10 ms, CPU > 90%). Historische Daten werden 90 Tage gespeichert (für Trend-Analysen).

Integration mit KI: Die Bench sammelt realistische Daten für GNN-Training. Topologie-Graphen (Knoten=ECUs, Kanten=Bus-Links) + Latenz-Messungen werden exportiert (CSV, Parquet). GNN-Modelle lernen Latenz-Prognosen für verschiedene E/E-Architekturen und optimieren Software-Platzierung. Validierung im Shadow-Mode.

Erweiterte Testfunktionen:

  • HIL (Hardware-in-the-Loop): Reale ECUs mit simulierten Sensoren/Aktuatoren – echte Signale, kontrollierte Umgebung
  • SIL (Software-in-the-Loop): Rein software-basierte Validierung vor Hardware-Verfügbarkeit
  • A/B Shadow Mode Testing: Neue Softwareversion parallel zur Heuristik laufen lassen – Vorschläge loggen, nicht anwenden. Validierung ohne Production-Risk
  • Testframework: Integrierte Ergebnissammlung, Visualisierung (Grafana), Audit-Trail für ISO 26262

Wasm-Integration: Wasm-Module laufen identisch auf Laptop, Bench und Zielhardware – reproduzierbare Tests. Deterministische Umgebung (AoT) für Latenz-Charakterisierung. Trace-Daten zeigen Interop-Overhead.

Warum konfigurierbare Testbench statt fixer Hardware-Setups?

Flexibilität: Software-defined Topologien erlauben schnelle Szenario-Wechsel ohne Hardware-Umbau (Umschaltzeit <1 ms).
Kostenreduktion: Zentrale Bench statt Hardware-Duplikate bei jedem Partner – messbare CO₂-Einsparungen.
Datensammlung: Bench liefert realistische Daten für GNN-Training.

Was ist der Unterschied zwischen Bench-Tests und Simulation?

Bench: Nutzt reale Hardware (RECS, echte Bus-Systeme), liefert realistische Latenz-/Jitter-Daten.
Simulation (OMNeT++, Mininet): Rein software-basiert, skaliert besser für viele Szenarien, aber weniger realistische Timings.
Best Practice: Simulation für Exploration, Bench für Validierung.

Welche Latenz-Anforderungen erfüllt die Schaltmatrix?

Physical-Layer Switching: Ziel ist minimale Latenz und schnelle Umschaltzeiten, kritisch für TSN und Echtzeit-Tests. Charakterisierung vor Einsatz geplant.
Use Cases: ADAS, Fahrdynamik-Regelung, Safety-kritische Pfade.

Wie funktioniert Remote-Zugriff TISAX-konform?

Zeit-Slot-Reservierung: Web-Interface, exklusiver Zugriff während Slot.
Multi-Tenant-Isolation: Separate Namespaces, VLANs, verschlüsselt (TLS 1.3).
Keine Produktionsdaten: Nur Bench-generierte Daten, pseudonymisierte Test-Daten erlaubt.
Audit-Trail: Alle Zugriffe protokolliert (TISAX VDA ISA 6.0 Level 3).

Hinweis: TISAX und Security-elemente sind geplant, aber derzeit optional.

Welche E/E-Architekturen werden unterstützt?

Legacy-Domänen: Dezentrale Steuergeräte nach Funktionen getrennt (Powertrain, Chassis, Infotainment).
Zonen-Controller: Regional gruppierte Controller nach Fahrzeugbereichen (vorne, hinten, links, rechts).
Zentral-Computer: Hochintegrierte Plattformen (L3+ Autonomie, alle Funktionen zentralisiert).
Testbench-Vorteil: Alle Stufen in einer Plattform testbar – Migrations-Szenarien validieren.

Welche RECS-Varianten und Formfaktoren werden unterstützt?

t.RECS: Thermal-optimiert (x86), für High-Performance (ADAS). Unterstützt Standard-Formfaktoren:
SMARC: Ultra-Low-Power (ARM Cortex-A), ideal für Sensor-Nodes.
COM-HPC: High-Performance (x86, GPU-ready), für Zentral-Computer.
COM-Express: Industrial-Standard, breite Vendor-Unterstützung.
TSN-fähig, verschiedene Architekturen (x86, ARM, RISC-V).

Was ist der Unterschied zwischen HIL, SIL und Shadow Mode Testing?

HIL (Hardware-in-the-Loop): Reale ECUs + simulierte Umgebung – echte Hardware-Validierung.
SIL (Software-in-the-Loop): Rein software-basiert – Validierung vor Hardware-Verfügbarkeit.
Shadow Mode (A/B Testing): KI-Modelle parallel zu Produktion – Vorschläge loggen, nicht anwenden. Validierung ohne Risk.
Use Case: SIL → HIL → Shadow Mode → Production (schrittweise Validierung).

Wie integriert die Testbench mit Wasm und KI?

Wasm: Module laufen identisch auf Laptop, Bench, Zielhardware – reproduzierbare Tests. Bench liefert deterministische Umgebung (AoT-Kompilierung) für Latenz-Charakterisierung.
KI: Bench sammelt Topologie-Graphen + Latenz-Messungen → GNN-Training (Latenzprognose, Platzierung). Validierung im Shadow-Mode.

Weitere Technologie-Seiten: SDV-Plattform · Künstliche Intelligenz · WebAssembly