Discussion :

[Stéphane le calme]

Le télescope spatial James Webb est largement contrôlé par des fichiers JavaScript
Il est chargé de prendre les jolies photos

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.

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 est 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++. Quoi qu'il en soit, les images sont incroyables, quel que soit le type de code exécuté pour les générer.

Sources : NASA, JWST

Et vous ?

Que pensez-vous de JavaScript ? L'avez-vous déjà utilisé dans vos projets personnels ou professionnels ?
Êtes-vous surpris de le voir autant utilisé avec le télescope spatial ?
Que pensez-vous des bibliothèques JavaScript comme jQuery ?
Que pensez-vous des langages visant à améliorer et de sécuriser la production de code JavaScript comme TypeScript ?

[melka one]

C'est certainement plus facile (et donc probablement moins sujet aux erreurs) que si chaque programme était écrit en code obscur

c'est sur c'est pas du javascript d'aujourd'hui

[Aiekick]

c'est vraiment une drole d'idée quand on connait la depense energetique du js comparé a d'autre langage compilé..
on va dire que comme le sta a des panneaux solaires, ils s'en fiches !?

[calvaire]

c'est vraiment une drole d'idée quand on connait la depense energetique du js comparé a d'autre langage compilé..
on va dire que comme le sta a des panneaux solaires, ils s'en fiches !?

en effet je doute que l'efficacité énergétique soit aussi importante à ce point la. En tant que poarticulier dans mon garage on peut facilement faire des ordinateurs capable d’exécuter du javascript et consommant que 2-3w (raspberry pi).
L'informatique à évoluer depuis les sondes voyager, et le 1er vol sur la lune. On peut en faire plus aujourd'hui avec un ordinateur consommant moins d'1 w et petit comme un doigt. Les panneaux solaires doivent laaaargement suffire.

maintenant pourquoi javascript, je trouve ce choix très étrange malgré l'article. L'argument d'utiuliser un langage interprété au lieu d'un compilé est recevable, mais je serais perso partis vers un langage plus safe avec notamment un contrôle de type et une vrai logique mathématique. Il faut savoir que javascript est remplie de bug niveau calcul scientifique, rien qu'avec les additions/soustraction et parenthèse y'a des incohérences.

[totozor]

Mon père travaillait dans le spatial, je me souviens d'un conférence où il comparait l'ordinateur d'un satellite moderne à un Iphone et la comparaison semble aberrante, l'Iphone étant BEAUCOUP plus puissant sur tous les plans, sauf 1 : la fiabilité.
Quand on parle d'un truc qui doit fonctionner 30 ans sans possibilité d'entretien les critères ne sont pas les même que quand on choisit notre téléphone qui va tomber en obsolescence dans 2 ou 3 ans.

Le spatial est un secteur d'activité exceptionnel parce qu'une faille n'est pas permise. Le premier système central qui tombe en panne rend tous les autres inexploitables.
Donc ils ont tendance à utiliser des vieux systèmes parce que qui dit vieux dit recul sur la fiabilité et leur capacité à bien fonctionner en vieillissant. Donc finalement un système qui date d'il y a 20 ans en fait probablement un jeune parmi ses confrère physiques.

[Aiekick]

Mon père travaillait dans le spatial, je me souviens d'un conférence où il comparait l'ordinateur d'un satellite moderne à un Iphone et la comparaison semble aberrante, l'Iphone étant BEAUCOUP plus puissant sur tous les plans, sauf 1 : la fiabilité.
Quand on parle d'un truc qui doit fonctionner 30 ans sans possibilité d'entretien les critères ne sont pas les même que quand on choisit notre téléphone qui va tomber en obsolescence dans 2 ou 3 ans.

Le spatial est un secteur d'activité exceptionnel parce qu'une faille n'est pas permise. Le premier système central qui tombe en panne rend tous les autres inexploitables.
Donc ils ont tendance à utiliser des vieux systèmes parce que qui dit vieux dit recul sur la fiabilité et leur capacité à bien fonctionner en vieillissant. Donc finalement un système qui date d'il y a 20 ans en fait probablement un jeune parmi ses confrère physiques.

a ma connaissance dans le spatial tout est codé en ADA. si ils commencent a utiliser des technos bancale comme JS ou python pour ces niveaux de criticité et de durée de vie on est mal.
j'aurais plutot pensé au rust en conso / sureté il defonce tout le monde

[sevyc64]

si ils commencent a utiliser des technos bancale comme JS ou python pour ces niveaux de criticité et de durée de vie on est mal.

Le problème n'est pas d'utiliser une techno bancale, bien au contraire, mais plutôt l'historique que l'on a sur cette techno.

Dans ce secteur d'activité, une vieille techno même bancale, mais dont on connait tous les travers, toutes les failles, et surtout les moyens de les contourner et de les contrecarrer, sera toujours plus sure qu'une techno plus récente, qui se prétend bien plus sure mais dont, au final, on ne connait pas grand chose sur ses défauts potentiellement pas encore découverts.

[Philippe320]

Est-ce si étonnant que cela ?
Les FMS des premiers A320 étaient basés sur des 80286 (pas récents, même au début de cet avion)
La raison : tous les bugs étaient connus, la sécurité du système s’en trouvait augmentée

On peut imaginer la même raison à propos d’un compilateur d’un language récent, par rapport à un language ancien, non compilé, parfaitement partagé, sur un système «*accessible*» qu’à distance.