Mais pourquoi une médaille d’or de la recherche à un informaticien ?

Ah la science informatique, ce n'est pas comme la dilatation du temps prévue par la relativité restreinte ou le boson de Higgs qui s'explique en trois minutes. Ces morceaux de science que tout un chacun mentionne sans sourciller dans les conversations de fin de soirée. Quand on parle de complexité algorithmique ou de preuve de programme (et je n'ose mentionner le « lambda-calcul» …) c'est carrément incongru ! Pourtant, si un informaticien reçoit la médaille d'or de la recherche scientifique française pour avoir «traqué des bugs» c'est qu'il y a de la science, donc de la science à partager. Alors pourquoi cette science nous semble t'elle si étrange et étrangère ? Pour une raison simple : elle ne nous est pas familière, comme dit ma belle-mère. Nous ne l'avons pas apprise à l'école, car des gens ont réussi à faire croire que nous n'avions pas besoin de comprendre les sciences du numérique, juste utiliser les outils logiciels et consommer les produits disponibles.

Mais alors ? Qu'aurions nous du apprendre qui nous permettrait de comprendre les travaux scientifiques de Gérard Berry ? Trois petites choses, assez simples et surtout fort utiles. Allons-y.

1. Systèmes informatiques passifs et réactifs.

Il y a une différence entre un programme informatique et un système réactif.

Un programme informatique main() comme celui montré ici s'exécute une seule fois; par exemple en affichant bonjour print("Hello world!"); puis, si la température est trop basse < 15 degrés, en allumant le chauffage set("heater", "on");. Soit.

Mais ce n'est pas du tout ce qui va rendre service dans la vraie vie. Dans la vraie vie, on ne vérifie pas une fois en passant si il faut ou non brancher le chauffage. Non. On veut que dès que la température passe en dessous d'un seuil, le chauffage s'allume.

On a donc besoin d'un qui réagisse à des événements, comme  ici. À l'initialisation, "init", il nous dit bonjour, histoire de vérifier qu'il s'est bien activé, et quand when() la température baisse, c'est à dire quand l'événement se produit, il effectue l'action souhaitée.

Voilà: c'est ça un système réactif. C'est un système avec un logiciel qui "ne fait rien", sauf d'attendre un événement et de déclencher une action en réaction. La grande différence c'est que le temps rentre en jeu.

Bon. Vous êtes probablement en train de faire deux remarques : c'est évident, mais … pas si simple.

1. C'est évident ! Mon smartphone est bien un appareil qui ne fait rien (histoire de pas vider la batterie inutilement) mais réagit quand il reçoit un SMS ou que je touche son écran. Le réveil-matin est bien un appareil qui ne fait rien sauf attendre (le sadique) 07:01 du matin pour émettre une sonnerie complètement débile. Et bien oui: toute l'informatique embarquée ou enfouie dans les systèmes numériques qui nous entourent est essentiellement un ensemble de logiciels réactifs qui se déclenchent (i) à un moment donné, (ii) en réaction à un événement.

En fait, c'est pour des raisons historiques que les "programmes d'ordinateur" sont présentés comme un code non réactif qui s'exécute de bout en bout, et puis voilà. C'est la seule chose que l'on pouvait faire sur les premières machines programmables, comme celle-ci. Mais les choses ont changé depuis !

2. Ce n'est pas si simple ! Certes. Comment ça marche en fait ? Quand je touche l'écran de mon portable, on imagine bien que cela active un circuit qui envoie un signal au processeur de mon smartphone, ce qui va alors lancer la partie de logiciel correspondante. Mais pour le capteur de température ? Il n'y a pas de "lutin" dans le thermomètre qui va réagir à 18 ou 15 degrés, donc il faut d'une manière ou d'une autre un bout de code qui "surveille" en permanence le thermomètre pour émettre l'alarme si la température baisse. Bien. Mais il faut alors que le processeur fasse plusieurs choses en parallèle: surveiller le thermomètre, mais aussi l'écran tactile, etc.... Du coup, il faut que le processeur bascule d'une tâche à une autre en permanence, attends, y'a le téléphone qui sonne, mais tu peux pas allumer le chauffage tout de suite car la fenêtre est ouverte, ah tiens un SMS de ma belle-mère, quoi que dis tu ? Attends: une urgence! Ah ça tombe mal, la batterie de mon smartphone est presque vide, m… STOP !

Il n'y a aucune chance qu'un système réactif fonctionne correctement si on se contente de faire réagir en vrac les bouts de programmes qui sont connectés à chaque événement: il va y avoir des incohérences, de la bousculade, des réactions indésirables. Il faut donc modéliser le fonctionnement d'un tel système pour garantir son fonctionnement. Si le système en question est le stimulateur cardiaque qui maintient en fonctionnement le cœur de ma belle-mère ou bien le pilote automatique de son avion qui atterrit en pleine tempête, ça ferait désordre qu'il y ait un bug.

2. Un défi scientifique: modéliser le temps et les événements.

Il  est donc clair qu'il faut formaliser ces mécanismes, tenir compte du temps, des délais de réponse, des mécanismes de synchronisation. Il faut trouver une logique à tout ça. Le système informatique peut-être dans plusieurs états: éteint, allumé, avec tel composant en marche, ou tel pixel de son écran avec une couleur donnée. Garantir que le système fonctionne bien, c'est garantir que, parmi les millions d'états possibles, il est bien dans un des états désirés. Par exemple, garantir l'état du chauffage domestique selon la température mesurée. Et bien l'informatique théorique étudie comment des raisonnements logiques permettent de garantir que les programmes conduisent la machine dans un état correct. On fait la vérification formelle des circuits et logiciels.

Ouf! Ça a l'air compliqué… Et bien, c'est très très compliqué. Car il y a pire: comme le système est réactif, en interaction avec des événements extérieurs totalement inattendus, il faut raisonner en incluant le temps réel et le contexte. En bref, ici: un "truc" n'est pas «vrai ou faux»; il est «vrai ou faux à un instant donné, compte-tenu des autres éléments qui sont arrivés». Comment peut-on alors se sortir de tout ça?

C'est là que les collègues, dont Gérard Berry, ont eu une bonne idée. Ils se sont mis à voir les choses autrement.

- Une vision événementielle du temps: le levier est de considérer, pour le système informatique, le temps comme une succession d'événements.

Ainsi, peu importe, par exemple, l'heure exacte où l'avion va ouvrir son train d'atterrissage, puis atterrir: ce qui est super utile c'est garantir qu'il ouvre son train d'abord. Plus généralement, au lieu de considérer tous les instants on ne va prendre en compte que ceux où il y a un événement.

Ça semble plus simple, mais surtout cela va permettre de travailler comme sur une carte routière: chaque lieu correspond à un état du système, lié à une combinaison d'événements. Quand un nouvel événement arrive, on change de lieu et on doit juste prendre la "route" (c'est à dire exécuter le bout de programme informatique) qui permet d'aller là où on souhaite. Avec du vocabulaire d'informaticien on parle du "graphe" des états du système et des transitions entre ces états, bref: d'un automate à état fini.

