Sûreté de

fonctionnement
Didier Buchs

11/22/07 ©Didier Buchs 1

Objectifs de la sûreté de
fonctionnement

Spécifier, concevoir, réaliser et exploiter

des systèmes où la faute est naturelle,
prévue et tolérable.

11/22/07 ©Didier Buchs 2

Concepts de base et terminologie

sûreté de fonctionnement = confiance justifiée

dans le service délivré

service = comportement perçu par ses

utilisateurs (humains ou matériels)

11/22/07 ©Didier Buchs 3

Attributs de la sûreté de
fonctionnement:
 Disponibilité (prêt à lʼutilisation)
 Fiabilité (continuité du service)
 Sécurité-innocuité (non-occurrence de défaillances
catastrophiques)
 Sécurité-confidentialité (manipulation non-autorisée
des informations)
 Intégrité (non-occurrence dʼaltérations inapropriées
de lʼinformation)
 Maintenabilité (facilité dʼentretenir et de réparer)

11/22/07 ©Didier Buchs 4

Terminologie des entraves à
la sûreté
défaillance (spécification non respectée,
déviation du service par rapport à la fonction)
spécification ou fonction (description du
service attendu)
erreur (état pouvant entraîner une
défaillance)
faute (cause dʼune erreur)

Faute -> erreur -> defaillance -> faute -> ….

11/22/07 ©Didier Buchs 5

Comment tenir compte de la
sûreté de fonctionnement ?
Méthode de développement destinées à:
la prévention des fautes
la tolérance aux fautes
lʼélimination des fautes
la prévision des fautes

Caractéristique principale: la combinaison de

ces techniques assure lʼobtention de la sûreté
de fonctionnement.

11/22/07 ©Didier Buchs 6

Quelques objectifs du génie
logiciel:

Augmentation de la sûreté de fonctionnement

de systèmes informatiques

Diminution des coûts de développement

11/22/07 ©Didier Buchs 7

exemple lié à la sécurité:
(Gilly-Bursinel, 3 mars 2000):

Regional
?

Direct Direct
arrêt 150m !!

11/22/07 ©Didier Buchs 8

Comment le génie logiciel
peut garantir la sécurité ?
Probabilités de défaillance nécessaires !
 10-9 pannes/heure (avion)
 10-11 pannes/heure (train)

Dans notre exemple: feux de signalisations

contrôlés par ordinateur.
 1.Modèle du système
 2.Recherche des cas critiques => élimination
 3.Modèle du programme
 4.Vérification des cas critiques et de la
conformance
11/22/07 ©Didier Buchs 9
Modèle du système
Sections dʼintérêt

11/22/07 ©Didier Buchs 10

Modèle du système
Transition = passage dʼune section à lʼautre
d2 m2 m1 d3 n2 d1 d4
n1

pm1__ m2
pm0__ GE,e m1 GE,e GE,e
GE,e pm2__
LS,e LS,e LS,e LS,e LS,e
m2
LS,e GE,e m1
LS,e
GE,e
d1 d1
d3
d3
LS,e GE,e

LS,e
pd1__ GE,e
Voie
LS,e GE,e pd2__
GE,e
d4 d4
d2 LS,e

LS,e GE,e d2
GE,e
LS,e
n1LS,e
pn0__ LS,e pn1__ LS,e n2 LS,e pn2__
GE,e n2 GE,e
GE,e GE,e GE,e
n1

11/22/07 ©Didier Buchs 11

Etudes des cas critiques du modèle
par énumération des situations.
{coopnDefaultContext[<gilly:{pm0LS_@1,pn2GE_@1},->]}
{coopnDefaultContext[<gilly:{pm0LS_@1,pn1GE_@4},->]}
(gilly.n2,-)
(gilly.m1,-)
(gilly.d1,-)
{coopnDefaultContext[<gilly:{pn0LS_@8,pn2GE_@1},->]}
(gilly.d4,-)
{coopnDefaultContext[<gilly:{pm1LS_@2,pn2GE_@1},->]}

{coopnDefaultContext[<gilly:{pd1LS_@3,pn2GE_@1},->]}

{coopnDefaultContext[<gilly:{pd1LS_@3,pn1GE_@7},->]}
(gilly.n2,-) (gilly.n1,-)
(gilly.m2,-) (gilly.n2,-)

