Acelerar el desarrollo de aplicaciones industriales de IoT - Parte 1: Simulación de datos de dispositivos de IoT

Nota del editor: Los proyectos de desarrollo de aplicaciones integradas se retrasan a menudo mientras los desarrolladores esperan la disponibilidad de las implementaciones de hardware de los nuevos dispositivos. El desarrollo de aplicaciones de la Internet Industrial de las Cosas (IIoT) se enfrenta a un cuello de botella similar, a la espera de los datos de los sensores necesarios para aplicaciones como los sistemas de mantenimiento predictivo industrial o los sistemas de automatización de instalaciones basados en métodos de aprendizaje de máquinas. Esta serie de dos partes explora alternativas para proporcionar los primeros flujos de datos necesarios para acelerar el desarrollo de las aplicaciones del IIoT. En la primera parte se describe el uso de métodos de simulación para generar esos flujos de datos. La segunda parte trata de las opciones para la creación rápida de prototipos de sistemas de sensores para la generación de datos.

Las aplicaciones de Internet industrial de las cosas (IIoT) a gran escala presentan múltiples retos que pueden paralizar las implementaciones y hacer que las empresas se cuestionen el rendimiento de la inversión en los numerosos recursos necesarios para la aplicación. Para prevenir esas situaciones y ayudar a los promotores a determinar más rápidamente los beneficios de la implementación del IIoT, se requiere un acceso fácil a los datos para la simulación de la implementación.

Al utilizar métodos de simulación para generar flujos de datos realistas, los desarrolladores pueden comenzar el desarrollo de aplicaciones del IIoT mucho antes de la implementación de la red de IoT e incluso refinar la definición de la propia red de sensores del IIoT.

Este artículo mostrará cómo las diversas plataformas en la nube de IoT proporcionan una simulación de datos e introducirá ejemplos de puertas de enlace de Multi-Tech Systems Inc. que pueden acelerar aún más la implementación.

El caso de la simulación de los datos del IIoT

El uso de datos simulados para impulsar el desarrollo de aplicaciones y sistemas no es, por supuesto, nada nuevo. Los desarrolladores han utilizado métodos de simulación a nivel de sistema durante décadas para poner a prueba las infraestructuras informáticas y los servicios de conectividad. Estas pruebas cumplen una función importante en la verificación de la resistencia de las configuraciones estáticas. En las plataformas de servicios en la nube, estas pruebas proporcionan un método relativamente sencillo para verificar el autoescalado de las máquinas virtuales y otros recursos de la nube.

Las aplicaciones del IIoT comparten estos mismos requisitos y más. Además de ayudar en las pruebas de carga y en el autoescalado, la simulación de datos proporciona una importante herramienta para verificar la integración de los muchos servicios y recursos dispares que se necesitan para implementar un software tan complejo como una aplicación IIoT de nivel empresarial. Más allá de esas prácticas más fundamentales, la simulación de datos puede acelerar el desarrollo de aplicaciones complejas de IIoT construidas sobre las sofisticadas plataformas de servicios disponibles en los principales proveedores de nubes.

La perspectiva del software

Las aplicaciones del IIoT operan en arquitecturas complejas que se ven significativamente diferentes a las de los desarrolladores de software de aplicación que a las de los desarrolladores de sistemas de sensores y actuadores. Para estos últimos, una arquitectura de IIoT a gran escala es un vasto conjunto de sensores y actuadores que interactúan con los procesos físicos que son objeto de la aplicación global. Para los desarrolladores de software de aplicación, una arquitectura de IIoT de nivel empresarial comprende una serie de servicios cuya actividad coordinada ofrece en última instancia la funcionalidad de la aplicación.

La arquitectura de referencia de IoT de Microsoft Azure ofrece una visión representativa de las aplicaciones típicas de IIoT (y de las aplicaciones de IoT en general) desde la perspectiva del software de aplicación. Este punto de vista resume los múltiples servicios funcionales que una aplicación típica une en la nube para ofrecer ideas y acciones basadas en datos de los dispositivos de punto final y de borde en la periferia (Figura 1).

