Méthode de réconciliation de données certifiée VDI2048 et principes théoriques associés

La division Recherche et Développement (R&D)

Présentation

EDF R&D a pour missions principales de contribuer à l’amélioration de la performance des unités opérationnelles du Groupe EDF et d’identifier et préparer les relais de croissance à moyen et long terme. La Recherche et Développement est une activité stratégique en lien direct avec le projet industriel d’EDF. Basé sur une collaboration d’acteurs internes avec des partenaires industriels et académiques internationaux, EDF R&D s’est articulée depuis 2003 en 12 défis, regroupés par thèmes : Notre planète, Notre optimisation, Les clients, La production, Les réseaux et un défi transverse sur la simulation numérique. Ces champs de recherche sont les plus importants pour le Groupe EDF et recouvrent l’ensemble des métiers de l’entreprise. Le pôle R&D est constitué d’environ 2000 personnes pour un budget de 375 M €/an. Il se décompose en 12 départements dont le département STEP (Simulation et Traitement de l’information pour l’Exploitation des systèmes de Production).

Le département STEP

Pour la réalisation de mon mémoire d’ingénieur, j’ai intégré le groupe P1C « Fonctionnement et Conduite » du département STEP. Ce département a pour mission d’aider l’exploitant des moyens de production du Groupe EDF (nucléaire, thermique à flamme, hydraulique, énergies renouvelables…). Il ’accompagne dans la conduite, la surveillance et le maintien des installations existantes et à venir, en prenant en compte le cadre réglementaire évolutif en termes de sûreté et d’environnement. Le département STEP développe des modèles à l’échelle système des moyens de production, réalise des expérimentations sur modèles physiques ou directement sur les sites de production. L’unité est divisée en 5 groupes et compte environ 130 personnes dont 110 cadres et chercheurs, 20 techniciens, 20 doctorants. Ses principales activités contribuent:
– à la maîtrise du contrôle-commande et à la démonstration de sa sûreté de fonctionnement;
– au développement d’outils d’aide à la conduite;
– à l’amélioration de la qualité et de la précision des mesures;
– à l’adaptation de la production aux besoins des réseaux;
– à l’optimisation de la surveillance des matériels et des ouvrages;
– au développement de systèmes d’informations supports;
– à l’amélioration de la sécurité des intervenants (radioprotection);
– à la simplification et à l’amélioration des processus « arrêt de tranche » et « tranche en marche » en proposant l’intégration de nouvelles technologies.
Le groupe P1C possède une expertise sur le fonctionnement des installations EDF, et développe des méthodes d’aide à l’exploitation pour optimiser les performances énergétiques tout en  respectant les contraintes évolutives liées à la sûreté et l’environnement. Une part de son activité repose notamment sur le recours à la modélisation et à la simulation des process à l’échelle 0D/1D (ou échelle dite « système »). Dans ce cadre, mon projet de fin d’étude fait partie intégrante du projet de recherche européen « OpenProd» (Open Model-Driven Whole-Product Development and Simulation Environment).

Contexte de l’étude

Le projet OpenProd

Présentation du projet

Le projet OpenProd [12] (Open Model-Driven Whole-Product Development and Simulation Environment) implique 28 partenaires académiques et industriels. Ce projet est une des 120 composantes du programme de recherche européen ITEA2 concernant l’ingénierie logicielle et système. Le but du projet OpenProd est de fournir un environnement logiciel pour le développement de codes et de systèmes complexes en utilisant la modélisation à l’échelle système. Développé sous la plate-forme open source Eclipse, cet environnement vise notamment à rester relativement ouvert en intégrant des outils aussi bien open source que commerciaux, basés sur les langages standardisés Modelica et UML.

EDF R&D dans le projet OpenProd

EDF R&D participe au projet OpenProd:
– au niveau des lots 2 et 5 : dans l’objectif d’aborder les problématiques relatives à l’ingénierie des exigences à travers un couplage entre les langages Modelica et UML et de préparer ainsi les outils d’ingénierie pour la modernisation du contrôle-commande des tranches nucléaires;
– au niveau du lot 3 : en vue notamment de pouvoir introduire, dans les modèles Modelica de centrales de production d’énergie existants à EDF, la notion d’incertitudes et les études qui en découlent (e.g. propagation des incertitudes à travers un modèle et réconciliation de données);
– au niveau du lot 6 : pour tester, sur des cas d’études concrets, les avancées logicielles qui auront été développées au cours du projet dans le cadre des lots 2, 3 et 5.
L’étude suivante intervient au niveau du lot 3 du projet OpenProd, dans le cadre de la gestion des incertitudes dans les modèles Modelica et se focalise plus particulièrement sur la méthode de réconciliation de données appliquée aux modèles de simulation EDF.
Dans ce cadre, une expression des besoins EDF [3] a été livrée en 2010. Cette étude s’insère donc dans la phase de conception préliminaire du projet (cf. Figure 4 , cycle en V), la société Mathcore Engineering AB, partenaire EDF dans le cadre du projet OpenProd, ayant réalisé un premier prototype opérationnel dès le début du stage.

Objectifs du stage

Problématique du stage (cf. ANNEXE 7.1)

La majorité des projets EDF en centrales nucléaires concerne les installations en cours d’exploitation (e.g. revalorisation de la production d’énergie, amélioration de la fiabilité, …) et la construction de nouvelles installations (nucléaires, renouvelables…). Dans ce contexte, EDF a acquis une grande expertise dans le domaine de la modélisation et de la simulation des installations de production d’énergie. Cette expertise s’appuie essentiellement sur la modélisation des différents process à l’échelle 0D/1D. Dans ce cadre, un des axes de recherche actuels est notamment d’améliorer la connaissance des systèmes en confrontant les prédictions théoriques aux données réelles issues de capteurs sur site. L’introduction de la notion de mesures incertaines peut en particulier améliorer ou qualifier la qualité de la prédiction du modèle par la méthode de réconciliation de données.
Les techniques de réconciliation de données et de détection des erreurs grossières se sont développées durant ces 35 dernières années. Ces techniques sont largement appliquées dans les raffineries, usines pétrochimiques, nucléaires (Installation de Leibstadt en Suisse) et dans les industries de transformation des minéraux. A partir d’informations redondantes (mesures + incertitudes), la technique de réconciliation de données permet d’améliorer l’exactitude des mesures i.e. de réduire la valeur des incertitudes des mesures corrigées ou « réconciliées ». La norme allemande VDI2048 [5] régit en particulier l’application de cette méthode dans le domaine de l’énergie.
La réconciliation de données intéresse EDF dans le but de détecter les dérives potentielles de capteurs.
En milieu industriel, la technique de réconciliation de données présente plusieurs avantages:
– Réduction des coûts dus aux mesures :
– réduction de la fréquence de la calibration des capteurs : seulement les capteurs défectueux sont contrôlés;
– réduction du nombre d’analyse de routine.
– Contrôle du procédé:
– capacité à donner en temps réel des informations précises sur le process;
– détection immédiate de la déviation de capteurs et de la dégradation des performances des équipements;
– Qualité au niveau process.

LA MODELISATION 0D/1D POUR LES PROCESS ENERGETIQUES

Avant d’aborder les spécificités du prototype pour la réconciliation de données en Modelica, le chapitre 3 introduit la notion de modélisation 0D/1D pour les process énergétiques.

Le langage Modelica

Notion de modèle à l’échelle système

D’après, le langage Modelica est un langage de description de systèmes mathématiques orienté objet. Il est gratuit et non propriétaire. Dans le contexte de la modélisation physique, il permet de représenter le comportement dynamique de systèmes complexes impliquant n’importe quel domaine de la physique. Son originalité relève principalement du fait qu’il permet une description hiérarchisée et acausale du système, deux propriétés utiles à la construction et à la gestion des bibliothèques de modèles.

Historique

D’après [19],initiée par ELMQVIST de la société DYNASIM AB, l’élaboration du langage Modelica a commencé en 1996 dans le cadre du projet ESPRIT SIE-WG, visant en priorité à augmenter la réutilisabilité et la portabilité des modèles. Plusieurs développeurs de langages industriels participèrent à l’élaboration de ce projet jusqu’en décembre 1999 où sont apparues les premières spécifications fonctionnelles du langage Modelica. Les évolutions sont désormais régies dans le cadre d’une association à but non lucratif : l’association Modelica.

Principales caractéristiques du langage

D’après [19], le langage Modelica est un langage:
– non lié à une discipline ou à un métier : il permet de décrire de manière unifiée différents domaines de la physique et assure ainsi une certaine portabilité.
– orienté objet avec les propriétés d’encapsulation et d’héritage: ceci permet de créer notamment des modèles hiérarchisés et facilite la définition de modèles très génériques et donc réutilisables.
– acausal : les équations ne sont orientées qu’une fois que le code est compilé. Cette caractéristique est une caractéristique fondamentale du langage. Elle s’appuie sur une écriture formelle des équations du modèle.
– non lié à un propriétaire ce qui permet de diminuer les dépendances vis-à-vis de fournisseurs de logiciels spécifiques et assure ainsi une certaine pérennité des modèles.
La structure d’un objet« class» ou « model» est découpée en deux sections principales :
– l’une pour la déclaration des paramètres et des variables, de la balise « model » à « equation»
– et l’autre pour l’écriture du modèle sous forme équationnelle, de la balise « equation » à « end»

Simulation d’un modèle Modelica

Pour que le modèle soit simulable, il doit comporter autant d’équations que d’inconnues et le système d’équations défini par le modèle (des balises « equation » à « end» ) doit être soluble.
Une fois que la phase d’élaboration du modèle est terminée, l’utilisateur exécute la compilation. Une erreur est générée s’il n’est pas simulable, autrement, l’interface graphique Modelica permet de paramétrer le modèle pour la simulation.
Simuler un modèle consiste à résoudre le système des équations du modèle à partir des paramètres et des données d’entrée renseignées par l’utilisateur. A la fin d’un calcul de simulation, pour un point de fonctionnement donné, l’état du système est parfaitement connu. Le process peut être en régime dynamique ou en régime permanent. Les valeurs de chaque paramètre sont directement accessibles et les courbes d’évolution des variables au cours du temps peuvent être affichées.

Exemples de logiciels de simulation de modèles Modelica

Pour la prise en main et la compréhension des modèles Modelica, des modèles simplistes ont été créés au cours du stage sur les plateformes Dymola et MathModelica basées sur le langage Modelica.
Globalement, ces trois outils logiciels sont composés:
– d’un modeleur graphique, qui permet de modéliser des systèmes élémentaires (équations physiques des équipements) et de construire, par assemblage, des modèles de process complexes;
– d’un générateur de code ayant pour fonction de construire le simulateur à partir des équations physiques du système. L’utilisateur a, en général, le choix entre plusieurs solveurs et plusieurs méthodes d’intégration (Dassl, Euler,…);
– Une interface pour le calcul et le pilotage de la simulation;
– Un traceur de courbes.

Observabilité/Redondance

Notions d’observabilité et de redondance
Pour un système donné, séparons les variables d’intérêt en deux sous-ensembles:
– Le sous-ensemble des mesures réconciliées ;
– Le sous-ensemble des variables non-mesurées (????).
La notion d’observabilité apparaît avec la prise en compte des variables non-mesurées. Elle permet d’étendre l’apport de la réconciliation de données aux données non-mesurées. Les relations décrites par le modèle du process définissent un nouveau système équationnel qui permet d’estimer la valeur des variables non-mesurées en fonction des mesures réconciliées. Les données non-mesurées sont déduites à partir de ces équations. Ces données sont dites observables si le système d’équation est soluble. Par exemple, en milieu industriel, la notion d’observabilité permet d’estimer une grandeur si le capteur dédié est défaillant ou inactivé.
Le critère d’observabilité donne une information complémentaire sur le système. Cette fonctionnalité pourra être intégrée dans le prototype OpenProd.

Définition des concepts d’observabilité et de redondance

Définition de l’observabilité [9] : On dit qu’une variable est observable si elle est estimable à partir des mesures et des équations du modèle statique du process.
Définition de la redondance [9] : Une variable mesurée est redondante si elle reste observable lorsque les mesures qui lui sont associées sont retirées.
Cette dernière définition revient à considérer comme redondantes, les variables mesurées que l’on peut estimer à partir d’autres valeurs mesurées.

Rappel

On appelle conditions auxiliaires, les contraintes du problème de réconciliation. Ces contraintes sont les équations du modèle qui n’impliquent que des variables mesurées.
Les notions d’observabilité et de redondances sont liées. Le degré de redondance indique le nombre de conditions auxiliaires réduites du problème de réconciliation. Plus le degré de redondance est grand, plus l’information disponible sur le process est riche (modèle équationnel + mesures issues des capteurs). Ce critère de redondance donne une information complémentaire sur le modèle. Cette fonctionnalité pourra être intégrée dans le prototype.
Ces deux notions dépendent de la topologie du réseau de capteurs, et de la capacité à pouvoir déterminer la valeur d’une variable mesurée (redondance) ou non-mesurée (observabilité) de manière indirecte, en fonction des autres mesures du système.

Définition

On appelle problème de coaptation, le problème d’observabilité des valeurs non-mesurées à partir des valeurs mesurées (ou des valeurs réconciliées).
L’analyse de l’observabilité du système se décompose en deux sous-problèmes:
1) Ecriture des conditions auxiliaires : un problème de réconciliation de données réduit, qui résout uniquement les variables réconciliées.
2) Ecriture d’un problème de coaptation pour calculer et estimer les variables non-mesurées. Remarque:
On considère toute variable mesurée comme étant une variable à réconcilier.

Choix des cas-tests

La version actuelle du prototype ne permet pas de tester toutes les fonctionnalités:
– La fonctionnalité F1 : « Importation d’un modèle Modelica EDF» n’est pas valide car la bibliothèque ThermosysPro n’est pas entièrement supportée par la version actuelle du prototype(les modèles des cas-tests 1 et 2 ont toutefois été construits à partir de la librairie ThermosysPro dans le cadre du stage, pour préparer la deuxième phase de validation).
– Certaines sous-fonctionnalités de la fonctionnalité F2 : « Formulation du problème de réconciliation à partir d’un modèle Modelica (ETAPES 1, 2, 3) » ne peuvent être testées car elles ne sont pas implémentées dans la version actuelle du prototype.
Du fait de la non-compatibilité des modèles EDF avec la version actuelle du prototype, les modèles de tests ont été écrits directement en langage Modelica. Seul le modèle du test 1-2 a été créé à partir d’une bibliothèque Modelica développée par la société MathCore AB.
Le cas-test n°1 concerne un process simple et permet de valider essentiellement la fonctionnalité F2: « Formulation du problème de réconciliation à partir d’un modèle Modelica (ETAPES 1, 2, 3) ».
Les modèles associés sont formulés à partir d’équations linéaires (bilans massiques) puis nonlinéaires (bilans massiques + bilans d’énergie). Toutes les sous-fonctionnalités relatives à la fonctionnalité F2« Formulation du problème de réconciliation à partir d’un modèle Modelica (ETAPES 1, 2, 3)», sont testées dans le test 1-1-1. Le cas test n°1 couvre l’ensemble des principales situations possibles lors de la résolution d’un problème de réconciliation de données.
Le cas-test n°2 concerne un process industriel, modélisé très simplement à partir de simples bilans massiques. Ce cas d’étude est issu de la norme VDI 2048 et permet de tester la fonctionnalité F3: « Réconciliation de données à partir de modèle externe (ETAPES 4, 5, 6) ». Le processus de validation est précisément décrit dans le test 2-1-1.
Le cas-test n°3 concerne un process industriel simple issu de la littérature [9]. Le modèle associé est linéaire et intègre les bilans massiques. Des résultats de référence issu du document [9] permettent de tester la fonctionnalité F3: « Réconciliation de données à partir de modèle externe (ETAPES 4, 5, 6)». Un algorithme développé au cours du stage et spécifique à ce test, permet d’aborder la notion de « redondance et observabilité » dans l’optique de l’implémentation d’une fonctionnalité SF11: « d’aide à l’utilisateur pour la réconciliation de données ».
Le cas-test n°4 concerne une colonne de distillation binaire (i.e. à deux composés chimiques) [9].
Certaines équations du modèle sont des équations bilinéaires. Le modèle intègre les bilans massiques globaux sur toute la colonne ainsi que les équations de normalisation des fractions molaires de chaque composé chimique. Les résultats de référence issus du document [9] permettent de tester la fonctionnalité F3: « Réconciliation de données à partir de modèle externe (ETAPES 4, 5, 6) » et de tester la performance de la version itérative de l’algorithme de résolution, implémentée au cours du stage.
Le protocole de test a été développé afin de cibler les fonctionnalités et le comportement du prototype actuel. D’une manière générale, la validation est décrite très précisément dans les premiers tests de chaque cas-test. Les divergences par rapport aux fonctionnalités déjà validées sont elles-mêmes décrites. Le protocole de test s’accompagne de remarques et d’analyses des phénomènes observés, et permet de se familiariser avec les méthodes de réconciliation de données et de détection d’erreurs grossières.

