Crash de l’AF447 et les limites de l’informatique embarquée

Alors que le BEA a rendu son premier rapport et qu’il semble maintenant certain que les enregistreurs de vols ne seront jamais retrouvés, quelle sont les directions prises par les enquêteurs ?

Les seuls faits avérés sont les messages d’alertes envoyés par l’avion au contrôle au sol d’Air France.

Rappelons que ces messages ne sont pas destinés à assurer la sécurité mais à prévenir les services techniques au sol afin de se préparer à intervenir sur l’appareil. Par exemple si un dispositif est en panne le dispositif de secours est automatiquement activé et un message est envoyé afin qu’un composant de remplacement soit prêt dès que l’avion atterrira.

La lecture de ces alertes (informations brutes) suggère à tout spécialiste des logiciels qu’une défaillance des ordinateurs semble être liée au crash. Cela fait froid dans le dos car ce genre de logiciel est omniprésent dans les avions mais aussi dans les trains, les automobiles modernes, les dispositifs médicaux…

Cette hypothèse semble se concrétiser. Ainsi le « Wall Street Journal » dans un article intitulé « Computer Failures Are Probed in Jet Crash » détaille comment les jets modernes (A330, B777…) sont de plus en plus dépendants de leurs ordinateurs de bord et comment ces ordinateurs pourraient être à l’origine du crash de l’AF447.

Regardons de plus près ces logiciels. Au départ, de simples automates destinés aider les pilotes à garder l’avion dans le « domaine de vol » (sécurité, confort, consommation de carburant), ils sont devenus d’énormes « usines à gaz » gérant l’avion dans son ensemble. A titre d’exemple un avion moderne comme l’Airbus A380 est contrôlé par plusieurs ordinateurs dont les logiciels totalisent plus de 18 millions de lignes de code. Un logiciel d’une telle taille contient forcément des bugs. De plus ils sont maintenant liés aux systèmes dits de divertissement (la vidéo qui s’affiche sur le petit écran LCD du passager avec la position, la vitesse de l’avion) avec les risques, même minimes, que cela comporte.

L’aviation civile a donc mis en place des protocoles de qualité et de tests très rigoureux décrits par le protocole DO-178B. Cependant un protocole, aussi rigoureux soit- t’il, ne garantira jamais une absence totale d’erreurs. Il suffit d’imaginer le nombre de variables « en entrée » de ces systèmes (vitesse, altitude, vitesse de rotation des moteurs, pression d’huile, GPS, informations données par le pilote, température…) et de calculer le nombre de combinaisons possibles. On s’aperçoit que l’on arrive rapidement à un nombre de cas de tests quasiment infini.

La solution serait-elle alors de prévoir un débrayage total des systèmes embarqués, avec reprise en main entièrement manuelle de l’avion ? Est-ce la bonne solution ? Probablement pas. D’une part ces aides à la navigation ont diminué le nombre d’accidents, mais surtout l’architecture même des avions modernes ne permet plus l’interaction directe, que ce soit dans le sens pilote-avion (du manche à balais aux gouvernes par exemple), ni dans le sens environnement-pilote (de la sonde de vitesse à l’affichage en cabine).

Il faudrait alors encore améliorer la qualité de ces logiciels… Est-ce possible ? Ces logiciels sont développés par de grandes entreprises assez peu nombreuses sur le marché (Thales, Honeywell, Northrop Grumman) qui gardent jalousement leurs procédés de fabrication. Leurs logiciels sont validés par les organismes de normalisation et des protocoles tels que DO-178B mais leurs codes source restent secret.

Soyons iconoclaste et demandons-nous si le mode de développement utilisé par les projets « open-source » ne serait pas mieux adapté. Ils ont prouvé leur fiabilité dans le cas, par exemple, du couple Linux / Apache (plus de 60% des serveurs web dans le monde). Il a été prouvé par de nombreuses enquêtes qu’Apache était moins sujet aux logiciels malveillants que IIS (le serveur Web de Microsoft). Il y a cependant tout un mécanisme à mettre en place afin d’assurer le respect de la propriété des entreprises sur leurs logiciels et, éventuellement, de rémunérer les « découvreurs » de bugs.

La multiplication des logiciels embarqués amène donc des avancées mais aussi des risques supplémentaires. Les pilotes sont de plus en plus formés à ces systèmes et de moins en moins au pilotage « à la main » (plus informaticiens et moins pilotes). Ces systèmes automatisés ont provoqué la disparition du « troisième homme » : le mécanicien naviguant (Rappelez-vous les mouvements sociaux chez Air Inter à la sortie de l’Airbus A 320). Il serait peut être judicieux de repenser à créer un nouveau troisième homme en embarquant un « ingénieur système navigant ». Un homme (une femme) spécialiste des logiciels de contrôle de vols et qui serait à même de surveiller et éventuellement de déconnecter tout élément logiciel défaillant. Le pilote redeviendrait alors un pilote à part entière (plus pilote qu’informaticien) et recevrait une formation le rendant capable de poser son avion « à la main » dans les circonstances critiques.

Quoi qu’il en soit, le bouleversement apporté par les nouveaux systèmes de contrôle automatique obligera les organismes internationaux à se pencher sur ce problème mais la solution prendra des années à se mettre en place. Rassurons-nous tout de même, car hormis le crash de l’AF 447 ,les avions modernes montrent tous les jours leur fiabilité !

par Homme Champignon samedi 11 juillet 2009 - 20 réactions

(14 votes) Votez cet article

Faire un don

2 moyens pour donner

Don défiscalisé 10€ ou plus

Obtenez une réduction fiscale de 66% avec un e-reçu. Un don de 10 € ne vous coûte que 3€40.

Grâce à votre aide, AgoraVox peut continuer à publier plus de 1000 articles par mois. En donnant à la Fondation AgoraVox, vous offrez un soutien à la liberté d'expression et d'information.

Les réactions les plus appréciées

Par HELIOS (xxx.xxx.xxx.79) 11 juillet 2009 16:23

PREMIERE PARTIE

===============

Bonjour,

Je voudrais intervenir dans ce débat et lui apporter une touche professionnelle.

J’aimerai d’abord parler du MATERIEL.

Les équipements de bord ne sont pas des PC comme nous achetons à "Rue Mongallet".
Il s’agit de matériel industriel qui n’ont que peu a voir avec leurs version grand public.
S’attacher a parler de Motorola 68000 ou d’Intel 80286 n’a que peu de sens. Les informations à traiter et traitées ne sont pas des clones de Windows, il n’y a pas d’interface graphique. La plupart du temps un simple 8088 sorti en 1983 est capable de tout traiter.

Acquérir et traiter les paramètres de vol une fois toutes les millisecondes (1/1000 de seconde) avec un 80286 ou un "petit" 80386, vous savez, les pentium 3, c’est déjà du grand luxe cote puissance de calcul.

Chercher des causes dans le matériel est a mon avis faire un mauvais procès aux fabricants d’équipements.

Je modérerais néanmoins mon point de vue, car depuis les années 2000 il y a eu une chute considérable de la qualité intrinsèque de TOUS les matériels sans exception, militaire compris. Le domaine infernal de la rentabilité s’est mis a affecter l’ensemble du monde industriel où la logique du :

--- "on fabrique pour x années ou x mois au moins, si ça dure plus tant mieux" ---

est devenu :

