Simuladores — /simulators

Configurar una integración de planta suele chocar con un problema de agenda: el PLC está en la línea de producción, el PI System es de otro equipo, y nadie libera pruebas en el equipo en horario productivo. El CMS resuelve esto trayendo los servidores dentro de sí mismo.

Son tres, en pestañas separadas:

Sirven para:

• validar la configuración de una Recolección o Entrega antes de tener acceso al equipo;
• reproducir un escenario de error en ambiente de prueba, cuantas veces sea necesario;
• demostrar el flujo completo sin depender de la fábrica;
• entrenar a quien va a operar, sin riesgo de escribir en un equipo real.

Lo que los tres tienen en común

La Conexión Externa aparece sola

Al habilitar un simulador, el CMS crea y mantiene la Conexión Externa correspondiente — “OPC Simulator (interno)”, “Modbus Simulator (interno)”, “PI Simulator (interno)”. Aparece normalmente en Conexiones Externas y puede elegirse en una Aplicación, una Recolección o una Entrega como cualquier otra. No hay dirección que escribir, ni riesgo de escribirla mal.

Deshabilitar el simulador no borra la conexión: simplemente deja de responder.

Perfiles: guardar escenarios enteros

Los tres simuladores trabajan con perfiles — instantáneas nombradas del conjunto de tags. En vez de volver a registrar tag por tag para cada prueba, guarda “Prensa 3”, “Planta Norte”, “Escenario de falla” y alterna entre ellos.

Aplicar y sobrescribir piden confirmación, porque los dos cambian un conjunto entero de tags de una vez.

Los perfiles entran en el import/export de configuración de la Danger Zone — cada simulador con su dominio propio. Así es como un escenario armado en la máquina de quien configuró llega al ambiente de demostración.

Cualquier cambio reinicia el servidor

Guardar una tag, aplicar un perfil o cambiar el puerto reconstruye el servidor desde cero. Es deliberado: tocar el address space “en vivo” sería más complejo y más propenso a estado inconsistente — y aquí no estamos en un camino de producción. Los cambios se agrupan en una ventana corta, así que guardar cinco tags seguidas provoca un reinicio, no cinco.

OPC UA Simulator

Servidor OPC UA completo, servido por el propio cms-api. Expone una variable por tag registrada.

Configuración

El pie muestra el estado real: Corriendo en el puerto N o Apagado, y el error cuando el puerto ya está en uso.

El servidor escucha solo en 127.0.0.1, dentro de cms-api: las Recolecciones y Entregas del propio CMS lo alcanzan, un cliente de afuera (UaExpert, otro servidor de la red) no. Es a propósito — el simulador es anónimo y tiene tags escribibles.

Tags de prueba

Cada tag tiene nombre, NodeId, tipo de dato y valor actual:

• Tipos — BOOLEAN, INT16, INT32, FLOAT, DOUBLE, STRING.
• NodeId — sigue el formato ns={ns};s=NombreDeLaTag, sugerido automáticamente desde el nombre.
• Valor actual — editable en la propia lista, con un botón que graba al instante. En una tag BOOLEAN ese botón se llama Disparar; en los demás tipos, Guardar.

Ese botón es lo que hace al simulador realmente útil: una Recolección OPC_UA_TRIGGER queda suscrita a la tag, y usted provoca el disparo cuando quiera, sin esperar un ciclo de máquina.

Modbus Simulator

Esclavo Modbus TCP integrado. A diferencia de OPC UA, Modbus no tiene modelo de objetos: el protocolo opera sobre cuatro vectores de registros crudos, direccionados por número.

Las cuatro tablas

La dirección de una tag se escribe como Tabla:Dirección — por ejemplo HOLDING_REGISTER:40.

Tipos de dato y orden de palabras

Como el registro Modbus tiene 16 bits, los valores mayores ocupan dos registros consecutivos. Las tags declaran:

