WWW.CRASH-AERIEN.AERO
http://www.crash-aerien.news/forum/

Un avion de Air France disparait en Atlantique (Partie 1)
http://www.crash-aerien.news/forum/un-avion-de-air-france-disparait-en-atlantique-partie-1-t11597-5895.html
Page 394 sur 400

Auteur:  Alexandre G. [ Sam 27 Juin 2009 14:59 ]
Sujet du message: 

CZmax a écrit:
Je sais que vous vous etes donné du mal pour nous pondre un post aussi long mais ce n'est pas une raison pour nous le resservir deux fois...(http://www.crash-aerien.com/forum/precedente-vt11597.html?postdays=0&postorder=asc&start=5730)

Toutefois vous omettez d'y préciser toutes les difficultés qu'éprouve AF à se séparer de ses éléments incontrôlables, dangereux et hermetiques à toute notion de CRM...notamment des CDB. Et pourtant il en va de la sécurité des vols.
Qu'en pensez vous ?


Rassurez-vous je n'ai aucun mal à écrire, et ça ne me prend pas beaucoup de temps, je le dicte ....

Le CRM entre deux copilotes, en situation difficile est effectivement un gros problème, on en aura probablement la preuve.... Si on retrouve le CVR. Mais voyez vous je trouve qu'il est plus sain de parler des choses qui se sont produites, des faits avérés, des vrais accidents dont celui-ci, de vrais morts, dont ceux que nous déplorons et nos pas de ceux que vous supposeriez survenir dans les mains de ces pilotes dangereux à propos desquels vous accusez Air France de Négligence voire de laxisme.

Il me semble que dire publiquement qu'Air France ferme les yeux sur des pilotes supposés dangereux est grave et que c'est de nature à faire quelques ennuis à Crash Master, d'accepter de publier vos assertions diffamatoires, surtout en ce moment !

Qui est dangereux ? Le Pilote de Toronto qu'on a remis en Ligne et dont son chef de secteur disait-lui même qu'il était très fragile..... mais que bon ça allait s'arranger......

Qui est dangereux le CDB d'Abidjan, dont Gilbert Rovetto disait lui même que le pauvre, s'était concentré sur la vitesse en remise de gaz, et que le pauvre avait complètement.

Qui est dangereux le pilote de Douala, qui ayant cru qu'il y avait une ligne axiale, s'était aligné sur le bord droit de la piste malgré un CRM parfait de son copilote qui lui disait que la piste était à gauche, sans obtenir de réactions ?

Se poser à côté de la piste, comme cela s'est produit, n'a pas été jugé dangereux, toucher de la queue en remise de gaz après avoir été tellement paralysé, qu'il en a roulé dans la pampa pendant 800m avant de penser à tirer sur le manche, n'a pas été considéré comme dangereux, voyez vous... D'ailleurs voir un quelconque danger dans ces incidents graves le BEA, s'est bien gardé de donner un avis...

Ces pilotes sont toujours en Ligne, et sauf je le répète à mettre sérieusement en cause cette Cie en insinuant qu'ils ne devraient pas l'être je pense que vous devriez réserver vos propos pour la Juge chargée de l'enquête.

Je pense que votre aide serait inestimable, car manifestement vous semblez être en mesure d'éviter un prochain accident en alertant les autorités sur les Commandants dangereux de cette Cie. Sur 2 500, si l'on vous prend au mot, il va y avoir bientôt des embauches directes de Captain ?

Vous ai-je déjà dit que à Czmax, on est limité .... limité en tout !

Je parles des marges de manœuvres de l'avion qui sont réduites à zéro, celle de crash master sont en train de le devenir aussi d'ailleurs.

Auteur:  Alexandre G. [ Sam 27 Juin 2009 15:09 ]
Sujet du message: 

[imgx]http://nsm01.casimages.com/img/2009/06/27//090627041108401973963289.png[/imgx]

Auteur:  Alexandre G. [ Sam 27 Juin 2009 15:22 ]
Sujet du message:  La Com technique Air France ?

AIRBUS vient de communiquer à tous ses clients et opérateurs les recommandations suivantes :

Question pour l'enquête portant sur la capacité d'Air France à communiquer les documents à ses pilotes ( au moins Airbus). Les pilotes ont-ils reçu copie dans leurs casiers et/ou sur leur messagerie Air France ? Si NON, Czmax, s'il n'est pas au buffeting pourrait-peut-être, diffuser ?

