73.000 Medidores Inteligentes Ficaram Mudos da Noite para o Dia — e o Firmware Havia Passado em Todos os Testes de Laboratório

Em novembro de 2024, uma concessionária em Plano, Texas, enviou uma atualização de firmware de rotina para 88.000 hidrômetros. A atualização deveria corrigir o esgotamento prematuro da bateria — um reparo de boa-fé de um problema conhecido. No laboratório, funcionou. No campo, 73.000 medidores ficaram mudos e nunca voltaram.

Eu sempre volto a esse número por causa do que ele implica. Não foi um ataque, uma tempestade ou um defeito de fabricação. Foi uma atualização de software que havia sido testada e aprovada, comportando-se exatamente como projetada — e ainda assim inutilizou 83% de uma frota. Essa lacuna entre "passou no laboratório" e "matou o campo" é todo o problema da IA de medidores inteligentes, e é por isso que construímos um sistema de manutenção preditiva de AMI na Veriprajna que observa os sinais que um painel de análise nunca foi construído para ver.

A primeira vez que me sentei com o líder de operações de uma concessionária municipal e olhei para o head-end de AMI deles — o sistema que coleta as leituras de cada medidor — eu esperava uma sala de controle. O que encontrei foi uma planilha. Carimbos de data/hora da última comunicação, uma linha por medidor, e uma rolagem lenta de células ficando desatualizadas. Ele podia me dizer, com precisão, quais medidores haviam parado de se comunicar. Ele não podia me dizer quais parariam em seguida. Essa assimetria — retrospectiva perfeita, previsão zero — é todo o mercado.

Por Que o Firmware Que Passa no Laboratório Inutiliza o Campo?

Aqui está o que realmente aconteceu em Plano, e é a história mais útil deste domínio.

O firmware foi testado em medidores com baterias novas e um sinal de rádio forte — uma bancada limpa. Mas a frota implantada tinha de quatro a cinco anos, e a maioria dessas baterias estava em 60 a 75% de sua capacidade original. As rotinas atualizadas de gerenciamento de energia consumiam um pouco mais de corrente durante a gravação inicial do flash. Em uma bateria nova, irrelevante. Em uma degradada, esse consumo extra foi suficiente para acionar a proteção contra queda de tensão. Os módulos de transmissão reiniciaram, perderam seu registro na rede e nunca se recuperaram.

O firmware não falhou. Ele atendeu à especificação. A frota simplesmente envelheceu além do que a bancada de teste previa, e ninguém estava modelando isso.

Essa frase é a tese de tudo o que construímos. O defeito não estava no código. Estava na suposição de que um medidor de laboratório e um medidor de campo são a mesma máquina. Não são, e a diferença se acumula silenciosamente por anos antes que alguém aperte o botão que a expõe.

Essas falhas se agrupam. O firmware do mesmo fornecedor produziu incidentes semelhantes em Minneapolis, Toronto e Nova York. A Toronto Hydro encontrou cerca de 470.000 transmissores degradando prematuramente e gastou US$ 5,6 milhões apenas na primeira rodada de correção. Memphis registrou uma taxa de falha sistêmica de 8% e criou um fundo de reparos de US$ 9 milhões. No Reino Unido, cerca de um em cada cinco medidores inteligentes não funciona como deveria; mais de 600.000 foram reconectados desde julho de 2024. Nenhuma dessas concessionárias carecia de uma plataforma de análise. Todas tinham uma. A plataforma simplesmente não estava observando aquilo que quebrou.

O Erro Que Defendi por Tempo Demais

Quero ser honesto sobre a versão disto que erramos, porque é a parte que a maioria das pessoas pula.

Quando começamos, o movimento óbvio era a detecção de anomalias. Um medidor prestes a falhar deveria parecer estranho em seus dados — leituras de consumo à deriva, lacunas nos relatórios, padrões esquisitos. Então construímos um modelo que observava o fluxo de consumo e sinalizava anomalias. Era limpo. Demonstrava lindamente. Eu o defendi em sala após sala.

