sûreté de fonctionnement du logiciel

Cours d’analyse des risques© ALL4TEC 2011 1
FIABILITE ET AMDEC
DES LOGICIELS

Plan du cours
1 - Principes de sûreté de fonctionnement des logiciels
2 - Fiabilité du logiciel
3 - AMDEC du logiciel
4 – Démonstrations et exercices

1 - PRINCIPES DE SÛRETÉ DE
FONCTIONNEMENT DES LOGICIELS
1.1 Spécificités des logiciels
1.2 Construction de la sûreté de fonctionnement des
logiciels
1.3 Les outils de la sûreté de fonctionnement des
logiciels

1.1 - Spécificités des logiciels
 Les systèmes programmés tiennent une place de plus en
plus importante dans le monde moderne
 Les industriels rencontrent des difficultés croissantes
dans la réalisation et la validation de ces systèmes
– Complexité croissante
– Imbrication des logiciels et dispersion de la criticité
– Utilisation de COTS (Components Off-The-Shelf)

F M D S
F M D S
F M D S
F M D S
F M D S
F M D S
F M D S
F M D S
F M D S
F M D S
F M D S
F M D S
F M D S
Durée de remise en service ..................................................
Probabilité de succès de mission ........................................
Taux de détection des défaillances ......................................
Contraintes de procédures ....................................................
Nombre et nature des barrières indépendantes ..................
MTBF et/ou MTTF ...................................................................
Contraintes de conception.....................................................
Taux de fausses alarmes .......................................................
Taux de localisation des défaillances ..................................
Niveau d’interchangeabilité ...................................................
Capacité de reconfiguration ..................................................
Probabilité d'occurrence d'événements critiques ...............
Pérennité des composants ....................................................
Exigences de SdF pour les logiciels
Fiabilité Maintenabilité Disponibilité Sécurité ?

Principes généraux
 Dès le début du projet il faut prendre des dispositions
pour traiter les risques identifiés
 Entre l'expression des besoins et le code binaire
exécutable, le logiciel passe par une série d'étapes de
plus en plus abstraites
 Il faut faire la démonstration que les risques résiduels
sont acceptables
 La maîtrise de la SdF du logiciel passe par la maîtrise de
son processus de production

1.2 - Construction de la SdF des
logiciels
 On parle bien de CONSTRUCTION :
– Il faut impérativement prendre en compte la SdF dès les
premières phases de réalisation du système
– Il faut savoir le justifier
– Il faut être capable de “recoller les morceaux”
• le logiciel passe par plusieurs “états”
• problème général de la traçabilité
 Via la mise en place de :
– concepts
– méthodes
– outils
– techniques

Principales actions en construction (1/2)
Évitement
des fautes
Élimination
des fautes
Tolérance
aux fautes
Prévision
des fautes

Principales actions en construction (2/2)
Évitement des fautes - Tolérance aux fautes - Elimination des fautes - Prévision des fautes ?
Obtention, par construction, d’un système
robuste et de qualité, afin d’empêcher
l’occurrence de fautes
Spécification ou conception d’un système qui
sera capable de fonctionner correctement en
présence de fautes, éventuellement de façon
dégradée
Suppression des fautes résiduelles avant la
mise en service et vérification de l’absence de
ces fautes
Analyse et positionnement des
caractéristiques de SdF du système, au regard
des exigences exprimées par le client

1.3 - Les outils de la SdF du logiciel
 Le logiciel fonctionne dans un système
 Le système est un tout …
 … mais sa sûreté de fonctionnement dépend d’autres
constituants que le logiciel :
– Matériel
– Hommes
– Procédures

La SdF du logiciel dans le système
 La sûreté de fonctionnement du logiciel est totalement
liée au système dans lequel celui-ci est intégré
 Elle hérite du contexte (utilisation ou mission,
environnement, contraintes) de ce dernier et du résultat
des analyses système
 Elle poursuit ces analyses dans le contexte du logiciel

Incidence du logiciel
sur la SdF du système
 Le logiciel contribue à la réalisation des
traitements de sûreté
– Certains traitements nécessaires aux fonctions de sûreté ne
sont réalisables que par logiciel
 Le logiciel contribue à la sûreté du matériel
– Fonctions de détection des pannes du matériel (réduction du l
système non sûr) par auto tests et par tests périodiques
Mais … le logiciel contribue aux défaillances du
système
– Erreurs résiduelles dans le logiciel en exploitation
– Une erreur résiduelle activée peut entraîner une défaillance du
système
Incidence
négative
Incidence
positive
Incidence
positive

Défaillances logiciel
et défaillances système
défaillance
système
défaillance
matériel
défaillance
logiciel
non
robustesse
défaillance
matériel
défaut de
conception= intervention humaine

Méthodes et outils de SdF du système
 Identification du besoin
– Analyse Préliminaire des Risques (APR)
 Modélisations
– Fonctionnelles : statiques et dynamiques, formelles ...
– Spécifiques SdF : Blocs diagrammes de fiabilité, graphes de
Markov …
à des fins d’allocations d'objectifs de fiabilité ou de criticité, de
taux de détection ...
 Règles et procédures d'analyse
– Règles SdF de conception, d'approvisionnement et de fabrication
– Procédures d'homogénéisation des activités de SdF des sous-
ensembles:
• Cohérence des objectifs et des contraintes
• Cohérence des méthodes et des référentiels d'analyses

Méthodes et outils de SdF du logiciel
 AMDEC du logiciel et AEEL
– Caractérisation de conséquences des
défauts
– Caractérisation des modules critiques
 Evaluation de fiabilité
– Modèles de croissance de fiabilité :
• En phase de validation
• En phase d'exploitation

2 - FIABILITE DU LOGICIEL
2.1 Un besoin industriel
2.2 Fiabilité et qualité
2.3 La théorie en fiabilité expérimentale
2.4 Les processus de collecte et d'étude
2.5 Le processus d'étude de fiabilité expérimentale
2.6 Conclusion

2.1 - Un besoin industriel
– Les calculs sont précis ......................................................
– la maintenance du logiciel est aisée ................................
– le logiciel tolère les pannes de matériel ..........................
– le logiciel fait ce que le client en attend ..........................
– le logiciel est facile à utiliser ............................................
– le logiciel n'a pas souvent de panne ...............................
– le logiciel est rapide ..........................................................
– le logiciel est bien protégé ...............................................
– le logiciel fonctionne comme il faut, quand il faut .........
– la maintenance n'est pas excessive pour le client ........











Les définitions de la fiabilité du logiciel
Qualité
Taux de
défaillance
Conformité
Idem matériel
Robustesse
Satisfaction
du client

Les définitions de la fiabilité du logiciel
 La caractéristique de fiabilité
Aptitude d'un programme à accomplir l'ensemble des fonctions spécifiées
dans un document de référence, dans un environnement opérationnel, et
pour une durée d'utilisation donnée.
 La fiabilité mathématique
Probabilité qu'a un programme d'accomplir l'ensemble des fonctions
spécifiées dans un document de référence, dans un environnement
opérationnel, et pour une durée d'utilisation donnée.
niveau de confiance de l'utilisateur
dans l'obtention du service demandé

Fiabilité du logiciel pour qui ?
 Le fabricant ....................................................................
 Le client ..........................................................................
 L'utilisateur ....................................................................

Le fabricant
 Mesurer la fiabilité
– planifier et contrôler les activités de test
– autoriser des évolutions sans perturbations
– évaluer, valider, qualifier
 Améliorer la fiabilité
– évaluer les méthodes
– diminuer les coûts de maintenance
– améliorer la communication avec le client et l'utilisateur
 Extrapoler
– prendre des décisions efficaces au bon moment
– améliorer la productivité
– faire des évaluations préalables

Le client
– avoir des exigences quantifiées et vérifiables
– contracter des clauses de fiabilité
– évaluer le fabricant
– créer le dialogue avec le fabricant et l'utilisateur
– demander des évolutions
– diminuer les coûts de maintenance
– améliorer l'efficacité
 Extrapoler
– préparer les utilisateurs
– mettre en place les moyens

L'utilisateur
– vérifier les performances
– créer le dialogue avec le client et le fabricant
– demander des évolutions
– améliorer l'efficacité
– travailler dans la sérénité
 Extrapoler
– s'organiser
– gérer les risques

Maîtriser
 évaluer
 contrôler
 prévoir
 améliorer

