L’erreur

Nous nous intéressons ici à quelques exemples de systèmes dont le processus de V&V n’a pas détecté d’erreur et qui pourtant sont allés jusqu’à la panne. Nous discuterons la place de l’erreur dans le processus d’ingénierie des systèmes et les mé- thodes associées pour détecter leur insertion. Nous pourrons alors extraire l’origine de ces problèmes pour conclure sur l’intérêt des méthodes de V&V et la nécessité d’une méthode de validation des activités de V&V.

1.3. L’ingénierie des systèmes 21

1.3.2.1 Exemple d’échecs

Kosmos 419 Nous sommes le 10 mai 1971, après 10 ans et 9 missions infruc-

tueuses, tous les espoirs russes pour la conquête de Mars reposent sur la sonde Kosmos 419. Le lanceur Proton K décolle et lance la sonde de plus de 4 tonnes en orbite d’attente. Malheureusement, l’étage supérieur qui devait envoyer Kosmos 419 ne s’allume pas, c’est un nouvel échec. Loin des soucis mécaniques des premiers lan- cers, c’est une erreur de programmation qui est la cause de cet échec. Le moteur, qui devait envoyer la sonde vers Mars 1,5h après la mise en orbite d’attente, a été pro- grammé pour se déclencher 1,5 années après. Kosmos 419 rentre dans l’atmosphère terrestre et se désintègre deux jours après son lancement.

Vol 501 Le 4 juin 1996 à 9h35, le lanceur Ariane 5 allume ses moteurs pour un vol inaugural. Les systèmes de guidage inertiel (principal et secours) sont mis en route et commencent à mesurer les mouvements de rotation et d’accélération de la fusée. Ce système est principalement composé d’un calculateur, d’un accéléromètre et d’un gyroscope. Il permet de connaître la position, la vitesse et l’inclinaison d’un véhicule. C’est un système classique que l’on retrouve dans les bateaux, les avions, les missiles et les engins spatiaux. Après 37 secondes de vol, les fortes accélérations de la fusée provoquent un dépassement de capacité dans le calculateur du système de guidage inertiel principal, qui se met aussitôt hors service. Le système de guidage de secours (identique à l’autre) subit la même avarie, et s’arrête à la même seconde. Le pilote automatique, qui s’appuie sur les informations provenant du système de guidage inertiel, n’a alors plus aucun moyen de contrôler la fusée. L’échec de la mission est inéluctable. Une enquête est ouverte et montrera que, pour économiser 200 000 $, le Centre national d’études spatiales a demandé à ne pas refaire les simulations de vol puisque le logiciel de navigation était identique à celui d’Ariane 4, connu pour être un lanceur fiable.

C’est la variable d’accélération horizontale du logiciel de navigation qui est la cause de l’autodestruction de la fusée. Certaines variables ne sont pas protégées des valeurs trop élevées puisqu’il est physiquement impossible qu’un débordement se produise. La puissance d’Ariane 5 amène des accélérations 5 fois plus importantes, et ce qui était physiquement impossible avec Ariane 4 le devient avec Ariane 5. La variable codée sur 8 bits n’était pas suffisante pour stocker l’accélération d’Ariane 5. Le calcu- lateur voyait une trajectoire très différente de celle que la fusée suivait. L’ordinateur a alors commandé une violente correction de trajectoire, les tuyères des boosters et du moteur principal ont tourné jusqu’en butée, et la fusée est partie en virage serré. Les boosters ont alors été arrachés et la fusée a commandé son auto-destruction. Des simulations de vol après-coup, utilisant les systèmes de guidage inertiel et l’ordina- teur de bord, dans les conditions de vol d’Ariane 5, ont reproduit les événements qui ont conduit à l’explosion de la fusée. La négligence de ces activités de V&V a couté 500 millions de dollars.

22 Chapitre 1. Ingénierie des systèmes complexes et simulation

Mars Climate Orbiter Le 23 septembre 1999, la sonde Mars Climate Orbiter est

