wikinotes

Pour ce MOOC, les inscrits ont accès à la plateforme FIT IoT-LAB. Lors de la conception de celle-ci , les chercheurs du CNRS ont également conçu leur propre matériel. Nous allons détailler ici l'architecture matérielle de la carte IoT-LAB M3, qui a été déployé en grand nombre pour permettre les expérimentations à large échelle. Nous expliquerons également succinctement de quelle manière est réalisée l'intégration matérielle des cartes d'expérimentation dans la plateforme pour une utilisation à distance.

Prenons pour exemple les appareils connectés du FIT IoT-LAB:

• Quels sont leurs composants?
• Comment peut-on interagir avec eux à distance?

Ce synoptique montre les liens entre les différents composants du M3 IoT-LAB.

Les composants en bleu sont les composants principaux de l'appareil. Les composants en orange sont les capteurs qui font la spécificité de l'appareil. Enfin, les composants en violet montrent comment on connecte l'appareil à un ordinateur ou à la plateforme d'essai IoT-LAB.

Nous avons présenté en détail le M3 IoT-LAB et ses différents composants. Afin de tester les applications de communication, qui nécessitent au moins deux appareils, un émetteur et un récepteur, un développeur doit alterner entre au moins deux appareils connectés à son ordinateur. Comment tester des applications plus importantes avec des dizaines, des centaines d'appareils? Comment reprogrammer facilement tous ces appareils?

L'objet connecté IoT-LAB M3 tire son nom du CPU dont il est équipé: le Cortex M3 du fabricant ARM. Le Cortex M3 est un CPU 32 bits cadencé à une vitesse maximum de 72 MHz. Le Cortex M3 est intégré au MCU STM32 (référence STM32F103REY) du fabricant STMicroelectronics ou plus communément appelé ST. Le MCU STM32 embarque 64ko de RAM et 256ko de ROM. Ces caractéristiques techniques placent l'objet connecté IoT-LAB M3 dans la catégorie des objets contraints utilisant des systèmes d'exploitation embarqués. Un exemple d'objet connecté utilisant ce même MCU est la télécommande de l'Apple TV 4.

Au niveau des dimensions, le M3 a un form factor (ie design de la CAO du système embarqué) d'une taille de 4 cm de large sur 5 cm de long. Gardons à l'esprit que l'objet IoT-LAB M3 a été conçu comme une carte générique de développement. Selon le cas d'usage, un industriel pourrait encore optimiser la CAO pour réduire l'encombrement des composants à la taille de l'ongle d'un pouce.

Afin de communiquer avec les différents composants externes, l'objet IoT-LAB M3 utilise les bus de données I2C et SPI de son MCU SMT32. Puce radio

La puce radio AT86RF231 du fabricant Atmel (racheté en 2016 par Microchip) communique sur la bande de fréquence ISM 2.4 GHz. Cette puce radio a été conçue pour implémenter la couche MAC du standard IEE 802.15.4 utilisée entre autre par les protocoles de communication Zigbee et LoraWAN. La bande passante maximale est 256 kbits/s . Une antenne céramique très petite d'une longueur de 9 mm est soudée sur le circuit. On classe cette technologie radio dans la catégorie courte portée pour des distances maximum de quelques dizaines de mètres en intérieur jusqu'à une centaine de mètre en extérieur. Selon ces spécifications techniques, la puce radio consomme jusqu'à 14 mA pour une transmission à puissance maximale. Elle est interconnectée avec le MCU sur le bus SPI qui permet des échanges de données rapides. Elle est également branchée sur un port GPIO du MCU afin de gérer le réveil de la puce radio dans le cas d'une mise en veille.

Une mémoire NOR Flash externe (N25Q128A13E1240F) de 128 Mbits est connecté au MCU via le bus SPI afin d'autoriser des transferts de données rapides. Cette mémoire est utile pour stocker de manière persistante les données acquises par les capteurs au cours de l'exécution du programme. Un autre cas d'usage est la mise à jour OTA (Over The Air) du firmware du MCU. Certains OS embarqués partitionnent cette mémoire ROM pour télécharger et stocker différentes versions de firmware.

4 capteurs connectés au MCU via le bus I2C sont embarqués dans le IoT-LAB M3 :

• Le capteur de lumière ISL29020: il mesure l'intensité lumineuse environnante en lux;
• Le capteur de pression LPS331AP: il mesure la pression atmosphérique en hPa;
• L'accéléromètre/magnétomètre LSM303DLHC: il remonte l'accélération d'un objet. Son utilisation permet de détecter des mouvements. En définissant un seuil, il génère un changement d'état sur une entrée/sortie digitale du MCU afin de créer une interruption, utile par exemple pour sortir le MCU de veille.
• Le gyromètre L3G4200D: il mesure l'orientation de l'objet dans l'espace, par exemple pour déterminer l'orientation de l'écran d'une tablette ou d'un smartphone.

