Serialización JSON para PLC en OLLA Lab

OLLA Lab serializa la lógica de escalera (ladder logic) en JSON estructurado en lugar de archivos binarios opacos. Esta representación basada en texto permite la sincronización en la nube, el seguimiento de cambios con control de versiones y el análisis automático para flujos de trabajo de validación, manteniendo la práctica de PLC dentro de un entorno de simulación acotado en lugar de un sistema de control en tiempo real.

Los archivos de proyecto propietarios de los PLC no son "seguros" simplemente porque son difíciles de leer. En la práctica, la opacidad a menudo debilita la colaboración, la auditabilidad y la recuperación, ya que la lógica queda atrapada dentro de formatos binarios específicos del proveedor.

En OLLA Lab, los diagramas de escalera se almacenan como esquemas JSON estructurados que pueden transmitirse, analizarse y reconstruirse en un entorno basado en navegador. Durante el benchmarking interno en la nube de Ampergon Vallis en el tercer trimestre de 2025, la serialización de 25 proyectos de OLLA Lab, que oscilaban entre 20 y 100 peldaños (rungs), produjo una reducción media de la carga útil del 82% frente a la línea base interna equivalente en binario de la plataforma, mientras que el análisis del esquema del proyecto completo por parte del asistente Yaga se completó en menos de 400 ms para el caso de prueba de 100 peldaños [Metodología: n=25 exportaciones de proyectos; definición de la tarea = serializar y transmitir el estado completo del proyecto de escalera; comparador de línea base = objeto de almacenamiento equivalente en binario interno de Ampergon Vallis utilizado para pruebas de arquitectura; ventana de tiempo = Q3 2025]. Esto respalda una afirmación sobre la eficiencia del transporte y la velocidad de análisis dentro de la propia arquitectura de OLLA Lab. No respalda una afirmación universal sobre todo el software de PLC.

El punto principal es sencillo: la lógica basada en texto es más fácil de versionar, inspeccionar, recuperar y validar. Los blobs binarios son excelentes para ser blobs. Eso no es lo mismo.

Los archivos binarios propietarios limitan el control de versiones porque almacenan la lógica de control como datos opacos orientados a la máquina en lugar de texto direccionable por líneas. Los sistemas de control de fuentes estándar, como Git, funcionan mejor cuando pueden comparar cambios textuales discretos, no cuando un archivo completo parece cambiar de una sola vez.

En muchos entornos de PLC heredados, un archivo de proyecto es efectivamente un contenedor compilado. Si un ingeniero cambia un valor preestablecido de temporizador y otro cambia un contacto permisivo, Git a menudo no puede identificar esas ediciones como deltas lógicos separados. Ve un único artefacto binario alterado. La calidad de la fusión (merge) cae inmediatamente.

Esto crea varias limitaciones prácticas:

- Poca visibilidad de las diferencias (diff): las herramientas de comparación de texto estándar no pueden mostrar qué cambió a nivel de peldaño o instrucción. - Comportamiento de fusión débil: las ediciones concurrentes son más difíciles de conciliar sin herramientas específicas del proveedor. - Auditabilidad limitada: los revisores pueden saber que un archivo cambió, pero no exactamente cómo. - Portabilidad reducida: el proyecto se vuelve dependiente de un IDE y un analizador de archivos específicos. - Usabilidad de IA frágil: los modelos de lenguaje grandes y los validadores basados en reglas no pueden inspeccionar de forma nativa las estructuras binarias propietarias.

Una distinción útil es la integridad del archivo frente a la inteligibilidad de la ingeniería. Un archivo binario puede abrirse correctamente y seguir siendo operativamente inútil para su revisión.

Blobs binarios frente a la serialización JSON en automatización

| Propiedad | Archivo binario propietario | Lógica serializada en JSON | |---|---|---| | Legibilidad humana | Mínima o nula | Legible con conocimiento de la estructura | | Comparación (diff) estándar en Git | Pobre | Sólida | | Soporte de rama/fusión | Limitado | Más sólido, dependiendo de la disciplina del esquema | | Análisis mediante IA | Típicamente indirecto o no disponible | Analizable directamente | | Independencia del proveedor | Baja | Mayor a nivel de estructura de datos | | Diagnóstico de corrupción | Más difícil de aislar | Más fácil de inspeccionar y recuperar selectivamente | | Transporte en la nube | A menudo más pesado y dependiente de herramientas | Sin estado y compatible con la web |

Esto no significa que el almacenamiento binario sea ilegítimo. Significa que el almacenamiento binario está mal alineado con los flujos de trabajo modernos de revisión de software. La tecnología operativa (OT) ha vivido con ese desajuste durante años porque no tenía otra opción.

