73.000 slimme meters vielen 's nachts uit — en de firmware had elke labtest doorstaan

In november 2024 stuurde een nutsbedrijf in Plano, Texas een routinematige firmwareupdate naar 88.000 watermeters. De update moest voortijdige batterijontlading verhelpen — een reparatie te goeder trouw van een bekend probleem. In het lab werkte het. In het veld vielen 73.000 meters uit en kwamen nooit meer terug.

Ik blijf terugkomen op dat getal vanwege wat het impliceert. Dit was geen hack, geen storm en geen fabricagefout. Het was een software-update die getest en goedgekeurd was en zich precies gedroeg zoals ontworpen — en toch legde die 83% van een vloot lam. Die kloof tussen "door het lab gekomen" en "het veld gedood" is het hele probleem bij AI voor slimme meters, en daarom bouwden we een AMI-systeem voor voorspellend onderhoud bij Veriprajna dat let op de signalen die een analyticsdashboard nooit ontworpen was om te zien.

De eerste keer dat ik samen met het operationeel hoofd van een gemeentelijk nutsbedrijf naar hun AMI-head-end keek — het systeem dat metingen van elke meter verzamelt — verwachtte ik een controlekamer. Wat ik kreeg, was een spreadsheet. Timestamps van het laatst gehoorde signaal, één rij per meter, en een traag voortschuivende lijst van cellen die verouderen. Hij kon me precies vertellen welke meters gestopt waren met communiceren. Hij kon me niet vertellen welke als volgende zouden uitvallen. Die asymmetrie — perfect achteraf inzicht, nul vooruitzicht — is de hele markt.

Waarom legt firmware die door het lab komt het veld lam?

Dit is wat er echt gebeurde in Plano, en het is veruit het nuttigste verhaal in dit vakgebied.

De firmware was getest tegen meters met verse batterijen en een sterk radiosignaal — een schone testbank. Maar de uitgerolde vloot was vier tot vijf jaar oud, en de meeste van die batterijen zaten op 60 tot 75% van hun oorspronkelijke capaciteit. De bijgewerkte energiebeheerroutines trokken tijdens de eerste flash-schrijfbewerking iets meer stroom. Op een nieuwe batterij: irrelevant. Op een verzwakte: die extra stroomafname was genoeg om de onderspanningsbeveiliging te laten inschakelen. De zendmodules resetten, verloren hun netwerkregistratie en herstelden nooit meer.

De firmware faalde niet. Ze voldeed aan de specificatie. De vloot was simpelweg onder de testbank vandaan verouderd, en niemand modelleerde dat.

Die zin is de kernstelling van alles wat we bouwen. Het defect zat niet in de code. Het zat in de aanname dat een labmeter en een veldmeter dezelfde machine zijn. Dat zijn ze niet, en het verschil stapelt zich jarenlang stilletjes op voordat iemand op de knop drukt die het blootlegt.

Deze storingen komen in clusters voor. De firmware van dezelfde leverancier heeft vergelijkbare incidenten veroorzaakt in Minneapolis, Toronto en New York. Toronto Hydro ontdekte dat ruwweg 470.000 zenders vroegtijdig degradeerden en gaf alleen al aan de eerste ronde herstelwerk $5,6 miljoen uit. Memphis had een systemisch uitvalpercentage van 8% en richtte een reparatiefonds van $9 miljoen op. In het VK werkt ongeveer één op de vijf slimme meters niet zoals het hoort; meer dan 600.000 zijn sinds juli 2024 opnieuw aangesloten. Geen van deze nutsbedrijven ontbeerde een analyticsplatform. Ze hadden er allemaal een. Het platform lette alleen niet op datgene wat kapotging.

De fout die ik veel te lang bleef steunen

Ik wil eerlijk zijn over de versie hiervan die we verkeerd deden, want het is het stuk dat de meeste mensen overslaan.

Toen we begonnen, was de voor de hand liggende zet anomaliedetectie. Een meter die op het punt staat te falen zou er moeten uitzien als iets vreemds in zijn data — verbruiksmetingen die afdrijven, gaten in de rapportage, vreemde patronen. Dus bouwden we een model dat de verbruiksstroom bewaakte en anomalieën markeerde. Het was strak. Het deed het prachtig in demo's. Ik verdedigde het in de ene kamer na de andere.

