Architecture de test à base d'ordinateurs sur carte (type RaspberryPi)

De fablab
Aller à : navigation, rechercher

Cadre du projet

  • Encadrants : Etienne Dublé et Franck Rousseau.
  • Nombre d'étudiants : 1 groupe de 3 à 4.
  • Lieu : le projet aura lieu en salle FabLab à l'Ensimag.
  • Prérequis : Connaissances sur le boot Linux. Des notions sur Android seraient un plus.

Contexte

Quand on travaille sur le thème des réseaux de capteurs, ou des systèmes distribués, la phase de test est très importante, car le parallélisme sous-jacent est souvent source de dysfonctionnements. Dans un premier temps, on procède souvent à quelques tests sur un "coin de table". Ensuite il faut mettre en place un plus grand nombre de noeuds ; on se tourne alors vers des infrastructures de test publiques, telles que celles fournies par les projets Senslab/FIT, Orbit, Wisebed, GreenOrbs, etc.

Notre expérience montre que :

  • La mise en place d'un test sur un "coin de table" implique finalement que l'on doit mettre en place toute une petite infrastructure. Cela prend du temps et on doit le refaire à chaque expérience.
  • Les infrastructures de test publique présentent l'inconvénient d'être uniquement accessible à distance. Cela implique un manque de souplesse (impossibilité de changer le type de matériel déployé), de visibilité, et de réactivité en cas de problème.

Nous proposons donc de concevoir et prototyper une infrastructure de test, facilement déployable, adaptable, et peu onéreuse, qui puisse résoudre ces inconvénients.

Matériel utilisé

Les noeuds de l'architecture seront des ordinateurs sur carte basé sur un processeur ARM, de type Raspberry Pi ou BeagleBoard. Malgré leur compacité, ces ordinateurs sur carte disposent d'une connectique standard (USB maître, sortie vidéo, etc.), d'une puissance de calcul importante (CPU de l'ordre de 1GHz, RAM de 256Mo ou plus...), pour un coût très modéré.

Raspi.png Beagleboard.png

Dans un des scénarios (voir plus loin) des cartes ST Microelectronics MB851 seront également utilisées. Ces cartes sont munies de différents capteurs (accéléromètre, température, etc.) et utilisées dans les recherches sur les réseaux de capteurs. Leurs ressources sont beaucoup plus limitées (CPU très basse consommation, RAM de 8 kilos-octets, Flash de 128 kilos-octets). Le mini-OS que l'on installera dessus (contiki) est adapté à ces contraintes. Ces cartes seront branchées sur le port USB des cartes Raspberry Pi (ou beagleboard).

MB851.png

Enfin, le réseau sera déployé autour d'un switch PoE (Power Over Ethernet), permettant via un seul câble à la fois d'alimenter les noeuds et de leur fournir une connectivité ethernet. Cela permettra de faciliter un déploiement futur à plus grande échelle.

Scénarios

Scénario 1

Dans ce scénario (voir figure ci-dessous) les noeuds (raspberry pi ou beagleboard) sont munis d'une clé wifi (connectée sur un port USB) et démarrent un OS Android. Ce scénario permet ainsi d'émuler un réseau de smartphones, et de mener des tests de gestion de données distribuées dans un environnement de ce type.

Scenario wifi android.png

Scénario 2 (sauf si manque de temps)

Dans ce scénario (voir figure ci-dessous) les noeuds (raspberry pi ou beagleboard) sont principalement utilisés comme passerelle vers une (ou plusieurs) carte(s) MB851 connectée(s) en USB. Elles permettent ainsi d'instrumenter et de monitorer le réseau de capteurs ainsi mis en place, les cartes MB851 utilisant leur radio 802.15.4 pour communiquer entre elles. Les noeuds (raspberry pi ou beagleboard) devront dans ce cas charger un OS Linux. Ce scénario correspond à des expériences très courantes dans le domaine des réseaux de capteurs.

Scenario capteurs linux.png

Travail demandé

Le but du projet est de concevoir et implémenter une infrastructure logicielle capable de supporter ces 2 scénarios. En particulier, l'architecture devant être à terme déployée dans un bâtiment, les noeuds (raspberry pi ou beagleboard) ne seront pas facilement accessibles. Ils devront donc être instrumentés à distance (sauf pour la connexion des équipements sur les ports USB bien sûr). En particulier, il devra être possible de rebooter les noeuds à distance. Ceux-ci devront alors démarrer un OS Android ou Linux suivant le choix de l'utilisateur.

En réalité, les cartes raspberry pi (ou beableboard) démarrent sur une carte SD. L'OS qui y sera stocké devra, dans notre cas, se connecter au serveur NFS, lire le choix de l'OS choisi par l'utilisateur (dans un fichier sur le serveur NFS peut-être ?), et démarrer ce second OS.

Note : Il est normalement possible de charger un noyau différent à partir d'un noyau en cours d'exécution (kexec). En cas de problème sur ce point technique, on le contournera via une copie du noyau sur la carte SD et un reboot...

Au final il faudra donc fournir principalement :

  • Une distribution minimale (Linux à priori) à déployer sur la carte SD de chaque noeud, conçue pour charger un 2e OS.
  • Une distribution Android adaptée aux raspberry pi (ou beagleboard) et à notre architecture (connectivité ethernet pour l'instrumentation, pilote wifi, etc.) et stockée sur le serveur NFS.
  • Scénario 2, si le temps le permet: une distribution Linux adaptée aux raspberry pi (ou beagleboard) et à notre architecture, stockée sur le serveur NFS, capable de :
    • flasher les cartes MB851
    • permettre à l'utilisateur de communiquer avec la carte (liaison TCP jusqu'au raspberry pi puis série / USB pour joindre la carte MB851).
  • Scénario 2, si le temps le permet: un OS contiki (l'OS embarqué sur les cartes MB851) configuré suivant les besoins.
  • Une interface utilisateur pour l'instrumentation des noeuds, plus ou moins évoluée suivant l'avancement du projet (ligne de commande ou interface web). Le serveur NFS pourra être utilisé pour héberger cette interface.

Réalisation

Lien vers le projet

Bibliographie