IOT architecture

La bonne architecture pour votre application IoT

Nous avons vu dans un article précédent que le marché de l’IoT était entré dans une phase de croissance exponentielle tirée par des usages nouveaux et innombrables.

Quand on parle d’IoT, on pense souvent en premier à l’objet lui-même qui est évidemment essentiel. Il a ses propres contraintes : fiabilité, poids, dimension, autonomie en énergie, coûts, …Mais la valeur d’un système IoT va se trouver dans l’exploitation des données et leur publication auprès d’un public. Pour cela l’application doit évidemment être performante fonctionnellement, mais elle doit aussi présenter une architecture qui lui assurera sécurité, scalabilité et haute disponibilité dans le contexte particulier de l’IOT.

Très nombreux sont les projets d’IOT qui buttent rapidement sur un défaut de conception d’architecture. Celle-ci doit bien être pensée dans une approche Devops afin d’adapter l’architecture logicielle et l’infrastructure. Nous allons donc voir quelles sont les spécificités d’une application IoT afin d’aborder les contraintes d’architecture et d’exploitation.

Une infrastructure IOT

Une infrastructure d’IOT repose sur 3 grands composants que l’on retrouve dans le schéma en début d’article

  • un parc d’objets connectés fixes ou mobiles, répartis géographiquement,
  • un réseau telecom qui va permettre de connecter les objets en transmettant des messages, ce réseau peut être filaire ou sans-fil court (wifi, bluetooth,…) ou longue portée, mobile (2G, 3G…) ou bas débit (LoraWan, Sigfox,…)
  • une application, développée le plus souvent en technologie web, qui collecte les data du réseau d’objets pour fournir une information agrégée et retraitée.

Voyons donc les grandes fonctionnalités d’une application IOT qui sont représentées dans le schéma suivant:

La fonction Gateway : intégration des flux

La fonction Gateway est la porte d’échange des message entre l’application et le parc des objets, elle est branchée sur le réseau télécom et va notamment se charger de la sécurité.

Le premier objectif est d’authentifier et autoriser les objets à dialoguer avec l’application. On peut se dire que cette contrainte de sécurité dépendra de la nature des informations: si elles sont peu critiques, cela peut paraitre un coût superflu. Mais une entreprise qui propose un service d’IoT aura intérêt à s’assurer que ses données sont intègres et donc que l’on ne peut pas injecter des jeux de données fictives à partir d’objets illégitimes.  Le deuxième objectif est de chiffrer les messages transitant sur le réseau pour éviter qu’ils soient interceptées.

L’implémentation de la sécurité  dépendra du protocole et du mode de dialogue retenu. Bien souvent cette sécurité viendra alourdir le poids des messages et le temps de transmission, et comme la transmission consomme de l’énergie et du coût télécom , il y a là un arbitrage à faire. Mais dans tous les cas il faut le penser assez vite. Car rajouter de la sécurité quand on a un volume conséquent ou déjà des soucis de capacité, cela peut être très compliqué.

En exploitation, on veillera à mettre en oeuvre une supervision applicative adaptée qui permettra de détecter toute anomalie des flux de messages. En cas de coupure du service, c’est l’application qui cesse d’être alimentée en données, et si les systèmes prévoient en général de pouvoir ré-emettre, cette capacité est le plus souvent limitée dans le temps, la supervision doit donc détecter l’anomalie assez rapidement.

Le traitement des messages

Une fois la Gateway passé, il va falloir réceptionner , traiter et intégrer les messages. Ici la question de la volumétrie est critique, cette fonction doit pouvoir absorber un volume de messages très fluctuant.

La ville de Houston est en ce moment victime d’inondations brutales  et sans précédent. Typiquement dans un évènement climatique soudain, les capteurs auront rapidement une foule d’informations à transmettre et à intégrer, or il est essentiel que l’application sache les absorber en temps réel. Exemple, un pic de pollution, comment évolue-t-il , sur quelle zone, peut-on lever l’alerte ou non , faut-il l’aggraver ?

Une autre fluctuation sera l’augmentation du parc d’objets : le succès d’un déploiement initial peut déboucher sur un élargissement rapide, une start-up qui a validé le fonctionnel chez un client important peut avoir des difficultés dans le déploiement à plus grande échelle. Pas besoin d’atteindre des volumes astronomiques pour rencontrer des limites, chez alfa-safety nous sommes intervenus pour analyser des applications qui peinaient à dépasser quelques centaines d’objets.

On voit donc que cette fonction doit être performante et scalable, et ceci dans une proportion importante. Cela veut aussi dire que cette fonction doit en termes d’architecture logicielles être pensée comme un service autonome pour assurer la scalabilité de l’application.

La gestion du parc