Toen lieten we het los op een echte degradatiegolf in een pilotvloot, en het bleef daar groen staan terwijl er onder zijn neus stilletjes meters kapotgingen. Ik herinner me het specifieke gevoel dat ik het dashboard rustig zag blijven en er zeker van was dat het model kapot was. Het model was niet kapot. Ik had het op het verkeerde signaal gericht.

Detectie van verbruiksanomalieën is precies wat de bestaande Meter Data Management Systems al doen. Oracle leverde in juni 2025 AI-gestuurde anomaliedetectie voor zijn utilities-platform; SAP is een IDC MarketScape-leider in de categorie. Deze tools zijn goed in wat ze doen — ze betrappen een meter die vreemde getallen rapporteert. Het probleem is dat een meter die afstevent op firmwaredood geen vreemde getallen rapporteert. Ze rapporteert volkomen normale getallen, tot op het moment dat ze niets meer rapporteert. We hadden datgene wat al bestond opnieuw gebouwd en de blinde vlek ervan opnieuw geërfd.

Een falende meter ziet er in zijn verbruiksdata niet ziek uit. Ze ziet er gezond uit, en dan is ze weg. Het signaal dat je nodig hebt, leeft ergens waar de facturatiestroom niet kan komen.

Wat de MDMS niet kan zien: twee signalen die falen echt voorspellen

De ommekeer kwam toen we stopten met de vraag "is deze meting afwijkend?" en begonnen te vragen "wat slijt er fysiek in een meter, en kunnen we dat meten voordat het kapotgaat?"

Twee antwoorden deden ertoe.

Het eerste is de laadtoestand van de batterij, gemodelleerd per uitrolcohort in plaats van als vlootgemiddelde. De les van Plano is dat een firmwarepush alleen gevaarlijk is tegen een bepaalde verdeling van batterijgezondheid — en die verdeling is kenbaar. Als je elk eindpunt indeelt op installatiedatum en per cohort histogrammen van de laadtoestand opbouwt, kun je de onderspanningsklif zien aankomen voordat je iets flasht. We begonnen firmware te beproeven tegen het werkelijke leeftijd-en-capaciteitsprofiel van de vloot, niet tegen een testbank vol nieuwe eenheden.

Het tweede is de stille slijtage van het NAND-flashgeheugen, en dit veranderde echt hoe ik over de hele categorie denk. Slimme meters loggen data naar flashgeheugen — elke meting, elke gebeurtenis, in intervallen van 15 minuten voor demand response. Elke schrijfbewerking slijt de cellen fysiek. Fabrikanten specificeren een levensduur van 20 jaar, maar hoogfrequent loggen verbruikt schrijfcycli veel sneller dan die prognoses aannamen. En hier komt het verraderlijke deel: naarmate de flash degradeert, drijven opgeslagen verbruiksmetingen 2 tot 8% af terwijl de meter normaal blijft rapporteren. De radio praat nog steeds. De MDMS toont een gezond, communicerend eindpunt. Ondertussen kloppen de getallen stilletjes niet, stapelen facturatiegeschillen zich op en brokkelt het publieke vertrouwen af — en tegen de tijd dat de meter volledig stilvalt, is de flash te ver gedegradeerd om zelfs maar een corrigerende firmwarefix te accepteren. Die eenheid vereist een vrachtwagen en een vervanging van $650 tot $1.400 per stuk.

Dus de kolom "meter rapporteert" van het dashboard en de kolom "datakwaliteit" kunnen maandenlang met elkaar in tegenspraak zijn, en bijna niemand leest de tweede. Wij maakten de tegenspraak tussen die twee tot het luidste alarm in het systeem.

"Oracle doet dit al. Waarom bouwen jullie het?"

Een adviseur die ik respecteer, zei het vroeg al botweg: de analyticsmarkt is overvol, de gevestigde spelers zijn serieus, waarom bouwen?

