Sentinela: caso técnico de um monitor das normas do ONS

O Sentinela é uma aplicação desktop que acompanha as revisões dos Procedimentos de Rede e do Manual de Procedimentos da Operação (MPO), as normas que o Operador Nacional do Sistema Elétrico (ONS) publica e que um centro de operação da transmissão precisa seguir. Ele coleta os documentos que importam, compara as versões, prepara a minuta do informe interno e registra o ciente de cada operador. A publicação do informe é sempre de uma pessoa: a automação nunca publica sozinha.

Este caso técnico mostra como o sistema funciona, as decisões que o moldaram e as falhas reais que viraram regra. Os números foram conferidos no código, na versão de 28/10/2026.

Transparência: o Sentinela foi projetado e é desenvolvido por Jeremias Cardoso, autor deste blog, para o centro de operação em que trabalha. O texto não cita a empresa, pessoas, estações nem caminhos de rede, e deixa de fora detalhes de segurança da infraestrutura.

Nota de atualização (30/10/2026): este post foi reescrito como caso técnico. A versão de 19/07/2026 descrevia o padrão geral de um robô que monitora sites oficiais; o padrão continua aqui, agora com os números, as decisões e os incidentes do sistema real.

O problema: seis passos feitos à mão

Antes do Sentinela, acompanhar as normas era um processo manual em seis passos:

1. consultar o site do ONS;
2. identificar as normas que envolvem a empresa;
3. baixar o PDF;
4. avaliar o que mudou em relação à versão anterior;
5. escrever um informe interno sobre a mudança;
6. coletar o ciente de toda a equipe.

O sistema automatiza os cinco primeiros e digitaliza o sexto, com trilha de auditoria. O centro de operação funciona 24 horas, e o sistema foi desenhado para cerca de 15 operadores em turnos, com 2 a 4 usando ao mesmo tempo. Quando o acompanhamento falha, a equipe opera com uma norma defasada sem saber, e é justamente esse tipo de falha silenciosa que o projeto inteiro tenta evitar.

O sistema em números

Números de outubro de 2026, com a data de cada medida entre parênteses.

A contagem de linhas considera só os arquivos versionados e exclui linhas em branco e comentários: são 29,5 mil linhas de Java, 932 de estilos e 139 de migrações de banco. Com brancos e comentários, a aplicação passa de 42 mil linhas físicas. A interface é escrita direto em Java, sem arquivos de tela separados.

Como o monitor funciona

Todo monitor de fonte oficial é a mesma máquina de quatro estágios: varrer, detectar novidade, comparar e avisar. O que muda é o cuidado em cada estágio.

Varredura: dado, não layout

As páginas do ONS são montadas por JavaScript no navegador, e o HTML que chega ao robô não traz a lista de documentos. Por isso o coletor lê os dados que alimentam as páginas, em formato JSON, e não o visual. Quanto mais perto do dado e mais longe do layout, menos alarme falso; depender do layout é o ponto frágil do RPA tradicional.

A coleta roda na tela, sob demanda, ou como tarefa agendada do Windows, sem interface. O padrão é terça e quinta às 6h, com mínimo de duas vezes por semana, e a tarefa agendada não coleta duas vezes no mesmo dia, a menos que alguém force.

Detecção: três sinais, não um

Para cada documento da lista, o coletor baixa o PDF para uma área de conferência e calcula o SHA-256, uma impressão digital do arquivo. O documento só é considerado “sem novidade” quando três sinais batem: o número da revisão, a data de vigência e o hash. Se a fonte publica um arquivo diferente com o mesmo número de revisão, o sistema não sobrescreve nada: falha fechado, mantém o que já tinha e guarda a cópia recebida à parte, para alguém investigar.

Comparação: o que mudou, página a página

O produto de um monitor não é o aviso, é a diferença. O Sentinela extrai o texto de cada página das duas versões e compara uma com a outra. Também lê o quadro de controle de revisões que a própria norma traz, que costuma dizer o que o ONS alterou. Esses dois passos são determinísticos: não dependem de IA.

