Accélérer le développement d'applications IIoT – 1re partie : simulation des données de dispositifs IoT

Note de l'éditeur : les projets de développement d'applications embarquées sont souvent retardés, car les développeurs attendent que les implémentations matérielles des nouveaux dispositifs soient disponibles. Le développement d'applications pour l'Internet industriel des objets (IIoT) est confronté au même problème : les développeurs doivent attendre les données de capteur requises pour les applications comme les systèmes industriels de maintenance préventive ou les systèmes d'automatisation d'installation basés sur des méthodes d'apprentissage automatique. Cette série en deux parties étudie les alternatives permettant d'assurer les flux de données précoces requis pour accélérer le développement d'applications IIoT. Ici, la 1re partie décrit l'utilisation des méthodes de simulation pour générer ces flux de données. La 2e partie analyse les options pour le prototypage rapide de systèmes de capteurs afin de générer des données.

Les applications de l'Internet industriel des objets (IIoT) à grande échelle présentent de nombreux défis qui peuvent bloquer les déploiements et laisser les entreprises s'interroger sur le retour sur investissement des nombreuses ressources nécessaires à l'implémentation. Il est nécessaire de disposer d'un accès aisé aux données de simulation de déploiement pour éviter ce genre de situations et aider les développeurs à déterminer rapidement les avantages du déploiement IIoT.

En utilisant des méthodes de simulation pour générer des flux de données réalistes, les développeurs peuvent commencer le développement d'applications IIoT bien avant le déploiement du réseau IoT. Ils peuvent même peaufiner la définition du réseau de capteurs IIoT en lui-même.

Cet article décrit comment les différentes plateformes cloud IoT assurent la simulation de données, avant de présenter des exemples de passerelles de Multi-Tech Systems Inc. qui peuvent accélérer davantage le déploiement.

Arguments en faveur de la simulation des données IIoT

L'utilisation de données simulées pour commander le développement d'applications et de systèmes n'est bien sûr pas nouvelle. Les développeurs utilisent des méthodes de simulation au niveau système depuis des dizaines d'années pour tester les infrastructures informatiques et les services de connectivité. Ces tests jouent un rôle important dans la vérification de la robustesse des configurations statiques. Sur les plateformes de services cloud, ces tests fournissent une méthode relativement simple pour vérifier la mise à l'échelle automatique des machines virtuelles et d'autres ressources cloud.

Les applications IIoT partagent ces mêmes exigences et bien d'autres encore. Outre l'aide apportée pour les tests de charge et la mise à l'échelle automatique, la simulation de données fournit un outil important pour vérifier l'intégration de nombreux services et ressources disparates qui servent à implémenter des logiciels aussi complexes qu'une application IIoT de niveau entreprise. Au-delà de ces pratiques plus fondamentales, la simulation de données peut accélérer le développement d'applications IIoT complexes qui reposent sur les plateformes de services sophistiquées proposées par les principaux fournisseurs de cloud.

Côté logiciel

Les applications IIoT fonctionnent sur des architectures complexes qui semblent considérablement différentes du point de vue des développeurs de logiciels d'application que de celui des développeurs de systèmes d'actionneurs et de capteurs. Pour ces derniers, une architecture IIoT à grande échelle est un vaste ensemble de capteurs et d'actionneurs qui communiquent avec les processus physiques au cœur de l'application globale. Pour les développeurs de logiciels d'application, une architecture IIoT de niveau entreprise comprend un certain nombre de services dont l'activité coordonnée assure en définitive les fonctionnalités de l'application.

L'architecture de référence IoT Azure de Microsoft offre un aperçu représentatif des applications IIoT typiques (et des applications IoT en général) du point de vue des logiciels d'application. Cet aperçu résume les multiples services fonctionnels qu'une application typique regroupe dans le cloud pour fournir des informations et des actions basées sur les données provenant des points d'extrémité et des dispositifs en périphérie (Figure 1).

Figure 1 : L'architecture de référence IoT Azure de Microsoft illustre les nombreux types de services et de ressources cloud généralement requis par une application IIoT pour fournir des informations et des actions utiles à partir des données générées par les réseaux de dispositifs en périphérie. (Source de l'image : Microsoft Corp.)

