73.000 Smart Meter fielen über Nacht aus — und die Firmware hatte jeden Labortest bestanden
Im November 2024 spielte ein Versorgungsunternehmen in Plano, Texas, ein routinemäßiges Firmware-Update auf 88.000 Wasserzähler auf. Das Update sollte eine vorzeitige Batterieentladung beheben — eine gut gemeinte Reparatur eines bekannten Problems. Im Labor funktionierte es. Im Feld fielen 73.000 Zähler aus und kamen nie wieder zurück.
Ich komme immer wieder auf diese Zahl zurück, wegen dessen, was sie impliziert. Das war kein Hack, kein Sturm und kein Fertigungsfehler. Es war ein Software-Update, das getestet und freigegeben worden war und sich genau wie vorgesehen verhielt — und trotzdem machte es 83 % einer Flotte unbrauchbar. Diese Kluft zwischen "hat das Labor bestanden" und "hat das Feld getötet" ist das ganze Problem bei Smart-Meter-KI, und deshalb entwickelten wir ein AMI-System für vorausschauende Wartung bei Veriprajna, das die Signale beobachtet, für deren Erfassung ein Analyse-Dashboard nie konzipiert wurde.
Als ich das erste Mal mit dem Betriebsleiter eines kommunalen Versorgers zusammensaß und mir ihr AMI-Head-End ansah — das System, das die Messwerte jedes Zählers sammelt —, erwartete ich einen Leitstand. Was ich bekam, war eine Tabellenkalkulation. Zeitstempel des letzten Kontakts, eine Zeile pro Zähler und ein langsames Durchscrollen von Zellen, die veralteten. Er konnte mir genau sagen, welche Zähler aufgehört hatten zu senden. Er konnte mir nicht sagen, welche als Nächstes ausfallen würden. Diese Asymmetrie — perfekter Rückblick, null Voraussicht — ist der gesamte Markt.
Warum macht Firmware, die das Labor besteht, das Feld unbrauchbar?
Folgendes ist in Plano tatsächlich passiert, und es ist die mit Abstand aufschlussreichste Geschichte in diesem Bereich.
Die Firmware wurde an Zählern mit frischen Batterien und starkem Funksignal getestet — ein sauberer Prüfstand. Doch die ausgerollte Flotte war vier bis fünf Jahre alt, und die meisten dieser Batterien lagen bei 60 bis 75 % ihrer ursprünglichen Kapazität. Die aktualisierten Energieverwaltungsroutinen zogen während des ersten Flash-Schreibvorgangs etwas mehr Strom. Bei einer neuen Batterie irrelevant. Bei einer verschlissenen reichte dieser Mehrverbrauch aus, um den Brownout-Schutz auszulösen. Die Übertragungsmodule setzten sich zurück, verloren ihre Netzwerkregistrierung und erholten sich nie wieder.
Die Firmware versagte nicht. Sie erfüllte die Spezifikation. Die Flotte war dem Prüfstand schlicht davongealtert, und niemand modellierte das.
Dieser Satz ist die These hinter allem, was wir bauen. Der Fehler lag nicht im Code. Er lag in der Annahme, dass ein Laborzähler und ein Feldzähler dieselbe Maschine sind. Das sind sie nicht, und der Unterschied summiert sich jahrelang lautlos, bevor jemand den Knopf drückt, der ihn offenlegt.
Diese Ausfälle treten gehäuft auf. Die Firmware desselben Herstellers hat ähnliche Vorfälle in Minneapolis, Toronto und New York verursacht. Toronto Hydro stellte fest, dass rund 470.000 Sender vorzeitig degradierten, und gab allein für die erste Sanierungsrunde 5,6 Millionen Dollar aus. Memphis verzeichnete eine systemische Ausfallrate von 8 % und richtete einen Reparaturfonds über 9 Millionen Dollar ein. Im Vereinigten Königreich funktioniert etwa jeder fünfte Smart Meter nicht so, wie er sollte; seit Juli 2024 wurden mehr als 600.000 wieder angeschlossen. Keinem dieser Versorger fehlte eine Analyseplattform. Sie alle hatten eine. Die Plattform beobachtete nur nicht das, was kaputtging.
Der Fehler, den ich viel zu lange verteidigt habe
Ich möchte ehrlich sein über die Version davon, die wir falsch gemacht haben, denn es ist der Teil, den die meisten überspringen.
Als wir anfingen, war der naheliegende Schritt die Anomalieerkennung. Ein Zähler, der kurz vor dem Ausfall steht, sollte auffallen — seltsam in seinen Daten: driftende Verbrauchswerte, Lücken in der Meldung, ungewöhnliche Muster. Also bauten wir ein Modell, das den Verbrauchsdatenstrom beobachtete und Anomalien markierte. Es war sauber. Es ließ sich hervorragend demonstrieren. Ich verteidigte es in einem Raum nach dem anderen.
Dann ließen wir es gegen eine echte Degradationswelle in einer Pilotflotte laufen, und es blieb grün, während darunter still und leise Zähler kaputtgingen. Ich erinnere mich an das genaue Gefühl, das Dashboard ruhig bleiben zu sehen und mir sicher zu sein, dass das Modell defekt war. Das Modell war nicht defekt. Ich hatte es auf das falsche Signal gerichtet.
Die Erkennung von Verbrauchsanomalien ist genau das, was die bestehenden Meter-Data-Management-Systeme bereits leisten. Oracle brachte im Juni 2025 KI-gestützte Anomalieerkennung für seine Versorgerplattform auf den Markt; SAP ist in dieser Kategorie ein IDC-MarketScape-Leader. Diese Werkzeuge sind gut in dem, was sie tun — sie erwischen einen Zähler, der seltsame Zahlen meldet. Das Problem ist, dass ein Zähler, der auf den Firmware-Tod zusteuert, keine seltsamen Zahlen meldet. Er meldet vollkommen normale Zahlen, bis zu dem Moment, in dem er gar nichts mehr meldet. Wir hatten das nachgebaut, was bereits existierte, und uns seinen blinden Fleck erneut eingehandelt.
Ein ausfallender Zähler sieht in seinen Verbrauchsdaten nicht krank aus. Er sieht gesund aus, dann ist er weg. Das Signal, das man braucht, liegt dort, wo der Abrechnungsdatenstrom nicht hinsehen kann.
Was das MDMS nicht sehen kann: Zwei Signale, die einen Ausfall wirklich vorhersagen
Die Wende kam, als wir aufhörten zu fragen "Ist dieser Messwert anomal?" und anfingen zu fragen "Was in einem Zähler verschleißt physisch, und können wir es messen, bevor es kaputtgeht?"
Zwei Antworten waren entscheidend.
Das erste ist der Ladezustand der Batterie, modelliert nach Einsatzkohorte statt als Flottendurchschnitt. Die Lehre aus Plano ist, dass ein Firmware-Rollout nur gegenüber einer bestimmten Verteilung des Batteriezustands gefährlich ist — und diese Verteilung ist erkennbar. Wenn man jeden Endpunkt nach Installationsdatum bündelt und Ladezustands-Histogramme pro Kohorte erstellt, kann man die Brownout-Klippe kommen sehen, bevor man überhaupt etwas flasht. Wir begannen, Firmware gegen das tatsächliche Alters- und Kapazitätsprofil der Flotte zu staffeln, nicht gegen einen Prüfstand voller neuer Geräte.
Das zweite ist der stille Verschleiß des NAND-Flash-Speichers, und dieses hat wirklich verändert, wie ich über die gesamte Kategorie denke. Smart Meter protokollieren Daten in den Flash-Speicher — jeden Messwert, jedes Ereignis, in 15-Minuten-Intervallen für das Demand Response. Jeder Schreibvorgang nutzt die Zellen physisch ab. Hersteller geben eine Lebensdauer von 20 Jahren an, doch die hochfrequente Protokollierung verbraucht Schreibzyklen weit schneller, als jene Prognosen annahmen. Und hier ist der heimtückische Teil: Während der Flash-Speicher degradiert, driften die gespeicherten Verbrauchswerte um 2 bis 8 %, während der Zähler weiterhin normal meldet. Das Funkmodul sendet weiterhin. Das MDMS zeigt einen gesunden, kommunizierenden Endpunkt. Unterdessen sind die Zahlen still und leise falsch, Abrechnungsstreitigkeiten häufen sich, und das öffentliche Vertrauen erodiert — und wenn der Zähler schließlich völlig verstummt, ist der Flash-Speicher zu stark degradiert, um überhaupt noch einen korrigierenden Firmware-Fix anzunehmen. Diese Einheit braucht einen Einsatzwagen und einen Austausch für 650 bis 1.400 Dollar pro Stück.
So können die Spalte "Zähler meldet" des Dashboards und seine Spalte "Datenqualität" monatelang widersprüchlich sein, und fast niemand liest die zweite. Wir haben den Widerspruch zwischen diesen beiden zum lautesten Alarm im System gemacht.
"Oracle macht das doch schon. Warum baut ihr es?"
Ein Berater, den ich schätze, brachte es früh unverblümt auf den Punkt: Der Analysemarkt ist überfüllt, die etablierten Anbieter sind ernst zu nehmen, warum also bauen?
Das ist eine berechtigte Frage, und die ehrliche Antwort ist, dass sich die etablierten Anbieter um ein anderes Problem drängen. Itrons Distributed-Intelligence-Plattform ist wirklich beeindruckend — über 16 Millionen aktivierte Zähler, über 100 Millionen verwaltete Endpunkte, eine Partnerschaft mit NVIDIA vom März 2026, um KI am Netzrand auszuführen. Landis+Gyrs Revelo betreibt in Zusammenarbeit mit Sense eine geräteweise Lastaufschlüsselung bei 1 Megahertz. Sensus brachte Anfang 2026 Evolve auf den Markt, um Zähler als aktive Netzsensoren neu zu positionieren. Die gesamte Branche bewegt sich — offiziell gemacht durch das Motto der DistribuTECH 2026 — "von AMI zu KI".
Doch jeder dieser Analyse-Stacks funktioniert nur mit den eigenen Endpunkten des jeweiligen Herstellers. Itrons Intelligenz sieht Itron-Zähler. Die von Landis+Gyr sieht Landis+Gyr. Echte Versorger betreiben gemischte Flotten, angewachsen über ein Jahrzehnt von Beschaffungszyklen — teils Aclara, teils Itron, teils Sensus —, und die Analytik keines einzelnen Herstellers deckt sie alle ab. Und keine von ihnen, proprietär oder nicht, bietet eine Firmware-Simulation vor dem Rollout gegen Ihre spezifische, gealterte Flotte. Die Lücke, die Plano unbrauchbar machte, ist strukturell herrenlos.
Die etablierten Anbieter sagen Ihnen, dass ein Zähler meldet. Die OT-Sicherheitswerkzeuge sagen Ihnen, dass er verwundbare Firmware ausführt. Keines von beiden sagt Ihnen, dass er drei Monate von einem Hardware-Tod entfernt ist.
Die Sicherheitsanbieter sind hier erwähnenswert, weil man annimmt, dass sie das abdecken. Claroty, Nozomi, Armis — sie leisten hervorragende Asset-Erkennung, bis hinunter zur Firmware-Version jedes Endpunkts, und sie verstehen die Industrieprotokolle. Doch sie sind darauf ausgelegt, den Zähler zu finden, der einen ausnutzbaren Firmware-Build ausführt, nicht den Zähler, dessen Batteriekohorte den nächsten Flash-Schreibvorgang nicht überlebt. Wartung und Sicherheit betrachten dasselbe Gerät und stellen unterschiedliche Fragen. Wir brauchten die Wartungsfrage, und sie wurde nicht gestellt.
Der Prüfstand, auf dem Firmware absichtlich scheitern soll
Das Element, auf das ich am stolzesten bin, ist das unspektakulärste: ein Emulationsprüfstand, auf dem Firmware scheitert, bevor sie den Zähler eines Kunden erreicht.
Wir richten eine QEMU-Umgebung ein — Software, die die tatsächliche Hardware des Zählers emuliert — und flashen ein Firmware-Kandidatenimage gegen simulierte Endpunkte, die die realen Batterie- und Signalprofile der Flotte tragen. Die Kohorte mit verschlissener Batterie, die Kohorte mit schwachem HF-Signal, die Kohorte mit hoher Schreibzyklenzahl. In der ersten Nacht, in der wir ein auf einer gealterten Flotte modelliertes Profil laufen ließen und die emulierte Einheit genau so einbrechen sahen, wie es das Feld tut und das Labor nie, verstand ich endlich, dass Plano kein Zufall war. Es war reproduzierbar. Es war nur nie reproduziert worden, vor dem Rollout, weil die Testumgebung nicht existierte.
Das ist die Umkehrung. Heute ist das Feld die Testumgebung, und die Kunden sind die Testpersonen. Wir verlagern den Ausfall in ein Labor, in dem es nichts kostet, tausend simulierte Zähler unbrauchbar zu machen, und in dem man alles lernt.
Bedeutet vorausschauende Wartung nicht einfach mehr Fehlalarme?
Der Einwand, den ich am häufigsten von Betriebsleuten höre — jenen, die sich an Werkzeugen die Finger verbrannt haben, die falschen Alarm schlagen — ist, dass Vorhersage nur eine schickere Art ist, Rauschen zu erzeugen.
Das ist die richtige Sorge. Ein Gesundheits-Scoring-Modell, das jede Woche 30 % Ihrer Flotte markiert, ist schlimmer als nutzlos; die Teams lernen, es zu ignorieren, und Sie haben Budget ausgegeben, um genau die Alarmmüdigkeit neu zu erschaffen, mit der Sie begonnen haben. Also kalibrierten wir gegen Kosten, nicht gegen Anomaliezahlen. Der Maßstab war nicht "wie viele Ausfälle haben wir erwischt", sondern "wie viele Einsatzfahrten haben wir verhindert im Verhältnis zu denen, die wir ausgelöst haben." Branchendaten zur KI-gestützten vorausschauenden Wartung deuten auf bis zu 30 % Senkung der Wartungskosten und spürbare Reduzierungen der Ausfallzeiten hin, wenn sie gegen das richtige Signal erfolgt — und das richtige Signal ist, noch einmal, physischer Verschleiß, nicht Datenkuriositäten. Eine Vorhersage, die keine Dispositionsentscheidung ändert, ist keine Vorhersage. Sie ist eine Benachrichtigung. Das ist, denke ich, der Grund, warum so viele Versorger KI-Wartung pilotieren und dann steckenbleiben — BCGs Versorgerarbeit von 2026 benennt die Lücke zwischen Pilot und Produktion ausdrücklich — sie weisen nach, dass ein Modell Ausfälle markieren kann, können den Rollout dann aber nicht rechtfertigen, weil die Markierungen nie mit einer Disposition verknüpft waren, der ein Einsatzleiter tatsächlich vertrauen würde.
Firmware-Management ist gerade zu einem Compliance-Dokument geworden
Hier gibt es eine regulatorische Wende, die viele Versorger meiner Meinung nach noch nicht ganz verinnerlicht haben, und sie erhöht den Einsatz erheblich.
Seit dem 1. April 2026 ist NERC CIP-003-9 in Kraft. Dessen Anforderung R1, Teil 1.2.6, schreibt Sicherheitskontrollen für den Fernzugriff von Anbietern auf Grid-Cyber-Systeme mit geringer Auswirkung vor — als solche werden die meisten Smart Meter eingestuft. Im Klartext: Der Over-the-Air-Update-Pfad, über den Sie Firmware ausspielen, ist nun eine regulierte Kontrolloberfläche, und die Strafen bei Fehlern belaufen sich auf bis zu 1 Million Dollar pro Tag. Derselbe OTA-Kanal, der Plano unbrauchbar machte, ist nun auch ein Compliance-Artefakt, für das Sie Nachweise erbringen müssen.
Das verändert das Käufergespräch völlig. Firmware-Management war früher eine Betriebsaufgabe. Jetzt landen die Zugriffsprotokolle, die Staging-Aufzeichnungen, die Rollback-Verfahren in einem Ordner, den ein Prüfer liest. Ein System, das Firmware vor dem Rollout validiert, verhindert nicht mehr nur Ausfälle; es erzeugt den Nachweis, dass Sie den Update-Pfad verantwortungsvoll verwaltet haben.
Darunter liegt ein leiserer Standard, nach dem Beschaffungsteams fragen und auf den sie selten eine klare Antwort erhalten: IEC 62443, der Standard für industrielle Cybersicherheit bei AMI. Nur sehr wenige Zählerhersteller haben eine vollständige IEC-62443-Zertifizierung auf Komponentenebene angestrebt — die Firmware selbst. Die meisten zertifizieren auf Systemebene und lassen die Endpunkt-Firmware unzertifiziert, was bedeutet, dass genau die Schicht, die Plano unbrauchbar machte, auch die Schicht mit der dünnsten Sicherheitsbescheinigung ist. Diese Lücke ist der Grund, warum wir Sicherheitsaudits auf Komponentenebene über gemischte AMI-Lieferketten hinweg durchführen, nicht nur am Head-End. Auf der anderen Seite des Atlantiks schreiben die Ofgem-Standards des Vereinigten Königreichs nun eine automatische Entschädigung vor — 40 £ pro Fall — für Zählerausfälle durch Lieferantenverschulden, ausgezahlt innerhalb von 10 Werktagen. Die Kosten eines toten Zählers sind nicht mehr nur die Einsatzfahrt. Es sind die Geldstrafe, die Entschädigung und die Prüfungsfeststellung.
Was ich dem Betriebsleiter mit dem veralteten Dashboard sagen würde
Wenn ich jetzt zu jener Tabelle veralteter Zeitstempel zurückkehren würde, würde ich Folgendes sagen.
Die Zahl, die Ihnen den Schlaf rauben sollte, sind nicht die Zähler, die bereits verstummt sind. Es sind die 29 % — der Anteil der Endpunkte, von denen einige Versorger feststellten, dass sie lautlos ausgefallen waren, mit toten Funkmodulen, ohne dass je ein Alarm ausgelöst wurde, und die erst auffielen, als jemand nachsah. Ihre Plattform lügt Sie nicht an. Sie beantwortet eine engere Frage als die, die Sie tatsächlich haben. Sie weiß, wer aufgehört hat zu senden. Sie müssen wissen, wer kurz davor ist.
Der Smart-Meter-Markt steuert bis 2035 auf 112 Milliarden Dollar zu, und der installierte Bestand in Nordamerika liegt bereits über 150 Millionen Einheiten. Jeder dieser Endpunkte ist ein kleiner Computer mit einer alternden Batterie und einem verschleißenden Flash-Chip, der an der Seite eines Gebäudes sitzt und auf einen Firmware-Rollout wartet, der irgendwo getestet wurde, wo er nicht lebt. Das nächste Plano ist bereits vorbereitet. Die einzige offene Frage ist, ob jemand die Flotte modelliert hat, auf der es gleich landen wird. Wenn Sie es lieber auf einem Prüfstand als an den Wänden von 73.000 Kunden herausfinden möchten, dann ist das das System, das man bauen sollte.
Die Firmware, die Plano unbrauchbar machte, bestand jeden Test, den man ihr gab. Wir gaben ihr nur nie den richtigen.