Table des matières

1. INTRODUCTION 
1.1. PRESENTATION DE L’ENTREPRISE
1.1.1. Le Groupe EDF
1.1.2. Mix énergétique de la production EDF
1.1.3. Les enjeux du Groupe dans les 5 à 10 ans à venir
1.1.4. La division Recherche et Développement (R&D)
1.2. CONTEXTE DE L’ETUDE
1.2.1. Le projet OpenProd
1.2.2. Objectifs du stage
1.3. STRUCTURE DE L’ETUDE
2. METHODE DE RECONCILIATION DE DONNEES CERTIFIEE VDI2048 ET PRINCIPES THEORIQUES ASSOCIES 
2.1. ETAPE 1: CHOIX DES MESURES xA RECONCILIER
2.1.1. Notion de redondance spatiale et temporelle
2.2. ETAPE 2: DETERMINATION DES INCERTITUDES ASSOCIEES A CHAQUE MESURE ET CALCUL DE LA MATRICE DE COVARIANCE xS
2.3. ETAPE 3: DETERMINATION DES CONDITIONS AUXILIAIRES ( ) ⋅ f
2.4. ETAPE 4: CALCUL DES VALEURS RECONCILIEES xˆ
2.5. ETAPE 5 : CALCUL DES INCERTITUDES ASSOCIEES AUX VALEURS RECONCILIEES
2.6. ETAPE 6: ANALYSE DES DONNEES RECONCILIEES
3. LA MODELISATION 0D/1D POUR LES PROCESS ENERGETIQUES 
3.1. LE LANGAGE MODELICA
3.1.1. Notion de modèle à l’échelle système
3.1.2. Historique
3.1.3. Principales caractéristiques du langage
3.1.4. Simulation d’un modèle Modelica
3.2. EXEMPLES DE LOGICIELS DE SIMULATION DE MODELES MODELICA
3.2.1. Le logiciel Dymola
3.2.2. Le logiciel MathModelica
3.2.3. Le logiciel OpenModelica
3.3. PRESENTATION DE LA BIBLIOTHEQUE THERMOSYSPRO
4. APPLICATION DE LA RECONCILIATION DE DONNEES AUX MODELES MODELICA EDF
4.1. PROTOTYPE POUR L’APPLICATION DE LA RECONCILIATION DE DONNEES AUX MODELES MODELICA EDF
4.1.1. Architecture du prototype
4.1.2. Méthodologie pour l’application de la réconciliation de données aux modèles Modelica
4.2. ETAT DE L’ART VALI
4.2.1. Modélisation de système à l’échelle 0D/1D
4.2.2. Données du problème de réconciliation (mesures + incertitudes) : ETAPE 1 et ETAPE 2
et notion de données non-mesurées
4.2.3. Détermination des conditions auxiliaires et redondance : ETAPE 3
4.2.4. Analyse des données : Détection des erreurs grossières et analyse de sensibilité:
ETAPE 6
4.2.5. Synthèse des fonctionnalités VALI pour l’élaboration des nouvelles exigences EDF
4.2.6. Conclusion sur les fonctionnalités VALI pour la réconciliation de données
4.3. NOUVELLES EXIGENCES EDF
4.3.1. Prise en compte de plusieurs mesures pour une même grandeur physique (redondances
spatiale ou temporelle) : ETAPE 1
4.3.2. Choix du type d’équation bilan à considérer pour la formulation des conditions auxiliaires
4.3.3. Itérations successives pour gérer des équations non-linéaires dans le modèle
4.3.4. Gestion de l’observabilité des variables non-mesurées et de la redondance du système
de mesures
4.4. OBSERVABILITE/REDONDANCE
4.4.1. Notions d’observabilité et de redondance
4.4.2. Analyse matricielle pour la redondance et l’observabilité
4.5. PROGRAMMATION DE L’OUTIL DE CALCUL EXTERNE DU PROTOTYPE OPENPROD POUR LA RECONCILIATION DES DONNEES
4.5.1. Les données d’entrée de l’outil externe de calcul
4.5.2. Les résultats en sortie de l’outil externe de calcul
4.5.3. Notice d’utilisation du prototype OpenProd
4.5.4. Codage de l’outil externe de calcul de la méthode de réconciliation de données en
langage Mathematica
5. VALIDATION DU PROTOTYPE OPENPROD 
5.1. DESCRIPTION D’UN CAS-TEST
5.2. METHODOLOGIE UTILISEE POUR TESTER LE PROTOTYPE OPENPROD
5.3. CRITERES DE PERFORMANCE POUR LA VALIDATION DU PROTOTYPE
5.4. CHOIX DES CAS-TESTS
5.5. CAS TEST 1
5.5.1. Process n°1
5.5.2. Modèle n°1
5.5.3. Modèle n°2
5.6. CAS TEST 2 – ISSU DE LA NORME VDI 2048 –
5.6.1. Process n°2
5.6.2. Modèle n°1
5.7. CAS TEST 3 – ISSU DE [9] AVEC NOTION DE REDONDANCE ET D’OBSERVABILITE
5.8. CAS TEST 4: MODELE BILINEAIRE
5.8.1. Process
5.8.2. Modèle n°1
5.9. SYNTHESE DES RESULTATS DES CAS-TESTS
6. CONCLUSIONS ET PERSPECTIVES
6.1. CONCLUSION SUR LA VERSION ACTUELLE DU PROTOTYPE OPENPROD
6.1.1. Etat des lieux des spécifications logicielles du prototype OpenProd
6.1.2. Etat des lieux des spécifications numériques et de l’itération de la méthode de réconciliation de données (nouvelle exigence implémentée dans le prototype OpenProd)
6.2. CORRECTION DU « BUG»D’EXTRACTION DES DONNEES: COMPETENCE SOCIETE MATHCORE ENGINEERING AB
6.3. AMELIORATION DU PROTOTYPE OPENPROD
6.3.1. Améliorations des fonctionnalités de l’outil externe de calcul implémentées au cours du stage
6.3.2. Nouvelles exigences EDF à implémenter dans le prototype OpenProd
6.3.3. Retour d’expérience sur l’utilisation du logiciel Mathematica
6.3.4. Perspectives pour l’évolution du prototype OpenProd
6.4. ORDRE DES PRIORITES ACTUELLES POUR LE DEVELOPPEMENT DU PROTOTYPE OPENPROD
6.4.1. Priorité 1 : Compatibilité totale de la bibliothèque ThermosysPro avec le standard Modelica
6.4.2. Priorité 2 : Correction du « Bug » d’extraction des données
6.4.3. Priorité 3 : Améliorations du prototype et nouvelles exigences EDF
7. ANNEXES 
7.1. INTITULE DU STAGE DE FIN D’ETUDES
7.2. CODE MATHEMATICA DE L’OUTIL EXTERNE DE CALCUL DU PROTOTYPE OPENPROD: IMPLEMENTATION DE LA METHODE DE RECONCILIATION DE DONNEES A PARTIR DU TEST 1-1-1
7.2.1. “Model.nb”
7.2.2. “Init.nb”
7.2.3. “Main.nb”
7.2.4. “Preproc.nb”
7.2.5. “Ucv5.nb”
7.3. NOTICE D’UTILISATION DETAILLEE DU PROTOTYPE OPENPROD A PARTIR DE L’EXEMPLE D’UN CIRCUIT HYDRAULIQUE (CF. PARAGRAPHE 4.5)
8. BIBLIOGRAPHIE 
TABLE DES FIGURES

Télécharger le rapport complet