Het is een terechte vraag, en het eerlijke antwoord is dat de gevestigde spelers zich verdringen rond een ander probleem. Itrons Distributed Intelligence-platform is werkelijk indrukwekkend — meer dan 16 miljoen geactiveerde meters, meer dan 100 miljoen beheerde eindpunten, een partnerschap met NVIDIA in maart 2026 om AI aan de rand van het net te draaien. Landis+Gyrs Revelo doet, in samenwerking met Sense, lastdisaggregatie op apparaatniveau bij 1 megahertz. Sensus lanceerde begin 2026 Evolve om meters te herpositioneren als actieve netsensoren. De hele branche, zoals het thema van DistribuTECH 2026 officieel maakte, beweegt "van AMI naar AI."

Maar elk van die analyticsstacks werkt alleen met de eigen eindpunten van die leverancier. Itrons intelligentie ziet Itron-meters. Die van Landis+Gyr ziet Landis+Gyr. Echte nutsbedrijven draaien gemengde vloten, aangegroeid over een decennium van inkoopcycli — deels Aclara, deels Itron, deels Sensus — en geen enkele analytics van één leverancier overspant ze allemaal. En geen van hen, proprietair of niet, biedt firmwaresimulatie vóór uitrol tegen jouw specifieke verouderde vloot. De kloof die Plano lamlegde is structureel van niemand.

De gevestigde spelers vertellen je dat een meter rapporteert. De OT-beveiligingstools vertellen je dat hij kwetsbare firmware draait. Geen van beide vertelt je dat hij drie maanden verwijderd is van een hardwaredood.

De beveiligingsleveranciers zijn het waard om hier te noemen, omdat mensen aannemen dat zij dit afdekken. Claroty, Nozomi, Armis — ze doen uitstekende asset-discovery, tot op de firmwareversie van elk eindpunt, en ze begrijpen de industriële protocollen. Maar ze zijn gebouwd om de meter te vinden die een exploiteerbare firmwarebuild draait, niet de meter wiens batterijcohort de volgende flash-schrijfbewerking niet overleeft. Onderhoud en beveiliging kijken naar hetzelfde apparaat en stellen verschillende vragen. Wij hadden de onderhoudsvraag nodig, en die werd niet gesteld.

De testbank waar firmware met opzet mag falen

Het onderdeel waar ik het trotst op ben, is het minst glamoureus: een emulatiebank waar firmware faalt voordat het de meter van een klant bereikt.

We zetten een QEMU-omgeving op — software die de daadwerkelijke hardware van de meter emuleert — en flashen een firmwarekandidaat tegen gesimuleerde eindpunten die de echte batterij-en-signaalprofielen van de vloot dragen. Het cohort met verzwakte batterijen, het cohort met zwak RF-signaal, het cohort met veel schrijfcycli. De eerste nacht dat we een profiel draaiden dat gemodelleerd was op een verouderde vloot en de geëmuleerde eenheid precies zo door onderspanning zagen uitvallen als het veld doet en het lab nooit doet, begreep ik eindelijk dat Plano geen ongeluk was. Het was reproduceerbaar. Het was alleen nog nooit gereproduceerd vóór uitrol, omdat de testomgeving niet bestond.

Dat is de omkering. Vandaag is het veld de testomgeving en zijn de klanten de proefpersonen. Wij verplaatsen het falen naar een lab waar het onbruikbaar maken van duizend gesimuleerde meters niets kost en je alles leert.

Betekent voorspellend onderhoud niet gewoon meer valse alarmen?

Het bezwaar dat ik het vaakst hoor van operationele mensen — degenen die zich gebrand hebben aan tools die telkens loos alarm slaan — is dat voorspelling gewoon een chiquere manier is om ruis te genereren.

Het is de juiste zorg. Een gezondheidsscoremodel dat elke week 30% van je vloot markeert, is erger dan nutteloos; ploegen leren het te negeren, en je hebt budget uitgegeven om de alarmmoeheid te herscheppen waarmee je begon. Dus kalibreerden we op kosten, niet op aantallen anomalieën. De maatstaf was niet "hoeveel storingen we opvingen" maar "hoeveel vrachtwagenritten we voorkwamen ten opzichte van de ritten die we uitlokten." Sectorgegevens over AI-gestuurd voorspellend onderhoud wijzen op verlagingen van de onderhoudskosten tot 30% en betekenisvolle vermindering van uitvaltijd wanneer het tegen het juiste signaal wordt gedaan — en het juiste signaal is, nogmaals, fysieke slijtage, geen data-rariteit. Een voorspelling die geen dispatchbeslissing verandert, is geen voorspelling. Het is een melding. Dit is, denk ik, waarom zoveel nutsbedrijven AI-onderhoud piloteren en dan vastlopen — het utilities-werk van BCG uit 2026 benoemt de kloof tussen pilot en productie expliciet — ze bewijzen dat een model storingen kan markeren, maar kunnen de uitrol vervolgens niet rechtvaardigen omdat de markeringen nooit terug te koppelen waren aan een dispatch die een ploegleider daadwerkelijk zou vertrouwen.