--- "on fabrique pour x années, ou x mois et cela NE DOIT PAS durer plus"... pour assurer le renouvellement commercial.

Parallèlement a ça, la réparabilité a été diminuée au maximum, les fabricants préférant échanger l’ensemble du produit plutôt que de le réparer. Cette politique a l’énorme avantage de maitriser le marché (pas d’exposition du contenu, des process, de la fabrication etc), de contrôler le renouvellement des produits et de couper l’herbe sous le pied a toute une économie du réparable bien gênante. Je rajouterai, mais cela n’a rien a voir avec le sujet, cela permet de mettre en œuvre des usines délocalisées ou le personnel est peu formé et le taux de qualité en bout de chaine inferieur. Dans la démarche marketing, une « marque » vous échangeant sans discuter un produit en panne (mal fabriqué) par un neuf, augmente paradoxalement son image de marque !!!

L’aéronautique n’échappe pas a cette tendance, sauf qu’en vol de nuit au milieu de l’atlantique on ne change pas un calculateur de bord en garantie !

Comme vous le voyez, sans donner un blanc seing a l’industrie aéronautique, je m’abstiens pour l’instant d’accuser le matériel. Il est probable qu’une architecture plus "prudente" de l’avion aurait évité ce drame, mais c’est très difficile de le vérifier et de le justifier au vu des statistiques QUE NOUS CONNAISSONS. ---A quand le libre accès au log des messages de maintenance des avions, car toutes les pannes ne se sont pas transformées en drame, mais peut être ceux ci ont été évités de justesse. Je dirais même mieux, a quand les statistiques de retour des malfaçons et des pannes sur tout ce qui se produit ?

Passons maintenant au LOGICIEL.

Si je suis très tolérant avec les producteurs de hardware, je suis considérablement plus accusateur pour les sociétés de services ayant développé les logiciels embarqués et toute l’informatique qui va avec.

Comme pour le matériel, il y a eu une chute terrible de la qualité des produits a la fin des années 90. Cela est relativement simple a expliquer.
Le monde du logiciel, basé sur une rigueur forte, a comme les autres "commerces" été rattrapé par les coûts. Pour diminuer ceux ci, Deux axes ont été envisages... baisser le prix de la main d’œuvre et baisser la durée de fabrication... ou les deux mon général !

Lire le commentaire dans son contexte

Réagir à l'article Réagir à ce message Signaler un abus
Par HELIOS (xxx.xxx.xxx.79) 11 juillet 2009 16:25

DEUXIEME PARTIE (SUITE)

=====================

==== Baisser le COUT de la MAIN D’ŒUVRE ==== :

Cela s’est fait d’une part par la délocalisation, ce qui a entrainé ipso facto une diminution du prix mais aussi une diminution de la qualité. non pas que les informaticiens off shore soient plus mauvais, mais tout simplement ils ne sont pas formés aux méthodes, ne connaissent pas le niveau de responsabilité que nous connaissons (regardez le « i ») et ont donc implémenté, a leur sauce, des produits complexes... et d’autre part, par l’embauche de "jeunes" débutants (moins de 2 ans d’expérience) et leur affectation sur des projets a haut risque. Ces armées de programmeurs de qualité inégale ont eu sur les bras des travaux au delà de leur expérience, cas aggrave par l’encadrement défaillant. je m’explique sur ce point...

L’encadrement coutant plus cher, le nombre et la qualité a fortement baissé. Là ou on comptait moins d’une dizaine d’ingénieurs pour un chef de projet s’est transformé en 20 et plus de jeune nécessitants un support accru vue leur expérience. Le traitement de la qualité (un ingénieur dédié par projet), l’intervention de consultants… tout ce support a la création a fondu laissant la place a des Template et/ou des logiciels d’avancement de projets qui ne remplace évidement pas la compétence des spécialistes.

De plus, les cadres chargés d’assumer les responsabilités techniques, administratives de ces projets n’échappent pas a ma vindicte. Dans la plupart des SSII, ce sont les moins bons qui résistent aux purges. Pendant que les personnes compétentes sont « au charbon » c’est-à-dire sont chez les clients en train de bosser, eux, jamais choisis ni réclamés par les clients restent dans les couloirs de leur entreprise et développent des capacités d’influence significative. Il est a lors pour eux aisé de se maintenir et de progresser dans les hiérarchies diffusant leur incompétence et éliminant tous ceux qui les connaissent bien et qui pourraient leur faire un peu d’ombre.

Enfin, la complaisance des procédures de recettes, éminemment liées aux conditions contractuelles de ces projets sommes toutes juteux n’est pas a ignorer non plus. Entre copain, on ne va pas « rejeter » des process complets, même s’ils sont bancals et si des équipes discrètes autant que réduites vont faire leur possible pour en bricoler le fonctionnement jusqu’à l’acceptabilité vraie.

===== Baisser la DUREE de fabrication =====

C’est la un domaine que peu de personne imagine, mais La France a été un des leaders mondiaux dans la réalisation de logiciel. Cela a été du a différents facteur dont un fut majeur lié a la qualité de la conception.

Grace a l’application de méthodes très fortes et très solides, les produits ainsi développés dans le contexte des démarches méthodologiques vraiment appliquées étaient d’excellente qualité. Le revers de la médaille est naturellement la lourdeur des opérations de conceptions, leurs durées et la compétence nécessaire des concepteurs, ingénieurs mieux formes, expérimentés et donc plus chers.

La cupidité des SSII qui au départ ont profité pour saigner je ne sais combien de banques d’assurances, d’administrations en leur vendant ces méthodes s’est également traduit par la volonté de ne pas capitaliser les travaux déjà effectués recommençant encore et encore les mêmes études.

Ce qui devait arriver arriva rapidement, les anglo-saxons ont profités pour d’abord récupérer le mécontentement, ont sorti des « raccourcis » méthodologiques développés par leurs propres sociétés, les ont commercialisés (au passage la méthode dominante française était gratuite) et ont lancés des idées séduisantes mais hélas perverses. En prônant le « RAD » Rapid Application Design, ils ont évidement tués les démarches plus complexes. Petit a petit ils ont réussi a vendre des concepts existant déjà dans les méthodes et démarches existantes, mais ils les ont emballés dans leur langue et dans les esprits grâce au relais d’internet qui a joué un rôle déterminant, comme il se doit. Les méthodes dites « OBJET » qui ne sont que des vues faciles du comportement des concepts informatiques ont remplacé les vraies approches conceptuelles, avec naturellement les imprécisions et non homogénéité qui vont avec. (Reportez vous a UML si vous voulez en savoir plus)

Naturellement les SSII ont pu ainsi fourguer leurs équipes de bras cassés, tant au point de vue des forces vives (ingénieurs) trop débutants que de leur encadrements (incompétents et magouilleurs)

Nous en sommes arrivés au point ou aujourd’hui, les entreprises achètent des formations méthodologiques a la bonne gouvernance des systèmes d’information (lisez ITIL) alors qu’ils possèdent déjà tout ça dans les recueils méthodologiques EN FRANCAIS des années 1990.

Au final, les produits logiciels informatiques n’ont rien gagnés en qualité intrinsèques, c’est-à-dire en nombre de bug par ligne de code écrite, c’est-à-dire qu’il persiste autant d’erreur technique a l’intérieur qu’il y a 20 ans, qu’ils sont extrêmement plus lourd et surtout et c’est la le problème et nous revenons ainsi au vol AF 447, leur architecture conceptuelle est probablement mauvaise ou au minimum ne couvre pas l’ensemble du domaine qu’il devrait traiter.

