Évaluation du respect des exigences de sûreté des logiciels

Journée SEE - SIC
"Ingénierie des besoins"
Évaluation du respect des exigences de sûreté
des logiciels critiques dans le secteur nucléaire :
outils et perspectives.
21 octobre 2004 à l'ENST - Paris
Pascal Régnier ([email protected])
Jean Gassino ([email protected]).
Journée SEE-SIC Ingénierie des besoins. Paris, le 21 octobre 2004
1
Plan
Quelles exigences dans l’industrie nucléaire en France ?
Le rôle de l’IRSN
Définir les exigences -> réglementation, évolutions
Évaluer la satisfaction des exigences -> R&D
Conclusion
Journée SEE-SIC Ingénierie des besoins. Paris, le 21 octobre 2004
2
Principe d’une centrale nucléaire
Contrôle commande
non classé de sûreté
(régulations)
Incident
Système de protection
Observation
« passive » en
fonctionnement
normal
Agit sur
détection d’un
événement
initiateur
Journée SEE-SIC Ingénierie des besoins. Paris, le 21 octobre 2004
P
Fonctionnement normal
Exigences des systèmes nucléaires critiques
architecture du contrôle-commande
– pilotage, régulations (réglages des barres, vannes, etc..)
– protection (chute des barres)
-> systèmes physiquement différents. Le système de protection surveille,
et au besoin stoppe la réaction.
conséquences
– fonctions critiques dans des systèmes dédiés (ex: système de protection)
– tout le système de protection est critique, ses exigences fonctionnelles
sont des exigences de sûreté
Journée SEE-SIC Ingénierie des besoins. Paris, le 21 octobre 2004
4
Exigences génériques et particulières (1)
Exigences génériques… (textes réglementaires: CEI60880, RFS « logiciels »,…)
ª… sur la conception
– critère de défaillance unique (matériel) -> redondances
– autotests
– programmation défensive
– ...
ª… sur le processus de développement
– exigences sur le processus de développement (phases, vérifications
indépendantes, ..)
Journée SEE-SIC Ingénierie des besoins. Paris, le 21 octobre 2004
5
Exemple d’exigence générique
Réglementation: extrait de la Règle Fondamentale de Sûreté
(RFS II.4.1.a)
Ea 3.9. La documentation concernant chaque activité du cycle de développement du logiciel
doit comporter les relations (traçabilité*) entre les éléments décrits par cette documentation
et ceux contenus dans les documents des activités situées en amont. Le niveau de traçabilité
doit être apprécié en regard de l’exigence Ea 3.8.
Une pratique acceptable peut être de mentionner dans chaque partie d’un document les
références au(x) paragraphe(s) du (des) document(s) des activités situées en amont nécessaires
à l’établissement des relations visées par cette exigence.
Ea 3.8. La documentation et le programme exécutable du logiciel doivent permettre le
contrôle indépendant de la cohérence de chaque représentation du logiciel et de l’absence de
contradiction entre les différentes représentations.
Journée SEE-SIC Ingénierie des besoins. Paris, le 21 octobre 2004
6
Exigences génériques et particulières (2)
exigences particulières à chaque système
1
1+τp
Elaboration
– Etape 1: Études d'accidents => liste des évènements
initiateurs (accidents de référence) + vérification du
caractère enveloppe
– Etape 2: Définition des fonctions nécessaires pour
détecter chaque événement initiateur et atteindre un
état d'arrêt sûr + recherche de fonctions diversifiées
&
S R
ex: rupture de tube de générateur de vapeur
-> détection par Basse Pression circuit primaire
-> détection par Haut niveau GV
=> définition des « chaînes de protection » et
représentation graphique (complétée par des textes)
Journée SEE-SIC Ingénierie des besoins. Paris, le 21 octobre 2004
&
&
7
L’industrie nucléaire en France
- un seul exploitant de centrales (EDF)
- choix de paliers standardisés (REP 900, 1300, 1400 MW)
-> un seul constructeur de chaudières (Framatome)
-> un seul fabricant de contrôle-commande jusqu’au 1400 MW
Les interlocuteurs se connaissent depuis longtemps et ont une culture
commune.
Les besoins fonctionnels ont été élaborés lors du palier 900 (logique
câblée), puis transposés à la technologie logicielle pour les 1300 et 1400 MW
(en intégrant des évolutions fonctionnelles à chaque palier).
-> la représentation en diagrammes d’automaticiens est restée.
Journée SEE-SIC Ingénierie des besoins. Paris, le 21 octobre 2004
8
Le rôle de l’IRSN
Acteurs de la sûreté nucléaire en France
Exploitants: EDF, COGEMA, CEA,…
Autorité de sûreté: Direction Générale de la Sûreté Nucléaire et de la
Radioprotection + antennes régionales (260 personnes)
Appui technique: Institut de Radioprotection et de Sûreté Nucléaire
(expertise et recherche, 1500 personnes)
Démarche
- Analyse de la documentation produite à l'issue du cycle de développement.
(y compris code source et code binaire)
- Débat technique contradictoire
- Avis techniques délivrés par l'IRSN en vue d'une autorisation de
fonctionnement pour une installation…
Nb: Pas de "certification" d'équipements ou de logiciel
Journée SEE-SIC Ingénierie des besoins. Paris, le 21 octobre 2004
9
Action IRSN en matière de réglementation (1)
Le référentiel actuel est basé sur des textes
- nationaux (RFS II 4 1 a)
- internationaux (CEI 60880)
Les points principaux sont le « déterminisme fin », la formalisation et la
vérification « boîte blanche » de chaque étape, l’indépendance de la
vérification.
-> adéquation des exigences initiales, vérification de leur respect tout
au long du cycle de vie.
-> la "lourdeur" du cycle de vie stabilise les exigences.
Cette réglementation est très bien adaptée à des
développements « sur-mesure »
Journée SEE-SIC Ingénierie des besoins. Paris, le 21 octobre 2004
10
Action IRSN en matière de réglementation (2)
L’évolution des pratiques industrielles concerne aussi l’industrie nucléaire
(même avec du retard), et amène du bon et du .. moins souhaitable.
-> les textes réglementaires évoluent, et l’IRSN y participe activement
(CEI, RCCE, NRWG, actions internationales diverses..)
Exemple d’enjeu : COTS, CEP (« smart sensors »)
-> comment vérifier le respect des exigences du domaine nucléaire pour des
composants conçus pour un marché bien plus vaste?
-> quelles exigences alternatives mais restant «sécurisantes»?
.. problème ouvert
Journée SEE-SIC Ingénierie des besoins. Paris, le 21 octobre 2004
11
Respect des exigences ?
Évaluer le respect des exigences de sûreté est une activité technique, basée
sur des analyses du produit.
Constats simples:
- rôle primordial des logiciels de sûreté en France
- taille croissante des logiciels ( x10 à chaque palier)
- modes de défaillance spécifiques au logiciel, dus aux couplages invisibles
au niveau fonctionnel
- comportement discontinu du logiciel (if .. then .. else ..), impossibilité
du test exhaustif, limites fondamentales et pratiques à la vérification
Conclusions:
- il n’existe pas de méthode/outil de vérification définitif
- une action constante de R&D est indispensable pour que l’évaluation ne
soit pas (trop) en retard sur la technologie (introduction de noyaux temps
réel, de CEP, ..)
Journée SEE-SIC Ingénierie des besoins. Paris, le 21 octobre 2004
12
Méthodes et outils
programme de R&D : initié au milieu des années 80 (1300 MW)
- analyse dynamique :
R&D -> CLAIRE * (exécution de binaires en environnement simulé)
- analyse statique :
R&D -> AVIS (analyse de spécifications, voir plus loin)
Expérimentation MALPAS (exécution symbolique)
R&D -> FLUCTUAT * (précision numérique par interprétation abstraite)
R&D -> analyse d’impact des modifications *
utilisation Polyspace Verifier
R&D -> Chronoscope * ( analyse outillée des problèmes spécifiques au
multitâche: identifications de règles de conception
et vérification dans le code source)
R&D -> GATeL * (génération automatique de cas de test, mesure objective
de la couverture d’un ensemble de cas)
* : en collaboration avec le CEA
Journée SEE-SIC Ingénierie des besoins. Paris, le 21 octobre 2004
13
Retour d'expérience du Programme AVIS
•AVIS = Analyse pour la Validation Informatisée de Spécifications
•Programme de R&D 1994 -> 1998.
•Objectif: Développer des méthodes et outils pour une analyse plus systématique
des spécifications en langage naturel
•Approche: (linguistes + ingénieurs) => outils informatiques.
Texte en
Français
Modélisation (manuelle)
actions et objet et relations
d'après contenu grammatical du
texte
Outil NOMINO FX
(analyseur lexical)
Proto. FOCUS
Proto. EXIGENCIA
Journée SEE-SIC Ingénierie des besoins. Paris, le 21 octobre 2004
"Model checking" linguistique
Ex: instabilités lexicales
Syntagmes nominaux et verbaux…
… point de départ pour analyses
automatisées…
Identification des marqueurs de flou
Identification des marqueurs d'exigences
14
AVIS (2)
Enseignements:
- problème difficile (I.A.) pas de solution générale
- possibilité d'outils "simples" pour traiter 75 -80% des cas mais impossibilité
d'aller au delà même au prix de développement conséquents.
- sensibilitation de l'analyste 'manuel' aux notions d'instabilité lexicale, de
marqueur d'exigence et de marqueur de flou.
- … les (véritables) spécifications sont pour l'essentiel exprimées sous forme
graphique et non textuelle (Diagrammes Fonctionnels)
Journée SEE-SIC Ingénierie des besoins. Paris, le 21 octobre 2004
15
AVIS (3)
Journée SEE-SIC Ingénierie des besoins. Paris, le 21 octobre 2004
AVIS (4)
exemples de "marqueurs d'exigences"
à chaque; afin de; chaque fois que; constituée de; dans ce cas; dans la mesure où; dans le cas où;
dans toute; de la façon suivante; de manière à; de sorte que; dès que; dispose de; disposer d';
disposera des; du fait de; en fonction de; exigences; faudra; il existe; imposées au; inclus;
inférieur; jusqu' à ce qu'; jusqu' à ce que; liés à; liés à; limites; lors de; maximal; ne doit pas; ne
doivent pas; nécessaires au; nécessitent; pour; pour chaque; quand; requiert; S' il; si nécessaire;
sinon; sont les suivantes; sont les suivants; soumis à; sous réserve que; suffisante pour; suivante;
suivantes; supérieur; tel qu'; telle que; telles que; tels que; tient à; tout; toute; toutes; un seul;
une fois que; uniquement; …
Nb: sur le même principe il est possible de repérer les "marqueurs de flou" pour
identifier des exigences imprécises (ex: quelques, certaines,…).
Journée SEE-SIC Ingénierie des besoins. Paris, le 21 octobre 2004
17
GATeL
Utilisé pour la couverture des tests fonctionnels, l'outil GATeL permet au
passage un découpage d'une spécification graphique en exigences.
Spec
…
Y = A and B
Modèle
Lustre
Directives de dépliage
GATeL
Arbre de test
Cat 1: Y Vrai
Cat 1.1: A vrai B vrai
Sortie Y
Cat 2: Y faux
Cat 2.2: B faux
Cat 2.1: A faux
- Modèle Lustre direct à établir à partir des DFP.
- expression formelle du découpage
- découpage à la carte:
Exemples:
- les différentes façons de déclencher un arrêt d'urgence
- les différents comportements de chaque module du diagramme
Journée SEE-SIC Ingénierie des besoins. Paris, le 21 octobre 2004
18
Conclusion
- Exigences de sûreté critiques localisées dans des systèmes dédiés.
- Expression des exigences (spécifiques) dans un formalisme adapté à leur nature
(compromis clarté / non-ambiguité)
- Développement:
- exigence de traçabilité dans la réglementation (RFS)
- nombreuses phases de vérification indépendante (vérification du respect
de toutes les exigences issues de la phase précédente)+ validation
- la "lourdeur" du cycle de vie stabilise les exigences.
- Evaluation indépendante (du respect des exigences):
- Evaluation des dispositions en matière de tracabilité (exam cycle de vie.)
- Evaluation du contenu technique:
- exigences initiales
- respect des exigences d'une phase à la suivante..
Pistes et outils pour aller au delà de la relecture de document…
… problème difficile besoin de R&D.
===
Journée SEE-SIC Ingénierie des besoins. Paris, le 21 octobre 2004
19