Aviso: minuta automática, publicação humana

Com a mudança detectada, o sistema gera a minuta do informe. Só quem tem o perfil de supervisor pode editar, aprovar e publicar. Depois da publicação, cada operador registra o ciente, e esse registro só cresce: o contrato da aplicação não apaga nem altera ciente. Dois supervisores editando o mesmo informe em estações diferentes não se atropelam: cada alteração confere a versão que a pessoa estava vendo, e quem chegou depois recebe um aviso de conflito em vez de um “salvo” falso.

Um painel chamado Vigia mostra quando foi a última coleta completa. Passadas 24 horas sem coleta, ele oferece a recuperação; passadas 48 horas, mostra um alerta vermelho para todos.

A lista que cortou 1.657 normas para 121

A primeira coleta completa trouxe 1.657 normas, 1.207 delas instruções de operação. Era ruído demais para o centro de operação. Filtrar automaticamente pelo nome da empresa também não funcionava: o nome não aparece em nenhum metadado da fonte.

A saída, decidida em 17/06/2026, foi uma lista curada: o centro de operação cadastra os documentos que importam, partindo do plano de contingência que a equipe já mantinha. O coletor lê os metadados de tudo, que é barato, mas só baixa e compara o que está na lista. Hoje são 121 documentos. As 1.657 normas já baixadas continuaram no portal como histórico consultável.

A lição vale para qualquer monitor: quem define o que é relevante é quem usa a informação, não o volume que a fonte publica.

Onde mora o banco: do Access à nuvem e de volta

O Sentinela nasceu sem servidor, com um banco Microsoft Access numa pasta de rede, para viabilizar o piloto. Em 20/06/2026, o banco foi para um SQL na nuvem. Em 24/06, por custo, foi para outro banco na nuvem. Em 19/07, voltou ao Access: a rede corporativa do centro de operação não permitia a conexão das estações com o banco remoto. O desenvolvimento acontecia fora dessa rede, e a validação nela tinha ficado para depois; foi um mês de migrações desfeito por isso.

A volta trouxe de novo a limitação conhecida do Access: ele não organiza a escrita entre processos de máquinas diferentes. Em 01/08/2026, o projeto mediu isso com três processos gravando no mesmo arquivo, no mesmo milissegundo:

• em cerca de 7 de 24 rodadas, dois processos conseguiram inserir o mesmo registro;
• em 5 de 5 rodadas de escrita simultânea, o arquivo ficou com zero linhas legíveis na tabela;
• uma atualização condicionada, que deveria deixar passar só um, informou sucesso nos três processos em 4 de 4 rodadas.

A resposta foi pôr o árbitro fora do arquivo de dados. Desde 30/09, a coleta adquire uma trava de arquivo do sistema operacional, ao lado do banco, antes de qualquer outra coisa, e a tarefa agendada roda inteira sob essa trava. A estação que perde a disputa sai sem escrever nada. Antes disso, a perdedora seguia para as etapas seguintes, gravava no banco sem trava e ainda saía com código de sucesso.

O sistema irmão, o SIGCOT, resolveu o mesmo problema trocando o Access por um SQL Server corporativo. O Sentinela, cuja escrita pesada se concentra na coleta, ficou no Access e passou a controlar quem escreve e quando.

A análise de relevância: IA só com o que é público

Saber o que mudou não basta: alguém precisa dizer se a mudança importa para a operação. Para isso o Sentinela prepara um pacote com a diferença entre as versões, o quadro de controle de revisões e um roteiro de perguntas. A resposta esperada tem formato fixo: resumo, relevância (alta, média ou baixa), justificativa e os trechos afetados com o número da página. O roteiro proíbe inventar: sem evidência no material, a resposta é “não encontrado”.

