Aller au contenu

Utilisateur:Dubus.guillaume/Brouillon

Une page de Wikipédia, l'encyclopédie libre.

La sûreté des 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 uni

Définitions[modifier | modifier le code]

Sûreté de fonctionnement[modifier | modifier le code]

Article principal : 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écision 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 constraintes et modèles afin d'éliminer ou de contrôler ces dangers. Un logiciel critique est un logiciel qui contient des fonctions critiques[1].

Aérospatiale[modifier | modifier le code]

Article principal : Aérospatiale.

L'aérospatiale est une discipline scientifique qui rassemble les techniques de l'aéronautique et de l'astronautique[note 1].

Objectifs[modifier | modifier le code]

Économiques[modifier | modifier le code]

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[2] :

  • La réduction du poids des éléments permet d'économiser le fuel;
  • 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[3].

Les modules doivent être au maximum réutilisables. Selon McDermid, une ligne de code vérifiée coûte entre 150 et 250 dollars. Le développement d'un logiciel de haut niveau de sûreté d'environ cent mille lignes de codes coûterait en moyenne 25 millions de dollars[4].

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[5]:

Système Coût Description de la perte
Ariane 5 (1996) 594 millions de dollars Erreur logiciel impliquant une perte de contrôle.
Delta III (1998) 336 millions de dollars Erreur logiciel causant une perte de cotrô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) 524 millions de dollars Une erreur d'unité métrique dans un logiciel d'atterissage a causé une mauvaise trajectoire et la destruction pendant l'entrée dans l'atmosphère marsienne.
Zenit 3SL (2000) 367 millions de dollars Une erreur logiciel a prématurément éteint une fonctionnalité, empêchant le sattelite d'atteindre son orbite.

Techniques[modifier | modifier le code]

Evolution du nombre de lignes de code par projet aerospatial (en milliers)[6]

L'implication des logiciels dans l'aérospatiale augmente très rapidement. A titre d'exemple, le vaisseau Voyager, il y a 25 ans, contenait 5000 lignes de code informatique, aujourd'hui l'ISS (International Space Station) en contient 1,4 million[7]. La défaillance de tel système critique 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 de personnes[8].

La NASA par exemple impose sur ses logiciels une chance de défaillance de 10-9 pour 10 heures de vol[9]. 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[10].

Les logiciels de l'aérospatiale doivent assurer:

  • La sûreté de fonctionnement;
  • L'efficacité;
  • Une gestion temps réel sûre ou un ratio performance/coût faible.

Depuis 1945, le nombre de décédés par an pour 100 millions de miles passagers sur des vols commerciaux, hors actes de malveillance intentionnelle est passé de 5 à moins de 0,05[11]. En plus de la sécurité liée au fonctionnement des logiciels, les méthodes et les l'organisation des projets doivent imposer une grande rigueur pour éviter au maximum les retards, qui impliquent également de grands surcoûts.[12]

Coûts et retards pour les programmes de modernisation de la FAA
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[modifier | modifier le code]

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é[13].

Systèmes embarqués[modifier | modifier le code]

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[14]. 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.

Gestion des données persistantes[modifier | modifier le code]

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[15].

Processeurs multi-cœur[modifier | modifier le code]

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[2].

Temps réel[modifier | modifier le code]

Article principal : Système temps réel.

De nombreuses connections 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[16].

Consommation d'énergie[modifier | modifier le code]

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[17].

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 jusque 20% de la consommation totale[17].

Exigences[modifier | modifier le code]

Passagers décédés par an pour 160 millions de km, sur les vols commerciaux, hors actes de malveillance intentionnelle

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[18]. De nombreuses organisations de certification et de réglementation aéronautique civile existent. Les deux principales sont[19]:

  • l'Agence Européenne de la Sécurité Aérienne (AESA), créée en 2003;
  • la Federal Aviation Agency (FAA) aux États-Unis, créée en 1958.

Ces deux agences définissent, entre autre, 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[19]. 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 exigences[note 2].

Architectures pour la sûreté des logiciels[modifier | modifier le code]

Systèmes à redondance parallèle[modifier | modifier le code]

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[20]:

  • 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.


Le problème de cette méthode est qu'elle ne gère pas les erreurs de calcul sur l'un des éléments. Pour palier à cela, il faudra utiliser des systèmes plus complexes comme la Triple redondance modulaire.

Redondance Triple Modulaire[modifier | modifier le code]

Article principal : Triple modular redundancy.

La fonction fondamentale d'un système de détection et de correction d'erreurs est d'atténuer l'effet des bits erronés sur un système. Les dispositifs renforcés contre un unique évènement affecté par détection et correction d'erreurs nécessitent des méthodes non conventionnelles pour estimer le taux d'erreurs du système pour les environnements spatiaux. La redondance triple modulaire est utilisée pour atténuer le taux d'erreurs dans un système FPGA.[21]