FROM : AIRBUS CUSTOMER SERVICES TOULOUSE

TO : ALL A318/A319/A320/A321 CFM AIRBUS RESIDENT CUSTOMER SUPPORT MANAGERS

FLIGHT OPERATIONS TELEX - FLIGHT OPERATIONS TELEX
FLIGHT OPERATIONS TELEX - FLIGHT OPERATIONS TELEX

TO: A318-A319-A320-A321 CFM56-5B OPERATORS

SUBJECT: ATA 73 - A320 CFM56-5B FAMILY - Engine stall due to Hydro
Mechanical Unit (HMU) early failure

OUR REF.: STL 999.0055/09 - PHR/ab dated 24 June 2009

CLASSIFICATION: Incident

AFFECTED AIRCRAFT: This FOT is applicable to all A320 family aircraft
equipped with CFM56-5B family engines.

-----------------------------------------------------------------------
Notice:
It is the Operators' responsibility to distribute this FOT, or the
information contained in this FOT, to all A318/A319/A320/A321 CFM56-5B
flight crews without delay.
-----------------------------------------------------------------------

REFERENCED DOCUMENTS:
A: OIT ref. SE 999.0054/09 dated 23 June 2009

1. PURPOSE

The purpose of this FOT is to:
- Inform the Airbus A320 family operators equipped with CFM56-5B
engines of engine stalls due to an issue on the HMU.
- Provide the operators with operational requirements for the
monitoring of engine 'symptoms', especially during engine start, and
the possible cancellation of the departure.

2. DESCRIPTION

Airbus and CFM have been made aware or have had reports of engine
stalls during take-off and climb.
A given list of HMUs is identified to be at the origin of the events.
Most of the events were preceded by symptoms (Start stall, ENG
COMPRESSOR VANE caution) during operations on ground.
For detailed information please refer to OIT SE 999.0054/09 Ref [A].

3. FLIGHT OPERATIONS RECOMMENDATIONS

The Flight Operations department should contact the relevant internal
or external Engineering department in order to check whether the
operator's fleet contains listed HMUs.
If the operator fleet contains listed HMUs, the flight crews must
monitor the symptoms that may appear, especially during engine start.

If both engines of an aircraft have encountered or encounter symptoms,
at least one HMU must be immediately replaced, as per OIT SE
999.0054/09 Ref [A].
If one engine of an aircraft has encountered or encounters symptoms,
the HMU must be replaced no later than after one flight, as per OIT SE
999.0054/09 Ref [A].

3.1 Symptoms monitoring during operations on ground:

If the ECAM triggers any of the following cautions:
- ENG 1(2) COMPRESSOR VANE or
- ENG 1(2) START FAULT - ENG STALL or
- ENG 1(2) STALL
Even if the engine has correctly started or if the ECAM caution has
disappeared, the flight crew must report it in the logbook to ensure
the traceability.
Before flight, the flight crew must also contact immediately the
maintenance in order to check if the departure is allowed, refer to OIT
SE 999.0054/09 Ref[A].

3.2 Engine stall in flight:

If an engine stall occurs in flight, the QRH 2.23 ENG 1(2) STALL
remains applicable.

4. ACTIONS

These operational recommendations will be issued in the OEB 198/1 and
its associated OEB PROC in the QRH.
This OEB and its OEB-PROC are scheduled for dispatch by the end of June
2009.

This OEB should be cancelled with the complete replacement of all the
listed HMU.

Please submit questions about the operational content of this FOT
to:

Mr. P.H. R., STLS,
Best regards,

Capt. M. P.
Vice President Flight Operations Support and Services

Auteur:  Alexandre G. [ Sam 27 Juin 2009 15:25 ]
Sujet du message: 

volauvent a écrit:
cricri guyancourt a écrit:
En tout cas merci à Pil, Alexandre G, et tous les autres pour vos analyses et documents À l'appui.
C'est évident, que plus jamais ça, ne doit se reproduire, la honte !

Par contre, personne ne sait pourquoi comment, l'alerte à l'attentat sur le BA Paris, 2 ou 3 jours avant?
Un désiquilibré..?


Les forums ne sont pas des tribunaux donc si rien n'a change et rien ne changera , commencons par se demander pourquoi les theories verifiees ou pas de nos chers tech ici , ne depassent pas le bord du site ...

