\documentclass[12pt,twoside]{article}
\usepackage[utf8]{inputenc} % apparemment utf8x est mieux que utf8 mais c'est incompatible avec biblatex...
\usepackage[T1]{fontenc}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{amsfonts}
\usepackage{textcomp}
\usepackage[style=numeric,backend=biber]{biblatex}
\usepackage{csquotes}
\usepackage[francais]{babel}
\usepackage[pdftex]{hyperref}
\usepackage{verbatim}
\usepackage{alltt}
\usepackage{hhline}
\usepackage{lmodern}
\usepackage{fancyhdr}
\usepackage{graphicx}
\usepackage[a4paper,margin=2cm]{geometry}
% \usepackage[hmarginratio=1:1]{geometry}
\usepackage{listings}
\usepackage{float}
\usepackage{url}
\usepackage{tabularx}
\usepackage{calc}
% \usepackage[scaled]{luximono} % des fontes "tt" avec gras et italique
  % /!\ Fontes non dispos sous debian!  Faire:
  % # wget http://tug.org/fonts/getnonfreefonts/install-getnonfreefonts
  % # texlua install-getnonfreefonts
  % # getnonfreefonts -a
  % # getnonfreefonts-sys -a
  % # texhash
  % # rm install-getnonfreefonts
\usepackage{xspace}
% \usepackage{garamondx}
% \usepackage{slantsc}	% des fontes small caps penchées

\bibliography{labo}


\newcommand{\xAAL}{\textsc{xAAL}\xspace}

\begin{document}

\title{Motivations pour le protocole \xAAL}

\author{Christophe Lohr}

\maketitle

\begin{abstract}
Ce document, très orienté par la vision de l'auteur, tente d'expliciter et
de motiver les choix faits par l'équipe IHSEV de Télécom Bretagne pour la
définition de ce protocole.
\end{abstract}


\section{Introduction}
\subsection{Contexte historique}
Depuis 2002, l'équipe IHSEV\footnote{\url{http://departements.telecom-bretagne.eu/info/recherche/ihsev/}} 
(anciennement SID) de Télécom Bretagne s'intéresse aux
systèmes d'information et de communication pour l'aide aux personnes
dépendantes, que la dépendance soit liées à la maladie, un handicape, ou
simplement la vieillesse.

\begin{itemize}

\item Le projet \textsl{Maison Intelligente} (2001-2004) avait pour objectif
  le développement de solutions techniques favorisant la vie à domicile des
  personnes lourdement handicapée.  Ce sont les premiers travaux de l'équipe
  concernant la convergence des protocoles de réseaux domestiques et de IP. 
  L'équipe avait alors choisit le protocole UPnP-Home
  Automation\footnote{\url{http://upnp.org/specs/ha/}} (\emph{Universal Plug
  and Play}) comme protocole pivot entre les divers protocoles matériels
  (principe de \emph{gateway} X10, X2D, RC5, Bluetooth, etc.), et avec les
  interfaces utilisateurs.
  \cite{TELECOM_BRETAGNE-2030,TELECOM_BRETAGNE-2071,TELECOM_BRETAGNE-1003}

\item Par la suite, les projets \textsl{T@pa} (2005-2006)
  \cite{TELECOM_BRETAGNE-1575,TELECOM_BRETAGNE-1146,TELECOM_BRETAGNE-1147,TELECOM_BRETAGNE-4581}
  \textsl{Companym@ges} (2007-2009) 
  \cite{TELECOM_BRETAGNE-7221,TELECOM_BRETAGNE-2911,TELECOM_BRETAGNE-3401,TELECOM_BRETAGNE-8759,TELECOM_BRETAGNE-8370}
  et \textsl{Mazadoo} (2010-2012) 
  \cite{TELECOM_BRETAGNE-10834,TELECOM_BRETAGNE-8369}
  se sont focalisés sur les technologies de type télévision connectée et les
  \emph{services relationnels} (de type messagerie, album photo, visio,
  réseaux sociaux, sur TV), à destination des personnes âgées en maison de
  retraite.

