Los diseños de software de control inteligente y HMI ayudan a los ingenieros a construir nuevas redes para el IIoT

Marissa Tucker de Parker Hannifin habla con el editor sénior 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?

Iría un paso más allá del controlador de movimiento y diría que el controlador de automatización programable [PAC] desempeña el papel más importante en el IIoT. Esto se debe a que, además de tener la lógica de la máquina, los PAC incluyen el control de movimiento como parte de sus rutinas y, a menudo, también tienen una interfaz hombre-máquina [HMI] integrada. 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. Esto no solo reduce el tiempo de programación, sino que también facilita las capacidades de IIoT.

Este es un ejemplo:el HMI integrado puede acceder automáticamente al error de posición, que solía ser muy específico del controlador de movimiento. Si esa HMI integrada tiene capacidades de servidor web, lo que muchas de ellas tienen, la HMI puede enviar inmediatamente una alerta al operador local y también al gerente de la planta por correo electrónico o SMS [servicio de mensajes cortos]. Esto es mucho mejor que el enfoque tradicional de hacer que el controlador de movimiento envíe el error al PLC [controlador lógico programable], y el PLC luego tiene que procesar los datos solo para enviarlos a la HMI, que puede o no tener un Servidor web. Esta compleja transferencia 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 puede obtener información fácilmente en cualquier lugar.

Es fundamental asegurarse de que el desarrollador que crea la HMI integrada pueda crear diferentes grupos de usuarios y credenciales. Esto permite al programador crear una instancia personalizada de la HMI, según el usuario.

La facilidad del flujo de información dentro de la máquina es importante, pero también lo es la facilidad del flujo de información entre máquinas. El estándar de programación IEC 61131-3 garantiza que una máquina desarrollada por un fabricante hable el mismo idioma que utiliza otro. Esto beneficia enormemente a los integradores porque pueden hacer que dos sistemas de máquinas diferentes se comuniquen entre sí más fácilmente, un paso necesario hacia IIoT. Organizaciones como OMAC [Organización para la Automatización y el Control de Máquinas], que promueve el estándar PackML, están llevando la norma 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 debe poner a disposición de otras máquinas en la red.

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

El desafío radica en tomar datos de dispositivos de bajo nivel y convertirlos en información útil. Un enfoque es realizar el procesamiento al nivel de estos dispositivos y luego enviar los resultados a través de 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 gran 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 gastos generales costosos.

Al dejar el bus simple, estos datos se pueden recopilar y hacer útiles mediante el procesamiento en el PAC o PLC que debe existir en cada sistema de máquina. Al optar por un PAC, que también tiene una HMI integrada para la publicación web, los usuarios pueden tomar esa información y colocarla en la red, donde sea necesario. Imagine un sistema neumático con un sensor que monitorea continuamente el sonido en decibelios. Los únicos datos que deben enviarse a un PAC IO-Link son los dB actuales. El PAC puede tener bloques de funciones IEC 61131-3 personalizados desarrollados por el fabricante que pueden funcionar en varios controladores. Estos bloques de funciones 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 la neumática. .

¿Cómo llega la información de la máquina a la nube y qué pasa con el software involucrado?

Todavía existe una gran división entre la planta de producción y TI. Especialmente para las empresas de fabricación con múltiples instalaciones en varios estados o países, lo ideal es almacenar datos en un servidor externo o en la nube. Desde el punto de vista del software, los fabricantes de componentes deben ayudar a que la vida de los fabricantes de máquinas sea lo más fácil posible cuando trabajan con TI.

La mayoría de los fabricantes de máquinas se sienten cómodos programando un PLC o PAC en IEC o lenguajes similares, por lo que las empresas deben buscar fabricantes que adopten un enfoque integrado del control de máquinas para facilitar el flujo de información. pero que también facilitan compartir esa información con los servidores de TI. Otro estándar que está siendo expulsado de Europa es OPC-UA [OPC Unified Architecture]. Este protocolo cliente-servidor se ha expandido significativamente, permitiendo una forma universal de transferir datos de máquina a máquina, de máquina a SCADA o de máquina a servidor. Debido a su flexibilidad, OPC-UA se está convirtiendo rápidamente en el estándar de IoT. Busque proveedores que tengan herramientas de software integradas para crear fácilmente una conexión OPC-UA con solo unos pocos clics y permitir que los desarrolladores compartan datos simplemente compartiendo algunas etiquetas dentro de un programa IEC 61131-3. Una vez que esté accesible en un servidor, deje que TI se encargue del resto.

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

