Software inteligente de control y HMI: Capacitando a ingenieros para construir redes IIoT de próxima generación

Marissa Tucker de Parker Hannifin habla con el Editor Senior Patrick Waurzyniak

Marissa, ¿cuál es el papel del controlador de movimiento en el Internet Industrial de las Cosas [IIoT], y qué software está involucrado?

Yo lo llevaría un paso más allá del controlador de movimiento y diría que el controlador de automatización programable [PAC] juega el papel más grande en el IIoT. Eso es porque, además de tener la lógica de la máquina, los PACs incluyen el control de movimiento como parte de sus rutinas y a menudo tienen una interfaz hombre-máquina [HMI] integrada, también. La belleza de este enfoque es que el programa no necesita compartir etiquetas entre dispositivos porque los componentes están en el mismo dispositivo usando la misma lógica. No solo esto reduce el tiempo de programación, sino que también facilita las capacidades IIoT.

Aquí hay un ejemplo: Error de posición —que solía ser muy específico del controlador de movimiento— es automáticamente accesible por la HMI integrada. Si esa HMI integrada tiene capacidades de servidor web, lo cual muchas tienen, la HMI puede enviar inmediatamente una alerta al operario local y también al gerente de planta por correo electrónico o SMS [servicio de mensajes cortos]. Esto es mucho mejor que el enfoque tradicional de tener el controlador de movimiento enviar el error al PLC [controlador lógico programable], con el PLC teniendo que procesar los datos solo para enviarlos a la HMI —que puede o no tener un servidor web. Esta transferencia compleja de datos entre dispositivos se elimina, ya que la lógica se escribe en un software de programación descargado en un dispositivo de hardware. Está tan estrechamente integrado que puedes obtener información fácilmente en cualquier lugar.

Asegurar que el desarrollador que crea la HMI integrada pueda crear diferentes grupos de usuarios y credenciales es crítico. Esto permite al programador crear una instancia personalizada de la HMI, dependiendo del usuario.

La facilidad de flujo de información dentro de la máquina es importante, pero también lo es la facilidad de flujo de información entre máquinas. El estándar de programación IEC 61131-3 asegura que una máquina desarrollada por un fabricante hable el mismo idioma usado por otro. Esto beneficia enormemente a los integradores porque pueden hacer que dos sistemas de máquinas diferentes se comuniquen más fácilmente, un paso necesario hacia el IIoT. Organizaciones como OMAC [Organization for Machine Automation and Control], que promueve el estándar PackML, están llevando IEC 61131-3 al siguiente nivel no solo recomendando cómo debe programarse un sistema, sino también desarrollando un conjunto estándar de etiquetas que las máquinas deberían poner a disposición de otras máquinas en la red.

¿Qué pasa con dispositivos de bajo nivel, como válvulas neumáticas y sensores de posición? ¿No se supone que todo debe ser parte del IoT?

El desafío radica en tomar datos de dispositivos de bajo nivel y convertirlos en información útil. Un enfoque es hacer el procesamiento a nivel de estos dispositivos y luego enviar los resultados ya sea por un bus de control de alto rendimiento o directamente a la nube. Este es un enfoque muy costoso y no ayuda a recopilar o centralizar los datos. Alternativamente, estamos viendo un enorme crecimiento en la popularidad de IO-Link, un protocolo basado en serie que puede recopilar datos básicos de sensores de temperatura, solenoides, colectores de válvulas neumáticas, etc., sin costosa sobrecarga.

Al mantener el bus simple, estos datos pueden recopilarse y hacerse útiles procesándolos en el PAC o PLC que tiene que existir en cada sistema de máquina. Al optar por un PAC, que también tiene una HMI integrada para publicación web, los usuarios pueden entonces tomar esa información y ponerla en la red, donde sea que necesite ir. Imagina un sistema neumático con un sensor que monitoriza continuamente el sonido en decibelios. El único dato que necesita enviarse a un PAC IO-Link es el dB actual. El PAC puede tener bloques de función IEC 61131-3 personalizados desarrollados por el fabricante que pueden funcionar en múltiples controladores. Estos bloques de función pueden verificar si hay un patrón extraño en el ruido, para decir: "Ah, podría haber una fuga". El programador puede tomar esa alerta y enviar un mensaje a un usuario de nivel de mantenimiento de la HMI antes de que falle el sistema neumático.

¿Cómo llega la información de la máquina a la nube, y qué hay del software involucrado?

Todavía hay una gran división entre la planta de fábrica y TI. Especialmente para empresas manufactureras con múltiples instalaciones en varios estados o países, almacenar datos en un servidor externo o la nube es ideal. Desde el lado del software, los fabricantes de componentes necesitan ayudar a que la vida de los constructores de máquinas sea lo más fácil posible al trabajar con TI.

