La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Défis pour la variabilité et la traçabilité des exigences en ingénierie système Nicolas SANNIER *,** et Benoît BAUDRY ** *EDF R&D – **INRIA Rennes.

Présentations similaires


Présentation au sujet: "Défis pour la variabilité et la traçabilité des exigences en ingénierie système Nicolas SANNIER *,** et Benoît BAUDRY ** *EDF R&D – **INRIA Rennes."— Transcription de la présentation:

1 Défis pour la variabilité et la traçabilité des exigences en ingénierie système Nicolas SANNIER *,** et Benoît BAUDRY ** *EDF R&D – **INRIA Rennes

2 Plan I.Contexte industriel : Quatre petites histoires à EDF II.A propos des exigences réglementaires/normatives III.Défis IV.Lingénierie des exigences dirigée par les modèles V.Modéliser la variabilité des exigences VI.Traçabilité des exigences VII.Conclusion 2

3 Contexte : Quatre petites histoires à EDF 0- 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é 3

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 : software for computers in the safety systems of nuclear power stations Décisions dEDF – CEI 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é 4

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

6 Contexte: Quatre petites histoires à EDF 2- Aux environs de 2007 – Conception du CC EPR en France Début des années 2000 – Nouvelles normes publiées : Software aspects for computer-based systems performing category A functions 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é 6

7 Contexte: Quatre petites histoires à EDF 2- 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) 7

8 Contexte: Quatre petites histoires à EDF 4- 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é 8

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 9

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 10

11 Lingénierie des exigences dirigée par les modèles Un problème à la convergence de plusieurs domaines 11 Model-Driven Engineering (meta)modeling, SysML, separation of concerns, model composition, model transformation… Product Line Engineering variability, product lines, features… Requirements Engineering requirements analysis, management, goal oriented RE, legal conformance, ambiguity … We are here ! Systems Engineering document-centric processes, I&C systems, nuclear safety, practice, standards, …

12 Lingénierie des exigences dirigée par les modèles Modeling 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 12

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 13

14 Modéliser la variabilité des exigences Vue globale 14

15 Modéliser la variabilité des exigences un exemple 15 Exemple dinterprétation et de choix – Norme NF EN – CSCT rénovation du RIC (instrumentation du cœur) pour les VD (2010) – 7. SPECIFICATIONS RELATIVES AU DEVELOPPEMENT DU PROJET 7.1. PHASES DU CYCLE DE DEVELOPPEMENT DE LA FOURNITURE – Spécifications relatives aux études – Validation des données dentrée par analyse sur site

16 Traçabilité des exigences 16 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 17

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


Télécharger ppt "Défis pour la variabilité et la traçabilité des exigences en ingénierie système Nicolas SANNIER *,** et Benoît BAUDRY ** *EDF R&D – **INRIA Rennes."

Présentations similaires


Annonces Google