Avez-vous eu affaire au durcissement de l'espace?

Je suis très désireux d'étudier les meilleures pratiques en matière de renforcement de l'espace. Par exemple, j'ai lu (bien que je ne trouve plus l'article) que certaines parties centrales des robots mobiles Mars n'utilisaient pas l'allocation de mémoire dynamique, en fait, c'était interdit. J'ai aussi lu que la mémoire principale à l'ancienne peut être préférable dans l'espace.

J'examinais certains des projets associés au Google Lunar Challenge et me demandais ce que ce serait de ressentir du code sur la Lune ou même dans l'espace. Je sais que les conseils durcis par l’espace offrent une certaine sécurité dans un environnement aussi rude, mais je me demande (en tant que programmeur C) comment j’aurais besoin d’ajuster ma pensée et mon code si j’écrivais quelque chose qui fonctionnerait dans l’espace?

Je pense que les sociétés spatiales privées connaîtront peut-être davantage de croissance au cours des prochaines années. J'aimerais au moins en savoir un peu plus sur les meilleures pratiques.

Qu'advient-il d'un programme si des radiations, du froid ou de la chaleur bombardent une carte qui a subi des dommages pour son isolation? Je pense que l’objectif est de garder les humains à l’intérieur d’un vaisseau spatial (jusqu’à réparer ou échanger des choses) et d’éviter les missions de réparation.

En outre, si le conseil maintient un système critique, les alertes précoces semblent primordiales.

Comment peut-on acquérir de l'expérience dans ce domaine en procédant à des tests et à des essais et erreurs (à l'exception du lancement de votre propre satellite personnel?)

Le logiciel spatial n'est pas une magie arcanique. Vous utilisez toujours les 0 et les 1, pas les 1 et les 3. Il n'y a donc probablement aucun facteur wow impliqué dans la description de ce qui entre dans le développement de logiciels.

Quelques légères différences qui me viennent à l'esprit à l'heure actuelle sont les suivantes:

• Extrêmement orienté processus.
• Les logiciels spatiaux auront toujours des minuteries de surveillance logicielles et matérielles.
• Chaque système spatial sur lequel j'ai travaillé était un système temps réel difficile.
• Vous simulez (avec une grande précision) chaque acteur externe du système. Cela implique généralement la construction d'un matériel personnalisé (parfois très coûteux) utilisé uniquement à des fins de test.
• Vous consacrez des efforts et des dépenses considérables à des tests formels.
• Le client (généralement JPL) est extrêmement impliqué dans le processus de test.
• Vous utilisez généralement des compilateurs et des environnements de développement anciens et connus, plutôt que les nouveaux.
• Révisions de code, revues de code et revues de code.
• Vous feriez mieux d'être très à l'aise de basculer entre les univers matériel et logiciel. Vous n'avez pas besoin de savoir comment concevoir le matériel, mais vous devez savoir comment cela fonctionne.
• Utilisation intensive d'équipements de test, tels que des oscilloscopes, des analyseurs logiques, des synthétiseurs et des analyseurs de spectre.
• Au moins 3 emplacements pour stocker le programme d'application. La valeur par défaut est gravée dans la ROM. Cela ne changera jamais. Les 2 autres sont pour la version actuelle et la prochaine / dernière version.
• L'analyse des défaillances (MTBF) est vraiment importante.
• Systèmes redondants et plans de basculement pour les composants critiques.

Je viens de trébucher sur votre question intéressante.

J'étais au laboratoire d'instrumentation pendant Apollo et encore plus tard quand il s'appelait Draper Lab pendant la "guerre froide".

Pour l'ordinateur de guidage Apollo, le noyau était utilisé pour la mémoire vive et un noyau tressé spécial pour la mémoire morte. La machine elle-même a été entièrement construite à partir de portes NOR et a été très lente, par souci de fiabilité.

Je n'ai pas travaillé directement sur les missiles Minuteman, mais j'étais conscient de certains problèmes. Si une tête nucléaire se déclenche à proximité de certains appareils électroniques, elle la met en court-circuit. L'ordinateur de guidage était équipé d'un capteur de rayonnement capable d'éteindre instantanément Vc, afin que rien ne brûle. Ensuite, l’ordinateur redémarrera après avoir effacé ses registres.