\item L'équipe à renoué avec les technologies domotiques dès le
  projet \textsl{\textsc{Sigaal}} (2009-2011)
  \cite{TELECOM_BRETAGNE-13349,TELECOM_BRETAGNE-12361,TELECOM_BRETAGNE-10287,TELECOM_BRETAGNE-9577,TELECOM_BRETAGNE-9815}
  et \textsl{Amalys}
  \cite{TELECOM_BRETAGNE-9921,TELECOM_BRETAGNE-9922}
  (2011-2013), où les technologies domotiques se trouvaient intégrés avec
  les services TV.  Les usagers (personnes âgées à leur domicile)
  bénéficiaient alors sur leur TV non seulement des services relationnels,
  mais également de domotique (pilotage des équipements de la maison,
  actimétrie du type "temps passé dans chaque pièce ou hors du domicile"),
  ainsi que des services complémentaires sur smartphone et tablette (e.g.
  interface utilisateur, géolocalisation out-door, alarme, etc.)
  Pour cela, l'équipe avait alors choisit d'abandonner UPnP jugé trop
  complexe, mais en gardant certains principes fort comme le mécanisme de
  découverte des équipements.  Dans un premier temps, l'équipe c'est
  intéressé au protocole xAP jugé plus intéressant que la variante xPL, en
  tentant de réintroduire le mécanisme de découverte.  Cependant, il est
  rapidement apparu que la définition d'un nouveau protocole s'imposait. 
  C'est ainsi que le protocole \xAAL est né dans notre équipe.

\item Aujourd'hui, nous proposons de poursuivre nos travaux sur
  l'élaboration de ce protocole domotique au travers de projets comme
  \textsl{\textsc{Precious}} (2013-2016) pour la prévention des facteurs de
  risques de maladie chroniques (e.g.  diabète), le CPER VITAAL (2014-2020)
  qui s'intéresse notamment à la \emph{domomédecine} (i.e.  services
  intégrés de santé à domicile), ou les nombreux projets étudiants (centrale
  téléphonique alliée à la centrale domotique, codage de passerelles pour
  divers protocoles Z-Wave EnOcean, etc.).

\end{itemize}


