Wie KRONYX funktioniert: Von der Sensorregistrierung bis zur Live-Datenbereitstellung

Ingest – Normalize – Process in real time

How KRONYX Works header

Wie KRONYX funktioniert: Von der Sensorregistrierung bis zur Live-Datenbereitstellung

Organisationen, die Sensoren einsetzen – sei es für Submetering, Logistik, Umweltüberwachung oder kommunale Infrastruktur – stehen alle vor derselben strukturellen Frage:

Wie gelangen Telemetriedaten von der Feldhardware in eine zuverlässige, regelkonforme und skalierbare Verarbeitungsumgebung, ohne langfristige operative Belastungen zu verursachen?

KRONYX wurde entwickelt, um diese Frage aus Kundensicht zu beantworten. Unabhängig davon, ob Daten über Gateways, direkte API-Uploads oder hybride Bereitstellungen eingehen, bleibt das operative Modell konsistent.

Dieser Artikel erläutert, wie Kunden Geräte registrieren, Deployments onboarden und auf Daten zugreifen können – ohne selbst einen Telemetrieprozessor intern betreiben zu müssen.

1. Kontoinitialisierung und Zugriffsstruktur

Jeder Kunde arbeitet innerhalb eines dedizierten Account-Namespace.

Der Zugriff ist rollenbasiert und granular definiert, sodass Benutzer ausschließlich mit ihren zugewiesenen Deployments interagieren. Daten sind logisch pro Account getrennt. Es gibt keine mandantenübergreifende Sichtbarkeit.

KRONYX agiert ausschließlich als Auftragsverarbeiter. Der Kunde bleibt Verantwortlicher im Sinne der DSGVO.

Die gesamte Verarbeitung und Speicherung erfolgt innerhalb der Europäischen Union und ist an die Verpflichtungen eines DSGVO-Auftragsverarbeiters sowie an EU-Datenresidenzanforderungen ausgerichtet.

Diese Trennung stellt sicher, dass Kunden die volle Eigentümerschaft und Kontrolle über ihre Geschäftslogik, Abrechnungssysteme und Kundenbeziehungen behalten.

2. Massen-Onboarding mit strukturiertem CSV-Upload (DataBoss-Modell)

Große Deployments erfordern ein strukturiertes Onboarding.

Anstatt hunderte oder tausende Geräte manuell zu registrieren, laden Kunden eine strukturierte CSV-Datei über die KRONYX-Onboarding-Schnittstelle hoch.

Die CSV-Datei enthält:

  • Gateway-Identifikatoren
  • Sensor-Identifikatoren
  • Protokolltyp
  • Optionale Metadaten (Gebäudereferenz, Einheit, Asset-Gruppe, Mieterpseudonym)
  • Deployment-Zuordnung

Nach dem Upload:

  • Validiert das System die Einträge
  • Werden für jedes Gateway und jeden Sensor automatisch Zugangsdaten generiert
  • Werden eindeutige Authentifizierungstoken zugewiesen, sofern erforderlich
  • Werden Datensätze mit systemgenerierten Metadaten angereichert

Die Rückgabedatei ist dieselbe CSV-Datei – nun ergänzt um zugewiesene Zugangsdaten und interne Identifikatoren.

Dieser Ansatz ermöglicht es Betreibern, Onboarding in großem Maßstab durchzuführen und gleichzeitig eine deterministische Geräteidentität sicherzustellen.

Es werden zwei Zugangsdaten-Strategien unterstützt:

1. Gerätebezogene Zugangsdaten

Jedes Gateway oder jeder Sensor erhält individuelle Authentifizierungsdaten.

Dies ermöglicht detailliertes Performance-Logging, gerätespezifische Nachvollziehbarkeit und präzise Diagnosen.

2. Account-basierte Zugangsdaten

Ein gemeinsames Authentifizierungsmodell vereinfacht Deployment und operative Verwaltung.

Das Logging ist weniger granular, die Administration jedoch deutlich schlanker.

Kunden wählen das Modell entsprechend ihrer operativen Anforderungen.

Die Massen-Ingestion ist speziell für hochvolumige Umgebungen ausgelegt.

3. Gateway-basierte vs. direkte Sensor-Deployments

