Archives 2016

Du régulateur de James Watt à ma thèse

« Sinon, tu travailles sur quoi exactement ? »

J'aime bien cette question, savoir que quelqu'un s'intéresse à mon travail est très gratifiant, pourtant, je la redoute : comment vulgariser suffisamment sans trop simplifier, ou comment donner assez de détails sans se perdre dans des périphrases incompréhensibles.

L'exercice est périlleux, alors je me lance.

Du régulateur de James Watt à ma thèse.

Un peu d'histoire

Pour réguler automatiquement la vitesse de sa machine a vapeur et ainsi avoir une vitesse la plus constante possible, James Watt (1), a inventé un système très ingénieux : il fixa à une tige, entrainée par la machine, deux boules en métal au bout de bras. Ainsi, plus la tige va vite, plus les deux boules s'écartent. Les bras maintenant les boules étant reliés au robinet d'alimentation en vapeur, la hauteur des boules fait varier l'arrivée en vapeur : la vitesse agit sur l'arrivée de vapeur, il y a rétroaction.

Le régulateur à boule de James Watt. Vue d'artiste très talentueux.
Le régulateur à boules de James Watt.

Aujourd'hui, cette science de la régulation (ou contrôle) s'appelle l'automatique. On parler alors d'actionneur (le robinet), de capteur (les deux boules en métal pour capter la vitesse) et une boucle de rétroaction : la machine a vapeur qui fait varier sa vitesse en fonction du débit de vapeur.

Bien sûr, les systèmes entièrement mécaniques sont rares et l'invention de l'électronique, puis de l'informatique ont permis des systèmes beaucoup plus complexes et performants. Il existe donc des programmes (logiciels) de contrôle.

(1) Cet exemple vient de l'article From Control Loops to Real-Time Programs de Paul Caspi and Oded Maler (Verimag-CNRS, 2005).

Les systèmes critiques, temps réel dur

Certains systèmes contrôlés sont très critiques : un fonctionnement anormal peut avoir des conséquences graves (humaines, écologiques, etc). Les exemples souvent cités sont les commandes de vol d'un avion, ou les systèmes de sécurité d'une centrale nucléaire, mais aussi dans les voitures (que dire de la voiture « autonome » ?).

Dans le cas d'un avion, les actionneurs sont les ailerons et les élévateurs de l'avion, des capteurs mesurent l'altitude, ou les commandes du pilote par exemple. Entre ces capteurs et ces actionneurs, il n'y a plus de systèmes à boules, mais un ordinateur qui calcule la position des actionneurs en fonction de la valeur des capteurs (après numérisation) : la position de l'élévateur, en fonction des entrées.

Une caractéristique de ces systèmes critiques est que le temps fait partie intégrante du cahier des charges : on imagine difficilement le système de contrôle demander au pilote d'attendre la fin du chargement pour rétablir la trajectoire de l'aéronef (!) ou que l'altitude de l'avion soit momentanément traitée 10 secondes plus tard.

Les langages synchrones

Peu après 1989, le besoin d'avoir un langage permettant de rendre le développement de programmes de contrôle plus facile s'est fait sentir. Il fallait un langage pouvant être compris par les automaticiens et qui intègre une notion de temps pour faciliter le développement de tels programmes.

Entre 1991 et 1992, trois langages sont apparus : Lustre, Signal et Esterel.

« Bien. Et donc, tu travailles sur quoi exactement ? »

Les langages synchrones sont très utilisés actuellement pour la programmation de systèmes de contrôle. Cependant, pour rendre les systèmes plus performants, plus confortables, plus complets, etc, ces programmes se complexifient.

Depuis une dizaine d'années, les processeurs arrivent à leurs limites : il n'est plus possible d'augmenter la performance sans augmenter énormément la consommation. Ainsi, sont apparus les processeurs multi-cœurs (contenant plusieurs processeurs) offrant de meilleurs performances pour une consommation moindre.

Cependant, ces processeurs récents sont très complexes et rendent les temps de calculs très difficiles à prévoir (certains comportements sont même aléatoires) : alors que justement, le temps est très important pour le contrôle !

L'entreprise Kalray conçoit un processeur many-cœurs qui permet de prévoir (de manière pas trop pessimiste) ces temps de calcul.

Mon sujet de thèse est donc : comment faire tourner ces programmes de contrôle sur le Kalray MPPA.

Vers le doctorat