{coopnDefaultContext[<gilly:{pm1LS_@2,pn1GE_@6},->]}

{coopnDefaultContext[<gilly:{pd1LS_@3,pn0GE_@9},->]}
(gilly.d4,-)
{coopnDefaultContext[<gilly:{pm2LS_@5,pn2GE_@1},->]}

{coopnDefaultContext[<gilly:{pn0LS_@10,pn1GE_@7},->]}

(gilly.n1,-)

{coopnDefaultContext[<gilly:{pn1GE_@7,pn1LS_@11},->]}

11/22/07 ©Didier Buchs 12

 Vérification de la sûreté
Propriété de sûreté du problème

$t¬#i " {1L n}nbtrainst (tronçoni ) ! 2

Enoncé de la propriété dans le modèle

( (
$M " A(R, M 0 ) ¬#i " {1L n}# M ( Ptronçoni ) ! 2 ) )
De telles situations existent dans ce modèle
=> introduction de feux de signalisations

11/22/07 ©Didier Buchs 13

 Propriétés attendue
 Modèle avec feux de signalisations:

 => vérification de la propriété précédente:

$t¬#i " {1L n}nbtrainst (tronçoni ) ! 2

si vérifiée => système est sûr !
11/22/07 ©Didier Buchs 14
Sûreté de fonctionnement
Disponibilité
Fiabilité
Attributs
Sécurité-innocuité
Sécurité-confidentialité
Prévention des fautes
Sûreté Tolérance aux fautes
de Moyens
fonctionnement Elimination des fautes
Prévision des fautes
Fautes

Entraves Erreurs

Défaillances

11/22/07 ©Didier Buchs 15

Quelles fautes peuvent survenir ?
Cause
phénoménologique
Nature
Fautes Phase de création
ou d!occurrence
Frontières du système
Fautes physiques
Fautes dues à l!homme
Fautes accidentelles
Fautes intentionnelles
sans volonté de nuire
Fautes intensionnellement
nuisible
Fautes de développement
Fautes opérationnelles
Fautes internes
Fautes externes

Fautes permanentes
Persistance
Fautes temporaires

11/22/07 ©Didier Buchs 16

Fautes dues à lʼhomme
 Fautes de conception

 Fautes dʼinteraction

 Logiques malignes

 Intrusions

11/22/07 ©Didier Buchs 17

Moyens pour la sûreté de
fonctionnement
la prévention des fautes

la tolérance aux fautes

lʼélimination des fautes

la prévision des fautes

11/22/07 ©Didier Buchs 18

Prévention des fautes

SADT

Méthodes ...
semi-formelles
Fusion
Prévention
des fautes CCS,CSP
Modèles ...
Réseaux de Petri
Logique temporelle
Méthodes formelles Propriétés ...
Types abstraits alg.
Z
Hybrides ...
Lotos

11/22/07 ©Didier Buchs 19

 Tolérance aux fautes

Détection d!erreurs

Traitement d!erreurs Diagnostic d!erreurs

Recouvrement d!erreurs
Tolérance
aux fautes
Diagnostic de fautes

Traitement de fautes Passivation

Reconfiguration

11/22/07 ©Didier Buchs 20

Elimination des fautes
Analyse statique

Statique Preuves

Analyse de comportement
Vérification
Exécution symbolique
Elimination Dynamique Conformité /
des fautes Recherche de fautes
Fonctionnel /
Diagnostic Structurel
Test
Correction Basé sur des fautes /
Selon des critères

Déterministes /
Aléatoires

11/22/07 ©Didier Buchs 21

Prévision des fautes

Evaluation ordinale

Prévision
des fautes
Fiabilité stabilisée

Evaluation probabiliste

Croissance de fiabilité

11/22/07 ©Didier Buchs 22

Diagramme du cours
Modèles de conception

Systèmes
classiques
Modèles
Formalisme
Développement de spécif.
Prévention
des fautes Propriétés
Tolérance Exécution symbolique
Génie Systèmes aux fautes
Elimination
logiciel sûrs
des fautes
Prévision
Gestion de projet des fautes
Fonctionnel
Interaction homme-système Test

11/22/07 ©Didier Buchs 23

Quelques catastrophes ! (tiré de
Wired magazine)
 Last month (sept 2005) automaker Toyota announced a recall of 160,000 of its Prius hybrid vehicles following
reports of vehicle warning lights illuminating for no reason, and cars' gasoline engines stalling unexpectedly. But
unlike the large-scale auto recalls of years past, the root of the Prius issue wasn't a hardware problem -- it was
a programming error in the smart car's embedded code. The Prius had a software bug.With that recall, the Prius
joined the ranks of the buggy computer -- a club that began in 1945 when engineers found a moth in Panel F,
Relay #70 of the Harvard Mark II system.1The computer was running a test of its multiplier and adder when the
engineers noticed something was wrong. The moth was trapped, removed and taped into the computer's
logbook with the words: "first actual case of a bug being found."･ Sixty years later, computer bugs are still with
us, and show no sign of going extinct. As the line between software and hardware blurs, coding errors are
increasingly playing tricks on our daily lives. Bugs don't just inhabit our operating systems and applications --
today they lurk within our cell phones and our pacemakers, our power plants and medical equipment. And now,
in our cars.But which are the worst?It's all too easy to come up with a list of bugs that have wreaked havoc. It's
harder to rate their severity. Which is worse -- a security vulnerability that's exploited by a computer worm to
shut down the internet for a few days or a typo that triggers a day-long crash of the nation's phone system? The
answer depends on whether you want to make a phone call or check your e-mail.Many people believe the worst
bugs are those that cause fatalities. To be sure, there haven't been many, but cases like the Therac-25 are
widely seen as warnings against the widespread deployment of software in safety critical applications. Experts
who study such systems, though, warn that even though the software might kill a few people, focusing on these
fatalities risks inhibiting the migration of technology into areas where smarter processing is sorely needed. In
the end, they say, the lack of software might kill more people than the inevitable bugs.What seems certain is
that bugs are here to stay. Here, in chronological order, is the Wired News list of the 10 worst software bugs of
all time ﾉ so far.
 July 28, 1962 -- Mariner I space probe. A bug in the flight software for the Mariner 1 causes the rocket to divert
from its intended path on launch. Mission control destroys the rocket over the Atlantic Ocean. The investigation
into the accident discovers that a formula written on paper in pencil was improperly transcribed into computer
code, causing the computer to miscalculate the rocket's trajectory.

11/22/07 ©Didier Buchs 24

 1982 -- Soviet gas pipeline. Operatives working for the Central Intelligence Agency allegedly
(.pdf) plant a bug in a Canadian computer system purchased to control the trans-Siberian gas
pipeline. The Soviets had obtained the system as part of a wide-ranging effort to covertly
purchase or steal sensitive U.S. technology. The CIA reportedly found out about the program
and decided to make it backfire with equipment that would pass Soviet inspection and then
fail once in operation. The resulting event is reportedly the largest non-nuclear explosion in
the planet's history.
 1985-1987 -- Therac-25 medical accelerator. A radiation therapy device malfunctions and delivers
lethal radiation doses at several medical facilities. Based upon a previous design, the Therac-
25 was an "improved" therapy system that could deliver two different kinds of radiation:
either a low-power electron beam (beta particles) or X-rays. The Therac-25's X-rays were
generated by smashing high-power electrons into a metal target positioned between the
electron gun and the patient. A second "improvement" was the replacement of the older
Therac-20's electromechanical safety interlocks with software control, a decision made
because software was perceived to be more reliable.What engineers didn't know was that
both the 20 and the 25 were built upon an operating system that had been kludged together
by a programmer with no formal training. Because of a subtle bug called a "race condition," a
quick-fingered typist could accidentally configure the Therac-25 so the electron beam would
fire in high-power mode but with the metal X-ray target out of position. At least five patients
die; others are seriously injured.

11/22/07 ©Didier Buchs 25

 1988 -- Buffer overflow in Berkeley Unix finger daemon. The first internet worm (the so-called
Morris Worm) infects between 2,000 and 6,000 computers in less than a day by taking
advantage of a buffer overflow. The specific code is a function in the standard input/output
library routine called gets() designed to get a line of text over the network. Unfortunately,
gets() has no provision to limit its input, and an overly large input allows the worm to take
over any machine to which it can connect.Programmers respond by attempting to stamp out
the gets() function in working code, but they refuse to remove it from the C programming
language's standard input/output library, where it remains to this day.
 1988-1996 -- Kerberos Random Number Generator. The authors of the Kerberos security system
neglect to properly "seed" the program's random number generator with a truly random
seed. As a result, for eight years it is possible to trivially break into any computer that relies
on Kerberos for authentication. It is unknown if this bug was ever actually exploited.
 January 15, 1990 -- AT&T Network Outage. A bug in a new release of the software that controls
AT&T's #4ESS long distance switches causes these mammoth computers to crash when they
receive a specific message from one of their neighboring machines -- a message that the
neighbors send out when they recover from a crash.One day a switch in New York crashes
and reboots, causing its neighboring switches to crash, then their neighbors' neighbors, and
so on. Soon, 114 switches are crashing and rebooting every six seconds, leaving an
estimated 60 thousand people without long distance service for nine hours. The fix: engineers
load the previous software release.
 1993 -- Intel Pentium floating point divide. A silicon error causes Intel's highly promoted Pentium
chip to make mistakes when dividing floating-point numbers that occur within a specific range.
For example, dividing 4195835.0/3145727.0 yields 1.33374 instead of 1.33382, an error of
0.006 percent. Although the bug affects few users, it becomes a public relations nightmare.
With an estimated 3 million to 5 million defective chips in circulation, at first Intel only offers
to replace Pentium chips for consumers who can prove that they need high accuracy;
eventually the company relents and agrees to replace the chips for anyone who complains.
The bug ultimately costs Intel $475 million.
11/22/07 ©Didier Buchs 26
Catastrophes (suite)

 1995/1996 -- The Ping of Death. A lack of sanity checks and error handling in the IP
fragmentation reassembly code makes it possible to crash a wide variety of operating systems
by sending a malformed "ping" packet from anywhere on the internet. Most obviously
affected are computers running Windows, which lock up and display the so-called "blue
screen of death" when they receive these packets. But the attack also affects many Macintosh
and Unix systems as well.
 June 4, 1996 -- Ariane 5 Flight 501. Working code for the Ariane 4 rocket is reused in the Ariane
5, but the Ariane 5's faster engines trigger a bug in an arithmetic routine inside the rocket's
flight computer. The error is in the code that converts a 64-bit floating-point number to a 16-
bit signed integer. The faster engines cause the 64-bit numbers to be larger in the Ariane 5
than in the Ariane 4, triggering an overflow condition that results in the flight computer
crashing.First Flight 501's backup computer crashes, followed 0.05 seconds later by a crash
of the primary computer. As a result of these crashed computers, the rocket's primary
processor overpowers the rocket's engines and causes the rocket to disintegrate 40 seconds
after launch.
 November 2000 -- National Cancer Institute, Panama City. In a series of accidents, therapy
planning software created by Multidata Systems International, a U.S. firm, miscalculates the
proper dosage of radiation for patients undergoing radiation therapy.Multidata's software
allows a radiation therapist to draw on a computer screen the placement of metal shields
called "blocks" designed to protect healthy tissue from the radiation. But the software will
only allow technicians to use four shielding blocks, and the Panamanian doctors wish to use
five.The doctors discover that they can trick the software by drawing all five blocks as a
single large block with a hole in the middle. What the doctors don't realize is that the Multidata
software gives different answers in this configuration depending on how the hole is drawn:
draw it in one direction and the correct dose is calculated, draw in another direction and the
software recommends twice the necessary exposure.At least eight patients die, while another
20 receive overdoses likely to cause significant health problems. The physicians, who were
legally required to double-check the computer's calculations by hand, are indicted for murder.
11/22/07 ©Didier Buchs 27
Un exemple concret de catastrophe:
Ariane 501

Référence: Rapport de la commission dʼinspection (J.L. Lions

chairman) 19 juillet 1996.
 Cahier des charges de la commission:
 Déterminer les causes de lʼéchec du lancement
 Critiquer les procédures de test de qualification et
dʼacceptation
 Déterminer les moyens pour remédier à ce problème et
éventuellement en découvrir dʼautres.

11/22/07 ©Didier Buchs 28

Scénario de la catastrophe

Le lancement: (4 juin 1996, Kourou)

4000m

H0+37!!

report du lancement

H0!-7!
H0!=8h35! H0 = 9h33!59!!

11/22/07 ©Didier Buchs 29

Configuration du système
Inertial Platform

SRI1 SRI2 Inertial Reference System

OBC OBC On Board Computer

Vulcan and solid booster engines nozzles

Nozzles

11/22/07 ©Didier Buchs 30

Caractéristiques principales
du système
Haut degré de duplication des composants
pour augmenter la fiabilité
Lʼaltitude et les déplacements spaciaux sont
mesurés par les SRI.
Les deux SRI ont même soft et hard et
opèrent en parallèle
Un SRI est actif tandis que lʼautre est en
attente active
En cas de problème dʼun SRI lʼautre est
employé immédiatement à sa place.

11/22/07 ©Didier Buchs 31

Caractéristiques principales
du système (suite)
Les SRI de Ariane 5 sont identiques aux SRI
de Ariane 4
Il y a deux OBC, dont un est actif et lʼautre est
de secours
Les données des SRI sont transmises au
OBC par lʼintermédiaire dʼun bus de données
LʼOBC contrôle les déviateurs de jets
(nozzles) par lʼintermédiaire dʼactuateurs et
de servo-valves.

11/22/07 ©Didier Buchs 32

Un exemple concret de catastrophe: Ariane 501
Erreur
Erreur conv. 32 bit -> 16bit
Levée d’exception
Message err. sur le bus
Changement de
SRI impossible
Faute
Faute de spécification
SRI Ariane 4 -> Ariane 5
réutilisation erronée
SRI1 SRI2 Platforme à inertie
Faute de conception du
traitement des erreurs
logicielles
OBC OBC Ordinateur de bord

Envoi valeur incorrecte Faute de programmation

à l’actuateur des conversions

Déviateur de jet propulseur

Déviation complète jet
Faute au test
11/22/07 ©Didier Buchs
d‘intégration 33
Autodestruction
Suite des événements (vers le passé)
 Désintégration du lanceur à H0 + 39s (charge aérodynamique trop
importante à cause de lʼangle de 20 degré pris par la fusée)
 Angle dʼattaque causée par une déflection complète des déviateurs de
jets.
 La déflection a été commandée par lʼOBC sur la base de données
transmises par le SRI actif (SRI2). Ces données ne contenaient pas de
données de vol correctes. Il sʼagissait en fait de motifs de diagnostique
du SRI 2, qui ont été interprétés comme données de vol.
 SRI2 fournit des informations éronnées car lʼunité déclare une erreur
due à une exception logiciel.
LʼOBC ne peut commuter le SRI2 sur le SRI1 car le SRI1 a cessé de
fonctionner pour la même raison que SRI2 lors du cycle précédant.

11/22/07 ©Didier Buchs 34

Suite de la suite des événements
 Lʼexception logiciel du SRI a été causée par une
conversion 64 bits FP -> 16 bits Signed Integer hors
représentation possible. Lʼexception est une erreur
dʼopérande. Lʼinstruction de conversion (Ada) nʼétait pas
protégée (bien que dʼautres instructions le fussent).
 Lʼerreur cʼest produite dans une portion de code qui ne
sert quʼau réglage de la plate-forme à inertie. Durant le
décollage cette fonction ne sert à rien.
 La fonction de réglage est opérationnelle pour 50
secondes après le démarrage du mode de vol des SRI
qui a lieu à H0-3s pour Ariane 5. Cette fonction est donc
opérationnelle pendant env. 40s durant le vol (cʼest une
spécification de Ariane 4 et non de Ariane 5).
11/22/07 ©Didier Buchs 35
Suite de la suite des événements (bis)
Lʼerreur dʼopérande sʼest produite à cause
dʼune valeur particulièrement élevée de la
fonction dʼajustement appelée BH (Horizontal
Bias), correspondant à la vitesse horizontale
ressentie par la plate-forme. Cette valeur
nʼétait pas la même pour Ariane 5 que pour
Ariane 4 étant donné la différence de leur
trajectoire.

11/22/07 ©Didier Buchs 36

Résumé de Ariane 501
Erreur
Erreur conv. 32 bit -> 16bit
Levée d’exception
Message err. sur le bus
Changement de
SRI impossible
Faute
Faute de spécification
SRI Ariane 4 -> Ariane 5
réutilisation erronée
SRI1 SRI2 Platforme à inertie
Faute de conception du
traitement des erreurs
logicielles
OBC OBC Ordinateur de bord

Envoi valeur incorrecte Faute de programmation

à l’actuateur des conversions

Déviateur de jet propulseur

Déviation complète jet
Faute au test
11/22/07 ©Didier Buchs
d‘intégration 37

Autodestruction
Commentaires
Cause technique de la catastrophe
Choix technologiques de conception de la
gestion dʼerreurs
Choix technologiques de conception de la
procédure de recalage

11/22/07 ©Didier Buchs 38

 Cause technique de la catastrophe:
 manque de protection des opérations de conversion, ce qui a causé lʼarrêt
de lʼordinateur du SRI.
 Choix technologiques de programmation: Toutes les conversions nʼétaient
pas protégées, car ces activités ne devaient pas imposer une surcharge en
temps de plus de 80%.
 Le choix des variables à protéger a été motivé pour 7 variables, mais
finalement pour des raisons obscures seulement 4 variables ont été
protégées.
 Une des raisons de ne pas protéger ces trois variables sʼexplique par les
limites physiques où les marges de sécurité très larges (ce qui était un
raisonnement erroné pour BH).
 Ces choix ont été faits dʼun commun accord entre les partenaires du projet.
 Il nʼy a pas de preuve que des données de la trajectoire aient été utilisées
pour analyser le comportement de ces variables et quʼil ait été
conjointement admis de ne pas inclure les données de la trajectoire
dʼAriane 5 dans le cahier des charges du SRI.
11/22/07 ©Didier Buchs 39
Choix technologiques de
conception de la gestion dʼerreurs:
 La mission nʼa pas échoué pour cette erreur
uniquement. La spécification du système de gestion
dʼexceptions a été lui-même une cause de lʼéchec.
 Celle-ci dit quʼen cas dʼexception le système doit indiquer
sur le bus cet échec et le stocker sur une EEPROM (qui a
été retrouvée pour Ariane 501).
 Finalement le SRI doit être stoppé.
 Cʼest donc lʼarrêt du SRI qui a été fatal. La raison de
ce choix est que ces exceptions sont censées refléter
un problème hardware, ce qui dans ce cas est
raisonnable puisque le système de sauvegarde doit
alors entrer en service.

11/22/07 ©Didier Buchs 40

suite
 Il est clair que malgré lʼerreur flagrante de conception
logiciel, des mécanismes peuvent être introduits pour
atténuer ce genre de problèmes.
 Le SRI aurait pu continuer à fournir sa meilleure
estimation des informations nécessaires.
 On devrait se préoccuper de vérifier quʼune exception
logiciel ne cause pas un arrêt du processeur dans les
équipements critiques. La perte dʼune fonction
logiciel est dangereuse car le même logiciel est
utilisé dans les deux SRI.

11/22/07 ©Didier Buchs 41

Choix technologiques de conception
de la procédure de recalage:
 La raison de la poursuite de la procédure de recalage
après le décollage est due à des choix anciens de la
gamme Ariane.
 Les choix ont été faits en particulier en raison de
report de lancement, ceci permet tout juste un
décalage de la fenêtre de tir sans recommencer toute
la longue procédure de réinitiallisation.
 Ces principes nʼont pas vraiment de raison dʼêtre
pour Ariane 5 qui a adopté dʼautres procédures
dʼinitialisation.
 Cette procédure nʼa également pas de raison dʼêtre
puisque, par principe, lʼajustement est une opération
qui doit être faite lorsque la fusée est immobilisée.
11/22/07 ©Didier Buchs 42
Commentaires généraux
 La commission souligne le fait quʼune défaillance
logiciel est dʼune nature très différente de celle dʼune
défaillance matérielle. Le logiciel est flexible et
expressif et peut répondre à un cahier des charges
très complexes mais en contre-partie conduit à des
réalisations complexes qui sont difficiles à certifier.
 Le point de vue pris lors de la conception du système
est quʼun logiciel doit être considéré comme correct
jusquʼà ce quʼil soit en faute. La commission propose
le contraire, le logiciel doit être supposé erroné
jusquʼà ce que lʼapplication de la meilleure méthode
connue ait démontré quʼil est correct. => principe de
sûreté

11/22/07 ©Didier Buchs 43

Procédure de test et de
qualification
Procédure de qualification du système de vol:

 Qualification des équipements

 Qualification du logiciel (logiciel embarqué)

 Intégration dʼétages

11/22/07 ©Didier Buchs 44

test de validation du système
 Le test du SRI comme boite noire est impossible pour
des raisons physiques, uniquement lʼinjection de
données des accéléromètres correspondantes à la
trajectoire de vol est possible.
 Ces tests nʼont pas été effectués à cause de lʼabsence
des données de vol dʼAriane 5 dans le cahier des
charges.
 La spécification des SRI nʼinclut pas de restrictions
opérationnelles liées à des choix dʼimplémentation. De
telles déclarations de limitation, qui doivent être
obligatoires pour chaque élément critique de la mission,
auraient pu servir à découvrir que le système nʼétait
pas compatible avec la trajectoire de Ariane 5.
11/22/07 ©Didier Buchs 45
test de validation du système
 Une phase complète de test par simulation a été
développée pour détecter les problèmes généraux de
vol (diverses trajectoires acceptables, pannes des
équipements et procédures de récupération, ...). De
nombreux équipements étaient intégrés
physiquement lors de ce test. Les deux SRI ne
lʼétaient pas et étaient remplacés par des modules
logiciels.
 Les tests dʼintégration des SRI nʼétaient à ce niveau
que de simples tests des capacités électriques et de
transmission du bus de données.

11/22/07 ©Didier Buchs 46

test de validation du système
 Le choix de ne pas intégrer les SRI dans la boucle de
test était du à la complexité de cette tache. Des
considérations de précision des équipements de test
ont également conduit à remplacer les SRI par des
simulations logiciels (la précision dans ce test nʼétait
pas le point crucial).
 La commission souligne que lʼobjectif à ce niveau de
test dʼintégration nʼest pas seulement de vérifier les
interfaces mais aussi de voir que tous les
composants fonctionnent bien ensemble. Il était très
risqué de penser que le bon fonctionnement dʼ Ariane
4, suffisait pour se passer de test dʼintégration pour
Ariane 5.

11/22/07 ©Didier Buchs 47

Recommandations de la
commission
 R1: La fonction dʼajustement doit-être coupée dès le décollage.
 R2: Préparer des moyens de test plus réalistes, injecter des
données réalistes et réaliser un test en boucle fermée complet.
Une simulation complète doit être faite avant chaque mission.
Augmenter la couverture de test.
 R3: Ne pas autorisé quʼun quelconque capteur arrête dʼenvoyer
ses données.
 R4: Organiser pour chaque système incluant du logiciel une
procédure de qualification. Fournir des informations claires sur
les restrictions dʼutilisation.
 R5: Revoir chaque logiciel de vol et en particulier:
 Identifier chaque supposition impliquée par le code
 Vérifier les valeurs que peuvent prendre les variables des logiciels
 R6: Partout ou cela est possible, nʼutiliser les exceptions que
pour les fonctionnalités de sauvegarde.
11/22/07 ©Didier Buchs 48
 Suite
 R7: Fournir plus de données à la télémétrie pour la panne de chaque
composant, ainsi les équipements de sauv. dʼinf. seront moins essentiels.
 R8: Reconsidérer les composants critiques, inclure les fautes du logiciel.
 R9: Inclure des personnes extérieures au projet pour les tests.
 R10: Inclure les données de trajectoire dans les spécifications
 R11:Revoir la couverture de test
 R12: Même soin aux doc. de justification du code quʼau code lui-même.
 R13: Etablir une équipe qui prépare la procédure de qualification, établir
des règles claires qui assurent cette qualification par des procédures de
haute qualité de spécification, vérification et test du logiciel.
 R14: Augmenter la clarté de lʼorganisation de la coopération entre les
partenaires du projet Ariane 5, établir des contacts entre ingénieurs qui
sʼaffranchissent des aspects hiérarchiques.

11/22/07 ©Didier Buchs 49

Remarques finales:
 Une série de fautes de gestion du projet ont conduit à
la catastrophe:
 Erreurs logiciels mal prises en compte dans la
réalisation du système.
 Limites de lʼimplémentation mal fixées, confusion
entre les spécifications de Ariane 4 et 5.
 Test dʼintégration incorrect

 Réutilisation mal réussie car:

 Spécification mal établie
 Limites de lʼimplémentation mal définie
 Tests trop limités

11/22/07 ©Didier Buchs 50