Pour gérer cela, l'ordinateur cliqueterait périodiquement ses registres dans le noyau et, lorsqu'il le redémarrerait, il commencerait à partir de ce point de contrôle. Pour que cela fonctionne, le logiciel (tout en ASM) devait être analysé pour s'assurer qu'il pouvait prendre n'importe quel nombre de ces hits, à n'importe quelle fréquence, sans obtenir de mauvaises réponses. Cela a été appelé étant "redémarrage protégé". Problème très intéressant, étant donné (Dieu merci), il n'a jamais dû être utilisé.

Pour obtenir une fiabilité d'environnement difficile en C, voici certaines choses très concrètes que j'ai vues faire.

MISRA-C: Le sous-ensemble Automotive C. Un peu comme Ravenscar ADA / Java.

chiens de garde: s'assurer que le programme ne se bloque pas

mémoire ecc (parfois)

sommes de contrôle: recherche de bits inversés. J'ai vu ces trois éléments dans un seul système:

1) somme de contrôle du programme en continu (c'était dans EPROM mais les bits étaient toujours retournés).

2) la somme de contrôle de certaines structures de données périodiquement.

3) le bon fonctionnement du processeur est vérifié périodiquement.

4) vérifiez que les registres IO ont ce qu’ils sont supposés avoir.

4b) relire les sorties sur des entrées indépendantes et vérifier.

Les exigences du système sous-jacent (système d'exploitation et matériel) sont bien plus importantes que le langage de programmation. Fondamentalement, vous devez assurer (et prouver) un comportement déterministe et prévisible du système global. Une grande partie de la recherche connexe a été effectuée dans la communauté en temps réel. Je vous recommande fortement de lire deux livres si vous souhaitez vraiment étudier ce sujet: Real-Time Systems de Jane Liu et un livre du même nom de Hermann Kopetz . Le premier aborde la planification de manière très théorique, tandis que le second vous remet sur pied et couvre à peu près tous les aspects liés à la conception de systèmes (en temps réel), par exemple la tolérance aux pannes.

De plus, les deux incidents suivants illustrent bien la qualité des problèmes rencontrés par les ingénieurs en logiciel lorsqu'ils envoient quelque chose dans l'espace:

• Ariane 5 (Réutilisation de logiciels éprouvés sous différentes contraintes)
• Redémarrage de Mars Rover Pathfinder (inversion de priorité)

J'ai trouvé ce document (vers 2009) pour la norme de codage institutionnel JPL pour le langage de programmation C sur le laboratoire pour logiciels fiables (LaRS) sur le site du laboratoire de propulsion par réaction .

Voici un résumé des règles documentées:

1. Conformité linguistique

   • Ne vous écartez pas de la définition du langage.
   • Compiler avec tous les avertissements activés; utiliser des analyseurs de code source statique.

2. Exécution prévisible

   • Utilisez des limites de boucle vérifiables pour toutes les boucles censées se terminer.
   • N'utilisez pas de récursion directe ou indirecte.
   • N'utilisez pas l'allocation de mémoire dynamique après l'initialisation de la tâche.
   • * Utilisez les messages IPC pour la communication de tâche.
   • N'utilisez pas de retards de tâches pour la synchronisation des tâches.
   • * Transférer explicitement l'autorisation d'écriture (propriété) pour les objets de données partagés.
   • Placez des restrictions sur l'utilisation des sémaphores et des verrous.
   • Utilisez la protection de la mémoire, les marges de sécurité, les barrières.
   • N'utilisez pas goto, setjmp ou longjmp.
   • N'utilisez pas d'attribution de valeur sélective à des éléments d'une liste enum.

3. Codage défensif

   • Déclarez les objets de données au niveau de portée le plus petit possible.
   • Vérifiez la valeur de retour des fonctions non-void ou explicitement converti en (void).
   • Vérifiez la validité des valeurs transmises aux fonctions.
   • Utilisez des assertions statiques et dynamiques comme contrôles de validité.
   • * Utilisez U32, I16, etc. au lieu des types de données C prédéfinis tels que int, short, etc.
   • Rendre explicite l'ordre d'évaluation dans les expressions composées.
   • N'utilisez pas d'expressions avec des effets secondaires.

4. Clarté du code

   • N'utilisez que très peu le pré-processeur C.
   • Ne définissez pas de macros dans une fonction ou un bloc.
   • Ne pas indéfinir ou redéfinir les macros.
   • Placez #else, #elif et #endif dans le même fichier que le #if ou #ifdef correspondant.
   • * Ne placez pas plus d'une déclaration ou déclaration par ligne de texte.
   • * Utilisez des fonctions courtes avec un nombre limité de paramètres.
   • * N'utilisez pas plus de deux niveaux d'indirection par déclaration.
   • * N'utilisez pas plus de deux niveaux de déréférencement par référence d'objet.
   • * Ne cachez pas les opérations de déréférence dans les macros ou les typedefs.
   • * N'utilisez pas de pointeurs de fonction non constants.
   • Ne transtypez pas les pointeurs de fonction dans d'autres types.
   • Ne placez pas de code ou de déclarations avant une directive #include.

*) Toutes les règles sont des règles obligatoires , à l'exception de celles marquées d'un astérisque.