La mayoría de los constructores de máquinas se sienten cómodos programando un PLC o PAC en IEC o lenguajes similares, así que las empresas deberían buscar fabricantes que tomen un enfoque integrado al control de máquina para hacer el flujo de información fácil pero que también hagan fácil compartir esa información a servidores TI. Otro estándar impulsado desde Europa es OPC-UA [OPC Unified Architecture]. Este protocolo cliente-servidor se ha expandido significativamente, permitiendo una forma universal de transferir datos ya sea máquina-a-máquina, máquina-a-SCADA, o máquina-a-servidor. Debido a su flexibilidad, OPC-UA se está convirtiendo rápidamente en el estándar IoT. Busca proveedores que tengan herramientas de software integradas para crear fácilmente una conexión OPC-UA en solo unos clics y permitir a los desarrolladores compartir datos simplemente compartiendo unas pocas etiquetas dentro de un programa IEC 61131-3. Una vez accesible en un servidor, deja que TI se encargue del resto.

¿Es la información útil en la nube? ¿Cómo llegan los datos críticos a las manos del operario, en la planta?

Depende del caso de uso. Cualquiera que piense en IIoT, ya sea operario de máquina, constructor de máquinas OEM, o dueño de fábrica, debería primero desarrollar un caso de uso. Un gerente de planta de fábrica, por ejemplo, puede querer información de efectividad general del equipo [OEE]. Este tipo de información usualmente no es algo que se comparta con una esfera pública más amplia, así que es mejor usar un servidor interno. Sin embargo, los gerentes de planta a menudo pueden estar lejos de la máquina, o no en sus escritorios, pero aún necesitan ver el OEE. El caso de uso impulsa la solución: Si la máquina tiene una HMI integrada con servidor web, un usuario puede conectarse a ella desde una plataforma iOS o Android, ingresar sus credenciales, y ver el OEE de las máquinas, sin nube externa necesaria. Esta red en fábrica a menudo se refiere como computación «fog» (niebla).

Otro ejemplo es un agente de compras que necesita monitorizar datos de rendimiento para múltiples líneas de fábrica en múltiples ubicaciones. Un servidor externo es la única respuesta. Para minimizar el riesgo de exponer información sensible de la empresa, el programa puede publicar solo la salida total, en lugar de rendimientos. Aunque esta solución exige el uso de un servidor en la nube, ilustra la necesidad de usar moderación al enviar cualquier dato a un servidor externo por dos razones: generalmente, es menos seguro que mantenerlo en una red interna o «fog», y la mayoría de planes cobran a las empresas por enviar y almacenar datos en una nube externa.

Los especialistas en marketing han hecho un gran trabajo promocionando la Industria 4.0, pero cada usuario necesita dar un paso atrás y preguntar: "¿Cómo puedo usar la información?". La nube puede no ser tan necesaria como podrías pensar.

¿No está toda esta conectividad aumentando los costes?

Puede, pero no tiene por qué. Donde se vuelve caro es dentro de tres o cuatro años, cuando tu empresa está lista para IoT, pero especificaste dispositivos que dificultan o imposibilitan la comunicación vía servidor web u OPC-UA, o elegiste diseño tradicional fragmentado en lugar de PACs de máquina única que hacen el flujo de datos significativamente más fácil. Para mitigar este error, puedes comprar sensores increíblemente caros que van desde control de temperatura directo a una nube externa, bypassing todos los otros dispositivos en la máquina. Desde allí, tendrás que programar una capa personalizada completa o sitio web usando el software de otra persona para hacer los datos útiles. No quieres ser ese tipo.

En su lugar, implementa IIoT inteligentemente: hazlo parte del diseño de la máquina desde el Día Uno. Si estás construyendo una nueva aplicación, estás en la posición perfecta para transicionar, incluso si no es algo que tu organización esté considerando ahora. Las elecciones que haces hoy pueden ahorrar cientos de miles de dólares más tarde.

También, selecciona dispositivos de bajo nivel que soporten buses como IO-Link para poder obtener datos de ellos asequiblemente. Usa protocolos estándar que sean rentables y te permitan usar datos de muchas fuentes. Usa un solo software de programación en un solo controlador para simplificar la programación. Asegúrate de que el controlador de máquina tenga la capacidad para una relación cliente-servidor sin necesariamente requerir otra pasarela adicional. De esa forma, si necesitas empezar a enrutar información a diferentes ubicaciones, puedes hacerlo directamente en tu programa basado en IEC. No olvides la computación fog. Si tu PLC tiene una HMI integrada que es capaz de servidor web, podrías satisfacer todos tus casos de uso IIoT sin el uso de una nube en absoluto. Y si necesitas, asegúrate de que el controlador que elijas tenga software que haga fácil compartir a un servidor OPC-UA, para que TI pueda hacer lo que TI hace mejor.

Elecciones inteligentes hacen que la conversión a IIoT sea muy asequible, pero las elecciones deben hacerse ahora.