Rapport 30 page ReactivHome- draft predefinitif 2012 09 12 - Clips

carriagespinInternet και Εφαρμογές Web

22 Οκτ 2013 (πριν από 3 χρόνια και 10 μήνες)

414 εμφανίσεις


Projet ANR
-
AA
-
PPPP
-
000

ReA
ctivHome

Services en Réseau pour l’efficacité
énergétique Active dans l’Habitat


Programme
Habisol

20
09

I
NTRODUCTION

................................
................................
...

4

A

PHASE

1


S
PECIFICATION ET
A
RCHITECTURE DU SYSTE
ME
R
EACTIV
H
OME
(O
RANGE
L
ABS
,

10

A
12

PAGES
)

........................

7

A.1

Tache 1 Specification du Système reactivhome et des services
associés

................................
................................
...............

7

A.1.1

Tâche 1.1 : Specification des différents cas d'utilisation

7

A.1.2

Tâche 1.2

: Spécification des configurations équipements+ bâtiments

11

A.2

Tâche 2

: Architecture et
développement logiciel du système
ReActivHome (Orange)

................................
.........................

13

B

P
HASE
2

:

C
ONCEPTION ET DEVELOP
PEMENT DES DIFFERENT
S
MODULES
(G
-
SCOP,

O
RANGE
L
ABS
,

CEA
-
INES,

M
UTICOM
,

12

A
14

PAGES
)

................................
................................
..

24

B.1

Rappel de l’objectif de la phase 2(CEA
-
INES)

..........................

24

B.2

Tâche 3

: Interface utilisateur (Multicom, 3 pages)

..................

24

B.2.1

Objectifs et méthodologie

:

24

B.2.2

Réalisation de l’interface pour tablette tactile

30

B.2.3

Intégration du démonstrateur dans Domus

32

B.2.4

Tests du démonstrateur dans la plateforme DOMUS

33

B.3

Tâche 4

: Modélisation, simulation et identification
automatique des équipements électriques et thermiques
(CEA
-
INES+ G2EL
ab)

................................
...........................

35

B.3.1

Reconnaissance de charge

35

B.3.2

Identification de modèle thermique (G2ELab, 2 pages)

39

Identification du modèle thermique (G2ELab, 2 pages)

39

B.4

Tâche 5

: Supervision et commande réacti
ve, anticipative et
adaptative

................................
................................
..........

41

B.4.1

Module de prédiction de production solaire (CEA
-
INES, 2 pages)

41

B.4.2

Composant logiciel aux interfaces standardisées prévoyant les
demandes de service des habitants (G
-
SCOP, 2 pages)

44

B.4.3

Composant logiciel aux interfaces standardisées pour le pilotage réactif
et anticipatif (G
-
SCOP, 4 pages)

45

C

P
HASE
3

:

T
ESTS DE PERFORMANCE
ET VALIDATION
(CEA
-
INES,

M
ULTICOM
,

G2EL
AB
,

S
CHNEIDER
,

O
RANGE
)
............................

45

C.1

Rappel de l’objectif de la phase 3

................................
...........

45

C.1.1

Validation de la couche Home
abstraction layer

: identification,
monitoring et reconfiguration multi
-
capteurs de plusieurs équipements
physiques et pièces

46

C.1.2

VALIDATION DE LA COUCHE HOME ABSTRACTION LAYER :
IDENTIFICATION, MONITORING ET RECONFIGURATION MULTI
-
CAPTEURS SUR LA BASE DU SIMULATEUR DE CONTEXTE SIAFU

49

C.1.3

EVALUATIONS DE PERFORMANCES DE LA COUCHE HOME
ABSTRACTION LAYER

50

C.2

Rapport de test su
r RT
-
Lab les recommandations (G2ELab, 3
page)

................................
................................
.................

51

Objectifs de la tache

51

Déroulement de la tâche

51

Résu
ltats obtenus et conclusion

54

Expérimentation sur plateforme


(CEA
-
INES, Orange, Multicom, 10
pages)
................................
................................
................

55

C.3

Expérimentation sur plateforme

................................
.............

55

C.3.1

processus de test et de selection des environnements de test (CEA
INES, 1 pages)

55

C.3.2

resultat de tests sur plateforme domus (multicom, 1 pages)

61

C.3.3

resultat de tests sur la plateforme armadillo box (cea
-
ines, 6 pages)

62

C.3.4

conclusi
on du test sur les demonstrateurs (cea
-
ines, 1 pages)

76

C
ONCLUSIONS
(CEA
-
INES,

1

PAGES
)

................................
.......

76

ANNEXE

I

:

................................
................................
....

76

ANNEXE

II

:

................................
................................
...

76

ANNEXE

III

:

P
UB
LICATIONS

................................
.................

76



Ce document e
st à remplir par le coordinateur
en collaboration avec les partenaires du projet
.
L’ensemble des
partenaires doit avoir une copie
de la version transmise à l’ANR.


Ce modèle doit être utilisé uniquement pour le compte
-
rendu de fin de projet.

I
NTRODUCTION


Les mondes de l’énergie et du bâtiment sont aujourd’hui en évolution rapide et profonde.

L’enjeu principal concerne la
consommation d’énergie des bâtiments, et plus
particulièrement du résidentiel
-
tertiaire
. En 2007, les
bâtiments résidentiels et tertiaires

ont
consommé 67,6 Mtep (consommation corrigée des effets du climat), soit
44 % de l’énergie
finale consommée en Franc
e
. Cette consommation est en hausse de 42% depuis 1970.

L’électricité et le gaz représentent respectivement 35 % et 34 % des consommations d’énergie
du secteur résidentiel
-
tertiaire en 2007. Leur utilisation a été multipliée par 7 au cours des
trois de
rnières décennies, principalement en remplacement du pétrole, qui représentait 19 %
en 2007 contre 53 % en 1970, et du charbon, qui n'est quasiment plus utilisé en 2007 (0,6 %
contre 17 % en 1970). En 2007, le résidentiel
-
tertiaire a consommé 87 % du bois
-
énergie utilisé
en France soit 7,9 Mtep.

En
Mtep

Figure
1

:
Consommation énergétique finale du secteur résidentiel


tertiaire, par type
d'énergie utilisée


Notes

:

consommation corrigée des effets du climat ; hors utilisation de

ressources à des fins
non énergétiques ; * CMS

: combustibles minéraux solides (charbon + coke de houille) ; **
EnRt

: énergies renouvelables autres qu’hydraulique, éolien et photovoltaïque.

Source

:

SOeS, 2008.

En 2007, 66 % de l'énergie consommée par le résidentiel
-
tertiaire est consacrée au chauffage
(46 Mtep), et 14 % à l'eau chaude sanitaire et la cuisson, et 20% à l'électricité spécifique
(éclairage, climatisation…). Les deux tiers de l’énergie consomm
ée concernent les bâtiments
résidentiels et 1/3 le secteur tertiair
e.



Nous devrons dans les années à venir fortement réduire la consommation de ce secteur
(facteur 4) pour réduire notre impact énergétique et réduire l’émission de gaz à effet de serre.




La pénétration croissante des énergies renouvelables et en particulier de l’énergie solaire.
Cette part de plus en plus importante va entrainer une difficulté grandissante de gestion
du réseau électrique du fait de l’aggravation des disparités journalières

de la puissance
consommée (voir
Figure
2
) et de la dissémination de la production.



Figure
2

: impact de la pénétration du photovoltaïque s
ur la puissance journalière
consommée sur le réseau électrique Français



Les véhicules électriques en cours de développement vont aggraver ces difficultés par la
nécessité de leur recharge et les transferts possibles d’énergie indépendamment du
réseau élect
rique.




Les smart grid (
Figure
3
) en cours de développement

ont été imaginés pour gérer ces
nouveaux réseaux où la production et la consommation sont répartis et où l’intermitence
devient importante.




Figure
3

: schéma de principe des «

smart grid

»



Comme nous allons le voir, le projet MULTSOL s’inscrit pleinement dans ce cadre en
proposant un système de gestion innovant de l’énergie dans les bâtiments

: sorte de «

micro
smart grid

» qui devra à terme communiquer avec le «

Smart Grid

» du réseau de tr
ansport.


Multisol s’est essentiellement concentré sur la partie «

électrique

» de l’énergie des bâtiments,
mais il est facilement extensible aux autres domaines de l’énergie voir également à la gestion
d’autres fluides (comme l’eau par exemple). L’object
if du projet a été de prouver la faisabilité
technique d’un tel dispositif de gestion et de chiffrer son efficacité sur quelques exemples.


Ce document est le rapport final du projet qui décrit le travail réalisé, les résultats obtenus et
qui ouvre sur les

perspectives offertes par ce type de dispositif.




A

PHASE


1


S
PECIFICATION
ET
A
RCHITECTURE
DU SYSTEME
R
EACTIV
H
OME

(
O
RANGE
L
ABS
,

10

A
12

PAGES
)

A.1

T
ACHE
1

S
PECIFICATION DU
S
YSTEME

REACTIVHOME ET DES S
ERVICES ASSOCIES

A.1.1

T
ACHE
1.1

:

S
PECIFICATION

DES DIFFERENTS CAS D
'
UTILISATION


A.1.1.1

Rappel des o
bjectifs de la tache


L'obje
c
t
if

de la tâche

a été de fournir, de manière la plus exhaustive possible, une description
des cas d'utilisation d'un
système

de gestion de l’énergie pour la maison

sans présumer du
périmètre de l'architecture technique, ni du contenu des démonstrations prévues pour la fin
du projet.

