Traducido del inglés, una publicación original de Matt Newton en el blog de Opto 22
Hemos hablado de otras tecnologías, como edge computing y RESTful APIs, que reducen la complejidad de la arquitectura de un sistema para el Internet de las cosas (IoT) o el Internet industrial de las cosas (IIoT).
Reducir la complejidad es esencial para hacer que el IIoT funcione, especialmente para obtener datos de sensores, equipo y dispositivos actualmente instalados y que están funcionando perfectamente en campo pero no tienen la capacidad de IoT.
No existiría un retorno de inversión si se debe instalar costos equipos intermediarios y pagar por trabajo de integración costoso. Así que nuestra REST API para controladores SNAP PAC reduce la complejidad y coloca a las aplicaciones IIoT dentro del alcance práctico.
OPC
OPC se diseñó para conectar aplicaciones ejecutando en el sistema operativo Windows con dispositivos de automatización industrial para el acceso de datos.
En 1996 un grupo de fabricantes de equipo de automatización: Fisher-Rosemount, Intellution, Opto 22 y Rockewell crearon una fuerza de trabajo para desarrollar un estándar para el acceso de datos desde dispositivos industriales basado en los elementos COM y DCOM de Windows y nombrado OLE para el control de procesos o, de forma abreviada, OPC.
La principal desventaja de OPC en su forma original (-DA, -HDA, etc.) es que utiliza una arquitectura obligatoria de cliente-servidor en donde un servidor de Windows especifica los elementos, dispositivos y protocolos para una gran cantidad de dispositivos hasta los estándares de los clientes OPC pero, de nuevo, corriendo en sistemas de Windows.
La especificación más reciente OPC UA trata de evitar la necesidad de una PC con Windows eliminando el uso de COM/DCOM y permitiendo que un servidor esté incrustado dentro de un producto como un PLC o PAC.
Por desgracia, la participación de fabricantes de hardware con este enfoque es pequeña y existen pocos clientes OPC UA disponibles (Notable excepción Groov de Opto 22). Además, OPC (y OPC UA) es un gran conjunto de especificaciones abarcando más de 13 documentos y 1,000 páginas.
El estándar especifica muchos aspectos incluyendo los protocolos de transporte, seguridad, servicios, modelos de información, perfiles y otros. Los fabricantes que deciden incluir un servidor OPC UA en sus productos deben considerar costos y tiempo de desarrollo, tamaño de flash y RAM, uso de CPU y costos de mantenimiento posteriores.
Cuando se considera a OPC para una aplicación de IIoT, se debe considerar ruteadores, firewalls (cortafuegos) y VPN (Redes virtuales privadas). A pesar de todo, OPC es una excelente solución para que software corriendo en Windows intercambie datos con sistemas existentes, particularmente en redes locales. Sin embargo, para aplicaciones de IIoT en donde los datos serán transportados entre diferentes tipos de dispositivos con diferentes sistemas operativos y con limitantes en el hardware en una variedad de arquitecturas, se puede utilizar un mejor protocolo.
MQTT
MQTT es un protocolo de transporte que envía datos utilizando una arquitectura de publicador/suscriptor (pub/sub) y ofrece muchas ventajas en aplicaciones IIoT como: estándar abierto y adecuado para conexiones remotas o débiles y para dispositivos instalados tras un cortafuegos.
En una arquitectura pub/sub los clientes se suscriben a un tópico que contiene datos y que son almacenados en un intermediario (broker) MQTT.
En una aplicación típica que utilice MQTT, se puede encontrar un PAC (Controlador programable para la automatización) en un lugar remoto publicando el estado de sus Entradas/Salidas en un tópico particular a un intermediario localizado en las oficinas principales. Entonces, otro sistema, como un HMI puede suscribirse al tópico en el intermediario y recibir actualizaciones cuando el estado de las Entradas/Salidas cambia.
Uno de los grandes beneficios que ofrece MQTT en aplicaciones de IIoT es que es un protocolo abierto y un estándar OASIS. Esto significa que los desarrolladores de sistemas pueden adoptar MQTT como un protocolo de comunicación en sus diseños sin importar el sistema operativo que utilicen.
Incluir MQTT en un nuevo diseñado es generalmente más sencillo que incluir OPC UA en el dispositivo. MQTT es además un protocolo ligero, que significa que utiliza menor ancho de banda para enviar datos comparado con otros protocolos como OPC. Esto es importante en aplicaciones de IIoT en donde los dispositivos pueden estar instalados en lugares remotos con restricciones de acceso a la red como bajos anchos de banda, alta latencia, límite de datos o conexiones frágiles.
La arquitectura pub/sub de MQTT también la hace ideal para aplicaciones IIoT porque empuja los datos al intermediario con una conexión saliente. La mayoría de los cortafuegos bloquean en tráfico entrante (por ejemplo, un cliente externo de OPC solicitando datos de un servidor interno de OPC) pero permiten las conexiones salientes sobre puertos TCP seguros, como el 443 para TLS/SSL.
En una aplicación IIoT, por ejemplo, un PAC instalado en un pozo petrolero remoto puede abrir una conexión saliente a través de un cortafuegos y llamar para reportar sus datos a un intermediario MQTT localizado en las oficinas principales.
Hacia el futuro
A medida que el IIoT siga avanzando, las aplicaciones se volverán más fluidas y la arquitectura de los sistemas menos compleja.
Dos claves para alcanzar estos objetivos en aplicaciones de IIoT son edge computing y MQTT. Y estas tecnologías ya están disponibles y pronto serán de uso común como lo son ahora en los productos de Opto 22.
En Instrumentación y Control 22 contamos con expertos en automatización que le pueden ayudar a determinar el alcance de sus necesidades para el presente y el futuro y así ayudarlo a seleccionar el controlador industrial idóneo para su proceso de automatización.
Temas: Internet de las cosas, monitoreo remoto, IoT, PACs, IIoT, Industrial internet of things, MQTT