Quix
Quix ist ein Unternehmen für Echtzeit-Datenplattformen. Wir liefern die Software-Ebene, die Sensordaten aufnimmt, in Echtzeit verarbeitet und in Steuerungsaktionen überführt, aufgebaut auf offenen Standards (Apache Kafka, MQTT, Python).
Für kommunale und Infrastrukturkunden liegt unser Schwerpunkt auf der Integration heterogener Sensordatenströme, der zuverlässigen Ausführung mehrstufiger Wenn-Dann-Steuerungslogik, deren Konfiguration durch Betriebspersonal ohne Programmierkenntnisse, der automatisierten Berichterstattung sowie dem sicheren Betrieb (ISO 27001, Betrieb in der stadteigenen Cloud oder On-Premises). Wir liefern selbst keine Sensoren oder Leuchten, sondern bringen die Daten vorhandener Hardware-Partner zuverlässig zum Zusammenwirken und machen das Ergebnis messbar.
Vergleichbare Projekte (ohne Kundennamen):
Für die Verkehrsbehörde einer Stadt: Echtzeitverarbeitung von rund 40 GB/Tag an WLAN-Sensordaten aus 180 Stationen mit Machine Learning, betrieben auf einem dedizierten, vom Internet getrennten Cloud-Konto mit Zugriff nur über VPN.
Für einen deutschen Betreiber erneuerbarer Energien (kritische Infrastruktur): Zusammenführung heterogener Edge- und Sensordaten in eine einzige Echtzeit-Ansicht mit einer Alarmregel je Gerätetyp; rund 30 TB/Monat; Speicherkosten um den Faktor 100 gesenkt; im Tagesbetrieb von einer Person ohne Programmierhintergrund bedient.
Für einen nationalen Wasserversorger: vollständig abgeschotteter On-Premises-Betrieb in einer regulierten betriebstechnischen Umgebung.
Für einen großen Maschinenbauer: Python-native Echtzeit-Pipeline zur Aufnahme von Maschinensensordaten über MQTT.
Alle Sensortypen (Radar, Umweltsensoren, Fahrzeugklassifizierung, Neigung und Schwingung) werden in eine einzige Echtzeit-Pipeline aufgenommen. Jeder Typ gelangt über seinen eigenen Datenstrom herein, je Lichtpunkt zugeordnet, sodass ein Datenstrom hinzugefügt oder entfernt werden kann, ohne die anderen zu berühren.
Das zuverlässige Zusammenspiel stellen wir über vier Mechanismen sicher, an denen einfache Integrationen scheitern:
Zeitliche Ausrichtung heterogener Quellen: Wir richten alle Daten anhand des jeweils eigenen Zeitstempels einer Messung auf der Ereigniszeit aus, nicht anhand des Eingangszeitpunkts. So beruht jede Entscheidung auf einem konsistenten Bild, auch wenn Radar mehrmals pro Sekunde, ein Luftqualitätssensor einmal pro Minute und ein Neigungssensor nur bei Veränderung meldet.
Umgang mit verspäteten und nicht der Reihe nach eintreffenden Daten: Da die LoRa-Zustellung weder sofort noch in garantierter Reihenfolge erfolgt, berücksichtigt die Pipeline verspätete Eingänge, statt auf einem unvollständigen Bild zu handeln.
Lastausgleich (Back-Pressure): Ist ein nachgelagertes System kurzzeitig langsam, drosselt die Plattform die Aufnahme kontrolliert, statt Messwerte zu verwerfen oder den Broker zu überlasten.
Zustandsbehafteter Kontext je Lichtpunkt: Jeder Lichtpunkt führt seine jüngste Historie mit (letztes Verkehrsereignis, aktuelles Umgebungsniveau, jüngste Schwingung), sodass Regeln über Zustand und Trend entscheiden und nicht nur über den letzten Einzelwert.
Priorisierung konkurrierender Auslöser: Da alle Sensoren in eine gemeinsame Pipeline einspeisen, hat die Plattform bei jeder Entscheidung die vollständige Situation im Blick. Konflikte werden durch ausdrückliche, konfigurierbare Regeln aufgelöst. Jede Regel trägt eine Priorität, wobei Sicherheitsbedingungen (Schwingungs- oder Neigungsalarm, für Fußgänger relevante Ereignisse) Vorrang vor Energiesparbedingungen haben, sodass ein Abdimmen eine Sicherheitsreaktion nie außer Kraft setzt. Betreffen zwei Regeln im selben Moment denselben Lichtpunkt, setzt sich die höherpriorisierte durch, und die Entscheidung wird protokolliert und bleibt damit erklärbar.
Stabilität im realen Betrieb: Schwellenwerte tragen Mindesthaltezeiten (Hysterese und Entprellung), sodass Leuchten bei Grenzwerten oder einzelnen verrauschten Messwerten nicht zwischen Stufen flackern. Fehlen Eingangsdaten oder sind sie veraltet, fallen die betroffenen Lichtpunkte auf eine definierte sichere Beleuchtungsstufe zurück statt in einen undefinierten Zustand. Jede Entscheidung wird aufgezeichnet und bildet die Grundlage für Fehlerdiagnose und Nachweis. Dieselbe Architektur betreiben wir in vergleichbar anspruchsvollen Umgebungen, etwa bei rund 40 GB Sensordaten pro Tag aus 180 Stationen und bei rund 30 TB pro Monat über verteilte Anlagen kritischer Infrastruktur.
Die Steuerungslogik wird als Regelkatalog abgebildet. Jede Regel ist eine kurze, lesbare Beschreibung von Bedingungen und einer Aktion, zum Beispiel: "Wenn Fahrzeugklasse = LKW und Geschwindigkeit > Y km/h, dann setze die Beleuchtungsstärke im Abschnitt S für T Sekunden auf Stufe Z" oder "Wenn Umgebungshelligkeit < X und kein Verkehr erkannt, dann dimme auf Minimalstufe". Mehrstufige Szenarien entstehen, indem Regeln über mehrere Sensoren, Zeitfenster und den jüngsten Zustand eines Lichtpunkts kombiniert werden. Die Auswertung erfolgt zentral in der Echtzeit-Pipeline, sodass auch verschachtelte Und/Oder-Bedingungen und prioritätsabhängige Reaktionen konsistent und nachvollziehbar abgearbeitet werden.
Entscheidend ist: Die Regeln werden als versionierte Konfiguration gespeichert, nicht im Code vergraben. Jede Änderung wird nachverfolgt, jede frühere Version kann wiederhergestellt werden, und zwei beliebige Versionen lassen sich vergleichen, um genau zu sehen, was sich wann geändert hat. Für eine Stadt, die das Beleuchtungsverhalten gegenüber Verwaltung und Politik begründen muss, wird die Steuerungslogik damit von einer Blackbox zu einem transparenten, prüfbaren Dokument.
Konfiguration durch kommunales Personal ohne Programmierkenntnisse: Wir sind ehrlich, wie das funktioniert, denn die Ausschreibung verlangt zu Recht, Komplexität beherrschbar zu machen, ohne sie zu verschleiern. Quix baut die Regel-Engine und einen anfänglichen Katalog von Regelvorlagen einmalig gemeinsam mit Ihrem Team auf. Danach ist der Tagesbetrieb Konfiguration, nicht Programmierung. Ihr Betriebspersonal passt Schwellenwerte, Beleuchtungsstufen, Haltezeiten, Prioritäten und die Zuordnung, welche Regel für welche Straße oder welchen Abschnitt gilt, durch das Bearbeiten von Parametern in einer kontrollierten Konfigurationsoberfläche an. Kein Python, kein Deployment, keine spezialisierte IT für diese alltäglichen Änderungen. Jede Änderung ist versioniert, umkehrbar und kann vor der Aktivierung geprüft werden.
Das Einführen eines wirklich neuen Regeltyps (eine neue Sensorkombination, die keine Vorlage abdeckt) ist eine kleine Entwicklungsaufgabe, die wir im Rahmen der Betreuung übernehmen oder die ein städtischer Ingenieur später mit denselben Werkzeugen erledigen kann. Diese Aufteilung, kein Code für die alltägliche Feinjustierung und nur leichte Entwicklung für wirklich neue Logik, hält das System über Jahre sicher und wartbar. Dass dieser Ansatz im Alltag trägt, zeigt sich in der Praxis: Bei einem deutschen Energiebetreiber auf unserer Plattform betreibt der IT-Leiter, nach eigener Aussage kein Vollzeit-Programmierer, seine Datenpipelines mithilfe unserer Vorlagen und integrierter KI-Unterstützung.
Quix beruht auf offenen Standards und fügt sich neben einen bestehenden Technologie-Stack ein, statt ihn zu ersetzen.
LoRa-Netz: LoRaWAN-Netzwerkserver veröffentlichen Geräte-Uplinks über MQTT. Quix verfügt über einen produktiven MQTT-Connector, sodass die Plattform die Sensor-Uplinks direkt am Broker Ihres LoRa-Netzwerkservers abonniert und Downlink-Befehle auf demselben Weg veröffentlicht. MQTT ist eine native, unterstützte Schnittstelle, keine selbstgebaute Brücke.
Beleuchtungsmanagement (Exedra): Quix integriert sich über die von Exedra bereitgestellten Schnittstellen, typischerweise eine REST-API und/oder MQTT. Die Plattform liest Zustände aus Exedra und schreibt Steuerbefehle zurück, sodass Exedra das führende System für die Leuchten bleibt, während Quix die sensorübergreifenden Entscheidungen liefert. Die genaue Anbindung legen wir in einer kurzen Integrationsanalyse zu Projektbeginn fest.
Vorhandene Leuchten und Hardware: Quix sendet Befehle über Exedra und den bestehenden Steuerungspfad. Die Kompatibilität wird damit vom bereits betriebenen Managementsystem übernommen. Wir fügen keine proprietäre Hardware hinzu und schreiben keinen bestimmten Leuchten-Hersteller vor, was das Ziel, unnötige Produktvielfalt im kommunalen Bestand zu vermeiden, unmittelbar unterstützt.
Unterstützte Schnittstellen: MQTT (Quellen und Senken), REST-APIs, Telegraf, InfluxDB, Apache Kafka sowie S3-kompatibler Speicher werden heute produktiv unterstützt. Da die Plattform offen und erweiterbar ist, lassen sich weitere Connectoren bei Bedarf ergänzen.
Datensouveränität und Sicherheit: Für einen Einsatz in der öffentlichen Hand ist dies ebenso wichtig wie die Protokolle. Quix kann im stadteigenen Cloud-Konto oder On-Premises betrieben werden, einschließlich abgeschotteter, netzwerkbeschränkter Umgebungen, sodass Sensor- und Verkehrsdaten innerhalb der Grenzen und unter der Kontrolle der Stadt bleiben. Quix ist ISO-27001-zertifiziert. Genau dieses abgeschottete Modell haben wir bereits umgesetzt: für ein Smart-City-Projekt der öffentlichen Hand (dediziertes, vom Internet getrenntes Cloud-Konto, Zugriff nur über VPN, regelmäßige Penetrationstests) sowie für einen Wasserversorger in einer vollständig abgeschotteten betriebstechnischen Umgebung.
Die ersten Monate unter realem Verkehr und realem Wetter sind die Phase, in der sich die Steuerungslogik tatsächlich bewährt und in der die meisten Projekte sich selbst überlassen werden. Unser Ansatz ist das Gegenteil.
Datenbasierte Feinjustierung: Vom ersten Tag an werden jeder Sensorwert und jede Steuerungsentscheidung gespeichert. Während der Inbetriebnahme nutzen wir das auf zwei Arten.
Erstens beobachten wir live, wie sich die Regeln unter realen Bedingungen verhalten, und passen Schwellenwerte, Haltezeiten und Prioritäten an, sobald sich Muster zeigen, etwa über Stoßzeiten, Wetterfronten und Werktag gegenüber Wochenende.
Zweitens, und diese Fähigkeit fehlt den meisten Anbietern, können wir die ersten Wochen real aufgezeichneter Daten durch einen überarbeiteten Regelsatz erneut laufen lassen, bevor wir ihn ausrollen. Eine vorgeschlagene Änderung wird so gegen das geprüft, was auf den Konstanzer Straßen tatsächlich geschehen ist, nicht gegen Annahmen, sodass die Stadt die Wirkung einer Regeländerung sieht, bevor sie produktiv geht.
Leistungen für die Inbetriebnahme- und Nachbetreuungsphase:
Eine definierte Optimierungsphase in den ersten Monaten, mit regelmäßiger Überprüfung des Live-Verhaltens und datenbasierter Feinjustierung.
Ein monatlicher Steuerungsrhythmus (ein Format, das wir bereits mit Kunden im Bereich regulierter Infrastruktur durchführen), in dem Quix Verbesserungsvorschläge einbringt und die Stadt Betriebsbeobachtungen, mit klar festgehaltenen Maßnahmen je Sitzung.
Schulung und Dokumentation, damit Ihr Betriebsteam Regeln eigenständig konfigurieren und pflegen kann.
Übergang in den eigenständigen Betrieb: Das Ziel ist ein System, das die Stadt selbst betreiben kann. Die alltägliche Anpassung der Logik erfolgt als Konfiguration ohne Programmierung (siehe Abschnitt 3), die versioniert, prüfbar und umkehrbar ist. Wir übergeben den Regelkatalog, die Dokumentation und die Konfigurationsoberfläche an Ihr Team und bleiben für wirklich neue Regeltypen sowie für gezielte Optimierungsfragen als Partner verfügbar, nicht als Voraussetzung des laufenden Betriebs.
Die Ausschreibung benennt einen fehlenden Baustein: eine automatisierte, vertrauenswürdige Berichterstattung zu Einsparungen und Verfügbarkeit für die verwaltungsinterne und politische Kommunikation. Das ist ein Kernbestandteil unserer Lösung, kein Zusatz. Da jeder Messwert und jede Steuerungsentscheidung gespeichert wird, ist jede berichtete Kennzahl auf die zugrunde liegenden Rohdaten zurückführbar und damit nachprüfbar.
Automatisierte Einsparungsberichte: Die Plattform berichtet den gemessenen Energieverbrauch fortlaufend gegen eine definierte Ausgangsbasis, je Straße, Abschnitt oder für das gesamte Netz. Die im Pilotprojekt Europabrücke dokumentierte Einsparung von über 70 Prozent wird so zu einer Größe, die das System laufend verfolgt und nachweist, statt zu einer einmaligen Studie.
Systemverfügbarkeit und Zustand: Neigungs- und Schwingungsereignisse, Sensorausfälle und Störungen werden erfasst, sodass die Verfügbarkeit automatisch berichtet wird und Störungen im Moment ihres Auftretens eskalieren.
Sensorauswertungen: Umweltdaten (Luftqualität, Lärm, Temperatur, Feuchte) und Verkehrsdaten stehen für Auswertungen sowie für die bürger- und verwaltungsorientierten Anwendungen bereit, die das SGC-Programm vorsieht.
Nachvollziehbarkeit der Steuerung: Jede getroffene Entscheidung ist protokolliert, einschließlich der Frage, welche Regel sich aus welchem Grund durchgesetzt hat. Damit ist nicht nur das Ergebnis, sondern auch das Verhalten des Systems dokumentiert.
Reporting- und Dashboard-Funktionen: Wir stellen sofort nutzbare Dashboards bereit (auf Basis von Grafana, einem offenen Standard) zu Energieeinsparung, Verfügbarkeit und Sensordaten, die nicht-technische Beteiligte direkt lesen können. Ansichten lassen sich je Zielgruppe gestalten (Betrieb, Verwaltung, Politik), und Berichte können für die politische und verwaltungsinterne Kommunikation exportiert werden. Da die Daten in offenen Formaten vorliegen, wird die Stadt nie von ihren eigenen Messungen ausgesperrt und kann jederzeit weitere Auswertungen darauf aufbauen.
Die folgenden Zahlen sind eine indikative, unverbindliche Einschätzung, wie von der Ausschreibung erbeten, auf Basis vergleichbarer Projekte. Der endgültige Umfang und die Preise werden je Beauftragung festgelegt.
Einmalige Implementierung und Beratung: rund 300.000 € einmalig. Umfasst die Integration mit Exedra, dem LoRa-Netz und den Sensordatenströmen, den Aufbau der Regel-Engine und des Vorlagenkatalogs sowie die Unterstützung bei Inbetriebnahme und Optimierung.
Software-Abonnement und Support: 200.000–300.000 € pro Jahr. Umfasst die verwaltete Plattform, den laufenden Support und die begleitete Optimierungsbeziehung.
Betriebsmodell: im Vorstehenden enthalten, ob öffentliche Cloud, stadteigenes Cloud-Konto oder On-Premises.
Warum das über den Lebenszyklus wirtschaftlich bleibt: Quix ergänzt lediglich eine Software-Ebene über den Sensoren und Leuchten, die Sie bereits von Ihren Partnern beziehen. Das vermeidet unnötige Produktvielfalt und hält die Beschaffung offen. Die Plattform beruht auf offenen Standards (Kafka, MQTT, offene Tabellen- und Dateiformate), und die Stadt besitzt ihren Code, ihre Konfiguration und ihre Daten, also keine Anbieterbindung. Die Betriebskosten skalieren mit der Stadt, nicht mit der Komplexität: Das Hinzufügen von Straßen oder Sensortypen ist Konfiguration und schrittweise Rechenleistung, nicht jedes Mal ein neues Projekt. Zugleich werden die Einsparungen, die das Programm rechtfertigen, laufend nachgewiesen und bleiben so Jahr für Jahr für Verwaltung und Politik sichtbar. Wie stark die langfristigen Kosten in sensorlastigen Systemen von der Datenverarbeitung bestimmt werden, zeigt ein vergleichbares Energieinfrastruktur-Projekt, in dem der Umstieg auf unseren offenen Daten-Stack die Speicherkosten bei gleichem Datenvolumen um den Faktor 100 senkte.
Übertragbarkeit auf andere Kommunen: Der Ansatz ist von Grund auf übertragbar. Die Architektur ist nicht an einen bestimmten Sensor- oder Leuchten-Hersteller gebunden, sondern integriert über offene Schnittstellen (MQTT, REST) das, was vor Ort vorhanden ist. Der Regelkatalog bildet eine wiederverwendbare Grundlage, die jede Kommune über Konfiguration an ihre Straßen, Schwellenwerte und Prioritäten anpasst, ohne dass die zugrunde liegende Logik neu gebaut werden muss. Die gleichen Bausteine (Sensorintegration, konfigurierbare Wenn-Dann-Logik, automatisierte Berichterstattung, sicherer Betrieb in der eigenen Cloud oder On-Premises) haben wir in unterschiedlichen Branchen und Ländern eingesetzt, von der Verkehrsbehörde einer Stadt über kritische Energieinfrastruktur bis zu einem regulierten Wasserversorger. Eine in Konstanz bewährte Lösung lässt sich damit als Vorlage auf weitere Städte ausrollen.
