66ème ème Congrès 18 – 19 octobre 2007 St DenisCongrès 18 – 19 octobre 2007 St Denis 1

Sûreté de fonctionnementdes

systèmes informatiquestemps réel

pascal.regnier@irsn.fr

66ème ème Congrès 18 – 19 octobre 2007 St DenisCongrès 18 – 19 octobre 2007 St Denis 2

Introduction

Dans le secteur médical comme dans d’autres secteurs tels que l’automobile le logiciel « critique » prend une place de plus en plus importante:

• Accélérateurs en radiothérapie;

• Robotique médicale;

• Mesure du glucose en continu….

– Quels sont les risques liés à l’utilisation de tels logiciels?

– Comment maîtriser ces risques ?

– Qu’a-t-il été mis en place en terme d’organisation dans d’autres secteurs (avionique, nucléaire, industrie)?

66ème ème Congrès 18 – 19 octobre 2007 St DenisCongrès 18 – 19 octobre 2007 St Denis 3

Identification et caractérisation du risque lié à l’utilisation de logiciels

1

Recensement des logiciels:

• PC, stations de travail

• Équipements avec poste de commande informatique, Automates

… mais aussi

• Capteurs, onduleurs, … des petits équipements, même sans interface informatique apparente peuvent

comporter du logiciel…

Etre conscient de la présence de logiciel « embarqué »

1.1

66ème ème Congrès 18 – 19 octobre 2007 St DenisCongrès 18 – 19 octobre 2007 St Denis 4

• Des accidents ont eu lieu:– Crash du vol Ariane 501– Accélérateur médical THERAC 25 (1987) 3 morts et 3 blessés graves (1986)– Arrivée d’un missile Patriot sur un baraquement Américain 28 morts (1991)

• Une Discipline récenteL’informatique est une discipline récente, en évolution très rapide, tirée par une demande grand public plus que par des considérations de très haute fiabilité.

Quelques raisons de se préoccuper du risque lié à l’utilisation de logiciels

1.2

Identification et caractérisation du risque lié à l’utilisation de logiciels

1

66ème ème Congrès 18 – 19 octobre 2007 St DenisCongrès 18 – 19 octobre 2007 St Denis 5

• Des « modes de défaillance » différents de ceux du matériel:

Quelques raisons de se préoccuper du risque lié à l’utilisation de logiciels

1.2

- «  Un système programmé produit des évènements redoutés du fait …, de l’exécution correcte des logiciels qui, dans certaines configurations, avec certaines données, produit un résultat non souhaité. »

Y. Mortureux, les Techniques de l’ingénieur / « La sûreté de fonctionnement… »

- la redondance matérielle ne résout rien pour le logiciel

- Tous les « modes de défaillance » sont a priori a envisager.

- comportement discontinu du logiciel

… cependant:

- contrairement au matériel qui fini forcément par tomber en panne, un logiciel ne s’use pas et peut éventuellement toujours fonctionner comme souhaité!

66ème ème Congrès 18 – 19 octobre 2007 St DenisCongrès 18 – 19 octobre 2007 St Denis 6

• Un objet d’une très très grande complexité combinatoire:

Quelques raisons de se préoccuper du risque lié à l’utilisation de logiciels

1.2

A

B

- 5 chemins différents entre A et B, jusqu’à 20 itérations => 520 =~1014 chemins

- 5 minutes pour concevoir, écrire et exécuter chaque test => 1 milliard d’années

Un vrai programme contient des milliers de conditions, pas juste 4!!)

=> Constat d’impossibilité du test exhaustif

Calcul sur 5 variables,32bit chacune

- 25x32 ~1048 cas différents.

- 1 million d’appels pendant 1 million d’années couvrent moins de 0,000000000000000000000000003 % des cas

=> Constat que le retour d’expérience seul ne suffit pas pour avoir un niveau de confiance élevé.

66ème ème Congrès 18 – 19 octobre 2007 St DenisCongrès 18 – 19 octobre 2007 St Denis 7

L’APR a-t-elle identifié un risque lié à la défaillance de logiciel?

2

Non Fin!

Ou

i

Le logiciel est il temps réel?3

• Logiciel « temps réel » = logiciel intégré à un équipement et qui agit directement sur les actionneurs. = Agit directement à la place de l’opérateur humain, soit en interprétant ses ordres, soit en décidant à sa place .

• Exemples:

– Contrôle commande d’un avion, d’une centrale nucléaire, d’un accélérateur médical, …