3 LEDS (rouge, vert, orange) sont connectées au MCU via les entrées/sorties digitales sur le IoT-LAB M3. En local, elles sont utiles pour notifier un état ou une action du MCU. A distance sur la plateforme d'expérimentation IoT-LAB, les LEDs vont nous permettre d'illustrer le monitoring de consommation d'énergie en changeant périodiquement leur état allumé ou éteint.

Le nœud M3 peut être alimenté en 3,3V de deux manières différentes :

• via le port USB;
• via la batterie externe.

Au niveau des consommations des différentes périphériques, on notera que le MCU consomme à pleine puissance 14 mA auquel il faut ajouter la consommation des autres périphériques. Par exemple le puce radio consomme 14 mA en émission et 12 mA en réception.

Les cas d'usages typiques des objets connectés contraints requièrent souvent l'utilisation d'une batterie. Afin de maximiser la durée de vie de l'objet, la stratégie d'économie d'énergie consiste à basculer le MCU ainsi que ses divers composants dans un état de veille dès que l'objet a fini un traitement. Dans le cas du MCU STM32, on arrive à une consommation de 1 mA dans le mode SLEEP, et en-dessous de 1 μA dans le mode STANDBY. La puce radio AT86RF231 supporte le même type de fonctionnalités pour des gains énergétiques comparables.

L'interface JTAG permet de reprogrammer et débugger le MCU depuis un ordinateur. Elle est accessible via le composant FTDI qui est placé derrière les connecteurs USB et IoT-LAB. Ce dernier est utilisé pour l'intégration de l'objet IoT-LAB M3 dans la plateforme IoT-LAB. Ce composant FTDI expose également un port UART qui permet d'afficher des messages sur le terminal utilisateur.

C'est pour expérimenter ces cas d'utilisation que l'INRIA a créé la plateforme d'essai IoT-LAB, qui permet de reprogrammer à distance plusieurs centaines d'appareils. Le M3 IoT-LAB est connecté à un ordinateur embarqué: la passerelle IoT-LAB. Cette passerelle est aussi puissante qu'un smartphone. Elle joue le rôle de l'ordinateur du développeur pour reprogrammer à distance le micrologiciel du M3 IoT-LAB. Il permet aussi de surveiller la performance du M3 IoT-LAB en termes de consommation d'énergie, de bruit radio-électrique et de trafic réseau. Grâce à cela, l'utilisateur connecté à l'IoT-LAB peut par exemple estimer la durée de vie de la batterie de son application. Le portail est doté d'un port Ethernet qui permet de connecter le M3 IoT-LAB au serveur d'expérimentation, qui joue un rôle de directeur.

L'objet connecté IoT-LAB M3 présenté précédemment est typiquement identique à des cartes de développement IoT communément branchées à un ordinateur via un port USB afin de les programmer et déboguer. Dans un contexte d'expérimentation d'applications ou de protocoles réseaux à grande échelle, il devient fastidieux de reprogrammer une dizaine voire une centaine d'objets de cette manière.

La plateforme FIT IoT-LAB apporte une solution à ce problème en intégrant chaque carte d'expérimentation appelée Open Node (ON) derrière un mini-ordinateur appelé Gateway (GW). On utilise ici le terme de passerelle, mais au sens matériel, car elle met en lien la carte d'expérimentation avec les autres composants matériels de la plateforme. Ce sera cette passerelle qui aura notamment la charge de programmer la carte d'expérimentation. En plus de cette passerelle intermédiaire, un système embarqué autonome appelé Control Node (CN) est capable de surveiller l'Open Node pour mesurer sa consommation énergétique, le bruit et le trafic radio. L'intérêt d'utiliser un MCU dédié est de garantir une exécution temps réel de ces mesures. Enfin, le noeud IoT-LAB complet est relié via un réseau privé à un serveur IoT-LAB de site qui va pouvoir l'administrer à distance.

Pour faciliter le déploiement, la Gateway embarque un module PoE (Power Over Ethernet) qui, comme son nom l'indique, permet d'apporter l'alimentation électrique par le port Ethernet en plus de la liaison réseau. Étant le seul lien au matériel, c'est donc aussi par cette liaison que passent les liens habituels d'interaction avec la carte d'expérimentation:

• Le lien série de l'Open Node est redirigé vers une socket TCP servie par la Gateway sur le port 20000;
• Le lien de déboguage de l'Open Node est redirigé vers une seconde socket TCP servie par la Gateway sur le port 3333;

Ainsi que les données remontées par le Control Node:

• Les données du sniffer sont écrites dans une socket TCP servie par la Gateway sur le port 30000;
• Les données de surveillance automatique (i.e. monitoring) sont eux écrits dans directement dans des fichiers dans l'espace de travail de l'utilisateur.

Des règles de filtrage réseau dynamiques rendent ces liens accessibles par l'utilisateur ayant réservé ces nœuds d'expérimentation, depuis la frontale SSH du site concerné, pour la durée de l'expérience.

Visitez le site web d'IoT-LAB pour plus d'information sur la carte IoT-LAB Gateway.