1°/ Objectifs
Ce sujet a pour objectif de mettre en place une application complexe faisant intervenir des connaissances de la plupart des matières techniques enseignées en 3ème année, mais aussi celles des années précédentes. Comme le choix a été fait de "mixer" la SAÉ a S5 vec celle de S6, le cadre de développement de ce sujet relativement fixé et se base sur des codes déjà écrits qu'il faut adapter aux besoins applicatifs. Ces derniers sont en revanches laissés libres.
2°/ Cadre général
La SAÉ consiste a "inventer" une application basée sur des micro-contrôleurs et des objets connectés (téléphones portables, camera ip, ...) pour collecter des données. Ces données sont soit directement textuelles/numériques, comme c'est souvent le cas avec celles que collectent des micro-contrôleurs grâce à des capteurs, soit au format audio, image, ... qu'il faut traiter pour en tirer de l'information textuelle/numérique. Qu'il y ait ou non traitement, le résultat est stocké dans une base de données non relationnelle, type mongodb. Une application web front-end faite en vuejs permet ensuite de récupérer des données dans cette BdD (au travers d'une API) et de les visualiser.
Vous DEVEZ reprendre l'architecture logicielle d'un prototype d'application de "maison intelligente", donné dans la figure 1 de la section suivante. Vous pouvez ajouter des "morceaux" à ce prototype, mais pas en retirer, quand bien même cela semble bien complexe pour ce type d'application.
Une grande partie du code de cette application sera donnée comme base (NB : le reste a été perdu par un stagiaire qui ne voulait pas utiliser git :-) ). Vous devrez OBLIGATOIREMENT utiliser cette base et ne pas repartir de 0. L'évaluation tiendra compte de cet aspect, et sanctionnera tout morceau de code totalement réécrit, alors qu'il était déjà présent dans le prototype et quasi fonctionnel pour votre application. L'idée est de se mettre dans des conditions de développement comme dans une entreprise où l'on doit faire évoluer un code existant, tout en restant dans un cadre de développement fortement contraint.
Une partie de la SAÉ sera consacrée à la gestion du code et la mise en production. C'est pourquoi les serveurs implémentés devront être "dockerisés" automatiquement, grâce à des processus d'intégration continue.
3°/ Le prototype de départ
3.1°/ Scénario
Dans une maison, des boîtiers permettent de faire des mesures à intervalles réguliers. Ces boîtiers contiennent des micro-contrôleurs de type esp8266, connectés à des capteurs. Par exemple, on cherche à mesurer la température et pression atmosphérique sur la terrasse, la luminosité dans chaque pièce (= lumière allumée ou non), la production électrique de panneaux photovoltaïques, etc. L'objectif de cette collecte de données est de faire par exemple du suivi/gestion de consommation énergétique, au travers de la visualisation de graphiques, statistiques, ... via un navigateur.
Le propriétaire peut également utiliser son téléphone portable et/ou des caméra IPs pour prendre des photos du ciel, qui vont être analysées par un serveur afin d'en tirer des informations chiffrées, par exemple la nébulosité, le % de chance qu'il pleuve, etc. Ces informations peuvent être croisées avec celles collectées via les micro-contrôleurs, par exemple pour faire de la prévision météorologique, ou bien pour prendre des décisions concernant la maison, comme par exemple fermer les volets, ...
3.2°/ Architecture logicielle
Elle est donné en figure 1 ci-dessous
 |
