¿La convergencia IT/OT es solo una palabra de moda? Desentrañando su verdadero valor

Entonces, ¿es la «convergencia IT/OT» solo otro término de moda engañoso?

Podrías argumentar que sí. Cada vez que alguien capta una nueva idea, hay un intento de hacerla memorable y hacer que suene como «la mejor novedad desde el pan de molde». Así que, por supuesto, alguien va a inventar una frase pegadiza que supuestamente inspire cambio y que pueda usar para marketing.

Lo cierto es, sin embargo, que esta «convergencia» de IT y OT es realmente solo la siguiente extensión de hacer los datos utilizables.

¿Qué es la convergencia IT/OT?

Hace un tiempo, vimos el inicio de la automatización en fabricación. El equipo automatizado fue diseñado para realizar una función específica que necesitaba realizarse a una velocidad o nivel de potencia que los humanos no podían lograr. Pero cuando el equipo automatizado fallaba, el ingeniero de control necesitaba entrar en el sistema para determinar qué falló. Esto requería entrar en los registros de los sistemas PLC para buscar pistas del fallo. Este fue el inicio del uso de datos de tecnología operacional (OT).

Tener algunos datos previos al punto de fallo era bueno para diagnóstico —para ver qué pasó antes. Como resultado, los sistemas PLC empezaron a usar historiadores para retener flujos de datos más largos de sensores, calentadores y actuadores de automatización —usando grandes cantidades de datos OT.

Al monitorizar los datos OT de historiadores, las funciones SCADA podían proporcionar a operadores cierta visión de cómo operaba el equipo. Cuando un fallo era inminente, las funciones SCADA permitían a operadores (o supervisores) una oportunidad de actuar antes de que ocurriera el fallo. Esto requería que el sistema SCADA tuviera acceso a los datos de historiadores, y usaba comunicaciones propietarias como MODBUS o PROFIBUS para hacer esos datos disponibles a operadores vía interfaces hombre-máquina (HMI). Pero la monitorización era exclusiva al rendimiento del equipo, expandiendo aún más el uso de datos OT.

A través de la observación de estos flujos de datos (medidores, pantallas de operador, etc.) y entendiendo más sobre la deriva de los datos, se podía reconocer —vía los sistemas SCADA— no solo cuándo el fallo de equipo era inminente, sino que los datos también podían usarse para analizar fallos en calidad de producto en prueba e inspección —operaciones que pueden haber sido varios pasos más tarde en el proceso.

Esto creó la necesidad de tener datos OT vinculados con datos IT. Resultó en la creación de interfaces complejas desde PLCs y SCADA a sistemas de tecnología de la información (IT) como MES, permitiendo que datos relacionales de fallo de producto se vincularan a datos operacionales del equipo que fabrica el producto. Algunos lo intentaron directo a ERP también (y siguen intentándolo), pero los sistemas ERP no están equipados para procesar y presentar esos datos lo suficientemente rápido y con suficiente detalle en relación a otros eventos durante el proceso de fabricación.

El problema con las interfaces a MES es que son altamente personalizadas y caras, a veces añadiendo hasta un 40-50% del coste de implementación de un proyecto. El siguiente paso en la mejora del acceso a datos sería hacer los datos PLC más accesibles a MES y otras bases de datos relacionales. Cuando esta necesidad de acceso se combina con el coste de computación y memoria de computadora volviéndose más baratos y la comunicación de red volviéndose más estable (entran las redes 5G), tuvo sentido conectar los sensores y actuadores PLC directo a redes IT (lo que llamamos IIoT) y hacer sus datos disponibles a... quien los necesitara.

Todo este trasfondo es para resaltar que hacer los datos OT más fácilmente disponibles a sistemas IT es simplemente el siguiente paso en un proceso más largo de la evolución tecnológica que nos trajo a la Industria 4.0.

¿Cómo puede usarse la convergencia IT/OT?

