Comme je l’ai écrit dans un autre article, une des caractéristiques des projets IoT est qu’ils demandent l’intégration de blocs techniques provenant de trois domaines différents : électronique, communication et logiciel. Et dans chacun de ces trois domaines, différents sous-domaines sont souvent impliqué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.
C’est pour cela qu’il est presque impossible, lorsque l’on développe un nouveau système, de se reposer uniquement sur des blocs techniques déjà développés en propre, ou que vous utilisez depuis longtemps : vous avez à intégrer de nouveaux composants de provenance externe. Et souvent vous allez découvrir que la documentation fournie ne dit pas tout à propos des caractéristiques des composants, et de leur comportement.
Il y a plusieurs moyens de réduire les risques et de réduire le temps de développement, malgré ces différences entre les spécifications et la réalité. Parmi eux, j’ai l’habitude de reposer au moins sur les trois suivants :
- pour chaque composant que je ne connais pas encore, je réalise des tests destinés à comprendre comment le composant réagit
- quand il est mal utilisé (par exemple, pour un module de communication : commandes mal formattées, demande de connexion à un serveur distant non existant, etc.)
- quand il est surchargé (par exemple, toujours pour un module de communication : transmission de messages au plus haut débit possible, pendant la réception de messages au plus haut débit possible)
- je conserve les environnements de test associés pendant toute la durée du projet, de telle façon à ce qu’en cas de problème avec le système en cours de développement, je puisse utiliser ces environnements comme références
- au niveau logiciel, j’implémente d’abord la gestion des conditions anormales (par exemple : tamponnage des données sur perte de connectivité, remise à zéro du récepteur GNSS s’il se fige, etc.) L’architecture matérielle doit bien supporter cela (par exemple : le microcontrôleur de l’équipement doit être capable de contrôler la patte de remise à zéro du récepteur GNSS)
Respecter ces recommandations ralentit le début de projet, mais cela permet l’élimination de tant de problèmes qui sinon ne seraient apparus qu’à la fin du projet ou, encore pire, sur le terrain, que le bilan est très positif.
Bien sûr, ces recommandations peuvent également s’appliquer aux composants développés en interne. Et aux projets uniquement logiciels.