Figura 1: La arquitectura de referencia de IoT de Microsoft Azure ilustra los múltiples tipos de servicios y recursos de la nube que una aplicación de IIoT requiere generalmente para ofrecer conocimientos y acciones útiles a partir de los datos generados por las redes de dispositivos en la periferia. (Fuente de la imagen: Microsoft Corp.)

Las soluciones de aplicaciones específicas implementan estos recursos de nubes en combinaciones apropiadas, conectadas funcionalmente a través de mecanismos de intercambio estandarizados y coordinadas por la lógica de la aplicación. En su solución de vehículo conectado, por ejemplo, Amazon Web Services (AWS) sugiere cómo los servicios en la nube podrían mezclarse y combinarse en módulos responsables de proporcionar diferentes características y capacidades de la aplicación (figura 2).

Figura 2: La solución de vehículo conectado a AWS proporciona una visión representativa de la orquestación de servicios en lanube de una aplicación típica de IoT a gran escala para ofrecer las capacidades funcionales necesarias. (Fuente de la imagen: Amazon Web Services)

Como sugieren estas representaciones arquitectónicas, el esfuerzo de desarrollo de software requerido para crear una aplicación de IIoT es tan desafiante y expansivo como la implementación de redes periféricas de sistemas de sensores y actuadores. Pocas organizaciones pueden permitirse el lujo de retrasar el desarrollo de este complejo software hasta que la red de dispositivos sea capaz de generar suficientes datos. De hecho, la implementación de la red de dispositivos podría tener que esperar a una mayor definición y refinamiento que puede surgir cuando los especialistas en análisis y los expertos en aprendizaje de máquinas comiencen a trabajar con los resultados de las aplicaciones. En el peor de los casos, la implementación de la red de dispositivos y el desarrollo de software se encuentran en un punto muerto: cada uno depende de los resultados del otro.

Afortunadamente, la solución a este dilema radica en la naturaleza de las arquitecturas de IoT. Más allá de algunas similitudes generales, las arquitecturas de servicios en la nube como las ilustradas anteriormente de Microsoft y AWS difieren, por supuesto, en los detalles. Sin embargo, todos ellos demuestran una característica arquitectónica similar que se encuentra típicamente en las plataformas en la nube de IoT: Un módulo de servicio de interfaz bien definido o una funcionalidad de capa que separa la red periférica de los dispositivos de IoT de la aplicación de software basada en la nube. Además de proporcionar una conectividad uniforme, estos servicios de interfaz son vitales para la gestión y la seguridad de los dispositivos, así como para otras capacidades clave necesarias en las aplicaciones del IIoT a gran escala.

En la nube Microsoft Azure, este servicio de interfaz se llama Azure IoT Hub (consulte la Figura 1 de nuevo); en la nube AWS, es AWS IoT Core (consulte la Figura 2 de nuevo). En la plataforma Google Cloud, esta interfaz es el núcleo Cloud IoT Core, y en la nube de IBM, es el servicio de plataforma de IoT de IBM Watson. Otras plataformas como la ThingWorx IoT Platform se conectan de manera similar a través de servicios de conectividad como el ThingWorx Edge Microserver, ThingWorx Kepware Server o los kits de herramientas de adaptador de protocolo. En resumen, toda plataforma de nubes debe proporcionar un servicio de interfaz coherente que canalice los datos de la periferia a los servicios de nubes o se arriesgue a una confusa maraña de conexiones de dispositivos periféricos directamente a recursos individuales en lo profundo de la nube.

Inyección de datos simulados

Al utilizar el kit de desarrollo de software (SDK) de cada plataforma de IoT, los desarrolladores pueden inyectar datos de sensores simulados directamente en el servicio de interfaz de la plataforma a los niveles de volumen, velocidad y variedad necesarios para verificar la funcionalidad y el rendimiento de la aplicación. Los datos simulados generados a la velocidad y resolución deseadas llegan al servicio de interfaz utilizando protocolos estándar como el Transporte de telemetría MQ (MQTT), el Protocolo de aplicación restringida (CoAP) y otros. Para el servicio de interfaz (y el software de aplicación posterior), los flujos de datos simulados son indistinguibles de los datos adquiridos por un sistema de sensores de hardware. Cuando las redes de dispositivos están listas para entrar en línea, los flujos de datos de sus sensores simplemente reemplazan los flujos de datos simulados que llegan al servicio de interfaz.

