Nicolas SANNIER*,** et Benoît BAUDRY** *EDF R&D – **INRIA Rennes 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

Plan Contexte industriel : Quatre petites histoires à EDF A propos des exigences réglementaires/normatives Défis L’ingénierie des exigences dirigée par les modèles Modéliser la variabilité des exigences Traçabilité des exigences Conclusion

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 d’assignation entre fonctions et systèmes Les systèmes importants pour la sûreté font l’objet d’une démonstration de sûreté

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 L’ASN (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 d’EDF depuis 1986, la norme CEI 60880 : software for computers in the safety systems of nuclear power stations Décisions d’EDF CEI 60880 pour ses systèmes remplissant des fonctions de cat. A Proposer ses propres justifications pour les autres systèmes classés L’utilisation des normes comme partie intégrante de la démonstration de sûreté

Contexte : Quatre petites histoires à EDF 1- Début 1990 – Contrôle-commande du palier N4 (2/2) Questions de l’ASN autour du code inutilisé des composants programmés Partie intégrale du composant Risque de mauvais comportement (?) Volonté d’enlever 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é)

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 : 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 l’ASN Projet EPR Contexte européen Réutiliser au mieux les développements du palier N4 Nouvelle tendance technologique : l’instrumentation intelligente Les normes comme support au développement pour les systèmes réalisant des fonctions importantes pour la sûreté

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 l’interpré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)

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 d’alignement des documents Problème d’interprétation des documents Alignement des termes Compatibilité des choix d’ingénierie pour l’architecture Démonstration de sûreté

A propos des exigences réglementaires/normatives Les normes représentent le meilleur de l’état de l’art Des guides méthodologiques Améliore la fiabilité, l’efficience, la réutilisation, la confiance Contiennent des exigences, des recommandations, des annexes … N’imposent rien, leur application est sur une base volontaire Différence entre : Exigence normative qui dit ce qu’il est bon de faire Exigence réglementaire qui impose ce qu’il y a à faire Une exigence normative devient véritablement une exigence : Quand l’autorité de sûreté impose l’application de la norme L’interprétation des normes constitue une partie de la “pratique”

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 l’interpré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 d’expertises 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

L’ingénierie des exigences dirigée par les modèles Un problème à la convergence de plusieurs domaines 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, …

L’ingénierie des exigences dirigée par les modèles Modeling is modeling Un modèle n’est qu’une représentation de la réalité pour une préoccupation donnée Une vision simplifiée mais utile et opérationnelle Bien plus qu’un dessin à oublier dans un dossier MBSE : Un saut de paradigme (du document vers les modèles) Apport de l’IDM La meta-modélisation comme cadre structurel Conformité (par construction) des modèles à leur méta-modèle Des capacités d’analyses vis-à-vis de ce DSML Séparation des préoccupations Composition de modèles Transformation de modèles

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 qu’un 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

Modéliser la variabilité des exigences Vue globale

Modéliser la variabilité des exigences un exemple Exemple d’interpré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 d’entrée par analyse sur site

Traçabilité des exigences Capitaliser des choix, des décisions faites des années auparavant Pourquoi est-ce qu’on a gardé cette exigence bizarre en 2005 ? Plutôt qu’une autre plus importante sur les modes de vérification par exemple A notre niveau : Aligner la documentation et la pratique d’une manière plus formelle Connaître les impacts des changements tout au long du projet

Conclusion et perspectives Un saut des approches centrées document vers les modèles Des artéfacts textuels à des éléments de modèle D’une 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 l’information 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 d’abstraction Apport de sémantique supplémentaire (typage, dépendances formalisées) Dans une approche multi-projets

Merci de votre attention ! Time for questions, ideas, shoes (?) Nicolas.sannier {@inria.fr - @edf.fr}