Firmwarebeheer werd zojuist een compliance-document

Er is hier een regelgevende wending die veel nutsbedrijven volgens mij nog niet volledig hebben verwerkt, en die verhoogt de inzet aanzienlijk.

Sinds 1 april 2026 is NERC CIP-003-9 van kracht. Requirement R1, Part 1.2.6 legt beveiligingscontroles voor externe leverancierstoegang op aan grid-cybersystemen met lage impact — en zo worden de meeste slimme meters geclassificeerd. In gewone taal: het over-the-air updatepad dat je gebruikt om firmware te pushen, is nu een gereguleerd controlevlak, en de boetes voor fouten lopen op tot $1 miljoen per dag. Hetzelfde OTA-kanaal dat Plano lamlegde, is nu ook een compliance-artefact waarvoor je bewijs moet leveren.

Dat verandert het gesprek met de koper volledig. Firmwarebeheer was vroeger een operationeel klusje. Nu gaan de toegangslogs, de staging-records, de rollback-procedures — die gaan in een map die een auditor leest. Een systeem dat firmware valideert vóór uitrol, voorkomt niet langer alleen storingen; het genereert het bewijs dat je het updatepad verantwoord hebt beheerd.

Er ligt onder deze standaard een stillere waar inkoopteams naar vragen en waarop ze zelden een duidelijk antwoord krijgen: IEC 62443, de industriële-cyberbeveiligingsstandaard voor AMI. Zeer weinig meterleveranciers hebben volledige IEC 62443-certificering nagestreefd op het componentniveau — de firmware zelf. De meesten certificeren op de systeemlaag en laten de firmware van het eindpunt ongecertificeerd, wat betekent dat precies de laag die Plano lamlegde ook de laag is met de dunste beveiligingsattestatie. Die kloof is waarom we beveiligingsaudits op componentniveau uitvoeren over gemengde AMI-toeleveringsketens, niet alleen de head-end. Aan de andere kant van de Atlantische Oceaan verplichten de Ofgem-normen van het VK nu automatische compensatie — £40 per geval — voor meterstoringen door leveranciersfouten, uitbetaald binnen 10 werkdagen. De kosten van een dode meter zijn niet langer alleen de vrachtwagenrit. Het zijn de boete, de compensatie en de auditbevinding.

Wat ik het operationeel hoofd met het verouderde dashboard zou vertellen

Als ik nu terugging naar die spreadsheet met verouderde timestamps, is dit wat ik zou zeggen.

Het getal dat je wakker zou moeten houden, zijn niet de meters die al stil zijn geworden. Het is de 29% — het aandeel eindpunten waarvan sommige nutsbedrijven ontdekten dat ze waren uitgevallen stilletjes, radio's dood, zonder dat er ooit een alarm werd geslagen, en die pas opdoken toen iemand ging kijken. Je platform liegt niet tegen je. Het beantwoordt een engere vraag dan die je eigenlijk hebt. Het weet wie gestopt is met communiceren. Jij moet weten wie op het punt staat dat te doen.

De markt voor slimme meters stevent af op $112 miljard tegen 2035, en de geïnstalleerde basis in Noord-Amerika ligt al boven de 150 miljoen eenheden. Elk van die eindpunten is een kleine computer met een verouderende batterij en een verslijtende flashchip, die aan de zijkant van een gebouw zit te wachten op een firmwarepush die getest is op een plek waar hij niet leeft. De volgende Plano is al ingericht. De enige openstaande vraag is of iemand de vloot heeft gemodelleerd waarop hij gaat landen. Als je er liever op een testbank achter komt dan op de muren van 73.000 klanten, dan is dat het systeem dat je moet bouwen.

De firmware die Plano lamlegde, doorstond elke test die ze kreeg. We gaven haar alleen nooit de juiste.