Cet article est intéressant. Je suis désolé de laisser un commentaire en deux parties, aussi long. Le sujet n’est pas simple, mais on ne peut laisser dire que l’informatique embarquée a atteint ses limites.

On peut seulement montrer et condamner les comportements irresponsables d’un modèle industriel qui n’a plus les moyens d’être le maitre chez lui et qui doit composer avec le modèle financier dont, on le comprend bien, la finalité est loin d’être la même.

<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p> </o:p>
Je vous remercie de m’avoir lu, j’ai bien écrit un article là, hein

Lire le commentaire dans son contexte

Réagir à l'article Réagir à ce message Signaler un abus
Par Halman (xxx.xxx.xxx.76) 11 juillet 2009 15:22

Homme, les cdve ont au mois 3 chaines informatiques différentes, avec des algorythmes différents, des processeurs et des adressages mémoires différents, des entrées différentes, qui se vérifient. Donc panne totale d’informatique sur 3 systèmes différents, la cause est forcement externe et pas informatique.

Ce qui est intriguant c’est le décrochage à plat.

On apprend aux jeunes débutants à s’en rendre compte sans instruments et à en sortir, en les laissant s’y mettre eux mêmes. Alors un équipage de professionnels qui s’y retrouve en décrochage plat...

Le problème des cdve et des pilotes automatiques est un vaste débat qui date déjà des années 1930. Laisser la main à une machine, à quel point, sur quel tâche, quand et comment reprendre la main, etc.

Mermoz avait un mépris absolu de ces nouveaux pilotes de lignes en costard cravates avec des systèmes automatiques de stabilisation.

Le problème des avions de ligne moderne est leur trop grande dépendance à des systèmes, des procédures, et de moins en moins au pilotage manuel. Ces cockpits recouverts de systèmes et ne laissant plus la place qu’à un minimanche latéral et à un simple petit pare brise plus petit que celui d’une voiture. Il y en a que cela ne dérange pas.

Le problème des pilotes de ligne est qu’ils pensent en permanence à procédures, types de procédures, domaine de vol + marges de sécurités, etc. Leur domaine de vol est ultra restreint par des alarmes sonores et visuelles bien avant la véritable limite à atteindre. Et comme les gens genre ENAC ne sont habitués qu’à ce genre de pilotage, (ils abhorrent de se mettre ne serait ce que de quelques degrés aux grands angles même si ils sont encore à des années lumières du décrochage par exemple.)

Je les ai vus à Chateaudun et à Chartres s’entrainer à la vrille entre autre. C’est une catastrophe. Ils n’arrivent pas à admettre que la vrille doit devenir une telle habitude qu’elle doit être un automatisme. Ils laissent cet exercice aux domaines exceptionnels. (Ils en passent des nuits blanches une semaine avant !). Résultat lorsqu’ils s’y retrouvent, ce n’est pas automatique, et ils mettent trois tours à en sortir alors qu’avec un peu d’habitude en un tour et demi on en sort.
A raison de plus de 100 mètres de perte d’altitude par tour, on comprend le problème de sécurité.

Ils sont saturés d’informations d’alertes sonores et visuelles, de procédures, de modes de pilotes automatiques, de modes d’affichages, de mode des ordinateurs. Dans tel pays l’approche se fait de telle manière, et dans le pays voisin c’est l’inverse, et autres joyeusetés.

Ils n’ont pratiquement plus le temps de se concentrer sur le pilotage pur.

J’ai volé plusieurs fois avec des cdb Air France, je ne le ferai plus.

Par exemple ils n’ont pas l’habitude de regarder dehors les autres aéronefs. Ils sont en planeur dans une ascendance où on est 20, on se frole à 10 mètres, mais ils ne regardent pas dehors et ont le nez sur le tableau de bord.

Toute une manière de piloter basique et fondamentale dont ils n’ont plus l’habitude.

Quant à votre comparaison du monde Linux/Crosoft à Thalès, ce sont des univers totalement différents. A ce niveau là ils ne font pas mumuse avec le look des interfaces graphiques mais sont plongés dans des calculs scientifiques et de systèmes experts et de calculs parallèles. Leur grande préoccupation est, comme aux bon vieux temps du début de l’informatique, d’optimiser leurs lignes de codes pour effectuer le maximum de taches le plus précisément possible, avec le moins de ressources possibles et avec la plus grande vitesse et la plus grande précision possible. Pas vraiment la préoccupation des Linuxiens et des Microsoftiens.

Les navettes spatiales fonctionnent encore avec des 8086 et cela ne les empêche pas de calculer des trajectoires orbitales et supersonniques au centième de degré près, au millimetre par seconde près, et effectuer des taches parallèles même si les spécialistes me diront que le 8086 n’est pas gravé pour du calcul parallèle. Les programmer en logiciel et les faire exécuter par un monotache séquentiel ça marche aussi.
Parce qu’ils ne sont pas occupés à lire un cd, afficher une mise en veille à la con, et autres gadgets du bureau.
Un 8086 qui execute les calculs d’un simulateur gravitationnel en mode texte, uniquement occupé à faire du calcul mathématique, sans affichage graphique ni autres ressources utilisées pour le look tourne quatre fois plus vite que s’il devait afficher du graphique couleurs et utiliser des gestionnaires de souris, de cartes sons et autres gadgets pour geecks de bureaux.

Nous vivons une époque merveilleuse où tout le monde a oublié qu’un ordinateur est d’abord un calculateur mathématique avant d’être un truc multimédia pour geeck du dimanche dans son salon ; où les dirigeants de compagnies aériennes basent tout sur l’efficience commerciale gérée par informatique en oubliant que l’avion est toujours un avion, un pilote toujours un pilote, les lois de la mécanique des fluides toujours les lois de la mécanique des fluides.

Lire le commentaire dans son contexte

Réagir à l'article Réagir à ce message Signaler un abus
Par al44 (xxx.xxx.xxx.153) 11 juillet 2009 17:33

Bonjour,

Informaticien travaillant sur ce type de logiciel ( sous marin nucléaire, plutôt qu’avionique), je confirme complétement les dires d’Hélios . Oui la complexité croissante des processeurs, et des process à gérer rend de plus en plus difficille une validation compléte des logiciels. Mais avec un respect de régles, des gens rigoureux , des tests exhaustifs et les outils existants on arrive à quelque chose d’acceptable si on nous en laisse le temps. Le probléme, c’est notre super logique ultra libérale (ou néocon) qui dois faire des gains de productivité à TOUT LES PRIX .Donc en plus des exemples déjà donné, sachez que par exemple les Directeurs de Centrale Nucléaire sont notés sur les gains de productivité qu’ils font ( en générale sur la maintenance ou en virant les anciens trop cher qui maitrisaient les process), attendez-vous dans les années à venir a voir pas mal d’avions dégringoler, des champignons pousser et des sous-marins nucléaire se rentrez dedans...
Ceci dit cela aura peut être plus d’effet que les morts des emeutes de la faims, dont les responsables sont les mêmes que ceux qui ont généré la crise et les 2 ou 3 bricoles citées plus haut. Pour l’instant, on leur file du fric pour que tout soit comme avant et ont continu joyeusement, la crise est fini qu’ils disent mais l’impacte de leurs conneries inhumaines on va le découvrir petit à petit .