Les cas d'utilisation présentés reposent cependant sur un petit nombre d'hypothèses ou de
préal
ables structurants et qui concernent la caractérisation des utilisateurs. Ceux
-
ci se
répartissent en deux grandes catégories :
les utilisateurs

finaux, occupants de l'habitat où est
installé le système ReActivHome et les utilisateurs professionnel proposan
t des services à
l'utilisateur final.

Les caractéristiques élémentaires des utilisateurs finaux sont les suivantes:

-

Ils

vivent aussi bien en habitat individuel que collectif (appartement), rural ou urbain

-

Une

ou plusieurs personnes vivent dans le logem
ent géré par le même système, ce peuvent

éventuellement être des personnes assistées (personnes âgées ou handicapées)

-

I
ls peuvent être à la fois un utilisateur délégant la plus grande partie du fonctionnement au
système, ou un utilisateur pragmatique rep
renant la main en fonction de ses besoins ou un
utilisateur expert entrant dans le système pour concevoir ses propres modes d’optimisation
de la consommation énergétique en paramétrant très finement le système.

Cette caractérisation première, voire très él
émentaire mais suffisante pour cette étape de
conception, a été approfondie afin de mieux identifier les attentes et les besoins (services,
interfaces). Ce travail a été réalisé sur la base d'études documentaires sur les comportements
citoyens, entendus d
u point de vue du développement durable, dont se déduiront les
catégories de consommateurs (niveau de vie, taille du groupe, âge, habitudes, mode de vie,
mode de consommation/production, mode d'usage).

Pour les utilisateurs ou intermédiaires professionnels
, en plus des acteurs déjà connus
(opérateurs d’électricité, de gaz, sociétés de services d’énergie,
etc.
) de nouveaux métiers ou
fonctions pourront émerger avec l'usage d'un système tel que ReActivHome. Par exemple :
régisseur, gestionnaire, concierge de
l'énergie ou encore installateur, mainteneur/réparateur
et même client des données de l'utilisateur final pour son propre usage.

A.1.1.2

Déroulement de la tâche

Le livrable
1.1

: Spécification des cas d’usage
,
a pris

un point de vue très général pour
définir
l’ensemble des utilisations possibles d’un système de gestion d’énergie, vues par rapport à
une méthodologie standard de spécification de use cases UML

: les use cases sont vus
comme des interaction
s

élémentaires entre acteurs externes au système (
autres systèmes ou
utilisateurs) et le système
R
e
A
ctiv
H
ome
lui
-
même
, en fournissant ainsi une spécification
comportementale externe

A partir d
’un diagramme synoptique

des cas d'utilisation

(

4
)

on a décrit les principaux cas d'utilisation suivants et ceu
x qui en dérivent

:

Superviser l'usage de l'énergie et son optimisation

1.

Optimiser l'usage de l'énergie

2.

Personnaliser le système

3.

Configurer le système

4.

Maintenir le système


F
igure
4

:
Diagramme synoptique
complet
des cas d’utilisation


Figure
5

Diagramme
simmplifié
des cas d’utilisation

principaux

A.1.2

T
ACHE
1.2

:

S
PECIFICATION DES CO
NFIGURATIONS EQUIPEM
ENTS
+

BATIMENTS

A.1.2.1

Objectifs de la
tache

Le but
de cette tâche a été

est de fournir une spécification
en extension

du périmètre maximal
d’un tel système. Il s’agit bien d’un périmètre maximal dans la mesure où
le projet

vise à la
généralité et à préparer l’évolution future des systèmes,
au
-
delà de ce qui pourra
effectivement être implémenté avec les moyens limités du projet.

Les spécifications ultérieures des modèles mis en œuvre dans la partie logicielle du système
d’une part, et des configurations matérielles effectivement mises en œuv
re dans les différents
démonstrateurs d’autre part, adresseront respectivement des sous
-
ensembles du périmètre
délimité ici.

La

Figure
6

donne
une vue d’ensemble des
différentes catégories d’équipements intégrés
dans le périmètre du système ReActivHome


C
e système fonctionner
a

sur la base du
réseau local domestique
* qui
connectera,
directement
ou indirectement
,

l'ensemble de ces équipements.
Cette intégration peut se f
aire suivant deux
modes complémentaires

:
les équipements anciens existants seront
«

reconnus

»,
observés et
commandés par l'intermédiaire d'un dispositif électrique spécifique inséré sur leur
alimentation, la
prise gigogne
* ReActivHome qui sera développée

dans le cadre du projet.

Pour ce qui est les équipements "état de l'art", du point de vue informatique, qui disposent
d'une connectivité par un standard connu de réseau de données, comme Wifi ou Ethernet, ou
par le
réseau capillaire
*, ils
peuvent être int
égrés directement dans le réseau,
par des processus
de découverte de type «

zeroconf

»

qu’ils soient gérés seulement dans les couches réseau
classiques ou
à haut niveau dans
le cadre d’
une
architecture orientée
-
services

(SOA*), la prise
gigogne ReActivHome pourra être quand même utilisée à titre transitoire. En effet,
aujourd'hui, ces interfaces informatiques ne permettent pas l'observation de la
consommation électrique, et encore moins la commande
on
-
off
1
. L'interface i
nformatique
fournira quand même dans ce cas un point d'entrée complémentaire vers ces équipements, et
il est important de la prendre en compte dans le système parce qu'elle correspond à
l'évolution future des environnements domestiques, même si c'est seule
ment aujourd'hui
une petite minorité d'équipements qui peuvent être interfacés ainsi.

Dans les deux cas, l'intégration de ces équipements dans le système ReActivHome devra se
faire de manière spontanée et dynamique,
en ne nécessitant pas, dans l’idéal, d’
autre étape
de
configuration manuelle

que l’insertion de la prise sur l’alimentation de l’équipement.

Il est important de noter que le système ReActivHome devra s’adapter à tous les types de
bâtiments et à leur niveau d’équipement et d’instrumentation. Pou
r être économiquement
viable et permettre un déploiement à large échelle, il faut que ce système puisse également
apporter des gains dans l’habitat
moyen, dotés d’
équipements
existants potentiellement
anciens avec un investissement réduit en matériel et en

main d’œuvre pour la configuration.




1

Certains
protocoles permettent

toutefois d’opérer à distance

la mise en veille ou
le

réveil
à partir de la
veille (Wakeon LAN,
UPnP low
-
power
)


Figure
6

: Catégories d'équipements intégrés dans le système ReActivHome

A.1.2.2

Déroulement de la tâche

Ce
tte

tâche a cherché à
permis de s’intéresser à l’e
nsemble des équipements

correspondant
au

périmètre maximal du système
ReActivHome
. Il s’agit bien d’un périmètre maximal dans
la mesure où le présent document vise à la généralité et à préparer l’évolution future des
systèmes, au
-
delà de ce qui pourra effectivement être implémenté avec les moyens limités du
projet.

Cette spécification

est associée à une catégorisation des équipements inclus dans le périmètre
du système suivant des critères pertinents par rapport à la gestion de l’énergie. Cette
classification sert de base à la sélection des équipements retenus aux différents niveaux
su
ivants

: pour être modélisés, être simulés, être inclus dans des démonstrations. Les
modèles utilisés pour ces équipements utiliseront également les différentes dimensions de
cette catégorisation comme caractéristiques d’une ontologie formelle sous
-
jacent
e

à ces
modèles.

On a fourni un
e

classification des équipements du périmètre ReActivHome suivant les
critères suivants



Consommation moyenne



Puissance maximale



Commandabilité potentielle par le système



Identifiabilité/registrabilité



Observabilité



Type
d’alimentation en énergie



Proportion de ménages possédant l’équipement en question



Mode opératoire



Conservation de l’état : interruptibilité
-
décalabilité



Interface réseau de données



Nombre de modèles différents



Localisation



Prédictibilité



Gain d’efficacité

potentiel/durée d’utilisation



Partage



Nombre d’unités par logement



Mutualisation possible avec d’autres services



Type de fonctionnement énergétique



Type d’énergie utilisé



Famille d’équipements



Genre d’équipements



Espèce d’équipements



Priorité


Ces critère
s ont été repris dans l’ontologie qui sert de base aux modèles utilisés dans la
couche

«

Home Abstraction layer

»

A.2

T
ACHE
2

:

A
RCHITECTURE ET DEVEL
OPPEMENT LOGICIEL DU

SYSTEME
R
E
A
CTIV
H
OME

(O
RANGE
)

A.2.1.1

Objectifs de la tache

Comme pour les cas d’utilisation, l’ar
chitecture
a été

abordée avec un point de vue général,
qui n’en limite pas la spécification à ce qui est implémenté dans la phase de développement.

L’architecture définie l’a donc été sur la base du périmètre du système ReActivHome
spécifié dans la tâche
1.2. Il s’agit d’un périmètre maximal, destiné à prévoir l’évolution à
court
-
terme possible du système. Il comprend donc tous les composants qui seront
implémentés dans l’ensemble des démonstrations prévues pour la fin du projet, mais peut
aller au
-
delà po
ur la généralité


Dans ce point de vue, les équipements gérés par le système et les pièces de la maison sont
représentés de manière similaire par un proxy logiciel qui interface l’ensemble des capteurs
et des actionneurs permettant de les monitorer. Ce
proxy a été spécifié dans un modèle
générique, ainsi que la configuration complète de traitement permettant d’acquérir,
fusionner et agréger les données issues des capteurs pour en extraire les informations
pertinentes

A.2.1.2


Déroulement (sous tâches 2.1 & 2.2)

Les 2 premières sous
-
tâches de cette tâche étaient
à l’origine
divisées en «

Sous
-
Tache 2.1
Architecture détaillée de l’infrastructure TIC du système ReActivHome au niveau du réseau
local domestique

», et «

Sous
-
Tâche 2.2 Architecture du système ReActivHo
me au niveau du
réseau distant

»
. Cette séparation est apparue non adaptée à la réalité de l’importance du
travail d’architecture, la séparation entre les parties du système déployées sur le réseau local
et celles qui le seront sur le réseau distant (plate
forme de services) n’étant pas un critère
discriminant par rapport

Les livrables ont été repérimétrés et rebaptisés par rapport à un
découpage plus réaliste de l’architecture

:

Livrable 2.1

: «

Spécification de l’architecture fonctionnelle et de l’infrast
ructure du système
ReActivHome

»

Livrable 2.2 «

Spécification détaillée de l’architecture et de l’implémentation du cœur fonctionnel
du système ReActivHome

L
e travail a permis de converger sur un modèle de l’architecture en 4 couches qui rend plus
claire l
’articulation entre la gestion des entités physiques modélisées dans l’architectures au
travers des capteurs et des actionneurs et la gestion des «

services

» qui sont vus par
l’utilisateur et qui sont directement la cible d’optimisation par le moteur d’op
timisation
(couches réactives et anticipatives)

La v
ue fonctionnelle

décrit

les fonctions implémentant les cas d’usage spécifiés dans l a tâche
1.1,

leurs répartitions entre différents
composants fonctionnels

et les interfaces entre ces
composants
.

Cette vue ne prend pas en compte la répartition de ces composants entre les
différentes entités matérielles et réseaux, qui fait l’objet de la vue «

infrastructure

».

La
Figure
7

donne une vue plus synthétique de l’architecture, avec une décomposition en 4
couches transversales à l’ensemble de l’architecture.

La couche 3 «

services

» correspond aux entités fonctionnelles abstraites gérées par le cœur
du système d’opti
misation. Il s’agit ici des services vus par les utilisateurs comme le
chauffage ou l’éclairage, et non pas des services informatiques de bas niveau tels que gérés
par une architecture orienté service comme UPnP ou des web services, même si ces services
pe
uvent être gérés explicitement par une telle SOA. C’est au niveau de ces services que le
système va agir en fonction des degrés de liberté et contraintes qui leur sont spécifiques, tout
en prenant en compte l’état des entités et le contexte remonté par les

capteurs.

La couche 2 «

modèles d’entités physiques

» comprend les proxies (représentants) de ces
entités (pièces et équipements) qui leur servent d’interface informatique vis
-
à
-
vis du reste du
système et la couche locale qui en gère le contrôle en foncti
on de données et critères
purement locaux à ces entités.

La couche 1 «

interfaces d’entités physiques

» comprend les capteurs et actionneurs qui
interfacent physiquement ces entités ainsi que les couches de traitement qui servent à
transformer les données
correspondantes. Pour ce qui concerne les équipements dotés d’une
interface informatique, cette interface fait partie de cet ensemble mais des capteurs pourront
néanmoins être utilisés le cas échéant pour compléter l’information fournie par cette
interface
.

La couche 0 «

entités physiques

» correspond à ces entités elles
-
mêmes (pièces et
équipements) en tant qu’entités ayant un impact énergétique. Au sens strict ces entités ne
sont pas dans le périmètre du système ReActivHome en tant que système informatiqu
e, mais
ce sont celles qui composent la maison en tant que système thermodynamique dont le
système ReActivHome est le reflet informationnel, au travers des interfaces de la couche 1.

La configuration (comprenant configuration spontanée initiale et reconfig
uration dynamique
automatique) opère au travers des 3 premières couches. Elle reflète la configuration physique
de la couche 0.

La figure 3 apporte une vue complémentaire de celle
-
ci, incluant les interfaces vers les
utilisateurs et l’environnement extern
e (capteurs physiques correspondant à des sources de
données comme la météo ou l’état du réseau électrique externe, mais aussi capteurs
physiques pouvant être situés à l’extérieur de la maison)



:

Figure
7

:
Architecture
fonctionnelle globale, vue synthétique


L’architecture du cœur fonctionnel du système a fait l’objet du livrable L2.2

La couche gérant l’identification, la
supervision

et le contrôle
(EIMC)
des entités (pièce
s
,
équipement
s
) du système s’intercale entre la couche
services et la couche des entités
physiques.

La couche
EIMC collecte

les données issues des entités physiques

et les restitue aux

applications
.

Elle répercute les données de commande vers les entités physiques.

Ch
aque entité de la couche physique est représentée
par un modèle abstrait dans la couche
EIMC. Le composant EIMC correspondant comprend des modules d’analyse des données
issues des capteurs

de persistance d’état et de contrôle.
La

représentation
d’état main
tenue
dans la couche de persistance
donne une image à jour de l’état de l’entité, et permet d’agir
sur cette entité via les actionneurs qui lui sont associés.

La couche
EIMC

contient autant
d’instances«

analyse / persista
nce d’état / contrôle

»


ensem
ble
EIMC

») qu’il y a d’entités dans le système

