Simulador de maniobras: caso técnico de un motor de enclavamiento

El Simulador de Maniobras es una aplicación web, local y didáctica, para dibujar el diagrama unifilar de una subestación, ensayar maniobras sobre él y armar el plan de maniobras. Muestra, en cada paso, qué está energizado, qué está sin tensión y qué el sistema no sabe. Y rechaza la maniobra que un enclavamiento prohíbe, diciendo cuál regla violaría.

No se conecta a SCADA, a una base de datos de producción ni a equipo real, y no sustituye un estudio eléctrico, una aprobación de ingeniería o un procedimiento operativo. Este caso técnico muestra cómo funciona el motor del modelo eléctrico, quién decide la secuencia de la maniobra, los errores que se volvieron regla y por qué el producto todavía no tiene aceptación. Los números se verificaron en el código, en la versión del 27/10/2026.

Transparencia: el Simulador de Maniobras es proyectado y desarrollado por Jeremias Cardoso, autor de este blog. El texto no cita empresa, personas, subestaciones, regiones ni códigos de equipo.

Nota de actualización (30/10/2026): este post se reescribió como caso técnico. La versión del 24/09/2026 decía que el sistema estaba escrito en TypeScript y dibujado en Canvas, que proponía por sí solo la secuencia de maniobra entre dos puntos y que corría “cientos de combinaciones” de interruptores. Verificado en el código, el sistema es JavaScript con dibujo en SVG, la secuencia la arma el usuario con ayuda de previas y propuestas que una persona acepta, y los números de prueba están abajo. La corrección del 29/10 sigue valiendo: primero se abren los seccionadores, después se verifica la ausencia de tensión y solo entonces se cierran los seccionadores de puesta a tierra.

El problema: el orden de la maniobra no admite error

En una subestación, cada equipo tiene un papel. El disyuntor interrumpe corriente. El seccionador aísla, pero no está hecho para abrir con corriente pasando, y por eso solo se maniobra con el disyuntor de al lado abierto. El seccionador de puesta a tierra descarga el tramo que va a recibir mantenimiento, y solo puede cerrar cuando esté sin tensión. Una inversión en el orden daña equipo y pone a la gente en riesgo.

Por eso la maniobra se entrena. El simulador existe para que el error ocurra en la pantalla, donde cuesta un mensaje, y para que quien planifica una maniobra vea el efecto de cada paso antes de escribir el plan. El proyecto nació dentro del repositorio de SIGCOT, el sistema de gestión de la operación del mismo autor, y se volvió un repositorio independiente el 18/08/2026.

El sistema en números

Números del repositorio el 27/10/2026, fecha del último commit.

El conteo de líneas deja afuera los paquetes generados por el build, los informes, los documentos y los experimentos. Parte del código de la aplicación describe los diagramas de las subestaciones modeladas, y no solo reglas.

Cinco cosas que no pueden mezclarse

La decisión de modelado más importante del proyecto está en una frase de la documentación: posición mecánica, energización, autorización, topología y enclavamiento son dimensiones distintas. Saber que un interruptor está cerrado no dice si hay tensión en él. Saber que hay tensión no dice si alguien autorizó la maniobra. Y ninguna de esas respuestas vale por la otra.

De ahí sale el contrato que atraviesa el código entero: el hecho eléctrico que nadie confirmó queda como null o PENDING, y el sistema falla cerrado. Nunca adivina una posición para completar el dibujo, ni trata como desenergizado un tramo que no conoce. Confirmar una dimensión libera solo esa dimensión.

El motor de grafo eléctrico

El corazón del simulador es un motor que corre sin navegador. Recibe tres entradas: la topología del patio, la posición mecánica de cada interruptor y la condición de cada fuente. Devuelve una “foto” congelada del estado eléctrico. La interfaz solo dibuja esa foto: es una proyección, no la fuente de la verdad.

El cálculo es una búsqueda en grafo, con cuatro reglas simples y rígidas:

