RAPPORT DE STAGE

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

2.1.2 Le laboratoire IRIT

L’Institut de Recherche en Informatique de Toulouse (IRIT) 1 est l’un des piliers de la

recherche en Midi-Pyrénées avec ses 700 membres, permanents et non-permanents. De par son

caractère multi-tutelle (CNRS, INPT, Universités toulousaines), son impact scientifique et ses

interactions avec les autres domaines, le laboratoire constitue une des forces structurantes du

paysage de l’informatique et de ses applications dans le monde du numérique, tant au niveau

régional que national. Notre projet était en collaboration avec l’équipe SIG (Systèmes

d’Informations Généralisés) qui se compose de 19 permanents, et d’une trentaine d’étudiants

post-doctorants, doctorants ou stagiaires, et d’ingénieurs de recherche. Ses recherches

s’inscrivent dans le domaine des Systèmes d’Informations (Information Systems) et ont pour objet

scientifique la donnée et l’utilisateur. Elles concernent notamment les problématiques d’accès à

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

Figure 2: Planning prévisionnel

3 Analyse de l’existant

3.1 Étude de l’existant

Plus de 5000 de capteurs sont répartis dans tous les bâtiments. Les capteurs permettent

de suivre et gérer l’ensemble des équipements exploités par le SGE, comme ,par exemple, des

sondes de températures, des commandes de vannes de régulation et des compteurs. Au sein du

SGE, il y a deux systèmes de gestion de données qui cohabitent:

• METASYS, système propriétaire de supervision, gère essentiellement les

équipements de CVC (Chauffage traitement d’air). Cette supervision communique

exclusivement avec des automates régulateurs de marque Johnson Controls.

• PCVUE, système de supervision de type ouvert, intègre les équipements de CVC,

de haute tension, d’air comprimé, d’éclairage public... Cette supervision communique avec des

automates de toute marque.

Le SGE dispose d’une base de données Access qui représente le patrimoine des

équipements en gestion dans le sens où il y a l’ensemble des informations sur les bâtiments, les

clients, les équipements, les visites et les maintenances des équipements et des capteurs.

3.1.1 Système METASYS

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.

Figure 3: Hiérarchie des répertoires de données METASYS

Par exemple, le nom du répertoire SP_4A indique le nom du local technique SP suivi

d’une référence du bâtiment 4A. En effet, le SGE dispose de plusieurs locaux techniques qui

décrivent les Sous-Stations de chauffage. Parmi lesquels nous trouvons :

• SSP : Sous Station Primaire.

• SS : Sous Station secondaire.

• LT : Local Technique.

• CTA : Central de traitement d’air.

• PHT : Poste Haute Tension.

• TGBT : Tableau Général Basse Tension.

Sous chaque répertoire de local technique, nous trouvons des répertoires qui

représentent la liste des capteurs. Finalement, nous arrivons aux fichiers .dbf qui représentent les

données de capteurs(4).

Figure 4: Extrait d’un fichier.DBF

Ces fichiers contiennent des informations importantes concernant la date et la valeur de

la mesure. En revanche pour avoir une date complète qui désigne une mesure, il faut concaténer

les champs Att, Date_NDX et TIME_NDX.

3.1.2 Système PCVUE

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

3.3.1 Besoins fonctionnels et non fonctionnels

Dans notre processus de définition des besoins, nous avons débuté par un entretien avec

le responsable électromécanique. C’est celui qui est chargé du projet. Il sera la première personne

interrogée suivie des cadres supérieurs. Suite à l’analyse des réponses des interrogés, nous avons

rassemblé les besoins fonctionnels, qui se classifient en deux niveaux majeurs ; la spécification

des caractéristiques de l’entrepôt et la spécification des fonctionnalités de l’application

d’interrogation de l’entrepôt [3] [9].

Les spécifications de l’entrepôt

L’entrepôt doit être conçu de manière qu’il permette de:

• Construire une source de données unique et non volatile.

• Mieux contrôler les données : nous pouvons organiser les données selon nos

besoins et donc rendre la base de données plus optimale.

• Rendre la base plus évolutive et plus adaptée à nos futurs besoins.

• Garder la traçabilité de chaque donnée : source d’extraction de cette information.

• Avoir une modélisation multidimensionnelle des données et hiérarchisation de

granularité d’analyse d’un niveau global à un niveau plus détaillé.

• Garantir une évolution et un rafraîchissement périodique et régulier des données.

• Gérer un grand volume de données variées.

Les spécifications de l’application

L’application doit être conçue de manière à permettre :

• La haute disponibilité des données à n’importe quel instant.

• La formulation des requêtes assez complexes permettant l’interrogation des

données de l’entrepôt à n’importe quel niveau hiérarchique.

• La génération facile des rapports ad-hoc ou autre types de rapport.

• La consultation aisée des tableaux de bord fournis.

• L’application facile des différentes opérations sur les données.

3.3.2 Besoins non fonctionnels

• Définir une résolution et une quantité graphique adéquate.