J'aimerai qu' Alexandre me dise : voila , j'y vais au tribunal , je vais donner mes explications , j'ai 3000 pilotes avec moi et ca va changer ... Ici que l'on soit convaincu ou pas , n'a aucun interet . On se defoule avec nos connaissances , on se regarde dans le miroir du screen et c'est tout .

A moins que l'on me prouve le contraire !



Evidemment que j'y serai. De plus c'est super lucratif de préparer le procès avec les grands Cabinets d'Avocat Etrangers.

Auteur:  volauvent [ Sam 27 Juin 2009 15:36 ]
Sujet du message: 

Alexandre G. a écrit:
volauvent a écrit:
cricri guyancourt a écrit:
En tout cas merci à Pil, Alexandre G, et tous les autres pour vos analyses et documents À l'appui.
C'est évident, que plus jamais ça, ne doit se reproduire, la honte !

Par contre, personne ne sait pourquoi comment, l'alerte à l'attentat sur le BA Paris, 2 ou 3 jours avant?
Un désiquilibré..?


Les forums ne sont pas des tribunaux donc si rien n'a change et rien ne changera , commencons par se demander pourquoi les theories verifiees ou pas de nos chers tech ici , ne depassent pas le bord du site ...

J'aimerai qu' Alexandre me dise : voila , j'y vais au tribunal , je vais donner mes explications , j'ai 3000 pilotes avec moi et ca va changer ... Ici que l'on soit convaincu ou pas , n'a aucun interet . On se defoule avec nos connaissances , on se regarde dans le miroir du screen et c'est tout .

A moins que l'on me prouve le contraire !



Evidemment que j'y serai. De plus c'est super lucratif de préparer le procès avec les grands Cabinets d'Avocat Etrangers.


:lol: J'en etais presque intiment convaincu mais que vous le rappeliez aux eternels septiques meme vraies , me paraissait indispensable au bout de 400 pages ...

Auteur:  SuperLéon [ Sam 27 Juin 2009 15:44 ]
Sujet du message: 

Alexandre G. a écrit:
Vous ai-je déjà dit que à Czmax, on est limité .... limité en tout !

Je parles des marges de manœuvres de l'avion qui sont réduites à zéro, celle de crash master sont en train de le devenir aussi d'ailleurs.


Marges de manoeuvres ?

"On" s'en occupe ! 8)

AF 447 : Ce que le BEA n’a pas fait pour prévenir l’accident !

http://henrimarnetcornus.20minutes-blogs.fr/

Auteur:  cricri guyancourt [ Sam 27 Juin 2009 17:05 ]
Sujet du message: 

SuperLéon a écrit:
Alexandre G. a écrit:
Vous ai-je déjà dit que à Czmax, on est limité .... limité en tout !
Je parles des marges de manœuvres de l'avion qui sont réduites à zéro, celle de crash master sont en train de le devenir aussi d'ailleurs.

Marges de manoeuvres ?
"On" s'en occupe ! 8)

AF 447 : Ce que le BEA n’a pas fait pour prévenir l’accident !
http://henrimarnetcornus.20minutes-blogs.fr/

Citation:
Dans cette base de données
Il n’y a pas l’incident d’AF de mai/juin 2008 lié aux sondes Pitot

Il n’y a pas l’incident d’AF de juillet 2008 lié aux sondes Pitot

Il n’y a pas les 3 incidents d’AF d’août 2008 liés aux sondes Pitot

Il n’y a pas les 2 incidents d’ACA de septembre 2008 liés aux sondes Pitot

Il n’y a pas l’incident d’AF de septembre 2008 lié aux sondes Pitot

Il n’y a pas l’incident d’AF d’octobre 2008 lié aux sondes Pitot


Oui, c'est consternant !
Pour la vidéo, les anglais adorent depuis mallouines...

Auteur:  Alexandre G. [ Sam 27 Juin 2009 17:35 ]
Sujet du message:  La Taupe à Tech !