:



Figure
8

:
Architecture avec plusieurs entités

Les modules d’analyse, de persistance d’état et de contrôle formant
avec les capteurs et les
actionneurs
un

système de contrôle
e
n

boucle fermée

par rapport à l’entité physique
correspondante,

ils peuvent
fonctionner de manière autonome

indépendamment de la
couche applicative pour réguler l’état de l’entité par rapport à d
es contraintes purement
locales.

La couche EIMC contient trois modules

:



Analyse

:

o

Communication avec les capteurs associés pour collecter les données
correspondant aux évènements significatifs.

o

Fusion et agrégation des données collectées.

o

Identification d
es types et des états des entités physiques.



Contrôle

:

o

Vérification de la faisabilité d’une commande provenant du module de
persistance d’état.

o

Traduction d’une commande en données compréhensibles par un actionneur.

o

Choix d’un ou plusieurs actionneurs pou
r réaliser une commande.

o

Communication avec les actionneurs

: envoi des commandes



Persistance d’état

:

o

Représentation de l’état courant des entités physiques, basée sur le traitement
des informations par le module d’analyse.

o

Interface de communication
entre la couche applicative et la couche EIMC.



Figure
9

:
Architecture de la couche EIMC


Après la
spécification détaillée

de l’
architecture au cours de la période précédente, le travail
sur cette tâch
e a concerné les sous
-
tâches 2.3 «

Développement logiciel des briques du réseau
au niveau du réseau domestique

» et 2.4 «

Développement logiciel des briques de base au
niveau des services

». La séparation nette qui avait été faite, au moment de la rédact
ion de
la proposition, entre la partie du système ReActivHome hébergée au sein du réseau local
domestique et celle qui serait hébergée sur une plateforme de services distante hébergée a
n’apparaît plus tout à fait aussi déterminante, c’est pourquoi il a
été jugé préférable de
fusionner les 2 livrables correspondants (L2.3 et L2.4) en un seul.qui décrit l’implémentation
complète du cœur du système sous forme de descriptions de classes (Javadoc). Ce cœur du
système ReActivHome correspond à la couche appelée

«

Home Abstraction Layer

» (HAL)
qui sert d’interface entre les capteurs et le moteur d’optimisation, en présentant à celui
-
ci une
abstraction des capteurs au travers de modules appelés «

entity

identifica
tion monitoring
and control

» (E
IMC)

A.2.1.3


Déroulement
(Tâches 2.3 & 2.4) Développement des briques de base
logicielles

Cette partie du travail

a concerné la fin des sous
-
tâches 2.3 «

Développement logiciel des
briques du réseau au niveau du réseau domestique

» et 2.4 «

Développement logiciel des
briques de

base au niveau des services

». L
à encore, l
a séparation nette qui avait été faite, au
moment de la rédaction de la proposition, entre la partie du système ReActivHome
hébergée au sein du réseau local domestique et celle qui serait hébergée sur une plateforme
de services distante hébergée a n’appa
raît plus tout à fait aussi déterminante, c’est pourquoi
il
a

été jugé préférable de fusionner les 2 livrables correspondants (L2.3 et L2.4) en un seul

qui décrit l’implémentation complète du cœur du système sous forme de descriptions de
classes (Javadoc).

Ce cœur du système ReActivHome correspond à la couche appelée
«

Home Abstraction Layer

» (HAL) qui sert d’interface entre les capteurs et le moteur
d’optimisation, en présentant à celui
-
ci une abstraction des capteurs au travers de modules
appelés «

subsy
stem identification monitoring and control

» (SIMC)


Le schéma ci
-
dessous conne une vue du mapping des composants présentés dans le présent
document sur les différentes
plateformes

