L’IoT (Internet of Things) est souvent perçu comme un concept nébuleux qui, au mieux, est associé à des fonctions de domotique ou de Quantified self ! En fait l’IoT recèle des cas d’usage très variés qui nécessitent des systèmes d’information tous aussi variés.
Domotique où non, ces cas exploitent des patterns applicatifs et techniques ainsi que les technologies associées. Par ailleurs, de nombreuses offres commerciales ou open source de “plates-formes IoT” fleurissent sur le marché. Elles offrent des services d’acquisition de données, de télécommunications et de traitements. En fait, elles implémentent tout ou partie des patterns et des technologies que nous venons d’évoquer.
Cette première partie de l’article a pour objectif de présenter les besoins de l’IoT, les patterns "solution" utiles et de les illustrer sur des cas concrets. Nous allons donc nous focaliser sur les éléments présentés ci-dessous :
La complexité du sujet nécessite de maîtriser bien des aspects. Chez OCTO, les “ Architectes IoT ” incarnent ce savoir-faire.
Les systèmes d’IoT se caractérisent par 4 besoins majeurs :
Le besoin de connectivité
Le besoin d’analyse et de décision
Le besoin temporel
Le besoin d’action
Le tableau suivant montre la synthèse des Patterns de systèmes IoT.
| Patterns | Connectivité | Analyse et décision | Temporel | Action |
| Global / Central / Mobile | Objets connectés à Internet / Wan | Système central de collecte des informations des objets, d’analyse et de décision | Temps réel | Multicast vers des classes d’objet |
| Local / Ciblé | Objets connectés au LAN | Locale (objets intelligents, passerelles applicatives) | Différé | Ciblé objet par objet |
Prenons quelques exemples pour illustrer ces concepts :
Exemple : La montre connectée pour le Quantified self
| La montre connectée | Connectivité | Analyse et décision | Temporel | Action |
| Global / Central / Mobile | La montre communique en 3G via le téléphone mobile | Application cloud multi tenant d’analyse des données personnelles | Analyse différée dans l’application SaaS d’accompagnement de la montre | Pas d’action |
| Local / Ciblé La montre elle même | Bluetooth low energy entre la montre et le téléphone mobile | Affichage de quelques données en local | Accès immédiat sur affichage | Pas d’action |
Exemple : Régulation de la production d’électricité par délestage
Le cas d’usage est l’adaptation de l’offre et de la demande d’électricité par le délestage de charges inertielles (ballon d’eau chaude, radiateurs, climatisation…)
| Délestage électrique | Connectivité | Analyse et décision | Temporel | Action |
| Global / Central / Mobile | Les compteurs intelligents envoient les mesures par CPL puis passerelle Internet | Application cloud d’analyse des consommations et de décision des délestages | Analyse quasi temps réel (10 mn) et demande d’action | Envoi d’ordres de délestage par zone du réseau (régions géographiques) |
| Local / Ciblé Le compteur et le délesteur du ballon d’eau chaude | CPL local | Possibilité de décider du délestage par analyse de variation du tarif Arbitrage entre ballon ECS et radiateurs | Action temps réel en local possible (prise en compte immédiate du tarif) | Envoi de demande de délestage ballon par ballon (contrat négocié individuellement par l’opérateur d’électricité et ses clients) |
Les systèmes IoT sont donc définis par des combinaisons variées de ces 4 caractéristiques. Chaque caractéristique peut être réalisée par des patterns applicatifs et techniques.
L’interpénétration des télécommunications et de l’informatique rend la situation assez compliquée. Nous essayons ici de simplifier la situation en séparant la couche physique du middleware.
En IoT, l’architecte cherche avant tout l’allègement des moyens de communication. En effet, le déploiement des réseaux locaux en milieu professionnel ou résidentiel est compliqué et cher d’un point de vue pratique (appariement Wifi, déploiement de bornes physiques...). Les réseaux grande distance (3G/4G) facilitent le déploiement tout en offrant une connectivité Internet mais limitent les communications locales (inter-objets). Les réseaux grande distance basse consommation et bas débit (Sigfox, Lora Alliance…) offrent des alternatives aux technologies précédentes pour peu que le volume à transmettre, le débit et la latence de communication soient peu contraints. Les communications inter-objets sont impossibles par ces protocoles mais les produits de communication qui les implémentent permettent de faire en général un réseau local Wifi, Bluetooth ou équivalent.
Ci-dessous sont présentées les offres de communication grande distance disponibles pour les architectures IoT.
Pour ce qui est des communications locales, les offres suivantes sont les plus répandues. Vous pouvez constater que ces offres ne couvrent toutefois pas les mêmes services réseau.
L’IoT utilise 3 patterns de communication applicative :
Chaque offre, embarque ou non, un niveau de description des objets (avec une volonté de traiter l’interopérabilité).
Les offres applicables dans l’IoT sont plus ou moins dédiées vers ce domaine d’application d’autant plus qu’elles incorporent des fonctions de la couche application.
La figure suivante montre l’étendue des offres disponibles, et elle ne se veut pas exhaustive !!
L’analyse de ces offres montre que le pattern Pub/Sub objet est prépondérant. Ceci apparait logique pour deux raisons :
Dans le cas où ces deux besoins sont évacués, les échanges classiques “ non teintés IoT ” sont suffisants comme les MOM et les WebServices.
Évidemment, toutes ces offres ne sont pas combinables aux couches physiques présentées juste au-dessus ! Ce serait trop simple !! Je vous engage d’ailleurs à faire l’exercice d’établir la matrice de compatibilité entre ces couches middleware et les couches physiques (un des sujets majeur du savoir-faire des architectes IoT ).
Les objets sont installés, connectés et peuvent parler et écouter ! Maintenant que font-ils !? Ces objets peuvent agir comme des :
Les décisions locales d’objets communiquant reposent sur le croisement des informations sur le réseau local. Dans un système d’alarme, les capteurs peuvent collaborer pour détecter une situation anormale. En général, un point de concentration local porte l’algorithmique de décision. Les passerelles applicatives portent ce rôle et sont déjà légion sur le marché : centrale d’alarme, boitier concentrateurs de mesures, donc rien de bien nouveau. Une offre telle que OnHub est emblématique de la manière dont les constructeurs tentent de présenter la fonction. D'autres visions, proposent que le téléphone mobile joue le rôle de concentrateur qui porte les logiques de décision et de contrôle.
Les box d’opérateurs telco ainsi que les services de proximité (banque, courrier, distribution, …) sont également sur les rangs pour se placer dans cette position centrale. Les grands faiseurs ne sont pas en reste, Apple et Samsung ont annoncé respectivement leurs protocoles d’échange entre objets de la maison connectée. Une bataille industrielle s’annonce sur fond d’interopérabilité…
Là, par contre, l’IoT apporte réellement de la nouveauté : la remontée d’informations en masse. Les objets (ou plutôt leurs exploitants) peuvent décider de remonter les informations vers un système central pour effectuer des traitements de masse et prendre des décisions. Ce type d’opportunité émerge et n’est assurément pas totalement explorée. Prenons quelques exemples :
Les boites à lettres communicantes : Supposons que les boîtes aux lettres jaunes de La Poste présentes dans les rues soient capables de détecter leur niveau de remplissage. Elles envoient cette information au système central qui va organiser la tournée de relève pour vider en premier celles qui sont pleines. Mais La Poste serait aussi capable d’adapter le nombre de boites et les tournées de relève (à publier/pousser sur un site d'information public) en fonction des remplissages et de la géographie.
Le machine learning est une des technologies les plus prometteuses pour réaliser des décisions adaptées tant au niveau de l’objet individuel que du parc collectif. L’IoT étant notamment “centré sur les données” il est naturel de travailler les données (sans préjugé de modélisation) pour extraire des stratégies de conduite.
La démarche traditionnelle cartésienne fonctionne sur des “modèles” qui représentent le fonctionnement du système (par exemple un modèle mathématique qui prévoit la consommation d’électricité en fonction de la météo); Dans le machine learning, on cherche des correspondances sans modèle a priori basé sur un grand nombre d’observations. Ceci est typiquement applicable à l’IoT : un foisonnement de comportements individuels donne au total un comportement global, peu explicable, mais observable et analysable en machine learning. Les applications de cette approche sont nombreuses dans le domaine médical et le Quantified self. La détection de pathologies est réalisée par les relevés comportementaux des patients et leurs constantes physiologiques (age, glycémie, pou, pression artérielle, masse osseuse…). On évalue alors rapidement une situation critique sur un individu par l’observation de ses constantes.
Tout paraît donc possible, les objets étant des pourvoyeurs d’information sans limite. Malheureusement, leur richesse fonctionnelle doit être ajustée à ce que l’on souhaite faire et au prix de l’objet et des services associés. Trouver cet équilibre économique est une réelle expertise.
Le besoin de temps réel est toujours plus présent. La raison en est simple : aller plus vite dans les décisions permet au mieux de prendre la bonne option immédiatement, ou au pire de pouvoir redresser la barre rapidement. Alors que le métier se satisfaisait de statistiques a postériori (pattern BI), aujourd’hui l’interaction temps réel est nécessaire pour accrocher, satisfaire et fidéliser le client. La logistique, le commerce électronique, l’industrie sont confrontés à une demande d’accélération et de réactivité des flux d’information.
Les objets connectés, étant à l’avant-poste pour capter les informations réelles, déversent donc massivement et à grand débit les informations dans les sites centraux de décision.
Nous constatons que les systèmes traditionnels ne suivent plus en termes de performance et d'évolutivité (base de données relationnelles, serveurs d’application, systèmes scalables verticalement…).
Les exemples sont nombreux : compteurs de fluide intelligents, suivi logistique RFID, suivi de constantes physiologiques de patients, suivi d’objets circulants (containers, colis…).
Gros volumes d’événements, réactivité, règles de décision, trois patterns s’imposent :
De plus toutes les techniques de conception de la performance sont largement utilisées en IoT.
Le pattern CQRS sépare le canal d’alimentation des données du canal de requête.
Ainsi, les deux canaux peuvent disposer de caractéristiques et de cycles de vie indépendants et rendre la conception et la maintenance du système plus flexible. En entrée, les événements envoyés par les objets atteignent un débit très important (10.000 messages par seconde étant couramment observé dans le monde logistique par exemple). Le canal d’entrée ne doit en aucun cas être perturbé par l’usage des données engendrées. Du coté usage, les consommateurs sont le machine learning et les requêtes type BI.
L’IoT étant très tourné vers l’événement, le Complex Event Processing est largement utilisé.
L’utilisation qu’en fait l’IoT est tout à fait classique : comme la réaction à des événements particuliers (alarme déclenchée), mais aussi l’absence d’événements (non réaction d’un capteur toutefois attendue), la corrélation d’événements (le radiateur est allumé mais la température baisse…) A ne pas confondre avec le machine learning qui lui s’entraine sur les données pour ajuster des algorithmes de décision, le CEP lui peut être basé sur des règles programmées issues de modèles a priori.
Les temps de réponse attendus dans le monde de l’IoT sont très variables : de la seconde (alarmes) à l’heure (mesure de température) sont les valeurs les plus couramment rencontrées.
Une fois les données “refroidies” (plus susceptibles d’être modifiées) elles entrent dans une stockage adapté : Les solutions big data sont utilisées, Hadoop/Spark étant celles les plus utilisées dans le monde IoT. Les analyses a postériori peuvent alors commencer sur ces données historiques.
Une fois la décision prise, se pose la question d’envoyer la commande à l’objet capable d’agir (contacteur, variateur…). Il s’agit essentiellement d’une problématique du choix du canal de télécommunication descendant : quelle latence et débit nécessaire; quelle qualité de service de livraison (acquittement ou pas). Des solutions bas débit comme SIGFOX peut parfaitement convenir si la latence tolérée est forte, un canal Internet classique de révèle indispensable en cas d’action quasi temps réel.
On voit donc se dessiner un ensemble de fonctionnalités récurrentes dans le monde de l'IoT. Ces fonctions sont de l'ordre de la mesure, des télécommunications, de l'analyse des données, de la data science, du traitement temps réel des événements, du stockage de masse...
On sent bien que l'on peut constituer des plates-formes "génériques" qui peuvent s’instancier sur des cas métiers différents. Le pari est d'être capable de concevoir un système que l'on pourra paramétrer/compléter pour réaliser un système d'IoT complet orienté vers un usage donné. C'est tout l'enjeu du marché des plates-formes IoT.
Ainsi une même plate-forme (socle) pourrait être instanciée aussi bien pour une entreprise de logistique qui remonte et traite des informations des capteurs de ses camions, que d'un constructeur de radiateur qui réalise des fonctions d'optimisation d'énergie domestique. La promesse est donc : "La plate-forme IoT vous permet de construire l'offre métier IoT sans vous perdre dans un dédale de technologies et de problèmes techniques". Cette promesse est elle réaliste ? Nous allons tenter de répondre à cette question !
La conception d’une architecture IoT doit aborder les thématiques vues plus haut dans une vision holistique.
Cependant, toutes les entreprises n’ont pas la volonté et/ou la capacité à concevoir leur système d’IoT en interne. Chez OCTO, nous disposons de l’expertise de conception des plateformes IoT. Décoder les capacités de ces plates-formes est essentiel pour faire le choix adapté au projet IoT de l’entreprise.
Une représentation simplifiée va nous permettre d’analyser les offres:
La partie 2 de cet article va présenter l'analyse des offres commerciales sur ce modèle d’architecture type.
La figure suivante présente des offres majeures du marché. Elles sont très nombreuses et variées.
L'entreprise est donc confrontée à une foison d'offres qu'il convient de décoder et de choisir en fonction des objets et des services métier que l'on veut offrir.
Nous avons vu que les services d'IoT reposent sur des capacités de télécommunication (transport local/distant), d'analyse et de décision (calcul, data science, machine learning...), de réactivité temporelle (CEP) et de transmission d'actions. Ces capacités sont réalisables par des solutions et technologies très variées qui doivent être intégrées. Cette intégration est complexe et est menée par des architectes IoT. Les entreprises souhaitant se concentrer sur leur métier peuvent bénéficier de plates-formes IoT qui intègrent tout ou partie des capacités présentées ici. De nombreuses offres commerciales SaaS de plates-formes IoT sont disponibles mais il faut être capable de sélectionner celle la mieux adaptée au projet IoT de l'entreprise. La partie 2 de cet article va se concentrer sur ce dernier point.