Cela dit les vrais passionnés du Forum auront reconnu la signature de Andy Pasztor, qui avait brillé en annonçant la cause du crash de la Spanair ( à Madrid ) 10 jours après Crash Aérien, qui a bénéficié de nombreuses contributions ( Douglas, moi-même et d'autres )

Image
Image
Image
Image
Image

Auteur:  cricri guyancourt [ Sam 27 Juin 2009 18:02 ]
Sujet du message: 

En attendant, ils ont tout arrêté, mais vous pensez quoi ?
Que l'avion (ce qu'il en reste) est entier au fond ou bien au contraire en miettes?
Lews liens pour voir les photos:
http://www.fab.mil.br/portal/voo447/fotos.php

Auteur:  desconegut [ Sam 27 Juin 2009 19:13 ]
Sujet du message:  Re: La Taupe à Tech !

Un bug etant, jusqu'a preuve du contraire, toujours possible, ca reste plutot improbable. Les procedures de development et de certification des logiciels d'avionique d' avions commerciaux sont de loin les plus exigeantes et complexes en vigeur (eventuels interesses, voir DO-178B). Notez que je ne parle pas ici de systemes destines au spatial (fusees).

A mon humble avis, un default de fonctionnement de senseur(s) analogique(s), un default de cablage (blindage casse, etc), un condensateur d'adiru explose, eventuellement une memoire vive demunie de controle de parite defectueuse, ou une erreur humaine seraient des hypotheses bien plus probables.

\"L' avantage\" de la theorie du bug informatique est que si bug il y a, il(s) va(vont) etre trouve(s), reproduit(s) (en simu), et corrige(s).

Auteur:  baguette [ Sam 27 Juin 2009 19:42 ]
Sujet du message:  Re: La Taupe à Tech !

desconegut a écrit:
Un bug etant, jusqu'a preuve du contraire, toujours possible, ca reste plutot improbable. Les procedures de development et de certification des logiciels d'avionique d' avions commerciaux sont de loin les plus exigeantes et complexes en vigeur (eventuels interesses, voir DO-178B).

"L' avantage" de la theorie du bug informatique est que si bug il y a, il(s) va(vont) etre trouve(s), reproduit(s) (en simu), et corrige(s).


Bonsoir,

J'igonre si vous êtes informaticien ou non, mais j'avoue que le mot bug m'énerve quelque peu.
Il a une signification précise, qui implique directement le "programmeur", un bug n'est pas une erreur de conception, c'est une erreur d'écriture ou de "traduction" du langage courant vers le langage de programmation (erreur de choix du type de la variable de contrôle de boucle par exemple).

Dans le cadre présent, l'erreur m'apparaît être plus probable (si erreur il y a) en tant qu' erreur de conception ; autrement dit, ce n'est pas la manière dont le programme est écrit, mais la logique interne de ce programme qui est déficiente.
Plusieurs causes sont possibles : méconnaissances des paramètres en jeu, absence de données sur les paramètres à prendre en compte, simplification abusive des processus à analyser .... la liste serait longue.

Un exemple, le "vote" d'exclusion pour les trois sondes pitots en cas d'informations incohérentes.
J'aimerais, j'aimerais vraiment que quelqu'un ici me décrive un processus algorythmique logique d'exclusion, de la 1, de la 2, de la 3 ou de n'importe quelle combinaison ... et surtout du choix de la "bonne".

Bonne soirée à vous

Auteur:  fredotoga [ Sam 27 Juin 2009 20:36 ]
Sujet du message: 

Bonjour à tous.
J'ai lu les quelques 400 pages de ce topic. J'ai eu de l'intérêt pour une cinquantaine d'entre elles. Les autres n'étant que redondances et règlements de compte.

OPL sur A320 (filière Enac) depuis moins de 2 ans, je rejoins Alexandre G. sur la quasi-totalité des points développés concernant la compagnie nationale. Depuis ma mise en ligne, ma vision de la crevette a quelque peu... comment dire... évolué! Pour le comprendre il faut le vivre de l'intérieur, croyez moi.

Je pense que concernant ce crash, nous y verrons plus clair très prochainement. Mais sachez-le, certains ici sont nécessairement proches de la vérité. Cela a souvent été le cas par le passé.

Excellent week-end et bonne discussion.

Auteur:  desconegut [ Sam 27 Juin 2009 20:41 ]
Sujet du message:  Re: La Taupe à Tech !

baguette a écrit:
desconegut a écrit:
Un bug etant, jusqu'a preuve du contraire, toujours possible, ca reste plutot improbable. Les procedures de development et de certification des logiciels d'avionique d' avions commerciaux sont de loin les plus exigeantes et complexes en vigeur (eventuels interesses, voir DO-178B).