Los proveedores de plataformas de nubes suelen apoyar este enfoque de simulación de datos en diferentes niveles de capacidad. Por ejemplo, Google demuestra una aplicación sencilla impulsada por la simulación con una arquitectura de referencia y un código de muestra que implementa un simple bucle de control de un ventilador de temperatura controlada. Como las arquitecturas ilustradas anteriormente, esta arquitectura aprovecha los servicios de la plataforma Google Cloud alimentados por la interfaz de servicio Google Cloud IoT Core (Figura 3).

Figura 3: En cualquier plataforma en la nube de IoT, los simuladores de dispositivos utilizan los mismos protocolos de comunicación usados por los dispositivos físicos para alimentar datos a un servicio de interfaz como el núcleo Cloud IoT Core para la arquitectura de aplicación de la Plataforma en la nube de Google que se muestra aquí. (Fuente de la imagen: Google)

En esta aplicación de muestra, los simuladores de dispositivos de sensores templados generan datos a una velocidad de actualización seleccionada y pasan los datos al servicio de interfaz Google Cloud IoT Core utilizando el protocolo de mensajería MQTT. A su vez, ese servicio de interfaz utiliza los protocolos estándar de publicación-suscripción (pub/sub) de la plataforma para pasar los datos a un servidor simulado, que responde con un comando para encender o apagar el ventilador según sea necesario (Figura 4).

Figura 4: Una aplicación de muestra de Google demuestra un bucle de control básico que comprende un dispositivo simulado que envía datos a través del núcleo de Google Cloud IoT a un servidor simulado utilizando métodos de comunicación estándar. (Fuente de la imagen: Google)

Google proporciona un ejemplo de código Python que implementa esta aplicación básica. En este código, una instancia de clase de Dispositivo incluye un método que actualiza la temperatura simulada basada en el estado del ventilador simulado. La rutina principal llama a ese método a una tasa especificada y envía los datos utilizando un servicio de conexión MQTT proporcionado por el módulo cliente de Eclipse paho-mqtt Python MQTT (Listado 1).

Copy
class Device(object):
     """Represents the state of a single device."""
 
    def __init__(self):
         self.temperature = 0
         self.fan_on = False
         self.connected = False
 
    def update_sensor_data(self):
         """Pretend to read the device's sensor data.
        Si el ventilador está encendido, suponga que la temperatura ha disminuido un grado,        de lo contrario, asumir que aumentó un grado.        """
         if self.fan_on:
             self.temperature -= 1
         else:
             self.temperature += 1
.
.
.
def main():
.
.
.    device = Device()
 
 
    client.on_connect = device.on_connect
     client.on_publish = device.on_publish
     client.on_disconnect = device.on_disconnect
     client.on_subscribe = device.on_subscribe
     client.on_message = device.on_message
 
 
    client.connect(args.mqtt_bridge_hostname, args.mqtt_bridge_port)
 
 
    client.loop_start()
 
 
    # This is the topic that the device will publish telemetry events
     # (temperature data) to.
     mqtt_telemetry_topic = '/devices/{}/events'.format(args.device_id)
 
 
    # This is the topic that the device will receive configuration updates on.
     mqtt_config_topic = '/devices/{}/config'.format(args.device_id)
 
 
    # Wait up to 5 seconds for the device to connect.
     device.wait_for_connection(5)
 
 
    # Subscribe to the config topic.
     client.subscribe(mqtt_config_topic, qos=1)
 
 
    # Update and publish temperature readings at a rate of one per second.
     for _ in range(args.num_messages):
         # In an actual device, this would read the device's sensors. Here,
         # you update the temperature based on whether the fan is on.
         device.update_sensor_data()
 
 
        # Report the device's temperature to the server by serializing it
         # as a JSON string.
         payload = json.dumps({'temperature': device.temperature})
         print('Publishing payload', payload)
         client.publish(mqtt_telemetry_topic, payload, qos=1)
         # Send events every second.
         time.sleep(1)
 
 
    client.disconnect()
     client.loop_stop()
     print('Finished loop successfully. Goodbye!')

