Énergie, avionique & logiciel de vol
Un véhicule spatial ne possède pas une prise électrique idéale. Sa production varie, les batteries vieillissent, les convertisseurs dissipent de la chaleur et certaines charges ne peuvent pas fonctionner simultanément. L’avionique doit mesurer cet état, exécuter le logiciel de vol, piloter les actionneurs et rester maîtrisable lorsqu’un capteur ou un calculateur tombe en panne. Ce module relie donc puissance électrique, électronique et logiciel critique.
Objectifs de maîtrise
- expliquer les concepts avec les unités et les hypothèses
- refaire un calcul simple à la main avant d’utiliser un outil
- identifier au moins un mode de panne ou une limite du modèle
- relier la discipline à une architecture martienne complète
1. Budget de puissance et profil de mission
Le budget distingue puissance moyenne, puissance de pointe et énergie sur une durée. Une charge de 2 kW pendant dix minutes ne consomme pas la même énergie qu’une charge de 500 W pendant dix heures. Pour chaque phase de mission, on additionne les charges, les pertes et la marge puis on compare à la production et au stockage disponibles.
Réflexe d’ingénierie. Pour « budget de puissance et profil de mission », noter d’abord les entrées, les sorties, les unités et la plage de validité. Puis construire un cas nominal et un cas dégradé. Ce double calcul empêche de confondre une relation mathématique correcte avec une architecture réellement exploitable sur Mars.
2. Production : solaire, sources alternatives et orientation
Un générateur solaire dépend du flux reçu, de la surface, du rendement, de la température et de l’orientation. Sur Mars, poussière et saison modifient encore la disponibilité. D’autres architectures peuvent utiliser des sources nucléaires ou hybrides. La question système reste la même : quelle puissance garantie peut-on fournir dans le pire état crédible, pas seulement à midi dans le cas nominal ?
Réflexe d’ingénierie. Pour « production : solaire, sources alternatives et orientation », noter d’abord les entrées, les sorties, les unités et la plage de validité. Puis construire un cas nominal et un cas dégradé. Ce double calcul empêche de confondre une relation mathématique correcte avec une architecture réellement exploitable sur Mars.
3. Batteries : énergie, puissance, profondeur de décharge et vieillissement
Une batterie a une capacité énergétique mais aussi des limites de courant, température et état de charge. Des cycles profonds ou des températures défavorables accélèrent le vieillissement. Le dimensionnement doit donc conserver une marge après plusieurs années, pas uniquement le premier jour. Le système de gestion protège les cellules mais peut lui-même devenir une fonction critique.
Réflexe d’ingénierie. Pour « batteries : énergie, puissance, profondeur de décharge et vieillissement », noter d’abord les entrées, les sorties, les unités et la plage de validité. Puis construire un cas nominal et un cas dégradé. Ce double calcul empêche de confondre une relation mathématique correcte avec une architecture réellement exploitable sur Mars.
4. Conversion et distribution
Les panneaux et batteries ne délivrent pas forcément la tension souhaitée par chaque équipement. Convertisseurs, bus, protections et interrupteurs distribuent l’énergie. Une architecture doit isoler un défaut sans éteindre tout le véhicule. Les courants de court-circuit, appels au démarrage et pertes de conversion appartiennent au budget, tout comme les chemins de retour et la compatibilité électromagnétique.
Réflexe d’ingénierie. Pour « conversion et distribution », noter d’abord les entrées, les sorties, les unités et la plage de validité. Puis construire un cas nominal et un cas dégradé. Ce double calcul empêche de confondre une relation mathématique correcte avec une architecture réellement exploitable sur Mars.
5. Capteurs, acquisition et calcul embarqué
L’avionique transforme le monde physique en données : tensions, températures, accélérations, images, pression. Le calculateur horodate, filtre et interprète ces mesures. Une valeur numérique n’est utile que si l’on connaît sa plage, sa précision, sa fréquence d’échantillonnage et son statut. Un capteur bloqué à une valeur plausible est souvent plus dangereux qu’un capteur manifestement mort.
Réflexe d’ingénierie. Pour « capteurs, acquisition et calcul embarqué », noter d’abord les entrées, les sorties, les unités et la plage de validité. Puis construire un cas nominal et un cas dégradé. Ce double calcul empêche de confondre une relation mathématique correcte avec une architecture réellement exploitable sur Mars.
6. Bus de données et interfaces
Les sous-systèmes échangent commandes et télémesures par des bus et réseaux. Les interfaces doivent préciser formats, unités, cadence, latence, comportement en erreur et autorité. Deux équipements peuvent fonctionner parfaitement séparément et échouer une fois intégrés si l’un attend des degrés et l’autre envoie des radians, ou si une commande est interprétée avec un mauvais état.
Réflexe d’ingénierie. Pour « bus de données et interfaces », noter d’abord les entrées, les sorties, les unités et la plage de validité. Puis construire un cas nominal et un cas dégradé. Ce double calcul empêche de confondre une relation mathématique correcte avec une architecture réellement exploitable sur Mars.
7. Logiciel de vol : états, tâches et déterminisme
Le logiciel de vol exécute des tâches périodiques, gère des états de mission et applique des règles de sécurité. Dans un système critique, il faut pouvoir expliquer quelles conditions déclenchent une transition et quel composant a autorité. Le déterminisme signifie qu’une fonction critique respecte ses délais et son ordre d’exécution ; il ne suffit pas qu’elle soit « rapide en moyenne ».
Réflexe d’ingénierie. Pour « logiciel de vol : états, tâches et déterminisme », noter d’abord les entrées, les sorties, les unités et la plage de validité. Puis construire un cas nominal et un cas dégradé. Ce double calcul empêche de confondre une relation mathématique correcte avec une architecture réellement exploitable sur Mars.
8. FDIR et mode sûr
Fault Detection, Isolation and Recovery regroupe détection, localisation et réponse aux défauts. Une réaction automatique peut sauver un véhicule mais aussi aggraver une mauvaise mesure. Le mode sûr vise un état durable où énergie, thermique et communications sont stabilisés pendant que le diagnostic continue. Il doit être testé comme une vraie configuration, pas seulement décrit dans un document.
Réflexe d’ingénierie. Pour « fdir et mode sûr », noter d’abord les entrées, les sorties, les unités et la plage de validité. Puis construire un cas nominal et un cas dégradé. Ce double calcul empêche de confondre une relation mathématique correcte avec une architecture réellement exploitable sur Mars.
9. Logiciel critique : exigences, tests et configuration
Le logiciel évolue jusqu’au lancement et parfois après. Il faut donc versionner code, paramètres, interfaces et résultats d’essai. Chaque exigence critique doit être vérifiable. Les tests unitaires ne suffisent pas : intégration, simulation, matériel-dans-la-boucle, scénarios d’erreur et régression sont nécessaires pour comprendre le comportement du système complet.
Réflexe d’ingénierie. Pour « logiciel critique : exigences, tests et configuration », noter d’abord les entrées, les sorties, les unités et la plage de validité. Puis construire un cas nominal et un cas dégradé. Ce double calcul empêche de confondre une relation mathématique correcte avec une architecture réellement exploitable sur Mars.
Exemple calculé pas à pas
La méthode de travail est toujours la même : écrire ce que représente chaque symbole, convertir toutes les unités vers un système cohérent, effectuer l’opération, puis traduire le résultat en phrase. Enfin, faire un contrôle d’ordre de grandeur. Si le résultat change de facteur mille lorsqu’on passe de millimètres à mètres, la conversion doit être visible dans le calcul.
Exercice progressif
- Choisir un cas simple et lister toutes les données avec leurs unités.
- Calculer le résultat nominal sans marge.
- Modifier le paramètre le plus incertain de ±20 % et comparer.
- Ajouter une panne crédible et expliquer quel indicateur permet de la détecter.
- Décider si le système continue, se dégrade ou doit s’arrêter.
Solution raisonnée
Une bonne solution ne se résume pas au nombre final. Elle montre les conversions, la logique de la formule, la sensibilité et la décision. Si deux hypothèses différentes conduisent à la même décision opérationnelle, la conception est relativement robuste à cette incertitude. Si une petite variation inverse la décision, le paramètre doit devenir une priorité de mesure ou de marge.
Mini-projet de validation
Construire une note d’ingénierie de deux à quatre pages appliquant le cours à un sous-système martien. Le document doit contenir : besoin, hypothèses, schéma fonctionnel, calcul manuel, vérification par un second calcul ou une simulation, incertitudes, panne injectée, critères de décision et trois références primaires. L’objectif est de produire une chaîne de preuve que quelqu’un d’autre peut relire et refaire.
Erreurs classiques à détecter
- mélanger unités ou repères sans conversion visible ;
- présenter une valeur calculée comme une donnée mesurée ;
- ignorer la plage de validité d’un modèle ;
- confondre précision numérique et exactitude physique ;
- dimensionner sur le seul cas nominal sans marge ni mode dégradé.