1. Solo el interruptor cerrado conduce. El camino eléctrico pasa únicamente por interruptores cerrados.
2. La barra no es fuente. Las fuentes son las líneas que llegan; la barra solo queda viva si hay un camino cerrado hasta una de ellas.
3. Lo desconocido se propaga. Un interruptor o una fuente de estado desconocido marca como PENDING todo lo que alcanza. Un valor ausente nunca se vuelve “energizado”.
4. Completo es excepción, no la norma. La foto solo se marca como completa cuando no queda ningún interruptor ni fuente desconocida.

El seccionador de puesta a tierra no recibe estado eléctrico: el dibujo muestra solo su posición. En la pantalla, negro quiere decir camino energizado, blanco quiere decir sin camino, y PENDING es blanco punteado. La convención visual tiene una regla que vino de un error (más abajo): la forma muestra la posición del interruptor, y el color muestra la tensión, nunca una en el lugar de la otra.

El motor tiene dos modos. En la energía automática, la energización se recalcula a partir de las fuentes declaradas y de la conectividad después de cada maniobra. En la energía informada, quien usa declara que un tramo está desenergizado, y el sistema trata eso como premisa del usuario, no como cálculo ni medición.

Lo que el motor no hace también está escrito: no calcula flujo de potencia, no propaga estado entre subestaciones, no tiene telemetría ni comando remoto. La condición de cada línea que llega de afuera es una entrada de escenario. Ese límite no es un detalle: un sistema que no habla con equipo real no se vuelve puerta de entrada para un ataque a un controlador industrial.

Las reglas de enclavamiento

Sobre la foto eléctrica, el motor evalúa las reglas de enclavamiento. Las tres centrales, como están en la documentación de arquitectura:

• el seccionador al lado de un disyuntor solo se maniobra con ese disyuntor abierto;
• la puesta a tierra abre siempre, pero solo cierra con el circuito desenergizado y el seccionador de aislamiento abierto;
• el disyuntor abre siempre, pero solo cierra con los dos seccionadores de al lado cerrados y con toda puesta a tierra que alcanzaría explícitamente abierta.

La tercera regla tiene un detalle de implementación que vale la explicación. Para saber qué puestas a tierra alcanzaría el disyuntor, el motor arma el grafo como si el disyuntor candidato ya estuviera cerrado y busca puestas a tierra en ese camino hipotético. Una puesta a tierra ausente o pendiente en ese camino bloquea el cierre.

Cuando la maniobra se rechaza, nada cambia: ni la posición, ni el plan, ni la condición simulada. La pantalla muestra el motivo y el código de la regla violada, y el mismo código va a atributos de la página, para que la información no dependa solo del color. Cuando la maniobra se acepta, una posición cambia y exactamente un paso entra en el plan.

Quién arma la secuencia de maniobra

La versión anterior de este texto decía que el sistema proponía por sí solo la secuencia de seguridad entre dos puntos. No es lo que hace el código, y la diferencia importa.

El plan de maniobras nace de las maniobras que el usuario ejecuta: cada maniobra efectiva se vuelve un paso, y el plan es una lista que se edita. Sobre eso, el sistema ofrece tres ayudas, todas con una persona al mando:

1. Previa de liberación. En el banco de ensayo, un robot determinista (las conexiones, el registro y las reglas registradas definen lo que propone) calcula una previa para el objetivo elegido, dentro del perímetro que el autor declaró: abrir los disyuntores, después los seccionadores, después cerrar las puestas a tierra. Si el perímetro está incompleto, la previa se rechaza. Calcular la previa no ejecuta nada: quien ejecuta es el usuario, paso a paso o en secuencia.
2. Autoría asistida de línea. Al dibujar una línea de transmisión con los dos extremos en el mismo dibujo, el autor puede pedir una propuesta de reglas de enclavamiento. La acepta o la rechaza. El sistema no deduce la función de un equipo por su nombre y no crea posiciones ni presume energización.
3. Guion guiado. Es consultivo: se deriva de las reglas y nunca ejecuta equipo ni escribe en el plan.