Lire le commentaire dans son contexte

Réagir à l'article Réagir à ce message Signaler un abus

Réagissez à l'article

Réactions à cet article

Par Deneb (xxx.xxx.xxx.73) 11 juillet 2009 11:36

Et la loi de Moore ? Un avion qui a 15 ans d’âge avec son informatique mille fois moins performante que l’informatique d’aujourd’hui, peut-il encore être compatible avec les systèmes evoluant de plus en plus vite ? Est-il encore capable de traiter l’ensemble des informations liées au traffic aérien de plus en plus dense ?

Les systèmes informtiques embarqués sont-ils mis à jour regulièrement ou confie-t-on la vie des passagers à des vieux 80286 ?

Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
- Par Homme Champignon (xxx.xxx.xxx.39) 11 juillet 2009 11:55
  
  Pour la 310 de Yémenia il s’agit probablement d’autres causes.
  - Piste unique équipée de de l’ILS (aterisage automatique) dans un seul sens
  - Meteo mauvaise avec vent à contre sens obligeant le pilote a se poser "a l’envers"
  ... et qq chose de plus qui a provoqué un crash ! (erreur humaine ?)
  Ni l’avion (a priori mal entretenu mais ca n’est probablement pas le problème) ni l’informatique ne semble impliqué.
  
  Pour ce qui est de l’informatique embarquée, je penses qu’effectivement les calculateurs des anciens avions sont d’anciens modèles. Mais c’est justement pour des raisons de sécurité. Si les systèmes ont étés validés sur un automate tournant sur un 80286 (probablement plus un 68000 à l’époque) on ne vas pas s’amuser a changer tout pour avoir un processeur plus puissant. Les organismes de normalisation obligent a repasser l’ensemble des tests pour chaque changements... on ne joue alors pas au geek sur ce genre d’ordinateurs (on n’overcloke pas le processeur pour traiter plus de messages à la seconde). C’est d’ailleurs un problème pour les fabricants, ils doivent s’assurer de la disponibilité des pièces de rechanges pour toute la durée de vie de l’avion. (allez trouver un coprocesseur arithmétique de 68000 de nos jours) !
  
  Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
Par Halman (xxx.xxx.xxx.76) 11 juillet 2009 15:22

Homme, les cdve ont au mois 3 chaines informatiques différentes, avec des algorythmes différents, des processeurs et des adressages mémoires différents, des entrées différentes, qui se vérifient. Donc panne totale d’informatique sur 3 systèmes différents, la cause est forcement externe et pas informatique.

Ce qui est intriguant c’est le décrochage à plat.

On apprend aux jeunes débutants à s’en rendre compte sans instruments et à en sortir, en les laissant s’y mettre eux mêmes. Alors un équipage de professionnels qui s’y retrouve en décrochage plat...

Le problème des cdve et des pilotes automatiques est un vaste débat qui date déjà des années 1930. Laisser la main à une machine, à quel point, sur quel tâche, quand et comment reprendre la main, etc.

Mermoz avait un mépris absolu de ces nouveaux pilotes de lignes en costard cravates avec des systèmes automatiques de stabilisation.

Le problème des avions de ligne moderne est leur trop grande dépendance à des systèmes, des procédures, et de moins en moins au pilotage manuel. Ces cockpits recouverts de systèmes et ne laissant plus la place qu’à un minimanche latéral et à un simple petit pare brise plus petit que celui d’une voiture. Il y en a que cela ne dérange pas.

Le problème des pilotes de ligne est qu’ils pensent en permanence à procédures, types de procédures, domaine de vol + marges de sécurités, etc. Leur domaine de vol est ultra restreint par des alarmes sonores et visuelles bien avant la véritable limite à atteindre. Et comme les gens genre ENAC ne sont habitués qu’à ce genre de pilotage, (ils abhorrent de se mettre ne serait ce que de quelques degrés aux grands angles même si ils sont encore à des années lumières du décrochage par exemple.)

Je les ai vus à Chateaudun et à Chartres s’entrainer à la vrille entre autre. C’est une catastrophe. Ils n’arrivent pas à admettre que la vrille doit devenir une telle habitude qu’elle doit être un automatisme. Ils laissent cet exercice aux domaines exceptionnels. (Ils en passent des nuits blanches une semaine avant !). Résultat lorsqu’ils s’y retrouvent, ce n’est pas automatique, et ils mettent trois tours à en sortir alors qu’avec un peu d’habitude en un tour et demi on en sort.
A raison de plus de 100 mètres de perte d’altitude par tour, on comprend le problème de sécurité.

Ils sont saturés d’informations d’alertes sonores et visuelles, de procédures, de modes de pilotes automatiques, de modes d’affichages, de mode des ordinateurs. Dans tel pays l’approche se fait de telle manière, et dans le pays voisin c’est l’inverse, et autres joyeusetés.

Ils n’ont pratiquement plus le temps de se concentrer sur le pilotage pur.

J’ai volé plusieurs fois avec des cdb Air France, je ne le ferai plus.

Par exemple ils n’ont pas l’habitude de regarder dehors les autres aéronefs. Ils sont en planeur dans une ascendance où on est 20, on se frole à 10 mètres, mais ils ne regardent pas dehors et ont le nez sur le tableau de bord.

Toute une manière de piloter basique et fondamentale dont ils n’ont plus l’habitude.

Quant à votre comparaison du monde Linux/Crosoft à Thalès, ce sont des univers totalement différents. A ce niveau là ils ne font pas mumuse avec le look des interfaces graphiques mais sont plongés dans des calculs scientifiques et de systèmes experts et de calculs parallèles. Leur grande préoccupation est, comme aux bon vieux temps du début de l’informatique, d’optimiser leurs lignes de codes pour effectuer le maximum de taches le plus précisément possible, avec le moins de ressources possibles et avec la plus grande vitesse et la plus grande précision possible. Pas vraiment la préoccupation des Linuxiens et des Microsoftiens.

Les navettes spatiales fonctionnent encore avec des 8086 et cela ne les empêche pas de calculer des trajectoires orbitales et supersonniques au centième de degré près, au millimetre par seconde près, et effectuer des taches parallèles même si les spécialistes me diront que le 8086 n’est pas gravé pour du calcul parallèle. Les programmer en logiciel et les faire exécuter par un monotache séquentiel ça marche aussi.
Parce qu’ils ne sont pas occupés à lire un cd, afficher une mise en veille à la con, et autres gadgets du bureau.
Un 8086 qui execute les calculs d’un simulateur gravitationnel en mode texte, uniquement occupé à faire du calcul mathématique, sans affichage graphique ni autres ressources utilisées pour le look tourne quatre fois plus vite que s’il devait afficher du graphique couleurs et utiliser des gestionnaires de souris, de cartes sons et autres gadgets pour geecks de bureaux.

Nous vivons une époque merveilleuse où tout le monde a oublié qu’un ordinateur est d’abord un calculateur mathématique avant d’être un truc multimédia pour geeck du dimanche dans son salon ; où les dirigeants de compagnies aériennes basent tout sur l’efficience commerciale gérée par informatique en oubliant que l’avion est toujours un avion, un pilote toujours un pilote, les lois de la mécanique des fluides toujours les lois de la mécanique des fluides.

Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
Par Halman (xxx.xxx.xxx.76) 11 juillet 2009 15:42