O modo padrão é o assistido: uma pessoa leva o pacote a um assistente de IA externo e cola a resposta de volta no sistema. Existe um modo automático opcional, com um provedor na nuvem ou um modelo local, que recebe o mesmo pacote e devolve o trabalho para a via assistida quando falha. Na rede do centro de operação, os provedores externos de IA são bloqueados, então o modo assistido é o que vale, e a análise automática ficou como recurso adiado.

A regra é que só conteúdo público do ONS entra no pacote, nunca informe interno ou dado pessoal. A busca do portal e o assistente de dúvidas do manual não usam IA: o assistente, quando não sabe a resposta, diz que não sabe. É a mesma divisão que funciona fora do laboratório: a automação faz o trabalho repetitivo, e o julgamento fica com a pessoa.

Incidentes que viraram regra

22/07/2026: o backup que nascia e morria no mesmo ciclo. O backup diário copiava o banco para um arquivo com a data no nome. No Windows, a cópia herda a data de modificação do arquivo original, e a rotina que apaga backups com mais de 30 dias julgava a idade por essa data. Num banco sem escrita havia mais de 30 dias, o backup do dia era criado e apagado no mesmo ciclo, e a estação ficava sem backup nenhum, em silêncio. A rotação passou a usar a data do nome do arquivo.

22/07/2026: o teste que caiu na base de produção. Na mesma verificação, um arquivo de configuração de teste foi gravado com um caractere invisível no início, o BOM, que algumas ferramentas do Windows acrescentam. A primeira chave do arquivo deixou de ser reconhecida, e o sistema caiu na pasta padrão, que era a base real. O ciclo consultou dois documentos no site do ONS e gravou um registro de coleta. Nada foi perdido, e a conferência mostrou o banco real com o mesmo tamanho de antes. O relatório registrou a causa e a orientação: arquivo de configuração de teste não se grava com essa ferramenta, ou se conferem os primeiros bytes antes de rodar.

27/07/2026: “perdi todos os dados”. Ao abrir o pacote numa estação do centro de operação, o autor viu uma instalação nova: sem documentos, sem usuários, pedindo troca da senha inicial. Os dados não tinham sumido. A pasta padrão do Sentinela, usada quando nenhuma estava configurada, apontava para a pasta de dados de outro sistema, que existe em todas as estações. O teste de acesso passou, e o Sentinela criou ali um banco vazio sem nenhum passo falhar.

A correção virou regra inviolável: o sistema nunca cria banco sem consentimento explícito, diante do caminho completo, e a tarefa agendada nunca cria banco. O padrão de último recurso mudou para uma pasta que não existe por acidente. Onze testes travam essa decisão.

02/08/2026: o botão de parar que apagaria o alarme. A primeira versão do comando “parar após este documento” gravava um registro de coleta interrompida. Uma guarda automática reprovou o build: qualquer registro novo de coleta zerava o relógio do Vigia. Uma coleta parada no terceiro de 121 documentos diria “coletou agora” e esconderia a defasagem dos outros 118. A interrupção passou a ser registrada fora do histórico de coletas.

01/10/2026: a senha certa no banco errado. O endereço do banco ficava guardado no perfil do Windows de cada operador. Um operador gravou um caminho sem banco e deixou de conseguir entrar. Redefinir a senha não adiantou, porque a senha estava no banco verdadeiro e a estação olhava para outro lugar. O endereço passou a vir de um vínculo central, ao lado do executável.

23/10/2026: o pacote que não saiu do commit. A conferência da versão 1.1.10 mostrou que o pacote de instalação tinha sido gerado oito minutos antes do commit, a partir da pasta de trabalho. O conteúdo era o mesmo, mas não havia como provar. O pacote foi refeito em 27/10 a partir do commit limpo, e só então a versão ganhou a tag.

28/10/2026: reprovado no teste presencial. O autor testou na estação o aviso por e-mail da versão 1.2.0 e o reprovou por três motivos: os destinatários saíam separados por vírgula, que o Outlook não aceita no campo Para; a janela abria e não enviava, quando o pedido era envio automático; e o corpo trazia uma frase fixa em vez das alterações. A 1.2.0 foi congelada sem publicação, e a 1.3.0 refez o aviso com envio automático e um cartão com as alterações.