Méthodes de développement[modifier | modifier le code]

Les méthodes de développement dans l'aerospatiale doivent se soumettre aux normes de sécurités applicables aux logiciels critiques de l'avionique. Elles doivent donc respecter les conditions énoncées dans le DO-178C[22].

Model Driven Architecture (MDA) ou Model Based Development (MBD)[modifier | modifier le code]

Article principal : Model driven architecture.

Le développement basé sur le modèle utilise des composants de haut niveau, réutilisables et spécifiques au domaine. Cette méthode peut être utilisée à plusieurs niveaux, de la génération de fichiers de configuration à la génération de systèmes logiciel quasi-complet[2].

Article principal : Esterel Technologies.

SCADE, de la société Esterel, est un environnement intégré pour le dévelopement basé sur le modèle et la vérification synchrone. L'éxecution d'un logiciel doit être explicitée sous la forme de série d'étapes. A chaque étape[23]:

  • Les données d'entrée sont lues;
  • Les donnée de sortie sont calculés;
  • Ces données de sortie sont écrites.

SCADE dispose d'un validateur de modèle intégré qui permet de vérifier les modèles directement en environnement de développement[24].

Développement orienté sureté (Safety Driven Design)[modifier | modifier le code]

Les méthodes spécifications traditionnelles ainsi que les techniques d'analyse de risque ajoutent la sûreté et la vérification en fin de développement. Au contraire, le développement orienté sureté a pour but d'intégrer les problématiques de sûreté dès le début de la conception logiciel[25],[26].

La méthode STPA (Systems Theoretic Process Analysis) a pour objectif d'identifier les instances de controle inadequate qui pourraient être dangereux et les contraintes relatives à la sûreté nécessaires pour assurer un niveau de risque acceptable[27].

STAMP (System-Theoretic Accident Modeling and Process) est un modèle de causalité d'accident. Ce modèle part du principe que la sûreté est un problème de contrôle, c'est à dire que toute panne de composant, perturbation extérieur ou disfonctionnement d'interaction entre systèmes est dûe à un mauvais contrôle de ces éléments. L'objectif est que le système continue à agir de manière sûre au fur et à mesure que les changements et adaptations ont lieu[28].

Méthode Agile pour l'aerospatiale[modifier | modifier le code]

Article principal : Méthode agile.

La méthode agile s'oppose à la méthode en cascade (waterfall method) qui consiste à diviser le processus de développement en étapes et de respecter leur ordre, à sens unique, sans retour en arrière[29]. La méthode agile est encore très peu présente dans le domaine de l'aerospatiale étant donné qu'elle présente certaines problématiques pour respecter la norme DO-178B[30]:

  • La difficulté à s'adapter aux très gros projets;
  • Il est difficile d'augmenter la fréquence des relations avec les sous-traitants;
  • Des portions de codes héritées d'anciens projets font souvent partie des spécifications.

Autres méthodes[modifier | modifier le code]

D'autres méthodes apparaissent dans le cadre de recherches, parfois en collaboration avec des entreprises pour des projets réels. C'est le cas par exemple de la Formalisation et validation d'exigences critiques de sûreté[31]

La technique du Health Management[note 3] est déjà largement utilisée pour les équipements mécaniques ainsi que les systèmes électroniques. Elle permet d'améliorer leur robustesse et de réduire les coûts. De ce fonctionnement commence donc à apparaître le Software Health Management[note 4] (SHM), dont le concept est utilisé dans les logiciels de tests de l'aerospatiale[32].

Analyse et vérification formelle[modifier | modifier le code]

Automated verification[modifier | modifier le code]

Une grande partie de l'effort de sûreté va dans la tentative de preuve que les modèles existants sont sûrs plutôt que de construire des modèles sûr depuis leur conception. Le seul espoir pour la conception sûre, pratique et rentable est de concevoir des systèmes de sécurité dès la base de la conception[33].

En Safety-driven Design (Conception axée sur la sécurité), les informations nécessaires aux concepteurs pour prendre de bonnes décisions sont mises à leur disposition avant la conception et l'analyse est effectuée en parallèle au processus de conception plutôt qu'après. Une telle approche de conception sera non seulement beaucoup moins chère, mais entraînera la création de systèmes beaucoup plus sûrs[33].

