Sobre el autor
Carlos Behrends es director corporativo de Ventas para América del Sur de Endress + Hauser, miembro vitalicio de AADECA, miembro del comité de Honours and Awards del ISA, coordinador del grupo de trabajo de instrumentación de ABINEE.
 Figura 1. Modelo tradicional de la pirámide de automatización En 1992 el futuro de los sistemas de control abiertos era promisor: una nueva generación de sistemas de control de procesos industriales basados en estándares abiertos llegaba al mercado, y palabras o siglas como UNIX, Ethernet, API, etc., se transformaron en lenguaje común. En esa época, yo era vendedor en Foxboro, y recuerdo haber vendido una aplicación en la que conectamos una estación de trabajo del sistema de control basado en computadoras Sun, usando Unix, a una computadora DEC VAX, utilizando DECNet. Técnicamente, la integración tuvo sus desafíos (ver el cuadro “La historia detrás de la historia: por qué la integración entre IT y OT es imprescindible”), y demoramos algunos meses hasta que funcione. Una vez funcionando, permitió al usuario desarrollar una aplicación en Excel que utilizaba datos en tiempo real y le permitía hacer mas rápidamente cálculos de proceso, resultando en que esa fabrica recibió un premio mundial del grupo al que pertenecía, por su desempeño. En esa época, aplicaciones como esta eran innovadoras, y por lo menos en mi conocimiento, esa fue la primera integración entre DEC VAX y Sun UNIX para uso industrial en Argentina.
La digitalización aplicada en la industria aumenta, los sistemas de comunicación se estandarizan más y más, los dispositivos se hacen más baratos, y empezaron a aparecer caminos alternativos para los datos.
Cuando digo que el futuro era promisor, no era solo desde una perspectiva tecnológica: también me refiero al negocio, por el modelo de datos que imperaba. Tomaba forma la llamada pirámide de automatización (figura 1), un modelo que describe las funciones y flujo de datos entre tecnologías de sistemas de producción utilizados en industrias manufactureras y de procesos. En cuatro capas, el modelo incluye un nivel de campo (sensores y actuadores), el sistema de control (PLC, controladores, interfaces de usuario etc.), el sistema de gestión de producción (MEL) que analiza rendimiento, recursos empleados, gestión de calidad y procesos, etc.), y el sistema ERP (planificación de recursos empresariales, que gestiona distribución, logística, inventario, facturación, etc.). Ese modelo tiene implícita una premisa fundamental: ¡todos los datos del proceso de producción entran a la pirámide por la base! ¿Qué significaba eso para mí, vendedor de sistemas de control en 1991? Que cada dato necesario en cualquier nivel de la pirámide implicaba un punto de entrada/salida, generando ventas de tarjetas de entrada/salida, controladores, sistemas de comunicación, etc. Y considerando que ya hace veinte años las demandas de datos en tiempo real aumentaban, ¡eso podía ser muchos datos!  Figura 2. Namur Open Architecture (NOA)
Se abre un camino alternativo: NOA
En años recientes, la digitalización aplicada en la industria aumenta, los sistemas de comunicación se estandarizan más y más, los dispositivos se hacen más baratos, y empezaron a aparecer caminos alternativos para los datos. Por ejemplo, en una red Profibus utilizada para conectar sensores y actuadores al sistema de control, es posible conectar un gateway adicional, que lleva los datos a un servidor por un camino separado. Este camino puede llevar a un servidor, o genéricamente a una nube, en la que estos datos pueden ser analizados en funciones de nivel MEL (nivel de ejecución de manufactura) o ERP, sin haber pasado por el sistema de control. Los resultados del análisis pueden quedar disponibles para usuarios por medio de aplicaciones en celulares, o realimentados al ERP que hace parte formal de la pirámide. Así, ya hay aplicaciones que hacen análisis de base instalada o salud de instrumentos, por este camino alternativo.
Se genera así un nuevo modelo (figura 2), presentado en el fórum ARC de 2017 por Christian Klettner, director de Ingeniería y Mantenimiento para América del Sur en BASF (www.arcweb.com/blog/namur-open-architecture-introduced-arcs-orlando-foru...). El camino alternativo de datos se representa con una franja diagonal, y las dos características claves del modelo: el foco en la facilidad de acceder a datos que están en cualquier nivel de la pirámide, y la seguridad de evitar accesos no controlados desde fuera de ella. Presentado originalmente en la reunión general de NAMUR (Asociación de usuarios de tecnología de información en procesos industriales, con base en Alemania, fundada en 1949, y con 140 compañías-miembro), el modelo se conoce como “NAMUR Open Architecture” o “NOA”.
Los beneficios de la convergencia IT-OT serán mayores que los riesgos, y con las correspondientes medidas de mitigación, la convergencia ya no será mas un asunto de discusión y sí de implementación.  Figura 3. Conectividad inalámbrica a una aplicación (AIN) colaborativa en la nube
Dos ejemplos de aplicación
En el primer ejemplo (Figura 3), vemos cómo los datos de campo llegan al sistema de la red de integración de activos (AIN) de SAP, utilizando una red Wireless Hart, en un camino paralelo al sistema de control, habilitando así aplicaciones de aprendizaje de máquina (machine learning) y datos masivos (big data). El concepto fue probado en un proyecto lighthouse (en.wikipedia.org/wiki/Lighthouse_Project) de BASF, involucrando instrumentos de Endress+Hauser, válvulas de Samson y gateways de Pepperl+Fuchs (figura 3). (www.arcweb.com/blog/sap-leonardo-system-supports-innovative-solutions-pr...).
En el segundo ejemplo, los datos se transmiten a una nube, adonde por medio de una interfaz de programación de aplicaciones (API) quedan disponibles para aplicaciones de documentación, información del estado de instrumentos, análisis predictivo de su condición, análisis de base instalada, y datos de proceso.
Conclusión
Un nuevo modelo de tecnologías aplicadas a la producción se consolida, el NOA. Los ejemplos vistos anticipan los desafíos que los profesionales de nuestra industria enfrentan: seguridad de datos, nuevas aplicaciones, una frontera mas difusa entre los sistemas de producción y los de tecnología de información. La velocidad de adopción de estas nuevas posibilidades dependerá mucho de la capacidad de producir beneficios concretos en la producción y gestión, en un futuro de corto y medio plazo.
 Figura 4 La historia detrás de la historia: por qué la integración entre IT y OT es imprescindible
