Eclipse Kuksa

Kurzfazit

Eclipse Kuksa ist eine gut gemachte Open-Source-Middleware für Fahrzeugsignale und kein KI-Werkzeug. Der Databroker läuft auf einem Steuergerät im Fahrzeug, nimmt Signale von CAN-Bus, SOME/IP, DDS oder GPS entgegen und stellt sie nach der COVESA Vehicle Signal Specification standardisiert über gRPC und JSON bereit.¹² Damit löst er ein echtes Problem: Ohne gemeinsame Signalsemantik schreibt jedes Team seine Datenanbindung neu, pro Fahrzeugvariante. Kuksa trainiert aber keine Modelle, trifft keine Inferenzentscheidungen und enthält keine ML-Komponenten. Es ist die Datenebene, auf der KI später aufsetzt, die KI selbst sitzt woanders. Wer ein Embedded-Team hat, bekommt hier ein lizenzkostenfreies, extern auditiertes Fundament. Wer eine fertige Flottenplattform sucht, ist hier falsch.

Für wen ist Eclipse Kuksa?

SDV-Entwicklerteams bei OEMs und Tier-1-Zulieferern: Die eigentliche Zielgruppe. Wenn ihr an Software Defined Vehicles arbeitet und eine standardisierte, herstellerneutrale Abstraktionsschicht zwischen Bussystem und Anwendung braucht, ist Kuksa der naheliegende Kandidat, allein schon weil er im Eclipse-SDV-Umfeld mit Velocitas, Leda und den IoT-Projekten Hono und hawkBit zusammenspielt.

Forschung und Prototyping: Hochschulen, Fraunhofer-Institute und Vorentwicklungsabteilungen bekommen ein Werkzeug ohne Lizenzkosten und ohne NDA. Die Projektseite verweist ausdrücklich auf Prototyping, inklusive der CANOPi-Hardware mit zwei unabhängigen CAN-FD-Schnittstellen.¹

Teams, die Testflotten instrumentieren: Wer 20 Erprobungsfahrzeuge mit Messtechnik ausstattet und Signale vergleichbar auswerten will, hat ohne gemeinsame Semantik ein Datenchaos. Genau hier zahlt VSS sich aus.

Integrationsteams mit Datensparsamkeitsauftrag: Weil der Databroker im Fahrzeug läuft, kannst du filtern und aggregieren, bevor irgendetwas das Auto verlässt. Das ist datenschutzrechtlich ein deutlich besserer Ausgangspunkt als „alles hochladen, später aussortieren”.

Weniger geeignet für: Alle ohne Embedded-Team, alle, die einen Supportvertrag mit Reaktionszeiten brauchen, und alle, die hier ein KI-Werkzeug suchen. Kuksa ist Infrastruktur, keine Anwendung.

Preise im Detail

Position	Kosten
Lizenz	0 €. Apache Software License 2.0 und Eclipse Public License 2.0, keine Royalties
Kommerzieller Support	Von der Eclipse Foundation nicht angeboten. Nur über Dienstleister aus dem Umfeld
Hardware	Steuergeräte, Gateways oder Prototyping-Boards nach eigener Wahl, Projektkosten
Infrastruktur	Nur, wenn du Daten ausleitest: Speicher, Zeitreihendatenbank, Visualisierung
Eigentliche Kosten	Entwickler- und Integrationszeit, plus laufende Pflege bei Versionswechseln

Einordnung: Die Lizenz ist gratis, das Projekt nicht. Wie bei jeder Infrastruktur-Software liegt der Aufwand in Integration, Test und Pflege: Bus-Anbindung, VSS-Mapping auf eure Signalnamen, Sicherheitskonzept, Update-Strategie über die Fahrzeuglaufzeit. Wer das gegen eine kommerzielle Telemetrie-Plattform rechnet, sollte ehrlich zwei bis drei Entwicklermonate für die erste tragfähige Integration ansetzen, plus laufende Betreuung. Der Gegenwert ist Unabhängigkeit: kein Lizenzmodell, das sich mit der Flottengröße ändert, und kein Anbieter, der die Schnittstelle nach einer Übernahme umbaut.

Stärken im Detail

Eine Signalsprache für alle Fahrzeuge. Die COVESA Vehicle Signal Specification definiert einen gemeinsamen Baum aus Signalnamen, Einheiten und Datentypen. Statt „Signal 0x2A0 Byte 3 im Fahrzeugprojekt X” heißt es überall gleich Vehicle.Powertrain.CombustionEngine.Speed. Für Teams, die mehrere Baureihen oder Zulieferersteuergeräte anbinden, ist das der eigentliche Wertbeitrag: Die Auswertelogik überlebt den Fahrzeugwechsel.²

