2. AGENDA
• Introduction
• Partie 1 : le projet « Personal Home
Safety Agent »
• Pause
• Partie 2 : bâtissons ensemble un nouveau
projet …
www.hackster.io/ThereIsNoTry/personal-
home-safety-agent-2068ea
7. ARCHITECTURE DU SYSTEME
Hardware (sensors, actuators,
micro-controlleurs, ..)
Logique de gestion locale
D
E
V
I
C
E
Équipements de réseau (incluant
un éventuel gateway)
Logique de communication,
routage, securité, ..
I
N
F
R
A
Hosting
Logique globale, sécurité, front-
end
C
L
O
U
D
Mon code se
trouve ICI
8. COMMENT CA MARCHE ?
• 1) Eau détectée !
• 2) Décision de fermer la vanne
• 3) Ordre de fermeture
• 4) Configuration de l’alimentation
(FW vs RW)
• 5) Démarrage du moteur
• 6) Fin de course. Arrêt alimentation
• 7) Fin de course – Notification
• 8) Décision d’envoi de SMS
• 9) Appel vers TWILIO
9. COMMENT DÉVELOPPER AVEC WINDOWS 10 SUR
RASPBERRY PI
1. acheter un Raspberry PI 2, un breadboard, etc
2. setup de votre PC (VS 2015, ..)
3. Loader la micro-SD avec Windows10 Iot Core
4. Créer un projet (avec le bon template !)
https://ms-iot.github.io/content/en-US/GetStarted.htm
http://www.canakit.com/raspberry-pi-starter-ultimate-kit.html
https://www.raspberrypi.org/blog/windows-10-core-iot-starter-pack/
https://abra-electronics.com/?sl=en ( Montreal)
12. PARTIE 2 : A VOUS DE JOUER !
• Mise en contexte: bien comprendre les requis
• Envisager des solutions
• Le point sur les technologies existantes
• Architecture HW visée
• La suite….
13. LE PROBLEME TEL QUE FORMULÉ PAR LE CLIENT
• Mr F. Horklift est le gestionnaire d’un entrepot de plus de 150.000 pi2 dans
lequel évoluent chaque jour une flotte de chariots-élévateurs.
• Il devient de plus en plus difficile de bien entretenir la flotte, par manque de
données fiables sur les déplacements et il arrive même parfois qu’un chariot
soit temporairement perdu dans l’entrepot
• Il voudrait pouvoir viusaliser en temps réel la position des chariots dans
l’entrepot et aussi accumuler des données en vue d’optimizer la maintenance
14. LE PROBLEME.. EN TERME DE CAS D’USAGE
• En tant que gestionnaire, je veux…
• Visualiser la position des chariots élévateurs sur ma tablette, sur une carte représentant
l’entrepot
• Visualiser leurs mouvements sur la carte
• Visualiser les données historiques (temps, distance, efforts cumulés, chocs, âge de la
batterie)
• Me faire suggérer des actions de maintenances préventives (sur base d’une formule
standardisée dans cette industrie)
Notes:
- l’hiver, je vis en Floride mais je voudrais accéder aux mêmes vues
- Des routeurs Wi-Fi ont été installés un peu partout dans l’entrepôt
18. LES INFRASTRUCTURES SANS-FIL
Wireless Technology Range
Dedicated
Infrastructure
Power Consumption Disadvantages
FM 100 km No low
signal changes little in
small distance
GSM/CDMA 100 m ~ 10 km No Unknown Highly patented
WiFi 35 m (indoor) No (for most places) high high variance signal
ZigBee 30 ~ 60 m Yes low
Need dedicated
infrastructure
Bluetooth 10 m Yes low Cover range is limited
UWB few meters Yes low Cover range is limited
RFID 1m Yes low Cover range is limited
http://www.cse.wustl.edu/~jain/cse574-14/ftp/indoor/
21. POURQUOI UN “GATEWAY” ?
• Régler localement des problèmes locaux (i.e la
position des chariots sur une carte), c'est plus simple et
performant
• Pour l'instant, les données récoltées sont en lecture
seule mais on pourrait modifier la configuration des
chariots élévateurs dans un développement futur.
• C'est moins risqué d'exposer un seul point d'entrée, on
peut le protéger davantage (et couper le lien en cas
de problème)
• Par contre,.... on a un "single point of failure" avec le
Raspberry mais c est tout aussi vrai si on fait le
traitement dans le Cloud
22. POURQUOI MQTT (LOCALEMENT) ?
• On a une connectivité Wi-Fi (qu'on veut mesurer), on peut donc l'utiliser aussi pour
communiquer
• On veut que ce soit le moins énergivore possible pour le device qui se trouve sur le
chariot élévateur
• Une logique "Publier/Souscrire" est plus simple que "Appeler/Attendre réponse"
(HTTP) pour nos besoins. On a pas besoin d'une garantie de livraison pour chaque
message
• Il reste donc 2 possibilités (au minimum) : MQTT et CoAP (Constrained Application
Protocol ). MQTT est plus mature et il existe une librairie pour notre Particule Photon
23. POURQUOI AMQP (VS HTTP) ENTRE LE RASPI ET
AZURE ?
• Parce que c’est un standard multi-plateforme
• Parce que c est conçu pour du « queuing »
• Parce que je connais pas (encore) AMQP
• Parce qu’il y a un code sample dans le SDK Azure IoT
• MAIS le port 5672 doit être ouvert….
http://www.slideshare.net/paolopat/mqtt-iot-protocols-comparison