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 logicielsFiabilité 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èmedéfaillance

système

défaillance

matériel

défaillance

logiciel

non

robustesse

défaillance

matérieldé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 diagrammeQualité

....... 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 vieapproche qualitative

fiabilité prévisionnelle

Pendant les dernières phases du cycle de vieapproche 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érenceenvironnement 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

tdFtFtf

tF

tftz

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 de uemathématiq espérance

dt

tdt

)()(

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(ˆˆ

ˆ de estimateur

tiNttR

tt

iNttztt

xx

i

i

ll


Exemple : le modèle de Littlewood-Verral

t1 t3t2

1

2

0 )1(2

1)(

l

tt

1

)()(ˆ

)( [,] edéfaillanc de taux )()(

)(ˆ

einstantané MTTF ˆ

1ˆ

)1(2

1)(ˆ

)1(2)(ˆ

1

2

01

1

1

2

0

2

00

l

l

itTFTM

iittitt

tZ

TFTM

tt

tt

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

Nm

p


Équations des distributions de M(t)

Loi binomiale

Loi de Poisson

N

mNm

N

tNt

m

NmtMP

)()()(

)(exp!

)()( t

m

tmtMP

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 10000

10

20

30

40

50

60

70

Temps de fonctionnement

No

mb

re d

e d

éfa

illa

nce

s

c:\melodev\demo\demo.mbu21/03/99 - 14:04:22

Nombre de défaillances modélisé

StatistiqueMusa-OkumotoGoel-OkumotoCrowHyper-exponentiel

4 modèles NHPP de M-élopée


Le modèle bayésien de M-élopée

0 200 400 600 800 10000

10

20

30

40

50

60

70

80


No

mb

re d

e d

éfa

illa

nce

s

c:\melodev\demo\demo.mbuDécoupage automatique - 21/03/99 - 14:06:45

Nombre de défaillances modélisé (Littlewood-Verrall)

StatistiqueMod. complète


Musa-Okumoto (logarithmique)

Crow (puissance)

Les équations des modèles

infini N

l

ll

ll

)1ln()(

0,01

)(

0

0

0

0

tt

tt

Goel-Okumoto (exponentiel)

LAAS ou (hyper-exponentiel)

fini N

)exp(1)(

0,0)exp()(

tNt

NtNt

l

infini N

l

ll

tt

Ntt

)(

10,0)( 1

10;0;1

)exp()exp(ln)(

)exp()exp(

)exp()exp()(

12

21

21

2211

l

ttt

tt

ttt

-


Les équations des modèles

Schneidewind (exponentiel) Littlewood-Verral (bayésien)

Yamada (gamma)

période la est où intervallel' dans est

fini N

TBTBt

i-t

it

ii ,

)exp(1)(

0,0)exp()(

l

1

1

2

00

1

2

0

)1(2)(

)1(2

1)(

l

tt

tt

a

a

a

ta

kt

t

kt

)(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ésultatsexamen 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

DONNEESETUDE

DE

FIABILITE


Exemple d'étude de fiabilité

essais

d'ensemble

validation

clientexploitation

arrêt ? résultats ?

fiabilité ?

maintenance ?

suivicompilateur


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 100000

10

20

30

40

50

60

70


No

mb

re d

e d

éfa

illa

nce

s

c:\melodev\demo\exemple.mbu24/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


Ind

ica

teu

r

c:\melodev\demo\exemple.mbu24/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 10000

10

20

30

40

50

60

70

80


No

mb

re d

e d

éfa

illa

nce

s

c:\melodev\demo\exemplei.mbu24/03/99 - 21:57:00

Nombre de défaillances modélisé

StatistiqueMusa-OkumotoGoel-OkumotoCrowHyper-exponentielLittlewood-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 %


Err

eu

r

c:\melodev\demo\exemple.mbuDé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

7073

Musa-Okumoto

Goel-Okumoto

500 1400 2420 4120 5370 6980 7910 110000

10

20

30

40

50

60

70


No

mb

re d

e d

éfa

illa

nce

s


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 100000

0.01

0.02

0.03

0.04

0.05


Inte

nsité

de

dé

faill

an

ce


Intensité de défaillance modélisée (Musa-Okumoto)

StatistiqueMod. complète

Mod. successives


Prévisions

essais

d'ensemble

validation

clientexploitation

arrêt ? résultats ?

fiabilité ?

maintenance ?

suivicompilateur

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 -

ExerciceL'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éfaillance3

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 3010 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

V3V2

temps

V4

locale globale ajustée


Utilisation multi-environnements -

Exercice

environnement A environnement B

environnement C

p1

p2

ll2

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

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

fonctionnementTraç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

fonctionnelleAMDE

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) = Sx

y S

Alternant

primairez

S

Sr

Bloc de recouvrement

Test

d’acceptation

Alternant

secondaire


Exemple

Calcul PressionTraitement AU

V

TPV = 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.1 – Démonstration de calculs

de fiabilité avec M-élopée©


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 rapideDé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

fonctionnelleAMDE

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-versionsFonctions 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 24VF131 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 OKF14 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)

SOUS-FONCTION MODE de DEF - FLUX DESCRIPTION EFFET COMMENTAIRE ER

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


ER1

A23 DETECTER LE COURT-CIRCUIT

Gabarit erroné ou Comparaison avec le gabarit erronée (F23)

Sortie "court-circuit détecté" à FAUX par erreur


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 IMise 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 recouvrementUn 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’erreurVérification du gabarit de calcul en fonctionnement

• Signalisation d’erreur : alarmesMise 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

SOUS-FONCTION MODE de DEF - FLUX DESCRIPTION EFFET COMMENTAIRE ER


Recommandations pour A4

(extrait)SOUS-FONCTION … EFFET

SUR LE SYSTEME ER RECOMMANDATIONS

... ... ...

A41 COMMANDER L'OUVERTURE RAPIDE


ER1

Mise en place d'un bloc de recouvrement


ER3

Améliorer la robustesse sur 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)


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éesRepli:

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)"


4.3 - Démonstration d’AMDE avec

Safety Architect©


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

Education

sûreté de fonctionnement du logiciel