"L' avantage" de la theorie du bug informatique est que si bug il y a, il(s) va(vont) etre trouve(s), reproduit(s) (en simu), et corrige(s).


Bonsoir,

J'igonre si vous êtes informaticien ou non, mais j'avoue que le mot bug m'énerve quelque peu.
Il a une signification précise, qui implique directement le "programmeur", un bug n'est pas une erreur de conception, c'est une erreur d'écriture ou de "traduction" du langage courant vers le langage de programmation (erreur de choix du type de la variable de contrôle de boucle par exemple).

Dans le cadre présent, l'erreur m'apparaît être plus probable (si erreur il y a) en tant qu' erreur de conception ; autrement dit, ce n'est pas la manière dont le programme est écrit, mais la logique interne de ce programme qui est déficiente.
Plusieurs causes sont possibles : méconnaissances des paramètres en jeu, absence de données sur les paramètres à prendre en compte, simplification abusive des processus à analyser .... la liste serait longue.

Un exemple, le "vote" d'exclusion pour les trois sondes pitots en cas d'informations incohérentes.
J'aimerais, j'aimerais vraiment que quelqu'un ici me décrive un processus algorythmique logique d'exclusion, de la 1, de la 2, de la 3 ou de n'importe quelle combinaison ... et surtout du choix de la "bonne".

Bonne soirée à vous


Pour vous donner une idee, la structure des codes source de chaque logciel de ce type correspond point par point a la structure de l'analyse technique correspondante, celle ci correspondant a sont tour aux specifications fonctionelles.

Chaque ligne de code est precedee de 5 lignes de commentaires la documentant, les codes source sont revises par plusieurs ingenieurs.
Afin d'obtenir les certifications necessaires, chaque ligne de code (points d'entree et de sortie des fonctions, assignations et comparaisons de valeurs, controle de boucle) est testee avec des donnees acceptables et non. Ces test sont automatiques et assurent qu'aucune miette de code ne soit omise.
A ce stade les pilotes et inges d'essai valident le soft point par point par rapport aux specifications fonctionelles.

Pour ce qui concerne l'algo de validation des lectures des sondes "pitot", si 2 des 3 envoyent des donnees identiques coherentes avec le domaine de vol, la lecture est consideree acceptable (pour le PA), et dans tous les cas de lecture incoherante, ne fut-ce que d'une sonde durant plus de x secondes (demandez pas combien), une alarme est declenchee.

Finalement, ce logiciel tourne depuis plus de 15 ans sans problemes verifies, et contrairement au mauvais vin, le "soft" ne tourne pas au vinaigre avec le temps.

Vous avez tout a fait raison de souligner des mauvais types de donnees fournis comme parametres aux fonctions, cf le foirage du premier lancement d'ariane V (mentionne bien plus haut dans ce meme post).

Auteur:  domil [ Sam 27 Juin 2009 20:57 ]
Sujet du message: 

pil a écrit:
salut,
un forumiste parler de probleme et de statique et de pitot mais si tu regarde la loi pour avoir ton info de vitesse il te faut les deux valeurs fiables donc une seule en defaut suffit pour foutre la merde et la encore une fois je le redit c est les pitots qui ont merder pas les sondes statiques!!!! :wall: :wall: :wall:

En aéronautique, la pression dynamique s'ajoute à la pression statique pour donner la pression totale qui peut être mesurée au point de vitesse nulle ou point d'arrêt par un tube de Pitot. En retranchant la pression statique, on trouve la pression dynamique.


Le système Pitot comporte 2 tubes, l'un pour la pression dynamique (l'horizontal), l'autre pour la pression statique (le vertical)

Donc ça n'a aucun sens de dire "pitot et sonde statique".

Auteur:  automanet [ Sam 27 Juin 2009 21:02 ]
Sujet du message: 

Delta93 a écrit:
Le problème c'est qu' il y a rien de nouveau ou presque depuis des jours et que ça échauffe les esprits de ne rien avoir à se mettre sous la dent.



...Moi je me suis mis sous la dent l'article du Times.....très instructif..!!! a moins que mon niveau en Anglais m'ai enduit avec de l'erreur....

Page 394 sur 400 Heures au format UTC + 1 heure
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/