Conception d'un modèle d'estimation de la consommation énergétique pour un système embarqué IoT

Année académique 2020-2021
Travail de fin d’études
Conception d'un modèle d'estimation
de la consommation énergétique pour
un système embarqué IoT
Présenté par
Verhulst Pierre
En vue de l’obtention du grade de
Master en sciences de l'Ingénieur
orientation Electronique

2
Remerciements
Par ces quelques mots, je souhaite adresser mes remerciements à toutes les personnes qui
m’ont soutenu et aidé dans la réalisation de ce travail de fin d’études.
Tout d’abord, je tiens à remercier Monsieur Geoffrey Ottoy et Madame Liesbet Van der Perre
qui m’ont permis de travailler sur le projet IWAST au sein du centre de recherche DRAMCO.
Leurs conseils et leur écoute m’ont énormément aidé lors de mon stage. Grâce à eux, j’ai eu la
possibilité d’étendre mes connaissances dans le domaine riche des systèmes IoT.
De même, je souhaite remercier tout particulièrement Madame Laurence Baclin. En tant que
maître de stage institut, elle a toujours été présente pour m’accompagner lors de ce travail.
Ces nombreux conseils et sa disponibilité ont permis d’améliorer grandement la qualité de ce
rapport.
J’adresse mes sincères remerciements à toute l’équipe derrière le centre de recherche
DRAMCO, notamment Monsieur Jona Cappelle et Monsieur Gilles Callebaut. Leur accueil et
l’aide qu’ils ont pu m’apporter ont été essentiels dans le cadre de mon stage.
Un grand merci à Madame Stéphanie Eggermont qui m’a permis d’entrer en contact avec le
centre de recherche DRAMCO.
Enfin, je voudrais remercier mes parents ainsi que le reste de ma famille. Leur soutien durant
ces cinq années d’études m’a permis d’arriver au terme de cette formation enrichissante pour
mon avenir.

4
Table des matières
INTRODUCTION.............................................................................................................................................. 6
CHAPITRE 1 - LA PROBLEMATIQUE ENERGETIQUE DE L’IOT........................................................................... 8
1.1 L’INTERNET DES OBJETS ............................................................................................................................. 9
1.2 LA CONSOMMATION DES SYSTEMES EMBARQUES........................................................................................... 10
1.3 LA PROBLEMATIQUE ENERGETIQUE ............................................................................................................. 12
1.4 PROPOSITION DE SOLUTION ...................................................................................................................... 14
CHAPITRE 2 - ILLUSTRATION DE LA PROBLEMATIQUE ................................................................................. 17
2.1 LE PROJET IWAST .................................................................................................................................. 18
2.2 LA TECHNOLOGIE LORA® ET SA CONSOMMATION .......................................................................................... 20
2.3 LA SOLUTION ADAPTEE A IWAST............................................................................................................... 26
2.4 CAHIER DES CHARGES DE LA SOLUTION ........................................................................................................ 28
CHAPITRE 3 - MISE EN ŒUVRE DE LA SOLUTION ......................................................................................... 30
3.1 ÉLABORATION DU MODELE D’ESTIMATION ................................................................................................... 31
3.1.1 Analyse de la consommation statique .......................................................................................... 32
3.1.2 Analyse des tâches dynamiques communes ................................................................................. 34
3.1.3 Analyse des tâches dynamiques de communications.................................................................... 36
3.1.4 Le modèle complet........................................................................................................................ 41
3.2 LES MESURES D’ENERGIES DU SYSTEME IWAST ............................................................................................ 44
3.2.1 L’outil de mesure........................................................................................................................... 44
3.2.2 Méthodologie................................................................................................................................ 45
3.3 DEVELOPPEMENT DE L’APPLICATION ........................................................................................................... 45
3.3.1 Amélioration de l’ancienne version............................................................................................... 46
3.3.2 Implémentation du modèle d’estimation...................................................................................... 47
CHAPITRE 4 - RESULTATS ET ANALYSE CRITIQUE ......................................................................................... 50
4.1 RESULTATS DES MESURES D’ENERGIES ......................................................................................................... 51
4.1.1 Validation des hypothèses ............................................................................................................ 51
4.1.2 Évaluation de la consommation statique...................................................................................... 53
4.1.3 Rectification sur le modèle d’estimation....................................................................................... 54
4.2 ÉVALUATION DE LA PRECISION DE L’ESTIMATION............................................................................................ 56
CONCLUSION................................................................................................................................................ 60
TABLE DES ILLUSTRATIONS........................................................................................................................... 62
BIBLIOGRAPHIE ............................................................................................................................................ 65
ANNEXES...................................................................................................................................................... 67
A.1 METHODES DE CONCEPTIONS ECONOMES .................................................................................................... 67
A.2 LA MOTHERBOARD ................................................................................................................................. 69
A.3 LES SENSOR BOARDS ............................................................................................................................... 74
A.4 LA CONFIGURATION IWAST ..................................................................................................................... 83
A.5 COMPLEMENT SUR LES TACHES DYNAMIQUES COMMUNES .............................................................................. 85
A.6 RESULTAT COMPLET D’UNE ESTIMATION ...................................................................................................... 89
A.7 SOMMAIRE DU RAPPORT DES MESURES DE PUISSANCES .................................................................................. 91

Introduction 6
Introduction
De nos jours, les perspectives offertes par le domaine de l’Internet des objets (IoT) sont
colossales. L’adoption de ce type de technologie prend de plus en plus d’ampleur dans de
nombreux domaines. Tous les secteurs d’activité sont touchés au regard du déploiement
important des capteurs liés à cette technologie [1]. De nombreuses entreprises à travers le
monde sont déjà dans l’ère de l’industrie 4.0 et l’IoT représente un pilier majeur de cette
révolution. La combinaison de ces nouveaux réseaux avec le développement de l’intelligence
artificielle représente un nouveau défi technologique pour les Ingénieurs.
Dans ce contexte, la problématique de la consommation énergétique est cruciale. La majeure
partie de ces dispositifs est conçue pour être autonome tout au long de leur durée de vie. Ils
sont donc équipés de batteries. La maîtrise de la consommation énergétique est un élément
essentiel lors du développement de tels produits. Le but est de proposer des circuits
électroniques ayant une consommation beaucoup plus faible par rapport aux systèmes
embarqués habituels. Le respect de cet objectif s’accompagne d’une difficulté supplémentaire
vis-à-vis de l’évaluation énergétique. En effet, la mesure de courant très faible est plus délicate
à mettre en place et requiert l’emploi d’outils spécifiques. Cette évaluation est pourtant
essentielle pour déterminer le type et la capacité de la batterie.
Ainsi, l’enjeu énergétique des systèmes IoT présente deux facettes. La première se focalise sur
la conception et les méthodes employées pour atteindre une diminution drastique de la
consommation. La seconde se concentre sur le bilan énergétique et les méthodes nécessaires
pour y parvenir. Cet aspect représente le point d’attention de ce travail, il prend en compte la
mesure des faibles consommations de courant ainsi que la gestion des événements
imprévisibles qui peuvent survenir. Ce travail constitue une synthèse de ces deux aspects en
les illustrant au travers de l’étude énergétique d’un système IoT.
Développé au sein du centre de recherche DRAMCO,
IWAST (Fig. 1) est un projet STEM dont l’objectif est de
faire découvrir le monde de l’IoT auprès des plus jeunes.
Il est conçu pour accompagner des séances de
découvertes organisées dans les écoles de
l’enseignement secondaire de Belgique. Il s’inscrit donc
parfaitement dans la dynamique actuelle vouée à la
compréhension et au développement des objets
connectés.
Fig. 1 Le projet IWAST du centre de
recherche DRAMCO

Introduction
7
Ce projet pédagogique inclut toutes les caractéristiques que l’on peut rencontrer face à un
produit IoT. Sa consommation énergétique doit être minime et doit correspondre aux valeurs
standards des systèmes du même domaine. Cependant, la première version de IWAST ne
remplissait pas les exigences attendues. Des actions correctives menées en majeure partie par
les chercheurs de DRAMCO et un modèle d’évaluation ont été développés pour répondre au
problème soulevé. La suite de ce travail se focalise sur la problématique évoquée
précédemment au travers d’une réflexion sur la consommation de la seconde version du
projet IWAST. L’analyse et l’élaboration de la solution retenue pour ce projet spécifique
illustrent parfaitement la problématique énergétique globale des objets IoT.
Tout d’abord, le premier chapitre permet d’exposer les éléments principaux de la question
énergétique en lien avec l’IoT. Afin de clarifier le sujet, une brève introduction sur l’Internet
des Objets est présentée suivie par un passage théorique sur la consommation des systèmes
embarqués. Bien entendu, l’élément important de ce chapitre correspond à la description de
la problématique globale de la consommation énergétique de l’IoT. Afin d’y répondre,
plusieurs solutions sont évoquées dans la dernière partie de cette section.
Ensuite, le chapitre Illustration de la problématique propose d’explorer les aspects du
problème général au travers d’un exemple concret. Le projet IWAST ainsi que la technologie
LoRa® utilisée dans ce cadre y sont définis. Afin d’approfondir le sujet, des détails sur la
variation de la consommation en énergie lors de l’envoi des messages LoRa® sont présentés
par après. Les solutions évoquées dans le premier chapitre et adaptées au projet IWAST sont
décrites à la fin de ce chapitre.
Après cela, le troisième chapitre décrit la mise en œuvre de la solution adaptée à IWAST. Cette
partie a pour objectif d’expliquer au mieux la logique de la solution choisie. Elle consiste à
développer un modèle d’évaluation de la consommation basée sur des mesures de courants
effectuées à partir d’un outil de mesure externe. Le modèle est spécifique au système IWAST,
mais la méthodologie de mesures et les choix réalisés lors du déploiement de la solution font
partie de la méthodologie générale établie à la fin du premier chapitre.
Le quatrième chapitre inclut les résultats et les analyses critiques. Les hypothèses établies
dans le chapitre précédent sont vérifiées. Ce chapitre permet également de réaliser un
commentaire critique sur les pistes de solutions générales évoquées dans le premier chapitre
et utilisées dans le cadre du projet IWAST.
Enfin, la conclusion revient sur l’analyse de la problématique et sur la solution adoptée dans
le cadre de ce projet. On y évoque également différentes pistes pour aller plus loin dans
l’étude de la consommation énergétique des objets IoT.

Chapitre 1 - La problématique énergétique de l’IoT 8
Chapitre 1 - La problématique énergétique de l’IoT
Ce chapitre a pour objectif de présenter la problématique énergétique de l’IoT traitée
dans le cadre de ce travail. Plusieurs notions sont néanmoins nécessaires pour comprendre les
enjeux de cette problématique. Ainsi, la première partie aborde brièvement le concept d’IoT et
ses implications au sein de notre société. La seconde partie, plus théorique, se concentre sur la
consommation énergétique des systèmes embarqués et ce que cela implique dans le cadre des
objets connectés IoT. Il est important de bien assimiler les éléments qui définissent la
consommation énergétique des systèmes embarqués autonomes afin de comprendre les
différents aspects de la problématique.
La suite concerne les aspects principaux de la problématique énergétique de l’IoT. Les
différentes difficultés sont ainsi exposées. Ce chapitre se conclut par la proposition de
différentes pistes dans une optique de résolution de la problématique.

