Simulador de manobras: caso técnico de um motor de intertravamento

O Simulador de Manobras é uma aplicação web, local e didática, para desenhar o diagrama unifilar de uma subestação, ensaiar manobras sobre ele e montar o plano de manobras. Ele mostra, a cada passo, o que está energizado, o que está sem tensão e o que o sistema não sabe. E recusa a manobra que um intertravamento proíbe, dizendo qual regra ela violaria.

Ele não se conecta a SCADA, a banco de produção nem a equipamento real, e não substitui estudo elétrico, aprovação de engenharia ou procedimento operacional. Este caso técnico mostra como o motor elétrico funciona, quem decide a sequência de manobra, os erros que viraram regra e por que o produto ainda não tem aceite. Os números foram conferidos no código, na versão de 27/10/2026.

Transparência: o Simulador de Manobras é projetado e desenvolvido por Jeremias Cardoso, autor deste blog. O texto não cita empresa, pessoas, subestações, regiões nem códigos de equipamento.

Nota de atualização (30/10/2026): este post foi reescrito como caso técnico. A versão de 24/09/2026 dizia que o sistema era escrito em TypeScript e desenhado em Canvas, que propunha sozinho a sequência de manobra entre dois pontos e que rodava “centenas de combinações” de chaves. Conferido no código, o sistema é JavaScript com desenho em SVG, a sequência é montada pelo usuário com ajuda de prévias e propostas que uma pessoa aceita, e os números de teste estão abaixo. A correção de 29/10 continua valendo: primeiro se abrem as seccionadoras, depois se verifica a ausência de tensão e só então se fecham as chaves de aterramento.

O problema: a ordem da manobra não admite erro

Numa subestação, cada equipamento tem um papel. O disjuntor interrompe corrente. A seccionadora isola, mas não é feita para abrir com corrente passando, e por isso só manobra com o disjuntor ao lado aberto. A chave de aterramento descarrega o trecho que vai receber manutenção, e só pode fechar quando ele estiver sem tensão. Uma inversão na ordem estraga equipamento e põe gente em risco.

Por isso a manobra se treina. O simulador existe para que o erro aconteça na tela, onde ele custa uma mensagem, e para que quem planeja uma manobra veja o efeito de cada passo antes de escrever o plano. O projeto nasceu dentro do repositório do SIGCOT, o sistema de gestão da operação do mesmo autor, e virou repositório independente em 18/08/2026.

O sistema em números

Números do repositório em 27/10/2026, data do último commit.

A contagem de linhas deixa de fora os pacotes gerados pelo build, os relatórios, os documentos e os experimentos. Parte do código da aplicação descreve os diagramas das subestações modeladas, e não só regras.

Cinco coisas que não podem se misturar

A decisão de modelagem mais importante do projeto está numa frase da documentação: posição mecânica, energização, autorização, topologia e intertravamento são dimensões distintas. Saber que uma chave está fechada não diz se há tensão nela. Saber que há tensão não diz se alguém autorizou a manobra. E nenhuma dessas respostas vale pela outra.

Daí sai o contrato que atravessa o código inteiro: fato elétrico que ninguém confirmou fica como null ou PENDING, e o sistema falha fechado. Ele nunca adivinha uma posição para completar o desenho, nem trata como desenergizado um trecho que ele não sabe. Confirmar uma dimensão libera só aquela dimensão.

O motor de grafo elétrico

O coração do simulador é um motor que roda sem navegador. Ele recebe três entradas: a topologia do pátio, a posição mecânica de cada chave e a condição de cada fonte. Devolve uma “foto” congelada do estado elétrico. A interface só desenha essa foto: ela é uma projeção, não a fonte da verdade.

O cálculo é uma busca em grafo, com quatro regras simples e rígidas:

1. Só chave fechada conduz. O caminho elétrico passa apenas por chaves fechadas.
2. Barra não é fonte. As fontes são as linhas que chegam; a barra só fica viva se houver caminho fechado até uma delas.
3. O desconhecido se espalha. Chave ou fonte de estado desconhecido marca como PENDING tudo o que ela alcança. Valor ausente nunca vira “energizado”.
4. Completo é exceção, não padrão. A foto só é marcada como completa quando não sobra nenhuma chave nem fonte desconhecida.

A chave de aterramento não recebe estado elétrico: o desenho mostra só a posição dela. Na tela, preto quer dizer caminho energizado, branco quer dizer sem caminho, e PENDING é branco tracejado. A convenção visual tem uma regra que veio de um erro (mais abaixo): a forma mostra a posição da chave, e a cor mostra a tensão, nunca uma no lugar da outra.

O motor tem dois modos. Na energia automática, a energização é recalculada a partir das fontes declaradas e da conectividade depois de cada manobra. Na energia informada, quem usa declara que um trecho está desenergizado, e o sistema trata isso como premissa do usuário, não como cálculo nem medição.