Le gag avec les commandes de vol électrique c’est que comme ce sont des ordinateurs qui envoient des ordres électriques à des commandes electro hydraulique, les pilotes n’ont donc par conséquent pas de sensations aux commandes. Envoi à sens unique vers les commandes, et pas de retour des informations au manche, à contrario des commandes mécaniques.

Avec des commandes par cables et tiges et renvois de bielles, les efforts aérodynamiques sur les commandes se font sentir au manche. Par exemple plus la vitesse augmente plus les efforts à fournir au manche sont importants.

Il a donc fallu créer des logiciels qui reproduisent synthétiquement les efforts aux commandes. Et il a fallu des années de développements, de tests en vol et en commercial, des discussions interminables de pilotes de lignes à couper les cheveux en quatre pour savoir si lors du décrochage le logiciel devait reproduire ce qu’il se passait dans les gouvernes classiquement ou bien inventer un système mécanique d’alerte comme le manche vibreur, ou autre système bizarre.

Hors le manche vibreur se déclanche genre tout ou rien. BRRRR il vibre ou il vibre pas. Avec plus ou moins d’intensité selon que le décrochage est proche selon les modèles.

Alors qu’avec un système qui aurait reproduit chaque mouvement et chaque effort infime des ailerons, volets, profondeurs, dérive, etc, le pilote aurait eu des dizaines d’informations subtiles avant que le BRRRR se déclanche. Du coup les cdve rendent aussi aveugles aux sensations de données subtiles données par les efforts sur les commandes, qu’elles ne reproduisent que très grossièrement.

Et le pilotage s’en trouve totalement transformé. Un pilote d’A320 qui se remet au planeur est dérouté par les sensations du manche dans tout le domaine du vol.

D’où gros problème de sécurité.

Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
Par L’enfoiré (xxx.xxx.xxx.206) 11 juillet 2009 15:59

Bonjour Halman,
Merci pour cet éclairage.
Je viens de regarder sur FR5 "Dangers dans le ciel "Airbus DHL Oscar Lima Lima"
La ce n’est pas un problème d’avion, amis de terrorisme. Au dessus de Bagdad, missile qui a annulé le système hydraulique.
L’avion avec la seule force des moteurs et le jeu de rebond qui a pu regagner la piste d’atterissage. Encore un cas qui n’était pas prévu par les consignes.
Deux précédents crashs dans les mêmes circonstances.

Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
Par Marianne (xxx.xxx.xxx.112) 11 juillet 2009 16:05

@ l’auteur,

Bonjour,

Je vous renvoie tout da’bord à l’article que j’ai proposé à la publication sur Agoravox après le crash de l’AFF 447 concernant le problème des sondes Pitot :

http://www.agoravox.fr/tribune-libre/article/de-la-vitesse-critique-d-un-avion-57348.

Suivant ce dossier d’assez près, voici mes réflexions sur les questions que vous soulevez.

Comme vous le montrez, la complexité de plus en plus grande des systèmes de pilotage embarqués à bord des avions semble poser problème. Dans le cas de l’AF 447, d’après des syndicats de pilotes qui s’exprime sur la base des messages automatiques ACARS envoyés par l’avion avant le crash, il semble que la défaillance des sondes Pitot (gel obstruant les capteurs), ayant entraîné une erreur dans l’indication de vitesse à l’ordinateur de bord, soit à l’origine du bug.

Mais en cas de panne d’un autre élément de l’avion, comment aurait réagi l’ordinateur de bord ?

En effet, on peut imaginer une panne/erreur initiale différente qui aurait eu peu ou prou des conséquences similaires en faussant des données elles-mêmes en interaction constante avec tous les autres paramètres de pilotage...ce qui, comme vous le soulignez, représente un nombre impressionnant de combinaisons...

Vous écrivez que ces ordinateurs ont renforcé la sécurité des vols. Jusqu’ici, c’est probablement le cas même si les exceptions sont douloureuses et posent beaucoup de questions pas seulement d’ordre technique.

Après votre constat que ces ordinateurs sont faillibles et peuvent buguer, vous préconisez tout de même de pousser plus avant l’informatisation des avions en substituant aux logiciels actuels des logiciels encore plus sophistiqués. Puis vous vous interrogez :

"La solution serait-elle alors de prévoir un débrayage total des systèmes embarqués, avec reprise en main entièrement manuelle de l’avion ? Est-ce la bonne solution ? Probablement pas. D’une part ces aides à la navigation ont diminué le nombre d’accidents, mais surtout l’architecture même des avions modernes ne permet plus l’interaction directe, que ce soit dans le sens pilote-avion (du manche à balais aux gouvernes par exemple), ni dans le sens environnement-pilote (de la sonde de vitesse à l’affichage en cabine). »

Et plus loin :

"Ces systèmes automatisés ont provoqué la disparition du « troisième homme » : le mécanicien naviguant (Rappelez-vous les mouvements sociaux chez Air Inter à la sortie de l’Airbus A 320). Il serait peut être judicieux de repenser à créer un nouveau troisième homme en embarquant un « ingénieur système navigant."

En fait, tout en décrivant les changements intervenus ces 20 dernières années dans les techniques de pilotage, vous touchez à la question cruciale de savoir s’il est possible de s’en remettre totalement à des systèmes informatiques aussi sophistiqués soient-ils, "devenus d’énormes « usines à gaz » gérant l’avion dans son ensemble" ?

Autre question : est-ce les systèmes automatisés qui ont entraîné la disparition du mécanicien navigant (troisième homme) ou des choix opérés par des acteurs de l’industrie aéronautique – des techniciens mais surtout es industriels et/ou des actionnaires ?

En effet, il y a encore quelques années, les systèmes de pilotage informatiques étaient couplés aux systèmes hydrauliques existants et une reprise "en main" par le pilote était tout à fait envisageable.

Ces derniers ont été abandonnés comme de nombreux équipements considérés comme une surcharge responsable d’une consommation plus importante en carburant...

A cet égard, il est surprenant d’apprendre que pour réaliser des économies de carburant en allégeant le poids des avions, Airbus a même envisagé un temps de supprimer les manettes de gaz...

Airbus A 330, un appareil trop assisté par ordinateur ?

http://www.tourmag.com/Vol-447-l-Airbus-A330,-un-appareil-trop-assiste-par-ordinateur_a32498.html

Et pour comprendre comment fonctionne un pilote automatique :

http://jr.skynetblogs.be/post/5406692/comment-fonctionne-un-pilote-automatique-

En conclusion, s’il n’est pas question de nier l’apport des ordinateurs à bord des avions, une présence humaine renforcée et un deuxième système de pilotage affranchi – au moins en partie - du calcul automatisé ne sont-ils pas nécessaires pour parfaire la sécurité des avions de ligne.

La sécurité n’est-elle pas à ce prix ?

Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
Par L’enfoiré (xxx.xxx.xxx.206) 11 juillet 2009 16:17

Marianne,
Pour avoir "jouer" avec des ordinateurs pendant 40 ans, cela m’énerve encore d’entendre que 70% des crashs sont dûs à des erreurs humaines.
Un ordi, ça passe ou ça crache presque tout de suite, grâce à son électronique.
Ce qui est mécanique il y a de l’usure. L’électronique est moins sujet à ce problème de temps.

Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
Par HELIOS (xxx.xxx.xxx.79) 11 juillet 2009 16:23

PREMIERE PARTIE

