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

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:

USI2012 journée 2 Compte-rendu de la soirée Qualité du Logiciel au Paris JUG, le 15 septembre 2009 Quel type de développeur êtes-vous ? USI2012 André Comte-Sponville saison 2 : le bonheur