Depende del caso de uso. Cualquiera que esté pensando en IIoT, ya sea un operador de máquina, un fabricante de máquinas OEM o el propietario de una fábrica, primero debe desarrollar un caso de uso. Un gerente de planta, por ejemplo, puede querer información sobre la efectividad general del equipo [OEE]. Este tipo de información no suele ser algo que deba compartirse con una esfera pública más amplia, por lo que es mejor utilizar un servidor interno. Sin embargo, los gerentes de piso de la fábrica a menudo pueden estar lejos de la máquina, o no en sus escritorios, pero aun así necesitan mirar OEE. El caso de uso impulsa la solución:si la máquina tiene una HMI integrada con un servidor web, un usuario puede conectarse desde una plataforma iOS o Android, ingresar sus credenciales y ver el OEE de las máquinas, no se necesita una nube externa . Esta red en la fábrica a menudo se conoce como computación de "niebla".

Otro ejemplo es un agente de compras que necesita monitorear los datos de rendimiento de varias líneas de fábrica en varias ubicaciones. Un servidor externo es la única respuesta. Para minimizar el riesgo de exponer información confidencial de la empresa, el programa puede publicar solo la producción total, en lugar de los rendimientos. Si bien esta solución exige el uso de un servidor en la nube, ilustra la necesidad de restringir el envío de datos a un servidor externo por dos razones:generalmente, es menos seguro que mantenerlo en una red interna o 'niebla', y la mayoría de los planes cobrar a las empresas por enviar y almacenar datos en una nube externa.

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

¿Toda esta conectividad no aumenta los costos?

Puede, pero no tiene que hacerlo. Donde se vuelve costoso es dentro de tres o cuatro años, cuando su empresa esté lista para IoT, pero especificó dispositivos que dificultan o imposibilitan la comunicación a través del servidor web u OPC-UA, o eligió un diseño fragmentado tradicional en lugar de PAC de una sola máquina que facilitan significativamente el flujo de datos. Para mitigar este error, puede comprar sensores increíblemente caros que pasan del control de temperatura directamente a una nube externa, sin pasar por todos los demás dispositivos de la máquina. A partir de ahí, tendrá que programar una capa o sitio web completamente personalizado utilizando el software de otra persona para que los datos sean útiles. No quieres ser este tipo.

En su lugar, implemente IIoT de manera inteligente:hágalo parte del diseño de la máquina desde el primer día. Si está creando una nueva aplicación, está en la posición perfecta para la transición, incluso si no es algo que su organización esté considerando en este momento. Las decisiones que tome hoy pueden ahorrarle cientos de miles de dólares en el futuro.

Además, seleccione dispositivos de bajo nivel que admitan buses como IO-Link para que pueda obtener datos de ellos de manera asequible. Use protocolos estándar que sean rentables y le permitan usar datos de muchas fuentes. Utilice un solo software de programación en un solo controlador para simplificar la programación. Asegúrese de que el controlador de la máquina tenga la capacidad de una relación cliente-servidor sin requerir necesariamente otra puerta de enlace adicional. De esa manera, si necesita comenzar a enrutar información a diferentes ubicaciones, puede hacerlo directamente en su programa basado en IEC. No te olvides de la computación en la niebla. Si su PLC tiene una HMI integrada que es compatible con un servidor web, es posible que pueda satisfacer todos sus casos de uso de IIoT sin el uso de una nube en absoluto. Y si lo necesita, asegúrese de que el controlador que elija tenga un software que facilite compartirlo con un servidor OPC-UA, para que TI pueda hacer lo que mejor sabe hacer.

Las elecciones inteligentes hacen que la conversión a IIoT sea muy asequible, pero las decisiones deben tomarse ahora.