Cahier des Charges IOT

Nom du projet : OpenDomos

Zebidi Florian
Università di Corsica Pasquale Paoli
2015/2016
Table des matières
Présentation du projet.................................................................................................................................3
Contexte..................................................................................................................................................3
Objectifs.................................................................................................................................................3
L’existant................................................................................................................................................3
Le périmètre...........................................................................................................................................4
Expression des besoins...............................................................................................................................5
Besoins fonctionnels...............................................................................................................................5
Interface WEB et Application Mobile................................................................................................5
Box......................................................................................................................................................6
Périphérique........................................................................................................................................6
Besoins non fonctionnels........................................................................................................................7
Diagrammes UML..................................................................................................................................8
Use Cases............................................................................................................................................8
Description de l’architecture..................................................................................................................9
Architecture de la base de donnée........................................................................................................10
Analyse de la complexité......................................................................................................................11
Contraintes...............................................................................................................................................12
Coûts.....................................................................................................................................................12
Délais....................................................................................................................................................12
Autres...................................................................................................................................................12
Déroulement du projet.............................................................................................................................13
Planification..........................................................................................................................................13
Plan de V&V prévu..............................................................................................................................13
Documentation.....................................................................................................................................13

2/13 - Cahier des Charges IOT - Zebidi Florian

Présentation du projet
Nom : OpenDomos

Contexte
En France, le marché encore balbutiant de la domotique est dominé par quelques solutions propriétaires
onéreuses et peu évolutives qui se retrouvent obsolètes à court terme du fait de l'évolution rapide de la
technologie.
Prenons un exemple factuel avec l'offre domotique de SFR (HOME by SFR) :
Chez SFR, des lampes et des prises commandées sont proposées ainsi que quelques capteurs de
température et de fumée. Tous estampillés SFR et gérés via une Box SFR. Les problèmes commencent
lorsque l'utilisateur veut étoffer son parc d'objets connectés : Il sera contraint d'acheter ce que SFR
propose car leur service est incompatible avec les solutions tierces, quand bien même elles reposeraient
sur la même technologie de communication. Les protocoles sont privateurs.
Historiquement sur le territoire français c'est la solution KNX qui est majoritaire, elle propose des
réseaux câblés et sans fils de bonne qualité et durables mais est cependant très chère et verrouillée, il
faut par exemple solliciter l'intervention d'un technicien KNX pour l'installation ou l'évolution d'un
réseau domotique.

Objectifs
Une plate-forme domotique ouverte et modulable aurait d'indéniables avantages sur les produits
concurrents, elle permettrait de contrôler depuis une seule et même interface un ensemble hétérogène
d'objets connectés. Son ouverture garantissant des possibilités d'évolution, elle n'enfermera pas le client
dans un cercle vicieux d'achat forcé. Il est par ailleurs primordiale de la rendre interopérable avec les
normes et standards existants (sans oublier les standards de fait).
La plate-forme domotique que nous envisageons sera constituée d'une interface logiciel libre ainsi que
d'au moins un périphérique ouvert (c'est à dire un objet connecté dont le code source et le schéma de
montage seront libres).
Par ailleurs, nous nous concentrerons sur les technologies sans fils.

L’existant
De nombreux objets connectés existent déjà, il en va de même pour les protocoles de communication et
pour les interfaces logiciels. Ne ressentant pas le besoin de réinventer la roue nous nous appuierons sur
l'existant.
Une quirielle de sociétés produisent et vendent à très bas prix des prises et des lampes télécommandées
utilisant différentes technologies et protocoles. En Europe, la majorité de ces sociétés utilisent des
transmissions AM en 433 MHz. De nombreux systèmes tels que les portails et les volets roulants
utilisent cette fréquence. La communication en 433 MHz est aisée et ne posera vraisemblablement
aucun problème, ce sont les protocoles utilisés qui causeront le plus de difficultés.

3/13 - Cahier des Charges IOT - Zebidi Florian

Le plus efficace sera d'intercepter les signaux des commandes de ces appareils et de les reproduire.
La technologie Z-Wave est ou sera un des piliers de la domotique, Z-Wave fonctionne en utilisant une
technologie radio dans la bande de fréquence de 868 MHz et est de plus conçue pour les applications de
domotique.
Pour ce qui est des interfaces logiciels il y en a beaucoup, la plus intéressante est Domoticz.

Le périmètre
La domotique a certes pour cible tous les foyers et bâtiments mais pour des raisons de normes de
communication nous devront nous limiter, au moins dans un premier temps, à l'Europe. En effet
l'utilisation public des fréquences de 433 MHz et 868 MHz est permise en Europe mais ce n'est pas
forcément le cas ailleurs, aux États Unis par exemple on préférera les fréquences dans la bande des 315
Mhz en lieux et place du 433 MHz.
Il n'existe pas d'autres contraintes qui pourraient empêcher ce produit de toucher l'ensemble du marché
Européen.