Parce que la première cause des accidents dans les anciens systèmes est la défaillance de composants, l'analyse des risques des techniques de conception de sécurité était portée sur l'identification des composants critiques et/ou la prévention de leur arrêt (augmentant ainsi l'intégrité des composants) ou de fournir la redondance pour atténuer les effets de la défaillance d'un composant. Souvent, aucune analyse spéciale (analyse de risque ou de sécurité) n'est appliquée au logiciel[25].

La première étape pour mettre en oeuvre la sûreté est de séparer les échecs en deux parties[34]:

  • échecs impactant la sûreté;
  • échecs n'impactant pas la sûreté.

SFTA(SOFTWARE FAULT TREE ANALYSIS) qui est une méthode d'analyse de la sûreté de la conception des logiciels est utilisée pour s'assurer que la logique contenue dans la conception logicielle n'entraînera pas de fautes de sûreté et ausi pour déterminer les conditions environnementales qui pourraient amener le logiciel à causer des fautes de sûreté dans le système[34].

Tests unitaires[modifier | modifier le code]

MBT(Model-Based Testing) est une approche dont le but est de produire des systèmes logiciels de test se basant sur un modèle formel à partir duquel les cas de tests sont générés. Pour les tests dans l'aérospatiale, des méthodes particulières du MBT sont utilisées. On a par exemple le TTF (Test Template Framework) qui est utilisé par Fatest pour générer des tests unitaires. Notons que ces tests unitaires (produits par Fatest) ne sont pas les plus utilisés dans le domaine du MBT[35].

L'idée derrière la TTF, ainsi que d'autres méthodes MBT est d'analyser une spécification Z dérivée de cas de tests abstraits, c'est à dire des cas de test écrit en Z qui sont par la suite utilisés pour tester la mise en œuvre correspondante. Chaque classe de test est un schéma Z spécifiant une condition de test[36].

Depuis que la TTF a plusieurs différences avec les autres MBT méthodes, il est nécessaire d'expliquer comment il se comporte avec les oracles de test. Un oracle de test est un moyen par lequel il est possible de déterminer si un cas de test a trouvé une erreur dans sa mise en œuvre ou non. Dans TTF, la spécification agit comme un oracle de test. En effet, selon le fonctionnement de la TTF[37]:

  • les cas de test abstraits doivent être affinés en cas de tests exécutables;
  • ces cas de test sont exécutés par le programme sous essai;
  • la sortie produite par le programme pour un cas de test est abstraite au niveau de la spécification (si cela est possible);
  • à la fois le cas de test abstrait et sa sortie abstraite correspondante sont substitués dans le schéma de l'opération de Z appropriée.

De cette manière, le prédicat de l'opération devient un prédicat constant qui vaudra vrai ou faux[37].

Références[modifier | modifier le code]

  1. ↑ Leveson 1986, p. 139
  2. ↑ a b et c Sharp 2010, p. 623
  3. ↑ Sharp 2010, p. 625
  4. ↑ Habli 2007, p. 193
  5. ↑ Bell 2008
  6. ↑ Bell 2008, p. 135
  7. ↑ Hayhurst 2001, p. 7
  8. ↑ Leveson 1986, p. 125
  9. ↑ Leveson 1986, p. 126
  10. ↑ Leveson 1986, p. 135
  11. ↑ Bernard 2009, p. 9
  12. ↑ Hayhurst 2001, p. 7
  13. ↑ Abdallah 2010, p. 584
  14. ↑ Sharp 2010, p. 622
  15. ↑ Roll 2003, p. 79
  16. ↑ Roll 2003, p. 80
  17. ↑ a et b Spinka 2011, p. 83
  18. ↑ Bernard 2009, p. 15
  19. ↑ a et b Bernard 2009, p. 16
  20. ↑ Bennett 2010, p. 1
  21. ↑ Allen 2011, p. 1
  22. ↑ VanderLees 2009, p. 6.D.3-1
  23. ↑ Martin 2013, p. 6
  24. ↑ Martin 2013, p. 8
  25. ↑ a et b Stringfellow 2010, p. 515
  26. ↑ Owens, p. 1
  27. ↑ Stringfellow 2010, p. 518
  28. ↑ Owens, p. 4
  29. ↑ VanderLees 2009, p. 6.D.3-1
  30. ↑ VanderLees 2009, p. 6.D.3-10
  31. ↑ Cimatti 2008, p. 68
  32. ↑ Xie 2013, p. 1928
  33. ↑ a et b Stringfellow 2010, p. 516
  34. ↑ a et b Leveson 206, p. 515
  35. ↑ Cristia 2011, p. 128
  36. ↑ Cristia 2011, p. 129
  37. ↑ a et b Cristia 2011, p. 130

Notes[modifier | modifier le code]

  1. ↑ http://www.larousse.fr
  2. ↑ Acceptable Means of Compliance (AMC)
  3. ↑ En français "Management par la santé"
  4. ↑ En français "Management de logiciel par la santé"

Bibliographie[modifier | modifier le code]

Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Utilisateur:Dubus.guillaume/Brouillon&oldid=110002263 ».