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…
Table des matières
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 :
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 (ex: avoir un bouton qui permette d’allumer ce système, etc.). À ce stade, il s’agit de la spécification du besoin. Nous sommes donc à l’entrée du cycle en V et à la sortie de la DO-254.
Un point fondamental dans le processus de développement de systèmes aéronautiques complexes est qu’il faut aussi justifier que chaque élément répond à ces exigences : “j’ai conçu mon système en en tenant compte, et en voici la justification”. Cela implique d’être capable de prouver que l’on a implémenté 100% des exigences. Tout est tracé via différents documents.
À la fin, des matrices de traçabilité à tous les niveaux viennent prouver que tout a bien été pris en compte dans la conception, la validation et la qualification de l’équipement.
Les processus de développement normés sont extrêmement générateurs de documentation et de justifications. C’est un aspect à anticiper car il implique des coûts spécifiques et peut conduire à obtenir des centaines de documents pour un seul système.
Ces justifications seront ensuite mises à l’épreuve lors d’un audit par échantillonnage qui peut durer 1 ou 2 semaine(s).
Pour en savoir plus sur le Groupe Ametra et ses expertises, consultez le site officiel.
Article par Sébastien
Très bon article de vulgarisation !
Manque peut-être un petit schéma du cycle en V avec :
– le niveau avion tout en haut et les strates Spécification Systèmes, Sous-Systèmes et Equipements
– le niveau CDR closure OK tout en bas du V
– la descente du V pour la Validation
– la remontée du V pour la Vérification avec Matrices de Vérification
Manque la notion de flow-down des exigences fonctionnelles et de performances
Manque la notion de DO-160 pour la vérification Système tout en haut
Manque une référence à l’AFIS : https://www.afis.fr/pages/accueil.aspx
Voilà c »est tout 🙂