[ad_1]

Que cela vous plaise ou non, le cloud est devenu une partie intégrante de l’Internet des objets. Mais parfois, il n’est pas pratique ou souhaitable de compter sur un service cloud externe pour faire fonctionner votre système IoT. Que vos appareils soient de minuscules capteurs sans fil ou des lampadaires.

Avec notre dernière version de la plate-forme Thingsquare IoT, nous ajoutons la possibilité d’exécuter la plate-forme Thingsquare IoT hors du réseau, loin du cloud.

Nous ne sommes pas les seuls à croire à l’idée d’un IoT sans nuage. Dans la communauté IoT, le concept est souvent appelé edge ou fog computing. Il existe des plates-formes logicielles entières, telles que la plate-forme Litmus LoopEdge, Microsoft Azure Edge et la suite d’analyse Crosser IoT Edge, qui sont conçues pour fonctionner hors réseau. Il existe même des puces matérielles personnalisées conçues pour prendre en charge le calcul hors cloud, généralement le traitement de la parole.

Il y a aussi un vieil adage qui l’Internet des objets sans Internet n’est que… des choses. Ce n’est pas vrai: il existe de nombreuses situations dans lesquelles les systèmes IoT sans Internet peuvent être aussi précieux que les systèmes IoT compatibles avec Internet.

Chez Thingsquare, nous avons construit et déployé plusieurs systèmes IoT sans cloud avec la version sans cloud de notre plateforme IoT, notamment:

  • Générateurs électriques. Ceux-ci sont déployés dans un emplacement distant où il y a peu ou pas d’accès Internet.
  • Machinerie industrielle. Ceux-ci sont déployés en tant que produit complètement autonome avec un écran tactile séparé sur le contrôleur local.
  • Éclairage industriel. Ceux-ci sont exécutés dans des endroits où les clients veulent un système complètement cloisonné.

Pour plus d’informations sur le fonctionnement des plates-formes IoT, consultez notre article sur les raisons pour lesquelles vous devriez utiliser une plate-forme IoT et la page sur la plate-forme Thingsquare IoT.

Mais voyons d’abord pourquoi nous utilisons le cloud. Parce qu’il y a de bonnes raisons de le faire.

Parfois, il n’est pas pratique ou souhaitable de s’appuyer sur un service cloud externe pour faire fonctionner votre système IoT

Pourquoi l’IoT dans le cloud?

Il existe de bonnes raisons pour lesquelles la logique backend d’un système IoT est exécutée dans le cloud:

  • Stockage de données: Le cloud peut stocker une quantité presque illimitée de données.
  • Calcul: Certains mécanismes nécessitent une puissance de calcul abondante, ce dont le cloud peut fournir une quantité presque illimitée.
  • Accès à distance: Pour fournir aux utilisateurs un accès à distance aux données générées par les appareils IoT ou pour contrôler les appareils eux-mêmes, vous devez disposer d’un service cloud qui connecte les appareils à leurs utilisateurs.
  • Contrôle d’accès: Le cloud peut fournir des mécanismes de contrôle d’accès efficaces pour vos utilisateurs.
  • Références croisées des données: Pour pouvoir exécuter des algorithmes d’apprentissage automatique efficaces, vous devez parfois accéder à un large éventail de données. Le cloud vous permet de collecter des données de plus d’un site pour croiser et combiner ces données.
  • Intégration d’applications: Les systèmes IoT fonctionnent rarement seuls. L’intégration avec d’autres systèmes logiciels est beaucoup plus facile si le backend est situé à un seul endroit: le cloud.
  • Mises à jour de sécurité: lorsque le backend IoT est exécuté dans le cloud, une équipe de sécurité dédiée peut suivre et appliquer les mises à jour de sécurité si nécessaire.

Ces raisons, qui sont de bonnes raisons, expliquent pourquoi la plupart des systèmes IoT actuels sont fournis via le cloud. Thingsquare ne fait pas exception.

La partie backend de la plate-forme Thingsquare IoT est à l’origine conçue pour être exécutée dans le cloud. Parfois, le backend s’exécute sur un fournisseur de cloud typique comme Amazon Web Services, et parfois le backend est installé sur une machine hébergée, en tant que progiciel traditionnel sur site.

Mais l’exécution du backend IoT dans le cloud présente certains inconvénients.

Pourquoi l’IoT sans nuage?

Il y a de bonnes raisons de ne pas compter sur une connexion cloud toujours active pour chaque projet IoT:

  • Stabilité: les services cloud peuvent tomber en panne, donc éviter le cloud peut donc augmenter la stabilité.
  • Persistance: les services cloud peuvent disparaître, donc éviter le cloud peut permettre au système IoT de fonctionner indéfiniment, sans compter sur la société d’hébergement pour persister.
  • La confidentialité des données: parfois, les données ne doivent pas quitter l’emplacement où elles sont générées.
  • Sécurité: moins de connexions réseau signifie moins de vecteurs d’attaque.
  • Nécessité: parfois, il n’y a tout simplement pas d’accès Internet.

Tout logiciel basé sur le cloud peut devenir inaccessible si le cloud tombe en panne. Cela peut arriver même pour des entreprises comme Google, qui disposent sans doute d’infrastructures cloud de pointe et de l’une des meilleures équipes cloud au monde. Toute solution IoT qui dépend entièrement du cloud subira une panne si le cloud tombe en panne.

Parce que le service cloud est une chose vivante, il peut mourir. Cela peut se produire si l’entreprise qui gère le service disparaît ou si elle décide simplement qu’il n’est plus économique de le maintenir. Il existe plusieurs exemples concrets de cela.