Läuft im Fahrzeug, nicht in der Cloud. Der Databroker ist ein in-vehicle Server. Anwendungen auf demselben Steuergerät greifen lokal über gRPC oder JSON zu, nichts muss zwingend nach außen. Das ist gut für Latenz, gut für Ausfallsicherheit im Funkloch und gut für Datenschutz.²

Rust im Kern, saubere SDK-Abdeckung. Der Databroker ist in Rust geschrieben, was für eine speicherkritische, langlaufende Komponente auf einem Steuergerät die richtige Entscheidung ist. Drumherum liegen SDKs für Python, Java, Rust und Android sowie fertige Provider für CAN, DDS, GPS und SOME/IP, also genau die Anbindungen, die man im Fahrzeug tatsächlich braucht.³

Extern auditiert. Im Mai 2024 hat Quarkslab, vermittelt über OSTIF und die Eclipse Foundation, ein Sicherheitsaudit von Databroker und Python-Client-SDK veröffentlicht.¹ Das ist für ein Open-Source-Projekt dieser Größe keine Selbstverständlichkeit und ein Argument, das in Sicherheitsfreigaben zählt.

Stiftungsgetragen statt firmengetragen. Das Projekt liegt bei der Eclipse Foundation und ist Teil der Working Groups Software Defined Vehicle und IoT.² Es kann also nicht von einem einzelnen Unternehmen umlizenziert oder eingestellt werden, ein Unterschied, der bei Software mit Fahrzeuglebensdauer von zehn bis fünfzehn Jahren real ist.

Schwächen ehrlich betrachtet

Kein KI-Anteil, und zwar bewusst. Kuksa hat keine ML-Modelle, keine Anomalieerkennung, keine Inferenz-Runtime. Wer Predictive Maintenance oder Fehlermustererkennung will, baut die Auswertung selbst oder kauft sie separat. Das ist keine Schwäche des Projekts im engeren Sinn, aber es ist der Grund, warum wir hier keine KI-Empfehlung aussprechen.

Incubating heißt Incubating. Das Projekt steht bei der Eclipse Foundation weiterhin im Incubating-Status.² Der Databroker selbst trägt zwar Produktionsreife im Repository, aber der Projektstatus bedeutet formal: keine Zusagen zu Schnittstellenstabilität über Major-Versionen hinweg. Wer das in ein Serienfahrzeug bringt, braucht eine eigene Versionsstrategie und muss Migrationsaufwand einplanen.

Kein Supportvertrag. Es gibt niemanden, den du um zwei Uhr nachts anrufen kannst. Support läuft über GitHub-Issues, Mailinglisten und die Community. Für eine Vorentwicklung ist das in Ordnung, für ein Serienprogramm brauchst du entweder eigenes Knowhow in der Tiefe oder einen Dienstleister, der es mitbringt.

Veraltete Anleitungen im Netz. Der ursprüngliche kuksa.val-Server ist archiviert und End-of-Life.³ Im Netz stehen trotzdem noch viele Tutorials, Blogposts und Konferenzfolien, die sich darauf beziehen. Wer neu einsteigt, verliert leicht einen Tag mit einer Architektur, die es so nicht mehr gibt. Halte dich strikt an die aktuelle Projektseite und die GitHub-Organisation.

Nichts oberhalb der Datenebene. Kein Dashboard, keine Speicherung, keine Alarmierung, keine Flottenverwaltung. Alles, was nach dem Signal kommt, ist deine Aufgabe. In der Praxis heißt das: Kuksa ist nie das ganze Projekt, sondern immer eine Komponente in einem Stack, den du selbst zusammenstellst.

Englisch, durchgängig. Dokumentation, Issues, Mailinglisten, Spezifikation. Für Automotive-Entwicklerteams normal, für alle anderen eine Hürde.

Alternativen im Vergleich

Wenn du…	…nimm stattdessen
Eine fertige IoT-Plattform mit Geräteverwaltung und Dashboards willst	ThingsBoard
Zeitreihen aus Fahrzeug- oder Anlagensignalen speichern willst	InfluxDB
Die Signale visualisieren und Schwellwerte überwachen willst	Grafana
Auf den Daten Modelle trainieren und betreiben willst	AWS SageMaker
Große Flottendatenmengen aufbereiten und auswerten willst	Databricks

Zur Einordnung: Keines dieser Werkzeuge ersetzt Kuksa, sie ergänzen es. Kuksa ist die Schicht, die im Fahrzeug aus Rohsignalen benannte Datenpunkte macht. Alles darüber, Speicherung, Auswertung, Visualisierung, KI, ist ein eigener Baustein. Wer eine echte Alternative auf derselben Ebene sucht, landet bei proprietären OEM-eigenen Signalabstraktionen oder bei kommerziellen Automotive-Middleware-Stacks, die wir hier nicht führen, weil sie ebenfalls keine KI-Werkzeuge sind.