de l’infrastructure, correspondant respectivement
à ce qui est hébergé au
sein du réseau local de la maison (typiquement sur une passerelle ou
«

box

» générique ou dédiée, ou sur un serveur embaqué, et ce qui est hébergé «

dans le
cloud

», en pratique sur des plateformes de service accédées à distance sur le réseau.


Figure
10

: Implémentation du système ReActivHome

Le système ReActivHome est hébergé de manière répartie dans deux environnements
différents

:

1.

Au sein du réseau local domestique («

home environment

» Figure 1)


2.

Sur

une plate
-
forme de services de service
a (
dans le «

cloud

»
) accédée

à distance au
travers du réseau

Dans l’environnement du réseau local, deux hébergements du logiciel on été mis en
œuvre

:

1.

Une «

Energy Box

», serveur embarqué dédié, pour héberger la
couche HAL SIMC
(
Cf. L2.2 PARTIE III

: COUCHE D’IDENTIFICATION, SUPERVISON ET CONTROLE
DES ENTITES.)


2.

Un serveur Web léger (Webserver dans Figure 1) pour héberger le module
adaptation/alignement des données de capteur et actionneur, afin que le système
ph
ysique puisse publier leur données d’acquisition et la couche d’HAL pourrait les
récupérer via l’interface http

;

Les capteurs et actionneurs utilisés par le système pour s’interfacer avec le système physique
de la maison sont par ailleurs des équipements

dédiés physiquement distincts (
Cf. livrable
de la description Domus et Armadillo

B
ox
).


Dans l’environnement à distance, les trois parties suivantes sont hébergées

:

1.

HAL Front
-
end

: il est aussi un serveur web léger qui suit l’architecture REST pour
l’exchange des données du système ReActivHome entre les modules HAL SIMC,
GHome Tech et IHM. Il a été réalisée par
G
-
scop
;

2.

IHM

: L’interface utilisateur (
Cf. L2.2 PARTIE VI
II

: IMPLEMENTATION DES
INTERFACES UTILISATEURS
)

qui a été réalisée par
LIG

MultiCom
;

3.

GHome Tech

: La couche réactive et anticipative du système (
Cf. L2.2 PARTIE IV

:
COUCHE REACTIVE
) qui a été réalisée par
G
-
scop

;



Figure
11

:
architecture d’implémentation et de communication

du home abstraction layer





Implémentation OSGi sur la «

home energy box

»

Chaque module EIMC est implémenté par un bundle OSGI . L’architecture du système de
gestion des
EIMC est représentée
Error! Reference source not found.
.
3 bundles sont
démarrés à l’initialisation :



Sensor Module bundle



Actuator Module bundle



Global Context Monitor bundle

Ce dernier attend l’activation des Sensor Module et Actuator Module,

pour lancer la création
d’un EIMC.


Figure
12

:
implémentation OSGi d’un EIMC

EIMC est constitué des services suivants

:


1) Life
-
cycle manager

2) Classification/identification : identifie l’état
courant à partir des données des capteurs

3) RSM

:maintient l’etat courant dans un modèle exécutable de la machine d’état).

4) OntologyManager : peut charger une ontologie externe pour récupérer des modèles
pertinents de l’environnement CIM
Error! Reference source not found.
.

Prototypage

Dans le prototype implémenté, un “plug computer” Sheevaplug
2

héberge la couche HAL.
La sheevaplug fonctionne a
vec microprocesseur ARM 1.2 GHz, 512 Mo de mémoire, OS
linux Debian, SUN JDK 1.6 avec
implémentation

Apache Felix d’ OSGi (
Error! Reference
source not found.
)

Pour les capteurs nous utiliso
ns des capteurs Zigbee Cleode
3

et une couche d’interface des
capteurs HDM de la société prosyst
4
.




2

www.ionics
-
ems.com

3

http://www.cleode.fr

4

http://www.prosyst.fr/



Figure
13

:
Prototype architecture on plug computer

B


P
HASE
2

:

C
ONCEPTION ET DEVELOP
PEMENT DES
DIFFERENTS

MODULES

(
G
-
SCOP,

O
RANGE
L
ABS
,

CEA
-
INES,

M
UTICOM
,

12

A
14

PAGES
)


B.1

R
APPEL DE L

OBJECTIF DE
LA PHASE
2
(CEA
-
INES)


L’objectif de cette
deuxième phase était la conception du logiciel de supervision de
ReactivHome. Le travail avait initialement été dé
coupé en 3 tâches séparées :



Tâche 3

:
Interfaces utilisateur, ergonomie et acceptabilité



Tâche 4

:
Modélisation, simulation et identification automatique des
équipements électriques et thermiques



Tâche 5

:
Supervision et commande réactive, anticipative et

adaptative

B.2

T
ACHE
3

:

I
NTERFACE UTILISATEUR

(
M
ULTICOM
,

3

PAGES
)

B.2.1

O
BJECTIFS ET METHODOL
OGIE

:

Les objectifs de la tâche 3 sont de concevoir les IHM (Interfaces homme
-
machine) les plus
appropriées pour le système ReactivHome, de réaliser un démonstrateur dans

l’environnement DOMUS, et de valider les fon. La longue pratique de l’équipe MultiCom en
IHM a orienté la conception vers une méthode bien connue

: la conception participative,
mêlant les concepteurs, les ingénieurs aux usagers eux
-
mêmes. Cette méthode pe
rmet aux
usagers de concevoir pour eux
-
mêmes et d’être ainsi placés au centre de la conception.

Nous avons mis cette méthode en pratique dans le projet en procédant par étapes

:

a)

Etat de l’art des dispositifs disponibles et des propriétés du système Reactiv
Home
vues du côté des ingénieurs

b)

Recensement des IHM disponibles en termes d’acquis cognitifs pour les usagers

c)

Conception participative des IHM au cours de séances collectives progressives

d)

Définition des spécifications fonctionnelles par réalisation de maq
uettes et validation
auprès des ingénieurs, des concepteurs et des utilisateurs

e)

Développement du démonstrateur

Réalisation des IHM pour la tablette tactile

Intégration du démonstrateur dans le système

f)

Tests du démonstrateur sur la plateforme Domus

B.2.1.1

Disposi
tifs et propriétés

:

L’état de l’art indique que les interfaces les plus appropriées dépendent

:

-

des types d’utilisateurs (parents, enfants, personnes âgées, etc.)

-

des situations d’usage (debout, couché, assis, en faisant autre chose, etc.)

-

des fonctions
d
emandées (on
-
off, réglages, pi
lotage, configuration, etc.)

Il y a donc lieu de prévoir plusieurs dispositifs pour couvrir tous les besoins

à condition de
garder une cohérence entre eux
.

La recommandation principale étant d’adapter le type
d’interface aux a
ctivités des personnes (par exemple quand je suis au bureau c’est de mon PC
que j’interviens, quand je cuisine c’est d’une tablette graphique collée sur le frigo ou une
télécommande, quand je quitte la maison je voudrais un écran fixe près de la porte d’en
trée,
etc.). Les utilisateurs souhaitent aussi opérer à distance, par exemple à travers un agenda, de
leur téléphone mobile.

La figure ci
-
dessous donne la hiérarchie de quelques tâches possibles pour un service donné
(les services peuvent en outre se crois
er ou se combiner)


Figure
14

: Hiérarchie des tâches possibles pour un service donné

B.2.1.2

Recensement des dispositifs et options retenues

Nous avons recensé et étudié les propriétés des dispositifs suivants

:



t
élécommande (avec
TV ou
non
)



téléphone mobile



tablette tactile



écran tactile fixe



écran tactile amovible



interface tangible

: objets communicants



interface vocale (reconnaissance ou messages en sortie)



authentification biométrique



compteur intelligent


Les f
onctions attendues

de
ReactivHome étant

:

-

authentification utilisateur pour accès à certaines fonctions, programmes ou services
sécurité enfants par exemple)

-

commande on
-
off (programmes, appareils), envoi d’alarmes à l’extérieur

(en cas de
danger, par des enfants par exemple)

-

c
ommande et réglage (programmes, appareils, temporisation, paramètres)

:
programmes en direct, programmes différés, planification plus précise scheduling)

-

pilotage interactif (choix de programmes ou d’effets désirés par simulation de
solutions)

par dialogues ou macro
-
commandes, le retour vers l’utilisateur dans ce cas
est important

-

notifications de comportement des appareils ou de la consommation (niveaux,
alarmes, conseils, retours de programmes), la forme de ces notifications doit être
choisie

par l’utilisateur

: visuelle et/ou sonore (selon l’heure de la journée, la nuit c’est
plutôt sonore)

-

personnalisation / interaction avec l’extérieur (fournisseurs de services)

-

configuration / téléchargement de logiciels et de services


Nous avons retenu l
es grandes options suivantes pour initialiser les séances de conception
participative

:




Profils d’utilisateurs (parents, enfants, personnes âgées, etc.)




Situations d’usage (debout, couché, assis, en faisant autre chose, etc.)




Fonctions demandées (suivi, commandes, réglages, pilotage, personnalisation,
configuration)

Une seule tâche

: debout, assis, couché


charge cognitive normale et canaux perceptif et
moteur disponibles


Exemples

: travailler assis dans son bureau avec un P
C, regarder la TV vautré sur le
canapé, cuisiner debout

Deux tâches alternées ou parallèles (avec entrelacement)


charge cognitive importante mais
canaux perceptif et moteur relativement disponibles


Exemples

: cuisiner et regarder la TV de temps en temps



Exemples

: téléphoner en cuisinant

=> Ces différents cas impliquent que l’attention est plus ou moins mobilisée ainsi que les
canaux perceptifs et moteurs. Par ailleurs la posture rend plus ou moins aisée l’utilisation
d’un dispositif. Nous ne prendrons

pas en compte d’autres éléments comme le poids,
l’encombrement, etc.


B.2.1.3

Conception participative

Des séances de conception participative ont été faites dans lesquelles les dispositifs et les
interfaces ont été spécifiées par étape, en considérant, les types

d’affichage, les données à
afficher, les niveaux d’interaction, la situation physique du dispositif et la représentation du
bâtiment sur l’interface, comme

:

-

Plans de la maison (intérieur, extérieur, façades)

-

Types d’appareils (groupés ou individualisés)

-