Então o rodamos contra uma onda real de degradação em uma frota piloto, e ele ficou lá, verde, enquanto os medidores silenciosamente estragavam por baixo dele. Lembro-me da sensação específica de ver o painel permanecer calmo e ter certeza de que o modelo estava quebrado. O modelo não estava quebrado. Eu o havia apontado para o sinal errado.

A detecção de anomalias de consumo é exatamente o que os Sistemas de Gerenciamento de Dados de Medição existentes já fazem. A Oracle lançou a detecção de anomalias com IA para sua plataforma de concessionárias em junho de 2025; a SAP é líder no IDC MarketScape na categoria. Essas ferramentas são boas no que fazem — elas detectam um medidor que está relatando números estranhos. O problema é que um medidor a caminho da morte por firmware não relata números estranhos. Ele relata números perfeitamente normais, até o exato momento em que não relata mais nada. Havíamos reconstruído aquilo que já existia e voltado a herdar o seu ponto cego.

Um medidor em falha não parece doente em seus dados de consumo. Parece saudável, e então se vai. O sinal de que você precisa mora em algum lugar que o fluxo de faturamento não consegue ver.

O Que o MDMS Não Consegue Ver: Dois Sinais Que Realmente Preveem a Falha

A virada veio quando paramos de perguntar "esta leitura é anômala?" e começamos a perguntar "o que se desgasta fisicamente em um medidor, e podemos medi-lo antes que quebre?"

Duas respostas importaram.

O primeiro é o estado de carga da bateria, modelado por coorte de implantação em vez de como uma média da frota. A lição de Plano é que um envio de firmware só é perigoso contra uma distribuição específica de saúde da bateria — e essa distribuição é conhecível. Se você agrupar cada endpoint por data de instalação e construir histogramas de estado de carga por coorte, você consegue ver o precipício da queda de tensão se aproximando antes de gravar qualquer coisa. Começamos a preparar o firmware contra o perfil real de idade e capacidade da frota, não uma bancada cheia de unidades novas.

O segundo é o desgaste silencioso da memória flash NAND, e este realmente mudou a forma como penso sobre toda a categoria. Os medidores inteligentes registram dados na memória flash — cada leitura, cada evento, em intervalos de 15 minutos para resposta à demanda. Cada gravação desgasta fisicamente as células. Os fabricantes especificam vida útil de 20 anos, mas o registro de alta frequência consome os ciclos de gravação muito mais rápido do que essas projeções presumiam. E aqui está a parte insidiosa: à medida que o flash se degrada, as leituras de consumo armazenadas desviam de 2 a 8% enquanto o medidor continua relatando normalmente. O rádio ainda se comunica. O MDMS mostra um endpoint saudável e em comunicação. Enquanto isso, os números estão silenciosamente errados, as disputas de faturamento se acumulam e a confiança pública se corrói — e, quando o medidor fica totalmente mudo, o flash está degradado demais até para aceitar uma correção de firmware. Essa unidade precisa de um caminhão e de uma substituição a US$ 650 a US$ 1.400 cada.

Assim, a coluna "medidor relatando" do painel e a coluna "qualidade dos dados" podem discordar por meses, e quase ninguém lê a segunda. Transformamos a discordância entre essas duas no alarme mais alto do sistema.

"A Oracle Já Faz Isso. Por Que Vocês Estão Construindo?"

Um consultor que respeito colocou isso sem rodeios logo no início: o espaço de análise está lotado, os incumbentes são sérios, por que construir?

É uma pergunta justa, e a resposta honesta é que os incumbentes estão aglomerados em torno de um diferente problema. A plataforma Distributed Intelligence da Itron é genuinamente impressionante — mais de 16 milhões de medidores habilitados, mais de 100 milhões de endpoints sob gestão, uma parceria de março de 2026 com a NVIDIA para rodar IA na borda da rede. O Revelo da Landis+Gyr, com uma colaboração da Sense, faz desagregação de carga em nível de eletrodoméstico a 1 megahertz. A Sensus lançou o Evolve no início de 2026 para reposicionar os medidores como sensores ativos da rede. Toda a indústria, como o tema de 2026 da DistribuTECH oficializou, está migrando "de AMI para IA".