En la división tradicional de tareas de una empresa proveedora de sistemas, yo vendía el sistema, correspondía a Ingeniería hacer que funcione. Después de reuniones con el Departamento de Sistemas del cliente, yo estaba seguro de que funcionaría, aun así, era la primera vez que hacíamos esta integración. Sergio Szklanny, gerente de Ingeniería, asignó a Eduardo Giardino este proyecto. Y Eduardo comenzó a trabajar.
Los primeros días nada andaba. Eduardo cargó drivers, probó configuraciones, pero el sistema se resistía a comunicarse. Hasta que se le ocurrió seguir el cable de Ethernet. Unos cinco metros más allá, mezclado con otros cables, terminaba en la nada… Revisadas las conexiones, empezó de vuelta a verificar comunicaciones, versiones de software, etc. Y nada funcionaba. Mientras, cada semana, me informaban de la escasez de progreso, a lo que yo respondía “va a funcionar”.
Un día, Sergio me llamó a su oficina, y me contó no solo que no había funcionado, más aún, ¡habían encontrado por qué no funcionaría nunca! Eso para mí era un desafío: una cosa es que no hayan hecho funcionar la comunicación todavía, yo sabía que iba a funcionar. ¡Otra, que me digan que no iba a funcionar nunca!
Llegué rápido a la oficina de Sergio, y mientras esperábamos a Eduardo, Sergio repetía que no iba a funcionar, pero omitía los detalles. Cuando Eduardo llegó a la puerta de la oficina, Serio, por unos segundos, no se contuvo y se empezó a reír. ¡Habían encontrado el problema, todo funcionaba!
¿Cuál había sido el problema? Un día, mientras Eduardo trabajaba, se acercó una persona del Departamento de Sistemas del cliente, curioso de esta experiencia. Eduardo le mostró lo que estaba haciendo, y un detalle llamó la atención al técnico de sistemas del cliente: ¡la dirección en la red DECNet que nos habían asignado estaba equivocada!. Semanas haciendo pruebas con la información errada… El cliente nos informó una nueva dirección, ¡y todo empezó a funcionar perfectamente! .
Ya son 26 años desde que tuvimos esta experiencia, y es interesante ver la reciente tendencia de convergencia entre IT (tecnologías de información, responsables de la administración del negocio, como las computadoras personales, redes de información, etc.) y OT (tecnologías de operación, responsables de la producción, como sistemas de control, PLC, etc.). La convergencia IT-OT es una necesidad, y corresponde no solo a la convergencia de tecnologías, el alineamiento de políticas y definición de responsabilidades es esencial. Es claro que muchas compañías aún no integran los ambientes de IT y OT por los riesgos implícitos. Sin embargo, es fácil predecir que esta integración ocurrirá: las aplicaciones de big data e inteligencia artificial a datos de proceso producirán beneficios en la eficiencia de la producción. Y tarde o temprano, los beneficios de la convergencia IT-OT serán mayores que los riesgos, y con las correspondientes medidas de mitigación de riesgos, la convergencia ya no será mas un asunto de discusión y sí de implementación. |