OLLA Lab traduce la lógica de escalera almacenando el diagrama como objetos de datos estructurados en lugar de como una imagen plana o un blob de proyecto opaco. Un peldaño se representa a través de entidades anidadas como instrucciones, enlaces de etiquetas (tags), estados, parámetros y metadatos de diseño.

Cuando un usuario coloca una instrucción en el editor del navegador, la plataforma registra propiedades observables, incluyendo:

• tipo de instrucción,
• referencia de etiqueta (tag),
• dirección o identificador,
• valores de parámetros,
• posición del peldaño,
• estado relevante para la ejecución,
• y contexto del escenario asociado cuando corresponda.

Eso importa porque el objeto guardado no es simplemente un dibujo. Es una representación legible por máquina de la intención de control.

### Ejemplo: representación JSON a nivel de instrucción

instruction: { "type": "XIC", "tag": "Pump_Start_PB", "address": "I:0/1", "state": false }

Un esquema de proyecto más completo incluiría normalmente objetos adicionales para:

• orden de los peldaños,
• relaciones de ramificación,
• instrucciones de salida,
• valores preestablecidos de temporizadores o contadores,
• valores analógicos,
• parámetros PID,
• enlaces de escenarios,
• y capturas de estado de simulación.

Lo que esto significa en la práctica

Si un estudiante construye un peldaño de enclavamiento para un arrancador de motor, OLLA Lab puede almacenar tanto la estructura lógica como el contexto de simulación relacionado. Eso permite a la plataforma reconstruir el proyecto en el editor, ejecutarlo en modo de simulación y exponer el mismo estado al panel de variables y al asistente de IA.

Aquí es donde OLLA Lab se vuelve operativamente útil. La plataforma no está preservando una captura de pantalla de la lógica; está preservando un modelo de datos que otros componentes del sistema pueden interrogar.

En este artículo, el almacenamiento de lógica de escalera nativo de la nube significa que la lógica puede serializarse en esquemas basados en texto, transmitirse sin estado a servicios remotos, almacenarse independientemente de una estación de trabajo de ingeniería local y reconstruirse bajo demanda en un entorno accesible mediante navegador.

Esa definición es más estrecha que la versión de marketing que suele aparecer habitualmente. Estamos discutiendo la arquitectura de almacenamiento y transporte, no una propiedad mística de la virtud del software.

Un modelo de almacenamiento nativo de la nube para la lógica de escalera incluye normalmente:

- transmisión sin estado: el estado del proyecto se envía como datos, no como contexto de memoria de la estación de trabajo; - persistencia remota: los archivos del proyecto residen en un almacenamiento en la nube gestionado en lugar de solo en una máquina local; - reconstrucción en navegador: el editor puede reconstruir el diagrama a partir de objetos serializados; - interoperabilidad de servicios: los servicios de IA, calificación, intercambio y simulación pueden consumir el mismo esquema; - flexibilidad de dispositivos: los usuarios pueden acceder al mismo proyecto a través de escritorio, tableta, móvil o entornos XR compatibles.

En OLLA Lab, esta arquitectura soporta un editor de escalera basado en web, flujos de trabajo de simulación, formación basada en escenarios y asistencia guiada sin requerir que el estudiante gestione pilas de ejecución (runtime) de proveedores locales solo para practicar el comportamiento lógico.

Esa es una ventaja de formación y validación, no una afirmación de que las herramientas de navegador reemplazan a todas las suites de ingeniería de los proveedores. La distinción es importante.

El almacenamiento de PLC basado en texto permite prácticas de revisión y colaboración al estilo del software que son difíciles de aplicar a archivos de proyecto opacos. Las principales ventajas son la comparación (diffing), la ramificación (branching), la capacidad de recuperación y la validación asistida por máquina.

1. Comparación (Diffing)

Un diff es una comparación a nivel de línea entre dos versiones de un archivo. En un proyecto de escalera respaldado por JSON, un revisor puede identificar si el cambio involucró:

• un valor preestablecido de temporizador,
• un tipo de contacto,
• un enlace de etiqueta (tag),
• un umbral analógico,
• o un parámetro de secuencia.

Eso es materialmente mejor que "el archivo cambió". La revisión de ingeniería necesita algo más que un encogimiento de hombros.

2. Ramificación (Branching)

La ramificación permite a un usuario o equipo probar estrategias de control alternativas sin sobrescribir la versión de trabajo actual. En la formación y el ensayo con gemelos digitales, esto es especialmente útil para comparar:

• lógica permisiva alternativa,
• revisiones de manejo de fallos,
• ajustes de banda muerta de alarmas,
• opciones de secuenciación principal/secundaria,
• o experimentos de ajuste PID.

3. Capacidad de recuperación