Des solutions applicatives spécifiques déploient ces ressources cloud dans des combinaisons appropriées, connectées de manière fonctionnelle via des mécanismes d'échange standardisés, et coordonnées par la logique applicative. Par exemple, dans sa solution de véhicule connecté, Amazon Web Services (AWS) suggère une façon de mélanger et d'assortir les services cloud en modules chargés de fournir les différentes fonctionnalités et capacités de l'application (Figure 2).

Figure 2 : La solution de véhicule connecté d'AWS fournit un aperçu représentatif de l'orchestration des services cloud d'une application IoT à grande échelle typique pour fournir les capacités fonctionnelles nécessaires. (Source de l'image : Amazon Web Services)

Comme le suggèrent ces représentations architecturales, l'effort de développement logiciel requis pour créer une application IIoT est tout aussi difficile et vaste que l'implémentation des réseaux périphériques de capteurs et d'actionneurs. Quelques organisations peuvent se permettre de retarder le développement de ce logiciel complexe jusqu'à ce que le réseau de dispositifs soit en mesure de générer suffisamment de données. En fait, il est probable que le déploiement du réseau de dispositifs doive attendre une définition et une amélioration complémentaires qui peuvent survenir lorsque les spécialistes de l'analyse et les experts en apprentissage automatique commencent à travailler avec les résultats de l'application. Dans le pire des cas, le déploiement du réseau de dispositifs et le développement logiciel se retrouvent dans une impasse : chacun dépend des résultats de l'autre.

Heureusement, la solution à ce problème réside dans la nature des architectures IoT. Outre quelques similitudes générales, les architectures de services cloud comme celles de Microsoft et d'AWS illustrées ci-dessus sont bien entendu différentes lorsque l'on s'intéresse aux détails. Néanmoins, elles présentent toutes une fonctionnalité architecturale identique à celle que l'on trouve dans les plateformes cloud IoT : une fonctionnalité de couche ou de module de services d'interface bien définie qui sépare le réseau périphérique de dispositifs IoT de l'application logicielle basée sur le cloud. En plus de fournir une connectivité uniforme, ces services d'interface sont cruciaux pour la gestion et la sécurité des dispositifs, ainsi que pour les autres capacités principales requises dans les applications IIoT à grande échelle.

Dans le cloud Azure de Microsoft, ce service d'interface est appelé Azure IoT Hub (voir de nouveau la Figure 1). Pour le cloud d'AWS, il s'agit d'AWS IoT Core (voir de nouveau la Figure 2). Pour Google Cloud Platform, cette interface s'appelle Cloud IoT Core. Quant à IBM Cloud, il s'agit d'IBM Watson IoT Platform Service. D'autres plateformes, comme la plateforme IoT ThingWorx, se connectent également par le biais de services de connectivité (comme ThingWorx Edge Microserver, ThingWorx Kepware Server) ou via des boîtes à outils d'adaptateur de protocoles. En résumé, toutes les plateformes cloud doivent fournir un service d'interface cohérent qui dirige les données de la périphérie vers les services cloud, sous peine de faire face à un enchevêtrement confus de connexions allant directement des périphériques aux ressources individuelles au sein du cloud.

Injection de données simulées

En utilisant le kit de développement logiciel (SDK) de chaque plateforme IoT, les développeurs peuvent injecter des données de capteurs simulées directement dans le service d'interface de la plateforme, avec le volume, la vitesse et la variété nécessaires pour vérifier les fonctionnalités et les performances de l'application. Les données simulées générées à la résolution et à la vitesse souhaitées atteignent le service d'interface grâce à des protocoles standard, comme MQ Telemetry Transport (MQTT), Constrained Application Protocol (CoAP) et bien d'autres. Pour le service d'interface (et le logiciel d'application en aval), les flux de données simulées sont impossibles à distinguer des données acquises par un système de capteurs matériel. Lorsque les réseaux de dispositifs sont prêts à être mis en ligne, les flux de données de leurs capteurs remplacent tout simplement les flux de données simulées qui parviennent au service d'interface.

Les fournisseurs de plateformes cloud prennent généralement en charge cette approche de simulation de données avec différents niveaux de capacité. Par exemple, Google présente une application commandée par simulation simple avec une architecture de référence et du code d'exemple qui implémente une boucle de contrôle simple pour un ventilateur thermorégulé. Comme les architectures illustrées précédemment, cette architecture exploite les services Google Cloud Platform alimentés par l'interface du service Google Cloud IoT Core (Figure 3).