===============

Bonjour,

Je voudrais intervenir dans ce débat et lui apporter une touche professionnelle.

J’aimerai d’abord parler du MATERIEL.

Les équipements de bord ne sont pas des PC comme nous achetons à "Rue Mongallet".
Il s’agit de matériel industriel qui n’ont que peu a voir avec leurs version grand public.
S’attacher a parler de Motorola 68000 ou d’Intel 80286 n’a que peu de sens. Les informations à traiter et traitées ne sont pas des clones de Windows, il n’y a pas d’interface graphique. La plupart du temps un simple 8088 sorti en 1983 est capable de tout traiter.

Acquérir et traiter les paramètres de vol une fois toutes les millisecondes (1/1000 de seconde) avec un 80286 ou un "petit" 80386, vous savez, les pentium 3, c’est déjà du grand luxe cote puissance de calcul.

Chercher des causes dans le matériel est a mon avis faire un mauvais procès aux fabricants d’équipements.

Je modérerais néanmoins mon point de vue, car depuis les années 2000 il y a eu une chute considérable de la qualité intrinsèque de TOUS les matériels sans exception, militaire compris. Le domaine infernal de la rentabilité s’est mis a affecter l’ensemble du monde industriel où la logique du :

--- "on fabrique pour x années ou x mois au moins, si ça dure plus tant mieux" ---

est devenu :

--- "on fabrique pour x années, ou x mois et cela NE DOIT PAS durer plus"... pour assurer le renouvellement commercial.

Parallèlement a ça, la réparabilité a été diminuée au maximum, les fabricants préférant échanger l’ensemble du produit plutôt que de le réparer. Cette politique a l’énorme avantage de maitriser le marché (pas d’exposition du contenu, des process, de la fabrication etc), de contrôler le renouvellement des produits et de couper l’herbe sous le pied a toute une économie du réparable bien gênante. Je rajouterai, mais cela n’a rien a voir avec le sujet, cela permet de mettre en œuvre des usines délocalisées ou le personnel est peu formé et le taux de qualité en bout de chaine inferieur. Dans la démarche marketing, une « marque » vous échangeant sans discuter un produit en panne (mal fabriqué) par un neuf, augmente paradoxalement son image de marque !!!

L’aéronautique n’échappe pas a cette tendance, sauf qu’en vol de nuit au milieu de l’atlantique on ne change pas un calculateur de bord en garantie !

Comme vous le voyez, sans donner un blanc seing a l’industrie aéronautique, je m’abstiens pour l’instant d’accuser le matériel. Il est probable qu’une architecture plus "prudente" de l’avion aurait évité ce drame, mais c’est très difficile de le vérifier et de le justifier au vu des statistiques QUE NOUS CONNAISSONS. ---A quand le libre accès au log des messages de maintenance des avions, car toutes les pannes ne se sont pas transformées en drame, mais peut être ceux ci ont été évités de justesse. Je dirais même mieux, a quand les statistiques de retour des malfaçons et des pannes sur tout ce qui se produit ?

Passons maintenant au LOGICIEL.

Si je suis très tolérant avec les producteurs de hardware, je suis considérablement plus accusateur pour les sociétés de services ayant développé les logiciels embarqués et toute l’informatique qui va avec.

Comme pour le matériel, il y a eu une chute terrible de la qualité des produits a la fin des années 90. Cela est relativement simple a expliquer.
Le monde du logiciel, basé sur une rigueur forte, a comme les autres "commerces" été rattrapé par les coûts. Pour diminuer ceux ci, Deux axes ont été envisages... baisser le prix de la main d’œuvre et baisser la durée de fabrication... ou les deux mon général !

Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
- Par HELIOS (xxx.xxx.xxx.79) 11 juillet 2009 16:25
 
 DEUXIEME PARTIE (SUITE)
 
 =====================
 
 ==== Baisser le COUT de la MAIN D’ŒUVRE ==== :
 
 Cela s’est fait d’une part par la délocalisation, ce qui a entrainé ipso facto une diminution du prix mais aussi une diminution de la qualité. non pas que les informaticiens off shore soient plus mauvais, mais tout simplement ils ne sont pas formés aux méthodes, ne connaissent pas le niveau de responsabilité que nous connaissons (regardez le « i ») et ont donc implémenté, a leur sauce, des produits complexes... et d’autre part, par l’embauche de "jeunes" débutants (moins de 2 ans d’expérience) et leur affectation sur des projets a haut risque. Ces armées de programmeurs de qualité inégale ont eu sur les bras des travaux au delà de leur expérience, cas aggrave par l’encadrement défaillant. je m’explique sur ce point...
 
 L’encadrement coutant plus cher, le nombre et la qualité a fortement baissé. Là ou on comptait moins d’une dizaine d’ingénieurs pour un chef de projet s’est transformé en 20 et plus de jeune nécessitants un support accru vue leur expérience. Le traitement de la qualité (un ingénieur dédié par projet), l’intervention de consultants… tout ce support a la création a fondu laissant la place a des Template et/ou des logiciels d’avancement de projets qui ne remplace évidement pas la compétence des spécialistes.
 
 De plus, les cadres chargés d’assumer les responsabilités techniques, administratives de ces projets n’échappent pas a ma vindicte. Dans la plupart des SSII, ce sont les moins bons qui résistent aux purges. Pendant que les personnes compétentes sont « au charbon » c’est-à-dire sont chez les clients en train de bosser, eux, jamais choisis ni réclamés par les clients restent dans les couloirs de leur entreprise et développent des capacités d’influence significative. Il est a lors pour eux aisé de se maintenir et de progresser dans les hiérarchies diffusant leur incompétence et éliminant tous ceux qui les connaissent bien et qui pourraient leur faire un peu d’ombre.
 
 Enfin, la complaisance des procédures de recettes, éminemment liées aux conditions contractuelles de ces projets sommes toutes juteux n’est pas a ignorer non plus. Entre copain, on ne va pas « rejeter » des process complets, même s’ils sont bancals et si des équipes discrètes autant que réduites vont faire leur possible pour en bricoler le fonctionnement jusqu’à l’acceptabilité vraie.
 
 ===== Baisser la DUREE de fabrication =====
 
 C’est la un domaine que peu de personne imagine, mais La France a été un des leaders mondiaux dans la réalisation de logiciel. Cela a été du a différents facteur dont un fut majeur lié a la qualité de la conception.
 
 Grace a l’application de méthodes très fortes et très solides, les produits ainsi développés dans le contexte des démarches méthodologiques vraiment appliquées étaient d’excellente qualité. Le revers de la médaille est naturellement la lourdeur des opérations de conceptions, leurs durées et la compétence nécessaire des concepteurs, ingénieurs mieux formes, expérimentés et donc plus chers.
 
 La cupidité des SSII qui au départ ont profité pour saigner je ne sais combien de banques d’assurances, d’administrations en leur vendant ces méthodes s’est également traduit par la volonté de ne pas capitaliser les travaux déjà effectués recommençant encore et encore les mêmes études.
 
 Ce qui devait arriver arriva rapidement, les anglo-saxons ont profités pour d’abord récupérer le mécontentement, ont sorti des « raccourcis » méthodologiques développés par leurs propres sociétés, les ont commercialisés (au passage la méthode dominante française était gratuite) et ont lancés des idées séduisantes mais hélas perverses. En prônant le « RAD » Rapid Application Design, ils ont évidement tués les démarches plus complexes. Petit a petit ils ont réussi a vendre des concepts existant déjà dans les méthodes et démarches existantes, mais ils les ont emballés dans leur langue et dans les esprits grâce au relais d’internet qui a joué un rôle déterminant, comme il se doit. Les méthodes dites « OBJET » qui ne sont que des vues faciles du comportement des concepts informatiques ont remplacé les vraies approches conceptuelles, avec naturellement les imprécisions et non homogénéité qui vont avec. (Reportez vous a UML si vous voulez en savoir plus)
 
 Naturellement les SSII ont pu ainsi fourguer leurs équipes de bras cassés, tant au point de vue des forces vives (ingénieurs) trop débutants que de leur encadrements (incompétents et magouilleurs)
 
 Nous en sommes arrivés au point ou aujourd’hui, les entreprises achètent des formations méthodologiques a la bonne gouvernance des systèmes d’information (lisez ITIL) alors qu’ils possèdent déjà tout ça dans les recueils méthodologiques EN FRANCAIS des années 1990.
 
 Au final, les produits logiciels informatiques n’ont rien gagnés en qualité intrinsèques, c’est-à-dire en nombre de bug par ligne de code écrite, c’est-à-dire qu’il persiste autant d’erreur technique a l’intérieur qu’il y a 20 ans, qu’ils sont extrêmement plus lourd et surtout et c’est la le problème et nous revenons ainsi au vol AF 447, leur architecture conceptuelle est probablement mauvaise ou au minimum ne couvre pas l’ensemble du domaine qu’il devrait traiter.
 
 Cet article est intéressant. Je suis désolé de laisser un commentaire en deux parties, aussi long. Le sujet n’est pas simple, mais on ne peut laisser dire que l’informatique embarquée a atteint ses limites.
 
 On peut seulement montrer et condamner les comportements irresponsables d’un modèle industriel qui n’a plus les moyens d’être le maitre chez lui et qui doit composer avec le modèle financier dont, on le comprend bien, la finalité est loin d’être la même.
 
 <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p> </o:p>
 Je vous remercie de m’avoir lu, j’ai bien écrit un article là, hein
 
 Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