9
1.1L’Internet des Objets
La tendance à l’automatisation et le passage au traitement de l’information par les
plateformes numériques ont permis l’émergence du concept d’Internet des Objets (Internet
of Things dans sa dénomination anglaise). L’apparition du terme « IoT » est attribuable à Kevin
Ashton [2]. En 1997, il travaillait chez Procter et Gamble sur un système RFID dont
l’écosystème allait poser les bases principales des objets connectés IoT. Le terme, autrefois
considéré comme futuriste, s’est aujourd’hui imposé dans notre société toujours plus
connectée. Au moment d’écrire ces lignes, le passage imminent à la technologie de
communication 5G devrait permettre à l’Internet des Objets de passer un nouveau cap dans
son histoire. La croissance exponentielle du nombre d’objets connectés qui en découlerait
place les ingénieurs au-devant d’un défi colossal.
Plusieurs définitions peuvent être données pour ce concept. Selon l’article de recherche [3] :
« L'internet des objets renvoie à l'idée générale de choses, en particulier d'objets
du quotidien, qui sont lisibles, reconnaissables, localisables, adressables par des
dispositifs de détection d'informations et/ou contrôlables via l'internet, quel que
soit le moyen de communication »
K. K Patel et al., Internet of Things-IOT: Definition, Characteristics, Architecture,
Enabling Technologies, Application & Future Challenges
Concrètement, les éléments de bases [2] qu’un produit doit posséder pour être considéré
comme un objet IoT sont les suivants :
• l’objet doit être capable sur le plan informatique de gérer un protocole de
communication Internet ;
• le matériel doit pouvoir utiliser une plateforme de transport réseau (802.3, LoRa®,
Sigfox, etc.) ;
• le produit ne doit pas faire partie des objets connectés traditionnels tels que les
ordinateurs portables, les smartphones, les serveurs, les appareils propres au Data
Center, les machines de bureau (ex : imprimantes connectées) ou plus récemment les
tablettes.
De nombreux secteurs utilisent aujourd’hui les technologies IoT. Ainsi, le secteur industriel a
déjà introduit massivement les méthodes de l’industrie 4.0. De l’autre côté, l’IoT connaît une
croissance importante dans d’autres domaines : la finance et le commerce, les soins de santé,
le transport et la logistique, l’agriculture et l’environnement, l’énergie, la gestion des villes
(apparition du concept de Smart City) ou encore le domaine militaire.

1.2La consommation des systèmes embarqués
Avant d’aborder la consommation énergétique des systèmes embarqués, il est
intéressant de définir correctement ce que cette appellation désigne. Selon le livre de
référence « Introduction to Embedded Systems » [4], on définit un système embarqué de cette
façon :
« Un système embarqué peut être défini, de façon générale, comme un dispositif
contenant des composants matériels et logiciels étroitement couplés pour exécuter
une seule fonction, qui fait partie d’un système plus vaste, qui n’est pas destiné à
être programmé indépendamment par l’utilisateur et qui est censé fonctionner
avec une interaction humaine minimale ou nulle »
M. Jiménez et al., Introduction to Embedded Systems
De nombreux éléments de notre vie quotidienne sont considérés comme des systèmes
embarqués. À titre d’exemple, une simple calculatrice contient un système embarqué
permettant d’effectuer les opérations arithmétiques. On peut classer les systèmes embarqués
modernes en trois catégories :
• les petits systèmes embarqués (ex. : système de contrôle de pression des pneus,
contrôleur de four à micro-onde, électronique de jouets, etc.) ;
• les systèmes embarqués distribués (ex. : contrôleur de jeux vidéo, enregistreur de
données, processeur réseau, etc.) ;
• les systèmes embarqués haute-performance (ex : caméra haute définition spécialisée
dans les ralentis (utilisant un système FPGA), système à base de puces ASICS, etc.).
Ce classement n’est pas dénué d’intérêt d’un point de vue énergétique. En effet,
l’appartenance d’un système à une de ces catégories permet d’avoir un ordre de grandeur en
termes de consommation. De façon relativement triviale, un petit système embarqué
consomme beaucoup moins d’énergie qu’un système haute-performance. On peut
résolument placer les systèmes IoT dans la catégorie des petits systèmes embarqués. En effet,
ils sont pour la plupart construits autour d’un microcontrôleur devant assumer des tâches
relativement simples. Dès lors, la compréhension de la consommation énergétique des
microcontrôleurs est essentielle pour évaluer la consommation des systèmes IoT.
De façon générale, un microcontrôleur est un circuit intégré équipé de plusieurs périphériques
rassemblant les éléments essentiels comme la mémoire, le processeur, les unités
périphériques ou les ports d’entrée/sorties. La figure Fig. 2 représente la structure du
PIC16F18446 utilisé dans le cadre du projet IWAST. On peut distinguer aisément le processeur
principal (le CPU) accompagné de l’ensemble des périphériques. Par rapport aux
microprocesseurs utilisés dans nos ordinateurs, les microcontrôleurs ne sont pas

11
spécialement conçus pour traiter des opérations arithmétiques complexes. Par contre, ils ont
la possibilité d’agir plus facilement sur le monde extérieur au moyen de circuiteries d’interface
liées aux périphériques [5]. Le boitier est assez simple (voir les exemples Fig. 3) et peut
s’intégrer facilement au sein de systèmes embarqués plus complexes. C’est cette dernière
caractéristique qui a permis aux microcontrôleurs de s’imposer dans de nombreux produits.
Le code implémenté dans le microcontrôleur est appelé « micrologiciel » [6]. Il permet de
programmer les différents registres et de définir la routine principale du composant.
Concernant la consommation énergétique, la puissance consommée par les microcontrôleurs
peut être divisée en deux catégories : la puissance statique et la puissance dynamique [7].
Fig. 2 Organisation du microcontrôleur PIC16F18446 Fig. 3 Exemples de microcontrôleurs PIC
La puissance statique correspond à la puissance consommée lorsque la routine (le code à
l’intérieur du microcontrôleur) n’est pas active. Elle désigne donc les situations où le
microcontrôleur est placé dans une sorte de mode « veille ». Dans ce mode, l’horloge
principale est désactivée et la majeure partie de la consommation provient des fuites de
courant des transistors utilisés pour la régulation interne de la tension [8]. Néanmoins,
l’adoption de la technologie CMOS a permis de réduire fortement la consommation de
courant des fuites en question (le courant de fuite est proche de zéro avec ce type de
transistors [9]). La puissance statique englobe également l’énergie nécessaire pour maintenir
le système en « veille ». Il s’agit souvent de maintenir certains périphériques essentiels
comme le « WatchDog Timer » (WDT), la « Real Time Clock » (RTC) ou encore le « Brown-Out
Reset » (BOR). Même si elle peut paraître négligeable au vu de sa faible intensité, la prise en
compte de cette puissance est importante. En effet, les systèmes conçus pour fonctionner sur
batterie passent une majeure partie de leur temps en mode « veille ».
La puissance dynamique représente le complément de la puissance statique. Elle correspond
à la puissance consommée lorsque le programme interne s’exécute, on effectue les opérations
normales pour lesquelles le système est programmé. Concrètement, le fonctionnement
normal inclut la puissance induite par la commutation des transistors CMOS et des courants
de polarisations [7]. Cela concerne uniquement les périphériques utilisés par l’application. La

puissance dynamique est principalement influencée par la fréquence de l’horloge. Avec une
fréquence élevée, on peut effectuer plus d’opérations en moins de temps, mais on consomme
plus d’énergie. C’est pour cette raison que le choix de la fréquence d’horloge est essentiel
pour contrôler la puissance dynamique [8].
Les fiches techniques des microcontrôleurs permettent de connaître en détail la
consommation électrique associée à chaque périphérique. Malgré tout, des mesures en
conditions réelles restent plus fiables si l’on souhaite des valeurs précises. En effet, le code
constituant la routine du microcontrôleur influence la consommation de celui-ci. Dès lors, les
données des fiches techniques atteignent rapidement leurs limites. Plusieurs méthodes sont
possibles en fonction du degré de précision que l’on souhaite. On peut imaginer utiliser un
ampèremètre suffisamment précis pour mesurer la consommation de courant globale de
l’ensemble du microcontrôleur. D’autre part, on peut envisager des systèmes plus pointus
mesurant la consommation spécifique à chaque instruction de type assembleur. Cette
dernière option requiert néanmoins un banc de test plus perfectionné [10] si l’on souhaite
atteindre la précision requise.
1.3La problématique énergétique
Dans ce travail, on considère la durée de vie d’un système autonome comme étant sa
durée de fonctionnement sur un cycle de la batterie. En d’autres termes, il s’agit de la durée
de fonctionnement nominal entre le moment où la batterie est complètement chargée et le
moment où celle-ci ne possède plus assez d’énergie pour assurer un fonctionnement normal
du système. Les systèmes IoT autonomes sont conçus de façon à présenter une durée de vie
beaucoup plus longue par rapport aux autres appareils connectés. Cela se confirme par le fait
que l’on exprime régulièrement leur durée de fonctionnement en mois (parfois en année pour
certaines applications). Cette durée dépend de la façon dont le système consomme l’énergie
au cours du temps. La maîtrise de cette consommation est donc cruciale et doit être prise en
compte lors des phases de développement. Le système doit donc présenter une
consommation minimale tout en assurant efficacement l’ensemble des tâches qui lui sont
attribuées. C’est le premier aspect de la problématique :
Comment atteindre une consommation énergétique minimale du système tout en
respectant les exigences fonctionnelles de celui-ci ?
De même, le choix de la batterie fait partie de la problématique. On pourrait répondre
facilement à cet élément en choisissant la plus grosse batterie disponible sur le marché.
Évidemment, cette option n’est pas envisageable étant donné la taille minime que de tels
systèmes doivent présenter. Le dilemme réside dans le fait que l’on souhaite un système dont
la taille est très petite, mais avec une autonomie très grande. Il faut donc réaliser un

13
compromis entre la taille du système et son autonomie. Dès lors, une évaluation de la
consommation énergétique est nécessaire afin de faire les bons choix.
Pour un système embarqué lambda, il est assez trivial d’obtenir une évaluation de ses
performances énergétiques. En effet, la valeur de la puissance mesurée (en Watts) et la valeur
de l’énergie consommée (en Joules) peuvent se déterminer via les formules très simples :
! = # . &
!'()* [,] = #'./01) [#] . 23**)4/ [5]
6 = ! . 7
64)*18 [9] = !'()* [,] . 7:;) [<]
Étant donné la tension d’alimentation fixe qui caractérise les systèmes embarqués, la
détermination de la puissance peut se réaliser à partir de la mesure du courant consommé
par le système. C’est sur cette étape de mesure qu’un problème intervient dans le cadre des
objets IoT. En effet, les systèmes embarqués actuels peuvent présenter des consommations
de courant infinitésimales. On se situe dans des grandeurs de l’ordre du μA (voir du nA pour
les systèmes les plus économes). C’est une caractéristique importante pour la diminution de
la consommation, mais c’est également un obstacle pour la mesure. En effet, il est beaucoup
plus difficile de mesurer des courants de cet ordre. Un simple ampèremètre n’est pas valable,
il faut des équipements et des méthodes spécifiques.
D’autre part, la majeure partie des applications de l’IoT présente des événements
imprévisibles liés aux interactions des systèmes avec l’extérieur (ex. : détection du son, appui
sur un bouton, etc.). Ces événements présentent des consommations de courants non
négligeables qui influencent la consommation globale du système. Il est donc impossible de
prédire avec exactitude l’énergie totale consommée par un système IoT pour une certaine
durée.
Tous ces éléments font partie du deuxième aspect de la problématique :
Comment évaluer précisément la consommation énergétique des systèmes IoT si
ceux-ci présentent des consommations de courant très faibles et des événements
imprévisibles ?

