AEI 518 - Comunicaciones industriales del Siglo XX en la industria del siglo XXI

En este artículo veremos la actualidad de las comunicaciones industriales, alguno de los estándares que las implementan para dar respuesta a las exigencias de la Industria 4.0 y cómo podemos coexistir con los protocolos más antiguos.

Todos sabemos lo que son las comunicaciones industriales, al menos hemos oído hablar de que existen. Enumeremos algunos de los protocolos que usamos para su implementación (y su año aproximado de lanzamiento): Modbus RTU (1979), PROFIBUS DP (1989), DeviceNet (1994), CAN (1986), CANopen (1994), Interbus (1987), SERCOS (1987), Modbus TCP/IP (1999), Ethernet/IP (1990), EtherCAT (2003), PROFINET (1989), BACNET (1987), OPC-DA (1996), OPC-UA (2006), MQTT (1999). Salta a la vista que la gran mayoría de estos protocolos son del siglo pasado.

Entonces, ¿podemos abordar los nuevos retos que la Industria nos propone para el siglo XXI? ¿Seremos capaces de responder a las exigencias de los estándares de comunicación de la Industria 4.0?

Empezaré diciendo que la Inteligencia Artificial (AI) o “Busines Intelligence” (BI) se considera el elemento fundamental de esta cuarta revolución industrial que llamamos Industria 4.0 (después de la máquina de vapor, la cadena de montaje y la automatización). Esta AI o BI necesita grandes cantidades de datos (Big Data) y algoritmos para analizarlos (Data Analytics). La manera de conseguir estos datos es mediante la conexión y la comunicación entre los diferentes dispositivos industriales. Hoy en día, desde PLCs hasta sensores de campo tienen la posibilidad de compartir sus datos entre ellos y con diferentes sistemas de gestión, ERPs, SCADAs o sistemas MES.

Está claro que los protocolos de comunicación usados en planta, donde las distancias son cortas y por ello la latencia en las comunicaciones también lo es, no necesitan una gran evolución. Profinet, Profibus, Ethercat, Modbus…, son perfectamente funcionales a día de hoy como buses de campo y garantizan, por su fiabilidad y experiencia, la comunicación entre PLCs, sensores, actuadores, motores,…

Pero, ¿qué pasa con el otro lado de la comunicación? Los PLCs almacenan información que la industria 4.0 nos exige enviar “aguas arriba”. Esta información, en el mejor de los casos, se puede quedar en sistemas dentro de la propia planta pero, en muchos otros casos, habrá que enviarla hacia sistemas centralizados fuera de la fábrica que recoge información de diferentes localizaciones. Incluso se puede dar la necesidad de combinar las dos situaciones: podemos tener sistemas que recogen y analizan datos en planta (Edge Computing) y sistemas que analizaran, a posteriori, datos de varias plantas, normalmente en servicios en la nube (Cloud Computing). Estas dos situaciones no solo no están reñidas, sino que la gran mayoría de las veces, se complementan.

Y es aquí, en este punto, en el que parece que la industria ha elegido sus protocolos campeones.

OPC UA

Este es el estándar que la industria prefiere para la comunicación en planta entre la máquina y los sistemas de gestión. Podríamos decir que OPC UA (Open Platform Communications Unified Architecture) es el protocolo diseñado para traer datos del mundo industrial al mundo IT. Los datos pueden pasar por firewalls y conectar un PLC directamente a un sistema ERP, SCADA o MES. Así mismo, facilita la transferencia de datos entre servidores y clientes ya que se basa en un sistema de modelos de datos, es decir, la propia comunicación incorpora no solo el valor del dato que está pasando sino que incorpora también metadatos asociados como el nombre del dato, de qué tipo es (numérico, booleano, string...) y alarmas asociadas, entre otros. Otras características que hacen de OPC UA el estándar elegido para las comunicaciones en planta son su escalabilidad, su independencia de la plataforma que lo ejecuta y su capacidad para segmentar la red de IT de la red de OT.