- Par al44 (xxx.xxx.xxx.153) 11 juillet 2009 17:33
 
 Bonjour,
 
 Informaticien travaillant sur ce type de logiciel ( sous marin nucléaire, plutôt qu’avionique), je confirme complétement les dires d’Hélios . Oui la complexité croissante des processeurs, et des process à gérer rend de plus en plus difficille une validation compléte des logiciels. Mais avec un respect de régles, des gens rigoureux , des tests exhaustifs et les outils existants on arrive à quelque chose d’acceptable si on nous en laisse le temps. Le probléme, c’est notre super logique ultra libérale (ou néocon) qui dois faire des gains de productivité à TOUT LES PRIX .Donc en plus des exemples déjà donné, sachez que par exemple les Directeurs de Centrale Nucléaire sont notés sur les gains de productivité qu’ils font ( en générale sur la maintenance ou en virant les anciens trop cher qui maitrisaient les process), attendez-vous dans les années à venir a voir pas mal d’avions dégringoler, des champignons pousser et des sous-marins nucléaire se rentrez dedans...
 Ceci dit cela aura peut être plus d’effet que les morts des emeutes de la faims, dont les responsables sont les mêmes que ceux qui ont généré la crise et les 2 ou 3 bricoles citées plus haut. Pour l’instant, on leur file du fric pour que tout soit comme avant et ont continu joyeusement, la crise est fini qu’ils disent mais l’impacte de leurs conneries inhumaines on va le découvrir petit à petit .
 
 Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
- Par herbe (xxx.xxx.xxx.13) 11 juillet 2009 18:19
 
 Comme Helios, j’aimerais élargir le propos qui est un débat de société et c’est un cetain modèle qui est à repenser.
 
 Cet article nous aide aussi à prendre du recul :
 
 http://michelvolle.blogspot.com/200...
 
 extraits :
 
 "L’informatisation est donc un art dont le chef d’œuvre est la réussite de la synergie entre l’être humain et l’automate. Cela demande une conjonction de rigueur et de sensibilité à laquelle ne peuvent parvenir ni l’étroitesse de tant de techniciens spécialisés, ni les évidences triviales du business is business dont se satisfont tant de managers. "
 
 "
 
 L’informatisation procure par ailleurs des armes déconcertantes à des criminels, des terroristes, des insurgés : les institutions vacillent, les pouvoirs s’effraient. Elle nous a fait pénétrer un continent nouveau où nous découvrons une faune et une flore dont nous ne savons que faire : qu’est-ce qui est poison, qu’est-ce qui est comestible ? Il reste aussi à y tracer des routes, placer des balises, bâtir logements et entreprises.
 
 Que voulons-nous donc faire et, finalement, que voulons-nous donc être ? Au-delà des questions de savoir-faire, les questions de savoir-vivre s’adressent à nos valeurs, le tremblement de terre qu’a déclenché la technique nous invite à un effort d’élucidation métaphysique : il faut tirer au clair ce qui, nous orientant, suscite nos intentions, nos volontés, nos désirs ; il faut réveiller une réflexion qu’avait endormie le confort procuré par l’industrialisation."
 
 Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
- Par c.d.g. (xxx.xxx.xxx.39) 11 juillet 2009 18:53
 
 Il y a beaucoup de vra dans ce que dit Helios, mais il y a aussi quelques points avec lesquels je ne suis pas d accord.
 Ayant travaillé dans le domaine, a mon avis les methodes ne sont pas le probleme. Dire que UML et l orienté objet sont moins bien que les methodes des années 90 est faux. Ca ne s adresse pas a la meme problematique.
 Le cycle en V et autre DOD en vogue en 90 sont bien pour construire des logiciels dont les specifications sont coulees dans le beton au moment du debut du projet. L oriente objet vise surtout a reutiliser des composants qui existent deja. Et les methode agiles sont surtout concuespour des specifications evolutive (plutot pour des porjets ou le client a une idee vague de ce qu il veut, donc normalement plutot de IT que de l embarque)
 D ailleurs je suis sur que l airbus en question n embarque quasiment que du logiciel developpé avec les bonnes vieilles methode (et surement dans la fin des années 90)
 
 Ayant travaillé en SSII, je peux qu approuver le commentaire sur leur comportement. Une SSII est en general nommé "marchand de viande" qui n a qu une idee faire du benef et le plus vite possible.
 Donc si on peu mettre un debutant ou stagiaire pour faire le travailm, on va pas se gener. Par contre, je doute que dans le cas de l airbus, il y ai eut delocalisation. Les logiciels developpé en off shore ne sont pas encore dans les cockpit
 
 Un autre point est la baisse de la qualité du personnel qui ecrit le logiciel. C est normal. Qui a envi d etre sous payé par une SSII, sachant qu il va etre un jour remplacé par un indien encore moins cher. Donc contrairement a ce que dit helios, donc les responsables de projets ne sont pas les bras cassé mais ceux qui ont le plus de lucidité, d ambition (et souvent de competence tech). Mais c est vrai que pour etre un bon chef de porjet, il ne suffit pas d etre un bon technicien
 
 Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
