D

1
Dé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

2
Plan

1. Contexte industriel Quatre petites histoires à
   EDF
2. A propos des exigences réglementaires/normatives
3. Défis
4. Lingénierie des exigences dirigée par les
   modèles
5. Modéliser la variabilité des exigences
6. Traçabilité des exigences
7. Conclusion

3
Contexte 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é

4
Contexte 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é

5
Contexte 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é)

6
Contexte 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é

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

8
Contexte 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é

9
A 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

10
Dé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

11
Lingénierie des exigences dirigée par les
modèles Un problème à la convergence de
plusieurs domaines
12
Lingé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

13
Modé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

14
Modéliser la variabilité des exigencesVue globale
15
Modé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

16
Traç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

17
Conclusion 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

18
Merci de votre attention !Time for questions,
ideas, shoes (?)

• Nicolas.sannier _at_inria.fr - _at_edf.fr