Aller au contenu
Fini la pub... bienvenue à la cagnotte ! ×
AIR-DEFENSE.NET

[A400M] le défi stratégique européen


Dada4

Messages recommandés

J'en suis abasourdis. Je suppose que lors du premier vol d'un nouvel avion produit, avant de voler, il y a une préparation pour vol un peu poussée. Cela ne doit pas être très bien rapporté par les journalistes.

Il y a plus que ça. En principe tout est testé sous toutes les coutures.

C'est pourquoi je serais tenté d'ajouter qu'il y a un sérieux problème de contrôle, en plus de celui de qualité. Techniquement c'est juste inadmissible et j'imagine que certaines personnes doivent avoir le sommeil difficile depuis quelques temps...

  • Upvote (+1) 1
Lien vers le commentaire
Partager sur d’autres sites

J'en suis abasourdis. Je suppose que lors du premier vol d'un nouvel avion produit, avant de voler, il y a une préparation pour vol un peu poussée. Cela ne doit pas être très bien rapporté par les journalistes.

Ou possible la volonté de ne pas trop charger l'appareil, avant le résultat définitif de l’enquête  ...

Quoi qu'il en soit, et si c'est bien le cas (mauvaise manip info), Airbus porte une sacrée responsabilité morale en plus de sa responsabilité constructeur ... Leur bb serait presque hors de cause .... ! (?)

Enfin, les FADEC et leurs ECU/EPMU sont des usines à gaz .... Ou des prouesses techno quand ça marche, c'est selon !

Qu'ils fassent en sorte qu'il n'y ai plus de soucis de ce côté, il en va de la crédibilité du programme ... Et de la sécurité des équipages !

Lien vers le commentaire
Partager sur d’autres sites

Incroyable quand même d'avoir un logiciel (un ensemble de paquets je suppose avec des dépendances) qui puisse se trouver dans une configuration qui permet de passer les auto tests SANS ALERTE puis le démarrage, le taxiing, un gros niveau de puissance pour le point fixe et le lancement sur la piste mais qui "bloque" après quelques minutes à pleine puissance.

Modifié par Chaps
Lien vers le commentaire
Partager sur d’autres sites

Incroyable quand même d'avoir un logiciel (un ensemble de paquets je suppose avec des dépendances) qui puisse se trouver dans une configuration qui permet de passer les auto tests SANS ALERTE puis le démarrage, le taxiing, un gros niveau de puissance pour le point fixe et le lancement sur la piste mais qui "bloque" après quelques minutes à pleine puissance.

 

Je suis comme toi : ça me sidère ; remplissage de filesystem  de logs ?

 