La interconexión de datos OT a sistemas IT ahora encontró un nuevo problema.

Los sistemas PLC/SCADA que monitorizan sensores en historiadores pueden crear grandes flujos de datos (hasta megabytes de tamaño) en segundos. Desde la perspectiva de entender la caracterización de un evento de vuelta a los sistemas IT, sin embargo, este flujo de datos —incluso en pequeños marcos temporales— es simplemente demasiado para las bases de datos relacionales de sistemas IT como MES. Muchas implementaciones han intentado registrar una instancia de datos de sensor (tomada de un flujo de datos) para capturar un solo elemento de datos, intentando alguna representación de eventos OT a nivel IT. Muchos han encontrado, sin embargo, que vincular una instancia de datos OT a un evento de calidad de un producto durante la fabricación no es muy efectivo para monitorizar la calidad de un proceso en general.

Ahora necesitamos determinar formas de agregar flujos de datos de sistemas OT de una manera que retenga las características importantes de un evento de producción. El reporte de OEE es uno de estos intentos de agregación. Es importante reconocer que al usar cualquier forma de agregación de datos, va a haber alguna pérdida de los detalles importantes de un evento de calidad. Por eso el OEE se usa como objeto de datos de nivel de monitorización y no de nivel de análisis. Sin embargo, al monitorizar el valor en tiempo real del OEE cambiando, un sistema IT puede reconocer la tasa y magnitud de los cambios y crear una alarma para alertar sobre un problema.

Para analizar ese problema real, necesitarás volver al flujo de datos original que se usó para crear el valor OEE. Al menos con el valor OEE proporcionado en tiempo real, los ingenieros de fabricación y control ganan visibilidad sobre un problema lo suficientemente temprano para que puedan volver al historiador para análisis antes de que el evento sea enterrado por más datos del flujo de datos OT.

El problema es: ¿cómo agregas los datos?

La respuesta, como siempre, es... ¡depende!

Cómo agregar los datos dependerá de qué datos estás agregando y qué intentas monitorizar dentro del proceso. También dependerá de ser capaz de interpretar cambios en el modelo de agregación de datos.

En esta sección, analizaré un método de agregación y presentaré algunas formas de interpretar cambios en este conjunto de datos.

La «curva de distribución natural» o histograma es una de las representaciones gráficas más comunes de datos de dispositivos como sensores. La premisa principal de la curva es que, si solo hay variación aleatoria normal en un proceso, la distribución de las instancias de datos caerá en un patrón que se asemeja a una curva de distribución natural.

La Figura 1 muestra cómo podría verse la distribución de lecturas de un sensor de horno con variación normal cuando se grafica en un histograma.

Figura 1: Curva de distribución de temperatura de horno mostrando media, mediana y moda. Cortesía del autor.

Las características clave de la curva son que la media (promedio), mediana (valor medio del flujo de datos) y la moda (valor con más ocurrencias) son todas aproximadamente iguales. Esto puede usarse como referencia para determinar si el proceso está experimentando problemas. Mientras haya indicación de que el proceso está en control, hay valor en determinar los valores +/- 3 sigma y compararlos con los límites de control superior e inferior y los límites de especificación del producto.

Un escenario de ejemplo

Para monitorizar el proceso de una unidad de producción pasando por un horno de curado, el sistema MES tomaría nota del tiempo que la unidad entró y salió del horno. Durante este tiempo, el sistema PLC (usando un sensor inteligente) crearía un flujo constante de datos de sensor de temperatura que se almacenaría en una base de datos de historiador local en el dispositivo sensor. Cuando la unidad de producción saliera del horno, el MES haría una petición al dispositivo para un agregado de los datos de temperatura durante ese período definido. Incluso con potencia de computación limitada disponible a nivel de dispositivo, el dispositivo podría tomar cientos (o incluso miles) de puntos de datos y proporcionar un conjunto de datos agregados de vuelta al MES —en lugar de proporcionar una sola instancia del dato del sensor, como es típico, o intentar procesar el flujo de datos completo.

