KNX-RF en mode Energy Harvesting

Chapitre V. Simulation de la robustesse RadioFréquences de KNX-RF sous OMNet++

Figure V-15 : Structure optimisée d’une trame KNX-RF pour des applications d’Energy Harvesting

Chapitre V. Simulation de la robustesse RadioFréquences de KNX-RF sous OMNet++

V.8. Les propriétés potentiellement améliorables en KNX-RF

V.8.5. KNX-RF en mode Energy Harvesting

Pour enrichir l’offre de produit avec des systèmes qui fonctionnent sans piles, il serait intéressant

de se pencher sur la possibilité de créer un mode KNX-RF d’Energy Harvesting en s’appuyant sur les

principes fondamentaux des technologies d’energy harvesting existantes (e.g. EnOcean).

Les formes les plus courantes d'énergie qui peuvent être récoltées par un capteur sans fil sont

cinétique, solaire ou thermique. La quantité d’énergie récoltée grâce aux technologies d’energy

harvesting est relativement petite, typiquement de l’ordre du microampère. La conception d’un

système optimisé en termes de consommation d’énergie est donc essentielle pour permettre aux

capteurs de fonctionner correctement.

Trois fonctions principales définissent le budget énergétique d'un capteur sans fil : la mesure

(température, humidité, etc), la transmission radio de données et la phase de veille. Il faut donc

concevoir un système où l'énergie récoltée est répartie équitablement entre ces fonctions en tenant

compte des exigences de chacune.

Cette répartition peut être réalisée de deux manières : soit les fonctionnalités du système sont

fixées (et donc la puissance nécessaire pour les réaliser) et la technologie utilisée est dimensionnée

pour fournir la quantité d’énergie nécessaire, soit la puissance fournit par la technologie utilisé est

fixée et les fonctionnalités du système doivent alors être optimisées. Le deuxième scénario est le plus

commun.

Pour illustrer ces exigences et pouvoir définir un système d’energy harvesting pour KNX-RF,

considérons le cas d’un module intégrant une technologie basée sur une cellule solaire photovoltaïque.

Ses principales tâches consistent à mesurer la température et/ou l'humidité dans une pièce et de les

comparer avec les consignes définis par l'utilisateur.

La quantité d’énergie fournit par la cellule est limitée par sa taille et le niveau d'éclairement

minimal attendu. Pour notre étude, la taille assumée est de 5 cm² et l’éclairement est de 200 LUX

(niveau de lumière ambiante typique dans une pièce de vie) pendant six heures (moyenne d’heures

d’ensoleillement en France). La densité de puissance équivalente à 200 LUX est d’environ 29 µW/cm²

pour une longueur d’onde de 550 nm. Cependant, la densité de puissance typique produite par les

cellules solaires standards disponibles dans le marché n’est que de 5 µW/cm² dans un environnement

indoor [130]-[131].

Cela signifie que pour une taille de 5 cm², la cellule produit 50 µW, et ce pendant 6 heures. Par

souci de simplicité, nous considérons que la tension d’alimentation est de 3 volts. Le calcul du courant

moyen nous indique alors que nous avons besoin de concevoir un système qui consommerait moins de

2 μA en courant moyen. Pour évaluer les exigences en puissance de chaque fonction, nous allons

allouer l'énergie disponible de façon égalitaire en donnant environ 600 nA de courant à chaque

fonction : mesure, transmission radio et phase de veille + perte de puissance (décharge).

Pour la mesure, l'échange de données entre le capteur et le processeur (via le bus I2C) et le

traitement des données initiales d’un capteur optimisée de température ou d’humidité nécessiterait un

courant moyen d'environ 1 mA pour une durée de 10 ms. On peut alors calculer le nombre maximal de

mesures par jour en divisant l'énergie disponible par jour (600 nA x de 86400 s) par l'énergie requise

par la mesure (1 mA x 10 ms). Il en résulte que le capteur peut faire jusqu’à 5184 mesures par jour.

Etant donné que la température et l’humidité varient lentement dans le temps et qu’il faut

conserver l’énergie, nous considérerons dans ce qui suit que le capteur fait une mesure toutes les 1

minutes ; ce qui donne un total de 1440 mesures par jours.

Considérons maintenant l’énergie liée à la transmission radio de données. Afin d’optimiser au

maximum la consommation énergétique, tant le protocole radio que l’énergie dépensée en

transmission doivent être optimisés. La charge utile associée à un capteur est souvent de petite taille

(quelques octets). Par ailleurs, un protocole optimisé doit limiter les overheads de transmission

(contrôle de trame, préambule, synchronisation, contrôle d'erreur) autant que possible, tout en

maintenant une communication fiable.

Le contenu de la trame KNX-RF doit donc être optimisé pour avoir des trames plus courtes. Pour

ce faire, la trame ne sera limitée qu’à deux blocs maximum au lieu des quatre prévus par la norme. Le

préambule et le postambule doivent être supprimés. De plus, pour réduire la consommation d’énergie

et optimiser la bande passante, l’encodage Manchester ne sera plus appliqué sur les données. Les bits

de violation Manchester seront donc aussi supprimés. Ainsi, la trame complète sera composée de 22

octets intégrant une payload de 1 octet (Figure V-15).

Dans ce qui suit nous allons déterminer le débit nécessaire pour transmettre une telle trame tout

en respectant l’exigence en consommation d’énergie pour la fonction de transmission. Le transceiver

SEMTECH utilisé dans les modules KNX-RF consomme 30 mA en émission. En tenant compte du

budget énergétique disponible sur une journée (600 nA x de 86400 s), ainsi que le courant nécessaire à

l’émission, on peut calculer la durée totale de transmission possible par jour, qui est égale à 1,728 ms

par jour. En faisant le lien avec le nombre de mesures possibles par jour, nous pouvons calculer le

nombre total d’octets qui peuvent transiter par jour : 31680 octets. De là on peut déduire le débit

nécessaire pour que le protocole KNX-RF soit adapté à faire de l’energy harvesting et qui est égale à

environ 147 kbit/s.

Concernant la robustesse radio, la trame KNX-RF de 22 octets aurait une durée totale de 1,2 ms.

La probabilité de collision avec d’autres trames serait par conséquent réduite. Par ailleurs, une

stratégie de transmission intelligente est nécessaire pour fiabiliser les communications radio dans un

tel system faible en énergie. Pour ce faire, une trame radio ne sera transmise qu’en cas de changement

significatif de la valeur analogique mesurée comparée à la dernière mesure. Cela permettrait d’utiliser

l’énergie pour retransmettre la même trame un certain nombre de fois (à définir par simulation/ test et

calculs de probabilité de collisions) pour augmenter la fiabilité du système.

Par ailleurs, une modulation spectralement efficace et simple doit être choisie. La 2-FSK étant

moins efficace que le 2-ASK et la 2-PSK en terme de largeur de bande, et la PSK étant plus compliqué

à décodé, c’est la modulation 2-ASK qui semble la plus adaptée.

Concernant la fréquence d’opération, la fréquence 868,85 MHz (qui correspond au canal Fast F2)

semble un choix judicieux pour éviter les interférences, d’un côté, avec les systèmes EnOcean dont la

fréquence est 868,3 MHz, et de l’autre, avec les autres systèmes KNX-RF Fast qui ont tous pour canal