Un petit état des lieux des plates‐formes IoT FOSS

Posté par Benoit Renault (aka. Xia0ben) . Édité par ZeroHeure, Davy Defaud, Nÿco et Benoît Sibaud. Modéré par ZeroHeure. Licence CC By‑SA.
Étiquettes :
21
16
oct.
2017
Cloud

Bien le bonjour !

J’ai longtemps hésité à partager ce petit quelque chose ouvertement avec la communauté FOSS. Puis, je me suis dit que j’allais peut‐être me bouger et parler, accepter de m’exposer à la critique, avant que ce que j’y raconte perde de son actualité.

Mais quoi que donc qu’il parle le petit bonhomme ?

Ce petit quelque chose, c’est un rapport « état des lieux » des plates‐formes cloud IoT (Internet of Things) FOSS (Free or Open Source Software) que j’ai réalisé courant août 2017 dans le cadre du projet de recherche OCCIware (lien en bas).

Définition

Ce que j’appelle une plate‐forme IoT, c’est une suite logicielle présente sur un ou des serveurs, qui va accumuler les données produites par les capteurs embarqués, les stocker, les traiter, et éventuellement les analyser et générer des tableaux de bord. Un machin « cloud » quoi =). En anglais, ça donne ça :

« IoT middleware platform for building, managing, and integrating connected products. »

Oui, je sais, c’est imprécis et large, mais ça vient avant tout de la diversité des solutions et des approches, et puis aussi un peu de mon incapacité à faire des jolies définitions (*ノωノ).

Du FOSS, plz !

Et, bien sûr, FOSS, parce qu’il était tout simplement hors de question pour moi de stocker mes données sur un serveur sur lequel je n’ai pas les accès, avec une boîte noire qui fait tout ce qu’elle a bien envie de faire avec, SACREBLEU !

Plus de détails

J’ai passé une dizaine de jours à faire le tour des solutions du milieu, j’ai essayé de les évaluer individuellement et comparativement afin, au final, d’en choisir une qui correspondait à mes usages.

Ce rapport, c’est aussi l’occasion de discuter de critères d’évaluation de ces logiciels (et d’autres ?), et ce serait avec plaisir que j’accueillerai des remarques sur mes choix (parfois arbitraires ?) ! J’ai eu un peu l’occasion d’échanger avec les développeurs des différents projets présentés, qui m’ont déjà transmis quelques corrections mineures (voir l’historique des commits sur le dépôt), mais ce serait super si des personnes que ça intéresse s’exprimaient également.

Si je parlais aussi de « perdre de son actualité », c’est qu’avec le temps mon analyse de ces plates‐formes perd de son intérêt puisque les nouvelles versions viendront combler les défauts que je pointe. Je pense que ce rapport a un intérêt pour les six à douze prochains mois maximum. Après, sans mise à jour, je pense qu’on pourra dire qu’il est « deprecated » (◕‿◕✿).

Voilà, je m’en remets à votre jugement et vous souhaite une bonne lecture !

Benoît Renault (aka Xia0ben).

