Vous êtes sur la page 1sur 35

S

a
l
o
m


B
E
N
S
L
A
M
A

3

M
a
i


3
0

J
u
i
l
l
e
t

2
0
1
0

R
a
p
p
o
r
t

d
e

S
t
a
g
e

RAPPORT UNIVERSITAIRE

Mise en place d'un systme domotique et d'un SCADA
pour la gestion des flux nergtiques de la plateforme
Monitoring et Habitat Intelligent de PREDIS


Maitre de stage : Stphane Ploix

Polytech Grenoble
Dpartement 3I 4

Laboratoire G-SCOP, Grenoble INP
46, avenue Flix Viallet
38031 Grenoble


Salom BENSLAMA 3 Mai-30 Juillet 2010 Page | 2

Sommaire

Introduction

I. Le laboratoire G-SCOP et ses secteurs dactivit 5
I.1. Le laboratoire G-SCOP 5
I.1.1. Historique 5
I.1.2. Organisation administrative et scientifique 5
I.2. Secteurs dactivit du laboratoire 7
I.2.1. Des ples pluridisciplinaires au service du monde industriel 7
I.2.2. La gestion des flux nergtiques dans lhabitat, un dfi technologique et
cologique mais aussi un march en plein essor 8
II. Le cadre du stage 10
II.1. Prsentation de la plateforme PREDIS 10
II.1.1. Implantation et objectifs de la plateforme 10
II.1.2. Instrumentation de PREDIS 11
II.2. Objectifs du stage 13
III. Les missions du stage 14
III.1. Mise en place dinterfaces Web Service 14
III.1.1. Equipements domotiques en 433 MHz 15
III.1.2. Gestion Technique du Btiment 20
III.1.3. Equipements Zigbee 23
III.1.4. Tests de robustesse 25
III.2. Gestion de projet et management 26

Conclusion
Annexes

Salom BENSLAMA 3 Mai-30 Juillet 2010 Page | 3





Remerciements