Chronogrammes (utilisation programmée dans le temps)

-

Agendas et/ou types d’activités


Types d’affichages

:

-

Lumineux (leds sur les appareils ou télécommande)

-

Graphique (courbes, histogrammes)

-

Texte (boîtes de dialogue)

-

Photos (séquences de photos, films)

-

Im
ages (de synthèse)

-

Sonore (messages, sons d’alertes)

-

Tangible (Nabaztag)


Données

:

-

Consommation/production électrique dans le temps selon les sources utilisées

-

Coût individuel et cumulé de la consommation des appareils

-

Etats des capteurs (on
-
off,
curseurs, couleurs)

Sujets

:

-

9 personnes
ont participé aux séances

:

-

3 ingénieurs du projet (Schneider, CEA/INES et G
-
Scop)

-

6 utilisateurs potentiels du système (choisis pour être représentatifs d’habitations
individuelles ou d’appartements, famille
ou s
eul, âge/sensibilité au développement

durable ou économie d’énergie)

-

Ces 9 utilisateurs
ont été
répartis en 3 groupes de 3

: 1 ingénieur et 2 utilisateurs par
groupe


Méthode et progression en deux étapes

:

Exercices de mise en situation

Les deux exercices

consistent en deux tours de table. Deux questions leur sont adressées

:

Racontez une anecdote sur la gestion de l’énergie chez vous

Comment dans le futur, imaginez
-
vous gérer votre énergie et avec quels types d’interface

?

Les participants répondent chacu
n leur tour

Exercices de conception

La réalisation de l’exercice de conception se fait par groupe de 3 personnes.

Chaque groupe disposera d’une série de cas d’utilisation à compléter. Chaque cas est
présenté sur une feuille sur laquelle les différentes é
tapes sont indiquées. Pour chaque étape,
le groupe doit trouver un consensus et déterminer le type de données à afficher et le mode
de présentation de ces données. Pour les aider, chaque groupe dispose d’une fiche
présentant l’ensemble des données possible
s et les différents modes de présentation et types
d’affichages.

A la fin de l’exercice, chaque groupe présente aux autres les choix de données et de mode de
présentation qu’ils ont fait pour chacun des cas d’utilisation.


Résultats

:

Le tableau suivant mo
ntre une synthèse des choix des concepteurs pour les IHM de
ReactivHome

Dispositif

Quoi

Comment

Tablette

Pour tout faire

In situ

PC

-

id
-

In situ, à
distance

Ecran mural

-

Id
-

In situ, debout

Mobile

Tout sauf configurer

À distance

Ambiance

Visualiser (suivi)

In situ

Tangible

Optimiser

In situ

Les dispositifs retenus sont

:

-

Ecran graphique tactile

-

Dispositif mobile tel que
Smartphones

-

Objets physiques communicants

B.2.1.4

Spécifications et maquettes

Les spécifications des IHM se sont faites sous
forme de maquettes fonctionnelles de manière
à les rendre plus concrètes pour les ingénieurs et les utilisateurs. Elles ont été validées pas à
pas, fonction après fonction dans des séances participatives. Nous sommes arrivés à des IHM
telles que celles
-
ci

:



Les maquettes ont été confrontées aux critiques des ingénieurs et des utilisateurs pour
chaque fonction et certaines ont été reconçues. Une fois validées, ces maquettes ont servi de
spécification pour le développement.


B.2.1.5

Développement du démonstrateur


Cette tâche consiste à réaliser, sous forme d’une application Android destinée à une tablette
tactile, les interfaces précédemment validée permettant à l’utilisateur d’interagir avec le
système ReactivHome.

Une partie plus importante que prévue de cette t
âche, concerne également l’intégration du
démonstrateur sur la plate
-
forme d’expérimentations de Multicom

: Domus.

Il faut en effet intégrer les informations fournies par la prise gigogne Schneider, mettre ces
informations, ainsi que celles des capteurs d
éjà présents dans l’appartement, à disposition
sur un serveur, afin que la couche capteurs puissent accéder à ces informations. Il faut
également fournir un service permettant à cette couche d’envoyer des ordres aux actionneurs
de l’appartement.

Pour cela
il faut en outre fournir un fichier configuration de Domus, afin que le système
ReactivHome ait une connaissance, ainsi que des moyens de contrôle complets des capteurs
et actionneurs présents sur la plate
-
forme.



B.2.2

R
EALISATION DE L

INTERFACE POUR TABLE
TTE

TACTILE


Le choix retenu pour coder l’interface est celui d’une interface Android. Cette application est
basée sur les interfaces validées lors de la tache précédente.

Certaines modifications ont toutefois été effectuées afin de suivre l’évolution du proj
et.

Par exemple, trois nouveaux écrans ont été ajoutés à l’application

:

Le premier permet de visualiser de manière plus efficace l’autoconsommation sur les
sites de démonstrations, notamment dans l’Armadillo Box de l’INES.

Le second permet à l’utilisateu
r d’être conseillé par le système pour la
programmation de certains appareils (heure de démarrage d’une machine à pain, par
exemple), en fonction des plans anticipatifs.

L’utilisateur peut y modifier certains paramètres sur les activités prévues et ensuite

recevoir
les résultats d’un nouveau plan anticipatif, afin de choisir en toute connaissance de cause
l’heure de démarrage de son appareil.


Le dernier écran est particulier, car il n’est pas prévu pour être vu par l’utilisateur
final, mais permet, dans un

but de démonstration, d’afficher la liste des pièces, appareils et
services reconnus par le système, et d’afficher les plans anticipatifs de température des
pièces.


L’application Android est conçue pour être dynamique et indépendante de la plate
-
forme de

démonstration, ce qui veut dire qu’elle s’adapte aussi bien à la plateforme Domus qu’à
l’Armadillo Box. L’interface s’adapte donc au nombre de pièces et de services de l’habitat à
surveiller et affiche les informations correspondantes, sans avoir à chang
er le code pour
chaque lieu différent.

Cela implique que la totalité des informations à afficher sur la tablette doivent être
présentées sur un serveur d’interface, et formatées de manière précise, afin de fournir à
l’application les données dont elle a be
soin pour fonctionner. De cette manière, lorsque
plusieurs terminaux Android sont utilisés en même temps, les mêmes informations sont
affichées sur chacun d’eux.



Afin de simplifier la réalisation des démonstrateurs (et de limiter les échanges réseaux),
le
serveur d’interface

est

hébergé sur
un

serveur REST (HAL représentation) géré par G
-
SCOP.
Les données, dont certaines sont des agrégats d’autres données, sont intégrées dans une
partie spécifique aux interfaces. La définition de ces données et leur orga
nisation sur le
serveur ont
été définies lors de nombreuses réunions avec G
-
SCOP, ce qui a permis de les
exposer sur le serveur, et ainsi de les afficher dans l’interface utilisateur.

Techniquement, l’accès aux données se fait à l’aide d’une API Java fourn
ie par G
-
SCOP, qui
permet de simplifier la création des requêtes vers leur serveur. Elle permet également de
décoder simplement les réponses.



Figure
15

:
Exemple d'écran de l'application Android


B.2.3

I
NTEGRATION DU DEMONS
TRATEUR
DANS
D
OMUS


Afin que le système ReactivHome puisse fonctionner, il doit utiliser un certain nombre
d’informations concernant l’habitation. Il doit également pouvoir contrôler les appareils.
Cette connaissance et ce contrôle devaient être fournis par les pr
ises gigognes Schneider. La
quantité des prototypes étant limitée, et les sites de démonstrations étant déjà équipés de
capteurs, il a été convenu d’utiliser ceux déjà en place pour informer le système, en ajoutant
deux prises gigognes afin d’avoir la cons
ommation électrique de deux appareils (chose
impossible dans Domus, qui ne fournit qu’une consommation générale).


Pour l’intégration, il faut donc

:



Fournir un fichier de configuration au système, pour qu’il connaisse les
capteurs et les actionneurs de D
omus



Formater et fournir les données de ces capteurs au système, ainsi qu’un
moyen de contrôler les actionneurs



Intégrer les prises gigognes Schneider dans les actionneurs et capteurs de
Domus

B.2.3.1

Fichier de configuration du système



Dans la première version
de l’architecture du démonstrateur de Domus, la
configuration du système était effectuée par le serveur HAL représentation de G
-
SCOP. Il
fallait donc fournir au serveur un fichier xml contenant les différents capteurs et actionneurs
de Domus.

Ce fichier x
ml a été réalisé en fonction d’un schéma xsd fourni par G
-
SCOP et permettait de
configurer le système.

En raison de l’évolution du projet, l’architecture a ensuite été modifiée et la configuration se
fait dans la version finale dans la couche capteur, réal
isée par Orange. Le format étant
différent, il a fallu réaliser un autre fichier xml, en fonction d’un schéma cette fois fourni par
Orange. Ce fichier permet donc à la couche capteur d’être renseignée sur les capteurs
existants dans Domus et remonte la con
figuration vers le système ReactivHome.


B.2.3.2

Export des données de capteurs et contrôle des actionneurs


Afin que le système puisse accéder aux informations de Domus, et en contrôler les
appareils, un serveur lié au système de contrôle domotique a été développ
é.

Sa première mission est de fournir à la couche capteur les données de l’appartement. Ces
données sont donc récupérées en interrogeant le système domotique, puis exposée au format
xml selon un schéma fourni par Orange. Ce fichier contient, pour chaque ca
pteur dont la
valeur a été modifiée, la nouvelle valeur, et l’heure exacte de ce changement. Chaque fichier
généré couvre une période d’une minute (ce temps pourra être modifié après les premiers
tests du démonstrateur), et une fois généré, il écrase le pr
écédent sur le serveur.

