Le télescope spatial James Webb est largement contrôlé par des fichiers JavaScript

[Indigostar]

Le télescope spatial James Webb (figure ci-dessous) a été développé par la NASA avec des contributions majeures des agences spatiales européenne et canadienne. La mission JWST est conçue pour permettre un large éventail d’investigations scientifiques sur quatre grands thèmes : l’observation des premiers objets lumineux après le Big Bang, l’évolution des galaxies, la naissance des étoiles et des systèmes planétaires, et la formation des planètes ainsi que les origines de la vie

Il s’avère que JavaScript, le langage de programmation dont les développeurs Web et les utilisateurs adorent se plaindre, a contribué à fournir les superbes images que le télescope spatial James Webb a renvoyées sur Terre. Pour être plus précis, le télescope est largement contrôlé par des fichiers JavaScript. Il est basé sur un kit de développement logiciel de 2002.

Selon un manuscrit pour le module d’instruments scientifiques intégrés (ou ISIM) du JWST, le logiciel de l’ISIM est contrôlé par le Script Processor Task (SP), qui exécute des scripts écrits en JavaScript lors de la réception d’une commande pour le faire. « Le code chargé de transformer ces JavaScripts [ndlr. il s’agit de la formulation de la NASA] en actions peut en exécuter 10 à la fois ».

Le manuscrit et l’article JWST : Maximiser l’efficacité et minimiser les systèmes au sol, écrits par Ilana Dashevsky et Vicki Balzano du Space Telescope Science Institute, décrivent ce processus en détail, mais essayons de le simplifier un peu. JWST dispose d’un tas de ces scripts pré-écrits pour effectuer des tâches spécifiques, et les scientifiques sur le terrain peuvent lui dire d’exécuter ces tâches. Lorsqu’ils le feront, ces JavaScripts (formulation de la NASA) seront interprétés par un programme appelé processeur de script, qui contactera ensuite les autres applications et systèmes dont il a besoin en fonction de ce que le script appelle. JWST n’exécute pas un navigateur Web où JavaScript contrôle directement l’instrument infrarouge moyen - c’est plus comme lorsqu’un responsable reçoit une liste de tâches (dans cet exemple, les JavaScripts) à faire et les délègue à son équipe.

Les JavaScripts ne sont qu’une partie du puzzle, cependant ils sont très importants : l’ISIM est la collection d’instruments qui prennent réellement les images à travers le télescope, et les scripts contrôlent ce processus. La NASA l’appelle « le cœur du télescope spatial James Webb ».

Il semble donc un peu étrange qu’il utilise une technologie aussi ancienne ; selon Dashevsky et Balzano, le langage dans lequel les scripts sont écrits s’appelle Nombas ScriptEase 5.00e. Selon le site Web de Nombas (aujourd’hui disparu), la dernière mise à jour de ScriptEase 5.00e a été publiée en janvier 2003 (oui, il y a près de deux décennies). Il y a des gens qui peuvent voter et ne sont pourtant pas nés lorsque le logiciel contrôlant certains des instruments les plus vitaux du JWST est sorti.

Après y avoir réfléchi une seconde, cependant, l’âge du logiciel a un peu plus de sens - alors que le JWST a été lancé fin 2021, le projet est en cours depuis 1989. Lorsque la construction du télescope a commencé en 2004, ScriptEase 5 n’avait été publié qu’environ deux ans avant, son lancement ayant eu lieu en 2002. Ce n’est en fait pas particulièrement ancien, étant donné que les engins spatiaux sont souvent alimentés par une technologie éprouvée au lieu d’utiliser la plus récente et la plus performante. En raison du temps que prennent des projets comme le JWST pour démarrer (littéralement), les choses qui devaient être prêtes tôt peuvent sembler obsolètes selon des normes plus conventionnelles lorsque le jour du lancement arrive.

Il convient de noter que, comme le projet lui-même, ces documents qui décrivent le système JavaScript du JWST sont assez anciens ; celui écrit par Dashevsky et Balzano n’est pas daté mais est sorti en 2006, selon ResearchGate, et le manuscrit ISIM date de 2011. Il est toujours possible que la NASA ait pu modifier le système de script depuis lors, mais cela semble être une entreprise assez importante qui aurait été mentionnée quelque part. De plus, cette page de documentation JWST publiée en 2017 mentionne des « opérations scientifiques axées sur les événements », ce qui correspond à peu près exactement à la façon dont les documents décrivent le système basé sur JavaScript.