• Fournir des interfaces interactives et compréhensibles manipulées facilement par

les décideurs afin d’explorer leurs données.

• Fournir des tableaux de bord clairs et facilement analysables.

• Fournir des rapports lisibles tout en respectant la charte graphique.

• Assurer la sécurité et la performance de l’entrepôt.

4 Systèmes d’intégration pour l’analyse décisionnel

Face aux problèmes soulevés des systèmes de supervision du SGE et suite aux besoins

déduits par la direction, nous avons opté pour la réalisation du projet en deux phases.

4.1 Solution d’intégration à court terme

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 Solution d’intégration Big Data

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

Figure 7: Schéma descriptif de la deuxième partie du projet

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 La Business Intelligence

L’informatique décisionnelle, également Business Intelligence ou BI en anglais, désigne

les moyens, les méthodes et les outils qui apportent des solutions en vue d’offrir une aide à la

décision aux professionnels afin de leurs permettre d’avoir une vue d’ensemble sur l’activité de

l’entreprise et de leurs permettre de prendre des décisions plus avisées à travers des tableaux de

bord de suivi et des analyses.

2.1.1 Avantage du BI

Déployer une solution BI apporte de nombreux avantages :

• Améliorer la visibilité sur les chiffres, les écarts et les anomalies.

• La combinaison de plusieurs sources de données (ERP, systèmes comptable,

feuilles de calcul, des budgets …).

• La présentation uniforme d’informations fiables.

• L’automatisation permettant l’accélération de la collecte et de la diffusion de

l’information.

• La performance dans le calcul d’agrégats sur de gros volume de données.

• La prise de décision grâce à des indicateurs pertinents et à une structure

cohérente des informations.

• L’aide à nettoyer les données présentes dans différents logiciels.

• L’anticipation des événements et la projection dans l’avenir.

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.

2.2 Les principes des systèmes décisionnels

Le système décisionnel est architecturé de la façon suivante :

• Plusieurs sources de données en lecture.

• Un entrepôt de données fusionnant les données requises.

• Un ETL permettant d’alimenter l’entrepôt de données à partir des données

existantes.

• Des magasins de données permettant de simplifier l’entrepôt de données.

• Des applications d’exploitation de données pour présenter l’étude aux utilisateurs

finaux et décideurs.

Figure 1: Architecture générale d’un système décisionnel

2.2.1 Sources de données

Afin d’alimenter l’entrepôt, les informations doivent être identifiées et extraites de leurs

emplacements originels. Il s’agit des sources de données hétérogènes qui peuvent comporter des

données internes à l’entreprise, stockées dans les bases de données de production des différents

services. Elles peuvent être aussi des sources externes, récupérées via des services distants et des

web services ou des sources qui peuvent être sous format de fichiers plats.

2.2.2 Entrepôt de données

D’après BILL Inmon: "Un entrepôt de données est une collection de données

thématiques, intégrées, non volatiles et historiées, organisées pour la prise de décision.". D’après

cette définition nous distinguons les caractéristiques suivantes :

• Données Orientées sujet : les données des entrepôts sont organisées par sujet et

donc triées par thème.

• Données intégrées : les données provenant des différentes sources doivent être

intégrées avant leur stockage dans l’entrepôt de données. Un nettoyage préalable des données

est nécessaire afin d’avoir une cohérence et une normalisation de l’information.

• Données non-volatiles : à la différence des données opérationnelles, celles de

l’entrepôt sont permanentes et ne peuvent pas être modifiées. Le rafraîchissement de

l’entrepôt, consiste à ajouter de nouvelles données sans perdre celles qui existent.

• Historiées : les données doivent être datées.

2.2.3 Magasin de données

Les magasins de données ou Datamarts sont un sous-ensemble complet et naturel de

l’entrepôt de données. Ils sont structurés pour répondre rapidement aux sollicitations des

utilisateurs. À l’inverse d’un entrepôt de données qui peut être très volumineux et qui ne permet

pas une utilisation appropriée, ils ont en effet moins de données à gérer ce qui permet

d’améliorer considérablement les temps de réponse.

2.2.4 Extract-Transform-Load

ETL, acronyme d’Extraction Transformation Loading, est un processus d’intégration des

données [13] [14]. Il permet de transférer des données brutes d’un système source, de les

préparer pour une utilisation en aval et de les envoyer vers l’entrepôt de données. Ce système

doit faire passer les données par un tas de processus pour les dé-normaliser, les nettoyer, les

contextualiser, puis de les charger de la façon adéquate. Cependant, la réalisation de l’ETL est une

étape très importante et très complexe parce qu’il constitue 70% d’un projet décisionnel en

moyenne.

3 La différence entre OLTP et OLAP

Les systèmes informatiques peuvent se subdiviser en deux catégories: les systèmes

transactionnels OLTP (Online Transaction Processing) et les systèmes analytiques OLAP (OnLine

Analytical Processing).

• Les systèmes OLTP sont dédiés aux mé