Construire un système d'exploitation de la catégorie spatiale : leçons tirées du développement de satellites

Chaque satellite qui lance un ordinateur portable est porteur d'un cerveau, un système d'exploitation personnalisé (OS) qui orchestre toutes les fonctions critiques, du contrôle de l'attitude au traitement des données de charge utile. Contrairement au système d'exploitation à usage général sur un ordinateur portable, un système d'exploitation par satellite doit fonctionner sans faille pendant des années dans un vide saturé par rayonnement, avec une puissance limitée et aucune possibilité de réparation matérielle.

Les enjeux sont extraordinairement élevés. Une seule faute logicielle après le lancement peut rendre des millions de dollars en matériel inutile. Comme le note l'Agence spatiale européenne (ESA), les défaillances logicielles représentent un pourcentage significatif d'anomalies en orbite. Par conséquent, chaque ligne de code dans un système d'exploitation par satellite doit être justifiée, validée et durcie face à des conditions attendues et inattendues.

Pourquoi un système d'exploitation personnalisé pour les satellites?

Les systèmes commerciaux d'exploitation en temps réel (RTOS) comme VxWorks, RTEMS et FreeRTOS sont largement utilisés dans les applications aérospatiales intégrées. Cependant, de nombreux programmes satellites, surtout ceux qui ont des besoins uniques en matière de mission, choisissent de construire un système d'exploitation personnalisé pour obtenir un contrôle précis sur l'utilisation des ressources, la sécurité et la récupération des défauts.

  • Scheduling déterministe[: Les tâches satellitaires, telles que les propulseurs de tir ou la capture d'images, nécessitent des temps d'exécution prévisibles et limités que l'OS général ne peut garantir.
  • Impression numérique[: Chaque kilooctet de mémoire réduit la capacité de charge utile ou augmente le coût. Un OS personnalisé peut enlever des services inutiles, en maintenant le noyau maigre.
  • Containment par défaut: Les systèmes spatiaux doivent survivre aux perturbations à un seul événement (SEU) et aux problèmes matériels. Un système d'exploitation personnalisé peut mettre en place des mécanismes de surveillance et des systèmes de redondance spécifiques à un domaine qui ne sont pas disponibles dans les produits hors gamme.
  • Sécurité par conception[: Les satellites sont de plus en plus des cibles pour les cyberattaques. Un système d'exploitation personnalisé peut imposer une séparation stricte entre les données de commande, de télémétrie et de charge utile sans compter sur des correctifs tiers.
  • Soutien à long terme: Les missions peuvent durer de 10 à 15 ans. Un système d'exploitation personnalisé évite les risques liés à la chaîne d'approvisionnement et les changements de licence qui pourraient affecter les logiciels propriétaires dans de tels délais.

Phase 1: Définition des exigences du système satellitaire

Les ingénieurs doivent traduire les objectifs de la mission en spécifications techniques concrètes qui conduisent à chaque décision de conception ultérieure.

Traitement des données en temps réel

Les boucles de contrôle d'altitude nécessitent souvent des relevés de capteurs et des commandes de actionneur à des vitesses de 10 Hz à 100 Hz, avec des jitters mesurés en microsecondes. L'OS doit fournir un calendrier déterministe des tâches et interrompre la manipulation pour respecter ces délais. Par exemple, une mise à jour de traqueur d'étoiles qui arrive 5 ms en retard pourrait causer au satellite une erreur de pointage de son antenne, conduisant à une panne de communication.

Tolérance aux défauts et autonomie

Un satellite en orbite géostationnaire connaît un retard de communication aller-retour d'environ 500 ms. Au moment où le contrôle au sol détecte une défaillance, le satellite peut déjà être dans un état critique. L'OS doit donc détecter, isoler et récupérer de défaillances matérielles et logicielles de manière autonome.

Contraintes thermiques et d'alimentation

Chaque cycle du CPU consomme de la puissance et l'excès de calcul génère de la chaleur qui doit être dissipée dans le vide de l'espace. L'OS doit supporter la tension dynamique et l'échelle de fréquence (DVFS), le ralenti indique que l'alimentation vers le bas périphériques, et les algorithmes de planification qui minimisent la consommation d'énergie pendant les périodes d'éclipse lorsque les batteries sont la seule source d'énergie.

Commande sécurisée et télémétrie

La commande par satellite doit être authentifiée et chiffrée pour empêcher l'accès non autorisé. Le système d'exploitation devrait faire appliquer la vérification cryptographique de chaque paquet de commande avant l'exécution, ainsi que des liens downlinks sécurisés de télémétrie qui résistent à l'écoute.

Fiabilité à long terme dans les milieux difficiles

L'espace est un environnement hostile. Le rayonnement peut causer des perturbations à un seul événement (en bit flips) et des loquets. L'OS doit comprendre des pilotes de mémoire de correction d'erreurs (ECC), des auto-tests périodiques et la possibilité de réinitialiser les composants qui ont pénétré dans un état bloqué. Les composants doivent également faire face à des cycles de température extrêmes – de –100°C en éclipse à +120°C en plein soleil direct – exigeant que l'OS gère les capteurs thermiques et règle la vitesse de l'horloge pour rester dans des limites de fonctionnement sûres.

Phase 2: Conception de l'architecture de l'OS personnalisé

Avec les exigences en main, l'équipe passe à la conception architecturale. L'objectif est de créer un système modulaire, vérifiable et adaptable à différents bus satellites.

Sélection du noyau et calendrier en temps réel

Le noyau est le noyau du système d'exploitation. Pour les systèmes satellites, les ingénieurs choisissent généralement l'une des deux familles suivantes : un petit microkernel ou un cadre en temps réel. Les microkernels, comme le RTEMS open-source, offrent une communication interprocess efficace et une protection de la mémoire, tandis qu'un cadre personnalisé peut être encore plus simple. L'algorithme de planification est presque toujours un schéma préemptif de priorité fixe (comme le RETMS de vitesse) car il fournit un comportement prévisible et permet d'effectuer une analyse statique du temps d'exécution (WCET) le plus défavorable.

Dans la pratique, les priorités des tâches sont attribuées en fonction de la criticité de la fonction. Les tâches de contrôle de l'attitude sont les plus prioritaires, suivies par la gestion thermique, les opérations de charge utile et la télémétrie interne.

Gestion de la mémoire

Les systèmes d'exploitation par satellite évitent généralement la mémoire virtuelle parce que le survol des tables de pages et des erreurs TLB ajoute une imprévisibilité. Ils utilisent plutôt une allocation de mémoire statique, où chaque tâche est dotée d'un pool fixe de mémoire physique au démarrage. Cette approche élimine les erreurs hors mémoire et rend l'analyse WCET extensible.

Mécanismes de détection et de récupération des défaillances

Un système d'exploitation personnalisé pour un satellite intègre plusieurs couches de défense:

  • Surveillants de la santé: Les tâches de niveau noyau vérifient périodiquement l'existence des tâches d'application en surveillant leur progression d'exécution. Une tâche qui ne répond pas est redémarrée et l'événement est enregistré.
  • Watchdog Timers: Un minuteur de veille matériel réinitialise le processeur entier si le système d'exploitation ne le dessert pas dans un intervalle défini.
  • Mémoire ECC et Scrubing: Le système d'exploitation lit périodiquement les régions de mémoire et corrige les erreurs à un seul bits, empêchant ainsi l'accumulation d'erreurs qui pourraient entraîner des perturbations à plusieurs bits.
  • Triple‐Modular Redundancy (TMR): Pour les sous-systèmes critiques, le système d'exploitation peut gérer trois threads de calcul identiques et utiliser un électeur majoritaire pour sélectionner la sortie. Si un thread n'est pas d'accord, il est réinitialisé et restauré à un état connu.

Modularité et mise à jour

Les missions satellitaires peuvent durer des années et des défauts de logiciels peuvent être découverts après le lancement. Le système d'exploitation doit supporter les mises à jour en direct (OTA), mais avec une extrême prudence. Généralement, le système d'exploitation est divisé en un chargeur d'amorçage -olfden-o qui ne change jamais, un noyau qui peut être remplacé dans son intégralité, et des modules d'application qui peuvent être téléchargés indépendamment.

Phase 3 : Mise en œuvre et essais rigoureux

La mise en place d'un système d'exploitation par satellite respecte des normes de codage strictes, comme MISRA‐C ou DO‐178C pour les systèmes critiques en matière de sécurité, afin de minimiser les erreurs de programmation.

Essais en environnement simulé

Avant que l'OS ne touche jamais le matériel réel, il fonctionne dans une simulation logicielle qui modélise les capteurs, les actionneurs et la dynamique orbitale du satellite. Cet environnement permet aux développeurs de tester des cas de bord qui seraient dangereux à reproduire en laboratoire, comme une panne de propulseur lors d'une brûlure critique ou une perte soudaine de puissance. Des milliers d'heures de mission simulées sont accumulées pour vérifier que l'OS gère correctement les scénarios nominaux et hors-nominaux.

Essais de matériel dans la boucle

Une fois le système d'exploitation stable en simulation, il est chargé sur le matériel de vol réel, habituellement un processeur à rayonnement durci comme le LEON3, le RAD750 ou un microcontrôleur de la série Cortex‐R. Les essais du matériel dans la boucle (HIL) connectent l'ordinateur de vol à des périphériques réels ou émulés : unités de mesure inertielles, traqueurs d'étoiles, roues de réaction et radios de communication. Le système d'exploitation doit démontrer qu'il peut contrôler ces appareils avec le moment et la précision requis.

Les essais radiologiques et environnementaux

Le matériel de vol, qui fonctionne sur mesure, est soumis à des cycles de vide thermique, à des vibrations et à une exposition aux rayonnements dans des installations d'essai comme celles du Laboratoire de propulsion de jet de NASA et du Centre européen de recherche et de technologie spatiales de l'ESA. Ces tests révèlent des faiblesses dans le code de gestion des défauts de l'OS, par exemple, une sous-routine qui prend trop de temps pour se remettre d'une EUE, ou une serpillère qui est suspendue sous un bombardement de particules à haute énergie.

Intégration et essais de systèmes

La phase finale intègre l'OS à l'ensemble du système satellite, y compris l'unité de gestion de la puissance, le système de commande thermique et les instruments de charge utile. L'OS doit orchestrer la séquence de démarrage, la transition par des modes de sécurité, opérationnels et d'urgence, et répondre correctement à toutes les séquences de commande.

Phase 4 : Surmonter les principaux défis

Chaque projet d'exploitation par satellite fait face à un ensemble de défis bien connus. Voici comment ils sont traités avec des solutions d'ingénierie concrètes.

Contraintes de ressources : CPU, mémoire et puissance

Les processeurs spécialisés dans l'espace sont souvent de 10 à 20 ans derrière les pièces commerciales de pointe en performance. Par exemple, le RAD750 de NASA, basé sur le PowerPC 750, fonctionne à 200 MHz avec 256 Mo de RAM. Chaque octet de mémoire et chaque cycle CPU doivent être attribués avec sagesse. Les ingénieurs utilisent des outils d'analyse statique pour mesurer les temps d'exécution et l'utilisation de la mémoire les plus mauvais cas jusqu'au niveau bit. Les fonctionnalités non utilisées – comme une pile TCP/IP – sont retirées du noyau.

Durcissement des radiations sans matériel

Bien que le durcissement des radiations matérielles soit coûteux et parfois indisponible, un OS personnalisé peut mettre en œuvre une atténuation basée sur le logiciel. Les perturbations à un seul événement sont détectées par des vérifications de parité ou par ECC sur toutes les structures de données critiques. Le programmeur OS recalcule périodiquement les bilans de ses blocs de contrôle de processus et les restaure à partir d'une copie redondante si des erreurs sont trouvées.

Latence et sécurité des communications

Les liens de commande et de contrôle ont des retards inhérents (de millisecondes à plusieurs secondes). Le système d'exploitation doit tamponner les commandes, les valider en fonction de la chronologie de la mission et les exécuter à des moments précis. Les protocoles de sécurité tels que la sécurité des liaisons de données spatiales (SDLS) de la SDDS sont intégrés dans la pile de réseau OS. Toutes les commandes entrantes sont authentifiées par des méthodes à clé symétrique ou à clé publique avant d'être transmises à la couche d'application.

Dépendabilité sur les missions pluriannuelles

Un système d'exploitation qui fonctionne sans remise à zéro pendant 10 ans nécessite une robustesse extraordinaire. L'équipe de développement fait appel à -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Une perspective du monde réel : bâtir sur des modèles éprouvés

Bien que chaque système d'exploitation satellitaire soit unique, de nombreux projets reposent sur des systèmes open-source ou patrimoine. Par exemple, le noyau de la NASA (cFE) et le système d'exploitation de la couche d'abstraction (OSAL) fournissent un cadre qui a été utilisé sur de nombreuses missions, y compris l'Orbiter de reconnaissance lunaire et le Mars Science Laboratory. De même, l'Agence spatiale européenne s'est normalisée sur RTEMS pour plusieurs missions terrestres et scientifiques.

En revanche, un programme qui nécessite une efficacité ou une sécurité extrêmes peut commencer par un noyau minimal – peut-être dérivé de FreeRTOS ou d'un planificateur personnalisé – et se construire vers le haut. La clé est d'éviter de réinventer la roue pour les services de base (comme la gestion des interruptions ou des tâches) tout en investissant fortement dans les caractéristiques uniques de tolérance, de sécurité et d'autonomie qui distinguent le système d'exploitation du satellite.

Pour ceux qui souhaitent approfondir leurs recherches, les ressources externes suivantes offrent un cadre technique détaillé:

Conclusion

La construction d'un système d'exploitation personnalisé pour un système satellite est un exercice d'ingénierie extrême. Il nécessite une expertise approfondie en temps réel, en tolérance aux défauts, en gestion de puissance et en sécurité, tout en fonctionnant dans certaines des conditions physiques les plus difficiles en existence. Le processus – de la définition des exigences à des essais rigoureux en plusieurs étapes – produit un système d'exploitation qui est maigre, déterministe et suffisamment résistant pour fonctionner de façon autonome pendant des années sans intervention humaine.

Le système d'exploitation est l'épine dorsale silencieuse de chaque mission spatiale réussie, et la discipline nécessaire pour la construire élève les normes de l'ingénierie logicielle dans l'ensemble de l'industrie. Pour les ingénieurs et les gestionnaires de projet qui s'attaquent à ce défi, la clé est de respecter les contraintes, d'investir dans les essais et de ne jamais sous-estimer la valeur d'un mécanisme de récupération des défauts bien conçu.