Lista 1: Este fragmento de la aplicación de muestra de Google ilustra cómo la rutina principal actualiza periódicamente una instancia de clase de dispositivo que almacena el valor actual del sensor de temperatura simulado y proporciona un método que actualiza ese valor dependiendo del estado del ventilador simulado. (Fuente del código: Google)

A su vez, una instancia de clase Server proporciona un módulo que actualiza el estado del ventilador dependiendo de los datos de temperatura recibidos de la instancia de clase Device (Listado 2).

Copy
class Server(object):
     """Represents the state of the server."""
.
.
.    def _update_device_config(self, project_id, region, registry_id, device_id,
                               data):
         """Push the data to the given device as configuration."""
         config_data = None
         print('The device ({}) has a temperature '
               'of: {}'.format(device_id, data['temperature']))
         if data['temperature'] < 0:
             # Turn off the fan.
             config_data = {'fan_on': False}
             print('Setting fan state for device', device_id, 'to off.')
         elif data['temperature'] > 10:
             # Turn on the fan
             config_data = {'fan_on': True}
             print('Setting fan state for device', device_id, 'to on.')
         else:
             # Temperature is OK, don't need to push a new config.
             return

Lista 2: En este fragmento de la aplicación de muestra de Google, el método _update_device_config() definido en la clase Server proporciona la lógica de negocio de la aplicación, estableciendo el estado del ventilador en encendido cuando la temperatura sube por encima de un valor definido y estableciendo el estado del ventilador en off cuando baja. (Fuente del código: Google)

Además del código de muestra de Google, los desarrolladores pueden encontrar docenas de simuladores de dispositivos, sistemas y redes de IoT de código abierto en repositorios como GitHub. Por ejemplo, el código del simulador del sistema Raspberry Pi de código abierto de Microsoft incluye una integración preconstruida al centro de IoT Azure para el rápido desarrollo de aplicaciones basadas en la nube que interactúan con las placas Raspberry Pi. Además, las herramientas de programación de código bajo como Node-RED soportan módulos preconstruidos (nodos) para alimentar datos de sensores simulados a las principales interfaces de servicio de IoT de la plataforma en la nube. Utilizando estos enfoques, los desarrolladores pueden generar fácilmente un flujo de datos de sensores.

Ejecutar simulaciones a escala

La dificultad de utilizar simuladores a nivel de dispositivos y herramientas relacionadas es que la gestión de la simulación de datos puede convertirse en un proyecto en sí mismo. Para hacer funcionar los simuladores, los desarrolladores necesitan proveer y mantener los recursos como con cualquier aplicación. Lo que más preocupa es que los modelos de dispositivos utilizados para generar datos realistas se conviertan en un proyecto independiente, fuera del proceso de desarrollo de aplicaciones del IIoT. A medida que avanza el desarrollo, los desarrolladores deben asegurarse de que los modelos de dispositivos permanezcan sincronizados funcionalmente con cualquier cambio en la definición de la red y la aplicación del dispositivo del IIoT. En el caso de las aplicaciones de IIoT de nivel empresarial, los desarrolladores pueden descubrir que la ampliación de estas simulaciones puede ser difícil en el mejor de los casos, e incluso comenzar a utilizar los recursos necesarios para desarrollar la aplicación.

Los principales proveedores de plataformas en la nube de IoT abordan estas preocupaciones con soluciones de simulación de dispositivos de IoT diseñados para escalar tan fácilmente como otros recursos en la nube en sus respectivas plataformas. Por ejemplo, el Simulador de Dispositivos de IoT de AWS proporciona una plantilla de AWS para su servicio de configuración de CloudFormation, que despliega una red privada virtual que conecta microservicios implementados en contenedores que se ejecutan en el motor sin servidores de AWS Fargate (Figura 5).