KRONYX unterstützt mehrere Ingestion-Modelle, das operative Verhalten bleibt jedoch identisch.

Gateway-basierte Deployments

Kunden registrieren Gateways über das CSV-Onboarding.

Gateways authentifizieren sich mit den zugewiesenen Zugangsdaten und beginnen mit der Weiterleitung von Telemetriedaten. Gateway-Performance, Verfügbarkeit und Nachrichtenfluss können je nach gewählter Zugangsdatenstrategie überwacht werden.

Direkte Sensor-zu-API-Deployments

Für Geräte mit sicherer Direktanbindung:

  • Authentifizieren sich Sensoren gegen dedizierte Ingestion-Endpunkte
  • Werden Nachrichten über gesicherte API-Anfragen übermittelt
  • Ist kein zwischengeschaltetes Gateway erforderlich

Unabhängig vom Ingestion-Pfad werden Geräteeinträge aktualisiert und Daten identisch weiterverarbeitet.

Die gewählte Ingestion-Methode verändert weder Verarbeitung noch Auslieferung der Daten.

4. Was geschieht beim Eingang von Daten

Wenn ein Sensor oder Gateway Telemetriedaten übermittelt:

  • Wird der zugehörige Geräteeintrag aktualisiert
  • Werden die eingehenden Daten gespeichert
  • Prüft die konfigurierte Alarmlogik definierte Schwellenwerte
  • Erhalten abonnierte Systeme unmittelbar Updates

Aus Kundensicht ist das Verhalten klar strukturiert:

Daten treffen ein.
Datensätze werden aktualisiert.
Live-Abonnenten werden benachrichtigt.
Historische Daten bleiben abrufbar.

Es ist nicht erforderlich, dass der Kunde Queues, Broker oder Skalierungsmechanismen selbst verwaltet.

5. Live-Bereitstellung und Datenzugriffsmodelle

KRONYX verfolgt einen API-First-Ansatz. Eine verpflichtende Frontend-Ebene existiert nicht.

Kunden greifen über drei primäre Modelle auf Daten zu:

1. Live-Streaming (Push-Modell)

Für Systeme mit unmittelbarem Aktualisierungsbedarf:

  • Stellen WebSocket-Feeds Echtzeit-Nachrichtenströme bereit
  • Ermöglicht MQTT-Forwarding mandantenisolierte Telemetrieströme
  • Können entfernte Systeme ereignisgesteuerte Payloads empfangen

Alle Live-Abonnenten erhalten Updates während der Verarbeitung.

Dies ermöglicht:

  • Synchronisierung von Abrechnungssystemen
  • ERP-Integration
  • Monitoring-Dashboards
  • Externe Alarmierungsmechanismen

Live-Bereitstellung erfordert kein Polling.

2. On-Demand-Abruf (Pull-Modell)

Kunden können abfragen:

  • Aktuelle Gerätewerte
  • Historische Zeiträume
  • Verbrauchsdifferenzen
  • Gateway-Performance-Daten

Alle Endpunkte sind über REST-APIs zugänglich.

Dieses Modell eignet sich für:

  • Periodische Abrechnungserstellung
  • Audit-Exporte
  • Compliance-Prüfungen
  • Interne Analysen
  • Standortbasierte Nachverfolgung
  • Temperatur- oder Umweltüberwachung und Alarmierung

3. Eigene UI-Entwicklung

KRONYX schreibt kein Frontend vor. (In Vorbereitung)

Kunden können:

  • Eigene Dashboards entwickeln
  • In bestehende Anwendungen integrieren
  • Mobile oder Web-Oberflächen erstellen
  • Interne BI-Tools nutzen

Es bestehen keine Lizenzbeschränkungen für Entwicklungen auf Basis der API-Ebene.

Die Verarbeitung bleibt ausgelagert, während Präsentation und Benutzeroberfläche vollständig unter Kundenkontrolle stehen.

6. Reporting und regulatorische Ausrichtung

KRONYX unterstützt strukturierte Reporting-Workflows, darunter:

  • Delta-basierte Verbrauchsberichte
  • Zeitraum-Exporte
  • CSV-Extraktion
  • Cold-Archive-Abrufe bei Bedarf

Datenaufbewahrungsrichtlinien sind konfigurierbar und an regulatorische Anforderungen angepasst.