• Tipo — BOOLEAN, INT16, UINT16, INT32, UINT32, FLOAT32.
• Orden de palabras — BIG_ENDIAN o LITTLE_ENDIAN, para los tipos de 32 bits.

La capa de tags del simulador es una conveniencia de la pantalla — nombre y tipo por encima de los registros crudos. Lo que el maestro ve son los registros.

PI Simulator

Imitación del PI Web API de AVEVA PI System (ex-OSIsoft). Es el único de los tres que no levanta puerto nuevo: el PI Web API es REST, así que el simulador es un endpoint dentro de la propia API del CMS, en /api/pi-sim/piwebapi. Solo el propio CMS llega a él: en el borde (nginx) la ruta responde 404, porque el simulador acepta lectura y escritura sin autenticación.

Tags que varían solas

Esta es la diferencia central respecto a los otros dos simuladores. Un PI System guarda series temporales: preguntar “cuál es el valor ahora” es menos interesante que preguntar “cómo fue en la última hora”. Por eso cada tag tiene un comportamiento, y el valor se calcula en función del tiempo:

Los parámetros son valor base, amplitud y período (s). Cada tag tiene además nombre, descripción, unidad y tipo de punto (Float32, Float64, Int32, Digital, String).

Como el valor se calcula, y no se almacena, las consultas de historial funcionan para cualquier intervalo — incluso antes de que el simulador existiera. No hay serie que poblar.

Regenerar WebIds

En PI, todo objeto se direcciona por un WebId opaco, que el CMS resuelve a partir de la ruta de la tag y guarda. Cuando las tags se recrean en PI, o el servidor se migra, esos WebIds dejan de valer y el cliente necesita re-resolver las rutas por su cuenta.

El botón Regenerar WebIds provoca exactamente eso: invalida de una vez todos los WebIds ya entregados. Sirve para probar que el CMS se recupera sin que nadie edite ninguna Recolección — un escenario que en un PI real sería caro y riesgoso de reproducir.

Fidelidad al producto real

El simulador reproduce el contrato REST del PI Web API, incluyendo detalles que suelen atrapar a quien integra:

• exige el header X-Requested-With, como el PI real, que devuelve 401 sin él;
• la consulta por path devuelve el objeto directo, no una colección;
• un WebId obsoleto responde 404, y no un error genérico;
• las respuestas de historial están limitadas a 5.000 muestras.

Lo que no reproduce es la autenticación: acepta cualquier credencial, o ninguna — como un PI de laboratorio abierto. Ver PI Web API.

Escritura en equipo: el gate de permiso

Escribir en una tag OPC UA o en un registro Modbus altera el estado de un equipo real. Por eso las Entregas OPC_UA_WRITE y MODBUS_WRITE aceptan configurar una tag de permiso de escritura en el propio equipo: el CMS se suscribe a esa tag y solo graba mientras ella tenga el valor esperado.

Es el PLC, y no el CMS, quien decide cuándo aceptar escritura — el único orden correcto de esa decisión. Sin la tag configurada, la Entrega graba siempre que reciba un mensaje.

Fallar sin conseguir preguntar

Una Entrega con gate configurado cuya suscripción de la tag no está en pie responde no — nunca “no hay restricción”. La diferencia parece sutil y no lo es: hasta agosto de 2026 el gate OPC UA respondía leyendo la existencia de la sesión, y “gate configurado, pero no conseguí conectar” llegaba allí con la misma cara de “esta Entrega no tiene gate”. El resultado era el peor posible — fallar en verificar si el PLC podía recibir liberaba la escritura en el PLC. Hoy los dos gates, OPC UA y Modbus, fallan cerrados.

La conexión del gate también vuelve a intentar sola, con espera creciente de 2s a 20s, y la caída dispara CONEXAO_OPCUA_PERDIDA o CONEXAO_MODBUS_PERDIDA. Antes, una falla en el primer intento dejaba la Entrega sin gate hasta que alguien reiniciara la API.