Maîtriser ?
comparer les résultats avec les spécifications .......................
calculer le temps pour finir le test .........................................
calculer les besoins en maintenance ......................................
réécrire un programme trop complexe ....................................
calculer le nombre de défauts par ligne de code .....................
renforcer les équipes de test ..................................................
faire des inspections de code .................................................
faire du test structurel complet ...............................................
calculer la fiabilité obtenue en fin de test ...............................
passer de l'assembleur à un langage de plus haut niveau ....
E C P A
E C P A
E C P A
E C P A
E C P A
E C P A
E C P A
E C P A
E C P A
E C P A

Fiabilité du logiciel :
variables explicatives ?
nombre de lignes de code source.................................................
demandes de modifications du client en cours de développement
ancienneté de l'équipe .................................................................
nombreux changements de version .............................................
emploi d'un atelier de développement ..........................................
taille de la documentation d'origine ..............................................
mode de suivi des défaillances et de leurs corrections…………...
turn-over des membres de l'équipe ..............................................
organisation du projet ...................................................................
  
  
  
  
  
  
  
  
  
Produit  Processus  Contraintes 

Maîtriser n'est pas simple
modélisation
IL FAUT MAITRISER

QUALITÉ
DÉLAIS
2.2 - Fiabilité et qualité
COÛTS
CARACTÉRISTIQUES
DE QUALITÉ Fiabilité

L'approche ISO 9126
qualité
interne et
externe
évaluée à
l'aide de
métriques
Titre du diagramme Qualité
....... Caractéristique .........
...... Sous-caractéristique ......

C SC M
C SC M
C SC M
C SC M
C SC M
C SC M
C SC M
C SC M
C SC M
C SC M
Caractéristique, Sous-Caractéristique
ou Métrique ?
toutes les fonctions définies sont utilisées................................
facilité d'utilisation .....................................................................
1 - (nbre variables non explicitées/nbre total variables) …........
exactitude .................................................................................
portabilité ..................................................................................
1/nbre langages utilisés ............................................................
facilité d'analyse .......................................................................
maintenabilité ...........................................................................
1/degré maximum d'imbrication ...............................................
tous les accès sont protégés ...................................................

Les 6 caractéristiques de qualité
 Capacité fonctionnelle
 Facilité d'utilisation
 Rendement ou performance
 Fiabilité
 Maintenabilité
 Portabilité
opérations
sur le produit
révision
du produit
transition
du produit

Quelle question
pour quelle caractéristique ?
QUESTION : Le logiciel … Caractéristique associée
fonctionne-t-il en permanence exactement ?
puis-je l'utiliser sur une autre machine ?
puis-je le mettre en œuvre facilement ?
puis-je le réparer ?
fait-il ce que je veux ?
fonctionne-t-il de manière optimum ?

Quelles sous-caractéristiques
pour la fiabilité ?
– facilité d'analyse ........................................................
– tolérance aux fautes ..................................................
– stabilité ......................................................................
– facilité d'installation ...................................................
– maturité .....................................................................
– testabilité ...................................................................
– possibilité de récupération ........................................
– comportement vis-à-vis du temps .............................
– conformité ..................................................................










Les liens caractéristiques -
sous-caractéristiques
exactitude
interopérabilité
sécurité
Capacité fonctionnelle
maturité
tolérance aux fautes
possibilité de récupération
Fiabilité
facilité de compréhension
facilité d'apprentissage
facilité d'exploitation
attrait
Facilité d'utilisation
comportement vis-à-vis du temps
utilisation des ressources
Rendement ou performance
facilité d'analyse
facilité de modification
stabilité
testabilité
Maintenabilité
adaptabilité
facilité d'installation
facilité de co-existance
interchangeabilité
Portabilité
conformité
pour tous

Quelques exemples de métriques
pour la fiabilité
 densité estimée de défauts latents
 nombre de fautes corrigées
 couverture de test
 taux d'évitement des arrêts du système
 taux de redémarrage dans les temps
 couverture des exigences ....

Généralisation : L'approche GQM
Goal Question Metric
 Objectif
– bien définir l'objectif de la campagne de mesure selon trois
axes :
• but
• optique
• environnement
 Questions
– auxquelles il faut répondre pour atteindre l'objectif
précédemment défini
 Métriques
– permettant de répondre aux questions
– à intégrer dans la campagne de mesure

Démarche de mesure
 Documenter le processus de développement
 Etablir les objectifs du programme de mesure
– amélioration du processus de développement
– diminution des coûts de développement
– amélioration de la qualité du logiciel
– amélioration de la détection de problèmes ....
 Définir les métriques
– à l'aide du paradigme GQM

Démarche de mesure (suite)
 Identifier les données à collecter
 Définir les procédures de collecte
– comment les données élémentaires sont-elles collectées ?
– qui est responsable de la collecte et de l'enregistrement ?
– avec quelle fréquence les données sont-elles recueillies ?
– comment vérifier qu'elles sont correctes ?

Démarche de mesure (suite)
 Réunir les outils nécessaires
– outils de planification et de suivi
– outils d'analyse de code
– outils de gestion des fiches d'anomalies
– outils de gestion du test ...
 Créer la base de données des mesures
– présenter l'information à tous les niveaux hiérarchiques
– suivre l'obtention des objectifs fixés
– émettre des recommandations pour améliorer les processus ...

Démarche de mesure (suite et fin)
 Définir les modèles
– échantillons représentatifs
– données fiables
– modèles validés ...
 Recommencer
– réviser les objectifs et les mesures associées au fur et à mesure
que l'entreprise s'améliore ...

Quand évaluer ?
 Pendant les premières phases du cycle de vie
approche qualitative
fiabilité prévisionnelle
 Pendant les dernières phases du cycle de vie
approche quantitative
fiabilité expérimentale

Deux approches différentes
 Fiabilité prévisionnelle
– nature du logiciel
– nature du projet
– contraintes
– mode d'utilisation
 Fiabilité expérimentale
– comportement initial
– modèles mathématiques

approche
par les métriques
fiabilité qualité
approche
probabiliste
fiabilité mathématique
calculs amont
fiabilité prévisionnelle * ?
calculs aval
fiabilité expérimentale ** ***
Etat de l'art

2.3 - La théorie en fiabilité
expérimentale
le logiciel est
déterministe ...
il suffit de corriger
tous les défauts ...
je suis capable
de faire un logiciel
sans défaut ...
Spécificités du logiciel

Spécificités du logiciel
par rapport au matériel
 Structure
– Indépendance des composants
– Tolérance aux fautes
– Redondance
 Cycle de vie
– Evolutions
– Vieillissement
 Comportement
– Défaillances reproductibles
– Réparations

Processus d'apparition des défaillances
environnement de référence
environnement d'évaluation
environnement opérationnel
défaillances
défauts
domaine d'entrée
domaine de sortie
logiciel

Définitions
 Faute (fault)
Une faute est un événement causé par le processus de
production du logiciel ou par le contexte de son
développement.
 Erreur (error or defect)
Une erreur (ou un défaut) est une partie du programme
inadaptée ou manquante.
 Défaillance (failure)
Une défaillance d'un programme est une manifestation de la
divergence entre le comportement spécifié et le comportement
effectif du programme.

Inconvénients de l'approche"système "
ou "boîte blanche"
 Différentes natures de logiciels
– logiciel incorporé
– logiciel de base
– applicatif
 Interactions complexes
– interdépendance
– mécanismes de feedback
 Contributions variées
– à la mission
– au temps de fonctionnement

Les modèles "boîte blanche"
 Architecture du système
 Homogénéité des sollicitations en fonction du temps
 Connaissance de la fiabilité de chaque composant
 Connaissance du couplage entre les composants
complexité
explosion
combinatoire

Les modèles "boîte noire"
• Hyper-exponentiel
• Concoran-Weingarten-
Zehna
• Mills
• Littlewood-Verral
• Crow-Singpurwalla
• Musa-Okumoto
• Downs
• Singpurwalla
• Wagoner
• Littlewood structurel
• Lipow-Tayer
• Akiyam
• Nelson
• Schick-Wolverton
• Cox
• Wall-Ferguson
• Goel-Okumoto
• Musa
• Lapadula
• Halstead
• Schneidewind
• Trivedi-Shooman
• Weiss
• Ramamoorthy-Bastani
• Kremer
• Koch-Sprey
• Jelinski-Moranda
• Shantikumar
• Moranda Géométrique
• Crow-Duane
• Shooman
• Rushforth-Staffanson-
Crawford
• Motley-Brooks
• Angus-Schafer-Sukert
• Yamada-Osaki-Narihisa

Modèle probabiliste simple
ensemble des
données d'entrée
probabilisées
(Ei, pi)
tirage au sort
n exécutions
dont
d défaillances
R(n) = 1 - d/n
fiabilité pour n exécutions
modèle de Nelson
basé sur l'échantillonnage