\subsection{La domotique...}
Depuis maintenant 25 ans, des constructeurs proposent des équipements
permettant de piloter à distance les équipements de la maison (appareils
électroménagers, lumière, chauffage, ouvrants, alarme, etc.). Ces solutions
sont regroupées sous la dénomination
\emph{domotique}\footnote{\url{http://fr.wikipedia.org/wiki/Domotique}}.

Les domaines d'applications sont typiquement le confort, la gestion du
chauffage, la sécurité des biens.  Mais de nouveaux services apparaissent,
liés à l'introduction de l'informatique et de l'Internet dans les domiciles.

\begin{itemize}
\item Gestion du domicile à distance.  On connaissait les solutions
permettant de coupler le programmateur du chauffage avec un boîtier
téléphonique.  Le propriétaire peut alors allumer ou éteindre le chauffage à
distance, par un appel téléphonique.  Aujourd'hui cela se fait via Internet,
par exemple grâce à une interface web ou une application sur smartphone 
proposée par un opérateur de solution domotique.
De même, l'utilisateur peut visionner les caméras de vidéo-surveillance de
son domicile à distance, voir piloter entièrement sa maison par Internet. 
Quelques exemples parlants : 
Archos Smart Home\footnote{\url{www.archos.com/fr/products/objects/chome/ash/}}
Blyzz\footnote{\url{http://www.castorama.fr/store/pages/blyss-liveez.html}}
Control4\footnote{\url{http://www.control4.com/}}
DomoCube\footnote{\url{http://www.domocube.net/}}
Home by SFR\footnote{\url{http://boutique.home.sfr.fr/}}
Home Confort\footnote{\url{http://www.home-confort.net/}}
MyFox\footnote{\url{http://www.myfox.fr/}} etc.
(dans l'ordre alphabétique).

\item Interface utilisateur. Dans tous les exemples précédents, on aura
remarqué que, outre une interface utilisateur de type web, les opérateurs
proposent quasi systématiquement des interfaces sur tablettes ou smartphone,
et parfois aussi sur TV.  Cela apporte un réel confort en terme d'ergonomie. 
Comparez aux dispositifs de précédente génération, avec comme seul interface
un boitier avec deux ou trois boutons et un petit afficheur... 
Souvenez-vous du temps passé à régler les différentes plages horaires des
différentes zones du programmateur de chauffage électrique de votre 
maison...  décoder la signification des pictogrammes jour/nuit (qui sont 
pourtant standardisés), appuyer sur le seul petit bouton disponible pour 
faire défiler les minutes jusqu'à l'heure souhaitée, etc.
Bref, pour peu qu'il y ait eut un minimum d'efforts sur le design, ces
nouvelles interfaces de type informatique (web, tablettes, smartphone) sont 
réellement plus agréables à regarder, plus intuitives à utiliser, et plus 
riches en fonctionnalités.

Il y a également un intérêt économique: charge à l'utilisateur d'acheter ce
terminal (PC, tablette, smartphone,...);  le fabriquant se contente de mettre
à disposition une "application" à installer...

\item Surveillances de la consommation des fluides. Ce vocable renvoie aux
futures \emph{Règlementations Thermiques} 2015 et 2020 des bâtiments neufs
qui imposent, notamment, d'afficher à l'utilisateur sur son lieu de vie
(c.à.d. pas dans un placard technique au fond de la cave) sa consommation
réelle ou estimée des différents fluides consommés à son domicile:
électricité, gaz, eau, etc.  Cela implique des capteurs, des afficheurs, et
une capacité de journalisation ou de mémoire des relevés de mesure à
différentes échelles de temps. Outre les innombrables bricolages à brancher
sur le port téléinformatique disponible sur les compteurs
EDF\footnote{\url{http://bernard.lefrancois.free.fr/del1.htm}} (ou même se
contentant de compter les clignotements de la
led\footnote{http://northq.com/}), on trouve quelques produits commerciaux
dédiés (e.g. la Dombox\footnote{\url{http://www.dombox.fr/}}).

\item Sécurité des biens. Traditionnellement, les centrales alarme étaient
positionnées (d'un point de vu réglementation et marketing) un peu à côté
des solutions domotiques.  Cependant, d'un point de vu technologique, ces
deux gammes de produits partagent de nombreuses solutions techniques
(capteurs, transmission, boîtier de collecte ou centrale alarme).  La
différence majeure est que l'on va systématiquement privilégier des
techniques de transmission sécurisées entre les capteurs et la centrale
alarme (par exemple avec des protocoles à codes tournants, comme le KeeLocq
de Microchip), alors que ce n'était pas nécessairement le cas pour la
domotique simple (comme les protocoles X10 ou HomeEasy qui ressemblent plus
à des protocoles de télécommande infrarouge transposés à la radio).

Aujourd'hui, le recours à une transmission sécurisée est quasi systématique,
que ce soit pour des services de confort comme pour des services de
surveillance et d'alarme.  Par voie de conséquence, les constructeurs
fusionnent ces deux gammes, et utilisent les mêmes techniques de
transmission, voir le même boîtier de collecte.  Il est alors possible de
proposer un panel de services tout intégré: à la fois services de confort
et services de surveillance. Les produits mentionnés en tête de cette
section sont parlants sur ce domaine.

\item Sécurité des personnes. 

\item http://www.athemium.com/

\item Internet des objets.
\end{itemize}


\subsection{Question d'interopérabilité}
Pour des raisons de secret industriel et de modèle de vente, les produits
d'un constructeur ne sont que très exceptionnellement interopérables avec les
produits d'un autre constructeur (e.g. un interrupteur Legrand ne peut pas
piloter un volet roulant Delta Dore).

En effet, chaque constructeur, ou parfois des consortiums de constructeurs,
a défini un protocole spécifique pour les équipements qu'il vend.  Parmi les
plus connus, citons:
X10\footnote{\url{http://fr.wikipedia.org/wiki/X10_(informatique)}},
X2D\footnote{\url{http://domotique.comprendrechoisir.com/astuce/voir/155607/le-protocole-x2d-x3d-comment-ca-marche-pour-qui}},
KNX\footnote{\url{http://www.knx.fr/}},
Enocenan\footnote{\url{http://www.enocean.com/en/home/}},
ZWave\footnote{\url{http://www.z-wavealliance.org/}}.  Ces protocoles
peuvent être sur courant porteur (X10, X2D, KNX), sur radio (X2D X3D, Enocean,
ZWave) typiquement en 434 Mhz ou en 868 MHz.  D'autre protocoles comme
Zigbee\footnote{\url{http://www.zigbee.org/}} ou
Bluetooth-LowEnergy\footnote{\url{http://www.bluetooth.com/}} sont en
principe dédiés à des transmissions plus complexes et encore assez peu
utilisés en domotique mais tendent à le devenir.  De fait, les équipements 
domotiques ne sont pas interopérables.  Le standard
6LowPan\footnote{\url{http://fr.wikipedia.org/wiki/6LoWPAN}} (RFC 4919, RFC
4944) n'est quasiment pas utilisé dans les produits du commerce aujourd'hui. 
Notons que le protocole historique X10, dont le niveau de sécurité est très
faible, a vu ses spécifications techniques rapidement découvertes et s'est
retrouvé un standard de fait pour un certain nombre de constructeurs pendant
de nombreuses années.

Certains constructeurs font un pas timide vers l'ouverture de leur protocoles.
Tout en gardant secret les spécifications techniques de leur protocoles, ils
proposent à leur catalogue des transmetteurs incluant leur protocole
domotique et pouvant par exemple se brancher
sur le port USB d'un PC, et fournissent quelques librairies permettant de 
programmer des applications (typiquement des interfaces graphiques).

Compte tenu de l'existant (du parc installé, et du business modèle de type
marché captif), il est néanmoins peu réaliste de penser que l'un de ses
protocoles puisse s'imposer.  Pour gérer ce problème d'interopérabilité, la
stratégie aujourd'hui est de mettre en place des passerelles, ces fameuses
\emph{box domotiques} qui font un peu plus que le simple rôle de
concentrateur, mais qui supportent plusieurs protocoles constructeurs
simultanément\footnote{\url{http://domotique-info.fr/controleurs-domotique/}\\
\url{http://domotique-info.fr/2011/07/offres-box-domotique/}}.  Ces boîtiers
permettent une certaine souplesse, mais restent toujours limités à un nombre
donné de protocoles domotiques, et eux non plus ne sont pas interopérables
entre eux.


\subsection{Architecture} 
Les installations domotiques s'organisent classiquement autours de trois
grans types d'architectures:

\begin{itemize}
\item Paire à paire. Dans ce mode de fonctionnement, les équipements sont
dits \emph{appairées} entre eux.  Par exemple: telle télécommande est
appairée avec tel et tel volet roulant; tel thermostat pilote tels et tel
radiateurs; tel interrupteur allume ou éteint telle lampe.  Ce type
d'installation est intéressant lorsque l'on veut moderniser du bâti ancien
avec des solutions sans fil. Lors d'une phase préliminaire d'installation,
chaque équipement va apprendre les adresses des autres équipements avec
lesquels il doit dialoguer: de la façon traditionnelle en appuyant 
simultanément sur un bouton (e.g. X2D), ou méthode plus moderne à l'aide de
badge NFC (e.g. Wattlet\footnote{http://www.wattlet.fr/}).

\item Centralisée. C'est lorsque l'on a recours à une \emph{centrale
domotique}. Dans le cas le plus simple nous rencontrons le programmateur
du chauffage. La quasi totalité des maison équipées de chauffage électrique
connaissent le principe du programmateur: un boîtier installé généralement
dans la boîte à fusible de la maison, relié aux convecteurs via un fil
pilote, et gérant plusieurs zones de la maison pour baisser ou monter le
chauffage en fonction de l'heure de la journée ou du jour de la semaine. 

Mais plus généralement c'est l'architecture des centrales d'alarme: un
ensemble de capteurs d'intrusion (sur les ouvrants, détecteur de présence
volumétrique ou infra-rouge), un digicode pour désactiver l'alarme, un
dispositif d'alerte sonore lumineux ou téléphonique, le tout relié à un
boîtier central: la centrale d'alarme. 



\item 
http://www.universalremote.com/ (automate)
http://www.multiroom.fr/la-premiere-interface-domotique-en-surimpression-a-lecran/



\item Informatisées.



\end{itemize}



\subsection{Périmètre de l'étude}
Nous nous intéressons aux \emph{protocoles réseau domotiques sur IP}. 

\begin{itemize}
\item En premier lieu, c'est un \emph{protocole réseau} (en l'occurrence sur
IP) par lequel des équipements (capteurs, actionneurs, interfaces
utilisateurs, moteurs de scénarios, etc.) peuvent interagir entre eux en
s'envoyant des messages soit informatifs (e.g.  relevé de température) soit
de commande (e.g.  éteindre le chauffage).

\item Ce protocole se veut une abstraction des divers protocoles
constructeurs.  Le protocole que nous proposons ne se veut pas \emph{de plus
haut niveau}, avec plus de fonctionnalités, plus de services, plus
d'intelligence que les protocoles constructeurs.  Non, il se veut un langage
commun, permettant de dialoguer indifféremment avec des équipements de
constructeurs différents, avec le même niveau d'information dans les
messages échangés.  Le réseau par excellence qui s'impose aujourd'hui pour
cela est IP.  IP (\emph{Internet Protocol}) a supplanté tous les autres
protocoles concurrents des premiers jours d'Internet.  (Pensez à
IPX\footnote{\url{http://fr.wikipedia.org/wiki/Internetwork_Packet_Exchange}},
Decnet\footnote{\url{http://en.wikipedia.org/wiki/DECnet}},
Cyclades\footnote{\url{http://fr.wikipedia.org/wiki/Cyclades_(réseau)}},
X25\footnote{\url{http://fr.wikipedia.org/wiki/X.25}}, ...)

\item Ethernet... idem


\item Le fait que ce soit \emph{domotique} implique deux choses.  Tout
d'abord en terme d'équipement: ce sont des capteurs (ouverture de porte,
température, consommation d'eau ou d'électricité, etc.), des actionneurs
(commande de chauffage, lumière, volets roulants, etc.), et interfaces
utilisateurs ou des automates programmables.  Par contre, les flux réseau de
type échange de fichiers, vidéo, audio, interface web, etc.  n'ont pas leur
place sur ce réseau domotique.  Par exemple, si l'on veut commander la
chaîne hifi ou la caméra de vidéo-surveillance, il pourrait être tout à fait
légitime d'utiliser le réseau domotique pour la commande proprement-dit
(déclencher la musique ou la caméra, changer le volume, orienter la caméra,
etc.), par contre les flux audio ou vidéo doivent emprunter un autre canal
que le protocole domotique décrit ici (dans l'exemple précité: HTTP
Streaming, RTP, DLNA, ...).

Il faut donc garder à l'esprit que les équipements visés sont par nature
assez simple (thermomètre, contacteur de porte, interrupteur, etc.).  Par
conséquent, ce protocole doit rester foncièrement simple.  Même si la
complexité d'un protocole de plus haut niveau pourrait être déportée sur les
fameuses passerelles, on peut imaginer qu'un jour notre protocole domotique
soit directement implanté sur les équipements domotiques eux-mêmes (p.ex. 
Arduino, carte RN131 ou équivalent).  Le niveau de dialogue et le niveau de
complexité doit rester simple: pas d'automate protocolaire complexe,
quasiment sans état à garder en mémoire, quasiment pas de calcul.  (Notons
que cela puisse sembler être antinomique avec les besoins de sécurité,
auquel cas il faudra compter sur des solutions matérielles maintenant
disponibles pour réaliser des fonctions de chiffrement standard comme MD5 ou
AES).

\item Ensuite, le fait que ce soit domotique implique certaines hypothèses
en terme d'infrastructure réseau: cela se passe au sein du domicile, ou d'un
bâtiment plus ou moins grand.  À ce titre le réseau est généralement composé
d'un seul LAN (Local Area Network), éventuellement deux ou trois mais
interconnectés par des routes directes, donc un routage simple, voir pas de
routage du tout.  De plus, cela permet de quelques hypothèses sur le taux de
perte: généralement très faible sur des réseaux locaux Ethernet ou Wifi (les
collisions étant gérées par la couche liaison elle-même).  On peut également
présupposer que les équipements sont sur un réseau privé, non exposés sur
Internet.  Si certains usages peuvent requérir des accès extérieurs (e.g. 
journaliser des données du domicile dans une base de donnée sur Internet, ou
permettre à l'utilisateur de piloter son domicile depuis l'extérieur), on
considère que ce type de communication là doit utiliser un autre canal
réseau que le réseau domotique décrit ici et basculer sur un autre protocole
réseau spécifique à l'application (dans les exemples précités: REST, HTTP,
...).  Cette hypothèse de travail permet de simplifier les aspects de
sécurité et de montée en charge au sein de notre protocole réseau domotique.

\end{itemize}


\subsection{Positionnement et motivation}
Dans le monde des protocoles domotiques sur IP il existe déjà un certain
nombre de choses.
\begin{itemize}
\item UPnP: conceptuellement très intéressant. Différents profils
  (multimédia, routeur, domotiques, etc.). Des schémas XML de description. De
  l'introspection. De la découverte automatique. On peut également annoncer
  son IHM, etc. Bref, hyper générique... un peu trop justement. Trop souple
  (il faut parser les schémas annoncés par un device pour découvrir l'url
  sur laquelle on peu interagir avec lui). Parfois c'est l'ihm qui englobe
  la partie commande (i.e. dans l'ihm annoncé par le device, il faut
  récupérer le plugin pour son InternetExplorer pour commander le
  device!). Même pour des fonctionnements simple, on a du XML à
  parser... Trop lourd (pensez: un thermomètre !)
\item xAP: un protocole plus bas niveau. Malheureusement c'est du broadcast
  (ça n'existe plus en IPv6). Les implémentations collent des "hub" partout
  car les gars ont visiblement appris le réseau sur du .Net et n'ont pas vu
  l'option de socket SO\_REUSEADDR (alors que ça existe tout de même sous
  Windows). Le gros problème étant qu'il n'y a pas de découverte. Le
  mécanisme d'adressage est compliqué: il englobe l'identifiant du device,
  son type de schéma, et l'id de sa gateway: résultat, on utilise beaucoup
  le "*"... Le choix d'un format textuel est également critiquable (l'éternel
  problème en informatique des chaînes de longueur non prédictible) (AMHA).
\item xPL: un fork de xAP... mais en pire...
\end{itemize}


\begin{figure}
\centering
\includegraphics[width=0.6\linewidth]{standards}
\caption{How standards proliferate \url{http://xkcd.com/927/}}
\end{figure}


\nocite{*}
\printbibliography

\end{document}