La seconde mission du serveur est de permettre le contrôle des appareils présents
dans Domus. Un format xml a été défini avec les autres partenaires, et l’envoi d’un fichier
contenant les ordres et utilisant ce format permet de décl
encher les actions souhaitées au
niveau des actionneurs.

La couche capteur est ainsi liée au système domotique de Domus de la même façon
qu’elle l’aurait été aux prises gigognes Schneider si un appartement vide était équipé.


B.2.3.3

Intégration des prises Gigogn
es Schneider


Le système domotique de Domus n’étant pas équipé pour récolter les informations de
consommation d’un seul appareil électrique, une prise gigogne devait être incluse, afin de
pouvoir effectuer de la reconnaissance de charge, via la couche capt
eur.

Il a donc fallu utiliser l’API fournie par Schneider pour interroger la prise. Un logiciel
a ainsi été développé, permettant de récupérer la consommation active d’un appareil
branché sur celle
-
ci, et envoyant l’information au logiciel précédemment
développé pour
exporter les données de Domus sur le serveur. La prise gigogne est ainsi exposée et ses
informations sont ainsi accessibles comme celles de n’importe quel capteur de l’appartement.


B.2.4

T
ESTS DU DEMONSTRATEU
R DANS LA PLATEFORME

DOMUS

B.2.4.1

Développeme
nts


Le système ReactivHome n’étant pas complètement fonctionnel dans Domus et les
expérimentations nécessitant l’exécution de scénarios précis, le parti a été pris d’utiliser la
technique dite du «

magicien d’oz

», c'est
-
à
-
dire d’utiliser un opérateur, ay
ant accès aux
images et aux sons capturés dans Domus et pouvant ainsi simuler les prises de décisions, et
donc les actions du système, en fonction de l’avancement du scénario et des réactions des
sujets.


L’architecture du système ReactivHome a donc été si
mplifiée au maximum,
l’expérimentation n’utilisait en effet que la tablette et le serveur HAL représentation.

Ce dernier a donc subi quelques modifications, lui permettant d’exposer les données initiales
prévues dans les scénarios, données que le sujet ret
rouvait sur la tablette tactile.



Afin que l’opérateur puisse simuler les comportements du système, un logiciel a
également été développé. Celui
-
ci permet d’agir de différentes manières sur le serveur HAL
et sur l’appartement.

Le magicien peut ainsi chang
er la valeur des indicateurs principaux (confort, consommation,
production et
autoconsommation
) sur le serveur, ce qui entraîne une mise à jour de
l’affichage de ces indicateurs sur la tablette tactile, le sujet percevant ainsi que ses actions
influent sur

le système.

L’opérateur peut également agir sur les rampes de LED colorées présentes dans
l’appartement, ainsi que sur la couleur des dalles RFID, ces deux dispositifs étant également
testés lors de l’expérimentation comme moyens alternatifs pour le sujet

de connaître l’état
actuel du système.

Enfin, le robot à visage humanoïde Reeti étant utilisé lors de l’expérimentation, également
comme un moyen alternatif de prendre connaissance de l’état du système, l’outil permet à
l’opérateur de modifier le visage d
u robot, la couleur de ses joues, et de lui faire prononcer
des mots, montrant à l’utilisateur qu’il a compris sa requête. Par exemple, lorsqu’un sujet
demandait au robot de lui annoncer la valeur de la production, l’opérateur faisait dire
«

production

» a
u robot, tout en lui affichant un grand sourire et en colorant ses joues en
vert.


Figure
16

:
Logiciel utilisé par le magicien d’OZ pour les expérimentations




B.2.4.2

Conclusion

Les objectifs de la tâche 3 ont été atteints, un démonstr
ateur existe ainsi que les IHM qu’il
faudra mettre à l’épreuve dans un système déployé et de nombreux utilisateurs. Mais ceci
n’était pas le but du projet, qui doit maintenant passer à une phase industrielle.








B.3

T
ACHE
4

:

M
ODELISATION
,

SIMULATION ET IDENTI
FICATION AUTOMATIQUE

DES
EQUIPEMENTS ELECTRIQ
UES ET THERMIQUES
(
CEA
-
INES+

G2EL
AB
)


B.3.1

R
ECONNAISSANCE DE CHA
RGE


B.3.1.1

Objectifs de la tache

L’objectif visé par cette brique technologique qui sera intégrée au système ReactivHome
es
t double

:

1.

On cherche à identifier automatiquement les équipements électriques dans l’habitat
pour assurer l’auto
-
configuration du système de gestion de l’énergie

2.

On cherche à modéliser la consommation électrique des ces équipements pour que
le gestionnai
re d’énergie sache quelle quantité d’énergie réserver pour chaque
équipement lors des planifications de consommation

On expose dans ce document quelle a été l’approche choisie pour aborder ce problème,
quels moyens ont été mis en œuvre, quels techniques on
t été utilisées et enfin q
uels résultats
ont été obtenus.

B.3.1.2

Déroulement de la tâche

L’hypothèse principale faite pour nos travaux, est que nous disposerons de mesures des
grandeurs électriques effectuées au niveau de chaque équipement, attribuant les difficu
ltés
et échecs des systèmes existants à la nécessité de reconnaître les équipements en tête
d’installation avec un fort foisonnement.


La première action évidente à mener au regard de la tâche à accomplir a été de chercher à
en savoir plus sur le fonctionn
ement des équipements électriques qui nous intéressent, à
savoir les équipements des types suivants

:



Chauffe
-
eau électrique



Radiateur électrique fixe



Lave
-
vaisselle



Machine à laver



Four électrique traditionnel



Four à micro
-
ondes



Réfrigérateur



Ordinateur d
omestique



Ordinateur portable



Ecran LCD



Box internet


Pour chacun de ces équipements nous avons cherché à obtenir des mesures en
fonctionnement pour constituer une base de données sur laquelle nous fonderons nos
réflexions et testerons nos réalisations.

Quelques employés du CEA
-
INES ont été sollicités pour réaliser des mesures électriques
sur leurs appareils électroménagers. Des boitiers de mesure à intercaler entre l’équipement
étudié et sa prise murale ont été réalisés spécialement à cet effet.

Chaque
boitier (3 ont été réalisés) est composé d’un wattmètre et d’un mini
-
ordinateur, ce
dernier se chargeant de stocker un historique des mesures faites par le premier.




Une prise mâle et une prise femelle permettent d’intercaler aisément ce dispositif e
ntre
l’équipement et sa prise d’alimentation.


B.3.1.2.1

Approche pour l’identification des équipements

La connaissance du principe de fonctionnement de certains types d’équipements auxquels
on s’intéresse et l’analyse des séries de mesures à notre disposition nous
ont amené à
constater que la simple observation de la forme de la courbe de puissance absorbée permet
d’identifier bon nombre de types d’équipements.

B.3.1.2.2

Logique floue

La répétition des cycles de fonctionnements, la durée des cycles, le gabarit dans lequel ils

peuvent s’inscrire sont autant de critères sur lesquels l’œil humain se base pour tenter
d’identifier le type d’équipement à partir duquel une série de mesures donnée a été obtenue

;
c’est du moins ce sur quoi ont été systématiquement basées les justifica
tions données par
les personnes qui se sont prêtées à l’exercice.

Pour
formaliser

cette expérience et la traduire au sein d’un outil automatique nous avons
choisi d’utiliser la logique floue appliquée à des indicateurs calculés à partir des mesures
électri
ques. On verra, dans la suite de ce document, que ce choix offre aussi un potentiel
d’évolution à l’outil pour la prise en compte de nouveaux critères, de nouveaux types
d’équipements.

B.3.1.2.3

Cas de classification difficiles

Pour certains types d’équipements on f
ait aussi le constat que la discrimination au regard
des seules mesures électriques est une mission difficile. En effet, bien des équipements
partagent tout simplement les mêmes architectures d’alimentation électriques ce qui rend
leurs signatures non diff
érentiables les unes des autres.

Pour ces types d’équipements, comme les équipements dits «

bruns

» par exemple, la
classification pourra en revanche être faite par un système de plus haut niveau ayant accès
à l’ensemble des consommations électrique de l’h
abitat, à d’autres capteurs (présence, …)
et qui aura réalisé un apprentissage des usages des habitants.

Si les méthodes présentées dans ce document ne permettront pas pour ces types
d’équipements de faire une classification catégorique, elles feront tout
de même avancer le
sujet en informant le système appelant des types d’équipements qui sont susceptibles
d’avoir été à l’origine des consommations électriques étudiées.

B.3.1.2.4

Principe de fonctionnement de l’algorithme
d’identification/modélisation

Le schéma
-
bloc

ci
-
dessous représente le fonctionnement de l’algorithme d’identification
modélisation

:




Les mesures de puissance soumises à l’algorithme sont tout d’abord segmentées pour isoler
les cycles de fonctionnement de l’équipement électrique à identifier.



B.3.1.3

Résultat obtenue et conclusion

B.3.1.3.1

Résultats

Les résultats présentés ici ont été compilés à partir de tests faits sur notre algorithme
d’identification/modélisation paramétré avec le fichier de configuration communiqué dans
l’annexe 1. Ce fichier définit 12 m
odèles correspondant à 7 type
s

d’équipements différents :



Fridge01



InternetBox01



MicrowaveOven01



Oven01



Oven02



Oven03



Oven04



WaterHeater01



WashingMachine01



DishWasher01