4/13 - Cahier des Charges IOT - Zebidi Florian

Expression des besoins
Nous aurons besoin d'une application WEB et d'une application mobile (Android et ou iOS) qui
s’interfaceront avec un centre de contrôle pour piloter les périphériques pris en charge. Un périphérique
sera aussi développé pour les démonstrations : une simple prise commandée.

Besoins fonctionnels
Interface WEB et Application Mobile

Fonction Identification à l'interface de contrôle

Objectif Identifier le propriétaire du parc
L'identification sera possible en renseignant les champs :
Description Username et Password sur l'accueil de l'interface
La session doit être révoquée automatiquement au bout d'un
certain temps (1 heure par exemple), un utilisateur non
Contraintes / règles de gestion connecté ne doit pas pouvoir accéder aux fonction de gestion
Niveau de priorité faible

Fonction Ajout / Suppression / Modification d'un périphérique

Ajouter / supprimer / modifier facilement un périphérique dans
Objectif la base de donnée via une interface simple.
L'ajout d'un périphérique nécessite de renseigner son nom, son
Description type et le protocole utilisé
Il ne peut exister plusieurs périphériques du même nom, ou
Contraintes / règles de gestion ayant les mêmes codes
Niveau de priorité Haut

Fonction Contrôle des périphériques

Objectif Contrôler l'état des périphériques enregistrés
Une interface simple permettra de contrôler l'état des
Description périphériques et de les visualiser
Contraintes / règles de gestion
Niveau de priorité Haut

5/13 - Cahier des Charges IOT - Zebidi Florian

Box

Fonction Émettre et recevoir des donnée en 433MHz

Envoyer des ordres aux périphériques et recevoir des
Objectif réponses si possible
Un ordre en provenance de l'interface WEB ou de l'application
mobile doit pouvoir être transmit à des périphérique en
Description commandés par radio-fréquence en 433MHz
Contraintes / règles de gestion Un seul ordre en RF peut être envoyé à la fois
Niveau de priorité Haut

Périphérique
Fonction Contrôler l'état d'un relais
Objectif Fermer ou ouvrir un relais
Description Commander l'état d'un relais 230V alternatif
Contraintes / règles de gestion
Niveau de priorité Haut

Fonction Recevoir des ordres

Objectif Recevoir un ordre via la liaison RF 433
Description Recevoir un ordre la box en 433MHz et l'appliquer
Contraintes / règles de gestion
Niveau de priorité Haut

Fonction Émettre et recevoir des donnée en 433MHz

Envoyer des ordres aux périphériques et recevoir des
Objectif réponses si possible
Le périphérique communiquera via un émetteur et un récepteur
Description 433MHz avec la box.
Contraintes / règles de gestion Une seule donnée RF peut être envoyée à la fois
Niveau de priorité Haut

6/13 - Cahier des Charges IOT - Zebidi Florian

Besoins non fonctionnels
Cette section regroupe les besoins non essentiels au produit finit.

Fonction Prise en charge de périphériques existants en 433MHz

Objectif Permettre l'ajout et le contrôle d'un objet tierce
Description Être compatible avec une solution d'objets connectés tierce
Contraintes / règles de gestion Pouvoir s'interfacer avec un protocole différent
Niveau de priorité modéré

Fonction Prise en charge de périphériques existants en Z-Wave

Objectif Permettre l'ajout et le contrôle d'un objet tierce

Description Être compatible avec une solution d'objets connectés tierce

Pouvoir s'interfacer avec un objet connecté utilisant la norme Z-
Contraintes / règles de gestion Wave
Niveau de priorité faible

Fonction Scanner des codes de périphériques

Permettre de visualiser les émissions d'un périphérique pour
Objectif l'ajouter à la base

Il faut pouvoir récupérer les codes de contrôle d'un nouveau

Description périphérique dans le but de les ajouter à la base
Contraintes / règles de gestion Doit être en temps réel
Niveau de priorité Haut

7/13 - Cahier des Charges IOT - Zebidi Florian

Diagrammes UML
Use Cases

Figure 1 : Uses Case de l'interface utilisateur (application WEB et Android)

Figure 1 : Use Case d'un périphérique

8/13 - Cahier des Charges IOT - Zebidi Florian