Mais la raison la plus convaincante pour laquelle utiliser un système IoT sans cloud est lorsque l’accès à Internet n’est pas disponible. Chez Thingsquare, nous travaillons sur des projets où le système IoT est déployé en Afrique rurale, où l’accès à Internet est au mieux inégal. Et avec des projets dans des pays, l’accès à Internet était généralement disponible, mais où le système IoT était dans une cave profonde où l’accès 4G était impossible.

Les défis de l’IoT sans nuage

Déplacer le backend IoT du cloud pour se rapprocher des appareils IoT présente un certain nombre de défis:

  • Authentification: l’authentification est nettement plus facile avec le cloud, grâce à des mécanismes tels que l’authentification à 2 facteurs.
  • Accès à distance: fournir un accès à distance sans cloud est très difficile et dans la plupart des cas impossible.
  • Traitement de l’information: analyser les chiffres sans avoir accès à l’abondance de stockage et de calcul fournis par le cloud est beaucoup plus difficile.
  • Déploiement logiciel: de nombreux systèmes IoT nécessitent un traitement de données ou des mécanismes similaires, et ces systèmes sont souvent conçus pour être exécutés dans le cloud.
  • Mises à jour de logiciel: les logiciels sont vivants et doivent être tenus à jour.

Ces problèmes entraînent des compromis. Tout système IoT déployé hors du cloud doit être prêt à y faire face.

Une approche pratique d’un IoT sans nuage

Thingsquare adopte une approche délibérément simple de l’IoT sans nuage:

  • Nous exécutons notre backend IoT sur un contrôleur local non connecté
  • Traiter les compromis qui en résultent au cas par cas

Le contrôleur local peut fonctionner sur un matériel similaire à un Raspberry Pi. Le contrôleur local est déployé sur un réseau sur site et nous fournissons une interface utilisateur sur ce réseau uniquement. L’interface utilisateur est accessible via une application pour smartphone, qui peut détecter les contrôleurs locaux à proximité via Bluetooth et permettre aux utilisateurs d’interagir avec les appareils.

La logique backend de l’application IoT, qui s’exécuterait normalement dans le cloud, s’exécute également sur le contrôleur local. Cela signifie également que l’application backend doit être réduite aux limites d’un appareil de classe Raspberry Pi.





La plateforme Thingsquare IoT, fonctionnant dans le cloud.





La plate-forme Thingsquare IoT, fonctionnant sans nuage sur un contrôleur local.

Puisque nous ne pouvons pas nous attendre à ce que le matériel du contrôleur local soit aussi robuste qu’un hôte cloud, en particulier si le contrôleur local est basé sur un Dakota du Sud lecteur, nous limitons les écritures sur disque en stockant les données volatiles en mémoire. Cela signifie que les logiciels qui s’exécutent au-dessus de l’API doivent être prêts à gérer l’accès à moins de données.

Authentification d’utilisateur

Pour authentifier les utilisateurs, nous utilisons une approche à deux niveaux. Le premier niveau consiste à tirer parti du contrôle d’accès existant au WiFi local. Si un utilisateur est authentifié sur le WiFi local, ce niveau suppose que l’utilisateur doit également avoir accès au contrôleur local et à ses appareils. Il est possible de configurer le niveau d’accès que ces utilisateurs locaux non authentifiés doivent avoir.

Le deuxième niveau utilise une approche hybride: nous utilisons le cloud pour authentifier l’utilisateur et fournir un jeton d’accès au contrôleur local. Le contrôleur local annonce sa présence avec des balises Bluetooth cryptées que l’application smartphone utilise pour authentifier chaque utilisateur. Cela nécessite que les utilisateurs aient un compte dans le cloud. L’application vérifie avec le serveur cloud pour faire correspondre la balise cryptée et le compte utilisateur. Si l’utilisateur a accès, le serveur répond avec une clé d’accès au contrôleur local.

Authentification de l’appareil

L’authentification de l’appareil est comparativement plus facile que l’authentification de l’utilisateur, car les appareils peuvent être préprogrammés avec TLS certificats. Nous là

Livraison logicielle avec un référentiel git

Nous livrons tous les logiciels sur un référentiel git géré. Ce référentiel peut être mis à jour en connectant le contrôleur local à Internet et en demandant une mise à jour, ou manuellement via un USB bâton.





Pour les contrôleurs locaux hors ligne, les mises à jour logicielles sont fournies via le référentiel git, soit distribuées automatiquement via une connexion réseau temporaire, soit manuellement avec un USB bâton.

Mises à jour du firmware

Les fichiers de mise à jour du micrologiciel signés sont inclus dans le référentiel git. Les appareils peuvent demander des mises à jour au contrôleur local, tout comme ils le font lorsqu’ils sont connectés à un backend cloud.

Parce que nous utilisons le logiciel de backend IoT complet, réseau complet OTA les mises à jour fonctionnent comme d’habitude.

Interface utilisateur

Le contrôleur local peut présenter une interface utilisateur avec un écran tactile physiquement connecté au contrôleur, ou via le WiFi vers des applications pour smartphone sur le même réseau. Par défaut, l’interface utilisateur est implémentée via HTML5/ JS / CSS et est mis à jour via le référentiel git.

Conclusions

Le cloud fait partie intégrante de l’Internet des objets. Mais il y a des situations dans lesquelles le cloud n’est pas le meilleur choix.

Thingsquare fournit une solution IoT locale et sans nuage, basée sur le même logiciel qui soutient notre offre basée sur le cloud, qui résout les problèmes de livraison de logiciels, d’accès à l’interface utilisateur et de mises à jour du micrologiciel pour l’IoT sans nuage.