je sais bien que ces logiciels correspondent à de toutes, toutes petites séries, mais rien que l'idée qu'il faille les installer lors de d'assemblage final est étonnante : quelqu'un peut en dire plus (pas sur ce cas là spécifiquement, mais sur les pratiques habituelles dans cette industrie ?

Lien vers le commentaire
Partager sur d’autres sites

Je suis comme toi : ça me sidère ; remplissage de filesystem  de logs ?

 

je sais bien que ces logiciels correspondent à de toutes, toutes petites séries, mais rien que l'idée qu'il faille les installer lors de d'assemblage final est étonnante : quelqu'un peut en dire plus (pas sur ce cas là spécifiquement, mais sur les pratiques habituelles dans cette industrie ?

Il y avait de nouvelles fonctionalités: on a peut-être installé lors de l'assemblage final pour laisser plus de temps aux tests.

Lien vers le commentaire
Partager sur d’autres sites

Affligeant .... 3x plus d'instruction que pour le M-88

A se demander si AIRBUS n'aurait recruté des chefs de projet chez LM

Sans chercher d'excuses sur les causes de ce terrible accident (précipitation / négligences / pressions / défaillance qualité / pas les couilles de dire "stop" quand çà craint quelles qu'en soient les conséquences etc ...), la conception, le développement, la mise au point d'un tel ensemble turboprop de cette puissance et de cette taille (+ hélice !) est un challenge hors norme et une première européenne à tous niveaux !

 

Le contrôle de la gestion de marche d'un tel ensemble est bien plus compliqué, il me semble, que la gestion du contrôle de marche d'un M88 ... Les difficultés de développement de l'un ou de l'autre ne se trouve pas au même niveau et ne concerne pas les mêmes systèmes ou organes.

 

Donc comparer la différence entre les 275.000 instructions que gère le FADEC du moteur A400M par rapport au 90.000 instructions que gèrent ceux de l'A380 ou du Rafale, plus que de démontrer des lacunes au niveau du développement du moteur A400M en lui-même, reflète surtout la grande difficulté de gestion de ce monstre.

 

Au point, cet ensemble "est/sera" une merveille de technologie, un must et la fierté pour l'A400M et Airbus ...!

Mais voilà, à vouloir aller plus vite que la musique, on casse la corde du violon ... Le temps est et restera incompressible (au moins tant que l'on ne saura jouer de l'espace/temps, c'est-à dire pas pour demain) ...

 

Par contre tout ce qui filtre pour le moment concernant les défaillances probables du FADEC et de son installation (en général, ECU, EPMU & log) et de l'assemblage (? qu'est-ce qu'ils veulent vraiment dire par là ?), auraient du se produire au banc ou lors des tests pleine puissance au sol et/ou au point fixe et sanctionnées par des alertes interdisant le vol ... Mais avant.

 

Ce qui me turlupine aussi c'est l'emploi du mot problèmes "d'assemblage" dans le communiqué en plus du reste ....

Hors problème de log, est-ce qu'un mauvais assemblage mécanique d'une quelconque partie des moteurs aurait pu dicter l'arrêt automatique des moteurs de la part de l'EPMU par mesure de "sécurité" après dégradation graduelle de ceux-ci à pleine puissance ?

Hypothèse qui pourrait expliquer, peut-être, le fait que la perte des 3 moteurs se soient produite après plusieurs minutes de fonctionnement à pleine puissance ... Une idée comme çà ...

Genre éviter qu'une hélice se barre ou la nacelle toute entière entière suite a de graves dysfonctionnements du style déséquilibrage de l'ensemble hélice ou autre ... ????

 

Plausible ?

Lien vers le commentaire
Partager sur d’autres sites

A priori le nouveau soft s'intéresse particulièrement a la gestion du carburant, notamment la gestion des divers réservoirs.

 

Il est bien possible que les conditions d'alimentation en carburant dépendante des force volumique qui s'applique sur les le carburant lui même... et que donc certain condition ne se réalise qu'en vol.

 

En gros un mode d'alimentation spécifique lorsque l'avion est très cabré, un autre lorsque qu'il est bien a plat etc. de manière a optimiser la stabilité de l'avion via les transfert de masse et donc probablement de réduire la trainée etc.

 

En gros tout marche au sol ou au roulage ...

 

Ce qui m'étonne plus ici dans le propos c'est le défaut d'installation du soft.

 

On a l'impression que le soft a été mal "recopié" dans l'avion, ou les paramètre mal remis a zéro avec les nouveau réglage par défaut. En gros un simple problème de mise a jour informatique... Genre un bout du soft laisser en version 1.0 alors qu'un autre bout passe en version 2.0, et que lorsque que la partie 2.0 appel la partie 1.0 ... la rétro compatibilité n'est pas complète, et qu'on se retrouve avec des exceptions non gérées.

 

Quoiqu'il en soit c'est a la fois assez étonnant une "bourde" pareil, et surtout pas très rassurant sur la manière dont le programme est géré... Un système qui permet de décoller avec un software "corrompu", ou un software mal testé ... ça fait très mauvais genre.

Lien vers le commentaire
Partager sur d’autres sites

Ca donne l'image d'une societe qui gere ses programmes plus en fonction de ce qu'ils rapportent financierement qu'en fonction de la securite des equipages: on fait pas de fric la-dessus, donc on met le minimum de ressources dessus pour s'en debarrasser et basta... s'il est avere qu'il y a eut un manquement dans la securite des procedures, j'espere que cela va leur revenir danlag' a vitesse grand V, et qu'il y aura des suites penales pour mise en danger de la vie d'autrui et homicide involontaire. Et dire que sur ce programme militaire l'accent a ete mis sur la mise aux normes civiles de surete des vols, si cela etait un indicateur de la facon dont sont geres les programmes airbus dans la branche civile...  on espere que ceux la rapportent suffisamment de thunes pour qu'il y ait les ressources necessaires et garantir au mieux que ce genre de catastrophe n'arrive pas.

Lien vers le commentaire
Partager sur d’autres sites

D'après Le Monde, Fabrice Brégier, PDG d'Airbus,  s'est exprimé sur les causes de l'accident. Je reproduis ses propos tels que cités dans l'article du Monde :

 

 

Déjà, ça veut dire que la conception de l'avion n'est pas à mettre en cause. 

 

Ensuite, il y a eu, effectivement soit une faiblesse dans les procédures de test des avions avant la mise en vol, car il s'agissait du premier vol d'un avion de série, soit un problème qui provenait de la mise en œuvre de ces procédures 

 

Modifié par funcky billy II
Lien vers le commentaire
Partager sur d’autres sites

Il y a tellement de paramètres en jeu dans cette histoire, le programme est un assemblage complexe de plusieurs industriels et de plusieurs pays (et donc de méthodes de travail pouvant varier), l'avion en lui même est techniquement très ambitieux, juste le FADEC de l'A400m largue n'importe quel autre en Europe niveau complexité. Après, niveau installation de programme ça reste de la cuisine interne aux fabricants et dans ce genre de FADEC c'est pas un programme qu'il doit y avoir mais plusieurs chacun dans une puce en charge d'une des grandes fonctions le tout dirigé par un programme maître, installer ou changer un de ces programmes doit se faire selon un procédure bien précise avec des tests par la suite. A moins d'avoir un ingénieur/technicien de ce programme sous la main, c'est difficile de conclure sur les compétences/responsabilités de machin, truc ou muche. Après c'est sûr que ça fait tâche pour l'entreprise et sa gestion.

 

Quand au fait que ça soit arrivé l'air, ça n' a rien de surprenant, j'ai bien vu un cas comme ça chez Thales sur un des système du mirage 2000 qui plantait parfois en vol, il a fallut des mois pour qu'il arrivent à le reproduire en labo et trouver les conditions. En vol t'as des paramètre de température, pression, vibrations, efforts ou interférences très variables qui peuvent entrer en jeu en plus des comportements imprévus de logiciels toujours plus complexes.

Lien vers le commentaire
Partager sur d’autres sites

ca commence en reponse a un autre post, je copie la partie intéressante:
 

Ils ont cru que l'expérience de Casa, avec leurs C235 et C295, suffirait, ils se sont trompés. Je pense que ça leur servira de leçon pour la suite.

(...)
un avion CASA est à un Airbus A400M, ce qu'une Haemmerlin est à un Caterpillar (l'expérience des CASA ne sert à rien: il n'y a pas d'avionique modulaire sur un CASA, ni gestion centralisée de la configuration des systèmes, ni système de diagnostic des pannes intégré, je parle même pas des qualités de vol qui font qu'à l'Armée de l'air, on les surnomme les brouettes.... la seule expérience qui sert aux Espagnols est celle des tests de parachutages, de ravitaillement et des contre-mesures qu'effectivement Toulouse n'a pas). D'ailleurs, le prochain fabriquant d'un C-295, c'est ma tante de Bombay. megalol
Il faut arrêter de rogner sur tout et n'importe quoi pour faire des bénéfices financiers au détriment de la sécurité: un jour ou l'autre, ça se paie et cash. Si tu mets du jour au lendemain un Iphone dans les mains d'un usager de Nokia 3610, il va faire pas mal de bourdes avant de pouvoir comprendre comment il marche (c'est du vécu donc je sais de quoi je parle)... surtout que 9 fois sur 10, il ne prendra même pas la peine de lire complètement le mode d'emploi.
Le détail de ce problème est connu depuis longtemps (rien de nouveau sur l'avion accidenté par rapport aux précédents auxquels il n'est rien arrivé), la procédure d'installation est claire et sans ambiguïté: quand on charge le logiciel FADEC (il y en a 3 par moteur pour être plus précis dont un rien que pour l'hélice), il faut recharger juste après (et non avant sinon, il faut tout recommencer) les constantes de calibration installées sur chaque moteur (n'oublions pas que le logiciel de base est le même quelque soit l'emplacement et le sens de rotation du moteur donc le reste est à paramétrer sur chacun) que le processus de chargement écrase (à cause d'une non-conformité du motoriste à une exigence Airbus de gestion des logiciels embarqués qui ne sera pas corrigée avant 2017... quelle réactivité !). Les tests réalisés ensuite au sol ne permettent pas, bien entendu, de couvrir tout le domaine de vol de l'appareil (c'est fait une fois pour l'avion de développement ayant reçu le premier la mise à jour mais par sur tous les avions de série, il faut produire...) donc, si c'est mal fait comme ça a été le cas sur le MSN23 (et fort heureusement uniquement sur celui-ci) et bien on ne s'en rend compte qu'en vol hélas (en gros, l'avion ne peut pas monter correctement au dessus de 500' sans que les moteurs s'éteignent: 2 des 3 moteurs ont eu ce problème, le 3ème a probablement été éteint par l'équipage dans une tentative désespérée de faire redémarrer l'un des moteurs arrêtés ou par le choc avec le pylone). L'erreur a consisté à laisser la même personne le faire sur "presque" tous les moteurs alors que si les équipes étaient suffisamment bien formées et nombreuses, il y aurait un spécialiste logiciel par moteur au poste 35 (celui des essais systèmes) et qui dit redondance humaine, dit moins de chance de faire une erreur (bien que sur l'AF447, tous se sont gourés de la même façon). Ça n'est pas une défaillance des moteurs mais un erreur humaine à l'assemblage comme l'a rappelé Lahoud. Les moteurs ont fait exactement ce que le logiciel leur demandait simplement, quelqu'un avait oublié de leur dire s'ils étaient à droite ou à gauche de l'avion, à l'intérieur ou à l'extérieur de l'aile et quelques autres paramètres indispensables au fonctionnement qu'on regroupe tous sous le terme de trims moteur.
Pour une analogie plus simple à comprendre: si un distributeur bouffe votre carte bleue parce que vous tapez 3 fois un mauvais code, où est la défaillance? Dans le distributeur? Sur le code exécutable de la carte à puces?
(...)

  • Upvote (+1) 2