Autre modèle probabiliste simple
ni = ?modèle de Mills basé
sur l'essaimage de défauts
xi défauts pré-existants
et détectés
xs défauts introduits
et détectés
ni défauts pré-existants ns défauts introduits
xx xenz coixx

Principe des modèles à taux de panne
z(t) = taux de panne = probabilité de défaillance
par unité de temps après vérification
z(t)
t t+u t+2u t+3u ...
OK

Calcul du taux de panne
N téléviseurs identiques sont testés.
En notant R(t) la probabilité pour qu'un téléviseur fonctionne sans panne
jusqu'à l'instant t, quel est le taux instantané de panne par unité de temps ?

Modèles à taux de panne
)(
)(exp)(
)(
)(')(où
)(1
)(
)(
)()()(1)(
0
0
0

















duuufMTTF
duuztR
dt
tdF
tFtf
tF
tf
tz
duuftRtRtF
t
est le taux de panne hazard rate
est la densité de probabilité de T probability density function - pdf
est l'espérance mathématique de la variable aléatoire T mean time to failure
R fonction fiabilité
F fonction de répartition
t temps cumulé
T variable aléatoire associée
est la fonction fiabilité reliability
t

Utilisation de l'intensité de défaillance
temps
défaillances
l(t)
spécificité de la fiabilité du logiciel

t temps cumulé
M nombre total de défaillances apparues
l(0)
l(t) (t)
M(t)

t temps cumulé
M nombre total de défaillances apparues
l(0)
l(t) (t)
M(t)
)(
)(




N
M(t)t deuemathématiqespérance
dt
td
t
)(
)(

l  est l'intensité de défaillance
failure intensity function

Principes usuels de modélisation
 Fonction intensité
– Quelle forme ?
– Quels paramètres ?
 Construction du modèle
– Hypothèses de distribution probabiliste
 Calcul
– Des fonctions caractéristiques
– Des équations pour estimer les paramètres

Exemple : le modèle de Jelinski-Moranda



t1 t3t2
l =  (N-i+1)
l(t) = N  exp( -  t)
])ˆ(êxp[)/(ˆ
ˆ
1
FTˆMT)êxp(ˆ)(ˆ
)ˆ(ˆ)/(ˆ)]êxp(ˆˆ
ˆdeestimateur
tiNttR
tt
iNttztt
xx
i
i





l
l


Exemple : le modèle de Littlewood-Verral
t1 t3t2
1
2
0 )1(2
1
)(


l



t
t
1
)(
)(ˆ
)([,]edéfaillancdetaux
)()(
)(ˆ
einstantanéMTTF
ˆ
1ˆ
)1(2
1
)(ˆ)1(2
)(ˆ
1
2
01
1
1
2
0
2
00




















l


l



i
tTFTM
iitt
itt
tZ
TFTM
t
t
t
t
p
ii
i
i

Principes de classification
des modèles selon Musa
nombre total de défauts fini ou infini ?
forme de la fonction Z(t) ?
distribution de M(t) ?

Distributions de M(t)
 Loi binomiale
 Loi de Poisson
N
m
p







 



 

 






 












 


Équations des distributions de M(t)
 Loi binomiale
 Loi de Poisson
   
N
mNm
N
tNt
m
N
mtMP









)()(
)(

   )(exp
!
)(
)( t
m
t
mtMP
m




Quelques formes de taux de panne
 Puissance (z=abtb)
 Inverse linéaire (z=a/(t+b))
 Polynomiale (z= -at2+bt+c)
 Géométrique (z=aki-1)
b>1
0<b<1
b<0
a<0
a>0

expo-
nentielle
puissance polyno-
miale
inverse
linéaire
géo-
métrique
autre
Jelinski-
Moranda
Shooman
Wagoner
Schick-
Wolverton
Schick-
Wolverton Littlewood
binomiale
Musa
Goel-Okumoto
Schneidewind
Moranda
poisson
Goel-Okumoto
autre
Shanthikumar
Kremer
Crow-Duane poisson Musa-Okumoto
Hyper-
exponentielle
Littlewood-
Verral Moranda autre
Classification des modèles selon Musa
nombre total de défauts infini
nombre total de défauts fini

Avantages des modèles NHPP
Valeurs caractéristiques
Forme de  ?
Processus de Poisson Non Homogène

0 200 400 600 800 1000
0
10
20
30
40
50
60
70
Temps de fonctionnement
Nombrededéfaillances
c:melodevdemodemo.mbu
21/03/99 - 14:04:22
Nombre de défaillances modélisé
Statistique
Musa-Okumoto
Goel-Okumoto
Crow
Hyper-exponentiel
4 modèles NHPP de M-élopée

Le modèle bayésien de M-élopée
0 200 400 600 800 1000
0
10
20
30
40
50
60
70
80
c:melodevdemodemo.mbu
Découpage automatique - 21/03/99 - 14:06:45
Nombre de défaillances modélisé (Littlewood-Verrall)
Statistique
Mod. complète

 Musa-Okumoto (logarithmique)
 Crow (puissance)
Les équations des modèles
infiniN

l

l
l
l
l
)1ln(
)(
0,0
1
)(
0
0
0
0





t
t
t
t
 Goel-Okumoto (exponentiel)
 LAAS ou (hyper-exponentiel)
  finiN)exp(1)(
0,0)exp()(
tNt
NtNt

l


infiniN

l
ll
tt
Ntt

 
)(
10,0)( 1
 
10;0;1
)exp()exp(ln)(
)exp()exp(
)exp()exp(
)(
12
21
21
2211









l
ttt
tt
tt
t
-

Les équations des modèles
 Schneidewind (exponentiel)  Littlewood-Verral (bayésien)
 Yamada (gamma)
 
  périodelaestoùintervallel'dansest
finiN
TBTBt
i-t
it
ii ,
)exp(1)(
0,0)exp()(







l
1
1
2
00
1
2
0
)1(2
)(
)1(2
1
)(





l





t
t
t
t









 
a
a
a
ta
k
t
t
k
t
)(1)(
)(
)( 1





l

cahier de bord de test
2.4 - Les processus de collecte et d'étude
recueillir
les données
analyser
à priori
étudier les
tendances
modéliser
prévoir
formaliser
les
résultats
jeux de test
logiciel à tester
organisation examen du besoin
examen du besoin
rapports d'anomalies
corrections
données exploitables
hypothèses de croissance
choix de modèle
courbes de tendance
courbes de modélisation
résultats quantifiés
rapport
décision
COLLECTE
DES
DONNEES
ÉTUDE
DE
FIABILITE

Préliminaires : Examen du besoin
 Nature des objectifs
 Type de système
 Mode d'utilisation

Nature des objectifs ?
– quantification de la fiabilité d'un système ........................
– mesure du taux de couverture ........................................
– tolérance des pannes de matériel ...................................
– confort d'utilisation ..........................................................
– succès d'une mission ......................................................
– calcul du nombre de défauts résiduels ...........................
– justification de la sécurité du système ............................
– évaluation des coûts de maintenance ............................
– aide au management du test ..........................................
– certification du logiciel .....................................................

Type du système
 Mise en œuvre par le système de plusieurs logiciels :
– de natures différentes
– d'origines variées
– à des fréquences différentes
 Architecture tolérante aux fautes
– à quel niveau ?
– avec quel degré d'indépendance ?

Mode d'utilisation
 Profil d'utilisation
 Phase d'évaluation
– validation
– phase opérationnelle
 Duplication des sollicitations
– dans un même système
– multi-site
 Duplication des versions

Organisation
 Quoi ?
 Qui ?
 Comment ?
analyse de
la valeur

Que collecter ?
 Défaillances
– est-ce une défaillance ?
– quand est-elle apparue ?
– est-elle déjà apparue ?
– d'où vient-elle ?
– qu'induit-elle ?
– pourquoi est-elle apparue ?
– comment est-elle traitée ?
 Sollicitation
– quelle variable de sollicitation
utiliser ?
– quelle est la durée de sollicitation ?
– quelle est sa nature ?
 Configuration
– version utilisée
– site
– matériel
 Autres informations
– date calendaire
– numéro de fiche
d'anomalie
– nom de la personne
responsable
– fiche de correction
associée
et de la
cohérence !

Qui va intervenir ?
 Désigner les acteurs
– chef de projet
– ingénieur de développement
– ingénieur qualité
– ingénieur de test
– ingénieur support
– utilisateur
 Définir leurs fonctions
 Planifier leurs actions
les former
et les motiver !

Quel est le rôle de chacun ?
acteur
fonction
chef de
projet
ingé.
dévelop.
ingé.
qualité ingé. test utilisateur
analyse du
problème
collecte
des
données
calculs de
fiabilité
interprét.
des
résultats
supervision

Mise en place des outils
 capture des données de sollicitation
 capture des données de défaillance
 capture des autres données ....
 enregistrement des données de fiabilité
 calculs de fiabilité
 édition des rapports ...
 suivi des actions ...

Préparation des données pour l'étude
 vérification de complétude
 vérification de cohérence
 vérification que les données sont plausibles !

2.5 - Le processus d’étude de
fiabilité expérimentale
étudier les
tendances
modéliser
prévoir
formaliser
les
résultats
examen du besoin
données exploitables
hypothèses de croissance
choix de modèle
courbes de tendance
courbes de modélisation
résultats quantifiés
rapport
décision
COLLECTE
DES
DONNEES
ETUDE
DE
FIABILITE

Exemple d'étude de fiabilité
essais
d'ensemble
validation
client
exploitation
arrêt ? résultats ?
fiabilité ?
maintenance ?
suivi
compilateur

Collecte des données
Fiche d'anomalie N°
défaillance bloquante
défaillance contournable
défaillance déjà vue
Base d'essais
date
n° de l'essai-nom du test-taille du test
...
...
date
n° de l'essai
nom du test
date
fusion
nb. de lignes compilées n° de FA

Etude des tendances
0 2000 4000 6000 8000 10000
0
10
20
30
40
50
60
70
c:melodevdemoexemple.mbu
24/03/99 - 21:44:25
Nombre cumulé de défaillances (unitaire)
MTTF fenêtré
sur l'échantillon total : 147 lc
sur les 5 dernières défaillances : 568 lc

Test de tendance
0 2000 4000 6000 8000 10000
-7
-6
-5
-4
-3
-2
-1
0
1
Indicateur
24/03/99 - 21:45:22
Indicateur de Laplace depuis l'origine (unitaire)
Hypothèse de croissance de fiabilité
acceptée

Modélisation
 Choix du meilleur modèle en trois étapes :
– représentation du processus
– qualité des prévisions
– convergence de la modélisation

Représentation du processus
0 200 400 600 800 1000
0
10
20
30
40
50
60
70
80
c:melodevdemoexemplei.mbu
24/03/99 - 21:57:00
Nombre de défaillances modélisé
Statistique
Musa-Okumoto
Goel-Okumoto
Crow
Hyper-exponentiel
Littlewood-Verrall
MTTF estimé par les modèles
Musa-Okumoto : 580 lc; Goel-Okumoto : 1978 lc; Crow : 333 lc;
Hyper-exponentiel : 248 lc; Littlewood-Verral : 267 lc.
0 2000 4000 6000 8000 10000

Qualité des prévisions
Musa-Okumoto
Goel-Okumoto
500 1400 2420 4120 5370 6980 7910 11000
-6 %
-4 %
-2 %
0 %
2 %
4 %
6 %
8 %
10 %
Erreur
Découpage régulier (temps) - 24/03/99 - 22:02:49
Erreur relative sur le nombre de défaillances modélisé
à échéance mobile = 1000 unités de temps
47
53
58
63
70
73
Musa-Okumoto
Goel-Okumoto
500 1400 2420 4120 5370 6980 7910 11000
0
10
20
30
40
50
60
70
Erreur absolue sur le nombre de défaillances modélisé
à échéance mobile = 1000 unités de temps

Convergence de la modélisation
0 2000 4000 6000 8000 10000
0
0.01
0.02
0.03
0.04
0.05
Intensitédedéfaillance
Intensité de défaillance modélisée (Musa-Okumoto)
Statistique
Mod. complète
Mod. successives

Prévisions
essais
d'ensemble
validation
client
exploitation
arrêt ? résultats ?
fiabilité ?
maintenance ?
suivi
compilateur
décision d'arrêt
des essais
prévision en
validation :
2 défaillances
MTTF annoncé au
client :
580 lc

Prévisions de maintenance -
Exercice
Après la validation, 5 compilateurs sont livrés.
Les utilisateurs prévoient de compiler en moyenne 10 000 lc par
semaine.
Le fournisseur prévoit un effort moyen de correction de 0.5
homme.jour par défaillance.
Calculer l'effort moyen de maintenance pendant trois mois, sachant
que le modèle donne :
estimateur de (612 000) = 160 défaillances.

Reprise des essais et planification -
Exercice
L'effort moyen de maintenance étant trop important, le chef de projet
décide de continuer le test jusqu'à ce que l'objectif de MTTF de 1 000
lc soit atteint.
Combien de lignes de code faudra-t-il encore compiler en test pour
atteindre cet objectif ?
La première phase de test (77 défauts, 12 000 lc compilées) a duré
60 jours.
En supposant que la durée des essais est proportionnelle au nombre
de défauts corrigés, calculer le temps qui sera nécessaire à
l'obtention de l'objectif fixé.
047.0
06378.00



l

Résolution des cas particuliers
 Défaillances non observées
 Utilisation non continue
 Relevés "presque unitaires"
 Utilisation multi-sites
 Changements de version
 Utilisation multi-environnements

Défaillances non observées
P(i) = proba. que la ième
défaillance est manquante
P(i) = p1 + (i/a)(p2-p1) si i<a
P(i) = p2 si i a

Utilisation non continue - Exercice
Problème
Utilisateur A - 50%
Utilisateur B - 50%
Utilisateur C - 25%
8 h 12 h
14 h 16 h
16 h 18 h
Solution
0 h 2 h 4 h
temps calendaire
temps d'exécution

Relevés "presque unitaires "
Exercice
Problème
Solution
1 2
temps d'exécution
n° de défaillance
3
4
5
6 7 8
1 2
temps d'exécution
n° de défaillance
6 7 8

Utilisation multi-sites - Exercice
Problème
Matériel A
Matériel B
8 h 9 h
8 h 30
10 h
Solution
0 h 2 h1 h
temps d'exécution
temps d'exécution
= défaillance du logiciel
3 h

Changements de version
Problème
Solution
V1
V3
V2
temps
V4
locale globale ajustée

Utilisation multi-environnements -
Exercice
environnement A environnement B
environnement C
p1
p2
l
l2
l3 

Quelques règles de bonne pratique (1/2)
prévoir à échéance raisonnable
Temps de fonctionnement connu
prévu
séparer les éléments non homogènes
environ. A
environ. B
logiciel
L
logiciel
M

Quelques règles de bonne pratique (2/2)
limites du retour d'expérience
10-3 par heure  3.000 heures de test
pour une confiance à 95 %
limites de la classification par gravité
probabilités ???

Techniques de test et fiabilité
debugging
test de la fiabilité
fiabilité
fiabilité ????
fonction fréquemment utilisée
x = défaut corrigé
0 = défaut non corrigé
x x x x 0
0
0
fonction peu utilisée
x x x x 0
0
0
fonction fréquemment utilisée
x x x x x
x
0
fonction peu utilisée
x x 0 0 0
0
0

Techniques de test et fiabilité
 Test structurel (boîte blanche)
 Test fonctionnel (boîte noire)
 Test d'endurance - test aux bornes
 Test d'intégration
 Test de non régression
 "Field test"
 Test selon le profil opérationnel
NON !
OUI !

Principes du test statistique
selon le profil opérationnel
 Test de la fiabilité plutôt que debugging
 Reproduction fidèle du profil d'utilisation
 Evaluation du niveau de fiabilité obtenu
 Management du test par la fiabilité

Difficultés liées au test statistique
selon le profil opérationnel
 Connaissance préalable du profil opérationnel
 Génération de scénarios suivant le profil opérationnel
 Nécessité de générer beaucoup de scénarios
 Nécessité d'exploiter beaucoup de résultats de test

Un processus de test selon le profil
opérationnel proposé par All4tec
– Réalisation d'un modèle d’usage
• avec l’outil MaTeLo©
• définition des fréquences d’utilisation
– Validation de ce modèle
• à l'aide des utilisateurs
– Génération des scénarios de test avec leurs résultats
• dans un format compatible avec celui des bancs de test
– Passage sur machine cible
• et exploitation des résultats à l'aide de MaTeLo© et M-élopée©

2.6 - Conclusion
fiabilité
coût
faible moyenne élevée très élevée ultra-élevée
image
de
marque

Bases de la fiabilité prévisionnelle
 Engranger les données explicatives
– produit
– processus
– contraintes
 Engranger le retour d'expérience
– fiabilité quantifiée des systèmes
connus
 Faire des modèles
 Les affiner




Plan d'action
 Mettre en place la fiabilité expérimentale et ...
 ... faire les comptes
 Initialiser la fiabilité prévisionnelle
 Améliorer les processus

3 - AMDEC DU LOGICIEL
3.1 Transition de l’analyse système à l’analyse
logiciel
3.2 Principes de réalisation des AMDEC
3.3 Comparaison avec l’AEEL
3.4 Mécanismes de tolérance aux fautes
3.5 Conclusion
AMDEC = Analyse des Modes de Défaillance
de leurs Effets et de leur Criticité

3.1 - Transition de l’analyse système
à l’analyse logiciel
Analyse
du besoin
Rédaction des
exigences
Conception
fonctionnelle
Conception
organique
Intégration
Qualification
Réception
constituants
Vérification
validation
Modifications
Sûreté de
fonctionnement
Traçabilité Optimisation
Préparation
moyens essais
AMDEC
organique
AMDEC
fonctionnelle
ER système
ER constituants

Liste des événements
indésirables
Besoin de transition
des événements redoutés
Objectif système
indésirables
Objectif logiciel
Evénements redoutés
Logiciels critiques
Criticité
recommandations

indésirables
Besoin de transition
des probabilités de défaillance
Objectif système
Niveau de l'effort
de développement
Objectif logiciel
Probabilité de défaillance
Criticité des logiciels

Démarche itérative
 Identifier les risques « système » jusqu’aux logiciels
critiques :
– Au niveau du choix d'architecture
– Justifier et/ou modifier la répartition matériel/logiciel des fonctions du
système
– Identifier les risques potentiels liés à la solution retenue et orienter les
efforts de construction de la sûreté de fonctionnement vers les logiciels
critiques
 Analyser les logiciels critiques :
– Au niveau du développement des logiciels
– Construire la sûreté de fonctionnement des logiciels les plus critiques
pendant leur développement, depuis la phase de spécification jusqu'à la
qualification

Les différentes AMDE(C) du logiciel
 L’AMDE(C) du logiciel …
– … n’est pas auto-porteuse :
• Plusieurs AMDE(C) sont nécessaires
– Abus de langage :
• Préférer “l’analyse des risques du logiciel”
ou
• Préciser la phase concernée, par exemple “l’AMDEC de
conception préliminaire”
Cf. confusions avec l’AEEL

Enchaînement des AMDE(C) dans les
dernières boucles d’ingénierie
Définir les
objectifs de SdF
Identifier les causes
de défaillances
Identifier les constituants critiques
Classifier les faiblesses du système
Etudier les conséquences d’une défaillance
Test
(relecture)
Analyse
ECU
AMDEC
fonctionnelle
AMDEC
structurelle
Spéc.
Logicielle
Spéc.
Matérielle
Conception
du logiciel
Conception
du matériel
AMDE
fonctionnelle
AMDE
structurelle
Codage
du logiciel
Intégration
et
validation
ECU =
Electronic Control Unit

Spécificités de l’AMDEC des ECU
 Emploi de modes de défaillance génériques :
– Non-production de donnée par la fonction
– Production intempestive de donnée par la fonction
– Production erronée de donnée Avec / Sans détection par la fonction
• donnée fausse... / vraie par erreur
• donnée au-delà / en deçà d’un seuil …
 L’AMDEC s’intéresse particulièrement :
– A la faisabilité du système avec le niveau de SdF exigé
– Aux fonctions de sécurité à mettre en œuvre
– Aux modes dégradés à prévoir
– Aux compléments de tests de validation à réaliser pour justifier le niveau de
SdF atteint
 Elle permet de hiérarchiser les fonctions du système selon
leur criticité

Spécificité de l’AMDE de spécification
du logiciel
 Analyse de l’ECU enrichie par l'introduction de la
modélisation fonctionnelle du logiciel pour mettre en
évidence :
– Les modes de défaillance critiques des fonctions logicielles
– Les fonctions logicielles critiques (dont les modes de défaillance
conduisent à des événements redoutés du logiciel)
– Les recommandations portant sur l'architecture fonctionnelle et
structurelle du logiciel permettant de réduire les risques liés aux modes
de défaillance critiques

Spécificité de l’AMDE de conception
préliminaire du logiciel
 Analyse des composants logiciels pour mettre en
évidence :
– Les composants critiques (dont les modes de défaillance conduisent à
des événements redoutés du logiciel)
– Les recommandations portant sur la conception du logiciel permettant
de réduire les risques liés aux modes de défaillance critiques
 L’AMDE s’intéresse particulièrement :
– Aux chemins des données
– A la structure des modules
– Aux barrières de sécurité à proposer
– Aux compléments des tests d'intégration à réaliser pour justifier le
niveau de SdF atteint

Spécificité de l’AMDE de conception
détaillée du logiciel
 Analyse des composants critiques pour :
– Raffiner l'analyse précédente en prenant en compte la
conception détaillée des composants
 Possibilité d’employer l’AEEL

Analyse des logiciels critiques (1/2)
 Effectuée sur chaque logiciel critique
 Ne tient compte que de la gravité
– On parle d’AMDEC
 Dépend du niveau de criticité :
– Analyse de la spécification
– Analyse de la conception préliminaire
– Analyse de la conception détaillée
– Analyse du code
• Relecture orientée par l’AMDE en général
• AMDE de code rarissime

Analyse des logiciels critiques (2/2)
 Dépend de la nature du développement :
– Nouveau
– Réutilisé
– COTS ...
 Analyse :
– Par AMDE
– Ou plus légère (descendante)

Produits de l’analyse
des logiciels critiques
Pour chaque logiciel critique :
– Hiérarchisation des composants du logiciel en fonction de leur
criticité
• Impact de leurs modes de défaillance sur les événements redoutés
du logiciel
• Identification de leurs modes de défaillance critiques
– Recommandations portant sur l'architecture fonctionnelle et
structurelle
• Permettant d'améliorer la prise en compte des exigences SdF du
logiciel (règles de conception, règles de codage)

3.2 – Principes de réalisation des AMDE
(1/3)
 Analyse locale
– Objectif :
• Pour chaque constituant élémentaire, identifier les effets des
modes de défaillance élémentaires
– Etude de l’impact sur les sorties d’un constituant élémentaire :
• des défaillances des entrées
• de tout problème lors de sa mise en œuvre (erreur
d’implémentation, dysfonctionnement de la fonction en
cours d’exécution)
 Analyse globale (ou « propagation »)
– Propagation des effets locaux jusqu’aux sorties du logiciel
– Utilisation de la liste des événements redoutés du logiciel afin
de cibler la propagation uniquement les sorties du logiciel
critiques

Principes de réalisation des AMDE (2/3)
 Interprétation des résultats
– Etude de robustesse :
• Pour définir le comportement du système et donc du logiciel
en présence de données d'entrée erronées
– Production de données erronées
– Emission de messages précisant la détection de données
erronées en entrée et le type d'action prise par le logiciel
– Analyse « interne » :
• Pour identifier les risques internes liés à des
dysfonctionnements des composants
– Matériels ou logiciels susceptibles de générer les événements
redoutés du système

Principes de réalisation des AMDE (3/3)
– Analyse « interne » (suite) :
• Pour proposer des actions correctives en vue de réduire la
criticité de ces risques sous la forme :
– D'exigences fonctionnelles
– De contraintes de conception (p.e. sur le partitionnement des
fonctions et services)
– De contraintes de codage ou de tests
 Arbre des défaillances (optionnel)
 Recherche des causes communes (optionnel ou partiel)

Présentation des résultats (1/2)
Résultats de l’analyse locale
 et  identifient les modes de défaillance en entrée du constituant
 = donnée à l’origine de la défaillance
 = nature générique du mode de défaillance de l’entrée (manquante,
erronée, production intempestive)
 et  identifient l’effet sur les sorties du constituant
 = nom de la sortie dont on évalue le mode de défaillance
 = nature générique du mode de défaillance de la sortie (manquante,
production erronée, production intempestive)
Identifiant du constituant
Entrée - Nature du MdD = Sortie - Nature du MdD
   
Entrée - Nature du MdD = Sortie - Nature du MdD
…………..

Présentation des résultats (2/2)
Résultats de l’analyse globale
 donne l’identifiant de l’ER étudié  donne le label de l’ERL étudié
 et  identifient les modes de défaillance en entrée :
 = donnée à l’origine de la défaillance
 = nature générique du mode de défaillance de l’entrée (manquante,
erronée, production intempestive)
 et  identifient l’effet sur les sorties :
 = nom de la sortie impactée
 = nature générique du mode de défaillance de la sortie (manquante,
production erronée, production intempestive)
Evénement Redouté Chemin de propagation
ID

Label

MdD final … …. MdD d’origine
Description des modes de défaillance du chemin de propagation
Donnée Origine-MdD = Donnée Produite-MdD
   

Utilisation et suivi
des résultats bruts d’analyse
 Vérifier que les :
– Moyens de détection proposés
– Recommandations émises
– Actions demandées
… ont bien été mis en œuvre
… en conception ou en test
 Faire un suivi indépendant de l’analyse (livret des
points critiques par exemple)
 Maintenir en configuration

3.3 - Comparaison avec l’AEEL
 AEEL (Analyse des Effets des Erreurs du Logiciel)
– Adaptation de l’AMDEC du matériel pour le logiciel
 Stricto sensu :
– Concept hors approche « système »
– Basé sur une typologie d’erreurs de codage
 Ses principes :
– Identification des parties critiques (modules & procédures)
– Vérification du respect des exigences de sécurité
– Allocation aux différentes parties, en fonction de leur criticité, de l'effort de
conception, développement, test
 Dans la pratique :
– Confusions entre analyse des risques, AMDEC du logiciel et AEEL

Typologie proposée par l’AEEL (1/2)
Types d'erreurs logicielles Classes d'erreurs utilisées Exemples de défauts originels
Erreurs de calcul Evaluation d'une équation incorrecte - Choix d'opérande erroné
- Valeur d'opérande interdite par un opérateur
- Choix d'opérateur incorrect
- Fonction d'un opérateur non assurée
- Omission dans les calculs
- Opérateur à supprimer
- Erreur de signe
- Calcul intermédiaire perdu
- Utilisation de ( ) erronées
Résultat erroné d'une opération - Dépassement de capacité
- Troncature d'une valeur
- Précision insuffisante
Erreurs d'algorithmique Erreurs de séquencement d'instruction - Ordre erroné des instructions
- Instruction omise
- Instruction à supprimer
- Séquence inaccessible
Branchement inconditionnel erroné - Implantation du branchement erronée
- Destination du branchement erronée
Branchement conditionnel erroné - Calcul erroné de la condition logique
- Décision de branchement erronée
- Mauvaise imbrication de branchements conditionnels
Boucle de traitement erronée - Mauvaise implantation de boucle
- Mauvaise gestion du paramètre de la boucle
- Adresse de rebouclage erronée

Typologie proposée par l’AEEL (2/2)
Types d'erreurs logicielles Classes d'erreurs utilisées Exemples de défauts originels
Erreurs de synchronisation Nature de la primitive de synchronisation - Défaut de modélisation
Paramètre de synchronisation erronée - Défaut de modélisation
Synchronisation non prévue - Défaut de modélisation
Erreurs sur les données traitées Erreurs de définition - Déclaration de structure erronée
- Déclaration de type erronée
- Déclaration manquante
- Déclaration multiple
- Mauvaise implantation de la déclaration
Erreurs d'initialisation - Initialisation manquante
- Initialisation mal placée
- Initialisation avec valeur erronée
Erreurs de manipulation - Erreur de label
- Erreur de calcul d'adresse
Modification de la valeur d'une donnée - Ecriture parasite
Erreurs d'interfaçage entre
procédures
Erreur d'appel de la procédure - Implantation de l'instruction d'appel de procédure erronée
Erreurs de sortie d'une procédure - Implantation de l'instruction de sortie de procédure erronée
Erreurs de transmission de paramètres entre
procédures
- Label de paramètre erroné
- Type de paramètre erroné
- Quantité de paramètres transmis erronée
Erreurs de transfert de données
avec l'environnement
Erreurs de définition de données - Déclaration de structuration erronée
- Déclaration de type erronée
Erreurs de transmission de données - Label d'une donnée erroné
- Quantité de données données transférées erronée
Périodicité de transfert erronée - Echantillonnage de données
- Temps de réponse inadapté

3.4 - Mécanismes de tolérance aux
fautes
 Ces mécanismes offrent des barrières de sécurité
– Actions en 2 temps :
• Détection de défaillance
• Evitement de l’effet système
– Principales techniques à 2 niveaux :
• En conception : techniques de redondance
• En codage : techniques spécifiques aux langages
 Autres types de barrières de sécurité :
– Appel opérateur, alarme, procédures opérationnelles
– Contrôle plus rigoureux du procédé de fabrication
– Tests spécifiques pour s’assurer de la couverture des risques

Mécanismes de conception
Programmation N-versions Blocs de recouvrement
Développer N versions sur
la base des mêmes
spécifications
Développer 1 version permettant
de se reconfigurer en position
sûre en cas de faute
Tolérer tout type de fautes
Mode commun = spécification
Tolérance aux fautes
vis-à-vis
des événements redoutés
Coût élevé

N-versions
P1
P2
Pn
entrées comparateur
alarme
sorties

Bloc de recouvrement
F(x, y) = S
x
y S
Alternant
primaire
z
S
Sr
Bloc de recouvrement
Test
d’acceptation
Alternant
secondaire

Exemple
Calcul Pression
Traitement AU
V
T
PV = nRT ?
P
Repli

Mécanismes de codage
Evitement de défaillance :
• par temporisation des traitements
Détection de défaillance :
– Par le matériel en relation avec le logiciel :
• Autotest
• Watchdog
– Par le logiciel :
• Pré- ou post-conditions
• Check-sums
• Traitement d’exceptions
Correction de défaillance :
– Par reprise (amont ou aval)
– Par reconfiguration et éventuellement mise en mode dégradé

Justification par consolidation
 Au niveau système
– Modélisations / allocations
– Règles et procédures d'analyse
 Au niveau matériel et logiciel
– Composants fiables et durables
– Mécanismes de détection et de reconfiguration
– Redondances, voteurs, confinement des défauts
 Au niveau Interface Homme-Machine
– Procédures et outils d'exploitation en cas de défaillance
– Procédures et outils de maintenance

3.5 - Conclusion
 Intérêt, limites et difficultés
 Qualité et sûreté de fonctionnement
 Recommandations générales

Intérêt, limites et difficultés
 Intérêt
– Efficace si appliquée à des composants logiciels pouvant être à l’origine
de défaillances de l’ensemble du système
– Permet d’optimiser les tests : en fonction de la criticité des composants
 Limites
– Analyse mal adaptée à la représentation d’évènements dynamiques
– Les modes communs de défaillance ne sont pas gérés
– Analyse conduisant à des redondances si les évènements redoutés sont
trop inter-dépendants
 Difficultés
– Mise en œuvre délicate pour des systèmes complexes comportant un
nombre de composants élevé
– L’analyste doit bien connaître le logiciel
– La qualité d’une analyse est difficile à évaluer par un non spécialiste

Qualité et sûreté de fonctionnement
 Spécificité du logiciel
– Toute erreur de logiciel est introduite lors du développement
 Méthodes de qualité logicielle
 Evitement des fautes
– Est-ce qu’on a fait le bon logiciel ?
– Est-ce qu’on a bien fait le logiciel?
– Processus de développement
– Méthodes, règles, technologies…
 Méthodes de Sûreté de Fonctionnement du logiciel
 Tolérance aux fautes
– Déterminer les risques  APR
– Analyser le logiciel  AMDE
– Construire un logiciel sûr  programmation défensive, BR, N-versions, …
Malgré toutes ces précautions,
il peut subsister
des erreurs résiduelles

Les qualités d’un logiciel critique
 Simplicité/complexité.
– Fonctions critiques programmées séparément sur
des processeurs distincts si possible
– Sinon ne pas sacrifier la simplicité à la performance
 Déterminisme/non déterminisme
– Au niveau fonctionnel
– Au niveau temporel : modèle d'exécution synchrone
 Robustesse
– Comportement du logiciel en cas de données
d’entrée erronées
Eviter l’incidence des erreurs
d’autres composants
Ne pas augmenter la
complexité par l’ajout de
fonctions
Temps de réponse borné,
comportement déterminé
Prévoir les erreurs
en
entrée du logiciel

Recommandations générales
 Se prémunir par construction contre certains types
d'erreur
– Exemple: le choix d'un logiciel monotâche élimine les risques de conflit d'accès à
des ressources communes
 Mettre en place des dispositifs matériels ou logiciels pour
détecter des comportements anormaux éventuels du
logiciel
– Chien de garde
– Surveillance mutuelle de deux logiciels communicants
 Utiliser un langage formel permettant d'écrire des
programmes dont le comportement est prévisible
– LUSTRE (SCADE), B ...

Se prémunir contre certains types
d’erreurs (1/2)
 Détecter les erreurs d'adressage
– Surveillance des accès en lecture/écriture à des
adresses illégales de l'espace adressable du
microprocesseur (traitement des "bus error")
– Surveillance des accès en écriture dans des zones
mémoires utilisées uniquement en lecture
(constantes, instructions, ...)
– Surveillance des accès illégaux dans des zones
mémoires utilisées en lecture/écriture
 Détecter les erreurs du flot de contrôle
– Surveillance du temps de cycle : dispositif de chien
de garde matériel
Détecter des erreurs du
flot de contrôle (boucle
infinie …), l'arrêt
d’exécution du
programme, la durée
excessive d’une séquence
sous interruption

Se prémunir contre certains types
d’erreurs (2/2)
 Détecter les erreurs du flot de données
– Surveillance de la cohérence des données, en utilisant la
redondance de certaines informations
– Surveillance de la cohérence des données, en utilisant les
valeurs limites sur certaines informations
– Surveillance des conditions d'appel de certaines fonctions
mathématiques (division par 0, racine carrée d'un nombre
négatif) ainsi que du débordement des calculs numériques
 Et de manière générale ...
Traiter toutes
les exceptions

4 – DEMONSTRATION ET
EXERCICES
4.1 Démonstration de calculs de fiabilité avec
l’outil M-élopée©
4.2 Exercice d’AMDE avec ECLAIR
4.3 Démonstration d’AMDE avec Safety Architect ©

4.2 - Exercice d’AMDE avec ECLAIR
4.2.1 Notre sujet d’étude : le système ECLAIR
4.2.2 APR pour ECLAIR
4.2.3 AMDE commentée
4.2.4 Exercice

4.2.1 - Notre sujet d’étude : le logiciel
d’un disjoncteur à ouverture rapide
Déclencheur =
accessoire du
disjoncteur
assurant la
protection
électrique
 ECLAIR = Déclencheur électronique rapide
pour disjoncteur forte puissance
 Fonctions assurées en phase d’exploitation :
– Détection d’un courant de court circuit et ouverture
rapide de l'appareil
– Contrôle du fonctionnement du système et de son niveau
d’alimentation ; action en conséquence sur l'appareil
– Information de l'utilisateur
– Test de fonctionnement
Cf. le document "CdC"

Adaptation de la démarche à l’étude
d’un petit système (1/2)
Test
(relecture)
Analyse
ECU
AMDEC
fonctionnelle
AMDEC
structurelle
Spéc.
Logicielle
Spéc.
Matérielle
Conception
du logiciel
Conception
du matériel
AMDE
fonctionnelle
AMDE
structurelle
Codage
du logiciel
Intégration
et
validation
AMDE
APR
Une seule analyse
globale

Adaptation de la démarche à l’étude
d’un petit système (2/2)
Cahier des charges
APR
AMDE
Evènements redoutés
Données critiques
Flots critiques
Spécifications du logiciel
N-versions
Fonctions critiques
BR
Tâches
SdF

ER fonctionnel
ER lié à
l’architecture
matérielle
4.2.2 - APR pour le système ECLAIR
 Trois événements redoutés critiques :
– Non-ouverture du disjoncteur sur court-circuit
hors phase d’inhibition (ER1)
– Ouverture du disjoncteur
en phase d'inhibition (ER3)
– Non décharge des condensateurs de stockage d'énergie
après l'ouverture de l'appareil (ER5)
Événement redouté
= risque d’une
fonction technique
Position de repli =
position que doit
prendre le système
si une défaillance
pouvant mener à un
événement redouté
a été détectée
 Deux positions de repli différentes :
– Ouverture du disjoncteur sur défaut risquant de provoquer ER1
hors phase d'inhibition
– Maintien du disjoncteur fermé dans tous les cas
en phase d’inhibition
Cf. le document "APR"
ER lié au profil
de
mission

Cours d’analyse des risques© ALL4TEC 2011
A ECLAIR
F23 Court-circuit détecté
A1
DEMARRER
A2
SURVEILLER
LES COURTS-CIRCUITS
A3
SURVEILLER LES CONDITIONS
DE FONCTIONNEMENT
A4
COMMANDER L'OUVERTURE
DE L'APPAREIL
E25
Liaison CAN
E24
Tension 24V
F131 Tension OK
F411
Commande disjonction BET
E26
Inhibition ouverture
F3 Défaut de fonctionnement détecté
A5
GERER L'IHM
F412
Commande disjonction MITOP1
F51 LEDs
F521 Activation test des capas
E1
Paramètres de l'appareil
E22
Courants à surveiller
E23
Capas, filerie BET
E3
Appuis boutons poussoirs
E21
Contact broche
F522 Activation test des thyristors
F131 CAN OK
F14 contact OF fermé
156
Fonction critique
= fonction dont
la défaillance
peut provoquer
un événement
redouté
Description fonctionnelle du logiciel
Commande disjonction
- MITOP
- BET
Commande relais
- position charge
- position décharge
Sorties critiques
Fonction critique
Cf. le document "Spécification détaillée"
F12,Commande relais position charge

4.2.3 - AMDE commentée
A1
DEMARRER
A11
ATTENDRE L'EMBROCHAGE
DE L'APPAREIL
A12
COMMANDER LES RELAIS
EN POSITION DE CHARGE
A13
SURVEILLER LA LIAISON CAN
ET LA TENSON 24V
A14
SURVEILLER L'ETAT
DU CONTACT OF ET DEMARRER
E25 Liaison CAN
E24 Tension 24V
F131 Tension 24V OK
F14 Contact OF fermé
F132 Liaison CAN OK
E21 Contact broche
F11 Contact embroché
F12Commande relais position charge

AMDE de A1 DEMARRER (partiel - 1/2)
SOUS-FONCTION MODE de DEF - FLUX DESCRIPTION EFFET COMMENTAIRE ER
... ... ... ... ...
A12
COMMANDER
LES RELAIS EN
POSITION DE
CHARGE
Commande charge
relais erronée (F12)
Masquage de la
Commande des relais en
position de charge
Capas non chargées
-> risque de non-
ouverture rapide
sur cc
ER1
A13 SURVEILLER
LA LIAISON CAN
ET LA TENSION
24V
Contrôle tension 24V
erroné (F131)
Tension 24V vue OK par
erreur
L'appareil peut être
fermé alors que les
conditions de fermeture
ne sont pas remplies ->
risque de non-ouverture
sur cc
ER1
Contrôle liaison CAN
erroné (F132)
Liaison CAN vue OK par
erreur
L'appareil peut être
fermé alors que les
conditions de fermeture
ne sont pas remplies ->
risque de non-ouverture
sur cc
ER1
A14 SURVEILLER
L'ETAT DU
CONTACT OF
Contrôle contact OF
erroné (F14)
Sortie Contact OF fermé
vue à FAUX par erreur à
FAUX
Appareil fermé vu ouvert
Protection inactive
-> risque de non-
ouverture sur cc
ER1
Cf. le document « AMDE hors A4 »

SOUS-FONCTION … EFFET SUR LE SYSTEME ER RECOMMANDATIONS
... ... ... ... ...
A12 COMMANDER LES
RELAIS EN POSITION
DE CHARGE
... Capas non chargées
-> risque de non-ouverture rapide
sur cc
ER1 Tester la charge des capas
A13 SURVEILLER
LA LIAISON CAN ET LA
TENSION 24V
... L'appareil peut être fermé alors
que les conditions de fermeture
ne sont pas remplies -> risque de
non-ouverture sur cc
ER1 Confirmer le bon
fonctionnement avant
d'autoriser la fermeture
Vérifier le bon
fonctionnement toutes les
heures
... L'appareil peut être fermé alors
que les conditions de fermeture
ne sont pas remplies -> risque de
non-ouverture sur cc
ER1 Confirmer le bon
fonctionnement avant
d'autoriser la fermeture
Vérifier le bon
fonctionnement toutes les
heures
A14 SURVEILLER
L'ETAT DU CONTACT
OF
... Appareil fermé vu ouvert
Protection inactive
-> risque de non-ouverture sur cc
ER1 Vérifier la vraisemblance :
Courant lu = 0 si appareil
ouvert
AMDE de A1 DEMARRER (partiel - 2/2)

La fonction A2 SURVEILLER LES CC
A2
SURVEILLER LES COURTS-CIRCUITS
F21 Courant sur les 3 phasesA21
ACQUERIR
LA MESURE DES COURANTS
A22
CALCULER
A23
DETECTER LE COURT-CIRCUIT
E12 Calibre
F22 Dérivée des courants
E13 Gabarit
E11 Période d'échantillonnage
E22 Courants à surveiller
F14 Contact OF fermé

AMDE de A2 SURVEILLER LES CC
(partiel - 1/2)
A21 ACQUERIR LA
MESURE DES
COURANTS
Valeur courant lue non
conforme à la valeur
mesurée (F21)
Valeur du courant
erronée sur une phase
Non-ouverture sur court-
circuit
ER1
A22 CALCULER Opérateurs du calcul
erronés
(In, In-1, dt) (F22)
Valeur de la dérivée
dI/dt erronée
circuit ER1
A23 DETECTER LE
COURT-CIRCUIT
Gabarit erroné ou
Comparaison avec le
gabarit erronée (F23)
Sortie "court-circuit
détecté" à FAUX par
erreur
circuit ER1
Cf. le document « AMDE hors A4 »

SOUS-
FONCTION
… EFFET SUR LE SYSTEME ER RECOMMANDATIONS
A21 ACQUERIR
LA MESURE
DES
COURANTS
… Non-ouverture sur court-
circuit
ER1 Prendre comme valeur une moyenne
d'échantillons
A22 CALCULER … Non-ouverture sur court-
circuit
ER1 Surveiller dt en contrôlant la
périodicité du calcul
A23 DETECTER
LE COURT-
CIRCUIT
… Non-ouverture sur court-
circuit
ER1 Test : insister sur le test du gabarit
Vérifier la non-corruption du gabarit
toutes les xx heures
(check-sum)
AMDE de A2 SURVEILLER LES CC
(partiel - 2/2)

Exemple de bloc de recouvrement
Algo détection cc
à partir de dI/dt Traitement CC :
ouverture rapide
Algo détection cc
à partir de I
Mise en position
de RepIi
Courant In, In-1
Courant I
Court-circuit
Cf. le document "Blocs de recouvrement (hors A4)"
Courant In

Recommandations
 Mise en place de barrières de sécurité
– Mécanismes de tolérance aux fautes
• Redondance (N-version)
• Blocs de recouvrement
Un autre algorithme de calcul du court-circuit
Vérification de cohérence : les capas doivent être chargées au
démarrage
– Autres types de barrière de sécurité
• Détection d’erreur
Vérification du gabarit de calcul en fonctionnement
• Signalisation d’erreur : alarmes
Mise en position de repli de l’appareil
Alarme « défaut de fonctionnement »

4.2.4 - Exercice
 Nous vous proposons d’étudier la fonction
COMMANDER L’OUVERTURE
– En vous appuyant sur l’APR du système …
– … et sur la description fonctionnelle ci-après
– Cherchez les modes de défaillances, les effets locaux et globaux
– Faites des recommandations pour la conception et les tests
 A vous de jouer …

Contexte de l’exercice
 Ouverture rapide
– Détecter plus vite le court-circuit et ouvrir plus vite l’appareil
– Commander ensuite une ouverture standard
– Attention : en phase d’inhibition, l’appareil ne doit pas s’ouvrir
 Rôle des capas
– Rôle des capas : fournir de l’énergie aux bobines pour l’ouverture

La fonction A4
COMMANDER OUVERTURE
Cf. le document "Spécification détaillée"
A4
F412 Commande disjonction MITOP (1)
A41
RAPIDE DE L'APPAREIL
A42
STANDARD DE L'APPAREIL
A43
COMMANDER LES RELAIS
EN POSITION DE DECHARGE
F42 Commande disjonction MITOP (2)
F43 Commande relais position décharge
F411 Commande disjonction BET
E26 Inhibition ouverture
F3 Défaut de fonctionnement détecté

AMDE de A4 COMMANDER OUVERTURE
Traiter dans l'ordre :
A41
A42
A43

AMDE de A4 COMMANDER OUVERTURE
(extrait)
SOUS-FONCTION EFFET SUR LA
FONCTION
DESCRIPTION EFFET EFFET
SUR LE SYSTEME
ER
... ... ... ... ...
A41 COMMANDER
L'OUVERTURE
RAPIDE
Commande ouverture
rapide erronée (F411)
Masquage de la commande
BET
Non-ouverture sur court-circuit ER1
Commande BET en inhibition Ouverture pendant la phase
d'inhibition
ER3
Commande ouverture
standard erronée (1)
(F412)
Commande MITOP (1) en
inhibition
Ouverture pendant la phase
d'inhibition
ER3
A42 COMMANDER
L'OUVERTURE
STANDARD
Commande ouverture
standard erronée (2)
(F42)
Masquage de la commande
MITOP (2)
Non-ouverture sur défaut
risquant de mener à ER1
ER1
Cde MITOP (2) en inhibition Ouverture pendant la phase
d'inhibition
ER3
A43 COMMANDER
LES RELAIS EN
POSITION DE
DECHARGE
Commande décharge
relais erronée (F43)
Masquage de la commande des
relais en position de décharge
Capas non déchargées après
l'ouverture de l'appareil
ER5
Cde intempestive des relais en
position de décharge
Capas non chargées
Défaut pouvant mener à ER1
ER1

Recommandations pour A4
(extrait)
SOUS-FONCTION … EFFET
SUR LE SYSTEME
ER RECOMMANDATIONS
... ... ...
A41 COMMANDER
L'OUVERTURE
RAPIDE
Non-ouverture sur
court-circuit
ER1 Mise en place d'un bloc de
recouvrement
Ouverture pendant la
phase d'inhibition
ER3 Améliorer la robustesse sur
inhibition
phase d'inhibition
ER3 Idem
A42 COMMANDER
L'OUVERTURE
STANDARD
Non-ouverture sur
défaut risquant de
mener à ER1
ER1 Mise en place d'un bloc de
recouvrement (idem précédent
avec "défaut de fonctionnement" à
la place de "court-circuit" en
entrée du BR)
phase d'inhibition
ER3 Idem
A43 COMMANDER
LES RELAIS EN
POSITION DE
DECHARGE
Capas non déchargées
après l'ouverture de
l'appareil
ER5 Défaut détecté lors de l'autotest
des condensateurs
Capas non chargées
Défaut pouvant mener
à ER1
ER1 Tester la charge des capas
SOUS-FONCTION … EFFET SUR LE SYSTEME ER RECOMMANDATION
Cf. le document « AMDE A4 »

Exemple de bloc de recouvrement
Commander
l’ouverture
rapide
Commander les
relais en position
décharge
Test capas
chargées
Repli:
ouverture
MITOP
Entrée inhibition
Court-circuit détecté
Commande BET
Liaison
CAN
Commande BET ok
Défaut Cde BET
Test de cohérence
fonctionnelle
Cf. le document "Blocs de recouvrement (A4)"

Intérêt de l’AMDE du logiciel
 L’AMDE du logiciel, outil pour la tolérance aux fautes …
– complète la démarche d’évitement des fautes (qualité logicielle)
 L’AMDE est applicable à tous les projets
– Pas besoin d’outil spécifique
– Ne nécessite pas de retour d’expérience
– S’applique aux logiciels de toute taille et à différents niveaux de
développement
 Elle facilite la diffusion de la « culture du risque » …
– … dans les équipes de développement logiciel et permet la traçabilité de
toutes les actions

Bibliographie
• Musa, Iannino, Okumoto - "Software reliability: measurement, prediction,
application" - McGraw-Hill Book Company 1987
• Basili et al. - "Experimentation in software engineering" - IEEE Trans. on
software engineering, Vol. SE-12, n° 7, July 1986
• Fenton - "Software metrics: A rigorous approach" - Chapman & Hall 1991
• Musa - "Operational profiles in software-reliability engineering" - IEEE
Software, March 1993
• ISdF - "Fiabilité du logiciel : mise en forme des travaux acquis" - projet ET
94.08
• Vallée, Vernos - "Le test et la fiabilité sont-ils antinomiques ?" - Lambda Mu
12, Montpellier, mars 2000
• ISO/IEC FDIS 9126 - "Information technology - Software product quality" -
February 1999
• Vallée, Vernos - "Comment utiliser la fiabilité du logiciel comme critère
d’arrêt du test" - Lambda Mu 13, Lyon, mars 2002
• La gestion des risques : principes et pratiques - A. Desroches, A. Leroy, F.
Vallée, Hermes Lavoisier, 2005

sûreté de fonctionnement du logiciel

sûreté de fonctionnement du logiciel

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados(20)

Destaque

Destaque(14)

Similar a sûreté de fonctionnement du logiciel

Similar a sûreté de fonctionnement du logiciel(20)

Último

Último(12)

sûreté de fonctionnement du logiciel