Desempenho: contar conexões antes de cronometrar

Com o Access em pasta de rede, abrir uma conexão custa caro: na configuração que mantém o arquivo íntegro entre estações, cada abertura relê o banco. Em vez de cronometrar telas, a auditoria de desempenho de setembro contou conexões, medidas em bases de 3 e de 12 documentos:

O ciclo de coleta passou a fazer 121 releituras a menos. O ganho em segundos, porém, não foi medido: a cronometragem real no centro de operação depende de implantar a versão com medição automática de abertura e login e de uma semana de coleta de dados. O projeto registra isso como pendência, não como vitória.

Testes e guardas

A suíte cresceu com o sistema: 111 testes em 20/06/2026, 631 em 28/07, 968 na versão 1.1.0, 1.145 em 30/09 e 1.256 em 28/10, sem falhas. Vinte classes são guardas de arquitetura: em vez de testar uma função, elas leem o código-fonte e travam uma regra. Uma confere que todo acesso ao banco fica na camada de dados. Outra confere que nenhum resultado parcial, cancelado ou com falha aparece como sucesso verde. Outra confere que nenhum segredo vai dentro do pacote de instalação.

O projeto tem 13 regras invioláveis, e a maioria tem guarda automática, no espírito dos portões que provam. A leitura do código para este texto não encontrou guarda automática para quatro delas, que dependem de revisão: o ciente que só cresce, a regra de que a IA só recebe conteúdo público, a proibição de estilo direto no código da tela e a atualização dos mapas de arquitetura.

O pacote portátil traz o Java embutido, então a estação não precisa instalá-lo. Antes de cada entrega, um teste de fumaça faz 24 verificações numa pasta nova e confere, pelo hash, que o arquivo de configuração real da estação não foi tocado.

O que ainda não está resolvido

• A 1.3.0 não está fechada. A tag espera a aprovação do teste presencial, e o envio real do e-mail ainda não foi executado na estação.
• O aceite com três estações na pasta de rede real não foi feito. Depende da TI e está documentado como não executado.
• A cronometragem no centro de operação nunca aconteceu. O ganho de desempenho está provado em conexões, não em segundos.
• A análise automática por IA está adiada, porque a rede bloqueia os provedores externos.
• Os mapas de arquitetura pararam em agosto. As decisões de outubro ainda não estão neles, o que descumpre uma das regras invioláveis.
• Não há número de uso. O repositório não registra quantos informes foram publicados nem quantos cientes foram dados. Este texto não afirma ganho de produtividade porque esse número não existe.

Lições que valem fora do setor elétrico

1. Filtre pela lista de quem usa, não pelo que a fonte publica. De 1.657 normas, 121 importam.
2. Teste o caminho de rede antes de migrar o banco. Um mês de migrações caiu numa conexão que a rede não permitia.
3. Banco de arquivo compartilhado precisa de árbitro fora do arquivo. Índice único e atualização condicionada não seguraram três processos; a trava do sistema operacional segurou.
4. Padrão de último recurso não pode existir por acidente. A pasta padrão que já existia em todas as estações transformou “abri a pasta errada” em “perdi tudo”.
5. O instrumento de vigilância não pode apagar o que vigia. Um registro a mais teria zerado o relógio do Vigia.
6. Pacote sai do commit, não da pasta de trabalho. Sem isso, a versão instalada não tem como provar de onde veio.

Fontes

• Arquitetura, decisões, incidentes, medições, testes e contagem de linhas: repositório do Sentinela na versão de 28/10/2026, lido pelo autor; extrato com os trechos, o método da contagem e os limites da verificação, verificado em 2026-10-30.
• Procedimentos de Rede e MPO, as fontes coletadas: Operador Nacional do Sistema Elétrico (ONS), endereço usado pelo coletor conferido no código em 2026-10-30.