Déployer rapidement des dispositifs IoT de puissance industrielle basés sur des capteurs sur Amazon Web Services

Les dispositifs de point d'extrémité pour l'Internet industriel des objets (IIoT) constituent l'interface essentielle entre les ressources basées sur le cloud et les processus industriels. Cependant, en reliant la périphérie au cloud, un dispositif IIoT doit répondre à des exigences croissantes en termes de performances, de connectivité, d'intégration de capteurs, de sécurité et de fiabilité au niveau du dispositif lui-même, ainsi qu'entre le dispositif et le cloud.

Des services spécialisés, par exemple Amazon IoT Core et Amazon FreeRTOS, ont permis de répondre à ces exigences essentielles côté cloud. Toutefois, la connexion avec ces services côté dispositif peut présenter d'autres complications pour les développeurs IIoT qui commencent tout juste à découvrir les services cloud, ainsi que les nombreux protocoles et interfaces associés. Ces développeurs doivent encore répondre aux exigences de détection et de traitement d'applications de périphérie, ainsi qu'aux contraintes de coût, de puissance, de performances et d'espace.

Cet article traite brièvement de l'utilisation des ressources basées sur le cloud et de leur évolution, puis présente un kit cloud complet basé sur le microcontrôleur RX65N de Renesas. Il explique dans quelle mesure il est possible d'utiliser ce microcontrôleur et la conception de référence avec le progiciel associé pour implémenter rapidement des dispositifs IIoT basés sur des capteurs pour une intégration au cloud Amazon Web Services (AWS).

Utilisation de ressources cloud

Bien que d'autres fournisseurs de services cloud rattrapent lentement leur retard, AWS reste le principal fournisseur d'offres cloud évolutives avec et sans serveur en matière d'informatique, de stockage et de logiciel en tant que service (SaaS). Les organisations utilisent régulièrement ces services dans des applications à l'échelle de l'entreprise, pouvant changer suivant l'évolution de la demande et s'appuyant sur un large éventail de packs SaaS, le tout supporté au moyen de services d'intergiciels uniformes sur l'ensemble de la plateforme pour les communications, les notifications, la sécurité, le stockage de données et pratiquement tous les besoins en informatique.

Pour les entreprises qui déploient des applications IoT à grande échelle, l'utilisation de ces services pour analyser les données IIoT provenant de véhicules, d'équipements, de bâtiments et d'usines de fabrication donne des avantages évidents pour améliorer la compréhension et le contrôle des actifs physiques, des processus et des pratiques. Cependant, pour les développeurs, le processus de connexion d'un dispositif IIoT à AWS ou à tout autre service cloud peut sembler moins évident en raison de l'écart apparent entre les conceptions IoT en temps réel limitées en ressources dans la périphérie et les services virtuels évolutifs dans le cloud.

Pour combler cet écart, les principaux fournisseurs de services cloud proposent un ensemble de fonctionnalités de connexion conçues pour rapprocher les différences importantes entre les dispositifs IoT et les services cloud. Pour AWS, ces fonctionnalités sont contenues dans AWS IoT Core, qui sert non seulement de passerelle à la plateforme AWS complète, mais également à des services de niveau application spécifiques à l'IoT pour le stockage de données, les analyses, la visualisation et l'apprentissage automatique (Figure 1).

