Rapport de Stage - forge.imag.fr©... · Salomé BENSLAMA 3 Mai-30 Juillet 2010 Page | 3 Remerciements A l’issue de ce stage, mes remerciements iront tout d’abord à Monsieur

Sa

lom

é B

EN

SL

AM

A

3 M

ai –

30

Ju

ille

t 2

01

0

Ra

pp

ort

de

Sta

ge

RAPPORT UNIVERSITAIRE

Mise en place d'un système domotique et d'un SCADA

pour la gestion des flux énergétiques de la plateforme

Monitoring et Habitat Intelligent de PREDIS

Maitre de stage : Stéphane Ploix

Polytech’ Grenoble

Département 3I 4

Laboratoire G-SCOP, Grenoble INP 46, avenue Félix Viallet

38031 Grenoble

Salomé BENSLAMA 3 Mai-30 Juillet 2010 Page | 2

Sommaire

Introduction

I. Le laboratoire G-SCOP et ses secteurs d’activité 5

I.1. Le laboratoire G-SCOP 5

I.1.1. Historique 5

I.1.2. Organisation administrative et scientifique 5

I.2. Secteurs d’activité du laboratoire 7

I.2.1. Des pôles pluridisciplinaires au service du monde industriel 7

I.2.2. La gestion des flux énergétiques dans l’habitat, un défi technologique et

écologique mais aussi un marché en plein essor 8

II. Le cadre du stage 10

II.1. Présentation 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 d’interfaces Web Service 14

III.1.1. Equipements domotiques en 433 MHz 15

III.1.2. Gestion Technique du Bâtiment 20

III.1.3. Equipements Zigbee 23

III.1.4. Tests de robustesse 25

III.2. Gestion de projet et management 26

Conclusion

Annexes


Remerciements

A l’issue de ce stage, mes remerciements iront tout d’abord à Monsieur Stéphane PLOIX, mon

maître de stage, pour son accueil et la confiance qu’il m’a accordé dès mon arrivée dans le

laboratoire, ainsi qu’{ Messieurs Shadi ABRAS et Stéphane BERGEON pour le temps qu’ils m’ont

consacré tout au long de cette période en répondant à toutes mes interrogations. Je tiens à

remercier également toute l’équipe du laboratoire G-SCOP pour m’avoir intégrée rapidement au

sein de leur département.

Grenoble, le 30 Juillet 2010

S.B.


Introduction

Après des siècles d’utilisation de l’énergie sans restriction ni conscience, la limitation de l’impact

environnemental de notre mode de vie est devenue une problématique majeure du monde

scientifique d’aujourd’hui, tant en terme de réduction des sources de pollution qu’en terme de

gestion des flux énergétiques.

L’habitat, en particulier, représente une large part de la consommation d’énergie, 24% environ,

et l’optimisation 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 Génie Electrique) et le G-SCOP (Grenoble Sciences pour la

Conception, l’Optimisation et la Production), ont ainsi initié des recherches sur la gestion

intelligente des flux énergétiques dans l’habitat. Le G-SCOP a en outre développé des outils pour

