Ordinateur de bord et données : calculer, mémoriser, commander et télémesurer

9 — Dossier de référence : ce qu’un vrai projet doit encore prendre en compte

Cette partie va volontairement plus loin que le calcul d’introduction. Elle relie le concept aux interfaces, aux pannes, aux essais, à la durée et à la maintenance afin que le cours puisse servir de chapitre de référence et pas seulement de fiche de révision.

L’ordinateur de bord est un orchestrateur, pas seulement un calculateur

Il reçoit des télémesures, exécute des commandes, horodate des événements, supervise des bus de données, lance des algorithmes GNC, stocke des données et contribue à la détection des pannes. Certaines fonctions sont temps réel : une boucle d’attitude ne peut pas attendre plusieurs secondes qu’un autre logiciel termine. D’autres sont moins urgentes, comme compresser une image scientifique. L’architecture informatique répartit donc priorités, processeurs, mémoires et réseaux selon les délais et les conséquences d’une perte.

Mémoire volatile, non volatile et données de survie

La RAM est rapide mais perd généralement son contenu sans alimentation. Une mémoire non volatile conserve code, paramètres et données après redémarrage. Pour une mission longue, il faut protéger les images logicielles de référence, journaux d’anomalies et configurations capables de restaurer un état sûr. La mémoire elle-même peut subir erreurs de bits dues au rayonnement. Des codes de correction d’erreur, scrubbing, copies redondantes et redémarrages contrôlés contribuent à la résilience.

Les bus de données sont des routes partagées

Capteurs, actionneurs et ordinateurs échangent leurs données via des liaisons et protocoles. Débit, latence, déterminisme, topologie et tolérance aux pannes déterminent le choix. Un bus très rapide n’est pas nécessairement meilleur s’il augmente complexité, consommation ou sensibilité. Il faut aussi gérer les adresses, priorités, synchronisation et erreurs. Une panne de réseau peut rendre des équipements sains inaccessibles ; l’architecture de communication interne fait donc partie de la sûreté du véhicule.

Le temps est une donnée de navigation et de diagnostic

Deux mesures prises à des instants différents ne peuvent pas être fusionnées correctement si leur horodatage est faux. Une dérive d’horloge peut donc affecter navigation, communication, séquences et reconstruction d’une panne. Le véhicule maintient des références temporelles, distribue le temps aux équipements et enregistre les événements. Pour les opérations à longue distance, il faut aussi distinguer le temps embarqué, le temps de réception au sol et les délais de propagation.

Rayonnements et informatique : penser à l’erreur transitoire

Une particule énergétique peut modifier temporairement un bit ou perturber un circuit sans détruire définitivement le matériel. On parle notamment de single-event upset pour certains événements. Le système doit donc distinguer erreur récupérable et dommage permanent. La tolérance peut combiner composants adaptés, blindage, redondance, vote, mémoire corrigée, watchdog et reconfiguration. L’objectif n’est pas de prétendre qu’aucune erreur n’arrivera, mais de continuer à fonctionner ou de revenir dans un état sûr lorsque l’erreur survient.

Observabilité : une panne impossible à expliquer est une panne difficile à réparer

Si le logiciel se contente d’afficher « erreur », l’équipage ou le sol manque d’informations. Des journaux structurés enregistrent événements, valeurs importantes, changements de mode, resets et messages de bus. Il faut cependant gérer le volume : conserver tout en permanence peut saturer la mémoire ou le lien radio. On choisit donc niveaux de journalisation, fenêtres temporelles et priorités. Une bonne observabilité permet de reconstituer la séquence causale après une anomalie.

Architecture distribuée et autonomie martienne

Un véhicule habité ou une base peut répartir le calcul entre plusieurs contrôleurs locaux plutôt que dépendre d’un unique ordinateur central. Cette distribution peut isoler des pannes et réduire le câblage, mais elle complique synchronisation, mise à jour logicielle et diagnostic. Sur Mars, la maintenance doit considérer aussi les fichiers de configuration, outils de programmation, versions de firmware et capacité à remplacer un calculateur par un matériel compatible. L’avionique devient donc une chaîne logistique numérique autant qu’un ensemble de cartes électroniques.