Figure 1 : AWS IoT constitue l'interface de service entre les capteurs IIoT sur le terrain et la plateforme de services AWS plus étendue utilisée pour analyser les données de capteur pour des applications industrielles telles que l'application de gestion de flotte suggérée ici. (Source de l'image : AWS)

Au-delà de ces capacités, l'intégration du système d'exploitation en temps réel (RTOS) open-source FreeRTOS à AWS IoT offre un avantage important en termes de gestion des exigences de cycle de vie pour la mise à jour et la maintenance du système.

Comme avec toute autre offre de niveau entreprise, les services AWS IoT spécifient un ensemble complet d'exigences d'interface et de protocoles pour l'intégration, l'authentification et l'échange de messages de dispositifs. Bien que conforme aux exigences de la plateforme AWS plus étendue, la nature spécialisée de l'environnement IoT signifie que même les développeurs AWS expérimentés risquent de faire face à une courbe d'apprentissage importante par rapport à l'intégration d'un dispositif à AWS IoT Core et les services AWS IoT associés. En outre, les développeurs, quel que soit leur niveau d'expérience, sont confrontés aux défis habituels relatifs à l'implémentation d'une conception IoT qui répond à une demande continue de performances supérieures, de consommation énergétique réduite et de sécurité renforcée.

Face à cet ensemble de défis, le kit cloud RTK5RX65N0S01000BE RX65N de Renesas constitue une solution prête pour le déploiement rapide de dispositifs IIoT sur AWS.

Plateforme complète

Le kit cloud RX65N fournit une plateforme complète de développement et de conception de référence pour le déploiement et l'évaluation de dispositifs IIoT avec les services cloud AWS IoT. Outre un pack de développement logiciel complet, le kit contient trois cartes matérielles, dont une carte cible avec un microcontrôleur R5F565NEDDFP 32 bits de Renesas certifié pour Amazon FreeRTOS, une carte Wi-Fi et une carte Renesas Cloud Option avec connexions USB et un ensemble de capteurs généralement nécessaires dans une application IIoT.

Basé sur le cœur de processeur RXv2 32 bits de Renesas, le microcontrôleur R5F565NEDDFP fournit 640 Ko de mémoire RAM, 32 Ko de Flash de données et 2 Mo de Flash code. Dans ce microcontrôleur, il est possible de configurer la mémoire Flash code en mode linéaire pour lequel elle fonctionne comme un espace d'adressage unique ou en mode double pour lequel elle fonctionne comme deux zones de mémoire distinctes. Le mode double permet des mises à jour plus fiables sans fil (OTA), car il charge le nouveau micrologiciel dans un bloc inoccupé et valide son intégrité et son authenticité avant de redémarrer le système.

Outre la prise en charge de la mémoire, le R5F565NEDDFP et les autres membres de la gamme RX65N intègrent un vaste ensemble de schémas fonctionnels, notamment une unité en virgule flottante IEEE-754 et une unité de protection de la mémoire (MPU). Parmi leurs interfaces externes, les microcontrôleurs RX65N incluent deux convertisseurs analogique-numérique (CAN) 12 bits multicanaux, un convertisseur numérique-analogique (CNA) 12 bits à deux canaux et des interfaces de communications industrielles y compris Ethernet, CAN (Controller Area Network) et de multiples interfaces série, notamment I²C, Quad SPI et une interface de communication série multicanal (SCI) prenant en charge I²C et SPI.

Interface matérielle du capteur

En plus de fournir une plateforme d'évaluation, le kit cloud de Renesas démontre la relative facilité d'intégration du microcontrôleur RX65N aux capteurs IIoT. Dans cet exemple, la carte Cloud Option du kit inclut un ensemble de trois capteurs :

• Capteur numérique de lumière ISL29035 (ISL29035IROZ-T7) de Renesas pour la mesure de l'éclairage ambiant/infrarouge
• Capteur MEMS BMI160 de Bosch Sensortec pour l'accélération sur trois axes et la mesure gyroscopique
• Capteur MEMS BME680 de Bosch Sensortec pour les mesures de gaz, de température, d'humidité et de pression

Étant donné que les trois capteurs fournissent une interface série I²C, l'intégration au microcontrôleur consiste simplement à connecter les dispositifs à un bus I²C partagé. Le schéma de la carte Cloud Option illustre cette interface matérielle simple (Figure 2).

Figure 2 : Inclus dans le kit cloud RX65N de Renesas, le schéma de conception de référence de la carte Cloud Option de Renesas illustre l'interface matérielle simple nécessaire pour connecter ses trois capteurs à un bus série I²C partagé. (Source de l'image : Renesas)

À l'aide de connecteurs compatibles disponibles sur la carte Cloud Option, les développeurs peuvent également étendre les fonctionnalités matérielles du kit avec les cartes d'extension PMOD et Grove.

Développement logiciel

Même si les microcontrôleurs et capteurs avancés utilisés dans les dispositifs IIoT simplifient la conception matérielle, la conception logicielle peut s'avérer considérablement plus complexe. En plus des exigences logicielles pour le système IIoT, les développeurs sont confrontés à des exigences d'interfaçage avec des ressources cloud, par exemple les services de plateforme AWS IoT Core et AWS. Dans cet exemple, ces exigences sont satisfaites au moyen de deux kits de développement logiciel (SDK) AWS ciblant les services de dispositif et de cloud.

Au niveau de l'application, les développeurs de logiciels IoT interagissent avec les services AWS via le kit SDK AWS standard. À ce niveau, les interactions avec les dispositifs et leurs données se produisent via ces mêmes services, supportés par les services de messagerie et de notification AWS communs aux services AWS et AWS IoT, comme indiqué ci-dessous.

