Réflexions sur le 'man-rating' d'Ariane et autres lanceurs

A la suite des nombreuses discussions sur la capacité à être 'human rated' d'Ariane 5, j'ai été consulter le document NASA NPR 8705.2A 'Human-Rating requirements for Space Systems', chap 3 : System Design Requirements et j'ai revu l'architecture électrique Ariane 5 à sa lumière.

Il y a deux exigences majeures:

3.1.1 Space systems shall be designed so that no two failures result in crew or passenger fatality or permanent disability (Requirement 34419).

3.1.6 Space systems shall not use emergency systems or contingency and emergency operations (such as fire suppression or crew escape) to satisfy the two-failure tolerance requirement or two-inadvertent action requirement (Requirement 34429).

A la lecture de la 3.1.1 on peut se dire qu'un système Fail Op/Fail Safe remplit la demande. Ariane 5 étant redondée complètement au niveau électrique (A4 ne l'était pas au niveau calculateur) la première panne permet de continuer la mission, la deuxième conduit à une évacuation de l'équipage. C'est un peu limite car le Fail Safe est obtenu par destruction du lanceur en cas de vol non habité et il est bien entendu que ce ne pourrait être le cas avec des hommes à bord. Il faut bien voir qu'en cas d'avarie ultime la séquence de destruction est déclenchée par la rupture de fils courant le long de la structure lanceur lorsque celle ci commence à perdre son intégrité. Il n'y a pas besoin d'avoir une système électrique foonctionnel pour y arriver. Sans compter le suivi optique à terre par l'opérateur de sauvegarde. Avec des hommes à bord il faudrait détecter la panne avant que le lanceur ne commence à se briser. Soit on fait une absolue confiance aux autotests, ce qui est déja le cas (une hypothèse forte du système est que les SRI comme les OBC sont capables de s'autodétecter en panne). Soit il faut passer à du triplex. C'est exactement ce qui était fait sur Hermès (quadruplex même).
On garde le lanceur et on remplace la case lanceur par la case du véhicule habité. C'est une option de design car on peut aussi garder une case lanceur et une case véhicule habité.

Là où cela se gate c'est que la deuxième exigence 3.1.6 exclut l'utilisation des moyens de sauvegarde en cas de deuxième panne. Sur une A5 ça ne marche plus du tout. Par exemple perdre les deux bus 1553 (en imaginant un pool calculo dans le véhicule habité) conduit à évacuer le lanceur fissa car il n'y a plus aucune commandabilité restante.

Conclusion, en appliquant le doc NASA au pied de la lettre côté électrique, il faut passer au moins en triplex sur les chaînes électriques lanceur et remplacer la case actuelle par une architecture en quadruplex au niveau calculateur. C'est pas gagné au niveau de la facture. Surtout si on veut en plus faire de la diversité logicielle. Sans compter, par ailleurs, les coûts de validation du bastringue.

Anecdotiquement je suis assez curieux de savoir si les Atlas sont en triplex?

J'ai lu dans un post que les redondances avaient été réduites sur A5 pour gagner de la charge utile. A ma connaissance ce n'est pas exact. Le design a toujours été en duplex depuis l'origine et l'est toujours. Comme mentionné on a même redondé le calculateur de vol qui ne l'était pas sur les Ariane 4 et précédentes.

Le rationnel de la redondance sur un lanceur non habité n'est pas tellement la sécurité, on peut toujours le détruire en vol, mais la probabilité de succès qui est un facteur économique et commercial important. L'ordre de grandeur du coût du système électrique est dans les 10% du coût total du lanceur, ne pas le redonder ne fait pas gagner grand chose au regard des coûts d'assurance qui prennent en compte la fiabilité pour fixer la facture.

Enfin, quant à la configuration d'un véhicule ailé au sommet du lanceur ou accroché sur le réservoir, ce n'est pas non plus une décision économique, comme il m'a semblé le lire, mais le résultat de considérations d'efforts aérodynamiques et de stabilité du composite. De ce point de vue, la configuration d'Hermès n'était pas très glorieuse, disons qu'il y a eu une certaine pudeur sur le sujet.... La plupart des lancements d'un véhicule ailé ont eu lieu en configuration 'sur réservoir':
Shuttle, Bourane et son homonyme qui était un missile de croisière à statoréacteurs de chez Lavochkine, Navaho américain et sans doute d'autres que je ne connais pas. Les contre exemples existent mais il s'agit en général de très petits véhicules limitant fortement les moments aérodynamiques sur la structure.