Ce changement de point de vue a permis de développer plein d'outils pour déterminer à-priori (avant que l'avion n'atterrisse !) ce qui pouvait se passer, donc valider les logiciels.

Une objection à cette idée ? Oui ! Dans la vraie vie, le programme ne s'exécute pas instantanément, il prend du temps. Alors que se passe t'il si le système reçoit un événement en plein pendant le calcul de son changement d'état lié à l'événement précédent ? Devrait-il calculer son propre temps de calcul ? Mais combien ça lui prend de temps ce calcul du temps de calcul ? On s'en sort pas ! C'est la catastrophe. … Ou pas.

C'est là que Gérard Berry et les collègues ont eu une idée complètement loufoque, et parfaitement géniale.

- L'hypothèse synchrone: qu'à cela ne tienne, ils ont supposé que pour calculer comment passer d'un état à un autre, le système le ferait . . infiniment vite, c'est à dire de manière synchrone.

Bien entendu ils ne prétendent pas que tous les calculs se sont font instantanément (!). Juste qu'un long calcul d'une durée indéterminée génèrera un événement lorsqu'il sera achevé. Et on calculera l'état du système en tenant compte de cet événement. Seul le calcul sur les événements est supposé instantanné.

Schématiquement, pour calculer ce que l'on doit faire quand un événement arrive, c'est regarder dans une table indexée par l'événement, quel est l'état suivant: cela se fait en une opération ce qui est instantanné.

