La sûreté de fonctionnement des logiciels aérospatiaux correspond à la mesure du risque d'un logiciel ou d'une partie de logiciel, souvent critique, impliqué dans le fonctionnement d'un engin aéronautique ou astronautique.
Les principales motivations sont économiques et techniques. Il est important dans ces domaines impliquant autant d'argent d'éviter les pertes, que ce soit matériel ou humain, entraînant des surcoûts énormes. Les difficultés à gérer sont multiples, il faut créer une grande quantité de systèmes embarqués, gérer des données persistantes légères, valider des exécutions par processeurs multi-cœurs, répondre à des problématiques temps-réel, limiter la consommation d'énergie et répondre à des contraintes de développement strictes.
Il existe des architectures spécifiques à la sûreté de fonctionnement basé sur la redondance matérielle ou logicielle. Les méthodes employées importent également pour limiter les coûts de retard ou de mauvais fonctionnement, mais doivent en plus apporter la sûreté en parallèle du bon fonctionnement. D'abord en amont, pendant la conception, sont utilisées des méthodes comme l'architecture basée sur le modèle, le développement orienté sûreté ou l'utilisation de la méthode agile dans l'aérospatiale. Mais également en fin de processus, où les programmes sont vérifiés via la vérification automatique ou encore les tests unitaires
Définitions Sûreté de fonctionnement
Selon Leveson, la sûreté d'un logiciel implique d'assurer qu'il s'exécutera sans induire de risque non acceptable. La qualité de risque acceptable ou inacceptable doit être définie pour chaque système et implique souvent des décisions politiques, économiques et morales. Comme pour la sûreté matérielle, la sûreté logiciel est mise en place en identifiant les dangers potentiels tôt dans le processus de développement et en établissant des contraintes et modèles afin d'éliminer ou de contrôler ces dangers. Un logiciel critique est un logiciel qui contient des fonctions critiques.
Aérospatiale
L'aérospatiale est une discipline scientifique qui rassemble les techniques de l'aéronautique et de l'astronautique..
Objectifs Économiques Une des principales motivations des applications logiciel, notamment pour les vols commerciaux, est d'optimiser les ressources dans un but économique. Cette optimisation peut être effectuée dans plusieurs catégories : La réduction du poids des éléments permet d'économiser le fioul ; La consommation électrique doit être réduite au maximum pour éviter d'avoir à transporter trop de batteries ; L'utilisation d'outils comme la mémoire cache doit être limitée au maximum car elle entraîne un surcoût sur les processeurs qui sont extrêmement nombreux au sein d'un avion commercial.
La maintenance est également une grande source de coûts, c'est pourquoi les avions militaires sont utilisés pendant plusieurs décennies. Il est donc crucial d'apporter au sein des logiciels fiabilité, stabilité et facilité de maintenance.
Les modules doivent être au maximum réutilisables. Selon McDermid, une ligne de code vérifiée coûte entre 150 et . Le développement d'un logiciel de haut niveau de sûreté d'environ cent mille lignes de codes coûterait en moyenne de dollars.
La sûreté des logiciels permet avant tout d'éviter les accidents qui représentent des coûts financiers et matériels importants comme le montre le tableau suivant: Système Coût Description de la perte Ariane 5 (1996) de dollars Erreur logiciel impliquant une perte de contrôle. Delta III (1998) de dollars Erreur logiciel causant une perte de contrôle et l'auto-destruction. Titan 4B (1999) 1.5 milliard de dollars La mauvais placement d'une décimale dans un logiciel de vol a causé le déploiement prématuré de charges dans une orbite trop basse. Mars Climate Oribiter (1999) de dollars Une erreur d'unité métrique dans un logiciel d’atterrissage a causé une mauvaise trajectoire et la destruction pendant l'entrée dans l'atmosphère martienne. Zenit 3SL (2000) de dollars Une erreur logiciel a prématurément éteint une fonctionnalité, empêchant le satellite d'atteindre son orbite.
Techniques thumb|Évolution du nombre de lignes de code par projet aerospatial (en milliers)
L'implication des logiciels dans l'aérospatiale augmente très rapidement. À titre d'exemple, les sondes Voyager, en 1977, contenaient lignes de code informatique, tandis que l'ISSInternational Space Station en contient 1,4 million. La défaillance de tels systèmes critiques peut avoir des conséquences graves comme des pertes de propriétés, des dégâts environnementaux, des blessures ou des décès.
La NASA par exemple impose sur ses logiciels une chance de défaillance de 10 pour 10 heures de vol. Dans plusieurs pays, une validation formelle et une démonstration de la sûreté de systèmes informatiques critiques pour la sécurité sont requis par les autorités de licences officielles.
Les logiciels de l'aérospatiale doivent assurer : la sûreté de fonctionnement ; l'efficacité ; une gestion en temps réel sûre ou un ratio coût/performance faible.
Depuis 1945, le nombre de morts par an pour de milles parcouru par des passagers sur des vols commerciaux, hors actes de malveillance intentionnelle, est passé de 5 à moins de 0,05. En plus de la sécurité liée au fonctionnement des logiciels, les méthodes et les organisations des projets doivent imposer une grande rigueur pour éviter au maximum les retards, qui impliquent également de forts surcoûts. + Coûts et retards pour les programmes de modernisation de la FAA Federal Aviation Administration Projet Coût total du programme (en million de $) Date d'opération Estimation originale Coût réel Estimation originale Date réelle WAAS 892.4 2900.0 1998 2000 STARS 940.2 1400.0 1998 2002 AMASS 59.8 151.8 1996 2002
Challenges Les logiciels critiques (comme ceux des zones industrielles, de l'industrie de l'automobile, et les applications de l'aérospatiale) ne devraient jamais subir d'erreur de codage (de bug).
Les systèmes électroniques pour les véhicules modernes doivent être conçus pour respecter des exigences strictes en matière de performances temps-réel, de sûreté, de consommation d'énergie et de sécurité.
Systèmes embarqués
L'approche la plus souvent utilisée pour développer de larges systèmes aérospatiaux impliquant une équipe importante est de créer des systèmes embarqués sous forme d'intergiciels. Cela permet de déplacer la complexité bas niveau hors des applications qui interagiront avec ces systèmes, ainsi que de travailler avec de nombreux systèmes hétérogènes, de porter le code et de faciliter la maintenance.
Les systèmes embarqués ne permettent pas, contrairement aux ordinateurs classiques, de séparer le matériel du logiciel. Il est en effet compliqué d'abstraire le matériel pour pouvoir poser n'importe quelle couche logiciel dessus. Cela implique de plus grands coûts liés à la non réutilisabilité et à la double compétence éléctronicien/informaticien nécessaire.
Gestion des données persistantes
Les données persistantes doivent être légères étant donné que la mémoire de stockage est souvent limitée et alimentée par des batteries. Il faut également gérer des interruptions électriques momentanées en conservant les informations.
Processeurs multi-cœur Les processeurs multi-cœur posent plusieurs problèmes. Tout d'abord ils présentent une plus grande complexité de configuration et des fonctionnalités clés comme la mémoire cache et la gestion de pipelines. Mais le plus contraignant est la propriété non déterministe de l’ordre d'exécution des tâches qui est un challenge particulier pour construire des démonstrations sûres de système logiciel.
Temps réel
De nombreuses connexions existent au sein de ces systèmes complexes. Il faut donc une gestion appropriée des tâches parallèles. Cela implique qu'il faut garantir qu'un processus sera terminé avant une limite de temps et une limite de ressources dans le cadre d'applications aussi critiques.
Le respect de la vitesse d'exécution limite la complexité des algorithmes utilisés au sein de systèmes embarqués. À cela s'ajoute souvent le besoin de pouvoir surveiller l'activité des dis algorithmes, ajoutant encore de la complexité.
Consommation d'énergie Les éléments embarqués au sein d'un appareil doivent assurer leur fonctionnalité tout en étant limités par la puissance fournie par le générateur. C'est particulièrement le cas pour les plus petits véhicules où la quantité d'énergie disponible est extrêmement limitée.
Pour économiser un maximum d'énergie, les algorithmes sont pensés en fonction de leur simplicité et de leur consommation. L'énergie utilisée par les systèmes informatiques embarqués peut représenter jusqu'à 20 % de la consommation totale.
Exigences
Tout avion qui décolle d'un aéroport doit répondre à des exigences nationales, voire internationales pour garantir l'intégrité des personnes à bord et autour de l'appareil. De nombreuses organisations de certification et de réglementation aéronautique civile existent. Les deux principales sont : l'AESAAgence Européenne de la Sécurité Aérienne, créée en 2003 (voir exigences AESA) ; la FAA aux États-Unis, créée en 1958 (Plus d'informations).
Ces deux agences définissent, entre autres, les exigences concernant la conception des avions, leur exploitation commerciale et les licences de pilotage. Les principales exigences applicables à la sureté de fonctionnement des systèmes sont définies dans le paragraphe numéroté 1309 à la fois dans le document CS-25 de l'AESA et le FAR-25 de la FAA. Ils décrivent les exigences et sont généralement complétés d'annexes décrivant les moyens acceptés pour répondre à ces exigencesAcceptable Means of Compliance (AMC).
Architectures pour la sûreté des logiciels Systèmes à redondance parallèle Pour contrôler les pannes, les constructeurs d'engins aérospatiaux utilisent la redondance parallèle des systèmes. Tous les systèmes critiques sont multipliés (Au moins par 2). Ainsi si l'un des éléments tombe en panne, son identique parallèle est toujours disponible. Il existe 3 types de redondance : Redondance de la surface (Surface redundancy) : Le matériel est dupliqué ainsi que son contrôleur ; Redondance du contrôleur : Le même matériel est contrôlé par deux contrôleurs ; Contrôleur avec redondance interne : un seul contrôleur gère le matériel, la sécurité par redondance est gérée par le contrôleur.
Cette redondance permet d'augmenter le temps avant la panne d'un élément. Par exemple si un élément a un taux de pannes de par heure, alors si on le duplique en 3 exemplaires on obtient un taux de pannes de × × = par heure. On peut donc espérer que l'élément ne tombe en panne qu'après heures.
Le problème de cette méthode est que si un élément provoque des erreurs de calcul ou de mesure, le système ne saura pas définir quel élément a "raison". Pour pallier cela, il faudra utiliser des systèmes plus complexes comme la Triple redondance modulaire.
Redondance Triple Modulaire
La redondance triple modulaire est une variante de la redondance N modulaire et est couramment utilisée dans les systèmes automatisés à tolérance de pannes. Un système de redondance N modulaire exécute successivement plusieurs tâches indépendantes. Chaque tâche distincte est exécutée par un nombre impair N de processeurs distincts. L'unité de vote obtient le résultat sans défaut pour la tâche en sélectionnant le résultat calculé par la majorité au moins (N + 1) / 2 des processeurs.
Pour un système de redondance triple modulaire, l'application de contrôle est reproduite sur un groupe de trois machines distinctes. Chaque tâche doit recevoir une entrée identique et est ensuite exécutée par les trois machines. Les résultats obtenus sont ensuite comparés, et le résultat calculé par la majorité des trois serveurs d'applications est utilisé comme le résultat final.