Description de l’architecture
La « Box » est le centre névralgique du système et contient un serveur WEB, une base de donnée et un
serveur RF. Un utilisateur peut via l'interface WEB ou mobile donner des ordres et gérer des
périphériques, l'applicatif du serveur WEB modifiera des données dans la base et le serveur RF
répercutera ces modifications sur les périphériques concernés.
Le serveur RF appliquera simplement une routine toutes les minutes qui enverra à chaque périphérique
l'état qui est le sien dans la base, cela palliera aux possibles problèmes de réception.

Figure 2 : Schéma de l'architecture

Dans le cas du scanne de code de périphériques, une connexion directe est établie entre l'interface et le
scanner RF au moyen d'un websocket, cela permettra d'afficher en temps réel (ou plutôt avec un
décalage négligeable) les codes en 433 MHz reçus par le scanner.

9/13 - Cahier des Charges IOT - Zebidi Florian

Architecture de la base de donnée
La base de donnée se devra d'être aussi générique que possible. En effet, bien que le premier but de ce
projet soit de contrôler des prises commandées, il faut par la suite pouvoir étendre le champs des
possibilités. En Orienté Objet pour avoir une liste d'objets hétéroclites on utilise le polymorphisme, en
relationnel on pourra avoir recourt au méta modèle.
Ci-dessous le MLDR et le MDC de la base telle qu'attendue :

Device (ID_DEVICE, Name, Description)

Auth (ID_USER, User, Hash, Permission)
Attribut (ID_Attribut, Valeur, #ID_DEVICE)

Figure 3 : MDC

La méta-modélisation nous permet de définir les attributs d'une table de manière dynamique, ainsi on
peut modifier la table à l'envie.
Ceci nous permettra d'avoir pour deux Devices donnés des attributs très différents : les codes de mise
en fonctionnement et d'extinction d'un interrupteur par exemple ou bien par la suite des informations
d'identifications pour un périphérique domotique en wifi.

10/13 - Cahier des Charges IOT - Zebidi Florian

 Analyse de la complexité

ID Label Descriptif Complex ité

La BOX utilise un Raspberry PI 2 et un émetteur et un récepteur
RF 433 MHz ; le périphérique présenté utilisera un Atmega
328PU, un émetteur et un récepteur RF, un relais 230VAC et un
1 Éléments
Mode de convertisseur 5VDC 3
communication La BOX communiquera avec les périphériques par commandes
2 M2M par radio-fréquence dans la bande AM (433 MHz) 6
Le scanner de codes de commande fonctionne en utilisant un
Utilisation de websocket pour communiquer directement des données de la
3 Web Service BOX à l'interface. 3

Développement
d’une application Application pour piloter, paramétrer le système, et/ou visualiser
4 mobile (IHM) les données 7
Développement
d’un site web Site pour piloter, paramétrer le système, et/ou visualiser les
5 (IHM) données 6
Base de
6 données Création et utilisation d’une base de données (SQL) 2
13 Qualité du code Commentaire, test, etc. 3
14 Documentation Qualité, Clarté, Utilisation de diagrammes, etc. 3

15 Etude de marché Positionnement par rapport au marché (veille technologique) 2

Choix
16 technologiques Choix expliqués dans les parties Contexte et Objectif 7

Optimisation des
18 éléments choisis La BOX et le device de test sont réduits au strict minimum 5

11/13 - Cahier des Charges IOT - Zebidi Florian

Contraintes
Coûts
Le coût total du projet devra être relativement contenu, pas plus de 100 euros pour le centre de contrôle
et moins de 20 euros pour la prise commandée.

Délais
Le projet devra être livré avant le 10 décembre.

Autres
Les normes européennes nous permettent d'utiliser des communications en 433 MHz pour un usage
civile, la LPD433 stipule que les appareils de faible puissance à usage libre dans la bande 433 MHz ne
nécessitent pas l'acquisition d'une licence si ils ne dépassent pas 10mW de puissance dissipé pendant
l’émission.

12/13 - Cahier des Charges IOT - Zebidi Florian

Déroulement du projet
Planification

Figure 4 : Diagramme de Gantt

Ci-dessus le diagramme de Gantt du projet, seuls les jours de week-end sont travaillés. Deux phases de
conceptions sont nécessaires avant d'attaquer le cœur de la réalisation, la conception du centre de
contrôle qui commande les objets connectés et la conception de la prise commandée.
En commençant Jeudi 12 Novembre et en en travaillant que les week-end la fin du projet est estimée
pour le 29 Novembre.

Plan de V&V prévu

Du point de vue matériel, des tests seront effectué pour assurer le fonctionnement des montages. Des
tests unitaires aussi seront fournis pour le code.

Documentation
Un rapport de projet ainsi qu'une présentation orale seront livrés, une documentation utilisateur et une
documentation du code commenté seront aussi fournies.

13/13 - Cahier des Charges IOT - Zebidi Florian