1.4Proposition de solution
Dans le cadre de cette problématique, il est difficile d’établir une solution unique pour
y répondre. En effet, les spécificités de chaque projet IoT doivent être prises en compte lors
de l’élaboration de la solution. Certains projets ne nécessitent pas de se focaliser sur l’énergie
dépensée alors que d’autres sont bloqués dans leur développement en raison d’une
consommation trop importante. Dans le cas où la consommation énergétique pose un
problème, il faut s’intéresser à plusieurs éléments :
• sur quels composants du système embarqué peut-on agir pour réduire la
consommation énergétique ?
• quel type de batterie et quelle capacité peut-on choisir ? Quelle est la limite ?
• quelles sont les fonctionnalités nécessaires pour que le système remplisse les tâches
pour lesquelles il a été conçu ?
• quels sont les événements qui peuvent entrainer une réaction du système (et donc
amener à une certaine consommation) ?
Ces questions générales doivent se poser au début de l’analyse énergétique du projet. Par la
suite, on peut commencer à répondre aux deux aspects de la problématique. Dans le cadre de
ce travail, plusieurs pistes ont été explorées pour arriver à une méthodologie (Fig. 4)
répondant à la problématique. Les deux aspects (la diminution de la consommation et
l’évaluation énergétique) sont traités indépendamment. Différentes solutions sont
envisagées.
Fig. 4 Solutions envisagées en réponse à la problématique énergétique de l'IoT

15
Pour la diminution de la consommation, deux solutions peuvent être envisagées. La première
solution consiste à réaliser une analyse Software du micrologiciel implémenté dans le
microcontrôleur. L’impact du code de la routine sur la consommation énergétique est très
important. En effet, la routine définit les actions à effectuer au cours du temps. Il est donc
nécessaire d’adopter un ensemble de principes (l’annexe A.1 reprend en détail l’ensemble des
principes) lorsque l’on code un système destiné à consommer très peu d’énergie :
• désactiver les périphériques inutilisés et activer les autres seulement au moment où la
routine les requiert ;
• choisir une horloge interne adaptée à l’application et plus économe ;
• activer les modes « veille » dès que cela est possible ;
• utiliser un code basé sur des interruptions.
La seconde solution, l’analyse Hardware, consiste à étudier en détail la version actuelle du
circuit électronique. Cela permet de déterminer les éléments gourmands en énergies et peut
amener à modifier l’architecture. Pour les composants, plusieurs alternatives assurant la
même fonction peuvent exister. En général, un circuit intégré de fabrication plus récente
utilisera une famille technologique plus économe (ex. : passage du TTL au CMOS). L’analyse
Hardware peut aussi déboucher sur une refonte complète du circuit électronique en cas de
nécessité.
Pour l’évaluation énergétique, deux solutions sont envisageables. L’option la plus précise
consiste à implémenter un système de mesure du courant en temps réel directement dans le
système embarqué. Cet élément doit se placer, dans l’idéal, entre la batterie et le reste du
système embarqué. La difficulté principale de cette méthode est liée aux variations
importantes que les valeurs de courant peuvent présenter dans le cadre des systèmes IoT. En
général, il faut un système capable de mesurer précisément des courants allant de 1 nA
jusqu’à 100 mA. Plusieurs méthodes sont possibles pour y parvenir, on peut citer :
• l’utilisation d’un capteur de courant à base de résistances Shunt dont les valeurs sont
calibrées en fonction de l’ordre de grandeur des courants [11] ;
• l’utilisation d’un capteur basé sur une unité d’accumulation à base de condensateur
[10] (pour la mesure de courants très faible).
L’avantage de cette méthode est que l’on obtient une mesure réelle et précise de la
consommation. Cependant, ce procédé est intrusif. Il faut veiller à ne pas perturber le bon
fonctionnement du système embarqué. De même, son utilisation nécessite l’ajout d’une
alimentation spécifique. En effet, ce système de mesure consomme également une certaine
quantité d’énergies, il ne faut pas que celle-ci soit reprise dans le décompte final de l’énergie
consommée par le système IoT.

L’autre option consiste à élaborer un modèle d’estimation. Sa conception nécessite une étape
d’analyse importante (Software et Hardware) afin de comprendre parfaitement chaque
élément du système embarqué. Sur base de cette étude, un modèle peut être établi afin
d’évaluer la consommation complète. Afin de calculer la consommation totale, des valeurs de
courant précises doivent être incorporées dans le modèle. On peut les acquérir de deux
façons :
• on se base sur les données contenues dans les fiches techniques. Cette option est
efficace pour les petits composants électroniques dont la consommation ne présente
pas de variations importantes. À l’inverse, cette solution est moins pertinente pour les
microcontrôleurs dont la consommation dépend principalement du micrologiciel ;
• on se base sur des mesures de courants réalisées à l’aide d’un appareil de mesures
adapté aux systèmes embarqués IoT. Le choix de cette option implique évidemment
d’utiliser un appareil calibré et une certaine fiabilité.
Le caractère non intrusif de cette méthode est un avantage conséquent. Cependant, le
résultat final se limite à une estimation dont la précision dépend des mesures effectuées par
un dispositif externe.
Au final, l’évaluation énergétique doit permettre de dresser un profil de puissance (Fig. 5) du
système embarqué IoT. On peut ainsi connaître la consommation des différents éléments qui
composent le dispositif. En plus de fournir des informations sur l’autonomie et sur le choix de
la batterie, cela permet de déterminer les points où des mesures correctives doivent être
prises.
Fig. 5 Exemple de profil de puissance

Chapitre 2 - Illustration de la problématique
17
Le chapitre qui suit a pour objectif d’illustrer les concepts introduits au chapitre
précédent au travers d’un projet réalisé dans le cadre d’un stage de fin d’études. Son lien avec
l’Internet des Objets et ses défauts en termes de consommation énergétique en font un
exemple idéal dans le cadre de la problématique énergétique IoT.
Ainsi, la première partie de ce chapitre se focalise sur la description des éléments principaux
qui définissent le projet IWAST. Les annexes comportent plus de détails sur les éléments du
projet.
La deuxième part de ce chapitre est consacrée à la technologie LoRa® et son protocole
LoRaWAN®. C’est le protocole de télécommunication utilisé par le projet IWAST. Dans le cadre
de la problématique énergétique IoT, il est essentiel de comprendre la façon dont les données
sont transmises. L’énergie nécessaire à ces communications représente une part importante
de la consommation globale du dispositif IoT. Cette partie permet donc de comprendre le lien
entre les différentes étapes de la transmission des données et l’énergie consommée.
La dernière partie de ce chapitre est consacrée à la solution choisie pour le projet IWAST. On y
décrit les raisons qui ont conduit au choix de l’élaboration d’un modèle d’estimation. Par la
suite, une description des exigences de la solution est développée dans un cahier des charges
succinct.

Chapitre 2 - Illustration de la problématique 18
2.1Le projet IWAST
Aujourd’hui, de nombreuses initiatives portant l’abréviation « STEM » font leur
apparition dans nos écoles. Cette abréviation anglaise qui signifie « Science, Technology,
Engineering and Mathematics » [12] désigne avant tout une philosophie d’apprentissage, on
parle d’ailleurs assez couramment de « STEM Education ». Ces différents projets ont pour
objectif commun d’apporter à un public jeune (souvent dans la tranche des 10-18 ans) un
ensemble de connaissances jugées essentielles dans les quatre domaines qu’ils couvrent. Les
étudiants sont ainsi dotés de compétences leur permettant de proposer des solutions
créatives aux nombreux problèmes qu’ils peuvent rencontrer. C’est également un excellent
moyen pour susciter des vocations vers des secteurs qui peinent aujourd’hui à trouver les
profils recherchés [13].
C’est dans ce cadre que l’on peut inscrire le projet IWAST dont l’abréviation signifie « IoT With
A Soft Touch ». Il est développé par le centre de recherche DRAMCO situé sur le campus
technologique de Gand de l’université KULeuven. Son objectif principal est de faire découvrir
aux étudiants des écoles secondaires le domaine de l’IoT et des systèmes embarqués en
général. Les quatre dernières lettres de son abréviation (With A Soft Touch) reflètent la
caractéristique principale du système. En effet, contrairement à d’autres plateformes
embarquées IoT, il n’est pas nécessaire de posséder des notions avancées en électronique
pour réussir à configurer et mettre en marche le dispositif. Cet aspect est capital si l’on désire
attirer l’attention d’un public suffisamment jeune.
Concrètement, le projet IWAST est un système
modulable composé de plusieurs cartes électroniques
de forme hexagonale (Fig. 6). Plusieurs fonctionnalités
sont offertes en fonction de la configuration choisie
par l’utilisateur. On peut citer notamment la mesure
de la température ambiante, la mesure du bruit
ambiant, la mesure de la luminosité, etc.
Fig. 6 Le système IWAST
Par rapport à d’autres systèmes, IWAST est conçu pour simplifier l’intégration de l’ensemble
des capteurs à des fins éducatives. Les données acquises par le système peuvent être
récupérées grâce au réseau sans fil LoRa®. C’est cette caractéristique essentielle qui reflète
l’implémentation du système dans un réseau de type IoT.
IWAST est un projet open source. L’ensemble des codes du projet est disponible sur la
plateforme de collaboration en ligne GitHub. On y trouve également les schémas électriques
des différents modules et toutes les informations (techniques ou non) nécessaires pour
comprendre le fonctionnement et la configuration du système.

19
À ce jour, deux écoles secondaires de Flandre ont déjà collaboré avec le centre de recherche
pour une première phase de test. Celle-ci a permis de démontrer d’importants problèmes en
termes de consommation d’énergie dans la première version du système. Le projet étant
toujours en cours de développement, la seconde phase de test impliquera également ces deux
écoles secondaires. Par la suite, lorsque l’ensemble de la plateforme embarquée sera
suffisamment stable, le nombre de collaborations devrait significativement augmenter.
Concernant le fonctionnement du dispositif, le système embarqué IWAST se compose de
plusieurs éléments de forme hexagonale. L’élément primordial du dispositif est la carte mère
que l’on nomme par sa dénomination anglaise : Motherboard (l’annexe A.2 décrit en détail le
fonctionnement de cette carte). Cette carte est indispensable pour le bon fonctionnement du
dispositif complet. Il est en effet possible d’y relier jusqu’à six autres éléments du système :
les Sensor Boards (l’annexe A.3 décrit chacune de ces cartes de façon détaillée). Ces cartes
permettent au système de recueillir plusieurs types de mesures. Dans le cadre de ce travail,
les différents types de mesures effectuées par un capteur sont nommés « métrique » (cette
dénomination est spécifique au projet IWAST). Au stade actuel du projet, quatre types
différents de Sensor Boards existent :
• la carte Buttons : Elle permet de générer des signaux en appuyant sur un des
quatre boutons de la carte. Cette carte peut donc fournir un
seul type de métrique ;
• la carte Sound Level : Elle permet de générer un signal contenant la mesure du
bruit ambiant en décibel. Cette carte peut donc fournir un
seul type de métrique ;
• la carte Power Module : Cette carte n’est pas comme les autres Sensor Boards.
Elle permet d’assurer une alimentation complète du
système IWAST grâce à une batterie et une cellule
photovoltaïque. Elle peut également recueillir une
mesure de la luminosité ambiante et une mesure de la
tension de la batterie (qui reflète sa charge). Cette carte
peut donc fournir deux types différents de métrique ;
• la carte Air Quality : Elle permet de générer un signal contenant plusieurs
mesures. La carte peut mesurer la température ambiante,
l’humidité ambiante, la pression et la qualité de l’air1
. Cette
carte peut donc fournir quatre types différents de métrique.
1
La qualité de l’air est évaluée par la puce BME680. Elle permet de détecter de nombreux gaz : composés
organiques volatils (COV) provenant de peintures, laques, décapants, produits de nettoyage, produit de
l’ameublement, odeurs des équipements de bureau, des colles, des adhésifs et de l’alcool. En fonction de ce que
la carte détecte, elle fournit un niveau définissant la qualité de l’air. Plus le niveau est élevé, plus la qualité de
l’air sera médiocre.