Varias subestaciones, un solo plan

Una maniobra real rara vez se queda en una sola subestación: desconectar una línea involucra los dos extremos. Para eso, todo elemento ganó una referencia global, formada por la subestación y por su identificador, y el plan pasó a pertenecer al estado global, no a una de las subestaciones.

Las conexiones entre subestaciones son estructurales y nunca sirven de comando remoto. Guardar una copia del estado del otro extremo está prohibido. El contrato existe para un escenario que el simulador necesita mostrar: el operador desconecta el terminal remoto, cree que la línea murió, y sigue viva por el terminal local, con el interruptor de línea cerrado.

Los archivos de afuera no ganan poder

El editor importa y exporta diagramas en JSON, y la importación se trata como entrada no confiable. El archivo entero se valida en una copia temporal, y solo un candidato seguro sustituye el borrador. Un JSON importado no puede dar capacidad de maniobra a un elemento ni falsificar la topología. Los nombres reservados como __proto__ se rechazan, y ningún texto importado o tecleado lo ejecuta la página.

La distribución sigue la misma línea. El paquete es un ZIP portátil, con accesos directos para abrir el archivo directamente o servir la aplicación solo para la propia máquina, y un manifiesto con los hashes SHA-256. No instala un programa y no envía archivos por internet.

Incidentes que se volvieron regla

El primer diagrama completo se construyó en cinco rondas, el 07 y el 08/08/2026, y los errores de esas rondas se volvieron una guía para los diagramas siguientes. Otros vinieron después.

1. La barra tratada como fuente. Fue el error más grave y el más persistente: sobrevivió tres rondas. Con la barra encendida por su cuenta, el diagrama mostraba tensión donde no la había. Regla: las fuentes son las líneas, y la barra solo se energiza por un camino cerrado hasta una de ellas. Con todas las líneas afuera, el diagrama entero queda blanco, que es el comportamiento real.
2. El disyuntor cerrado idéntico al abierto. En la segunda ronda, los colores de posición y de tensión se mezclaron, y un disyuntor cerrado quedó visualmente igual a uno abierto. Regla: forma para la posición, color para la tensión.
3. Un booleano para dos lados. El trazo de la línea aparecía vivo después de un interruptor abierto, porque una sola variable representaba los dos lados del seccionador. Regla: todo interruptor de línea es una frontera de dos lados.
4. La puesta a tierra exigida para reconectar. Tratar la puesta a tierra y el seccionador como una sola cosa hizo que el modelo exigiera la puesta a tierra cerrada para reconectar el disyuntor, lo opuesto de lo correcto. Regla: la puesta a tierra tiene regla propia.
5. La suite en verde con el enclavamiento invertido. Ocurrió dos veces: todas las pruebas pasaban con una regla al revés, porque comprobaban la regla tal como había sido escrita, no la secuencia que hace el operador. Regla: la prueba nace del guion del operador, no del código. Es la forma más peligrosa de falla silenciosa: la señal verde existe, y la protección no.
6. Dieciséis conductores olvidados. Un script que desconecta todas las fuentes y lista lo que sigue oscuro encontró 16 conductores sin la marcación de tramo, que ninguna prueba atrapaba.
7. La corrección de layout que empeoró todo (01/09/2026). Una corrección de layout hecha sin antes escribir el caso de aceptación del rango de pantalla afectado cambió un defecto por otro peor, y la suite de aceptación pasó porque solo visitaba dos resoluciones. Regla: la prueba del rango entra en el mismo commit de la corrección.
8. La omisión que se volvía permiso (23/10/2026). Un valor predeterminado hacía que todo activo sin titular declarado se tratara como propio. Regla: propiedad declarada por activo; la omisión no puede volverse permiso.

