Zum Inhalt springen
Kostenlos ⚠️ Hybrid Geprüft: April 2026

Eclipse Kuksa

Eclipse Foundation (SDV Working Group)

4/5
Tool öffnen

Eclipse Kuksa ist die Open-Source-Plattform für Fahrzeugtelemetrie im Software Defined Vehicle (SDV)-Umfeld. Das Kuksa.val-Databroker läuft direkt im Fahrzeug und stellt Fahrzeugsignale nach VSS (Vehicle Signal Specification) standardisiert bereit — der Einstieg in skalierbare Telemetrie-Pipelines ohne Vendor-Lock-in.

Kosten: Open Source (Apache 2.0); kostenlos self-hosted. Infrastrukturkosten (Server, Cloud) je nach Deployment separat.

Stärken

  • Standardisierte VSS-Signal-Semantik: einheitliche Signalnamen und -typen über Fahrzeugtypen hinweg
  • On-Premise-fähig: Databroker läuft in-vehicle (gRPC/SOME-IP), Cloud-Anbindung flexibel wählbar
  • Aktive Eclipse-Foundation-Community mit Beiträgen von CARIAD (Volkswagen), Bosch, Microsoft, Red Hat
  • Apache-2.0-Lizenz — keine Royalties, kein Vendor-Lock-in
  • Integriert mit AUTOSAR Adaptive und COVESA VSSo-Ontologie für branchenweite Interoperabilität

Einschränkungen

  • Erfordert tiefes Embedded- und Linux-Knowhow für den In-Vehicle-Betrieb
  • Kein deutschsprachiger Support — alle Docs und Community-Kanäle auf Englisch
  • Noch keine stabile Produktionsreife für sicherheitskritische AUTOSAR-Domänen (nur Infotainment/ZU-Ebene)
  • DBC-Dekodierung (CAN-Signale) liegt außerhalb des Kuksa-Scopes — separates Tooling (cantools, Vector tools) notwendig

Passt gut zu

OEM-interne Entwicklungsteams, die VSS-basierte Telemetrie-Pipelines aufbauen Tier-1-Zulieferer, die Telemetrie-APIs ohne Vendor-Lock-in implementieren wollen Forschungseinrichtungen und Startups mit CARIAD/Bosch-Ökosystem-Anbindung

So steigst du ein

Schritt 1: Klone das Repository (git clone https://github.com/eclipse-kuksa/kuksa-databroker) und starte den Databroker lokal via Docker (docker run eclipse/kuksa-databroker:latest). Das reicht für erste Experimente mit VSS-Signalen ohne Fahrzeughardware.

Schritt 2: Simuliere Fahrzeugsignale mit dem Kuksa-Client (pip install kuksa-client) und sende Testsignale (z.B. Vehicle.Speed, Vehicle.Powertrain.Battery.StateOfCharge.Current) gegen den lokalen Databroker.

Schritt 3: Verbinde deinen Cloud-Ingestion-Stack (Kafka, Azure IoT Hub oder MQTT-Broker) mit dem Databroker-Feed-Connector. Für Produktion: Abstimmung mit der Fahrzeugsoftware-Architektur notwendig — der Databroker läuft auf dem Gateway-ECU oder einem zentralen Compute-Node.

Ein konkretes Beispiel

Ein EV-Startup mit 3.000 Testfahrzeugen nutzt Eclipse Kuksa als standardisierte Signalschnittstelle zwischen Fahrzeugcomputer und Cloud-Telemetrie-Pipeline. Der Kuksa-Databroker aggregiert CAN-Bus-Signale (nach DBC-Dekodierung via cantools), OBD-Diagnosewerte und SOME-IP-Nachrichten und stellt sie als gRPC-Stream bereit. Databricks-Jobs konsumieren diesen Stream für stündliches Clustering auf Fehlermustern. Ohne Kuksa gab es pro Fahrzeugvariante eine proprietäre Telemetrie-Lösung — jetzt ein einheitliches Schema, ein einheitlicher Ingestion-Pfad.

Diesen Inhalt teilen:

Empfohlen in 1 Use Cases

Redaktionell bewertet · Preise und Funktionen können sich ändern.

Stimmt etwas nicht?

Preise geändert, Feature veraltet oder etwas fehlt? Wir freuen uns über Hinweise und Ergänzungen.

Feedback geben
Kostenloser Newsletter

Bleib auf dem neuesten
Stand der KI

Wähle deine Themen und erhalte relevante KI-News, Praxistipps und exklusive Inhalte direkt in dein Postfach – kein Spam, jederzeit abmeldbar.

Was interessiert dich? Wähle 1–3 Themen — du bekommst nur Inhalte dazu.

Mit der Anmeldung stimmst du unserer Datenschutzerklärung zu. Jederzeit abmeldbar.

Kostenlos
Kein Spam
Jederzeit abmeldbar