IoT Energy
Monitoring von Hochspannungsleitungen — von den Sensoren im Feld zu einer Plattform
Ein nordamerikanischer Hersteller von Armaturen für Freileitungen brauchte eine Plattform, die die Sensoren auf seinen Hochspannungsleitern in etwas verwandelt, mit dem Netzbetreiber arbeiten können. Cloudnonic hat sie 2026 von Ende zu Ende gebaut: Ingestion, Datenebene, API, Webanwendung und die AWS-Infrastruktur darunter, mit einem Engineering-Team.366+
Auf der Plattform registrierte FeldgeräteBeschleunigungssensoren, IMUs, Wetterstationen und mehr21+
Überwachte FreileitungenFür Netzbetreiber in Nordamerika und Europa13+
Netzbetreiber und Partner mit eigenem MandantenJeweils mit eigenen Nutzern, Rollen, Leitungen und Alarmen5+
Sensortypen mit eigener VerarbeitungsketteVom Rohdatenpaket zur technischen KennzahlJahr2026 – Laufend
StandortVereinigte Staaten
TechnologienFastAPI · React · PostgreSQL · AWS Lambda · Terraform
UmfangCloud-Infrastruktur · Plattform-Engineering · Full-Stack-Entwicklung · Daten und Analyse
Das Problem
Der Kunde stellt die Armaturen her, die Hochspannungsleitungen tragen: Klemmen, Dämpfer, Abstandhalter. Über die Jahre kamen Sensoren hinzu — Beschleunigungs- und Inertialsensoren am Leiterseil, Biegedehnungsaufnehmer, Wetterstationen an den Masten —, damit Netzbetreiber sehen, wie sich eine Leitung bei Wind, Eis und Last verhält.Die Sensoren funktionierten. Was fehlte, war die Plattform dahinter. Die Daten erreichten die Gateways und blieben dort; jeder Netzbetreiber war eine eigene Installation, und es gab keinen Ort, an dem Flottenzustand, Leitungsstatus oder ein Alarm sichtbar wurden, sobald sich ein Leiterseil außerhalb seiner Grenzen bewegte.Gefragt war ein Produkt, kein Projekt: mandantenfähig vom ersten Tag an, White-Label, damit der Hersteller es unter eigener Marke verkaufen kann, und in der Lage, Wellenform-Pakete von Hunderten Geräten aufzunehmen, ohne einen Messwert zu verlieren.Was wir gebaut haben
Eine Webanwendung, in der Leitungen, Spannfelder und Anlagen auf einer Karte liegen; jedes Gerät ist einem Spannfeld zugeordnet, sein Verbindungsstatus auf einen Blick sichtbar. Organisationen, Nutzer und Rollen geben jedem Netzbetreiber einen eigenen Mandanten; Regeln und Alarme informieren die richtigen Personen, sobald ein Messwert einen Schwellwert überschreitet.Über den Rohdaten liegen Dashboards je Sensorfamilie: Beschleunigungskennzahlen mit X-, Y- und Z-Wellenformen und ihren FFT-Spektren, Biegedehnungsanalyse, Bewegung von Leiterseil und Dämpfer, Wetterstationsdaten und ein flottenweiter Systemcheck. Jedes Dashboard lässt sich nach Organisation, Leitung, Anlage und Gerät filtern, jedes Diagramm exportieren.Die Anwendung ist übersetzt, anpassbar im Erscheinungsbild und wird als statische Single-Page-App hinter einem CDN ausgeliefert — ein neuer Netzbetreiber ist eine Konfigurationsänderung, kein Deployment.Ingestion für Lastspitzen
Gateways im Feld streamen nicht; sie wachen auf, schicken ein mehrere Megabyte großes Paket und werden wieder still. Genau deshalb ist der Ingestion-Pfad serverlos: eine HTTP-API und eine MQTT-Bridge nehmen die Pakete an, Lambda-Funktionen validieren und zerlegen sie, und FIFO-Queues übergeben jeden Sensortyp an seine eigene Verarbeitungskette — mit Dead-Letter-Queue und Replay für alles, was fehlschlägt.Rohe Wellenform-Pakete werden beim Eintreffen archiviert, stundenweise partitioniert, sodass sich jede Kennzahl später aus den Originalmesswerten neu berechnen lässt. Verarbeitete Messwerte landen in einer für Zeitreihen partitionierten PostgreSQL-Datenebene, die die API über eine eigene Rolle liest.Die Kalibrierung lebt im Katalog des jeweiligen Gerätetyps; ein neues Sensormodell bedeutet einen neuen Eintrag und eine Verarbeitungskette — keine neue Plattform.Verantwortung für die Infrastruktur
Alles läuft auf AWS und ist in Terraform definiert: das Netzwerk, ein Fargate-Cluster für den FastAPI-Kern, RDS PostgreSQL und Redis in privaten Subnetzen, Cognito mit Multi-Faktor-Authentifizierung, KMS-Schlüssel, Secrets Manager mit rotierten Datenbankrollen und CloudFront vor der Anwendung.Jedes Repository veröffentlicht in eigenem Takt mit generiertem Changelog, die Umgebungen sind voneinander isoliert, und der Kunde nimmt auf Staging ab, bevor etwas in Produktion geht. Seit dem Go-live läuft die Plattform unter einem Wartungsvertrag mit definiertem Service-Level.Wie wir mit dem Kunden arbeiten
Das Projekt läuft über ein gemeinsames Planungs-Repository: Domänenmodell, Architekturentscheidungen, Standards und ein Backlog, das der Kunde lesen kann. Entscheidungen werden festgehalten, sobald sie fallen — wer sechs Monate später prüft, findet die Begründung, nicht nur den Code.Cloudnonic verantwortet das Engineering über die vier Repositories — Frontend, Kern-API, Ingestion und Infrastruktur —, während der Kunde Produktrichtung, Abnahme und die Geschäftsbeziehung zu den Netzbetreibern auf der Plattform verantwortet.Ergebnis
- Hunderte Feldgeräte auf mehr als zwanzig Freileitungen melden in eine Plattform
- Schwingungs-Wellenformen werden zu Kennzahlen, die ein Leitungsingenieur in Sekunden liest
- Mandantenfähig vom ersten Tag: jeder Netzbetreiber sieht nur seine Leitungen, Geräte und Alarme
- White-Label, damit der Hersteller die Plattform unter eigener Marke verkauft
- Rohdaten stundenweise archiviert und jederzeit neu verarbeitbar
- Abnahme auf Staging je Release und Wartungsvertrag nach dem Go-live