Toutes ces cartes peuvent se connecter et communiquer avec la Motherboard grâce à un
système de connexion composé de six broches. On utilise un bus I2C comme protocole de
communication pour échanger les données entre les cartes.
Les données collectées sont ensuite envoyées sur un réseau IoT en utilisant la technologie
LoRa®. Le centre de recherche possède une passerelle LoRa® installée sur le toit de leur
bâtiment. C’est le réseau communautaire The Things Network (TTN) qui a été choisi comme
réseau LoRaWAN® afin de collecter et de visualiser les données envoyées par IWAST. Il a
l’avantage d’être un réseau open source et totalement gratuit. Sa large couverture à travers
le monde et sa grande communauté font de lui un réseau LoRaWAN® très important à l’heure
actuelle. Le chemin emprunté par les données recueillies par les Sensor Boards peut être
résumé de cette façon (Fig. 7) :
Fig. 7 Progression des données recueillies par les Sensor Boards
Lors de la première phase de test en situation réelle, le dispositif a présenté de nombreux
problèmes dont les conséquences ne peuvent être négligées. En effet, ces défaillances
compromettent les fonctions basiques du système, le rendant dès lors inutilisable. Les
diagnostics qui ont suivis ont rapidement permis de déterminer une des causes principales :
l’alimentation du système. La consommation semblait trop importante et la batterie ne
permettait pas de subvenir aux besoins. Ces problèmes représentent donc une illustration
parfaite de la problématique énergétique de l’IoT. La consommation de courant n’était pas
adaptée pour un système de type IoT (premier aspect) et aucun moyen ne permettait
d’évaluer précisément cette consommation (deuxième aspect).
2.2La technologie LoRa® et sa consommation
IWAST est un projet STEM destiné à introduire le concept d’Internet des Objets. La
communication des données recueillies vers Internet doit donc être assurée par un protocole
spécifique. Dans ce cadre, le centre de recherche a décidé d’utiliser la technologie LoRa® et
son réseau LoRaWAN® pour les transmissions.

21
La technologie LoRa® correspond à la couche physique développée par la société SEMTECH
pour connecter facilement des objets IoT à un réseau LoRaWAN®. Elle utilise une modulation
de type CSS (Chirp Spread Spectrum). Il est important de ne pas confondre le terme LoRa® qui
désigne la couche physique et le terme LoRaWAN® utilisé pour nommer le protocole réseau
LPWAN (Low Power Wide Area Network). Ce protocole de télécommunications permet donc
de créer des réseaux complets d’objets IoT. Ces réseaux sont basés sur une topologie en étoile
et sont organisés de cette façon (Fig. 8) :
Fig. 8 Architecture classique LoRaWAN®
On peut admettre que la technologie LoRa® utilise un protocole de type ALOHA. La
caractéristique principale de ce type de protocole est qu’il ne requiert aucune synchronisation
entre l’émetteur et le récepteur. Cela signifie donc que l’émetteur peut transmettre à tout
instant. Il ne se soucie pas des éventuelles collisions qui peuvent survenir sur le réseau [14].
Cette particularité simplifie grandement le modèle de consommation des transmissions
LoRa®.
Le protocole propose trois classes (A, B et C) pour définir la façon dont les messages sont
transmis. La classe A est la plus simple et propose la transmission la plus économe en termes
de consommation énergétique [15]. C’est pour cette raison qu’un grand nombre de systèmes
IoT utilisent la transmission LoRa® de classe A, notamment le système IWAST. Concrètement,
cette catégorie assure une simple communication bidirectionnelle entre le système IoT et la
passerelle LoRa®. Elle est composée de trois paquets (Fig. 9) :
• le premier correspond au message de transmission émis par le dispositif IoT. Il peut
survenir à tout instant en fonction de l’application définie par le dispositif ;
• les deux derniers correspondent aux messages de réponses envoyés par la passerelle
LoRa® et reçus par le dispositif IoT. Ceux-ci sont reçus après le message de transmission
selon deux délais prédéfinis et constants.

Fig. 9 Schéma de communication LoRa® de la classe A
Dans le cadre de la consommation d’énergie, la grandeur temporelle joue un rôle majeur. En
effet, l’énergie utilisée pour l’envoi et la réception des paquets varie en fonction du temps (E
= P x T). La détermination des durées de chaque paquet et des autres délais est donc
primordiale si l’on souhaite établir un modèle énergétique. Plusieurs paramètres propres à la
technologie LoRa® ont une incidence sur la temporalité :
• Spreading Factor (SF):
Le facteur d’étalement du spectre (« Spreading Factor » en anglais) caractérise le signal émis
par les appareils LoRa®. Il influence notamment la vitesse de transmission ainsi que la
consommation d’énergie utilisée pour l’envoi d’un message. Dans le cadre de la technologie
LoRa®, le facteur SF varie entre 7 et 12 et permet ainsi d’adapter le débit de données.
Chaque message est composé de plusieurs symboles représentant un ou plusieurs bits de
données. La valeur du facteur d’étalement du spectre SF équivaut au nombre de bits
représentés dans un symbole [16]. Ainsi, l’ensemble des valeurs possibles pour le symbole
vaut 2SF
(le symbole peut représenter une valeur comprise entre 0 et 2SF
-1). La période Ts
d’un symbole varie en fonction du facteur SF et de la bande passante BW. À partir de ces
explications, on peut définir plusieurs relations en lien avec le facteur SF:
!! =
2"#
%&
'! =
%&
2"#
!! : Période d’un symbole [s]
"# : Facteur d’étalement du spectre
$% : Bande passante [Hz]
'! : Taux de symbole [Hz]
'" : Nombre de pulsations par seconde [Hz]
'$ = '! . 2"#
(= %&) ↔ ,- = ./0% 1
'$
'!
2
Le choix d’un facteur SF plus élevé permet d’augmenter la distance entre l’émetteur LoRa®
et la passerelle. Cependant, l’énergie consommée est plus importante et le débit plus faible.