Verantwortliche erhalten Zugriff auf Protokolle und Audit-Trails.

Sensible Identifikatoren werden gemäß den Verpflichtungen eines DSGVO-Auftragsverarbeiters pseudonymisiert oder verschlüsselt.

Compliance ist strukturell verankert, nicht rein prozessual.

7. Operative Segmentierung nach Unternehmensgröße

Obwohl Onboarding- und Bereitstellungsmodell für alle Kunden identisch sind, unterscheidet sich der strategische Nutzen je nach Skalierung.

Hochvolumige Betreiber (100.000+ Sensoren)

Für Organisationen auf nationaler oder regionaler Ebene:

  • Erfordert Telemetrie-Wachstum keine interne Plattformerweiterung
  • Keine DevOps-Skalierungskurve abhängig von der Geräteanzahl
  • Keine Infrastruktur-Duplizierung über Regionen hinweg
  • Gateway-Identität und Logging bleiben strukturiert und auditierbar
  • Datenresidenz verbleibt innerhalb der EU

Feldoperationen bleiben unverändert.

Verarbeitungskomplexität wird ausgelagert, ohne Kontrollverlust.

Wachstum wird operativ, nicht infrastrukturell bestimmt.

Kleine und mittelständische Betreiber

Für kleinere Deployments:

  • Keine Notwendigkeit, ein eigenes Telemetrie-Backend zu entwickeln oder zu betreiben
  • Kein brokerlastiger Stack
  • Kein Infrastruktur-Monitoring-Aufwand
  • Kein Aufbau eigener Compliance-Architektur
  • Planbare Kosten pro Gerät

Organisationen können drahtlose Sensorik einsetzen, ohne sich zu einem Plattformentwicklungsunternehmen entwickeln zu müssen.

Verarbeitung wird zur Service-Ebene – nicht zur dauerhaften internen Belastung.

8. Was KRONYX nicht ersetzt

KRONYX ersetzt nicht:

  • Installationsteams
  • Kundenbeziehungen
  • Abrechnungssysteme
  • CRM-Plattformen
  • Markenidentität

Es ersetzt nur eine Verantwortung:

Den internen Betrieb einer hochfrequenten Telemetrie-Verarbeitungsschicht.

Kunden behalten die Souveränität über ihre Geschäftsprozesse und delegieren lediglich die technische Disziplin von Ingestion, Speicherung und strukturierter Auslieferung.

9. Strategische Perspektive

In vielen Sensor-Deployments existieren drei Disziplinen nebeneinander:

  1. Feldinstallation
  2. Kundenservice und Abrechnung
  3. Telemetrie-Verarbeitungsinfrastruktur

Die ersten beiden sind geschäftliche Differenzierungsmerkmale.

Die dritte ist eine infrastrukturelle Spezialisierung.

KRONYX ermöglicht eine klare Trennung dieser Rollen.

Sensoren können skalieren.
Gateways können erweitert werden.
Verträge können wachsen.

Ohne dass die Backend-Verarbeitung zur organisatorischen Einschränkung wird.

Telemetrie-Wachstum bringt eine architektonische Entscheidung mit sich, die viele Organisationen aufschieben.

Die Installation von Zählern, die Bereitstellung von Hardware und das Management von Kundenbeziehungen sind etablierte Disziplinen – operativ, vertraglich und serviceorientiert.

Der Betrieb einer großskaligen digitalen Verarbeitungsschicht ist hingegen eine eigenständige Disziplin. Sie umfasst sichere Ingestion, Credential-Management, Developer Operations, Audit-Ausrichtung und Infrastruktur-Skalierung – Verantwortlichkeiten, die typischerweise mit Cloud-Service-Anbietern verbunden werden.

Für Hersteller, Zählerlieferanten und Servicebetreiber ist die strategische Frage daher nicht mehr rein technischer Natur. Sie ist strukturell.

Sind wir ein Hardware- und Serviceunternehmen, das digitale Verarbeitung nutzt – oder entwickeln wir uns aus Notwendigkeit zu einem Cloud-Infrastrukturbetreiber?

Nicht jedes Unternehmen muss beide Disziplinen beherrschen.

Die Unterscheidung wird entscheidend, sobald Skalierung an Dynamik gewinnt.

Scroll to top