De ce fait cette idée est géniale, pour une raison simple (mais qu'il fallait deviner): si le système réagit de manière synchrone alors son fonctionnement devient simplissime, du coup le calcul pour passer d'un état à l'autre est .. immédiat ! Et hop: l'hypothèse se tient.

Une autre objection ? Je la devine: personne n'a envie de décrire à la main tous les états et combinaisons d'événements ! Heureusement, Gérard Berry et les collègues sont des informaticiens, ils ont donc proposé un langage de programmation pour que les ingénieurs puissent exprimer le comportement du système.

3. Un langage pour programmer logiciels et circuits.

Combien faut-il de constructions pour décrire un système réactif ? On doit sûrement pouvoir :

- émettre un événement,

- faire une action à l'arrivée d'un événement (ou suspendre une action en présence d'un événement),

- enchainer deux actions l'une après l'autre,

- exécuter deux actions en parallèle,

- arrêter d'une manière ou d'une autre une action en cours.

Mais encore ? À quelques nuances prêt la réponse des informaticiens est : cela suffit  ! Avec onze primitives, le langage, dit Esterel, permet de définir tout ce qu'il est possible de définir pour un système réactif. Ce n'est pas évident à démontrer, mais c'est le cas.

Par exemple le programme affiché ici, émet le signal O dès que les événements A et B ont été reçus. C'est une boucle infinie qui attend A et B en parallèle, avant d'émettre O et de recommencer.

L'ingénieur a donc simplement à écrire ce qu'il souhaite sous forme de modules qui émettent et reçoivent des signaux ou événements. Comme ce langage est complètement formalisé, il existe un traducteur automatique (un compilateur pour être précis) qui va générer la "carte routière" (l'automate à état fini) de tous les états possibles. Cela va permettre de faire des vérifications, et de l'implanter dans un circuit électronique ou sous forme logicielle.

Et voilà comment aujourd'hui on peut contrôler de manière sûre des systèmes informatiques compliqués. Bon, il faut que je vous laisse, l'avion a atterri et ma belle-mère est à la douane. Avec son cœur fragile, je voudrais pas la faire attendre, s'agit d'être synchrone.


2 commentaires pour “Mais pourquoi une médaille d’or de la recherche à un informaticien ?”

  1. patricedusud Répondre | Permalink

    Merci pour ce sympathique cours où votre belle mère joue un rôle presque aussi important que le langage Esterel qui a, faut-il le rappeler, plus de 30 ans, (nettement moins cependant que votre belle-mère) 🙂
    "C'est la seule chose que l'on pouvait faire sur les premières machines programmables, comme celle-ci. Mais les choses ont changé depuis !"
    Cela fait tout de même un sacré bout de temps que les ordinateurs "temps réel" existent.
    Mon expérience personnel est celle de l'ordinateur IBM 1800 des années 60 🙂

  2. JLM Répondre | Permalink

    https://www.honeywellprocess.com/en-US/pages/default.aspx
    il y en a même qui triplent les Unités de Contrôle en votant démocratiquement en 2/3.
    En déportant les automates "esclaves" ,qu'ils soient de la "famille" ou "étrangers" puisqu'il existe un langage universel et des passerelles ,on gagne en vitesse de traitement.Pourquoi surveiller le train d'atterrissage en vol alors qu'il suffit d'activer son automate lorsque besoin se fait sentir qui utilisera le langage Grafcet et le calcul numérique analogique afin de savoir s'il faut chauffer un peu,beaucoup ...
    honeywell avait des concurrents en Français -comme Alspa de Cegelec-Alsthom-rapidement mis hors circuit;pragmatisme ,et universalisme étant plus prisés que dogmatisme-idéologique même éclairé.à la lueur de'une science qui n'a pas à réécrire la Bible ou le Kamasoutra.

Publier un commentaire