Title: D
1Défis pour la variabilité et la traçabilité des
exigences en ingénierie système
- Nicolas SANNIER, et Benoît BAUDRY
- EDF RD INRIA Rennes
2Plan
- Contexte industriel Quatre petites histoires à
EDF - A propos des exigences réglementaires/normatives
- Défis
- Lingénierie des exigences dirigée par les
modèles - Modéliser la variabilité des exigences
- Traçabilité des exigences
- Conclusion
3Contexte Quatre petites histoires à EDF0-
Préambule
- Concevoir des systèmes importants pour la sûreté
- Distinction
- entre les fonctions importantes pour la sûreté
(classées A, B ou C / F1a, F1b ou F2) et celles
pas importantes pour la sûreté (NC) - et les systèmes importants pour la sûreté (E1a,
E1b, E2) et les autres (NC) - Règles dassignation entre fonctions et systèmes
- Les systèmes importants pour la sûreté font
lobjet dune démonstration de sûreté
4Contexte Quatre petites histoires à EDF 1-
Début 1990 Contrôle-commande du palier N4 (1/2)
- Conception du système de contrôle-commande du N4
- Introduction de composants programmés dans des
systèmes classés - LASN (autorité de sûreté nucléaire) ne connaît
bien pas ces composants - Pas de références sur lesquelles se baser
- Attendre et discuter les propositions dEDF
- depuis 1986, la norme CEI 60880 software for
computers in the safety systems of nuclear power
stations - Décisions dEDF
- CEI 60880 pour ses systèmes remplissant des
fonctions de cat. A - Proposer ses propres justifications pour les
autres systèmes classés - Lutilisation des normes comme partie intégrante
de la démonstration de sûreté
5Contexte Quatre petites histoires à EDF 1-
Début 1990 Contrôle-commande du palier N4 (2/2)
- Questions de lASN autour du code inutilisé des
composants programmés - Partie intégrale du composant
- Risque de mauvais comportement (?)
- Volonté denlever ces fragments non utilisés
- Le code non utilisé hors scope de la 60880
- Discussion et démonstration de sûreté
- EDF devra justifier la conservation des fragments
de code non utilisés (pour tout ses systèmes
remplissant des fonctions importantes pour la
sûreté)
6Contexte Quatre petites histoires à EDF2- Aux
environs de 2007 Conception du CC EPR en France
- Début des années 2000
- Nouvelles normes publiées
- 60880-2001 Software aspects for computer-based
systems performing category A functions - 62138-2004 Software aspects for computer-based
systems performing category B or C functions - Nouvelle réglementation française
- Règles fondamentales de sûreté (RFS) de lASN
- Projet EPR
- Contexte européen
- Réutiliser au mieux les développements du palier
N4 - Nouvelle tendance technologique
linstrumentation intelligente - Les normes comme support au développement pour
les systèmes réalisant des fonctions importantes
pour la sûreté
7Contexte Quatre petites histoires à EDF2- Aux
environs de 2007 passage du CC EPR en Angleterre
- Le même projet mais construit en Angleterre
- Même documents de référence Les normes CEI
- Safety Assessment Principles au lieu des RFS
- Différence dans linterprétation des normes
- Pratique différence de la France
- Des approches particulièrement détaillées
- Une culture par approche probabiliste
- Les bases de la démonstration de sûreté en
Angleterre - Une approche uniquement complémentaire en France
(plutôt déterministe)
8Contexte Quatre petites histoires à EDF4- Et si
on construisait un EPR aux USA ?
- Les normes CEI en Europe, les normes IEEE aux USA
- Est-ce que les méthodes sont acceptables dans ce
contexte ? - Est-ce que les développements EPR sont compatible
au marché US ? - Compatibilité vis-à-vis de la réglementation
- Problème dalignement des documents
- Problème dinterprétation des documents
- Alignement des termes
- Compatibilité des choix dingénierie pour
larchitecture - Démonstration de sûreté
9A propos des exigences réglementaires/normatives
- Les normes représentent le meilleur de létat de
lart - Des guides méthodologiques
- Améliore la fiabilité, lefficience, la
réutilisation, la confiance - Contiennent des exigences, des recommandations,
des annexes - Nimposent rien, leur application est sur une
base volontaire - Différence entre
- Exigence normative qui dit ce quil est bon de
faire - Exigence réglementaire qui impose ce quil y a à
faire - Une exigence normative devient véritablement une
exigence - Quand lautorité de sûreté impose lapplication
de la norme - Linterprétation des normes constitue une partie
de la pratique
10Défis
- Ces quatre histoires nous montrent la nécessité
- De suivre lévolution des normes et de la
réglementation - De prendre en compte linterprétation de ces
textes dans différents contextes - Connaître les écarts entre les différentes
pratiques - Ces projets impliquent la participation de
nombreuses personnes pendant des décennies - Avec des cultures et des préoccupations
différentes voire orthogonales - Les documents sous forme textuelle comme vecteur
principal pour les informations - Une accumulation dexpertises partielles et
individuelles sur le sujet - Particulièrement dépendantes de la gestion des
ressources humaines - De la nécessité de formaliser cette connaissance
- Unification et capitalisation
11Lingénierie des exigences dirigée par les
modèles Un problème à la convergence de
plusieurs domaines
12Lingénierie des exigences dirigée par les
modèlesModeling is modeling
- Un modèle nest quune représentation de la
réalité pour une préoccupation donnée - Une vision simplifiée mais utile et
opérationnelle - Bien plus quun dessin à oublier dans un dossier
- MBSE Un saut de paradigme (du document vers les
modèles) - Apport de lIDM
- La meta-modélisation comme cadre structurel
- Conformité (par construction) des modèles à leur
méta-modèle - Des capacités danalyses vis-à-vis de ce DSML
- Séparation des préoccupations
- Composition de modèles
- Transformation de modèles
13Modéliser la variabilité des exigences
- Eléments de variabilité
- Au niveau documentaire
- Document
- Interprétation
- Au niveau de la pratique
- Faire le pont entre les pratiques
- Formaliser les dépendances entre pratiques
- Raffinements (composition et plus)
- Interactions (références, conflits,
dépendances , équivalence, couverture ) - Pour quun projet futur puisse satisfaire
plusieurs pratiques - Comparaison entre pratiques sur plusieurs niveaux
- Synthèse de ces dépendances dans un modèle global
du projet
14Modéliser la variabilité des exigencesVue globale
15Modéliser la variabilité des exigencesun exemple
- Exemple dinterprétation et de choix
- Norme NF EN 62138-2009
- CSCT rénovation du RIC (instrumentation du cœur)
pour les VD3-1300 (2010) - 7. SPECIFICATIONS RELATIVES AU
DEVELOPPEMENT DU PROJET - 7.1. PHASES DU CYCLE DE DEVELOPPEMENT DE LA
FOURNITURE - 7.1.1. Spécifications relatives aux études
- 7.1.1.1. Validation des données dentrée par
analyse sur site
16Traçabilité des exigences
- Capitaliser des choix, des décisions faites des
années auparavant - Pourquoi est-ce quon a gardé cette exigence
bizarre en 2005 ? - Plutôt quune autre plus importante sur les modes
de vérification par exemple - A notre niveau
- Aligner la documentation et la pratique dune
manière plus formelle - Connaître les impacts des changements tout au
long du projet
17Conclusion et perspectives
- Un saut des approches centrées document vers les
modèles - Des artéfacts textuels à des éléments de modèle
- Dune connaissance partielle et implicite à un
référencement explicite - La modélisation pour
- La formalisation et la capitalisation de cette
expertise humaine - Gérer, analyser, tirer de linformation de ces
éléments - Travaux futurs
- Vers un autre Doors/Caliber/Artisan
Studio/Reqtify/Unicase-like? - Pas le même domaine ni le même niveau
dabstraction - Apport de sémantique supplémentaire (typage,
dépendances formalisées) - Dans une approche multi-projets
18Merci de votre attention !Time for questions,
ideas, shoes (?)
- Nicolas.sannier _at_inria.fr - _at_edf.fr