O que o motor não faz também está escrito: não calcula fluxo de potência, não propaga estado entre subestações, não tem telemetria nem comando remoto. A condição de cada linha que chega de fora é uma entrada de cenário. Esse limite não é detalhe: um sistema que não fala com equipamento real não vira porta de entrada para ataque a controlador industrial.

As regras de intertravamento

Sobre a foto elétrica, o motor avalia as regras de intertravamento. As três centrais, como estão na documentação de arquitetura:

• a seccionadora ao lado de um disjuntor só manobra com esse disjuntor aberto;
• o terra abre sempre, mas só fecha com o circuito desenergizado e a seccionadora de isolamento aberta;
• o disjuntor abre sempre, mas só fecha com as duas seccionadoras ao lado fechadas e com todo aterramento que ele alcançaria explicitamente aberto.

A terceira regra tem um detalhe de implementação que vale a explicação. Para saber quais terras o disjuntor alcançaria, o motor monta o grafo como se o disjuntor candidato já estivesse fechado e procura terras nesse caminho hipotético. Terra ausente ou pendente nesse caminho bloqueia o fechamento.

Quando a manobra é recusada, nada muda: nem a posição, nem o plano, nem a condição simulada. A tela mostra o motivo e o código da regra violada, e o mesmo código vai para atributos da página, para que a informação não dependa só de cor. Quando a manobra é aceita, uma posição muda e exatamente um passo entra no plano.

Quem monta a sequência de manobra

A versão anterior deste texto dizia que o sistema propunha sozinho a sequência de segurança entre dois pontos. Não é o que o código faz, e a diferença importa.

O plano de manobras nasce das manobras que o usuário executa: cada manobra efetiva vira um passo, e o plano é uma lista que se edita. Sobre isso, o sistema oferece três ajudas, todas com uma pessoa no comando:

1. Prévia de liberação. Na bancada de ensaio, um robô determinístico (as conexões, o cadastro e as regras registradas definem o que ele propõe) calcula uma prévia para o alvo escolhido, dentro do perímetro que o autor declarou: abrir os disjuntores, depois as seccionadoras, depois fechar os terras. Se o perímetro estiver incompleto, a prévia é recusada. Calcular a prévia não executa nada: quem executa é o usuário, passo a passo ou em sequência.
2. Autoria assistida de linha. Ao desenhar uma linha de transmissão com os dois extremos no mesmo desenho, o autor pode pedir uma proposta de regras de intertravamento. Ele aceita ou rejeita. O sistema não deduz a função de um equipamento pelo nome dele e não cria posições nem presume energização.
3. Roteiro guiado. É consultivo: deriva das regras e nunca executa equipamento nem escreve no plano.

Várias subestações, um plano só

Uma manobra real raramente fica numa subestação só: desligar uma linha envolve as duas pontas. Para isso, todo elemento ganhou uma referência global, formada pela subestação e pelo identificador dele, e o plano passou a pertencer ao estado global, não a uma das subestações.

As ligações entre subestações são estruturais e nunca servem de comando remoto. Guardar uma cópia do estado da outra ponta é proibido. O contrato existe para um cenário que o simulador precisa mostrar: o operador desliga o terminal remoto, acha que a linha morreu, e ela continua viva pelo terminal local, com a chave de linha fechada.

Arquivos de fora não ganham poder

O editor importa e exporta diagramas em JSON, e a importação é tratada como entrada não confiável. O arquivo inteiro é validado numa cópia temporária, e só um candidato seguro substitui o rascunho. Um JSON importado não consegue dar capacidade de manobra a um elemento nem forjar a topologia. Nomes reservados como __proto__ são recusados, e nenhum texto importado ou digitado é executado pela página.

A distribuição segue a mesma linha. O pacote é um ZIP portátil, com atalhos para abrir o arquivo direto ou servir a aplicação só para a própria máquina, e um manifesto com os hashes SHA-256. Ele não instala programa e não envia arquivo pela internet.

Incidentes que viraram regra

O primeiro diagrama completo foi construído em cinco rodadas, em 07 e 08/08/2026, e os erros dessas rodadas viraram um guia para os diagramas seguintes. Outros vieram depois.