DishWasher02



DishWasher03


Les tests ont été faits sur 44 séries de mesures.


B.3.1.3.2

Identific
ation

Le tableau suivant présente les résultats de la fonction identification de notre algorithme. On
y voit, en ligne, les différents types d’équipements sur lesquels les mesures ont été faites et,
en colonnes, les modèles ayant été retenus pour les série
s de mesures étudiée, et donc les
types d’équipements identifiés

:

Tableau



On voit ici aussi que la série de mesures provenant du congélateur est associée à la classe
«

réfrigérateur

» au travers du modèle «

Fridge01

». Les deux types d’équipement ont
un
mode de fonctionnement identiques et des signatures électriques non
-
différentiables

: ce
résultat est donc attendu.

Pour les autres types d’équipements, on voit que chaque série de mesures a bien été
classée correctement.


B.3.2

I
DENTIFICATION DE MOD
ELE
THERMIQUE

(
G2EL
AB
,

2

PAGES
)

I
DENTIFICATION D
U

MODELE THERMIQUE
(
G2EL
AB
,

2

PAGES
)

Objectifs de la tâche

C
ette tâche a pour objet l’obtention d’un modèle de bâtiment qui reproduit le
comportement thermique d’un certain bâtiment réel, dans notre cas
Armadillo
-
box de CEA
-
INES. Il s’agit d’une seule pièce munie des plusieurs capteurs environnementaux dont
l’enveloppe thermique laquelle est spécialement conçue afin d’assurer des performances
énergétiques élevées. A partir des mesures disponibles des gran
deurs d’entrée et de sortie et
du comportement physique de la pièce, on demande de trouver les coefficients d’un modèle
linéaire dynamique (dans le sens de la théorie des systèmes), le plus simple et robuste
possible.

Déroulement de la tâche

Les données d’
Armadillo
-
box étant disponibles sur un horizon de temps assez
réduit

(à la
limite de quelques jours), nous avons choisi un
modèle

d’ordre réduit (d’ordre 1), car le
changement des températures du sol et des parois est négligeable. Le modèle thermique
génér
ique de la pièce a été développé, dont celui d’ordre 1 qui est donné dans l’équation
d’état suivante

:



(1)

Le modèle d’état se présente donc sous la forme :

,

où:

est le vecte
ur d’état,

est le vecteur d’entrée,

représente la matrice d’état et

constitue la
matrice d’entrée.

Les mesures de température extérieure, ensoleillement global de la maison,
débit et température de l’échappement de la pompe à chaleur (PAC) sont les entrées et la
température intérieure de la maison est la sortie.

Le schéma électrique équivalent de ce modèle est donné en
F
igure 1
.

Les paramètres du modèle


voire les résistances

thermiques
,
,

et la capacité



qui constitue les coefficients de la matrice d’état et d’entrée, doivent être obtenus par calcul.
Dans ce but, les te
mpératures
,
,

doivent être estimées et le flux thermique

doit être calculé. Une liaison entre la température extérieure de la maison et l’ensoleillement
a été identifiée.

L’identification du modèle est de type «

boîte noire

» et utilise la méthode optimale de
sous
-
espace «

n2sid

» du logiciel MATLAB. Afin d’app
liquer la procédure d’optimisation, les
données primaires enregistrées pour plusieurs jours ont été mises dans une forme
souhaitable (harmonisations des périodes d’échantillonnage, filtrage primaire,
etc
.
). Suivant
l’obtention des coefficients de la matric
e d’état et d’entrée, une vérification de la précision
d’estimation a été réalisée. Cela implique l’excitation du modèle par les mêmes séries de
temps d’entrée et la comparaison du vecteur de la température intérieure avec la mesure de
température de la pi
èce réelle.



Figure 1
. Schéma équivalent du modèle thermique de la pièce


En consultant la fiche technique d’Armadillo
-
box, on peut calculer certains paramètres
comme

et

afin de calculer les autres à partir du modèle (1) et des coefficients de la
matrice d’état et d’entrée auparavant identifiés.

Résultat obtenu et conclusion

L’identification du comportement thermique donne des résultats satisfaisants. Une
comparaison entr
e la sortie du modèle identifié (rouge) et la mesure de la température
intérieure de la pièce (bleu) pour deux différents jours est visible dans la
F
igure 2
.



Figure 2
. a) Comparaison entre le résultat de l’identification et la mesure réelle pour le jour
j

; b) Comparaison entre le résultat de l’identification et la mesure réelle pour le jour
j
+1


B.3.2.1

Résultat obtenue et conclusion

Lors de l’identification croisée, une certaine variation des paramètres a été identifiée, en
suggérant une possible
non
-
linéarité

dans le système.

B.4

T
ACHE
5

:

S
UPERVISION ET COMMAN
DE REACTIVE
,

ANTICIPATIVE ET
ADAPTATIVE

B.4.1

M
ODULE DE PREDICTION
DE PRODUCTION SO
LAIRE

(
CEA
-
INES,

2

PAGES
)

B.4.1.1

Objectifs de la tache


La tâche 5.1 «

Prévision de la production photovoltaïque

» consiste à développer un outil
permettant de prévoir 24h à l'avance la production photovoltaïque à partir de prévisions
météorologiques et de mesur
es locales (voir figure 1).



Figure
17

: représentation sché
matique de l’outil de prévision

B.4.1.2

Déroulement de la tâche

Plusieurs approches sont envisageables pour prévoir la production photovoltaïque du
lendemain. On peut :

-

soit a
voir une approche de type boite noire, dans laquelle on ne modélise pas
directement les phénomènes physiques, mais on essaye de les appréhender par des lois
statistiques et explicatives existant entre les entrées (les prévisions météorologiques) et les
so
rties (la production photovoltaïque)

-

soit utiliser des modèles physiques pour prendre en compte les différents
phénomènes ‘du soleil au réseau électrique’ impactant la production

-

soit mener une approche hybride, qui d’un côté utilise une boite noire po
ur des
phénomènes difficile à modéliser, et les modèles de l’état de l’art pour ceux plus accessibles.

C’est cette dernière approche que nous avons mis en œuvre.

L’algorithme de prévision suit les étapes décrites dans la figure 2.


Figure
18

: Module de prévision


Dans un premier temps les prévisions météorologiques
sont récupérées et traitées afin
d’obtenir les prévisions pour le site considéré. Les spécificités du site sont prises en
considérations à ce moment
-
là.

Le pas temporel de la prévision météorologique est typiquement de 3h, il est alors
nécessaire de passer

à un pas inférieur (par exemple de une demi
-
heure) par interpolation.

Ensuite, l’impact des masques lointains (collines, montagnes) et proches (bâtiments) est
pris en compte.

La dernière étape consiste à appliquer les modèles de la centrale photovoltaïque

afin de
calculer la production électrique de cette centrale. Les caractéristiques des différents
composants de la centrale peuvent être utilisées. Les modèles utilisés dépendent des
informations que l’on dispose.


Cet outil est auto
-
adaptatif en exploitan
t les mesures disponibles et les algorithmes
développés font appel à des techniques d’apprentissage et d’intelligence artificielle.

Prévision
météorologiques

Météo locale

Simulation de la

centrale

Prévision de la
production

Interpolation
temporelle

Pris en compte des

masques

La partie ‘apprentissage’ du système est capitale, c’est elle qui permet d’atteindre de
bonnes performances, et d’aboutir à
une erreur et une incertitude sur la prévision
relativement faible.

C’est à la fin de chaque journée que le module d’apprentissage est lancé afin de recalculer
certains paramètres caractéristiques de la centrale photovoltaïque.

Son fonctionnement se résume

ainsi :

Il récupère les mesures de la journée qui vient de se finir, les intègre dans une base de
données contenant tout l’historique de la centrale. Ensuite différents algorithmes
d’apprentissage sont exécutés afin de mettre à jours les jeux de paramètre
s et poids des
modèles successifs qui sont mis en œuvre par l’outil de prévision.

La figure 3 présente l’ensemble de l’outil de prévision avec sa partie apprentissage.


Figure
19
: Outil de prévision complet avec module d’apprentissage

B.4.1.3

Résultat obtenue et conclusion

Table 1

: Evaluation de notre système de prévision de la puissance


Notre outil

Persistance


Prévision
météorologiques

Météo locale

Simulation de la

centrale

Prévision de l
a
production

Interpolation
temporelle

Pris
e

en compte des

masques


Monitoring centrale

Base de
données

Module d’apprentissage


Nbr de jours
apprentissage

Nbr de jours
pour valider

MAE moyenne

(écart
-
type)

MAE médiane

MAE moyenne
(toutes données)

MAE moyenne

(écart
-
type)

MAE médiane