Figure 3 : Sur toutes les plateformes cloud IoT, les simulateurs de dispositifs utilisent les mêmes protocoles de communication que ceux des dispositifs physiques afin de fournir des données à un service d'interface, comme Google Cloud IoT Core pour l'architecture d'applications Google Cloud Platform illustrée ici. (Source de l'image : Google)

Dans cette application d'exemple, les simulateurs de dispositifs de capteurs de température génèrent des données à une vitesse de mise à jour sélectionnée et les transmettent au service d'interface Google Cloud IoT Core via le protocole de messagerie MQTT. Ensuite, ce service d'interface utilise les protocoles Publish-Subscribe (pub/sub) standard de la plateforme pour envoyer les données à un serveur simulé. Ce dernier répond avec une commande qui active ou désactive le ventilateur au besoin (Figure 4).

Figure 4 : Une application Google d'exemple montre une boucle de contrôle de base comprenant un dispositif simulé qui envoie des données via Google Cloud IoT Core à un serveur simulé grâce à des méthodes de communications standard. (Source de l'image : Google)

Google fournit du code Python d'exemple qui implémente cette application de base. Dans ce code, une instance de classe Device inclut une méthode qui met à jour la température simulée en fonction de l'état du ventilateur simulé. La routine principale fait appel à cette méthode à une certaine vitesse et envoie les données à l'aide d'un service de connexion MQTT fourni par le module client Eclipse paho-mqtt Python MQTT (Liste 1).

