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 ?
# Utilité des plateformes génériques ?
Posté par damaki . En réponse à la dépêche Un petit état des lieux des plates‐formes IoT FOSS. É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 ?