Airbus passe au Big Data avec Oracle pour l’analyse de ses essais en vol
Face à la quantité de données générées par la conception des prototypes d’avions, le Big Data apporte chez Airbus de jeunes, mais prometteuses, réponses. L’avionneur a travaillé sur la question avec Oracle.
La conception d’un avion est un processus complexe. Un processus marqué, dans sa phase d’essais en vol, par une succession de tests à traiter dans des délais très courts (souvent une nuit) et une période restreinte (Time to Market oblige) sans – bien sûr - jamais sacrifier la sécurité ni la qualité.
Confronté à un « plafonnement de [ses] moyens actuels » pour traiter des masses d’informations qui ont déjà grandement augmenté depuis 5 ans, Airbus a décidé l’année dernière de se pencher sur les outils Big Data. Le but étant de se préparer à une nouvelle multiplication annoncée des données, générées notamment par des systèmes embarquées de plus en plus sophistiqués.
Des essais qui génèrent aujourd’hui 2 To de données par vol, et beaucoup plus demain
Sur la scène du Salon Big Data de Paris, Jean-Marc Wattecant, le « Head of Data Processing, Flight and Integration Test Centre » de l’avionneur, est revenu sur ce projet ô combien sensible. Car « on ne parle pas ici d’avions déjà livrés aux compagnies, mais de prototypes que l’on est en train de développer et de tester, de pousser aux limites pour montrer aux autorités de régulation que l’on peut certifier un avion ».
Concrètement, lors de ces essais en vol, Jean-Marc Wattecant et ses équipes récupèrent un ensemble d’informations issues des bus avioniques standards et de capteurs supplémentaires posés sur le prototype. « Ces capteurs ont des rôles différents selon ce que l’on veut observer. Cela peut aller de la température des moteurs à des contraintes de charge sur la voilure ou sur le train d’atterrissage », précise l’expert. Pour la campagne en cours de l’A350, Airbus analyse par exemple jusqu’à 600 000 paramètres. Et certains capteurs émettent plusieurs points par seconde. Résultat, « on arrive à avoir des journées à plus de 2 To ».
Cette volumétrie est, en plus, en constante évolution. « En effet, nous faisons des avions de plus en plus complexes, dans le sens où nous cherchons toujours plus de performances et de sécurité, explique le responsable d’Airbus au MagIT. Il faut donc des calculateurs qui permettent de gérer ces évolutions. C’est le même phénomène que votre voiture : pour avoir une meilleure consommation, vous avez un moteur optimisé avec des calculateurs qui gère l’injection. La philosophie ici est la même. On augmente la qualité intrinsèque du produit, mais il faut des moyens pour le piloter. Et c’est ce que nous contrôlons ».
Toutes ces informations sont enregistrées pendant le vol, sous la supervision d’un ingénieur navigant d’essai en charge de vérifier que les conditions de chaque test sont bien respectées (vitesse, palier, angle, etc.). Puis de retour au sol, le support de stockage est déchargé sur les serveurs d’Airbus pour que son contenu soit analysé et archivé (les données brutes devant aussi être fournies aux autorités).
Schéma du processus de production et de mise à disposition des données des essais en vol
Responsable des outils IT pour ces analyses, Jean-Marc Wattecant joue les modestes. Pour lui, la volumétrie qu’il a à gérer n’aurait rien à voir avec les géants du web comme Google ou Facebook. N’empêche. A titre de comparaison, lors d’un récent colloque organisé à la Maison des Mines de Paris, des experts et intégrateurs estimaient que la volumétrie classique d’un projet BI avoisinait le Téra de données. Dans une entreprise du CAC 40, ce chiffre monte régulièrement entre 5 et 10 To. Et pour les gros projets BI, les volumes atteignent les 40 To. En clair, dans le contexte de ses essais en vol, Airbus traite tous les 20 jours des volumes de données équivalents à la fourchette haute des projets BI multinationaux.
Et encore, ces essais en vol sont le bout d’une chaîne de tests. « C’est vraiment la phase finale du développement de l’avion. Ils permettent à la fois de valider ce que l’on a vu par d’autres moyens d’essais et de valider ce que l’on ne peut pas certifier autrement, confirme Jean-Marc Wattecant. En amont nous procédons à de nombreux tests : numériques, de soufflerie, en labos, etc. ». Des étapes qui, elles aussi, génèrent des données à « pérenniser » pour pouvoir les soumettre au régulateur.
Des problèmes d’accès simultanés pour les ingénieurs, mais pas de « Go » pour le vol suivant sans analyse
Une fois les téraoctets générés en vol mis sur les serveurs au sol, des ingénieurs aéronautiques entrent en scène pour en tirer la substantifique moelle. « On a en moyenne 600 utilisateurs sur ces systèmes », évalue Jean-Marc Wattecant. Avec, à la clef, un phénomène d’embouteillage puisqu’une grosse partie des ingénieurs est surtout intéressée par les vols qui ont eu lieu la veille ou la semaine précédente. « On observe un réel problème d’accès concurrents qui parfois nous crée des problèmes de performances sur les moyens actuels », diagnostique le responsable.
Un problème d’autant plus critique que les délais sont serrés. Très serrés. « On n’a pas vraiment le choix de prendre du retard […] Pour donner le « go » sur le vol du lendemain, il faut être capable d’avoir fait une première analyse des données du jour pour voir s’il n’y a pas de risques ou de problèmes majeurs pour ne pas mettre en danger l’avion (c’est quand même la première priorité !) et pour vérifier que les tests étaient conformes à ce qui était prévu », explique l’expert sur la scène du Salon.
Délais tendus, avions sophistiqués, données multipliées, embouteillages. La situation n’est pas simple pour l’IT. « Et on voit bien que ce n’est pas fini », pronostique-t-il, évoquant en plus le lancement de nouveaux avions, notamment « le programme NEO qui va rentrer en période de « flight test » en fin d’année ».
Comme il était « déjà difficile avec les moyens standards de répondre à l’attente », une action s’imposait. « Nous avons des avions de plus en plus complexes et nous n’avons pas nécessairement plus de temps. Donc il faut trouver les moyens de traiter ce paradoxe », atteste le représentant d’Airbus. D’autant plus qu’il ne s’agit pas d’absorber un pic d’activité ponctuel et intense, mais bien de s’adapter à une situation durable. « On n’est pas en train de parler d’une quinzaine un peu difficile où on fait travailler les équipes de manière un peu soutenue en se disant que ça va passer. Ce n’est pas un pic… c’est un plateau ».
Pour prendre le relai de l’existant et être ainsi capable « de certifier les avions sur ce rythme-là pour être présents sur le marché », Jean-Marc Wattecant décide donc d’étudier des solutions réputées pour leurs fortes capacités de traitement et de parallèlisation des process : les outils Big Data.
Un « Proof of Concept » riche d’enseignements pour tester le Big Data en contexte industriel
Un choix qui, quand on s’appelle Airbus, ne se fait cependant pas à la légère. Le Big Data n’a pas été conçu ni défini pour ce genre d’industrie ultra-critique. Un point crucial que confirme l’expert: « ces technos ne sont pas disponibles dans nos standards Airbus […] Il a donc fallu faire un parcours pour voir si cela avait du sens ».
Ce parcours au long cours d’Airbus débute par un RFI (« Request For Information »), nom maison pour « Proof of Concept » (PoC, en français « Preuve de Faisabilité »), « une manière d’évaluer [ces solutions] en grandeur nature ». Quatre acteurs majeurs (que l’avionneur ne souhaite pas nommer) répondent à la demande. Ils se voient mis à l’épreuve par Jean-Marc Wattecant qui leur demande de faire un démonstrateur qui traite les deux problèmes majeurs du métier : l’injection massive de données et la lecture concurrente avec beaucoup d’utilisateurs.
« On a pris des données d’un A380 dont nous disposions déjà. Ensuite on a demandé aux sociétés consultées de faire un chargement massif de ces données et de faire une extrapolation par rapport à nos besoins », nous détaille-t-il. « Après, […] on leur a donné notre soft maison […] pour simuler une lecture et on leur a dit : « faites nous un test avec un utilisateur, 10, 20, 30 » pour tester la stabilité, quelle que soit la charge. ».
Plusieurs éléments ressortent de cette mise en situation riche en enseignements. Le premier est que le Big Data est aujourd’hui mature. « La technologie n’est plus au stade de la recherche. Nous, nous ne sommes pas dans une logique de labo : à la fin du projet, on veut une solution industrielle. Donc parler de quelque chose d’opérationnelle, c’était important ».
Mature donc. Et adapté au cas d’usage prévu. « On a vu une stabilité dans la performance, même si on a beaucoup d’utilisateurs en simultanée, ce qui est aujourd’hui un des points faibles de notre façon de travailler ».
Autre avantage, le Big Data permettrait de décloisonner les données et de concevoir de « nouveaux services ». « Actuellement, notre environnement est orienté vol par vol. Cela rend difficile les analyses de tendances au travers de plusieurs vols ou de plusieurs avions d’un même programme », regrette Jean-Marc Wattecant. Mais avec les outils fournis « plus ou moins en standard » avec tous les produits Big Data, « il y a clairement de quoi faire des analyses transverses ». Aux métiers de trouver lesquelles.
Bref, le RFI fait passer tous les voyants au vert pour adopter en interne ces technologies à base d’Hadoop et de MapReduce (« ils ont tous répondu avec la même approche software, il n’y a pas eu d’exception là-dessus »).
Pas question de rentrer dans un déploiement long et coûteux
Oui mais voilà, entre un PoC et un déploiement industriel critique, il y a quelques escales à ne pas oublier. Comme le respect du calendrier de déploiement et la continuité de l’activité des tests. Le système à choisir devant être opérationnel pour les premiers essais en vol de l’A320 NEO (un moyen-courrier avec une nouvelle motorisation plus économe), il n’était pas question pour Jean-Marc Wattecant de rentrer dans un projet de plusieurs années.
Conséquence, Airbus a cherché - en plus de la performance pure (traitement et accès simultanées aux données) - une solution progressive qui permette dans un premier temps de faire tourner son applicatif d’analyse actuel, puis dans un deuxième temps - et seulement dans un deuxième temps - d’envisager les « nouveaux usages ». « On voulait y aller « step by step » sans que ce soit un Big Bang, souligne bien le décideur IT. C’était clef, sinon on n’était pas capable d’avoir quelque chose de raisonnablement faisable pour la fin de cette année ».
Autre point discriminant, « le design ». Comprendre : la modélisation des données en fonction de l’usage final. « Cela a beau être des systèmes Big Data avec de la puissance de calcul, si le design n’est pas correctement fait, on a une performance qui n’apporte pas la valeur attendue », avertit Jean-Marc Wattecant.
« Big Data, ça ne veut pas dire magie »
A l’issue de cette sélection, Airbus penche pour la Big Data Appliance d’Oracle. L’expert IT de l’avionneur avance trois raisons principales pour ce choix. La capacité de transition par étapes planifiées et prévisibles. Le prix (« il y a vraiment eu un différentiel là-dessus »). Et l’intégration entre Hardware et Software (« quand on a peu de temps devant nous, avoir des solutions déjà intégrées est une manière de gérer notre risque planning – le plus fort sur ce projet-là »).
Si les premiers ROI ne sont attendus qu’en 2015, Jean-Marc Wattecant prévient néanmoins déjà : « Big Data, ça ne veut pas dire magie ». Surtout dans un milieu aéronautique où les technologies – encore jeunes – demandent à être adaptées et mises à l’épreuve. « Rien d’impossible, mais ça doit être bâti ». En sens inverse, les équipes d’Airbus doivent de leur côté se familiariser avec ces nouveautés pour en assurer la pérennité. « Il n’est pas question de développer une solution industrielle et de ne pas être capable de la supporter à la fin », insiste le responsable.
Pas de magie à attendre, donc, d’autant que les retombées doivent être bien contextualisées. De son expérience, et sous réserve d’optimisations futures, l’expert d’Airbus constate en effet que « la valeur du Big Data a vraiment du sens quand on commence à avoir beaucoup d’accès simultanés à la donnée où les systèmes classiques ont rapidement des goulots d’étranglement ». Avec moins d’utilisateurs, les bénéfices (en tout cas ceux du PoC) sont moins tangibles.
Reste que le choix d’Oracle, un acteur renommé mais américain, pour une entreprise européenne aussi emblématique et sensible qu’Airbus, dans un environnement IT où les révélations sur l’espionnage industrielle et les backdoors s’enchaînent autour de PRISM, pourrait poser question.
Pragmatique, Jean-Marc Wattecant ne balaye pas la problématique d’un revers de main quand on lui pose la question. Il se montre certes très confiant (« nous avons plein de produits américains, notamment du Microsoft »). Mais également prévoyant : « tous les serveurs sont hébergés chez Airbus. Alors certes, ce sont des produits Oracle, mais ils sont intégrés dans nos datacenters qui sont surveillés et contrôlés par nos soins ».
L’A320 New Engine Option en approche avec l’Appliance d’Oracle (en attendant l’A30X)
A moins de 8 mois de la mise en service du nouveau système, les équipes d’Airbus, d’Oracle et du cabinet de conseils Sopra (qui a accompagné le projet) travaillent sur le design des données et sur l’intégration à l’environnement existant du constructeur. « On sait que c’est une phase critique, donc on s’est donné trois mois ». En revanche, la partie implémentation des couches de données ne devrait, elle, pas poser de gros problèmes.
En tout état de cause, Jean-Marc Wattecant reste sur son objectif initial : avoir un outil Big Data opérationnel pour les 3 000 d’essais en vol des huit prototypes du programme NEO. Si tout se passe bien, cette version re-motorisée de l’A320 - avec des réacteurs plus gros à la meilleure efficience énergétique - devrait décoller dans les aéroports du monde entier au quatrième trimestre 2015.