Soit dit en passant, cette base de connaissances contient également quelques détails supplémentaires sur le SSD de 68 Go du télescope, indiquant qu’il peut contenir entre 58,8 et 65 gigaoctets de données scientifiques réelles. Oui, le disque SSD de ce télescope a à peu près la même capacité que celui qui était disponible dans le MacBook Air 2008 d’origine.

 Envoyé par Nasa

La principale source de commande dans les opérations normales est le Script Processor Task, qui exécute des scripts écrits en JavaScript lors de la réception d’une commande pour le faire. L’exécution du script est effectuée par un moteur JavaScript exécuté en tant que tâche distincte qui prend en charge dix JavaScripts simultanés exécutés indépendamment les uns des autres. Un ensemble d’extensions du langage JavaScript a été implémenté pour fournir l’interface au SP, qui à son tour peut accéder aux services ISIM FSW via les ports d’interface de tâche standard. De plus, pour fournir une communication entre des JavaScripts exécutés indépendamment, il existe des extensions qui peuvent définir et récupérer les valeurs des paramètres partagés.

Une collection de JavaScripts, stockés sous forme de fichiers ASCII, constitue le système de scripts d’opérations, décrit à la section 3.7, qui offre la possibilité d’opérations automatiques (voir Figure 22). Un JavaScript peut envoyer une commande en communiquant avec SP, qui envoie le paquet de commande au gestionnaire de commandes. Si la commande provenant d’un JavaScript est une fonction SI, telle que déplacer une roue de réseau vers une certaine position, la commande serait acheminée vers la tâche d’application pour ce SI. Cette tâche d’application SI peut générer de nombreuses commandes vers le matériel SI pour terminer l’opération demandée. Ces commandes matérielles sont envoyées via le Command Manager à la tâche d’interface de bus, 1553 ou SpaceWire, qui se connecte au composant SI commandé.

La même tâche d’application SI peut envoyer une commande au matériel SI, via la tâche d’interface de bus, demandant des informations d’état pour vérifier que la commande précédente a été correctement exécutée. Ces informations sur l’état du matériel seront reçues par la tâche d’interface de bus et formatées dans un paquet de télémétrie qui est envoyé par son port de télémétrie au gestionnaire de télémétrie, qui achemine le paquet vers toute tâche qui s’est abonnée pour recevoir des paquets identifiés avec cet ID d’application. Lorsque la tâche d’application SI reçoit ce paquet, elle peut décider si la commande a réussi, si l’opération est terminée ou si une erreur s’est produite. Chaque tâche émet à intervalles réguliers un paquet de télémétrie « de ménage » fournissant des informations générales sur l’état qui peuvent être visualisées en temps réel lors d’un contact au sol, ou enregistrées sur le SolidState Recorder et analysées ultérieurement sur le terrain. En outre, chaque tâche peut émettre des messages d’événement pour signaler des erreurs ou des opérations réussies.

La grande question à ce stade serait peut-être « pourquoi Javascript ? » Bien sûr, il y a probablement un peu plus d’angoisse à propos du langage maintenant qu’il n’y en avait à l’époque où les ingénieurs du projet sélectionnaient la technologie pour le projet, mais la NASA est célèbre parmi certains programmeurs pour ses directives de programmation strictes - quel est l’intérêt d’aller vers de la programmation orientée script-web au lieu de faire appel à un code plus traditionnel ?

Eh bien, le document de la NASA indique que cette façon de faire donne « au personnel d’exploitation une plus grande visibilité, un meilleur contrôle et une plus grande flexibilité sur les opérations du télescope », leur permettant de modifier facilement les scripts « alors qu’ils apprennent les ramifications et les subtilités de l’utilisation des instruments ». Fondamentalement, la NASA travaille avec un tas de fichiers qui sont écrits dans un format quelque peu lisible par l’homme - s’ils ont besoin d’apporter des modifications, ils peuvent simplement ouvrir un éditeur de texte, faire un tas de tests sur le terrain, puis envoyer le fichier mis à jour au JWST. C’est certainement plus facile (et donc probablement moins sujet aux erreurs) que si chaque programme était écrit en code obscur que vous auriez à recompiler si vous vouliez apporter des modifications.

Si vous êtes toujours inquiet, notez que le document du Space Telescope Science Institute mentionne que le processeur de script lui-même est écrit en C++. Quoiqu’il en soit, les images sont incroyables, quel que soit le type de code exécuté pour les générer.

Sources : NASA, JWST, javascript.developpez.com

[duJambon]

Il faut espérer que les actions des scripts sont bien encadrées par des sécurités soft et hard, notamment au niveau des entrées/sorties, mais la nasa n’est surement pas encore complètement idiote et que le javascript n’est pas en prise directe avec le téléscope, mais utilise une couche de programmation de sécurité intermédiaire…