Desde el sensor a la nube vía OPC UA o MQTT

Hay dos demandas específicas detrás de los términos Industria 4.0 e IoT: conectar dispositivos de automatización a la nube y vincular todos los dispositivos entre sí. El término nube es representativo de otras diversas formas como nube privada, nube pública o híbridos de ambas. No todas estas nubes deben tener algo que ver con Internet, y en la automatización de fábricas se utilizan nubes privadas o híbridos de estas.

El segundo aspecto se refiere a los dispositivos de campo: deben generar información que va más allá de los datos de E/S pura; tales como de diagnóstico, análisis o datos de las condiciones en las que se encuentra. Las aplicaciones en la nube son capaces de evaluar esta información, la cual se resume en una semántica unificada de objetos. Esta semántica es de gran importancia: existe el objetivo de definir un estándar común. El Big Data, que se genera y estandariza de esta manera, forma la base para servicios y modelos de negocio, tales como el mantenimiento preventivo, control de flujo de bienes y optimización de procesos.

Los debates sobre la implementación de la Industria 4.0 pueden ser muy controvertidos, sin embargo, hay acuerdo en que los datos, que son los responsables de la generación de valor añadido, se forman en los sensores de los dispositivos de campo. También hay una buena oportunidad para el consenso en relación con la comunicación del IoT con OPC UA y MQTT. Pero ¿dónde comienza el inicio de la comunicación del IoT y cómo se actualizan los datos transferidos desde el dispositivo de campo a la nube: se transferirán los datos como de costumbre a través de Real-Time Ethernet con un colector de datos y desde allí a una nube? ¿O es la información transmitida directamente desde el dispositivo de campo a través de OPC UA ó MQTT a través de un Gateway hacia la nube?

Desde la perspectiva de Hilscher, empresa representada en España y Portugal por Novatronic Sistemas, la comunicación IoT comienza ya en el dispositivo de campo. A través del canal TCP/IP, se realiza una comunicación en tiempo real a través del mismo medio físico, sin efectos secundarios y de forma paralela a la comunicación Real-Time Ethernet. Para satisfacer la demanda de una semántica unificada, se debe establecer un modelo de transferencia del dispositivo de campo con el fin de asegurar una estructura de información homogénea desde el sensor hacia la nube. Además, esta comunicación IoT es independiente del protocolo en tiempo real en uso y ya implementado en el unidad de comunicación del dispositivo.

A pesar de todo el bombo: no podemos olvidar las plantas existentes. La comunicación del IoT se establecerá de forma gradual en la automatización de fábricas. La implementación se lleva a cabo a través de las nuevas aplicaciones en la nube de “arriba a abajo” y, además, los dispositivos de campo deben ser activados de 'abajo hacia arriba'. Por lo tanto, un dispositivo IoT no sólo debe proporcionar la comunicación del IoT, también es una ruta de actualización para las innumerables plantas existentes.

Por otra parte, el diseñador de la planta también tiene que considerar la seguridad y la privacidad de los dispositivos de campo. En muchos casos, el estándar de seguridad de la propia infraestructura de una empresa puede ser suficiente. Debe pensarse a fondo si son necesarios mecanismos de seguridad adicionales y estos deben ser integrados en el concepto de la planta. Además, el dispositivo de campo trae consigo un mecanismo de seguridad básica.

Con el fin de proporcionar una solución impulsada por el mercado para la Iindustria4.0 y el IoT, Hilscher ha refinado sus módulos de comunicación DIL-32 equipándolos con funciones IoT. El módulo de comunicación habilitado para IoT se basa en el chip multi-protocolo netX52. En el diseño de la solución, se prestó especial atención al hecho de dotarle de una alta flexibilidad funcionalidad garantizando, además, un fácil manejo durante la aplicación.

Además de la comunicación Ethernet en tiempo real, el netIC IoT incluye un servidor OPC UA, así como un cliente MQTT. A través del canal de TCP/IP del protocolo Ethernet en tiempo real (por ejemplo, PROFINET o Ethernet/IP), los datos de los dispositivos de campo son accesibles sin pasar por el control. Esto se puede mediante cualquier cliente OPC UA o mediante el envío de datos por el módulo IoT a un dispositivo con MQTT que el usuario puede configurar libremente. Los dispositivos de campo existentes pueden ser equipados con la comunicación IoT a través de la colocación de pines configurables. Para actualizarlos, hay un modo 'pin-compatible' con el módulo NIC 50-RE con interfaz de host UART. Con eso, un OEM ahorra un nuevo diseño de hardware y el desarrollador simplemente tiene que ampliar la aplicación de software con el modelo genérico.

Para los nuevos desarrollos, la netIC IOT se puede conectar a través de una interfaz SPI de 50 MHz al procesador anfitrión. Así, el dispositivo fabricante está equipado para la Industria 4.0 / IoT, con la seguridad de la inversión simultánea en su desarrollo de productos. Él mismo puede decidir cuándo y qué datos activan OPC UA o MQTT.

Otra pieza fundamental del netIC IOT es la tecnología Net Proxy: cada sistema Ethernet ofrece servicios específicos que el usuario tiene que programar en su su aplicación. Esto requiere una profunda comprensión de la funcionalidad del sistema de red y, por lo tanto, programación adicional para el software de la aplicación.

Aquí es donde comienza la tecnología Net Proxy: la idea básica es la formación de un objeto y servicio de interfaz orientados al dispositivo entre la aplicación y la comunicación. Esta capa de abstracción “esconde” su complejidad, así como las diferentes APIs de los protocolos de red y proporciona servicios sencillos para el intercambio de datos cíclico y acíclico. El OEM puede crear su aplicación sin requisitos específicos de protocolo y recibir así un verdadero dispositivo multi-protocolo. Net Proxy también ofrece la respuesta al deseo de unificar la semántica ya que una vez que se haya creado una definición general en el mercado, este puede ser implementado en conforme a ella.

La herramienta de ingeniería netX Studio ofrece soporte a los fabricantes para crear el dispositivo final. Con la ayuda de esta herramienta, el desarrollador crea la biblioteca de objetos para su familia de dispositivos y el modelo de objetos específicos para su producto. Mediante la asignación de atributos, el mapeo de los objetos individuales para el protocolo de comunicación se produce de forma automática.

Durante la configuración del dispositivo, el OEM también libera aquellos objetos que están destinados a la comunicación de E/S a través de OPC UA o MQTT o a través de su servidor web específico del producto. Como resultado de ello, la herramienta suministra una imagen descargable y un archivo EDS específico para su dispositivo, así como para el archivo de cabecera para la conexión con el software de la aplicación. De este modo, la herramienta de ingeniería cubre todos los aspectos para una puesta en marcha exitosa. El cliente final utiliza un interfaz de servidor web simple para los últimos ajustes, tales como la configuración del agente de MQTT.

La conexión de un dispositivo de campo a una nube tiene bastantes riesgos. Por lo tanto, un punto vital a considerar de la Industria 4.0 y el IoT es la seguridad informática: el uso de chips TPM (Trusted Platform Module) como los que ya se utilizan en los ordenadores portátiles, PDAs o en la comunicación móvil.

Para Hilscher, comunicación y seguridad IoT están estrechamente vinculados entre sí. Por lo tanto, netIC IOT se puede extender en el futuro con mecanismos de seguridad tales como “arranque seguro”. En el primer paso, se puede integrar un chip TPM 1.2 a través de interfaz SPI, con la opción de cambiar más adelante a TPM 2.0. La tecnología está todavía en una fase de evaluación general con el objetivo de poder presentar las funciones de seguridad para el primer netIC IOT a finales de 2016.