So steigst du ein

Schritt 1: Fang mit dem Quickstart auf Standard-Hardware an. Bevor du an ein echtes Steuergerät gehst, bring den Databroker lokal oder auf einem Raspberry Pi zum Laufen und speise ihn mit aufgezeichneten CAN-Daten. Du siehst dann in wenigen Stunden, ob das VSS-Modell zu deinen Signalen passt, ohne dass Hardware-Themen die Sicht verstellen.

Schritt 2: Mach das VSS-Mapping zum eigenen Arbeitspaket. Der Punkt, an dem Projekte hängenbleiben, ist selten die Software, sondern die Zuordnung zwischen euren internen Signalnamen und dem VSS-Baum. Setz dafür eine Person mit Bus-Wissen und eine mit Datenmodell-Wissen zusammen und dokumentiert das Mapping versioniert im Repository, nicht in einer Tabelle auf einem Netzlaufwerk.

Schritt 3: Kläre Sicherheit und Datenschutz, bevor du ausleitest. Sobald Signale das Fahrzeug verlassen, wird aus einem Technikprojekt ein Datenschutzprojekt. Entscheide früh, welche Signale überhaupt raus dürfen, ob sie im Fahrzeug aggregiert werden und wer im Betrieb Zugriff bekommt. Das Quarkslab-Audit hilft bei der Sicherheitsfreigabe, ersetzt aber kein eigenes Konzept.

Ein konkretes Beispiel

Ein Tier-1-Zulieferer im Raum Stuttgart erprobt ein neues Thermomanagement für Elektrofahrzeuge und hat dafür 30 Fahrzeuge aus drei verschiedenen Baureihen im Feld. Bisher schrieb jedes Fahrzeugprojekt seine eigene Messdatenanbindung, mit dem Ergebnis, dass die Auswertescripte für Baureihe A auf Baureihe B nicht liefen und ein Praktikant im Sommer drei Wochen mit Spaltenumbenennung verbracht hat. Mit Kuksa als Databroker im Messfahrzeug liegen die relevanten Größen für alle drei Baureihen unter denselben VSS-Pfaden. Die Ausleitung filtert im Fahrzeug auf 40 Signale statt der über 2.000 verfügbaren, was das übertragene Datenvolumen erheblich senkt und die Datenschutzprüfung überhaupt erst handhabbar macht. Die eigentliche Auswertung, Muster in Kühlkreislauf-Verläufen finden, passiert danach in der Cloud auf einer ML-Plattform. Kuksa liefert die Eingangsdaten, mehr nicht, und genau das ist der Punkt.

DSGVO & Datenschutz

• Kein Anbieter, kein Vertrag: Kuksa ist Software, die du selbst betreibst. Es gibt keinen Auftragsverarbeiter, keinen AVV und keine Datenübermittlung an die Eclipse Foundation. Verantwortlicher im Sinne der DSGVO bist vollständig du.
• Speicherort: Du bestimmst ihn. Der Databroker läuft im Fahrzeug, alles Weitere hängt an deiner eigenen Infrastruktur. Wer EU-Hosting braucht, kann es umsetzen, muss es aber selbst tun.
• Fahrzeugdaten sind meist personenbezogen: Position, Geschwindigkeitsprofil, Ladezustand, Fahrzeugidentifikationsnummer. Sobald ein Bezug zu einer Fahrerin oder einem Halter herstellbar ist, greift die DSGVO in voller Breite. Der EU Data Act verschärft die Lage zusätzlich, weil er Nutzern Zugriffs- und Weitergaberechte an den von ihren Fahrzeugen erzeugten Daten einräumt.
• Datensparsamkeit ist hier technisch machbar: Der große Vorteil einer in-vehicle Architektur: Du kannst auf dem Steuergerät filtern, aggregieren und pseudonymisieren, bevor Daten übertragen werden. Nutze das aktiv, es ist das stärkste Argument gegenüber Aufsichtsbehörden und Betriebsrat.
• Beschäftigtendaten: Bei Dienstwagen und Erprobungsflotten sind Fahrdaten zugleich Beschäftigtendaten. Betriebsvereinbarung und Mitbestimmung gehören früh ins Projekt, nicht nach dem ersten Prototyp.
• Sicherheit: Das Audit von Quarkslab vom Mai 2024 deckt Databroker und Python-SDK ab.¹ Zugriffskontrolle, Authentifizierung und Netzwerktrennung im Fahrzeug musst du trotzdem selbst konfigurieren, die Standardkonfiguration eines Prototyping-Setups gehört nicht ins Feld.
• Empfehlung: Für Teams mit eigenem Sicherheits- und Datenschutz-Knowhow eine sehr gute Ausgangslage, weil nichts an einen Dritten abfließt. Für Teams ohne diese Kompetenz ist die Selbstverantwortung eher Risiko als Vorteil.