adapter le comportement d’un bâtiment { l’activité humaine qui lui est associée.

C’est autour de cette problématique que j’ai pu, du 3 mai 2010 au 30 juillet 2010, effectuer mon

stage de fin de quatrième année, au sein du département 3I de Polytech’ Grenoble et sous la

direction du laboratoire G-SCOP. Stéphane PLOIX, enseignant chercheur et maitre de conférence

{ l’INP Grenoble a assuré la direction du stage et j’ai également été amenée à collaborer avec

plusieurs autres personnes du laboratoire.

Le sujet — la mise en place d’un système domotique et d’un SCADA pour la gestion des flux

énergétiques de la plateforme monitoring et habitat intelligent de PREDIS — s’inscrit dans la

volonté de ce laboratoire d’offrir des outils concrets pour valoriser la recherche et le progrès

dans ce domaine : l’objectif étant de rendre accessibles les données relatives à une plateforme

test.

Le présent rapport détaillera dans un premier temps l’histoire et les principaux domaines

d’activité du laboratoire G-SCOP, puis introduira le cadre du stage ainsi que ses objectifs et son

cahier des charges, pour enfin préciser et expliciter les différentes missions effectuées au cours

de ces trois mois de stage pour atteindre ces objectifs.


I. Le laboratoire G-SCOP et ses secteurs d’activité

I.1. Présentation générale

I.1.1. Historique

La région Rhône-Alpes, et plus particulièrement l’agglomération grenobloise et la vallée du

Grésivaudan, constituent un des sites historiques de la recherche scientifique française. La

recherche en automatique par exemple, est présente depuis plus de 50 ans sur le site de

Grenoble, avec la création en 1957 du Laboratoire d’Automatique de Grenoble (LAG) par René

Perret. D’autres domaines liés dans leurs applications avec le LAG sont également représentés :

génie industriel, optimisation… tous sont fortement présents dans la vie de la recherche au plan

national et travaillent en collaboration les uns avec les autres car leurs domaines d’activité

s’entrecroisent souvent, se superposent parfois.

Au 1er janvier 2007, tous les laboratoires grenoblois ont été fondus et profondément

restructurés pour devenir des laboratoires centrés autour de pôles de compétences répondant

aux exigences du monde industriel actuel. Le laboratoire G-SCOP a ainsi été fondé autour des

thèmes de la conception, de l’optimisation et de la production : G-SCOP accueille 140 chercheurs

issus des laboratoires LAG (automatique et supervision), Leibniz/IMAG (optimisation), GILCO

(génie industriel) et 3S (conception mécanique). Aujourd’hui, le laboratoire dépend à la fois du

groupe Grenoble-INP, du CNRS et de l’UJF (Université Joseph Fourier) (fig. 1).

Figure 1 - Organismes de tutelle du laboratoire G-SCOP

Le laboratoire G-SCOP constitue donc un laboratoire pluridisciplinaire dont l’objectif premier est

de répondre aux enjeux d’un monde industriel en pleine mutation : ses compétences s’étendent

de la conception de produit { l’optimisation, en passant par la gestion des systèmes de

production. La notion de développement durable y est omniprésente, aussi bien pour la

croissance d’une entreprise, la pérennité d’un produit ou encore le plus immédiat, la gestion de

l’énergie dans le bâtiment.

I.1.2. Organisation administrative et scientifique

Afin de cerner au mieux les besoins du monde industriel d’aujourd’hui, le laboratoire est pensé

autour de deux pôles de compétences distincts (fig. 2) : Optimisation et systèmes de production

d’une part, Conception intégrée d’autre part.


Directeur du laboratoire

Yannick FREIN

Directeur adjoint

François VILLENEUVE

Optimisation et Systèmes de Production

Conception Intégrée

Conception collaborative

Frédéric NOEL

Conception produit-process

Peggy ZWOLINSKI

Système d’Information et Représentation

multiple du produit

Michel TOLLENAERE

Optimisation Combinatoire

Andras SEBO

Gestion et Conduite des Systèmes de Production

Maria DI MASCOLO

Recherche opérationnelle

pour les systèmes de production

Bernard PENZ

Directeur du laboratoire

Yannick FREIN

Directeur adjoint

François VILLENEUVE

Finances

Amandine MONIN

Administration

Myriam OLIVA

Moyens Informatiques

Jean-Yves ALLARD

Cellule Dépenses

Kheira TOURKI Claudia DROGO

Infrastructure

Chantal PUECH Souad BOUJIT

Ressources Humaines

Fadila MESSAOUD

Réseaux

Cédric EYRAUD Sébastien MARTIN

Applications Fabrice

GRAVELAT Jonathan

MARTINAT

Figure 2 – Organigrammes scientifique et administratif du laboratoire G-SCOP


I.2. Secteurs d’activité du laboratoire

I.2.2. Des pôles pluridisciplinaires au service du monde industriel

Le laboratoire est organisé autour de deux pôles de compétences capables de répondre

idéalement aux besoins du monde industriel.

Optimisation et Systèmes de Production

Le premier pôle vise à améliorer la conception et la gestion des systèmes de production. Pour

cela, les systèmes doivent être modélisés, les modèles analysés et le développement repose sur

de puissants outils d’optimisation.

Les chercheurs de l’équipe Optimisation combinatoire, issus du laboratoire Leibniz/IMAG,

développent des outils mathématiques d’optimisation ; leur travail consiste à rechercher la

meilleure solution parmi un ensemble, très large, de toutes les solutions possibles et se base sur

des problématiques de structures combinatoires.

L’équipe Recherche opérationnelle pour les systèmes de production utilise des résultats et des

méthodes d’optimisation pour améliorer l’efficience des systèmes de production, et ce { toutes

les étapes de décision liées à ces systèmes — conception, planification, transport ; ces outils

doivent permettre aux entreprises d’accroitre leurs performances par un gain de temps et un

processus de développement optimal.

L’équipe Gestion et conduite des systèmes de production, essentiellement issue du LAG et du

GILCO, s’emploie { développer des outils pour faire face aux aléas dans les systèmes de

production et regroupe des thèmes tels que le diagnostic, la sûreté de fonctionnement, la

robustesse et la surveillance, ce qui conduit à traiter des problématiques industrielles sur les

chaînes logistiques, les systèmes hospitaliers ou encore la supervision des flux énergétiques.

C’est { cette équipe que j’ai été rattachée pendant toute la durée de mon stage, et plus

particulièrement aux personnes étudiant les flux énergétiques dans l’habitat.

Conception intégrée

Le second pôle a pour objectif l’amélioration de la conception des produits grâce { l’étude de

leur cycle de vie et des méthodes de conception.

L’équipe Conception collaborative cherche à avoir une approche collaborative dans la conception

des produits, c’est-à-dire à inclure tous les acteurs de la chaine de conception, production et

utilisation du produit, jusqu’au recyclage, pour favoriser les échanges et interactions.

Pour l’équipe Conception produit-process l’objectif est d’étudier toutes les métiers qui entrent en

jeu dans la conception d’un produit pour mieux les intégrer et les utiliser dans le processus de

conception et mieux appréhender leurs exigences et contraintes.


Enfin, l’équipe Système d’information et représentation multiple du produit (SIREP) s’attache {

définir ou améliorer les systèmes d’informations liés { la conception d’un produit car ils

constituent une étape incontournable de ce processus.

I.2.3. La gestion des flux énergétiques dans l’habitat, un défi technologique et écologique mais

aussi un marché en plein essor

Dès 2003, les chercheurs du laboratoire G-SCOP ont initié des travaux de recherche sur la

gestion intelligente des flux énergétiques dans l’habitat. Les études et outils qui en découlent

constituent un enjeu considérable puisque les techniques utilisées n’en sont, pour la plupart,

qu’{ leurs balbutiements, et que peu d’entre elles sont réellement déployées sur le terrain. Pour

les industries en effet, la gestion de ces flux énergétiques nécessite des moyens sûrs, fiables et

faciles à installer et { maintenir, ce qui n’est pas vraiment le cas { l’heure actuelle ; pour les

particuliers, les outils domotiques demeurent un marché de niche réservé aux technophiles, en

raison notamment de leur coût d’installation important.

C’est pourquoi la recherche en domotique et immotique fait apparaitre un réel défi

technologique et écologique : technologique car les modèles et méthodes ne sont pas tous

connus et maitrisés, écologique car au-delà du confort apporté, la gestion des flux énergétiques

peut permettre des économies d’énergies considérables ainsi que l’utilisation d’énergies propres

et renouvelables.

La domotique, terme apparu au milieu des années 1980, est née de la prolifération et de la

miniaturisation des composants électroniques ainsi que du développement des technologies de

communication. L’idée de faire dialoguer des composantes de l’habitat jusque-là isolées en îlots

a donc germé. A une autre échelle, l’immotique (néologisme issu du mot immeuble) désigne

l’application de ces mêmes objectifs à un immeuble ou un site industriel dans son ensemble et

nécessite des techniques de plus grande envergure. Ces outils tendent en outre à se

démocratiser depuis quelques années avec l’avènement d’une conscience écologique collective

et l’intérêt grandissant du grand public pour la protection de l’environnement. Car si le but

premier de la domotique et de l’immotique n’est pas immédiatement écologique mais plutôt

d’augmenter le confort de l’habitat, il demeure indéniable que ces outils peuvent contribuer aux

économies d’énergie et ainsi { la préservation de notre planète, en particulier par une meilleure

gestion des flux énergétiques au sein de l’habitat. Bien que ce contexte favorable ait poussé la

recherche dans ces domaines, il n’existe néanmoins, que peu de foyers ou de locaux industriels

qui aient accès à une véritable supervision et gestion intelligente du bâtiment. La plupart des

appareils existants ne constituent effectivement qu’une partie automatisée de l’habitat comme

les télécommandes pour volets roulants, pour portails automatiques ou encore les thermostats

pour régler la température et quasiment aucun n’offre une supervision globale permettant de


piloter l’ensemble des équipements disponibles dans la maison. Par ailleurs, quasiment aucun ne

propose de dimension « intelligente » : pas d’adaptation { l’occupant et aux conditions

extérieures, et encore moins de gestion intelligente de l’énergie.

En région Rhône-Alpes, ces thématiques sont traitées, et ce depuis quelques années, par de

nombreux projets menés de front par plusieurs laboratoires grenoblois, comme le projet ANR

Multisol (optimisation des flux électriques dans un bâtiment photovoltaïque), l’ANR PREBAT

(bâtiment { énergie positive), l’ANR DLDPV (diagnostic d’installation photovoltaïque), mais

également à travers le cluster 7 initié par la région Rhône-Alpes pour la gestion de l’énergie dans

le bâtiment.

Le laboratoire G-SCOP, et le laboratoire G2ELAB notamment, ont montré que la gestion des flux

énergétiques pouvait grandement être améliorée par une commande à plusieurs niveaux :

anticipatif, réactif et local. Par une meilleure coordination entre les sources d’énergies et les

charges, les quantités de gaz à effet de serre rejetées peuvent être considérablement réduites,

sans délaisser ou diminuer le confort ni nécessairement modifier le bâtiment. Par ailleurs, le

laboratoire travaille sur des outils permettant de mieux reconnaitre et modéliser les activités

humaines { partir d’informations provenant de capteurs, et ce afin de mieux appréhender la

flexibilité inhérente au contexte des bâtiments habités. Depuis 2009, le laboratoire mène une

action conjointe avec le G2ELAB autour de la plateforme de recherche et d’innovation PREDIS

(fig. 3).

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


II. Le cadre du stage

II.1. Présentation de la plateforme PREDIS

II.1.2. Implantation et objectifs de la plateforme

La plateforme PREDIS est un centre dédié { la recherche pour l’innovation et la formation dans

le domaine de la gestion énergétique intelligente des bâtiments.

Le projet a démarré en 2009, avec la construction de la plateforme par les laboratoires G2ELAB,

G-SCOP, LIG (Laboratoire d’Informatique de Grenoble) et LEGI (Laboratoire des Ecoulements

Géophysiques 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 énergétique.

Cette plateforme d’une surface totale de 2500 m², a été implantée au sein du campus

universitaire de Grenoble, dans les locaux de l’école ENSE3 du groupe Grenoble INP (Ecole

Nationale Supérieure de l’Eau, l’Energie et l’Environnement). Elle sert de centre de formation

pour les étudiants de l’école, mais aussi et surtout, de centre d’innovation pour les chercheurs et

de plateforme de démonstration.

Le centre PREDIS ayant vocation { servir d’exemple en matière d’habitat intelligent et plus

particulièrement en terme de gestion intelligente de l’énergie, il a été séparé en deux espaces

distincts : le premier, situé au rez-de-chaussée, abrite une partie des moyens expérimentaux du

laboratoire G2ELAB (Grenoble Génie Electrique) consacrée aux flux énergétiques ; le second

espace, au premier étage, reconstitue un espace d’habitat tertiaire, autour d’une salle

informatique (fig. 4) utilisée par les élèves de l’école et d’un bureau de recherche. C’est

précisément ce dernier espace qui constitue l’essentiel du centre de démonstration PREDIS : cet

espace tertiaire comprend, outre la salle informatique et l’espace bureau, deux locaux

techniques contenant, l’un la centrale de traitement d’air (CTA), l’autre, un serveur et le

dispositif de supervision de la plateforme (fig. 5 et 6). Cet espace permet ainsi de tester en

conditions réelles des modèles et algorithmes de gestion intelligente de l’énergie, qui pourront

ensuite être appliqués dans le domaine concret de l’habitat.

La construction du bâtiment qui abrite la plateforme PREDIS a dû prendre en compte

d’importantes contraintes d’économie d’énergie : les murs sont ainsi composés de plâtre, de

ouate de cellulose et d’une planche de bois ; les baies vitrées ont été réalisées en double vitrage ;

l’éclairage utilise des néons basse consommation dont l’allumage ne se déclenche que lorsqu’un

mouvement est détecté par l’un des capteurs installés dans les salles et dont l’intensité est

automatiquement réglée en fonction de la luminosité naturelle grâce à des capteurs de

luminosité.


Figure 6 - Local de supervision

II.1.3. Instrumentation de PREDIS

Afin d’avoir un suivi des flux d’énergie au sein de la plateforme, ainsi qu’un moyen d’action sur

ces derniers, la partie habitat tertiaire a été fortement instrumentée. Le réseau de capteurs

utilise différentes technologies ayant chacune leurs spécificités et leur mode de communication.

Le premier local technique abrite la centrale de traitement d’air servant à la ventilation et au

chauffage de la plateforme par apport d’air { température et débit fixés. La régulation en

température se fait selon deux scénarios, le principe étant seulement de profiter des

températures les plus fraiches : en hiver, de l’air extérieur chauffé par des batteries d’eau chaude

est expulsé en continu à l’intérieur, alors qu’en été, l’air extérieur est aspiré uniquement de nuit

pour être rejeté sans être traité. Afin de recueillir des informations sur la pièce, différents

capteurs de présences, de température, d’humidité de l’air ainsi que des compteurs d’énergies

pour toutes les prises de courant, les batteries d’eau chaude et l’éclairage sont installés.

La première partie de l’instrumentation de la salle, de loin la plus importante, repose sur une

GTB (Gestion Technique du Bâtiment) également appelée GTC (Gestion Technique Centralisée),

une technologie issue de l’immotique. Elle consiste essentiellement en une CTA permettant de

Figure 4 - Salle informatique

Figure 5 - Local technique de la CTA


traiter l’air qui circule au sein de la plateforme et fonctionnant avec une VMC double flux

(Ventilation Mécanique Contrôlée) et des compteurs d’énergie sensibles au kWh équipés sur le

tableau électrique. La CTA possède de plus quelques sondes de température, de débit d’air pour

le suivi de la VMC et de présence pour la gestion de l’éclairage. Cette première partie de

l’instrumentation repose donc sur une structure relativement lourde et inerte, difficile { prendre

en main et { modifier en cas de besoin. C’est pourquoi un autre réseau de capteurs a été installé

en parallèle de cette GTB : il repose quant à lui sur des équipements légers et communicants,

plus facile à mettre en place mais également à compléter le cas échéant. La première partie de

cette instrumentation parallèle consiste en un réseau d’équipements domotiques communiquant

tous sur la bande radio 433MHz (sondes de température et d’hygrométrie Oregon Scientific,

anémomètre et pluviomètre Oregon Scientific, RFXMeter pour mesurer la consommation

énergétique 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

d’avoir une vision plus précise de la consommation électrique pour une prise (les compteurs

d’énergie de la GTB étant limités au kWh), des wattmètres fonctionnant en norme Zigbee sont

actuellement ajoutés : leur installation sur chacune des prises, et particulièrement sur celles qui

alimentent des ordinateurs portables, devrait permettre de suivre de façon précise la courbe de

consommation électrique.

Le second local constitue un local de supervision puisque l’ordinateur est équipé d’un SCADA

(Supervisory Control And Data Acquisition). Ce système de télégestion1 permet le contrôle des

automates et le traitement en temps réel des données qui lui sont envoyées, aussi bien pour

avoir un suivi de la salle (lecture de données) que pour effectuer des actions de type contrôle

commande (écriture de données ou d’ordres). L’ordinateur est également équipé du logiciel

InTouch qui permet de visualiser graphiquement les informations ainsi recueillies et de

contrôler certains réglages comme les températures de chauffage ou le fonctionnement de la

CTA. Ce logiciel permet ainsi de gérer le SCADA de façon graphique, ce qui s’avère nettement

plus aisé pour l’utilisateur. Cette installation offre une vue d’ensemble de la salle et regroupe

près de 900 variables internes pouvant être utilisées pour du suivi, de l’archivage ou du contrôle.

Il est prévu à terme d’ajouter { l’équipement disponible sur la plateforme une base de données

facilement accessible pour les utilisateurs. L’ajout de cette base de données commune à tous les

équipements permettrait de plus d’avoir un suivi précis de la salle et de favoriser l’archivage des

données. De cette manière, toute personne se connectant à cette base de données pourrait

prendre connaissance d’un historique exhaustif de la plateforme, ce qui peut s’avérer utile d’une

part pour analyser et étudier le fonctionnement de la salle, corriger ou modifier le contrôle du

1 Gestion { distance d’installations techniques


gestionnaire, surveiller la réaction correcte de la supervision aux évènements, mais également

pour modéliser le modèle thermique de la salle ou concevoir des équipements supplémentaires

tel qu’un système de refroidissement pour l’habitat tertiaire. Ces deux dernières thématiques

sont d’ailleurs traitées par des étudiants, également stagiaires sur la plateforme PREDIS.

II.2. Objectifs du stage

La plateforme PREDIS étant une plateforme de démonstration, l’objectif principal pour son

l’équipe 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 bâtiment.

La plateforme PREDIS doit donc être convertie en open platform libre d’accès ; pour cela, et pour

chaque type d’équipement 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 données entre

plusieurs ordinateurs reliés par un réseau et répondant à une hiérarchie serveur-client, cette

solution offrant l’avantage de fournir les données énergétiques 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 sécurisés pour devenir accessibles de

l’extérieur et non plus seulement sur le réseau local de la plateforme : ceci permettrait une

meilleure accessibilité des données et une plus grande portée pour le service offert par PREDIS.

L’objectif du stage que j’ai effectué au sein du laboratoire G-SCOP était précisément la

conception et la réalisation de ces Web Services, ce qui supposait au préalable la compréhension

des protocoles de communication avec les équipements de la plateforme, le décodage des

informations, la conception de l’architecture des programmes des serveurs ainsi que

l’élaboration de clients types.

Les programmes devaient être développés en langage Python, choisi pour sa portabilité et

facilité d’écriture. Ce langage offre de plus de nombreuses bibliothèques pour élaborer toutes

sortes de services ici très utiles : le langage Python est en effet un langage interprété et non

compilé ce qui le rend portable sur n’importe quelle plateforme (autrement dit, un même

programme peut être utilisé indifféremment sur différents systèmes d’exploitation). Par ailleurs,

pour chaque Web Service, des diagrammes de classes UML devaient être créés, afin d’optimiser

la phase de conception.


III. Les missions du stage

III.1. Mise en place d’interfaces Web Service

Le moyen le plus simple et le plus efficace pour rendre accessibles les données relatives à la

plateforme PREDIS est de les publier sur le réseau par l’intermédiaire d’un Web Service. Ce

programme permet l’échange de données entre plusieurs ordinateurs reliés à un même réseau

grâce à des requêtes : l’ordinateur qui est connecté physiquement aux données sert de serveur, il

reçoit les requêtes des autres ordinateurs qui sont alors clients et traite les informations selon le

contenu des requêtes reçues (connexion, acquisition de données, écriture…). La plateforme étant

composée de trois types d’équipements distincts capables de fournir des données, équipements

433 MHz, GTB et Zigbee, elle est donc équipée de trois Web Service pour les publier (fig. 7). Afin

de simplifier leur future utilisation, ces Web Services sont standardisés au maximum et leur

structure logicielle est détaillée en annexe (annexes 1 à 6).

Capteurs Energie, Présence, Débit

d’air, Température

Automates programmables

Bus de terrain

Réseau

Serveur OPC et SCADA incomplet

Matrikon OPC Data Manager

Serveur OPC accessible

GTB

Equipements X10

Prises commandables

Oregon Scientific Température, Hygrométrie, Anémométrie

RFXMeter Consommation

électrique

433MHz

RFXCOM 433MHz

Wattmètres

433MHz via

Passerelle CPL

Zigbee

Web Service

Web Service

Web Service

Base de données

Figure 7 - Synoptique de la plateforme PREDIS


III.1.2. Equipements domotiques en 433 MHz

Contrairement à la GTB, technique lourde issue de l’immotique, les équipements domotiques qui

fonctionnent sur 433MHz sont des équipements légers : ils sont alimentés sur batteries et

consomment peu, offrant ainsi une grande durée de vie des piles. De plus, ils ne nécessitent pas

d’installation complexe : les sondes de température et d’hygrométrie possèdent des supports

simplement vissés au mur, les prises X10 ainsi que le RFXMeter sont naturellement branchés sur

les prises voulues sans plus d’installation nécessaire.

L’anémomètre et le pluviomètre n’ont pas encore été mis en place au sein de la plateforme ; leur

installation { l’extérieur du bâtiment pose de nombreux problèmes en terme de portée mais

aussi d’implantation. En effet, les toits du bâtiment sont composés de tôles obliques légères

empêchant l’installation d’équipements { l’horizontale, qui plus est en cas d’équipements

lourds ; mais l’implantation des sondes sur d’autres bâtiments risquerait d’entrainer une portée

insuffisante pour pouvoir recevoir les données et donc les analyser.

Les autres types de capteurs en 433MHz sont en revanche fonctionnels. Les sondes de

température et d’hygrométrie ont été installées au sein de la plateforme de façon à avoir un suivi

global de l’état des salles. Il faut néanmoins être assez précis pour distinguer les différentes

zones de la plateforme, c’est pourquoi dix sondes ont été réparties selon le plan suivant (fig. 8) :

quatre dans la salle informatique (dont une au niveau du shed (toiture), deux dans l’espace

bureau, une dans le local de supervision, une { l’extérieur de la plateforme (espace attenant

fermé mais non utilisé) et enfin deux dans le local technique de la CTA.

Figure 8 – Plan d’implantation des sondes de température et d’hygrométrie

Toutes ces sondes envoient leurs données sur une bande radio libre, la bande 433MHz. Cette

bande radio est laissée libre pour les équipements individuels mais certaines réglementations

doivent néanmoins être respectées, en particulier des réglementations techniques telles que la

basse tension ou la compatibilité électromagnétique. De plus, cette bande de fréquence étant


libre, aucune déclaration n’est nécessaire et son utilisation est gratuite. En revanche, cette

liberté pose quelques problèmes en particulier le nombre croissant d’utilisateurs de cette bande

radio qui rend les brouillages de plus en plus fréquents et l’absence de recours possible pour ces

utilisateurs. En Europe, une autre bande est laissée libre : la bande autour de 868MHz qui offre

plus de possibilités mais donc les contraintes sont plus nombreuses. En plus de

l’instrumentation, l’utilisation de cette bande de fréquence nécessite un équipement

supplémentaire pour la réception des trames de données, 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 façon automatique avec

les équipements qui lui sont associés. En effet, le RFXCOM une fois alimenté, peut être branché

sur un réseau Ethernet et communiquer avec lui par protocole TCP/IP pour recevoir les trames

hexadécimales en provenance des capteurs directement sur un ordinateur et les analyser, les

traiter… Cette solution s’avère très performante puisqu’elle rend possible la communication

centralisée (par un même appareil) avec plusieurs capteurs de types différents (fig. 9 à 13). Le

RFXCOM n’accepte qu’une seule connexion et c’est aussi pourquoi un Web Service est utile.

Figure 9 - RFXCOM Figure 10 - Prise commandable X10

Figure 11 - Sondes de température Figure 12 - RFX Meter Figure 13 - Anémomètre

et d'hygrométrie


La conception de ce Web Service s’est appuyée sur un certain nombre d’exigences : offrir un

maximum de services, garantir un certain niveau de robustesse, communiquer avec des langages

standardisés de haut niveau. Afin de respecter ces contraintes, des choix ont été faits, tant au

niveau des langages et protocoles utilisés qu’en terme de standardisation et de services offerts.

Les services offerts par ce Web Service sont multiples : réponse aux requêtes HTTP des clients

pour connaître les dernières valeurs de température, d’humidité et de mesures d’énergie,

réponse { des clients de type serveur en callback pour l’archivage des données, ouverture en

écriture pour commander les prises X10 et possibilité d’envoi des trames en hexadécimal pour

un aspect pédagogique. 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 d’abstraction), et il a fallu maitriser les bibliothèques inhérentes à ces fonctions afin de

tirer parti au mieux de leurs performances : la connexion avec le RFXCOM ne nécessite pas de

communication complexe et la structure du socket qui permet l’envoi et la réception de trames

de données suffit amplement. En revanche, le protocole HTTP est bien plus performant pour la

communication entre le client et le serveur en raison des méthodes apportées. Ensuite, la

communication entre le serveur et le ou les client(s) se fait uniquement, dans les requêtes HTTP,

par langage XML (fig. 14), langage de balisage extensible car standardisé, très utilisé dans le

monde de l’informatique (par exemple les pages web) et surtout modulable : il est dit extensible

car c’est l’utilisateur qui choisit l’arborescence et le nom des balises. La syntaxe des requêtes

HTTP respecte le format XML qui est fixé par le serveur et le client se doit de le respecter pour

être compris. Le schéma XML a été élaboré de façon à harmoniser les différentes requêtes et

ainsi à simplifier la conception des parser (classe d’analyse syntaxique pour décoder les balises

XML) : les balises sont toujours les mêmes mais les valeurs changent ce qui permet d’utiliser le

même parser pour toutes les requêtes en provenance des clients.

Concernant la lecture des données, deux aspects sont développés en parallèle. Les trames de

données en provenance des sondes parvenant en permanence au RFXCOM, l’archivage des

Serveur Client

serve_forever getData par http et XML

Traitement : dernières valeurs reçues

Réponse 200 (statut ok) et valeurs par http et XML

Figure 14 - Séquencement des communications entre le client et le serveur


données nécessite un client en callback : c’est un programme qui, { son inscription auprès du

serveur, renvoie un hôte 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 reçue est

automatiquement transférée vers le serveur en callback. Pour cela, le serveur principal crée 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 données, elle

n’offre en revanche aucun intérêt pour quelqu’un qui souhaite étudier les données et pour lequel

il est plus intéressant d’utiliser un client qui envoie des requêtes à la fréquence voulue. Les

trames hexadécimales reçues peuvent, dans le cas du client en callback, être décodées avant

d’être envoyées pour une utilisation simplifiée ou bien être envoyées brutes pour une utilisation

pédagogique ou les élèves doivent concevoir le décodeur. Enfin, concernant l’ouverture en

écriture, il est possible d’envoyer des commandes pour allumer ou éteindre une prise. Un

encodeur traduit la commande en une trame compréhensible par les équipements. Cela peut

permettre d’effectuer 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 réseau

électrique. Le serveur Web possède de plus une interface graphique rendant la lecture des

données plus aisée (fig. 15).


Figure 15 - Capture d'écran, Serveur


III.1.3. Gestion Technique du Bâtiment

Les sondes relatives à la GTB transmettent leurs informations via des automates

programmables, tous reliés 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 regroupées par un

serveur OPC, auquel un client OPC peut se connecter pour lire les données. Cette solution offre

l’immense avantage de regrouper toutes les informations sur la CTA et la consommation

électrique de l’habitat tertiaire de façon standardisée et relativement simple d’accès. La norme

OPC est un standard de communication initialisé par Microsoft, maintenant géré par la fondation

OPC qui permet de simplifier la communication entre les applications de supervision (ici le

SCADA installé sur l’ordinateur du local de supervision) et les actionneurs (ici les API). La norme

OPC réserve néanmoins certaines limites car elle ne peut être utilisée que sur le système

d’exploitation Windows en raison des protocoles de communication sur lesquels elle s’appuie

qui sont spécifiques Windows. Par ailleurs, { l’intérieur du serveur OPC, des couches automation

sont implémentées de manière à attaquer le serveur OPC avec des programmes écrits dans

différents langages. Comme OPC est une norme Windows, on distingue deux couches

automation : l’une qui donne l’accès au serveur pour des programmes écrits avec des langages

de type C++, C Sharp (C#) et l’autre pour les programmes de type Java, Python…

Malheureusement, dans le serveur OPC installé sur la plateforme PREDIS, la couche automation

pour les programmes Python n’a pas été implémentée et cette difficulté doit donc être

contournée, soit en ajoutant un programme C# qui attaque le serveur OPC avant le Web Service

(développé en Python), soit en utilisant les logiciels Matrikon OPC qui simulent un nouveau

serveur OPC accessible { partir du serveur OPC originel. C’est cette solution qui a été choisie

dans un premier temps pour sa facilité de mise en œuvre. Néanmoins, elle devient laborieuse {

paramétrer dès lors que le nombre de variables utilisées est important, c’est pourquoi un

programme sera prochainement développé pour donner l’accès 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 créer des points de liaison pour relier les variables qui nous intéressent sur

le serveur OPC primaire (serveur maitre) à celles ajoutées au préalable sur le serveur de

simulation (serveur esclave). Par cette manipulation, les données présentes 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é développé pour cette partie de la plateforme permet la

lecture des données du serveur OPC mais également l’écriture sur ce même serveur. En effet, les


données représentées par les variables du serveur sont diverses : mesures de température dans

les pièces et { l’extérieur, mesure des débits de soufflage et d’extraction de la CTA, valeur des

compteurs pour la consommation électrique (limitée au kWh), des capteurs de fin de course

mais aussi des consignes de température et de vitesse, des commandes et des variables

booléennes manuel/automatique. Pour ces trois dernières, l’accès en écriture est primordial

puisqu’il permet de modifier le comportement de la CTA, d’effectuer des réglages de débit, de

changer des consignes de température pour les pièces 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 réaliser le Web Service, il a fallu séparer les variables pertinentes de celles qui

étaient inutiles ou erronées puis créer les fichiers de configuration pour les logiciels Matrikon. A

cet effet, une nouvelle nomenclature a été faite de façon { rendre l’identification d’une variable la

plus aisée possible et { standardiser leur nom, ce qui n’était absolument pas le cas pour les

variables disponibles sur le serveur OPC { l’origine.

Comme pour les Web Service utilisés par les équipements en 433 MHz, la communication entre

le serveur et les clients se fait par HTTP, avec des chaines respectant le même format XML. La

connexion au serveur OPC se fait grâce à la libraire OpenOPC pour Python qui permet de lire des

données, écrire des valeurs… Un autre aspect important est celui de l’affichage des données ainsi

recueillies : leur nombre étant bien trop élevé pour concevoir une interface graphique claire, il a

été décidé de publier ces données sur une page Web (fig. 16 et 17). En effet, un navigateur Web,

lorsqu’il essaie d’accéder { une adresse, envoie une requête HTTP de type GET. La prise en

compte de ce type de requête a donc été ajoutée dans ce Web Service afin renvoyer une chaine

XML et donc de pouvoir visualiser l’état des variables directement { partir d’un navigateur

internet. Enfin, il a fallu faire un choix quant { l’accessibilité des variables en écriture : toutes ne

sont effectivement pas nécessaires pour l’écriture, et il aurait été possible de limiter les droits

d’écriture aux quelques variables qui étaient jugées utiles. Néanmoins, la politique de la

plateforme étant d’offrir le maximum de services et le maximum de tests possibles, toutes les

variables ont été laissées ouvertes en écriture et c’est aux utilisateurs de prendre garde { leurs

modifications. Si la manœuvre est peu risquée pour une mesure de température, qui sera

écrasée à la prochaine mesure, cela peut être plus dangereux pour les variables auto/manu ou

on/off car elles peuvent arrêter complètement la CTA et donc la ventilation dans la pièce. Les

utilisateurs sont les garants du bon fonctionnement de la plateforme et ils doivent veiller à

remettre les valeurs correctes des variables après leurs essais.


Figure 16 - Capture d'écran, Serveur

Figure 17 - Extrait de la page Web générée par le serveur


III.1.4. Equipements Zigbee

Comme il a été dit, la GTB est équipée de compteurs pour la consommation électrique mais ceux-

ci sont limités en sensibilité au kWh. De ce fait, un suivi précis de la consommation électrique de

la salle est extrêmement difficile et c’est pourquoi des wattmètres précis au dixième de Watt

sont actuellement ajoutés à la plateforme (fig. 19). Ils permettent d’avoir une vision beaucoup

plus complète de la consommation électrique dans la plateforme PREDIS car les informations

disponibles sont très précises, puissance, énergie, courant, tension, et rendent possible une

analyse très fine de la consommation électrique des appareils. Ces wattmètres envoient leurs

données avec une technologie Zigbee, qui est un protocole de communication sans fil basé sur la

norme générique IEEE 802.15.4. Ce protocole se place sur le même marché que le Wifi ou le

Bluetooth mais offre l’avantage d’une très faible consommation, d’une fiabilité assez élevée et

d’un prix de revient dérisoire. En revanche, il ne bénéficie que d’une portée de l’ordre 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

l’avantage d’une très faible consommation électrique, ce qui peut se révéler déterminant pour

une sonde placée dans un lieu difficile d’accès, et cette problématique s’est d’ailleurs posée pour

l’ajout de nouveaux capteurs, problématique sur laquelle nous reviendrons plus tard. Quinze

wattmètres sont ainsi installés dans la salle informatique pour pouvoir suivre au plus près la

courbe de consommation des quinze ordinateurs dont la plateforme est équipée. Pour recevoir

les données envoyées en Zigbee, un récepteur est nécessaire : un XBee Pro (fig. 18). D’autres

fournisseurs et d’autres marques existent sur le marché avec des performances différentes en

fonction des tarifs. Un autre récepteur Zigbee a d’ailleurs été commandé pour le mois de

Septembre afin de dissocier l’aspect recherche et l’aspect pédagogique.

Figure 18 - Récepteur Zigbee Figure 19 - Wattmètre


Le Web Service conçu ici est en apparence le plus simple puisqu’il ne nécessite qu’un accès en

lecture. Le récepteur est connecté { l’ordinateur qui héberge le serveur grâce { un port USB qui

émule un port série. Dans le programme, il convient donc d’utiliser une bibliothèque spécifique

pour la gestion des ports série. Concernant la robustesse du service offert ainsi que ses

performances, un problème s’est rapidement posé : le récepteur offre la possibilité d’interroger

un équipement à la fois ou bien tous les appareils détectés d’un coup. A première vue, la seconde

solution est bien plus avantageuse en terme de temps de réponse et donc de performance du

service mais représente également une simplification majeure pour le programme. Néanmoins,

après la mise en place d’un protocole de test, cette solution s’est avérée peu fiable car la réponse

des wattmètres était aléatoire selon la distance au récepteur et de plus, il semblerait que le

récepteur ait des performances limitées en terme de gestion des conflits : les trames reçues

s’accumulent dans le buffer et dégradent la réception. Pour ces raisons, il a finalement été choisi

d’interroger les wattmètres un par un. Le temps nécessaire au service est certes un peu allongé

mais le niveau de robustesse est garanti. La lecture des données reçues est facilitée par une

interface graphique (fig. 20).

Figure 20 - Capture d'écran, serveur


III.1.5. Tests de robustesse

Au-del{ de la publication des données, l’objectif pour les Web Service était aussi d’être robustes

et fiables.

Le premier aspect à prendre en compte pour mesurer la robustesse du service était la résistance

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 requêtes

et même s’il y a plusieurs clients, cela ne pose pas de problèmes. En revanche, pour les

équipements en 433 MHz, le fait que les sondes envoient des trames en continu et non

uniquement sur demande nécessite un serveur en callback pour l’archivage des données et ce

dernier est bien plus délicat. De nombreux tests ont donc été mis en place pour vérifier que le

serveur se comporte bien en cas de clients multiples : ces tests ont été fructueux puisque de

nombreuses modifications ont été apportées au vu des résultats obtenus. En effet, les tests ont

permis de mettre en évidence certaines faiblesses de l’architecture, notamment concernant la

déconnexion des clients. Celle-ci peut s’effectuer de deux manières : si le client est arrêté, le

serveur continue d’essayer de lui envoyer les trames reçues et cette opération impossible lève

une exception ou bien le client est déconnecté manuellement par le serveur. Dans les deux cas, la

liste contenant les contacts doit être correctement gérée. 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é arrêté, un système de timeout a été créé : cela consiste à associer une date et une heure à la

création de chaque message { envoyer et fixer un délai pour l’envoyer. Si le client est

déconnecté, le serveur cherche { le recontacter jusqu’{ ce que le message soit dépassé. A ce

moment là, le client est supprimé de la liste des contacts.

Le deuxième aspect à étudier pour la fiabilité des Web Service était les données elles mêmes :

leur réception peut être faussée, les données modifiées ou erronées. Pour les équipements en

433 MHz, le RFXCOM peut parfois envoyer non pas une mais plusieurs trames accolées et il faut

les séparer, parfois les données sont erronées et il faut les supprimer. Concernant la GTB, il a

fallu faire un tri parmi les variables car certaines ne sont plus utilisées. Enfin, pour le Zigbee, les

trames étant entourées de balises hexadécimales, leur longueur est allongée lorsque ces mêmes

caractères se retrouvent dans la trame et il faut alors faire un premier décodage pour avoir la

trame hexadécimale complète.

Quelques tests unitaires ont enfin été réalisés sur les modules d’encodage et de décodage des

trames afin de vérifier qu’ils fonctionnaient selon les objectifs souhaités : décodage complet des

trames correctes, renvoi de messages spécifiques pour les trames erronées, détection des

différents types de trames existantes.


III.2. Gestion de projet et management

Tout au long du stage et afin d’avoir un suivi de l’ensemble des activités relatives { la plateforme

PREDIS, des réunions ont été organisées de manière à coordonner au mieux les tâches, éviter les

doublons et la perte de temps et pour mener une réflexion commune autour des problèmes

rencontrés. Ces séances ont ainsi réuni tous les stagiaires travaillant sur PREDIS tous les quinze

jours environ : chaque personne présente se devait d’y effectuer une courte présentation de son

travail et de son avancement ; un compte rendu d’activités devait également être rédigé à

chaque fin de semaine et { l’issue de chaque réunion. Du fait de la présence d’une stagiaire

indienne ne parlant pas français, les réunions et les rapports ont systématiquement utilisé la

langue anglaise (annexe 7).

Au cours de mon stage j’ai par ailleurs été amenée, durant les mois de juin et juillet, à guider un

stagiaire nouvellement arrivé sur la plateforme : sa tâche consistant à enrichir l’instrumentation

de PREDIS, je l’ai aidé en ce qui concerne les différentes technologies de protocoles de

communication utilisés, et l’ai initié aux avantages et inconvénients liés à leur mise en place dans

la plate forme PREDIS.


Conclusion

Au cours de ces trois mois de stage au sein du laboratoire G-SCOP, j’ai pu pour la première fois

appréhender les problématiques liées à la gestion intelligente des flux énergétiques dans

l’habitat.

Cette expérience, initialement guidée par mon gout a priori pour la domotique, a confirmé mes

futurs choix professionnels : la variété des tâches (informatique industrielle, programmation,

gestion de projet), l’apport de connaissances nouvelles (langage Python, notion de Web Service,

communication par sockets et HTTP) et la dimension environnementale de ce projet ont en effet

coïncidé avec mes attentes dans ce domaine de compétence particulier.

Ce stage m’a du reste permis de développer mes capacités d’adaptation, de découvrir de

nouvelles compétences et donc d’accroître mes aptitudes techniques et humaines par la

conception et l’élaboration de services qui seront concrètement utilisés au sein de la plateforme

PREDIS.

Le bilan de ce stage s’avère au final extrêmement positif puisque tous les objectifs fixés en début

de stage et par le cahier des charges ont été remplis.


Lexique

SCADA : Supervisory Control And Data Acquisition

Système de télégestion et d’acquisition de données permettant gérer à grande

échelle et { distance un grand nombre d’équipements

Domotique : Ensemble des techniques utilisées dans l’habitat visant { améliorer le confort, la

gestion de l’énergie, la sécurité et la communication

Immotique : Elargissement de la domotique { l’échelle d’un immeuble ou d’un site industriel.

Les solutions les plus couramment installées sont la GTB et la GTC

GTB : Gestion Technique du Bâtiment

Appellation désignant tous les équipements et services permettant le suivi ainsi

que le contrôle et la commande de la gestion énergétique d’un bâtiment ; sous ce

terme sont regroupés les réseaux de capteurs, les automates programmables qui

les commandent ainsi que les programmes de supervision.

GTC : Gestion Technique Centralisée

Identique à GTB

CTA : Centrale de Traitement de l’Air

Unité permettant le traitement et la ventilation de l’air qui circule au sein de la

plateforme : la régulation concerne aussi bien la qualité de l’air (quantité en CO2

régulée par ventilation) que la température.

VMC : Ventilation Mécanique Contrôlée, ici Double Flux

Dispositif destiné { assurer le renouvellement de l’air dans un bâtiment. Couplée

{ un échangeur thermique, une VMC double flux permet de chauffer l’air entrant

en hiver et de le rafraichir l’été grâce { l’air sortant du bâtiment.

CPL : Courant Porteur en Ligne

Technologie permettant le transfert d’informations via le réseau électrique grâce

{ des techniques de modulation de fréquence. C’est une alternative aux câbles et

au Wifi.

Web Service : Programme informatique permettant l’échange de données et la communication

par internet ou intranet (réseau informatique local)

Anémomètre : 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 numérique permettant de transférer des

données dans des champs de type arborescents.

API : Automate Programmable Industriel

Dispositif électronique programmable structuré autour d’une unité de calcul et

composé de modules tels que des entrées et sorties analogiques et numériques et

des modules de communication (bus de terrain ModBus et LonWorks)


Sondes Oregon Scientific,

RFXMeter et X10

RFXCOM

Serveur Web

WS

REST

Client Web

Bande radio

433 MHz

Socket

Requête HTTP

Format XML

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


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


Sondes

Serveur Web WS

REST

Client Web

Connexion analogique

ou numérique

Client OPC

Requête HTTP

Format XML

Automates programmables

Matrikon Data Manager

Annexe 3 : Diagramme UML des composants (Gestion Technique du Bâtiment)


Annexe 4 : Diagramme UML des classes (Gestion Technique du Bâtiment)


Wattmètres

Récepteur Zigbee

Emission

Zigbee

Serveur Web

WS

REST

Client Web

Protocole

Zigbee

Port Série émulé

sur USB

Requête HTTP

Format XML

Annexe 5 : Diagramme UML des composants (équipements Zigbee)


Annexe 6 : Diagramme UML des classes (équipements Zigbee)


Annexe 7 : Déroulement du stage (3 Mai 2010 – 30 Juillet 2010)

Documents

Rapport de Stage - forge.imag.fr©... · Salomé BENSLAMA 3 Mai-30 Juillet 2010 Page | 3 Remerciements A l’issue de ce stage, mes remerciements iront tout d’abord à Monsieur