Au niveau du dispositif, les développeurs utilisent un kit SDK de dispositif (ou « Thing ») pour se connecter aux services AWS IoT. Les demandes et réponses spécifiques entre les dispositifs et les services AWS sont traitées par un agent de messages qui gère les échanges à l'aide du protocole de messagerie standard de publication/d'abonnement (pub/sub) ISO MQTT (Message Queuing Telemetry Transport) (Figure 3).

Figure 3 : L'implémentation d'applications IIoT implique l'utilisation de kits SDK distincts pour les dispositifs et les applications, mais les deux reposent sur un ensemble de mécanismes uniformes sur l'ensemble de la plateforme pour la messagerie, les notifications et d'autres fonctionnalités sous-jacentes. (Source de l'image : AWS)

Lorsque le dispositif envoie des messages MQTT avec des données utiles, un moteur de règles appelle des services de plateforme AWS supplémentaires en fonction d'un ensemble d'expressions écrites par le développeur dans une syntaxe basée sur le langage de requête SQL (Structured Query Language). Par exemple, la règle indiquée dans la Liste 1 peut publier de nouveau la charge générée par l'expression SQL (SELECT * FROM 'iot/test) dans une autre file d'attente MQTT (my-mqtt-topic) si un modèle d'inférence (my-model) appelé par la fonction de services d'apprentissage automatique Amazon (machinelearning_predict()) classe les données comme appartenant à une étiquette spécifique (predictedLabel=1).

Copier { "sql": "SELECT * FROM 'iot/test' where machinelearning_predict('my-model', 'arn:aws:iam::123456789012:role/my-iot-aml-role', *).predictedLabel=1", "ruleDisabled": false, "awsIotSqlVersion": "2016-03-23", "actions": [{ "republish": { "roleArn": "arn:aws:iam::123456789012:role/my-iot-role", "topic": "my-mqtt-topic" } }] } 

Liste 1 : Le moteur de règles AWS appelle les services AWS et achemine les données à l'aide de règles de sélection de type SQL, d'actions désignées et de métadonnées associées. (Source du code : AWS)

Jumeaux numériques

Tandis que le moteur de règles AWS IoT fournit une capacité de traitement faiblement couplée, le service AWS IoT Device Shadow permet de découpler l'application IoT de l'intégrité du dispositif IoT. Les jumeaux numériques contiennent des informations d'état sur un dispositif IoT physique. Par conséquent, si un dispositif IoT perd la connectivité ou rompt autrement la connexion avec AWS, les services cloud peuvent utiliser le jumeau numérique pour continuer à fonctionner sur la base des dernières données reçues, sans avoir à créer leurs propres mécanismes de mise en cache des données de dispositif. Inversement, le service de périphérie AWS IoT Greengrass permet aux dispositifs IoT de continuer à interagir virtuellement avec le cloud lors d'interruptions intermittentes des services cloud. Dans cet exemple, Greengrass continue à fonctionner dans des dispositifs de périphérie pour gérer les jumeaux numériques et fournir le sous-ensemble nécessaire de services cloud requis pour maintenir le fonctionnement du dispositif IoT.

Même si les jumeaux numériques conservent l'état du dispositif, le service Device Shadow est plus qu'un simple mécanisme de mise en cache. Il fournit également une interface commune permettant aux applications d'envoyer des requêtes aux dispositifs IoT. Étant donné que ce service est lié au mécanisme MQTT pub/sub, les mises à jour et les demandes de données entraînent la notification automatique de toutes les applications et de tous les dispositifs abonnés aux files d'attente MQTT associées à chaque jumeau numérique.

Au niveau de l'implémentation, le service Device Shadow utilise un format de document JSON simple qui contient les données et métadonnées associées à chaque dispositif physique. En utilisant le kit SDK du dispositif, les logiciels installés sur le dispositif IoT peuvent transmettre un nouveau document JSON qui met à jour l'état signalé dans le jumeau numérique avec ses données les plus récentes. Inversement, un hôte ou une application IoT mobile peut mettre à jour le jumeau numérique avec de nouvelles valeurs. Par exemple, pour un dispositif IIoT affichant actuellement une LED verte ou une lumière verte sur un écran, une application peut mettre à jour le jumeau numérique pour demander une modification en rouge et même recevoir un rapport indiquant le delta entre les états souhaité et signalé (Liste 2).

