Introduction

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.

Besoins des systèmes IoT

Les systèmes d’IoT se caractérisent par 4 besoins majeurs :

Le besoin de connectivité

• L’objet communique avec des objets en proximité géographique (réseau local)
• L’objet communique sur Internet (réseau mondial)
• L’objet nécessite une communication fixe ou mobile (wearable par exemple)
• Ou une combinaison de ces propriétés !

Le besoin d’analyse et de décision

• Les informations produites par les objets sont utilisées globalement (utilisation de la statistique et du foisonnement) à large échelle
• Les informations produites par les objets sont utilisées pour produire localement des décisions (niveau individuel)
• Ou les deux

Le besoin temporel

• Les informations créées par les objets ont une criticité temporelle forte (temps réel)
• Les informations n’ont pas de contraintes fortes en termes de délai de traitement

Le besoin d’action

• Les actions décidées sont ciblées vers des objets bien identifiés
• Les actions décidées sont appliquées sur les objets de manière statistique ou aléatoire
• ou les 2

Le tableau suivant montre la synthèse des Patterns de systèmes IoT.

Prenons quelques exemples pour illustrer ces concepts :

Exemple : La montre connectée pour le Quantified self

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…)

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.

La connectivité

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.

Offres disponibles sur la couche physique

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.

Couche middleware de communication

L’IoT utilise 3 patterns de communication applicative :

• Les web services (http  REST, SOAP)
• Les messages (MOM : MQ, MQTP...)
• Le Publish&Suscribe (Pub/Sub)

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 :

• D’une part, ce pattern répond au besoin de voir apparaître de nouveaux objets et de les abonner à des services existants ou d’injecter de nouveaux services (l’ajout d’un nouveau thermostat qui va contrôler les radiateurs)
• D’autre part, l’exposition d’objets métier sur le réseau, avec la volonté de monter dans la couche applicative et de proposer des cadres d’interopérabilité.

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 ).

Analyse et décision

Que font les objets

Les objets sont installés, connectés et peuvent parler et écouter ! Maintenant que font-ils !? Ces objets peuvent agir comme des :

• capteurs sources d’information
• afficheurs capables de transmettre un état ou des informations
• capacités de calcul distribuées
• actionneurs qui peuvent agir sur leur environnement

Décisions locales

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é…

Décisions centrales

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.

Besoins temporels

Plus vite dit le métier !

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…).

L’IoT impose les architectures réactives

Gros volumes d’événements, réactivité, règles de décision, trois patterns s’imposent :

• Le CQRS (Command Query Responsibility Segregation)
• Le CEP (Complex Event Processing)
• Le stockage et traitement des données massives (Big Data)

De plus toutes les techniques de conception de la performance sont largement utilisées en IoT.

Le CQRS

Le pattern CQRS sépare le canal d’alimentation des données du canal de requête.

Source : http://martinfowler.com/bliki/CQRS.html

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.

Le Complex Event Processing

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.

Les données de masse (Big data)

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.

Besoins d’actions

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.

Vision architecturale globale : Les plates-formes IoT

Position du problème

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 !

Les plates-formes IoT

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.

Les offres

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.

Conclusion

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.