Los esquemas basados en texto son más fáciles de inspeccionar y recuperar parcialmente cuando algo sale mal. Si un objeto de proyecto está mal formado, el fallo a menudo puede aislarse en una sección específica del esquema en lugar de hacer que todo el archivo sea ilegible.

4. Colaboración sin bloqueo rígido de archivos

Un flujo de trabajo en la nube estructurado puede soportar la revisión multiusuario y la retroalimentación del instructor de forma más limpia que las transferencias de archivos locales. Las funciones de intercambio y calificación de OLLA Lab se asientan sobre este beneficio arquitectónico.

5. Mejores flujos de trabajo de validación

Un esquema legible por máquina puede verificarse en cuanto a consistencia antes de la implementación o antes de la ejecución de la simulación. Los ejemplos incluyen:

• referencias de etiquetas faltantes,
• enlaces duplicados,
• rangos de parámetros no válidos,
• estructuras de peldaños incompletas,
• o desajustes de escenarios.

Esto es adyacente a la idea más amplia de Infraestructura como Código: tratar la configuración del sistema como datos inspeccionables y versionados. En OT, el principio es útil, pero la implementación debe seguir siendo disciplinada. Una parada de planta causada por una elegante higiene de Git seguiría siendo una parada de planta.

La serialización JSON hace que OLLA Lab sea apto para IA porque los sistemas de IA requieren entradas de texto estructurado, no contenedores de proyectos binarios propietarios. Un modelo de lenguaje, un motor de reglas o un servicio de validación pueden analizar claves, relaciones y valores JSON directamente.

Cuando un usuario le pregunta a Yaga por qué una bomba no arranca, el asistente no infiere el estado de control a partir de píxeles en una pantalla. Se le puede proporcionar la estructura del proyecto serializada, los estados actuales de las etiquetas y el contexto del escenario. Esa es la diferencia entre la interpretación de imágenes y el razonamiento consciente del esquema.

Apto para IA, definido operativamente

En este contexto, apto para IA significa:

• la lógica de control existe en un formato de texto estructurado,
• las etiquetas relevantes y los tipos de instrucción están representados explícitamente,
• el estado actual de la simulación puede adjuntarse al esquema lógico,
• y el paquete resultante puede analizarse lo suficientemente rápido como para soportar una retroalimentación interactiva.

Eso respalda varios casos de uso acotados:

• identificar un `XIO` bloqueante o un permisivo falso,
• detectar una ruta de enclavamiento no activada,
• señalar el uso inconsistente de etiquetas,
• explicar el comportamiento de un temporizador,
• revisar la lógica de umbral analógico,
• o guiar a un estudiante a través de las causas probables de un fallo.

No significa que la IA sea una autoridad certificadora, un validador de seguridad o un sustituto de la revisión de diseño. La IA puede acelerar la inspección. No hereda la responsabilidad.

Por qué esto importa para el aprendizaje

Un estudiante que solo escribe sintaxis de escalera aún no está listo para la simulación (Simulation-Ready). En el uso de Ampergon Vallis, listo para la simulación significa ser capaz de probar, observar, diagnosticar y endurecer la lógica de control frente al comportamiento realista del proceso antes de que llegue a un proceso en tiempo real.

Eso incluye la capacidad de:

• monitorear el estado de E/S,
• comparar el estado de la escalera con el comportamiento del equipo simulado,
• inyectar fallos,
• revisar la lógica después de condiciones anormales,
• y explicar por qué la lógica revisada es más correcta.

La sintaxis es necesaria. La capacidad de implementación es la prueba más difícil.

La serialización JSON apoya la validación de gemelos digitales al proporcionar al simulador y al motor lógico una descripción compartida y legible por máquina del estado del sistema de control. El programa de escalera, los valores de las etiquetas, los enlaces analógicos y los parámetros del escenario pueden intercambiarse como datos estructurados.

Un flujo de trabajo de validación de gemelos digitales, utilizado con cuidado, no es solo "ejecutar el código en una escena 3D bonita". Operativamente, significa comprobar si la lógica de control produce el comportamiento esperado del equipo bajo condiciones normales y anormales definidas.

En OLLA Lab, eso puede incluir:

• alternar entradas discretas y observar la respuesta de salida,
• monitorear valores analógicos y el comportamiento del comparador,
• probar temporizadores y contadores frente a las expectativas de la secuencia,
• validar enclavamientos y permisivos,
• y comparar las transiciones de estado de la máquina con la filosofía de control prevista.

Esto importa porque muchos ejercicios de escalera se detienen en la corrección del peldaño. La puesta en marcha real no lo hace. La lógica tiene que sobrevivir al contacto con el comportamiento del proceso, y el comportamiento del proceso suele ser menos educado que la versión de la pizarra.