A lissue de ce stage, mes remerciements iront tout dabord Monsieur Stphane PLOIX, mon
matre de stage, pour son accueil et la confiance quil ma accord ds mon arrive dans le
laboratoire, ainsi qu{ Messieurs Shadi ABRAS et Stphane BERGEON pour le temps quils mont
consacr tout au long de cette priode en rpondant toutes mes interrogations. Je tiens
remercier galement toute lquipe du laboratoire G-SCOP pour mavoir intgre rapidement au
sein de leur dpartement.


Grenoble, le 30 Juillet 2010
S.B.
Salom BENSLAMA 3 Mai-30 Juillet 2010 Page | 4



Introduction

Aprs des sicles dutilisation de lnergie sans restriction ni conscience, la limitation de limpact
environnemental de notre mode de vie est devenue une problmatique majeure du monde
scientifique daujourdhui, tant en terme de rduction des sources de pollution quen terme de
gestion des flux nergtiques.
Lhabitat, en particulier, reprsente une large part de la consommation dnergie, 24% environ,
et loptimisation de la consommation des foyers constitue un enjeu capital pour le monde de la
recherche, et plus long terme pour le monde industriel. Deux laboratoires de recherche
grenoblois, le G2ELAB (Grenoble Gnie Electrique) et le G-SCOP (Grenoble Sciences pour la
Conception, lOptimisation et la Production), ont ainsi initi des recherches sur la gestion
intelligente des flux nergtiques dans lhabitat. Le G-SCOP a en outre dvelopp des outils pour
adapter le comportement dun btiment { lactivit humaine qui lui est associe.

Cest autour de cette problmatique que jai pu, du 3 mai 2010 au 30 juillet 2010, effectuer mon
stage de fin de quatrime anne, au sein du dpartement 3I de Polytech Grenoble et sous la
direction du laboratoire G-SCOP. Stphane PLOIX, enseignant chercheur et maitre de confrence
{ lINP Grenoble a assur la direction du stage et jai galement t amene collaborer avec
plusieurs autres personnes du laboratoire.
Le sujet la mise en place dun systme domotique et dun SCADA pour la gestion des flux
nergtiques de la plateforme monitoring et habitat intelligent de PREDIS sinscrit dans la
volont de ce laboratoire doffrir des outils concrets pour valoriser la recherche et le progrs
dans ce domaine : lobjectif tant de rendre accessibles les donnes relatives une plateforme
test.

Le prsent rapport dtaillera dans un premier temps lhistoire et les principaux domaines
dactivit du laboratoire G-SCOP, puis introduira le cadre du stage ainsi que ses objectifs et son
cahier des charges, pour enfin prciser et expliciter les diffrentes missions effectues au cours
de ces trois mois de stage pour atteindre ces objectifs.
Salom BENSLAMA 3 Mai-30 Juillet 2010 Page | 5

I. Le laboratoire G-SCOP et ses secteurs dactivit
I.1. Prsentation gnrale
I.1.1. Historique
La rgion Rhne-Alpes, et plus particulirement lagglomration grenobloise et la valle du
Grsivaudan, constituent un des sites historiques de la recherche scientifique franaise. La
recherche en automatique par exemple, est prsente depuis plus de 50 ans sur le site de
Grenoble, avec la cration en 1957 du Laboratoire dAutomatique de Grenoble (LAG) par Ren
Perret. Dautres domaines lis dans leurs applications avec le LAG sont galement reprsents :
gnie industriel, optimisation tous sont fortement prsents dans la vie de la recherche au plan
national et travaillent en collaboration les uns avec les autres car leurs domaines dactivit
sentrecroisent souvent, se superposent parfois.
Au 1
er
janvier 2007, tous les laboratoires grenoblois ont t fondus et profondment
restructurs pour devenir des laboratoires centrs autour de ples de comptences rpondant
aux exigences du monde industriel actuel. Le laboratoire G-SCOP a ainsi t fond autour des
thmes de la conception, de loptimisation et de la production : G-SCOP accueille 140 chercheurs
issus des laboratoires LAG (automatique et supervision), Leibniz/IMAG (optimisation), GILCO
(gnie industriel) et 3S (conception mcanique). Aujourdhui, le laboratoire dpend la fois du
groupe Grenoble-INP, du CNRS et de lUJF (Universit Joseph Fourier) (fig. 1).


Figure 1 - Organismes de tutelle du laboratoire G-SCOP

Le laboratoire G-SCOP constitue donc un laboratoire pluridisciplinaire dont lobjectif premier est
de rpondre aux enjeux dun monde industriel en pleine mutation : ses comptences stendent
de la conception de produit { loptimisation, en passant par la gestion des systmes de
production. La notion de dveloppement durable y est omniprsente, aussi bien pour la
croissance dune entreprise, la prennit dun produit ou encore le plus immdiat, la gestion de
lnergie dans le btiment.

I.1.2. Organisation administrative et scientifique
Afin de cerner au mieux les besoins du monde industriel daujourdhui, le laboratoire est pens
autour de deux ples de comptences distincts (fig. 2) : Optimisation et systmes de production
dune part, Conception intgre dautre part.
Salom BENSLAMA 3 Mai-30 Juillet 2010 Page | 6







































Directeur du laboratoire
Yannick FREIN
Directeur adjoint
Franois VILLENEUVE
Optimisation et
Systmes de Production
Conception Intgre
Conception
collaborative


Frdric
NOEL
Conception
produit-process


Peggy
ZWOLINSKI
Systme
dInformation et
Reprsentation
multiple du produit
Michel
TOLLENAERE
Optimisation
Combinatoire


Andras
SEBO
Gestion et
Conduite des
Systmes de
Production
Maria
DI MASCOLO
Recherche
oprationnelle
pour les systmes
de production
Bernard
PENZ
Directeur du laboratoire
Yannick FREIN
Directeur adjoint
Franois VILLENEUVE
Finances
Amandine MONIN
Administration
Myriam OLIVA
Moyens
Informatiques
Jean-Yves ALLARD

Cellule Dpenses

Kheira TOURKI
Claudia DROGO
Infrastructure

Chantal PUECH
Souad BOUJIT
Ressources
Humaines
Fadila
MESSAOUD
Rseaux

Cdric EYRAUD
Sbastien
MARTIN
Applications
Fabrice
GRAVELAT
Jonathan
MARTINAT

Figure 2 Organigrammes scientifique et administratif du laboratoire G-SCOP
Salom BENSLAMA 3 Mai-30 Juillet 2010 Page | 7

I.2. Secteurs dactivit du laboratoire
I.2.2. Des ples pluridisciplinaires au service du monde industriel
Le laboratoire est organis autour de deux ples de comptences capables de rpondre
idalement aux besoins du monde industriel.

Optimisation et Systmes de Production
Le premier ple vise amliorer la conception et la gestion des systmes de production. Pour
cela, les systmes doivent tre modliss, les modles analyss et le dveloppement repose sur
de puissants outils doptimisation.

Les chercheurs de lquipe Optimisation combinatoire, issus du laboratoire Leibniz/IMAG,
dveloppent des outils mathmatiques doptimisation ; leur travail consiste rechercher la
meilleure solution parmi un ensemble, trs large, de toutes les solutions possibles et se base sur
des problmatiques de structures combinatoires.
Lquipe Recherche oprationnelle pour les systmes de production utilise des rsultats et des
mthodes doptimisation pour amliorer lefficience des systmes de production, et ce { toutes
les tapes de dcision lies ces systmes conception, planification, transport ; ces outils
doivent permettre aux entreprises daccroitre leurs performances par un gain de temps et un
processus de dveloppement optimal.
Lquipe Gestion et conduite des systmes de production, essentiellement issue du LAG et du
GILCO, semploie { dvelopper des outils pour faire face aux alas dans les systmes de
production et regroupe des thmes tels que le diagnostic, la sret de fonctionnement, la
robustesse et la surveillance, ce qui conduit traiter des problmatiques industrielles sur les
chanes logistiques, les systmes hospitaliers ou encore la supervision des flux nergtiques.
Cest { cette quipe que jai t rattache pendant toute la dure de mon stage, et plus
particulirement aux personnes tudiant les flux nergtiques dans lhabitat.

Conception intgre
Le second ple a pour objectif lamlioration de la conception des produits grce { ltude de
leur cycle de vie et des mthodes de conception.

Lquipe Conception collaborative cherche avoir une approche collaborative dans la conception
des produits, cest--dire inclure tous les acteurs de la chaine de conception, production et
utilisation du produit, jusquau recyclage, pour favoriser les changes et interactions.
Pour lquipe Conception produit-process lobjectif est dtudier toutes les mtiers qui entrent en
jeu dans la conception dun produit pour mieux les intgrer et les utiliser dans le processus de
conception et mieux apprhender leurs exigences et contraintes.
Salom BENSLAMA 3 Mai-30 Juillet 2010 Page | 8

Enfin, lquipe Systme dinformation et reprsentation multiple du produit (SIREP) sattache {
dfinir ou amliorer les systmes dinformations lis { la conception dun produit car ils
constituent une tape incontournable de ce processus.

I.2.3. La gestion des flux nergtiques dans lhabitat, un dfi technologique et cologique mais
aussi un march en plein essor
Ds 2003, les chercheurs du laboratoire G-SCOP ont initi des travaux de recherche sur la
gestion intelligente des flux nergtiques dans lhabitat. Les tudes et outils qui en dcoulent
constituent un enjeu considrable puisque les techniques utilises nen sont, pour la plupart,
qu{ leurs balbutiements, et que peu dentre elles sont rellement dployes sur le terrain. Pour
les industries en effet, la gestion de ces flux nergtiques ncessite des moyens srs, fiables et
faciles installer et { maintenir, ce qui nest pas vraiment le cas { lheure actuelle ; pour les
particuliers, les outils domotiques demeurent un march de niche rserv aux technophiles, en
raison notamment de leur cot dinstallation important.
Cest pourquoi la recherche en domotique et immotique fait apparaitre un rel dfi
technologique et cologique : technologique car les modles et mthodes ne sont pas tous
connus et maitriss, cologique car au-del du confort apport, la gestion des flux nergtiques
peut permettre des conomies dnergies considrables ainsi que lutilisation dnergies propres
et renouvelables.

La domotique, terme apparu au milieu des annes 1980, est ne de la prolifration et de la
miniaturisation des composants lectroniques ainsi que du dveloppement des technologies de
communication. Lide de faire dialoguer des composantes de lhabitat jusque-l isoles en lots
a donc germ. A une autre chelle, limmotique (nologisme issu du mot immeuble) dsigne
lapplication de ces mmes objectifs un immeuble ou un site industriel dans son ensemble et
ncessite des techniques de plus grande envergure. Ces outils tendent en outre se
dmocratiser depuis quelques annes avec lavnement dune conscience cologique collective
et lintrt grandissant du grand public pour la protection de lenvironnement. Car si le but
premier de la domotique et de limmotique nest pas immdiatement cologique mais plutt
daugmenter le confort de lhabitat, il demeure indniable que ces outils peuvent contribuer aux
conomies dnergie et ainsi { la prservation de notre plante, en particulier par une meilleure
gestion des flux nergtiques au sein de lhabitat. Bien que ce contexte favorable ait pouss la
recherche dans ces domaines, il nexiste nanmoins, que peu de foyers ou de locaux industriels
qui aient accs une vritable supervision et gestion intelligente du btiment. La plupart des
appareils existants ne constituent effectivement quune partie automatise de lhabitat comme
les tlcommandes pour volets roulants, pour portails automatiques ou encore les thermostats
pour rgler la temprature et quasiment aucun noffre une supervision globale permettant de
Salom BENSLAMA 3 Mai-30 Juillet 2010 Page | 9

piloter lensemble des quipements disponibles dans la maison. Par ailleurs, quasiment aucun ne
propose de dimension intelligente : pas dadaptation { loccupant et aux conditions
extrieures, et encore moins de gestion intelligente de lnergie.

En rgion Rhne-Alpes, ces thmatiques sont traites, et ce depuis quelques annes, par de
nombreux projets mens de front par plusieurs laboratoires grenoblois, comme le projet ANR
Multisol (optimisation des flux lectriques dans un btiment photovoltaque), lANR PREBAT
(btiment { nergie positive), lANR DLDPV (diagnostic dinstallation photovoltaque), mais
galement travers le cluster 7 initi par la rgion Rhne-Alpes pour la gestion de lnergie dans
le btiment.
Le laboratoire G-SCOP, et le laboratoire G2ELAB notamment, ont montr que la gestion des flux
nergtiques pouvait grandement tre amliore par une commande plusieurs niveaux :
anticipatif, ractif et local. Par une meilleure coordination entre les sources dnergies et les
charges, les quantits de gaz effet de serre rejetes peuvent tre considrablement rduites,
sans dlaisser ou diminuer le confort ni ncessairement modifier le btiment. Par ailleurs, le
laboratoire travaille sur des outils permettant de mieux reconnaitre et modliser les activits
humaines { partir dinformations provenant de capteurs, et ce afin de mieux apprhender la
flexibilit inhrente au contexte des btiments habits. Depuis 2009, le laboratoire mne une
action conjointe avec le G2ELAB autour de la plateforme de recherche et dinnovation PREDIS
(fig. 3).




Figure 3 - Logo de la plateforme PREDIS, Smart Networks for Energy


Salom BENSLAMA 3 Mai-30 Juillet 2010 Page | 10

II. Le cadre du stage
II.1. Prsentation de la plateforme PREDIS
II.1.2. Implantation et objectifs de la plateforme
La plateforme PREDIS est un centre ddi { la recherche pour linnovation et la formation dans
le domaine de la gestion nergtique intelligente des btiments.
Le projet a dmarr en 2009, avec la construction de la plateforme par les laboratoires G2ELAB,
G-SCOP, LIG (Laboratoire dInformatique de Grenoble) et LEGI (Laboratoire des Ecoulements
Gophysiques et Industriels) mais galement par des acteurs du monde industriels tels que
France Telecom, et se poursuit depuis avec la mise en exploitation de la plateforme pour la
recherche nergtique.
Cette plateforme dune surface totale de 2500 m, a t implante au sein du campus
universitaire de Grenoble, dans les locaux de lcole ENSE
3
du groupe Grenoble INP (Ecole
Nationale Suprieure de lEau, lEnergie et lEnvironnement). Elle sert de centre de formation
pour les tudiants de lcole, mais aussi et surtout, de centre dinnovation pour les chercheurs et
de plateforme de dmonstration.

Le centre PREDIS ayant vocation { servir dexemple en matire dhabitat intelligent et plus
particulirement en terme de gestion intelligente de lnergie, il a t spar en deux espaces
distincts : le premier, situ au rez-de-chausse, abrite une partie des moyens exprimentaux du
laboratoire G2ELAB (Grenoble Gnie Electrique) consacre aux flux nergtiques ; le second
espace, au premier tage, reconstitue un espace dhabitat tertiaire, autour dune salle
informatique (fig. 4) utilise par les lves de lcole et dun bureau de recherche. Cest
prcisment ce dernier espace qui constitue lessentiel du centre de dmonstration PREDIS : cet
espace tertiaire comprend, outre la salle informatique et lespace bureau, deux locaux
techniques contenant, lun la centrale de traitement dair (CTA), lautre, un serveur et le
dispositif de supervision de la plateforme (fig. 5 et 6). Cet espace permet ainsi de tester en
conditions relles des modles et algorithmes de gestion intelligente de lnergie, qui pourront
ensuite tre appliqus dans le domaine concret de lhabitat.

La construction du btiment qui abrite la plateforme PREDIS a d prendre en compte
dimportantes contraintes dconomie dnergie : les murs sont ainsi composs de pltre, de
ouate de cellulose et dune planche de bois ; les baies vitres ont t ralises en double vitrage ;
lclairage utilise des nons basse consommation dont lallumage ne se dclenche que lorsquun
mouvement est dtect par lun des capteurs installs dans les salles et dont lintensit est
automatiquement rgle en fonction de la luminosit naturelle grce des capteurs de
luminosit.
Salom BENSLAMA 3 Mai-30 Juillet 2010 Page | 11

Figure 6 - Local de supervision





















II.1.3. Instrumentation de PREDIS
Afin davoir un suivi des flux dnergie au sein de la plateforme, ainsi quun moyen daction sur
ces derniers, la partie habitat tertiaire a t fortement instrumente. Le rseau de capteurs
utilise diffrentes technologies ayant chacune leurs spcificits et leur mode de communication.

Le premier local technique abrite la centrale de traitement dair servant la ventilation et au
chauffage de la plateforme par apport dair { temprature et dbit fixs. La rgulation en
temprature se fait selon deux scnarios, le principe tant seulement de profiter des
tempratures les plus fraiches : en hiver, de lair extrieur chauff par des batteries deau chaude
est expuls en continu lintrieur, alors quen t, lair extrieur est aspir uniquement de nuit
pour tre rejet sans tre trait. Afin de recueillir des informations sur la pice, diffrents
capteurs de prsences, de temprature, dhumidit de lair ainsi que des compteurs dnergies
pour toutes les prises de courant, les batteries deau chaude et lclairage sont installs.
La premire partie de linstrumentation de la salle, de loin la plus importante, repose sur une
GTB (Gestion Technique du Btiment) galement appele GTC (Gestion Technique Centralise),
une technologie issue de limmotique. Elle consiste essentiellement en une CTA permettant de
Figure 4 - Salle informatique
Figure 5 - Local technique de la CTA
Salom BENSLAMA 3 Mai-30 Juillet 2010 Page | 12

traiter lair qui circule au sein de la plateforme et fonctionnant avec une VMC double flux
(Ventilation Mcanique Contrle) et des compteurs dnergie sensibles au kWh quips sur le
tableau lectrique. La CTA possde de plus quelques sondes de temprature, de dbit dair pour
le suivi de la VMC et de prsence pour la gestion de lclairage. Cette premire partie de
linstrumentation repose donc sur une structure relativement lourde et inerte, difficile { prendre
en main et { modifier en cas de besoin. Cest pourquoi un autre rseau de capteurs a t install
en parallle de cette GTB : il repose quant lui sur des quipements lgers et communicants,
plus facile mettre en place mais galement complter le cas chant. La premire partie de
cette instrumentation parallle consiste en un rseau dquipements domotiques communiquant
tous sur la bande radio 433MHz (sondes de temprature et dhygromtrie Oregon Scientific,
anmomtre et pluviomtre Oregon Scientific, RFXMeter pour mesurer la consommation
nergtique et quipements X10) ; les quipements X10 consistent en des prises commandables
distance par CPL (Courant Porteur en Ligne) et une passerelle du CPL vers le 433MHz. Afin
davoir une vision plus prcise de la consommation lectrique pour une prise (les compteurs
dnergie de la GTB tant limits au kWh), des wattmtres fonctionnant en norme Zigbee sont
actuellement ajouts : leur installation sur chacune des prises, et particulirement sur celles qui
alimentent des ordinateurs portables, devrait permettre de suivre de faon prcise la courbe de
consommation lectrique.

Le second local constitue un local de supervision puisque lordinateur est quip dun SCADA
(Supervisory Control And Data Acquisition). Ce systme de tlgestion
1
permet le contrle des
automates et le traitement en temps rel des donnes qui lui sont envoyes, aussi bien pour
avoir un suivi de la salle (lecture de donnes) que pour effectuer des actions de type contrle
commande (criture de donnes ou dordres). Lordinateur est galement quip du logiciel
InTouch qui permet de visualiser graphiquement les informations ainsi recueillies et de
contrler certains rglages comme les tempratures de chauffage ou le fonctionnement de la
CTA. Ce logiciel permet ainsi de grer le SCADA de faon graphique, ce qui savre nettement
plus ais pour lutilisateur. Cette installation offre une vue densemble de la salle et regroupe
prs de 900 variables internes pouvant tre utilises pour du suivi, de larchivage ou du contrle.

Il est prvu terme dajouter { lquipement disponible sur la plateforme une base de donnes
facilement accessible pour les utilisateurs. Lajout de cette base de donnes commune tous les
quipements permettrait de plus davoir un suivi prcis de la salle et de favoriser larchivage des
donnes. De cette manire, toute personne se connectant cette base de donnes pourrait
prendre connaissance dun historique exhaustif de la plateforme, ce qui peut savrer utile dune
part pour analyser et tudier le fonctionnement de la salle, corriger ou modifier le contrle du

1
Gestion { distance dinstallations techniques
Salom BENSLAMA 3 Mai-30 Juillet 2010 Page | 13

gestionnaire, surveiller la raction correcte de la supervision aux vnements, mais galement
pour modliser le modle thermique de la salle ou concevoir des quipements supplmentaires
tel quun systme de refroidissement pour lhabitat tertiaire. Ces deux dernires thmatiques
sont dailleurs traites par des tudiants, galement stagiaires sur la plateforme PREDIS.

II.2. Objectifs du stage
La plateforme PREDIS tant une plateforme de dmonstration, lobjectif principal pour son
lquipe dirigeante consiste la transformer en une plateforme test o les chercheurs et/ou
industriels pourraient venir tester leurs algorithmes ou programmes de supervision pour la
gestion intelligente du btiment.

La plateforme PREDIS doit donc tre convertie en open platform libre daccs ; pour cela, et pour
chaque type dquipement utilis dans la salle, une interface de type Web Service sera mise en
place.
Le principe de fonctionnement de ces interfaces repose sur la communication de donnes entre
plusieurs ordinateurs relis par un rseau et rpondant une hirarchie serveur-client, cette
solution offrant lavantage de fournir les donnes nergtiques et de suivi de la salle { toute
personne se connectant aux serveurs. De plus, elle permet aux utilisateurs de la plateforme de
communiquer avec un standard de plus en plus utilis dans le monde industriel pour sa praticit
et sa fiabilit. A terme, ces Web Services pourront tre scuriss pour devenir accessibles de
lextrieur et non plus seulement sur le rseau local de la plateforme : ceci permettrait une
meilleure accessibilit des donnes et une plus grande porte pour le service offert par PREDIS.

Lobjectif du stage que jai effectu au sein du laboratoire G-SCOP tait prcisment la
conception et la ralisation de ces Web Services, ce qui supposait au pralable la comprhension
des protocoles de communication avec les quipements de la plateforme, le dcodage des
informations, la conception de larchitecture des programmes des serveurs ainsi que
llaboration de clients types.
Les programmes devaient tre dvelopps en langage Python, choisi pour sa portabilit et
facilit dcriture. Ce langage offre de plus de nombreuses bibliothques pour laborer toutes
sortes de services ici trs utiles : le langage Python est en effet un langage interprt et non
compil ce qui le rend portable sur nimporte quelle plateforme (autrement dit, un mme
programme peut tre utilis indiffremment sur diffrents systmes dexploitation). Par ailleurs,
pour chaque Web Service, des diagrammes de classes UML devaient tre crs, afin doptimiser
la phase de conception.
Salom BENSLAMA 3 Mai-30 Juillet 2010 Page | 14

III. Les missions du stage
III.1. Mise en place dinterfaces Web Service
Le moyen le plus simple et le plus efficace pour rendre accessibles les donnes relatives la
plateforme PREDIS est de les publier sur le rseau par lintermdiaire dun Web Service. Ce
programme permet lchange de donnes entre plusieurs ordinateurs relis un mme rseau
grce des requtes : lordinateur qui est connect physiquement aux donnes sert de serveur, il
reoit les requtes des autres ordinateurs qui sont alors clients et traite les informations selon le
contenu des requtes reues (connexion, acquisition de donnes, criture). La plateforme tant
compose de trois types dquipements distincts capables de fournir des donnes, quipements
433 MHz, GTB et Zigbee, elle est donc quipe de trois Web Service pour les publier (fig. 7). Afin
de simplifier leur future utilisation, ces Web Services sont standardiss au maximum et leur
structure logicielle est dtaille en annexe (annexes 1 6).















Capteurs
Energie, Prsence, Dbit
dair, Temprature
Automates
programmables
Bus de
terrain
Rseau
Serveur OPC et SCADA
incomplet
Matrikon OPC
Data Manager
Serveur OPC
accessible
GTB
Equipements
X10
Prises
commandables
Oregon Scientific
Temprature,
Hygromtrie,
Anmomtrie
RFXMeter
Consommation
lectrique
433MHz
RFXCOM
433MHz
Wattmtres
433MHz
via
Passerelle
CPL
Zigbee
Web Service
Web Service
Web Service
Base de
donnes
Figure 7 - Synoptique de la plateforme PREDIS
Salom BENSLAMA 3 Mai-30 Juillet 2010 Page | 15

III.1.2. Equipements domotiques en 433 MHz
Contrairement la GTB, technique lourde issue de limmotique, les quipements domotiques qui
fonctionnent sur 433MHz sont des quipements lgers : ils sont aliments sur batteries et
consomment peu, offrant ainsi une grande dure de vie des piles. De plus, ils ne ncessitent pas
dinstallation complexe : les sondes de temprature et dhygromtrie possdent des supports
simplement visss au mur, les prises X10 ainsi que le RFXMeter sont naturellement branchs sur
les prises voulues sans plus dinstallation ncessaire.
Lanmomtre et le pluviomtre nont pas encore t mis en place au sein de la plateforme ; leur
installation { lextrieur du btiment pose de nombreux problmes en terme de porte mais
aussi dimplantation. En effet, les toits du btiment sont composs de tles obliques lgres
empchant linstallation dquipements { lhorizontale, qui plus est en cas dquipements
lourds ; mais limplantation des sondes sur dautres btiments risquerait dentrainer une porte
insuffisante pour pouvoir recevoir les donnes et donc les analyser.
Les autres types de capteurs en 433MHz sont en revanche fonctionnels. Les sondes de
temprature et dhygromtrie ont t installes au sein de la plateforme de faon avoir un suivi
global de ltat des salles. Il faut nanmoins tre assez prcis pour distinguer les diffrentes
zones de la plateforme, cest pourquoi dix sondes ont t rparties selon le plan suivant (fig. 8) :
quatre dans la salle informatique (dont une au niveau du shed (toiture), deux dans lespace
bureau, une dans le local de supervision, une { lextrieur de la plateforme (espace attenant
ferm mais non utilis) et enfin deux dans le local technique de la CTA.

Figure 8 Plan dimplantation des sondes de temprature et dhygromtrie

Toutes ces sondes envoient leurs donnes sur une bande radio libre, la bande 433MHz. Cette
bande radio est laisse libre pour les quipements individuels mais certaines rglementations
doivent nanmoins tre respectes, en particulier des rglementations techniques telles que la
basse tension ou la compatibilit lectromagntique. De plus, cette bande de frquence tant
Salom BENSLAMA 3 Mai-30 Juillet 2010 Page | 16

libre, aucune dclaration nest ncessaire et son utilisation est gratuite. En revanche, cette
libert pose quelques problmes en particulier le nombre croissant dutilisateurs de cette bande
radio qui rend les brouillages de plus en plus frquents et labsence de recours possible pour ces
utilisateurs. En Europe, une autre bande est laisse libre : la bande autour de 868MHz qui offre
plus de possibilits mais donc les contraintes sont plus nombreuses. En plus de
linstrumentation, lutilisation de cette bande de frquence ncessite un quipement
supplmentaire pour la rception des trames de donnes, un RFXCOM. Cet appareil permet de
capter les trames qui passent sur la bande 433MHz, il est compatible avec la plupart des
quipements domotiques et permet ainsi de pouvoir communiquer de faon automatique avec
les quipements qui lui sont associs. En effet, le RFXCOM une fois aliment, peut tre branch
sur un rseau Ethernet et communiquer avec lui par protocole TCP/IP pour recevoir les trames
hexadcimales en provenance des capteurs directement sur un ordinateur et les analyser, les
traiter Cette solution savre trs performante puisquelle rend possible la communication
centralise (par un mme appareil) avec plusieurs capteurs de types diffrents (fig. 9 13). Le
RFXCOM naccepte quune seule connexion et cest aussi pourquoi un Web Service est utile.



Figure 9 - RFXCOM Figure 10 - Prise commandable X10


Figure 11 - Sondes de temprature Figure 12 - RFX Meter Figure 13 - Anmomtre
et d'hygromtrie


Salom BENSLAMA 3 Mai-30 Juillet 2010 Page | 17

La conception de ce Web Service sest appuye sur un certain nombre dexigences : offrir un
maximum de services, garantir un certain niveau de robustesse, communiquer avec des langages
standardiss de haut niveau. Afin de respecter ces contraintes, des choix ont t faits, tant au
niveau des langages et protocoles utiliss quen terme de standardisation et de services offerts.
Les services offerts par ce Web Service sont multiples : rponse aux requtes HTTP des clients
pour connatre les dernires valeurs de temprature, dhumidit et de mesures dnergie,
rponse { des clients de type serveur en callback pour larchivage des donnes, ouverture en
criture pour commander les prises X10 et possibilit denvoi des trames en hexadcimal pour
un aspect pdagogique. Pour cela, la connexion entre le RFXCOM et le serveur se fait par un
socket tandis que les communications client-serveur se font par HTTP (protocole de plus haut
niveau dabstraction), et il a fallu maitriser les bibliothques inhrentes ces fonctions afin de
tirer parti au mieux de leurs performances : la connexion avec le RFXCOM ne ncessite pas de
communication complexe et la structure du socket qui permet lenvoi et la rception de trames
de donnes suffit amplement. En revanche, le protocole HTTP est bien plus performant pour la
communication entre le client et le serveur en raison des mthodes apportes. Ensuite, la
communication entre le serveur et le ou les client(s) se fait uniquement, dans les requtes HTTP,
par langage XML (fig. 14), langage de balisage extensible car standardis, trs utilis dans le
monde de linformatique (par exemple les pages web) et surtout modulable : il est dit extensible
car cest lutilisateur qui choisit larborescence et le nom des balises. La syntaxe des requtes
HTTP respecte le format XML qui est fix par le serveur et le client se doit de le respecter pour
tre compris. Le schma XML a t labor de faon harmoniser les diffrentes requtes et
ainsi simplifier la conception des parser (classe danalyse syntaxique pour dcoder les balises
XML) : les balises sont toujours les mmes mais les valeurs changent ce qui permet dutiliser le
mme parser pour toutes les requtes en provenance des clients.











Concernant la lecture des donnes, deux aspects sont dvelopps en parallle. Les trames de
donnes en provenance des sondes parvenant en permanence au RFXCOM, larchivage des
Serveur Client
serve_forever
getData par http et XML
Traitement : dernires valeurs reues
Rponse 200 (statut ok) et valeurs par http et XML
Figure 14 - Squencement des communications entre le client et le serveur
Salom BENSLAMA 3 Mai-30 Juillet 2010 Page | 18

donnes ncessite un client en callback : cest un programme qui, { son inscription auprs du
serveur, renvoie un hte et un port de callback sur lequel il peut tre rappel. Ce client devient
alors un serveur et le serveur de base devient son client et chaque trame reue est
automatiquement transfre vers le serveur en callback. Pour cela, le serveur principal cre une
liste de contacts auxquels il doit renvoyer les trames. Si cette technique permet de ne manquer
aucune information et devient indispensable pour un archivage sur une base de donnes, elle
noffre en revanche aucun intrt pour quelquun qui souhaite tudier les donnes et pour lequel
il est plus intressant dutiliser un client qui envoie des requtes la frquence voulue. Les
trames hexadcimales reues peuvent, dans le cas du client en callback, tre dcodes avant
dtre envoyes pour une utilisation simplifie ou bien tre envoyes brutes pour une utilisation
pdagogique ou les lves doivent concevoir le dcodeur. Enfin, concernant louverture en
criture, il est possible denvoyer des commandes pour allumer ou teindre une prise. Un
encodeur traduit la commande en une trame comprhensible par les quipements. Cela peut
permettre deffectuer un monitoring dans la salle informatique selon le niveau de batteries des
ordinateurs, ou leur consommation lectrique et de les basculer sur batterie ou sur le rseau
lectrique. Le serveur Web possde de plus une interface graphique rendant la lecture des
donnes plus aise (fig. 15).

Salom BENSLAMA 3 Mai-30 Juillet 2010 Page | 19

Figure 15 - Capture d'cran, Serveur
Salom BENSLAMA 3 Mai-30 Juillet 2010 Page | 20

III.1.3. Gestion Technique du Btiment
Les sondes relatives la GTB transmettent leurs informations via des automates
programmables, tous relis par bus de terrain (LonWorks et ModBus) un automate principal
qui transmet les informations au serveur principal par protocole TCP/IP et surtout par interface
OPC. Toutes les informations disponibles sur les automates sont en effet regroupes par un
serveur OPC, auquel un client OPC peut se connecter pour lire les donnes. Cette solution offre
limmense avantage de regrouper toutes les informations sur la CTA et la consommation
lectrique de lhabitat tertiaire de faon standardise et relativement simple daccs. La norme
OPC est un standard de communication initialis par Microsoft, maintenant gr par la fondation
OPC qui permet de simplifier la communication entre les applications de supervision (ici le
SCADA install sur lordinateur du local de supervision) et les actionneurs (ici les API). La norme
OPC rserve nanmoins certaines limites car elle ne peut tre utilise que sur le systme
dexploitation Windows en raison des protocoles de communication sur lesquels elle sappuie
qui sont spcifiques Windows. Par ailleurs, { lintrieur du serveur OPC, des couches automation
sont implmentes de manire attaquer le serveur OPC avec des programmes crits dans
diffrents langages. Comme OPC est une norme Windows, on distingue deux couches
automation : lune qui donne laccs au serveur pour des programmes crits avec des langages
de type C++, C Sharp (C#) et lautre pour les programmes de type Java, Python
Malheureusement, dans le serveur OPC install sur la plateforme PREDIS, la couche automation
pour les programmes Python na pas t implmente et cette difficult doit donc tre
contourne, soit en ajoutant un programme C# qui attaque le serveur OPC avant le Web Service
(dvelopp en Python), soit en utilisant les logiciels Matrikon OPC qui simulent un nouveau
serveur OPC accessible { partir du serveur OPC originel. Cest cette solution qui a t choisie
dans un premier temps pour sa facilit de mise en uvre. Nanmoins, elle devient laborieuse {
paramtrer ds lors que le nombre de variables utilises est important, cest pourquoi un
programme sera prochainement dvelopp pour donner laccs au Web Service sans passer par
ces logiciels. Pour le moment, il faut passer par deux logiciels, Matrikon Simulation et Matrikon
Data Manager : Matrikon Simulation permet de simuler un serveur OPC sur lequel on ajoute des
variables (des tags) qui sont accessibles pour les programmes python tandis que Matrikon Data
Manager permet de crer des points de liaison pour relier les variables qui nous intressent sur
le serveur OPC primaire (serveur maitre) celles ajoutes au pralable sur le serveur de
simulation (serveur esclave). Par cette manipulation, les donnes prsentes sur le serveur OPC
de la plateforme PREDIS deviennent accessibles pour le Web Service, qui se connecte au serveur
de simulation.

Ceci tant dit, le Web Service qui a t dvelopp pour cette partie de la plateforme permet la
lecture des donnes du serveur OPC mais galement lcriture sur ce mme serveur. En effet, les
Salom BENSLAMA 3 Mai-30 Juillet 2010 Page | 21

donnes reprsentes par les variables du serveur sont diverses : mesures de temprature dans
les pices et { lextrieur, mesure des dbits de soufflage et dextraction de la CTA, valeur des
compteurs pour la consommation lectrique (limite au kWh), des capteurs de fin de course
mais aussi des consignes de temprature et de vitesse, des commandes et des variables
boolennes manuel/automatique. Pour ces trois dernires, laccs en criture est primordial
puisquil permet de modifier le comportement de la CTA, deffectuer des rglages de dbit, de
changer des consignes de temprature pour les pices ou encore de passer la CTA en mode
automatique ou manuel. Pour le mode manuel, il existe galement des variables qui ne sont
prises en compte que dans ce mode comme la vitesse de rotation manuelle de la CTA par
exemple. Pour raliser le Web Service, il a fallu sparer les variables pertinentes de celles qui
taient inutiles ou errones puis crer les fichiers de configuration pour les logiciels Matrikon. A
cet effet, une nouvelle nomenclature a t faite de faon { rendre lidentification dune variable la
plus aise possible et { standardiser leur nom, ce qui ntait absolument pas le cas pour les
variables disponibles sur le serveur OPC { lorigine.

Comme pour les Web Service utiliss par les quipements en 433 MHz, la communication entre
le serveur et les clients se fait par HTTP, avec des chaines respectant le mme format XML. La
connexion au serveur OPC se fait grce la libraire OpenOPC pour Python qui permet de lire des
donnes, crire des valeurs Un autre aspect important est celui de laffichage des donnes ainsi
recueillies : leur nombre tant bien trop lev pour concevoir une interface graphique claire, il a
t dcid de publier ces donnes sur une page Web (fig. 16 et 17). En effet, un navigateur Web,
lorsquil essaie daccder { une adresse, envoie une requte HTTP de type GET. La prise en
compte de ce type de requte a donc t ajoute dans ce Web Service afin renvoyer une chaine
XML et donc de pouvoir visualiser ltat des variables directement { partir dun navigateur
internet. Enfin, il a fallu faire un choix quant { laccessibilit des variables en criture : toutes ne
sont effectivement pas ncessaires pour lcriture, et il aurait t possible de limiter les droits
dcriture aux quelques variables qui taient juges utiles. Nanmoins, la politique de la
plateforme tant doffrir le maximum de services et le maximum de tests possibles, toutes les
variables ont t laisses ouvertes en criture et cest aux utilisateurs de prendre garde { leurs
modifications. Si la manuvre est peu risque pour une mesure de temprature, qui sera
crase la prochaine mesure, cela peut tre plus dangereux pour les variables auto/manu ou
on/off car elles peuvent arrter compltement la CTA et donc la ventilation dans la pice. Les
utilisateurs sont les garants du bon fonctionnement de la plateforme et ils doivent veiller
remettre les valeurs correctes des variables aprs leurs essais.

Salom BENSLAMA 3 Mai-30 Juillet 2010 Page | 22


Figure 16 - Capture d'cran, Serveur


Figure 17 - Extrait de la page Web gnre par le serveur
Salom BENSLAMA 3 Mai-30 Juillet 2010 Page | 23

III.1.4. Equipements Zigbee
Comme il a t dit, la GTB est quipe de compteurs pour la consommation lectrique mais ceux-
ci sont limits en sensibilit au kWh. De ce fait, un suivi prcis de la consommation lectrique de
la salle est extrmement difficile et cest pourquoi des wattmtres prcis au dixime de Watt
sont actuellement ajouts la plateforme (fig. 19). Ils permettent davoir une vision beaucoup
plus complte de la consommation lectrique dans la plateforme PREDIS car les informations
disponibles sont trs prcises, puissance, nergie, courant, tension, et rendent possible une
analyse trs fine de la consommation lectrique des appareils. Ces wattmtres envoient leurs
donnes avec une technologie Zigbee, qui est un protocole de communication sans fil bas sur la
norme gnrique IEEE 802.15.4. Ce protocole se place sur le mme march que le Wifi ou le
Bluetooth mais offre lavantage dune trs faible consommation, dune fiabilit assez leve et
dun prix de revient drisoire. En revanche, il ne bnficie que dune porte de lordre de 100m
selon le milieu et les obstacles contre 300m pour le Wifi et constitue de plus un protocole de
communication relativement lent. Pour la plateforme PREDIS, ces quipements offrent
lavantage dune trs faible consommation lectrique, ce qui peut se rvler dterminant pour
une sonde place dans un lieu difficile daccs, et cette problmatique sest dailleurs pose pour
lajout de nouveaux capteurs, problmatique sur laquelle nous reviendrons plus tard. Quinze
wattmtres sont ainsi installs dans la salle informatique pour pouvoir suivre au plus prs la
courbe de consommation des quinze ordinateurs dont la plateforme est quipe. Pour recevoir
les donnes envoyes en Zigbee, un rcepteur est ncessaire : un XBee Pro (fig. 18). Dautres
fournisseurs et dautres marques existent sur le march avec des performances diffrentes en
fonction des tarifs. Un autre rcepteur Zigbee a dailleurs t command pour le mois de
Septembre afin de dissocier laspect recherche et laspect pdagogique.



Figure 18 - Rcepteur Zigbee Figure 19 - Wattmtre


Salom BENSLAMA 3 Mai-30 Juillet 2010 Page | 24

Le Web Service conu ici est en apparence le plus simple puisquil ne ncessite quun accs en
lecture. Le rcepteur est connect { lordinateur qui hberge le serveur grce { un port USB qui
mule un port srie. Dans le programme, il convient donc dutiliser une bibliothque spcifique
pour la gestion des ports srie. Concernant la robustesse du service offert ainsi que ses
performances, un problme sest rapidement pos : le rcepteur offre la possibilit dinterroger
un quipement la fois ou bien tous les appareils dtects dun coup. A premire vue, la seconde
solution est bien plus avantageuse en terme de temps de rponse et donc de performance du
service mais reprsente galement une simplification majeure pour le programme. Nanmoins,
aprs la mise en place dun protocole de test, cette solution sest avre peu fiable car la rponse
des wattmtres tait alatoire selon la distance au rcepteur et de plus, il semblerait que le
rcepteur ait des performances limites en terme de gestion des conflits : les trames reues
saccumulent dans le buffer et dgradent la rception. Pour ces raisons, il a finalement t choisi
dinterroger les wattmtres un par un. Le temps ncessaire au service est certes un peu allong
mais le niveau de robustesse est garanti. La lecture des donnes reues est facilite par une
interface graphique (fig. 20).




Figure 20 - Capture d'cran, serveur


Salom BENSLAMA 3 Mai-30 Juillet 2010 Page | 25

III.1.5. Tests de robustesse
Au-del{ de la publication des donnes, lobjectif pour les Web Service tait aussi dtre robustes
et fiables.

Le premier aspect prendre en compte pour mesurer la robustesse du service tait la rsistance
aux multiples connexions. Pour les Web Service de la GTB et pour le Zigbee, cet aspect tait
relativement simple puisque les seuls changes ont lieu lorsque les clients envoient des requtes
et mme sil y a plusieurs clients, cela ne pose pas de problmes. En revanche, pour les
quipements en 433 MHz, le fait que les sondes envoient des trames en continu et non
uniquement sur demande ncessite un serveur en callback pour larchivage des donnes et ce
dernier est bien plus dlicat. De nombreux tests ont donc t mis en place pour vrifier que le
serveur se comporte bien en cas de clients multiples : ces tests ont t fructueux puisque de
nombreuses modifications ont t apportes au vu des rsultats obtenus. En effet, les tests ont
permis de mettre en vidence certaines faiblesses de larchitecture, notamment concernant la
dconnexion des clients. Celle-ci peut seffectuer de deux manires : si le client est arrt, le
serveur continue dessayer de lui envoyer les trames reues et cette opration impossible lve
une exception ou bien le client est dconnect manuellement par le serveur. Dans les deux cas, la
liste contenant les contacts doit tre correctement gre. Pour la suppression manuelle par le
serveur, il suffit de supprimer le contact de la liste. Pour prendre en compte le cas o le client a
t arrt, un systme de timeout a t cr : cela consiste associer une date et une heure la
cration de chaque message { envoyer et fixer un dlai pour lenvoyer. Si le client est
dconnect, le serveur cherche { le recontacter jusqu{ ce que le message soit dpass. A ce
moment l, le client est supprim de la liste des contacts.
Le deuxime aspect tudier pour la fiabilit des Web Service tait les donnes elles mmes :
leur rception peut tre fausse, les donnes modifies ou errones. Pour les quipements en
433 MHz, le RFXCOM peut parfois envoyer non pas une mais plusieurs trames accoles et il faut
les sparer, parfois les donnes sont errones et il faut les supprimer. Concernant la GTB, il a
fallu faire un tri parmi les variables car certaines ne sont plus utilises. Enfin, pour le Zigbee, les
trames tant entoures de balises hexadcimales, leur longueur est allonge lorsque ces mmes
caractres se retrouvent dans la trame et il faut alors faire un premier dcodage pour avoir la
trame hexadcimale complte.

Quelques tests unitaires ont enfin t raliss sur les modules dencodage et de dcodage des
trames afin de vrifier quils fonctionnaient selon les objectifs souhaits : dcodage complet des
trames correctes, renvoi de messages spcifiques pour les trames errones, dtection des
diffrents types de trames existantes.

Salom BENSLAMA 3 Mai-30 Juillet 2010 Page | 26

III.2. Gestion de projet et management
Tout au long du stage et afin davoir un suivi de lensemble des activits relatives { la plateforme
PREDIS, des runions ont t organises de manire coordonner au mieux les tches, viter les
doublons et la perte de temps et pour mener une rflexion commune autour des problmes
rencontrs. Ces sances ont ainsi runi tous les stagiaires travaillant sur PREDIS tous les quinze
jours environ : chaque personne prsente se devait dy effectuer une courte prsentation de son
travail et de son avancement ; un compte rendu dactivits devait galement tre rdig
chaque fin de semaine et { lissue de chaque runion. Du fait de la prsence dune stagiaire
indienne ne parlant pas franais, les runions et les rapports ont systmatiquement utilis la
langue anglaise (annexe 7).

Au cours de mon stage jai par ailleurs t amene, durant les mois de juin et juillet, guider un
stagiaire nouvellement arriv sur la plateforme : sa tche consistant enrichir linstrumentation
de PREDIS, je lai aid en ce qui concerne les diffrentes technologies de protocoles de
communication utiliss, et lai initi aux avantages et inconvnients lis leur mise en place dans
la plate forme PREDIS.
Salom BENSLAMA 3 Mai-30 Juillet 2010 Page | 27



Conclusion

Au cours de ces trois mois de stage au sein du laboratoire G-SCOP, jai pu pour la premire fois
apprhender les problmatiques lies la gestion intelligente des flux nergtiques dans
lhabitat.

Cette exprience, initialement guide par mon gout a priori pour la domotique, a confirm mes
futurs choix professionnels : la varit des tches (informatique industrielle, programmation,
gestion de projet), lapport de connaissances nouvelles (langage Python, notion de Web Service,
communication par sockets et HTTP) et la dimension environnementale de ce projet ont en effet
concid avec mes attentes dans ce domaine de comptence particulier.
Ce stage ma du reste permis de dvelopper mes capacits dadaptation, de dcouvrir de
nouvelles comptences et donc daccrotre mes aptitudes techniques et humaines par la
conception et llaboration de services qui seront concrtement utiliss au sein de la plateforme
PREDIS.

Le bilan de ce stage savre au final extrmement positif puisque tous les objectifs fixs en dbut
de stage et par le cahier des charges ont t remplis.
Salom BENSLAMA 3 Mai-30 Juillet 2010 Page | 28

Lexique

SCADA : Supervisory Control And Data Acquisition
Systme de tlgestion et dacquisition de donnes permettant grer grande
chelle et { distance un grand nombre dquipements
Domotique : Ensemble des techniques utilises dans lhabitat visant { amliorer le confort, la
gestion de lnergie, la scurit et la communication
Immotique : Elargissement de la domotique { lchelle dun immeuble ou dun site industriel.
Les solutions les plus couramment installes sont la GTB et la GTC
GTB : Gestion Technique du Btiment
Appellation dsignant tous les quipements et services permettant le suivi ainsi
que le contrle et la commande de la gestion nergtique dun btiment ; sous ce
terme sont regroups les rseaux de capteurs, les automates programmables qui
les commandent ainsi que les programmes de supervision.
GTC : Gestion Technique Centralise
Identique GTB
CTA : Centrale de Traitement de lAir
Unit permettant le traitement et la ventilation de lair qui circule au sein de la
plateforme : la rgulation concerne aussi bien la qualit de lair (quantit en CO
2

rgule par ventilation) que la temprature.
VMC : Ventilation Mcanique Contrle, ici Double Flux
Dispositif destin { assurer le renouvellement de lair dans un btiment. Couple
{ un changeur thermique, une VMC double flux permet de chauffer lair entrant
en hiver et de le rafraichir lt grce { lair sortant du btiment.
CPL : Courant Porteur en Ligne
Technologie permettant le transfert dinformations via le rseau lectrique grce
{ des techniques de modulation de frquence. Cest une alternative aux cbles et
au Wifi.
Web Service : Programme informatique permettant lchange de donnes et la communication
par internet ou intranet (rseau informatique local)
Anmomtre : Sonde permettant de mesurer la vitesse et la direction du vent
HTTP : HyperText Transfer Protocol
Protocole de communication de type client-serveur. La couche de transport est le
protocole TCP.
XML : Extensible Markup Langage
Langage informatique de balisage numrique permettant de transfrer des
donnes dans des champs de type arborescents.
API : Automate Programmable Industriel
Dispositif lectronique programmable structur autour dune unit de calcul et
compos de modules tels que des entres et sorties analogiques et numriques et
des modules de communication (bus de terrain ModBus et LonWorks)

Salom BENSLAMA 3 Mai-30 Juillet 2010 Page | 29

Sondes Oregon
Scientific,
RFXMeter et
X10


RFXCOM

Serveur Web


WS
REST
Client Web


Bande radio
433 MHz
Socket
Requte HTTP
Format XML







Annexe 1 : Diagramme UML des composants (quipements 433 MHz)


Salom BENSLAMA 3 Mai-30 Juillet 2010 Page | 30








Annexe 2 : Diagramme UML des classes (quipements 433 MHz)


Salom BENSLAMA 3 Mai-30 Juillet 2010 Page | 31

Sondes


Serveur Web


WS
REST
Client Web


Connexion analogique
ou numrique
Client OPC
Requte HTTP
Format XML
Automates
programmables

Matrikon Data
Manager









Annexe 3 : Diagramme UML des composants (Gestion Technique du Btiment)


Salom BENSLAMA 3 Mai-30 Juillet 2010 Page | 32









Annexe 4 : Diagramme UML des classes (Gestion Technique du Btiment)



Salom BENSLAMA 3 Mai-30 Juillet 2010 Page | 33

Wattmtres


Rcepteur
Zigbee


Emission
Zigbee
Serveur Web


WS
REST
Client Web


Protocole
Zigbee
Port Srie mul
sur USB
Requte HTTP
Format XML







Annexe 5 : Diagramme UML des composants (quipements Zigbee)



Salom BENSLAMA 3 Mai-30 Juillet 2010 Page | 34








Annexe 6 : Diagramme UML des classes (quipements Zigbee)



Salom BENSLAMA 3 Mai-30 Juillet 2010 Page | 35








Annexe 7 : Droulement du stage (3 Mai 2010 30 Juillet 2010)