Les systèmes informatiques à l'épreuve de l'espace sont une question de fiabilité. On trouvera une introduction approfondie au domaine dans Concepts fondamentaux de la fiabilité de Algirdas Avižienis, Jean-Claude Laprie & Brian Randell.

Le temps réel est également un concept clé pour l'informatique spatiale. En tant que Pankrat, je recommanderais Real-Time Systems de Hermann Kopetz.

Pour donner une idée pragmatique des défis de l’informatique spatiale, pensez à:

• conditions extrêmes dans l'espace: très chaud lorsqu'il est orienté vers le soleil, très froid de l'autre côté, nombreux rayons cosmiques qui peuvent inverser des bits en mémoire, accélérations et vibrations énormes lors du lancement, ... Le matériel pour l'espace doit être beaucoup plus robuste que le matériel pour les militaires.

• En cas de panne, à l'exception de la Station spatiale internationale ou du télescope spatial Hubble, personne ne vient remplacer le système défaillant. Tout doit être réparé du sol via une observabilité et une commandabilité maximales, ainsi que par le biais de systèmes de secours sur lesquels basculer. C'est facile pour les satellites de la Terre. Ceci est plus difficile avec les sondes spatiales pour lesquelles les retards de communication peuvent durer une heure. En effet, tout doit être le plus fiable possible.

Ce que j'ai appris du seul projet auquel j'ai participé en tant que stagiaire:

Vos spécifications matérielles vont changer, généralement pour le pire!

Par exemple, le processeur renforcé qui était utilisé dans la conception avait été promis , mais attention, il fonctionnait à 20 MHz.

Le résultat final était à 12 MHz. Le programmeur principal du projet a passé beaucoup de temps à redéfinir les algorithmes afin de répondre aux besoins en temps réel des systèmes de contrôle. Une grande partie du logiciel de télémétrie a été déchargée sur un second système au lieu de fonctionner sur le processeur principal.

Essayez donc de laisser des ressources supplémentaires disponibles dans la conception d'origine et essayez de ne pas utiliser tout le processeur et la mémoire disponibles.

Pour une perspective logicielle, écrivez une tâche privilégiée qui, de manière aléatoire, retourne des bits dans votre code et voyez comment elle s'en acquitte. C'est ton simulateur.

Du point de vue matériel, les pièces seront anciennes, car il faut beaucoup de temps pour obtenir quelque chose qui soit classé dans l'espace. De plus, les nouvelles pièces sont de plus en plus petites et plus une caractéristique est petite (pensez à une cellule mémoire sur un CI), plus elle est susceptible d'être corrompue par un événement de rayonnement.

J'ai travaillé sur un dispositif critique pour la sécurité et nous avons dû passer par des étapes similaires.

Nous avions des variables critiques pour la sécurité. Il y avait une copie de l'inverse de la variable. Après chaque boucle, la variable a été vérifiée par rapport à son inverse.

Nous avons eu un test de marche et de zéro sur TOUS les registres. Cela comprenait le compteur de programme!

Nous avons testé tous les opcodes du jeu d’instructions. Nous devions être sûrs que si vous ajoutiez 2 registres, les registres étaient ajoutés.

Une partie de cela n’est probablement pas liée aux programmes dans l’espace, mais cela vous donne une idée de l’ampleur des vérifications possibles.

Je pense que plus l'environnement est dégradé, plus le nombre de codes de correction d'erreur utilisés est élevé, et certaines mémoires ECC peuvent être utilisées dans une certaine mesure.

Si l'on peut estimer le niveau d'erreur, on peut construire un code de correction d'erreur capable de gérer les erreurs introduites.

• Oui, la mémoire principale est sur les panneaux de recherche.
• La mémoire dynamique n'est pas bonne pour les systèmes embarqués. Problèmes de fiabilité.

Je suppose que le logiciel ECC de données utilisant la théorie de l’information et un logiciel personnalisé pour diffuser les données dans le système afin de gérer les défaillances de la mémoire serait un bon début. Mais, je n’étudie pas les logiciels rad-hard, je ne les connais donc pas, c’est juste une supposition.