Remontée de données capteur sur réseau cellulaire

Garder en tête une vue globale est très important dans la conception d’un système IoT. Pourquoi ?

Une première caractéristique remarquable des projets IoT est qu’ils nécessitent l’intégration de blocs techniques provenant de trois domaines différents : électronique, communications et logiciel. Et pour chacun de ces domaines, différents sous-domaines sont habituellement concernés : électronique analogique et numérique, modules de communication sans fil, piles de protocoles, logiciel embarqué, interfaces utilisateurs, gestion de bases de données, analyse de données, données géospatiales, etc.

Une seconde caractéristique remarquable est le grand nombre de cas d’usages totalement différents. L’IoT recouvre les villes intelligentes (au fait, c’est quoi, une ville intelligente ?), la gestion de l’énergie, la surveillance de l’environnement, l’immotique, la domotique, la gestion de flottes de véhicules, les systèmes de suivi, etc.

De nombreux cas d’usages et plusieurs technologies différentes : pas étonnant que la conception d’un système fiable répondant aux besoins utilisateurs nécessite une vision globale !

Voyons un exemple, qui va nous permettre de mieux comprendre cela.

Dans cet exemple, un équipement équipé d’un capteur doit remonter périodiquement un jeu de données du capteur vers un système central, en utilisant un réseau GSM en mode GPRS. L’équipement est alimenté par un module photovoltaïque et la batterie associée. Par conséquent, l’une des principales contraintes est une basse consommation.

L’équipe de conception possède une bonne expérience en capteurs et en électronique numérique. Mais elle n’est pas très expérimentée en développement logiciel et en protocoles de communicaiton. Par conséquent, elle décide de sous-traiter cette partie du projet.

Pour la partie matérielle, la conception repose sur un module cellulaire dit « basse consommation », et un microcontrôleur basse consommation également.

Pour la partie logicielle, le sous-traitant décide de stocker les données du capteur dans des fichiers CSV, et de remonter chaque fichier en utilisant FTP. La taille de chaque fichier est d’environ 10 Ko.

Regardons cela un peu plus en détail.

fichier CSV

Un fichier CSV contient des caractères lisibles par un humain. La donnée associée utilise plus de place que si elle était stockée en format binaire. Ce n’est pas un réel problème pour des données codées habituellement codées sur deux octets. Par exemple, 65000 utilise 5 + 1 octets (0x36 0x35 0x30 0x30 0x30 et le séparateur CSV, par exemple un point-virgule), tandis que 17 utilise 2 + 1 octets. Mais c’est beaucoup plus inefficace pour des champs comme des horodatages. Habituellement, un horodatage codé en binaire demande seulement 4 octets. Dans notre exemple, il a été décidé d’utiliser le format ASCII suivant pour les horodatages :

dd/mm/yyyy hh:mm:ss+hh:mm

qui comprend 25 + 1 octets, soit plus de six fois la taille du format binaire.

Le format prévu d’une ligne du fichier CSV est :

"00:1B:16:2D:4C:67";"11/02/2014 08:01:16+02:00";"112";"26023";"702";"2800";
"3045";"21905";"1223";"64"

Je ne connais pas le domaine de définition de chaque valeur entière transmise. Considérons qu’il s’agit d’entiers non signés sur deux octets. Par conséquent, le stockage des informations de la ligne ci-dessus sous format binaire nécessite 6 + 4 + 8 x 2 = 26 octets. Stocker les informations au format ASCII demande 101 octets, avec un ou deux caractères additionnels (retour chariot et / ou saut de ligne). Ainsi, plus de trois fois le nombre d’octets du format binaire !

Regardons maintenant la sémantique de l’information. Chaque ligne contient l’adresse de l’équipement, un horodatage, et les données du capteur. Se conformer au format CSV usuel demande que l’adresse de l’équipement soit présente sur chaque ligne. Utiliser un autre format (binaire) permettrait d’écrire cette information seulement une fois dans le fichier. Cela diminuerait encore la taille du transfert de (nombre de lignes – 1) x 6.

De plus, un schéma simple de compression pourrait être utilisé pour les données capteur. Par exemple, des valeurs différentielles pourraient être transmises, après une première valeur absolue.

Pourquoi chercher à réduire le volume de données ? Parce que le moins vous transmettez, le moins vous consommez de l’énergie. En GPRS, le débit peut être aussi bas que 1000 octets / s. Pour un fichier de 10 Ko, cela signifie une durée minimale de 10 s (en fait, plus de temps est nécessaire : voir ci-dessous).

FTP

Regardons maintenant FTP. En fonctionnement habituel, FTP utilise deux connexions TCP : une pour contrôler la session FTP, l’autre pour transmettre les données. Une session complète ressemble à cela :

• ouvrir la connexion de contrôle
• attendre l’acquittement du serveur
• envoyer l’utilisateur, attendre l’acquittement du serveur
• envoyer le mot de passe, attendre l’acquittement du serveur
• envoyer le type de transfert, attendre l’acquittement du serveur
• ouvrir la connexion de donnée
• envoyer le fichier
• fermer les connexions

Comme cela est visible, le protocole FTP demande d’attendre au moins quatre acquittements de l’extrémité distante. Pour TCP, des acquittements supplémentaires sont nécessaires, leur nombre exact dépendant de la négociation des paramètres et de la taille du fichier. En GPRS, la latence peut atteindre 1 s (dans le pire des cas). Dans notre exemple, cela signifie 5 s seulement pour attendre les acquittements.

Par conséquent, le temps total de communication (transmission des donnée et acquittements) peut atteindre 15 s.

Si un protocol binaire (même un très simple) avait été choisi, afin de réduire le volume de donnée et de minimiser le nombre de messages dans le sens descendant, le temps de communication aurait pu être réduit à trois ou quatre secondes. Et la consommation d’énergie aurait été réduite en conséquence.

Conclusion

Une faible consommation était très importante, dans ce projet. La conception matérielle répondait à cette exigence. Mais comme l’équipe de conception n’était pas assez expérimentée en développement logiciel, elle a décidé de sous-traiter cette partie. Elle n’a pas réalisé que cela pouvait impacter la consommation d’énergie, selon l’implémentation choisie par le sous-traitant. Et le sous-traitant a choisi la solution la plus simple pour lui : stocker les données en format CSV, et utiliser la pile FTP fournie avec le module de communication. L’économie d’énergie provenant de la conception matérielle est en partie neutralisée (ou peut-être totalement neutralisée, voire pire) par la couche logicielle.