Les fabricants de matériel ont déployé des efforts considérables pour développer des solutions performantes de connexion des réseaux de capteurs. Selon les besoins du terrain, une grande variété d'options ont vu le jour. On trouve des passerelles dédiées à des domaines d'application spécifiques, comme la passerelle FlexGate d'EXPEMB, optimisée pour LoRa. Il existe également des systèmes multifonctionnels, tels que la passerelle conga-IoT de congatec, qui offre jusqu'à huit antennes radio, permettant ainsi un choix extrêmement large de technologies sans fil, ainsi que la connexion de périphériques et de bus de terrain supplémentaires. Cependant, les plateformes matérielles dédiées à une application spécifique ne constituent que la première étape vers une plateforme de solution qui simplifiera l'accès des développeurs OEM aux données provenant de dispositifs embarqués et de réseaux de capteurs hétérogènes dans le cloud.
Dans le monde idéal des développeurs d'applications cloud, le matériel distribué ne nécessite que peu d'entretien. Les développeurs souhaitent que la connexion des appareils, machines et systèmes au cloud soit aussi simple que le branchement de périphériques USB ou de cartes d'extension PCIe à un PC : ouvrir le cloud, reconnaître les appareils, les configurer selon les besoins, et la connexion est établie. Si les systèmes informatiques embarqués disposaient d'une interface aussi conviviale, y compris pour leurs périphériques, la création automatique de toutes les applications cloud et tableaux de bord nécessaires serait un jeu d'enfant grâce aux frameworks et outils adéquats. Le problème réside dans le fait que les données de capteurs sur le terrain – dont la taille varie de quelques bits pour les mesures de température à plusieurs gigabits pour les flux vidéo volumineux – sont générées par une grande variété de capteurs et transmises sous diverses formes, via des protocoles, interfaces et chemins de transmission hétérogènes. Sans logique locale capable de traiter ces données hétérogènes et de les convertir en informations exploitables, l'établissement d'une connexion fonctionnelle au cloud est quasiment impossible. Le cloud permet d'enregistrer n'importe quel état avec une densité maximale ou de collecter uniquement les données nécessaires à court ou à long terme, par exemple pour effectuer des analyses de Big Data et fournir un accès à la demande à ces données depuis n'importe où. Pour ce faire, une passerelle est nécessaire : une plateforme de système virtuel ou un appareil dédié, où les données sont reçues, traduites, traitées et transmises de manière transparente aux interfaces cloud correspondantes.
Importance primordiale des passerelles :
les passerelles jouent un rôle clé dans l’orchestration des réseaux de capteurs, car elles constituent le point d’envoi des informations vers le terrain, le cloud ou d’autres passerelles voisines. Outre une configuration matérielle adéquate, elles nécessitent d’excellentes capacités de traitement du langage et de prise de décision. Elles requièrent une logique permettant de collecter, d’analyser et de transcoder les données des capteurs, et de déterminer comment les exploiter. Enfin, elles doivent être capables de structurer les données de manière cohérente et de gérer la communication bidirectionnelle au sein de la solution cloud, le tout avec un chiffrement de bout en bout sécurisé.
La nouvelle API Cloud (Interface de Programmation d'Applications) pour les passerelles IoT congatec illustre la conception d'un middleware et d'une logique facilitant l'orchestration des réseaux de capteurs sans fil. Son objectif est de simplifier la connexion des technologies informatiques embarquées et des périphériques associés au cloud en fournissant des modules logiciels prêts à l'emploi, utilisables comme modèles pour le développement d'applications personnalisées. Grâce à l'API Cloud congatec pour passerelles IoT, les réseaux de capteurs locaux de tous types peuvent être intégrés à n'importe quelle solution cloud.
La passerelle IoT communique localement avec les capteurs intelligents, traitant et convertissant les données reçues. Les modules de pilotage embarqués (EDM) servent d'interface pour les matériels tiers et les cartes d'extension, assurant la traduction des données reçues dans le langage spécifique à l'application de la passerelle IoT. Les données sont transmises progressivement au cloud via des interfaces et des processus de décision prédéfinis, grâce à des modules et des blocs fonctionnels transparents, compatibles avec des interfaces logiques identiques pour toutes les applications.
Le rôle clé des intergiciels :
les logiciels, et notamment les intergiciels de passerelle IoT, sont essentiels pour la réception, le traitement, le conditionnement et le transfert à la demande des données issues du terrain. Or, c'est souvent à ce niveau que les problèmes de compatibilité apparaissent, car il n'existe à ce jour aucune API standardisée pour la communication entre les capteurs, les passerelles et le cloud. Il est désormais impératif de combler cette lacune en standardisant les API cloud pour les passerelles IoT. L'objectif est de trouver une méthode unifiée pour recevoir et traiter les données localement, puis les transférer vers le cloud. En effet, seule une API cloud standardisée et prête à l'emploi permet une intégration simple des différentes connexions de capteurs sans fil (Bluetooth LE, ZigBee, LoRa et autres LPWAN) ainsi que des protocoles filaires pour l'automatisation des bâtiments et des industries. De cette manière, même des configurations de protocoles très hétérogènes peuvent être facilement intégrées avec un minimum d'efforts de développement. Il en va de même pour les communications dans le cloud, bien entendu, car les exigences spécifiques aux serveurs propriétaires ou aux offres tierces telles que Microsoft Azure, Telekom ou Amazon AWS Cloud doivent également être satisfaites de manière simple et rapide.
Les premiers composants logiciels à être normalisés sont les différents modules fonctionnels de l'API cloud. Sur le terrain, le moteur de capteurs avec EDM, implémenté dans l'API cloud congatec pour passerelles IoT, joue un rôle clé. Il permet la conversion et la transmission des données des capteurs et actionneurs locaux vers un middleware générique et indépendant du protocole. Il normalise également les mesures en unités physiques librement définissables et vérifie la signification des données reçues. Grâce à la connexion d'interface EAPI normalisée, les modules peuvent fournir des paramètres matériels pertinents, tels que les températures et tensions du système, l'utilisation du processeur ou la détection de vol.
Grâce à son moteur de règles dédié, la passerelle envoie des alertes locales et déclenche des actions automatisées lorsque certains seuils sont dépassés ou sur le point de l'être. Son moteur de capteurs indépendant du matériel permet aux développeurs OEM d'intégrer de manière uniforme les mêmes types de capteurs, comme les capteurs de température. Ceci simplifie la configuration et améliore l'efficacité.
Au-delà de cette logique de connexion et d'abstraction matérielle, il manque une interface cloud standardisée et adaptable à chaque fournisseur. Pour y remédier, congatec a développé, en collaboration avec M2MGO, un module d'interface : le moteur de communication. Ce dernier assure une communication chiffrée avec les serveurs et différents clouds via des connexions filaires ou sans fil intelligentes. Si tous les modules fonctionnels étaient basés sur une norme ouverte et indépendante des fournisseurs, capteurs, passerelles et clouds pourraient être assemblés librement selon les besoins, garantissant ainsi un fonctionnement optimal.
Outre la connectivité cloud plug-and-play pour le matériel, les développeurs ont également besoin d'une solution simple pour configurer les passerelles IoT afin de mettre en œuvre les scénarios décrits. La plateforme cloud M2MGO People-System-Things (PST) s'intègre parfaitement à l'API cloud congatec pour les passerelles IoT. Au-delà de la gestion des données des appareils et des systèmes, PST offre un ensemble de fonctionnalités robustes pour la création d'applications sans programmation. Les utilisateurs peuvent générer des applications web complètes à l'aide d'un éditeur glisser-déposer. Selon les appareils disponibles, des applications mobiles pour utilisateurs finaux peuvent même être créées automatiquement, sans intervention manuelle.
Structure de l'écosystème :
Bien entendu, la robustesse d'une telle approche d'API cloud ouverte dépend de l'écosystème qui la soutient. Pour des solutions véritablement prêtes à l'emploi, les principaux fournisseurs de systèmes embarqués, de périphériques et de services cloud devront prendre en charge une API cloud, car chaque dispositif matériel requiert un moteur de capteurs dédié et chaque cloud un moteur cloud approprié. Selon la logique de décision requise par la passerelle, seules des exécutions spécifiques du moteur de règles sont nécessaires. Cela minimise l'effort de développement requis pour la connexion au cloud. Dans les installations standard, il est possible de déployer des modules certifiés et prêts à l'emploi sans écrire une seule ligne de code supplémentaire. Le prêt à l'emploi et la paramétrisation, plutôt que la programmation, sont les principes directeurs. Si tous les modules standard sont correctement installés, le moteur de capteurs fourni lit, traduit et traite les données sur la passerelle IoT immédiatement après leur capture, en utilisant le langage du cloud. L'utilisateur peut ainsi visualiser les informations traitées dans une application web générée automatiquement, sans avoir à programmer et développer individuellement l'ensemble du processus pour chaque capteur. À l'avenir, toutes les données souhaitées seront automatiquement transférées vers le cloud et mises à la disposition de l'utilisateur.
Avantages de la standardisation
. La standardisation offre bien d'autres avantages : grâce aux blocs fonctionnels standardisés, les clients ne sont plus liés à un fournisseur unique. De plus, la standardisation de ces API constitue une base idéale pour les stratégies de migration des équipementiers. Les développeurs n'ont besoin de concevoir leur application IoT qu'une seule fois et peuvent ensuite la porter sur n'importe quelle combinaison de capteurs, de passerelles et de cloud pour de nouvelles applications. Cette portabilité est extrêmement pratique, car une solution cloud qui connecte des bus de terrain localement et communique ensuite via Wi-Fi avec un cloud Microsoft Azure est différente d'une solution qui collecte des données localement via Wi-Fi ou LoRa puis les transfère via 3G/4G vers un cloud de télécommunications. Si les passerelles individuelles prennent en charge une API cloud standardisée, les développeurs n'ont qu'à modifier le moteur cloud ; tout le reste demeure inchangé. C'est un moyen efficace de répondre aux exigences les plus spécifiques grâce à des composants standard prêts à l'emploi. À titre d'exemple, voici un calcul rapide : une solution IoT avec quatre réseaux de capteurs alternatifs et trois environnements cloud possibles pour différentes applications nécessitait auparavant 12 implémentations complètement différentes sur la passerelle IoT (3x4). Une API cloud standardisée simplifie considérablement la tâche, qui se limite à l'intégration ou au déploiement de seulement 7 moteurs (3 moteurs cloud et 4 moteurs de capteurs). Si certains de ces moteurs sont déjà disponibles, l'effort est encore réduit. Toutes ces options garantissent également la disponibilité des solutions à long terme.
État actuel des efforts de normalisation :
Compte tenu des nombreux avantages de la normalisation ouverte pour les équipementiers et les fournisseurs d’applications IoT, le SGET (Standardization Group for Embedded Technologies eV) a créé un groupe de travail il y a deux ans. À titre de premier résultat, le SGET a présenté un système de démonstration inédit lors du salon Embedded World 2017. Le groupe travaille actuellement à la finalisation de la version 1.0 de la nouvelle norme d’API cloud pour les systèmes embarqués et les modules d’extension. L’objectif est l’adoption officielle de la norme début 2018. D’ici là, davantage de fabricants sont encouragés à participer, car plus la base de soutien est large, plus les chances d’établir cette norme sur le long terme sont grandes. Les efforts de normalisation de l’API cloud seraient considérablement renforcés si, outre les fabricants de technologies embarquées, les fournisseurs de périphériques et les principaux fournisseurs de services cloud adhéraient également à cette norme ouverte. Obtenir le soutien de ces acteurs est donc une tâche essentielle pour le SGET dans le cadre du processus de normalisation.
Auteurs :