También hubo un problema de desempeño: un selector de estilo hizo que el costo de cada redibujado del diagrama subiera cerca de 16 veces, y se resolvió marcando el atributo por código, sin diferencia visual.

Pruebas: verde que no sabe ponerse rojo

Las pruebas usan el ejecutor nativo de Node, y las de interfaz abren un Chromium real. Sin el navegador, la batería reprueba, en lugar de aprobar sin probar. El 19/10/2026 el comando principal registró 1.371 pruebas, todas aprobadas, en cerca de 22 minutos. El mismo día, una ronda anterior se había detenido con 8 fallas antes de llegar a ese resultado.

Además de la suite, hay baterías de escenario. La mayor consolida 485 escenarios y 18 combinaciones mínimas, y observó los 24 códigos de regla aplicables a la subestación de referencia. Dentro del propio editor, el botón Probar corre los casos de una línea en una copia aislada del dibujo; uno de los ejemplos reúne 140 casos.

La regla que el proyecto escribió para sus propias pruebas es la mejor lección del caso: una verificación que no sabe ponerse roja no es verde. Toda comprobación nueva tiene que probarse por mutación, rompiendo a propósito lo que debería atrapar y viéndola reprobar.

Situación: sin aceptación, y escrito así

El 20/08/2026, una nota de versión interna se declaró “Release Candidate Homologado”. La documentación posterior desmiente ese sello, y el sitio del autor repetía “terminado y homologado” hasta esta revisión. El estado real, verificado en los registros:

• hubo aceptaciones parciales: el banco completo y la primera subestación piloto fueron aceptados por el autor el 29/09/2026;
• en la reevaluación del 16/10/2026, el producto quedó como no aprobado;
• el 20/10 el trabajo se pausó, sin aceptación del producto y sin continuación automática, y el 25/10 la ronda en curso cerró como bloqueada, por decisión del autor;
• toda publicación local lleva el sello “LOCAL / NO HOMOLOGADO”, y la publicación para la organización no existe;
• hospedaje, identidad institucional y publicación operativa quedan para etapas siguientes.

La memoria del proyecto llegó a describir un lote de modelos como “100% terminado y validado”; hoy ese lote está registrado como candidato no calificado. Escribir el estado como es forma parte del producto: un simulador de seguridad que se declara listo sin estarlo enseña lo incorrecto.

Lo que todavía no está resuelto

• Aceptación del producto. No existe, y ninguna versión fue marcada en Git.
• Uso en capacitación. El repositorio no registra grupos ni operadores capacitados; el texto no afirma ganancia de aprendizaje.
• Alcance del motor. Sin flujo de potencia y sin propagación entre subestaciones, el simulador enseña la lógica del enclavamiento, no el comportamiento eléctrico completo de la red.
• Autoría de línea. El ensayo admite un disyuntor por extremo y exige los dos extremos en el mismo dibujo.
• Tiempo de la suite. Veintidós minutos por ronda pesan en el ciclo de cambio.

Lecciones que valen fuera de la subestación

1. Separe las dimensiones del estado. Posición, energía y autorización responden a preguntas distintas.
2. Lo desconocido es un estado, no un vacío. Marque, propague y bloquee.
3. La interfaz proyecta; el motor decide. Una regla que solo existe en la pantalla no es regla.
4. El rechazo no cambia nada. Una maniobra negada no puede dejar rastro en el plan.
5. Pruebe a partir del guion de quien opera, no del código que usted acaba de escribir.
6. Pruebe que la comprobación falla antes de confiar en que pasa.
7. Sello de listo solo con aceptación. La autodeclaración envejece mal.

Fuentes

• Código, documentación, decisiones de arquitectura, incidentes y registros de prueba: repositorio del Simulador de Maniobras en la versión del 27/10/2026, leído por el autor; extracto con los fragmentos, el método del conteo y los límites de la verificación, verificado el 2026-10-30.