Aller plus loin

  • # Utilité des plateformes génériques ?

    Posté par  . Évalué à 1. Dernière modification le 16 octobre 2017 à 17:47.

    Bonjour,
    J'ai beaucoup de mal à comprendre le but d'une analyse unique. Le terme IoT regroupe une foule d'objets connectés avec des utilisations totalement hétérogènes et parler de plateforme, c'est déjà discriminer suivant un ou plusieurs cas d'utilisation, ce qui reviendrait à faire une analyse par cas d'utilisation et un document sur les plateformes qui correspondent aux besoins.

    Je me vois difficilement traiter de la même manière des microcontrôleurs sous Arduino avec une stack ultra-légère faisant juste des appels à un service pour y déverser de la télémétrie et un service actif, par exemple pour piloter la domotique de ma maison, qui aura de toute façon une architecture différente (un nœud de regroupement des relevés des sondes et qui les enverra au serveur et recevra des ordres). A l'opposé de tout ça, on pourrait avoir une cafetière connectée étant juste capable de recevoir l'ordre de faire du café, sans état à publier, ou encore un appareil avec Alexa d'Amazon qui pourra faire bien plus de chose de tout ce qui a été listé ci-avant. Quid de l'industriel et du contrôle d'appareil à distance, entrant aussi dans ces cases ?

    Bref, ça serait bien d'expliquer votre besoin spécifique côté client et serveur, et donc le pourquoi de cette analyse, parce qu'en survolant le document, je ne vois pas en quoi ces frameworks font gagner plus de temps que de développer un serveur tout simple et un client simple embarqué ni à quels besoins ils répondent.
    De la même manière, le besoin est flou sur les contraintes de sécurité côté client et serveur. Est-ce que le client valide le serveur avec son certificat et vice versa, par exemple ? (bonnes pratiques standard, en somme).
    Et pas de mention de mise à jour OTA des clients. Est-ce qu'on considère qu'on remplace les appareils tous les ans sans mise à jour possible ? Est-ce qu'il est acceptable d'aller sur site et de mettre à jour les appareils un par un, régulièrement ?

    • [^] # Re: Utilité des plateformes génériques ?

      Posté par  . Évalué à 1.

      Bonjour à vous !

      Tout d'abord, merci pour votre commentaire fourni en arguments et remarques pertinentes !

      L'intérêt d'une plateforme générique pour l'IoT (du moins, l'argument donné par la plupart des produits présentés ici) est justement de couvrir un grand panel de cas IoT, allant de la domotique à des capteurs météo pour l'agriculture, en passant par la gestion de capteurs urbains, comme le résume par exemple le site web du projet Kaa sur sa page https://www.kaaproject.org/overview/ :

      "Kaa is a multi-purpose middleware platform for the Internet of Things that allows building complete end-to-end IoT solutions, connected applications, and smart products. The Kaa platform provides an open, feature-rich toolkit for the IoT product development and thus dramatically reduces associated cost, risks, and time-to-market. For a quick start, Kaa offers a set of out-of-the-box enterprise-grade IoT features that can be easily plugged in and used to implement a large majority of the IoT use cases."

      Oui, bien sûr, comme dans n'importe quel développement, il est possible de faire un petit bidule rapidement avec quelques lignes de Python qui couvre juste un besoin, mais, comme dans tout développement, si l'on veut soit passer à l'échelle, ne plus avoir à maintenir un back-end et se concentrer sur l'application, à un moment, il est vite préférable de partir sur une base préexistante, développée avec un souci d'adaptabilité et de mise à l'échelle.

      Kaa, par exemple, prend en compte aussi bien le cas du simple Arduino qui fait de la télémétrie au cas très complexe de la domotique en apportant :
      - Une abstraction partielle du matériel IoT edge grâce à des kits de développement/bibliothèques pour un grand nombre de plateformes hardware, accélérant le développement
      - La possibilité d'un contrôle et d'une mise à jour à distance si le cas le nécessite (#domotique) (ce qui n'est pas le cas de toute les plateformes, et qui aurait sûrement mérité un critère supplémentaire)
      - Une abstraction partielle des machines clientes (de consultation ou contrôle, i.e. les smartphones, tablettes et autres ordinateurs) grâce à des SdKs rendant le même service que pour les périphériques Edge.

      Ce que c'est plateforme génériques apportent, c'est justement de ne pas avoir à redévelopper toutes ces fonctionnalités et bien d'autres (interface d'administration, stockage, traitement, aggrégation des données, et j'en passe), et de pouvoir directement se concentrer sur des cas d'usages.

      Il est vrai que le besoin exact (capteurs de consommation d'énergie allant d'une échelle locale à continentale, en résumé) n'est pas exprimé dans l'article, mais l'est au début du rapport avec un lien vers l'OCCIware Linked Data Use Case. Votre remarque montre que je devrais préciser cela directement dans l'article et le rapport, et pas juste mettre un lien dans le rapport =).

      En ce qui concerne la sécurité, j'avoue bien honnêtement que mes deux critères "Statements" and "Audits" sont très limités, et mériteraient grandement d'être détaillés, notamment au niveau des questions de :
      - Chiffrement
      - Signature
      - Détection des périphériques malveillants
      - Containerisation
      - Possibilités de mise à jour à distance pour combler les failles,

      Néanmoins, je ne disposais que d'environ 3 heures d'analyse spécifique à chaque projet : j'explique donc dans le rapport que mes critères sont orientés de telle sorte que je pouvais respecter cette durée, en se concentrant sur une analyse du site web, de la documentation et du repo du projet. Cette durée d'analyse est un des points clefs du rapport. Pour aller à un niveau de détail aussi profond, étant donné le manque d'information flagrant pour certains projets (souligné dans le rapport), il aurait fallu prendre le temps de lire le code en bonne partie pour juger de la qualité réelle de la sécurité : en gros faire un audit. Non seulement je n'avais pas le temps, mais cela sort clairement de mon domaine de compétence, ce que je préfère admettre plutôt que de m'aventurer dans des conclusions hasardeuses.

      Il me semble avoir adressé dans ce commentaire la totalité des points soulevés : si cela n'est pas le cas, je répondrai avec plaisir à d'autres remarques/questions/critiques ;-).

      Bien à vous !

  • # "Server percentage" ?

    Posté par  (site web personnel) . Évalué à 2.

    Donc si je lis bien, une partie de la note est le pourcentage de Java dans le code serveur, plus y il a de Java et meilleure est la note ?
    Ça me semble hallucinant.

    • [^] # Re: "Server percentage" ?

      Posté par  . Évalué à 1.

      Si vous êtes dans une boîte avec une majorité de développeurs java, ça a totalement du sens. Mais comme tous mes points dans mon message, ça non plus ça n'est pas une contrainte clairement exprimée dans le document.

      • [^] # Re: "Server percentage" ?

        Posté par  . Évalué à 1. Dernière modification le 18 octobre 2017 à 22:39.

        Damaki a très bien saisi le sens du critère : je donne d'ailleurs le même argument dans le rapport.

        Après je tiens à souligner que ce rapport n'a pas pour but de donner une note : trop de critères qualitatifs et divers, il serait trop long et d'une pertinence définitivement discutable que de les pondérer d'une quelconque façon.

        L'intérêt du rapport est surtout de mettre en avant les forces et faiblesses de chaque projet sur la grande variété de critères, et trouver celui qui "brille" le plus subjectivement dans le cadre du besoin du Use Case auquel le rapport renvoie.

        Donc, non, il n'y a pas de bonne note pour si le projet utilise du java (en fait, la plupart le fond : le seul autre language représenté est Javascript parmi ce genre de plateforme), seulement une préférence pour le use case. =)

        Autrement, ce serait en effet "hallucinant". ;-)

  • # Contiki ??

    Posté par  (site web personnel) . Évalué à 3.

    Je sais bien que ça a commencé comme un OS pour C64, mais… pas un mot sur Contiki ???

    • [^] # Re: Contiki ??

      Posté par  (site web personnel) . Évalué à 3.

      Heu, il ne parle pas de système à embarquer dans un micro (OS), mais de logiciels "cloud", des sites web quoi.

      Par contre, je dirais qu'il ne parle pas des plateformes pour les nouveaux réseaux LPWAN … si ça existe en FOSS ?

      • [^] # Re: Contiki ??

        Posté par  . Évalué à 1.

        En vrai c'est un peu un mix des deux dans le document. Ce qui n'est pas idiot, puisque trouver les stacks clientes n'est pas toujours évident.

        • [^] # Re: Contiki ??

          Posté par  . Évalué à 1.

          Encore, Damaki a souligné exactement ce qui "cloche" : "c'est un peu un mix des deux".

          La plupart des plateformes Cloud présentées proposent leurs SdKs pour plateformes périphériques Edge (arduinos, esp8266, raspis et autres contrôleurs tournant à base de Gnunux…) que clients (android, Gnunux, …).

          Il était donc a priori pertinent que de souligner cet effort de la part des développeurs quand il le faisaient, car ces SdKs ont un intérêt loin d'être négligeable dans la conception d'une application IoT, puisqu'ils réduisent drastiquement le temps de prise en main de la plateforme dans son entièreté.

          @François Revol : je ne connaissais pas du tout, et il n'est pas du tout ressorti dans mes heures de recherche, sûrement car je recherchais des plateformes middleware cloud, et pas des os pour périphériques Edge, comme l'a souligné Belegar. Néanmoins, le projet a l'air intéressant, et a sans aucun doute sa place dans l'écosystème très vaste de l'IoT.

          @Belegar : Je n'ai rien trouvé en FOSS pour ce qui est de plateforme middleware cloud pour les réseaux LPWAN. Après, dans l'absolu, pour les relier aux plateformes ici présentées, il suffirait d'une Gateway IoT connectée à la fois au LPWAN et à Internet pour renvoyer les infos au reste du système, un simple module manquant en somme ? =)

          Mon emploi du temps étant très chargé jusqu'à lundi prochain, je continuerai avec plaisir cette discussion la semaine prochaine : n'hésitez pas à apporter d'autres remarques, car toutes celles relevées jusqu'à maintenant sont définitivement pertinentes, et je vous en remercie tous (d'autant que j'avais pas mal d'appréhension au départ de faire un article pour diffuser ce rapport) ! Merci également pour le respect avec lequel vous formulez vos commentaires, cela rend la discussion d'autant plus agréable ! ;-)

          • [^] # Re: Contiki ??

            Posté par  (site web personnel) . Évalué à 1.

            Sauf que dans le cas des LPWAN, les données issues des capteurs sont disponibles sur les serveurs des opérateurs … qui ont chacun un protocole différent (ou API) pour aller récupérer les données.

            • [^] # Re: Contiki ??

              Posté par  . Évalué à 1.

              Bonjour Belegar,

              Ah, nous voilà dans le tristement courant cas de l'emprisonnement utilisateur =). Une courte recherche Google avec les mots-clefs "open source LoRaWAN" a néanmoins fait ressortir https://www.loraserver.io/ côté software, et https://lorrier.com/ côté hardware (mots-clefs "open source LPWAN") : si la question t'intéresse, pourquoi pas envisager de jeter un oeil à ces solutions, et nourrir la discussion à ce niveau ? Ma connaissance des LPWAN est plus que limitée, et j'ai le sentiment que tu as déjà des éléments de réflexion à partager ? Merci en tout cas d'avoir soulevé la question, qui mérite clairement en effet d'être soulevée, puisque les LPWAN vont être amenés à faire de plus en plus partie du quotidien des dev IoT ;-).

              Bien à toi !

  • # gobot

    Posté par  . Évalué à 1.

    Pour les gens allergiques au java (donc pas le cas de ce use case si j'ai bien compris) et/ou qui veulent se mettre au go, il y a aussi GOBOT.

    • [^] # Re: gobot

      Posté par  . Évalué à 1.

      Bonjour Eggus,

      Merci pour ce pointeur ! As-tu déjà étudié/utilisé ce projet ? Serais-tu intéressé de l'évaluer avec la grille de critères proposée dans le rapport ? Celui-ci étant sous licence libre CC-BY-SA 4.0, toute contribution serait la bienvenue ! ;-).

      Bonne journée à toi !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.