Copier { "state": { "desired": { "color": "RED", "state": "STOP" }, "reported": { "color": "GREEN", "engine": "ON" }, "delta": { "color": "RED", "state": "STOP" } }, "metadata": { "desired": { "color": { "timestamp": 12345 }, "state": { "timestamp": 12345 }, "reported": { "color": { "timestamp": 12345 }, "engine": { "timestamp": 12345 } }, "delta": { "color": { "timestamp": 12345 }, "state": { "timestamp": 12345 } } }, "version": 17, "timestamp": 123456789 } } 

Liste 2 : Un jumeau numérique AWS est un document JSON qui contient des métadonnées et des données de dispositif, notamment des valeurs pour les états de dispositif signalé et souhaité, ainsi que le delta entre les deux états. (Source du code : AWS)

Même si des services tels que les jumeaux numériques et les moteurs de règles prennent en charge l'intégration aux applications et à la plateforme AWS plus étendue, l'une des pièces maîtresses du service AWS IoT est l'intégration d'Amazon FreeRTOS. Ce RTOS open-source étend le populaire noyau FreeRTOS open-source à un ensemble complet de bibliothèques. Outre les bibliothèques de services courants tels que l'enregistrement, Amazon FreeRTOS ajoute des bibliothèques pour les services AWS IoT. Ces bibliothèques incluent AWS IoT Device Shadow, AWS IoT Greengrass (gdd) et AWS IoT Device Defender pour la surveillance de la sécurité des dispositifs. En outre, Amazon enrichit FreeRTOS avec des bibliothèques pour de nombreux services d'intergiciels, notamment les sockets sécurisées, le protocole TLS (Transport Layer Security), la norme de cryptographie à clé publique (PKCS) n 11, un agent OTA, Bluetooth, Wi-Fi et l'échange de messages MQTT.

Déploiement simple

Renesas aide les développeurs à acquérir rapidement de l'expérience avec son kit cloud et la connectivité avec les services AWS IoT. Après avoir configuré l'ensemble de cartes du kit cloud, les utilisateurs doivent installer l'environnement de développement intégré (IDE) e² studio basé sur Eclipse de Renesas et le compilateur CC-RX de Renesas. En utilisant e² studio et le compilateur CC-RX, les développeurs peuvent rapidement importer et compiler Amazon FreeRTOS ainsi que le code d'exemple du kit cloud RX65N open-source de Renesas.

Renesas fournit une documentation associée qui offre une description étape par étape de la configuration d'AWS IoT et des informations d'authentification requises pour établir une connexion avec AWS. Après cette procédure d'installation relativement rapide, il est nécessaire d'exécuter le programme de démonstration pour surveiller les données de capteur envoyées par le dispositif sous forme de messages MQTT et les visualiser à l'aide d'un client d'affichage MQTT disponible via la console AWS IoT.

Développement de logiciels personnalisés

En plus de fournir une démonstration immédiate de l'intégration de dispositifs IoT à AWS IoT, le code d'exemple de Renesas sert également de conception de référence pour les applications personnalisées. Même avec cette disponibilité du code, toutefois, l'un des défis auxquels les développeurs feront face dans leurs projets personnalisés concerne le grand nombre de configurations associées à Amazon FreeRTOS et aux services AWS IoT associés. Chaque service nécessite la spécification de nombreux paramètres associés, par exemple la longueur des files d'attente et la taille des messages.

Bien que le code d'exemple de Renesas comprenne des configurations FreeRTOS prédéfinies pour ses démonstrations, les développeurs de code personnalisé doivent utiliser des options de configuration pour chaque service, bibliothèque et utilitaire. Renesas a développé le Smart Configurator pour simplifier ce processus. Disponible en tant que plug-in e² studio et en tant qu'application autonome, le Smart Configurator permet aux développeurs d'examiner et de modifier les paramètres de chaque groupe de configuration via une interface utilisateur graphique (Figure 4).