Bons Vols

Merci DeepThroat pour ces infos tres intéressant

Intéressant DeepThroat mais sans doute devenu caduque car avec l'arrêt du projet CSTS il est probable qu'Ariane5 ne connaisse jamais de version man-rated...

De plus il est probable que le véhicule habité d'Energia soit assez peu ailé. Au plus une forme portante mais guerre plus. Les russes ont surtout envisagé un lancement au top de la fusée (Soyouz 2-3 ou 3).

Je n'adressais pas spécialement le projet CSTS, je voulais juste faire un point sur ces questions qui ont été évoquées tout au long de cette discussion. Ces considérations restent applicables pour n'importe quel lanceur.
J'espère simplement avoir apporté quelques informations utiles.

Bons Vols

Merci pour l'info DeepThroat

DeepThroat a écrit:
Enfin, quant à la configuration d'un véhicule ailé au sommet du lanceur ou accroché sur le réservoir, ce n'est pas non plus une décision économique, comme il m'a semblé le lire, mais le résultat de considérations d'efforts aérodynamiques et de stabilité du composite. De ce point de vue, la configuration d'Hermès n'était pas très glorieuse, disons qu'il y a eu une certaine pudeur sur le sujet.... La plupart des lancements d'un véhicule ailé ont eu lieu en configuration 'sur réservoir':
Shuttle, Bourane et son homonyme qui était un missile de croisière à statoréacteurs de chez Lavochkine, Navaho américain et sans doute d'autres que je ne connais pas. Les contre exemples existent mais il s'agit en général de très petits véhicules limitant fortement les moments aérodynamiques sur la structure.

Bons Vols

Merci de cette clarification qui permet mieux de saisir le dilemme auquel on est confronté pour le choix de la position d'un véhicule ailé , soit latéralement, soit au sommet: dans les deux cas, il y a des problèmes à résoudre même s’ils ne sont pas de même nature.