23
• Coding Rates (CR):
Comme pour tout autre protocole de communication, les signaux LoRa® ne sont pas
insensibles au bruit. L’approche adoptée pour répondre à ce problème est d’utiliser une
méthode de correction d’erreurs basée sur le principe du code de Hamming. Le taux de
codage (« Coding Rates » en anglais) permet de définir la distance n de la méthode de
correction. En d’autres termes, la distance n correspond à la capacité du code de Hamming
à détecter et corriger des erreurs [14]. On peut définir sa valeur n comme étant le nombre
de bits à modifier pour rendre la méthode de correction (ou de détection) d’erreurs
inefficace. Le taux de codage CR est lié à la distance n selon cette relation :
3' =
4
4 + 6
3' : Taux de codage
( : Distance du code de Hamming (entre 1 et 4)
La technologie LoRa® permet de sélectionner une distance allant de 1 à 4. On peut donc se
limiter à une simple détection d’erreur de type « Parity Check » (n=1) ou choisir une méthode
plus robuste permettant de détecter jusqu’à trois erreurs et de corriger un bit (n=4).
Avec ces deux paramètres, on peut définir le débit de données Rb correspondant au nombre
de bits envoyé par seconde (on l’appelle également « débit utile »). Il varie en fonction de la
bande passante BW, du facteur d’étalement du spectre SF et du taux de codage CR. Le choix
de la bande passante dépend du matériel utilisé (dépends principalement de la puce choisie
pour la communication LoRa®). Il est possible d’utiliser une bande passante de 125 kHz,
250kHz ou 500 kHz. Ce choix dépend de la réglementation en vigueur dans la région où le
système est implémenté.
'& = ,- .
%&
2"#
. 3' [89 ou <=>]
Ce taux a une influence directe sur l’énergie. En effet, un débit Rb plus élevé présente un temps
de transmission plus faible. Pour la technologie LoRa®, le facteur « temps de transmission »
présente un impact plus important sur la consommation énergétique que le facteur « débit
Rb ». Dès lors, l’impact énergétique d’une augmentation du débit est effacé par celui causé
par la diminution du temps de transmission. Augmenter le débit induit une diminution du
temps de transmission qui provoque une diminution de la consommation énergétique.
Si on analyse les relations précédentes, on peut émettre plusieurs affirmations par rapport au
choix des paramètres SF et CR :
• un facteur SF plus élevé ou un facteur CR avec une distance n plus élevée entraine
une diminution du débit de données Rb provoquant une augmentation du temps de
transmission. Cela implique donc une augmentation de la consommation
énergétique ;

• un facteur SF moins élevé ou un facteur CR avec une distance n moins élevée entraine
une augmentation du débit de données Rb provoquant une diminution du temps de
transmission. Cela implique donc une diminution de la consommation énergétique.
La taille des paquets transmis a également un impact sur la consommation d’énergie. Il est
assez trivial d’affirmer que les paquets contenant un grand nombre de données (donc plus de
bits) demandent plus d’énergie pour être transmis par rapport aux paquets moins volumineux.
La structure de ces paquets (Fig. 10) diffère légèrement en fonction du type de message
(transmission TX ou réception RX).
Fig. 10 Structures des paquets LoRa®
La taille nPre de la partie « Préambule » (utilisée pour la synchronisation entre la transmission
et la réception) varie en fonction de la région. En Europe, sa taille habituelle est de 8 symboles
[15]. La taille de la partie « Données utiles » varie évidemment en fonction du nombre de
données que l’on souhaite envoyer. En fonction des paramètres définis précédemment, on
peut déterminer la durée théorique nécessaire pour l’envoi des paquets TX à l’aide des
relations définies par la norme LoRa® [17] :
!'() = (6'() + 4,25) . !!
6'*+ = 8 + CDE FGHI. JK
8 . LM − 4 . ,- + 44 − 20 . 8
4 . (,- − 2 . PQ)
. (6,- + 4)R , 0ST
!'*+ = 6'*+ . !!
!! : Période d’un symbole [s]
!#$% : Période de la partie « Préambule » [s]
(#$% : Nombre de symboles de la partie « Préambule »
)* : Nombre d’octets représentant les données utiles
"# : Facteur d’étalement du spectre
+ : Facteur d’en-tête (= 0 si l’en-tête couche physique et l’en-tête CRC est activé / =1 sinon)
,- : Option « Low Data Rate Optimization » (=1 si l’option est activée / = 0 sinon)
(&' : Distance du code Hamming associé au taux de codage CR
!#() : Période des parties « en-tête », « données utiles » et « CRC données utiles » [s]
(#() : Nombre de symboles contenus dans les parties « en-tête », « données utiles » et « CRC données utiles »

25
Dès lors, la durée théorique 7!"# pour l’envoi des paquets TX (« Time on Air » en anglais)
équivaut à la somme des deux périodes précédentes :
!./( = !'() + !'*+ [>]
La détermination de l’énergie pour la transmission d’un message LoRa® ne se limite pas aux
trois parties du schéma de communication vu précédemment. Il faut également prendre en
compte d’autres éléments :
• une partie précédant le message de transmission TX et qui permet le « réveil » de
l’émetteur LoRa®. Les systèmes embarqués communiquant avec la technologie LoRa®
utilisent des cartes spécifiques pour émettre les messages. Il est courant de mettre ces
modules en mode « sommeil » lorsqu’ils ne sont pas utilisés. Il faut donc prendre en
compte une certaine part d’énergie nécessaire à leur réveil lorsque l’on souhaite
envoyer un message. On appelle cette partie « Wake-up Transceiver » ;
• les deux parties présentes entre les messages (entre TX - RX1 et entre RX1 - RX2)
doivent également être prises en compte. On appelle ces parties « Delay RX1 » et
« Delay RX2 ».
Avec l’ajout de ces trois parties, voici le profil de puissance auquel on peut s’attendre lors de
l’envoi d’un message LoRa® (Fig. 11) :
Fig. 11 Structure du profil de puissance pour un message LoRa®
Pour résumer, le temps total nécessaire pour l’envoi d’un message LoRa® correspond à cette
expression :
!01-* = !234 + !./( + !5-67 + !-67 + !5-6% + !-6% [>]
!*+'( : Période totale de l’envoi d’un message LoRa [s]
!,-. : Période de la partie « Wake-up Transceiver » [s]
!/0$ : Période de la partie « Time on Air » [s]
!1'23 : Période de la partie « Delay RX1 » [s]
!'23 : Période de la partie « Reception RX1 » [s]

Concernant les messages RX, leurs configurations sont fonction de la région et de la
configuration utilisée pour les messages de type TX. Il est donc plus difficile d’évaluer
théoriquement la durée des paquets RX. Les éléments « Wake-up Transceiver », « Delay RX1 »
et « Delay RX2 » dépendent de la puce LoRa® utilisée. Il faut donc se référer au Datasheet de
ces modules ou effectuer des mesures précises sur la puce pour connaître les durées 7$%&,
7'()* et 7'()+.
2.3La solution adaptée à IWAST
L’approche adoptée pour la résolution de la problématique dans le cadre du projet
IWAST s’est d’abord accompagnée d’une étape d’analyse importante. Un « état des lieux » a
été mené afin d’envisager la solution la plus utile pour le centre de recherche. Cette analyse
préliminaire a permis de constater plusieurs éléments :
• au moment de l’état des lieux, plusieurs éléments du système avaient déjà subi
d’importantes modifications dans le but de réduire la consommation globale. Que ce
soit au niveau des micrologiciels ou des composants Hardware, plusieurs
améliorations notables ont été introduites par le centre de recherche. Parmi celles-ci,
on retrouve notamment les méthodes de conception économes décrites dans l’annexe
A.1 ;
• le centre de recherche ne disposait d’aucun moyen permettant d’évaluer la
consommation énergétique du système IWAST. Plus précisément, aucun outil ne
permettait d’estimer l’énergie nécessaire au système pour fonctionner durant un
certain laps de temps en fonction de sa configuration. Il était donc impossible d’évaluer
précisément l’impact des améliorations apportées pour diminuer la consommation.
Pour rappel, la problématique énergétique globale de l’IoT présente deux aspects : la
diminution de la consommation et l’évaluation énergétique (1.3). Les méthodes de diminution
de la consommation étant déjà implémentées, le premier aspect de la problématique semble
résolu (Fig. 12).

27
Fig. 12 Solutions possibles dans le cadre du projet IWAST
Afin de répondre entièrement à la problématique, il faut donc développer une solution
permettant d’évaluer la consommation énergétique de la nouvelle version du système IWAST.
Pour le deuxième aspect, deux options sont possibles si l’on se réfère aux solutions envisagées
dans le cadre de la problématique globale (1.4) :
• l’implémentation d’un système de mesure en temps réel implémenté directement
dans le système. Cette option nécessite de modifier l’architecture Hardware des cartes
IWAST ;
• l’élaboration d’un modèle d’estimation à partir d’une analyse Hardware et Software.
Pour l’acquisition des données de puissances, des alternatives sont possibles : se baser
sur les données fournies par les fiches techniques des composants ou se baser sur un
ensemble de mesures effectuées à l’aide d’un appareil externe.
Dans le but d’adopter la solution optimale, une liste d’objectifs et d’attentes a été établie. Les
principales exigences du centre de recherche ont été résumées de cette façon :
• il faut une solution permettant d’acquérir une valeur relativement précise de la
consommation en énergie du système IWAST ;
• la solution doit tenir compte des différentes Sensor Boards connectées, de la
configuration de l’utilisateur et des évènements extérieurs qui peuvent survenir ;
• la solution doit pouvoir s’adapter au développement et aux mises à jour du projet
(Hardware ou Software) ;
• la solution ne doit pas détériorer le bon fonctionnement du dispositif.

Le choix s’est finalement porté sur la seconde solution : l’élaboration d’un modèle
d’estimation. Cette décision a été prise pour plusieurs raisons. Tout d’abord, le temps de
développement nécessaire à l’élaboration de cette solution est beaucoup plus court par
rapport à la première option. Étant donné la durée limitée du projet, ce facteur a eu une
grande influence sur la décision. D’autre part, la première solution nécessite une intervention
directe sur le système IWAST. Le risque de dégrader le bon fonctionnement du dispositif est
donc plus élevé. Enfin, la seconde solution permet également d’améliorer l’application IWAST
CONFIGURATOR. Celle-ci n’a pas été améliorée à la suite des récentes modifications du projet.
Le choix de la seconde option offre donc la possibilité de fournir une mise à jour conséquente
de l’application de configuration.
2.4Cahier des charges de la solution
Concrètement, la solution doit se présenter sous la forme de deux livrables principaux :
1. un rapport détaillé de l’ensemble des mesures de courant effectuées sur le dispositif
IWAST. Le rapport doit contenir un descriptif des configurations analysées, les modes
opératoires, les résultats et les conclusions des différentes mesures. Un tableur
contenant l’ensemble des valeurs brutes doit également être fourni avec le rapport ;
2. la nouvelle version de l’application IWAST CONFIGURATOR doit être déposée sur la
plateforme en ligne GitHub du projet IWAST. La nouvelle version doit contenir
l’utilitaire permettant d’estimer la consommation d’énergie du système IWAST en
fonction de la configuration choisie. Il faut également y intégrer l’ensemble des
améliorations demandées par le centre de recherche :
• rendre possible la configuration de plusieurs Motherboard sans
devoir fermer l’application après chaque déconnexion ;
• ajouter les nouvelles fonctionnalités concernant la Sensor Board
Power Module ;
• désactiver la possibilité de régler une interruption de type « Polling »
pour la Sensor Board Buttons ;
• intégrer la possibilité d’activer ou de désactiver l’option « Data
Accumulation ».
Par ailleurs, d’autres exigences techniques et spécifiques au projet IWAST ont été formulées
par le centre de recherche :
1. la nouvelle version de l’application doit être similaire à l’ancienne version pour la
configuration du système ;

29
2. l’utilitaire implémentant le modèle d’estimation doit être directement accessible
après la configuration et doit se baser sur celle-ci pour estimer l’énergie ;
3. les mesures utilisées par le modèle pour estimer l’énergie doivent se trouver en ligne
(sur la plateforme GitHub du projet) et doivent être récupérées par l’utilitaire pour
chaque estimation ;
4. la nouvelle version doit être codée à l’aide du langage de programmation Python ;
5. les améliorations demandées pour la configuration du système IWAST doivent être
intégrées à la nouvelle version ;
6. l’application doit pouvoir être installée facilement par un nouvel utilisateur sur le
système d’exploitation Windows 10.

Chapitre 3 - Mise en œuvre de la solution 30
Chapitre 3 - Mise en œuvre de la solution
L’objectif de ce chapitre est de développer en profondeur la solution adoptée pour la
résolution de la problématique liée à IWAST. Cette partie approfondit donc la conception et la
logique employée pour une solution destinée à un projet spécifique. Dans cette optique, la
solution est divisée et décrite en trois parties.
La première partie est consacrée à l’élaboration du modèle d’estimation. On y détaille les
éléments qui constituent ce modèle et la façon dont on les détermine. À ce stade, le modèle se
base sur plusieurs hypothèses qu’il est nécessaire de valider par la suite. Après la description
de chaque élément, le modèle mathématique complet est présenté.
La deuxième partie se focalise sur l’outil de mesure utilisé pour alimenter le modèle avec les
données nécessaires. Il s’agit principalement des valeurs de temps et d’énergies. On y décrit
l’outil, son fonctionnement et la méthodologie de mesures employée avec IWAST.
La dernière partie décrit en détail le développement de la nouvelle version de l’application de
configuration IWAST CONFIGURATOR. Concrètement, des précisions sur les ajouts souhaités
par le centre de recherche et sur la façon dont le modèle d’estimation est implémenté sont
traitées.

31
3.1Élaboration du modèle d’estimation
Le modèle d’estimation développé pour l’évaluation énergétique du projet IWAST se
base sur plusieurs mesures de courants et de temps. La stratégie adoptée pour son
élaboration est relativement simple et se base sur le fonctionnement du micrologiciel. Pour
rappel (1.2), la routine définie par le programme exécute un certain nombre de tâches.
Chacune d’entre elles peut être caractérisée par une consommation de courant spécifique et
une durée. Les tâches remplies par le micrologiciel correspondent en fait à la puissance
dynamique consommée par le microcontrôleur. En effet, il s’agit des opérations de la routine
lorsque celle-ci est active (lorsqu’elle ne se situe pas dans un mode veille).
Dans le cadre des systèmes IoT, il est utile de faire la distinction entre les tâches dynamiques
communes (prises de mesures, calculs, etc.) et les tâches dynamiques de communication
(transmission des messages vers le réseau IoT). Ainsi, une première hypothèse a été émise :
Pour chaque type de tâche dynamique commune, la durée et la consommation
énergétique qui les caractérisent restent identiques.
La validité de cette hypothèse est essentielle pour le reste du modèle. Les résultats présentés
par la suite permettent d’ailleurs de l’affirmer. Dans notre cas, cette hypothèse n’est pas
valide pour les tâches dynamiques de communications. En effet, le chapitre précédent (2.2) a
démontré que la durée de transmission des paquets LoRa® varie en fonction de la taille des
données utiles. Dans le cadre de IWAST, il est possible que la taille des données utiles varie.
De ce fait, la durée des transmissions peut également varier.
Si la puissance dynamique est importante dans le cadre de ce modèle, l’estimation de la
puissance statique l’est tout autant. Cependant, il ne s’agit pas de tâches définies par une
certaine durée. La consommation statique correspond à la puissance consommée lorsque le
microcontrôleur se trouve en mode veille. Cette caractéristique rend donc l’estimation plus
complexe. À ce stade, une seconde hypothèse peut être formulée :
Les transitions entre les tâches dynamiques et le mode statique se réalisent
instantanément. En d’autres termes, le passage d’un mode à l’autre n’a pas
d’impact sur la consommation énergétique et sa durée est négligeable.
Finalement, trois catégories peuvent être analysées : les tâches dynamiques communes, les
tâches dynamiques de communications et la consommation statique. Il est ainsi possible de
réaliser un bilan énergétique en additionnant les consommations spécifiques de chacune de
ces catégories. Pour IWAST, il a été décidé d’estimer la consommation d’énergie du système
pour une durée de 24h. Avec la carte Power Module, le système est équipé d’une batterie de
500 mAh. Le dispositif doit présenter un fonctionnement en mode nominal pour une durée

relativement importante. Il est donc pertinent d’estimer sa durée de vie sur batterie en
nombre de jours2
.
3.1.1 Analyse de la consommation statique
On considère l’énergie statique du dispositif IWAST comme étant l’énergie dépensée
par le système embarqué lorsque celui-ci est en mode veille (1.2). Le système est conçu pour
dépenser le moins d’énergie possible, il est donc admis que le mode sommeil représente la
part la plus importante en termes de temps. De ce fait, en raison de l’aspect intégratif de la
puissance statique, il devient évident que l’estimation de l’énergie dépensée pour ce mode
doit être suffisamment précise pour ne pas fausser le résultat final.
Une première approche pour déterminer la part en énergie statique consiste à diviser
l’intervalle de temps en deux parties : la partie dynamique et la partie statique (Fig. 13). Pour
de nombreux systèmes embarqués, la première étape de l’estimation consiste à calculer le
temps total passé par le dispositif dans sa part d’énergie dynamique 7,567
.Étant donné que
l’on détermine l’énergie pour une journée de 24h (86400 secondes), il suffit d’y soustraire la
durée totale englobant toutes les tâches dynamiques pour obtenir le temps de l’énergie
statique 7,89:9
.La mesure du courant moyen et la tension fixe de 3.3 V permet d’établir la
puissance statique moyenne !-./..Enfin, on peut déterminer le total de l’énergie statique pour
une journée à l’aide de la formule basique présentée ci-dessous. Cependant, même si cette
démarche semble la plus logique, elle ne peut pas être envisagée dans le contexte IWAST.
!8!"#"
= 86400 − !8$%&
Q!9*9 = L!9*9 . !8!"#"
Fig. 13 Première approche pour l'estimation de la consommation statique
Le dispositif IWAST se démarque des autres systèmes embarqués par le fait que l’on peut avoir
plusieurs microcontrôleurs travaillant ensemble. Ainsi, à titre d’exemple, on peut simplement
connecter la Motherboard et la carte Sound Level. Cette configuration admet l’utilisation de
deux microcontrôleurs : l’unité principale ATSAMD21 et le PIC16 de la carte périphérique. On
2
Sans le soutien de l’unité photovoltaïque de la carte Power Module

33
peut également envisager une configuration plus complexe telle que la connexion de toutes
les Sensor Boards à la Motherboard. Dans ce cas, un ATSAMD21 et quatre microcontrôleurs
PIC16 opèrent de façon simultanée.
Cela ajoute un nouveau degré de complexité dans la détermination de la consommation
statique. En effet, il est possible d’avoir des situations où l’énergie dynamique et l’énergie
statique de plusieurs cartes s’entremêlent. Pendant qu’un microcontrôleur effectue une tâche
(dépensant une énergie que l’on considère comme dynamique), les autres peuvent être en
mode sommeil (que l’on attribue à l’énergie statique). Cette particularité rejette la première
approche envisagée. En effet, la division de la période de temps en partie statique et
dynamique distinctes n’est pas envisageable.
La solution envisagée pour répondre à ce problème consiste à analyser la consommation
individuelle de chaque microcontrôleur. Ainsi, pour obtenir l’énergie consommée par
l’ensemble du système sur un certain intervalle de temps, on effectue la somme des énergies
de chaque microcontrôleur en fonction de leur mode. Pour l’énergie statique, il faut analyser
chaque microcontrôleur, calculer son temps propre passé en mode statique et déterminer son
énergie statique individuelle pour une journée de 24h. La somme de toutes les énergies
statiques de chaque carte i constitue en toute logique l’énergie statique totale consommée
par le dispositif IWAST. Ce choix a une influence sur le reste des déterminations. Il faut
effectivement adopter la même approche pour la détermination des énergies dynamiques.
!!"#". &'&()* = $ %+&(&(') . *,!"#".
(')
-. /0%&'()
-.1
-;./.. >+>(?%: Énergie statique totale du dispositif IWAST [W.s]
/$@+($A : Nombre de cartes (Motherboard + Sensor Boards)
);./.(1) : Puissance statique totale de la carte i [W]
!B!"#".
(1) : Temps statique total de la carte i [s]
La détermination de la puissance statique !-./. (:) spécifique à une carte i est équivalente par
rapport à la première approche. On mesure le courant moyen lorsque la carte est en mode
sommeil et on multiple cette grandeur par la tension fixe de 3.3 V. L’estimation du temps
7,89:9.
(:) nécessite plus de réflexion. De nouveau, le principe est similaire à la première
approche, mais en tenant compte des événements dynamiques propres à chaque carte. Ainsi,
on calcule 7,89:9.
de la carte i en réalisant la soustraction de la durée totale des événements
dynamiques3
7,567.
spécifique à la carte i avec la durée d’une journée de 24h.
L"4.4(I) = V"4.4. <1+(I) . W !'()(. ,-.(#) : Courant statique moyen de la carte i [A]
3 : Tension d’alimentation de la carte i (=3.3 V) [V]
!B*+,.
(1) : Temps dynamique total de la carte i [s]
!8/010.
(I) = 86400 − !8234.
(I)
3
On considère les tâches dynamiques communes et les tâches dynamiques de communications.

Prenons comme exemple la Motherboard connectée avec la carte Sound Level et la carte
Buttons. Au terme d’une mesure du système, on peut obtenir un profil de puissance4
équivalent à la figure présentée ci-après (Fig. 14). Le calcul de l’énergie statique revient à
réaliser la somme des « surfaces statiques » de chaque carte.
Fig. 14 Seconde approche de l'estimation de l'énergie statique
Il peut également s’avérer utile de disposer du temps total que le système passe en mode
statique. Cela permet d’avoir un pourcentage objectif et d’établir une évaluation de la
capacité du système à économiser son énergie. On effectue donc la somme de tous les temps
passés en mode dynamique pour chaque microcontrôleur. On applique ensuite la soustraction
de 86400 par la somme calculée. Cette opération nous donne un total qui représente le pire
cas. On peut en effet avoir des situations où des évènements dynamiques de plusieurs cartes
ont lieu simultanément. Ces évènements particuliers peuvent diminuer le temps total, mais
l’impact global n’est pas significatif.
!8/010. "5"#67
= 86400 − X !8234.
(I)
/= >?85#9$
/=@
3.1.2 Analyse des tâches dynamiques communes
L’approche adoptée pour la détermination de l’énergie dynamique se base sur
l’approche choisie pour l’énergie statique (3.1.1). On doit donc évaluer la consommation
totale de chaque tâche dynamique commune propre à chaque carte (Motherboard et Sensor
Boards). Grâce aux analyses Software et Hardware, cinq types différents de tâches
dynamiques communes ont pu être pris en compte :
• Polling interrupt
• Threshold not exceeded
• Threshold exceeded
• Wake-up Motherboard
• Accumulation message saving
4
Le profil présenté ici est donné à titre d’exemple, il n’est pas représentatif d’une quelconque mesure réelle

35
De façon générale, il est assez simple d’évaluer la contribution énergétique totale de chaque
type d’événement pour chaque carte (Motherboard et Sensor Boards). En effet, il suffit
d’appliquer la relation suivante :
Q919*A) )B9.(I) = Q/CD.)B9.(I) . Y%)B9.(I)
&:-:;<= =>:.(#) : Énergie totale du type d’événement associé à la Sensor Board i [W.s]
&?@A. =>:.(#) : Énergie d’un événement pour la Sensor Board i [W.s]
'(=>:.(#) : Nombre d’apparitions du type d’événement pour la Sensor Board i
L’obtention d’une valeur pour l’énergie d’un type d’événement est simple à obtenir à partir
des mesures de courant. La difficulté réside dans la détermination du nombre d’apparitions
de chaque type d’événements. Il est possible d’évaluer facilement ce nombre pour certains
types grâce aux informations recueillies lors de la configuration (c’est notamment le cas pour
les tâches Polling interrupt). D’autre part, une détermination précise du nombre d’apparitions
est impossible pour d’autres types d’évènements (tels que les tâches Threshold exceeded).
Dans ce cadre, les analyses Hardware et Software du système sont importantes pour la
compréhension du fonctionnement des tâches dynamiques communes (des détails complets
sur chaque type d’événements se trouvent dans l’annexe A.5 ).
Finalement, on peut résumer la détermination de l’énergie des tâches dynamiques communes
et le calcul du temps complet dans ce mode par les formules suivantes :
Q57 919*A) = Q7 + X (Q%(I) + QE(I) + QF(I) + QG(I))
/= >?!7&!. 85#9$
/=@
&B = &CDE. :-:;<= : Énergie totale des événements « Wake-up Motherboard » [W.s]
&F (#) = &G-<. :-:;<=(#) : Énergie totale des événements « Polling Interrupt » associés à la Sensor Board i [W.s]
&H (#) = &(I.JK. :-:;<=(#) : Énergie totale des événements « Threshold non exceeded » associés à la Sensor Board i [W.s]
&L (#) = &(I.K. :-:;<=(#) : Énergie totale des événements « Threshold exceeded » associés à la Sensor Board i [W.s]
&M (#) = &;NN.O;>?@P :-:;<=(#) : Énergie totale pour le stockage des données associé à la Sensor Board i [W.s]
')O=@O. Q-;RA : Nombre de Sensor Boards connectées
!57 919*A) = !7 + X (!%(I) + !E(I) + !F(I) + !G(I))
/= >?!7&!. 85#9$
/=@
*B = *CDE. :-:;<= : Temps total des événements « Wake-up Motherboard » [s]
*F (#) = *G-<. :-:;<=(#) : Temps total des événements « Polling Interrupt » associé à la Sensor Board i [s]
*H (#) = *(I.JK. :-:;<=(#) : Temps total des événements « Threshold non exceeded » associé à la Sensor Board i [s]
*L (#) = *(I.K. :-:;<=(#) : Temps total des événements « Threshold exceeded » associé à la Sensor Board i [s]
*M (#) = *;NN.O;>?@P :-:;<=(#) : Temps total pour le stockage des données associé à la Sensor Board i [s]

3.1.3 Analyse des tâches dynamiques de communications
L’énergie dynamique associée à l’envoi des messages LoRa® par la Motherboard est
particulière et doit être traitée à part. Si on se base sur l’analyse théorique de la
consommation LoRa® (2.2), on peut considérer une structure simplifiée (Fig. 15) du profil
énergétique lors de l’envoi d’un message LoRa® :
Fig. 15 Structure simplifiée de la transmission d'un message
Pour rappel, le délai théorique 7!"# de la partie « Transmission TX » peut se déterminer
facilement au travers de la relation suivante :
!./( = !'() + !'*+
!/0$ : Période de la partie « Transmission TX » [s]
!#$% : Période de la partie « Préambule » [s]
!#() : Période des parties « en-tête », « données utiles » et « CRC
données utiles » [s]
En connaissant les paramètres LoRa® du système IWAST, on peut donc déterminer de façon
théorique la durée de la partie « Transmission TX ». Ainsi, certains paramètres LoRa® du projet
sont fixes :
• le taux de codage CR ne varie pas, il est fixé à 4
5
A (donc 40( = 1) ;
• le nombre de symboles 41#2 de la partie « Préambule » est fixé à 8 ;
• on utilise les en-têtes (« couche physique » et « CRC ») donc le facteur C vaut 0 ;
• la bande passante D, utilisée pour IWAST vaut 125 kHz.
Concernant les autres paramètres, on peut faire varier le facteur d’étalement du spectre SF
de 7 à 12 dans le code de la Motherboard. Si le facteur SF est supérieur ou égal à 11, le
paramètre « Low Data Rate Optimization » est activé. Dès lors, la variable DE est égale à 1.
Celle-ci passe à 0 dans le cas contraire. La taille des données utiles PL est variable en fonction
de la configuration et des Sensor Boards connectées. Ces informations propres à IWAST
permettent donc de simplifier les relations théoriques des périodes 71#2 et 71/3 :
!'() = (6'() + 4,25) . !! = (8 + 4,25) .
2"#
125 000

37
6'*+ = 8 + CDE JGHI. K1
8 . LM − 4 . ,- + 44
4 . (,- − 2 . PQ)
. 52 , 0RS
!'*+ = 6'*+ .
2"#
125 000

Il faut cependant s’assurer que la durée réelle de la partie « Transmission TX » est conforme
par rapport à la valeur théorique. Dans le cas contraire, les mesures doivent déterminer le
degré d’erreur entre la théorie et la pratique.
Concernant les délais des éléments RX1 et RX2, l’analyse théorique de ce travail ne permet
pas d’établir directement des formules théoriques. Les mesures d’énergies doivent donc
permettre de déterminer leurs durées que l’on appelle 7()* et 7()+.De même les mesures
doivent permettre d’établir les durées des périodes « Wake-up Transceiver », « Delay RX1 »
et « Delay RX2 ». Dans ce cadre, on peut envisager l’hypothèse suivante :
Les périodes « Delay RX1 » et Delay RX2 » présentent la même consommation de
courant.
La durée totale d’un message LoRa® peut donc être déterminée au moyen de la relation
présentée ci-dessous. À l’exception de la variable 7!"#, les éléments de cette formule sont
déterminés à l’aide des mesures effectuées directement sur le système.
!01-* = !234 + !./( + !5-67 + !-67 + !5-6% + !-6% [>]
!*+'( : Période totale de l’envoi d’un message LoRa [s]
!,-. : Période de la partie « Wake-up Transceiver » [s]
!/0$ : Période de la partie « Time on Air » [s]
Afin de déterminer entièrement l’énergie dynamique de la communication, il faut également
estimer le nombre de messages pouvant être envoyé au cours d’une journée de 24h. Il faut
également analyser le contenu de ces messages si l’on souhaite déterminer correctement la
taille des données utiles définissant la variable 7!"#.Pour cette analyse, deux situations sont
abordées :
• L’accumulation de message n’est pas active
Dans cette configuration, l’option « Data Accumulation » n’est pas active. Dès
qu’une Sensor Board envoie des données à la Motherboard, celle-ci les envoie

directement dans un message LoRa®. On parle dès lors de l’envoi d’un « Message
Immédiat ». Concrètement, un message est envoyé pour chaque événement de
type « Polling Interrupt » ou « Threshold Exceeded ».
Y<I01-*(I) = Y<4H.8(I) + Y<I1A (I)
Y!I01-* = X Y<I01-*(I)
/=>?!7&!. 85#9$
/=@
'(#S-T;(#) : Nombre de messages immédiats LoRa envoyés pour la Sensor Board i
'((I.K(#) : Nombre d’évènements « Threshold exceeded » pour la Sensor Board i
'(G-< (#) : Nombre d’évènements « Polling Interrupt » pour la Sensor Board i
'*#S-T; : Nombre total de messages immédiats LoRa envoyés sur une journée
La taille des données reçues par la Motherboard dépend du nombre de mesures
associé à chaque Sensor Board. Le format des données utile PL de ce type de
message est repris dans le tableau ci-dessous (Tab. 1) :
Tab. 1 Format des données utiles des messages classiques
Titre Taille Description
<message-type> 1 octet 0x49 (= « I ») pour un message immédiat
<sensor-address> 1 octet
L’adresse I2C de la Sensor Board d’où provient
les données
<sensor-readings> 2 octets x Y<<)9(/$!(I)
2 octets par mesures contenant les données
associées à la Sensor Board
À titre d’exemple, un message immédiat avec des données provenant de la carte
Power Module présente une taille de 6 octets car la carte analyse deux mesures.
• L’accumulation de message est active
Dans cette configuration, l’option « Data Accumulation » est activée. Dès qu’une
Sensor Board envoie des données à la Motherboard, celle-ci les stocke dans sa
mémoire interne. Chaque paquet de données enregistrées dans la mémoire interne
respecte la structure définie dans le tableau ci-dessous (Tab. 2) :

39
Tab. 2 Format des données utiles des messages accumulés
<message-type> 1 octet 0x41 (= « A ») pour un message accumulé
<sensor-address> 1 octet
L’adresse I2C de la Sensor Board d’où provient
les données
<seconds-elapsed> 2 octets
Nombre de secondes écoulées depuis la
dernière mesure
<sensor-readings> 2 octets x Y<<)9(/$!(I)
2 octets par mesures contenant les données
associées à la Sensor Board
À titre d’exemple, l’enregistrement d’un paquet de données provenant de la carte
Power Module présente une taille de 8 octets (car la carte analyse deux mesures)
dans la mémoire interne. Lorsque la mémoire dépasse le seuil de 30 octets de
données, celles-ci sont envoyées dans un message LoRa® que l’on appelle
« messages accumulés ». Une fois les données transmises, celles-ci sont effacées
pour que la mémoire puisse en accueillir de nouvelles. On peut donc estimer que la
taille de la partie PL contenant les données utiles est toujours égale à 30 octets pour
cette configuration.
La détermination du nombre de messages accumulés envoyés sur une journée de
24h est plus complexe. Il faut d’abord déterminer le nombre total d’enregistrements
sur une journée en prenant en compte le nombre de mesures associé à chaque
enregistrement. Ainsi, on peut établir le nombre total d’octets placés en mémoire
sur une journée. On divise ce total par la valeur du seuil (30 octets) pour obtenir le
nombre de messages accumulés envoyés sur une journée.
Y!D01-* =
∑ 1Y<4H.8(I) + Y<I1A (I)] . (4 + 2 . Y<<)9(/$!(I))2
/= >?!7&!. 85#9$
/=@
30
'*+S-T;(#) : Nombre total de messages accumulés LoRa envoyés sur une journée
'((I.K(#) : Nombre d’évènements « Threshold exceeded » pour la Sensor Board i
'(G-< (#) : Nombre d’évènements « Polling Interrupt » pour la Sensor Board i
'(,=:R?NO(#) : Nombre de mesures pour la Sensor Board i
Dans les deux situations, on peut remarquer que le nombre de messages envoyés dépend du
nombre EF&4.,(:) liés aux Sensor Board et qui ne peut pas être prédit directement. Il faut
donc fixer « manuellement » cette variable au moment de l’estimation.
Le dernier point à aborder pour l’énergie dynamique de communication concerne l’énergie
consommée pour l’envoi du message de statut. Il permet de donner plusieurs informations
sur le système. La structure du message est présentée dans le tableau Tab. 3.

Tab. 3 Format des messages de statut
<message-type> 1 octet 0x53 (= « S ») pour un message de statut
<motherboard-id> 2 octets L’identifiant 16 bit de la Motherboard
<status-counter> 2 octets
Le compteur 16 bit qui augmente pour chaque itération
d’un message de statut
<data-accumulation> 1 octet
0x00 = L’option « Data Accumulation » n’est pas active
0x01 = L’option « Data Accumulation » est active
<nr-of-sensors> 1 octet
Valeur représentant le nombre de Sensor Boards
connectées
{sensor-address-list} 1 octet x Y<!)C!. &1*(D
Liste reprenant les adresses I2C de chaque Sensor
Boards connectées
Par exemple, si trois Sensor Boards sont connectées, la taille de la partie PL contenant les
données utiles du message de statut équivaut à 10 octets. Ce message particulier est envoyé
toutes les 12 heures par la Motherboard. Le nombre de messages de ce type envoyés sur une
journée est donc égal à 2.
Pour résumer, l’estimation de l’énergie dynamique de communication dépend principalement
du choix de l’option « Data Accumulation » ou non. Le choix du facteur d’étalement du spectre
SF influence également les valeurs d’énergies associées à l’envoi des messages. Le nombre de
mesures associé aux Sensor Boards doit également être pris en compte pour déterminer la
taille de la partie PL contenant les données utiles. La valeur de cette taille permet ainsi de
détermine la valeur théorique 7!"# de la partie « Transmission TX » du message Lora®.
Si l’option « Data Accumulation » n’est pas activée, on peut établir la consommation
d’énergie dynamique de communication sur une journée au travers de la relation suivante :
Q5% 919*A = 2 . Q!9*93! + X (Y<I01-*(I) . QV01-*(I))
/=>?!7&!. 85#9$
/=@

&UF :-:;< : Énergie dynamique de communication totale pour une journée [W.s]
&O:;:VO : Énergie d’un message de statut (PL = 7 + '(Q-;RA) [W.s]
&!S-T;(#) : Énergie d’un message immédiat associé à la Sensor Board i (PL = 2 + '(,=:R?NO(#)) [W.s]
De même, pour cette configuration, on peut déterminer le temps complet associé à l’énergie
dynamique de communication sur une journée :
!5% 919*A = 2 . !!9*93! + X (Y<I01-*(I) . !V01-*(I))
/=>?!7&!. 85#9$
/=@

41
*UF :-:;< : Temps total associé à l’énergie dynamique de communication pour une journée [s]
*O:;:VO : Durée d’un message de statut (PL = 7 + '(Q-;RA) [s]
'(#S-T;(#) : Nombre de messages immédiats LoRa associé la Sensor Board i
*!S-T;(#) : Durée d’un message immédiat associé à la Sensor Board i (PL = 2 + '(,=:R?NO(#)) [s]
Si l’option « Data Accumulation » est activée, on peut établir la consommation d’énergie
dynamique de communication sur une journée au travers de la relation suivante :
Q5% 919*A = 2 . Q!9*93! + Y!D01-* . Q_01-*
&UF :-:;< : Énergie dynamique de communication totale pour une journée [W.s]
&,S-T; : Énergie d’un message accumulé (PL ≅ 30) [W.s]
De même, pour cette configuration, on peut déterminer le temps complet associé à l’énergie
dynamique de communication sur une journée :
!5% 919*A = 2 . !!9*93! + Y!D01-* . !_01-*
*UF :-:;< : Temps total associé à l’énergie dynamique de communication pour une journée [s]
*O:;:VO : Durée d’un message de statut (PL = 7 + '(Q-;RA) [s]
*,S-T; : Durée d’un message accumulé (PL ≅ 30) [s]
3.1.4 Le modèle complet
Le modèle d’estimation complet peut se résumer au travers de la formule suivante :
QJ2."4 = Q"4.4 919*A) + Q5,7 919*A) + Q5,% 919*A)
Le détail de cette relation requiert le traitement de deux scénarios :
• Si l’option « Data Accumulation » n’est pas activée :
QJ2."4 = F X L!9*9(I) . !8!"#".
(I)
/= >?85#9$
/=@
T
+ FQ2KL. 919*A) + X QI1A. 919*A)(I) + Q4H.>8. 919*A)(I) + Q4H.8. 919*A)(I)]
/= >?!7&!. 85#9$
/=@
T
+ F2 . Q!9*93! + X `Y<I01-*(I) . QV01-*(I)a
/=>?!7&!. 85#9$
/=@
T

&WC)'( : Énergie totale du système IWAST pour une journée (24h) [W.s]
')Q-;RA : Nombre de cartes (Motherboard + Sensor Boards)
.O:;:(#) : Puissance statique totale de la carte i [W]
*K!"#".
(#) : Temps statique total de la carte i [s]
&CDE. :-:;<= : Énergie totale des événements « Wake-up Motherboard » [W.s]
&G-<. :-:;<=(#) : Énergie totale des événements « Polling Interrupt » associés à la Sensor Board i [W.s]
&(I.JK. :-:;<=(#) : Énergie totale des événements « Threshold non exceeded » associés à la Sensor Board i [W.s]
&(I.K. :-:;<=(#) : Énergie totale des événements « Threshold exceeded » associés à la Sensor Board i [W.s]
&!S-T;(#) : Énergie d’un message immédiat associé à la Sensor Board i (PL = 2 + '(,=:R?NO(#)) [W.s]
• Si l’option « Data Accumulation » est activée :
QJ2."4 = F X L!9*9(I) . !8!"#".
(I)
/= >?85#9$
/=@
T
+ FQ2KL. 919*A) + X K
QI1A. 919*A)(I) + Q4H.>8. 919*A)(I)
+ Q4H.8. 919*A)(I) + Q*$$.!*B/CM 919*A)(I)
R
/= >?!7&!. 85#9$
/=@
T
+ (2 . Q!9*93! + Y!D01-* . Q_01-*)
&WC)'( : Énergie totale du système IWAST pour une journée (24h) [W.s]
')Q-;RA : Nombre de cartes (Motherboard + Sensor Boards)
.O:;:(#) : Puissance statique totale de la carte i [W]
*K!"#".
(#) : Temps statique total de la carte i [s]
&CDE. :-:;<= : Énergie totale des événements « Wake-up Motherboard » [W.s]
&G-<. :-:;<=(#) : Énergie totale des événements « Polling Interrupt » associés à la Sensor Board i [W.s]
&(I.JK. :-:;<=(#) : Énergie totale des événements « Threshold non exceeded » associés à la Sensor Board i [W.s]
&(I.K. :-:;<=(#) : Énergie totale des événements « Threshold exceeded » associés à la Sensor Board i [W.s]
&;NN.O;>?@P :-:;<=(#) : Énergie totale pour le stockage des données associé à la Sensor Board i [W.s]
&,S-T; : Énergie d’un message accumulé (PL ≅ 30) [W.s]
Plusieurs variables présentent dans ce modèle sont liées à la configuration du système et
peuvent être déterminées automatiquement après le paramétrage de celui-ci. D’autres
éléments liés aux événements imprévisibles tels que les dépassements de seuil doivent être
évalués par l’utilisateur final (voir l’annexe A.5 pour plus de détails sur ces événements). Ainsi,
plusieurs paramètres nécessitent une attribution arbitraire de leur valeur :
• le nombre de dépassements de seuil EF&4.,(:) associé à une Sensor Board i ;
• le nombre de « non-dépassements » de seuil EF&4.6,(:) associé à certaines Sensor
Boards i ;
• le facteur d’étalement du spectre SF utilisé pour la transmission des messages LoRa.

43
Si on prend en compte la batterie incluse dans la carte Power Module, on peut rapidement
estimer la durée de vie du système complet avec la valeur de l’énergie. La quantité de charges
G7 portée par la batterie de la carte Power Module vaut 500 mAh (lorsque celle-ci est
complètement chargée). À partir des formules de la puissance et de l’énergie, on peut
aisément déterminer la durée de vie de la batterie en fonction de l’énergie consommée par le
système IWAST :
L? = b? . V? Hc Q? = L? . c?
V =
L
b
↔ V =
Q
b . c

↔ V . c =
Q
b
[_. >]
↔ V . c . b = Q [&. >]
L? : Puissance de la batterie [W]
b? : Tension de la batterie [V]
V? : Courant de la batterie [A]
c? : Temps [s]
Q? : Énergie de la batterie [W . s]
Donc si &8 . /8 = 500 ;5ℎ et J8 = 3,3 #, la capacité de la batterie vaut 1,65 ,. ℎ (=
5940 9)5
. La valeur 69$!:& correspond à l’énergie consommée par le système IWAST sur une
journée. On peut ainsi déterminer le temps de fonctionnement complet du système sur la
batterie :
!J2."4 =
V? . c? . b?
QJ2."4
=
1,65
QJ2."4
*WC)'( : Temps de fonctionnement complet du système sur la batterie [jours]
&WC)'( : Énergie totale du système IWAST pour une journée (24h) [W.h]
/X : Tension de la batterie [V]
!X : Courant de la batterie [A]
0X : Temps [s]
Plusieurs remarques doivent être faites par rapport à ce temps de fonctionnement :
• cette estimation ne tient pas compte du vieillissement et des imperfections liés à la
batterie Lithium-Ion utilisée par la Sensor Board Power Module. La valeur obtenue par
la relation précédente est donc supérieure à la réalité ;
• cette estimation se base sur le principe que l’énergie 69$!:& est identique pour
l’ensemble des jours sur lesquels le système est censé fonctionner. Il est évident que
ce principe ne correspond pas à la réalité étant donné que l’énergie consommée
dépend d’événements imprévisibles tels que les dépassements de seuils.
5
Il est important de ne pas confondre l’unité Watts-heures [W.h] avec l’unité Watt [W]. Un Watts-heure
correspond à un joule et représente l’énergie fournie ou consommée par un appareil d’une puissance d’un watt
pendant une heure [18]. L’unité Watts-heures représente donc une quantité d’énergie contrairement à l’unité
Watt qui représente un débit d’énergie. On peut éviter cette confusion en utilisant l’unité Joule (1 Wh = 3600 J).

3.2Les mesures d’énergies du système IWAST
3.2.1 L’outil de mesure
Les mesures d’énergies des systèmes embarqués faible puissance sont complexes à
réaliser. Dans la majorité des cas, un simple ampèremètre muni d’un dispositif permettant
d’enregistrer les données au cours du temps suffit amplement. La mesure du courant et de la
tension fixe permet de calculer la puissance. La prise en compte de la variable temporelle
permet ensuite de déterminer l’énergie consommée par le système au cours du temps. L’idée
est simple, mais la caractéristique « faible puissance » propre à la plupart des systèmes IoT
rend la mesure plus délicate. Le dispositif de mesure doit être capable de mesurer des
courants de l’ordre du µA voire du nA dans certains cas. Il faut également s’assurer que la
mesure n’influence pas le fonctionnement du système et donc le résultat.
Pour ce faire, le centre de recherche dispose d’un outil très performant. Otii Arc® est un
analyseur de puissance développé par la société QOITECH® (Fig. 16). Il a été conçu pour aider
les développeurs à intégrer leurs systèmes embarqués dans le monde de l’IoT. Il est donc tout
à fait capable de mesurer des courants de l’ordre du nA. Le dispositif se combine avec son
logiciel dédié. On peut ainsi enregistrer directement toutes les données pour obtenir des
profils de puissances similaires à l’exemple ci-dessous (Fig. 17).
Fig. 16 L'appareil de mesure Otii Arc Fig. 17 Exemple de profil de puissance
Concrètement, le dispositif fonctionne de la même façon qu’une alimentation de laboratoire
externe. On branche les bornes rouges et noires aux broches d’alimentation du système
embarqué que l’on souhaite analyser. On peut ensuite alimenter celui-ci avec la tension
requise à partir du logiciel. Dès lors, l’appareil enregistre toutes les mesures de courant et
peut évaluer l’énergie consommée en fonction de l’intervalle de temps qui nous intéresse. En
termes d’unités, le dispositif de mesure estime l’énergie consommée par le système analysé
en [W.h]. L’unité équivalente de cette grandeur est le joule [J].

45
3.2.2 Méthodologie
Pour l’analyse du système IWAST, la Motherboard et l’ensemble des Sensor Boards
doivent être analysés individuellement. Ainsi, on peut extraire les informations liées à
l’énergie statique et aux événements dynamiques propres à chaque carte.
Le rapport détaillant l’ensemble des mesures et les résultats est donc divisé en cinq parties :
la Motherboard et les quatre Sensor Boards. Chaque partie contient une brève description
technique de la carte analysée. On y trouve des explications sur les composants électroniques
utilisés et des extraits de fiches techniques liés à ces éléments. Chaque carte possède un mode
opératoire spécifique décrivant la méthodologie employée pour l’ensemble des mesures. Les
structures de ces modes opératoires sont similaires pour toutes les cartes et respectent le
schéma ci-dessous :
1. description de la connexion de l’appareil de mesure Otii Arc® avec la (les) carte(s) du
système IWAST ;
2. description des configurations à régler dans l’application IWAST CONFIGURATOR et qui
nécessitent une analyse. Chaque configuration nécessite une séance de mesure
aboutissant à un profil de puissance précis. On attribue un identifiant à chacun de ces
profils ;
3. description des éléments à analyser dans chaque profil de puissance de la carte
analysée. On peut ainsi connaître les types d’événements dynamiques que l’on doit
prendre en compte ;
4. description des mesures spéciales à réaliser en fonction de la carte.
Les résultats sont présentés après le mode opératoire. On peut ainsi émettre des conclusions
permettant d’affirmer ou de contredire les hypothèses établies précédemment. Ces
conclusions sont importantes, elles permettent de simplifier les résultats en dégageant les
données pertinentes pour le modèle d’estimation. On peut donc établir le tableur reprenant
l’ensemble des données sur lesquelles l’estimation de la consommation énergétique se base.
3.3Développement de l’application
La nouvelle version de l’application se base en grande partie sur les éléments
constituants la première version. Le code Python peut donc être repris et amélioré pour
satisfaire les exigences du projet. L’application PyCharm CE constitue l’environnement de
développement utilisé pour la programmation en Python. L’édition communautaire de
l’application est sous licence Apache 2. Concrètement, cela signifie que le logiciel est gratuit
et que l’on est libre de l’utiliser partout (y compris pour un usage professionnel).

Conception d'un modèle d'estimation de la consommation énergétique pour un système embarqué IoT

Conception d'un modèle d'estimation de la consommation énergétique pour un système embarqué IoT

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Conception d'un modèle d'estimation de la consommation énergétique pour un système embarqué IoT

Similaire à Conception d'un modèle d'estimation de la consommation énergétique pour un système embarqué IoT (20)

Dernier

Dernier (9)

Conception d'un modèle d'estimation de la consommation énergétique pour un système embarqué IoT