IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Actualités Discussion :

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

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    mars 2013
    Messages
    7 313
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : mars 2013
    Messages : 7 313
    Points : 175 628
    Points
    175 628
    Par défaut Le télescope spatial James Webb est largement contrôlé par des fichiers JavaScript
    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.

    Nom : jwst.png
Affichages : 21867
Taille : 105,2 Ko

    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 ».

    Nom : javascript.png
Affichages : 5059
Taille : 43,3 Ko

    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.

    Nom : deux.png
Affichages : 4961
Taille : 64,3 Ko

    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.

    Citation 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 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 ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre expérimenté
    Homme Profil pro
    chomeur
    Inscrit en
    avril 2015
    Messages
    652
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 77
    Localisation : France, Seine Maritime (Haute Normandie)

    Informations professionnelles :
    Activité : chomeur
    Secteur : Distribution

    Informations forums :
    Inscription : avril 2015
    Messages : 652
    Points : 1 427
    Points
    1 427
    Par défaut
    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
    Plus vite encore plus vite toujours plus vite.

  3. #3
    Membre extrêmement actif
    Homme Profil pro
    Graphic Programmer
    Inscrit en
    mars 2006
    Messages
    1 400
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Graphic Programmer
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mars 2006
    Messages : 1 400
    Points : 3 406
    Points
    3 406
    Par défaut
    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 !?

  4. #4
    Membre expert
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    octobre 2019
    Messages
    890
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Aube (Champagne Ardenne)

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Conseil

    Informations forums :
    Inscription : octobre 2019
    Messages : 890
    Points : 3 776
    Points
    3 776
    Par défaut
    Citation Envoyé par Aiekick Voir le message
    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.

  5. #5
    Membre expérimenté
    Homme Profil pro
    ingénieur qualité
    Inscrit en
    mars 2015
    Messages
    488
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : ingénieur qualité
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : mars 2015
    Messages : 488
    Points : 1 677
    Points
    1 677
    Par défaut
    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.

  6. #6
    Membre extrêmement actif
    Homme Profil pro
    Graphic Programmer
    Inscrit en
    mars 2006
    Messages
    1 400
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Graphic Programmer
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mars 2006
    Messages : 1 400
    Points : 3 406
    Points
    3 406
    Par défaut
    Citation Envoyé par totozor Voir le message
    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

  7. #7
    Modérateur
    Avatar de sevyc64
    Homme Profil pro
    Développeur informatique
    Inscrit en
    janvier 2007
    Messages
    10 056
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 056
    Points : 27 568
    Points
    27 568
    Par défaut
    Citation Envoyé par Aiekick Voir le message
    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.
    --- Sevyc64 ---

    Parce que le partage est notre force, la connaissance sera notre victoire

  8. #8
    Membre régulier Avatar de Philippe320
    Profil pro
    Inscrit en
    novembre 2005
    Messages
    179
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2005
    Messages : 179
    Points : 99
    Points
    99
    Par défaut
    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.
    Philippe

Discussions similaires

  1. Réponses: 2
    Dernier message: 28/10/2021, 20h41
  2. Réponses: 3
    Dernier message: 06/12/2019, 17h44
  3. Réponses: 13
    Dernier message: 07/02/2018, 12h31
  4. Réponses: 7
    Dernier message: 14/06/2012, 11h34
  5. Quel est le bon usage des fichiers "*.bpk" ?!
    Par bnadem35 dans le forum C++Builder
    Réponses: 3
    Dernier message: 12/09/2006, 18h31

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo