Défis pour la variabilité et la traçabilité des exigences en ingénierie système

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 • 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

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

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 • 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é

5. Contexte : Quatre petites histoires à EDF1- 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é)

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

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

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

9. 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”

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

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

12. L’ingénierie des exigences dirigée par les modèlesModeling 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

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

14. Modéliser la variabilité des exigencesVue globale

15. Modéliser la variabilité des exigencesun 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

16. 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

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 • 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

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