Développer des systèmes aéronautiques complexes implique de relever de nombreux défis : enjeux de sécurité, respect des normes, mise en place de processus spécifiques, contraintes de réalisation et de validation, gestion des enjeux et de la responsabilité de sous-traitance… Un processus de développement particulièrement encadré Travailler sur un système aéronautique implique le respect de nombreux standards et normes, jusqu’à pouvoir obtenir l’autorisation de voler par la FAA et l’EASA, les autorités de certification américaine et européenne (pour ne citer qu’elles). La certification prouve que le produit satisfait aux règlements de navigabilité qui lui sont applicables. Les principaux critères d’approbation sont les suivants : Aucune panne ne doit conduire à une condition de défaillance catastrophique. Toute condition de panne doit être extrêmement improbable. L’origine des normes applicables vient du fait qu’en aéronautique, la Sûreté de Fonctionnement (SdF) est prépondérante. Plus les designs électroniques gagnent en complexité, plus il est difficile de démontrer leur non-impact sur la sécurité des passagers et des équipages.   Le principe de base est qu’un design ne doit pas entraîner d’accident mortel. Les risques doivent être calculés pour ne jamais dépasser un niveau donné : par exemple, la probabilité d’une défaillance catastrophique doit ainsi être inférieure à 10-9 par heure de vol. Ci-contre, un exemple d’arbre de défaillances Les normes sont donc nées parce que les systèmes électroniques devenaient de plus en plus compliqués : vitesse de calcul, fonctionnalités, transferts de données, interactions variées… la complexité des appareils s’est accrue, ce qui a fait naître le besoin de définir des règles et un processus pour leur développement. De nombreux standards ont émergé dans ce contexte, dont la DO-254 et la DO-178. Pour rappel, un système complexe se décompose en équipements, tels qu’un calculateur et un actionneur par exemple. Chaque sous-ensemble va être constitué d’électronique, de logiciel et de mécanique. La DO-178 est apparue pour encadrer le processus de développement de logiciels (software), là où la DO-254 est venue réguler celui du hardware. En effet, la complexité de l’électronique et notamment d’une technologie des composants FPGA (Field-Programmable Gate Area), c’est-à-dire des puces dans lesquelles on décrit de l’électronique, est venue augmenter fortement la complexité des systèmes. De son côté, l’ARP4754 spécifie la manière dont on va concevoir les fonctions d’un avion à haut niveau, ce qui permet d’encadrer le tout en strates, du système à ses sous-ensembles. L’autorisation de vol d’un aéronef est régie par des autorités de certification. Il en existe plusieurs à travers le monde, dont la FAA aux Etats-Unis et l’EASA en Europe. Ces dernières ne donnent leur aval qu’une fois qu’elles ont eu la démonstration absolue que tous les équipements d’un avion ont respecté les processus de développement. Elles peuvent alors donner une autorisation de vol. À l’heure actuelle, certifier coûte beaucoup d’argent. Le coût d’un développement normé est en effet exponentiel par rapport à un développement classique (à savoir qui n’impacte pas la vie des usagers et ne peut pas générer d’accident). L’évaluation des niveaux de risques Il existe 5 niveaux de criticité (de A à E, E étant le moins critique), tels que définis par la norme DO-178. On parle de DAL, Design Assurance Level. Niveau A : Un défaut du système ou sous-système peut conduire à un problème “catastrophique”. Niveau B : Un défaut du système ou équipement peut provoquer un problème “dangereux” provoquant des dégâts sérieux et même potentiellement la mort de plusieurs occupants. Niveau C : Un défaut du système ou sous-système étudié peut provoquer un problème “majeur” menant à un dysfonctionnement des équipements vitaux de l’appareil et des blessures potentielles. Niveau D : Un défaut peut provoquer un problème mineur sans impact sur la sécurité du vol. Niveau E : Un défaut peut provoquer un problème sans effet sur la sécurité du vol. Gravité Conséquences pour les passagers MINEURE Inconfort MAJEURE Inconfort pouvant causer des blessures DANGEREUSE Blessures graves ou mortelles à un nombre limité d’occupants. CATASTROPHIQUE Nombre important de morts accompagné généralement de la perte de l’avion. © Groupe Ametra Ce niveau est classifié au moment de l’analyse du système ou sous-système. Le niveau matériel d’un équipement a un impact direct sur : le processus de développement, le niveau de documentation associée, la méthodologie de développement, la stratégie de validation et de vérification. Schéma illustrant le traçage requis entre les artefacts de certification, conformément à la norme RTCA DO-178C: © Steven H. VanderLeest – Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=27610716   De par son positionnement en tant d’équipementier de rang 2, le Groupe Ametra intervient sur le développement d’équipements aéronautiques en support d’industriels comme SAFRAN ou THALES qui porteront la certification en frontal avec la FAA ou l’EASA. Cela pose bien sûr la question de la sous-traitance. Tout le monde ne sait pas (ou ne souhaite pas) s’engager dans un tel processus, car ce dernier est risqué, complexe et à fort impact financier. Les coûts de développement sont un vrai enjeu pour la sous-traitance. Il existe en effet de nombreuses contraintes pour développer selon des processus onéreux. Cela implique d’être compétitif, de capitaliser les compétences et outils, mais aussi de savoir embarquer les risques. Le processus de développement – DO-254 Plus qu’une norme, la DO-254 est plutôt un guide, un standard. Elle permet de mettre en place un processus et des étapes à réaliser dès le début du développement (spécification et conception préliminaire).   Ci-dessous, le cycle de vie typique d’un développement FPGA : © Groupe Ametra Ces développements sont des cycles en V dans lesquels le processus va imposer un ensemble considérable de revues de jalons spécifiques. En général, on représente la DO sous la forme d’un cycle en V et de la traçabilité. Dans le cadre de la DO, la validation désigne la validation des exigences, les étapes de vérification puis de qualification. La base de tout le processus est de décliner le besoin fonctionnel et environnemental sous la forme d’exigences qui vont apparaître tout au long du cycle en V. Toutes les fonctions que l’on souhaite implémenter vont devoir être écrites sous forme d’exigences