En el área de la seguridad, hay que destacar que OPC UA dispone de funciones de seguridad tanto en la capa de Autenticación (autenticación de cliente, servidor y de mensajes para la sesión UA) como en la capa Comunicaciones (todas las comunicaciones OPC UA están cifradas y firmadas).

MQTT

Para la comunicación fuera de planta, no es arriesgado afirmar que MQTT (Message Queue Telemetry Transport) se ha convertido en el estándar de facto para la industria. Es verdad que es un protocolo de finales de los 90, pero no fue hasta 2010, cuando IBM lanzó la especificación V3.1 del protocolo, que este empezó a ser tenido en cuenta en el mundo del IoT. En 2014 pasó a ser un estándar OASIS (Organization for the Advancement of Structured Information Standards) y en 2016 un estándar ISO (International Organization for Standardization), por lo que podemos considerarlo un protocolo del siglo XXI. ¿Por qué MQTT ha sido el protocolo ganador frente a otros como CoAP, LWM2M, XMPP, AMQP? Por dos motivos fundamentales.

El primero, la comunidad MQTT. Desde que IBM decidió enviar el protocolo a OASIS, la combinación de “open-source” y “open-standard” eliminaron las barreras para adoptar MQTT y cualquiera podía implementarlo de forma gratuita. A esto podemos añadir la aparición de diferentes “Brokers open-source”. Mosquito fue el primero, pero la comunidad MQTT continuó creciendo y se lanzaron varias herramientas cliente que permitían la depuración de aplicaciones y otros “Brokers” “open-source”, como HiveMQ o VerneMQ. Incluso HiveMQ llegó a publicar una serie de artículos que explicaban en detalle cómo usar la especificación MQTT. La comunidad estaba facilitando a los desarrolladores aprender, experimentar y adoptar MQTT.

El segundo motivo es su utilidad. Es capaz de enviar mensajes y mantener comunicaciones fiables incluso sobre redes poco fiables. Se basa en un protocolo de publicación / suscripción muy simple y ligero, diseñado para redes de bajo ancho de banda, alta latencia o poco fiables. Su sencillez permite implementar de forma fácil clientes MQTT y al ser un protocolo pub / sub es por naturaleza bidireccional y da respuesta a la mayoría de aplicaciones IIoT.

Por supuesto, MQTT implementa servicios de seguridad, con tráfico cifrado SSL/TLS y autenticación por nombre de usuario y contraseña o por certificados.

Para acabar, una última pregunta, ¿cómo podemos integrar estos protocolos en nuestra instalación? La respuesta no es difícil, desde SIDE Automatización os proponemos el uso del Ewon Flexy. Un router industrial y pasarela de datos que nos permite conectarnos a nuestros PLCs y dispositivos de campo y almacenar en su interior las variables y los datos que necesitamos para nuestro “Big Data”. Flexy dispone de los drivers de comunicación nativos de los principales PLCs del mercado para alimentar su base de datos de variables y además actúa tanto como cliente que como servidor OPC UA e incorpora las instrucciones necesarias para publicar y subscribirse a nuestro “Broker” MQTT. Cualquier variable recogida en Flexy de cualquier PLC puede ser leída y escrita usando conexiones OPC UA y mensajes MQTT. La configuración de Flexy no puede ser más sencilla, basada en intuitivas pantallas y asistentes, y por supuesto, Flexy soporta la seguridad y encriptación mencionadas antes para OPC-UA y MQTT. Además posee capacidad de programación por lo que podremos configurar nuestras comunicaciones industriales tal y como las necesitemos. Ewon Flexy es el elemento “Edge” que realiza la función de puente entre OT e IT permitiendo así disponer de todos los datos que nuestras máquinas nos proporcionen, pero segmentando las redes y aumentando así la seguridad de la planta.

César Ricón Bada
Product manager en tecnologías IIoT en SIDE