Figure 4 : Le Smart Configurator de Renesas propose une interface graphique simple pour examiner et modifier les nombreux paramètres de configuration associés aux nombreux services et bibliothèques pris en charge dans Amazon FreeRTOS. (Source de l'image : Renesas)

Pour le code, les développeurs peuvent tirer parti de la source complète fournie dans le référentiel de code du kit cloud RX65N de Renesas. Les exemples de routines inclus dans ce référentiel illustrent les principaux modèles de conception permettant d'utiliser chaque service AWS IoT via les mécanismes de messagerie basés sur MQTT.

Pour illustrer le service AWS IoT Device Shadow, par exemple, un module inclus (aws_shadow_lightbulb_on_off.c) et les fichiers d'en-tête associés illustrent la manière dont le logiciel exécuté sur le dispositif IoT crée des documents JSON, initialise les files d'attente et envoie les messages de mise à jour du dispositif au service Device Shadow. Bien que l'architecture logicielle complète soit assez complexe, ce module d'exemple montre comment une structure de données de base et quelques lignes de code peuvent être utilisées pour modifier la couleur d'une lumière (couleur verte indiquée dans le document JSON présenté dans la Liste 1) en définissant le bon attribut dans le document JSON du jumeau numérique sur la nouvelle couleur (couleur souhaitée en rouge dans la Liste 1). Après initialisation du jumeau numérique, le code crée une tâche qui alterne la couleur souhaitée entre deux états (rouge et vert) en émettant une nouvelle demande d'état souhaité à l'aide de la fonction prvGenerateDesiredJSON() pour générer le nouveau document JSON avec l'état de couleur alternatif (Liste 3).

Copier #define shadowDemoDESIRED_JSON \ "{" \ "\"state\":{" \ "\"desired\":{" \ "\"%s\":\"%s\"" \ "}" \ "}," \ "\"clientToken\": \"token-%d\"" \ "}" ...
static uint32_t prvGenerateDesiredJSON( ShadowQueueData_t * const pxShadowQueueData, const char * const pcTaskName, uint8_t ucBulbState ) { /* Map cBulbState to strings. */ static const char * const pColors[ 2 ] = { "green", "red" }; /* Generate JSON. */ return ( uint32_t ) snprintf( ( char * ) pxShadowQueueData->pcUpdateBuffer, shadowDemoBUFFER_LENGTH, shadowDemoDESIRED_JSON, pcTaskName, pColors[ ucBulbState ], ( int ) xTaskGetTickCount() ); } ...
/* Keep changing the desired state of light bulb periodically. */ for( ; ; ) { configPRINTF( ( "%s changing desired state.\r\n", pxShadowTaskParam->cTaskName ) ); /* Toggle the desired state and generate a new JSON document. */ ucBulbState = !( ucBulbState ); xShadowQueueData.ulDataLength = prvGenerateDesiredJSON( &xShadowQueueData, pxShadowTaskParam->cTaskName, ucBulbState ); /* Add the new desired state to the update queue. */ if( xQueueSendToBack( xUpdateQueue, &xShadowQueueData, shadowDemoSEND_QUEUE_WAIT_TICKS ) == pdTRUE ) { /* If the new desired state was successfully added, wait for notification that the update completed. */ configASSERT( ulTaskNotifyTake( pdTRUE, shadowDemoNOTIFY_WAIT_MS ) == 1 ); configPRINTF( ( "%s done changing desired state.\r\n", pxShadowTaskParam->cTaskName ) ); } else { configPRINTF( ( "Update queue full, deferring desired state change.\r\n" ) ); } vTaskDelayUntil( &xLastWakeTime, shadowDemoSEND_UPDATE_MS ); } 

Liste 3 : Cet extrait de code d'exemple dans le référentiel de code du kit cloud RX65N de Renesas illustre le modèle de conception de base pour utiliser un document JSON défini dans shadowDemoDESIRED_JSON et instancié par la fonction prvGenerateDesiredJSON() pour modifier l'état souhaité d'un jumeau numérique à l'aide d'une file d'attente de mise à jour. (Source du code : Renesas)

Conclusion

Avec son large éventail d'offres, un service cloud commercial tel qu'AWS constitue une plateforme attrayante pour les développeurs qui créent des applications IIoT à grande échelle, en particulier ceux qui doivent travailler avec d'autres applications d'entreprise. Pour les développeurs, toutefois, traiter à la fois des problèmes de conception de dispositifs IoT et d'intégration dans le cloud entraîne souvent des retards imprévus dans le développement et le déploiement.

Basé sur le microcontrôleur RX65N de Renesas, le kit cloud RX65N de Renesas fournit un dispositif de capteur IIoT complet et une conception de référence. Utilisé en combinaison avec son pack logiciel associé, le kit cloud de Renesas fournit une plateforme de développement flexible et rapide pour l'implémentation de dispositifs IIoT basés sur des capteurs pour une intégration à AWS.