| Figure 1 : architecture logicielle du prototype d'application |
Description :
- Les données collectées (température, pression, voltage, etc) par les micro-contrôleurs sont envoyées à un serveur écrit en Java.
- Les µC se connectent au serveur via des sockets TCP et la communication se fait en mode texte.
- Le serveur est implémenté afin de servir simultanément plusieurs µC (donc multi-threadé) afin que ces derniers puissent envoyer des données n'importe quand.
- Le protocole de communication contient des requêtes permettant aux µC :
- de demander de stocker un certain type d'information,
- de demander les horaires et/ou intervalles auxquels ils doivent faire les mesures, sachant que ces horaires/intervalles sont stockés en BdD (et modifiables via le front-end)
- Pour envoyer/interroger la Bdd, le serveur utilise 2 principes : soit indrectement via une API écrite en node, qui sert également au front-end pour récupérer les données, soit un accès direct via les "drivers" mongodb pour java.
- L'accès direct à la Bdd en Java est "expérimental" et considéré comme "non fiable". Toutes les données collectées sont donc par défaut stockées en BdD via l'API, mais il existe également des méthodes dans le serveur qui permettent de stocker certaines données en accès direct. NB : cette situation correspond à une migration de technologie, où l'on développe en utilisant une technologie connue et maîtrisée, mais pour des raisons par exemple de performance, on commence le développement de certaines fonctionnalités avec une autre technologie.
- Les photos du ciel prise via une application mobile sous android, qui les envoie à un serveur d'analyse multimédia. Dans le prototype, il est également écrit en Java en utilisant une connexion TCP, mais cette fois en mode binaire (NB : ce n'est pas une contrainte, comme indiqué dans la partie suivante)
- Le serveur ne peut servir qu'un seul client à la fois.
- Le serveur analyse chaque photo reçue afin de calculer différentes informations : nébulosité, densité/type de nuages, ...
- Ce serveur est lui-même client du serveur Java de centralisation des données, afin d'envoyer les résultats de l'analyse.
- Le front-end est une SPA écrite en vuejs.
- Elle est structurée en deux parties : invité et administrateur.
- La partie invité permet simplement d'afficher un tableau de bord, avec des graphiques créés à partir de données stockées en BdD.
- La partie administrateur permet de gérer la "flotte" de boîtier, notamment en gérant les horaires/intervalles de mesure pour chacun.
- Les fichiers HTML+JS+CSS de la SPA sont stockés et servis par l'API node
- Tous les serveurs et la SPA sont développés en utilisant des outils de "versioning" permettant d'avoir des branches de développement et de production séparées.
- Leur développement utilise des processus d'intégration continue afin d'intégrer directement les modifications de codes soumises et produire les versions déployables des serveurs.
- Ceux-ci sont déployés sous la forme de conteneurs docker, lancés automatiquement après déploiment.
4°/ Le contexte et les contraintes
Vous devez trouver un contexte applicatif qui soit différent de celui du prototype mais qui soit compatible avec l'architecture logicielle, c'est-à-dire basé sur des données collectées par des µC et des plateformes mobiles (téléphone ou tablette).
Les autres contraintes à respecter sont :
- un serveur multi-threadé de centralisation des données, écrit en Java et basé sur des sockets TCP.
- ce serveur interagit avec la BdD mongodb de deux façons : la principale est via un API REST écrite en node, la secondaire directement via l'API Java pour mongodb,
- un serveur d'analyse multimédia qui doit être différent du serveur de centralisation des données et qui ne doit pas être un serveur web type API REST (cf. ci-dessous)
- la BdD qui centralise les données est forcément mongodb,
- le front-end se fait avec vuejs, avec des graphiques/stats produits dynamiquement à partir de données de la BdD,
- le développement se fait en utilisant des processus d'intégration continue,
- les serveurs sont déployés sous la forme de conteneurs dockers, produits à la fin du processus d'intégration continue, si possible de façon automatique.
- le versioning + intégration continue se font via les serveurs gitlab et jenkins du département (NB : ce qui veut dire accès VPN si vous êtes à l'extéireur du réseau fac)
En dehors de ces contraintes, vous êtes libres d'adapter des éléments en fonction de votre application, notamment :
- le serveur d'analyse multimédia peut prendre la forme d'un serveur basé sur TCP (comme dans le prototype), écrit en Java/C/C++/node/pyhton/..., ou bien un serveur basé sur des websocket, ou encore un autre protocole, du moment qu'il ne fonctionne pas comme un serveur HTTP de type API REST. Le choix se fait en fonction du type de traitement qu'il doit faire et qui sera plus facile d'écrire dans tel ou tel langage. ATTENTION, ce choix impacte également la partie programmation mobile.
- la façon de programmer les plateformes mobiles peut être soit en natif avec android et/ou iOS, ou bien en hybride avec des framework tels que ionic ou quasar. En revanche, choisissez une solution adaptée au serveur d'analyse multimédia. Par exemple, le natif conviendra parfaitement à un serveur basé sur TCP, alors que l'hybride ne pourra fonctionner qu'avec un serveur basé sur des websockets.
- les graphiques dynamiques et les stats. affichés par le front-end peuvent être créés à l'aide de n'importe quelle bibliothèque JS
Du point de vue matériel, vous pouvez également faire varier :
- le nombre de µC et de mobile utilisés,
- le nombre et types de capteurs connectés aux µC,
- le nombre de plateforme mobile
pourvu que ce soit au moins 1 de chaque type (= au moins 1 type de capteur connecté à au moins 1 µC + au moins 1 téléphone/tablette). Si ce minimum est respecté, vous pouvez même utilisé d'autres sources de capture de données, comme par exemple des caméra IP, des montres, des frigos, etc. Le seul problème avec ce type de matériel est qu'ils sont généralement non programmables et peut être difficilement connectable à un serveur que vous implémentez vous-même.
Cette liberté implique que les types des données captées est laissé libre. Le mobile peut par exemple utiliser du son plutôt que des photos. Si possible, choisissez un contexte qui soit entièrement cohérent, c'est-à-dire où les données collectées via les µC et les plateformes mobiles servent un même but.
Remarques & conseils :
- Dans l'idéal, la partie serveur d'analyse doit être réellement implémentable, par exemple grâce à l'utilisation de opencv pour les images. Ne choisissez donc pas des analyses trop complexes, genre reconnaissance vocale. Cependant, cela peut venir en contradiction avec la consigne de cohérence de fonctionnalités mentionnée juste avant. Dans ce cas, privilégiez le fait que la partie analyse soit faisable. Le professeur référent pour cette partie (G. Perrot) pourra vous conseiller..
- Pour les capteurs reliés aux µC, vous devez vous baser sur quelque chose d'existant, à savoir qu'un nombre impressionnant de type de capteurs est disponible. Il suffit d'aller sur des sites marchands (genre gotronic, lextronic) pour le constater. Si votre contexte exige du matériel qui n'est pas disponible au département, l'équipe pédagogique verra s'il est possible de le commander et de l'avoir à un prix et délai raisonnable. Sinon, vous devrez simplement écrire du code qui simule le fonctionnement de ce matériel.
Quelques exemples de contexte :
- surveillance de présence dans des bâtiments, des manifestations,
- gestion d'une épreuve sportive (avec dossards pucés rfid et analyse photo finish)
- course d'orientation (boîtiers qui bipent quand on arrive près de l'objectif, et validation grâce à une photo de l'objectif)
- gestion d'un plateau d'emission de variété (boîtiers de type buzzer pour les quizz, enregistrement audio pour mesurer la rires/applaudissements/...)