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

I. Contexte industriel : Quatre petites histoires à EDFII. A propos des exigences réglementaires/normativesIII. DéfisIV. L’ingénierie des exigences dirigée par les modèlesV. Modéliser la variabilité des exigencesVI. Traçabilité des exigencesVII. Conclusion

2

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é

3

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é

4

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

5

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é

6

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)

7

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é

8

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”

9

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

10

L’ingé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 Engineeringdocument-centric processes, I&C systems,

nuclear safety, practice, standards, …

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

12

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

13

Modéliser la variabilité des exigencesVue globale

14

Modéliser la variabilité des exigencesun exemple

15

• 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

16

• 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

17

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

Nicolas.sannier {@inria.fr - @edf.fr}