1. A barra tratada como fonte. Foi o erro mais grave e o mais persistente: sobreviveu três rodadas. Com a barra acesa por conta própria, o diagrama mostrava tensão onde não havia. Regra: as fontes são as linhas, e a barra só energiza por caminho fechado até uma delas. Com todas as linhas fora, o diagrama inteiro fica branco, que é o comportamento real.
2. O disjuntor fechado idêntico ao aberto. Na segunda rodada, as cores de posição e de tensão se misturaram, e um disjuntor fechado ficou visualmente igual a um aberto. Regra: forma para a posição, cor para a tensão.
3. Um booleano para dois lados. O traço da linha aparecia vivo depois de uma chave aberta, porque uma única variável representava os dois lados da seccionadora. Regra: toda chave de linha é uma fronteira de dois lados.
4. O terra exigido para religar. Tratar terra e seccionadora como uma coisa só fez o modelo exigir o terra fechado para religar o disjuntor, o oposto do correto. Regra: o terra tem regra própria.
5. A suíte verde com o intertravamento invertido. Aconteceu duas vezes: todos os testes passavam com uma regra ao contrário, porque eles conferiam a regra como tinha sido escrita, não a sequência que o operador faz. Regra: o teste nasce do roteiro do operador, não do código. É a forma mais perigosa de falha silenciosa: o sinal verde existe, e a proteção não.
6. Dezesseis condutores esquecidos. Um script que desliga todas as fontes e lista o que continua escuro achou 16 condutores sem a marcação de trecho, que nenhum teste pegava.
7. A correção de layout que piorou tudo (01/09/2026). Uma correção de layout feita sem antes escrever o caso de aceite da faixa de tela afetada trocou um defeito por outro pior, e a suíte de aceite passou porque só visitava duas resoluções. Regra: o teste da faixa entra no mesmo commit da correção.
8. A omissão que virava permissão (23/10/2026). Um valor padrão fazia todo ativo sem titular declarado ser tratado como próprio. Regra: propriedade declarada por ativo; omissão não pode virar permissão.

Também houve um problema de desempenho: um seletor de estilo fez o custo de cada redesenho do diagrama subir cerca de 16 vezes, e foi resolvido marcando o atributo pelo código, sem diferença visual.

Testes: verde que não sabe ficar vermelho

Os testes usam o executor nativo do Node, e os de interface abrem um Chromium real. Sem o navegador, a bateria reprova, em vez de aprovar sem testar. Em 19/10/2026 o comando principal registrou 1.371 testes, todos aprovados, em cerca de 22 minutos. No mesmo dia, uma rodada anterior tinha parado com 8 falhas antes de chegar a esse resultado.

Além da suíte, há baterias de cenário. A maior consolida 485 cenários e 18 combinações mínimas, e observou todos os 24 códigos de regra aplicáveis à subestação de referência. Dentro do próprio editor, o botão Testar roda os casos de uma linha numa cópia isolada do desenho; um dos exemplos reúne 140 casos.

A regra que o projeto escreveu para os próprios testes é a melhor lição do caso: verificação que não sabe ficar vermelha não é verde. Toda checagem nova precisa ser provada por mutação, quebrando de propósito o que ela deveria pegar e vendo-a reprovar.

Situação: sem aceite, e escrito assim

Em 20/08/2026, uma nota de versão interna se declarou “Release Candidate Homologado”. A documentação posterior desmente esse selo, e o site do autor repetia “concluído e homologado” até esta revisão. O estado real, conferido nos registros:

• houve aceites parciais: a bancada completa e a primeira subestação piloto foram aceitas pelo autor em 29/09/2026;
• na reavaliação de 16/10/2026, o produto ficou como não aprovado;
• em 20/10 o trabalho foi pausado, sem aceite do produto e sem continuação automática, e em 25/10 a rodada em curso fechou como bloqueada, por decisão do autor;
• toda publicação local leva o selo “LOCAL / NÃO HOMOLOGADO”, e a publicação para a organização não existe;
• hospedagem, identidade institucional e publicação operacional ficam para etapas seguintes.

A memória do projeto chegou a descrever um lote de modelos como “100% Concluído e Validado”; hoje esse lote está registrado como candidato não qualificado. Escrever o estado como ele é faz parte do produto: um simulador de segurança que se declara pronto sem estar ensina a coisa errada.

O que ainda não está resolvido

• Aceite do produto. Não existe, e nenhuma versão foi marcada no Git.
• Uso em treinamento. O repositório não registra turmas nem operadores treinados; o texto não afirma ganho de aprendizado.
• Alcance do motor. Sem fluxo de potência e sem propagação entre subestações, o simulador ensina a lógica do intertravamento, não o comportamento elétrico completo da rede.
• Autoria de linha. O ensaio suporta um disjuntor por ponta e exige os dois extremos no mesmo desenho.
• Tempo da suíte. Vinte e dois minutos por rodada pesam no ciclo de mudança.

Lições que valem fora da subestação

1. Separe as dimensões do estado. Posição, energia e autorização respondem a perguntas diferentes.
2. O desconhecido é um estado, não um vazio. Marque, propague e bloqueie.
3. A interface projeta; o motor decide. Regra que só existe na tela não é regra.
4. Recusa não muda nada. Manobra negada não pode deixar rastro no plano.
5. Teste a partir do roteiro de quem opera, não do código que você acabou de escrever.
6. Prove que a checagem falha antes de confiar que ela passa.
7. Selo de pronto só com aceite. Autodeclaração envelhece mal.

Fontes

• Código, documentação, decisões de arquitetura, incidentes e registros de teste: repositório do Simulador de Manobras na versão de 27/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.