Mas cada uma dessas pilhas de análise funciona apenas com os endpoints do próprio fornecedor. A inteligência da Itron enxerga medidores Itron. A da Landis+Gyr enxerga Landis+Gyr. Concessionárias reais operam mistas frotas, acumuladas ao longo de uma década de ciclos de aquisição — algumas Aclara, algumas Itron, algumas Sensus — e a análise de nenhum fornecedor isolado abrange todas elas. E nenhuma delas, proprietária ou não, oferece simulação de firmware pré-implantação contra sua frota envelhecida específica. A lacuna que inutilizou Plano é, estruturalmente, de ninguém.

Os incumbentes lhe dirão que um medidor está relatando. As ferramentas de segurança de TO lhe dirão que ele está executando firmware vulnerável. Nenhum lhe dirá que ele está a três meses de uma morte de hardware.

Vale nomear os fornecedores de segurança aqui, porque as pessoas presumem que eles cobrem isso. Claroty, Nozomi, Armis — eles fazem uma excelente descoberta de ativos, até a versão do firmware em cada endpoint, e entendem os protocolos industriais. Mas foram construídos para encontrar o medidor executando uma versão de firmware explorável, não o medidor cuja coorte de bateria não sobrevive à próxima gravação de flash. Manutenção e segurança olham para o mesmo dispositivo e fazem perguntas diferentes. Precisávamos da pergunta de manutenção, e ela não estava sendo feita.

A Bancada Onde o Firmware Vai Falhar de Propósito

A parte de que mais me orgulho é a menos glamorosa: uma bancada de emulação onde o firmware falha antes de chegar ao medidor de um cliente.

Montamos um ambiente QEMU — software que emula o hardware real do medidor — e gravamos uma imagem de firmware candidata contra endpoints simulados que carregam os perfis reais de bateria e sinal da frota. A coorte de bateria degradada, a coorte de RF fraco, a coorte de alto ciclo de gravação. Na primeira noite em que rodamos um perfil modelado em uma frota envelhecida e vimos a unidade emulada sofrer queda de tensão exatamente como o campo faz e o laboratório nunca faz, finalmente entendi que Plano não foi um acidente. Era reproduzível. Só nunca havia sido reproduzido antes da implantação, porque o ambiente de teste não existia.

Essa é a inversão. Hoje, o campo é o ambiente de teste, e os clientes são os sujeitos do teste. Movemos a falha para um laboratório onde inutilizar mil medidores simulados não custa nada e ensina tudo.

A Manutenção Preditiva Não Significa Apenas Mais Alarmes Falsos?

A objeção que mais ouço das pessoas de operações — aquelas que se queimaram com ferramentas que gritam "olha o lobo" — é que a previsão é apenas uma forma mais sofisticada de gerar ruído.

É a preocupação certa. Um modelo de pontuação de saúde que sinaliza 30% de sua frota toda semana é pior do que inútil; as equipes aprendem a ignorá-lo, e você gastou orçamento para recriar a fadiga de alertas com que começou. Então calibramos com base no custo, não na contagem de anomalias. O parâmetro de referência não era "quantas falhas detectamos", mas "quantas idas de caminhão nós evitamos em relação às que provocamos." Os dados do setor sobre manutenção preditiva orientada por IA apontam para reduções de até 30% no custo de manutenção e cortes significativos de tempo de inatividade quando feita contra o sinal certo — e o sinal certo, novamente, é o desgaste físico, não a esquisitice dos dados. Uma previsão que não muda uma decisão de despacho não é uma previsão. É uma notificação. É por isso, acho, que tantas concessionárias fazem pilotos de manutenção com IA e depois empacam — o trabalho de 2026 da BCG sobre concessionárias aponta explicitamente a lacuna entre piloto e produção — elas provam que um modelo consegue sinalizar falhas, mas depois não conseguem justificar a implantação porque os sinalizadores nunca se conectaram a um despacho no qual um chefe de equipe realmente confiaria.