Ne pas croire que mon post précédent représente ma conviction profonde en matière de lanceur. Si on tient compte de la durée de fonctionnement du lanceur (moins d'une heure au grand maximum) et que l'on est prêt à utiliser la sauvegarde en cas de 'deuxième' défaillance sur une même fonctionune solution où l'on conserverait le lanceur tel quel et où la case serait remplacée par celle du véhicule habité me semble très raisonnable. De mémoire ce devait être la configuration d'Hermès.
Je crois que les spécifications US relèvent de missions longues telles que les missions lunaires où effectivement l'utilisation d'une sauvegarde hors de l'orbite terrestre peut présenter quelques légères difficultés.
Je ne parle que du lanceur. Pour le véhicule habité lui même une triplication des chaînes serait de bon aloi. Je me demande d'ailleurs si on ne verra pas ce genre de chose sur les prochains lanceurs US. Encore que l'aspect coût d'une troisième chaîne soit finalement marginal rapporté à l'ensemble et aux coûts des discussions des gardiens des normes....
Pour l'anecdote, sur les avions de combat on se contente en général de redondance duplex car il est admis que l'équipage s'éjecte en cas de défaillance non récupérable. Les calculateurs de commande de vol sont en quadruplex mais c'est pour une question de détection de panne, pas vraiment de fiabilité. D'ailleurs quatre calculateurs ensemble sont bien moins fiables qu'un seul, mais ils disent plus facilement lequel est en panne et comment le remplacer.....

Bons Vols

Je ne comprends pas vraiment la raison de la deuxième exigence...
Le calculateur de la capsule habité perd les deux bus 1553 qui la relie au lanceur (j'aimerai savoir quelle est la probabilité de perte de ces deux bus)
rien ne l'empêche alors de commander la tour d'éjection de la capsule et l'équipage est sauf.
D'ailleurs dans les deux cas où on a perdu Ariane 5, un tel système aurait permis de sauver l'équipage (AMHA).
Je pense qu'on pourrai au prix de modification mineurs (et encore) prendre Ariane-5ES ATV et mettre une capsule dessus !
Je suis peut être un peut trop optimiste, mais si on a assez confiance en Ariane pour mettre l'ATV dessus, alors avec une tour d'éjection...

Je n'ai pas la justification des exigences (normalement un document existe sur ce sujet....) donc ce qui suit est purement mon interprétation du sujet :sage: .

Si on revient au problème de base de ce genre d'exercice, la question est d'évaluer les chances de ramener tout le monde dans un état présentable. Si possible autrement qu'avec musique funèbre, drapeau et prolonge d'artillerie..... Donc, il faut disposer d'éléments quantitatifs pour évaluer la solution proposée par les industriels qui, c'est bien connu, ont essayé de tirer le maximum de profit des généreux contrats accordés par les généreuses agences. Pour cela on dispose de méthodes de calcul de probabilité de défaillance. En matière de systèmes électroniques les deux outils favoris sont :study: :
-les modèles de Markov
-la norme Mil Hdbk 217
Munis de ces deux articles on peut, avec un peu de sueur, donner un chiffre de fiabilité du système électrique qui viendra pondérer celui des autres systèmes. Bref au bout du compte on arrive en général à des chiffres peu encourageants dès lors que la mission dure ou que la complexité est grande. Pour fixer les idées, il n'est pas exceptionnel de tomber sur du 0.6 ou du 0.7 à 5 ans pour un satellite un rien complexe.
J'en vois déja qui s'émeuvent au fond de la salle, quoi! si peu fiable un truc si cher! Eh non, dans la réalité la fiabilité observée est meilleure, mais pour des raisons purement techniques la Mil 217 est des plus pessimistes.
Pour faire court, la position actuelle est de considérer qu'un calcul de fiab permet de comparer des solutions entre elles mais ne représente pas la fiabilité réelle attendue. Heureusement....
Bon, revenons à notre problème, si on ne peut pas se fier aux chiffres (mais qu'est ce qu'ils foutent les ingénieurs....) que fait on? On en revient aux principes. Un principe c'est comme la foi, ça ne se démontre pas, mais ça peut sauver :eeks:
Pour ceux qui sont un peu lents des neuronnes, j'explique: Vous allez sauter en parachute, un type à l'air grave et pénétré (lui reste dans l'avion...) vous explique que votre dorsal a une chance sur un million de ne pas s'ouvrir et qu'utiliser un ventral est tout donc tout à fait inutile, vous rendra le saut infiniment plus confortable et tellement plus phototgénique. Bien sur, si la voile ne se déploie pas, il peut y avoir quelques légers inconvénients, mais bon, un sur un million n'est ce pas...
Sauf à avoir une foi totale dans la technique et un zeste de mépris pour votre peau, vous finissez avec un ventral en plus du dorsal, la prière des paras au fond du sac, une patte de lapin, et si vous en aviez eu le temps,un pèlerinage à Lourdes. Bravo, vous avez des principes.
Bref un principe c'est une décision à priori dont on espère que les conséquences iront dans le sens espéré.

Je reviens à notre problème. Je prends un lanceur de base. Je ne redonde rien. Si ça cloche, on détruit (faudra quand même redonder le système destruction...). J'ai du Fail Safe du point de vue global: ça flanche mais je ne tue personne.
Bon, mais ça finit par couter cher. Mon assureur gueule. Donc je redonde. Première défaillance je continue, deuxième je détruis. Résultat Fail Op Fail Safe. C'est mieux et ça reste raisonnable.
Maintenant je mets des humains dans le système. Faut faire mieux par principe. Moralité on triplique pour espérer être en Fail Op Fail Op Fail Safe. Le Fail Safe étant l'évacuation pas la destruction de l'équipage bien sur.... :lol!:

Je pense que la première exigence découle de la philosophie des avions de combat, philo qui conduit à de la redondance duplex. Comme quelques minutes de réflexion montrent que l'industriel répondra conforme à l'exigence avec un duplex et une philo Fail Op Fail Safe, la deuxième exigence a été ajoutée pour éviter ce genre de simplifications et aussi pour traiter les phases où l'évacuation n'est pas possible. C'est un principe à l'aune duquel on examinera la conception indépendamment de toute évaluation chiffrée. Ce n'est que lorsque le principe ne sera pas satisfait qu'on ira triturer les chiffres pour se convaincre que l'on peut prendre le risque.

Enfin pour répondre à la dernière question sur la probabilité de perdre les deux bus 1553, la réponse dépend du type de panne considéré. Si on ne considère que les pannes matérielles la proba n'est pas grande. Par contre on ne sait pas sérieusement chiffrer une probabilité de défaillance du logiciel qui conduirait à ce que les deux OBC crachent ensemble sur les bus (il y a des protections malgré tout....mais je simplifie un peu).
Ce n'est pas de la théorie, Vol 501 s'est planté àla base parceque les deux centrales à inertie: les SRI, se sont envoyées en l'air (sans jeux de mots) sur un overflow logiciel qui est apparu comme une panne commune. La probabilité calculée pour perdre les deux SRI simultanément sur panne matérielle était epsilonesque.... Ici, un triplex n'aurait rien changé, la troisième SRI se serait crashée identiquement. La solution eut été de disposer d'une autre version de SRI développée avec un logiciel différent, mais c'est une autre histoire.... :???:

Bons Vols

Blink / Pamplemousse a écrit:On sait pourquoi le projet CSTS est arrêté ?

Pour traiter la sûreté de fonctionnement très en amont: comme ça, on a vraiment 0 % de chance (démontrée) de porter atteinte à l'intégrité des équipages. ;) Ok, je sors ...

Commander Ham a écrit:Je ne comprends pas vraiment la raison de la deuxième exigence...

Non, je reste ...
L'exigence 3.1.6 est là pour interdire que l'on ait recours trop souvent, pour satisfaire les exigences 3.1.1 et 3.1.3, à des solutions conduisant à l'arrêt de mission ...

L'exigence 3.1.7 enfonce encore le clou:

3.1.7 Space systems shall not use abort as the first leg of failure tolerance

CosmoS a écrit:

Commander Ham a écrit:Je ne comprends pas vraiment la raison de la deuxième exigence...

Non, je reste ...
L'exigence 3.1.6 est là pour interdire que l'on ait recours trop souvent, pour satisfaire les exigences 3.1.1 et 3.1.3, à des solutions conduisant à l'arrêt de mission ...

L'exigence 3.1.7 enfonce encore le clou:

3.1.7 Space systems shall not use abort as the first leg of failure tolerance

Je trouve cette discussion passionnante.
L'exigence 3.1.1 dit que deux pannes ne doivent pas entrainer perte ou blessure de l'équipage.
L'exigence 3.1.6 dit qu'on ne doit pas utiliser de système d'évacuation de l'équipage pour satisfaire 3.1.1.
Or si j'analyse bien : Ariane 5 est redondé 2 fois au niveau électrique / calculateur.
Donc si on a une panne, elle vole toujours.
Par contre en cas de deuxième panne, elle ne vole plus mais on peut toujours sauver l'équipage.
On peut en déduire que l'exigence 3.1.1 est satisfaite.
Mais on utilise alors la tour de sauvetage donc l'exigence 3.1.6 ne l'est pas.
Mais est ce si compliqué que cela de tripler la redondance sur les calculateurs et bus?
Et puis, est ce vraiment nécessaire ? Comme l'a dit DeepThroat, un bug de conception de programme sera le même sur les n calculateurs redondés !
Je m'explique : la durée de vol d'Ariane n'excède pas 1 heure - il me semble. (Quelle est la durée pour la mission ATV ?)
Il me semble que ce paramètre doit aussi rentrer en ligne de compte dans le calcul de probabilité de défaillance.
Ca ne sert à rien de faire un système robuste aux pannes sur 6 mois s'il ne fonctionne à chaque fois qu'1 heure !

Pour clore ce message, sait-on quel est le niveau de redondance du lanceur soyuz?

Commander Ham a écrit:
Je trouve cette discussion passionnante.
L'exigence 3.1.1 dit que deux pannes ne doivent pas entrainer perte ou blessure de l'équipage.
L'exigence 3.1.6 dit qu'on ne doit pas utiliser de système d'évacuation de l'équipage pour satisfaire 3.1.1.
Or si j'analyse bien : Ariane 5 est redondé 2 fois au niveau électrique / calculateur.
Donc si on a une panne, elle vole toujours.
Par contre en cas de deuxième panne, elle ne vole plus mais on peut toujours sauver l'équipage.
On peut en déduire que l'exigence 3.1.1 est satisfaite.
Mais on utilise alors la tour de sauvetage donc l'exigence 3.1.6 ne l'est pas.

C'est bien l'idée, en considérant un équipement avec redondance (simple - je suppose que c'est ce que tu voulais dire) comme la centrale inertielle.
Le recours aux systèmes et opérations d'urgence (3.1.6) ou à l'abandon de la mission (3.1.7) doit être réservé à des cas encore plus "graves" (donc en principe encore moins probables) que les doubles pannes. C'est du moins ce que j'ai compris.

Commander Ham a écrit:
Mais est ce si compliqué que cela de tripler la redondance sur les calculateurs et bus?
Et puis, est ce vraiment nécessaire ? Comme l'a dit DeepThroat, un bug de conception de programme sera le même sur les n calculateurs redondés !
Je m'explique : la durée de vol d'Ariane n'excède pas 1 heure - il me semble. (Quelle est la durée pour la mission ATV ?)
Il me semble que ce paramètre doit aussi rentrer en ligne de compte dans le calcul de probabilité de défaillance.
Ca ne sert à rien de faire un système robuste aux pannes sur 6 mois s'il ne fonctionne à chaque fois qu'1 heure !

Par nature, la redondance complexifie, alourdit et renchérit le lanceur, et effectivement, elle n'est pas forcément nécessaire (cf. cas (b) de l'exigence 3.1.2) ni faisable (cas (a)).
Bien entendu, la durée de mission rentre en ligne de compte et n'induit pas forcément les mêmes solutions (voir les Notes de l'exigence 3.1.1 ).
Dans tous les cas, la redondance n'est utile que vis-à-vis des pannes aléatoires. Le problème du bug d'Ariane 501 est qu'il était tout à fait déterministe :| .

Mais est ce si compliqué que cela de tripler la redondance sur les calculateurs et bus?

Oui! :affraid:

Je m'explique. La triplication du bus conduit à ajouter un Controleur de Bus à chaque calculateur, ce qui dans les hypothèses A5 revient à refaire la moitié du calculateur au moins: (il y a deux cartes, une carte calcul et une carte I/O). La carte I/O est aussi complexe que la carte calcul, elle comprend son propre CPU et sa mémoire... Ensuite tripliquer le bus veut dire refaire tout le routage électrique du lanceur et de la case. Par ailleurs tripliquer le bus sans tripliquer les équipements qui y sont accrochés n'a pas grand sens...il faut aussi installer ces équipements ce qui fait du poids et du volume en plus. Au niveau calculateur ajouter un troisième calculateur n'a de sens qu'en terme de couverture de panne. Pas en terme de fiabilité, car comme déja mentionné la durée du vol est courte et la probabilité de défaillance d'un calculateur n'est pas grande. Mais si on change la philo de détection de panne on doit tout reprendre. Actuellement la philo de détection est basée sur des autotests, en faisant simple un calculateur est maître du lanceur pendant que l'autre est passif, écoutant les échanges sur le bus mais ne prenant pas la main. Pour qu'il y ait changement de calculateur il faut que le maître se déclare en panne. Comme dans les bons westerns "vas y Joe, laisse moi crever, occupe toi du lanceur..."
il doit passer la main explicitement. Dans une configuration triplex il y a un mécanisme de vote qui conduit à ce que deux aient raison sur un. C'est un concept entièrement different tant au niveau matériel que logiciel. Donc, il faut tout reprendre. Si en plus on applique la philo strictement et que l'on veut tolérer au moins deux pannes on va droit au quadruplex.
En conclusion, il faut au minimum virer la case actuelle et faire piloter le lanceur par le véhicule habité. Si on triplique ce qui reste dans le lanceur on recommnece un gros bout de ce qui a déja été fait.

Pour l'anecdote lors du vol 501 la séquence de défaillance observée a été:
SRI (2, je crois) se déclare en panne
Calculateur maître inhibe les acquisitions SRI
SRI (l'autre la 1) se déclare en panne (même motif, même punition)
Calculateur maître voit les deux SRI perdues.
Calculateur maître tente l'accès par le bus redondant (hypothèse perte bus car perte deux SRI moins probable). Echec.
Calculateur maître se déclare en panne (car perte des deux SRI moins probable que panne calculateur)
Calculateur maître envoie le signal de commutation à calculateur redondant.
Calculateur redondant prend la main (après avoir vérifié qu'il n'y a plus de traffic bus venu du calculateur maître) et constate dans la foulée que les deux SRI sont "out" et qu'elles ne communiquent plus sur les bus.
Calculateur redondant ne se déclare pas en panne et continue la mission (il n'y a plus que cela à faire, et prier)
Faute de données inertielles valides le pilotage lanceur se vautre.
Destruction du lanceur.
La case se sépare du lanceur et au moins un plateau porte équipement est éjecté (pas très clair si l'éjection a eu lieu en vol ou à l'impact).
La télémesure case est reçue jusqu'à l'impact au sol témoignant que celle ci fonctionne toujours après l'explosion du lanceur.
Les calculateurs seront récupérés après l'impact. Un est détruit. Le second est toujours fonctionnel.

Fin de l'histoire.

Bons Vols

Merci pour le déroulement de la séquence niveau informatique embarqué (ma spécialité :blbl: ) du vol 501.
Il est vrai que si on change le principe de détection de panne par autotest en détection de panne par consensus,
il faut refaire toute l'architecture logicielle (et surement matérielle) !

On peut se consoler en se disant que toute la partie mécanique, aérodynamique et structurelle est déjà là.

Pour finir, personne ne connait le niveau de redondance sur cette vieille Semiorka?

DeepThroat, es tu certain de cette séquence compliquée ? C'est la première fois que j'entends parler d'une commutation OBC à 501 ! Le rapport de la commission d'enquête ne le mentionne pas :scratch: :

Navré du retard pour la réponse, je n'avais pas vu la question. :shock:

Donc, je confirme. Il y a deux calculateurs sur la case, et la TM a bien montré la commutation. C'est même le premier symptome observé. Dans les premières minutes après la destruction l'opinion générale était que les calculateurs s'étaient plantés. Ce n'est q'après dépouillement de la TM que les SRI ont été mises en cause.
La description de l'INRIA est un peu inexacte. Si j'ai bonne mémoire les deux centrales transmettaient les données vers le pool calculateur, mais le programme de vol n'utilisait que les données de celle déclarée nominale. L'autre ne devait être utilisée que sur défaillance.
De même la commission ne mentionne pas le fait que le bout de code qui était en cause ne servait à rien et était un reliquat des centrales Ariane 4. Le problème était que ce code comprenait une variable correspondant à la projection de la trajectoire lanceur au sol. A5 ayant une trajectoire beaucoup plus inclinée pour profiter de la portance induite par les boosters, la variable a saturé. Il y a eu levée d'une exception ADA, non gérée, qui à conduit à l'arrêt du calculateur de la SRI.
Au fin fond du problème, la vrai cause est la façon dont le soft de vol a été validé: sur un banc utilisant des centrales simulées. Pour des raisons d'économie....(les centrales venant de A4 elles étaient réputées fonctionner....).
Après l'échec il y a eu un vrai cirque sur la qualité logiciel et tous les organismes ayant un rapport avec ce sujet sont venus participer à la fiesta. :face:


Bons Vols

Les centrales simulées étant celles d'Ariane 4, cela expliquerait pourquoi l'exception n'avait pas été levée. Et par curiosité dans ces softs, il y en a beaucoup des exceptions qui sont libres de se propager lorsqu'elles sont levées. (moi qui croyais naïvement que l'instruction "exception" était largement utilisée dans les sous-programmes et fonctions des corps de paquetages Ada...)

PS : J'ai du ressortir mon Norman H. Cohen ;)

DeepThroat a écrit:
La description de l'INRIA est un peu inexacte.

Attention (je suppose que tu l'as bien vu, mais je crois bon de le signaler à tous): il ne s'agit pas d'un document INRIA mais du document officiel de la commission Lions, qu'un chercheur de l'INRIA n'a fait que recopier sur son site. Cela dit, un membre de l'INRIA a participé à cette commission (et, plus anecdotiquement, JL Lions a été le 1er président de cet organisme).

DeepThroat a écrit:
Si j'ai bonne mémoire les deux centrales transmettaient les données vers le pool calculateur, mais le programme de vol n'utilisait que les données de celle déclarée nominale. L'autre ne devait être utilisée que sur défaillance.
De même la commission ne mentionne pas le fait que le bout de code qui était en cause ne servait à rien et était un reliquat des centrales Ariane 4. Le problème était que ce code comprenait une variable correspondant à la projection de la trajectoire lanceur au sol. A5 ayant une trajectoire beaucoup plus inclinée pour profiter de la portance induite par les boosters, la variable a saturé. Il y a eu levée d'une exception ADA, non gérée, qui à conduit à l'arrêt du calculateur de la SRI.

Cela est bien mentionné dans les résultats de l'enquete (à partir du point "m"). Finalement, l'execution de ce bout de code était doublement inutile: pas le bon lanceur, pas la bonne phase de vol non plus ! :roll:
Sur la commutation du calculateur, je ne mets pas en doute ta connaissance du sujet, mais je suis surpris car les points "g" et "h" mentionnent explicitement le calculateur principal.

Sur la commutation du calculateur, je ne mets pas en doute ta connaissance du sujet, mais je suis surpris car les points "g" et "h" mentionnent explicitement le calculateur principal.

Je persiste et signe, il y a eu commutation des calculateurs. :wall:
Peut être l'utilisation du terme 'principal' est elle destinée à faire la distinction entre les calculateurs des SRI et le pool des OBC destinées au contrôle du lanceur. Il me semble me souvenir qu'il y a aussi un calculateur dans l'UCTM. On a bien observé l'arrêt des communications sur les bus 1553 au moment de la commutation, l'activation du signal inter OBC de commutation, et la reprise des trames sur les bus. Je maintiens.

il y en a beaucoup des exceptions qui sont libres de se propager lorsqu'elles sont levées.

Là je ne m'en souviens plus. Attention, il s'agit du soft des centrales, pas du soft OBC qui est aussi en ADA. De mémoire, toujours, il y en avait plus d'une....Depuis, bien sûr, tout cela a été corrigé....

Bons Vols

DeepThroat a écrit:

Sur la commutation du calculateur, je ne mets pas en doute ta connaissance du sujet, mais je suis surpris car les points "g" et "h" mentionnent explicitement le calculateur principal.

Je persiste et signe, il y a eu commutation des calculateurs. :wall:
Peut être l'utilisation du terme 'principal' est elle destinée à faire la distinction entre les calculateurs des SRI et le pool des OBC destinées au contrôle du lanceur.

Attention la tête ;) .
Il me semble qu'il n'y a pas vraiment d'ambiguité possible sur le fait que dans les points "g" et "h", le mot "calculateur" désigne l'OBC - ou en tout cas celui qui est actif à l'instant considéré - et pas celui des SRI ou d'autres sous-systèmes, donc je vois mal l'apport du "principal". Sachant qu'il y a eu commutation d'OBC (encore une fois, je ne mets pas en doute tes dires 8-) ), on dirait que "calculateur principal" est utilisé ici comme synonyme d' "OBC" tout court, sous entendu: celui qui est actif à l'instant considéré, qu'il s'agisse du "main" ou du "spare".
Si c'est ça, c'est quand même sacrément trompeur, d'autant qu'il est bien rappelé au début du rapport que l'OBC (entre autres sous-systèmes) est dupliqué.
Cela dit, cela peut se comprendre que le rapport de synthèse ne donne qu'une version simplifiée de la séquence de panne, en limitant tout ce qui est redondance/commutation aux seuls SRI (mais ce n'était pas évident a priori !).

je me posais a question ( peut être bête) mais quelles étapes doit franchir un lanceur si il veut être dit "man rated" ?
quelles doivent être ses caractéristiques ?? ( je suppose que sa doit avoir rapport avec les G appliqué a la "charge utile" )

Fiabilité, systèmes redondants à souhait et surtout dévelopement d'un système de fusée de secours comme sur les Saturn ou Soyuz. Sans doute, l'infrastructre au sol doit être modifiée, s'il s'agit d'un lanceur éxistant déjà (Ariane, Delta, Atlas).

D'autres suggestions? :scratch:

Spaceman a écrit:Fiabilité, systèmes redondants à souhait et surtout dévelopement d'un système de fusée de secours comme sur les Saturn ou Soyuz. Sans doute, l'infrastructre au sol doit être modifiée, s'il s'agit d'un lanceur éxistant déjà (Ariane, Delta, Atlas).

D'autres suggestions? :scratch:

Équipe de soutient au sol, équipe de récupération et son matériel, système informatique à niveau...

Il faut enlever certaines vibrations qui pourraient être dangereuses pour l'équipage.

Il faut une tour pour que les astronautes puissent monter dans leur vaisseau au sommet de la fusée.