mise en orbite. La manœuvre d’insertion en orbite martienne était l’une des phases les plus critiques de la mission. La sonde suit à ce moment là une procédure entière- ment automatique et lorsque la manœuvre commence, plus rien ne peut stopper son déroulement. Les télémesures reçues attestent du bon comportement de la sonde. Comme prévu, la sonde passe de l’autre coté de Mars et le signal radio est perdu. Les calculs annoncent un rétablissement de la connexion pour 11h26. A 11h36 la NASA annonce officiellement que le contact avec la sonde est perdu. Si, durant les premières heures, les ingénieurs annoncent plusieurs théories sur la perte de la sonde, ce n’est que quelques heures plus tard que les premières analyses montrent des ré- sultats inattendus. La sonde est passée à peine à 57 km au dessus de la surface de mars, soit 28 km en dessous de la limite critique et à plus de 100 km de la trajectoire prévue. Une rentrée aussi directe dans l’atmosphère engendre un échauffement trop important et mène à la destruction de la sonde. Trois commissions sont chargées de trouver d’où provient cette erreur fatale. Une des commissions se prononce à peine une semaine après la destruction de Mars Climate Orbiter. Il apparaît qu’un problème d’unité dans l’expression d’une force de poussée est la cause du crash. Les ingénieurs de Lockheed Martin Astronautics (Denver dans le Colorado), la firme qui a conçu et fabriqué la sonde martienne, avaient apparemment gardé l’habitude de travailler avec les unités du système anglo-saxons. De leur côté, les ingénieurs du Jet Propulsion Laboratory (Pasadena en Californie) travaillaient depuis des années dans le système métrique. Aucun système de vérification n’a alors été capable de détecter une telle erreur considérée comme trop simple. C’est dans un contexte éco- nomique déjà difficile que la NASA doit supporter la perte d’un engin à 126 million de dollars pour une simple erreur de conversion d’unités. Les scientifiques perdent quand à eux le premier satellite de météorologie martien.

Ces échecs, bien que financièrement coûteux, n’ont pas eu de conséquences dra- matiques, ce qui n’a malheureusement pas toujours était le cas dans l’histoire de l’IS. L’augmentation de la complexité des systèmes rend la conception de plus en plus difficile et ces erreurs "simples" se retrouvent immergées au sein d’un système complexe, ce qui rend le processus de détection difficile. C’est une problématique qui amène académiques et industriels à réfléchir à de nouveaux processus, méthodes et outils pour améliorer la conception des systèmes. Un travail parallèle s’effectue en améliorant les méthodes de V&V et en perfectionnant les méthodes de développe- ment pour diminuer l’insertion d’erreurs. L’utilisation massive de simulations fidèles et peu couteuses apparaissent.

1.3.2.2 La chaîne de l’erreur

Les faiblesses des méthodes de conception actuelles, qui mènent à la panne, sont en partie connues. Dans [Printz 1998], l’auteur nous rappelle l’origine des erreurs humaines dans les processus informatisés qui sont retrouvés en ingénierie système.

1.3. L’ingénierie des systèmes 23

En voici une sélection :

— Erreur de perception, manque de discrimination, distinction fond/forme et/ou sémantique/syntaxe

— Erreur de codage/décodage

— Erreur de représentation et/ou symbologie non adaptée (interopérabilité entre systèmes)

— Représentation, compréhension et interprétation erronées de phénomènes dy- namiques et/ou combinatoires

— Impasse, non-exhaustivité, oubli pur et simple — Acceptation comme vraie d’une hypothèse fausse — Acceptation comme fausse d’une hypothèse vraie — Attribution de propriétés inutiles et/ou erronées — Hypothèse superflue et/ou non appropriée

— Erreur de communication homme - homme, de traduction lors d’un change- ment de code (contre sens, faux sens, etc.)

— Non respect d’une procédure ou d’une règle — Non prise de décision en temps voulu

— Action non adaptée au contexte, action contradictoire et/ou antinomique vis à vis d’autres actions

— Itération, répétition inutile d’une action

— Absence d’information qui entraîne une action par défaut non adaptée — Erreur de raisonnement, raisonnement circulaire

— Défaut ou excès de généralité, abstraction mal construite, définition ambiguë — Confusion langage / métalangage, concept / méta-concept (mélange de types

au sens logique, ou équations de dimensions incohérentes en physique) — Analogies, associations erronées et/ou non adaptées au contexte

— Changement de tâche fréquent, « papillonnage » , toute perturbation qui augmente la probabilité de confusion et d’interférence

Auxquelles nous rajouterons des problèmes de méthodologie, facilitant l’insertion d’erreurs humaines :

— Multiplication des modèles d’un même système

— Absence d’historique des décisions (problème de traçabilité)

— Méthodes utilisées obsolètes au vu de la complexité des systèmes développés — Mauvaise traçabilité de l’exigence (modification de l’exigence non répercutée) — Mauvaise évaluation des délais de développement (pression sur les délais de

livraison)

— Extension d’exigences fonctionnelles/ nouveaux besoins — Mauvaise définition des interfaces

— Manque de retour d’expériences — Pari technologique utopique

— Augmentation du nombre de sous-traitants — Division des équipes de développement

24 Chapitre 1. Ingénierie des systèmes complexes et simulation

— Réutilisation de composants

— Mauvaise gestion de versions (modèle, logiciel) — Utilisation de patchs pour pallier les erreurs — ...

Loin d’être exhaustive, cette liste illustre quelques uns des vecteurs d’erreurs possibles en IS. Ces travaux de thèse chercheront à modérer certaines de ces erreurs dans le processus de modélisation de la simulation.

JF. Pradat-Peyre nous rappelle la chaine de l’erreur et l’apparition d’une panne dans Pratique Des Tests Logiciels [Pradat-Peyre 2009]. La figure1.7reprend le cycle de vie présenté en figure 1.4afin d’y associer les propos de l’auteur.