Lien vers le commentaire
Partager sur d’autres sites

Intéressant... 

Néanmoins rien ne laisse entendre que la non-conformité du motoriste a donné lieu à une surveillance particulière visant à détecter une anomalie dans la mise en oeuvre de la mesure palliative consistant à restaurer les paramètres moteur après mise à jour du logiciel.

S'il apparaît clairement que quelqu'un à mal fait son travail, il n'est sans doute pas le seul car d'autres ont peut-être bien omit d'envisager que ça pouvait arriver...

Lien vers le commentaire
Partager sur d’autres sites

Le problème est manifestement dans la procédure.

Il manque manifestement l'étape de contrôle permettant de vérifiez que l'opération a été correctement effectué.

Cela dit, il peut aussi y avoir erreur de conception : si rien ne permet de vérifier que les opérations ont été correctement effectué.

Lien vers le commentaire
Partager sur d’autres sites

Si tu ne peux pas vérifier que ça a été fait correctement, tu assures le coup en refaisant la partie critique (en l'occurrence, il aurait suffit de restaurer les paramètres moteur à une étape ultérieure).

 

Ceci étant dit, je trouve quand même curieux qu'il soit impossible de vérifier ce paramétrage à postériori, alors que les moteurs sont par ailleurs identiques. Puisque visiblement le paramétrage du moteur doit être fait après chaque remplacement dudit moteur, il doit bien y avoir dans les procédures un moyen de vérifier que ce paramétrage est correct, sinon ça va immanquablement merder plus d'une fois...

Modifié par DEFA550
Lien vers le commentaire
Partager sur d’autres sites

Refaire l'opération c'est assumer qu'un opérateur, le même ou un autre est capable de faire l'erreur qu'on envisage possible pour la première fois.

C'est une bonne solution si tu découvre que l'opérateur qui a fait l'opération ne maîtrisait pas la procédure ou bien s'il déclare se rendre compte d'avoir oublié de réaliser une des opérations ou l'ordre correct.

 

LA seule bonne solution c'est d'avoir un moyen de vérifier à posteriori que le paramétrage est correct.

  • Upvote (+1) 1
Lien vers le commentaire
Partager sur d’autres sites

Autour de 2005, un mirage 2000-9 des UAE s'était crashé en France lors du vol de réception.

Je ne me souvient pas de la date exacte mais c'était un bi-place et le client était en place arrière....

 

Ca fait désordre d'éjecter le client... Commercialement c'est pas top mais pas de bobo au final sauf l'avion a 90M d'€ pièce s'entend.

Le SNECMA avait été mis en cause et si je me souvient bien (je n'ai pas fait de recherche): c'était le FADEC.

 

En bref: la mise en route d'un système complexe est toujours une phase TRES délicate et si quelqu'un vous dit un jour "ouai, c'est scandaleux: il est tout neuf et déjà des problème", passez votre chemin, il n'y connait manifestement rien à la technique.

 

Après pour cet incident en particulier, c'est effectivement anormal mais si le FADEC est une usine à gaz où plus personne n'y comprend rien sauf quelques personnes initiée (qui vont avoir tendance à faire de la rétention d'information), c'est qu'il y a quand même un pb de conception et d'organisation.

 

Je serait quand même curieux de savoir comment ça s'est passé au niveau micro-management même si c'est horrible pour les personnes en cause.

Modifié par c seven
Lien vers le commentaire
Partager sur d’autres sites

Si tu ne peux pas vérifier que ça a été fait correctement, tu assures le coup en refaisant la partie critique (en l'occurrence, il aurait suffit de restaurer les paramètres moteur à une étape ultérieure).

 

Ceci étant dit, je trouve quand même curieux qu'il soit impossible de vérifier ce paramétrage à postériori, alors que les moteurs sont par ailleurs identiques. Puisque visiblement le paramétrage du moteur doit être fait après chaque remplacement dudit moteur, il doit bien y avoir dans les procédures un moyen de vérifier que ce paramétrage est correct, sinon ça va immanquablement merder plus d'une fois...

Si vraiment on ne peut pas vérifier, on filme l'écran et le clavier pendant le paramétrage et on demande à une autre personne de controler.

Lien vers le commentaire
Partager sur d’autres sites

Autour de 2005, un mirage 2000-9 des UAE s'était crashé en France lors du vol de réception.

Je ne me souvient pas de la date exacte mais c'était un bi-place et le client était en place arrière....

 

Ca fait désordre d'éjecter le client... Commercialement c'est pas top mais pas de bobo au final sauf l'avion a 90M d'€ pièce s'entend.

Le SNECMA avait été mis en cause et si je me souvient bien (je n'ai pas fait de recherche): c'était le FADEC.

DAD11, 4 avril 2005 à Istres.

Cause : Dérivetage du support abradable du labyrinthe 14 suite à rupture en fatigue vibratoire des 36 rivets. Type de dommage alors inconnu dans l'expérience M53.

Origine : Défaut de fabrication. Schéma industriel particulier (certaines opérations de fabrication du support distributeur 1er étage équipé ont été délestées du sous-traitant habituel vers un autre sous-traitant)

Lien vers le commentaire
Partager sur d’autres sites

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !

Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.

Connectez-vous maintenant
  • Statistiques des membres

    6 005
    Total des membres
    1 749
    Maximum en ligne
    cilom
    Membre le plus récent
    cilom
    Inscription
  • Statistiques des forums

    21,6k
    Total des sujets
    1,7m
    Total des messages
  • Statistiques des blogs

    4
    Total des blogs
    3
    Total des billets
×
×
  • Créer...