Gut kombiniert mit

• InfluxDB und Grafana, das Standardgespann für alles nach dem Databroker: Zeitreihen speichern, Verläufe visualisieren, Schwellwerte überwachen. Für die meisten Erprobungsprojekte reicht diese Kombination lange, bevor überhaupt eine ML-Plattform nötig wird.
• AWS SageMaker, wenn aus den gesammelten Signalen tatsächlich Modelle werden sollen, etwa für Anomalieerkennung im Antriebsstrang oder Verschleißprognosen. Hier passiert die KI, die Kuksa selbst nicht mitbringt.
• ThingsBoard, wenn du oberhalb der Fahrzeugebene eine Geräte- und Flottenverwaltung mit Dashboards brauchst und sie nicht selbst bauen willst.

Unser Fazit

Eclipse Kuksa bekommt 3 von 5 Sternen. Technisch ist das Projekt gut aufgestellt: Databroker in Rust, saubere SDK- und Provider-Abdeckung, ein externes Sicherheitsaudit, aktive Releases bis April 2026 und eine Trägerschaft bei der Eclipse Foundation, die das Projekt gegen die Launen einzelner Firmen absichert.¹³² Gegen mehr Sterne sprechen drei Dinge. Erstens der Incubating-Status ohne kommerziellen Supportvertrag, was für Serienprogramme ein echtes Risiko ist. Zweitens die hohe Einstiegshürde, ohne Embedded- und Bus-Wissen ist das Projekt nicht nutzbar, und die veralteten kuksa.val-Anleitungen im Netz machen den Einstieg unnötig steinig. Drittens, und für unser Publikum entscheidend: Kuksa ist keine KI, sondern die Schicht darunter. Für SDV-Teams ist es trotzdem eine der solidesten offenen Optionen am Markt, und für alle anderen schlicht nicht das richtige Werkzeug.

Was wir bemerkt haben

• Juli 2026, Projektstatus auf der Eclipse-Projektseite geprüft: weiterhin Incubating, Lizenzen Apache 2.0 und EPL 2.0, Mitgliedschaft in den Working Groups Software Defined Vehicle und IoT. Das Release 0.5.0 stammt vom 20. Dezember 2024, das aktuellste dokumentierte Release 0.6.1 vom 9. April 2026.² Das Projekt ist also aktiv, aber der formale Reifegrad hat sich seit Jahren nicht geändert.
• Juli 2026, Seite von Deprecation-Framing auf eine ehrliche KI-nah-Einordnung umgestellt und auf die volle Struktur gebracht. Eclipse Kuksa bleibt status: live und voll sichtbar, wird aber als Dateninfrastruktur (aiRelevance: adjacent) geführt, nicht als KI-Tool empfohlen. Ein früher genannter, nicht belegbarer Vergleich einzelner beitragender Firmen wurde entfernt.
• Mai 2024, Quarkslab veröffentlicht ein Sicherheitsaudit von Kuksa Databroker und Python-Client-SDK, vermittelt über OSTIF und die Eclipse Foundation.¹ Für ein Projekt dieser Größe ungewöhnlich und ein handfestes Argument in Sicherheitsfreigaben.
• Weiterhin gültig, der ursprüngliche kuksa.val-Server ist archiviert und End-of-Life.³ Wer über eine ältere Anleitung einsteigt, baut auf einer Architektur, die es nicht mehr gibt. Aktuelle Quelle ist die Eclipse-Kuksa-GitHub-Organisation.

Quellen

1. Eclipse Kuksa, offizielle Projektseite (GitHub Pages), https://eclipse-kuksa.github.io/kuksa-website/, abgerufen am 25.07.2026. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

2. Eclipse KUKSA, Projektseite der Eclipse Foundation (Incubating, Working Groups, Lizenzen, Releases, COVESA VSS, gRPC/JSON), https://projects.eclipse.org/projects/automotive.kuksa, abgerufen am 25.07.2026. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

3. Eclipse Kuksa, GitHub-Organisation (Databroker in Rust, SDKs, Provider, End-of-Life von kuksa.val), https://github.com/eclipse-kuksa, abgerufen am 18.07.2026. ↩ ↩² ↩³ ↩⁴