Figura 5: El simulador de dispositivos de IoT de AWS combina múltiples servicios de AWS para entregar un flujo escalable de datos de dispositivos al mismo núcleo de IoT de AWS utilizado por los dispositivos físicos. (Fuente de la imagen: Amazon Web Services)

Los desarrolladores acceden a la simulación de forma interactiva a través de una consola de interfaz gráfica de usuario (GUI) que se ejecuta en el servicio Amazon S3, o de forma programada a través de la interfaz de programación de aplicaciones (API) del simulador de dispositivos de IoT, generada por la plantilla CloudFormation en el servicio Amazon API Gateway. Durante una simulación, el microservicio del Simulador de Dispositivos de IoT extrae las configuraciones de los dispositivos de la base de datos NoSQL de Amazon DynamoDB de acuerdo con un plan de simulación general descrito en su propio elemento de configuración.

Las configuraciones de los dispositivos son registros JSON que definen los nombres de los atributos del dispositivo (temperatura, por ejemplo), el rango de valores (-40 a 85, por ejemplo) y actualizan el intervalo del dispositivo y la duración de la simulación, entre otras informaciones. Los desarrolladores pueden añadir tipos de dispositivos de forma interactiva a través de la consola o de forma programada a través de la API. Utilizando los métodos normales de DevOps, los tipos de dispositivos, la configuración y la infraestructura pueden ser rápidamente escalados para alcanzar las tasas de actualización de datos deseadas que llegan al núcleo de la AWS IoT y a la aplicación posterior.

En el simulador del dispositivo Azure, los desarrolladores pueden complementar aún más la lista básica de atributos con un conjunto de comportamientos soportados por el dispositivo durante la ejecución de la simulación, así como un conjunto de métodos que la aplicación de la nube puede llamar directamente.

Los gemelos digitales

Este tipo de simulación de datos de dispositivos está estrechamente ligado conceptualmente con las capacidades de gemelos digitales que surgen en las plataformas comerciales en la nube de IoT. A diferencia de las sombras de los dispositivos que normalmente sólo proporcionan una representación estática del estado del dispositivo, los gemelos digitales extienden un modelo de dispositivo virtual para que coincida con el estado del dispositivo físico, así como con su comportamiento.

En Azure de Microsoft, el servicio Azure Digital Twins permite a los desarrolladores incluir funciones definidas por el usuario para definir el comportamiento durante la simulación de un dispositivo, y seguir alimentando los resultados al Azure IoT Hub como antes. Independientemente de si es simulado o real, los datos entrantes se envían a un servicio de enrutamiento de eventos para su posterior distribución en la aplicación. Microsoft también utiliza los datos de los gemelos digitales para crear gráficos espaciales que representan las interacciones y el estado entre los elementos en entornos jerárquicos complejos, como un sistema de automatización industrial que comprende múltiples redes (Figura 6).

Figura 6: El servicio Microsoft Azure Digital Twins permite a los desarrolladores construir dispositivos virtuales que coincidan con sus homólogos físicos en cuanto a características y capacidades y proporcionar la base para servicios sofisticados como gráficos espaciales de jerarquías complejas de la IIoT. (Fuente de la imagen: Microsoft)

Para las aplicaciones del IIoT, los gemelos digitales pueden proporcionar un poderoso mecanismo capaz de soportar todo el ciclo de vida de las aplicaciones construidas alrededor de estas capacidades. En las primeras etapas de desarrollo, los gemelos digitales pueden ser impulsados a escala por los servicios de simulación de dispositivos de la plataforma. A medida que las redes físicas de IIoT se ponen en línea, esos datos simulados que alimentan al gemelo digital pueden ser reemplazados por datos de dispositivos. Más adelante, en una aplicación de IIoT plenamente implementada, los desarrolladores pueden utilizar las diferencias encontradas entre un dispositivo físico y su gemelo digital como aporte adicional a los algoritmos de mantenimiento predictivo o a los detectores de intrusión de seguridad, por ejemplo. A lo largo del ciclo de vida, los gemelos digitales pueden proteger la aplicación de las interrupciones de la red o de cambios significativos en la configuración de las redes de dispositivos IIoT.