Contexto de las normas

El valor de la simulación y la validación basada en modelos en el control industrial es consistente con la literatura de ingeniería más amplia sobre gemelos digitales, puesta en marcha virtual y pruebas previas a la implementación. Las normas y directrices en seguridad funcional y práctica del ciclo de vida de los sistemas de control, incluida la IEC 61508, enfatizan la validación sistemática, la trazabilidad y la reducción de riesgos a través de actividades de verificación disciplinadas en lugar de la confianza informal solamente. Un simulador no es un certificado SIL, pero a menudo es un lugar mucho mejor para descubrir una mala suposición que un patín (skid) en tiempo real.

Los esquemas de proyectos basados en texto mejoran la exportación y la recuperación porque son portátiles, inspeccionables y más fáciles de archivar en repositorios de software estándar. En OLLA Lab, el valor práctico no es solo la copia de seguridad. Es la preservación de la evidencia.

Un estudiante o ingeniero debe exportar los proyectos de una manera que preserve tanto la lógica como la historia de validación en torno a ella.

Paquete de evidencia de ingeniería recomendado

Si desea que un proyecto demuestre su habilidad de manera creíble, no construya una galería de capturas de pantalla. Construya un cuerpo compacto de evidencia de ingeniería:

Establezca qué significa el comportamiento exitoso en términos observables: condiciones de inicio, condiciones de parada, enclavamientos, umbrales de alarma, ventanas de tiempo y respuesta ante fallos.

Documente la condición anormal introducida: prueba fallida, entrada atascada, nivel bajo, disparo por sobrecarga, condición analógica fuera de rango o tiempo de espera de secuencia.

Registre exactamente qué lógica cambió y por qué: se añadió un permisivo, se corrigió la polaridad del contacto, se revisó el valor preestablecido del temporizador, se mejoró el manejo de alarmas o se endureció el comportamiento de reinicio.

1. Descripción del sistema Defina el proceso o la máquina que se está controlando, incluyendo las principales entradas, salidas, secuencias y restricciones operativas.
2. Definición operativa de "correcto"
3. Lógica de escalera y estado del equipo simulado Preserve la versión de la lógica de escalera junto con los estados simulados relevantes, los valores de las etiquetas y las condiciones del escenario.
4. El caso de fallo inyectado
5. La revisión realizada
6. Lecciones aprendidas Resuma lo que el fallo reveló sobre el diseño original y lo que la lógica revisada maneja ahora correctamente.

Esa estructura es más persuasiva que los efectos visuales pulidos por sí solos porque muestra juicio de ingeniería. Cualquiera puede exportar un archivo. Menos personas pueden explicar por qué un caso de fallo cambió la filosofía de control.

Beneficios prácticos de recuperación

Una exportación basada en texto también admite:

• almacenamiento de archivos personales,
• historial de versiones basado en repositorio,
• revisión del instructor,
• comparación entre pares,
• y reimportación selectiva en una nueva sesión de práctica.

Nuevamente, esta es una ventaja acotada dentro de un entorno de formación y simulación. No implica una equivalencia de implementación directa con los paquetes de ejecución específicos del proveedor.

El almacenamiento de escalera basado en JSON es valioso porque convierte la lógica de escalera en datos de ingeniería inspeccionables en lugar de un artefacto de proyecto opaco. Eso permite el control de versiones, flujos de trabajo en la nube, análisis asistido por IA y una recuperación más resiliente.

Para OLLA Lab específicamente, el punto arquitectónico es más estrecho y sólido que una afirmación de revolución del software general. OLLA Lab ofrece a los ingenieros un entorno basado en web para practicar el tratamiento de la lógica de control como datos estructurados y comprobables, mientras validan el comportamiento en simulación, escenarios de gemelos digitales y flujos de trabajo de resolución de problemas guiados.

Ese es el nivel correcto de ambición. Enseña los hábitos que los equipos de automatización modernos necesitan cada vez más: trazabilidad, revisabilidad, pruebas conscientes de fallos y revisiones respaldadas por evidencia. No es glamour. Es solo una mejor higiene de ingeniería, que suele ser lo que sobrevive a la puesta en marcha.

- IEC 61508 Visión general de seguridad funcional - IEC 61131-3 Lenguajes de programación de controladores programables - NIST SP 800-207 Arquitectura de confianza cero (Zero Trust) - Tao et al. (2019) Gemelo digital en la industria (IEEE) - Kritzinger et al. (2018) Gemelo digital en la fabricación (IFAC) - Negri et al. (2017) Gemelo digital en sistemas de producción basados en CPS - Recursos de seguridad funcional de exida - Oficina de Estadísticas Laborales de EE. UU.