Copier 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.         If the fan is on, assume the temperature decreased one degree,         otherwise assume that it increased one degree.         """          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!') 

Liste 1 : Cet extrait de l'application d'exemple de Google illustre comment la routine main met périodiquement à jour une instance de classe Device qui stocke la valeur actuelle du capteur de température simulé et fournit une méthode qui met à jour cette valeur en fonction de l'état du ventilateur simulé. (Source du code : Google)

À son tour, une instance de classe Server fournit un module qui met à jour l'état du ventilateur en fonction des données de température provenant de l'instance de classe Device (Liste 2).

Copier 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 

Liste 2 : Dans cet extrait de l'application d'exemple de Google, la méthode _update_device_config() définie dans la classe Server fournit la logique pour l'application, en réglant l'état du ventilateur sur Marche lorsque la température dépasse une valeur définie et sur Arrêt lorsqu'elle baisse. (Source du code : Google)

Outre le code d'exemple de Google, les développeurs peuvent trouver des dizaines de simulateurs de réseaux, de systèmes et de dispositifs IoT open-source sur des référentiels comme GitHub. Par exemple, le code du simulateur de système Raspberry Pi open-source de Microsoft inclut l'intégration pré-conçue dans Azure IoT Hub pour un développement rapide d'applications basées cloud qui communiquent avec des cartes Raspberry Pi. De plus, les outils de programmation schématique comme Node-RED prennent en charge les modules pré-conçus (nodes) pour alimenter en données de capteurs simulés les principales interfaces de services IoT des plateformes cloud. Grâce à ces approches, les développeurs peuvent facilement générer un flux de données de capteurs.

Exécution des simulations à l'échelle

La difficulté qui découle de l'utilisation de simulateurs au niveau des dispositifs et d'outils connexes vient du fait que la gestion de la simulation des données peut devenir un projet en soi. Pour faire fonctionner les simulateurs, les développeurs doivent fournir et maintenir des ressources, comme pour n'importe quelle application. Plus préoccupant encore, les modèles de dispositifs utilisés pour générer des données réalistes deviennent un projet distinct en dehors du processus de développement d'applications IIoT. Au cours du développement, les développeurs doivent s'assurer que les modèles de dispositifs restent synchronisés de manière fonctionnelle avec tout changement de définition du réseau de dispositifs et de l'application IIoT. Pour les applications IIoT de niveau entreprise, les développeurs peuvent constater que la mise à l'échelle de ces simulations peut s'avérer très difficile et même commencer à puiser dans les ressources nécessaires au développement de l'application.

Les principaux fournisseurs de plateformes cloud IoT répondent à ces préoccupations avec des solutions de simulation de dispositifs IoT conçues pour être mises à l'échelle aussi facilement que les autres ressources cloud de leurs plateformes respectives. Par exemple, l'AWS IoT Device Simulator (simulateur de dispositif IoT) fournit un modèle AWS pour son service de configuration CloudFormation, qui déploie un réseau privé virtuel connectant des micro-services implémentés dans des conteneurs exécutés sur le moteur sans serveur AWS Fargate (Figure 5).

Figure 5 : L'AWS IoT Device Simulator combine plusieurs services AWS pour fournir un flux évolutif de données de dispositifs au même service AWS IoT Core utilisé par les dispositifs physiques. (Source de l'image : Amazon Web Services)

Les développeurs accèdent à la simulation de manière interactive par le biais d'une console d'interface utilisateur graphique (GUI) s'exécutant dans le service Amazon S3, ou par programmation via l'interface de programmation (API) IoT Device Simulator générée par le modèle CloudFormation dans le service Amazon API Gateway. Au cours d'une simulation, le micro-service IoT Device Simulator extrait les configurations des dispositifs de la base de données NoSQL DynamoDB d'Amazon, conformément à un plan de simulation global décrit dans son propre élément de configuration.

Les configurations des dispositifs sont des enregistrements JSON qui définissent les noms des attributs des dispositifs (température, par exemple), la plage de valeurs (-40 à 85, par exemple) et mettent à jour l'intervalle des dispositifs et la durée de la simulation, entre autres. Les développeurs peuvent ajouter des types de dispositifs de manière interactive via la console ou par programmation via l'interface de programmation. En utilisant des méthodes DevOps normales, les types de dispositifs, la configuration et l'infrastructure peuvent être rapidement mis à l'échelle pour atteindre les taux de mise à jour de données souhaités qui parviennent à AWS IoT Core et à l'application en aval.

Dans le simulateur de dispositif Azure, les développeurs peuvent enrichir la liste de base des attributs avec un ensemble de comportements pris en charge par le dispositif lors de l'exécution de la simulation, ainsi qu'un ensemble de méthodes auxquelles l'application cloud peut directement faire appel.

Jumeaux numériques

Ce type de simulation de données de dispositifs est étroitement lié (sur le plan conceptuel) aux capacités de jumelage numérique qui émergent sur les plateformes cloud IoT commerciales. Contrairement aux doubles de dispositifs qui ne fournissent généralement qu'une représentation statique de l'état du dispositif, les jumeaux numériques étendent un modèle de dispositif virtuel qui correspond à l'état physique du dispositif ainsi qu'à son comportement.

Dans Azure de Microsoft, le service Azure Digital Twins permet aux développeurs d'inclure des fonctions définies par l'utilisateur pour définir le comportement lors d'une simulation de dispositif, tout en fournissant les résultats à l'Azure IoT Hub comme auparavant. Qu'elles soient simulées ou réelles, les données entrantes sont ensuite envoyées vers un service de routage d'événements pour une distribution plus poussée dans l'application. Microsoft utilise également les données des jumeaux numériques pour créer des graphiques spatiaux qui décrivent les interactions et l'état des éléments dans les environnements hiérarchiques complexes, comme un système d'automatisation industrielle constitué de plusieurs réseaux (Figure 6).

Figure 6 : Le service Azure Digital Twins de Microsoft permet aux développeurs d'élaborer des dispositifs virtuels dont les caractéristiques et fonctionnalités correspondent à celles de leurs homologues physiques et qui fournissent la base de services sophistiqués comme les graphiques spatiaux de hiérarchies IIoT complexes. (Source de l'image : Microsoft)

Pour les applications IIoT, les jumeaux numériques peuvent fournir un mécanisme puissant capable de prendre en charge l'intégralité du cycle de vie des applications conçues autour de ces capacités. Aux premiers stades du développement, les jumeaux numériques peuvent être commandés à grande échelle par les services de simulation de dispositifs de la plateforme. Au fur et à mesure que les réseaux IIoT physiques sont mis en ligne, il est possible de remplacer ces flux de données simulées vers le jumeau numérique par des flux de données de dispositif. Par la suite, dans une application IIoT entièrement déployée, les développeurs peuvent utiliser toutes les différences trouvées entre un dispositif physique et son jumeau numérique comme entrée supplémentaire pour les algorithmes de maintenance préventive ou les détecteurs d'intrusion de sécurité, par exemple. Tout au long du cycle de vie, les jumeaux numériques peuvent protéger l'application contre les pannes de réseau ou les modifications importantes apportées à la configuration des réseaux de dispositifs IIoT.

L'émergence des jumeaux numériques dans les plateformes IoT fournit également un avantage secondaire en offrant une approche standardisée pour la description des attributs et des comportements des modèles de dispositifs. Pour son langage de description, le service Azure Digital Twins de Microsoft utilise JSON-LD (JavaScript Object Notation for Linked Data). Soutenu par le World Wide Web Consortium (W3C), JSON-LD fournit un format standard pour la sérialisation des données liées, qui est basé sur le format JSON standard de l'industrie, déjà utilisé dans un certain nombre d'autres segments d'application.

Les descriptions standardisées de jumeaux numériques peuvent accélérer davantage le développement grâce à l'émergence de référentiels de descriptions de jumeaux numériques pré-conçus pour les capteurs et les actionneurs. Par exemple, Bosch fournit déjà des descriptions de jumeaux numériques open-source pour plusieurs de ses capteurs, rédigées dans le langage Eclipse Vorto et publiées dans le référentiel Eclipse Vorto. Grâce à une grammaire familière à la plupart des programmateurs, le langage Eclipse Vorto fournit une méthode simple pour décrire les modèles et les interfaces des jumeaux numériques. Par la suite, les développeurs peuvent convertir leurs descriptions en langage Vorto au format JSON-LD ou dans d'autres formats, au besoin.

Développement de l'application IIoT

Qu'elle soit réalisée à l'aide de simulateurs discrets ou de plateformes orientées micro-services, la simulation de données de dispositifs offre une solution logicielle efficace pour accélérer le développement d'applications. Pour les applications IIoT qui utilisent de nombreux réseaux de dispositifs, la migration des simulations de dispositifs en périphérie peut faciliter davantage la transition vers le déploiement sans sacrifier le besoin de données représentatives au début du développement de l'application.

Les systèmes d'edge computing jouent un rôle de plus en plus essentiel dans les applications IoT à grande échelle. Ces systèmes fournissent les ressources locales nécessaires pour répondre aux besoins émergents, du prétraitement de base des données pour réduire la quantité de données qui atteignent le cloud aux capacités avancées de classification, comme les modèles d'inférence par apprentissage automatique. Les systèmes d'edge computing jouent également un rôle plus fondamental en tant que passerelles de communication entre les réseaux de dispositifs de type Field Area et les réseaux de backhaul haute vitesse.

Les passerelles comme la gamme MultiConnect Conduit programmable de Multi-Tech Systems fournissent des plateformes qui combinent la prise en charge des communications et les capacités de traitement en périphérique. Le système MTCAP-915-001A de Multi-Tech pour les régions 915 mégahertz (MHz) et le MTCAP-868-001A pour les régions 868 MHz fournissent une connectivité LoRaWAN pour l'agrégation des données de dispositifs sur les réseaux de type Field Area et une connectivité Ethernet ou 4G-LTE côté cloud. Basées sur le système d'exploitation open-source Multi-Tech Linux (mLinux), ces plateformes fournissent également un environnement de développement familier pour l'exécution de simulations de dispositifs. À mesure que des réseaux de terrain distincts sont mis en ligne avec des capteurs physiques et d'autres dispositifs, chaque unité peut reprendre son rôle de passerelle de communication, en réorientant les efforts de traitement vers des exigences comme le prétraitement des données.

Conclusion

Les applications IIoT présentent des défis importants pour le déploiement de réseaux de capteurs sur le terrain et le développement de logiciels d'application basés cloud capables de transformer les données des capteurs en résultats utiles. La dépendance mutuelle des réseaux de capteurs et des logiciels d'application peut mettre en difficulté le développement lorsque le déploiement des capteurs et l'implémentation des logiciels attendent l'un et l'autre d'atteindre un niveau de masse critique suffisant.

Comme indiqué ici, les développeurs peuvent sortir de cette impasse et accélérer le développement d'applications IIoT en simulant des flux de données à des niveaux réalistes de volume, de vitesse et de variété.