Depuis octobre 2015, je suis en thèse CIFRE. C'est un contrat entre un doctorant, une entreprise et un laboratoire. Je passe donc 3 jours chez Kalay, une entreprise qui conçoit et commercialise un processeur many-core. Un many-core est une puce (SoC) composée de plusieurs processeurs reliés par un réseau. Ainsi, deux jours par semaine, je suis chez Verimag, un laboratoire de recherche dont les sujets principaux sont la vérification de programme et les langages synchrones. C'est une courte introduction, mais je compte écrire un article pour détailler un peu ces notions.

Voici le début d'une série d'articles introduisant ma thèse. Je consacre le premier aux décisions qui m'ont conduites à la recherche.

Passage par le master recherche

J'ai été étudiant à l'Ensimag (Grenoble INP) pendant 3 ans, jusqu'à l'été 2015. Durant le second semestre de la 2ème année, j'ai consacré un après-midi par semaine chez Verimag à un stage recherche. Cette expérience m'a donné envie de m'inscrire en Master 2 recherche (M2R) en septembre 2014. Ensuite, j'ai passé l'été 2014 chez SAP à Walldorf (j'ai écris un article), ce n'était pas un stage recherche, mais très R&D quand même car je travaillais sur certaines instructions de l'Intel Xeon Phi (qui n'était alors pas encore commercialisé).

Septembre 2015. Le Master 2 recherche (M2R) s'appelle MoSIG, Master of Science in Informatics at Grenoble (notez le terme informatics, qui, je trouve actuellement plus juste que computer science, si vous avez 5 mn, réfléchissez-y sur votre vélo :-)). Il existe plusieurs filières, celle que j'ai choisi traite d'informatique embarquée, de programmation parallèle et de systèmes distribués. Les cours sont dispensés en anglais, ce qui nous épargne les phrases du type : « Ce handler catch l'exception du cache miss. », pour le bien de tous.

J'ai fait ce choix de « l'informatique embarquée » plusieurs fois : en DUT Informatique. En vérité, j'aime me situer à la limite entre l'électronique et l'informatique (j'ai aussi fait le choix bac STI Electronique pour atteindre l'informatique par le matériel). Cette proximité électronique/informatique est très présente, notamment en embarquée où le matériel a autant d'importance que le logiciel : pour la fiabilité des systèmes critiques, la réduction de la consommation pour réduire la chaleur ou optimiser les batteries et la robustesse.

Les 6 mois de cours ont été très intéressants bien qu'un peu déroutant au début. En effet, en école d'ingénieurs, j'avais été habitué à avoir des travaux pratiques dans toutes les matières. Le master s'est passé différemment, car les cours étaient là pour dresser l'état de l'art d'un domaine. Par exemple, les grands concepts et méthodes et les papiers fondateurs. Aussi improbable que ça puisse paraitre, sans le nommer, j'ai fait de l'histoire : l'informatique est déjà assez vieille (et a évoluées assez vite) pour avoir une histoire propre.

J'ai passé beaucoup de mon temps libre à lire des articles, pour approfondir les concepts et avoir des exemples. Le but de la formation est surtout d'avoir un sens critique sur les articles et de savoir les comparer. Finalement, le manque de travaux pratiques, déroutant au début, ne m'a pas gêné, cela m'a plutôt poussé à chercher par moi-même.

Chercher par moi-même, connaitre l'historique des choses, avoir un sens critique sur les articles. C'était le nécessaire pour appréhender le stage de recherche et plus tard, le doctorat.

Le stage recherche

Le stage recherche au laboratoire Verimag a été très différent de ce que j'imaginais : plus dur. Le sujet « vers la génération de code d'une langage synchrone sur un architecture many-core » paraissait très technique au premier abord. Aussi, je n'avais jamais programmé sur un processeur many-core, cependant, avec quelques jours passé à lire la documentation, j'ai pu apprendre à faire fonctionner mes premiers exemples. Ce sujet étant proche de celui de mon doctorat, je le décrirai plus en détail dans l'article sur mes recherches actuelles.

Les difficultés n'ont finalement pas été techniques, mais propres à la recherche.

J'ai dû comprendre le jargon du domaine. En effet, il y a beaucoup de notions à connaitre et à savoir exprimer. Il faut oublier les synonymes et la beauté de la langue ! Un mot est une notion précise qu'il faut apprendre. Parfois, ce qui semble être un synonyme crée un contre-sens et embrouille une discussion. Comme toujours, si on oublie l'art, la langue n'est qu'un outils.

Plus tard, nous avons assisté à une formation pour apprendre à mieux utiliser la puce. J'ai appris alors que l'entreprise avait justement besoin d'un doctorant pour travailler sur les usages embarqués critiques. C'est ainsi que j'ai commencé mon doctorat.