L’étude des différents éléments de solution mis en œuvre aujourd’hui pour combattre la «

crise du logiciel » est au cœur du présent ouvrage.

Pour la phase en amont du développement logiciel, cela recouvre pour l’essentiel quatre
approches complémentaires qui seront étudiées en détail dans la suite de l’ouvrage.

(1) Le recueil des besoins avec les clients et utilisateurs et leur expression initiale à
travers des formes d’expression adaptées.

(2) L’analyse approfondie des besoins à l’aide de langages de modélisation, souvent

visuels, comme UML.

(3) La manière de gérer les développements. L’étude du Standish Group, déjà citée,
montre que la loi de Pareto du 20/80 est en gros respectée pour le logiciel, avec 20 %
des fonctionnalités implantées qui sont toujours (7 %) ou souvent (13 %) utilisées et
80 % des fonctionnalités implantées qui sont parfois (16%), rarement (19%) ou
jamais (45%) utilisées. Il est donc très important et rentable de cibler les
développements en priorité sur les fonctionnalités que l’on pense les plus utiles ou
les plus critiques. D’où le fort développement des méthodes itératives et agiles.

(4) Les bonnes pratiques pour la qualité, comme les revues et inspections ou le
développement dirigé par les tests.

EXERCICES

Exercice 1.1. Donnée, information, connaissance.

a) Rappeler la différence entre donnée, information et connaissance.

b) Donner un exemple de représentation explicite de connaissance en machine.

Exercice 1.2. Système informatique temps réel.

Quelle est la meilleure caractérisation d’un système temps réel parmi les deux suivantes ?

(1) Un système rapide.

(2) Un système prévisible.

Exercice 1.3. Cloud privé.

Comment définir le concept de « cloud privé » ?

Exercice 1.4. Caractérisation des services sur le cloud.

Dans le tableau suivant, indiquer par des croix les ressources (lignes du tableau) qui sont
fournies dans les différents types de services (colonnes du tableau).
IAAS PAAS SAAS
Données
Applications
Systèmes

15
 Machines
virtuelles
Serveurs
Stockage
Réseau

Exercice 1.5. Internet des objets et « ville intelligente ».

Derrière le concept de « ville intelligente » (smart city), on trouve la technologie des réseaux
sans fil de capteurs intelligents, au service d’une meilleure gestion de la ville.

Donner des exemples d’application de cette technologie, où les capteurs intelligents sont
intégrés à des objets urbains.

Exercice 1.6. Les défaillances logicielles de systèmes complexes

Lire l’extrait suivant du communiqué officiel expliquant la désintégration de la première

fusée Ariane 5. Analyser la cascade d’erreurs commise et l’inefficacité des mesures de
sécurité.

Communiqué de presse conjoint ESA-CNES

Paris, le 19 juillet 1996

Rapport de la Commission d’enquête Ariane 501

Echec du vol Ariane 5O1

Président de la Commission : Professeur J.-L. LIONS

Avant-propos
1. L’échec
1. Description générale
2. Informations disponibles
3. Récupération des débris
4. Autres anomalies observées sans rapport avec l’accident
2. Analyse de l’échec
1. Séquence des événements techniques
2. Commentaires du scénario de défaillance
3. Procédures d’essai et de qualification
4. Autres faiblesses éventuelles des systèmes incriminés
3. Conclusions
1. Résultats de l’enquête
2. Cause de l’accident
4. Recommandations
(...)

2. ANALYSE DE LÉCHEC
2.1. SEQUENCE DES EVENEMENTS TECHNIQUES

16
De manière générale la chaîne de pilotage d’Ariane 5 repose sur un concept standard. L’attitude du
lanceur et ses mouvements sont mesurés par un système de référence inertielle (SRI) dont le
calculateur interne calcule les angles et les vitesses sur la base d’informations provenant d’une plate-
forme inertielle à composants liés, avec gyrolasers et accéléromètres. Les données du SRI sont
transmises via le bus de données, au calculateur embarqué (OBC) qui exécute le programme de vol et
qui commande les tuyères des étages d’accélération à poudre et du moteur cryotechnique Vulcain,
par l’intermédiaire de servovalves et de vérins hydrauliques.

Pour améliorer la fiabilité, on a prévu une importante redondance au niveau des équipements. On
compte deux SRI travaillant en parallèle; ces systèmes sont identiques tant sur le plan du matériel que
sur celui du logiciel. L’un est actif et l’autre est en mode "veille active"; si l’OBC détecte que le SRI actif
est en panne, il passe immédiatement sur l’autre SRI à condition que ce dernier fonctionne
correctement. De même on compte deux OBC et un certain nombre d’autres unités de la chaîne de
pilotage qui sont également dupliquées.

La conception du SRI d’Ariane 5 est pratiquement la même que celle d’un SRI qui est actuellement
utilisé à bord d’Ariane 4, notamment pour ce qui est du logiciel.