O Gerenciamento de Firmware Acaba de se Tornar um Documento de Conformidade

Há uma virada regulatória aqui que acho que muitas concessionárias ainda não absorveram totalmente, e ela eleva consideravelmente o que está em jogo.

A partir de 1º de abril de 2026, a NERC CIP-003-9 está em vigor. Seu Requisito R1, Parte 1.2.6, impõe controles de segurança de acesso remoto de fornecedores em sistemas cibernéticos de rede de baixo impacto — que é como a maioria dos medidores inteligentes é classificada. Em termos simples: o caminho de atualização over-the-air que você usa para enviar firmware é agora uma superfície de controle regulada, e as penalidades por errar chegam a US$ 1 milhão por dia. O mesmo canal OTA que inutilizou Plano é agora também um artefato de conformidade para o qual você tem que produzir evidências.

Isso muda completamente a conversa com o comprador. O gerenciamento de firmware costumava ser uma tarefa operacional. Agora os registros de acesso, os registros de preparação, os procedimentos de reversão — vão para uma pasta que um auditor lê. Um sistema que valida o firmware antes da implantação não está mais apenas prevenindo interrupções; está gerando a evidência de que você gerenciou o caminho de atualização de forma responsável.

Há um padrão mais discreto por trás deste, sobre o qual as equipes de compras perguntam e raramente obtêm uma resposta direta: a IEC 62443, o padrão de cibersegurança industrial para AMI. Muito poucos fornecedores de medidores buscaram a certificação IEC 62443 completa no nível de componente — o firmware em si. A maioria certifica na camada de sistema e deixa o firmware do endpoint sem certificação, o que significa que a exata camada que inutilizou Plano é também a camada com a atestação de segurança mais fraca. Essa lacuna é o motivo pelo qual fazemos auditorias de segurança em nível de componente em cadeias de suprimento de AMI mistas, não apenas o head-end. Do outro lado do Atlântico, os padrões da Ofgem do Reino Unido agora exigem compensação automática — £40 por ocorrência — para falhas de medidores por culpa do fornecedor, pagas em até 10 dias úteis. O custo de um medidor morto não é mais apenas a ida de caminhão. É a multa, a compensação e a constatação da auditoria.

O Que Eu Diria ao Líder de Operações com o Painel Desatualizado

Se eu voltasse àquela planilha de carimbos de data/hora desatualizados agora, aqui está o que eu diria.

O número que deveria tirar seu sono não são os medidores que já ficaram em silêncio. São os 29% — a parcela de endpoints que algumas concessionárias descobriram ter falhado silenciosamente, com os rádios mortos, sem que nenhum alerta jamais fosse emitido, aparecendo apenas quando alguém foi procurar. Sua plataforma não está mentindo para você. Ela está respondendo a uma pergunta mais estreita do que a que você realmente tem. Ela sabe quem parou de se comunicar. Você precisa saber quem está prestes a parar.

O mercado de medidores inteligentes está caminhando para US$ 112 bilhões até 2035, e a base instalada na América do Norte já passa de 150 milhões de unidades. Cada um desses endpoints é um pequeno computador com uma bateria envelhecendo e um chip flash se desgastando, do lado de um prédio, esperando por um envio de firmware testado em algum lugar onde ele não vive. O próximo Plano já está provisionado. A única questão em aberto é se alguém modelou a frota sobre a qual ele está prestes a cair. Se você prefere descobrir em uma bancada do que nas paredes de 73.000 clientes, esse é o sistema a construir.

O firmware que inutilizou Plano passou em todos os testes que lhe foram dados. Nós apenas nunca lhe demos o certo.