Documente Academic
Documente Profesional
Documente Cultură
STAGE
Master 2
Modélisation et intégration de
données de capteurs/compteurs du SGE
par
Ines BEN KRAIEM
Tuteurs de stage :
Hervé CROS, Faiza GHOZI, André PENINOU
Juillet 2017
DEDICACES
qui je compte
Je dédie ce travail
1 Cadre du projet
Modélisation et intégration de données de capteurs/compteurs du SGE
1 Introduction
Dans ce chapitre, nous présentons l’organisme d’accueil au sein duquel s’est déroulé
notre projet, situons le présent travail dans son contexte général, spécifions les besoins et
mettons en relief l’analyse et critique de l’existant et enfin nous proposons la solution aux
problèmes soulevés.
2 Cadre général
Dans le cadre de la préparation du projet de fin d’étude en vue de l’obtention du diplôme
National d’Ingénieur en Informatique, Technologie Web et Multimédia, nous avons choisi
d’effectuer un stage d’une durée de 4 mois au sein du SGE et en collaboration avec le laboratoire
IRIT. Le stage a débuté le lundi 13 Mars 2017 et s’est achevé le lundi 13 Juillet 2017. L’objectif
premier était de mettre en place un système décisionnel pour les données énergétiques des
bâtiments et réseaux du campus de Rangueil (ou se trouve entre autre l’Université Paul Sabatier)
provenant de plusieurs capteurs et récupérées de différents bâtiments dans le but de visualiser
[17] et mettre à disposition ces données aux utilisateurs [15] [18].
2.1 Présentation de l’organisme d’accueil
L’équipe SIG (Systèmes d’Informations Généralisés) affilée au laboratoire IRIT, nous a
proposé le sujet d’intégration et de modélisation des données de capteurs/compteurs du SGE. Le
projet est élaboré au sien du SGE le Service de Gestion et d’Exploitation de la Chancellerie des
Universités du Rectorat de l’Académie de Toulouse.
2.1.1 Le Service de Gestion et d’Exploitation
C’est un service du rectorat spécialisé dans la gestion, l’exploitation et l’investissement
des réseaux mutualisés des campus de Rangueil. Il gère les données liées aux différentes
installations en termes de fluides (énergie, eau, air comprimé) sur différents campus.
Présentation des activités
Le SGE gère plusieurs pôles d’activités :
• Le pôle maintenance exploitation avec 11 Agents de l’Education Nationale : ce
service concerne les activités électromécaniques telles que les réseaux et infrastructures
électriques Haute Tension, les réseaux et infrastructures de chauffage urbain, l’éclairage Public,
la gestion technique centralisée (GTC), l’air comprimé, les réseaux d’eau et d’assainissement, les
réseaux de gaz Arrosage, Eau Usées, Eaux pluviales et Réseau Gaz.
• Le pôle espaces extérieurs avec 11 Agents de l’Education Nationales : ce service
gère les espaces verts et Voirie.
• Le pôle administratif avec 6 agents de l’Education Nationales
• Le pôle travaux SIGT avec 4 agents de l’Education Nationales
Organigramme
Le SGE compte 36 personnes occupant différents postes. La figure 1 représente
l’organigramme de l’entreprise
Figure 1: Organigramme du SGE
1 https://www.irit.fr/
la donnée brute et élaborée pour les utilisateurs.
2.2 Présentation général du projet
Le Service de Gestion et d’Exploitation gère deux systèmes de gestion des données de
capteurs, demandant des tâches lourdes et complexes de manipulations et d’extractions de ces
données de différentes sources (10000 points de comptage). Le système de gestion d’exploitation
visé dans ce stage,nommé METASYS, stocke les données sous forme de fichiers plats et
indépendants organisés en une hiérarchie de répertoires. Un fichier concerne un capteur
(température, vannes, pression, …) ou un compteur (eau chaude, électricité, …) et conserve les
différents relevés automatiques réguliers (toutes les 30’, 15 minutes, 2 heures, …). Par
conséquent, chaque relevé concerne une valeur avec un horodatage. Dans un même temps, ce
système est entrain d’être migré vers un autre système de monitoring, appelé PCVUE, qui dans
l’avenir contiendra la majorité des données des capteurs. Le besoin était de mettre en place une
solution d’intégration des données de ces systèmes de supervision METASYS et PCVUE dans une
base de données afin de faciliter l’extraction et la manipulation de ces données entre les deux
systèmes par l’intermédiaire d’outils disponibles sur PCVUE. La totalité des données d’historique
ne pouvant pas être traitée par PCVUE, il nous a été demandé de mettre en place une base pour
l’ensemble de l’historique pour faire des analyses et des comparaisons entre les différents
fichiers. Une solution simple et facile pour pouvoir explorer et visualiser [17] les données de cette
base devra être proposée.
2.3 Objectifs préliminaires
Le « SGE» souhaite apporter des solutions pour la modélisation, le stockage et
l’exploration des données générées par les capteurs/compteurs afin de pouvoir répondre à la
variété des besoins et exigences d’accès et d’analyses des utilisateurs. Pour cela, le SGE espère:
• Avoir une solution (modèle, architecture, outils) qui permette d’extraire et de
stocker les données, pour pouvoir ensuite les explorer et les visualiser suivant différents
critères [15] [18].
• Avoir une solution d’intégration de données des fichiers dans une source unique
et non volatile.
• Recenser les besoins des utilisateurs en termes d’analyse des données (pour
l’exploitation directe sur un bâtiment par exemple, pour des analyses à long terme et comparer
des consommations sur plusieurs années par exemple, pour l’extraction de données, …).
• Avoir des préconisations en termes de SGBD à retenir, de logiciel de visualisation
adapté [18], de matériel nécessaire (serveur, …), et de procédures d’exploitation à mettre en
place.
• Avoir à disposition des décideurs les différents outils d’exploration des données
en toute sécurité afin de favoriser une meilleure prise de décision.
• Avoir une solution pour piloter la performance durable.
Notre ambition est de répondre aux besoins du SGE en utilisant les technologies liées aux
bases de données, aux entreposages de données et à l’informatique décisionnelle [1] [8] [12].
2.4 Planning du projet
La planification est une étape importante dans le déroulement du projet parce qu’elle
traduit l’organisation du projet et l’estimation du temps nécessaire à la réalisation des différentes
tâches. Pour cela nous décomposons le projet en plusieurs tâches et nous prévoyons à chaque
tâche le temps nécessaire pour sa finalisation. La figure 2 présente les différentes étapes à suivre
pour la réalisation de notre projet (provisoire).
3 Analyse de l’existant
Description
METASYS est un système de supervision pour l’ensemble des fonctions techniques du
bâtiment. Il gère essentiellement les équipements de CVC mais il ne permet pas le suivi de la
performance énergétique et l’édition des rapports pour surveiller les consommations d’un
bâtiment.
Architecture
METASYS stocke les données sous forme de fichiers plats d’extension .DBF. Ces fichiers
représentent 252187 fichiers comme historique, soit 151 Go de données brutes, et 2635 fichiers
comme données opérationnelles de chauffage sur 6 mois d’une taille de 4 Go. Le SGE est entrain
de migrer du système METASYS vers le système PcVue. En effet, tous les nouveaux automates
sont maintenant branchés directement sur PcVue et non pas sur METASYS. La base de données
de METASYS est organisée en une hiérarchie de répertoires comme le montre la figure 3.
Description
PcVue est un système de supervision temps-réel permettant à l’opérateur de visualiser
et de piloter la production, la gestion d’alarmes, l’affichage de tendances, l’archivage de données
et l’acquisition de données. Il est utilisé dans le contrôle industriel, la gestion de bâtiments, la
gestion d’énergie, la distribution électrique, le chauffage, l’automatisation des sous-stations, la
sécurité, la détection incendie, le transport, les énergies renouvelables et les infrastructures. Ce
logiciel, qui est donc un outil de supervision, fonctionne en interaction avec les automates qui
modélisent les différentes informations envoyées par les capteurs et permet de générer des
courbes en fonction des informations de la base.
Architecture
PcVue est en connexion permanente avec une base propriétaire sous forme de fichiers
d’extension .dat, qui permet le stockage de toutes les informations des capteurs. Étant donné que
les capteurs envoient une information à chaque seconde, la base de données contient des millions
de lignes. Cette base occupe pour une période de 6 mois 10 Go de données brutes et pour son
historique qui date depuis 2010, nous avons 80 Go sur un premier lecteur et 15 Go sur un
deuxième lecteur. Le principe de PcVue est la création des variables qui représentent des points.
Ces points représentent des chemins pour les fichiers qui contiennent les valeurs des capteurs.
Chaque fichier contient les informations de plusieurs capteurs comme le montre la figure 5.
Figure 5: Extrait des données d’un fichier.dat
Ces fichiers sont une longue liste de chiffres et de lettres comportant des informations
précises. Le bandeau principal indique le nom du capteur qui est sous forme de chemin indiquant
le nom du client ‘CROUS’, le nom du batiment ‘TRIPODE C’, l’équipement ‘ECH1’ et le type de
mesure ‘REGS’. Egalement, nous distinguons deux dates dont l’une est la date de début de la
mesure et l’autre la date de fin de la mesure. Finalement, nous trouvons une liste de dates en
UTC (Coordinated Universal Time) suivie de valeurs générées par le capteur.
3.1.3 Base de données patrimoine ACCESS
Le SGE dispose d’une base de données Access qui représente le patrimoine de la société.
Elle contient les informations sur les clients du SGE, les bâtiments, les locaux techniques, les
équipements et les capteurs.
3.2 Critique de l’existant
Un des principaux problèmes du SGE est l’accès à un historique des données pour
effectuer des comparaisons et des analyses. A ce jour, le système METASYS n’offre pas une
gestion de l’historique supérieure à 6 mois et ne permet pas de croiser facilement des données
de plusieurs capteurs/compteurs. Egalement, il ne permet ni de faire une comparaison entre deux
fichiers qui ont un horodatage différent ni de faire une comparaison avec des fichiers provenant
d’autres systèmes différents. En ce qui concerne les courbes offertes par METASYS, le système ne
permet pas l’affinage des courbes à travers un calendrier pour choisir les dates voulues et
remonter dans le temps pour faciliter la lecture par les analystes. Et finalement ce système ne
suit pas une charte bien spécifique pour nommer les répertoires ce qui a engendré par
conséquent une énorme hétérogénéité au niveau des noms d’un même répertoire. De l’autre
côté, PcVue est limité par la complexité de fichiers.dat et la lourdeur du système. En effet, ce
système permet d’afficher des courbes lisibles pour surveiller les consommations d’un bâtiment
mais il n’est pas assez performant en terme temps de réponse. Egalement, actuellement, PcVue
enregistre les données sur deux machines dont une principale et l’autre de secours pour assurer
la pérennité des données en cas de coupure. Mais cette solution n’est pas fiable en terme
d’analyse étant donné que PcVue permette d’afficher les courbes d’une seule machine à la fois.
Par conséquent, lorsqu’il s’agit d’une coupure au niveau d’une machine, les données sont
enregistrées automatiquement dans l’autre machine mais elles ne sont pas remontées dans les
courbes ce qui engendre un affichage avec des valeurs manquantes. Finalement, ce système fait
une purge chaque jour et n’arrive pas à garder des traces de données à cause du grand volume
de ses bases propriétaire. Et enfin, le schéma de la base de données Access n’est pas créé
convenablement en termes de relations entre les tables, d’optimisations et de nombre de tables
crées. Et en plus, il ne contient aucun lien avec les données de METASYS ou PcVue.
3.3 Analyse et spécification des besoins
4.1.1 Présentation
La première phase du projet consiste à modifier la sauvegarde du PcVue de sa base
propriétaire vers SQL Server, à intégrer l’ensemble des données de METASYS sur une période de
6 mois dans la même base de PcVue. Finalement, nous construisons une source commune qui
englobe l’ensemble des données des deux systèmes comme le montre la figure 6.
Figure 6: Schéma descriptif de la première partie du projet
4.1.2 Avantages
Cette solution présente plusieurs avantages présentés ci-dessous:
• Avoir une seule base de données au lieu de deux bases propriétaires assez
complexes.
• Assurer la pérennité et la récupération de l’ensemble des données.
• Pouvoir appliquer les courbes et les analyses de PcVue sur les données de
METASYS.
• Comparer les données de METASYS et PCVUE.
• Résoudre le problème des valeurs manquantes dans les courbes de PcVue causée
par l’enregistrement des données sur deux machines distantes à travers la récupération des
données depuis SQL Server.
• Faire des comparaisons et des analyses entre des sous systèmes différents de
METASYS.
4.2.1 Présentation
La deuxième phase du projet consiste à gérer l’historique des systèmes du SGE. Pour
cette raison, nous avons décidé de créer un entrepôt de données orienté Big Data [4] [10] [11]qui
peut supporter le grand volume de données. Cet entrepôt va contenir l’historique de METASYS,
l’historique de PcVue, la base de données Access et finalement, les données de 6 mois
enregistrées lors de la première phase sous SQL Server [7]. Cette intégration va nous permettre
de brancher un outil d’analyse sur l’entrepôt afin d’obtenir des courbes et des tableaux de bord
qui aident la direction à piloter et analyser son système énergétique. La figure 7 montre la
nouvelle architecture de l’entrepôt Big Data [2].
4.2.2 Avantages
Cette deuxième partie de la solution présente les avantages suivant:
• Se débarrasser des archives des bases propriétaires.
• Avoir un accès à un historique des données pour effectuer des comparaisons et
des analyses.
• Avoir une source fiable, pertinente et solide.
• Stocker d’importants volumes de données de toute nature en temps réel.
5 Conclusion
Dans ce premier chapitre, nous avons défini le champ de notre étude suivi d’une étude
de l’existant afin de préciser les objectifs à atteindre. En effet, l’étude de l’existant nous a permis
de préparer une bonne conception pour les améliorations que nous allons ajouter dans la solution
proposée afin de répondre à nos besoins. Dans le chapitre qui suit, nous présentons les
démarches de développement et de conception de notre solution.
CHAPITRE 2 : L’informatique décisionnelle
1 L’informatique décisionnelle
Modélisation et intégration de données de capteurs/compteurs du SGE
1 Introduction
Ce chapitre sera réservé pour définir l’informatique décisionnelle. Nous présentons dans
un premier temps ses avantages et ses limites. Nous abordons, ensuite, ses termes et les concepts
clés en détaillant la notion d’ETL et d’entrepôt de données. Puis, nous développons les notions
de Big Data et de bases de données NoSQL.
2 Concepts généraux du BI
2.1.2 Limites du BI
Parmi les limites de la Business Intelligence :
• La mise en place d’une solution de BI prend beaucoup du temps : de nombreuses
entreprises dans le scénario industriel rapide ne sont pas assez patientes pour attendre la mise
en place du système décisionnel dans leur organisation.
• Complexité : un autre inconvénient de BI pourrait être sa complexité dans la mise
en œuvre des données.
• Erreur : les résultats produits par les systèmes décisionnels sont le résultat de
conceptions informatiques et mathématiques complexes, qui peuvent révéler des erreurs, par
ailleurs les résultats sont souvent statistiques, donc non déterministes. La possibilité d’une
erreur ou d’une approximation inadaptée devra toujours être prise en compte dans les
décisions.
4.3 Administration
Cette étape est constituée de plusieurs tâches pour assurer :
• La qualité et la pérennité des données aux différents applicatifs.
• La maintenance et le suivi.
• La gestion de configuration.
• La gestion de l’évolution et les demandes d’expansion.
• L’organisation et l’optimisation du SI.
• La documentation et les formations.
4.4 Restitution
C’est la dernière étape d’un projet d’entreposage de données, soit son exploitation.
L’exploitation de l’entrepôt se fait par le biais d’un ensemble d’outils analytiques développés
autour de ce dernier. Il s’agit de regrouper tout ce qui a attrait à la représentation et la
transmission des résultats d’analyse de données. Le principe de la restitution, donc, est d’agréger
et de synthétiser des données nombreuses et complexes sous forme d’indicateurs, de tableaux,
de graphiques permettant d’en avoir une appréhension globale et simplifiée pour faire toutes les
analyses nécessaires. 1.2 Nous avons défini dans cette partie les notions de bases des systèmes
décisionnels. Dans la partie suivante nous allons introduire les notions du Big Data et les bases de
données NoSQL.
5 Le Big Data
5.1 Définition
Littéralement, le Big Data signifie méga données, masses de données ou encore données
massives. Ces termes désignent un ensemble très volumineux de données qu’aucun outil
classique de gestion de base de données ou de gestion de l’information ne peut vraiment traiter.
Pour faire face à ces énormes volumes de données, de nouvelles technologies sont apparues
comme Hadoop, MapReduce ou les bases de données NoSQL (Not only SQL). Le Big Data couvre
quatre caractéristiques de base : volume, vélocité, variété et véracité.
• Volume : Les entreprises sont submergées de volumes de données croissants de
tous types, qui se comptent en téraoctets, pétaoctets voire en zettaoctets.
• Vélocité : La vélocité, ou vitesse, fait référence à l’énorme rapidité avec laquelle
les données sont générées et doivent être traitées.
• Variété : Le Big Data se présente sous la forme de données structurées ou non
structurées (texte, données de capteurs, son, vidéo, fichiers journaux, etc.).
• Véracité : La notion de véracité met en avant la dimension qualitative des
données nécessaire au fonctionnement des outils de Big Data.
SQL NoSQL
Stockage de données Les données sont stockées Les données sont stockées
dans un modèle relationnel, sous forme de document, graphe,
représentées dans des tables avec clé-valeur ou colonne.
des lignes et des colonnes.
Schémas et flexibilité Le schéma des données Les schémas sont
doit être prédéfini explicitement dynamiques. Une base NoSQL peut
au niveau du serveur c’est-à-dire en effet croître sans contrainte, sa
les colonnes doivent être décidées structure organisationnelle n’est
et définies avant la saisie des pas liée à un schéma relationnel
données et chaque enregistrement difficile à modifier.
doit être conforme au schéma fixé.
Évolutivité Les bases de données SQL Les bases de données
sont verticalement évolutives. La NoSQL sont évolutives
mise à l’échelle nécessite horizontalement. La mise à
l’augmentation de la charge en l’échelle se déroule entre les
modifiant la CPU et la RAM. serveurs. Il s’agit d’ajouter
simplement des serveurs de plus
dans l’infrastructure de base de
données.
Application Utilisé dans les projets qui Utilisé dans les projets qui
exigent des données discrètes qui exigent des données
peuvent être identifiées à l’avance indépendantes, indéterminées ou
et dont l’intégrité des données est évolutives.
essentielle.
Relation Les requêtes SQL offrent NoSQL n’a pas
une puissante clause JOIN. Nous d’équivalent de JOIN. Il est possible
pouvons obtenir des données d’avoir des données redondantes.
connexes dans plusieurs tables. Les
données ne doivent pas être
redondantes et elles doivent
respecter l’intégrité référentielle.
6 Conclusion
Dans ce chapitre, nous avons détaillé toutes les notions relatives aux systèmes
décisionnels, au Big Data et aux base de données NoSQL pour les maîtriser afin de favoriser le bon
déroulement du projet.
CHAPITRE 3 : Conception
1 Conception
Modélisation et intégration de données de capteurs/compteurs du SGE
1 Introduction
Au cours de ce chapitre, nous présentons dans un premier temps la structure de la base
de donnée SQL Server contenant les données de chaufferie sur 6 mois. Puis nous présentons la
conception multidimensionnelle de l’entrepôt de données Big Data.
2 Sources de données
Dans cette partie, nous présentons les diagrammes de classe de nos sources de données
afin de construire un digramme de classe finale qui défini la source globale. Ces schémas ont été
définis après application d’une phase en retro ingénierie (reverse engineering). En effet, nous
avons dégagé trois schémas pour nos source METASYS, PcVue et Access.
2.1 Source METASYS
Notre source METASYS est présentée sous forme de hiérarchie de répertoires. Ainsi, elle
est sous forme de répertoires qui représente les bâtiments et les locaux_techniques. Ces derniers
sont composés de sous-répertoires indiquant les capteurs. Finalement, ces capteurs sont
composés de mesures englobant les valeurs de capteurs. La figure 1 représente le schéma de
METASYS.
Figure 1: Schéma source du système METASYS
Ce digramme de classe décrit la source Access du patrimoine du SGE d’une part, et d’autre
part les classes des systèmes de supervision METASYS et PCVUE représentés dans ce schéma à
travers la table Mesure. En effet, elle permet de suivre les différentes mesures générées par les
capteurs et les sources d’où quelles proviennent. Ainsi, la classe Mesure avec ses attributs
id_mesure, chrono, name, value, quality, TS et type_capteur permet d’historiser la liste des
valeurs générées par des milliers de capteurs de notre société. Ces capteurs sont modélisés par
la classe Item qui fixe le nom du capteur et son unité de mesure. Chaque item est installé dans
un équipement (Classe Equipement) qui représente des composants dans les locaux techniques.
Ainsi, la table LocauxTechniques qui est caractérisée par les champs nom_local, reseau_local,
ref_local et niveau_local décrit les Sous_Stations de chauffage gérées par le SGE. Elles sont
différenciées en plusieurs types : Primaire, Secondaire, LT (Local Technique) et CTA (Central de
Traitement d’Air). Les locaux techniques appartiennent aux Bâtiments desservis par le SGE et liés
aux clients. La table Client décrit alors les différents clients du SGE, avec un détail sur l’ensemble
scientifique auquel ils appartiennent, le sous_ensemble des structures ainsi que leur localisation
Requêtes-types
2 http://kylin.apache.org/
les agrégats et les métadonnées de cube dans HBase. Nous pouvons ensuite interroger les
données du cube via l’interface utilisateur Kylin ou un outil de BI. L’architecture du moteur Kylin
se base sur trois axes comme le montre la figure 8:
• Identification d’un schéma en étoile sur Hadoop(Hive)
• Création d’un Cube à partir des tables Hive et stockage des métadonnées et des
agrégations du cube dans Hbase
• L’analyse des résultats avec des outils de visualisation via ODBC, JDBC ou RESTful
API.
5 Conclusion
Après avoir appliqué les différentes démarches de la modélisation conceptuelle de
l’entrepôt il ne reste qu’à le construire. Les étapes de cette construction feront l’objet du chapitre
suivant.
CHAPITRE 4 : Conception et Développement
de l’ETL
1 Introduction
Dans ce chapitre, nous présentons tout d’abord la conception et le développement de
l’ETL pour construire l’entrepôt de données pour les données d’exploitation d’une durée de 6
mois puis nous définissons les différentes phases de la construction de l’entrepôt de données Big
Data en commençant par la modélisation logique, physique pour aboutir à la phase d’intégration
des données où nous présentons la conception et le développement de l’ETL. Afin de réaliser la
phase d’intégration de données des deux systèmes de supervision METASYS et PcVue, nous avons
exploité les outils de développement présentés ci-dessous.
Talend Open Studio 3 est un ETL du type « générateur de code ». Pour chaque traitement
d’intégration de données, un code spécifique est généré, ce dernier pouvant être en Java ou en
Perl. Talend Open Studio utilise une interface graphique, le « Job Designer » (basée sur Eclipse
RCP) qui permet la création des processus de manipulation de données. Il permet également
l’intégration dans les suites décisionnelles Open Source (SpagoBI et JasperIntelligence).
2.1.2 SQL Server 2014
PcVue utilise un moteur d’archivage de données pour enregistrer des valeurs
(évènements, tendances) en utilisant divers mécanismes et formats :
• Données sauvegardées dans un format propriétaire dans un fichier texte.
• Données sauvegardées dans une base de données telle que SQL Server en
utilisant un composant natif (Historical Data Server).
D’habitude, PcVue utilise les fichiers complexes d’extension .dat pour stocker les
données. Afin d’avoir une base de données temps réel, nous avons choisi de sauvegarder les
données dans une base de données SQL Server.
Microsoft SQL Server 2014 est un système de gestion de base de données relationnelle
(SGBDR) en langage SQL développé par Microsoft. Il existe en différentes éditions : CE (Compact
Edition - solution embarquée pour les smartphones), Express (version gratuite), Developper,
3 https://www.talend.com/products/talend-open-studio/
Standard, BI et Enterprise. Nous avons opté pour l’utilisation de l’édition Standard qui offre des
fonctionnalités élémentaires en base de données, rapports et analyses.
2.2 Langages de développement
Afin de faire des transformations spécifiques et nécessaires à l’intégration de données,
nous avons utilisé IDLE comme environnement de développement intégré pour le langage Python
et Talend Open Studio pour la création des routines à travers un code java.
2.2.1 Java
Java est un langage de programmation informatique orienté objet et open source
développé par Sun Microsystems. Une de ses plus grandes forces est son excellente portabilité.
2.2.2 Python
Python 4 est un langage de programmation interprété qui peut s’utiliser dans de
nombreux contextes et s’adapter à tout type d’utilisation grâce à des bibliothèques spécialisées.
Le langage Python est placé sous une licence libre et fonctionne sur la plupart des plates-formes
informatiques. Parmi les avantages de Python est qu’on peut créer des petits programmes très
simples, appelés scripts, chargés d’une mission très précise ou bien créer des programmes
complets, comme des jeux, des suites bureautiques, des logiciels multimédias, des clients de
messagerie ou des projets très complexes, comme des progiciels.
4 https://www.python.org/
Nous allons expliquer davantage à travers la figure 1 l’architecture du système Pcvue et la
communication entre PcVue et METASYS.
A travers cette étude, nous avons opté pour la troisième solution parce qu’elle est la plus
fiable et la plus rapide à mettre en place. Pour cette raison, nous avons développé un script avec
le langage de programmation Python qui permet de créer un fichier Excel contenant l’ensemble
des points de METASYS. Ce script permet de parcourir les répertoires et les sous répertoires et de
générer un nom spécifique à notre charte comme par exemple le point suivant: "METASYS.SP-
4A.RECV2V.MES". Nous avons choisi de commencer le chemin par "METASYS" pour indiquer qu’il
s’agit des points remontés depuis le système METASYS. Puis le chemin est augmenté par le nom
du répertoire SP-4A qui indique "le bâtiment 4A" et le local technique "sous station primaire".
Nous rajoutons par la suite, "RECV2V" qui représente le capteur. Et enfin, nous terminons le
chemin par "MES" pour indiquer qu’il s’agit des mesures du capteur au lieu d’avoir des noms non
significatifs comme 128.DBF. Nous pouvons maintenant créer tous les 2635 points METASYS à
travers ce fichier de configuration d’une manière automatique dans le système PcVue.
Ainsi, la table TRENDTABLE contient l’ensemble des données de METASYS et PcVue qui
représentent a peu prés 150 000 000 lignes (Fig 11).
Figure 11: Aperçu des données METASYS dans la Table TRENDTABLE DE PcVue
4 Développement de l’ETL pour les données à long terme
La solution présentée pour analyser les données à court terme ne tient pas compte de
l’historique du SGE sur les 10 dernière années. En effet, elle offre une pratique sur 6 mois. Pour
intégrer les données d’archive, nous avons amené à proposer une nouvelle solution. Dans ce fait,
nous avons développé une solution SQL Server incluant les historiques de METASYS et PcVue ainsi
que les dates d’exploitation. Cette solution a été bien accueillie par les responsables de notre
projet qui ont pu exploiter et analyser les données du service. Néanmoins, cette solution a montré
ses limites notamment au niveau de la gestion de la volumétrie que ne cesse d’augmenter au fil
des années. Pour cela, nous avons étudié et proposé une deuxième solution Big Data permettant
de palier les limites de la première solution.
4.1 Intégration de l’historique sous SQL Server
Pour résoudre ces problèmes, nous avons décidé d’utiliser Hadoop/hdfs,un système de
fichiers distribué qui donne un accès haute-performance aux données réparties dans des clusters
Hadoop. Nous avons choisis Hive pour créer notre schéma multidimensionnel et interroger nos
tables et Hbase pour créer le cube OLAP. Nous avons décidé d’utiliser l’outil Talend Open Studio
For Big Data pour réaliser l’intégration. Nous avons réalisé une étude sur les outils existants pour
mettre en place facilement un cluster BigData. Par conséquent, nous avons choisi le bac à sable
(sandbox) Hadoop de Hortonworks. c’est une application d’un noeud simple Hadoop, basée sur
la Data Platform de Hortonworks (HDP). Il s’agit de l’installer sur une machine virtuelle Vmware
ou VirtuelBox pour travailler avec l’écosystème Hadoop. Le bac à sable fournit un environnement
de développement qui comprend plusieurs composants: Apache Hadoop, Apache Spark, Apache
Hive, Apache Hbase. A travers Data Platform de Hortonworks qui vise à faciliter le déploiement
et la gestion des clusters Hadoop nous pouvons gérer et exploiter Hadoop à travers Apache
AMbari, gérer les données à travers Hadoop HDFS et intérroger les données via Hive.
5 Conclusion
A travers ce chapitre, nous avons détaillé les problèmes rencontrés pour intégrer les
deux systèmes de supervision, nous avons proposé les solutions et défini la conception de l’ETL
et son développement pour l’exploitation sur une durée de 6 mois, pour les historiques et pour
le Big Data. A ce stade, il ne reste qu’à implémenter l’application d’interrogation de l’entrepôt de
données.
CHAPITRE 5 : Restitution
1 Restitution
Modélisation et intégration de données de capteurs/compteurs du SGE
1 Introduction
Dans ce chapitre, nous présentons la modélisation de l’application BI en définissant ses
différents types, usages et utilisateurs. Dans un second temps, nous entamons le développement
de cette application.
2 Modélisation de l’application BI
Lors de la spécification des besoins où nous avons entretenu les membres de la société
cliente de ce système décisionnel, nous avons défini le type d’application d’interrogation de
l’entrepôt de données attendu, pour quel usage, et pour quel type d’utilisateur. Nous détaillons
en ce qui suit le type d’application BI attendue, l’usage de cette dernière et ses utilisateurs.
• BI stratégique: Ce type d’analyse est axée sur l’avenir, ce qui permet à une
entreprise de prendre des décisions éclairées concernant les conditions futures de sa place dans
un marché ou dans un secteur particulier.
• BI tactique: la tactique fournit aux décideurs les informations nécessaires pour
surveiller les changements en temps réel de leur environnement et les aide à économiser de
l’énergie. L’intelligence tactique aborde les étapes d’actions qui doivent être prises en compte
pour atteindre les objectifs stratégiques de l’entreprise.
• BI opérationnel: Il concerne l’état opérationnel de l’entreprise Ce type utilise les
données issues en temps réel des applications pour les croiser avec les données historiques de
l’entreprise afin de fournir un support informationnel aux points d’affaire de l’entreprise.
3 Développement de l’application BI
Interface Discover
Grâce à la page DISCOVER de l’interface Kibana nous pouvons explorer les données de
façon interactive. Cette interface se décompose en trois parties:
• Un Toolbar pour les recherches.
5 https://www.elastic.co/fr/products
• Un histogramme pour voir la distribution des indexe dans le temps.
• Un tableau des documents qui comporte l’ensemble des indexes.
Par conséquent, nous pouvons accéder à chaque indexe qui représente un
enregistrement de la base de donnée et qui est représenté sous forme de document JSON. Ainsi
nous pouvons faire des requêtes de recherche, filtrer les résultats et afficher les données. Nous
avons la possibilité finalement de configurer le champ du temps pour changer la distribution des
documents au fil du temps dans l’histogramme et paramétrer la durée de rafraîchissement des
données pour récupérer les données rajoutées à Elasticsearch comme le montre la figure 2
4 Conclusion
Dans ce chapitre, nous avons présenté les analyses à l’aide du système de supervision
PcVue et nous avons présenté la modélisation de l’application BI ainsi que son développement à
travers l’enchaînement des différentes interfaces d’analyses décisionnelles.
CHAPITRE 6 : Conclusion et perspectives
[1] F. Ravat, O. Teste, R. Tournier, G. Zurfluh, Algebraic and graphic languages for OLAP
manipulations. International Journal of Data Warehousing and Mining, IGI Publishing, D.
Taniar, Vol. 4, N°1, p.17-46, 2008. doi: 10.4018/jdwm.2008010102
[2] F. Ravat, O. Teste, R. Tournier, G. Zurfluh, Finding an Application-Appropriate Model for
XML Data Warehouses. Information Systems Journal, Elsevier Science Publisher, Vol. 36
N°6, p.662-687, 2010.doi:10.1016/j.is.2009.12.002
[3] F. Ravat, O. Teste, R. Tournier, G. Zurfluh, Graphical Querying of Multidimensional
Databases. 11th East-European Conference on Advances in Databases and Information
Systems (ADBIS’07), Springer-Verlag, LNCS 4690, Y.E. Ioannidis, B. Novikov, B. Rachev,
p.298-313, Varna (Bulgaria), September 2007.
[4] M. Chevalier, M. El Malki, A. Kopliku, O. Teste, R. Tournier, How Can We Implement a
Multidimensional Data Warehouse Using NoSQL?, Lecture Notes in Business Information
Processing (LNBIP), Vol. 241, Springer, S. Hammoudi, L. Maciaszek, E. Teniente, O.
Camp, J. Cordeiro, ISBN 978-3-319-29132-1, p.108-130, 17th International Conference
on Enterprise Information Systems (ICEIS’15) , Revised Selected Papers, Barcelona,
Spain, April 27-30, 2015. doi: 10.1007/978-3-319-29133-8_6
[5] E. Annoni, F. Ravat, O. Teste, G. Zurfluh, Towards Multidimensional Requirement Design.
8th International Conference on Data Warehousing and Knowledge Discovery
(DAWAK’06), Springer-Verlag, LNCS 4081, A. Min Tjoa, J. Trujillo, p.75-84, Krakow
(Poland), September 2006.
[6] M. Chevalier, M. El Malki, A. Kopliku, O. Teste, R. Tournier, Benchmark for OLAP on NoSQL
Technologies, 9th International Conference on Research Challenges in Information
Science (RCIS'15), p. 480-485, IEEE, Athens, Greece, April 2015.
[7] F. Ravat, O. Teste, A Temporal Object-Oriented Data Warehouse Model. 11th International
Conference on Database and Expert Systems (DEXA'00), Springer-Verlag, LNCS 1873, M.
Ibrahim, J. Jüng, N. Revell, p.583-592, London (UK), September 2000.
[8] O. Teste, Towards Conceptual Multidimensional Design in Decision Support Systems. 5th
East-European Conference on Advances in Databases and Information Systems
(ADBIS'01), Research Communications Vol.1, A. Caplinskas, J. Eder, p.77-88, Vilnius
(Lithuania), September 2001.
[9] F. Ravat, O. Teste, G. Zurfluh, Langages pour Bases Multidimensionnelles : OLAP-SQL.
Revue des Sciences et Technologies de l'Information, ISI (Ingénierie des Systèmes
d'Information), Hermès, Vol.7, N°3, p.11-38, novembre 2002.
[10] M. Chevalier, M. El Malki, A. Kopliku, O. Teste, R. Tournier, Implementation of
multidimensional databases in column-oriented NoSQL systems, 19th East-European
Conference on Advances in Databases and Information Systems (ADBIS’15), p.79-91,
Poitiers, France, September 2015.
[11] M. Chevalier, M. El Malki, A. Kopliku, O. Teste, R. Tournier, Implementation of
Multidimensional databases with document-oriented NoSQL, 17th International
Conference on Big Data Analytics and Knowledge Discovery (DAWAK’15), p.379-390,
Valencia, Spain, September 2015.
[12] G. Pujolle, F. Ravat, O. Teste, R. Tournier, G. Zurfluh, Multidimensional Database Design
from Document-Centric XML Documents. 13th International Conference on Data
Warehousing and Knowledge Discovery (DAWAK'11), p.51-65, Toulouse (France),
September 2011.
[13] Berro, I. Megdiche, O. Teste, A Content-Driven ETL Processes for Open Data, 18th East-
European Conference on Advances in Databases and Information Systems (ADBIS’14),
Proceedings II, New Trends in Database and Information Systems II, Vol. 312, p.19-40,
Ohrid, republic of Macedonia, September 2014.
[14] Berro, I. Megdiche, O. Teste, Graph-Based ETL Processes For Warehousing Statistical
Open Data, 17th International Conference on Enterprise Information Systems (ICEIS’15),
p.271-278, Barcelona, Spain, April 2015.
[15] MF Canut, S On-At, A Péninou, F Sèdes, Time-aware egocentric network-based user
profiling, Proceedings of the 2015 IEEE/ACM International Conference on Advances in Social
Networks Analysis and Mining, pp. 569-572, 2015.
[16] H Ezzedine, A Peninou, H Maoudji, Towards Agents Oriented Specification of Human-
Machine Interface: Application to Transport Systems, IFAC Proceedings Volumes 34 (16),
pp.363-368, 2001
[17] D Tchuente, MF Canut, NB Jessel, A Péninou, F Sedes, Visualizing the relevance of social
ties in user profile modeling, Web Intelligence and Agent Systems: An International Journal
Volume 10 (2), pp. 261-274, 2012.
[18] CA Zayani, A Péninou, MF Canut, F Sèdes Towards an adaptation of semi-structured
document querying, Held in conjunction with the 6th International and Interdisciplinary
Conference on Modeling and Using Context, 2007.