- Par L’enfoiré (xxx.xxx.xxx.119) 13 juillet 2009 14:14
 
 Hélios,
 
 Merci aussi pour cet éclairage qui me paraît assez proche de mon expérience en informatique.
 
 Oui, absolument, on ne répare jamais un processeur. On le remplace. Pas de doute.
 
 S’il y a une défectuosité, cela se découvre assez vit et c’est la chaleur seule par son utilisation qui peut l’altérer dans la suite.
 
 L’informatique dans l’avionique, je ne suis pas spécialiste, mais je suis presque certain que les processeurs n’ont rien à voir avec des 8088 ou même 80386. Un 8088, tout traité ? Là, c’est de la fantaisie, car l’avionique demande une force de calcul qui doit gestionner bien plus d’instructions par unité de temps que dans les années 80.
 
 Intel et les autres s’approvisionnent probablement en Asie. Et en effet, la grande production a fait baisé les prix et la quantité remplace la qualité.
 
 Les logiciels ne font pas exception. On ne paye plus les experts spécialistes, on les envoie à la retraite prématurément, on délocalise en Inde et ailleurs. La culture étant différente, pourquoi cela irait-il mieux ?
 
 Alors, là bas on crée des ingénieurs à la pelle. Mais dans le lots, comme partout, il n’y a que quelques bons qui sortent du lot et qui font tourner les développements. L’armée des autres attendent le chef. Un overhead inouï.
 
 Les processus des logiciels sont diablement plus complexes et en évolution que le hardware pour compléter le tableau.
 
 Cela se passe chez les plus grands, Microsoft compris. On gère à distance le développement. Pour la maintenance des produits, c’est encore plus mal parti. On ne corrige pas les problèmes pour qu’ils ne se reproduisent plus, on fait du cas par cas, en espérant que les problèmes se reproduisent puisqu’on sera payé ad vitam pour les mêmes raisons.
 
 Le sujet n’est pas simple ?
 
 Si, il est limpide et naturel. Quand on ne paye plus, on ne travaille plus avec motivation avec le soucis du travail bien fait. Je ne connais que trop bien cela après 40 ans dans le circuit.
 
 Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
- Par L’enfoiré (xxx.xxx.xxx.119) 13 juillet 2009 14:23
 
 Pour ce qui des avions et de leur sécurité, nous sommes entrés dans une période de turbulance. Les prix ont chuté grâce au lowcost. On joue avec la masse des consommateurs.
 Les lowcost sont aussi sûr que sur les vols réguliers, dit-on.
 A quand les contrôles de maintenance encore plus éloignés pour eux ?
 On n’a jamais rien pour rien. Règle de base.
 
 Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
- Par Croa (xxx.xxx.xxx.168) 14 juillet 2009 07:43
 
 « depuis les années 2000 il y a eu une chute considérable de la qualité intrinsèque de TOUS les matériels sans exception » FAUX, globalement la fiabilité progresse !
 
 « on fabrique pour x années, ou x mois et cela NE DOIT PAS durer plus » Tout à fait VRAI mais concernant le matériel professionnel, cette caractéristique est intégrée dans la gestion maintenantce, bref, c’est surtout vrai en ce qui concerne le matériel grand public.
 
 Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
Par al44 (xxx.xxx.xxx.153) 11 juillet 2009 19:21

Je connais la DO178B , UML, les cycles en V, les cycles AGILE, CMMI et je le redits c’est hors sujet . On a maintenant de surper processeur PowerPC, des systémes d’exploitation VxWork ou Integity qui sont estempillé DO178B , des outils de couvertures de tests, des moteurs de tests basé sur des Oracles de tests , des outils de suvit des exigences ... Mais si au bout la logique est purement financiaire on fera de la merde. Les méthodes, outils, technologies n’ont rien à voir la dedans.Dernier exemple, pourquoi on remplace l’hydraulique par de l’électrique en ayant pour conséquence que quand les calculateurs redondés, voir triplés voir en vote (les calculateurs ce comparent leurs données d’entrées et le résultats de leurs calculs), tombe en rade il n’y a pas de plan B, c’est car il faut alléger l’avion . Et pourquoi, ben, pour gagner plus de fric en embarquent plus de passagers ou pour augmenter le rayon d’action ou pour consommer moins de carburant.

Dans le cas présent, le seul aspect technique qui m’étonne c’est qu’il y a 3 sondes PITAU ( pas mal on triple le capteur), mais ils sont tout les 3 de la même technologie, alors que même sur un sous marin pour mesurer l’immersion on utilise au minimum 2 techno différentes. bizzare

Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
Par Marianne (xxx.xxx.xxx.207) 12 juillet 2009 08:19

Dommage que cette discussion ait été interrompue (disparue de la une) en plein vol...

Elle s’avérait intéressante sur les choix techniques opérés par les industriels de l’aviation il y a quelques années et les raisons financières de ces choix.

Je me suis laissée dire qu’au moement de l’arrivée de ces gros ordianteurs de bord - et certains des commentaires ci-dessus le confirment - qu’un désaccord entre les techniciens de l’aviation et les partisans du tout informatique avait éclaté.

Finalement, comme le plus souvent dans un système avant tout dévolu à la rentabilité, ce sont les financiers qui ont gagné : tout informatique, abandon du système hydraulique même en système de secours et suppression du troisième homme (mécanicien)...

Comme quoi, en aviation comme dans de nombreux domaines, il est peut-être temps d’écouter les hommes de l’art, ceux qui travaillent et non ceux qui comptent...

Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
Par L’enfoiré (xxx.xxx.xxx.119) 13 juillet 2009 16:06

Marianne,
100% d’accord, avec les deux parties de l’intervention.
Un article qui sur Agoravox, ne tient pas plus d’un jour, pour laisser la place, demanderait plus de "doigté" sur ce qui est en jeu ou non pour notre futur.
Mais libre à vous de continuer l’échange. Je retourne personnellement très souvent sur de vieux articles pour les commenter.

Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
Par Croa (xxx.xxx.xxx.168) 14 juillet 2009 07:55

Toutes pistes méritent attention mais là je n’adhère pas ! Au moins en ce qui concerne les causes principales de la catastrophe ? Il y a du bon dans ces réflexions car nous savons bien qu’il ne faut pas faire confiance aux personnes autorisés.

L’hypothèse "Morice" me convient mieux, pour le moment.

à suivre...

Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
Par Marianne (xxx.xxx.xxx.187) 31 juillet 2009 08:03

"Ce 2O Aout 2009,aura lieu à Madrid l’hommage aux 154 Victimes du crash de la Spanair d’Aout 2008 à l’aéroport Barajas de Madrid. Jour funeste ou notre fils Pierrick 32ans et notre petit fils Ethan 4ans ont disparu eux aussi sur ce vol pour des vacances aux Canaries.

Les premières annonces médiatiques après le crash confirmaient le chaos organisationnel de la cie Spanair avec la supression de 1100 emplois sur 4000 dans tous les corps de métiers.

Depuis un an nous avons crée un blog http://ethanetpierrick.blogspot.com/. ou les diverses étapes toutes plus tristes et malheureuses les unes que les autres sont décrites.

Un des constats que nous pouvons tirer de cette année écoulée et après de nombreux autres crashs dont les deux derniers concernant des Francais,est que pour la plupart des entreprises la variable d’ajustement est la masse salariale mais pour les cies aériennes il y a une montée en puissance d’une deuxième variable : "les coûts de maintenance".

Patrick CHARILAS

Réagir à l'article Réagir à ce message Signaler un abus Lien permanent