– Ne sont pas temps réel: codes de calcul, informatique de gestion (gestion des patients par exemple).

Logiciel « critique »

66ème ème Congrès 18 – 19 octobre 2007 St DenisCongrès 18 – 19 octobre 2007 St Denis 8

Le logiciel est il temps réel?3

• Miser sur la qualité du logiciel, mais surtout

• Vérification indépendante des résultats produits par le logiciel– Vérification « manuelle » (relecture interrogative) – Demande de confirmation (interrogation d’un collègue/patient)– Moyen de calcul indépendant (effectuant de préférence un calcul différent: fonction inverse, algorithme simplifié,…)

+ formaliser cette vérification

…

Non

Ou

i

66ème ème Congrès 18 – 19 octobre 2007 St DenisCongrès 18 – 19 octobre 2007 St Denis 9

La mise en œuvre d’un système de protection peut elle aider?

4

• Système de protection (SP) = Détecte un évènement initiateur et agit pour en limiter les conséquences.

Fréquence

gra

vité

Evt. initiateur

X

1

21

2

Installation sans SP

Installation + SP ok

Installation + SP ko

Evt. Initiateuret

SP K.O.

X

X

3

3

Peut réduire le problème. On se focalise sur le comportement du SP (qui peut ou non être informatisé).

66ème ème Congrès 18 – 19 octobre 2007 St DenisCongrès 18 – 19 octobre 2007 St Denis 10

S’assurer du niveau de confiance que l’on peut attendre du logiciel

5

• Qu’a-t-il été mis en place dans d’autres secteurs?1: Un classement de sûreté

APR

Classement Niveau de risqueEnsemble cohérent

d’exigences pour le développement du logiciel

Avionique(norme DO 178B)

SILA Catastrophic

B Hazardous

C Major

D Minor

E No safety effect

Industrie(norme CEI 61508)

66ème ème Congrès 18 – 19 octobre 2007 St DenisCongrès 18 – 19 octobre 2007 St Denis 11

2: Des normes relatives au développement de logiciels critiques

Quelques points clé:– Faire simple;– Séparation des systèmes selon leur classe de sûreté;– Conception saine « Déterminisme » (systèmes simples et dédiés qq milliers de lignes de codes vs qq millions);– Equipe indépendante de « Vérification et Validation » (jusqu’à 60% du coût du logiciel);– Cycle de développement strictement phasé, avec documentation et traçabilité;– Critères de couverture de test (passer par toutes les lignes, branches,…);– Tendance: utilisation d’outils « d’analyse statique » pour ‘prouver’ l’absence de certaines erreurs.

S’assurer du niveau de confiance que l’on peut attendre du logiciel

5

66ème ème Congrès 18 – 19 octobre 2007 St DenisCongrès 18 – 19 octobre 2007 St Denis 12

3: Des organismes de vérification indépendants:

– Autorités de sûreté avec moyens techniques d’investigation

- Aéronautique: DGAC

- Nucléaire: ASN (+ support technique = IRSN)

- Sociétés de conseil vérifiant la conformité à une norme

- secteur industriel (conformité à CEI 61508): Bureau Veritas, TÜV…

S’assurer du niveau de confiance que l’on peut attendre du logiciel

5

66ème ème Congrès 18 – 19 octobre 2007 St DenisCongrès 18 – 19 octobre 2007 St Denis 13

Prendre des précautions d’exploitation6

• Gestion des versions, Compatibilité entre logiciels– Surtout en cas d’échange automatique de données

=> minimiser les changements,

=> faire des tests d’ensemble.

• Assimiler le manuel, former les utilisateurs– Analyser les risques liés aux erreurs de paramétrage.

66ème ème Congrès 18 – 19 octobre 2007 St DenisCongrès 18 – 19 octobre 2007 St Denis 14

Quelques points de repère pour maîtriser les risques liés l’utilisation de logiciels:

Identification/évaluation– Identifier le logiciel (en particulier le « logiciel embarqué »)– Prendre conscience de la nature particulière des « modes défaillance »

du logiciel.

Maîtrise: Développer des logiciels très fiable est coûteux est possible uniquement pour des fonctions simples =>– Stratégie d’évitement lorsque cela est possible:

• Miser sur des moyens de vérifications indépendant du logiciel• Utiliser un système de protection

– Sinon,• Utiliser du logiciel développé selon des normes de sûreté.• Prendre des précautions d’exploitation, notamment/changements de

versions.

Conclusion