MAE moyenne
(toutes données

Amélioration

Cadarache 1

77

58

8.4 % (5.8)

8.4

5.8

11.3 % (8.4)

11.8

9.8

25.8 %

Cadarache 2

436

405

8.5 % (6.1)

8.7

6.5

12.1 % (9.3)

12

9.4

29.6 %

Grenoble

70

39

8.1 % (3.9)

8.6

6.8

8.3

% (6.6)

9.5

6.5

2.6 %

Doubs(25)

19

6

13.7 % (1.3)

14.8

13.3

7.8 % (5.2)

9.3

6.6

-
76.3 %

Vienne (86)

169

140

11 % (7.1)

11

9.4

12.6 % (8.7)

12.8

11.2

12.9 %

Gard (30)

168

132

10.5 % (7.3)

10.2

8.5

14.1 % (9.2)

14.1

12.1

25.6 %

Drôme (26)

334

263

9.4 %
(5.8)

9.4

7.8

12 % (7.9)

12.5

10.6

21.5 %

INES 1

189

140

19.3 % (13.9)

18.2

14.6

21.2 % (15)

22.1

17.8

9 %

INES 2

258

217

11.5 % (7.2)

11.2

10

14.5 % (8.7)

14.7

13.6

21 %

INES 3

141

108

11.5 % (8.1)

11.5

8.7

12 % (9.1)

12.1

8.9

4.5 %

B. du Rhône (13)

133

98

11.3 % (8.9)

11

8.4

11.9 % (8.7)

12.3

9.3

4.4 %

Réunion (974)

79

67

11.1 % (4.2)

11.4

10.3

13.4 % (5.6)

13.7

13.5

17.2 %


Dans la plupart des cas, notre outil apporte une amélioration par rapport à la prévision de la
persistance.

Il est à noter
que les résultats présentés ici sont très certainement sous
-
évalués par rapport
aux performances réelles de l’outil. En effet, nous avons pu observer de mesures aberrantes
parmi les données malgré les filtres automatiques que nous avons mis en place (ce qu
i est
habituel quand on traite des données réelles). Nous avons fait le choix de conserver ces
données car nous souhaitons que l’outil soit robuste aux données aberrantes afin qu’il soit
capable de travailler en conditions réelle (où il n’y aura pas de pos
t
-
traitement possible).
Cependant, il est à craindre dans ce genre de situation, que des données aberrantes rendent
compte d’erreurs (qui en réalité n’en sont pas).

Les tests que nous avons menés sur un assez grand nombre de données réparties sur
plusieurs

sites sont globalement très positifs. Ils montrent clairement que notre outil apporte
un gain significatif par rapport à un système de prévision de la production par la persistance.
Le fait qu’il est été testé avec succès sur des centrales réparties sur d
ifférents sites
géographiques et dont les caractéristiques sont

parfois différentes montre la bonne capacité
d’adaptation de notre outil. Nous considérons donc que le système de prévision développé
ici est d’ores et déjà opérationnel.


B.4.2

C
OMPOSANT LOGICIEL
AUX INTERFACES STAND
ARDISEES PREVOYANT L
ES DE
MANDES
DE SERVICE DES HABIT
ANTS
(G
-
SCOP,

2

PAGES
)


B.4.2.1

Objectifs de la tache



B.4.2.2

Déroulement de la tâche



B.4.2.3

Résultat obtenue et conclusion


B.4.3

C
OMPOSANT LOGICIEL AU
X INTERFACES STANDA
RDISEES POUR LE PILO
TAGE REACTIF
ET
ANTICIPATIF
(G
-
SCOP,

4

PAGES
)


B.4.3.1

Objectifs de la tache



B.4.3.2

Déroulement de la tâche



B.4.3.3

Résultat obtenue et conclusion








C

P
HASE
3

:

T
ESTS DE PERFORMANCE

ET VALIDATION

C.1

R
APPEL DE L

OBJECTIF DE
LA PHASE
3


Cette tâche avait pour objectif la réalisation du
prototype, la mise en place de
l’environnement de test et les essais.

C.1.1

V
ALIDATION DE LA COUC
HE
H
OME ABSTRACTION LAYE
R

:

IDENTIFICATION
,

MONITORING ET RECONF
IGURATION MULTI
-
CAPTEURS DE PLUSIEUR
S EQUIPEMENTS
PHYSIQUES ET
PIECES


Le fonctionnement de cette
couche, en particulier pour ce qui concerne les mécanismes
d’auto
-
configuration et de monitoring, a été validé par un ensemble de scénarios qui en
couvrent les différents cas d’utilisation

:

C.1.1.1

Matériel spécifique

2 équipements électroménagers de types dif
férents, avec possiblement utilisation de
plusieurs équipements du même type (mais pas du même modèle au sens commercial)

o


une bouilloire (peut être présentée comme analogue à un chauffe
-
eau
domestique du point de vue de la gestion énergétique)

o

un petit r
adiateur électrique soufflant (présenté comme équivalent à un gros
radiateur du point de vue de la gestion énergétique)



Un équipement ICT«

état de l’art

»



une imprimante
-
scanner
-
copieur personnelle
-


exemple d’équipement
configurable par un mécanisme clas
sique zeroconf/SOA

3 kits de capteurs équipements (3 capteur de courant+ 2
capteur
s

de température+ capteur
d’eau simulé)

1

capteurs (multimodaux)

ZigBee Texas Instrument : une combinaison de trois capteurs
intégrés dans une maquette (capteurs de vibrations
, capteurs de
lumières
, capteur de
température).

Figure
20

Exemples d’équipements utilisés pour la validation l’identification et configuration
dans le système HAL

C.1.1.2

Scénarios utilisés pour la validation

Configuration

initiale (équipement non numérique)

o

événement initial de capteur dédié (

capteur de courant ou mo
de

muticapteur
posé sur l’équipement) qui déclenche la découverte

o

initialisation de la configuration de l’équipement avec un modèle générique.

o

association
entre le capteur initial (courant ou température) et équipement avec
un modèle correspondant de l’équipement (équipement électrique ou équipement
dissipant de la chaleur, suivant le capteur utilisé pour la découverte)

o

association avec un 2
e

capteur (eau
pour la bouilloire) en exploitant la coïncidence
temporelle entre les événements des 2 capteurs

o

mise à jour du modèle de l’équipement par un modèle plus spécifique
(équipement électrique utilisant de l’eau, équipement chauffant utilisant de l’eau,
suivant

le capteur utilisé initialement)

C
onfiguration initiale (équipement numérique état de l’art)

o

événement de capteur (

capteur de courant) qui déclenche la découverte par
notre mécanisme

o

initialisation de la configuration de l’équipement avec un modèle génér
ique.

o

association entre capteur de courant et équipement au niveau du modèle de
l’équipement

o

interrogation annuaire réseau sur présence équipement

o

si présence nouvel équipement pour ce type d’équipement utilisation contrôle en
boucle fermée avec actionnem
ent par l’interface ICT pour détecter que c’est le
même équipement que celui qui est associé au capteur de courant

o

mise à jour du modèle générique avec un modèle correspondant (dans un
alignement effectué préalablement entre les 2 ontologies) au modèle spé
cifique
supposé connu dans l’infrastructure de service à la quelle est associée un
équipement ICT «

état de l’art

» (exemple de l’imprimante)

Configuration de «

groupes d’entités

»
5
en tant que couche distincte
au
-
dessus

du
HAL avec un mapping 1


n ou n

1
sur les entités



Montrer la configuration d’un service «

service chauffage

» regroupant l’ensemble
des entités «

radiateur

», mais aussi l’ensemble des entités chauffantes (qui ne sont
pas des radiateurs mais ont un effet de bord chauffant) représentées da
ns HAL en
tant que rattachées à la catégorie «

heat dissipating

», qui vont se trouver intégrées
au service chauffage

o

exemples

: réfrigérateur, plaque chauffante, TV grand écran, projecteur
vidéo…

o

Montrer comment un modèle commun dénominateur de toutes c
es entités
(heat

Disspating Equipment) se trouve associé à ce groupe d’entités

o

Configuration dynamique Intégrer une personne rentrant dans le périmètre
du groupe d’entités comme «

entité chauffante

» de 100w



Idem avec un service éclairage intégrant les l
uminaires et écrans

o

Exemples d’entités ou devices actionneurs à intégrer

: ampoules, luminaires,
écrans

o

Pour la configuration dynamique montrer l’intégration des fenêtres dans le
groupe q
uan
d on passe du jour à la nuit

?

Monitoring des changements d’état

avec par affinement de l’identification et de la
configuration au fil de l’eau

o

Changements d’état sur modèle générique

o

Passage à un modèle plus spécifique après un cycle de monitoring
-


reconnaissance de l’équipement par pattern multi
-
capteur

o

Changements d’état dans utilisation normale sur modèle spécifique obtenu après
affinement de configuration

o

Estimation de paramètres associés à l’état, par exemple

:



Température



Volume de l’eau ou énergie latente




5

Pouvant corr
espondre à des «

services

» au sens du système g
-
home tech de reactivhome

o

possibilité d’utiliser l’interface utilisa
teur de configuration manuelle de cet
équipement pour en renseigner les paramètres
-


ne sera pas partie de la démo,
mais une alternative

Reconfiguration dynamique

repartir à 1

o

On prend 2 équipements suffisamment différents pour pouvoir les distinguer

au
bout de q
uel
q
ues

minutes de fonctionnement par leur signature de courant
-


par exemple imprimante et bouilloire

o

On intervertit les capteurs de courant sur les 2 équipements

o

on montre comment le système se reconfigure en
réassociant

les bons capteurs
et
reconnaissant les équipements sur leurs attachements différents

o

on montre le début du monitoring sur nouveaux cycles

Reconfiguration dynamique

repartir à 1



Reconfiguration

dynamique avec reconnaissance de patterns
multi capteurs

les
niveaux de co
urant sont identiques

-


On utilise 2 capteurs de courant (Zigbee) + 1 capteur autre que courant qui
pourra
être

capteur/compteur d’eau (déjà utilisé pour la configuration initiale),
ou de température (cleode/ Zigbee) ou une antenne

-

Les 2 équipements et l
e capteur sont posés sur une table et connectés avec 2
capteurs de courant différents



On prend 2 équipements qui ne PEUVENT PAS
être

distingués par leur
signature de courant (puissance identique)
-


parmi les couples suivants

:

i