l’IOT est jeune, les parcs d’objet évoluent rapidement, il est donc important de pouvoir suivre son parc et le manager: suivre les générations de modèles, faire des mises à jour à distance, mais aussi suivre son état , détecter ses défauts. Cette fonction , interne par opposition à l’application de présentation des datas, doit donc pouvoir évoluer à son rythme et indépendamment du reste de l’application. Pour cela, il est bien qu’elle soit conçue comme un module à part que l’on pourra mettre à jour sans devoir redéployer toute l’application.

Les bases de données

Le parc d’objets va alimenter l’application d’un flux croissant de données qu’il va falloir stocker, indexer, analyser. Dans ce bloc, on va donc trouver des bases relationnelles, mais aussi des bases rapides de types clé valeur, des outils d’indexation ou de moteur de recherche,…L’intégrité et la sécurité des données est critique, c’est LA VALEUR de l’application, le service de BDD doit donc être ultra sécurisé et résilient. Pouvoir partager les BDD entre plusieurs serveurs frontaux est critique pour assurer la disponibilité et la scalabilité de l’application. En termes de conception, une architecture N tier avec un serveur de BDD isolé est donc indispensable. On pourra notamment avoir une architecture permettant d’avoir un RPO (Recovery Point Objective ou point de restauration des datas) très court en cas d’incident. Typiquement sur un cloud  comme AWS, on placera ses bases de données sur un service RDS managé et en cluster sur deux zones de disponibilité.

Le serveur d’application -visualisation des données

L’objectif d’une application d’IOT est de traiter et présenter les données aux utilisateurs qui viendront s’y connecter, majoritairement via un accès web. Et aujourd’hui cette présentation sera presque toujours graphique: on y verra l’état de ses objets représenté par code couleur sur un fond cartographique, ou sous forme d’un tableau de bord avec indicateurs visuels et graphiques.

Le volume de connexions au serveur d’application dépendra de son public: limité pour une application professionnelle sur une audience ciblée, il peut devenir important sur une audience grand public. Il faudra peut être dans ce dernier cas prévoir un système d’auto-scaling pour ajouter un ou plusieurs serveurs en cas de pics de charge et/ou pour garantir les temps de réponse.

Il faut donc que cette brique applicative soit conçue comme un service en haute disponibilité que l’on pourra mettre à jour sans couper les autres. Tout cela doit être intégré dans l’architecture applicative.

Les transferts externes de data

Un autre mode d’usage des données est de les transférer vers le SI d’un client qui va à son tour les intégrer pour les exploiter dans son cas d’usage particulier, voici deux exemples qui montrent que cette fonction peut être critique:

  • un opérateur de service IOT propose à ses clients de s’abonner à un service d’information basé sur son réseau d’objets, les données sont remontées dans le SI du client final qui va s’en servir pour produire ses propres services, comme une société de surveillance ou mantenance qui transmet certaines alarmes à un sous-traitant qui se charge d’intervenir sur site.
  • un opérateur d’un réseau IOT sur lequel une société pourra venir connecter ses objets  en entrée et récupérer ses données en sortie.

C’est un autre usage applicatif des données, qui a la particularité de peut-être devoir être décliné de manière différente pour plusieurs clients et dont la disponibilité et la fiabilité seront absolument critique. Ici encore le service applicatif doit être autonome pour ses mises à jour, scalable et en haute disponibilité.

Enfin, on veillera ici encore à mettre en oeuvre une supervision applicative efficace des flux.

Une démarche de conception applicative impérativement en mode Devops

Comme nous l’avons dit, les projets d’IOT sont pour la plupart jeunes, ils démarrent souvent comme une start-up, la priorité initiale est de démontrer le concept applicatif et de convaincre les premiers clients et utilisateurs.
Mais si le succès est au rendez vous, il faut passer à la phase d’industrialisation pour garantir la fiabilité et la sécurité du service. Pour cela il est impératif d’adopter une démarche Devops pour la conception de l’architecture et de respecter certains principes simples au risque de devoir plus tard « détricoter » son application en cours de route:

  • Architecture en modules applicatifs ou services autonomes pour faire évoluer indépendamment les services et assurer leur scalabilité,
  • Bases données séparées et hébergés sur un serveur sécurisé pour protéger le coeur de la valeur et permettre la scalabilité des services exploitant ces données,
  • Niveau de sécurité adapté de la fonction Gateway,
  • Scalabilité et haute disponibilité sur les serveurs applicatifs de restitution et transfert des data.

alfa-safety a déjà une solide expérience sur des projets d’IOT qui sont en production sur des volumes conséquents et auprès d’acteurs de référence. alfa-safety est également partenaire conseil du cloud Amazon Web Services qui propose la palette de services pour IOT la plus complète et la plus aboutie du marché. Beaucoup de projets que nous menons se déploient sur AWS.

Vous travaillez sur une projet d’IOT et vous interrogez sur vos choix d’architecture ?  consultez notre site web  sur le sujet de l’IOT ou contactez nous .

 

Laisser un commentaire

*

Be sure to include your first and last name.

If you don't have one, no problem! Just leave this blank.