De Industria 4.0, necesidades de conectividad y guerras de protocolos y estándares
Cualquiera que haya asistido a una feria, webinar o visitado un site relacionado con Industria 4.0 habrá podido detectar que entre los conceptos más habituales y extendidos está el de IOT (Internet of Things), además de estar familiarizado con como otros muchos términos y estándares a su alrededor: IIOT, IOE, HTTP, REST, JSON, MQTT, OPC-UA, DDS… la lista podría continuar.
Cualquiera que haya asistido a una feria, webinar o visitado un site relacionado con Industria 4.0 habrá podido detectar que entre los conceptos más habituales y extendidos está el de IOT (Internet of Things), además de estar familiarizado con como otros muchos términos y estándares a su alrededor: IIOT, IOE, HTTP, REST, JSON, MQTT, OPC-UA, DDS… la lista podría continuar.
Todos sabemos que lo que queremos es obtener conectividad online entre nuestros sistemas de TI y los procesos reales que están sucediendo en las plantas. Pero la realidad que nos encontramos es que no hay un único estándar de comunicaciones hoy en día que nos permita comunicar nuestras soluciones de TI (ERP/MRP/MES) con cualquier máquina de cualquier fabricante, y tampoco es fácil entender entre todos estos términos cuáles son importantes en cada caso.
Trabajar para ayudar con este mix de términos es parte de la labor de los proveedores del sector, porque sin duda uno de los grandes desafíos cuando se necesita conectar un ERP/MES y sus máquinas, es la conectividad e interoperabilidad. Hay muchos protocolos para lograr esto: algunos que son propietarios y otros que son estándares abiertos, y es nuestro trabajo entender dónde y cuándo utilizarlos.
Para el propósito de esta discusión, es importante agrupar los protocolos en dos categorías: Cliente/servidor y Publish/subscribe (de publicación/ suscripción)
Los protocolos cliente/servidor requieren que el cliente se conecte al servidor y realice solicitudes. En este modelo, el servidor contiene los datos y responde a las solicitudes del cliente. Por ejemplo, el cliente puede así leer un dato de una máquina (véase: un tiempo de corte) si conoce el servidor. Este modelo es más adecuado cuando los equipos conocen su infraestructura a nivel de red (dirección IP y puerto del servidor).
Por su parte, los protocolos de publicación/suscripción requieren que los dispositivos se suscriban, y luego recojan datos a través de un proceso o sistema intermedio. Por ejemplo, un dispositivo puede muestrear un dato de una máquina cada minuto, y luego publicarlo una vez por hora. En este modelo, una aplicación suscrita a dicho flujo de datos recibe cada hora un listado de muestras de un minuto. Este modelo desvincula en cierta forma al productor de datos del consumidor, y es más adecuado cuando la infraestructura de red es más desconocida o variable.
Qué protocolos (OPC-UA, MQTT, DDS…) tendrán más cuota de mercado es algo que todavía no está claro, pero cada uno tiene sus pros y sus contras. Lo importante es elegir el protocolo que mejor se adapte a las necesidades de cada organización, aunque todavía es más importante seleccionar y contar con partners tecnológicos con experiencia, que puedan adaptarse a estos protocolos y a las diferentes casuísticas y permitan abstraer las aplicaciones de las guerras de protocolos y estándares.