Sur la base de la documentation et des données exhaustives relatives à l’échec d’Ariane 501 qui ont
été mises à la disposition de la Commission, on a pu établir la séquence suivante d’événements ainsi
que leurs interdépendances et leurs origines, depuis la destruction du lanceur jusqu’à la cause
principale en remontant dans le temps.

Le lanceur a commencé à se désintégrer à environ HO + 39 secondes sous l’effet de charges

aérodynamiques élevées dues à un angle d’attaque de plus de 20 degrés qui a provoqué la séparation
des étages d’accélération à poudre de l’étage principal, événement qui a déclenché à son tour le
système d’auto destruction du lanceur.

Cet angle d’attaque avait pour origine le braquage en butée des tuyères des moteurs à propergols
solides et du moteur principal Vulcain; le braquage des tuyères a été commandé par le logiciel du
calculateur de bord (OBC) agissant sur la base des données transmises par le système de référence
inertielle actif (SRI2). A cet instant, une partie de ces données ne contenait pas des données du vol
proprement dites mais affichait un profil de bit spécifique de la panne du calculateur du SRI2 qui a été
interprété comme étant des données de vol.

La raison pour laquelle le SRI2 actif n’a pas transmis des données d’attitude correctes tient au fait que
l’unité avait déclaré une panne due à une exception logicielle.

L’OBC n’a pas pu basculer sur le SRI1 de secours car cette unité avait déjà cessé de fonctionner durant
le précédent cycle de données (période de 72 millisecondes) pour la même raison que le SRI2.

L’exception logicielle interne du SRI s’est produite pendant une conversion de données de
représentation flottante à 64 bits en valeurs entières à 16 bits. Le nombre en représentation flottante
qui a été converti avait une valeur qui était supérieure à ce que pouvait exprimer un nombre entier à
16 bits. Il en est résulté une erreur d’opérande. Les instructions de conversion de données (en code
Ada) n’étaient pas protégées contre le déclenchement d’une erreur d’opérande bien que d’autres
conversions de variables comparables présentes à la même place dans le code aient été protégées.

17
L’erreur s’est produite dans une partie du logiciel qui n’assure que l’alignement de la plate-forme
inertielle à composants liés. Ce module de logiciel calcule des résultats significatifs avant le décollage
seulement. Dès que le lanceur décolle, cette fonction n’est plus d’aucune utilité.

La fonction d’alignement est active pendant 50 secondes après le démarrage du mode vol des SRI qui
se produit à HO - 3 secondes pour Ariane 5. En conséquence, lorsque le décollage a eu lieu, cette
fonction se poursuit pendant environ 40 secondes de vol. Cette séquence est une exigence Ariane 4
mais n’est pas demandé sur Ariane 5.

L’erreur d’opérande s’est produite sous l’effet d’une valeur élevée non prévue d’un résultat de la
fonction d’alignement interne appelé BH (Biais Horizontal) et lié à la vitesse horizontale détectée par
la plate-forme. Le calcul de cette valeur sert d’indicateur pour la précision de l’alignement en fonction
du temps.

La valeur BH était nettement plus élevée que la valeur escomptée car la première partie de la
trajectoire d’Ariane 5 diffère de celle d’Ariane 4, ce qui se traduit par des valeurs de vitesse
horizontale considérablement supérieures.

Les événements internes du SRI qui ont conduit à l’accident ont été reproduits par simulation. En
outre, les deux SRI ont été récupérés pendant l’enquête de la Commission et le contexte de l’accident
a été déterminé avec précision à partir de la lecture des mémoires. De plus, la Commission a examiné
le code logiciel qui s’est avéré correspondre au scénario de l’échec. Les résultats de ces examens sont
exposés dans le Rapport technique.

On peut donc raisonnablement affirmer que la séquence d’événements ci-dessus traduit les causes
techniques de l’échec d’Ariane 501.

Exercice 1.7. Les courbes de défaillance du matériel et du logiciel

Commenter les courbes suivantes, tirées de [Pre09], qui donnent l’évolution au cours du
temps du nombre de défaillances respectivement du matériel et du logiciel.

18
Exercice 1.8. La diversité des applications

Donner les principales qualités attendues :

a) d’un site de commerce électronique,
b) d’un système temps réel (par exemple de guidage au sol d’une fusée),
c) d’un système embarqué (par exemple de contrôle du freinage d’une voiture).

Exercice 1.9. The mythical man-month

L’homme-mois est souvent utilisé comme unité de mesure de l’effort de développement.

Frederick Brooks a critiqué cette unité dans son ouvrage The mythical Man-Month [Bro75].
L’hypothèse qu’un homme pendant deux mois équivaut à deux hommes pendant un mois, les
deux valant deux hommes-mois, est le plus souvent fausse. Expliquer pourquoi en
commentant les figures suivantes.

19