Lo siguiente sería un conjunto de valores de datos agregados para esta unidad de producción:

• Media: 90.0
• Mediana: sería muy cercana a 90.0
• Moda: aproximadamente 90.0 grados también
• +/- 3 Sigma distribución: 87.0, 93.0 (por verificar con LSC y LIC)

Haciendo un análisis rápido de las diferencias entre la media, mediana y la moda, el MES puede buscar monitorización de control de proceso aceptable así como tendencias de cambios desde unidades de producción previas que ya pasaron por el horno. Si los valores +/- 3 sigma están más allá de límites aceptables, el MES marcaría automáticamente la unidad de producción como sospechosa, del mismo modo si la media, mediana o moda difieren significativamente entre sí o de productos previos.

La Figura 2 presenta un ejemplo de cómo estos mismos valores indicarían un proceso que no estaba en control. En este caso, sin embargo, aún es posible que los valores +/- 3 sigma estén dentro de límites.

Figura 2: Diferencias de ejemplo de media, mediana y moda en un proceso sesgado. Cortesía del autor.

Ahora, técnicamente, si la distribución está sesgada como se muestra, los valores +/- 3 sigma pueden no considerarse válidos como resultado de la naturaleza sesgada del conjunto de datos. Pero el análisis inmediato por el dispositivo aún puede usarse para determinar si los límites de control han sido violados.

El punto clave: si este es el tipo de conjunto de datos proporcionado por un sensor inteligente, es una indicación para la ingeniería de fabricación de que el horno no está operando con solo varianza aleatoria —y por tanto debería investigarse.

Otras diferencias en media, mediana y moda (p. ej., la media y mediana son iguales, pero la moda es diferente) también pueden indicar condiciones como una distribución bi-modal que sugieren múltiples influencias de proceso en juego. Una vez más, la ingeniería de fabricación debería investigar el proceso.

Cuando los conjuntos de datos anteriores se vinculan directo a la unidad de producción a nivel MES, estos datos pueden usarse —con resultados de prueba e inspección— para indicar si hay un vínculo entre variación en temperatura del horno y el fallo de la unidad de producción.

Ya sea que el producto fallara como resultado de los problemas de proceso o no, ver valores de datos derivar durante una corrida de producción también puede indicar problemas fundamentales de gestión de proceso que necesitan investigarse.

Resumen

Los ejemplos previos de agregación de datos solo reflejan un escenario específico, pero pretenden proporcionar una visión de las razones para la convergencia de datos OT e IT así como el valor potencial de esta convergencia. En cada escenario de producción, el método correcto de agregación de datos necesitaría evaluarse, y la programación de dispositivos inteligentes necesitaría hacer esta funcionalidad disponible. O, como alternativa, sistemas de edge computing se programarían para reemplazar la funcionalidad descrita para los dispositivos inteligentes.

La conclusión es que, aunque la industria usa fuertemente «convergencia IT/OT» como término de moda para describir tecnología cambiante, hay un cambio legítimo en el procesamiento de datos que la tecnología detrás del término de moda entrega. Las empresas que aprovechan la tecnología de convergencia, y que aprenden a agregar e interpretar correctamente datos presentados vía convergencia, pueden ganar ventajas prácticas en la efectividad de programas de calidad y gestión de instalaciones. En el entorno global competitivo de hoy, usar cualquier ventaja es bueno para el resultado final.

Así que la respuesta es no. La convergencia IT/OT no es solo un término de moda. Es una herramienta valiosa en la evolución de la tecnología de adquisición y gestión de datos que puede beneficiar enormemente a empresas manufactureras. Aprender cómo agregar los datos del nivel OT para que los sistemas a nivel IT puedan lidiar con ellos es una parte importante de la convergencia.