La aparición de gemelos digitales en las plataformas de IoT también proporciona un beneficio secundario al ofrecer un enfoque estandarizado para describir los atributos y comportamientos del modelo de dispositivo. Para su lenguaje de descripción, el servicio de Microsoft Azure Digital Twins utiliza el JSON-LD (JavaScript Object Notation for Linked Data). Respaldado por el Consorcio de la World Wide Web (W3C), el JSON-LD proporciona un formato estándar para la serialización de datos vinculados basado en el formato estándar de la industria JSON, que ya se utiliza en varios otros segmentos de aplicación.

Las descripciones gemelas digitales estandarizadas pueden acelerar aún más el desarrollo con la aparición de depósitos de descripciones gemelas digitales preconstruidas para sensores y actuadores. Por ejemplo, Bosch ya proporciona descripciones gemelas digitales de código abierto de varios de sus sensores escritas en el lenguaje de Eclipse Vorto y publicadas en el repositorio de Eclipse Vorto. Al utilizar una gramática familiar para la mayoría de los programadores, el lenguaje de Eclipse Vorto proporciona un método simple para describir modelos e interfaces para gemelos digitales. Más tarde, los desarrolladores pueden convertir sus descripciones del lenguaje Vorto a JSON-LD u otros formatos según sea necesario.

Construir la aplicación del IIoT

Ya sea que se construya con simuladores discretos o con plataformas orientadas al microservicio, la simulación de datos de dispositivos proporciona una solución eficaz basada en software para acelerar el desarrollo de aplicaciones. En el caso de las aplicaciones de la IIoT que utilizan redes de dispositivos múltiples, la migración de las simulaciones de los dispositivos al borde puede ayudar a facilitar aún más la transición a la implementación sin sacrificar la necesidad de datos representativos al principio del desarrollo de la aplicación.

Los sistemas de edge computing juegan un papel cada vez más vital en las aplicaciones de IoT a gran escala. Estos sistemas proporcionan los recursos locales necesarios para las nuevas necesidades que van desde el preprocesamiento de datos básicos para reducir la cantidad de datos que llegan a la nube, hasta las capacidades de clasificación avanzada como los modelos de inferencia de aprendizaje automático. Los sistemas de computación de borde también juegan un papel más fundamental como puertas de comunicación entre las redes de dispositivos de área de campo y las redes de retroceso de alta velocidad.

Las puertas de enlace, como la familia de conductos programables MultiConnect de Multi-Tech Systems, proporcionan plataformas que combinan el soporte de comunicaciones con capacidades de procesamiento de bordes. El MTCAP-915-001A de Multi-Tech para regiones de 915 megahercios (MHz) y el MTCAP-868-001A para regiones de 868 MHz proporcionan conectividad LoRaWAN para agregar datos de dispositivos de red de área de campo, y conectividad Ethernet o 4G-LTE en el lado de la nube. Al basarse en el sistema operativo de código abierto Multi-Tech Linux (mLinux), estas plataformas también proporcionan un entorno de desarrollo familiar para ejecutar simulaciones de dispositivos. A medida que las redes de campo separadas se ponen en línea con sensores físicos y otros dispositivos, cada unidad puede volver a su papel de puerta de enlace de comunicaciones, redirigiendo los esfuerzos de procesamiento a requisitos como el preprocesamiento de datos.

Conclusión

Las aplicaciones del IIoT presentan importantes desafíos para la implementación e de redes de sensores en el campo y el desarrollo de un software de aplicaciones basado en nubes capaz de transformar los datos de los sensores en resultados útiles. La dependencia mutua de las redes de sensores y el software de aplicación puede hacer que el desarrollo se tambalee mientras que la implementación de los sensores y la implementación del software se esperan mutuamente para alcanzar un nivel suficiente de masa crítica.

Como se ha demostrado, los desarrolladores pueden romper este punto muerto y acelerar el desarrollo de las aplicaciones del IIoT simulando flujos de datos a niveles realistas de volumen, velocidad y variedad.