Conceptualisation Développement vers exploitationTransfert Exploitation Retrait

Erreur Humaine Introduction de défauts

Système comportant des défauts

Apparition possible de défaillance Panne

Figure 1.7 – La chaine de l’erreur

La figure 1.7 montre que l’apparition d’une erreur humaine3 va insérer un dé- faut dans le système. Il est important de noter que tout défaut n’engendre pas une défaillance. En effet, il n’est pas rare qu’un système fonctionne parfaitement malgré la présence d’erreurs en son sein. L’environnement n’amène tout simplement pas le système vers une zone défaillante. Le système pourra alors nous sembler robuste. Cette constatation explique pourquoi la réutilisation de composant doit être effec- tuée avec une grande prudence, même pour un composant connu pour avoir un fonctionnement parfait. En effet, le nouvel environnement peut mener le composant vers une zone de défaillance comme l’a montré le vol 501 (cf.1.3.2.1).

JF. Pradat-Peyre insiste sur la différence entre défaillance et panne. Une dé- faillance se traduit par un résultat inattendu (message non reçu, calculs erronés,etc.) mais le système peut continuer à fonctionner normalement. Ce fonctionnement nor- mal peut être dû au hasard ou à un dispositif de tolérance aux fautes. Une panne survient toujours après une défaillance. La panne a un caractère plus direct et mène le système en mode dégradé, le système perd certaines, voire l’ensemble, de ces fonc- tionnalités.

3. L’ergonome F. Vanderhaegen [Vanderhaegen 2003] donne un taux de 5 à 10 erreurs par heure d’activité effective.

1.3. L’ingénierie des systèmes 25

Au travers des exemples précédents, nous avons montré que les activités de V&V sont indispensables mais faillibles. Il existe effectivement un taux résiduel de défauts dans les systèmes.

Les métiers du logiciel nous fournissent une idée du taux d’erreur résiduel lors d’un développement logiciel par KLS4.(voir tableau1.1)

Logiciel Défaut résiduel

Grand public 5 à 10 par KLS

NASA : embarqué 0,1 par KLS (1400 KLS)

NASA : sol 0,5 par KLS (700 KLS)

Table 1.1 – Le taux de défaut résiduel par KLS (Source [Printz 2012]))

Les experts du domaine logiciel s’accordent à dire qu’un code source qui com- pile sans erreur et n’ayant subi aucune activité de V&V possède en moyenne 80 à 100 défauts par KLS. Après avoir passé l’ensemble des processus de V&V, le code possède en moyenne 1 à 2 défauts par KLS. Grâce à un processus de V&V plus développé, les logiciels critiques arrivent à un taux résiduel de 0,1 défaut par KLS. Il ne semble pas exister de chiffres spécifiques à l’IS, mais les données du domaine logiciel peuvent servir de base pour imaginer le taux de défauts résiduel présent dans un système complexe à la mise en exploitation. Il faut toutefois rester prudent sur l’utilisation de ces données, qui, pour la plupart, se basent sur des études faites au début des années 1990 ([Beizer 1990], [Cusumano 1995],[Boehm 1987]), époque qui peut être considérée comme le Moyen-âge en terme de méthodes logicielles.

Il existe un écart conséquent, en terme de défaut résiduel, entre un logiciel grand public, un logiciel sol et un logiciel embarqué. Cet écart provient de l’effort mis en place pour valider et vérifier le logiciel. Les critères de terminaison peuvent être très variés (nombre d’erreurs détectées, estimation type COCOMO, etc. ). Malgré cela, le principe reste le même. Plus le logiciel/système sera critique, plus l’effort sera important (voir figure 1.8). L’obtention d’un taux d’erreur résiduel nul (système parfait) demandera un effort infini.

Le travail de détection d’erreur représente selon les sources [Brooks Jr 1995, Paulish 2001,Printz 2013] 20 à 30 % du coup de développement, et passe à plus de 50% pour les parties critiques . L’activité de V&V représente alors plus de la moitié du temps de développement du système.

4. KLS pour Kilo Ligne Source, ce qui représente le nombre de milliers d’instructions que contient l’application.

26 Chapitre 1. Ingénierie des systèmes complexes et simulation Effort de V&V Système parfait (pas de défauts) Critère de terminaison Logiciel Grand Public Logiciel

Sol embarquéLogiciel

Défaults résiduels

Figure 1.8 – Défauts résiduels dans le logiciel

4444Capture4du4besoin44444444444444444Capture4des4exig ences444444444Phase4de4conception44444444Phase4de4réal isation44444444Phase4d'intégraiton4444Phase4de4validation

Coût4de4l'erreur

Figure 1.9 – Coût de l’erreur en fonction de la phase d’insertion (avec % d’insertion) et de la phase de détection.

En reprenant les phases du cycle en V (cf. 1.3.1.2), la figure 1.9 représente l’évolution du coût d’une erreur lors d’un projet en fonction de la phase d’insertion