Le Touilleur ExpressLe Touilleur ExpressLe Touilleur ExpressLe Touilleur Express
  • Accueil
  • A propos de l’auteur
  • A propos du Touilleur Express

USI2012 : quel logiciel y-a-t-il dans une fusée Ariane 5 ?

    Home Perso USI2012 : quel logiciel y-a-t-il dans une fusée Ariane 5 ?

    USI2012 : quel logiciel y-a-t-il dans une fusée Ariane 5 ?

    Par Nicolas Martignole | Perso | 10 commentaires | 30 juin, 2012 | 0 | 7 007 affichages
         

    David Lesens est responsable du programme de recherche de la société Astrium Space Transportation du groupe EADS. Il a collaboré sur le développement du programme ATV (Automatic Transport Vehicule) utilisé pour ravitailler la station spatiale internationale. Lors de sa présentation il a répondu à une des questions que l’on se pose lorsque l’on est informaticien : quels types de logiciels y-a-t-il dans les fusées et les stations spatiales ?

    L’informatique est indispensable pour les missions spatiales aujourd’hui. L’ATV par exemple est un cargo autonome, propulsé par une version spéciale d’Ariane 5. Depuis l’arrêt des missions avec les navettes spatiales américaines en 2011, c’est l’un des moyens de ravitaillement de l’ISS. Il emporte 7.7 tonnes de charge utile, et comme son nom l’indique, il est capable de s’amarrer automatiquement avec l’ISS.

    Les logiciels permettent de prendre en charge le contrôle de l’appareil, de piloter les panneaux solaires, de gérer la propulsion et le rapprochement avec l’ISS. L’ATV a un module pressurisé qui permet d’embarquer une charge utile importante. Par contre, le déchargement s’effectue « à la main » par les spationautes de l’ISS.

    Les caractéristiques d’un logiciel spatial, ainsi que du matériel sur lequel il s’exécute sont intéressantes. En quoi un logiciel est-il spatial ? Disons qualifié pour être envoyé dans l’espace ? Il y a 3 caractéristiques clés : embarqué, temps réel et critique.

    Embarqué, car le système est autonome. Il ne s’achète pas sur le marché, chaque logiciel est unique au programme spatial. L’ATV communique en bande S via des relais satellites de la NASA avec un centre basé à Toulouse. L’ISS est gérée par les américains à Houston, Texas. Un système embarqué est autonome, souvent temps réel. Cela désigne le logiciel mais aussi le matériel, comme les CPU « endurcis » capables de résister aux ondes électromagnétiques émises par le Soleil.

    Temps réel, car le système doit effectuer une tâche correctement dans un temps déterminé. L’exactitude est aussi importante que la capacité à délivrer ce résultat dans un temps déterminé. David présente l’exemple du lancement d’Ariane 5. Beau bébé de 750 tonnes, soit un dixième du poids de la tour Eiffel, la fusée atteint 8 000km/h  deux minutes après le décollage. Elle mesure de 47 à 52 mètres. Les vents latéraux perturbent la trajectoire de la fusée une fois qu’elle a décollé. Un des exemples de programme temps réel cité par David, est celui qui contrôle l’inclinaison et qui replace la fusée correctement.

    Le système spatial est dit aussi critique. Imaginez un plantage système lors du lancement, cela ferait mauvais genre qu’un lanceur avec 2 fois 237 tonnes de Propergol retombe dans votre jardin. Pour s’assurer qu’un logiciel développé respecte des normes précises, et aussi pour qualifier le niveau de criticité d’un logiciel, il existe différentes normes. Par exemple DO-178B pour l’avionique, mais surtout le standard européen ECSS. Je doute que Maven le respecte à la lettre. Ce standard définit 4 niveaux, du plus simple au plus critique. Dans le standard ECS Q 40B par exemple, une faille au niveau A signifie la destruction de l’appareil ou la mort des personnes, s’il y a des humains embarqués. Bref tout est normalisé et très détaillé (et certainement très ennuyant).

    Le souci lorsque l’on développe ce type de logiciel, c’est que tu ne fais pas de TDD (Test Driven Development) avec JUnit.

    Imagine un peu ( Assert.isFalse(Fusee.getCurrentPosition() , toiLecteur.getJardin() )

    Pour savoir si un logiciel fonctionne correctement, il est important de pouvoir déterminer et prévoir au maximum ce qu’il va faire. Pour cela, il faut rester simple. Lorsque l’on commence à parler de CPU par exemple, cela devient intéressant. A votre avis, quel type de CPU y-a-t-il dans une fusée Ariane 5 ? Et bien un Motorola 68020, le processeur des Apple II, utilisé aussi d’après Wikipedia pour le TGV Belge et l’automatisation de la ligne 14 du métro à Paris. La mémoire était de 512ko au départ, mais elle est de 2 Mo au final. Rappelez-vous que tout ceci a été développé dans les années 90, et que cela fonctionne encore très bien aujourd’hui. Lorsque je pense que mon iphone est 1000 fois plus puissante qu’une fusée qui vaut plusieurs millions d’euros… Mais mon iphone a un souci : il n’est pas temps réel, il est très difficile de déterminer les temps d’exécution, et il serait très dangereux pour piloter une fusée Ariane 5. Non, il n’y a pas d’application pour ça.

    Le souci avec les CPU actuels, c’est essentiellement l’architecture. Les programmes spatiaux n’ont pas besoin de mémoires caches, de multi-coeur ou de cache de niveau 2. Non, ils ont besoin de pouvoir répondre selon des temps déterminés à des actions. Par exemple les moteurs d’Ariane 5 sont controlés toutes les 18ms et en cas de soucis, il faut tout arrêter en moins de 40ms (source).

    Un autre souci est purement physique. Sur des CPU trop miniaturisés, l’espace entre les pistes sur le silicium est très mince. Or dans l’espace, contrairement à votre ordinateur de bureau, il y a un gros souci : le Soleil. Est-ce que vous connaissez la ceinture de Van Allen ? Rien à voir avec le chanteur, c’est une zone qui  entoure la Terre, dans laquelle en raison du champ magnétique terreste, se concentre les ondes électromagnétiques émises par le Soleil. Bon je vous fais la version courte, mais c’est le principe du micro-onde. Or le souci c’est que lorsqu’il y a des éruptions solaires, de fortes charges électromagnétiques peuvent endommager les équipements. Si votre CPU est gravé très finement comme les derniers CPU, celui crame littéralement. Avec un CPU plus ancien, renforcé et blindé, et bien cela résiste mieux à ce type de souci. Ensuite pour se couvrir contre ce type de problème, les systèmes sont dupliqués et répétés plusieurs fois. L’ensemble est supervisé par des systèmes critiques de supervision, et les bus de données sont aussi assez large pour éviter de « souder » des pistes avec le rayonnement électromagnétique.

    Le souci c’est aussi la mémoire. Sur les vieilles mémoires, les radiations n’ont pas trop d’effets. Sur les mémoires récentes, elles crament littéralement, car les pistes sont gravées trop finement sur le silicium. En conclusion donc, avec une technologie peu miniaturisé, il y a moins d’impacts. Il faut du matériel tolérant à des environnements radioactifs.

    Pour que l’ensemble fonctionne en étant partiellement endommagé, il faut que l’ensemble soit complètement contrôlé. Le temps réel ce n’est pas être rapide, mais être à l’heure. Pour que l’ordinateur soit à l’heure il faut alors éviter la mémoire cache, les multi-coeurs et avoir un bus de communication déterministe. Bien entendu il faut un système d’exploitation temps réel. Non, ce n’est pas du Windows.

    Lors du développement du logiciel, les cas critiques sont évalués et selon les normes à respecter, plus ou moins de stratégies de contournement et de secours sont mises en oeuvre. Nous n’avons pas du tout cette approche dans le développement de nos applications Webs. Bien souvent, il n’y a qu’un seul contrôleur. S’il plante, c’est terminé. Deuxième chose, nous avons une approche où la fonctionnalité s’active lorsqu’elle est livrée, en redémarrant le serveur. Une autre approche plus intéressante, pensez-y la prochaine fois, est de permettre d’activer ou de désactiver des fonctions dans votre logiciel avec des paramètres de configurations. Ainsi, votre nouvelle fonction peut très bien être livrée en prod. Vous pouvez ensuite l’activer via un panneau d’admin, puis la désactiver en cas de soucis.

    Pour qu’un logiciel soit simple et sécurisé, il faut qu’il soit simple. Ariane 5 c’est 40 000 lignes de code, en ADA.  Concernant l’ATV, évoqué au début de l’article, c’est environ 500 000 lignes de code, l’un des plus important programmes jamais développé. Le processeur 32-bits est plus puissant. Il y a aussi un peu de C, mais l’essentiel est en ADA.

    Le standard définit des normes pour coder le logiciel, mais aussi des processus de développements très stricts. C’est vraiment du pur cycle en V, il n’y a pas d’itérations ou d’Agilité. L’ensemble peut prendre plusieurs années. Le développement de l’ATV s’effectue sur 10 ans. Les équipes de David travaillent sur des projets spatiaux pour 2025.

    Les méthodes de gestion de projets et de développements sont très critiques. Tout est formalisé, hyper spécifié, travaillé plusieurs fois car il n’y a pas d’itérations allant jusqu’à la mise en production. Les spécifications peuvent être revues par un cabinet externe. Tout est hyper testé et vérifié. Cela va même jusqu’à vérifier que le binaire compilé fonctionne correctement, bref que le CPU lui-même n’est pas bogué.

    La quantité de documentations à écrire est impressionante. Mais bon, nous sommes dans un autre domaine que notre domaine habituel.

    Conclusion

    J’ai bien aimé cette présentation. Depuis la fusée de Tintin en passant par la Guerre des Etoiles, David Lesens a apporté des réponses intéressantes sur l’informatique embarquée dans les engins spatiaux. Cela aide à relativiser son métier de développeur au quotidien. Cependant nous avons aussi perçu que le monde de l’industrie ne peut pas se permettre d’avoir des solutions qui marchent « à peu près ». Tout demande un travail très important en amont, que ce soit sur les spécifications ou sur l’implémentation.

     

    Articles similaires:

    Default ThumbnailUSI2012 journée 2 Default ThumbnailCompte-rendu de la soirée Qualité du Logiciel au Paris JUG, le 15 septembre 2009 Default ThumbnailQuel type de développeur êtes-vous ? Default ThumbnailUSI2012 André Comte-Sponville saison 2 : le bonheur
    No tags.
    • Avatar
      Sébastien Douche 1 juillet 2012 at 3 h 09 min

      > Et bien un Motorola 68020, le processeur des Apple II

      Hein ?! L’Apple ][ (qui date de 1977, le seul ordi potable d’Apple car issu de la tête de Woz) avait un Motorola 6502 à 1MHz. Le 68020 est sorti bien après (mi 80 je crois). Je pense que c’est à partir du Mac qu’Apple à utilisé la gamme des 68000.

    • Avatar
      Jérôme 1 juillet 2012 at 8 h 40 min

      Merci pour cet article passionnant.

    • Avatar
      Nicolas Martignole 1 juillet 2012 at 10 h 45 min

      @Seb> oui en effet c’est bien du Macintosh et pas du tout de l’APple 2. Je corrige

    • Avatar
      Duyhai 2 juillet 2012 at 0 h 16 min

      Ahhh ADA ce vieux language qu’on apprenait à l’école en Génie info. C »est chiant à coder mais ça reste encore le plus fiable. ..

    • Avatar
      Dominique De Vito 2 juillet 2012 at 13 h 49 min

      Quelques autres infos (glanées, maintenant, il y a une quinzaine d’années) sur la navette spatiale américaine : il y a(avait) 3 calculateurs, qui étaient supposés calculer la même chose, associés à un mécanisme de vote pour éliminer la panne de l’un d’entre eux (ou son possible endommagement par des radiations cosmiques). Un peu comme pour une base NoSQL, comme Cassandra, où, avec un facteur de réplication de 3, il est possible de palier aux pannes simples.
      Par ailleurs, toute la mémoire de travail était allouée dès le départ. C’était une contrainte de programmation qui permettait de se mettre à l’abri d’un appel à malloc() qui n’aurait pas produit le résultat escompté, et d’améliorer le coté temps-réel des calculs.

    • Avatar
      Dominique De Vito 2 juillet 2012 at 13 h 53 min

      A l’issue du crash d’Ariane 5 du à un souci logiciel, on a parlé des approches poussées de vérification de code prônées par des jeunes pousses comme PolySpace, cf. http://www.01net.com/editorial/160212/polyspace-chasse-les-bugs-et-les-millions/ ou http://pro.01net.com/editorial/347608/daniel-pilaud-polyspace-linteret-du-mariage-avec-mathworks-est-de-passer-a-la-vitesse-superieure/

      Est-ce que cette approche a été bel et bien suivie par Arianespace, ou est-ce que ces jeunes pousses ont juste profité du crash pour se hausser du col, sans que leur savoir soit réellement utilisé ?

    • Avatar
      Antoine 9 juillet 2012 at 16 h 04 min

      Merci pour le retour, très intéressant. C’est clairement un monde différent à tous les niveaux, comparé à nos applications d’entreprise.

      Je n’ai pas bien compris l’argument concernant le TDD. Pourquoi n’est-ce pas possible ? Bien sûr, tout ne peut pas forcément être testé unitairement, mais on pourrait sûrement tester ainsi une partie du code (on peut mocker un gouverail de fusée ;o) ). Du moins c’est moins impression, je serais intéressé de comprendre pourquoi ça n’a pas d’intérêt pour eux.

    • Avatar
      Dominique De Vito 15 juillet 2012 at 16 h 51 min

      Je reviens sur les outils de vérification statique de code. Au hasard de mon surf quotidien, je suis tombé sur « The Astrée Static Analyzer » http://www.astree.ens.fr/

      « Objectives of Astrée

      Astrée is a static program analyzer aiming at proving the absence of Run Time Errors (RTE) in programs written in the C programming language. On personal computers, such errors, commonly found in programs, usually result in unpleasant error messages and the termination of the application, and sometimes in a system crash. In embedded applications, such errors may have graver consequences.

      Astrée analyzes structured C programs, with complex memory usages, but without dynamic memory allocation and recursion. This encompasses many embedded programs as found in earth transportation, nuclear energy, medical instrumentation, aeronautic, and aerospace applications, in particular synchronous control/command such as electric flight control or space vessels maneuvers.  »

      A titre d’exemple : « In April 2008, Astrée was able to prove completely automatically the absence of any RTE in a C version of the automatic docking software of the Jules Vernes Automated Transfer Vehicle (ATV) enabling ESA to transport payloads to the International Space Station ».

    • Avatar
      muondo 17 juillet 2012 at 20 h 28 min

      Merci pour cet article intéressant.

    • Avatar
      Frederic 4 août 2012 at 10 h 57 min

      Très bon article, bonne synthèse sur le logiciel embarqué.
      Un commentaire : le nom du language (Ada) n’est pas en majuscule, car c’est un nom propre comme Java, et non pas un acronyme comme FORTRAN (FORmula TRANslator) ou COBOL.
      Les performances d’Ada à l’execution et en utilisation mémoire sont bien supérieures à Java (benchmark Debian) : http://shootout.alioth.debian.org/u64q/which-programming-languages-are-fastest.php

    Recent Posts

    • GitHub Actions : le tueur de Jenkins ?

      Avouez-le : ce titre de blog est super racoleur. J’avais aussi pensé

      15 février, 2021
    • Comment recréer du lien social dans l’Entreprise avec des outils numériques en 2021

      Nous sommes en février 2021 pendant le 3ème confinement lié à la

      10 février, 2021
    • FizzBuzz en Java et Scala (surtout Scala)

      L’exercice FizzBuzz est un petit exercice très simple, à tester par exemple

      9 février, 2021

    Recent Tweets

    • J'ai refais/modernisé l'authentification OAuth2 pour Google, Github et LinkedIn sur le CFP de Devoxx FR.

      2 hours ago
    •  @LostInBrittany   @FGRibreau   @aheritier  😎

      22 hours ago
    •  @LostInBrittany   @FGRibreau   @aheritier  J ai un souci GitHub demain à corriger aussi avec oauth2

      22 hours ago
    •  @LostInBrittany   @FGRibreau   @aheritier  J ai réparé l’authentification Google. Tu devrais pouvoir te reauthentifier

      22 hours ago
    • RT  @_beauraF : Since 2:19 p.m., the entire  @doctolib  platform has been running on Rails 6.1. 🚀 Once again it feels like launching a rocket…

      1 day ago

    Mots clés

    agile (18) ajax (11) Apple (11) architecture (6) barcamp (5) BarCampJavaParis (5) ddd (5) devoxx (33) esb (6) exo (6) flex (9) geek (5) google (11) grails (5) groovy (10) humeur (12) humour (7) independant (6) iphone (12) Java (77) javascript (7) jazoon (28) jboss (22) jboss seam (12) jsf (9) jug (16) Linux (11) mac (6) mule (5) parisjug (7) paris jug (22) pjug (6) play (8) playframework (6) portlet (5) recrutement (6) ria (8) Scala (21) scrum (44) spring (23) Startup (11) usi (21) usi2010 (9) web (16) xebia (7)

    Le Touilleur Express

    Contactez-moi : nicolas@touilleur-express.fr

    Suivez-moi sur Twitter : @nmartignole

    Copyright© 2008 - 2020 Nicolas Martignole | Tous droits réservés
    • A propos de l’auteur
    • A propos du Touilleur Express
    Le Touilleur Express