Professional Documents
Culture Documents
1
ou via un accès par navigateur WEB) de manière à illustrer simplement des fonctionnements attendus
de machines (API) avec action/rétroaction de l’homme.
Contexte : cours de Grafcet s’appuyant sur un LMS (Moodle) ou un site web.
Contraintes : - accessibilité - pas d’installation complexe pour l’utilisateur (sinon un navigateur à jour
ou un simple téléchargement). - la solution permet une réaction dynamique sur action de l’utilisateur
(saisie, sélection, clic de souris, ou mouvement de souris) - multisupport (accessible ou lisible sur android
ou exécutable sur une simple pc (tout OS)
Enjeu : faire comprendre un fonctionnement habituellement décrit en texte et sans machine réelle
pour aider à la conception de GRAFCETs simples et la compréhension des E/S.
Fonctionnalité du produit : modification du monde virtuel à partir d’information monde réel (clic de
bouton maintenu ou pas, valeur de paramètre éventuellement, mouvement) avec déplacement de figures
symboliques ou photos (en x,y voire z) pour montrer le fonctionnement attendu. Les sorties sont donc
visuelles à partir de calcul simple (translation, rotation), avec simulation de chute ou versement. Le
contrôle est fait par l’application selon les valeurs d’E/S au départ et en cours de fonctionnement.
Exemple 1 : un objet percé et fraisé sur ordre, visualisation virtuelle des perçage et fraisage de
durée différente avec avance/retrait outils etc. de manière à voir la séquentialité et les actions parallèle.
Symbolisme : rectangle, couleur, tige. . .
Exemple 2 : fonctionnement vérins monostable ou bistable (translation tige etc), représentation de
bouton, interrupteur
L’idée serait la traduction de mes énoncés pour illustrer par du visuel de manière simple (sans chercher
à faire un outil de simulation) un comportement souhaité.
Résultats attendus (négociables) : produit fini correspondant à un fonctionnement directement ex-
ploitable produit plus générique modifiable ou adaptable éléments fonctionnels basiques faciles à relier
pour créer de nouveaux fonctionnements (mouvement, organisation, veille d’événements/actions) . . . (voir
enjeu)
Extension : visualiser le grafcet solution (sans passer par des outils type automgen compliqué), dans
les cas simples : déplacement jeton sur un graphe donné en fond d’écran
Enjeu : transposable à d’autres cas applications exemples ce qui requiert des mouvement de base
(translation, rotation) et des formes de bases (cube, cercle, tige, verin actionneur capteurs), le codage
doit alors être sur un système connu de moi ou facilement utilisable d’un point de vue fonctionnel
(assemblage).
Codes envisagés : Processing, java, html, code pour android autre
Si vous êtes intéressés par ce projet, n’hésitez pas à poser vos questions pour plus de précisions et à
me contacter pour un rendez-vous.
2
Pour gérer cette variété de situations (choix d’algorithmes, de matériel à utiliser, etc.), la librairie est
conçue de manière modulaire : des composants logiciels fournissent des fonctionnalité, et le système choisit
un des composants possibles en fonction de la situation. Ce choix se fait au moment de la compilation (est-
ce que le composant compile ?) et au moment de l’exécution (est-ce que les ressources dont le composant
a besoin sont disponible ? Quelle est l’adéquation du composant à la situation ?).
Les composants sont développés séparément, et peuvent être ajoutés en option. Ce système fonctionne
bien, la librairie est largement utilisée.
Le but de ce projet consiste 1) à étudier le fonctionnement de ce système de composant, à le décrire
précisément (en langage naturel) et 2) à l’extraire (ou à le reproduire) pour qu’il puisse servir dans le
cadre de nos propres projets de développement logiciel.
Le code de la librairie est écrit en C. Mais se frotter avec le système configure/make de la librairie
nécessite(ra) de naviguer dans des scripts shell, dans Autoconf/Automake/libtool, dans des macros m4,
et éventuellement des scripts perl.
Liens en rapport :
• http://www.open-mpi.org
• http://www.open-mpi.org/papers/workshop-2006/mon_06_mca_part_1.pdf
3
permet de jouer de la musique ou de choisir une chaine de télévision en fonction des émotions et de
lhumeur de lutilisateur (heureux, triste, en colère. . . ). Elle est codée en C#, utilise le casque Epoc
de la société EMOTIV (http ://www.emotiv.com/) et le brassard Bodywave de la société FreerLogic
(http ://www.freerlogic.com/). Lapplication repose sur un réseau neuronal pour le calcul des émotions
et de lhumeur.
Le travail à réaliser pour ce sujet 2 consiste à permettre lécoute soit des ses propres musiques (comme
cela est le cas actuellement), soit de se connecter à Deezer ou Spotify pour disposer dune bibliothèque
infinie de musiques (toujours choisies en fonction de ses émotions et de son humeur). Cela implique dune
part de créer le code associé à cette fonctionnalisé, mais également de rester ń connecté ż avec lapplication
actuelle pour permettre les deux usages.
Etant donné que ce sujet est en lien avec les deux autres sujets, il est vital que le binôme travaille en
étroite collaboration avec les binômes des autres sujets, tout au moins dans la première étape du travail.
Liens en rapport :
• Application de l’an passé http://youtu.be/BzoSQIoad7E
• casque EPOC http://www.emotiv.com
• brassard BodyWave http://www.freerlogic.com
4
données, - La recherche de données suivant certains critères tels que la proximité par exemple (les données
contiennent des coordonnées GPS), - Laffichage des données sur une carte Google. . .
Ces scripts seront associées à des pages web permettant la saisie des informations, ainsi que leur
affichage, tri, sélection, etc.
Liens en rapport :
• Cake PHP http://cakephp.org/
• Cake PHP, France http://www.cakephp-fr.org/
5
Contexte : Un outil de réparation automatique des logiciels résout des bugs automatiquement. Par
exemple, lon peut générer un patch quand un test passe au rouge [Weimer2009]. Il est aussi possible
déviter des crashes en production. La réparation automatique peut donc se passer à tous les moments du
cycle de vie : du développement à la maintenance et la production.
Problématique : La réparation automatique manipule soit du code (source ou binaire) soit des données
(létat à lexécution, comme la pile ou le tas). La réparation automatique utilise aussi bien des algorithmes
aléatoires (par exemple des algorithmes génétiques) que des solveurs (par exemple avec SAT ou SMT).
Létat actuel de la recherche ne permet pas comparer lefficacité de ces deux types dapproche.
Contributions attendues : Vous participerez au développement des outils de réparation automatique
de bug de léquipe Spirals [DeMarco2014]. Si le projet/stage est une réussite, ce travail donnera lieu à une
possible suite en stage de M2, puis thèse.
Compétences requises : Développement Java.
Bibliographie :
[Weimer2009] W. Weimer, T. Nguyen, C. L. Goues, and S. Forrest. Automatically finding patches
using genetic programming. In Proceedings of the International Conference on Software Engineering,
2009.
[qin2005rx] F. Qin, J. Tucek, J. Sundaresan, and Y. Zhou. Rx : treating bugs as allergies a safe
method to survive software failures. In ACM SIGOPS Operating Systems Review, volume 39, pages
235248. ACM, 2005.
[DeMarco2014] Favio DeMarco, Jifeng Xuan, Daniel Le Berre, Martin Monperrus. Automatic Repair
of Buggy If Conditions and Missing Preconditions with SMT, In Proceedings of the 6th International
Workshop on Constraints in Software Testing, Verification, and Analysis (CSTVA 2014)
[Monperrus14] Martin Monperrus. A Critical Review of Automatic Patch Generation Learned from
Human-Written Patches : Essay on the Problem Statement and the Evaluation of Automatic Software
Repair, In Proceedings of the International Conference on Software Engineering, 2014.
6
pêche lorsque le niveau des ressources diminue trop. À terme : prise en compte d’éléments économiques
dans la prise de décision (demande sur une espèce, coût de l’énergie. . . )
Hébergement et encadrement : Ce projet se déroulera au sein de l’équipe SMAC du LIFL/CRISTAL
(Lille 1), qui est spécialisée dans la modélisation de comportements d’agents et de phénomènes collectifs.
Il sera co-encadré par S. Picault (LIFL, Lille 1) pour l’expertise multi-agents et C. Largouët (IRISA,
Agrocampus Rennes) pour l’expertise écosystèmes et la scénarisation.
Liens en rapport :
• sujet complet PDF http://www.lifl.fr/~picault/stages/2015-projet-M1-SMAC-peche.pdf
• plateforme NetLogo http://ccl.northwestern.edu/netlogo
• extension IODA pour NetLogo http://www.lifl.fr/SMAC/projects/ioda/ioda_for_netlogo/
7
trop généraux tendent à retourner de longues listes darticles tandis que des mots clés trop précis peuvent
donner lieu à lomission de nombreux résultats pertinents.
Dans de nombreux cas, les chercheurs travaillent à partir dun petit nombre darticles quils jugent très
pertinents au regard des travaux quils mènent. Ce sont ces articles qui leurs servent notamment de point
de départ pour trouver dautres articles connexes au sujet quils traitent. À limage de la recommandation
de livres proposée par Amazon sur son site en ligne, nous souhaitons donc mettre en place un service
capable de recommander des publications scientifiques à partir dun jeu darticle.
PROJET Dans le cadre de ce projet technique, lobjectif est de mettre en uvre dans un premier
temps un service de recommendation darticles scientifiques qui est capable dextraire les principaux sujets
abordés par un jeu darticles sélectionnés par un utilisateur en utilisant lalgorithme LDA (Latent Dirichlet
Allocation) mis à disposition par la librairie Mahout [2] ou MLlib [3]. Ces sujets sont extraits sous la
forme dune séquence de mots clés qui pourront être ensuite soumis à des moteurs comme Google Scholar
pour trouver dautres articles pertinents sur le sujet.
Dans un deuxième temps, ce service pourra aussi être utilisé pour produire automatiquement une
cartographie des articles collectés (e.g., sous la forme dun graphe) et ainsi mieux comprendre la nature
de leurs liens (mots clés en commun, auteurs en commun, article référençant un autre, etc.).
Liens en rapport :
• 1 - DBLP http://www.dblp.org
• 2 - Apache Mahout https://mahout.apache.org
• 3 - Spark MLlib https://spark.apache.org/docs/latest/mllib-guide.html
8
LIEU Spirals Research Group Inria Lille - Nord Europe Parc Scientifique de la Haute Borne 40, avenue
Halley - Bat. B, Park Plaza 59650 Villeneuve d’Ascq - FRANCE
CONTEXTE APISENSEő [1] est une plate-forme logicielle permettant de fédérer les téléphones du-
tilisateurs volontaires pour collecter des jeux de données significatifs dans la nature en interagissant avec
ces utilisateurs (questionnaires) ou en partageant les données produites à partir de leurs capteurs. Cette
plate-forme est notamment utilisée dans le domaine des telecoms pour mesurer la qualité de laccès à
Internet, ou dans le domaine du développement durable pour estimer lempreinte carbone des usagers en
fonction de leurs déplacements.
Avec lémergence de lInternet des Objets, de nombreux équipements ńconnectésż ont vu le jour (brace-
lets, capteurs domotiques [2], etc.) et peuvent se connecter aux téléphones des usagers pour synchroniser
leurs données. Le téléphone ne joue plus uniquement le rôle de capteur mais aussi de relais de linformation.
Nous souhaiterions donc permettre aux utilisateurs dAPISENSEő de collecter non seulement des données
issues des téléphones mais aussi des données provenant déquipements tierces connectés à ce téléphone.
PROJET Dans le cadre de ce projet technique, lobjectif est détudier le cas de la technologie Arduino
qui permet de concevoir ses propres objets connectés. En particulier, nous souhaitons offrir à la com-
munauté Arduino la possibilité de publier les données issus de nimporte quel capteur (gaz, lumière, son,
etc.) sur lInternet via une connexion Internet qui serait mise à disposition par le téléphone (e.g., via son
interface Bluetooth). Lobjectif est donc de développer un kit de développement (SDK) pour Arduino qui
permette de publier des données de manière passive (à la demande du téléphone) ou réactive (à linitiative
du capteur Arduino). Ce kit de développement sera illustré sur le cas dune application de surveillance de
la qualité de lair qui pourra être déployée à léchelle de luniversité.
Liens en rapport :
• 1 - APISENSEő http://www.apisense.com
• 2 - Air.Air ! http://www.airair.info
• 3 - Arduino http://arduino.cc
9
Le contexte du projet est l’équipe de développement logiciel du système d’information de Polytech Lille.
Cette équipe développe des applications webs (PC et mobiles) pour la gestion de scolarité, et différents ser-
vices de l’école. Les technologies employées sont : HTML5, CSS, Javascript, Jquery, PHP Objet, Postgres.
Une activité récurrente du développeur consiste à écrire un formulaire web avec des fonctions d’aide de sai-
sie et vérification javascript (datepicker, vérification champ mail, etc) puis à stocker les informations saisies
dans une base de données. L’objectif du projet est de proposer une architecture (PHP/CSS/javascript) qui
va offrir au développeur une API PHP qui va générer automatiquement l’éditeur ainsi que la sauvegarde
des données saisies dans une table. Le code PHP pourrait ressembler à ceci : ———————————-
$gen=new GenerateurFormulaire() ; $gen->setBD(serveur,nomBase, user, password) ; // connexion base
$gen->seTable(nomTable) ; // définition de la table de la base $gen->addChamp(nom, Nom :) ; //param
1 : nom de colonne,param2 : label $gen->addChamp(prenom,Prenom :) ; $gen->addChamp(datenaissance,
Date de Naissance : ) ; $gen->addChampSpecifique(email, Email : ,EMAIL) ; $gen->show() ; —————
——————- Le programme consultera dans la base le type de la colonne de chaque champ à éditer et
générera l’éditeur HTML approprié (textfield, checkbox, date, etc) Cet outil permettra aussi de générer
des composants HTML <select>lors de clés étrangères.
Ce projet pourra devenir un projet Open Source car il peut être appliqué dans beaucoup de systèmes
d’information
10
L’équipe de recherche en bioinformatique Bonsai est spécialisée dans la conception d’algorithmes efficaces
pour l’analyse de données biologiques. En collaboration avec des microbiologistes du laboratoire ProBio-
GEM, des membres de l’équipe ont conçu Norine (http ://bioinfo.lifl.fr/norine/), une base de données
de molécules particulières appelées peptides nonribosomiques. Ces peptides ont des activités variées et
certains sont déjà utilisés comme médicaments tels que la pénicilline qui est un antibiotique ou l’acti-
nomycine D qui est un anticancéreux. Lors de la découverte d’un nouveau peptide, il est intéressant de
pouvoir prédire son activité par analyse informatique et, ainsi, limiter les expérimentations. Les données
contenues dans Norine sont exploitables par des techniques classiques d’apprentissage automatique afin
de prédire l’activité d’un peptide inconnu. Des membres de l’équipe Bonsai ont déjà mis au point une re-
présentation des peptides nonribosomiques pertinente pour la prédiction de leur activité (voir article [1]).
Mais, il reste encore à finaliser le protocole de prédiction en affinant les jeux d’apprentissage à utiliser, en
choisissant la méthode d’apprentissage la plus adaptée et en déterminant ses paramètres optimaux. L’uti-
lisation de la bibliothèque Weka est préconisée. Il faut également développer l’interface d’interrogation
via Internet qui prendra en entrée un peptide inconnu et affichera ses activités potentielles.
Proposition de planning : - prise en main de la Bibliothète Weka, - extraction des caractéristiques des
peptidiques depuis la base Norine - apprentissage/validation croisées selon les modèles proposés dans [1]
- mise en place d’une interface de prédiction sur le serveur Norine
[1] A new fingerprint to predict nonribosomal peptides activity. Abdo A, Caboche S, Leclere V, Jacques
P, Pupin M. J Comput Aided Mol Des. 2012 Oct ;26(10) :1187-94
Liens en rapport :
• Base de données Norine http://bioinfo.lifl.fr/norine
11
les questions orales ou écrites posées aux ministres. On pourra aussi chercher, quand elle nexiste pas, à
constituer une base de données avec ces informations afin de la mettre à disposition du public.
Si, pour la législature actuelle et la précédente, ces données sont disponibles directement et dans un for-
mat facilement accessible, cest moins vrai quand on remonte dans le temps (voir [ici](http ://archives.assemblee-
nationale.fr/1/cri/1-1961-1962-ordinaire1.asp) pour les débuts de la cinquième République), ou même
[là](http ://archives.assemblee-nationale.fr/10/cri/10-1995-1996-ordinaire1.asp) plus récemment, car la
plupart des textes sont stockés sous forme de pdf. Il faudra donc mettre en place un protocole dextrac-
tion en fonction de la qualité de ceux-ci, comme des changements de format (peu fréquents heureusement)
du journal officiel.
## Les usages des réseaux sociaux
Comment communiquent les élusăà lère du numériqueă? Ce projet consiste à créer un système qui
permettrait de collecter quotidiennement des informations depuis Twitter et/ou Facebook (nombre de
personnes qui suivent ou amis, nombre de ńăretweetsăż ou ńălikesăż, nombre de personnes suivies, vo-
lume et contenu des dinformation partagées en fonction des plateformes, etc.). Ces informations seraient
stockées dans une base de données mise à jour automatiquement. On pourrait par la suite explorer ces
résultats via une interface simple qui donnerait à voir les principales tendances et leurs évolutions dans
le temps.
## Lindiscipline de vote
Si le mouvement des ńăfrondeursăż du Parti Socialiste a reçu ces derniers temps une attention mé-
diatique importante, lindiscipline de vote est elle relativement régulière à lAssemblée comme au Sé-
nat. Lobjectif de ce projet est de partir des comptes-rendus des scrutins publics publiés sur les sites
de ces deux institutions pour mesurer, [hier](http ://www.assemblee-nationale.fr/12/scrutins/table-2006-
2007.asp) comme [aujourdhui](http ://www2.assemblee-nationale.fr/scrutins/liste/%28legislature%29/14),
lintensité et les formes du vote ńăcontre son partiăż. In fine, ce projet permettra daboutir à une meilleure
caractérisation de lindiscipline (entre partis, dans le temps, et de ses formes).
Liens en rapport :
• Version html du projet, avec les liens fonctionnels http://www.lifl.fr/~hym/s/parlementaires.
html
12
Visualisation des structures et de leurs évolutions, détection de propriétés : Pour apporter un éclai-
rageănouveau à des questions classiques de sociologie des sciences, on pourrait aussi proposer des tech-
niques de recherche de régularités dans les données. Un outil de visualisation pourrait être mis en place
afin de permettre une phase dexploration plus aisée, ou de réaliser des sorties graphiques de certains
résultats. Il serait aussi intéressant de proposer un logiciel qui rende plus accessibles les requêtes sur les
données notamment pour y détecter des propriétés.
Le code produit sera diffusé sous licence libre [CeCILL].
Liens en rapport :
• Version html du projet, avec les liens fonctionnels http://www.lifl.fr/~hym/s/socio%20citations.
html
13
Sujet 58 : Produire de la musique en temps réel
Auteur : Giuseppe Lipari
Responsable : Giuseppe Lipari
Pour produire de la musique de qualité professionnelle avec un ordinateur (MAO, Musique Assistée
par Ordinateur), il est nécessaire d’utiliser des outils logiciels spécifiques. Par exemple, l’outil JACK
(http ://jackaudio.org/) permet de manipuler des flux (streams) audio en temps réel de manière très
simple. Il est ainsi possible de faire de l’enregistrement audio multipiste et du MIDI simultanément.
Le traitement temps réel des flux audio est très sensible à la latence. Pour utiliser JACK de manière
optimale, il est donc nécessaire de configurer le noyau pour une utilisation temps réel.
Même en utilisant un noyau configuré pour le temps réel et un ordonnancement à priorités fixées, il
n’est pas simple d’obtenir de bons résultats.
Un premier problème est que l’ordonnanceur temps réel requiert les droits d’administration du système
(root). Par conséquent, si des processus avec des priorités temps réel s’exécutent sans jamais s’interrompre,
les autres processus ne s’exécutent jamais : ils souffrent de famine (starvation). Un deuxième problème
est qu’il n’est pas simple de choisir la priorité à affecter aux différentes tâches concurrentes temps réel.
Pour permettre à un utilisateur sans les droits d’administrateur d’utiliser les fonctionnalités temps
réel, il faut empêcher qu’un processus obtienne le contrôle exclusif du processeur. Le nouvel ordonnanceur
SCHED_DEADLINE, disponible dans le noyau Linux à partir de la version 3.14, à été conçu pour
répondre en partie à ce problème. Avec SCHED_DEADLINE, il est possible de contraindre le temps
d’exécution d’une tâche à respecter un quota correspondant à une fraction du temps d’exécution total du
processeur. De plus, avec SCHED_DEADLINE l’utilisateur n’a pas besoin de spécifier les priorités des
tâches (elles sont calculées par l’ordonnanceur).
L’objective est donc de concevoir et réaliser un architecture logiciel pour gérer la qualité du service
des applications multimedia sur Linux, basée sur le nouveau ordonnancer SCHED_DEADLINE.
Cet objectif final ambitieux dépasse vraissemblablement le cadre de ce projet. On propose donc de
concevoir un ensemble de petits outils, chacun simple et extensible.
- Un outil pour mesurer les temps d’exécution des taches gérés par SCHED_DEADLINE. On peut
utiliser le module https ://github.com/balsini/sched-deadline-spy comme point de départ.
- Un outil pour contrôler l’admission de nouvelles tâches temps réel. L’outil est un processus daemon
qui s’exécute avec des droits root et s’interface avec les tâches. Si une tâche demande à être gérée par
l’ordonnancer SCHED_DEADLINE, elle envoie une requête au processus daemon qui vérifie qu’il reste
suffisament de quota processeur pour accepter la requête. Si la réponse est positive, la tâche est acceptée ;
sinon, la tâche est rejetée.
Les outils développés pendant le projet seront validé sur l’application JACK.
Compétences : Une connaissance dun ou plusieurs des concepts suivants serait un plus : bon niveau
de programmation en C/C++, programmation système, programmation concurrent et parallèle, configu-
ration et compilation du noyaux Linux.
Liens en rapport :
• L’outil JACK http://jackaudio.org/
• Kernel module pour mesurer le temps d’execution https://github.com/balsini/sched-deadline-spy
14
pièce qui créerait faussement un lien entre deux zones très éloignées. Il est souhaitable, et conceptuel-
lement possible, de détecter et supprimer de telles lectures. Comme les séquenceurs PacBio sont très
récents, la détection des chimères est un aspect encore peu étudié.
Lobjectif du projet est de comprendre, tester et éventuellement produire des méthodes pour la détec-
tion de chimères. Le projet commencera par lanalyse de la méthode non documentée implantée dans le
pipeline HGAP de PacBio puis se poursuivra par limplémentation dautres techniques en comparant les
performances. On pourra aboutir à un nouveau protocole plus efficace de détection de chimères.
Profil souhaité : Motivation pour lanalyse de données bioinformatiques. Programmation en Python
(langage dans lequel HGAP est implémenté). Aucune connaissance en biologie nest requise pour aborder
ce sujet.
Liens en rapport :
• Principe du séquençage ADN PacBio https://www.youtube.com/watch?v=v8p4ph2MAvI
• Papier HGAP (nous contacter pour obtenir un PDF) http://www.nature.com/nmeth/journal/
v10/n6/full/nmeth.2474.html
• Article évoquant la détection de chimères PacBio http://www.biomedcentral.com/1471-2164/
15/720
15
Nous proposons dans ce sujet de développer des modèles et interfaces graphiques permettant aux
jardinier amateurs de concevoir leur potager en respectant cette notion de compagnonnage des plantes.
On s’appuiera par exemple sur les données fournies en [1], qui résument les affinités entre plantes en
terme de voisinages propices ou néfastes.
Les objectifs méthodologiques du PJI sont les suivants :
Développement de formats de fichiers, structures de données et interfaces graphiques définissant : -
Le choix des espèces à cultiver dans un potager, - La forme du potager et des espaces non cultivables
(chemins, mares, arbres, locaux, etc.), - Les voisinages propices ou néfastes entre couples de plantes, - La
représentation graphique d’un potager.
Développement d’algorithmes de résolution du problème : - les étudiants modéliseront le problème
sous la forme d’un problème d’optimisation, par exemple inspiré des problèmes du sac à dos, problèmes
de bin packing, problèmes de coloration de graphe, etc., où il s’agira de placer les plantes de manière à
maximiser les affinités de chacune avec leurs voisines immédiates. - Les étudiants implémenteront enfin des
algorithmes d’optimisation (algorithme glouton, recherche locale itérative, etc.) permettant de calculer
les répartitions optimales d’un ensemble de plantes dans un potager donné.
Encadrants : Samuel Blanquart et Bilel Derbel
Liens en rapport :
• associations de plantes http://www.homejardin.com/coup_de_pouce_compagnonnage/aide_conseil_
assistance_explications.html
16
Les technologies utilisées sont principalement le langage de programmation scala (fonctionnel et objet
tournant sur la JVM) et la bibliothèque d’acteurs Akka. L’analyse des résultats pourra se faire avec
python ou scala.
Liens en rapport :
• Site de l’équipe Émeraude http://www.lifl.fr/emeraude
• Langage Scala http://www.scala-lang.org/
17
Sujet 70 : Serveur de jeux tour par tour
Auteur : Yoann Dufresne Et Gauvain Marquet
Responsable : Yoann Dufresne Et Gauvain Marquet
L’an passé nous avions soumis en PJI la création d’un modèle de jeux tour par tour (voir les liens). Ce PJI
ayant très bien fonctionné, nous disposons à présent d’un programme de base (voir le lien sourceforge)
permettant d’implémenter un jeu tour par tour quelconque. Ce modèle est accompagné de toute la
documentation permettant de réaliser le jeu en partant de la conception du modèle par dessus le méta-
modèle jusqu’à l’implémentation des échanges réseaux nécessaires.
Dans l’état actuel, le méta modèle peut facilement être utilisé pour la conception de jeux et les jeux
implémentés peuvent facilement héberger chacun une partie. Une partie lancée est un modèle indépendant
qui écoute sur un port les commandes qui lui sont passées via n’importe quel moyen par un protocole
défini durant la conception du jeu. Une fois la partie terminée, le programme quitte.
L’idée ici est de faire un autre composant logiciel (un service) capable de repérer les différents jeux im-
plémentés et de proposer d’instancier des parties. On pourra également imaginer un troisième composant
logiciel permettant d’interagir avec avec le serveur via une interface web.
Ce projet sera développé sous licence libre (gpl) et demandera absolument la contribution d’un binôme.
Liens en rapport :
• Sujet du travail de l’année passé (sujet 39) http://www.lifl.fr/~salson/pji-sdl/listeprojetsPJI2013-2014.
pdf
• Sourceforge du projet https://sourceforge.net/projects/pftpt/
18
Sujet 74 : Modification de l’hyperviseur Xtratum
Auteur : Julien Iguchi-Cartigny
Responsable : Julien Iguchi-Cartigny
Xtratum est un hyperviseur (pour permettre la virtualisation) conçu pour les architectures LEON3 (pour
les satellites). Il est minimaliste, dans le sens où de nombreuses structures sont statiques après le démar-
rage (nombre de machines virtuelles, allocation mémoire, ordonnanceur).
Nous développons dans notre équipe un dispositif physique permettant de détecter un nombre impor-
tant de lecture et d’écriture de la part d’une machine virtuelle. Si un tel événement se déclenche, alors
une interruption est produite à destination de l’hyperviseur.
Le but de ce projet est d’écrire la partie du code dans Xtratum gérant l’interception de cet interruption
et la prise de mesure associé (arrêt de la machine virtuelle fautive).
langages : c et un petit peu d’assembleur sur architecture SparcV8. Si vous aimez la programmation
système, ce sujet est pour vous.
Liens en rapport :
• XtratuM http://www.fentiss.com/en/products/xtratum.html
• Leon3 http://www.gaisler.com/index.php/products/processors/leon3
19
Smews est un serveur web embarqué développé par l’équipe 2XS. Sa particularité est d’être conçu pour
fonctionner sur des équipements aussi petits que des cartes à puces.
A l’heure actuelle, Smews permet de développer des applications web qui utilisent les méthodes GET
et POST. Pour permettre aux utilisateurs de concevoir des application REST, il lui manque de pouvoir
supporter les autres méthodes du protocole HTTP que sont HEAD, OPTIONS, PUT et DELETE.
Le but du projet et donc d’implémenter, au sein de smews, la gestion de ces méthodes.
Le développement sera effectué en C et en Python. Si le temps le permet, une application web de
démonstration utilisant une API REST pourra être développée (par exemple en utilisant Angular.js)
Liens en rapport :
• Site web de Smews http://www.lifl.fr/2XS/smews
• Dépôt Smews sur github http://github.com/2xs/smews
20
Liens en rapport :
• Exemple de portail à Mérignac http://leon.merignac.com
• Le projet emblématique du domaine (Grande-Bretagne principalement) http://fixmystreet.org/
• Une autre proposition http://www.leproblemedemarue.fr/
21
• Carte Jetson Tegra K1 https://developer.nvidia.com/jetson-tk1
• Projet PowerAPI http://powerapi.org
22
Sujet 90 : Un bugtracker pour geeks et non-geeks
Auteur : Mathieu Giraud
Responsable : Mathieu Giraud
Un bugtracker permet de créer et éditer des tâches, avec des priorités, des mots-clé, des dates limites
éventuelles, des commentaires, des références croisées à des tâches ou à des commits dun gestionnaire de
version. C’est un outil qui peut servir à la fois en suivi de code mais aussi en gestion de projet d’équipe.
Faire cohabiter sur une même application des utilisateurs avec des expertises très différentes est toujours
un défi. On souhaiterait réaliser un bugtracker dont les fonctionnalités seraient accessibles :
- dun côté, pour des utilisateurs normaux, par une interface web élégante,
- de lautre, pour des utilisateurs préférant le terminal, vi, emacs ou d’autres éditeurs, par un fichier
texte, brut, par exemple encodé en org-mode, éditable hors connexion.
Certains bugtrackers proposent déjà une API avec laquelle on pourrait extraire ce type de fichier
texte, mais cela reste délicat davoir un accès correct à toutes les fonctionnalités, et encore plus de pouvoir
modifier des tâches sans être connecté. Le but de ce projet est donc de réaliser un prototype de bugtracker
an ayant une approche radicalement différente, où le fichier texte, directement éditable par lutilisateur
non-web, constitue le format principal de stockage. La synchronisation avec le serveur pourrait se faire
par des commits / push sur un serveur git. Le serveur web interprète ce fichier (ou les commits) et gère,
si besoin, une base de données locale.
Technologies : git, python, framework web à déterminer, bootstrap.js
Liens en rapport :
• MantisBT, un bugtracker libre http://www.mantisbt.org
• Producteev, un bugtracker pas libre http://www.producteev.com
• org-mode http://orgmode.org
23
capteurs. Nous nous intéressons à une classe spécifique dactions qui correspondent à la manifestation des
émotions telles que la joie, la tristesse, lénervement. La reconnaissance démotion peut servir dans diffé-
rents domaines impliquant de linteraction homme-machine tels que dans lindustrie du commerce (tables
de vente interactives), dans laide des personnes à domicile, etc.
Léquipe FOX sintéresse de manière générale à lextraction des informations de la vidéo et à des
applications au comportement humain. Dans nos travaux passés, nous avons déjà exploré lextraction des
émotions de base (telle que la joie, cf. image ci-dessous) à partir des images en utilisant uniquement des
informations statiques telles que les distances entre les régions significatives du visage (sourcils, yeux,
nez, bouche, etc.). Si ces informations sont suffisante pour caractériser des émotions simples et plutôt
statiques telle que la joie. En effet, dès que lon aperçoit le visage dune personne nous pouvons de rendre
compte si la personne exprime la joie. Cependant, elles ne suffisent plus lorsque lon étudie des émotions
plus complexes telles ques lintérêt. Nous croyons que lapport informationnel issu de létude du mouvement
de la personne dans sa globalité peut augmenter de manière importante la détection des émotions et la
quantification de leur intensité.
24
La mission principale consiste en la réalisation d’un état de l’art sur la manière dont les mouvements
occulaires et les mouvements présents dans la zone peri-occulaire peuvent être interprétés afin d’inférer
l’état d’une personne. Un travail d’adaptation d’un prototype existant est également envisagé pour tester
la validité des métriques proposées.
25
Sujet 103 : Extraction de données contextuelles dans tweeter
Auteur : Luigi Lancieri
Responsable : Luigi Lancieri
Un des thèmes de recherche de l’équipe Noce du LFL est la mesure du facteur humain dans les réseaux
sociaux tels que tweeter.
L’objectif du projet est d’explorer les moyens de récupérer de manière indirecte des informations liées
aux tweets. Citons par exemple la tranche d’age de l’usager, sa catégorie socio-professionnelle ou ses
centres dintérêts. Ces informations ne sont pas présentes explicitement dans tweeter mais il est possible
de trouver des indices avec le contexte de chaque tweet. Par exemple, un usager utilisant souvent du
vocabulaire lié au sport est probablement intéressé par le sport.
Travail à réaliser Réaliser un état de l’art sur les modes d’extractions de données contextuelles sur le
web et plus spécifiquement sur tweeter. Réaliser un petit démonstrateur permettant de montrer lintérêt
de la collecte d’indices contextuels.
26
CONTEXTE
L’équipe 2XS est hébergé par lInstitut de Recherche en Composants logiciel et matériel pour lInfor-
mation et la Communication Avancée (IRCICA, une Unité de Service et de Recherche : USR-3380) qui
associe le CNRS et lUniversité Lille 1. Au sein de ce laboratoire des équipes de recherche de domaines
différents collaborent sur des travaux pluridisciplinaires. Dans ce cadre, l’équipe 2XS (informatique) tra-
vaille avec l’équipe CSAM (électronique). Nous nous intéressons notamment aux liens qui existent entre
l’énergie que dissipent les microcontrôleurs et les programmes qu’ils exécutent.
PROJET
Dans le cadre de ses travaux, l’équipe CSAM a développer une maquette lui permettant de mesurer
la différence entre un signal radio reçu, et celui qui a été émis. Il a été démontré que l’environnement
à un fort impact sur cette mesure. Nous souhaitons maintenant reprendre cette démarche et étudié très
précisément l’impact de l’exécution d’un programme cryptographique sur le signal radio reçu. Il a déjà
été démontré dans des articles scientifique que l’écoute passive du son produit par un microprocesseur,
avec un simple microphone, pouvait constituer une fuite d’information, et compromettre la sécurité du
chiffrement. Nous envisageons de faire de même avec la maquette conçu par l’équipe CSAM.
L’objet de ce projet technique est donc (1) la prise en main de la maquette de mesure réalisée par
l’équipe CSAM ; puis (2) la prise en main de l’implémentation du chiffrement RSA dans un microcon-
trôleur MBed ; et enfin (3) l’observation statistique et la corrélation des résultats issus des mesures de la
maquette, lorsque le système cryptographique est opérant.
Liens en rapport :
• équipe CSAM http://www.ircica.univ-lille1.fr/spip.php?rubrique12
• équipe 2XS http://www.lifl.fr/2XS/Team/Members
• Article d’attaque de RSA à l’aide d’un micro. http://www.tau.ac.il/~tromer/papers/acoustic-20131218.
pdf
27
On s’attachera dans ce projet aux aspects mobiles, un autre PJI assurant le développement du portail
proprement dit.
Il s’agira, en fonction du cahier des charges qui est le nôtre, et qui restera à affiner ensemble 1-
d’évaluer, d’étudier les propositions existantes (en particulier en terme de fonctionnalité, d’ergonomie,
de paramétrisation) 2- développer (éventuellement à partir de codes existants) une première version
fonctionnelle d’une application mobile de remontée de problème 3- faire lien avec le portail développé
sans cadre dun autre PJI
On s’attachera à une démarche agile pour assurer une prise en charge incrémentale et progressive
des fonctionnalités, des besoins. On fournira aussi le résultat de notre travail sous licence libre, gage de
qualité et de pérennité des développements.
Ce projet est un clone Android du PJI 82 qui lui sattachera au développement iOS. On travaillera
bien entendu en collaboration dans un esprit de mutualisation.
Une expérience préalable de développement Android serait bienvenue.
Liens en rapport :
• Application mobile de géolocalisation de problèmes (et de solutions !) http://www.lifl.fr/~salson/
pji-sdl/projet.php?id=82
28
PROJET
Il sagira donc de débuter ce projet par un état de lart des possibilités existantes afin de positionner
celui-ci et de définir précisément les attentes des usagers quant à son utilisation. Dans un second temps
et à partir d ! es spécifications, il sagira de développer lapplication dans une optique multi-plateformes,
en utilisant le framework PhoneGap notamment. Les fonctionnalités principales engloberont la gestion
dune liste de contacts, les demandes de localisation et la génération ditinéraires.
29
Exemple 2 : plateau ou tapis indexé
Exemple 3 : un objet percé et fraisé sur ordre, visualisation virtuelle des perçage et fraisage de
durée différente avec avance/retrait outils etc. de manière à voir la séquentialité et les actions parallèle.
Symbolisme : rectangle, couleur, tige. . .
L’idée serait la traduction de mes énoncés pour illustrer par du visuel de manière simple (sans chercher
à faire un outil de simulation) un comportement souhaité.
Résultats attendus (négociables) : produit fini correspondant à un fonctionnement directement ex-
ploitable produit plus générique modifiable ou adaptable (java dans ce cas) éléments fonctionnels ba-
siques faciles à relier pour créer de nouveaux fonctionnements (mouvement, organisation, veille d’événe-
ments/actions) . . . (voir enjeu)
Extension : visualiser le grafcet solution (sans passer par des outils type automgen compliqué), dans
les cas simples : déplacement jeton sur un graphe donné en fond d’écran
La solution technique imposée est : javascript, java pour intégration html (transparente pour l’utili-
sateur), code pour android encapsulé avec tutoriel se réalisable.
Si vous êtes intéressés par ce projet, n’hésitez pas à poser vos questions pour plus de précisions et à
me contacter pour un rendez-vous.
30
Sujet 123 : [ALTERNANT] étudiant :Arthur-Guilhem De Bus-
schere & entreprise :Payplug
Auteur : Stephane Planquart
Responsable : Philippe Marquet
31
Sujet 130 : [ALTERNANT] étudiant :Antonin Noel & entreprise :Ge-
nesio
Auteur : Benjamin Envent
Responsable : Philippe Marquet
32