air - User contributions [en]

File:RICM5 2017 2018 RMontagne Flyer.pdf

2018-03-15T08:44:06Z

Hugo.Amodru-Favin:

File:RICM5 2017 2018 RMontagne.pdf

2018-03-15T06:27:46Z

Hugo.Amodru-Favin:

Projets 2017-2018

2018-03-15T06:27:18Z

Hugo.Amodru-Favin: /* Affectations */

<<[[Projets 2016-2017]] | [[Projets]] | [[Projets 2018-2019]]>>
=RICM=
==RICM3==

==RICM4==
===Projet Semestre S8===

Enseignants responsables : Olivier Richard, Didier Donsez

* Dates : Lundi après-midi, Mardi après-midi
* Lancement: 15/01/2018 en 257 à 15h45
* Soutenance: A définir
* Soutenance à mi-parcours: Lundi 12 et mardi 13 mars: [[ordre_passages_mi_parcours_RICM4_2017_2018 | Ordre de passages]]

* '''Evaluation à mi-parcours le lundi/mardi ???''': Format: 10min (5min de présentation 3 slides au plus, 5min de discussion). Cette évaluation sera prise en compte dans la note finale.

'''Consignes générales:'''

* '''Vous devez être pro-actifs !!!''': Si des points sont pas ou mals spécifiés, vous le faîtes et vous justifiez vos choix. Pour les problèmes techniques éventuels vous pouvez: creuser la question, contacter l'auteur du code si il y a lieu, écrire un rapport de bug ('''Attention:''' ca se prépare !), soumettre un patch/pull request, contacter l'enseignant ou la personne référente du projet.

* '''Vous devez maintenir une fiche de suivi de projet''': elle doit être mise à jour chaque semaine, elle rassemble les élements essentiels du projet, elle indique les évolutions du projet et présente sa feuille de route. '''Note:''' le nom de la fiche doit être composé du nom du projet et suffixé par ricm4_2017_2018. '''Cette fiche compte pour la note finale'''

* '''Votre code''' pour doit être hébergé sur le gitlab et à l'URL suivante https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18 , vous utiliserez votre compte UGA.

* Les documents public doivent être rédigés en anglais (README, documentation, commentaires de code, nom de variables et de fonctions). Une bonnification sera accordée si le rapport et les transparents sont en anglais (la soutenance sera en francais).

'''Propositions de projets:'''

# [[QCM C2I]] , Pierre Gillois, Didier Donsez
# [[Dashboard pour gestionnaire de tâches]] (Angular 5): Olivier Richard
# [[Moteur de workflows distribué]] (WDL/Cromwell): Olivier Richard
# [[ESP32 et language D]]: Olivier Richard
# [[Serious game multi-joueurs pour tables tactiles en réseau]] : Didier Donsez, Anne-Laure Finkel, Stéphanie Diligent.
# [[Challenge OpenCity]] : Georges-Pierre Bonneau, Didier Donsez
# Projet [[UltraTeam]] avec des trackers [[ESP32-LoRa]] + GPS : Reprise partielle du projet eCOM de gestion des courses sportives et du projet [[UltraTeam]] 2017 pour la partie backend et frontend du projet : Didier Donsez
# Projet [[Réseau Social LoRa]] avec des pods [[ESP32-LoRa]] : Olivier Richard.
# Contribution et evaluation au/du projet [https://github.com/IntelLabs/hpat HPAT] (A compiler-based big data framework in Python): Olivier Richard.
# [[Ruche connectée LoRa]] : Nicolas Palix
# [[Serres connectées]] : Nicolas Palix
# [[I-Greenhouse]] : [[Serre connectée aquaponie]] : Nicolas Palix
# Projet "Plateforme de mise en relation pour les entrepreneurs sociaux" : Didier Donsez
# [[Chatbot pour borne d'accueil handicap]] : Didier Donsez, Marie-Paule Balicco et Jérôme Maisonnasse (service accueil handicap COMUE UGA)
# Connected Shop (avec [[Eclipse SmartHome]]) : Didier Donsez.
# [[Deploiment Nucleo | Déploiement sécurisé et sans fil pour carte Nucleo]]: Olivier Richard et Sylain Toru
# [[RobAIR]] : Cobot Majordome : Jérôme Maisonnasse, Germain Lemasson, Bastien Scher (FabMSTIC).

==== Affectations ====
{|class="wikitable alternance"
|+ Affectation des projets RICM4 2017-2018
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Enseignant(s)
!scope="col"| Fiche de suivi
!scope="col"| Dépot git
|-

!scope="row"| 1
| [[QCM C2I]]
| NON ATTRIBUÉ
| Pierre Gillois, Didier Donsez
| [[RICM4_2017_2018_-_| Fiche]] - [[RICM4_2017_2018_-_/_SRS|SRS]] - [[RICM4_2017_2018_-_/UML | UML]]
|
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 2
| [[Dashboard pour gestionnaire de tâches]] (Angular 5)
| BELGUENDOUZ Sekina, LARNICOL Titouan
| Olivier Richard
| [[RICM4_2017_2018_-_Dashboard| Fiche]] - [[RICM4_2017_2018_-_Dashboard/SRS|SRS]] - [[RICM4_2017_2018_-_Dashboard/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/2 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Dashboard_en.pdf|Presentation de mi-parcours en anglais]] - [[Media:Dashboard_fr.pdf|Presentation de mi-parcours en français]] - [[Media:Dashboard_fr.pptx|Presentation de mi-parcours en pptx]]
|-

!scope="row"| 3
| [[Moteur de workflows distribué]] (WDL/Cromwell)
| NON ATTRIBUÉ
| Olivier Richard
| [[RICM4_2017_2018_-_| Fiche]] - [[RICM4_2017_2018_-_/_SRS|SRS]] - [[RICM4_2017_2018_-_/UML | UML]]
|
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 4
| [[ESP32 et language D]]
| MANGER Raphael, HOUBRON Adrian
| Olivier Richard
| [[RICM4_2017_2018_-_ESP32_D| Fiche]] - [[RICM4_2017_2018_-_ESP32_D/_SRS|SRS]] - [[RICM4_2017_2018_-_ESP32_D/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/4 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 5
| [[Serious game multi-joueurs pour tables tactiles en réseau]]
| LEPAGE Tim, SERGEANT Dimitri
| Didier Donsez, Anne-Laure Finkel, Stéphanie Diligent
| [[RICM4_2017_2018_-SeriousGame Polystar | Fiche]] - [[RICM4_2017_2018_- SeriousGame Polystar /_SRS|SRS]] - [[RICM4_2017_2018_- SeriousGame Polystar /UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/5 gitlab]
| [[Media:xxx_.pdf|Rapport final]] - [[Media:xxx_.pdf|Presentation finale FR]] - [[Media:xxx_.pdf|Final Presentation EN]] - [[Media:xxx_.pdf|Flyer]] - [[Media:PolyStar.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 6
| [[Challenge OpenCity]]
| BOUCHERIMA Amina, FOMBARON Quentin
| Georges-Pierre Bonneau, Didier Donsez
| [[RICM4_2017_2018_-_OpenCity| Fiche]] - [[RICM4_2017_2018_-_OpenCity/_SRS|SRS]] - [[RICM4_2017_2018_-_OpenCity/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/6 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 7.1
| Projet [[UltraTeam]] avec des trackers [[ESP32-LoRa]] + GPS
| TERRIER Bastien, GROS-DAILLON Hugo
| Didier Donsez
| [[RICM4_2017_2018_-_UltraTeam_7.1| Fiche]] - [[RICM4_2017_2018_-_UltraTeam_7.1/_SRS|SRS]] - [[RICM4_2017_2018_-_UltraTeam_7.1/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/7.1 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:UltraTeam 7.1 Mid Presentation.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 7.2
| Projet [[UltraTeam]] avec des trackers [[ESP32-LoRa]] + GPS
| MOLION Enzo, VALETTE Léo
| Didier Donsez
| [[RICM4_2017_2018_-_UltraTeamMV| Fiche]] - [[RICM4_2017_2018_-_UltraTeamMV_:_SRS|SRS]] - [[RICM4_2017_2018_-_UltraTeamMV_:_UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/7.2 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 8
| Projet [[Réseau Social LoRa]] avec des pods [[ESP32-LoRa]]
| VEGREVILLE Thibaud, GENTILLON Loris, ZHENG Jian
| Olivier Richard
| [[RICM4_2017_2018_-_Réseau_Social_LoRa| Fiche]] - [[RICM4_2017_2018_-_Réseau_Social_LoRa/_SRS|SRS]] - [[RICM4_2017_2018_-_Réseau_Social_LoRa/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/8 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 9
| Contribution et evaluation au/du projet [https://github.com/IntelLabs/hpat HPAT]
| NON ATTRIBUÉ
| Olivier Richard
| [[RICM4_2017_2018_-_| Fiche]] - [[RICM4_2017_2018_-_/_SRS|SRS]] - [[RICM4_2017_2018_-_/UML | UML]]
|
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 10
| [[Ruche connectée LoRa]]
| BESNIER Benjamin, LÉVESQUE Théo, WEILL William
| Nicolas Palix
| [[RICM4_2017_2018_-_Ruche_Connectee_| Fiche]] - [[RICM4_2017_2018_-_Ruche_Connectee_/_SRS|SRS]] - [[RICM4_2017_2018_-_Ruche_Connectee/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/10 gitlab]
| [[RICM4_2017_2018_|Rapport final]] - [[RICM4_2017_2018_|Presentation finale FR]] - [[RICM4_2017_2018_|Final Presentation EN]] - [[RICM4_2017_2018_|Flyer]] - [[RICM4_2017_2018_|Presentation de mi-parcours]]
|-

!scope="row"| 11
| [[Serres connectées]]
| BESNARD Guillaume, DEPRIESTER Timothée
| Nicolas Palix
| [[RICM4_2017_2018_-_Serre_Connectee| Fiche]] - [[RICM4_2017_2018_-_Serre_Connectee_/_SRS|SRS]] - [[RICM4_2017_2018_-_Serre_Connecte/UML | UML]] - [[RICM4_2017_2018_-_Serre_Connecte/Schedule | Schedule]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/11 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]] - [[Media:RICM4_2017_2018_-_Serre_Connecte_Poster.pdf|Poster]]
|-

!scope="row"| 12
| [[I-Greenhouse]] : [[Serre connectée aquaponie]]
| SURIER GAROFALO Aurélien, FERREIRA Joffrey, OZENDA Thomas
| Nicolas Palix
| [[RICM4_2017_2018_-_IGreenHouse| Fiche]] - [[RICM4_2017_2018_-_IGreenHouse_/_SRS|SRS]] - [[IGreenHouse/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/12 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 13
| Projet "Plateforme de mise en relation pour les entrepreneurs sociaux"
| AUBERT Vincent, COURTIAL Julien
| Didier Donsez
| [[RICM4_2017_2018_-_Entrepreneur| Fiche]] - [[RICM4_2017_2018_-_Entrepreneur_AUBERT_COURTIAL/_SRS|SRS]] - [[RICM4_2017_2018_-_/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/13 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 14
| [[Chatbot pour borne d'accueil handicap]]
| AUCLAIR-CORDAT Julien, BAMBA Samuel
| Didier Donsez, Marie-Paule Balicco et Jérôme Maisonnasse (service accueil handicap COMUE UGA)
| [[RICM4_2017_2018_-_| Fiche]] - [[RICM4_2017_2018_-_/_SRS|SRS]] - [[RICM4_2017_2018_-_/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/14 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 15
| Connected Shop (avec [[Eclipse SmartHome]])
| CUZIN Florian, ECHEVET Théo
| Didier Donsez
| [[RICM4_2017_2018_-_| Fiche]] - [[RICM4_2017_2018_-_/_SRS|SRS]] - [[RICM4_2017_2018_-_/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/15 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 16
| [[Deploiment Nucleo | Déploiement sécurisé et sans fil pour carte Nucleo]]
| CHANET Zoran, CHARLOT Servan
| Olivier Richard, Sylain Toru
| [[RICM4_2017_2018_-_Nucleo | Fiche]] - [[RICM4_2017_2018_-_Nucleo/_SRS|SRS]] - [[RICM4_2017_2018_-_Nucleo/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/16 gitlab]
| [[RICM4_2017_2018_|Rapport final]] - [[RICM4_2017_2018_|Presentation finale FR]] - [[RICM4_2017_2018_|Final Presentation EN]] - [[RICM4_2017_2018_|Flyer]] - [[Media:Projet_Nucleo_diapo_mi_parcours.pdf‎|Presentation de mi-parcours]]
|-

!scope="row"| 17.1
| [[RobAIR]] : Robot Majordome
| DEVOS Xavier, LAFRASSE Cédric
| Jérôme Maisonnasse, Germain Lemasson, Bastien Scher (FabMSTIC)
| [[RICM4_2017_2018_-_RobAIR17-1| Fiche]] - [[RICM4_2017_2018_-_RobAIRDL/_SRS|SRS]] - [[RICM4_2017_2018_-_RobAIRDL/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/17.1 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 17.2
| [[RobAIR]] : Robot Majordome
| JEAN Jordan, EZ-ZINE Najwa
| Jérôme Maisonnasse, Germain Lemasson, Bastien Scher (FabMSTIC)
| [[RICM4_2017_2018_-_robair2| Fiche]] - [[RICM4_2017_2018_-_robair2/_SRS|SRS]] - [[RICM4_2017_2018_-_robair2/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/17.2 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

|}

==RICM5==
===Projet IoT S9===
Enseignants responsables : Bernard Tourancheau

Calendrier: ??? Septembre à ??? Décembre 2017.

* Projet IoT 3 : [[Ski-locator]] (Bernard Tourancheau)

===Projet Semestre S10===

Enseignants responsables : Didier Donsez

Calendrier: 29 Janvier à 15 Mars 2018.

Séances de Management de projets innovants:
* Mercredi 31/01 de 8h à 12h: Stéphanie Diligent
* Mercredi 7 février de 8h à 12h : Stéphanie Diligent
* Mardi 15 février de 8h à 12 : Emmanuelle Tréhoust
* Lundi 26 février de 8h à 12h : Olivier Gilles
* Mardi 13 mars de 8h à 12h : Stéphanie Diligent et Emmanuelle Tréhoust

Réunion de présentation : 8 Janvier 2018 Matin à 9H00-10H00 (RdV Salle P257 et Salle AIR P259). Faire couler le café.

Hackathon Vinci (8,9,10/02) : http://hacktogether.vinci-energies.com/

Démarrage : Lundi 29 Janvier 2018

Soutenance à mi-parcours : Mercredi 14 Février 2018, 8H00-11H00 (30 minutes par équipe).

Rendu rapport de management : Mardi 13 Mars 2018 - Matin

Soutenance (puis Pot de la fin) : Jeudi 15 Mars 2018

Vendredi 16 Mars : 10000 ans de RICM

==== Planning soutenances mi-parcours ====
Mercredi 14 Février 2018, salle P144, 8H00-11H00 (25 minutes TTC par équipe).

* 8H00-8H30 [[Real Time Subtitles 2017-2018| Real Time Subtitles]]
* 8H30-9H00 [[Deep Learning 2017-2018 | Deep Learning]]
* 9H00-9H30 [[EasyFlight]]
* 9H30-10H00 [[ Réalité virtuelle et Augmentée pour la maintenance d'usines]]
* 10H00-10H30 [[R'Montagne]]
* 10H30-11H00 [[SmartMove]]
* 11H00-11H30 [[RICM5 2017 2018 - UGAChain|UGAChain]]

==== Planning soutenances finales ====
Jeudi 15 Mars 2018
Matin (Salle P251)
* 8H00-9H00 [[R'Montagne]] (50 minutes TTC)
* 9H00-10H00 [[SmartMove]] (50 minutes TTC)
* 10H00-11H00 (50 minutes TTC) [[ Réalité virtuelle et Augmentée pour la maintenance d'usines]]
* 11H00-12H00 (50 minutes TTC) [[RICM5 2017 2018 - UGAChain|UGAChain]] : Blockchain for Education
Pause déjeuner
Matin (Salle P249)
* 13H00-14H00 [[Real Time Subtitles 2017-2018| Real Time Subtitles]] (50 minutes TTC)
* 14H00-15H00 [[SmartRecruiting]] (50 minutes TTC)
* 15H00-16H00 [[EasyFlight]] (50 minutes TTC)

====Instructions pour la soutenance====
* Chaque soutenance comporte 20 minutes de présentation, 10 minutes de question et 20 minutes de démonstration. Un transparent doit être consacré au travail confié et réalisé par les étudiants en DUT (AVOSTI) pour R'Montagne.
* La présentation est constituée des chapitres suivants:
** Rappel du sujet/besoin et cahier des charges
** Technologies employées
** Architecture techniques
** Réalisations techniques
** Gestion de projet (méthode, planning prévisionnel et effectif, gestion des risques, rôles des membres, ...)
** Outils (collaboration, CD/CI par exemple ...)
** Métriques logiciels : lignes de code, langages, performance, temps ingénieur (d'après vos journaux)...)
** Conclusion (Retour d'expérience)
** Transparent introduisant la démonstration
* Répétez plusieurs fois votre présentation et votre démonstration. Il y aura des personnalités invitées. Prévoyez un démonstration filmée pour palier à l'effet "démo".
* L'ensemble des documents (y compris photos, vidéos et ''[[Logiciels#Screencast|screencast]]s'') doivent être accessibles depuis le tableau ci-dessous et dans chaque fiche de suivi. Prévoyez une copie sur clé USB.
* Les étudiants de DUT vous accompagnent lors de votre soutenance et présenteront leur travail. Coordonnez vous avec eux et faites les répéter.
* '''TOUT Le matériel prêté devra être rapporté et restitué dans un sac cabas lors de la soutenance.'''

==== Affectations ====
{|class="wikitable alternance"
|+ Affectation des projets RICM5 2017-2018
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Enseignant(s)
!scope="col"| Fiche de suivi
!scope="col"| Dépot git
|-

!scope="row"| 1
| [[Real Time Subtitles 2017-2018| Sous-titre d'un cours en temps réel]]
| '''Estelle ALLARD''' / Aymeric BROCHIER / Louis COCHINHO / Oriane DALLE / Alexandre FERRERA / Alice RIVOAL
| Didier Donsez, Laurent Besacier, François Portet, Marie-Paule Balicco, Jérome Maisonnasse
| [[Real Time Subtitles 2017-2018| Fiche]] - [[Real_Time_Subtitles_2017-2018/SRS|SRS]]
| [https://gitlab.com/LouisCochinho/RealTimeSubtitles GitLab]
| [[Media:RICM5_2017_2018_Real_time_subtitles_rapport.pdf|Rapport final]] - [[Media:RICM5_2017_2018_Real_time_subtitles_slides.pdf|Presentation finale]] - [[Media:RICM5_2017_2018_Real_time_subtitles_mi.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 2
| [[Réalité Augmentée pour le Smart Campus 2018|Réalité Augmentée pour le Smart Campus]]
| Lucas LESAGE / '''Denis LACHARTRE''' / Douria ZENNOUCHE / Gilles BONHOURE / Maxime DEREYMEZ
| Didier Donsez, Georges-Pierre Bonneau
| [[Campus_Augmente_2017-2018|Fiche]] - [[Media:SRS_ProjetAR_2018.pdf|SRS]]
| [https://github.com/ProjetS10-CyberHoloMachin Organisation Git]
| [[Media:RICM5_2017_2018_XYZ.pdf|Rapport final]] - [[Media:RICM5_2017_2018_XYZ.pdf|Presentation finale ]] -[[Media : Cyberposter_ProjetAR_2018.pdf | Poster]] - [[Media:Rapport_final_MPI_ProjetAR_2018.pdf‎ | Rapport final MPI ]] - [[Media:Presentation_Mi_parcours_ProjetAR_2018.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 3
| SmartRecruiting : [[SmartRecruiting|Deep Learning]] avec [[TensorFlow]] sur les référentiels de compétence
| Héloise FERNANDES DE ALMEIDA / '''Romane GALLIER''' / Alicia AUBERTIN / Antoine GAMBRO / Qianqian FU
| Didier Donsez
| [[SmartRecruiting| Fiche]] - [[SmartRecruiting/SRS|SRS]]
| [https://github.com/Projet-DeepLearning-RICM5-2018 Organisation Git]
| [[Media:RICM5_2017_2018_XYZ.pdf|Rapport final]] - [[Media:RICM5_2017_2018_XYZ.pdf|Presentation finale]] - [[Media:RICM5_2017_2018_DeepLearning_mi-parcours.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 4
| [[RICM5 2017 2018 - UGAChain|UGAChain]] : Blockchain for Education
| Charles MARCHAND / '''Antoine BOISADAM''' / Ahmed NASSIK / Simon CHAMBONNET / Lucas GUERRY / Aymeric VIAL-GRELIER
| Didier Donsez & co
| style="white-space: nowrap;"|[[RICM5 2017 2018 - UGAChain| Fiche]] - [[RICM5 2017 2018 - UGAChain /_SRS|SRS]]
| [https://github.com/RICM5-BlockChain Github]
| [[Media:RICM5_2017_2018_UGAChain.pdf|Rapport final]] - [[Media:RICM5_2017_2018_UGAChain.pdf|Présentation finale]] - [[Media:RICM5_2017_2018_UGAChain-Flyer.pdf|Flyer]] - [[Media:RICM5_2017_2018_UGAChain_-_Soutenance_mi-parcours.pdf|Présentation de mi-parcours]]
|-

!scope="row"| 5
| [[R'Montagne]]
| '''Hugo AMODRU-FAVIN''' / Antoine DELISE / Gwenaël MOREAU
| Bernard Tourancheau
| [[R'Montagne| Fiche]] - [[RICM5_2017_2018_-_RMontagne_/_SRS|SRS]]
| [https://github.com/delisea/R-Montagne Github]
| [[Media:RICM5_2017_2018_XYZ.pdf|Rapport final]] - [[Media:RICM5_2017_2018_RMontagne.pdf|Presentation finale ]] - [[Media:RICM5_2017_2018_XYZ.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 6
| [[SmartMove]]
| '''Anthony GEOURJON''' / Timothée LEMAIRE / Clément ROUQUIER / Vincent TURRIN
| Bernard Tourancheau
| [[RICM5_2017-2018 - SmartMove| Fiche]] - [[RICM5_2017-2018-SmartMove-SRS|SRS]]
| [https://github.com/orgs/SmartMove-PolytechGrenoble/dashboard Github]
| [[Media:RICM5_2017_2018_XYZ.pdf|Rapport final]] - [[Media:RICM5_2017_2018_XYZ.pdf|Presentation finale]] - [[Media:RICM5_2017_2018_XYZ.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 7
| [[EasyFlight 2017-2018|EasyFlight]]
| '''Boris ODIEVRE''' / Remi SAVARY / Lambert ROCHER / Hervé BECHER
| Didier Donsez
| [[EasyFlight 2017-2018| Fiche]] - [[RICM5_2017-2018-EasyFlight-SRS|SRS]]
| [https://github.com/lambertrocher/EasyFlight Github]
| [[Media:RICM5_2017_2018_XYZ.pdf|Rapport final]] - [[Media:RICM5_2017_2018_XYZ.pdf|Presentation finale]] - [[Media:RICM5_2017_2018_XYZ.pdf|Presentation de mi-parcours]]
|-

|}

==== Sujets non choisis ====
* [[Contributions open-source au projet JHipster]] (Didier Donsez)
* [[Contributions à Software Heritage]] (Didier Donsez and co)
* Projet IoT 3 : [[Ski-locator]] (Bernard Tourancheau)

= Projets collectifs MAT/IESE =

== Années 3 et 4 ==

* [[ASAC/SJC|Serres connectées @ Jardin du coteau]]
* [[ASAC/GEJC|Gestion de l'eau @ Jardin du coteau]]
* [[ASAC/AP|Aquaponie @ Polytech]]

=[[Projets M2PGI Services Machine-to-Machine et Internet-of-Things]]=
==[[PM2M/2018/TP|PM2M]]==

R'Montagne

2018-03-15T05:34:44Z

Hugo.Amodru-Favin: /* Métriques Logicielles */

=Équipe=
{|class="wikitable"
|-
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Rôle
|-
| Hugo Amodru-Favin
| Chef de Projet
|-
| Antoine Delise
| Lead Developer
|-
| Gwenaël Moreau
| Kanban Master
|-

|}

==Tâches==

Répartition générale des tâches
{|class="wikitable"
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Tâche
|-
| Hugo Amodru-Favin
| Application Ionic
|-
| Antoine Delise
| Développement Arduino
|-
| Gwenaël Moreau
| BDD - API
|-

|}

Détail des tâches : [https://waffle.io/delisea/R-Montagne Waffle.io]

=Journal=

{|class="wikitable"
|+
|-
!scope="col" width="120px"| Date
!scope="col" width="350px"| Hugo AMODRU-FAVIN
!scope="col" width="350px"| Antoine DELISE
!scope="col" width="350px"| Gwenaël MOREAU
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 1
|-

|-
| rowspan="1" | Lundi 29/01/18
| style="width: 225px;" |
* Ré-assimilation du sujet
| style="width: 225px;" |
* Ré-assimilation du sujet
| style="width: 225px;" |
* Ré-assimilation du sujet
* Mise en place d'un Kanban
|-
| rowspan="1" | Mardi 30/01/18
| style="width: 225px;" |
* Mise à jour de la page AIR
* Réflexions sur l'implémentation du LoRa
| style="width: 225px;" |
* Mise à jour de la page AIR
* Réflexions sur l'implémentation du LoRa
| style="width: 225px;" |
* Mise en place du calendrier prévisionnel
* Définition et répartition des tâches
|-
| rowspan="1" | Mercredi 31/01/18
| style="width: 225px;" |
* Récupération des cartes Semtech
* Présentation du Hackathon Vinci Energies
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Récupération des cartes Semtech
* Présentation du Hackathon Vinci Energies
* Prise en main des cartes LoRa
* Recherche d'un environnement de programmation gratuit utilisable pour le projet
| style="width: 225px;" |
* Récupération et prise en main des cartes Semtech LoRaMote
* Présentation du Hackathon Vinci Energies
|-
| rowspan="1" | Jeudi 01/02/18
| style="width: 225px;" |
* Choix des fonctionnalités de l'application mobile
| style="width: 225px;" |
* Prise en main des cartes LoRa
* Recherche d'un environnement de programmation gratuit utilisable pour le projet
| style="width: 225px;" |
* Prise en main des cartes LoRa
|-
| rowspan="1" | Vendredi 02/02/18
| style="width: 225px;" |
* Réflexions sur l'implémentation de l'application
* Démarrage de l'application mobile
* Mises à jour d'Ionic, de Android Studio
| style="width: 225px;" |
* Premières communications fructueuses des cartes Semtech LoRaMote
* Recherche d'un environnement de programmation gratuit utilisable pour le projet
| style="width: 225px;" |
* Premières communications fructueuses des cartes Semtech LoRaMote
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 2
|-

|-
| rowspan="1" | Lundi 05/02/18
| style="width: 225px;" |
* Configuration Login et Mot de Passe, Identification base
| style="width: 225px;" |
* Prise en main des cartes LoRa, premiers programme Lora
* Atolic TrueStudio semble correspondre à nos attentes
| style="width: 225px;" |
* Réflexion et création de la base de données
|-
| rowspan="1" | Mardi 06/02/18
| style="width: 225px;" |
* Configuration Login, Mot de passe
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
* Routage statique In Progress
| style="width: 225px;" |
* Création de l'API REST EN PHP
|-
| rowspan="1" | Mercredi 07/02/18
| style="width: 225px;" |
* Réunion avec Rémi CHOLLET et 3 PEIP D
* Assimilation du fonctionnement de Leaflet
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
* écritude d'une librairie de buffer cyclique à taille variable pour manipuler des paquets
| style="width: 225px;" |
* Réunion avec Rémi CHOLLET et 3 PEIP D
* Création de l'API REST en PHP
|-
| rowspan="1" | Jeudi 08/02/18
| style="width: 225px;" |
* Ajout de marqueurs sur Leaflet
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
* Routage statique fonctionnel
| style="width: 225px;" |
* Création de l'API REST EN PHP
|-
| rowspan="1" | Vendredi 09/02/18
| style="width: 225px;" |
* Hackathon Vinci Energies
| style="width: 225px;" |
* Hackathon Vinci Energies
| style="width: 225px;" |
* Hackathon Vinci Energies
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 3
|-

|-
| rowspan="1" | Lundi 12/02/18
| style="width: 225px;" |
* Préparation Soutenance
| style="width: 225px;" |
* Mise en place d'un Contiki/Cooja pour faciliter le développement
* Importation des librairie et début débogage
| style="width: 225px;" |
* Préparation Soutenance
|-
| rowspan="1" | Mardi 13/02/18
| style="width: 225px;" |
* Mise à jour de AIR
* Préparation Soutenance
* Répétition soutenance
| style="width: 225px;" |
* Préparation Soutenance
* Répétition soutenance
* Mise en place d'un Contiki/Cooja pour faciliter le dévelloppement
* Fin du débogage de l'importation des librairies
| style="width: 225px;" |
* Préparation Soutenance
* Répétition soutenance
|-
| rowspan="1" | Mercredi 14/02/18
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
|-
| rowspan="1" | Jeudi 15/02/18
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
|-
| rowspan="1" | Vendredi 16/02/18
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
|-
| rowspan="1" | Interruption de Février
| style="width: 225px;" |
| style="width: 225px;" |
* Développement sur Contiki/Cooja afin de réaliser un routage dynamique
| style="width: 225px;" |
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 4
|-

|-
| rowspan="1" | Lundi 26/02/18
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Travail sur l'affichage des éléments sur la carte utilisateur
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Continuation du travail sur Contiki
* Le routage dynamique fonctionne
* Il reste des imprécision à corriger pour améliorer la communication
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Corrections de l'API en accord avec l'application mobile
* Modifications sur la base de données
|-
| rowspan="1" | Mardi 27/02/18
| style="width: 225px;" |
* Création de la page de création d'un nouvel utilisateur
* Design de l'application mobile
| style="width: 225px;" |
* Fin du protocole de routage Contiki, tests virtuels de fonctionnement
* Le routage dynamique fonctionne sur des réseaux complexes
| style="width: 225px;" |
* Liaison entre l'application mobile et l'API
|-
| rowspan="1" | Mercredi 28/02/18
| style="width: 225px;" |
* Fin de la page de création d'un nouvel utilisateur
* Ajout de l'utilisation des sessions dans l'application
| style="width: 225px;" |
* Panne ordinateur personnel
* Perte des données du routage dynamique malgré une tentative de back-up avant la panne
* Travail sur l'application mobile avec Hugo
| style="width: 225px;" |
* API : Création d'un utilisateur
* API : Récupération des informations nécessaires pour la carte
* API : Ajout de l'utilisation des sessions pour stocker l'utilisateur connecté
|-
| rowspan="1" | Jeudi 01/03/18
| style="width: 225px;" |
* Affichage des informations sur la Map
| style="width: 225px;" |
* Affichage des informations sur la Map
* Tentative de récupération ordinnateur et données (échec)
| style="width: 225px;" |
* API : Récupération des informations nécessaires pour la carte
|-
| rowspan="1" | Vendredi 02/03/18
| style="width: 225px;" |
* Listing des futures tâches à implémenter dans l'application
* Réunion et préparation rendez-vous avec M.Donsez
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Réparation d'ordinateur personnel, de nouveau pleinement opérationnel mais toutes les données ont été perdues
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Renseignements sur Swagger
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 5
|-

|-
| rowspan="1" | Lundi 05/03/18
| style="width: 225px;" |
* Restructuration de l'application, amélioration visuelle
* Logout fonctionnel
| style="width: 225px;" |
* Finalisation de la carte, et ajout de la gestion des différentes cartes
* Restructuration de l'application
| style="width: 225px;" |
* Création d'une page Swagger
* Corrections de l'API
* Ajout des cartes dans la base de données
* Récupération des éléments liés à la carte dans l'API
|-
| rowspan="1" | Mardi 06/03/18
| style="width: 225px;" |
* Ajout gestion secouriste
* Développement de la page Account, modification utilisateur
| style="width: 225px;" |
* Ajout gestion secouriste
* Création vues côté secouristes
| style="width: 225px;" |
* Fin du Swagger
* API : Modifications utilisateur
* API : Modifications mot de passe
* Base de données : Ajout affectations secouristes-cartes
* API : Récupération des cartes pour un secouriste
|-
| rowspan="1" | Mercredi 07/03/18
| style="width: 225px;" |
* Amélioration et finalisation de la page Account
| style="width: 225px;" |
* Corrections du menu et de la navigation
| style="width: 225px;" |
* Programme de récupération des messages à la racine et inscription des données dans la base de données
|-
| rowspan="1" | Jeudi 08/03/18
| style="width: 225px;" |
* Extraction des dents de sagesse
| style="width: 225px;" |
* Menu dynamique, permet de gérer plusieurs map
* Création de la page de compte
* Modification et débogage du système de navigation
| style="width: 225px;" |
* Création du programme de communication LoRa et récupération des coordonnées GPS depuis la carte SodaqONE
* Tests de temps de synchronisation et précision du GPS
|-
| rowspan="1" | Vendredi 09/03/18
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Design du LogoV2, Embellie CSS de l'application mobile
* Réunion avec les PEIP D
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Un peu de Sodaq
* Ajout de filtre
* Nouveau déploiement sur le PlayStore
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Finition du programme de communication LoRa
* Tests d'envoi de la carte SodaqONE vers la base de données en passant par une racine (carte Arduino LoRa)
|-
| rowspan="1" | Samedi 10/03/18
| style="width: 225px;" |
* Réflexions et implémentations des Usercases concernant la gestion des licences
* Ajout de notifications mobiles
* Ajout d'une page liée à la gestion des Trackers
* Début du Poster Anniversaire
| style="width: 225px;" |
* Réflexions et implémentations des Usercases concernant la gestion des licences
* Ajout de notifications mobiles
| style="width: 225px;" |
* Tests du programme de communication avec les LoRas
|-
| rowspan="1" | Dimanche 11/03/18
| style="width: 225px;" |
* Implémentations des usercases liées à la gestion des licences côté application
* Système de notification automatique (FireBase)
| style="width: 225px;" |
* Implémentations des usercases liées à la gestion des licences côté api
* Système de notification automatique (FireBase)
| style="width: 225px;" |
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 6
|-

|-
| rowspan="1" | Lundi 12/03/18
| style="width: 225px;" |
* Ajouts de fonctionnalités dans l'application
| style="width: 225px;" |
* Correctifs programme de communication
* ébauche de l'interface d'administration (édition automatique)
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Correctifs programme de communication
|-
| rowspan="1" | Mardi 13/03/18
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Finalisation des fonctionnalités de l'application
* Correctifs des bugs
* Test Réel à la Bastille
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Finalisation des fonctionnalités de l'application
* Correctifs des bugs
* Page de création de Map Admin
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Préparation des capteurs pour le test réel
* Test Réel à la Bastille
|-
| rowspan="1" | Mercredi 14/03/18
| style="width: 225px;" |
* Préparation de la soutenance
* Remplissage de la BDD
* Finalisation du Poster
* Test Réel aux Taillées
| style="width: 225px;" |
* Préparation de la soutenance
* Préparation de la démonstration
* Dernier correctifs de l'application
| style="width: 225px;" |
* Préparation de la soutenance
* Finalisation du Poster
* Test Réel aux Taillées
|-
| rowspan="1" | Jeudi 15/03/18
| style="width: 225px;" |
* Soutenance de Projet
| style="width: 225px;" |
* Soutenance de Projet
| style="width: 225px;" |
* Soutenance de Projet
|-
| rowspan="1" | Vendredi 16/03/18
| style="width: 225px;" |
* 16 Ans de la filière RICM : Présentation du travail effectué
| style="width: 225px;" |
* 16 Ans de la filière RICM : Présentation du travail effectué
| style="width: 225px;" |
* 16 Ans de la filière RICM : Présentation du travail effectué
|}

=Métriques Logicielles=

Langages :
* Ionic (TypeScript, HTML, CSS)
* C++
* PHP
* Java

Lignes de code :
* Application mobile : ~3000
* API + Swagger : ~2000
* LoRa : ~150
* Routage : ~300

Cocomo (complexité P semidetached) :
* Effort = 3 * 5,1501,12 = 18,8 mois homme
* TDev = 2,5 * Effort0,35 = 7 mois

Temps ingénieur :
* 180h par personne
* 6400€ brut coûtant par personne et par mois
* Coût du projet : 23500€

=Collaboration avec le DUT RT et les PEIPs D=
L'objectif de cette collaboration est de familiariser des étudiants en PEIP D avec des projets qu'ils seront amenés à développer dans les prochaines années. Nous avons rencontré Rémi CHOLLET et 3 étudiants Mercredi 7 Février, en voici un résumé écrit par Mr CHOLLET définissant les contours de cette collaboration.

"Un rapide résumé de la rencontre que nous avons eu ce matin avec le projet R’Montagne.

Présents :
- RCIM5 Gwenael Moreau, Hugo Amodru-Favin
- PEIP-D : Yoann Goma-Missamou, Vincent Cadoux, Philippe Charrat
- IUT : Rémy Chollet, tuteur pédagogique des PEIP-D
Excusés : Didier Donsez, blessé (aie ! courage …), Antoine Delise en cours de marketing

Contexte :
Les PEIP-D participent aux projets RICM5 en prenant une tâche « annexe » (hors chemin critique) en charge. L’objectif est une expérience d’immersion + notation liée au PEIP.

Déroulé :
Les étudiant RCIM5 ont présenté le projet dans son principe et état d’avancement. Les échanges se sont portés sur l’idée de mener une étude (simulation et mesure) sur la consommation des balises par les PEIP-D avec pour objectif de dimensionner la réserve d’énergie.

Ceci implique :
- coté RCIM5 : mise à disposition d’une carte prototype.

- cote PEIP-D : inventaire des paramètres à prendre en compte :
* consommation carte (GPS + puce LoRa) = > veille + temps d’activation (recherche à faire sur le temps de synchronisation du GPS)
* puissance d’émission à calibrer en fonction de la couverture voulue et débit (voir Spread Factor ?)
* temps d’émission-réception (émission jusqu’à acquittement)

- cote PEIP-D : penser la manip pour valider ce modèle
* mesure moyenne du courant
* configuration effective du réseau
* réserver le matériel (voir Jean-Yves Frau au département R&T ?)

- cote PEIP-D : paramètrer les simulations et mesures en fonction de puissance d’émission (ou autre élément pouvant apparaitre comme pertinent)

D’une manière générale, pour les PEID-D :
- penser bibliographie (pour commencer : https://fr.wikipedia.org/wiki/LoRaWAN et aussi https://fr.wikipedia.org/wiki/Format_des_piles_et_accumulateurs_électriques :-) )
- planifier
- communiquer : reporting !!!"

=Description du sujet=

==Randonnée et risques==

Ouvert à tous, la randonnée est un sport et un loisir qui prend de plus en plus d’ampleur de nos jours. Ne nécessitant pas de grands prérequis, des milliers de personnes se lancent en montagne chaque jour, malheureusement parfois sans connaître toutes les mesures de sécurité associées.

En effet, de janvier à juin 2016, en randonnée et en alpinisme, l’Association Nationale pour l’Étude de la Neige et des Avalanches (ANENA) a comptabilisé 21 accidents notables, dont 8 accidents mortels, impliquant 15 décès.

Aujourd’hui, les mesures de sécurités préconisent que chaque groupe de randonneur se doivent de se munir d’un téléphone portable afin d’appeler les secours en cas de problème. Malheureusement, la communication mobile dépendant de la couverture réseau, peu présente en montagne, l’impossibilité de joindre les secours reste un problème.

==Solutions existantes==

La solution la plus répandue, est celle du téléphone à connexion satellite. Ayant une communication vers les satellites, cela permet une couverture réseau beaucoup plus répandue dans les montagnes, partout dans le monde (ou presque). Cependant, les téléphones portables satellitaires coûtent chers, et ne sont pas forcément abordables par la plupart des personnes, surtout celles ne sortant qu’occasionnellement.

[https://fall-alarm.net/ Fall Alarm] est un système de détection de chute sur chantier utilisant les mêmes technologies dont nous avons besoin pour notre projet.

==Quelles zones géographiques ?==

Toutes les zones montagneuses peuvent présenter des zones blanches, démunies de connexion quelconque autre que les connexions satellitaires. Certaines chaînes de montagne comme la Cordillaire des Andes ne présentent aucune connexion possible quelconque.

Dans le cadre de notre projet, nous fonctionnerons essentiellement dans la localisation grenobloise avec l'objectif que notre solution soit applicable partout dans le monde. Une contrainte intervient tout de même étant donnée que la fréquence d'utilisation du LoRa en Europe est de 868MHz, 915MHz en Amérique et 433MHz en Asie.

= Fonctionnalités =

Afin de remplir au mieux ses attentes, le principal objectif de ce dispositif sera premièrement de pouvoir communiquer avec les secours à n’importe quel moment, et surtout n’importe où. De plus, il sera capable de détecter de nombreux cas de détresse de la part de l’usager afin de pouvoir lancer un appel d’urgence sans interaction avec l’usager, au cas où il serait inconscient, ou incapable de lancer un appel manuel.

Grâce aux accéléromètres, le dispositif sera à même de détecter un mouvement brutal du randonneur, ce qui pourrait s’apparenter à une chute. Ils pourront également détecter une position anormale, ou une immobilité prolongée, ce qui déclencherait le dispositif d’urgence automatiquement.

Grâce à des tests réalisés au préalable, le boîtier pourra détecter correctement les chûtes de simples mouvements, afin de ne pas lancer l’appel sans raison valable.

Avant de lancer une alerte automatique, le dispositif émettra un signal auditif et visuel à l’utilisateur quelques secondes auparavant, afin de le prévenir l'émission du signal d’urgence, et de lui proposer de le désactiver sur simple pression d’un bouton, afin d’éviter les communications inutiles.

Également, le randonneur sera à même d'émettre volontairement un appel d’urgence à l’aide du bouton, ce qui permet à tout moment d’appeler de l’aide sans effort. Cela peut permettre également à appeler les secours pour une personne en danger qui ne porterait pas le dispositif.

L’appel au secours se représente par un envoi de coordonnées GPS aux secours, via une communication radio LoRa vers des bornes relais placées au préalables en montagne. Cette communication irait de relai de relai jusqu’au centre de sécurité, d’où le message serait transmis aux secours.

De plus, une application mobile verra le jour afin de connecter tous les utilisateurs du module de sécurité, de les visualiser sur une map, et de partager leurs données. En effet, à chaque incident, l’application mettra à jour la position et de la date de l’accident, afin de permettre aux prochains utilisateurs d’être prévenus. Ils pourraient, s'ils sont à proximité, d'assister la personne en détresse en attendant l'arrivée des secours. Bien évidemment, cette application ne sera accessible uniquement si le smartphone de l'utilisateur est relié à une connexion 4G ou Wi-Fi.

Cette prévention pourrait les sensibiliser aux risques de la montagne, leur permettre d’éviter le secteur mais aussi d’aider les personnes en danger si la distance le permet.

= Exigences =
== Fonctionnelles ==

*Batterie garantie fonctionnelle 1 semaine
*Rechargement possible via le panneau solaire portable
*Dispositif pouvant être allumé et éteint par l'utilisateur
*Alarme s’enclenche automatiquement dès qu'elle est considérée nécessaire, signal sonore
*Utilisateur a la possibilité d’activer/désactiver l’alarme quand il le souhaite
*Lorsque l’alarme est active, l’appareil ne peut s’éteindre
*...

== Non-Fonctionnelles ==

*Résistance : aux chocs, impacts, waterproof (utilisé en permanence en plein air)
*Disponibilité : Appareil de secours -> Doit être au plus possible performant
*Performance : Minimiser les pertes réseaux
*Accessible : Utilisateur pas forcément familier avec des appareils électroniques (facile d’utilisation)
*Fiabilité : Précision du GPS (rayon de 10m), données non-éronnées
*Coût : Le plus faible possible pour vendre le moins cher possible
*Efficacité : Réduire la consommation, utiliser le moins possible les ressources

= Composants =
== LoRaONE ==
Pour le coeur du projet, après avoir cherché et comparés plusieurs modules LoRa, GPS ou encore accéléromètres, nous avons finalement opté pour le projet LoRaONE.

LoRaONE est un projet de SODAQ regroupant plusieurs composants dans une seule et même carte, de taille réduite.

https://www.kickstarter.com/projects/sodaq/loraone-the-lora-iot-development-board

“The one IoT development board to rule them all” --SODAQ

Cette carte regroupe plusieurs capteurs afin de respecter aux mieux nos exigences :

Un émetteur/récepteur LoRa afin de pouvoir communiquer au mieux avec les antennes relai à longue distance

Un module + antenne GPS de bonne précision (< 10m) pour connaître en tout temps notre position, et ainsi faciliter l’arrivée des secours, ainsi que la recherche de l’individu en détresse

Un accéléromètre sur 3 axes afin de pouvoir détecter tout mouvement, vitesse ou rotation dans l’espace, ce qui permet la détection de chutes ou d’arrêt de mouvements

3 LED RGB afin de pouvoir signaler à l’utilisateur un manque de batterie, un signal d’urgence ou plus si nécessaire

Un bouton poussoir pour le signal d’alarme

Un connecteur de charge par panneau solaire, afin de faire durer chaque batterie le plus longtemps possible

Un connecteur micro-USB ainsi que des lignes pour se connecter à une base Arduino si besoin

[[File:LoRaOne.png||400px|Spécifications carte LoRaOne]]

De plus, grâce au starter pack, nous pouvons avoir accès à la base ONEBase qui nous permettrait d’étendre plus loin la facilité d’utilisation du produit :

[[File:LoRaOneBase.png||400px|Spécifications base LoRaOneBase]]

Comme nous pouvons le voir, cette base nous permettra de connecter la batterie ainsi que le panneau solaire qui sont fournis dans le pack.

Nous pourrons également connecter jusqu’à 4 modules supplémentaires.

La batterie fournie aura une capacité de 800 mAh, le panneau solaire fourni pouvant délivrer jusqu’à 500 mW de puissance.

Le total atteint une taille d’environ 10*5 cm, ce qui n’est pas excessif, ce qui le rend aisément portatif sur une jambe ou à la taille.

'''Coût : 115€'''

Ce module pourra également servir d’antenne relai, l'alimentation solaire devrait maintenir le dispositif chargé en permanence. Des tests seront effectués pour savoir si un panneau solaire plus puissant est requis.

== Boîtier ==

Le boîtier sécurisé devant respecter plusieurs exigences, nous pouvons le construire en plastique résistant, ce qui le rendrait léger tout en respectant une rigidité suffisante. Les antennes pourront être placées le long du boîtier, à l’intérieur si la connexion est suffisante, ou à l’extérieur. Dans ce dernier cas les trous réalisés sur le boîtier afin de laisser passer les câbles seront colmatés afin de garantir une étanchéité.

[[File:SchemaBoitier.png||100px|Schéma boitier d'alarme]]

== Balises ==

Afin de remonter les informations transmises par les boitiers, des balises seront mises en places sur la zone à couvrir, leur nombre et leur positions dépendra du terrain (obstacles, dénivelés). On distinguera deux types de balises. Tout d’abord, les balises racines qui permettront une communication GSM afin de faire remonter les données vers le serveur. Viennent ensuite les balises standard qui se contenteront de faire remonter vers leur balise racine associée. L’architecture de liaison des balises est détaillée dans une prochaine partie.

Chaque balise est composée d’une barre de fer pouvant être plantée dans le sol, d’un système de lest afin d’immobiliser la balise, d’un paratonnerre, d’un panneau solaire ainsi que d’un LoraOne et d’une batterie. Les balises racines seront équippée en plus d’un dispositif de communication GSM (téléphone portable, émetteur GSM).

[[File:SchemaBalise.png||150px|Schéma balises d'alarme]]

== Application mobile ==
Une application mobile est téléchargeable par les utilisateurs. Ils peuvent voir les autres utilisateurs présents dans leur zone. Lorsqu’un utilisateur est en position de danger, une notification apparaît si les utilisateurs sont proches de la situation de danger.

Cette application n’est pas directement reliée au dispositif. Elle ne fonctionne qu’avec la connexion du mobile, et est destinée à être un niveau de sécurité supérieur. Un randonneur proche d’une zone de danger pourrait arriver sur place plus rapidement que les secours.

= Communication =

Pour un envoi de position + numéro d’identification (X chiffres) :

*Temps de communication : < 2 s
*Communication régulière, intervalle de 15 minutes

On peut donc au maximum avoir 15 * 60 / 2 = 450 individus pouvant communiquer avec la même antenne relai, donc dans le même cercle d’environ 15 km de diamètre.

On communique donc au minimum 2 secondes sur 15 minutes, donc 1/450 << 1%, le temps de communication est respecté.

En cas de problème, nous pouvons envoyer jusqu’à 9x plus avec la borne sans dépasser le temps de communication autorisé (1%). Donc 1 envoi d’appel d’urgence toutes les 2 minutes environ.

La balise racine peut être directement connectée au serveur, dans ce cas, il n’y a pas de communication GSM nécessaire et pas de Gateway. Si la racine n’est pas directement connectée au serveur, elle devra au minimum garantir une communication GSM (ce qu’elle peut faire, il n’y a pas de Gateway nécessaire) pour remonter l’information vers le serveur, et donc la base de données.

GSM : Si Racine connectée à Serveur -> No GSM + Gateway
Else : GSM + Gateway : LoRa Racine connectée ordi (RaspberryPI) + ordi connecté GSM

= Stabilisation et gestion d’erreurs =

== Choix du routage ==

Notre réseau n'est pas un réseau traditionnel. Les seules communications existantes sont soit une remontée d'information vers la racine soit une innondation d'alerte vers les clients. Pour celà nous avons donc décidé d'utiliser un algorithme de routage simplifié basé uniquement sur un arbre en largeur des balises. Nous rajoutons en option la possibilité de créer plusieurs racines et donc plusieurs arbres dont les racines communiquent par gsm. Nous nous basons sur des papiers de recherches afin de déterminer quel algorithme auto-stabilisant est le plus adapté au système LoRa (Tel que le papier "A self-stabilizing algorithm for constructing breadth-first trees" par Shing-Tsaan Huang, Nian-Shing Chen).

== Stabilisation ==

Afin de gérer la communication de chaque message vers le serveur, nous allons prendre un noeud (balise LoRa) dit “racine” connecté directement au serveur, nous ne nous occuperons pas de la communication au serveur dans cet onglet. Chaque message reçu de la part d’un noeud du système doit être relayé jusqu’à la racine du système afin de communiquer avec les secours (ou serveur simplement).

Pour cela, il faudra assurer que chaque balise LoRa soit connecté au réseau, afin d’avoir au départ un graphe de communication connexe. Par dessus ce graphe, nous allons utiliser un processus silencieux auto-stabilisant qui construira un arbre de parcours en largeur, avec pour racine le noeud “racine” décidé ci-dessus.

Au lancement du système, il faut prévoir un léger temps de stabilisation, qui dépendrait de l’algorithme et de la taille du graphe (nombre de balises). Cependant, après cela, l’algorithme assure un arbre en profondeur minimal qui nous permettrai de communiquer avec la racine le plus rapidement possible, et donc une qualité de service maximale.

== Gestion d’erreurs ==

Dans un réseau comme celui-ci, plusieurs types d’erreurs peuvent se produire :
Délai de communication trop important vers une balise
“Crash” d’une balise de communication
Surpopulation d’une balise ou congestion de messages

Afin de palier au premier type d’incident rencontré, il faut nécessairement qu’à chaque emplacement dans la zone couverte, l’utilisateur soit à même de communiquer avec au minimum 2 balises différentes. Ainsi, dans le cas d’une communication trop longue sur une balise, l’autre aurait de grandes chances de délivrer le message plus rapidement.

Au niveau de la défaillance d’une balise, l’algorithme d’arbre en profondeur nous fournit déjà une solution intégrée grâce à son auto-stabilisation. Dans le cas de déconnexion d’une balise, l’algorithme mettrai à jour automatiquement l’arbre de communication, et n’importe quel message d’alerte émis serait délivré dans un délai raisonnable.

Pour le troisième cas d’erreur, il n’y aurait pas de solution réelle, si ce n’est de limiter le nombre de communications données, en ne prenant plus en compte les “ping” de chaque utilisateur mais seulement les messages d’alertes, ce qui permettrai une bien plus grande gestion de la congestion à un endroit donné. Également, une balise en dessous d’un lien congestionné pourrait communiquer avec ses autres voisins (non-fils dans l’arbre) afin de libérer de l’espace dans le lien avec son père dans l’arbre. Également, le système ne pourra accepter que jusqu’à 1000 utilisateurs par noeud, et également 4000 utilisateurs par cluster (dans le cas d’un réseau avec plusieurs clusters donc plusieurs racines cette limite augmente).

Plusieurs types de paquets circulent sur le réseau de balise:
Les pings, messages envoyés spontanéments à intervalle régulier par les utilisateur contenant l’id ainsi que les deux coordonées gps (27 bits chacun)
Les incidents, identique à un ping mais à priorité haute.
Les alertes, messages brodcastés par le serveur afin d’envoyer un message en chaine de caractères courts et compressés.

=Coûts matériels=

Que ce soit pour le dispositif utilisateur ou la balise (racine ou non), le LoRaOne correspond pour permettre les actions recherchées. Afin de réaliser un prototype pertinent, 6 kits LoRaOne sont requis. Ces kits sont accessibles sur le site de Sodaq au prix de 115€ chacun (prix variable).
Disponible [https://shop.sodaq.com/en/one-eu-rn2483-v2.html ici], voir avant dernier bundle : starter "ONE EU starter" actuellement à 112,10€.

Un [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer buzzer] est à ajouter au dispositif utilisateur afin de lui délivrer un signal sonore.

Un shield GSM est requis pour que la balise racine communique avec l'extérieur. Sodaq en propose un designé pour fonctionner sur leurs produits mais est éctuellement en rupture de stock. Un shield GSM arduino convient tout autant et peut être trouvé sur le site arduino [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna ici].

Aucun boitier ne sera commandé car nous avons fait le choix de les manufacturer nous même au fablab. Le besoin d'étanchéité n'est pas primordial pour notre prototype, bien que nous tenterons de l'assurer.

{|class="récap commande"
|+ Récapitulatif
|-
|
!scope="col" style="width: 320px;"| Produit
!scope="col" style="width: 80px;"| Lien
!scope="col" style="width: 80px;"| Quantité
!scope="col" style="width: 80px;"| Prix Unitaire
|-

!scope="row"| 1
| LoRaOne EU Starter
| [https://shop.sodaq.com/en/one-eu-rn2483-v2.html Achat]
| 6
| 115€
|-

!scope="row"| 2
| Buzzer
| [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer Achat]
| 3
| 5.49€
|-

!scope="row"| 3
| Shield GSM
| [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna Achat]
| 1
| 65€
|-

|}

=Développement=

Nous utiliserons les librairies standards Arduino ainsi que celle de SODAQ/Arduino pour le LoRa.

L'IDE Arduino sera utilisé, plus pratique pour l'utilisation de Git (comparé à Mbed).

= Mise sur le marché =

Ce dispositif a pour but d’être utilisé en montagne, lors de randonnée. Il n’est pas destiné à un usage quotidien, c’est pourquoi nous considérons qu’il est plus judicieux de louer les dispositifs plutôt que de les vendre, même si l’achat n’est pas à omettre de notre stratégie.

Le dispositif peut être commandé en ligne, puis retourné par la poste après usage. Le client louerait le dispositif pour une certaine durée avec un possible nombre supplémentaire de batterie. Les tarifs varient en fonction de la durée et du nombre de batteries louées. Des offres de groupes pourraient être applicables. A long terme, des boutiques pourraient être disséminées dans des grandes villes proches des zones montagneuses, zones à randonnées (Grenoble, Annecy, etc.).

L’application est téléchargeable gratuitement par quiconque, mais utilisable seulement par les clients. Un code d’accès sera envoyé avec le dispositif expirant après la fin de la location.

Il faudra tenir compte de la bande passante du LoRa, variante en fonction des continents.

=Planning prévisonnel=

Sprint 1 : 29/01 --> 09/02 : Création du prototype logiciel #1
*Prise en main du matériel
*Premiers tests de transmissions LoRa
*Création du protocole d'architecture des balises
*Application sur les cartes et tests
*Tests de performances des cartes (durabilité, chargement, batterie)
*Tests de maintenabilité de l'algorithme (déconnexions, latences)

Sprint 2 : 12/02 --> 23/02 : Prototype logiciel #2 et prototype matériel
*Création du programme embarqué (utilisateur)
*Communication avec la racine et le serveur
*Création des maquettes boîtier et balise
*Construction des maquettes
*Finalisation du premier prototype

Sprint 3 : 26/02 --> 09/03 : Fonctionnalités supplémentaires
*Ajout de la communication entre le LoRa et le GSM sur la balise racine
*Création application mobile utilisateur
*Tests sur l'application
*Tests sur la transmission totale depuis l'utilisateur vers le serveur via le GSM
*Finalisation du projet

Sprint 4 : 12/03 --> 16/03 : Fin du projet
*Création de la documentation finale (à partir de la documentation réalisée en continu)
*Pause café
*Temps supplémentaire en cas de problèmes importants
*Préparation de la soutenance

R'Montagne

2018-03-15T05:33:58Z

Hugo.Amodru-Favin: /* Métriques Logicielles */

=Équipe=
{|class="wikitable"
|-
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Rôle
|-
| Hugo Amodru-Favin
| Chef de Projet
|-
| Antoine Delise
| Lead Developer
|-
| Gwenaël Moreau
| Kanban Master
|-

|}

==Tâches==

Répartition générale des tâches
{|class="wikitable"
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Tâche
|-
| Hugo Amodru-Favin
| Application Ionic
|-
| Antoine Delise
| Développement Arduino
|-
| Gwenaël Moreau
| BDD - API
|-

|}

Détail des tâches : [https://waffle.io/delisea/R-Montagne Waffle.io]

=Journal=

{|class="wikitable"
|+
|-
!scope="col" width="120px"| Date
!scope="col" width="350px"| Hugo AMODRU-FAVIN
!scope="col" width="350px"| Antoine DELISE
!scope="col" width="350px"| Gwenaël MOREAU
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 1
|-

|-
| rowspan="1" | Lundi 29/01/18
| style="width: 225px;" |
* Ré-assimilation du sujet
| style="width: 225px;" |
* Ré-assimilation du sujet
| style="width: 225px;" |
* Ré-assimilation du sujet
* Mise en place d'un Kanban
|-
| rowspan="1" | Mardi 30/01/18
| style="width: 225px;" |
* Mise à jour de la page AIR
* Réflexions sur l'implémentation du LoRa
| style="width: 225px;" |
* Mise à jour de la page AIR
* Réflexions sur l'implémentation du LoRa
| style="width: 225px;" |
* Mise en place du calendrier prévisionnel
* Définition et répartition des tâches
|-
| rowspan="1" | Mercredi 31/01/18
| style="width: 225px;" |
* Récupération des cartes Semtech
* Présentation du Hackathon Vinci Energies
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Récupération des cartes Semtech
* Présentation du Hackathon Vinci Energies
* Prise en main des cartes LoRa
* Recherche d'un environnement de programmation gratuit utilisable pour le projet
| style="width: 225px;" |
* Récupération et prise en main des cartes Semtech LoRaMote
* Présentation du Hackathon Vinci Energies
|-
| rowspan="1" | Jeudi 01/02/18
| style="width: 225px;" |
* Choix des fonctionnalités de l'application mobile
| style="width: 225px;" |
* Prise en main des cartes LoRa
* Recherche d'un environnement de programmation gratuit utilisable pour le projet
| style="width: 225px;" |
* Prise en main des cartes LoRa
|-
| rowspan="1" | Vendredi 02/02/18
| style="width: 225px;" |
* Réflexions sur l'implémentation de l'application
* Démarrage de l'application mobile
* Mises à jour d'Ionic, de Android Studio
| style="width: 225px;" |
* Premières communications fructueuses des cartes Semtech LoRaMote
* Recherche d'un environnement de programmation gratuit utilisable pour le projet
| style="width: 225px;" |
* Premières communications fructueuses des cartes Semtech LoRaMote
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 2
|-

|-
| rowspan="1" | Lundi 05/02/18
| style="width: 225px;" |
* Configuration Login et Mot de Passe, Identification base
| style="width: 225px;" |
* Prise en main des cartes LoRa, premiers programme Lora
* Atolic TrueStudio semble correspondre à nos attentes
| style="width: 225px;" |
* Réflexion et création de la base de données
|-
| rowspan="1" | Mardi 06/02/18
| style="width: 225px;" |
* Configuration Login, Mot de passe
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
* Routage statique In Progress
| style="width: 225px;" |
* Création de l'API REST EN PHP
|-
| rowspan="1" | Mercredi 07/02/18
| style="width: 225px;" |
* Réunion avec Rémi CHOLLET et 3 PEIP D
* Assimilation du fonctionnement de Leaflet
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
* écritude d'une librairie de buffer cyclique à taille variable pour manipuler des paquets
| style="width: 225px;" |
* Réunion avec Rémi CHOLLET et 3 PEIP D
* Création de l'API REST en PHP
|-
| rowspan="1" | Jeudi 08/02/18
| style="width: 225px;" |
* Ajout de marqueurs sur Leaflet
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
* Routage statique fonctionnel
| style="width: 225px;" |
* Création de l'API REST EN PHP
|-
| rowspan="1" | Vendredi 09/02/18
| style="width: 225px;" |
* Hackathon Vinci Energies
| style="width: 225px;" |
* Hackathon Vinci Energies
| style="width: 225px;" |
* Hackathon Vinci Energies
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 3
|-

|-
| rowspan="1" | Lundi 12/02/18
| style="width: 225px;" |
* Préparation Soutenance
| style="width: 225px;" |
* Mise en place d'un Contiki/Cooja pour faciliter le développement
* Importation des librairie et début débogage
| style="width: 225px;" |
* Préparation Soutenance
|-
| rowspan="1" | Mardi 13/02/18
| style="width: 225px;" |
* Mise à jour de AIR
* Préparation Soutenance
* Répétition soutenance
| style="width: 225px;" |
* Préparation Soutenance
* Répétition soutenance
* Mise en place d'un Contiki/Cooja pour faciliter le dévelloppement
* Fin du débogage de l'importation des librairies
| style="width: 225px;" |
* Préparation Soutenance
* Répétition soutenance
|-
| rowspan="1" | Mercredi 14/02/18
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
|-
| rowspan="1" | Jeudi 15/02/18
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
|-
| rowspan="1" | Vendredi 16/02/18
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
|-
| rowspan="1" | Interruption de Février
| style="width: 225px;" |
| style="width: 225px;" |
* Développement sur Contiki/Cooja afin de réaliser un routage dynamique
| style="width: 225px;" |
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 4
|-

|-
| rowspan="1" | Lundi 26/02/18
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Travail sur l'affichage des éléments sur la carte utilisateur
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Continuation du travail sur Contiki
* Le routage dynamique fonctionne
* Il reste des imprécision à corriger pour améliorer la communication
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Corrections de l'API en accord avec l'application mobile
* Modifications sur la base de données
|-
| rowspan="1" | Mardi 27/02/18
| style="width: 225px;" |
* Création de la page de création d'un nouvel utilisateur
* Design de l'application mobile
| style="width: 225px;" |
* Fin du protocole de routage Contiki, tests virtuels de fonctionnement
* Le routage dynamique fonctionne sur des réseaux complexes
| style="width: 225px;" |
* Liaison entre l'application mobile et l'API
|-
| rowspan="1" | Mercredi 28/02/18
| style="width: 225px;" |
* Fin de la page de création d'un nouvel utilisateur
* Ajout de l'utilisation des sessions dans l'application
| style="width: 225px;" |
* Panne ordinateur personnel
* Perte des données du routage dynamique malgré une tentative de back-up avant la panne
* Travail sur l'application mobile avec Hugo
| style="width: 225px;" |
* API : Création d'un utilisateur
* API : Récupération des informations nécessaires pour la carte
* API : Ajout de l'utilisation des sessions pour stocker l'utilisateur connecté
|-
| rowspan="1" | Jeudi 01/03/18
| style="width: 225px;" |
* Affichage des informations sur la Map
| style="width: 225px;" |
* Affichage des informations sur la Map
* Tentative de récupération ordinnateur et données (échec)
| style="width: 225px;" |
* API : Récupération des informations nécessaires pour la carte
|-
| rowspan="1" | Vendredi 02/03/18
| style="width: 225px;" |
* Listing des futures tâches à implémenter dans l'application
* Réunion et préparation rendez-vous avec M.Donsez
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Réparation d'ordinateur personnel, de nouveau pleinement opérationnel mais toutes les données ont été perdues
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Renseignements sur Swagger
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 5
|-

|-
| rowspan="1" | Lundi 05/03/18
| style="width: 225px;" |
* Restructuration de l'application, amélioration visuelle
* Logout fonctionnel
| style="width: 225px;" |
* Finalisation de la carte, et ajout de la gestion des différentes cartes
* Restructuration de l'application
| style="width: 225px;" |
* Création d'une page Swagger
* Corrections de l'API
* Ajout des cartes dans la base de données
* Récupération des éléments liés à la carte dans l'API
|-
| rowspan="1" | Mardi 06/03/18
| style="width: 225px;" |
* Ajout gestion secouriste
* Développement de la page Account, modification utilisateur
| style="width: 225px;" |
* Ajout gestion secouriste
* Création vues côté secouristes
| style="width: 225px;" |
* Fin du Swagger
* API : Modifications utilisateur
* API : Modifications mot de passe
* Base de données : Ajout affectations secouristes-cartes
* API : Récupération des cartes pour un secouriste
|-
| rowspan="1" | Mercredi 07/03/18
| style="width: 225px;" |
* Amélioration et finalisation de la page Account
| style="width: 225px;" |
* Corrections du menu et de la navigation
| style="width: 225px;" |
* Programme de récupération des messages à la racine et inscription des données dans la base de données
|-
| rowspan="1" | Jeudi 08/03/18
| style="width: 225px;" |
* Extraction des dents de sagesse
| style="width: 225px;" |
* Menu dynamique, permet de gérer plusieurs map
* Création de la page de compte
* Modification et débogage du système de navigation
| style="width: 225px;" |
* Création du programme de communication LoRa et récupération des coordonnées GPS depuis la carte SodaqONE
* Tests de temps de synchronisation et précision du GPS
|-
| rowspan="1" | Vendredi 09/03/18
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Design du LogoV2, Embellie CSS de l'application mobile
* Réunion avec les PEIP D
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Un peu de Sodaq
* Ajout de filtre
* Nouveau déploiement sur le PlayStore
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Finition du programme de communication LoRa
* Tests d'envoi de la carte SodaqONE vers la base de données en passant par une racine (carte Arduino LoRa)
|-
| rowspan="1" | Samedi 10/03/18
| style="width: 225px;" |
* Réflexions et implémentations des Usercases concernant la gestion des licences
* Ajout de notifications mobiles
* Ajout d'une page liée à la gestion des Trackers
* Début du Poster Anniversaire
| style="width: 225px;" |
* Réflexions et implémentations des Usercases concernant la gestion des licences
* Ajout de notifications mobiles
| style="width: 225px;" |
* Tests du programme de communication avec les LoRas
|-
| rowspan="1" | Dimanche 11/03/18
| style="width: 225px;" |
* Implémentations des usercases liées à la gestion des licences côté application
* Système de notification automatique (FireBase)
| style="width: 225px;" |
* Implémentations des usercases liées à la gestion des licences côté api
* Système de notification automatique (FireBase)
| style="width: 225px;" |
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 6
|-

|-
| rowspan="1" | Lundi 12/03/18
| style="width: 225px;" |
* Ajouts de fonctionnalités dans l'application
| style="width: 225px;" |
* Correctifs programme de communication
* ébauche de l'interface d'administration (édition automatique)
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Correctifs programme de communication
|-
| rowspan="1" | Mardi 13/03/18
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Finalisation des fonctionnalités de l'application
* Correctifs des bugs
* Test Réel à la Bastille
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Finalisation des fonctionnalités de l'application
* Correctifs des bugs
* Page de création de Map Admin
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Préparation des capteurs pour le test réel
* Test Réel à la Bastille
|-
| rowspan="1" | Mercredi 14/03/18
| style="width: 225px;" |
* Préparation de la soutenance
* Remplissage de la BDD
* Finalisation du Poster
* Test Réel aux Taillées
| style="width: 225px;" |
* Préparation de la soutenance
* Préparation de la démonstration
* Dernier correctifs de l'application
| style="width: 225px;" |
* Préparation de la soutenance
* Finalisation du Poster
* Test Réel aux Taillées
|-
| rowspan="1" | Jeudi 15/03/18
| style="width: 225px;" |
* Soutenance de Projet
| style="width: 225px;" |
* Soutenance de Projet
| style="width: 225px;" |
* Soutenance de Projet
|-
| rowspan="1" | Vendredi 16/03/18
| style="width: 225px;" |
* 16 Ans de la filière RICM : Présentation du travail effectué
| style="width: 225px;" |
* 16 Ans de la filière RICM : Présentation du travail effectué
| style="width: 225px;" |
* 16 Ans de la filière RICM : Présentation du travail effectué
|}

=Métriques Logicielles=

Langages :
- Ionic (TypeScript, HTML, CSS)
- C++
- PHP
- Java

Lignes de code :
- Application mobile : ~3000
- API + Swagger : ~2000
- LoRa : ~150
- Routage : ~300

Cocomo (complexité P semidetached) :
- Effort = 3 * 5,1501,12 = 18,8 mois homme
- TDev = 2,5 * Effort0,35 = 7 mois

Temps ingénieur :
- 180h par personne
- 6400€ brut coûtant par personne et par mois
- Coût du projet : 23500€

=Collaboration avec le DUT RT et les PEIPs D=
L'objectif de cette collaboration est de familiariser des étudiants en PEIP D avec des projets qu'ils seront amenés à développer dans les prochaines années. Nous avons rencontré Rémi CHOLLET et 3 étudiants Mercredi 7 Février, en voici un résumé écrit par Mr CHOLLET définissant les contours de cette collaboration.

"Un rapide résumé de la rencontre que nous avons eu ce matin avec le projet R’Montagne.

Présents :
- RCIM5 Gwenael Moreau, Hugo Amodru-Favin
- PEIP-D : Yoann Goma-Missamou, Vincent Cadoux, Philippe Charrat
- IUT : Rémy Chollet, tuteur pédagogique des PEIP-D
Excusés : Didier Donsez, blessé (aie ! courage …), Antoine Delise en cours de marketing

Contexte :
Les PEIP-D participent aux projets RICM5 en prenant une tâche « annexe » (hors chemin critique) en charge. L’objectif est une expérience d’immersion + notation liée au PEIP.

Déroulé :
Les étudiant RCIM5 ont présenté le projet dans son principe et état d’avancement. Les échanges se sont portés sur l’idée de mener une étude (simulation et mesure) sur la consommation des balises par les PEIP-D avec pour objectif de dimensionner la réserve d’énergie.

Ceci implique :
- coté RCIM5 : mise à disposition d’une carte prototype.

- cote PEIP-D : inventaire des paramètres à prendre en compte :
* consommation carte (GPS + puce LoRa) = > veille + temps d’activation (recherche à faire sur le temps de synchronisation du GPS)
* puissance d’émission à calibrer en fonction de la couverture voulue et débit (voir Spread Factor ?)
* temps d’émission-réception (émission jusqu’à acquittement)

- cote PEIP-D : penser la manip pour valider ce modèle
* mesure moyenne du courant
* configuration effective du réseau
* réserver le matériel (voir Jean-Yves Frau au département R&T ?)

- cote PEIP-D : paramètrer les simulations et mesures en fonction de puissance d’émission (ou autre élément pouvant apparaitre comme pertinent)

D’une manière générale, pour les PEID-D :
- penser bibliographie (pour commencer : https://fr.wikipedia.org/wiki/LoRaWAN et aussi https://fr.wikipedia.org/wiki/Format_des_piles_et_accumulateurs_électriques :-) )
- planifier
- communiquer : reporting !!!"

=Description du sujet=

==Randonnée et risques==

Ouvert à tous, la randonnée est un sport et un loisir qui prend de plus en plus d’ampleur de nos jours. Ne nécessitant pas de grands prérequis, des milliers de personnes se lancent en montagne chaque jour, malheureusement parfois sans connaître toutes les mesures de sécurité associées.

En effet, de janvier à juin 2016, en randonnée et en alpinisme, l’Association Nationale pour l’Étude de la Neige et des Avalanches (ANENA) a comptabilisé 21 accidents notables, dont 8 accidents mortels, impliquant 15 décès.

Aujourd’hui, les mesures de sécurités préconisent que chaque groupe de randonneur se doivent de se munir d’un téléphone portable afin d’appeler les secours en cas de problème. Malheureusement, la communication mobile dépendant de la couverture réseau, peu présente en montagne, l’impossibilité de joindre les secours reste un problème.

==Solutions existantes==

La solution la plus répandue, est celle du téléphone à connexion satellite. Ayant une communication vers les satellites, cela permet une couverture réseau beaucoup plus répandue dans les montagnes, partout dans le monde (ou presque). Cependant, les téléphones portables satellitaires coûtent chers, et ne sont pas forcément abordables par la plupart des personnes, surtout celles ne sortant qu’occasionnellement.

[https://fall-alarm.net/ Fall Alarm] est un système de détection de chute sur chantier utilisant les mêmes technologies dont nous avons besoin pour notre projet.

==Quelles zones géographiques ?==

Toutes les zones montagneuses peuvent présenter des zones blanches, démunies de connexion quelconque autre que les connexions satellitaires. Certaines chaînes de montagne comme la Cordillaire des Andes ne présentent aucune connexion possible quelconque.

Dans le cadre de notre projet, nous fonctionnerons essentiellement dans la localisation grenobloise avec l'objectif que notre solution soit applicable partout dans le monde. Une contrainte intervient tout de même étant donnée que la fréquence d'utilisation du LoRa en Europe est de 868MHz, 915MHz en Amérique et 433MHz en Asie.

= Fonctionnalités =

Afin de remplir au mieux ses attentes, le principal objectif de ce dispositif sera premièrement de pouvoir communiquer avec les secours à n’importe quel moment, et surtout n’importe où. De plus, il sera capable de détecter de nombreux cas de détresse de la part de l’usager afin de pouvoir lancer un appel d’urgence sans interaction avec l’usager, au cas où il serait inconscient, ou incapable de lancer un appel manuel.

Grâce aux accéléromètres, le dispositif sera à même de détecter un mouvement brutal du randonneur, ce qui pourrait s’apparenter à une chute. Ils pourront également détecter une position anormale, ou une immobilité prolongée, ce qui déclencherait le dispositif d’urgence automatiquement.

Grâce à des tests réalisés au préalable, le boîtier pourra détecter correctement les chûtes de simples mouvements, afin de ne pas lancer l’appel sans raison valable.

Avant de lancer une alerte automatique, le dispositif émettra un signal auditif et visuel à l’utilisateur quelques secondes auparavant, afin de le prévenir l'émission du signal d’urgence, et de lui proposer de le désactiver sur simple pression d’un bouton, afin d’éviter les communications inutiles.

Également, le randonneur sera à même d'émettre volontairement un appel d’urgence à l’aide du bouton, ce qui permet à tout moment d’appeler de l’aide sans effort. Cela peut permettre également à appeler les secours pour une personne en danger qui ne porterait pas le dispositif.

L’appel au secours se représente par un envoi de coordonnées GPS aux secours, via une communication radio LoRa vers des bornes relais placées au préalables en montagne. Cette communication irait de relai de relai jusqu’au centre de sécurité, d’où le message serait transmis aux secours.

De plus, une application mobile verra le jour afin de connecter tous les utilisateurs du module de sécurité, de les visualiser sur une map, et de partager leurs données. En effet, à chaque incident, l’application mettra à jour la position et de la date de l’accident, afin de permettre aux prochains utilisateurs d’être prévenus. Ils pourraient, s'ils sont à proximité, d'assister la personne en détresse en attendant l'arrivée des secours. Bien évidemment, cette application ne sera accessible uniquement si le smartphone de l'utilisateur est relié à une connexion 4G ou Wi-Fi.

Cette prévention pourrait les sensibiliser aux risques de la montagne, leur permettre d’éviter le secteur mais aussi d’aider les personnes en danger si la distance le permet.

= Exigences =
== Fonctionnelles ==

*Batterie garantie fonctionnelle 1 semaine
*Rechargement possible via le panneau solaire portable
*Dispositif pouvant être allumé et éteint par l'utilisateur
*Alarme s’enclenche automatiquement dès qu'elle est considérée nécessaire, signal sonore
*Utilisateur a la possibilité d’activer/désactiver l’alarme quand il le souhaite
*Lorsque l’alarme est active, l’appareil ne peut s’éteindre
*...

== Non-Fonctionnelles ==

*Résistance : aux chocs, impacts, waterproof (utilisé en permanence en plein air)
*Disponibilité : Appareil de secours -> Doit être au plus possible performant
*Performance : Minimiser les pertes réseaux
*Accessible : Utilisateur pas forcément familier avec des appareils électroniques (facile d’utilisation)
*Fiabilité : Précision du GPS (rayon de 10m), données non-éronnées
*Coût : Le plus faible possible pour vendre le moins cher possible
*Efficacité : Réduire la consommation, utiliser le moins possible les ressources

= Composants =
== LoRaONE ==
Pour le coeur du projet, après avoir cherché et comparés plusieurs modules LoRa, GPS ou encore accéléromètres, nous avons finalement opté pour le projet LoRaONE.

LoRaONE est un projet de SODAQ regroupant plusieurs composants dans une seule et même carte, de taille réduite.

https://www.kickstarter.com/projects/sodaq/loraone-the-lora-iot-development-board

“The one IoT development board to rule them all” --SODAQ

Cette carte regroupe plusieurs capteurs afin de respecter aux mieux nos exigences :

Un émetteur/récepteur LoRa afin de pouvoir communiquer au mieux avec les antennes relai à longue distance

Un module + antenne GPS de bonne précision (< 10m) pour connaître en tout temps notre position, et ainsi faciliter l’arrivée des secours, ainsi que la recherche de l’individu en détresse

Un accéléromètre sur 3 axes afin de pouvoir détecter tout mouvement, vitesse ou rotation dans l’espace, ce qui permet la détection de chutes ou d’arrêt de mouvements

3 LED RGB afin de pouvoir signaler à l’utilisateur un manque de batterie, un signal d’urgence ou plus si nécessaire

Un bouton poussoir pour le signal d’alarme

Un connecteur de charge par panneau solaire, afin de faire durer chaque batterie le plus longtemps possible

Un connecteur micro-USB ainsi que des lignes pour se connecter à une base Arduino si besoin

[[File:LoRaOne.png||400px|Spécifications carte LoRaOne]]

De plus, grâce au starter pack, nous pouvons avoir accès à la base ONEBase qui nous permettrait d’étendre plus loin la facilité d’utilisation du produit :

[[File:LoRaOneBase.png||400px|Spécifications base LoRaOneBase]]

Comme nous pouvons le voir, cette base nous permettra de connecter la batterie ainsi que le panneau solaire qui sont fournis dans le pack.

Nous pourrons également connecter jusqu’à 4 modules supplémentaires.

La batterie fournie aura une capacité de 800 mAh, le panneau solaire fourni pouvant délivrer jusqu’à 500 mW de puissance.

Le total atteint une taille d’environ 10*5 cm, ce qui n’est pas excessif, ce qui le rend aisément portatif sur une jambe ou à la taille.

'''Coût : 115€'''

Ce module pourra également servir d’antenne relai, l'alimentation solaire devrait maintenir le dispositif chargé en permanence. Des tests seront effectués pour savoir si un panneau solaire plus puissant est requis.

== Boîtier ==

Le boîtier sécurisé devant respecter plusieurs exigences, nous pouvons le construire en plastique résistant, ce qui le rendrait léger tout en respectant une rigidité suffisante. Les antennes pourront être placées le long du boîtier, à l’intérieur si la connexion est suffisante, ou à l’extérieur. Dans ce dernier cas les trous réalisés sur le boîtier afin de laisser passer les câbles seront colmatés afin de garantir une étanchéité.

[[File:SchemaBoitier.png||100px|Schéma boitier d'alarme]]

== Balises ==

Afin de remonter les informations transmises par les boitiers, des balises seront mises en places sur la zone à couvrir, leur nombre et leur positions dépendra du terrain (obstacles, dénivelés). On distinguera deux types de balises. Tout d’abord, les balises racines qui permettront une communication GSM afin de faire remonter les données vers le serveur. Viennent ensuite les balises standard qui se contenteront de faire remonter vers leur balise racine associée. L’architecture de liaison des balises est détaillée dans une prochaine partie.

Chaque balise est composée d’une barre de fer pouvant être plantée dans le sol, d’un système de lest afin d’immobiliser la balise, d’un paratonnerre, d’un panneau solaire ainsi que d’un LoraOne et d’une batterie. Les balises racines seront équippée en plus d’un dispositif de communication GSM (téléphone portable, émetteur GSM).

[[File:SchemaBalise.png||150px|Schéma balises d'alarme]]

== Application mobile ==
Une application mobile est téléchargeable par les utilisateurs. Ils peuvent voir les autres utilisateurs présents dans leur zone. Lorsqu’un utilisateur est en position de danger, une notification apparaît si les utilisateurs sont proches de la situation de danger.

Cette application n’est pas directement reliée au dispositif. Elle ne fonctionne qu’avec la connexion du mobile, et est destinée à être un niveau de sécurité supérieur. Un randonneur proche d’une zone de danger pourrait arriver sur place plus rapidement que les secours.

= Communication =

Pour un envoi de position + numéro d’identification (X chiffres) :

*Temps de communication : < 2 s
*Communication régulière, intervalle de 15 minutes

On peut donc au maximum avoir 15 * 60 / 2 = 450 individus pouvant communiquer avec la même antenne relai, donc dans le même cercle d’environ 15 km de diamètre.

On communique donc au minimum 2 secondes sur 15 minutes, donc 1/450 << 1%, le temps de communication est respecté.

En cas de problème, nous pouvons envoyer jusqu’à 9x plus avec la borne sans dépasser le temps de communication autorisé (1%). Donc 1 envoi d’appel d’urgence toutes les 2 minutes environ.

La balise racine peut être directement connectée au serveur, dans ce cas, il n’y a pas de communication GSM nécessaire et pas de Gateway. Si la racine n’est pas directement connectée au serveur, elle devra au minimum garantir une communication GSM (ce qu’elle peut faire, il n’y a pas de Gateway nécessaire) pour remonter l’information vers le serveur, et donc la base de données.

GSM : Si Racine connectée à Serveur -> No GSM + Gateway
Else : GSM + Gateway : LoRa Racine connectée ordi (RaspberryPI) + ordi connecté GSM

= Stabilisation et gestion d’erreurs =

== Choix du routage ==

Notre réseau n'est pas un réseau traditionnel. Les seules communications existantes sont soit une remontée d'information vers la racine soit une innondation d'alerte vers les clients. Pour celà nous avons donc décidé d'utiliser un algorithme de routage simplifié basé uniquement sur un arbre en largeur des balises. Nous rajoutons en option la possibilité de créer plusieurs racines et donc plusieurs arbres dont les racines communiquent par gsm. Nous nous basons sur des papiers de recherches afin de déterminer quel algorithme auto-stabilisant est le plus adapté au système LoRa (Tel que le papier "A self-stabilizing algorithm for constructing breadth-first trees" par Shing-Tsaan Huang, Nian-Shing Chen).

== Stabilisation ==

Afin de gérer la communication de chaque message vers le serveur, nous allons prendre un noeud (balise LoRa) dit “racine” connecté directement au serveur, nous ne nous occuperons pas de la communication au serveur dans cet onglet. Chaque message reçu de la part d’un noeud du système doit être relayé jusqu’à la racine du système afin de communiquer avec les secours (ou serveur simplement).

Pour cela, il faudra assurer que chaque balise LoRa soit connecté au réseau, afin d’avoir au départ un graphe de communication connexe. Par dessus ce graphe, nous allons utiliser un processus silencieux auto-stabilisant qui construira un arbre de parcours en largeur, avec pour racine le noeud “racine” décidé ci-dessus.

Au lancement du système, il faut prévoir un léger temps de stabilisation, qui dépendrait de l’algorithme et de la taille du graphe (nombre de balises). Cependant, après cela, l’algorithme assure un arbre en profondeur minimal qui nous permettrai de communiquer avec la racine le plus rapidement possible, et donc une qualité de service maximale.

== Gestion d’erreurs ==

Dans un réseau comme celui-ci, plusieurs types d’erreurs peuvent se produire :
Délai de communication trop important vers une balise
“Crash” d’une balise de communication
Surpopulation d’une balise ou congestion de messages

Afin de palier au premier type d’incident rencontré, il faut nécessairement qu’à chaque emplacement dans la zone couverte, l’utilisateur soit à même de communiquer avec au minimum 2 balises différentes. Ainsi, dans le cas d’une communication trop longue sur une balise, l’autre aurait de grandes chances de délivrer le message plus rapidement.

Au niveau de la défaillance d’une balise, l’algorithme d’arbre en profondeur nous fournit déjà une solution intégrée grâce à son auto-stabilisation. Dans le cas de déconnexion d’une balise, l’algorithme mettrai à jour automatiquement l’arbre de communication, et n’importe quel message d’alerte émis serait délivré dans un délai raisonnable.

Pour le troisième cas d’erreur, il n’y aurait pas de solution réelle, si ce n’est de limiter le nombre de communications données, en ne prenant plus en compte les “ping” de chaque utilisateur mais seulement les messages d’alertes, ce qui permettrai une bien plus grande gestion de la congestion à un endroit donné. Également, une balise en dessous d’un lien congestionné pourrait communiquer avec ses autres voisins (non-fils dans l’arbre) afin de libérer de l’espace dans le lien avec son père dans l’arbre. Également, le système ne pourra accepter que jusqu’à 1000 utilisateurs par noeud, et également 4000 utilisateurs par cluster (dans le cas d’un réseau avec plusieurs clusters donc plusieurs racines cette limite augmente).

Plusieurs types de paquets circulent sur le réseau de balise:
Les pings, messages envoyés spontanéments à intervalle régulier par les utilisateur contenant l’id ainsi que les deux coordonées gps (27 bits chacun)
Les incidents, identique à un ping mais à priorité haute.
Les alertes, messages brodcastés par le serveur afin d’envoyer un message en chaine de caractères courts et compressés.

=Coûts matériels=

Que ce soit pour le dispositif utilisateur ou la balise (racine ou non), le LoRaOne correspond pour permettre les actions recherchées. Afin de réaliser un prototype pertinent, 6 kits LoRaOne sont requis. Ces kits sont accessibles sur le site de Sodaq au prix de 115€ chacun (prix variable).
Disponible [https://shop.sodaq.com/en/one-eu-rn2483-v2.html ici], voir avant dernier bundle : starter "ONE EU starter" actuellement à 112,10€.

Un [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer buzzer] est à ajouter au dispositif utilisateur afin de lui délivrer un signal sonore.

Un shield GSM est requis pour que la balise racine communique avec l'extérieur. Sodaq en propose un designé pour fonctionner sur leurs produits mais est éctuellement en rupture de stock. Un shield GSM arduino convient tout autant et peut être trouvé sur le site arduino [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna ici].

Aucun boitier ne sera commandé car nous avons fait le choix de les manufacturer nous même au fablab. Le besoin d'étanchéité n'est pas primordial pour notre prototype, bien que nous tenterons de l'assurer.

{|class="récap commande"
|+ Récapitulatif
|-
|
!scope="col" style="width: 320px;"| Produit
!scope="col" style="width: 80px;"| Lien
!scope="col" style="width: 80px;"| Quantité
!scope="col" style="width: 80px;"| Prix Unitaire
|-

!scope="row"| 1
| LoRaOne EU Starter
| [https://shop.sodaq.com/en/one-eu-rn2483-v2.html Achat]
| 6
| 115€
|-

!scope="row"| 2
| Buzzer
| [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer Achat]
| 3
| 5.49€
|-

!scope="row"| 3
| Shield GSM
| [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna Achat]
| 1
| 65€
|-

|}

=Développement=

Nous utiliserons les librairies standards Arduino ainsi que celle de SODAQ/Arduino pour le LoRa.

L'IDE Arduino sera utilisé, plus pratique pour l'utilisation de Git (comparé à Mbed).

= Mise sur le marché =

Ce dispositif a pour but d’être utilisé en montagne, lors de randonnée. Il n’est pas destiné à un usage quotidien, c’est pourquoi nous considérons qu’il est plus judicieux de louer les dispositifs plutôt que de les vendre, même si l’achat n’est pas à omettre de notre stratégie.

Le dispositif peut être commandé en ligne, puis retourné par la poste après usage. Le client louerait le dispositif pour une certaine durée avec un possible nombre supplémentaire de batterie. Les tarifs varient en fonction de la durée et du nombre de batteries louées. Des offres de groupes pourraient être applicables. A long terme, des boutiques pourraient être disséminées dans des grandes villes proches des zones montagneuses, zones à randonnées (Grenoble, Annecy, etc.).

L’application est téléchargeable gratuitement par quiconque, mais utilisable seulement par les clients. Un code d’accès sera envoyé avec le dispositif expirant après la fin de la location.

Il faudra tenir compte de la bande passante du LoRa, variante en fonction des continents.

=Planning prévisonnel=

Sprint 1 : 29/01 --> 09/02 : Création du prototype logiciel #1
*Prise en main du matériel
*Premiers tests de transmissions LoRa
*Création du protocole d'architecture des balises
*Application sur les cartes et tests
*Tests de performances des cartes (durabilité, chargement, batterie)
*Tests de maintenabilité de l'algorithme (déconnexions, latences)

Sprint 2 : 12/02 --> 23/02 : Prototype logiciel #2 et prototype matériel
*Création du programme embarqué (utilisateur)
*Communication avec la racine et le serveur
*Création des maquettes boîtier et balise
*Construction des maquettes
*Finalisation du premier prototype

Sprint 3 : 26/02 --> 09/03 : Fonctionnalités supplémentaires
*Ajout de la communication entre le LoRa et le GSM sur la balise racine
*Création application mobile utilisateur
*Tests sur l'application
*Tests sur la transmission totale depuis l'utilisateur vers le serveur via le GSM
*Finalisation du projet

Sprint 4 : 12/03 --> 16/03 : Fin du projet
*Création de la documentation finale (à partir de la documentation réalisée en continu)
*Pause café
*Temps supplémentaire en cas de problèmes importants
*Préparation de la soutenance

R'Montagne

2018-03-15T05:32:20Z

Hugo.Amodru-Favin: /* Collaboration avec le DUT RT et les PEIPs D */

=Équipe=
{|class="wikitable"
|-
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Rôle
|-
| Hugo Amodru-Favin
| Chef de Projet
|-
| Antoine Delise
| Lead Developer
|-
| Gwenaël Moreau
| Kanban Master
|-

|}

==Tâches==

Répartition générale des tâches
{|class="wikitable"
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Tâche
|-
| Hugo Amodru-Favin
| Application Ionic
|-
| Antoine Delise
| Développement Arduino
|-
| Gwenaël Moreau
| BDD - API
|-

|}

Détail des tâches : [https://waffle.io/delisea/R-Montagne Waffle.io]

=Journal=

{|class="wikitable"
|+
|-
!scope="col" width="120px"| Date
!scope="col" width="350px"| Hugo AMODRU-FAVIN
!scope="col" width="350px"| Antoine DELISE
!scope="col" width="350px"| Gwenaël MOREAU
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 1
|-

|-
| rowspan="1" | Lundi 29/01/18
| style="width: 225px;" |
* Ré-assimilation du sujet
| style="width: 225px;" |
* Ré-assimilation du sujet
| style="width: 225px;" |
* Ré-assimilation du sujet
* Mise en place d'un Kanban
|-
| rowspan="1" | Mardi 30/01/18
| style="width: 225px;" |
* Mise à jour de la page AIR
* Réflexions sur l'implémentation du LoRa
| style="width: 225px;" |
* Mise à jour de la page AIR
* Réflexions sur l'implémentation du LoRa
| style="width: 225px;" |
* Mise en place du calendrier prévisionnel
* Définition et répartition des tâches
|-
| rowspan="1" | Mercredi 31/01/18
| style="width: 225px;" |
* Récupération des cartes Semtech
* Présentation du Hackathon Vinci Energies
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Récupération des cartes Semtech
* Présentation du Hackathon Vinci Energies
* Prise en main des cartes LoRa
* Recherche d'un environnement de programmation gratuit utilisable pour le projet
| style="width: 225px;" |
* Récupération et prise en main des cartes Semtech LoRaMote
* Présentation du Hackathon Vinci Energies
|-
| rowspan="1" | Jeudi 01/02/18
| style="width: 225px;" |
* Choix des fonctionnalités de l'application mobile
| style="width: 225px;" |
* Prise en main des cartes LoRa
* Recherche d'un environnement de programmation gratuit utilisable pour le projet
| style="width: 225px;" |
* Prise en main des cartes LoRa
|-
| rowspan="1" | Vendredi 02/02/18
| style="width: 225px;" |
* Réflexions sur l'implémentation de l'application
* Démarrage de l'application mobile
* Mises à jour d'Ionic, de Android Studio
| style="width: 225px;" |
* Premières communications fructueuses des cartes Semtech LoRaMote
* Recherche d'un environnement de programmation gratuit utilisable pour le projet
| style="width: 225px;" |
* Premières communications fructueuses des cartes Semtech LoRaMote
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 2
|-

|-
| rowspan="1" | Lundi 05/02/18
| style="width: 225px;" |
* Configuration Login et Mot de Passe, Identification base
| style="width: 225px;" |
* Prise en main des cartes LoRa, premiers programme Lora
* Atolic TrueStudio semble correspondre à nos attentes
| style="width: 225px;" |
* Réflexion et création de la base de données
|-
| rowspan="1" | Mardi 06/02/18
| style="width: 225px;" |
* Configuration Login, Mot de passe
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
* Routage statique In Progress
| style="width: 225px;" |
* Création de l'API REST EN PHP
|-
| rowspan="1" | Mercredi 07/02/18
| style="width: 225px;" |
* Réunion avec Rémi CHOLLET et 3 PEIP D
* Assimilation du fonctionnement de Leaflet
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
* écritude d'une librairie de buffer cyclique à taille variable pour manipuler des paquets
| style="width: 225px;" |
* Réunion avec Rémi CHOLLET et 3 PEIP D
* Création de l'API REST en PHP
|-
| rowspan="1" | Jeudi 08/02/18
| style="width: 225px;" |
* Ajout de marqueurs sur Leaflet
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
* Routage statique fonctionnel
| style="width: 225px;" |
* Création de l'API REST EN PHP
|-
| rowspan="1" | Vendredi 09/02/18
| style="width: 225px;" |
* Hackathon Vinci Energies
| style="width: 225px;" |
* Hackathon Vinci Energies
| style="width: 225px;" |
* Hackathon Vinci Energies
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 3
|-

|-
| rowspan="1" | Lundi 12/02/18
| style="width: 225px;" |
* Préparation Soutenance
| style="width: 225px;" |
* Mise en place d'un Contiki/Cooja pour faciliter le développement
* Importation des librairie et début débogage
| style="width: 225px;" |
* Préparation Soutenance
|-
| rowspan="1" | Mardi 13/02/18
| style="width: 225px;" |
* Mise à jour de AIR
* Préparation Soutenance
* Répétition soutenance
| style="width: 225px;" |
* Préparation Soutenance
* Répétition soutenance
* Mise en place d'un Contiki/Cooja pour faciliter le dévelloppement
* Fin du débogage de l'importation des librairies
| style="width: 225px;" |
* Préparation Soutenance
* Répétition soutenance
|-
| rowspan="1" | Mercredi 14/02/18
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
|-
| rowspan="1" | Jeudi 15/02/18
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
|-
| rowspan="1" | Vendredi 16/02/18
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
|-
| rowspan="1" | Interruption de Février
| style="width: 225px;" |
| style="width: 225px;" |
* Développement sur Contiki/Cooja afin de réaliser un routage dynamique
| style="width: 225px;" |
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 4
|-

|-
| rowspan="1" | Lundi 26/02/18
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Travail sur l'affichage des éléments sur la carte utilisateur
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Continuation du travail sur Contiki
* Le routage dynamique fonctionne
* Il reste des imprécision à corriger pour améliorer la communication
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Corrections de l'API en accord avec l'application mobile
* Modifications sur la base de données
|-
| rowspan="1" | Mardi 27/02/18
| style="width: 225px;" |
* Création de la page de création d'un nouvel utilisateur
* Design de l'application mobile
| style="width: 225px;" |
* Fin du protocole de routage Contiki, tests virtuels de fonctionnement
* Le routage dynamique fonctionne sur des réseaux complexes
| style="width: 225px;" |
* Liaison entre l'application mobile et l'API
|-
| rowspan="1" | Mercredi 28/02/18
| style="width: 225px;" |
* Fin de la page de création d'un nouvel utilisateur
* Ajout de l'utilisation des sessions dans l'application
| style="width: 225px;" |
* Panne ordinateur personnel
* Perte des données du routage dynamique malgré une tentative de back-up avant la panne
* Travail sur l'application mobile avec Hugo
| style="width: 225px;" |
* API : Création d'un utilisateur
* API : Récupération des informations nécessaires pour la carte
* API : Ajout de l'utilisation des sessions pour stocker l'utilisateur connecté
|-
| rowspan="1" | Jeudi 01/03/18
| style="width: 225px;" |
* Affichage des informations sur la Map
| style="width: 225px;" |
* Affichage des informations sur la Map
* Tentative de récupération ordinnateur et données (échec)
| style="width: 225px;" |
* API : Récupération des informations nécessaires pour la carte
|-
| rowspan="1" | Vendredi 02/03/18
| style="width: 225px;" |
* Listing des futures tâches à implémenter dans l'application
* Réunion et préparation rendez-vous avec M.Donsez
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Réparation d'ordinateur personnel, de nouveau pleinement opérationnel mais toutes les données ont été perdues
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Renseignements sur Swagger
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 5
|-

|-
| rowspan="1" | Lundi 05/03/18
| style="width: 225px;" |
* Restructuration de l'application, amélioration visuelle
* Logout fonctionnel
| style="width: 225px;" |
* Finalisation de la carte, et ajout de la gestion des différentes cartes
* Restructuration de l'application
| style="width: 225px;" |
* Création d'une page Swagger
* Corrections de l'API
* Ajout des cartes dans la base de données
* Récupération des éléments liés à la carte dans l'API
|-
| rowspan="1" | Mardi 06/03/18
| style="width: 225px;" |
* Ajout gestion secouriste
* Développement de la page Account, modification utilisateur
| style="width: 225px;" |
* Ajout gestion secouriste
* Création vues côté secouristes
| style="width: 225px;" |
* Fin du Swagger
* API : Modifications utilisateur
* API : Modifications mot de passe
* Base de données : Ajout affectations secouristes-cartes
* API : Récupération des cartes pour un secouriste
|-
| rowspan="1" | Mercredi 07/03/18
| style="width: 225px;" |
* Amélioration et finalisation de la page Account
| style="width: 225px;" |
* Corrections du menu et de la navigation
| style="width: 225px;" |
* Programme de récupération des messages à la racine et inscription des données dans la base de données
|-
| rowspan="1" | Jeudi 08/03/18
| style="width: 225px;" |
* Extraction des dents de sagesse
| style="width: 225px;" |
* Menu dynamique, permet de gérer plusieurs map
* Création de la page de compte
* Modification et débogage du système de navigation
| style="width: 225px;" |
* Création du programme de communication LoRa et récupération des coordonnées GPS depuis la carte SodaqONE
* Tests de temps de synchronisation et précision du GPS
|-
| rowspan="1" | Vendredi 09/03/18
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Design du LogoV2, Embellie CSS de l'application mobile
* Réunion avec les PEIP D
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Un peu de Sodaq
* Ajout de filtre
* Nouveau déploiement sur le PlayStore
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Finition du programme de communication LoRa
* Tests d'envoi de la carte SodaqONE vers la base de données en passant par une racine (carte Arduino LoRa)
|-
| rowspan="1" | Samedi 10/03/18
| style="width: 225px;" |
* Réflexions et implémentations des Usercases concernant la gestion des licences
* Ajout de notifications mobiles
* Ajout d'une page liée à la gestion des Trackers
* Début du Poster Anniversaire
| style="width: 225px;" |
* Réflexions et implémentations des Usercases concernant la gestion des licences
* Ajout de notifications mobiles
| style="width: 225px;" |
* Tests du programme de communication avec les LoRas
|-
| rowspan="1" | Dimanche 11/03/18
| style="width: 225px;" |
* Implémentations des usercases liées à la gestion des licences côté application
* Système de notification automatique (FireBase)
| style="width: 225px;" |
* Implémentations des usercases liées à la gestion des licences côté api
* Système de notification automatique (FireBase)
| style="width: 225px;" |
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 6
|-

|-
| rowspan="1" | Lundi 12/03/18
| style="width: 225px;" |
* Ajouts de fonctionnalités dans l'application
| style="width: 225px;" |
* Correctifs programme de communication
* ébauche de l'interface d'administration (édition automatique)
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Correctifs programme de communication
|-
| rowspan="1" | Mardi 13/03/18
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Finalisation des fonctionnalités de l'application
* Correctifs des bugs
* Test Réel à la Bastille
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Finalisation des fonctionnalités de l'application
* Correctifs des bugs
* Page de création de Map Admin
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Préparation des capteurs pour le test réel
* Test Réel à la Bastille
|-
| rowspan="1" | Mercredi 14/03/18
| style="width: 225px;" |
* Préparation de la soutenance
* Remplissage de la BDD
* Finalisation du Poster
* Test Réel aux Taillées
| style="width: 225px;" |
* Préparation de la soutenance
* Préparation de la démonstration
* Dernier correctifs de l'application
| style="width: 225px;" |
* Préparation de la soutenance
* Finalisation du Poster
* Test Réel aux Taillées
|-
| rowspan="1" | Jeudi 15/03/18
| style="width: 225px;" |
* Soutenance de Projet
| style="width: 225px;" |
* Soutenance de Projet
| style="width: 225px;" |
* Soutenance de Projet
|-
| rowspan="1" | Vendredi 16/03/18
| style="width: 225px;" |
* 16 Ans de la filière RICM : Présentation du travail effectué
| style="width: 225px;" |
* 16 Ans de la filière RICM : Présentation du travail effectué
| style="width: 225px;" |
* 16 Ans de la filière RICM : Présentation du travail effectué
|}

=Métriques Logicielles=

Langages :
Ionic (TypeScript, HTML, CSS)
C++
PHP
Java

Lignes de code :
Application mobile : ~3000
API + Swagger : ~2000
LoRa : ~150
Routage : ~300

Cocomo (complexité P semidetached) :
Effort = 3 * 5,1501,12 = 18,8 mois homme
TDev = 2,5 * Effort0,35 = 7 mois

Temps ingénieur :
180h par personne
6400€ brut coûtant par personne et par mois
Coût du projet : 23500€

=Collaboration avec le DUT RT et les PEIPs D=
L'objectif de cette collaboration est de familiariser des étudiants en PEIP D avec des projets qu'ils seront amenés à développer dans les prochaines années. Nous avons rencontré Rémi CHOLLET et 3 étudiants Mercredi 7 Février, en voici un résumé écrit par Mr CHOLLET définissant les contours de cette collaboration.

"Un rapide résumé de la rencontre que nous avons eu ce matin avec le projet R’Montagne.

Présents :
- RCIM5 Gwenael Moreau, Hugo Amodru-Favin
- PEIP-D : Yoann Goma-Missamou, Vincent Cadoux, Philippe Charrat
- IUT : Rémy Chollet, tuteur pédagogique des PEIP-D
Excusés : Didier Donsez, blessé (aie ! courage …), Antoine Delise en cours de marketing

Contexte :
Les PEIP-D participent aux projets RICM5 en prenant une tâche « annexe » (hors chemin critique) en charge. L’objectif est une expérience d’immersion + notation liée au PEIP.

Déroulé :
Les étudiant RCIM5 ont présenté le projet dans son principe et état d’avancement. Les échanges se sont portés sur l’idée de mener une étude (simulation et mesure) sur la consommation des balises par les PEIP-D avec pour objectif de dimensionner la réserve d’énergie.

Ceci implique :
- coté RCIM5 : mise à disposition d’une carte prototype.

- cote PEIP-D : inventaire des paramètres à prendre en compte :
* consommation carte (GPS + puce LoRa) = > veille + temps d’activation (recherche à faire sur le temps de synchronisation du GPS)
* puissance d’émission à calibrer en fonction de la couverture voulue et débit (voir Spread Factor ?)
* temps d’émission-réception (émission jusqu’à acquittement)

- cote PEIP-D : penser la manip pour valider ce modèle
* mesure moyenne du courant
* configuration effective du réseau
* réserver le matériel (voir Jean-Yves Frau au département R&T ?)

- cote PEIP-D : paramètrer les simulations et mesures en fonction de puissance d’émission (ou autre élément pouvant apparaitre comme pertinent)

D’une manière générale, pour les PEID-D :
- penser bibliographie (pour commencer : https://fr.wikipedia.org/wiki/LoRaWAN et aussi https://fr.wikipedia.org/wiki/Format_des_piles_et_accumulateurs_électriques :-) )
- planifier
- communiquer : reporting !!!"

=Description du sujet=

==Randonnée et risques==

Ouvert à tous, la randonnée est un sport et un loisir qui prend de plus en plus d’ampleur de nos jours. Ne nécessitant pas de grands prérequis, des milliers de personnes se lancent en montagne chaque jour, malheureusement parfois sans connaître toutes les mesures de sécurité associées.

En effet, de janvier à juin 2016, en randonnée et en alpinisme, l’Association Nationale pour l’Étude de la Neige et des Avalanches (ANENA) a comptabilisé 21 accidents notables, dont 8 accidents mortels, impliquant 15 décès.

Aujourd’hui, les mesures de sécurités préconisent que chaque groupe de randonneur se doivent de se munir d’un téléphone portable afin d’appeler les secours en cas de problème. Malheureusement, la communication mobile dépendant de la couverture réseau, peu présente en montagne, l’impossibilité de joindre les secours reste un problème.

==Solutions existantes==

La solution la plus répandue, est celle du téléphone à connexion satellite. Ayant une communication vers les satellites, cela permet une couverture réseau beaucoup plus répandue dans les montagnes, partout dans le monde (ou presque). Cependant, les téléphones portables satellitaires coûtent chers, et ne sont pas forcément abordables par la plupart des personnes, surtout celles ne sortant qu’occasionnellement.

[https://fall-alarm.net/ Fall Alarm] est un système de détection de chute sur chantier utilisant les mêmes technologies dont nous avons besoin pour notre projet.

==Quelles zones géographiques ?==

Toutes les zones montagneuses peuvent présenter des zones blanches, démunies de connexion quelconque autre que les connexions satellitaires. Certaines chaînes de montagne comme la Cordillaire des Andes ne présentent aucune connexion possible quelconque.

Dans le cadre de notre projet, nous fonctionnerons essentiellement dans la localisation grenobloise avec l'objectif que notre solution soit applicable partout dans le monde. Une contrainte intervient tout de même étant donnée que la fréquence d'utilisation du LoRa en Europe est de 868MHz, 915MHz en Amérique et 433MHz en Asie.

= Fonctionnalités =

Afin de remplir au mieux ses attentes, le principal objectif de ce dispositif sera premièrement de pouvoir communiquer avec les secours à n’importe quel moment, et surtout n’importe où. De plus, il sera capable de détecter de nombreux cas de détresse de la part de l’usager afin de pouvoir lancer un appel d’urgence sans interaction avec l’usager, au cas où il serait inconscient, ou incapable de lancer un appel manuel.

Grâce aux accéléromètres, le dispositif sera à même de détecter un mouvement brutal du randonneur, ce qui pourrait s’apparenter à une chute. Ils pourront également détecter une position anormale, ou une immobilité prolongée, ce qui déclencherait le dispositif d’urgence automatiquement.

Grâce à des tests réalisés au préalable, le boîtier pourra détecter correctement les chûtes de simples mouvements, afin de ne pas lancer l’appel sans raison valable.

Avant de lancer une alerte automatique, le dispositif émettra un signal auditif et visuel à l’utilisateur quelques secondes auparavant, afin de le prévenir l'émission du signal d’urgence, et de lui proposer de le désactiver sur simple pression d’un bouton, afin d’éviter les communications inutiles.

Également, le randonneur sera à même d'émettre volontairement un appel d’urgence à l’aide du bouton, ce qui permet à tout moment d’appeler de l’aide sans effort. Cela peut permettre également à appeler les secours pour une personne en danger qui ne porterait pas le dispositif.

L’appel au secours se représente par un envoi de coordonnées GPS aux secours, via une communication radio LoRa vers des bornes relais placées au préalables en montagne. Cette communication irait de relai de relai jusqu’au centre de sécurité, d’où le message serait transmis aux secours.

De plus, une application mobile verra le jour afin de connecter tous les utilisateurs du module de sécurité, de les visualiser sur une map, et de partager leurs données. En effet, à chaque incident, l’application mettra à jour la position et de la date de l’accident, afin de permettre aux prochains utilisateurs d’être prévenus. Ils pourraient, s'ils sont à proximité, d'assister la personne en détresse en attendant l'arrivée des secours. Bien évidemment, cette application ne sera accessible uniquement si le smartphone de l'utilisateur est relié à une connexion 4G ou Wi-Fi.

Cette prévention pourrait les sensibiliser aux risques de la montagne, leur permettre d’éviter le secteur mais aussi d’aider les personnes en danger si la distance le permet.

= Exigences =
== Fonctionnelles ==

*Batterie garantie fonctionnelle 1 semaine
*Rechargement possible via le panneau solaire portable
*Dispositif pouvant être allumé et éteint par l'utilisateur
*Alarme s’enclenche automatiquement dès qu'elle est considérée nécessaire, signal sonore
*Utilisateur a la possibilité d’activer/désactiver l’alarme quand il le souhaite
*Lorsque l’alarme est active, l’appareil ne peut s’éteindre
*...

== Non-Fonctionnelles ==

*Résistance : aux chocs, impacts, waterproof (utilisé en permanence en plein air)
*Disponibilité : Appareil de secours -> Doit être au plus possible performant
*Performance : Minimiser les pertes réseaux
*Accessible : Utilisateur pas forcément familier avec des appareils électroniques (facile d’utilisation)
*Fiabilité : Précision du GPS (rayon de 10m), données non-éronnées
*Coût : Le plus faible possible pour vendre le moins cher possible
*Efficacité : Réduire la consommation, utiliser le moins possible les ressources

= Composants =
== LoRaONE ==
Pour le coeur du projet, après avoir cherché et comparés plusieurs modules LoRa, GPS ou encore accéléromètres, nous avons finalement opté pour le projet LoRaONE.

LoRaONE est un projet de SODAQ regroupant plusieurs composants dans une seule et même carte, de taille réduite.

https://www.kickstarter.com/projects/sodaq/loraone-the-lora-iot-development-board

“The one IoT development board to rule them all” --SODAQ

Cette carte regroupe plusieurs capteurs afin de respecter aux mieux nos exigences :

Un émetteur/récepteur LoRa afin de pouvoir communiquer au mieux avec les antennes relai à longue distance

Un module + antenne GPS de bonne précision (< 10m) pour connaître en tout temps notre position, et ainsi faciliter l’arrivée des secours, ainsi que la recherche de l’individu en détresse

Un accéléromètre sur 3 axes afin de pouvoir détecter tout mouvement, vitesse ou rotation dans l’espace, ce qui permet la détection de chutes ou d’arrêt de mouvements

3 LED RGB afin de pouvoir signaler à l’utilisateur un manque de batterie, un signal d’urgence ou plus si nécessaire

Un bouton poussoir pour le signal d’alarme

Un connecteur de charge par panneau solaire, afin de faire durer chaque batterie le plus longtemps possible

Un connecteur micro-USB ainsi que des lignes pour se connecter à une base Arduino si besoin

[[File:LoRaOne.png||400px|Spécifications carte LoRaOne]]

De plus, grâce au starter pack, nous pouvons avoir accès à la base ONEBase qui nous permettrait d’étendre plus loin la facilité d’utilisation du produit :

[[File:LoRaOneBase.png||400px|Spécifications base LoRaOneBase]]

Comme nous pouvons le voir, cette base nous permettra de connecter la batterie ainsi que le panneau solaire qui sont fournis dans le pack.

Nous pourrons également connecter jusqu’à 4 modules supplémentaires.

La batterie fournie aura une capacité de 800 mAh, le panneau solaire fourni pouvant délivrer jusqu’à 500 mW de puissance.

Le total atteint une taille d’environ 10*5 cm, ce qui n’est pas excessif, ce qui le rend aisément portatif sur une jambe ou à la taille.

'''Coût : 115€'''

Ce module pourra également servir d’antenne relai, l'alimentation solaire devrait maintenir le dispositif chargé en permanence. Des tests seront effectués pour savoir si un panneau solaire plus puissant est requis.

== Boîtier ==

Le boîtier sécurisé devant respecter plusieurs exigences, nous pouvons le construire en plastique résistant, ce qui le rendrait léger tout en respectant une rigidité suffisante. Les antennes pourront être placées le long du boîtier, à l’intérieur si la connexion est suffisante, ou à l’extérieur. Dans ce dernier cas les trous réalisés sur le boîtier afin de laisser passer les câbles seront colmatés afin de garantir une étanchéité.

[[File:SchemaBoitier.png||100px|Schéma boitier d'alarme]]

== Balises ==

Afin de remonter les informations transmises par les boitiers, des balises seront mises en places sur la zone à couvrir, leur nombre et leur positions dépendra du terrain (obstacles, dénivelés). On distinguera deux types de balises. Tout d’abord, les balises racines qui permettront une communication GSM afin de faire remonter les données vers le serveur. Viennent ensuite les balises standard qui se contenteront de faire remonter vers leur balise racine associée. L’architecture de liaison des balises est détaillée dans une prochaine partie.

Chaque balise est composée d’une barre de fer pouvant être plantée dans le sol, d’un système de lest afin d’immobiliser la balise, d’un paratonnerre, d’un panneau solaire ainsi que d’un LoraOne et d’une batterie. Les balises racines seront équippée en plus d’un dispositif de communication GSM (téléphone portable, émetteur GSM).

[[File:SchemaBalise.png||150px|Schéma balises d'alarme]]

== Application mobile ==
Une application mobile est téléchargeable par les utilisateurs. Ils peuvent voir les autres utilisateurs présents dans leur zone. Lorsqu’un utilisateur est en position de danger, une notification apparaît si les utilisateurs sont proches de la situation de danger.

Cette application n’est pas directement reliée au dispositif. Elle ne fonctionne qu’avec la connexion du mobile, et est destinée à être un niveau de sécurité supérieur. Un randonneur proche d’une zone de danger pourrait arriver sur place plus rapidement que les secours.

= Communication =

Pour un envoi de position + numéro d’identification (X chiffres) :

*Temps de communication : < 2 s
*Communication régulière, intervalle de 15 minutes

On peut donc au maximum avoir 15 * 60 / 2 = 450 individus pouvant communiquer avec la même antenne relai, donc dans le même cercle d’environ 15 km de diamètre.

On communique donc au minimum 2 secondes sur 15 minutes, donc 1/450 << 1%, le temps de communication est respecté.

En cas de problème, nous pouvons envoyer jusqu’à 9x plus avec la borne sans dépasser le temps de communication autorisé (1%). Donc 1 envoi d’appel d’urgence toutes les 2 minutes environ.

La balise racine peut être directement connectée au serveur, dans ce cas, il n’y a pas de communication GSM nécessaire et pas de Gateway. Si la racine n’est pas directement connectée au serveur, elle devra au minimum garantir une communication GSM (ce qu’elle peut faire, il n’y a pas de Gateway nécessaire) pour remonter l’information vers le serveur, et donc la base de données.

GSM : Si Racine connectée à Serveur -> No GSM + Gateway
Else : GSM + Gateway : LoRa Racine connectée ordi (RaspberryPI) + ordi connecté GSM

= Stabilisation et gestion d’erreurs =

== Choix du routage ==

Notre réseau n'est pas un réseau traditionnel. Les seules communications existantes sont soit une remontée d'information vers la racine soit une innondation d'alerte vers les clients. Pour celà nous avons donc décidé d'utiliser un algorithme de routage simplifié basé uniquement sur un arbre en largeur des balises. Nous rajoutons en option la possibilité de créer plusieurs racines et donc plusieurs arbres dont les racines communiquent par gsm. Nous nous basons sur des papiers de recherches afin de déterminer quel algorithme auto-stabilisant est le plus adapté au système LoRa (Tel que le papier "A self-stabilizing algorithm for constructing breadth-first trees" par Shing-Tsaan Huang, Nian-Shing Chen).

== Stabilisation ==

Afin de gérer la communication de chaque message vers le serveur, nous allons prendre un noeud (balise LoRa) dit “racine” connecté directement au serveur, nous ne nous occuperons pas de la communication au serveur dans cet onglet. Chaque message reçu de la part d’un noeud du système doit être relayé jusqu’à la racine du système afin de communiquer avec les secours (ou serveur simplement).

Pour cela, il faudra assurer que chaque balise LoRa soit connecté au réseau, afin d’avoir au départ un graphe de communication connexe. Par dessus ce graphe, nous allons utiliser un processus silencieux auto-stabilisant qui construira un arbre de parcours en largeur, avec pour racine le noeud “racine” décidé ci-dessus.

Au lancement du système, il faut prévoir un léger temps de stabilisation, qui dépendrait de l’algorithme et de la taille du graphe (nombre de balises). Cependant, après cela, l’algorithme assure un arbre en profondeur minimal qui nous permettrai de communiquer avec la racine le plus rapidement possible, et donc une qualité de service maximale.

== Gestion d’erreurs ==

Dans un réseau comme celui-ci, plusieurs types d’erreurs peuvent se produire :
Délai de communication trop important vers une balise
“Crash” d’une balise de communication
Surpopulation d’une balise ou congestion de messages

Afin de palier au premier type d’incident rencontré, il faut nécessairement qu’à chaque emplacement dans la zone couverte, l’utilisateur soit à même de communiquer avec au minimum 2 balises différentes. Ainsi, dans le cas d’une communication trop longue sur une balise, l’autre aurait de grandes chances de délivrer le message plus rapidement.

Au niveau de la défaillance d’une balise, l’algorithme d’arbre en profondeur nous fournit déjà une solution intégrée grâce à son auto-stabilisation. Dans le cas de déconnexion d’une balise, l’algorithme mettrai à jour automatiquement l’arbre de communication, et n’importe quel message d’alerte émis serait délivré dans un délai raisonnable.

Pour le troisième cas d’erreur, il n’y aurait pas de solution réelle, si ce n’est de limiter le nombre de communications données, en ne prenant plus en compte les “ping” de chaque utilisateur mais seulement les messages d’alertes, ce qui permettrai une bien plus grande gestion de la congestion à un endroit donné. Également, une balise en dessous d’un lien congestionné pourrait communiquer avec ses autres voisins (non-fils dans l’arbre) afin de libérer de l’espace dans le lien avec son père dans l’arbre. Également, le système ne pourra accepter que jusqu’à 1000 utilisateurs par noeud, et également 4000 utilisateurs par cluster (dans le cas d’un réseau avec plusieurs clusters donc plusieurs racines cette limite augmente).

Plusieurs types de paquets circulent sur le réseau de balise:
Les pings, messages envoyés spontanéments à intervalle régulier par les utilisateur contenant l’id ainsi que les deux coordonées gps (27 bits chacun)
Les incidents, identique à un ping mais à priorité haute.
Les alertes, messages brodcastés par le serveur afin d’envoyer un message en chaine de caractères courts et compressés.

=Coûts matériels=

Que ce soit pour le dispositif utilisateur ou la balise (racine ou non), le LoRaOne correspond pour permettre les actions recherchées. Afin de réaliser un prototype pertinent, 6 kits LoRaOne sont requis. Ces kits sont accessibles sur le site de Sodaq au prix de 115€ chacun (prix variable).
Disponible [https://shop.sodaq.com/en/one-eu-rn2483-v2.html ici], voir avant dernier bundle : starter "ONE EU starter" actuellement à 112,10€.

Un [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer buzzer] est à ajouter au dispositif utilisateur afin de lui délivrer un signal sonore.

Un shield GSM est requis pour que la balise racine communique avec l'extérieur. Sodaq en propose un designé pour fonctionner sur leurs produits mais est éctuellement en rupture de stock. Un shield GSM arduino convient tout autant et peut être trouvé sur le site arduino [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna ici].

Aucun boitier ne sera commandé car nous avons fait le choix de les manufacturer nous même au fablab. Le besoin d'étanchéité n'est pas primordial pour notre prototype, bien que nous tenterons de l'assurer.

{|class="récap commande"
|+ Récapitulatif
|-
|
!scope="col" style="width: 320px;"| Produit
!scope="col" style="width: 80px;"| Lien
!scope="col" style="width: 80px;"| Quantité
!scope="col" style="width: 80px;"| Prix Unitaire
|-

!scope="row"| 1
| LoRaOne EU Starter
| [https://shop.sodaq.com/en/one-eu-rn2483-v2.html Achat]
| 6
| 115€
|-

!scope="row"| 2
| Buzzer
| [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer Achat]
| 3
| 5.49€
|-

!scope="row"| 3
| Shield GSM
| [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna Achat]
| 1
| 65€
|-

|}

=Développement=

Nous utiliserons les librairies standards Arduino ainsi que celle de SODAQ/Arduino pour le LoRa.

L'IDE Arduino sera utilisé, plus pratique pour l'utilisation de Git (comparé à Mbed).

= Mise sur le marché =

Ce dispositif a pour but d’être utilisé en montagne, lors de randonnée. Il n’est pas destiné à un usage quotidien, c’est pourquoi nous considérons qu’il est plus judicieux de louer les dispositifs plutôt que de les vendre, même si l’achat n’est pas à omettre de notre stratégie.

Le dispositif peut être commandé en ligne, puis retourné par la poste après usage. Le client louerait le dispositif pour une certaine durée avec un possible nombre supplémentaire de batterie. Les tarifs varient en fonction de la durée et du nombre de batteries louées. Des offres de groupes pourraient être applicables. A long terme, des boutiques pourraient être disséminées dans des grandes villes proches des zones montagneuses, zones à randonnées (Grenoble, Annecy, etc.).

L’application est téléchargeable gratuitement par quiconque, mais utilisable seulement par les clients. Un code d’accès sera envoyé avec le dispositif expirant après la fin de la location.

Il faudra tenir compte de la bande passante du LoRa, variante en fonction des continents.

=Planning prévisonnel=

Sprint 1 : 29/01 --> 09/02 : Création du prototype logiciel #1
*Prise en main du matériel
*Premiers tests de transmissions LoRa
*Création du protocole d'architecture des balises
*Application sur les cartes et tests
*Tests de performances des cartes (durabilité, chargement, batterie)
*Tests de maintenabilité de l'algorithme (déconnexions, latences)

Sprint 2 : 12/02 --> 23/02 : Prototype logiciel #2 et prototype matériel
*Création du programme embarqué (utilisateur)
*Communication avec la racine et le serveur
*Création des maquettes boîtier et balise
*Construction des maquettes
*Finalisation du premier prototype

Sprint 3 : 26/02 --> 09/03 : Fonctionnalités supplémentaires
*Ajout de la communication entre le LoRa et le GSM sur la balise racine
*Création application mobile utilisateur
*Tests sur l'application
*Tests sur la transmission totale depuis l'utilisateur vers le serveur via le GSM
*Finalisation du projet

Sprint 4 : 12/03 --> 16/03 : Fin du projet
*Création de la documentation finale (à partir de la documentation réalisée en continu)
*Pause café
*Temps supplémentaire en cas de problèmes importants
*Préparation de la soutenance

R'Montagne

2018-03-15T05:30:41Z

Hugo.Amodru-Favin: /* Journal */

=Équipe=
{|class="wikitable"
|-
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Rôle
|-
| Hugo Amodru-Favin
| Chef de Projet
|-
| Antoine Delise
| Lead Developer
|-
| Gwenaël Moreau
| Kanban Master
|-

|}

==Tâches==

Répartition générale des tâches
{|class="wikitable"
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Tâche
|-
| Hugo Amodru-Favin
| Application Ionic
|-
| Antoine Delise
| Développement Arduino
|-
| Gwenaël Moreau
| BDD - API
|-

|}

Détail des tâches : [https://waffle.io/delisea/R-Montagne Waffle.io]

=Journal=

{|class="wikitable"
|+
|-
!scope="col" width="120px"| Date
!scope="col" width="350px"| Hugo AMODRU-FAVIN
!scope="col" width="350px"| Antoine DELISE
!scope="col" width="350px"| Gwenaël MOREAU
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 1
|-

|-
| rowspan="1" | Lundi 29/01/18
| style="width: 225px;" |
* Ré-assimilation du sujet
| style="width: 225px;" |
* Ré-assimilation du sujet
| style="width: 225px;" |
* Ré-assimilation du sujet
* Mise en place d'un Kanban
|-
| rowspan="1" | Mardi 30/01/18
| style="width: 225px;" |
* Mise à jour de la page AIR
* Réflexions sur l'implémentation du LoRa
| style="width: 225px;" |
* Mise à jour de la page AIR
* Réflexions sur l'implémentation du LoRa
| style="width: 225px;" |
* Mise en place du calendrier prévisionnel
* Définition et répartition des tâches
|-
| rowspan="1" | Mercredi 31/01/18
| style="width: 225px;" |
* Récupération des cartes Semtech
* Présentation du Hackathon Vinci Energies
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Récupération des cartes Semtech
* Présentation du Hackathon Vinci Energies
* Prise en main des cartes LoRa
* Recherche d'un environnement de programmation gratuit utilisable pour le projet
| style="width: 225px;" |
* Récupération et prise en main des cartes Semtech LoRaMote
* Présentation du Hackathon Vinci Energies
|-
| rowspan="1" | Jeudi 01/02/18
| style="width: 225px;" |
* Choix des fonctionnalités de l'application mobile
| style="width: 225px;" |
* Prise en main des cartes LoRa
* Recherche d'un environnement de programmation gratuit utilisable pour le projet
| style="width: 225px;" |
* Prise en main des cartes LoRa
|-
| rowspan="1" | Vendredi 02/02/18
| style="width: 225px;" |
* Réflexions sur l'implémentation de l'application
* Démarrage de l'application mobile
* Mises à jour d'Ionic, de Android Studio
| style="width: 225px;" |
* Premières communications fructueuses des cartes Semtech LoRaMote
* Recherche d'un environnement de programmation gratuit utilisable pour le projet
| style="width: 225px;" |
* Premières communications fructueuses des cartes Semtech LoRaMote
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 2
|-

|-
| rowspan="1" | Lundi 05/02/18
| style="width: 225px;" |
* Configuration Login et Mot de Passe, Identification base
| style="width: 225px;" |
* Prise en main des cartes LoRa, premiers programme Lora
* Atolic TrueStudio semble correspondre à nos attentes
| style="width: 225px;" |
* Réflexion et création de la base de données
|-
| rowspan="1" | Mardi 06/02/18
| style="width: 225px;" |
* Configuration Login, Mot de passe
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
* Routage statique In Progress
| style="width: 225px;" |
* Création de l'API REST EN PHP
|-
| rowspan="1" | Mercredi 07/02/18
| style="width: 225px;" |
* Réunion avec Rémi CHOLLET et 3 PEIP D
* Assimilation du fonctionnement de Leaflet
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
* écritude d'une librairie de buffer cyclique à taille variable pour manipuler des paquets
| style="width: 225px;" |
* Réunion avec Rémi CHOLLET et 3 PEIP D
* Création de l'API REST en PHP
|-
| rowspan="1" | Jeudi 08/02/18
| style="width: 225px;" |
* Ajout de marqueurs sur Leaflet
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
* Routage statique fonctionnel
| style="width: 225px;" |
* Création de l'API REST EN PHP
|-
| rowspan="1" | Vendredi 09/02/18
| style="width: 225px;" |
* Hackathon Vinci Energies
| style="width: 225px;" |
* Hackathon Vinci Energies
| style="width: 225px;" |
* Hackathon Vinci Energies
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 3
|-

|-
| rowspan="1" | Lundi 12/02/18
| style="width: 225px;" |
* Préparation Soutenance
| style="width: 225px;" |
* Mise en place d'un Contiki/Cooja pour faciliter le développement
* Importation des librairie et début débogage
| style="width: 225px;" |
* Préparation Soutenance
|-
| rowspan="1" | Mardi 13/02/18
| style="width: 225px;" |
* Mise à jour de AIR
* Préparation Soutenance
* Répétition soutenance
| style="width: 225px;" |
* Préparation Soutenance
* Répétition soutenance
* Mise en place d'un Contiki/Cooja pour faciliter le dévelloppement
* Fin du débogage de l'importation des librairies
| style="width: 225px;" |
* Préparation Soutenance
* Répétition soutenance
|-
| rowspan="1" | Mercredi 14/02/18
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
|-
| rowspan="1" | Jeudi 15/02/18
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
|-
| rowspan="1" | Vendredi 16/02/18
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
|-
| rowspan="1" | Interruption de Février
| style="width: 225px;" |
| style="width: 225px;" |
* Développement sur Contiki/Cooja afin de réaliser un routage dynamique
| style="width: 225px;" |
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 4
|-

|-
| rowspan="1" | Lundi 26/02/18
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Travail sur l'affichage des éléments sur la carte utilisateur
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Continuation du travail sur Contiki
* Le routage dynamique fonctionne
* Il reste des imprécision à corriger pour améliorer la communication
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Corrections de l'API en accord avec l'application mobile
* Modifications sur la base de données
|-
| rowspan="1" | Mardi 27/02/18
| style="width: 225px;" |
* Création de la page de création d'un nouvel utilisateur
* Design de l'application mobile
| style="width: 225px;" |
* Fin du protocole de routage Contiki, tests virtuels de fonctionnement
* Le routage dynamique fonctionne sur des réseaux complexes
| style="width: 225px;" |
* Liaison entre l'application mobile et l'API
|-
| rowspan="1" | Mercredi 28/02/18
| style="width: 225px;" |
* Fin de la page de création d'un nouvel utilisateur
* Ajout de l'utilisation des sessions dans l'application
| style="width: 225px;" |
* Panne ordinateur personnel
* Perte des données du routage dynamique malgré une tentative de back-up avant la panne
* Travail sur l'application mobile avec Hugo
| style="width: 225px;" |
* API : Création d'un utilisateur
* API : Récupération des informations nécessaires pour la carte
* API : Ajout de l'utilisation des sessions pour stocker l'utilisateur connecté
|-
| rowspan="1" | Jeudi 01/03/18
| style="width: 225px;" |
* Affichage des informations sur la Map
| style="width: 225px;" |
* Affichage des informations sur la Map
* Tentative de récupération ordinnateur et données (échec)
| style="width: 225px;" |
* API : Récupération des informations nécessaires pour la carte
|-
| rowspan="1" | Vendredi 02/03/18
| style="width: 225px;" |
* Listing des futures tâches à implémenter dans l'application
* Réunion et préparation rendez-vous avec M.Donsez
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Réparation d'ordinateur personnel, de nouveau pleinement opérationnel mais toutes les données ont été perdues
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Renseignements sur Swagger
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 5
|-

|-
| rowspan="1" | Lundi 05/03/18
| style="width: 225px;" |
* Restructuration de l'application, amélioration visuelle
* Logout fonctionnel
| style="width: 225px;" |
* Finalisation de la carte, et ajout de la gestion des différentes cartes
* Restructuration de l'application
| style="width: 225px;" |
* Création d'une page Swagger
* Corrections de l'API
* Ajout des cartes dans la base de données
* Récupération des éléments liés à la carte dans l'API
|-
| rowspan="1" | Mardi 06/03/18
| style="width: 225px;" |
* Ajout gestion secouriste
* Développement de la page Account, modification utilisateur
| style="width: 225px;" |
* Ajout gestion secouriste
* Création vues côté secouristes
| style="width: 225px;" |
* Fin du Swagger
* API : Modifications utilisateur
* API : Modifications mot de passe
* Base de données : Ajout affectations secouristes-cartes
* API : Récupération des cartes pour un secouriste
|-
| rowspan="1" | Mercredi 07/03/18
| style="width: 225px;" |
* Amélioration et finalisation de la page Account
| style="width: 225px;" |
* Corrections du menu et de la navigation
| style="width: 225px;" |
* Programme de récupération des messages à la racine et inscription des données dans la base de données
|-
| rowspan="1" | Jeudi 08/03/18
| style="width: 225px;" |
* Extraction des dents de sagesse
| style="width: 225px;" |
* Menu dynamique, permet de gérer plusieurs map
* Création de la page de compte
* Modification et débogage du système de navigation
| style="width: 225px;" |
* Création du programme de communication LoRa et récupération des coordonnées GPS depuis la carte SodaqONE
* Tests de temps de synchronisation et précision du GPS
|-
| rowspan="1" | Vendredi 09/03/18
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Design du LogoV2, Embellie CSS de l'application mobile
* Réunion avec les PEIP D
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Un peu de Sodaq
* Ajout de filtre
* Nouveau déploiement sur le PlayStore
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Finition du programme de communication LoRa
* Tests d'envoi de la carte SodaqONE vers la base de données en passant par une racine (carte Arduino LoRa)
|-
| rowspan="1" | Samedi 10/03/18
| style="width: 225px;" |
* Réflexions et implémentations des Usercases concernant la gestion des licences
* Ajout de notifications mobiles
* Ajout d'une page liée à la gestion des Trackers
* Début du Poster Anniversaire
| style="width: 225px;" |
* Réflexions et implémentations des Usercases concernant la gestion des licences
* Ajout de notifications mobiles
| style="width: 225px;" |
* Tests du programme de communication avec les LoRas
|-
| rowspan="1" | Dimanche 11/03/18
| style="width: 225px;" |
* Implémentations des usercases liées à la gestion des licences côté application
* Système de notification automatique (FireBase)
| style="width: 225px;" |
* Implémentations des usercases liées à la gestion des licences côté api
* Système de notification automatique (FireBase)
| style="width: 225px;" |
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 6
|-

|-
| rowspan="1" | Lundi 12/03/18
| style="width: 225px;" |
* Ajouts de fonctionnalités dans l'application
| style="width: 225px;" |
* Correctifs programme de communication
* ébauche de l'interface d'administration (édition automatique)
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Correctifs programme de communication
|-
| rowspan="1" | Mardi 13/03/18
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Finalisation des fonctionnalités de l'application
* Correctifs des bugs
* Test Réel à la Bastille
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Finalisation des fonctionnalités de l'application
* Correctifs des bugs
* Page de création de Map Admin
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Préparation des capteurs pour le test réel
* Test Réel à la Bastille
|-
| rowspan="1" | Mercredi 14/03/18
| style="width: 225px;" |
* Préparation de la soutenance
* Remplissage de la BDD
* Finalisation du Poster
* Test Réel aux Taillées
| style="width: 225px;" |
* Préparation de la soutenance
* Préparation de la démonstration
* Dernier correctifs de l'application
| style="width: 225px;" |
* Préparation de la soutenance
* Finalisation du Poster
* Test Réel aux Taillées
|-
| rowspan="1" | Jeudi 15/03/18
| style="width: 225px;" |
* Soutenance de Projet
| style="width: 225px;" |
* Soutenance de Projet
| style="width: 225px;" |
* Soutenance de Projet
|-
| rowspan="1" | Vendredi 16/03/18
| style="width: 225px;" |
* 16 Ans de la filière RICM : Présentation du travail effectué
| style="width: 225px;" |
* 16 Ans de la filière RICM : Présentation du travail effectué
| style="width: 225px;" |
* 16 Ans de la filière RICM : Présentation du travail effectué
|}

=Collaboration avec le DUT RT et les PEIPs D=
L'objectif de cette collaboration est de familiariser des étudiants en PEIP D avec des projets qu'ils seront amenés à développer dans les prochaines années. Nous avons rencontré Rémi CHOLLET et 3 étudiants Mercredi 7 Février, en voici un résumé écrit par Mr CHOLLET définissant les contours de cette collaboration.

"Un rapide résumé de la rencontre que nous avons eu ce matin avec le projet R’Montagne.

Présents :
- RCIM5 Gwenael Moreau, Hugo Amodru-Favin
- PEIP-D : Yoann Goma-Missamou, Vincent Cadoux, Philippe Charrat
- IUT : Rémy Chollet, tuteur pédagogique des PEIP-D
Excusés : Didier Donsez, blessé (aie ! courage …), Antoine Delise en cours de marketing

Contexte :
Les PEIP-D participent aux projets RICM5 en prenant une tâche « annexe » (hors chemin critique) en charge. L’objectif est une expérience d’immersion + notation liée au PEIP.

Déroulé :
Les étudiant RCIM5 ont présenté le projet dans son principe et état d’avancement. Les échanges se sont portés sur l’idée de mener une étude (simulation et mesure) sur la consommation des balises par les PEIP-D avec pour objectif de dimensionner la réserve d’énergie.

Ceci implique :
- coté RCIM5 : mise à disposition d’une carte prototype.

- cote PEIP-D : inventaire des paramètres à prendre en compte :
* consommation carte (GPS + puce LoRa) = > veille + temps d’activation (recherche à faire sur le temps de synchronisation du GPS)
* puissance d’émission à calibrer en fonction de la couverture voulue et débit (voir Spread Factor ?)
* temps d’émission-réception (émission jusqu’à acquittement)

- cote PEIP-D : penser la manip pour valider ce modèle
* mesure moyenne du courant
* configuration effective du réseau
* réserver le matériel (voir Jean-Yves Frau au département R&T ?)

- cote PEIP-D : paramètrer les simulations et mesures en fonction de puissance d’émission (ou autre élément pouvant apparaitre comme pertinent)

D’une manière générale, pour les PEID-D :
- penser bibliographie (pour commencer : https://fr.wikipedia.org/wiki/LoRaWAN et aussi https://fr.wikipedia.org/wiki/Format_des_piles_et_accumulateurs_électriques :-) )
- planifier
- communiquer : reporting !!!"

=Description du sujet=

==Randonnée et risques==

Ouvert à tous, la randonnée est un sport et un loisir qui prend de plus en plus d’ampleur de nos jours. Ne nécessitant pas de grands prérequis, des milliers de personnes se lancent en montagne chaque jour, malheureusement parfois sans connaître toutes les mesures de sécurité associées.

En effet, de janvier à juin 2016, en randonnée et en alpinisme, l’Association Nationale pour l’Étude de la Neige et des Avalanches (ANENA) a comptabilisé 21 accidents notables, dont 8 accidents mortels, impliquant 15 décès.

Aujourd’hui, les mesures de sécurités préconisent que chaque groupe de randonneur se doivent de se munir d’un téléphone portable afin d’appeler les secours en cas de problème. Malheureusement, la communication mobile dépendant de la couverture réseau, peu présente en montagne, l’impossibilité de joindre les secours reste un problème.

==Solutions existantes==

La solution la plus répandue, est celle du téléphone à connexion satellite. Ayant une communication vers les satellites, cela permet une couverture réseau beaucoup plus répandue dans les montagnes, partout dans le monde (ou presque). Cependant, les téléphones portables satellitaires coûtent chers, et ne sont pas forcément abordables par la plupart des personnes, surtout celles ne sortant qu’occasionnellement.

[https://fall-alarm.net/ Fall Alarm] est un système de détection de chute sur chantier utilisant les mêmes technologies dont nous avons besoin pour notre projet.

==Quelles zones géographiques ?==

Toutes les zones montagneuses peuvent présenter des zones blanches, démunies de connexion quelconque autre que les connexions satellitaires. Certaines chaînes de montagne comme la Cordillaire des Andes ne présentent aucune connexion possible quelconque.

Dans le cadre de notre projet, nous fonctionnerons essentiellement dans la localisation grenobloise avec l'objectif que notre solution soit applicable partout dans le monde. Une contrainte intervient tout de même étant donnée que la fréquence d'utilisation du LoRa en Europe est de 868MHz, 915MHz en Amérique et 433MHz en Asie.

= Fonctionnalités =

Afin de remplir au mieux ses attentes, le principal objectif de ce dispositif sera premièrement de pouvoir communiquer avec les secours à n’importe quel moment, et surtout n’importe où. De plus, il sera capable de détecter de nombreux cas de détresse de la part de l’usager afin de pouvoir lancer un appel d’urgence sans interaction avec l’usager, au cas où il serait inconscient, ou incapable de lancer un appel manuel.

Grâce aux accéléromètres, le dispositif sera à même de détecter un mouvement brutal du randonneur, ce qui pourrait s’apparenter à une chute. Ils pourront également détecter une position anormale, ou une immobilité prolongée, ce qui déclencherait le dispositif d’urgence automatiquement.

Grâce à des tests réalisés au préalable, le boîtier pourra détecter correctement les chûtes de simples mouvements, afin de ne pas lancer l’appel sans raison valable.

Avant de lancer une alerte automatique, le dispositif émettra un signal auditif et visuel à l’utilisateur quelques secondes auparavant, afin de le prévenir l'émission du signal d’urgence, et de lui proposer de le désactiver sur simple pression d’un bouton, afin d’éviter les communications inutiles.

Également, le randonneur sera à même d'émettre volontairement un appel d’urgence à l’aide du bouton, ce qui permet à tout moment d’appeler de l’aide sans effort. Cela peut permettre également à appeler les secours pour une personne en danger qui ne porterait pas le dispositif.

L’appel au secours se représente par un envoi de coordonnées GPS aux secours, via une communication radio LoRa vers des bornes relais placées au préalables en montagne. Cette communication irait de relai de relai jusqu’au centre de sécurité, d’où le message serait transmis aux secours.

De plus, une application mobile verra le jour afin de connecter tous les utilisateurs du module de sécurité, de les visualiser sur une map, et de partager leurs données. En effet, à chaque incident, l’application mettra à jour la position et de la date de l’accident, afin de permettre aux prochains utilisateurs d’être prévenus. Ils pourraient, s'ils sont à proximité, d'assister la personne en détresse en attendant l'arrivée des secours. Bien évidemment, cette application ne sera accessible uniquement si le smartphone de l'utilisateur est relié à une connexion 4G ou Wi-Fi.

Cette prévention pourrait les sensibiliser aux risques de la montagne, leur permettre d’éviter le secteur mais aussi d’aider les personnes en danger si la distance le permet.

= Exigences =
== Fonctionnelles ==

*Batterie garantie fonctionnelle 1 semaine
*Rechargement possible via le panneau solaire portable
*Dispositif pouvant être allumé et éteint par l'utilisateur
*Alarme s’enclenche automatiquement dès qu'elle est considérée nécessaire, signal sonore
*Utilisateur a la possibilité d’activer/désactiver l’alarme quand il le souhaite
*Lorsque l’alarme est active, l’appareil ne peut s’éteindre
*...

== Non-Fonctionnelles ==

*Résistance : aux chocs, impacts, waterproof (utilisé en permanence en plein air)
*Disponibilité : Appareil de secours -> Doit être au plus possible performant
*Performance : Minimiser les pertes réseaux
*Accessible : Utilisateur pas forcément familier avec des appareils électroniques (facile d’utilisation)
*Fiabilité : Précision du GPS (rayon de 10m), données non-éronnées
*Coût : Le plus faible possible pour vendre le moins cher possible
*Efficacité : Réduire la consommation, utiliser le moins possible les ressources

= Composants =
== LoRaONE ==
Pour le coeur du projet, après avoir cherché et comparés plusieurs modules LoRa, GPS ou encore accéléromètres, nous avons finalement opté pour le projet LoRaONE.

LoRaONE est un projet de SODAQ regroupant plusieurs composants dans une seule et même carte, de taille réduite.

https://www.kickstarter.com/projects/sodaq/loraone-the-lora-iot-development-board

“The one IoT development board to rule them all” --SODAQ

Cette carte regroupe plusieurs capteurs afin de respecter aux mieux nos exigences :

Un émetteur/récepteur LoRa afin de pouvoir communiquer au mieux avec les antennes relai à longue distance

Un module + antenne GPS de bonne précision (< 10m) pour connaître en tout temps notre position, et ainsi faciliter l’arrivée des secours, ainsi que la recherche de l’individu en détresse

Un accéléromètre sur 3 axes afin de pouvoir détecter tout mouvement, vitesse ou rotation dans l’espace, ce qui permet la détection de chutes ou d’arrêt de mouvements

3 LED RGB afin de pouvoir signaler à l’utilisateur un manque de batterie, un signal d’urgence ou plus si nécessaire

Un bouton poussoir pour le signal d’alarme

Un connecteur de charge par panneau solaire, afin de faire durer chaque batterie le plus longtemps possible

Un connecteur micro-USB ainsi que des lignes pour se connecter à une base Arduino si besoin

[[File:LoRaOne.png||400px|Spécifications carte LoRaOne]]

De plus, grâce au starter pack, nous pouvons avoir accès à la base ONEBase qui nous permettrait d’étendre plus loin la facilité d’utilisation du produit :

[[File:LoRaOneBase.png||400px|Spécifications base LoRaOneBase]]

Comme nous pouvons le voir, cette base nous permettra de connecter la batterie ainsi que le panneau solaire qui sont fournis dans le pack.

Nous pourrons également connecter jusqu’à 4 modules supplémentaires.

La batterie fournie aura une capacité de 800 mAh, le panneau solaire fourni pouvant délivrer jusqu’à 500 mW de puissance.

Le total atteint une taille d’environ 10*5 cm, ce qui n’est pas excessif, ce qui le rend aisément portatif sur une jambe ou à la taille.

'''Coût : 115€'''

Ce module pourra également servir d’antenne relai, l'alimentation solaire devrait maintenir le dispositif chargé en permanence. Des tests seront effectués pour savoir si un panneau solaire plus puissant est requis.

== Boîtier ==

Le boîtier sécurisé devant respecter plusieurs exigences, nous pouvons le construire en plastique résistant, ce qui le rendrait léger tout en respectant une rigidité suffisante. Les antennes pourront être placées le long du boîtier, à l’intérieur si la connexion est suffisante, ou à l’extérieur. Dans ce dernier cas les trous réalisés sur le boîtier afin de laisser passer les câbles seront colmatés afin de garantir une étanchéité.

[[File:SchemaBoitier.png||100px|Schéma boitier d'alarme]]

== Balises ==

Afin de remonter les informations transmises par les boitiers, des balises seront mises en places sur la zone à couvrir, leur nombre et leur positions dépendra du terrain (obstacles, dénivelés). On distinguera deux types de balises. Tout d’abord, les balises racines qui permettront une communication GSM afin de faire remonter les données vers le serveur. Viennent ensuite les balises standard qui se contenteront de faire remonter vers leur balise racine associée. L’architecture de liaison des balises est détaillée dans une prochaine partie.

Chaque balise est composée d’une barre de fer pouvant être plantée dans le sol, d’un système de lest afin d’immobiliser la balise, d’un paratonnerre, d’un panneau solaire ainsi que d’un LoraOne et d’une batterie. Les balises racines seront équippée en plus d’un dispositif de communication GSM (téléphone portable, émetteur GSM).

[[File:SchemaBalise.png||150px|Schéma balises d'alarme]]

== Application mobile ==
Une application mobile est téléchargeable par les utilisateurs. Ils peuvent voir les autres utilisateurs présents dans leur zone. Lorsqu’un utilisateur est en position de danger, une notification apparaît si les utilisateurs sont proches de la situation de danger.

Cette application n’est pas directement reliée au dispositif. Elle ne fonctionne qu’avec la connexion du mobile, et est destinée à être un niveau de sécurité supérieur. Un randonneur proche d’une zone de danger pourrait arriver sur place plus rapidement que les secours.

= Communication =

Pour un envoi de position + numéro d’identification (X chiffres) :

*Temps de communication : < 2 s
*Communication régulière, intervalle de 15 minutes

On peut donc au maximum avoir 15 * 60 / 2 = 450 individus pouvant communiquer avec la même antenne relai, donc dans le même cercle d’environ 15 km de diamètre.

On communique donc au minimum 2 secondes sur 15 minutes, donc 1/450 << 1%, le temps de communication est respecté.

En cas de problème, nous pouvons envoyer jusqu’à 9x plus avec la borne sans dépasser le temps de communication autorisé (1%). Donc 1 envoi d’appel d’urgence toutes les 2 minutes environ.

La balise racine peut être directement connectée au serveur, dans ce cas, il n’y a pas de communication GSM nécessaire et pas de Gateway. Si la racine n’est pas directement connectée au serveur, elle devra au minimum garantir une communication GSM (ce qu’elle peut faire, il n’y a pas de Gateway nécessaire) pour remonter l’information vers le serveur, et donc la base de données.

GSM : Si Racine connectée à Serveur -> No GSM + Gateway
Else : GSM + Gateway : LoRa Racine connectée ordi (RaspberryPI) + ordi connecté GSM

= Stabilisation et gestion d’erreurs =

== Choix du routage ==

Notre réseau n'est pas un réseau traditionnel. Les seules communications existantes sont soit une remontée d'information vers la racine soit une innondation d'alerte vers les clients. Pour celà nous avons donc décidé d'utiliser un algorithme de routage simplifié basé uniquement sur un arbre en largeur des balises. Nous rajoutons en option la possibilité de créer plusieurs racines et donc plusieurs arbres dont les racines communiquent par gsm. Nous nous basons sur des papiers de recherches afin de déterminer quel algorithme auto-stabilisant est le plus adapté au système LoRa (Tel que le papier "A self-stabilizing algorithm for constructing breadth-first trees" par Shing-Tsaan Huang, Nian-Shing Chen).

== Stabilisation ==

Afin de gérer la communication de chaque message vers le serveur, nous allons prendre un noeud (balise LoRa) dit “racine” connecté directement au serveur, nous ne nous occuperons pas de la communication au serveur dans cet onglet. Chaque message reçu de la part d’un noeud du système doit être relayé jusqu’à la racine du système afin de communiquer avec les secours (ou serveur simplement).

Pour cela, il faudra assurer que chaque balise LoRa soit connecté au réseau, afin d’avoir au départ un graphe de communication connexe. Par dessus ce graphe, nous allons utiliser un processus silencieux auto-stabilisant qui construira un arbre de parcours en largeur, avec pour racine le noeud “racine” décidé ci-dessus.

Au lancement du système, il faut prévoir un léger temps de stabilisation, qui dépendrait de l’algorithme et de la taille du graphe (nombre de balises). Cependant, après cela, l’algorithme assure un arbre en profondeur minimal qui nous permettrai de communiquer avec la racine le plus rapidement possible, et donc une qualité de service maximale.

== Gestion d’erreurs ==

Dans un réseau comme celui-ci, plusieurs types d’erreurs peuvent se produire :
Délai de communication trop important vers une balise
“Crash” d’une balise de communication
Surpopulation d’une balise ou congestion de messages

Afin de palier au premier type d’incident rencontré, il faut nécessairement qu’à chaque emplacement dans la zone couverte, l’utilisateur soit à même de communiquer avec au minimum 2 balises différentes. Ainsi, dans le cas d’une communication trop longue sur une balise, l’autre aurait de grandes chances de délivrer le message plus rapidement.

Au niveau de la défaillance d’une balise, l’algorithme d’arbre en profondeur nous fournit déjà une solution intégrée grâce à son auto-stabilisation. Dans le cas de déconnexion d’une balise, l’algorithme mettrai à jour automatiquement l’arbre de communication, et n’importe quel message d’alerte émis serait délivré dans un délai raisonnable.

Pour le troisième cas d’erreur, il n’y aurait pas de solution réelle, si ce n’est de limiter le nombre de communications données, en ne prenant plus en compte les “ping” de chaque utilisateur mais seulement les messages d’alertes, ce qui permettrai une bien plus grande gestion de la congestion à un endroit donné. Également, une balise en dessous d’un lien congestionné pourrait communiquer avec ses autres voisins (non-fils dans l’arbre) afin de libérer de l’espace dans le lien avec son père dans l’arbre. Également, le système ne pourra accepter que jusqu’à 1000 utilisateurs par noeud, et également 4000 utilisateurs par cluster (dans le cas d’un réseau avec plusieurs clusters donc plusieurs racines cette limite augmente).

Plusieurs types de paquets circulent sur le réseau de balise:
Les pings, messages envoyés spontanéments à intervalle régulier par les utilisateur contenant l’id ainsi que les deux coordonées gps (27 bits chacun)
Les incidents, identique à un ping mais à priorité haute.
Les alertes, messages brodcastés par le serveur afin d’envoyer un message en chaine de caractères courts et compressés.

=Coûts matériels=

Que ce soit pour le dispositif utilisateur ou la balise (racine ou non), le LoRaOne correspond pour permettre les actions recherchées. Afin de réaliser un prototype pertinent, 6 kits LoRaOne sont requis. Ces kits sont accessibles sur le site de Sodaq au prix de 115€ chacun (prix variable).
Disponible [https://shop.sodaq.com/en/one-eu-rn2483-v2.html ici], voir avant dernier bundle : starter "ONE EU starter" actuellement à 112,10€.

Un [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer buzzer] est à ajouter au dispositif utilisateur afin de lui délivrer un signal sonore.

Un shield GSM est requis pour que la balise racine communique avec l'extérieur. Sodaq en propose un designé pour fonctionner sur leurs produits mais est éctuellement en rupture de stock. Un shield GSM arduino convient tout autant et peut être trouvé sur le site arduino [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna ici].

Aucun boitier ne sera commandé car nous avons fait le choix de les manufacturer nous même au fablab. Le besoin d'étanchéité n'est pas primordial pour notre prototype, bien que nous tenterons de l'assurer.

{|class="récap commande"
|+ Récapitulatif
|-
|
!scope="col" style="width: 320px;"| Produit
!scope="col" style="width: 80px;"| Lien
!scope="col" style="width: 80px;"| Quantité
!scope="col" style="width: 80px;"| Prix Unitaire
|-

!scope="row"| 1
| LoRaOne EU Starter
| [https://shop.sodaq.com/en/one-eu-rn2483-v2.html Achat]
| 6
| 115€
|-

!scope="row"| 2
| Buzzer
| [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer Achat]
| 3
| 5.49€
|-

!scope="row"| 3
| Shield GSM
| [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna Achat]
| 1
| 65€
|-

|}

=Développement=

Nous utiliserons les librairies standards Arduino ainsi que celle de SODAQ/Arduino pour le LoRa.

L'IDE Arduino sera utilisé, plus pratique pour l'utilisation de Git (comparé à Mbed).

= Mise sur le marché =

Ce dispositif a pour but d’être utilisé en montagne, lors de randonnée. Il n’est pas destiné à un usage quotidien, c’est pourquoi nous considérons qu’il est plus judicieux de louer les dispositifs plutôt que de les vendre, même si l’achat n’est pas à omettre de notre stratégie.

Le dispositif peut être commandé en ligne, puis retourné par la poste après usage. Le client louerait le dispositif pour une certaine durée avec un possible nombre supplémentaire de batterie. Les tarifs varient en fonction de la durée et du nombre de batteries louées. Des offres de groupes pourraient être applicables. A long terme, des boutiques pourraient être disséminées dans des grandes villes proches des zones montagneuses, zones à randonnées (Grenoble, Annecy, etc.).

L’application est téléchargeable gratuitement par quiconque, mais utilisable seulement par les clients. Un code d’accès sera envoyé avec le dispositif expirant après la fin de la location.

Il faudra tenir compte de la bande passante du LoRa, variante en fonction des continents.

=Planning prévisonnel=

Sprint 1 : 29/01 --> 09/02 : Création du prototype logiciel #1
*Prise en main du matériel
*Premiers tests de transmissions LoRa
*Création du protocole d'architecture des balises
*Application sur les cartes et tests
*Tests de performances des cartes (durabilité, chargement, batterie)
*Tests de maintenabilité de l'algorithme (déconnexions, latences)

Sprint 2 : 12/02 --> 23/02 : Prototype logiciel #2 et prototype matériel
*Création du programme embarqué (utilisateur)
*Communication avec la racine et le serveur
*Création des maquettes boîtier et balise
*Construction des maquettes
*Finalisation du premier prototype

Sprint 3 : 26/02 --> 09/03 : Fonctionnalités supplémentaires
*Ajout de la communication entre le LoRa et le GSM sur la balise racine
*Création application mobile utilisateur
*Tests sur l'application
*Tests sur la transmission totale depuis l'utilisateur vers le serveur via le GSM
*Finalisation du projet

Sprint 4 : 12/03 --> 16/03 : Fin du projet
*Création de la documentation finale (à partir de la documentation réalisée en continu)
*Pause café
*Temps supplémentaire en cas de problèmes importants
*Préparation de la soutenance

R'Montagne

2018-03-14T10:19:16Z

Hugo.Amodru-Favin: /* Journal */

=Équipe=
{|class="wikitable"
|-
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Rôle
|-
| Hugo Amodru-Favin
| Chef de Projet
|-
| Antoine Delise
| Lead Developer
|-
| Gwenaël Moreau
| Kanban Master
|-

|}

==Tâches==

Répartition générale des tâches
{|class="wikitable"
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Tâche
|-
| Hugo Amodru-Favin
| Application Ionic
|-
| Antoine Delise
| Développement Arduino
|-
| Gwenaël Moreau
| BDD - API
|-

|}

Détail des tâches : [https://waffle.io/delisea/R-Montagne Waffle.io]

=Journal=

{|class="wikitable"
|+
|-
!scope="col" width="120px"| Date
!scope="col" width="350px"| Hugo AMODRU-FAVIN
!scope="col" width="350px"| Antoine DELISE
!scope="col" width="350px"| Gwenaël MOREAU
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 1
|-

|-
| rowspan="1" | Lundi 29/01/18
| style="width: 225px;" |
* Ré-assimilation du sujet
| style="width: 225px;" |
* Ré-assimilation du sujet
| style="width: 225px;" |
* Ré-assimilation du sujet
* Mise en place d'un Kanban
|-
| rowspan="1" | Mardi 30/01/18
| style="width: 225px;" |
* Mise à jour de la page AIR
* Réflexions sur l'implémentation du LoRa
| style="width: 225px;" |
* Mise à jour de la page AIR
* Réflexions sur l'implémentation du LoRa
| style="width: 225px;" |
* Mise en place du calendrier prévisionnel
* Définition et répartition des tâches
|-
| rowspan="1" | Mercredi 31/01/18
| style="width: 225px;" |
* Récupération des cartes Semtech
* Présentation du Hackathon Vinci Energies
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Récupération des cartes Semtech
* Présentation du Hackathon
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Récupération et prise en main des cartes Semtech LoRaMote
* Présentation du Hackathon Vinci Energies
|-
| rowspan="1" | Jeudi 01/02/18
| style="width: 225px;" |
* Choix des fonctionnalités de l'application mobile
| style="width: 225px;" |
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Prise en main des cartes LoRa
|-
| rowspan="1" | Vendredi 02/02/18
| style="width: 225px;" |
* Réflexions sur l'implémentation de l'application
* Démarrage de l'application mobile
* Mises à jour d'Ionic, de Android Studio
| style="width: 225px;" |
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Premières communications fructueuses des cartes Semtech LoRaMote
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 2
|-

|-
| rowspan="1" | Lundi 05/02/18
| style="width: 225px;" |
* Configuration Login et Mot de Passe, Identification base
| style="width: 225px;" |
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Réflexion et création de la base de données
|-
| rowspan="1" | Mardi 06/02/18
| style="width: 225px;" |
* Configuration Login, Mot de passe
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
| style="width: 225px;" |
* Création de l'API REST EN PHP
|-
| rowspan="1" | Mercredi 07/02/18
| style="width: 225px;" |
* Réunion avec Rémi CHOLLET et 3 PEIP D
* Assimilation du fonctionnement de Leaflet
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
| style="width: 225px;" |
* Réunion avec Rémi CHOLLET et 3 PEIP D
* Création de l'API REST en PHP
|-
| rowspan="1" | Jeudi 08/02/18
| style="width: 225px;" |
* Ajout de marqueurs sur Leaflet
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
| style="width: 225px;" |
* Création de l'API REST EN PHP
|-
| rowspan="1" | Vendredi 09/02/18
| style="width: 225px;" |
* Hackathon Vinci Energies
| style="width: 225px;" |
* Hackathon Vinci Energies
| style="width: 225px;" |
* Hackathon Vinci Energies
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 3
|-

|-
| rowspan="1" | Lundi 12/02/18
| style="width: 225px;" |
* Préparation Soutenance
| style="width: 225px;" |
* Mise en place d'un Contiki/Cooja pour faciliter le développement
| style="width: 225px;" |
* Préparation Soutenance
|-
| rowspan="1" | Mardi 13/02/18
| style="width: 225px;" |
* Mise à jour de AIR
* Préparation Soutenance
* Répétition soutenance
| style="width: 225px;" |
* Préparation Soutenance
* Répétition soutenance
* Mise en place d'un Contiki/Cooja pour faciliter le dévelloppement
| style="width: 225px;" |
* Préparation Soutenance
* Répétition soutenance
|-
| rowspan="1" | Mercredi 14/02/18
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
|-
| rowspan="1" | Jeudi 15/02/18
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
|-
| rowspan="1" | Vendredi 16/02/18
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
|-
| rowspan="1" | Interruption de Février
| style="width: 225px;" |
| style="width: 225px;" |
* Développement sur Contiki/Cooja afin de réaliser un routage dynamique
| style="width: 225px;" |
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 4
|-

|-
| rowspan="1" | Lundi 26/02/18
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Travail sur l'affichage des éléments sur la carte utilisateur
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Continuation du travail sur Contiki
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Corrections de l'API en accord avec l'application mobile
* Modifications sur la base de données
|-
| rowspan="1" | Mardi 27/02/18
| style="width: 225px;" |
* Création de la page de création d'un nouvel utilisateur
* Design de l'application mobile
| style="width: 225px;" |
* Fin du protocole de routage Contiki, tests virtuels de fonctionnement
| style="width: 225px;" |
* Liaison entre l'application mobile et l'API
|-
| rowspan="1" | Mercredi 28/02/18
| style="width: 225px;" |
* Fin de la page de création d'un nouvel utilisateur
* Ajout de l'utilisation des sessions dans l'application
| style="width: 225px;" |
* Panne ordinateur personnel
* Perte des données du routage dynamique malgré une tentative de back-up avant la panne
* Travail sur l'application mobile avec Hugo
| style="width: 225px;" |
* API : Création d'un utilisateur
* API : Récupération des informations nécessaires pour la carte
* API : Ajout de l'utilisation des sessions pour stocker l'utilisateur connecté
|-
| rowspan="1" | Jeudi 01/03/18
| style="width: 225px;" |
* Affichage des informations sur la Map
| style="width: 225px;" |
* Affichage des informations sur la Map
| style="width: 225px;" |
* API : Récupération des informations nécessaires pour la carte
|-
| rowspan="1" | Vendredi 02/03/18
| style="width: 225px;" |
* Listing des futures tâches à implémenter dans l'application
* Réunion et préparation rendez-vous avec M.Donsez
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Réparation d'ordinateur personnel
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Renseignements sur Swagger
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 5
|-

|-
| rowspan="1" | Lundi 05/03/18
| style="width: 225px;" |
* Restructuration de l'application, amélioration visuelle
* Logout fonctionnel
| style="width: 225px;" |
* Finalisation de la carte, et ajout de la gestion des différentes cartes
* Restructuration de l'application
| style="width: 225px;" |
* Création d'une page Swagger
* Corrections de l'API
* Ajout des cartes dans la base de données
* Récupération des éléments liés à la carte dans l'API
|-
| rowspan="1" | Mardi 06/03/18
| style="width: 225px;" |
* Ajout gestion secouriste
* Développement de la page Account, modification utilisateur
| style="width: 225px;" |
* Ajout gestion secouriste
* Création vues côté secouristes
| style="width: 225px;" |
* Fin du Swagger
* API : Modifications utilisateur
* API : Modifications mot de passe
* Base de données : Ajout affectations secouristes-cartes
* API : Récupération des cartes pour un secouriste
|-
| rowspan="1" | Mercredi 07/03/18
| style="width: 225px;" |
* Amélioration et finalisation de la page Account
| style="width: 225px;" |
* Corrections du menu et de la navigation
| style="width: 225px;" |
* Programme de récupération des messages à la racine et inscription des données dans la base de données
|-
| rowspan="1" | Jeudi 08/03/18
| style="width: 225px;" |
* Extraction des dents de sagesse
| style="width: 225px;" |
*
| style="width: 225px;" |
* Création du programme de communication LoRa et récupération des coordonnées GPS depuis la carte SodaqONE
* Tests de temps de synchronisation et précision du GPS
|-
| rowspan="1" | Vendredi 09/03/18
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Design du LogoV2, Embellie CSS de l'application mobile
* Réunion avec les PEIP D
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
*
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Finition du programme de communication LoRa
* Tests d'envoi de la carte SodaqONE vers la base de données en passant par une racine (carte Arduino LoRa)
|-
| rowspan="1" | Samedi 10/03/18
| style="width: 225px;" |
* Réflexions et implémentations des Usercases concernant la gestion des licences
* Ajout de notifications mobiles
* Ajout d'une page liée à la gestion des Trackers
* Début du Poster Anniversaire
| style="width: 225px;" |
* Réflexions et implémentations des Usercases concernant la gestion des licences
* Ajout de notifications mobiles
| style="width: 225px;" |
* Tests du programme de communication avec les LoRas
|-
| rowspan="1" | Dimanche 11/03/18
| style="width: 225px;" |
* Implémentations des usercases liées à la gestion des licences côté application
| style="width: 225px;" |
* Implémentations des usercases liées à la gestion des licences côté api
| style="width: 225px;" |
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 6
|-

|-
| rowspan="1" | Lundi 12/03/18
| style="width: 225px;" |
* Ajouts de fonctionnalités dans l'application
| style="width: 225px;" |
* Correctifs programme de communication
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Correctifs programme de communication
|-
| rowspan="1" | Mardi 13/03/18
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Finalisation des fonctionnalités de l'application
* Correctifs des bugs
* Test Réel à la Bastille
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Finalisation des fonctionnalités de l'application
* Correctifs des bugs
* Page de création de Map Admin
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Préparation des capteurs pour le test réel
* Test Réel à la Bastille
|-
| rowspan="1" | Mercredi 14/03/18
| style="width: 225px;" |
* Préparation de la soutenance
* Remplissage de la BDD
* Finalisation du Poster
* Test Réel aux Taillées
| style="width: 225px;" |
* Préparation de la soutenance
* Préparation de la démonstration
* Dernier correctifs de l'application
| style="width: 225px;" |
* Préparation de la soutenance
* Finalisation du Poster
* Test Réel aux Taillées
|-
| rowspan="1" | Jeudi 15/03/18
| style="width: 225px;" |
* Soutenance de Projet
| style="width: 225px;" |
* Soutenance de Projet
| style="width: 225px;" |
* Soutenance de Projet
|-
| rowspan="1" | Vendredi 16/03/18
| style="width: 225px;" |
* 16 Ans de la filière RICM : Présentation du travail effectué
| style="width: 225px;" |
* 16 Ans de la filière RICM : Présentation du travail effectué
| style="width: 225px;" |
* 16 Ans de la filière RICM : Présentation du travail effectué
|}

=Collaboration avec le DUT RT et les PEIPs D=
L'objectif de cette collaboration est de familiariser des étudiants en PEIP D avec des projets qu'ils seront amenés à développer dans les prochaines années. Nous avons rencontré Rémi CHOLLET et 3 étudiants Mercredi 7 Février, en voici un résumé écrit par Mr CHOLLET définissant les contours de cette collaboration.

"Un rapide résumé de la rencontre que nous avons eu ce matin avec le projet R’Montagne.

Présents :
- RCIM5 Gwenael Moreau, Hugo Amodru-Favin
- PEIP-D : Yoann Goma-Missamou, Vincent Cadoux, Philippe Charrat
- IUT : Rémy Chollet, tuteur pédagogique des PEIP-D
Excusés : Didier Donsez, blessé (aie ! courage …), Antoine Delise en cours de marketing

Contexte :
Les PEIP-D participent aux projets RICM5 en prenant une tâche « annexe » (hors chemin critique) en charge. L’objectif est une expérience d’immersion + notation liée au PEIP.

Déroulé :
Les étudiant RCIM5 ont présenté le projet dans son principe et état d’avancement. Les échanges se sont portés sur l’idée de mener une étude (simulation et mesure) sur la consommation des balises par les PEIP-D avec pour objectif de dimensionner la réserve d’énergie.

Ceci implique :
- coté RCIM5 : mise à disposition d’une carte prototype.

- cote PEIP-D : inventaire des paramètres à prendre en compte :
* consommation carte (GPS + puce LoRa) = > veille + temps d’activation (recherche à faire sur le temps de synchronisation du GPS)
* puissance d’émission à calibrer en fonction de la couverture voulue et débit (voir Spread Factor ?)
* temps d’émission-réception (émission jusqu’à acquittement)

- cote PEIP-D : penser la manip pour valider ce modèle
* mesure moyenne du courant
* configuration effective du réseau
* réserver le matériel (voir Jean-Yves Frau au département R&T ?)

- cote PEIP-D : paramètrer les simulations et mesures en fonction de puissance d’émission (ou autre élément pouvant apparaitre comme pertinent)

D’une manière générale, pour les PEID-D :
- penser bibliographie (pour commencer : https://fr.wikipedia.org/wiki/LoRaWAN et aussi https://fr.wikipedia.org/wiki/Format_des_piles_et_accumulateurs_électriques :-) )
- planifier
- communiquer : reporting !!!"

=Description du sujet=

==Randonnée et risques==

Ouvert à tous, la randonnée est un sport et un loisir qui prend de plus en plus d’ampleur de nos jours. Ne nécessitant pas de grands prérequis, des milliers de personnes se lancent en montagne chaque jour, malheureusement parfois sans connaître toutes les mesures de sécurité associées.

En effet, de janvier à juin 2016, en randonnée et en alpinisme, l’Association Nationale pour l’Étude de la Neige et des Avalanches (ANENA) a comptabilisé 21 accidents notables, dont 8 accidents mortels, impliquant 15 décès.

Aujourd’hui, les mesures de sécurités préconisent que chaque groupe de randonneur se doivent de se munir d’un téléphone portable afin d’appeler les secours en cas de problème. Malheureusement, la communication mobile dépendant de la couverture réseau, peu présente en montagne, l’impossibilité de joindre les secours reste un problème.

==Solutions existantes==

La solution la plus répandue, est celle du téléphone à connexion satellite. Ayant une communication vers les satellites, cela permet une couverture réseau beaucoup plus répandue dans les montagnes, partout dans le monde (ou presque). Cependant, les téléphones portables satellitaires coûtent chers, et ne sont pas forcément abordables par la plupart des personnes, surtout celles ne sortant qu’occasionnellement.

[https://fall-alarm.net/ Fall Alarm] est un système de détection de chute sur chantier utilisant les mêmes technologies dont nous avons besoin pour notre projet.

==Quelles zones géographiques ?==

Toutes les zones montagneuses peuvent présenter des zones blanches, démunies de connexion quelconque autre que les connexions satellitaires. Certaines chaînes de montagne comme la Cordillaire des Andes ne présentent aucune connexion possible quelconque.

Dans le cadre de notre projet, nous fonctionnerons essentiellement dans la localisation grenobloise avec l'objectif que notre solution soit applicable partout dans le monde. Une contrainte intervient tout de même étant donnée que la fréquence d'utilisation du LoRa en Europe est de 868MHz, 915MHz en Amérique et 433MHz en Asie.

= Fonctionnalités =

Afin de remplir au mieux ses attentes, le principal objectif de ce dispositif sera premièrement de pouvoir communiquer avec les secours à n’importe quel moment, et surtout n’importe où. De plus, il sera capable de détecter de nombreux cas de détresse de la part de l’usager afin de pouvoir lancer un appel d’urgence sans interaction avec l’usager, au cas où il serait inconscient, ou incapable de lancer un appel manuel.

Grâce aux accéléromètres, le dispositif sera à même de détecter un mouvement brutal du randonneur, ce qui pourrait s’apparenter à une chute. Ils pourront également détecter une position anormale, ou une immobilité prolongée, ce qui déclencherait le dispositif d’urgence automatiquement.

Grâce à des tests réalisés au préalable, le boîtier pourra détecter correctement les chûtes de simples mouvements, afin de ne pas lancer l’appel sans raison valable.

Avant de lancer une alerte automatique, le dispositif émettra un signal auditif et visuel à l’utilisateur quelques secondes auparavant, afin de le prévenir l'émission du signal d’urgence, et de lui proposer de le désactiver sur simple pression d’un bouton, afin d’éviter les communications inutiles.

Également, le randonneur sera à même d'émettre volontairement un appel d’urgence à l’aide du bouton, ce qui permet à tout moment d’appeler de l’aide sans effort. Cela peut permettre également à appeler les secours pour une personne en danger qui ne porterait pas le dispositif.

L’appel au secours se représente par un envoi de coordonnées GPS aux secours, via une communication radio LoRa vers des bornes relais placées au préalables en montagne. Cette communication irait de relai de relai jusqu’au centre de sécurité, d’où le message serait transmis aux secours.

De plus, une application mobile verra le jour afin de connecter tous les utilisateurs du module de sécurité, de les visualiser sur une map, et de partager leurs données. En effet, à chaque incident, l’application mettra à jour la position et de la date de l’accident, afin de permettre aux prochains utilisateurs d’être prévenus. Ils pourraient, s'ils sont à proximité, d'assister la personne en détresse en attendant l'arrivée des secours. Bien évidemment, cette application ne sera accessible uniquement si le smartphone de l'utilisateur est relié à une connexion 4G ou Wi-Fi.

Cette prévention pourrait les sensibiliser aux risques de la montagne, leur permettre d’éviter le secteur mais aussi d’aider les personnes en danger si la distance le permet.

= Exigences =
== Fonctionnelles ==

*Batterie garantie fonctionnelle 1 semaine
*Rechargement possible via le panneau solaire portable
*Dispositif pouvant être allumé et éteint par l'utilisateur
*Alarme s’enclenche automatiquement dès qu'elle est considérée nécessaire, signal sonore
*Utilisateur a la possibilité d’activer/désactiver l’alarme quand il le souhaite
*Lorsque l’alarme est active, l’appareil ne peut s’éteindre
*...

== Non-Fonctionnelles ==

*Résistance : aux chocs, impacts, waterproof (utilisé en permanence en plein air)
*Disponibilité : Appareil de secours -> Doit être au plus possible performant
*Performance : Minimiser les pertes réseaux
*Accessible : Utilisateur pas forcément familier avec des appareils électroniques (facile d’utilisation)
*Fiabilité : Précision du GPS (rayon de 10m), données non-éronnées
*Coût : Le plus faible possible pour vendre le moins cher possible
*Efficacité : Réduire la consommation, utiliser le moins possible les ressources

= Composants =
== LoRaONE ==
Pour le coeur du projet, après avoir cherché et comparés plusieurs modules LoRa, GPS ou encore accéléromètres, nous avons finalement opté pour le projet LoRaONE.

LoRaONE est un projet de SODAQ regroupant plusieurs composants dans une seule et même carte, de taille réduite.

https://www.kickstarter.com/projects/sodaq/loraone-the-lora-iot-development-board

“The one IoT development board to rule them all” --SODAQ

Cette carte regroupe plusieurs capteurs afin de respecter aux mieux nos exigences :

Un émetteur/récepteur LoRa afin de pouvoir communiquer au mieux avec les antennes relai à longue distance

Un module + antenne GPS de bonne précision (< 10m) pour connaître en tout temps notre position, et ainsi faciliter l’arrivée des secours, ainsi que la recherche de l’individu en détresse

Un accéléromètre sur 3 axes afin de pouvoir détecter tout mouvement, vitesse ou rotation dans l’espace, ce qui permet la détection de chutes ou d’arrêt de mouvements

3 LED RGB afin de pouvoir signaler à l’utilisateur un manque de batterie, un signal d’urgence ou plus si nécessaire

Un bouton poussoir pour le signal d’alarme

Un connecteur de charge par panneau solaire, afin de faire durer chaque batterie le plus longtemps possible

Un connecteur micro-USB ainsi que des lignes pour se connecter à une base Arduino si besoin

[[File:LoRaOne.png||400px|Spécifications carte LoRaOne]]

De plus, grâce au starter pack, nous pouvons avoir accès à la base ONEBase qui nous permettrait d’étendre plus loin la facilité d’utilisation du produit :

[[File:LoRaOneBase.png||400px|Spécifications base LoRaOneBase]]

Comme nous pouvons le voir, cette base nous permettra de connecter la batterie ainsi que le panneau solaire qui sont fournis dans le pack.

Nous pourrons également connecter jusqu’à 4 modules supplémentaires.

La batterie fournie aura une capacité de 800 mAh, le panneau solaire fourni pouvant délivrer jusqu’à 500 mW de puissance.

Le total atteint une taille d’environ 10*5 cm, ce qui n’est pas excessif, ce qui le rend aisément portatif sur une jambe ou à la taille.

'''Coût : 115€'''

Ce module pourra également servir d’antenne relai, l'alimentation solaire devrait maintenir le dispositif chargé en permanence. Des tests seront effectués pour savoir si un panneau solaire plus puissant est requis.

== Boîtier ==

Le boîtier sécurisé devant respecter plusieurs exigences, nous pouvons le construire en plastique résistant, ce qui le rendrait léger tout en respectant une rigidité suffisante. Les antennes pourront être placées le long du boîtier, à l’intérieur si la connexion est suffisante, ou à l’extérieur. Dans ce dernier cas les trous réalisés sur le boîtier afin de laisser passer les câbles seront colmatés afin de garantir une étanchéité.

[[File:SchemaBoitier.png||100px|Schéma boitier d'alarme]]

== Balises ==

Afin de remonter les informations transmises par les boitiers, des balises seront mises en places sur la zone à couvrir, leur nombre et leur positions dépendra du terrain (obstacles, dénivelés). On distinguera deux types de balises. Tout d’abord, les balises racines qui permettront une communication GSM afin de faire remonter les données vers le serveur. Viennent ensuite les balises standard qui se contenteront de faire remonter vers leur balise racine associée. L’architecture de liaison des balises est détaillée dans une prochaine partie.

Chaque balise est composée d’une barre de fer pouvant être plantée dans le sol, d’un système de lest afin d’immobiliser la balise, d’un paratonnerre, d’un panneau solaire ainsi que d’un LoraOne et d’une batterie. Les balises racines seront équippée en plus d’un dispositif de communication GSM (téléphone portable, émetteur GSM).

[[File:SchemaBalise.png||150px|Schéma balises d'alarme]]

== Application mobile ==
Une application mobile est téléchargeable par les utilisateurs. Ils peuvent voir les autres utilisateurs présents dans leur zone. Lorsqu’un utilisateur est en position de danger, une notification apparaît si les utilisateurs sont proches de la situation de danger.

Cette application n’est pas directement reliée au dispositif. Elle ne fonctionne qu’avec la connexion du mobile, et est destinée à être un niveau de sécurité supérieur. Un randonneur proche d’une zone de danger pourrait arriver sur place plus rapidement que les secours.

= Communication =

Pour un envoi de position + numéro d’identification (X chiffres) :

*Temps de communication : < 2 s
*Communication régulière, intervalle de 15 minutes

On peut donc au maximum avoir 15 * 60 / 2 = 450 individus pouvant communiquer avec la même antenne relai, donc dans le même cercle d’environ 15 km de diamètre.

On communique donc au minimum 2 secondes sur 15 minutes, donc 1/450 << 1%, le temps de communication est respecté.

En cas de problème, nous pouvons envoyer jusqu’à 9x plus avec la borne sans dépasser le temps de communication autorisé (1%). Donc 1 envoi d’appel d’urgence toutes les 2 minutes environ.

La balise racine peut être directement connectée au serveur, dans ce cas, il n’y a pas de communication GSM nécessaire et pas de Gateway. Si la racine n’est pas directement connectée au serveur, elle devra au minimum garantir une communication GSM (ce qu’elle peut faire, il n’y a pas de Gateway nécessaire) pour remonter l’information vers le serveur, et donc la base de données.

GSM : Si Racine connectée à Serveur -> No GSM + Gateway
Else : GSM + Gateway : LoRa Racine connectée ordi (RaspberryPI) + ordi connecté GSM

= Stabilisation et gestion d’erreurs =

== Choix du routage ==

Notre réseau n'est pas un réseau traditionnel. Les seules communications existantes sont soit une remontée d'information vers la racine soit une innondation d'alerte vers les clients. Pour celà nous avons donc décidé d'utiliser un algorithme de routage simplifié basé uniquement sur un arbre en largeur des balises. Nous rajoutons en option la possibilité de créer plusieurs racines et donc plusieurs arbres dont les racines communiquent par gsm. Nous nous basons sur des papiers de recherches afin de déterminer quel algorithme auto-stabilisant est le plus adapté au système LoRa (Tel que le papier "A self-stabilizing algorithm for constructing breadth-first trees" par Shing-Tsaan Huang, Nian-Shing Chen).

== Stabilisation ==

Afin de gérer la communication de chaque message vers le serveur, nous allons prendre un noeud (balise LoRa) dit “racine” connecté directement au serveur, nous ne nous occuperons pas de la communication au serveur dans cet onglet. Chaque message reçu de la part d’un noeud du système doit être relayé jusqu’à la racine du système afin de communiquer avec les secours (ou serveur simplement).

Pour cela, il faudra assurer que chaque balise LoRa soit connecté au réseau, afin d’avoir au départ un graphe de communication connexe. Par dessus ce graphe, nous allons utiliser un processus silencieux auto-stabilisant qui construira un arbre de parcours en largeur, avec pour racine le noeud “racine” décidé ci-dessus.

Au lancement du système, il faut prévoir un léger temps de stabilisation, qui dépendrait de l’algorithme et de la taille du graphe (nombre de balises). Cependant, après cela, l’algorithme assure un arbre en profondeur minimal qui nous permettrai de communiquer avec la racine le plus rapidement possible, et donc une qualité de service maximale.

== Gestion d’erreurs ==

Dans un réseau comme celui-ci, plusieurs types d’erreurs peuvent se produire :
Délai de communication trop important vers une balise
“Crash” d’une balise de communication
Surpopulation d’une balise ou congestion de messages

Afin de palier au premier type d’incident rencontré, il faut nécessairement qu’à chaque emplacement dans la zone couverte, l’utilisateur soit à même de communiquer avec au minimum 2 balises différentes. Ainsi, dans le cas d’une communication trop longue sur une balise, l’autre aurait de grandes chances de délivrer le message plus rapidement.

Au niveau de la défaillance d’une balise, l’algorithme d’arbre en profondeur nous fournit déjà une solution intégrée grâce à son auto-stabilisation. Dans le cas de déconnexion d’une balise, l’algorithme mettrai à jour automatiquement l’arbre de communication, et n’importe quel message d’alerte émis serait délivré dans un délai raisonnable.

Pour le troisième cas d’erreur, il n’y aurait pas de solution réelle, si ce n’est de limiter le nombre de communications données, en ne prenant plus en compte les “ping” de chaque utilisateur mais seulement les messages d’alertes, ce qui permettrai une bien plus grande gestion de la congestion à un endroit donné. Également, une balise en dessous d’un lien congestionné pourrait communiquer avec ses autres voisins (non-fils dans l’arbre) afin de libérer de l’espace dans le lien avec son père dans l’arbre. Également, le système ne pourra accepter que jusqu’à 1000 utilisateurs par noeud, et également 4000 utilisateurs par cluster (dans le cas d’un réseau avec plusieurs clusters donc plusieurs racines cette limite augmente).

Plusieurs types de paquets circulent sur le réseau de balise:
Les pings, messages envoyés spontanéments à intervalle régulier par les utilisateur contenant l’id ainsi que les deux coordonées gps (27 bits chacun)
Les incidents, identique à un ping mais à priorité haute.
Les alertes, messages brodcastés par le serveur afin d’envoyer un message en chaine de caractères courts et compressés.

=Coûts matériels=

Que ce soit pour le dispositif utilisateur ou la balise (racine ou non), le LoRaOne correspond pour permettre les actions recherchées. Afin de réaliser un prototype pertinent, 6 kits LoRaOne sont requis. Ces kits sont accessibles sur le site de Sodaq au prix de 115€ chacun (prix variable).
Disponible [https://shop.sodaq.com/en/one-eu-rn2483-v2.html ici], voir avant dernier bundle : starter "ONE EU starter" actuellement à 112,10€.

Un [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer buzzer] est à ajouter au dispositif utilisateur afin de lui délivrer un signal sonore.

Un shield GSM est requis pour que la balise racine communique avec l'extérieur. Sodaq en propose un designé pour fonctionner sur leurs produits mais est éctuellement en rupture de stock. Un shield GSM arduino convient tout autant et peut être trouvé sur le site arduino [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna ici].

Aucun boitier ne sera commandé car nous avons fait le choix de les manufacturer nous même au fablab. Le besoin d'étanchéité n'est pas primordial pour notre prototype, bien que nous tenterons de l'assurer.

{|class="récap commande"
|+ Récapitulatif
|-
|
!scope="col" style="width: 320px;"| Produit
!scope="col" style="width: 80px;"| Lien
!scope="col" style="width: 80px;"| Quantité
!scope="col" style="width: 80px;"| Prix Unitaire
|-

!scope="row"| 1
| LoRaOne EU Starter
| [https://shop.sodaq.com/en/one-eu-rn2483-v2.html Achat]
| 6
| 115€
|-

!scope="row"| 2
| Buzzer
| [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer Achat]
| 3
| 5.49€
|-

!scope="row"| 3
| Shield GSM
| [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna Achat]
| 1
| 65€
|-

|}

=Développement=

Nous utiliserons les librairies standards Arduino ainsi que celle de SODAQ/Arduino pour le LoRa.

L'IDE Arduino sera utilisé, plus pratique pour l'utilisation de Git (comparé à Mbed).

= Mise sur le marché =

Ce dispositif a pour but d’être utilisé en montagne, lors de randonnée. Il n’est pas destiné à un usage quotidien, c’est pourquoi nous considérons qu’il est plus judicieux de louer les dispositifs plutôt que de les vendre, même si l’achat n’est pas à omettre de notre stratégie.

Le dispositif peut être commandé en ligne, puis retourné par la poste après usage. Le client louerait le dispositif pour une certaine durée avec un possible nombre supplémentaire de batterie. Les tarifs varient en fonction de la durée et du nombre de batteries louées. Des offres de groupes pourraient être applicables. A long terme, des boutiques pourraient être disséminées dans des grandes villes proches des zones montagneuses, zones à randonnées (Grenoble, Annecy, etc.).

L’application est téléchargeable gratuitement par quiconque, mais utilisable seulement par les clients. Un code d’accès sera envoyé avec le dispositif expirant après la fin de la location.

Il faudra tenir compte de la bande passante du LoRa, variante en fonction des continents.

=Planning prévisonnel=

Sprint 1 : 29/01 --> 09/02 : Création du prototype logiciel #1
*Prise en main du matériel
*Premiers tests de transmissions LoRa
*Création du protocole d'architecture des balises
*Application sur les cartes et tests
*Tests de performances des cartes (durabilité, chargement, batterie)
*Tests de maintenabilité de l'algorithme (déconnexions, latences)

Sprint 2 : 12/02 --> 23/02 : Prototype logiciel #2 et prototype matériel
*Création du programme embarqué (utilisateur)
*Communication avec la racine et le serveur
*Création des maquettes boîtier et balise
*Construction des maquettes
*Finalisation du premier prototype

Sprint 3 : 26/02 --> 09/03 : Fonctionnalités supplémentaires
*Ajout de la communication entre le LoRa et le GSM sur la balise racine
*Création application mobile utilisateur
*Tests sur l'application
*Tests sur la transmission totale depuis l'utilisateur vers le serveur via le GSM
*Finalisation du projet

Sprint 4 : 12/03 --> 16/03 : Fin du projet
*Création de la documentation finale (à partir de la documentation réalisée en continu)
*Pause café
*Temps supplémentaire en cas de problèmes importants
*Préparation de la soutenance

R'Montagne

2018-03-14T10:11:36Z

Hugo.Amodru-Favin: /* Journal */

=Équipe=
{|class="wikitable"
|-
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Rôle
|-
| Hugo Amodru-Favin
| Chef de Projet
|-
| Antoine Delise
| Lead Developer
|-
| Gwenaël Moreau
| Kanban Master
|-

|}

==Tâches==

Répartition générale des tâches
{|class="wikitable"
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Tâche
|-
| Hugo Amodru-Favin
| Application Ionic
|-
| Antoine Delise
| Développement Arduino
|-
| Gwenaël Moreau
| BDD - API
|-

|}

Détail des tâches : [https://waffle.io/delisea/R-Montagne Waffle.io]

=Journal=

{|class="wikitable"
|+
|-
!scope="col" width="120px"| Date
!scope="col" width="350px"| Hugo AMODRU-FAVIN
!scope="col" width="350px"| Antoine DELISE
!scope="col" width="350px"| Gwenaël MOREAU
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 1
|-

|-
| rowspan="1" | Lundi 29/01/18
| style="width: 225px;" |
* Ré-assimilation du sujet
| style="width: 225px;" |
* Ré-assimilation du sujet
| style="width: 225px;" |
* Ré-assimilation du sujet
* Mise en place d'un Kanban
|-
| rowspan="1" | Mardi 30/01/18
| style="width: 225px;" |
* Mise à jour de la page AIR
* Réflexions sur l'implémentation du LoRa
| style="width: 225px;" |
* Mise à jour de la page AIR
* Réflexions sur l'implémentation du LoRa
| style="width: 225px;" |
* Mise en place du calendrier prévisionnel
* Définition et répartition des tâches
|-
| rowspan="1" | Mercredi 31/01/18
| style="width: 225px;" |
* Récupération des cartes Semtech
* Présentation du Hackathon Vinci Energies
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Récupération des cartes Semtech
* Présentation du Hackathon
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Récupération et prise en main des cartes Semtech LoRaMote
* Présentation du Hackathon Vinci Energies
|-
| rowspan="1" | Jeudi 01/02/18
| style="width: 225px;" |
* Choix des fonctionnalités de l'application mobile
| style="width: 225px;" |
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Prise en main des cartes LoRa
|-
| rowspan="1" | Vendredi 02/02/18
| style="width: 225px;" |
* Réflexions sur l'implémentation de l'application
* Démarrage de l'application mobile
* Mises à jour d'Ionic, de Android Studio
| style="width: 225px;" |
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Premières communications fructueuses des cartes Semtech LoRaMote
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 2
|-

|-
| rowspan="1" | Lundi 05/02/18
| style="width: 225px;" |
* Configuration Login et Mot de Passe, Identification base
| style="width: 225px;" |
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Réflexion et création de la base de données
|-
| rowspan="1" | Mardi 06/02/18
| style="width: 225px;" |
* Configuration Login, Mot de passe
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
| style="width: 225px;" |
* Création de l'API REST EN PHP
|-
| rowspan="1" | Mercredi 07/02/18
| style="width: 225px;" |
* Réunion avec Rémi CHOLLET et 3 PEIP D
* Assimilation du fonctionnement de Leaflet
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
| style="width: 225px;" |
* Réunion avec Rémi CHOLLET et 3 PEIP D
* Création de l'API REST en PHP
|-
| rowspan="1" | Jeudi 08/02/18
| style="width: 225px;" |
* Ajout de marqueurs sur Leaflet
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
| style="width: 225px;" |
* Création de l'API REST EN PHP
|-
| rowspan="1" | Vendredi 09/02/18
| style="width: 225px;" |
* Hackathon Vinci Energies
| style="width: 225px;" |
* Hackathon Vinci Energies
| style="width: 225px;" |
* Hackathon Vinci Energies
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 3
|-

|-
| rowspan="1" | Lundi 12/02/18
| style="width: 225px;" |
* Préparation Soutenance
| style="width: 225px;" |
* Mise en place d'un Contiki/Cooja pour faciliter le développement
| style="width: 225px;" |
* Préparation Soutenance
|-
| rowspan="1" | Mardi 13/02/18
| style="width: 225px;" |
* Mise à jour de AIR
* Préparation Soutenance
* Répétition soutenance
| style="width: 225px;" |
* Préparation Soutenance
* Répétition soutenance
* Mise en place d'un Contiki/Cooja pour faciliter le dévelloppement
| style="width: 225px;" |
* Préparation Soutenance
* Répétition soutenance
|-
| rowspan="1" | Mercredi 14/02/18
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
|-
| rowspan="1" | Jeudi 15/02/18
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
|-
| rowspan="1" | Vendredi 16/02/18
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
|-
| rowspan="1" | Interruption de Février
| style="width: 225px;" |
| style="width: 225px;" |
* Développement sur Contiki/Cooja afin de réaliser un routage dynamique
| style="width: 225px;" |
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 4
|-

|-
| rowspan="1" | Lundi 26/02/18
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Travail sur l'affichage des éléments sur la carte utilisateur
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Continuation du travail sur Contiki
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Corrections de l'API en accord avec l'application mobile
* Modifications sur la base de données
|-
| rowspan="1" | Mardi 27/02/18
| style="width: 225px;" |
* Création de la page de création d'un nouvel utilisateur
* Design de l'application mobile
| style="width: 225px;" |
* Fin du protocole de routage Contiki, tests virtuels de fonctionnement
| style="width: 225px;" |
* Liaison entre l'application mobile et l'API
|-
| rowspan="1" | Mercredi 28/02/18
| style="width: 225px;" |
* Fin de la page de création d'un nouvel utilisateur
* Ajout de l'utilisation des sessions dans l'application
| style="width: 225px;" |
* Panne ordinateur personnel
* Perte des données du routage dynamique malgré une tentative de back-up avant la panne
* Travail sur l'application mobile avec Hugo
| style="width: 225px;" |
* API : Création d'un utilisateur
* API : Récupération des informations nécessaires pour la carte
* API : Ajout de l'utilisation des sessions pour stocker l'utilisateur connecté
|-
| rowspan="1" | Jeudi 01/03/18
| style="width: 225px;" |
* Affichage des informations sur la Map
| style="width: 225px;" |
* Affichage des informations sur la Map
| style="width: 225px;" |
* API : Récupération des informations nécessaires pour la carte
|-
| rowspan="1" | Vendredi 02/03/18
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Réparation d'ordinateur personnel
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Renseignements sur Swagger
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 5
|-

|-
| rowspan="1" | Lundi 05/03/18
| style="width: 225px;" |
* Restructuration de l'application, amélioration visuelle
* Logout fonctionnel
| style="width: 225px;" |
* Finalisation de la carte, et ajout de la gestion des différentes cartes
* Restructuration de l'application
| style="width: 225px;" |
* Création d'une page Swagger
* Corrections de l'API
* Ajout des cartes dans la base de données
* Récupération des éléments liés à la carte dans l'API
|-
| rowspan="1" | Mardi 06/03/18
| style="width: 225px;" |
* Ajout gestion secouriste
* Développement de la page Account, modification utilisateur
| style="width: 225px;" |
* Ajout gestion secouriste
* Création vues côté secouristes
| style="width: 225px;" |
* Fin du Swagger
* API : Modifications utilisateur
* API : Modifications mot de passe
* Base de données : Ajout affectations secouristes-cartes
* API : Récupération des cartes pour un secouriste
|-
| rowspan="1" | Mercredi 07/03/18
| style="width: 225px;" |
* Amélioration et finalisation de la page Account
| style="width: 225px;" |
* Corrections du menu et de la navigation
| style="width: 225px;" |
* Programme de récupération des messages à la racine et inscription des données dans la base de données
|-
| rowspan="1" | Jeudi 08/03/18
| style="width: 225px;" |
* Extraction des dents de sagesse
| style="width: 225px;" |
*
| style="width: 225px;" |
* Création du programme de communication LoRa et récupération des coordonnées GPS depuis la carte SodaqONE
* Tests de temps de synchronisation et précision du GPS
|-
| rowspan="1" | Vendredi 09/03/18
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Design du LogoV2, Embellie CSS de l'application mobile
* Réunion avec les PEIP D
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
*
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Finition du programme de communication LoRa
* Tests d'envoi de la carte SodaqONE vers la base de données en passant par une racine (carte Arduino LoRa)
|-
| rowspan="1" | Samedi 10/03/18
| style="width: 225px;" |
* Réflexions et implémentations des Usercases concernant la gestion des licences
* Ajout de notifications mobiles
* Ajout d'une page liée à la gestion des Trackers
* Poster Anniversaire
| style="width: 225px;" |
* Réflexions et implémentations des Usercases concernant la gestion des licences
* Ajout de notifications mobiles
| style="width: 225px;" |
* Tests du programme de communication avec les LoRas
|-
| rowspan="1" | Dimanche 11/03/18
| style="width: 225px;" |
* Implémentations des usercases liées à la gestion des licences côté application
| style="width: 225px;" |
* Implémentations des usercases liées à la gestion des licences côté api
| style="width: 225px;" |
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 6
|-

|-
| rowspan="1" | Lundi 12/03/18
| style="width: 225px;" |
* Ajouts de fonctionnalités dans l'application
| style="width: 225px;" |
* Correctifs programme de communication
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Correctifs programme de communication
|-
| rowspan="1" | Mardi 13/03/18
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Finalisation des fonctionnalités de l'application
* Correctifs des bugs
* Test Réel à la Bastille
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Finalisation des fonctionnalités de l'application
* Correctifs des bugs
* Page de création de Map Admin
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Préparation des capteurs pour le test réel
* Test Réel à la Bastille
|-
| rowspan="1" | Mercredi 14/03/18
| style="width: 225px;" |
* Préparation de la soutenance
* Finalisation du Poster
* Test Réel aux Taillées
| style="width: 225px;" |
* Préparation de la soutenance
* Préparation de la démonstration
* Dernier correctifs de l'application
| style="width: 225px;" |
* Préparation de la soutenance
* Finalisation du Poster
* Test Réel aux Taillées
|-
| rowspan="1" | Jeudi 15/03/18
| style="width: 225px;" |
* Soutenance de Projet
| style="width: 225px;" |
* Soutenance de Projet
| style="width: 225px;" |
* Soutenance de Projet
|}

=Collaboration avec le DUT RT et les PEIPs D=
L'objectif de cette collaboration est de familiariser des étudiants en PEIP D avec des projets qu'ils seront amenés à développer dans les prochaines années. Nous avons rencontré Rémi CHOLLET et 3 étudiants Mercredi 7 Février, en voici un résumé écrit par Mr CHOLLET définissant les contours de cette collaboration.

"Un rapide résumé de la rencontre que nous avons eu ce matin avec le projet R’Montagne.

Présents :
- RCIM5 Gwenael Moreau, Hugo Amodru-Favin
- PEIP-D : Yoann Goma-Missamou, Vincent Cadoux, Philippe Charrat
- IUT : Rémy Chollet, tuteur pédagogique des PEIP-D
Excusés : Didier Donsez, blessé (aie ! courage …), Antoine Delise en cours de marketing

Contexte :
Les PEIP-D participent aux projets RICM5 en prenant une tâche « annexe » (hors chemin critique) en charge. L’objectif est une expérience d’immersion + notation liée au PEIP.

Déroulé :
Les étudiant RCIM5 ont présenté le projet dans son principe et état d’avancement. Les échanges se sont portés sur l’idée de mener une étude (simulation et mesure) sur la consommation des balises par les PEIP-D avec pour objectif de dimensionner la réserve d’énergie.

Ceci implique :
- coté RCIM5 : mise à disposition d’une carte prototype.

- cote PEIP-D : inventaire des paramètres à prendre en compte :
* consommation carte (GPS + puce LoRa) = > veille + temps d’activation (recherche à faire sur le temps de synchronisation du GPS)
* puissance d’émission à calibrer en fonction de la couverture voulue et débit (voir Spread Factor ?)
* temps d’émission-réception (émission jusqu’à acquittement)

- cote PEIP-D : penser la manip pour valider ce modèle
* mesure moyenne du courant
* configuration effective du réseau
* réserver le matériel (voir Jean-Yves Frau au département R&T ?)

- cote PEIP-D : paramètrer les simulations et mesures en fonction de puissance d’émission (ou autre élément pouvant apparaitre comme pertinent)

D’une manière générale, pour les PEID-D :
- penser bibliographie (pour commencer : https://fr.wikipedia.org/wiki/LoRaWAN et aussi https://fr.wikipedia.org/wiki/Format_des_piles_et_accumulateurs_électriques :-) )
- planifier
- communiquer : reporting !!!"

=Description du sujet=

==Randonnée et risques==

Ouvert à tous, la randonnée est un sport et un loisir qui prend de plus en plus d’ampleur de nos jours. Ne nécessitant pas de grands prérequis, des milliers de personnes se lancent en montagne chaque jour, malheureusement parfois sans connaître toutes les mesures de sécurité associées.

En effet, de janvier à juin 2016, en randonnée et en alpinisme, l’Association Nationale pour l’Étude de la Neige et des Avalanches (ANENA) a comptabilisé 21 accidents notables, dont 8 accidents mortels, impliquant 15 décès.

Aujourd’hui, les mesures de sécurités préconisent que chaque groupe de randonneur se doivent de se munir d’un téléphone portable afin d’appeler les secours en cas de problème. Malheureusement, la communication mobile dépendant de la couverture réseau, peu présente en montagne, l’impossibilité de joindre les secours reste un problème.

==Solutions existantes==

La solution la plus répandue, est celle du téléphone à connexion satellite. Ayant une communication vers les satellites, cela permet une couverture réseau beaucoup plus répandue dans les montagnes, partout dans le monde (ou presque). Cependant, les téléphones portables satellitaires coûtent chers, et ne sont pas forcément abordables par la plupart des personnes, surtout celles ne sortant qu’occasionnellement.

[https://fall-alarm.net/ Fall Alarm] est un système de détection de chute sur chantier utilisant les mêmes technologies dont nous avons besoin pour notre projet.

==Quelles zones géographiques ?==

Toutes les zones montagneuses peuvent présenter des zones blanches, démunies de connexion quelconque autre que les connexions satellitaires. Certaines chaînes de montagne comme la Cordillaire des Andes ne présentent aucune connexion possible quelconque.

Dans le cadre de notre projet, nous fonctionnerons essentiellement dans la localisation grenobloise avec l'objectif que notre solution soit applicable partout dans le monde. Une contrainte intervient tout de même étant donnée que la fréquence d'utilisation du LoRa en Europe est de 868MHz, 915MHz en Amérique et 433MHz en Asie.

= Fonctionnalités =

Afin de remplir au mieux ses attentes, le principal objectif de ce dispositif sera premièrement de pouvoir communiquer avec les secours à n’importe quel moment, et surtout n’importe où. De plus, il sera capable de détecter de nombreux cas de détresse de la part de l’usager afin de pouvoir lancer un appel d’urgence sans interaction avec l’usager, au cas où il serait inconscient, ou incapable de lancer un appel manuel.

Grâce aux accéléromètres, le dispositif sera à même de détecter un mouvement brutal du randonneur, ce qui pourrait s’apparenter à une chute. Ils pourront également détecter une position anormale, ou une immobilité prolongée, ce qui déclencherait le dispositif d’urgence automatiquement.

Grâce à des tests réalisés au préalable, le boîtier pourra détecter correctement les chûtes de simples mouvements, afin de ne pas lancer l’appel sans raison valable.

Avant de lancer une alerte automatique, le dispositif émettra un signal auditif et visuel à l’utilisateur quelques secondes auparavant, afin de le prévenir l'émission du signal d’urgence, et de lui proposer de le désactiver sur simple pression d’un bouton, afin d’éviter les communications inutiles.

Également, le randonneur sera à même d'émettre volontairement un appel d’urgence à l’aide du bouton, ce qui permet à tout moment d’appeler de l’aide sans effort. Cela peut permettre également à appeler les secours pour une personne en danger qui ne porterait pas le dispositif.

L’appel au secours se représente par un envoi de coordonnées GPS aux secours, via une communication radio LoRa vers des bornes relais placées au préalables en montagne. Cette communication irait de relai de relai jusqu’au centre de sécurité, d’où le message serait transmis aux secours.

De plus, une application mobile verra le jour afin de connecter tous les utilisateurs du module de sécurité, de les visualiser sur une map, et de partager leurs données. En effet, à chaque incident, l’application mettra à jour la position et de la date de l’accident, afin de permettre aux prochains utilisateurs d’être prévenus. Ils pourraient, s'ils sont à proximité, d'assister la personne en détresse en attendant l'arrivée des secours. Bien évidemment, cette application ne sera accessible uniquement si le smartphone de l'utilisateur est relié à une connexion 4G ou Wi-Fi.

Cette prévention pourrait les sensibiliser aux risques de la montagne, leur permettre d’éviter le secteur mais aussi d’aider les personnes en danger si la distance le permet.

= Exigences =
== Fonctionnelles ==

*Batterie garantie fonctionnelle 1 semaine
*Rechargement possible via le panneau solaire portable
*Dispositif pouvant être allumé et éteint par l'utilisateur
*Alarme s’enclenche automatiquement dès qu'elle est considérée nécessaire, signal sonore
*Utilisateur a la possibilité d’activer/désactiver l’alarme quand il le souhaite
*Lorsque l’alarme est active, l’appareil ne peut s’éteindre
*...

== Non-Fonctionnelles ==

*Résistance : aux chocs, impacts, waterproof (utilisé en permanence en plein air)
*Disponibilité : Appareil de secours -> Doit être au plus possible performant
*Performance : Minimiser les pertes réseaux
*Accessible : Utilisateur pas forcément familier avec des appareils électroniques (facile d’utilisation)
*Fiabilité : Précision du GPS (rayon de 10m), données non-éronnées
*Coût : Le plus faible possible pour vendre le moins cher possible
*Efficacité : Réduire la consommation, utiliser le moins possible les ressources

= Composants =
== LoRaONE ==
Pour le coeur du projet, après avoir cherché et comparés plusieurs modules LoRa, GPS ou encore accéléromètres, nous avons finalement opté pour le projet LoRaONE.

LoRaONE est un projet de SODAQ regroupant plusieurs composants dans une seule et même carte, de taille réduite.

https://www.kickstarter.com/projects/sodaq/loraone-the-lora-iot-development-board

“The one IoT development board to rule them all” --SODAQ

Cette carte regroupe plusieurs capteurs afin de respecter aux mieux nos exigences :

Un émetteur/récepteur LoRa afin de pouvoir communiquer au mieux avec les antennes relai à longue distance

Un module + antenne GPS de bonne précision (< 10m) pour connaître en tout temps notre position, et ainsi faciliter l’arrivée des secours, ainsi que la recherche de l’individu en détresse

Un accéléromètre sur 3 axes afin de pouvoir détecter tout mouvement, vitesse ou rotation dans l’espace, ce qui permet la détection de chutes ou d’arrêt de mouvements

3 LED RGB afin de pouvoir signaler à l’utilisateur un manque de batterie, un signal d’urgence ou plus si nécessaire

Un bouton poussoir pour le signal d’alarme

Un connecteur de charge par panneau solaire, afin de faire durer chaque batterie le plus longtemps possible

Un connecteur micro-USB ainsi que des lignes pour se connecter à une base Arduino si besoin

[[File:LoRaOne.png||400px|Spécifications carte LoRaOne]]

De plus, grâce au starter pack, nous pouvons avoir accès à la base ONEBase qui nous permettrait d’étendre plus loin la facilité d’utilisation du produit :

[[File:LoRaOneBase.png||400px|Spécifications base LoRaOneBase]]

Comme nous pouvons le voir, cette base nous permettra de connecter la batterie ainsi que le panneau solaire qui sont fournis dans le pack.

Nous pourrons également connecter jusqu’à 4 modules supplémentaires.

La batterie fournie aura une capacité de 800 mAh, le panneau solaire fourni pouvant délivrer jusqu’à 500 mW de puissance.

Le total atteint une taille d’environ 10*5 cm, ce qui n’est pas excessif, ce qui le rend aisément portatif sur une jambe ou à la taille.

'''Coût : 115€'''

Ce module pourra également servir d’antenne relai, l'alimentation solaire devrait maintenir le dispositif chargé en permanence. Des tests seront effectués pour savoir si un panneau solaire plus puissant est requis.

== Boîtier ==

Le boîtier sécurisé devant respecter plusieurs exigences, nous pouvons le construire en plastique résistant, ce qui le rendrait léger tout en respectant une rigidité suffisante. Les antennes pourront être placées le long du boîtier, à l’intérieur si la connexion est suffisante, ou à l’extérieur. Dans ce dernier cas les trous réalisés sur le boîtier afin de laisser passer les câbles seront colmatés afin de garantir une étanchéité.

[[File:SchemaBoitier.png||100px|Schéma boitier d'alarme]]

== Balises ==

Afin de remonter les informations transmises par les boitiers, des balises seront mises en places sur la zone à couvrir, leur nombre et leur positions dépendra du terrain (obstacles, dénivelés). On distinguera deux types de balises. Tout d’abord, les balises racines qui permettront une communication GSM afin de faire remonter les données vers le serveur. Viennent ensuite les balises standard qui se contenteront de faire remonter vers leur balise racine associée. L’architecture de liaison des balises est détaillée dans une prochaine partie.

Chaque balise est composée d’une barre de fer pouvant être plantée dans le sol, d’un système de lest afin d’immobiliser la balise, d’un paratonnerre, d’un panneau solaire ainsi que d’un LoraOne et d’une batterie. Les balises racines seront équippée en plus d’un dispositif de communication GSM (téléphone portable, émetteur GSM).

[[File:SchemaBalise.png||150px|Schéma balises d'alarme]]

== Application mobile ==
Une application mobile est téléchargeable par les utilisateurs. Ils peuvent voir les autres utilisateurs présents dans leur zone. Lorsqu’un utilisateur est en position de danger, une notification apparaît si les utilisateurs sont proches de la situation de danger.

Cette application n’est pas directement reliée au dispositif. Elle ne fonctionne qu’avec la connexion du mobile, et est destinée à être un niveau de sécurité supérieur. Un randonneur proche d’une zone de danger pourrait arriver sur place plus rapidement que les secours.

= Communication =

Pour un envoi de position + numéro d’identification (X chiffres) :

*Temps de communication : < 2 s
*Communication régulière, intervalle de 15 minutes

On peut donc au maximum avoir 15 * 60 / 2 = 450 individus pouvant communiquer avec la même antenne relai, donc dans le même cercle d’environ 15 km de diamètre.

On communique donc au minimum 2 secondes sur 15 minutes, donc 1/450 << 1%, le temps de communication est respecté.

En cas de problème, nous pouvons envoyer jusqu’à 9x plus avec la borne sans dépasser le temps de communication autorisé (1%). Donc 1 envoi d’appel d’urgence toutes les 2 minutes environ.

La balise racine peut être directement connectée au serveur, dans ce cas, il n’y a pas de communication GSM nécessaire et pas de Gateway. Si la racine n’est pas directement connectée au serveur, elle devra au minimum garantir une communication GSM (ce qu’elle peut faire, il n’y a pas de Gateway nécessaire) pour remonter l’information vers le serveur, et donc la base de données.

GSM : Si Racine connectée à Serveur -> No GSM + Gateway
Else : GSM + Gateway : LoRa Racine connectée ordi (RaspberryPI) + ordi connecté GSM

= Stabilisation et gestion d’erreurs =

== Choix du routage ==

Notre réseau n'est pas un réseau traditionnel. Les seules communications existantes sont soit une remontée d'information vers la racine soit une innondation d'alerte vers les clients. Pour celà nous avons donc décidé d'utiliser un algorithme de routage simplifié basé uniquement sur un arbre en largeur des balises. Nous rajoutons en option la possibilité de créer plusieurs racines et donc plusieurs arbres dont les racines communiquent par gsm. Nous nous basons sur des papiers de recherches afin de déterminer quel algorithme auto-stabilisant est le plus adapté au système LoRa (Tel que le papier "A self-stabilizing algorithm for constructing breadth-first trees" par Shing-Tsaan Huang, Nian-Shing Chen).

== Stabilisation ==

Afin de gérer la communication de chaque message vers le serveur, nous allons prendre un noeud (balise LoRa) dit “racine” connecté directement au serveur, nous ne nous occuperons pas de la communication au serveur dans cet onglet. Chaque message reçu de la part d’un noeud du système doit être relayé jusqu’à la racine du système afin de communiquer avec les secours (ou serveur simplement).

Pour cela, il faudra assurer que chaque balise LoRa soit connecté au réseau, afin d’avoir au départ un graphe de communication connexe. Par dessus ce graphe, nous allons utiliser un processus silencieux auto-stabilisant qui construira un arbre de parcours en largeur, avec pour racine le noeud “racine” décidé ci-dessus.

Au lancement du système, il faut prévoir un léger temps de stabilisation, qui dépendrait de l’algorithme et de la taille du graphe (nombre de balises). Cependant, après cela, l’algorithme assure un arbre en profondeur minimal qui nous permettrai de communiquer avec la racine le plus rapidement possible, et donc une qualité de service maximale.

== Gestion d’erreurs ==

Dans un réseau comme celui-ci, plusieurs types d’erreurs peuvent se produire :
Délai de communication trop important vers une balise
“Crash” d’une balise de communication
Surpopulation d’une balise ou congestion de messages

Afin de palier au premier type d’incident rencontré, il faut nécessairement qu’à chaque emplacement dans la zone couverte, l’utilisateur soit à même de communiquer avec au minimum 2 balises différentes. Ainsi, dans le cas d’une communication trop longue sur une balise, l’autre aurait de grandes chances de délivrer le message plus rapidement.

Au niveau de la défaillance d’une balise, l’algorithme d’arbre en profondeur nous fournit déjà une solution intégrée grâce à son auto-stabilisation. Dans le cas de déconnexion d’une balise, l’algorithme mettrai à jour automatiquement l’arbre de communication, et n’importe quel message d’alerte émis serait délivré dans un délai raisonnable.

Pour le troisième cas d’erreur, il n’y aurait pas de solution réelle, si ce n’est de limiter le nombre de communications données, en ne prenant plus en compte les “ping” de chaque utilisateur mais seulement les messages d’alertes, ce qui permettrai une bien plus grande gestion de la congestion à un endroit donné. Également, une balise en dessous d’un lien congestionné pourrait communiquer avec ses autres voisins (non-fils dans l’arbre) afin de libérer de l’espace dans le lien avec son père dans l’arbre. Également, le système ne pourra accepter que jusqu’à 1000 utilisateurs par noeud, et également 4000 utilisateurs par cluster (dans le cas d’un réseau avec plusieurs clusters donc plusieurs racines cette limite augmente).

Plusieurs types de paquets circulent sur le réseau de balise:
Les pings, messages envoyés spontanéments à intervalle régulier par les utilisateur contenant l’id ainsi que les deux coordonées gps (27 bits chacun)
Les incidents, identique à un ping mais à priorité haute.
Les alertes, messages brodcastés par le serveur afin d’envoyer un message en chaine de caractères courts et compressés.

=Coûts matériels=

Que ce soit pour le dispositif utilisateur ou la balise (racine ou non), le LoRaOne correspond pour permettre les actions recherchées. Afin de réaliser un prototype pertinent, 6 kits LoRaOne sont requis. Ces kits sont accessibles sur le site de Sodaq au prix de 115€ chacun (prix variable).
Disponible [https://shop.sodaq.com/en/one-eu-rn2483-v2.html ici], voir avant dernier bundle : starter "ONE EU starter" actuellement à 112,10€.

Un [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer buzzer] est à ajouter au dispositif utilisateur afin de lui délivrer un signal sonore.

Un shield GSM est requis pour que la balise racine communique avec l'extérieur. Sodaq en propose un designé pour fonctionner sur leurs produits mais est éctuellement en rupture de stock. Un shield GSM arduino convient tout autant et peut être trouvé sur le site arduino [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna ici].

Aucun boitier ne sera commandé car nous avons fait le choix de les manufacturer nous même au fablab. Le besoin d'étanchéité n'est pas primordial pour notre prototype, bien que nous tenterons de l'assurer.

{|class="récap commande"
|+ Récapitulatif
|-
|
!scope="col" style="width: 320px;"| Produit
!scope="col" style="width: 80px;"| Lien
!scope="col" style="width: 80px;"| Quantité
!scope="col" style="width: 80px;"| Prix Unitaire
|-

!scope="row"| 1
| LoRaOne EU Starter
| [https://shop.sodaq.com/en/one-eu-rn2483-v2.html Achat]
| 6
| 115€
|-

!scope="row"| 2
| Buzzer
| [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer Achat]
| 3
| 5.49€
|-

!scope="row"| 3
| Shield GSM
| [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna Achat]
| 1
| 65€
|-

|}

=Développement=

Nous utiliserons les librairies standards Arduino ainsi que celle de SODAQ/Arduino pour le LoRa.

L'IDE Arduino sera utilisé, plus pratique pour l'utilisation de Git (comparé à Mbed).

= Mise sur le marché =

Ce dispositif a pour but d’être utilisé en montagne, lors de randonnée. Il n’est pas destiné à un usage quotidien, c’est pourquoi nous considérons qu’il est plus judicieux de louer les dispositifs plutôt que de les vendre, même si l’achat n’est pas à omettre de notre stratégie.

Le dispositif peut être commandé en ligne, puis retourné par la poste après usage. Le client louerait le dispositif pour une certaine durée avec un possible nombre supplémentaire de batterie. Les tarifs varient en fonction de la durée et du nombre de batteries louées. Des offres de groupes pourraient être applicables. A long terme, des boutiques pourraient être disséminées dans des grandes villes proches des zones montagneuses, zones à randonnées (Grenoble, Annecy, etc.).

L’application est téléchargeable gratuitement par quiconque, mais utilisable seulement par les clients. Un code d’accès sera envoyé avec le dispositif expirant après la fin de la location.

Il faudra tenir compte de la bande passante du LoRa, variante en fonction des continents.

=Planning prévisonnel=

Sprint 1 : 29/01 --> 09/02 : Création du prototype logiciel #1
*Prise en main du matériel
*Premiers tests de transmissions LoRa
*Création du protocole d'architecture des balises
*Application sur les cartes et tests
*Tests de performances des cartes (durabilité, chargement, batterie)
*Tests de maintenabilité de l'algorithme (déconnexions, latences)

Sprint 2 : 12/02 --> 23/02 : Prototype logiciel #2 et prototype matériel
*Création du programme embarqué (utilisateur)
*Communication avec la racine et le serveur
*Création des maquettes boîtier et balise
*Construction des maquettes
*Finalisation du premier prototype

Sprint 3 : 26/02 --> 09/03 : Fonctionnalités supplémentaires
*Ajout de la communication entre le LoRa et le GSM sur la balise racine
*Création application mobile utilisateur
*Tests sur l'application
*Tests sur la transmission totale depuis l'utilisateur vers le serveur via le GSM
*Finalisation du projet

Sprint 4 : 12/03 --> 16/03 : Fin du projet
*Création de la documentation finale (à partir de la documentation réalisée en continu)
*Pause café
*Temps supplémentaire en cas de problèmes importants
*Préparation de la soutenance

R'Montagne

2018-03-14T09:54:41Z

Hugo.Amodru-Favin: /* Journal */

=Équipe=
{|class="wikitable"
|-
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Rôle
|-
| Hugo Amodru-Favin
| Chef de Projet
|-
| Antoine Delise
| Lead Developer
|-
| Gwenaël Moreau
| Kanban Master
|-

|}

==Tâches==

Répartition générale des tâches
{|class="wikitable"
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Tâche
|-
| Hugo Amodru-Favin
| Application Ionic
|-
| Antoine Delise
| Développement Arduino
|-
| Gwenaël Moreau
| BDD - API
|-

|}

Détail des tâches : [https://waffle.io/delisea/R-Montagne Waffle.io]

=Journal=

{|class="wikitable"
|+
|-
!scope="col" width="120px"| Date
!scope="col" width="350px"| Hugo AMODRU-FAVIN
!scope="col" width="350px"| Antoine DELISE
!scope="col" width="350px"| Gwenaël MOREAU
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 1
|-

|-
| rowspan="1" | Lundi 29/01/18
| style="width: 225px;" |
* Ré-assimilation du sujet
| style="width: 225px;" |
* Ré-assimilation du sujet
| style="width: 225px;" |
* Ré-assimilation du sujet
* Mise en place d'un Kanban
|-
| rowspan="1" | Mardi 30/01/18
| style="width: 225px;" |
* Mise à jour de la page AIR
* Réflexions sur l'implémentation du LoRa
| style="width: 225px;" |
* Mise à jour de la page AIR
* Réflexions sur l'implémentation du LoRa
| style="width: 225px;" |
* Mise en place du calendrier prévisionnel
* Définition et répartition des tâches
|-
| rowspan="1" | Mercredi 31/01/18
| style="width: 225px;" |
* Récupération des cartes Semtech
* Présentation du Hackathon Vinci Energies
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Récupération des cartes Semtech
* Présentation du Hackathon
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Récupération et prise en main des cartes Semtech LoRaMote
* Présentation du Hackathon Vinci Energies
|-
| rowspan="1" | Jeudi 01/02/18
| style="width: 225px;" |
* Choix des fonctionnalités de l'application mobile
| style="width: 225px;" |
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Prise en main des cartes LoRa
|-
| rowspan="1" | Vendredi 02/02/18
| style="width: 225px;" |
* Réflexions sur l'implémentation de l'application
* Démarrage de l'application mobile
* Mises à jour d'Ionic, de Android Studio
| style="width: 225px;" |
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Premières communications fructueuses des cartes Semtech LoRaMote
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 2
|-

|-
| rowspan="1" | Lundi 05/02/18
| style="width: 225px;" |
* Configuration Login et Mot de Passe, Identification base
| style="width: 225px;" |
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Réflexion et création de la base de données
|-
| rowspan="1" | Mardi 06/02/18
| style="width: 225px;" |
* Configuration Login, Mot de passe
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
| style="width: 225px;" |
* Création de l'API REST EN PHP
|-
| rowspan="1" | Mercredi 07/02/18
| style="width: 225px;" |
* Réunion avec Rémi CHOLLET et 3 PEIP D
* Assimilation du fonctionnement de Leaflet
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
| style="width: 225px;" |
* Réunion avec Rémi CHOLLET et 3 PEIP D
* Création de l'API REST en PHP
|-
| rowspan="1" | Jeudi 08/02/18
| style="width: 225px;" |
* Ajout de marqueurs sur Leaflet
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
| style="width: 225px;" |
* Création de l'API REST EN PHP
|-
| rowspan="1" | Vendredi 09/02/18
| style="width: 225px;" |
* Hackathon Vinci Energies
| style="width: 225px;" |
* Hackathon Vinci Energies
| style="width: 225px;" |
* Hackathon Vinci Energies
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 3
|-

|-
| rowspan="1" | Lundi 12/02/18
| style="width: 225px;" |
* Préparation Soutenance
| style="width: 225px;" |
* Mise en place d'un Contiki/Cooja pour faciliter le développement
| style="width: 225px;" |
* Préparation Soutenance
|-
| rowspan="1" | Mardi 13/02/18
| style="width: 225px;" |
* Mise à jour de AIR
* Préparation Soutenance
* Répétition soutenance
| style="width: 225px;" |
* Préparation Soutenance
* Répétition soutenance
* Mise en place d'un Contiki/Cooja pour faciliter le dévelloppement
| style="width: 225px;" |
* Préparation Soutenance
* Répétition soutenance
|-
| rowspan="1" | Mercredi 14/02/18
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
|-
| rowspan="1" | Jeudi 15/02/18
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
|-
| rowspan="1" | Vendredi 16/02/18
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
|-
| rowspan="1" | Interruption de Février
| style="width: 225px;" |
| style="width: 225px;" |
* Développement sur Contiki/Cooja afin de réaliser un routage dynamique
| style="width: 225px;" |
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 4
|-

|-
| rowspan="1" | Lundi 26/02/18
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Travail sur l'affichage des éléments sur la carte utilisateur
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Continuation du travail sur Contiki
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Corrections de l'API en accord avec l'application mobile
* Modifications sur la base de données
|-
| rowspan="1" | Mardi 27/02/18
| style="width: 225px;" |
* Création de la page de création d'un nouvel utilisateur
* Design de l'application mobile
| style="width: 225px;" |
* Fin du protocole de routage Contiki, tests virtuels de fonctionnement
| style="width: 225px;" |
* Liaison entre l'application mobile et l'API
|-
| rowspan="1" | Mercredi 28/02/18
| style="width: 225px;" |
* Fin de la page de création d'un nouvel utilisateur
* Ajout de l'utilisation des sessions dans l'application
| style="width: 225px;" |
* Panne ordinateur personnel
* Perte des données du routage dynamique malgré une tentative de back-up avant la panne
* Travail sur l'application mobile avec Hugo
| style="width: 225px;" |
* API : Création d'un utilisateur
* API : Récupération des informations nécessaires pour la carte
* API : Ajout de l'utilisation des sessions pour stocker l'utilisateur connecté
|-
| rowspan="1" | Jeudi 01/03/18
| style="width: 225px;" |
* Affichage des informations sur la carte
| style="width: 225px;" |
* Affichage des informations sur la carte
| style="width: 225px;" |
* API : Récupération des informations nécessaires pour la carte
|-
| rowspan="1" | Vendredi 03/03/18
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Réparation d'ordinateur personnel
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Renseignements sur Swagger
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 5
|-

|-
| rowspan="1" | Lundi 05/03/18
| style="width: 225px;" |
* Restructuration de l'application, amélioration visuelle
* Logout fonctionnel
| style="width: 225px;" |
* Finalisation de la carte, et ajout de la gestion des différentes cartes
* Restructuration de l'application
| style="width: 225px;" |
* Création d'une page Swagger
* Corrections de l'API
* Ajout des cartes dans la base de données
* Récupération des éléments liés à la carte dans l'API
|-
| rowspan="1" | Mardi 06/03/18
| style="width: 225px;" |
* Ajout gestion secouriste
* Développement de la page Account, modification utilisateur
| style="width: 225px;" |
* Ajout gestion secouriste
* Création vues côté secouristes
| style="width: 225px;" |
* Fin du Swagger
* API : Modifications utilisateur
* API : Modifications mot de passe
* Base de données : Ajout affectations secouristes-cartes
* API : Récupération des cartes pour un secouriste
|-
| rowspan="1" | Mercredi 07/03/18
| style="width: 225px;" |
* Amélioration et finalisation de la page Account
| style="width: 225px;" |
* Corrections du menu et de la navigation
| style="width: 225px;" |
* Programme de récupération des messages à la racine et inscription des données dans la base de données
|-
| rowspan="1" | Jeudi 08/03/18
| style="width: 225px;" |
* Extraction des dents de sagesse
| style="width: 225px;" |
*
| style="width: 225px;" |
* Création du programme de communication LoRa et récupération des coordonnées GPS depuis la carte SodaqONE
* Tests de temps de synchronisation et précision du GPS
|-
| rowspan="1" | Vendredi 09/03/18
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Design du LogoV2, Embellie CSS de l'application mobile
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
*
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Finition du programme de communication LoRa
* Tests d'envoi de la carte SodaqONE vers la base de données en passant par une racine (carte Arduino LoRa)
|-
| rowspan="1" | Samedi 10/03/18
| style="width: 225px;" |
* Réflexions et implémentations des Usercases concernant la gestion des licences
* Ajout de notifications mobiles
* Ajout d'une page liée à la gestion des Trackers
* Poster Anniversaire
| style="width: 225px;" |
* Réflexions et implémentations des Usercases concernant la gestion des licences
* Ajout de notifications mobiles
| style="width: 225px;" |
* Tests du programme de communication avec les LoRas
|-
| rowspan="1" | Dimanche 11/03/18
| style="width: 225px;" |
* Implémentations des usercases liées à la gestion des licences côté application
| style="width: 225px;" |
* Implémentations des usercases liées à la gestion des licences côté api
| style="width: 225px;" |
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 6
|-

|-
| rowspan="1" | Lundi 12/03/18
| style="width: 225px;" |
* Ajouts de fonctionnalités dans l'application
| style="width: 225px;" |
* Correctifs programme de communication
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Correctifs programme de communication
|-
| rowspan="1" | Mardi 13/03/18
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Finalisation des fonctionnalités de l'application
* Correctifs des bugs
* Test Réel à la Bastille
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Finalisation des fonctionnalités de l'application
* Correctifs des bugs
* Page de création de Map Admin
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Préparation des capteurs pour le test réel
* Test Réel à la Bastille
|-
| rowspan="1" | Mercredi 14/03/18
| style="width: 225px;" |
* Préparation de la soutenance
* Finalisation du Poster
* Test Réel aux Taillées
| style="width: 225px;" |
* Préparation de la soutenance
* Préparation de la démonstration
* Dernier correctifs de l'application
| style="width: 225px;" |
* Préparation de la soutenance
* Finalisation du Poster
* Test Réel aux Taillées
|-
| rowspan="1" | Jeudi 15/03/18
| style="width: 225px;" |
* Soutenance de Projet
| style="width: 225px;" |
* Soutenance de Projet
| style="width: 225px;" |
* Soutenance de Projet
|}

=Collaboration avec le DUT RT et les PEIPs D=
L'objectif de cette collaboration est de familiariser des étudiants en PEIP D avec des projets qu'ils seront amenés à développer dans les prochaines années. Nous avons rencontré Rémi CHOLLET et 3 étudiants Mercredi 7 Février, en voici un résumé écrit par Mr CHOLLET définissant les contours de cette collaboration.

"Un rapide résumé de la rencontre que nous avons eu ce matin avec le projet R’Montagne.

Présents :
- RCIM5 Gwenael Moreau, Hugo Amodru-Favin
- PEIP-D : Yoann Goma-Missamou, Vincent Cadoux, Philippe Charrat
- IUT : Rémy Chollet, tuteur pédagogique des PEIP-D
Excusés : Didier Donsez, blessé (aie ! courage …), Antoine Delise en cours de marketing

Contexte :
Les PEIP-D participent aux projets RICM5 en prenant une tâche « annexe » (hors chemin critique) en charge. L’objectif est une expérience d’immersion + notation liée au PEIP.

Déroulé :
Les étudiant RCIM5 ont présenté le projet dans son principe et état d’avancement. Les échanges se sont portés sur l’idée de mener une étude (simulation et mesure) sur la consommation des balises par les PEIP-D avec pour objectif de dimensionner la réserve d’énergie.

Ceci implique :
- coté RCIM5 : mise à disposition d’une carte prototype.

- cote PEIP-D : inventaire des paramètres à prendre en compte :
* consommation carte (GPS + puce LoRa) = > veille + temps d’activation (recherche à faire sur le temps de synchronisation du GPS)
* puissance d’émission à calibrer en fonction de la couverture voulue et débit (voir Spread Factor ?)
* temps d’émission-réception (émission jusqu’à acquittement)

- cote PEIP-D : penser la manip pour valider ce modèle
* mesure moyenne du courant
* configuration effective du réseau
* réserver le matériel (voir Jean-Yves Frau au département R&T ?)

- cote PEIP-D : paramètrer les simulations et mesures en fonction de puissance d’émission (ou autre élément pouvant apparaitre comme pertinent)

D’une manière générale, pour les PEID-D :
- penser bibliographie (pour commencer : https://fr.wikipedia.org/wiki/LoRaWAN et aussi https://fr.wikipedia.org/wiki/Format_des_piles_et_accumulateurs_électriques :-) )
- planifier
- communiquer : reporting !!!"

=Description du sujet=

==Randonnée et risques==

Ouvert à tous, la randonnée est un sport et un loisir qui prend de plus en plus d’ampleur de nos jours. Ne nécessitant pas de grands prérequis, des milliers de personnes se lancent en montagne chaque jour, malheureusement parfois sans connaître toutes les mesures de sécurité associées.

En effet, de janvier à juin 2016, en randonnée et en alpinisme, l’Association Nationale pour l’Étude de la Neige et des Avalanches (ANENA) a comptabilisé 21 accidents notables, dont 8 accidents mortels, impliquant 15 décès.

Aujourd’hui, les mesures de sécurités préconisent que chaque groupe de randonneur se doivent de se munir d’un téléphone portable afin d’appeler les secours en cas de problème. Malheureusement, la communication mobile dépendant de la couverture réseau, peu présente en montagne, l’impossibilité de joindre les secours reste un problème.

==Solutions existantes==

La solution la plus répandue, est celle du téléphone à connexion satellite. Ayant une communication vers les satellites, cela permet une couverture réseau beaucoup plus répandue dans les montagnes, partout dans le monde (ou presque). Cependant, les téléphones portables satellitaires coûtent chers, et ne sont pas forcément abordables par la plupart des personnes, surtout celles ne sortant qu’occasionnellement.

[https://fall-alarm.net/ Fall Alarm] est un système de détection de chute sur chantier utilisant les mêmes technologies dont nous avons besoin pour notre projet.

==Quelles zones géographiques ?==

Toutes les zones montagneuses peuvent présenter des zones blanches, démunies de connexion quelconque autre que les connexions satellitaires. Certaines chaînes de montagne comme la Cordillaire des Andes ne présentent aucune connexion possible quelconque.

Dans le cadre de notre projet, nous fonctionnerons essentiellement dans la localisation grenobloise avec l'objectif que notre solution soit applicable partout dans le monde. Une contrainte intervient tout de même étant donnée que la fréquence d'utilisation du LoRa en Europe est de 868MHz, 915MHz en Amérique et 433MHz en Asie.

= Fonctionnalités =

Afin de remplir au mieux ses attentes, le principal objectif de ce dispositif sera premièrement de pouvoir communiquer avec les secours à n’importe quel moment, et surtout n’importe où. De plus, il sera capable de détecter de nombreux cas de détresse de la part de l’usager afin de pouvoir lancer un appel d’urgence sans interaction avec l’usager, au cas où il serait inconscient, ou incapable de lancer un appel manuel.

Grâce aux accéléromètres, le dispositif sera à même de détecter un mouvement brutal du randonneur, ce qui pourrait s’apparenter à une chute. Ils pourront également détecter une position anormale, ou une immobilité prolongée, ce qui déclencherait le dispositif d’urgence automatiquement.

Grâce à des tests réalisés au préalable, le boîtier pourra détecter correctement les chûtes de simples mouvements, afin de ne pas lancer l’appel sans raison valable.

Avant de lancer une alerte automatique, le dispositif émettra un signal auditif et visuel à l’utilisateur quelques secondes auparavant, afin de le prévenir l'émission du signal d’urgence, et de lui proposer de le désactiver sur simple pression d’un bouton, afin d’éviter les communications inutiles.

Également, le randonneur sera à même d'émettre volontairement un appel d’urgence à l’aide du bouton, ce qui permet à tout moment d’appeler de l’aide sans effort. Cela peut permettre également à appeler les secours pour une personne en danger qui ne porterait pas le dispositif.

L’appel au secours se représente par un envoi de coordonnées GPS aux secours, via une communication radio LoRa vers des bornes relais placées au préalables en montagne. Cette communication irait de relai de relai jusqu’au centre de sécurité, d’où le message serait transmis aux secours.

De plus, une application mobile verra le jour afin de connecter tous les utilisateurs du module de sécurité, de les visualiser sur une map, et de partager leurs données. En effet, à chaque incident, l’application mettra à jour la position et de la date de l’accident, afin de permettre aux prochains utilisateurs d’être prévenus. Ils pourraient, s'ils sont à proximité, d'assister la personne en détresse en attendant l'arrivée des secours. Bien évidemment, cette application ne sera accessible uniquement si le smartphone de l'utilisateur est relié à une connexion 4G ou Wi-Fi.

Cette prévention pourrait les sensibiliser aux risques de la montagne, leur permettre d’éviter le secteur mais aussi d’aider les personnes en danger si la distance le permet.

= Exigences =
== Fonctionnelles ==

*Batterie garantie fonctionnelle 1 semaine
*Rechargement possible via le panneau solaire portable
*Dispositif pouvant être allumé et éteint par l'utilisateur
*Alarme s’enclenche automatiquement dès qu'elle est considérée nécessaire, signal sonore
*Utilisateur a la possibilité d’activer/désactiver l’alarme quand il le souhaite
*Lorsque l’alarme est active, l’appareil ne peut s’éteindre
*...

== Non-Fonctionnelles ==

*Résistance : aux chocs, impacts, waterproof (utilisé en permanence en plein air)
*Disponibilité : Appareil de secours -> Doit être au plus possible performant
*Performance : Minimiser les pertes réseaux
*Accessible : Utilisateur pas forcément familier avec des appareils électroniques (facile d’utilisation)
*Fiabilité : Précision du GPS (rayon de 10m), données non-éronnées
*Coût : Le plus faible possible pour vendre le moins cher possible
*Efficacité : Réduire la consommation, utiliser le moins possible les ressources

= Composants =
== LoRaONE ==
Pour le coeur du projet, après avoir cherché et comparés plusieurs modules LoRa, GPS ou encore accéléromètres, nous avons finalement opté pour le projet LoRaONE.

LoRaONE est un projet de SODAQ regroupant plusieurs composants dans une seule et même carte, de taille réduite.

https://www.kickstarter.com/projects/sodaq/loraone-the-lora-iot-development-board

“The one IoT development board to rule them all” --SODAQ

Cette carte regroupe plusieurs capteurs afin de respecter aux mieux nos exigences :

Un émetteur/récepteur LoRa afin de pouvoir communiquer au mieux avec les antennes relai à longue distance

Un module + antenne GPS de bonne précision (< 10m) pour connaître en tout temps notre position, et ainsi faciliter l’arrivée des secours, ainsi que la recherche de l’individu en détresse

Un accéléromètre sur 3 axes afin de pouvoir détecter tout mouvement, vitesse ou rotation dans l’espace, ce qui permet la détection de chutes ou d’arrêt de mouvements

3 LED RGB afin de pouvoir signaler à l’utilisateur un manque de batterie, un signal d’urgence ou plus si nécessaire

Un bouton poussoir pour le signal d’alarme

Un connecteur de charge par panneau solaire, afin de faire durer chaque batterie le plus longtemps possible

Un connecteur micro-USB ainsi que des lignes pour se connecter à une base Arduino si besoin

[[File:LoRaOne.png||400px|Spécifications carte LoRaOne]]

De plus, grâce au starter pack, nous pouvons avoir accès à la base ONEBase qui nous permettrait d’étendre plus loin la facilité d’utilisation du produit :

[[File:LoRaOneBase.png||400px|Spécifications base LoRaOneBase]]

Comme nous pouvons le voir, cette base nous permettra de connecter la batterie ainsi que le panneau solaire qui sont fournis dans le pack.

Nous pourrons également connecter jusqu’à 4 modules supplémentaires.

La batterie fournie aura une capacité de 800 mAh, le panneau solaire fourni pouvant délivrer jusqu’à 500 mW de puissance.

Le total atteint une taille d’environ 10*5 cm, ce qui n’est pas excessif, ce qui le rend aisément portatif sur une jambe ou à la taille.

'''Coût : 115€'''

Ce module pourra également servir d’antenne relai, l'alimentation solaire devrait maintenir le dispositif chargé en permanence. Des tests seront effectués pour savoir si un panneau solaire plus puissant est requis.

== Boîtier ==

Le boîtier sécurisé devant respecter plusieurs exigences, nous pouvons le construire en plastique résistant, ce qui le rendrait léger tout en respectant une rigidité suffisante. Les antennes pourront être placées le long du boîtier, à l’intérieur si la connexion est suffisante, ou à l’extérieur. Dans ce dernier cas les trous réalisés sur le boîtier afin de laisser passer les câbles seront colmatés afin de garantir une étanchéité.

[[File:SchemaBoitier.png||100px|Schéma boitier d'alarme]]

== Balises ==

Afin de remonter les informations transmises par les boitiers, des balises seront mises en places sur la zone à couvrir, leur nombre et leur positions dépendra du terrain (obstacles, dénivelés). On distinguera deux types de balises. Tout d’abord, les balises racines qui permettront une communication GSM afin de faire remonter les données vers le serveur. Viennent ensuite les balises standard qui se contenteront de faire remonter vers leur balise racine associée. L’architecture de liaison des balises est détaillée dans une prochaine partie.

Chaque balise est composée d’une barre de fer pouvant être plantée dans le sol, d’un système de lest afin d’immobiliser la balise, d’un paratonnerre, d’un panneau solaire ainsi que d’un LoraOne et d’une batterie. Les balises racines seront équippée en plus d’un dispositif de communication GSM (téléphone portable, émetteur GSM).

[[File:SchemaBalise.png||150px|Schéma balises d'alarme]]

== Application mobile ==
Une application mobile est téléchargeable par les utilisateurs. Ils peuvent voir les autres utilisateurs présents dans leur zone. Lorsqu’un utilisateur est en position de danger, une notification apparaît si les utilisateurs sont proches de la situation de danger.

Cette application n’est pas directement reliée au dispositif. Elle ne fonctionne qu’avec la connexion du mobile, et est destinée à être un niveau de sécurité supérieur. Un randonneur proche d’une zone de danger pourrait arriver sur place plus rapidement que les secours.

= Communication =

Pour un envoi de position + numéro d’identification (X chiffres) :

*Temps de communication : < 2 s
*Communication régulière, intervalle de 15 minutes

On peut donc au maximum avoir 15 * 60 / 2 = 450 individus pouvant communiquer avec la même antenne relai, donc dans le même cercle d’environ 15 km de diamètre.

On communique donc au minimum 2 secondes sur 15 minutes, donc 1/450 << 1%, le temps de communication est respecté.

En cas de problème, nous pouvons envoyer jusqu’à 9x plus avec la borne sans dépasser le temps de communication autorisé (1%). Donc 1 envoi d’appel d’urgence toutes les 2 minutes environ.

La balise racine peut être directement connectée au serveur, dans ce cas, il n’y a pas de communication GSM nécessaire et pas de Gateway. Si la racine n’est pas directement connectée au serveur, elle devra au minimum garantir une communication GSM (ce qu’elle peut faire, il n’y a pas de Gateway nécessaire) pour remonter l’information vers le serveur, et donc la base de données.

GSM : Si Racine connectée à Serveur -> No GSM + Gateway
Else : GSM + Gateway : LoRa Racine connectée ordi (RaspberryPI) + ordi connecté GSM

= Stabilisation et gestion d’erreurs =

== Choix du routage ==

Notre réseau n'est pas un réseau traditionnel. Les seules communications existantes sont soit une remontée d'information vers la racine soit une innondation d'alerte vers les clients. Pour celà nous avons donc décidé d'utiliser un algorithme de routage simplifié basé uniquement sur un arbre en largeur des balises. Nous rajoutons en option la possibilité de créer plusieurs racines et donc plusieurs arbres dont les racines communiquent par gsm. Nous nous basons sur des papiers de recherches afin de déterminer quel algorithme auto-stabilisant est le plus adapté au système LoRa (Tel que le papier "A self-stabilizing algorithm for constructing breadth-first trees" par Shing-Tsaan Huang, Nian-Shing Chen).

== Stabilisation ==

Afin de gérer la communication de chaque message vers le serveur, nous allons prendre un noeud (balise LoRa) dit “racine” connecté directement au serveur, nous ne nous occuperons pas de la communication au serveur dans cet onglet. Chaque message reçu de la part d’un noeud du système doit être relayé jusqu’à la racine du système afin de communiquer avec les secours (ou serveur simplement).

Pour cela, il faudra assurer que chaque balise LoRa soit connecté au réseau, afin d’avoir au départ un graphe de communication connexe. Par dessus ce graphe, nous allons utiliser un processus silencieux auto-stabilisant qui construira un arbre de parcours en largeur, avec pour racine le noeud “racine” décidé ci-dessus.

Au lancement du système, il faut prévoir un léger temps de stabilisation, qui dépendrait de l’algorithme et de la taille du graphe (nombre de balises). Cependant, après cela, l’algorithme assure un arbre en profondeur minimal qui nous permettrai de communiquer avec la racine le plus rapidement possible, et donc une qualité de service maximale.

== Gestion d’erreurs ==

Dans un réseau comme celui-ci, plusieurs types d’erreurs peuvent se produire :
Délai de communication trop important vers une balise
“Crash” d’une balise de communication
Surpopulation d’une balise ou congestion de messages

Afin de palier au premier type d’incident rencontré, il faut nécessairement qu’à chaque emplacement dans la zone couverte, l’utilisateur soit à même de communiquer avec au minimum 2 balises différentes. Ainsi, dans le cas d’une communication trop longue sur une balise, l’autre aurait de grandes chances de délivrer le message plus rapidement.

Au niveau de la défaillance d’une balise, l’algorithme d’arbre en profondeur nous fournit déjà une solution intégrée grâce à son auto-stabilisation. Dans le cas de déconnexion d’une balise, l’algorithme mettrai à jour automatiquement l’arbre de communication, et n’importe quel message d’alerte émis serait délivré dans un délai raisonnable.

Pour le troisième cas d’erreur, il n’y aurait pas de solution réelle, si ce n’est de limiter le nombre de communications données, en ne prenant plus en compte les “ping” de chaque utilisateur mais seulement les messages d’alertes, ce qui permettrai une bien plus grande gestion de la congestion à un endroit donné. Également, une balise en dessous d’un lien congestionné pourrait communiquer avec ses autres voisins (non-fils dans l’arbre) afin de libérer de l’espace dans le lien avec son père dans l’arbre. Également, le système ne pourra accepter que jusqu’à 1000 utilisateurs par noeud, et également 4000 utilisateurs par cluster (dans le cas d’un réseau avec plusieurs clusters donc plusieurs racines cette limite augmente).

Plusieurs types de paquets circulent sur le réseau de balise:
Les pings, messages envoyés spontanéments à intervalle régulier par les utilisateur contenant l’id ainsi que les deux coordonées gps (27 bits chacun)
Les incidents, identique à un ping mais à priorité haute.
Les alertes, messages brodcastés par le serveur afin d’envoyer un message en chaine de caractères courts et compressés.

=Coûts matériels=

Que ce soit pour le dispositif utilisateur ou la balise (racine ou non), le LoRaOne correspond pour permettre les actions recherchées. Afin de réaliser un prototype pertinent, 6 kits LoRaOne sont requis. Ces kits sont accessibles sur le site de Sodaq au prix de 115€ chacun (prix variable).
Disponible [https://shop.sodaq.com/en/one-eu-rn2483-v2.html ici], voir avant dernier bundle : starter "ONE EU starter" actuellement à 112,10€.

Un [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer buzzer] est à ajouter au dispositif utilisateur afin de lui délivrer un signal sonore.

Un shield GSM est requis pour que la balise racine communique avec l'extérieur. Sodaq en propose un designé pour fonctionner sur leurs produits mais est éctuellement en rupture de stock. Un shield GSM arduino convient tout autant et peut être trouvé sur le site arduino [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna ici].

Aucun boitier ne sera commandé car nous avons fait le choix de les manufacturer nous même au fablab. Le besoin d'étanchéité n'est pas primordial pour notre prototype, bien que nous tenterons de l'assurer.

{|class="récap commande"
|+ Récapitulatif
|-
|
!scope="col" style="width: 320px;"| Produit
!scope="col" style="width: 80px;"| Lien
!scope="col" style="width: 80px;"| Quantité
!scope="col" style="width: 80px;"| Prix Unitaire
|-

!scope="row"| 1
| LoRaOne EU Starter
| [https://shop.sodaq.com/en/one-eu-rn2483-v2.html Achat]
| 6
| 115€
|-

!scope="row"| 2
| Buzzer
| [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer Achat]
| 3
| 5.49€
|-

!scope="row"| 3
| Shield GSM
| [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna Achat]
| 1
| 65€
|-

|}

=Développement=

Nous utiliserons les librairies standards Arduino ainsi que celle de SODAQ/Arduino pour le LoRa.

L'IDE Arduino sera utilisé, plus pratique pour l'utilisation de Git (comparé à Mbed).

= Mise sur le marché =

Ce dispositif a pour but d’être utilisé en montagne, lors de randonnée. Il n’est pas destiné à un usage quotidien, c’est pourquoi nous considérons qu’il est plus judicieux de louer les dispositifs plutôt que de les vendre, même si l’achat n’est pas à omettre de notre stratégie.

Le dispositif peut être commandé en ligne, puis retourné par la poste après usage. Le client louerait le dispositif pour une certaine durée avec un possible nombre supplémentaire de batterie. Les tarifs varient en fonction de la durée et du nombre de batteries louées. Des offres de groupes pourraient être applicables. A long terme, des boutiques pourraient être disséminées dans des grandes villes proches des zones montagneuses, zones à randonnées (Grenoble, Annecy, etc.).

L’application est téléchargeable gratuitement par quiconque, mais utilisable seulement par les clients. Un code d’accès sera envoyé avec le dispositif expirant après la fin de la location.

Il faudra tenir compte de la bande passante du LoRa, variante en fonction des continents.

=Planning prévisonnel=

Sprint 1 : 29/01 --> 09/02 : Création du prototype logiciel #1
*Prise en main du matériel
*Premiers tests de transmissions LoRa
*Création du protocole d'architecture des balises
*Application sur les cartes et tests
*Tests de performances des cartes (durabilité, chargement, batterie)
*Tests de maintenabilité de l'algorithme (déconnexions, latences)

Sprint 2 : 12/02 --> 23/02 : Prototype logiciel #2 et prototype matériel
*Création du programme embarqué (utilisateur)
*Communication avec la racine et le serveur
*Création des maquettes boîtier et balise
*Construction des maquettes
*Finalisation du premier prototype

Sprint 3 : 26/02 --> 09/03 : Fonctionnalités supplémentaires
*Ajout de la communication entre le LoRa et le GSM sur la balise racine
*Création application mobile utilisateur
*Tests sur l'application
*Tests sur la transmission totale depuis l'utilisateur vers le serveur via le GSM
*Finalisation du projet

Sprint 4 : 12/03 --> 16/03 : Fin du projet
*Création de la documentation finale (à partir de la documentation réalisée en continu)
*Pause café
*Temps supplémentaire en cas de problèmes importants
*Préparation de la soutenance

R'Montagne

2018-03-14T09:52:04Z

Hugo.Amodru-Favin: /* Journal */

=Équipe=
{|class="wikitable"
|-
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Rôle
|-
| Hugo Amodru-Favin
| Chef de Projet
|-
| Antoine Delise
| Lead Developer
|-
| Gwenaël Moreau
| Kanban Master
|-

|}

==Tâches==

Répartition générale des tâches
{|class="wikitable"
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Tâche
|-
| Hugo Amodru-Favin
| Application Ionic
|-
| Antoine Delise
| Développement Arduino
|-
| Gwenaël Moreau
| BDD - API
|-

|}

Détail des tâches : [https://waffle.io/delisea/R-Montagne Waffle.io]

=Journal=

{|class="wikitable"
|+
|-
!scope="col" width="120px"| Date
!scope="col" width="350px"| Hugo AMODRU-FAVIN
!scope="col" width="350px"| Antoine DELISE
!scope="col" width="350px"| Gwenaël MOREAU
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 1
|-

|-
| rowspan="1" | Lundi 29/01/18
| style="width: 225px;" |
* Ré-assimilation du sujet
| style="width: 225px;" |
* Ré-assimilation du sujet
| style="width: 225px;" |
* Ré-assimilation du sujet
* Mise en place d'un Kanban
|-
| rowspan="1" | Mardi 30/01/18
| style="width: 225px;" |
* Mise à jour de la page AIR
* Réflexions sur l'implémentation du LoRa
| style="width: 225px;" |
* Mise à jour de la page AIR
* Réflexions sur l'implémentation du LoRa
| style="width: 225px;" |
* Mise en place du calendrier prévisionnel
* Définition et répartition des tâches
|-
| rowspan="1" | Mercredi 31/01/18
| style="width: 225px;" |
* Récupération des cartes Semtech
* Présentation du Hackathon Vinci Energies
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Récupération des cartes Semtech
* Présentation du Hackathon
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Récupération et prise en main des cartes Semtech LoRaMote
* Présentation du Hackathon Vinci Energies
|-
| rowspan="1" | Jeudi 01/02/18
| style="width: 225px;" |
* Choix des fonctionnalités de l'application mobile
| style="width: 225px;" |
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Prise en main des cartes LoRa
|-
| rowspan="1" | Vendredi 02/02/18
| style="width: 225px;" |
* Réflexions sur l'implémentation de l'application
* Démarrage de l'application mobile
* Mises à jour d'Ionic, de Android Studio
| style="width: 225px;" |
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Premières communications fructueuses des cartes Semtech LoRaMote
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 2
|-

|-
| rowspan="1" | Lundi 05/02/18
| style="width: 225px;" |
* Configuration Login et Mot de Passe, Identification base
| style="width: 225px;" |
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Réflexion et création de la base de données
|-
| rowspan="1" | Mardi 06/02/18
| style="width: 225px;" |
* Configuration Login, Mot de passe
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
| style="width: 225px;" |
* Création de l'API REST EN PHP
|-
| rowspan="1" | Mercredi 07/02/18
| style="width: 225px;" |
* Réunion avec Rémi CHOLLET et 3 PEIP D
* Assimilation du fonctionnement de Leaflet
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
| style="width: 225px;" |
* Réunion avec Rémi CHOLLET et 3 PEIP D
* Création de l'API REST en PHP
|-
| rowspan="1" | Jeudi 08/02/18
| style="width: 225px;" |
* Ajout de marqueurs sur Leaflet
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
| style="width: 225px;" |
* Création de l'API REST EN PHP
|-
| rowspan="1" | Vendredi 09/02/18
| style="width: 225px;" |
* Hackathon Vinci Energies
| style="width: 225px;" |
* Hackathon Vinci Energies
| style="width: 225px;" |
* Hackathon Vinci Energies
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 3
|-

|-
| rowspan="1" | Lundi 12/02/18
| style="width: 225px;" |
* Préparation Soutenance
| style="width: 225px;" |
* Mise en place d'un Contiki/Cooja pour faciliter le développement
| style="width: 225px;" |
* Préparation Soutenance
|-
| rowspan="1" | Mardi 13/02/18
| style="width: 225px;" |
* Mise à jour de AIR
* Préparation Soutenance
* Répétition soutenance
| style="width: 225px;" |
* Préparation Soutenance
* Répétition soutenance
* Mise en place d'un Contiki/Cooja pour faciliter le dévelloppement
| style="width: 225px;" |
* Préparation Soutenance
* Répétition soutenance
|-
| rowspan="1" | Mercredi 14/02/18
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
|-
| rowspan="1" | Jeudi 15/02/18
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
|-
| rowspan="1" | Vendredi 16/02/18
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
|-
| rowspan="1" | Interruption de Février
| style="width: 225px;" |
| style="width: 225px;" |
* Développement sur Contiki/Cooja afin de réaliser un routage dynamique
| style="width: 225px;" |
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 4
|-

|-
| rowspan="1" | Lundi 26/02/18
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Travail sur l'affichage des éléments sur la carte utilisateur
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Travail sur Contiki, création d'un protocole de routage
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Corrections de l'API en accord avec l'application mobile
* Modifications sur la base de données
|-
| rowspan="1" | Mardi 27/02/18
| style="width: 225px;" |
* Création de la page de création d'un nouvel utilisateur
* Design de l'application mobile
| style="width: 225px;" |
* Fin du protocole de routage Contiki, tests virtuels de fonctionnement
| style="width: 225px;" |
* Liaison entre l'application mobile et l'API
|-
| rowspan="1" | Mercredi 28/02/18
| style="width: 225px;" |
* Fin de la page de création d'un nouvel utilisateur
* Ajout de l'utilisation des sessions dans l'application
| style="width: 225px;" |
* Panne ordinateur personnel
* Travail sur l'application mobile avec Hugo
| style="width: 225px;" |
* API : Création d'un utilisateur
* API : Récupération des informations nécessaires pour la carte
* API : Ajout de l'utilisation des sessions pour stocker l'utilisateur connecté
|-
| rowspan="1" | Jeudi 01/03/18
| style="width: 225px;" |
* Affichage des informations sur la carte
| style="width: 225px;" |
* Affichage des informations sur la carte
| style="width: 225px;" |
* API : Récupération des informations nécessaires pour la carte
|-
| rowspan="1" | Vendredi 03/03/18
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Réparation d'ordinateur personnel
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Renseignements sur Swagger
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 5
|-

|-
| rowspan="1" | Lundi 05/03/18
| style="width: 225px;" |
* Restructuration de l'application, amélioration visuelle
* Logout fonctionnel
| style="width: 225px;" |
* Finalisation de la carte, et ajout de la gestion des différentes cartes
* Restructuration de l'application
| style="width: 225px;" |
* Création d'une page Swagger
* Corrections de l'API
* Ajout des cartes dans la base de données
* Récupération des éléments liés à la carte dans l'API
|-
| rowspan="1" | Mardi 06/03/18
| style="width: 225px;" |
* Ajout gestion secouriste
* Développement de la page Account, modification utilisateur
| style="width: 225px;" |
* Ajout gestion secouriste
* Création vues côté secouristes
| style="width: 225px;" |
* Fin du Swagger
* API : Modifications utilisateur
* API : Modifications mot de passe
* Base de données : Ajout affectations secouristes-cartes
* API : Récupération des cartes pour un secouriste
|-
| rowspan="1" | Mercredi 07/03/18
| style="width: 225px;" |
* Amélioration et finalisation de la page Account
| style="width: 225px;" |
* Corrections du menu et de la navigation
| style="width: 225px;" |
* Journaux sur air.imag.fr
* Programme de récupération des messages à la racine et inscription des données dans la base de données
|-
| rowspan="1" | Jeudi 08/03/18
| style="width: 225px;" |
* Extraction des dents de sagesse
| style="width: 225px;" |
*
| style="width: 225px;" |
* Création du programme de communication LoRa et récupération des coordonnées GPS depuis la carte SodaqONE
* Tests de temps de synchronisation et précision du GPS
|-
| rowspan="1" | Vendredi 09/03/18
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Design du LogoV2, Embellie CSS de l'application mobile
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
*
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Finition du programme de communication LoRa
* Tests d'envoi de la carte SodaqONE vers la base de données en passant par une racine (carte Arduino LoRa)
|-
| rowspan="1" | Samedi 10/03/18
| style="width: 225px;" |
* Réflexions et implémentations des Usercases concernant la gestion des licences
* Ajout de notifications mobiles
* Ajout d'une page liée à la gestion des Trackers
* Poster Anniversaire
| style="width: 225px;" |
* Réflexions et implémentations des Usercases concernant la gestion des licences
* Ajout de notifications mobiles
| style="width: 225px;" |
* Tests du programme de communication avec les LoRas
|-
| rowspan="1" | Dimanche 11/03/18
| style="width: 225px;" |
* Implémentations des usercases liées à la gestion des licences côté application
| style="width: 225px;" |
* Implémentations des usercases liées à la gestion des licences côté api
| style="width: 225px;" |
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 6
|-

|-
| rowspan="1" | Lundi 12/03/18
| style="width: 225px;" |
* Ajouts de fonctionnalités dans l'application
| style="width: 225px;" |
* Correctifs programme de communication
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Correctifs programme de communication
|-
| rowspan="1" | Mardi 13/03/18
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Finalisation des fonctionnalités de l'application
* Correctifs des bugs
* Test Réel à la Bastille
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Finalisation des fonctionnalités de l'application
* Correctifs des bugs
* Page de création de Map Admin
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Préparation des capteurs pour le test réel
* Test Réel à la Bastille
|-
| rowspan="1" | Mercredi 14/03/18
| style="width: 225px;" |
* Préparation de la soutenance
* Finalisation du Poster
* Test Réel aux Taillées
| style="width: 225px;" |
* Préparation de la soutenance
* Préparation de la démonstration
* Dernier correctifs de l'application
| style="width: 225px;" |
* Préparation de la soutenance
* Finalisation du Poster
* Test Réel aux Taillées
|-
| rowspan="1" | Jeudi 15/03/18
| style="width: 225px;" |
* Soutenance de Projet
| style="width: 225px;" |
* Soutenance de Projet
| style="width: 225px;" |
* Soutenance de Projet
|}

=Collaboration avec le DUT RT et les PEIPs D=
L'objectif de cette collaboration est de familiariser des étudiants en PEIP D avec des projets qu'ils seront amenés à développer dans les prochaines années. Nous avons rencontré Rémi CHOLLET et 3 étudiants Mercredi 7 Février, en voici un résumé écrit par Mr CHOLLET définissant les contours de cette collaboration.

"Un rapide résumé de la rencontre que nous avons eu ce matin avec le projet R’Montagne.

Présents :
- RCIM5 Gwenael Moreau, Hugo Amodru-Favin
- PEIP-D : Yoann Goma-Missamou, Vincent Cadoux, Philippe Charrat
- IUT : Rémy Chollet, tuteur pédagogique des PEIP-D
Excusés : Didier Donsez, blessé (aie ! courage …), Antoine Delise en cours de marketing

Contexte :
Les PEIP-D participent aux projets RICM5 en prenant une tâche « annexe » (hors chemin critique) en charge. L’objectif est une expérience d’immersion + notation liée au PEIP.

Déroulé :
Les étudiant RCIM5 ont présenté le projet dans son principe et état d’avancement. Les échanges se sont portés sur l’idée de mener une étude (simulation et mesure) sur la consommation des balises par les PEIP-D avec pour objectif de dimensionner la réserve d’énergie.

Ceci implique :
- coté RCIM5 : mise à disposition d’une carte prototype.

- cote PEIP-D : inventaire des paramètres à prendre en compte :
* consommation carte (GPS + puce LoRa) = > veille + temps d’activation (recherche à faire sur le temps de synchronisation du GPS)
* puissance d’émission à calibrer en fonction de la couverture voulue et débit (voir Spread Factor ?)
* temps d’émission-réception (émission jusqu’à acquittement)

- cote PEIP-D : penser la manip pour valider ce modèle
* mesure moyenne du courant
* configuration effective du réseau
* réserver le matériel (voir Jean-Yves Frau au département R&T ?)

- cote PEIP-D : paramètrer les simulations et mesures en fonction de puissance d’émission (ou autre élément pouvant apparaitre comme pertinent)

D’une manière générale, pour les PEID-D :
- penser bibliographie (pour commencer : https://fr.wikipedia.org/wiki/LoRaWAN et aussi https://fr.wikipedia.org/wiki/Format_des_piles_et_accumulateurs_électriques :-) )
- planifier
- communiquer : reporting !!!"

=Description du sujet=

==Randonnée et risques==

Ouvert à tous, la randonnée est un sport et un loisir qui prend de plus en plus d’ampleur de nos jours. Ne nécessitant pas de grands prérequis, des milliers de personnes se lancent en montagne chaque jour, malheureusement parfois sans connaître toutes les mesures de sécurité associées.

En effet, de janvier à juin 2016, en randonnée et en alpinisme, l’Association Nationale pour l’Étude de la Neige et des Avalanches (ANENA) a comptabilisé 21 accidents notables, dont 8 accidents mortels, impliquant 15 décès.

Aujourd’hui, les mesures de sécurités préconisent que chaque groupe de randonneur se doivent de se munir d’un téléphone portable afin d’appeler les secours en cas de problème. Malheureusement, la communication mobile dépendant de la couverture réseau, peu présente en montagne, l’impossibilité de joindre les secours reste un problème.

==Solutions existantes==

La solution la plus répandue, est celle du téléphone à connexion satellite. Ayant une communication vers les satellites, cela permet une couverture réseau beaucoup plus répandue dans les montagnes, partout dans le monde (ou presque). Cependant, les téléphones portables satellitaires coûtent chers, et ne sont pas forcément abordables par la plupart des personnes, surtout celles ne sortant qu’occasionnellement.

[https://fall-alarm.net/ Fall Alarm] est un système de détection de chute sur chantier utilisant les mêmes technologies dont nous avons besoin pour notre projet.

==Quelles zones géographiques ?==

Toutes les zones montagneuses peuvent présenter des zones blanches, démunies de connexion quelconque autre que les connexions satellitaires. Certaines chaînes de montagne comme la Cordillaire des Andes ne présentent aucune connexion possible quelconque.

Dans le cadre de notre projet, nous fonctionnerons essentiellement dans la localisation grenobloise avec l'objectif que notre solution soit applicable partout dans le monde. Une contrainte intervient tout de même étant donnée que la fréquence d'utilisation du LoRa en Europe est de 868MHz, 915MHz en Amérique et 433MHz en Asie.

= Fonctionnalités =

Afin de remplir au mieux ses attentes, le principal objectif de ce dispositif sera premièrement de pouvoir communiquer avec les secours à n’importe quel moment, et surtout n’importe où. De plus, il sera capable de détecter de nombreux cas de détresse de la part de l’usager afin de pouvoir lancer un appel d’urgence sans interaction avec l’usager, au cas où il serait inconscient, ou incapable de lancer un appel manuel.

Grâce aux accéléromètres, le dispositif sera à même de détecter un mouvement brutal du randonneur, ce qui pourrait s’apparenter à une chute. Ils pourront également détecter une position anormale, ou une immobilité prolongée, ce qui déclencherait le dispositif d’urgence automatiquement.

Grâce à des tests réalisés au préalable, le boîtier pourra détecter correctement les chûtes de simples mouvements, afin de ne pas lancer l’appel sans raison valable.

Avant de lancer une alerte automatique, le dispositif émettra un signal auditif et visuel à l’utilisateur quelques secondes auparavant, afin de le prévenir l'émission du signal d’urgence, et de lui proposer de le désactiver sur simple pression d’un bouton, afin d’éviter les communications inutiles.

Également, le randonneur sera à même d'émettre volontairement un appel d’urgence à l’aide du bouton, ce qui permet à tout moment d’appeler de l’aide sans effort. Cela peut permettre également à appeler les secours pour une personne en danger qui ne porterait pas le dispositif.

L’appel au secours se représente par un envoi de coordonnées GPS aux secours, via une communication radio LoRa vers des bornes relais placées au préalables en montagne. Cette communication irait de relai de relai jusqu’au centre de sécurité, d’où le message serait transmis aux secours.

De plus, une application mobile verra le jour afin de connecter tous les utilisateurs du module de sécurité, de les visualiser sur une map, et de partager leurs données. En effet, à chaque incident, l’application mettra à jour la position et de la date de l’accident, afin de permettre aux prochains utilisateurs d’être prévenus. Ils pourraient, s'ils sont à proximité, d'assister la personne en détresse en attendant l'arrivée des secours. Bien évidemment, cette application ne sera accessible uniquement si le smartphone de l'utilisateur est relié à une connexion 4G ou Wi-Fi.

Cette prévention pourrait les sensibiliser aux risques de la montagne, leur permettre d’éviter le secteur mais aussi d’aider les personnes en danger si la distance le permet.

= Exigences =
== Fonctionnelles ==

*Batterie garantie fonctionnelle 1 semaine
*Rechargement possible via le panneau solaire portable
*Dispositif pouvant être allumé et éteint par l'utilisateur
*Alarme s’enclenche automatiquement dès qu'elle est considérée nécessaire, signal sonore
*Utilisateur a la possibilité d’activer/désactiver l’alarme quand il le souhaite
*Lorsque l’alarme est active, l’appareil ne peut s’éteindre
*...

== Non-Fonctionnelles ==

*Résistance : aux chocs, impacts, waterproof (utilisé en permanence en plein air)
*Disponibilité : Appareil de secours -> Doit être au plus possible performant
*Performance : Minimiser les pertes réseaux
*Accessible : Utilisateur pas forcément familier avec des appareils électroniques (facile d’utilisation)
*Fiabilité : Précision du GPS (rayon de 10m), données non-éronnées
*Coût : Le plus faible possible pour vendre le moins cher possible
*Efficacité : Réduire la consommation, utiliser le moins possible les ressources

= Composants =
== LoRaONE ==
Pour le coeur du projet, après avoir cherché et comparés plusieurs modules LoRa, GPS ou encore accéléromètres, nous avons finalement opté pour le projet LoRaONE.

LoRaONE est un projet de SODAQ regroupant plusieurs composants dans une seule et même carte, de taille réduite.

https://www.kickstarter.com/projects/sodaq/loraone-the-lora-iot-development-board

“The one IoT development board to rule them all” --SODAQ

Cette carte regroupe plusieurs capteurs afin de respecter aux mieux nos exigences :

Un émetteur/récepteur LoRa afin de pouvoir communiquer au mieux avec les antennes relai à longue distance

Un module + antenne GPS de bonne précision (< 10m) pour connaître en tout temps notre position, et ainsi faciliter l’arrivée des secours, ainsi que la recherche de l’individu en détresse

Un accéléromètre sur 3 axes afin de pouvoir détecter tout mouvement, vitesse ou rotation dans l’espace, ce qui permet la détection de chutes ou d’arrêt de mouvements

3 LED RGB afin de pouvoir signaler à l’utilisateur un manque de batterie, un signal d’urgence ou plus si nécessaire

Un bouton poussoir pour le signal d’alarme

Un connecteur de charge par panneau solaire, afin de faire durer chaque batterie le plus longtemps possible

Un connecteur micro-USB ainsi que des lignes pour se connecter à une base Arduino si besoin

[[File:LoRaOne.png||400px|Spécifications carte LoRaOne]]

De plus, grâce au starter pack, nous pouvons avoir accès à la base ONEBase qui nous permettrait d’étendre plus loin la facilité d’utilisation du produit :

[[File:LoRaOneBase.png||400px|Spécifications base LoRaOneBase]]

Comme nous pouvons le voir, cette base nous permettra de connecter la batterie ainsi que le panneau solaire qui sont fournis dans le pack.

Nous pourrons également connecter jusqu’à 4 modules supplémentaires.

La batterie fournie aura une capacité de 800 mAh, le panneau solaire fourni pouvant délivrer jusqu’à 500 mW de puissance.

Le total atteint une taille d’environ 10*5 cm, ce qui n’est pas excessif, ce qui le rend aisément portatif sur une jambe ou à la taille.

'''Coût : 115€'''

Ce module pourra également servir d’antenne relai, l'alimentation solaire devrait maintenir le dispositif chargé en permanence. Des tests seront effectués pour savoir si un panneau solaire plus puissant est requis.

== Boîtier ==

Le boîtier sécurisé devant respecter plusieurs exigences, nous pouvons le construire en plastique résistant, ce qui le rendrait léger tout en respectant une rigidité suffisante. Les antennes pourront être placées le long du boîtier, à l’intérieur si la connexion est suffisante, ou à l’extérieur. Dans ce dernier cas les trous réalisés sur le boîtier afin de laisser passer les câbles seront colmatés afin de garantir une étanchéité.

[[File:SchemaBoitier.png||100px|Schéma boitier d'alarme]]

== Balises ==

Afin de remonter les informations transmises par les boitiers, des balises seront mises en places sur la zone à couvrir, leur nombre et leur positions dépendra du terrain (obstacles, dénivelés). On distinguera deux types de balises. Tout d’abord, les balises racines qui permettront une communication GSM afin de faire remonter les données vers le serveur. Viennent ensuite les balises standard qui se contenteront de faire remonter vers leur balise racine associée. L’architecture de liaison des balises est détaillée dans une prochaine partie.

Chaque balise est composée d’une barre de fer pouvant être plantée dans le sol, d’un système de lest afin d’immobiliser la balise, d’un paratonnerre, d’un panneau solaire ainsi que d’un LoraOne et d’une batterie. Les balises racines seront équippée en plus d’un dispositif de communication GSM (téléphone portable, émetteur GSM).

[[File:SchemaBalise.png||150px|Schéma balises d'alarme]]

== Application mobile ==
Une application mobile est téléchargeable par les utilisateurs. Ils peuvent voir les autres utilisateurs présents dans leur zone. Lorsqu’un utilisateur est en position de danger, une notification apparaît si les utilisateurs sont proches de la situation de danger.

Cette application n’est pas directement reliée au dispositif. Elle ne fonctionne qu’avec la connexion du mobile, et est destinée à être un niveau de sécurité supérieur. Un randonneur proche d’une zone de danger pourrait arriver sur place plus rapidement que les secours.

= Communication =

Pour un envoi de position + numéro d’identification (X chiffres) :

*Temps de communication : < 2 s
*Communication régulière, intervalle de 15 minutes

On peut donc au maximum avoir 15 * 60 / 2 = 450 individus pouvant communiquer avec la même antenne relai, donc dans le même cercle d’environ 15 km de diamètre.

On communique donc au minimum 2 secondes sur 15 minutes, donc 1/450 << 1%, le temps de communication est respecté.

En cas de problème, nous pouvons envoyer jusqu’à 9x plus avec la borne sans dépasser le temps de communication autorisé (1%). Donc 1 envoi d’appel d’urgence toutes les 2 minutes environ.

La balise racine peut être directement connectée au serveur, dans ce cas, il n’y a pas de communication GSM nécessaire et pas de Gateway. Si la racine n’est pas directement connectée au serveur, elle devra au minimum garantir une communication GSM (ce qu’elle peut faire, il n’y a pas de Gateway nécessaire) pour remonter l’information vers le serveur, et donc la base de données.

GSM : Si Racine connectée à Serveur -> No GSM + Gateway
Else : GSM + Gateway : LoRa Racine connectée ordi (RaspberryPI) + ordi connecté GSM

= Stabilisation et gestion d’erreurs =

== Choix du routage ==

Notre réseau n'est pas un réseau traditionnel. Les seules communications existantes sont soit une remontée d'information vers la racine soit une innondation d'alerte vers les clients. Pour celà nous avons donc décidé d'utiliser un algorithme de routage simplifié basé uniquement sur un arbre en largeur des balises. Nous rajoutons en option la possibilité de créer plusieurs racines et donc plusieurs arbres dont les racines communiquent par gsm. Nous nous basons sur des papiers de recherches afin de déterminer quel algorithme auto-stabilisant est le plus adapté au système LoRa (Tel que le papier "A self-stabilizing algorithm for constructing breadth-first trees" par Shing-Tsaan Huang, Nian-Shing Chen).

== Stabilisation ==

Afin de gérer la communication de chaque message vers le serveur, nous allons prendre un noeud (balise LoRa) dit “racine” connecté directement au serveur, nous ne nous occuperons pas de la communication au serveur dans cet onglet. Chaque message reçu de la part d’un noeud du système doit être relayé jusqu’à la racine du système afin de communiquer avec les secours (ou serveur simplement).

Pour cela, il faudra assurer que chaque balise LoRa soit connecté au réseau, afin d’avoir au départ un graphe de communication connexe. Par dessus ce graphe, nous allons utiliser un processus silencieux auto-stabilisant qui construira un arbre de parcours en largeur, avec pour racine le noeud “racine” décidé ci-dessus.

Au lancement du système, il faut prévoir un léger temps de stabilisation, qui dépendrait de l’algorithme et de la taille du graphe (nombre de balises). Cependant, après cela, l’algorithme assure un arbre en profondeur minimal qui nous permettrai de communiquer avec la racine le plus rapidement possible, et donc une qualité de service maximale.

== Gestion d’erreurs ==

Dans un réseau comme celui-ci, plusieurs types d’erreurs peuvent se produire :
Délai de communication trop important vers une balise
“Crash” d’une balise de communication
Surpopulation d’une balise ou congestion de messages

Afin de palier au premier type d’incident rencontré, il faut nécessairement qu’à chaque emplacement dans la zone couverte, l’utilisateur soit à même de communiquer avec au minimum 2 balises différentes. Ainsi, dans le cas d’une communication trop longue sur une balise, l’autre aurait de grandes chances de délivrer le message plus rapidement.

Au niveau de la défaillance d’une balise, l’algorithme d’arbre en profondeur nous fournit déjà une solution intégrée grâce à son auto-stabilisation. Dans le cas de déconnexion d’une balise, l’algorithme mettrai à jour automatiquement l’arbre de communication, et n’importe quel message d’alerte émis serait délivré dans un délai raisonnable.

Pour le troisième cas d’erreur, il n’y aurait pas de solution réelle, si ce n’est de limiter le nombre de communications données, en ne prenant plus en compte les “ping” de chaque utilisateur mais seulement les messages d’alertes, ce qui permettrai une bien plus grande gestion de la congestion à un endroit donné. Également, une balise en dessous d’un lien congestionné pourrait communiquer avec ses autres voisins (non-fils dans l’arbre) afin de libérer de l’espace dans le lien avec son père dans l’arbre. Également, le système ne pourra accepter que jusqu’à 1000 utilisateurs par noeud, et également 4000 utilisateurs par cluster (dans le cas d’un réseau avec plusieurs clusters donc plusieurs racines cette limite augmente).

Plusieurs types de paquets circulent sur le réseau de balise:
Les pings, messages envoyés spontanéments à intervalle régulier par les utilisateur contenant l’id ainsi que les deux coordonées gps (27 bits chacun)
Les incidents, identique à un ping mais à priorité haute.
Les alertes, messages brodcastés par le serveur afin d’envoyer un message en chaine de caractères courts et compressés.

=Coûts matériels=

Que ce soit pour le dispositif utilisateur ou la balise (racine ou non), le LoRaOne correspond pour permettre les actions recherchées. Afin de réaliser un prototype pertinent, 6 kits LoRaOne sont requis. Ces kits sont accessibles sur le site de Sodaq au prix de 115€ chacun (prix variable).
Disponible [https://shop.sodaq.com/en/one-eu-rn2483-v2.html ici], voir avant dernier bundle : starter "ONE EU starter" actuellement à 112,10€.

Un [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer buzzer] est à ajouter au dispositif utilisateur afin de lui délivrer un signal sonore.

Un shield GSM est requis pour que la balise racine communique avec l'extérieur. Sodaq en propose un designé pour fonctionner sur leurs produits mais est éctuellement en rupture de stock. Un shield GSM arduino convient tout autant et peut être trouvé sur le site arduino [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna ici].

Aucun boitier ne sera commandé car nous avons fait le choix de les manufacturer nous même au fablab. Le besoin d'étanchéité n'est pas primordial pour notre prototype, bien que nous tenterons de l'assurer.

{|class="récap commande"
|+ Récapitulatif
|-
|
!scope="col" style="width: 320px;"| Produit
!scope="col" style="width: 80px;"| Lien
!scope="col" style="width: 80px;"| Quantité
!scope="col" style="width: 80px;"| Prix Unitaire
|-

!scope="row"| 1
| LoRaOne EU Starter
| [https://shop.sodaq.com/en/one-eu-rn2483-v2.html Achat]
| 6
| 115€
|-

!scope="row"| 2
| Buzzer
| [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer Achat]
| 3
| 5.49€
|-

!scope="row"| 3
| Shield GSM
| [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna Achat]
| 1
| 65€
|-

|}

=Développement=

Nous utiliserons les librairies standards Arduino ainsi que celle de SODAQ/Arduino pour le LoRa.

L'IDE Arduino sera utilisé, plus pratique pour l'utilisation de Git (comparé à Mbed).

= Mise sur le marché =

Ce dispositif a pour but d’être utilisé en montagne, lors de randonnée. Il n’est pas destiné à un usage quotidien, c’est pourquoi nous considérons qu’il est plus judicieux de louer les dispositifs plutôt que de les vendre, même si l’achat n’est pas à omettre de notre stratégie.

Le dispositif peut être commandé en ligne, puis retourné par la poste après usage. Le client louerait le dispositif pour une certaine durée avec un possible nombre supplémentaire de batterie. Les tarifs varient en fonction de la durée et du nombre de batteries louées. Des offres de groupes pourraient être applicables. A long terme, des boutiques pourraient être disséminées dans des grandes villes proches des zones montagneuses, zones à randonnées (Grenoble, Annecy, etc.).

L’application est téléchargeable gratuitement par quiconque, mais utilisable seulement par les clients. Un code d’accès sera envoyé avec le dispositif expirant après la fin de la location.

Il faudra tenir compte de la bande passante du LoRa, variante en fonction des continents.

=Planning prévisonnel=

Sprint 1 : 29/01 --> 09/02 : Création du prototype logiciel #1
*Prise en main du matériel
*Premiers tests de transmissions LoRa
*Création du protocole d'architecture des balises
*Application sur les cartes et tests
*Tests de performances des cartes (durabilité, chargement, batterie)
*Tests de maintenabilité de l'algorithme (déconnexions, latences)

Sprint 2 : 12/02 --> 23/02 : Prototype logiciel #2 et prototype matériel
*Création du programme embarqué (utilisateur)
*Communication avec la racine et le serveur
*Création des maquettes boîtier et balise
*Construction des maquettes
*Finalisation du premier prototype

Sprint 3 : 26/02 --> 09/03 : Fonctionnalités supplémentaires
*Ajout de la communication entre le LoRa et le GSM sur la balise racine
*Création application mobile utilisateur
*Tests sur l'application
*Tests sur la transmission totale depuis l'utilisateur vers le serveur via le GSM
*Finalisation du projet

Sprint 4 : 12/03 --> 16/03 : Fin du projet
*Création de la documentation finale (à partir de la documentation réalisée en continu)
*Pause café
*Temps supplémentaire en cas de problèmes importants
*Préparation de la soutenance

R'Montagne

2018-03-14T09:49:35Z

Hugo.Amodru-Favin: /* Journal */

=Équipe=
{|class="wikitable"
|-
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Rôle
|-
| Hugo Amodru-Favin
| Chef de Projet
|-
| Antoine Delise
| Lead Developer
|-
| Gwenaël Moreau
| Kanban Master
|-

|}

==Tâches==

Répartition générale des tâches
{|class="wikitable"
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Tâche
|-
| Hugo Amodru-Favin
| Application Ionic
|-
| Antoine Delise
| Développement Arduino
|-
| Gwenaël Moreau
| BDD - API
|-

|}

Détail des tâches : [https://waffle.io/delisea/R-Montagne Waffle.io]

=Journal=

{|class="wikitable"
|+
|-
!scope="col" width="120px"| Date
!scope="col" width="350px"| Hugo AMODRU-FAVIN
!scope="col" width="350px"| Antoine DELISE
!scope="col" width="350px"| Gwenaël MOREAU
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 1
|-

|-
| rowspan="1" | Lundi 29/01/18
| style="width: 225px;" |
* Ré-assimilation du sujet
| style="width: 225px;" |
* Ré-assimilation du sujet
| style="width: 225px;" |
* Ré-assimilation du sujet
* Mise en place d'un Kanban
|-
| rowspan="1" | Mardi 30/01/18
| style="width: 225px;" |
* Mise à jour de la page AIR
* Réflexions sur l'implémentation du LoRa
| style="width: 225px;" |
* Mise à jour de la page AIR
* Réflexions sur l'implémentation du LoRa
| style="width: 225px;" |
* Mise en place du calendrier prévisionnel
* Définition et répartition des tâches
|-
| rowspan="1" | Mercredi 31/01/18
| style="width: 225px;" |
* Récupération des cartes Semtech
* Présentation du Hackathon Vinci Energies
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Récupération des cartes Semtech
* Présentation du Hackathon
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Récupération et prise en main des cartes Semtech LoRaMote
* Présentation du Hackathon Vinci Energies
|-
| rowspan="1" | Jeudi 01/02/18
| style="width: 225px;" |
* Choix des fonctionnalités de l'application mobile
| style="width: 225px;" |
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Prise en main des cartes LoRa
|-
| rowspan="1" | Vendredi 02/02/18
| style="width: 225px;" |
* Réflexions sur l'implémentation de l'application
* Démarrage de l'application mobile
* Mises à jour d'Ionic, de Android Studio
| style="width: 225px;" |
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Premières communications fructueuses des cartes Semtech LoRaMote
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 2
|-

|-
| rowspan="1" | Lundi 05/02/18
| style="width: 225px;" |
* Configuration Login et Mot de Passe, Identification base
| style="width: 225px;" |
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Réflexion et création de la base de données
|-
| rowspan="1" | Mardi 06/02/18
| style="width: 225px;" |
* Configuration Login, Mot de passe
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
| style="width: 225px;" |
* Création de l'API REST EN PHP
|-
| rowspan="1" | Mercredi 07/02/18
| style="width: 225px;" |
* Réunion avec Rémi CHOLLET et 3 PEIP D
* Assimilation du fonctionnement de Leaflet
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
| style="width: 225px;" |
* Réunion avec Rémi CHOLLET et 3 PEIP D
* Création de l'API REST en PHP
|-
| rowspan="1" | Jeudi 08/02/18
| style="width: 225px;" |
* Ajout de marqueurs sur Leaflet
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
| style="width: 225px;" |
* Création de l'API REST EN PHP
|-
| rowspan="1" | Vendredi 09/02/18
| style="width: 225px;" |
* Hackathon Vinci Energies
| style="width: 225px;" |
* Hackathon Vinci Energies
| style="width: 225px;" |
* Hackathon Vinci Energies
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 3
|-

|-
| rowspan="1" | Lundi 12/02/18
| style="width: 225px;" |
* Préparation Soutenance
| style="width: 225px;" |
* Mise en place d'un Contiki/Cooja pour faciliter le développement
| style="width: 225px;" |
* Préparation Soutenance
|-
| rowspan="1" | Mardi 13/02/18
| style="width: 225px;" |
* Mise à jour de AIR
* Préparation Soutenance
* Répétition soutenance
| style="width: 225px;" |
* Préparation Soutenance
* Répétition soutenance
* Mise en place d'un Contiki/Cooja pour faciliter le dévelloppement
| style="width: 225px;" |
* Préparation Soutenance
* Répétition soutenance
|-
| rowspan="1" | Mercredi 14/02/18
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
|-
| rowspan="1" | Jeudi 15/02/18
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
|-
| rowspan="1" | Vendredi 16/02/18
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 4
|-

|-
| rowspan="1" | Lundi 26/02/18
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Travail sur l'affichage des éléments sur la carte utilisateur
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Travail sur Contiki, création d'un protocole de routage
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Corrections de l'API en accord avec l'application mobile
* Modifications sur la base de données
|-
| rowspan="1" | Mardi 27/02/18
| style="width: 225px;" |
* Création de la page de création d'un nouvel utilisateur
* Design de l'application mobile
| style="width: 225px;" |
* Fin du protocole de routage Contiki, tests virtuels de fonctionnement
| style="width: 225px;" |
* Liaison entre l'application mobile et l'API
|-
| rowspan="1" | Mercredi 28/02/18
| style="width: 225px;" |
* Fin de la page de création d'un nouvel utilisateur
* Ajout de l'utilisation des sessions dans l'application
| style="width: 225px;" |
* Panne ordinateur personnel
* Travail sur l'application mobile avec Hugo
| style="width: 225px;" |
* API : Création d'un utilisateur
* API : Récupération des informations nécessaires pour la carte
* API : Ajout de l'utilisation des sessions pour stocker l'utilisateur connecté
|-
| rowspan="1" | Jeudi 01/03/18
| style="width: 225px;" |
* Affichage des informations sur la carte
| style="width: 225px;" |
* Affichage des informations sur la carte
| style="width: 225px;" |
* API : Récupération des informations nécessaires pour la carte
|-
| rowspan="1" | Vendredi 03/03/18
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Réparation d'ordinateur personnel
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Renseignements sur Swagger
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 5
|-

|-
| rowspan="1" | Lundi 05/03/18
| style="width: 225px;" |
* Restructuration de l'application, amélioration visuelle
* Logout fonctionnel
| style="width: 225px;" |
* Finalisation de la carte, et ajout de la gestion des différentes cartes
* Restructuration de l'application
| style="width: 225px;" |
* Création d'une page Swagger
* Corrections de l'API
* Ajout des cartes dans la base de données
* Récupération des éléments liés à la carte dans l'API
|-
| rowspan="1" | Mardi 06/03/18
| style="width: 225px;" |
* Ajout gestion secouriste
* Développement de la page Account, modification utilisateur
| style="width: 225px;" |
* Ajout gestion secouriste
* Création vues côté secouristes
| style="width: 225px;" |
* Fin du Swagger
* API : Modifications utilisateur
* API : Modifications mot de passe
* Base de données : Ajout affectations secouristes-cartes
* API : Récupération des cartes pour un secouriste
|-
| rowspan="1" | Mercredi 07/03/18
| style="width: 225px;" |
* Amélioration et finalisation de la page Account
| style="width: 225px;" |
* Corrections du menu et de la navigation
| style="width: 225px;" |
* Journaux sur air.imag.fr
* Programme de récupération des messages à la racine et inscription des données dans la base de données
|-
| rowspan="1" | Jeudi 08/03/18
| style="width: 225px;" |
* Extraction des dents de sagesse
| style="width: 225px;" |
*
| style="width: 225px;" |
* Création du programme de communication LoRa et récupération des coordonnées GPS depuis la carte SodaqONE
* Tests de temps de synchronisation et précision du GPS
|-
| rowspan="1" | Vendredi 09/03/18
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Design du LogoV2, Embellie CSS de l'application mobile
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
*
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Finition du programme de communication LoRa
* Tests d'envoi de la carte SodaqONE vers la base de données en passant par une racine (carte Arduino LoRa)
|-
| rowspan="1" | Samedi 10/03/18
| style="width: 225px;" |
* Réflexions et implémentations des Usercases concernant la gestion des licences
* Ajout de notifications mobiles
* Ajout d'une page liée à la gestion des Trackers
* Poster Anniversaire
| style="width: 225px;" |
* Réflexions et implémentations des Usercases concernant la gestion des licences
* Ajout de notifications mobiles
| style="width: 225px;" |
* Tests du programme de communication avec les LoRas
|-
| rowspan="1" | Dimanche 11/03/18
| style="width: 225px;" |
* Implémentations des usercases liées à la gestion des licences côté application
| style="width: 225px;" |
* Implémentations des usercases liées à la gestion des licences côté api
| style="width: 225px;" |
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 6
|-

|-
| rowspan="1" | Lundi 12/03/18
| style="width: 225px;" |
* Ajouts de fonctionnalités dans l'application
| style="width: 225px;" |
* Correctifs programme de communication
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Correctifs programme de communication
|-
| rowspan="1" | Mardi 13/03/18
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Finalisation des fonctionnalités de l'application
* Correctifs des bugs
* Test Réel à la Bastille
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Finalisation des fonctionnalités de l'application
* Correctifs des bugs
* Page de création de Map Admin
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Préparation des capteurs pour le test réel
* Test Réel à la Bastille
|-
| rowspan="1" | Mercredi 14/03/18
| style="width: 225px;" |
* Préparation de la soutenance
* Finalisation du Poster
* Test Réel aux Taillées
| style="width: 225px;" |
* Préparation de la soutenance
* Préparation de la démonstration
* Dernier correctifs de l'application
| style="width: 225px;" |
* Préparation de la soutenance
* Finalisation du Poster
* Test Réel aux Taillées
|-
| rowspan="1" | Jeudi 15/03/18
| style="width: 225px;" |
* Soutenance de Projet
| style="width: 225px;" |
* Soutenance de Projet
| style="width: 225px;" |
* Soutenance de Projet
|}

=Collaboration avec le DUT RT et les PEIPs D=
L'objectif de cette collaboration est de familiariser des étudiants en PEIP D avec des projets qu'ils seront amenés à développer dans les prochaines années. Nous avons rencontré Rémi CHOLLET et 3 étudiants Mercredi 7 Février, en voici un résumé écrit par Mr CHOLLET définissant les contours de cette collaboration.

"Un rapide résumé de la rencontre que nous avons eu ce matin avec le projet R’Montagne.

Présents :
- RCIM5 Gwenael Moreau, Hugo Amodru-Favin
- PEIP-D : Yoann Goma-Missamou, Vincent Cadoux, Philippe Charrat
- IUT : Rémy Chollet, tuteur pédagogique des PEIP-D
Excusés : Didier Donsez, blessé (aie ! courage …), Antoine Delise en cours de marketing

Contexte :
Les PEIP-D participent aux projets RICM5 en prenant une tâche « annexe » (hors chemin critique) en charge. L’objectif est une expérience d’immersion + notation liée au PEIP.

Déroulé :
Les étudiant RCIM5 ont présenté le projet dans son principe et état d’avancement. Les échanges se sont portés sur l’idée de mener une étude (simulation et mesure) sur la consommation des balises par les PEIP-D avec pour objectif de dimensionner la réserve d’énergie.

Ceci implique :
- coté RCIM5 : mise à disposition d’une carte prototype.

- cote PEIP-D : inventaire des paramètres à prendre en compte :
* consommation carte (GPS + puce LoRa) = > veille + temps d’activation (recherche à faire sur le temps de synchronisation du GPS)
* puissance d’émission à calibrer en fonction de la couverture voulue et débit (voir Spread Factor ?)
* temps d’émission-réception (émission jusqu’à acquittement)

- cote PEIP-D : penser la manip pour valider ce modèle
* mesure moyenne du courant
* configuration effective du réseau
* réserver le matériel (voir Jean-Yves Frau au département R&T ?)

- cote PEIP-D : paramètrer les simulations et mesures en fonction de puissance d’émission (ou autre élément pouvant apparaitre comme pertinent)

D’une manière générale, pour les PEID-D :
- penser bibliographie (pour commencer : https://fr.wikipedia.org/wiki/LoRaWAN et aussi https://fr.wikipedia.org/wiki/Format_des_piles_et_accumulateurs_électriques :-) )
- planifier
- communiquer : reporting !!!"

=Description du sujet=

==Randonnée et risques==

Ouvert à tous, la randonnée est un sport et un loisir qui prend de plus en plus d’ampleur de nos jours. Ne nécessitant pas de grands prérequis, des milliers de personnes se lancent en montagne chaque jour, malheureusement parfois sans connaître toutes les mesures de sécurité associées.

En effet, de janvier à juin 2016, en randonnée et en alpinisme, l’Association Nationale pour l’Étude de la Neige et des Avalanches (ANENA) a comptabilisé 21 accidents notables, dont 8 accidents mortels, impliquant 15 décès.

Aujourd’hui, les mesures de sécurités préconisent que chaque groupe de randonneur se doivent de se munir d’un téléphone portable afin d’appeler les secours en cas de problème. Malheureusement, la communication mobile dépendant de la couverture réseau, peu présente en montagne, l’impossibilité de joindre les secours reste un problème.

==Solutions existantes==

La solution la plus répandue, est celle du téléphone à connexion satellite. Ayant une communication vers les satellites, cela permet une couverture réseau beaucoup plus répandue dans les montagnes, partout dans le monde (ou presque). Cependant, les téléphones portables satellitaires coûtent chers, et ne sont pas forcément abordables par la plupart des personnes, surtout celles ne sortant qu’occasionnellement.

[https://fall-alarm.net/ Fall Alarm] est un système de détection de chute sur chantier utilisant les mêmes technologies dont nous avons besoin pour notre projet.

==Quelles zones géographiques ?==

Toutes les zones montagneuses peuvent présenter des zones blanches, démunies de connexion quelconque autre que les connexions satellitaires. Certaines chaînes de montagne comme la Cordillaire des Andes ne présentent aucune connexion possible quelconque.

Dans le cadre de notre projet, nous fonctionnerons essentiellement dans la localisation grenobloise avec l'objectif que notre solution soit applicable partout dans le monde. Une contrainte intervient tout de même étant donnée que la fréquence d'utilisation du LoRa en Europe est de 868MHz, 915MHz en Amérique et 433MHz en Asie.

= Fonctionnalités =

Afin de remplir au mieux ses attentes, le principal objectif de ce dispositif sera premièrement de pouvoir communiquer avec les secours à n’importe quel moment, et surtout n’importe où. De plus, il sera capable de détecter de nombreux cas de détresse de la part de l’usager afin de pouvoir lancer un appel d’urgence sans interaction avec l’usager, au cas où il serait inconscient, ou incapable de lancer un appel manuel.

Grâce aux accéléromètres, le dispositif sera à même de détecter un mouvement brutal du randonneur, ce qui pourrait s’apparenter à une chute. Ils pourront également détecter une position anormale, ou une immobilité prolongée, ce qui déclencherait le dispositif d’urgence automatiquement.

Grâce à des tests réalisés au préalable, le boîtier pourra détecter correctement les chûtes de simples mouvements, afin de ne pas lancer l’appel sans raison valable.

Avant de lancer une alerte automatique, le dispositif émettra un signal auditif et visuel à l’utilisateur quelques secondes auparavant, afin de le prévenir l'émission du signal d’urgence, et de lui proposer de le désactiver sur simple pression d’un bouton, afin d’éviter les communications inutiles.

Également, le randonneur sera à même d'émettre volontairement un appel d’urgence à l’aide du bouton, ce qui permet à tout moment d’appeler de l’aide sans effort. Cela peut permettre également à appeler les secours pour une personne en danger qui ne porterait pas le dispositif.

L’appel au secours se représente par un envoi de coordonnées GPS aux secours, via une communication radio LoRa vers des bornes relais placées au préalables en montagne. Cette communication irait de relai de relai jusqu’au centre de sécurité, d’où le message serait transmis aux secours.

De plus, une application mobile verra le jour afin de connecter tous les utilisateurs du module de sécurité, de les visualiser sur une map, et de partager leurs données. En effet, à chaque incident, l’application mettra à jour la position et de la date de l’accident, afin de permettre aux prochains utilisateurs d’être prévenus. Ils pourraient, s'ils sont à proximité, d'assister la personne en détresse en attendant l'arrivée des secours. Bien évidemment, cette application ne sera accessible uniquement si le smartphone de l'utilisateur est relié à une connexion 4G ou Wi-Fi.

Cette prévention pourrait les sensibiliser aux risques de la montagne, leur permettre d’éviter le secteur mais aussi d’aider les personnes en danger si la distance le permet.

= Exigences =
== Fonctionnelles ==

*Batterie garantie fonctionnelle 1 semaine
*Rechargement possible via le panneau solaire portable
*Dispositif pouvant être allumé et éteint par l'utilisateur
*Alarme s’enclenche automatiquement dès qu'elle est considérée nécessaire, signal sonore
*Utilisateur a la possibilité d’activer/désactiver l’alarme quand il le souhaite
*Lorsque l’alarme est active, l’appareil ne peut s’éteindre
*...

== Non-Fonctionnelles ==

*Résistance : aux chocs, impacts, waterproof (utilisé en permanence en plein air)
*Disponibilité : Appareil de secours -> Doit être au plus possible performant
*Performance : Minimiser les pertes réseaux
*Accessible : Utilisateur pas forcément familier avec des appareils électroniques (facile d’utilisation)
*Fiabilité : Précision du GPS (rayon de 10m), données non-éronnées
*Coût : Le plus faible possible pour vendre le moins cher possible
*Efficacité : Réduire la consommation, utiliser le moins possible les ressources

= Composants =
== LoRaONE ==
Pour le coeur du projet, après avoir cherché et comparés plusieurs modules LoRa, GPS ou encore accéléromètres, nous avons finalement opté pour le projet LoRaONE.

LoRaONE est un projet de SODAQ regroupant plusieurs composants dans une seule et même carte, de taille réduite.

https://www.kickstarter.com/projects/sodaq/loraone-the-lora-iot-development-board

“The one IoT development board to rule them all” --SODAQ

Cette carte regroupe plusieurs capteurs afin de respecter aux mieux nos exigences :

Un émetteur/récepteur LoRa afin de pouvoir communiquer au mieux avec les antennes relai à longue distance

Un module + antenne GPS de bonne précision (< 10m) pour connaître en tout temps notre position, et ainsi faciliter l’arrivée des secours, ainsi que la recherche de l’individu en détresse

Un accéléromètre sur 3 axes afin de pouvoir détecter tout mouvement, vitesse ou rotation dans l’espace, ce qui permet la détection de chutes ou d’arrêt de mouvements

3 LED RGB afin de pouvoir signaler à l’utilisateur un manque de batterie, un signal d’urgence ou plus si nécessaire

Un bouton poussoir pour le signal d’alarme

Un connecteur de charge par panneau solaire, afin de faire durer chaque batterie le plus longtemps possible

Un connecteur micro-USB ainsi que des lignes pour se connecter à une base Arduino si besoin

[[File:LoRaOne.png||400px|Spécifications carte LoRaOne]]

De plus, grâce au starter pack, nous pouvons avoir accès à la base ONEBase qui nous permettrait d’étendre plus loin la facilité d’utilisation du produit :

[[File:LoRaOneBase.png||400px|Spécifications base LoRaOneBase]]

Comme nous pouvons le voir, cette base nous permettra de connecter la batterie ainsi que le panneau solaire qui sont fournis dans le pack.

Nous pourrons également connecter jusqu’à 4 modules supplémentaires.

La batterie fournie aura une capacité de 800 mAh, le panneau solaire fourni pouvant délivrer jusqu’à 500 mW de puissance.

Le total atteint une taille d’environ 10*5 cm, ce qui n’est pas excessif, ce qui le rend aisément portatif sur une jambe ou à la taille.

'''Coût : 115€'''

Ce module pourra également servir d’antenne relai, l'alimentation solaire devrait maintenir le dispositif chargé en permanence. Des tests seront effectués pour savoir si un panneau solaire plus puissant est requis.

== Boîtier ==

Le boîtier sécurisé devant respecter plusieurs exigences, nous pouvons le construire en plastique résistant, ce qui le rendrait léger tout en respectant une rigidité suffisante. Les antennes pourront être placées le long du boîtier, à l’intérieur si la connexion est suffisante, ou à l’extérieur. Dans ce dernier cas les trous réalisés sur le boîtier afin de laisser passer les câbles seront colmatés afin de garantir une étanchéité.

[[File:SchemaBoitier.png||100px|Schéma boitier d'alarme]]

== Balises ==

Afin de remonter les informations transmises par les boitiers, des balises seront mises en places sur la zone à couvrir, leur nombre et leur positions dépendra du terrain (obstacles, dénivelés). On distinguera deux types de balises. Tout d’abord, les balises racines qui permettront une communication GSM afin de faire remonter les données vers le serveur. Viennent ensuite les balises standard qui se contenteront de faire remonter vers leur balise racine associée. L’architecture de liaison des balises est détaillée dans une prochaine partie.

Chaque balise est composée d’une barre de fer pouvant être plantée dans le sol, d’un système de lest afin d’immobiliser la balise, d’un paratonnerre, d’un panneau solaire ainsi que d’un LoraOne et d’une batterie. Les balises racines seront équippée en plus d’un dispositif de communication GSM (téléphone portable, émetteur GSM).

[[File:SchemaBalise.png||150px|Schéma balises d'alarme]]

== Application mobile ==
Une application mobile est téléchargeable par les utilisateurs. Ils peuvent voir les autres utilisateurs présents dans leur zone. Lorsqu’un utilisateur est en position de danger, une notification apparaît si les utilisateurs sont proches de la situation de danger.

Cette application n’est pas directement reliée au dispositif. Elle ne fonctionne qu’avec la connexion du mobile, et est destinée à être un niveau de sécurité supérieur. Un randonneur proche d’une zone de danger pourrait arriver sur place plus rapidement que les secours.

= Communication =

Pour un envoi de position + numéro d’identification (X chiffres) :

*Temps de communication : < 2 s
*Communication régulière, intervalle de 15 minutes

On peut donc au maximum avoir 15 * 60 / 2 = 450 individus pouvant communiquer avec la même antenne relai, donc dans le même cercle d’environ 15 km de diamètre.

On communique donc au minimum 2 secondes sur 15 minutes, donc 1/450 << 1%, le temps de communication est respecté.

En cas de problème, nous pouvons envoyer jusqu’à 9x plus avec la borne sans dépasser le temps de communication autorisé (1%). Donc 1 envoi d’appel d’urgence toutes les 2 minutes environ.

La balise racine peut être directement connectée au serveur, dans ce cas, il n’y a pas de communication GSM nécessaire et pas de Gateway. Si la racine n’est pas directement connectée au serveur, elle devra au minimum garantir une communication GSM (ce qu’elle peut faire, il n’y a pas de Gateway nécessaire) pour remonter l’information vers le serveur, et donc la base de données.

GSM : Si Racine connectée à Serveur -> No GSM + Gateway
Else : GSM + Gateway : LoRa Racine connectée ordi (RaspberryPI) + ordi connecté GSM

= Stabilisation et gestion d’erreurs =

== Choix du routage ==

Notre réseau n'est pas un réseau traditionnel. Les seules communications existantes sont soit une remontée d'information vers la racine soit une innondation d'alerte vers les clients. Pour celà nous avons donc décidé d'utiliser un algorithme de routage simplifié basé uniquement sur un arbre en largeur des balises. Nous rajoutons en option la possibilité de créer plusieurs racines et donc plusieurs arbres dont les racines communiquent par gsm. Nous nous basons sur des papiers de recherches afin de déterminer quel algorithme auto-stabilisant est le plus adapté au système LoRa (Tel que le papier "A self-stabilizing algorithm for constructing breadth-first trees" par Shing-Tsaan Huang, Nian-Shing Chen).

== Stabilisation ==

Afin de gérer la communication de chaque message vers le serveur, nous allons prendre un noeud (balise LoRa) dit “racine” connecté directement au serveur, nous ne nous occuperons pas de la communication au serveur dans cet onglet. Chaque message reçu de la part d’un noeud du système doit être relayé jusqu’à la racine du système afin de communiquer avec les secours (ou serveur simplement).

Pour cela, il faudra assurer que chaque balise LoRa soit connecté au réseau, afin d’avoir au départ un graphe de communication connexe. Par dessus ce graphe, nous allons utiliser un processus silencieux auto-stabilisant qui construira un arbre de parcours en largeur, avec pour racine le noeud “racine” décidé ci-dessus.

Au lancement du système, il faut prévoir un léger temps de stabilisation, qui dépendrait de l’algorithme et de la taille du graphe (nombre de balises). Cependant, après cela, l’algorithme assure un arbre en profondeur minimal qui nous permettrai de communiquer avec la racine le plus rapidement possible, et donc une qualité de service maximale.

== Gestion d’erreurs ==

Dans un réseau comme celui-ci, plusieurs types d’erreurs peuvent se produire :
Délai de communication trop important vers une balise
“Crash” d’une balise de communication
Surpopulation d’une balise ou congestion de messages

Afin de palier au premier type d’incident rencontré, il faut nécessairement qu’à chaque emplacement dans la zone couverte, l’utilisateur soit à même de communiquer avec au minimum 2 balises différentes. Ainsi, dans le cas d’une communication trop longue sur une balise, l’autre aurait de grandes chances de délivrer le message plus rapidement.

Au niveau de la défaillance d’une balise, l’algorithme d’arbre en profondeur nous fournit déjà une solution intégrée grâce à son auto-stabilisation. Dans le cas de déconnexion d’une balise, l’algorithme mettrai à jour automatiquement l’arbre de communication, et n’importe quel message d’alerte émis serait délivré dans un délai raisonnable.

Pour le troisième cas d’erreur, il n’y aurait pas de solution réelle, si ce n’est de limiter le nombre de communications données, en ne prenant plus en compte les “ping” de chaque utilisateur mais seulement les messages d’alertes, ce qui permettrai une bien plus grande gestion de la congestion à un endroit donné. Également, une balise en dessous d’un lien congestionné pourrait communiquer avec ses autres voisins (non-fils dans l’arbre) afin de libérer de l’espace dans le lien avec son père dans l’arbre. Également, le système ne pourra accepter que jusqu’à 1000 utilisateurs par noeud, et également 4000 utilisateurs par cluster (dans le cas d’un réseau avec plusieurs clusters donc plusieurs racines cette limite augmente).

Plusieurs types de paquets circulent sur le réseau de balise:
Les pings, messages envoyés spontanéments à intervalle régulier par les utilisateur contenant l’id ainsi que les deux coordonées gps (27 bits chacun)
Les incidents, identique à un ping mais à priorité haute.
Les alertes, messages brodcastés par le serveur afin d’envoyer un message en chaine de caractères courts et compressés.

=Coûts matériels=

Que ce soit pour le dispositif utilisateur ou la balise (racine ou non), le LoRaOne correspond pour permettre les actions recherchées. Afin de réaliser un prototype pertinent, 6 kits LoRaOne sont requis. Ces kits sont accessibles sur le site de Sodaq au prix de 115€ chacun (prix variable).
Disponible [https://shop.sodaq.com/en/one-eu-rn2483-v2.html ici], voir avant dernier bundle : starter "ONE EU starter" actuellement à 112,10€.

Un [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer buzzer] est à ajouter au dispositif utilisateur afin de lui délivrer un signal sonore.

Un shield GSM est requis pour que la balise racine communique avec l'extérieur. Sodaq en propose un designé pour fonctionner sur leurs produits mais est éctuellement en rupture de stock. Un shield GSM arduino convient tout autant et peut être trouvé sur le site arduino [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna ici].

Aucun boitier ne sera commandé car nous avons fait le choix de les manufacturer nous même au fablab. Le besoin d'étanchéité n'est pas primordial pour notre prototype, bien que nous tenterons de l'assurer.

{|class="récap commande"
|+ Récapitulatif
|-
|
!scope="col" style="width: 320px;"| Produit
!scope="col" style="width: 80px;"| Lien
!scope="col" style="width: 80px;"| Quantité
!scope="col" style="width: 80px;"| Prix Unitaire
|-

!scope="row"| 1
| LoRaOne EU Starter
| [https://shop.sodaq.com/en/one-eu-rn2483-v2.html Achat]
| 6
| 115€
|-

!scope="row"| 2
| Buzzer
| [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer Achat]
| 3
| 5.49€
|-

!scope="row"| 3
| Shield GSM
| [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna Achat]
| 1
| 65€
|-

|}

=Développement=

Nous utiliserons les librairies standards Arduino ainsi que celle de SODAQ/Arduino pour le LoRa.

L'IDE Arduino sera utilisé, plus pratique pour l'utilisation de Git (comparé à Mbed).

= Mise sur le marché =

Ce dispositif a pour but d’être utilisé en montagne, lors de randonnée. Il n’est pas destiné à un usage quotidien, c’est pourquoi nous considérons qu’il est plus judicieux de louer les dispositifs plutôt que de les vendre, même si l’achat n’est pas à omettre de notre stratégie.

Le dispositif peut être commandé en ligne, puis retourné par la poste après usage. Le client louerait le dispositif pour une certaine durée avec un possible nombre supplémentaire de batterie. Les tarifs varient en fonction de la durée et du nombre de batteries louées. Des offres de groupes pourraient être applicables. A long terme, des boutiques pourraient être disséminées dans des grandes villes proches des zones montagneuses, zones à randonnées (Grenoble, Annecy, etc.).

L’application est téléchargeable gratuitement par quiconque, mais utilisable seulement par les clients. Un code d’accès sera envoyé avec le dispositif expirant après la fin de la location.

Il faudra tenir compte de la bande passante du LoRa, variante en fonction des continents.

=Planning prévisonnel=

Sprint 1 : 29/01 --> 09/02 : Création du prototype logiciel #1
*Prise en main du matériel
*Premiers tests de transmissions LoRa
*Création du protocole d'architecture des balises
*Application sur les cartes et tests
*Tests de performances des cartes (durabilité, chargement, batterie)
*Tests de maintenabilité de l'algorithme (déconnexions, latences)

Sprint 2 : 12/02 --> 23/02 : Prototype logiciel #2 et prototype matériel
*Création du programme embarqué (utilisateur)
*Communication avec la racine et le serveur
*Création des maquettes boîtier et balise
*Construction des maquettes
*Finalisation du premier prototype

Sprint 3 : 26/02 --> 09/03 : Fonctionnalités supplémentaires
*Ajout de la communication entre le LoRa et le GSM sur la balise racine
*Création application mobile utilisateur
*Tests sur l'application
*Tests sur la transmission totale depuis l'utilisateur vers le serveur via le GSM
*Finalisation du projet

Sprint 4 : 12/03 --> 16/03 : Fin du projet
*Création de la documentation finale (à partir de la documentation réalisée en continu)
*Pause café
*Temps supplémentaire en cas de problèmes importants
*Préparation de la soutenance

R'Montagne

2018-03-14T09:42:41Z

Hugo.Amodru-Favin: /* Journal */

=Équipe=
{|class="wikitable"
|-
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Rôle
|-
| Hugo Amodru-Favin
| Chef de Projet
|-
| Antoine Delise
| Lead Developer
|-
| Gwenaël Moreau
| Kanban Master
|-

|}

==Tâches==

Répartition générale des tâches
{|class="wikitable"
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Tâche
|-
| Hugo Amodru-Favin
| Application Ionic
|-
| Antoine Delise
| Développement Arduino
|-
| Gwenaël Moreau
| BDD - API
|-

|}

Détail des tâches : [https://waffle.io/delisea/R-Montagne Waffle.io]

=Journal=

{|class="wikitable"
|+
|-
!scope="col" width="120px"| Date
!scope="col" width="350px"| Hugo AMODRU-FAVIN
!scope="col" width="350px"| Antoine DELISE
!scope="col" width="350px"| Gwenaël MOREAU
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 1
|-

|-
| rowspan="1" | Lundi 29/01/18
| style="width: 225px;" |
* Ré-assimilation du sujet
| style="width: 225px;" |
* Ré-assimilation du sujet
| style="width: 225px;" |
* Ré-assimilation du sujet
* Mise en place d'un Kanban
|-
| rowspan="1" | Mardi 30/01/18
| style="width: 225px;" |
* Mise à jour de la page AIR
* Réflexions sur l'implémentation du LoRa
| style="width: 225px;" |
* Mise à jour de la page AIR
* Réflexions sur l'implémentation du LoRa
| style="width: 225px;" |
* Mise en place du calendrier prévisionnel
* Définition et répartition des tâches
|-
| rowspan="1" | Mercredi 31/01/18
| style="width: 225px;" |
* Récupération des cartes Semtech
* Présentation du Hackathon Vinci Energies
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Récupération des cartes Semtech
* Présentation du Hackathon
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Récupération et prise en main des cartes Semtech LoRaMote
* Présentation du Hackathon Vinci Energies
|-
| rowspan="1" | Jeudi 01/02/18
| style="width: 225px;" |
* Choix des fonctionnalités de l'application mobile
| style="width: 225px;" |
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Prise en main des cartes LoRa
|-
| rowspan="1" | Vendredi 02/02/18
| style="width: 225px;" |
* Réflexions sur l'implémentation de l'application
* Démarrage de l'application mobile
* Mises à jour d'Ionic, de Android Studio
| style="width: 225px;" |
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Premières communications fructueuses des cartes Semtech LoRaMote
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 2
|-

|-
| rowspan="1" | Lundi 05/02/18
| style="width: 225px;" |
* Configuration Login et Mot de Passe, Identification base
| style="width: 225px;" |
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Réflexion et création de la base de données
|-
| rowspan="1" | Mardi 06/02/18
| style="width: 225px;" |
* Configuration Login, Mot de passe
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
| style="width: 225px;" |
* Création de l'API REST EN PHP
|-
| rowspan="1" | Mercredi 07/02/18
| style="width: 225px;" |
* Réunion avec Rémi CHOLLET et 3 PEIP D
* Assimilation du fonctionnement de Leaflet
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
| style="width: 225px;" |
* Réunion avec Rémi CHOLLET et 3 PEIP D
* Création de l'API REST en PHP
|-
| rowspan="1" | Jeudi 08/02/18
| style="width: 225px;" |
* Ajout de marqueurs sur Leaflet
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
| style="width: 225px;" |
* Création de l'API REST EN PHP
|-
| rowspan="1" | Vendredi 09/02/18
| style="width: 225px;" |
* Hackathon Vinci Energies
| style="width: 225px;" |
* Hackathon Vinci Energies
| style="width: 225px;" |
* Hackathon Vinci Energies
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 3
|-

|-
| rowspan="1" | Lundi 12/02/18
| style="width: 225px;" |
* Préparation Soutenance
| style="width: 225px;" |
* Mise en place d'un Contiki/Cooja pour faciliter le développement
| style="width: 225px;" |
* Préparation Soutenance
|-
| rowspan="1" | Mardi 13/02/18
| style="width: 225px;" |
* Mise à jour de AIR
* Préparation Soutenance
* Répétition soutenance
| style="width: 225px;" |
* Préparation Soutenance
* Répétition soutenance
* Mise en place d'un Contiki/Cooja pour faciliter le dévelloppement
| style="width: 225px;" |
* Préparation Soutenance
* Répétition soutenance
|-
| rowspan="1" | Mercredi 14/02/18
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
|-
| rowspan="1" | Jeudi 15/02/18
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
|-
| rowspan="1" | Vendredi 16/02/18
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 4
|-

|-
| rowspan="1" | Lundi 26/02/18
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Travail sur l'affichage des éléments sur la carte utilisateur
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Travail sur Contiki, création d'un protocole de routage
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Corrections de l'API en accord avec l'application mobile
* Modifications sur la base de données
|-
| rowspan="1" | Mardi 27/02/18
| style="width: 225px;" |
* Création de la page de création d'un nouvel utilisateur
* Design de l'application mobile
| style="width: 225px;" |
* Fin du protocole de routage Contiki, tests virtuels de fonctionnement
| style="width: 225px;" |
* Liaison entre l'application mobile et l'API
|-
| rowspan="1" | Mercredi 28/02/18
| style="width: 225px;" |
* Fin de la page de création d'un nouvel utilisateur
* Ajout de l'utilisation des sessions dans l'application
| style="width: 225px;" |
* Panne ordinateur personnel
* Travail sur l'application mobile avec Hugo
| style="width: 225px;" |
* API : Création d'un utilisateur
* API : Récupération des informations nécessaires pour la carte
* API : Ajout de l'utilisation des sessions pour stocker l'utilisateur connecté
|-
| rowspan="1" | Jeudi 01/03/18
| style="width: 225px;" |
* Affichage des informations sur la carte
| style="width: 225px;" |
* Affichage des informations sur la carte
| style="width: 225px;" |
* API : Récupération des informations nécessaires pour la carte
|-
| rowspan="1" | Vendredi 03/03/18
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Réparation d'ordinateur personnel
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Renseignements sur Swagger
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 5
|-

|-
| rowspan="1" | Lundi 05/03/18
| style="width: 225px;" |
* Ajout de la page de modification d'un utilisateur
* Restructuration de l'application
| style="width: 225px;" |
* Finalisation de la carte, et ajout de la gestion des différentes cartes
* Restructuration de l'application
| style="width: 225px;" |
* Création d'une page Swagger
* Corrections de l'API
* Ajout des cartes dans la base de données
* Récupération des éléments liés à la carte dans l'API
|-
| rowspan="1" | Mardi 06/03/18
| style="width: 225px;" |
* Fin de la modification d'un utilisateur
* Ajout de changement de mot de passe
* Ajout gestion secouriste
| style="width: 225px;" |
* Ajout gestion secouriste
* Création vues côté secouristes
| style="width: 225px;" |
* Fin du Swagger
* API : Modifications utilisateur
* API : Modifications mot de passe
* Base de données : Ajout affectations secouristes-cartes
* API : Récupération des cartes pour un secouriste
|-
| rowspan="1" | Mercredi 07/03/18
| style="width: 225px;" |
* Ajout des notifications
| style="width: 225px;" |
* Corrections du menu et de la navigation
| style="width: 225px;" |
* Journaux sur air.imag.fr
* Programme de récupération des messages à la racine et inscription des données dans la base de données
|-
| rowspan="1" | Jeudi 08/03/18
| style="width: 225px;" |
* Extraction des dents de sagesse
| style="width: 225px;" |
*
| style="width: 225px;" |
* Création du programme de communication LoRa et récupération des coordonnées GPS depuis la carte SodaqONE
* Tests de temps de synchronisation et précision du GPS
|-
| rowspan="1" | Vendredi 09/03/18
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Design du LogoV2, Embellie CSS de l'application mobile
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
*
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Finition du programme de communication LoRa
* Tests d'envoi de la carte SodaqONE vers la base de données en passant par une racine (carte Arduino LoRa)
|-
| rowspan="1" | Samedi 10/03/18
| style="width: 225px;" |
* Réflexions et implémentations des Usercases concernant la gestion des licences
* Ajout de notifications mobiles
* Ajout d'une page liée à la gestion des Trackers
* Poster Anniversaire
| style="width: 225px;" |
* Réflexions et implémentations des Usercases concernant la gestion des licences
| style="width: 225px;" |
* Tests du programme de communication avec les LoRas
|-
| rowspan="1" | Dimanche 11/03/18
| style="width: 225px;" |
*
| style="width: 225px;" |
*
| style="width: 225px;" |
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 6
|-

|-
| rowspan="1" | Lundi 12/03/18
| style="width: 225px;" |
* Ajouts de fonctionnalités dans l'application
| style="width: 225px;" |
* Correctifs programme de communication
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Correctifs programme de communication
|-
| rowspan="1" | Mardi 13/03/18
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Finalisation des fonctionnalités de l'application
* Correctifs des bugs
* Test Réel à la Bastille
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Finalisation des fonctionnalités de l'application
* Correctifs des bugs
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Préparation des capteurs pour le test réel
* Test Réel à la Bastille
|-
| rowspan="1" | Mercredi 14/03/18
| style="width: 225px;" |
* Préparation de la soutenance
* Finalisation du Poster
* Test Réel aux Taillées
| style="width: 225px;" |
* Préparation de la soutenance
* Préparation de la démonstration
* Dernier correctifs de l'application
| style="width: 225px;" |
* Préparation de la soutenance
* Finalisation du Poster
* Test Réel aux Taillées
|-
| rowspan="1" | Jeudi 15/03/18
| style="width: 225px;" |
* Soutenance de Projet
| style="width: 225px;" |
* Soutenance de Projet
| style="width: 225px;" |
* Soutenance de Projet
|}

=Collaboration avec le DUT RT et les PEIPs D=
L'objectif de cette collaboration est de familiariser des étudiants en PEIP D avec des projets qu'ils seront amenés à développer dans les prochaines années. Nous avons rencontré Rémi CHOLLET et 3 étudiants Mercredi 7 Février, en voici un résumé écrit par Mr CHOLLET définissant les contours de cette collaboration.

"Un rapide résumé de la rencontre que nous avons eu ce matin avec le projet R’Montagne.

Présents :
- RCIM5 Gwenael Moreau, Hugo Amodru-Favin
- PEIP-D : Yoann Goma-Missamou, Vincent Cadoux, Philippe Charrat
- IUT : Rémy Chollet, tuteur pédagogique des PEIP-D
Excusés : Didier Donsez, blessé (aie ! courage …), Antoine Delise en cours de marketing

Contexte :
Les PEIP-D participent aux projets RICM5 en prenant une tâche « annexe » (hors chemin critique) en charge. L’objectif est une expérience d’immersion + notation liée au PEIP.

Déroulé :
Les étudiant RCIM5 ont présenté le projet dans son principe et état d’avancement. Les échanges se sont portés sur l’idée de mener une étude (simulation et mesure) sur la consommation des balises par les PEIP-D avec pour objectif de dimensionner la réserve d’énergie.

Ceci implique :
- coté RCIM5 : mise à disposition d’une carte prototype.

- cote PEIP-D : inventaire des paramètres à prendre en compte :
* consommation carte (GPS + puce LoRa) = > veille + temps d’activation (recherche à faire sur le temps de synchronisation du GPS)
* puissance d’émission à calibrer en fonction de la couverture voulue et débit (voir Spread Factor ?)
* temps d’émission-réception (émission jusqu’à acquittement)

- cote PEIP-D : penser la manip pour valider ce modèle
* mesure moyenne du courant
* configuration effective du réseau
* réserver le matériel (voir Jean-Yves Frau au département R&T ?)

- cote PEIP-D : paramètrer les simulations et mesures en fonction de puissance d’émission (ou autre élément pouvant apparaitre comme pertinent)

D’une manière générale, pour les PEID-D :
- penser bibliographie (pour commencer : https://fr.wikipedia.org/wiki/LoRaWAN et aussi https://fr.wikipedia.org/wiki/Format_des_piles_et_accumulateurs_électriques :-) )
- planifier
- communiquer : reporting !!!"

=Description du sujet=

==Randonnée et risques==

Ouvert à tous, la randonnée est un sport et un loisir qui prend de plus en plus d’ampleur de nos jours. Ne nécessitant pas de grands prérequis, des milliers de personnes se lancent en montagne chaque jour, malheureusement parfois sans connaître toutes les mesures de sécurité associées.

En effet, de janvier à juin 2016, en randonnée et en alpinisme, l’Association Nationale pour l’Étude de la Neige et des Avalanches (ANENA) a comptabilisé 21 accidents notables, dont 8 accidents mortels, impliquant 15 décès.

Aujourd’hui, les mesures de sécurités préconisent que chaque groupe de randonneur se doivent de se munir d’un téléphone portable afin d’appeler les secours en cas de problème. Malheureusement, la communication mobile dépendant de la couverture réseau, peu présente en montagne, l’impossibilité de joindre les secours reste un problème.

==Solutions existantes==

La solution la plus répandue, est celle du téléphone à connexion satellite. Ayant une communication vers les satellites, cela permet une couverture réseau beaucoup plus répandue dans les montagnes, partout dans le monde (ou presque). Cependant, les téléphones portables satellitaires coûtent chers, et ne sont pas forcément abordables par la plupart des personnes, surtout celles ne sortant qu’occasionnellement.

[https://fall-alarm.net/ Fall Alarm] est un système de détection de chute sur chantier utilisant les mêmes technologies dont nous avons besoin pour notre projet.

==Quelles zones géographiques ?==

Toutes les zones montagneuses peuvent présenter des zones blanches, démunies de connexion quelconque autre que les connexions satellitaires. Certaines chaînes de montagne comme la Cordillaire des Andes ne présentent aucune connexion possible quelconque.

Dans le cadre de notre projet, nous fonctionnerons essentiellement dans la localisation grenobloise avec l'objectif que notre solution soit applicable partout dans le monde. Une contrainte intervient tout de même étant donnée que la fréquence d'utilisation du LoRa en Europe est de 868MHz, 915MHz en Amérique et 433MHz en Asie.

= Fonctionnalités =

Afin de remplir au mieux ses attentes, le principal objectif de ce dispositif sera premièrement de pouvoir communiquer avec les secours à n’importe quel moment, et surtout n’importe où. De plus, il sera capable de détecter de nombreux cas de détresse de la part de l’usager afin de pouvoir lancer un appel d’urgence sans interaction avec l’usager, au cas où il serait inconscient, ou incapable de lancer un appel manuel.

Grâce aux accéléromètres, le dispositif sera à même de détecter un mouvement brutal du randonneur, ce qui pourrait s’apparenter à une chute. Ils pourront également détecter une position anormale, ou une immobilité prolongée, ce qui déclencherait le dispositif d’urgence automatiquement.

Grâce à des tests réalisés au préalable, le boîtier pourra détecter correctement les chûtes de simples mouvements, afin de ne pas lancer l’appel sans raison valable.

Avant de lancer une alerte automatique, le dispositif émettra un signal auditif et visuel à l’utilisateur quelques secondes auparavant, afin de le prévenir l'émission du signal d’urgence, et de lui proposer de le désactiver sur simple pression d’un bouton, afin d’éviter les communications inutiles.

Également, le randonneur sera à même d'émettre volontairement un appel d’urgence à l’aide du bouton, ce qui permet à tout moment d’appeler de l’aide sans effort. Cela peut permettre également à appeler les secours pour une personne en danger qui ne porterait pas le dispositif.

L’appel au secours se représente par un envoi de coordonnées GPS aux secours, via une communication radio LoRa vers des bornes relais placées au préalables en montagne. Cette communication irait de relai de relai jusqu’au centre de sécurité, d’où le message serait transmis aux secours.

De plus, une application mobile verra le jour afin de connecter tous les utilisateurs du module de sécurité, de les visualiser sur une map, et de partager leurs données. En effet, à chaque incident, l’application mettra à jour la position et de la date de l’accident, afin de permettre aux prochains utilisateurs d’être prévenus. Ils pourraient, s'ils sont à proximité, d'assister la personne en détresse en attendant l'arrivée des secours. Bien évidemment, cette application ne sera accessible uniquement si le smartphone de l'utilisateur est relié à une connexion 4G ou Wi-Fi.

Cette prévention pourrait les sensibiliser aux risques de la montagne, leur permettre d’éviter le secteur mais aussi d’aider les personnes en danger si la distance le permet.

= Exigences =
== Fonctionnelles ==

*Batterie garantie fonctionnelle 1 semaine
*Rechargement possible via le panneau solaire portable
*Dispositif pouvant être allumé et éteint par l'utilisateur
*Alarme s’enclenche automatiquement dès qu'elle est considérée nécessaire, signal sonore
*Utilisateur a la possibilité d’activer/désactiver l’alarme quand il le souhaite
*Lorsque l’alarme est active, l’appareil ne peut s’éteindre
*...

== Non-Fonctionnelles ==

*Résistance : aux chocs, impacts, waterproof (utilisé en permanence en plein air)
*Disponibilité : Appareil de secours -> Doit être au plus possible performant
*Performance : Minimiser les pertes réseaux
*Accessible : Utilisateur pas forcément familier avec des appareils électroniques (facile d’utilisation)
*Fiabilité : Précision du GPS (rayon de 10m), données non-éronnées
*Coût : Le plus faible possible pour vendre le moins cher possible
*Efficacité : Réduire la consommation, utiliser le moins possible les ressources

= Composants =
== LoRaONE ==
Pour le coeur du projet, après avoir cherché et comparés plusieurs modules LoRa, GPS ou encore accéléromètres, nous avons finalement opté pour le projet LoRaONE.

LoRaONE est un projet de SODAQ regroupant plusieurs composants dans une seule et même carte, de taille réduite.

https://www.kickstarter.com/projects/sodaq/loraone-the-lora-iot-development-board

“The one IoT development board to rule them all” --SODAQ

Cette carte regroupe plusieurs capteurs afin de respecter aux mieux nos exigences :

Un émetteur/récepteur LoRa afin de pouvoir communiquer au mieux avec les antennes relai à longue distance

Un module + antenne GPS de bonne précision (< 10m) pour connaître en tout temps notre position, et ainsi faciliter l’arrivée des secours, ainsi que la recherche de l’individu en détresse

Un accéléromètre sur 3 axes afin de pouvoir détecter tout mouvement, vitesse ou rotation dans l’espace, ce qui permet la détection de chutes ou d’arrêt de mouvements

3 LED RGB afin de pouvoir signaler à l’utilisateur un manque de batterie, un signal d’urgence ou plus si nécessaire

Un bouton poussoir pour le signal d’alarme

Un connecteur de charge par panneau solaire, afin de faire durer chaque batterie le plus longtemps possible

Un connecteur micro-USB ainsi que des lignes pour se connecter à une base Arduino si besoin

[[File:LoRaOne.png||400px|Spécifications carte LoRaOne]]

De plus, grâce au starter pack, nous pouvons avoir accès à la base ONEBase qui nous permettrait d’étendre plus loin la facilité d’utilisation du produit :

[[File:LoRaOneBase.png||400px|Spécifications base LoRaOneBase]]

Comme nous pouvons le voir, cette base nous permettra de connecter la batterie ainsi que le panneau solaire qui sont fournis dans le pack.

Nous pourrons également connecter jusqu’à 4 modules supplémentaires.

La batterie fournie aura une capacité de 800 mAh, le panneau solaire fourni pouvant délivrer jusqu’à 500 mW de puissance.

Le total atteint une taille d’environ 10*5 cm, ce qui n’est pas excessif, ce qui le rend aisément portatif sur une jambe ou à la taille.

'''Coût : 115€'''

Ce module pourra également servir d’antenne relai, l'alimentation solaire devrait maintenir le dispositif chargé en permanence. Des tests seront effectués pour savoir si un panneau solaire plus puissant est requis.

== Boîtier ==

Le boîtier sécurisé devant respecter plusieurs exigences, nous pouvons le construire en plastique résistant, ce qui le rendrait léger tout en respectant une rigidité suffisante. Les antennes pourront être placées le long du boîtier, à l’intérieur si la connexion est suffisante, ou à l’extérieur. Dans ce dernier cas les trous réalisés sur le boîtier afin de laisser passer les câbles seront colmatés afin de garantir une étanchéité.

[[File:SchemaBoitier.png||100px|Schéma boitier d'alarme]]

== Balises ==

Afin de remonter les informations transmises par les boitiers, des balises seront mises en places sur la zone à couvrir, leur nombre et leur positions dépendra du terrain (obstacles, dénivelés). On distinguera deux types de balises. Tout d’abord, les balises racines qui permettront une communication GSM afin de faire remonter les données vers le serveur. Viennent ensuite les balises standard qui se contenteront de faire remonter vers leur balise racine associée. L’architecture de liaison des balises est détaillée dans une prochaine partie.

Chaque balise est composée d’une barre de fer pouvant être plantée dans le sol, d’un système de lest afin d’immobiliser la balise, d’un paratonnerre, d’un panneau solaire ainsi que d’un LoraOne et d’une batterie. Les balises racines seront équippée en plus d’un dispositif de communication GSM (téléphone portable, émetteur GSM).

[[File:SchemaBalise.png||150px|Schéma balises d'alarme]]

== Application mobile ==
Une application mobile est téléchargeable par les utilisateurs. Ils peuvent voir les autres utilisateurs présents dans leur zone. Lorsqu’un utilisateur est en position de danger, une notification apparaît si les utilisateurs sont proches de la situation de danger.

Cette application n’est pas directement reliée au dispositif. Elle ne fonctionne qu’avec la connexion du mobile, et est destinée à être un niveau de sécurité supérieur. Un randonneur proche d’une zone de danger pourrait arriver sur place plus rapidement que les secours.

= Communication =

Pour un envoi de position + numéro d’identification (X chiffres) :

*Temps de communication : < 2 s
*Communication régulière, intervalle de 15 minutes

On peut donc au maximum avoir 15 * 60 / 2 = 450 individus pouvant communiquer avec la même antenne relai, donc dans le même cercle d’environ 15 km de diamètre.

On communique donc au minimum 2 secondes sur 15 minutes, donc 1/450 << 1%, le temps de communication est respecté.

En cas de problème, nous pouvons envoyer jusqu’à 9x plus avec la borne sans dépasser le temps de communication autorisé (1%). Donc 1 envoi d’appel d’urgence toutes les 2 minutes environ.

La balise racine peut être directement connectée au serveur, dans ce cas, il n’y a pas de communication GSM nécessaire et pas de Gateway. Si la racine n’est pas directement connectée au serveur, elle devra au minimum garantir une communication GSM (ce qu’elle peut faire, il n’y a pas de Gateway nécessaire) pour remonter l’information vers le serveur, et donc la base de données.

GSM : Si Racine connectée à Serveur -> No GSM + Gateway
Else : GSM + Gateway : LoRa Racine connectée ordi (RaspberryPI) + ordi connecté GSM

= Stabilisation et gestion d’erreurs =

== Choix du routage ==

Notre réseau n'est pas un réseau traditionnel. Les seules communications existantes sont soit une remontée d'information vers la racine soit une innondation d'alerte vers les clients. Pour celà nous avons donc décidé d'utiliser un algorithme de routage simplifié basé uniquement sur un arbre en largeur des balises. Nous rajoutons en option la possibilité de créer plusieurs racines et donc plusieurs arbres dont les racines communiquent par gsm. Nous nous basons sur des papiers de recherches afin de déterminer quel algorithme auto-stabilisant est le plus adapté au système LoRa (Tel que le papier "A self-stabilizing algorithm for constructing breadth-first trees" par Shing-Tsaan Huang, Nian-Shing Chen).

== Stabilisation ==

Afin de gérer la communication de chaque message vers le serveur, nous allons prendre un noeud (balise LoRa) dit “racine” connecté directement au serveur, nous ne nous occuperons pas de la communication au serveur dans cet onglet. Chaque message reçu de la part d’un noeud du système doit être relayé jusqu’à la racine du système afin de communiquer avec les secours (ou serveur simplement).

Pour cela, il faudra assurer que chaque balise LoRa soit connecté au réseau, afin d’avoir au départ un graphe de communication connexe. Par dessus ce graphe, nous allons utiliser un processus silencieux auto-stabilisant qui construira un arbre de parcours en largeur, avec pour racine le noeud “racine” décidé ci-dessus.

Au lancement du système, il faut prévoir un léger temps de stabilisation, qui dépendrait de l’algorithme et de la taille du graphe (nombre de balises). Cependant, après cela, l’algorithme assure un arbre en profondeur minimal qui nous permettrai de communiquer avec la racine le plus rapidement possible, et donc une qualité de service maximale.

== Gestion d’erreurs ==

Dans un réseau comme celui-ci, plusieurs types d’erreurs peuvent se produire :
Délai de communication trop important vers une balise
“Crash” d’une balise de communication
Surpopulation d’une balise ou congestion de messages

Afin de palier au premier type d’incident rencontré, il faut nécessairement qu’à chaque emplacement dans la zone couverte, l’utilisateur soit à même de communiquer avec au minimum 2 balises différentes. Ainsi, dans le cas d’une communication trop longue sur une balise, l’autre aurait de grandes chances de délivrer le message plus rapidement.

Au niveau de la défaillance d’une balise, l’algorithme d’arbre en profondeur nous fournit déjà une solution intégrée grâce à son auto-stabilisation. Dans le cas de déconnexion d’une balise, l’algorithme mettrai à jour automatiquement l’arbre de communication, et n’importe quel message d’alerte émis serait délivré dans un délai raisonnable.

Pour le troisième cas d’erreur, il n’y aurait pas de solution réelle, si ce n’est de limiter le nombre de communications données, en ne prenant plus en compte les “ping” de chaque utilisateur mais seulement les messages d’alertes, ce qui permettrai une bien plus grande gestion de la congestion à un endroit donné. Également, une balise en dessous d’un lien congestionné pourrait communiquer avec ses autres voisins (non-fils dans l’arbre) afin de libérer de l’espace dans le lien avec son père dans l’arbre. Également, le système ne pourra accepter que jusqu’à 1000 utilisateurs par noeud, et également 4000 utilisateurs par cluster (dans le cas d’un réseau avec plusieurs clusters donc plusieurs racines cette limite augmente).

Plusieurs types de paquets circulent sur le réseau de balise:
Les pings, messages envoyés spontanéments à intervalle régulier par les utilisateur contenant l’id ainsi que les deux coordonées gps (27 bits chacun)
Les incidents, identique à un ping mais à priorité haute.
Les alertes, messages brodcastés par le serveur afin d’envoyer un message en chaine de caractères courts et compressés.

=Coûts matériels=

Que ce soit pour le dispositif utilisateur ou la balise (racine ou non), le LoRaOne correspond pour permettre les actions recherchées. Afin de réaliser un prototype pertinent, 6 kits LoRaOne sont requis. Ces kits sont accessibles sur le site de Sodaq au prix de 115€ chacun (prix variable).
Disponible [https://shop.sodaq.com/en/one-eu-rn2483-v2.html ici], voir avant dernier bundle : starter "ONE EU starter" actuellement à 112,10€.

Un [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer buzzer] est à ajouter au dispositif utilisateur afin de lui délivrer un signal sonore.

Un shield GSM est requis pour que la balise racine communique avec l'extérieur. Sodaq en propose un designé pour fonctionner sur leurs produits mais est éctuellement en rupture de stock. Un shield GSM arduino convient tout autant et peut être trouvé sur le site arduino [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna ici].

Aucun boitier ne sera commandé car nous avons fait le choix de les manufacturer nous même au fablab. Le besoin d'étanchéité n'est pas primordial pour notre prototype, bien que nous tenterons de l'assurer.

{|class="récap commande"
|+ Récapitulatif
|-
|
!scope="col" style="width: 320px;"| Produit
!scope="col" style="width: 80px;"| Lien
!scope="col" style="width: 80px;"| Quantité
!scope="col" style="width: 80px;"| Prix Unitaire
|-

!scope="row"| 1
| LoRaOne EU Starter
| [https://shop.sodaq.com/en/one-eu-rn2483-v2.html Achat]
| 6
| 115€
|-

!scope="row"| 2
| Buzzer
| [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer Achat]
| 3
| 5.49€
|-

!scope="row"| 3
| Shield GSM
| [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna Achat]
| 1
| 65€
|-

|}

=Développement=

Nous utiliserons les librairies standards Arduino ainsi que celle de SODAQ/Arduino pour le LoRa.

L'IDE Arduino sera utilisé, plus pratique pour l'utilisation de Git (comparé à Mbed).

= Mise sur le marché =

Ce dispositif a pour but d’être utilisé en montagne, lors de randonnée. Il n’est pas destiné à un usage quotidien, c’est pourquoi nous considérons qu’il est plus judicieux de louer les dispositifs plutôt que de les vendre, même si l’achat n’est pas à omettre de notre stratégie.

Le dispositif peut être commandé en ligne, puis retourné par la poste après usage. Le client louerait le dispositif pour une certaine durée avec un possible nombre supplémentaire de batterie. Les tarifs varient en fonction de la durée et du nombre de batteries louées. Des offres de groupes pourraient être applicables. A long terme, des boutiques pourraient être disséminées dans des grandes villes proches des zones montagneuses, zones à randonnées (Grenoble, Annecy, etc.).

L’application est téléchargeable gratuitement par quiconque, mais utilisable seulement par les clients. Un code d’accès sera envoyé avec le dispositif expirant après la fin de la location.

Il faudra tenir compte de la bande passante du LoRa, variante en fonction des continents.

=Planning prévisonnel=

Sprint 1 : 29/01 --> 09/02 : Création du prototype logiciel #1
*Prise en main du matériel
*Premiers tests de transmissions LoRa
*Création du protocole d'architecture des balises
*Application sur les cartes et tests
*Tests de performances des cartes (durabilité, chargement, batterie)
*Tests de maintenabilité de l'algorithme (déconnexions, latences)

Sprint 2 : 12/02 --> 23/02 : Prototype logiciel #2 et prototype matériel
*Création du programme embarqué (utilisateur)
*Communication avec la racine et le serveur
*Création des maquettes boîtier et balise
*Construction des maquettes
*Finalisation du premier prototype

Sprint 3 : 26/02 --> 09/03 : Fonctionnalités supplémentaires
*Ajout de la communication entre le LoRa et le GSM sur la balise racine
*Création application mobile utilisateur
*Tests sur l'application
*Tests sur la transmission totale depuis l'utilisateur vers le serveur via le GSM
*Finalisation du projet

Sprint 4 : 12/03 --> 16/03 : Fin du projet
*Création de la documentation finale (à partir de la documentation réalisée en continu)
*Pause café
*Temps supplémentaire en cas de problèmes importants
*Préparation de la soutenance

R'Montagne

2018-03-14T09:42:21Z

Hugo.Amodru-Favin: /* Journal */

=Équipe=
{|class="wikitable"
|-
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Rôle
|-
| Hugo Amodru-Favin
| Chef de Projet
|-
| Antoine Delise
| Lead Developer
|-
| Gwenaël Moreau
| Kanban Master
|-

|}

==Tâches==

Répartition générale des tâches
{|class="wikitable"
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Tâche
|-
| Hugo Amodru-Favin
| Application Ionic
|-
| Antoine Delise
| Développement Arduino
|-
| Gwenaël Moreau
| BDD - API
|-

|}

Détail des tâches : [https://waffle.io/delisea/R-Montagne Waffle.io]

=Journal=

{|class="wikitable"
|+
|-
!scope="col" width="120px"| Date
!scope="col" width="300px"| Hugo AMODRU-FAVIN
!scope="col"| Antoine DELISE
!scope="col"| Gwenaël MOREAU
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 1
|-

|-
| rowspan="1" | Lundi 29/01/18
| style="width: 225px;" |
* Ré-assimilation du sujet
| style="width: 225px;" |
* Ré-assimilation du sujet
| style="width: 225px;" |
* Ré-assimilation du sujet
* Mise en place d'un Kanban
|-
| rowspan="1" | Mardi 30/01/18
| style="width: 225px;" |
* Mise à jour de la page AIR
* Réflexions sur l'implémentation du LoRa
| style="width: 225px;" |
* Mise à jour de la page AIR
* Réflexions sur l'implémentation du LoRa
| style="width: 225px;" |
* Mise en place du calendrier prévisionnel
* Définition et répartition des tâches
|-
| rowspan="1" | Mercredi 31/01/18
| style="width: 225px;" |
* Récupération des cartes Semtech
* Présentation du Hackathon Vinci Energies
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Récupération des cartes Semtech
* Présentation du Hackathon
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Récupération et prise en main des cartes Semtech LoRaMote
* Présentation du Hackathon Vinci Energies
|-
| rowspan="1" | Jeudi 01/02/18
| style="width: 225px;" |
* Choix des fonctionnalités de l'application mobile
| style="width: 225px;" |
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Prise en main des cartes LoRa
|-
| rowspan="1" | Vendredi 02/02/18
| style="width: 225px;" |
* Réflexions sur l'implémentation de l'application
* Démarrage de l'application mobile
* Mises à jour d'Ionic, de Android Studio
| style="width: 225px;" |
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Premières communications fructueuses des cartes Semtech LoRaMote
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 2
|-

|-
| rowspan="1" | Lundi 05/02/18
| style="width: 225px;" |
* Configuration Login et Mot de Passe, Identification base
| style="width: 225px;" |
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Réflexion et création de la base de données
|-
| rowspan="1" | Mardi 06/02/18
| style="width: 225px;" |
* Configuration Login, Mot de passe
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
| style="width: 225px;" |
* Création de l'API REST EN PHP
|-
| rowspan="1" | Mercredi 07/02/18
| style="width: 225px;" |
* Réunion avec Rémi CHOLLET et 3 PEIP D
* Assimilation du fonctionnement de Leaflet
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
| style="width: 225px;" |
* Réunion avec Rémi CHOLLET et 3 PEIP D
* Création de l'API REST en PHP
|-
| rowspan="1" | Jeudi 08/02/18
| style="width: 225px;" |
* Ajout de marqueurs sur Leaflet
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
| style="width: 225px;" |
* Création de l'API REST EN PHP
|-
| rowspan="1" | Vendredi 09/02/18
| style="width: 225px;" |
* Hackathon Vinci Energies
| style="width: 225px;" |
* Hackathon Vinci Energies
| style="width: 225px;" |
* Hackathon Vinci Energies
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 3
|-

|-
| rowspan="1" | Lundi 12/02/18
| style="width: 225px;" |
* Préparation Soutenance
| style="width: 225px;" |
* Mise en place d'un Contiki/Cooja pour faciliter le développement
| style="width: 225px;" |
* Préparation Soutenance
|-
| rowspan="1" | Mardi 13/02/18
| style="width: 225px;" |
* Mise à jour de AIR
* Préparation Soutenance
* Répétition soutenance
| style="width: 225px;" |
* Préparation Soutenance
* Répétition soutenance
* Mise en place d'un Contiki/Cooja pour faciliter le dévelloppement
| style="width: 225px;" |
* Préparation Soutenance
* Répétition soutenance
|-
| rowspan="1" | Mercredi 14/02/18
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
|-
| rowspan="1" | Jeudi 15/02/18
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
|-
| rowspan="1" | Vendredi 16/02/18
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 4
|-

|-
| rowspan="1" | Lundi 26/02/18
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Travail sur l'affichage des éléments sur la carte utilisateur
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Travail sur Contiki, création d'un protocole de routage
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Corrections de l'API en accord avec l'application mobile
* Modifications sur la base de données
|-
| rowspan="1" | Mardi 27/02/18
| style="width: 225px;" |
* Création de la page de création d'un nouvel utilisateur
* Design de l'application mobile
| style="width: 225px;" |
* Fin du protocole de routage Contiki, tests virtuels de fonctionnement
| style="width: 225px;" |
* Liaison entre l'application mobile et l'API
|-
| rowspan="1" | Mercredi 28/02/18
| style="width: 225px;" |
* Fin de la page de création d'un nouvel utilisateur
* Ajout de l'utilisation des sessions dans l'application
| style="width: 225px;" |
* Panne ordinateur personnel
* Travail sur l'application mobile avec Hugo
| style="width: 225px;" |
* API : Création d'un utilisateur
* API : Récupération des informations nécessaires pour la carte
* API : Ajout de l'utilisation des sessions pour stocker l'utilisateur connecté
|-
| rowspan="1" | Jeudi 01/03/18
| style="width: 225px;" |
* Affichage des informations sur la carte
| style="width: 225px;" |
* Affichage des informations sur la carte
| style="width: 225px;" |
* API : Récupération des informations nécessaires pour la carte
|-
| rowspan="1" | Vendredi 03/03/18
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Réparation d'ordinateur personnel
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Renseignements sur Swagger
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 5
|-

|-
| rowspan="1" | Lundi 05/03/18
| style="width: 225px;" |
* Ajout de la page de modification d'un utilisateur
* Restructuration de l'application
| style="width: 225px;" |
* Finalisation de la carte, et ajout de la gestion des différentes cartes
* Restructuration de l'application
| style="width: 225px;" |
* Création d'une page Swagger
* Corrections de l'API
* Ajout des cartes dans la base de données
* Récupération des éléments liés à la carte dans l'API
|-
| rowspan="1" | Mardi 06/03/18
| style="width: 225px;" |
* Fin de la modification d'un utilisateur
* Ajout de changement de mot de passe
* Ajout gestion secouriste
| style="width: 225px;" |
* Ajout gestion secouriste
* Création vues côté secouristes
| style="width: 225px;" |
* Fin du Swagger
* API : Modifications utilisateur
* API : Modifications mot de passe
* Base de données : Ajout affectations secouristes-cartes
* API : Récupération des cartes pour un secouriste
|-
| rowspan="1" | Mercredi 07/03/18
| style="width: 225px;" |
* Ajout des notifications
| style="width: 225px;" |
* Corrections du menu et de la navigation
| style="width: 225px;" |
* Journaux sur air.imag.fr
* Programme de récupération des messages à la racine et inscription des données dans la base de données
|-
| rowspan="1" | Jeudi 08/03/18
| style="width: 225px;" |
* Extraction des dents de sagesse
| style="width: 225px;" |
*
| style="width: 225px;" |
* Création du programme de communication LoRa et récupération des coordonnées GPS depuis la carte SodaqONE
* Tests de temps de synchronisation et précision du GPS
|-
| rowspan="1" | Vendredi 09/03/18
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Design du LogoV2, Embellie CSS de l'application mobile
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
*
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Finition du programme de communication LoRa
* Tests d'envoi de la carte SodaqONE vers la base de données en passant par une racine (carte Arduino LoRa)
|-
| rowspan="1" | Samedi 10/03/18
| style="width: 225px;" |
* Réflexions et implémentations des Usercases concernant la gestion des licences
* Ajout de notifications mobiles
* Ajout d'une page liée à la gestion des Trackers
* Poster Anniversaire
| style="width: 225px;" |
* Réflexions et implémentations des Usercases concernant la gestion des licences
| style="width: 225px;" |
* Tests du programme de communication avec les LoRas
|-
| rowspan="1" | Dimanche 11/03/18
| style="width: 225px;" |
*
| style="width: 225px;" |
*
| style="width: 225px;" |
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 6
|-

|-
| rowspan="1" | Lundi 12/03/18
| style="width: 225px;" |
* Ajouts de fonctionnalités dans l'application
| style="width: 225px;" |
* Correctifs programme de communication
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Correctifs programme de communication
|-
| rowspan="1" | Mardi 13/03/18
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Finalisation des fonctionnalités de l'application
* Correctifs des bugs
* Test Réel à la Bastille
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Finalisation des fonctionnalités de l'application
* Correctifs des bugs
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Préparation des capteurs pour le test réel
* Test Réel à la Bastille
|-
| rowspan="1" | Mercredi 14/03/18
| style="width: 225px;" |
* Préparation de la soutenance
* Finalisation du Poster
* Test Réel aux Taillées
| style="width: 225px;" |
* Préparation de la soutenance
* Préparation de la démonstration
* Dernier correctifs de l'application
| style="width: 225px;" |
* Préparation de la soutenance
* Finalisation du Poster
* Test Réel aux Taillées
|-
| rowspan="1" | Jeudi 15/03/18
| style="width: 225px;" |
* Soutenance de Projet
| style="width: 225px;" |
* Soutenance de Projet
| style="width: 225px;" |
* Soutenance de Projet
|}

=Collaboration avec le DUT RT et les PEIPs D=
L'objectif de cette collaboration est de familiariser des étudiants en PEIP D avec des projets qu'ils seront amenés à développer dans les prochaines années. Nous avons rencontré Rémi CHOLLET et 3 étudiants Mercredi 7 Février, en voici un résumé écrit par Mr CHOLLET définissant les contours de cette collaboration.

"Un rapide résumé de la rencontre que nous avons eu ce matin avec le projet R’Montagne.

Présents :
- RCIM5 Gwenael Moreau, Hugo Amodru-Favin
- PEIP-D : Yoann Goma-Missamou, Vincent Cadoux, Philippe Charrat
- IUT : Rémy Chollet, tuteur pédagogique des PEIP-D
Excusés : Didier Donsez, blessé (aie ! courage …), Antoine Delise en cours de marketing

Contexte :
Les PEIP-D participent aux projets RICM5 en prenant une tâche « annexe » (hors chemin critique) en charge. L’objectif est une expérience d’immersion + notation liée au PEIP.

Déroulé :
Les étudiant RCIM5 ont présenté le projet dans son principe et état d’avancement. Les échanges se sont portés sur l’idée de mener une étude (simulation et mesure) sur la consommation des balises par les PEIP-D avec pour objectif de dimensionner la réserve d’énergie.

Ceci implique :
- coté RCIM5 : mise à disposition d’une carte prototype.

- cote PEIP-D : inventaire des paramètres à prendre en compte :
* consommation carte (GPS + puce LoRa) = > veille + temps d’activation (recherche à faire sur le temps de synchronisation du GPS)
* puissance d’émission à calibrer en fonction de la couverture voulue et débit (voir Spread Factor ?)
* temps d’émission-réception (émission jusqu’à acquittement)

- cote PEIP-D : penser la manip pour valider ce modèle
* mesure moyenne du courant
* configuration effective du réseau
* réserver le matériel (voir Jean-Yves Frau au département R&T ?)

- cote PEIP-D : paramètrer les simulations et mesures en fonction de puissance d’émission (ou autre élément pouvant apparaitre comme pertinent)

D’une manière générale, pour les PEID-D :
- penser bibliographie (pour commencer : https://fr.wikipedia.org/wiki/LoRaWAN et aussi https://fr.wikipedia.org/wiki/Format_des_piles_et_accumulateurs_électriques :-) )
- planifier
- communiquer : reporting !!!"

=Description du sujet=

==Randonnée et risques==

Ouvert à tous, la randonnée est un sport et un loisir qui prend de plus en plus d’ampleur de nos jours. Ne nécessitant pas de grands prérequis, des milliers de personnes se lancent en montagne chaque jour, malheureusement parfois sans connaître toutes les mesures de sécurité associées.

En effet, de janvier à juin 2016, en randonnée et en alpinisme, l’Association Nationale pour l’Étude de la Neige et des Avalanches (ANENA) a comptabilisé 21 accidents notables, dont 8 accidents mortels, impliquant 15 décès.

Aujourd’hui, les mesures de sécurités préconisent que chaque groupe de randonneur se doivent de se munir d’un téléphone portable afin d’appeler les secours en cas de problème. Malheureusement, la communication mobile dépendant de la couverture réseau, peu présente en montagne, l’impossibilité de joindre les secours reste un problème.

==Solutions existantes==

La solution la plus répandue, est celle du téléphone à connexion satellite. Ayant une communication vers les satellites, cela permet une couverture réseau beaucoup plus répandue dans les montagnes, partout dans le monde (ou presque). Cependant, les téléphones portables satellitaires coûtent chers, et ne sont pas forcément abordables par la plupart des personnes, surtout celles ne sortant qu’occasionnellement.

[https://fall-alarm.net/ Fall Alarm] est un système de détection de chute sur chantier utilisant les mêmes technologies dont nous avons besoin pour notre projet.

==Quelles zones géographiques ?==

Toutes les zones montagneuses peuvent présenter des zones blanches, démunies de connexion quelconque autre que les connexions satellitaires. Certaines chaînes de montagne comme la Cordillaire des Andes ne présentent aucune connexion possible quelconque.

Dans le cadre de notre projet, nous fonctionnerons essentiellement dans la localisation grenobloise avec l'objectif que notre solution soit applicable partout dans le monde. Une contrainte intervient tout de même étant donnée que la fréquence d'utilisation du LoRa en Europe est de 868MHz, 915MHz en Amérique et 433MHz en Asie.

= Fonctionnalités =

Afin de remplir au mieux ses attentes, le principal objectif de ce dispositif sera premièrement de pouvoir communiquer avec les secours à n’importe quel moment, et surtout n’importe où. De plus, il sera capable de détecter de nombreux cas de détresse de la part de l’usager afin de pouvoir lancer un appel d’urgence sans interaction avec l’usager, au cas où il serait inconscient, ou incapable de lancer un appel manuel.

Grâce aux accéléromètres, le dispositif sera à même de détecter un mouvement brutal du randonneur, ce qui pourrait s’apparenter à une chute. Ils pourront également détecter une position anormale, ou une immobilité prolongée, ce qui déclencherait le dispositif d’urgence automatiquement.

Grâce à des tests réalisés au préalable, le boîtier pourra détecter correctement les chûtes de simples mouvements, afin de ne pas lancer l’appel sans raison valable.

Avant de lancer une alerte automatique, le dispositif émettra un signal auditif et visuel à l’utilisateur quelques secondes auparavant, afin de le prévenir l'émission du signal d’urgence, et de lui proposer de le désactiver sur simple pression d’un bouton, afin d’éviter les communications inutiles.

Également, le randonneur sera à même d'émettre volontairement un appel d’urgence à l’aide du bouton, ce qui permet à tout moment d’appeler de l’aide sans effort. Cela peut permettre également à appeler les secours pour une personne en danger qui ne porterait pas le dispositif.

L’appel au secours se représente par un envoi de coordonnées GPS aux secours, via une communication radio LoRa vers des bornes relais placées au préalables en montagne. Cette communication irait de relai de relai jusqu’au centre de sécurité, d’où le message serait transmis aux secours.

De plus, une application mobile verra le jour afin de connecter tous les utilisateurs du module de sécurité, de les visualiser sur une map, et de partager leurs données. En effet, à chaque incident, l’application mettra à jour la position et de la date de l’accident, afin de permettre aux prochains utilisateurs d’être prévenus. Ils pourraient, s'ils sont à proximité, d'assister la personne en détresse en attendant l'arrivée des secours. Bien évidemment, cette application ne sera accessible uniquement si le smartphone de l'utilisateur est relié à une connexion 4G ou Wi-Fi.

Cette prévention pourrait les sensibiliser aux risques de la montagne, leur permettre d’éviter le secteur mais aussi d’aider les personnes en danger si la distance le permet.

= Exigences =
== Fonctionnelles ==

*Batterie garantie fonctionnelle 1 semaine
*Rechargement possible via le panneau solaire portable
*Dispositif pouvant être allumé et éteint par l'utilisateur
*Alarme s’enclenche automatiquement dès qu'elle est considérée nécessaire, signal sonore
*Utilisateur a la possibilité d’activer/désactiver l’alarme quand il le souhaite
*Lorsque l’alarme est active, l’appareil ne peut s’éteindre
*...

== Non-Fonctionnelles ==

*Résistance : aux chocs, impacts, waterproof (utilisé en permanence en plein air)
*Disponibilité : Appareil de secours -> Doit être au plus possible performant
*Performance : Minimiser les pertes réseaux
*Accessible : Utilisateur pas forcément familier avec des appareils électroniques (facile d’utilisation)
*Fiabilité : Précision du GPS (rayon de 10m), données non-éronnées
*Coût : Le plus faible possible pour vendre le moins cher possible
*Efficacité : Réduire la consommation, utiliser le moins possible les ressources

= Composants =
== LoRaONE ==
Pour le coeur du projet, après avoir cherché et comparés plusieurs modules LoRa, GPS ou encore accéléromètres, nous avons finalement opté pour le projet LoRaONE.

LoRaONE est un projet de SODAQ regroupant plusieurs composants dans une seule et même carte, de taille réduite.

https://www.kickstarter.com/projects/sodaq/loraone-the-lora-iot-development-board

“The one IoT development board to rule them all” --SODAQ

Cette carte regroupe plusieurs capteurs afin de respecter aux mieux nos exigences :

Un émetteur/récepteur LoRa afin de pouvoir communiquer au mieux avec les antennes relai à longue distance

Un module + antenne GPS de bonne précision (< 10m) pour connaître en tout temps notre position, et ainsi faciliter l’arrivée des secours, ainsi que la recherche de l’individu en détresse

Un accéléromètre sur 3 axes afin de pouvoir détecter tout mouvement, vitesse ou rotation dans l’espace, ce qui permet la détection de chutes ou d’arrêt de mouvements

3 LED RGB afin de pouvoir signaler à l’utilisateur un manque de batterie, un signal d’urgence ou plus si nécessaire

Un bouton poussoir pour le signal d’alarme

Un connecteur de charge par panneau solaire, afin de faire durer chaque batterie le plus longtemps possible

Un connecteur micro-USB ainsi que des lignes pour se connecter à une base Arduino si besoin

[[File:LoRaOne.png||400px|Spécifications carte LoRaOne]]

De plus, grâce au starter pack, nous pouvons avoir accès à la base ONEBase qui nous permettrait d’étendre plus loin la facilité d’utilisation du produit :

[[File:LoRaOneBase.png||400px|Spécifications base LoRaOneBase]]

Comme nous pouvons le voir, cette base nous permettra de connecter la batterie ainsi que le panneau solaire qui sont fournis dans le pack.

Nous pourrons également connecter jusqu’à 4 modules supplémentaires.

La batterie fournie aura une capacité de 800 mAh, le panneau solaire fourni pouvant délivrer jusqu’à 500 mW de puissance.

Le total atteint une taille d’environ 10*5 cm, ce qui n’est pas excessif, ce qui le rend aisément portatif sur une jambe ou à la taille.

'''Coût : 115€'''

Ce module pourra également servir d’antenne relai, l'alimentation solaire devrait maintenir le dispositif chargé en permanence. Des tests seront effectués pour savoir si un panneau solaire plus puissant est requis.

== Boîtier ==

Le boîtier sécurisé devant respecter plusieurs exigences, nous pouvons le construire en plastique résistant, ce qui le rendrait léger tout en respectant une rigidité suffisante. Les antennes pourront être placées le long du boîtier, à l’intérieur si la connexion est suffisante, ou à l’extérieur. Dans ce dernier cas les trous réalisés sur le boîtier afin de laisser passer les câbles seront colmatés afin de garantir une étanchéité.

[[File:SchemaBoitier.png||100px|Schéma boitier d'alarme]]

== Balises ==

Afin de remonter les informations transmises par les boitiers, des balises seront mises en places sur la zone à couvrir, leur nombre et leur positions dépendra du terrain (obstacles, dénivelés). On distinguera deux types de balises. Tout d’abord, les balises racines qui permettront une communication GSM afin de faire remonter les données vers le serveur. Viennent ensuite les balises standard qui se contenteront de faire remonter vers leur balise racine associée. L’architecture de liaison des balises est détaillée dans une prochaine partie.

Chaque balise est composée d’une barre de fer pouvant être plantée dans le sol, d’un système de lest afin d’immobiliser la balise, d’un paratonnerre, d’un panneau solaire ainsi que d’un LoraOne et d’une batterie. Les balises racines seront équippée en plus d’un dispositif de communication GSM (téléphone portable, émetteur GSM).

[[File:SchemaBalise.png||150px|Schéma balises d'alarme]]

== Application mobile ==
Une application mobile est téléchargeable par les utilisateurs. Ils peuvent voir les autres utilisateurs présents dans leur zone. Lorsqu’un utilisateur est en position de danger, une notification apparaît si les utilisateurs sont proches de la situation de danger.

Cette application n’est pas directement reliée au dispositif. Elle ne fonctionne qu’avec la connexion du mobile, et est destinée à être un niveau de sécurité supérieur. Un randonneur proche d’une zone de danger pourrait arriver sur place plus rapidement que les secours.

= Communication =

Pour un envoi de position + numéro d’identification (X chiffres) :

*Temps de communication : < 2 s
*Communication régulière, intervalle de 15 minutes

On peut donc au maximum avoir 15 * 60 / 2 = 450 individus pouvant communiquer avec la même antenne relai, donc dans le même cercle d’environ 15 km de diamètre.

On communique donc au minimum 2 secondes sur 15 minutes, donc 1/450 << 1%, le temps de communication est respecté.

En cas de problème, nous pouvons envoyer jusqu’à 9x plus avec la borne sans dépasser le temps de communication autorisé (1%). Donc 1 envoi d’appel d’urgence toutes les 2 minutes environ.

La balise racine peut être directement connectée au serveur, dans ce cas, il n’y a pas de communication GSM nécessaire et pas de Gateway. Si la racine n’est pas directement connectée au serveur, elle devra au minimum garantir une communication GSM (ce qu’elle peut faire, il n’y a pas de Gateway nécessaire) pour remonter l’information vers le serveur, et donc la base de données.

GSM : Si Racine connectée à Serveur -> No GSM + Gateway
Else : GSM + Gateway : LoRa Racine connectée ordi (RaspberryPI) + ordi connecté GSM

= Stabilisation et gestion d’erreurs =

== Choix du routage ==

Notre réseau n'est pas un réseau traditionnel. Les seules communications existantes sont soit une remontée d'information vers la racine soit une innondation d'alerte vers les clients. Pour celà nous avons donc décidé d'utiliser un algorithme de routage simplifié basé uniquement sur un arbre en largeur des balises. Nous rajoutons en option la possibilité de créer plusieurs racines et donc plusieurs arbres dont les racines communiquent par gsm. Nous nous basons sur des papiers de recherches afin de déterminer quel algorithme auto-stabilisant est le plus adapté au système LoRa (Tel que le papier "A self-stabilizing algorithm for constructing breadth-first trees" par Shing-Tsaan Huang, Nian-Shing Chen).

== Stabilisation ==

Afin de gérer la communication de chaque message vers le serveur, nous allons prendre un noeud (balise LoRa) dit “racine” connecté directement au serveur, nous ne nous occuperons pas de la communication au serveur dans cet onglet. Chaque message reçu de la part d’un noeud du système doit être relayé jusqu’à la racine du système afin de communiquer avec les secours (ou serveur simplement).

Pour cela, il faudra assurer que chaque balise LoRa soit connecté au réseau, afin d’avoir au départ un graphe de communication connexe. Par dessus ce graphe, nous allons utiliser un processus silencieux auto-stabilisant qui construira un arbre de parcours en largeur, avec pour racine le noeud “racine” décidé ci-dessus.

Au lancement du système, il faut prévoir un léger temps de stabilisation, qui dépendrait de l’algorithme et de la taille du graphe (nombre de balises). Cependant, après cela, l’algorithme assure un arbre en profondeur minimal qui nous permettrai de communiquer avec la racine le plus rapidement possible, et donc une qualité de service maximale.

== Gestion d’erreurs ==

Dans un réseau comme celui-ci, plusieurs types d’erreurs peuvent se produire :
Délai de communication trop important vers une balise
“Crash” d’une balise de communication
Surpopulation d’une balise ou congestion de messages

Afin de palier au premier type d’incident rencontré, il faut nécessairement qu’à chaque emplacement dans la zone couverte, l’utilisateur soit à même de communiquer avec au minimum 2 balises différentes. Ainsi, dans le cas d’une communication trop longue sur une balise, l’autre aurait de grandes chances de délivrer le message plus rapidement.

Au niveau de la défaillance d’une balise, l’algorithme d’arbre en profondeur nous fournit déjà une solution intégrée grâce à son auto-stabilisation. Dans le cas de déconnexion d’une balise, l’algorithme mettrai à jour automatiquement l’arbre de communication, et n’importe quel message d’alerte émis serait délivré dans un délai raisonnable.

Pour le troisième cas d’erreur, il n’y aurait pas de solution réelle, si ce n’est de limiter le nombre de communications données, en ne prenant plus en compte les “ping” de chaque utilisateur mais seulement les messages d’alertes, ce qui permettrai une bien plus grande gestion de la congestion à un endroit donné. Également, une balise en dessous d’un lien congestionné pourrait communiquer avec ses autres voisins (non-fils dans l’arbre) afin de libérer de l’espace dans le lien avec son père dans l’arbre. Également, le système ne pourra accepter que jusqu’à 1000 utilisateurs par noeud, et également 4000 utilisateurs par cluster (dans le cas d’un réseau avec plusieurs clusters donc plusieurs racines cette limite augmente).

Plusieurs types de paquets circulent sur le réseau de balise:
Les pings, messages envoyés spontanéments à intervalle régulier par les utilisateur contenant l’id ainsi que les deux coordonées gps (27 bits chacun)
Les incidents, identique à un ping mais à priorité haute.
Les alertes, messages brodcastés par le serveur afin d’envoyer un message en chaine de caractères courts et compressés.

=Coûts matériels=

Que ce soit pour le dispositif utilisateur ou la balise (racine ou non), le LoRaOne correspond pour permettre les actions recherchées. Afin de réaliser un prototype pertinent, 6 kits LoRaOne sont requis. Ces kits sont accessibles sur le site de Sodaq au prix de 115€ chacun (prix variable).
Disponible [https://shop.sodaq.com/en/one-eu-rn2483-v2.html ici], voir avant dernier bundle : starter "ONE EU starter" actuellement à 112,10€.

Un [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer buzzer] est à ajouter au dispositif utilisateur afin de lui délivrer un signal sonore.

Un shield GSM est requis pour que la balise racine communique avec l'extérieur. Sodaq en propose un designé pour fonctionner sur leurs produits mais est éctuellement en rupture de stock. Un shield GSM arduino convient tout autant et peut être trouvé sur le site arduino [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna ici].

Aucun boitier ne sera commandé car nous avons fait le choix de les manufacturer nous même au fablab. Le besoin d'étanchéité n'est pas primordial pour notre prototype, bien que nous tenterons de l'assurer.

{|class="récap commande"
|+ Récapitulatif
|-
|
!scope="col" style="width: 320px;"| Produit
!scope="col" style="width: 80px;"| Lien
!scope="col" style="width: 80px;"| Quantité
!scope="col" style="width: 80px;"| Prix Unitaire
|-

!scope="row"| 1
| LoRaOne EU Starter
| [https://shop.sodaq.com/en/one-eu-rn2483-v2.html Achat]
| 6
| 115€
|-

!scope="row"| 2
| Buzzer
| [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer Achat]
| 3
| 5.49€
|-

!scope="row"| 3
| Shield GSM
| [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna Achat]
| 1
| 65€
|-

|}

=Développement=

Nous utiliserons les librairies standards Arduino ainsi que celle de SODAQ/Arduino pour le LoRa.

L'IDE Arduino sera utilisé, plus pratique pour l'utilisation de Git (comparé à Mbed).

= Mise sur le marché =

Ce dispositif a pour but d’être utilisé en montagne, lors de randonnée. Il n’est pas destiné à un usage quotidien, c’est pourquoi nous considérons qu’il est plus judicieux de louer les dispositifs plutôt que de les vendre, même si l’achat n’est pas à omettre de notre stratégie.

Le dispositif peut être commandé en ligne, puis retourné par la poste après usage. Le client louerait le dispositif pour une certaine durée avec un possible nombre supplémentaire de batterie. Les tarifs varient en fonction de la durée et du nombre de batteries louées. Des offres de groupes pourraient être applicables. A long terme, des boutiques pourraient être disséminées dans des grandes villes proches des zones montagneuses, zones à randonnées (Grenoble, Annecy, etc.).

L’application est téléchargeable gratuitement par quiconque, mais utilisable seulement par les clients. Un code d’accès sera envoyé avec le dispositif expirant après la fin de la location.

Il faudra tenir compte de la bande passante du LoRa, variante en fonction des continents.

=Planning prévisonnel=

Sprint 1 : 29/01 --> 09/02 : Création du prototype logiciel #1
*Prise en main du matériel
*Premiers tests de transmissions LoRa
*Création du protocole d'architecture des balises
*Application sur les cartes et tests
*Tests de performances des cartes (durabilité, chargement, batterie)
*Tests de maintenabilité de l'algorithme (déconnexions, latences)

Sprint 2 : 12/02 --> 23/02 : Prototype logiciel #2 et prototype matériel
*Création du programme embarqué (utilisateur)
*Communication avec la racine et le serveur
*Création des maquettes boîtier et balise
*Construction des maquettes
*Finalisation du premier prototype

Sprint 3 : 26/02 --> 09/03 : Fonctionnalités supplémentaires
*Ajout de la communication entre le LoRa et le GSM sur la balise racine
*Création application mobile utilisateur
*Tests sur l'application
*Tests sur la transmission totale depuis l'utilisateur vers le serveur via le GSM
*Finalisation du projet

Sprint 4 : 12/03 --> 16/03 : Fin du projet
*Création de la documentation finale (à partir de la documentation réalisée en continu)
*Pause café
*Temps supplémentaire en cas de problèmes importants
*Préparation de la soutenance

R'Montagne

2018-03-14T09:39:45Z

Hugo.Amodru-Favin: /* Journal */

=Équipe=
{|class="wikitable"
|-
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Rôle
|-
| Hugo Amodru-Favin
| Chef de Projet
|-
| Antoine Delise
| Lead Developer
|-
| Gwenaël Moreau
| Kanban Master
|-

|}

==Tâches==

Répartition générale des tâches
{|class="wikitable"
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Tâche
|-
| Hugo Amodru-Favin
| Application Ionic
|-
| Antoine Delise
| Développement Arduino
|-
| Gwenaël Moreau
| BDD - API
|-

|}

Détail des tâches : [https://waffle.io/delisea/R-Montagne Waffle.io]

=Journal=

{|class="wikitable"
|+
|-
!scope="col" width="120px"| Date
!scope="col"| Hugo AMODRU-FAVIN
!scope="col"| Antoine DELISE
!scope="col"| Gwenaël MOREAU
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 1
|-

|-
| rowspan="1" | Lundi 29/01/18
| style="width: 225px;" |
* Ré-assimilation du sujet
| style="width: 225px;" |
* Ré-assimilation du sujet
| style="width: 225px;" |
* Ré-assimilation du sujet
* Mise en place d'un Kanban
|-
| rowspan="1" | Mardi 30/01/18
| style="width: 225px;" |
* Mise à jour de la page AIR
* Réflexions sur l'implémentation du LoRa
| style="width: 225px;" |
* Mise à jour de la page AIR
* Réflexions sur l'implémentation du LoRa
| style="width: 225px;" |
* Mise en place du calendrier prévisionnel
* Définition et répartition des tâches
|-
| rowspan="1" | Mercredi 31/01/18
| style="width: 225px;" |
* Récupération des cartes Semtech
* Présentation du Hackathon Vinci Energies
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Récupération des cartes Semtech
* Présentation du Hackathon
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Récupération et prise en main des cartes Semtech LoRaMote
* Présentation du Hackathon Vinci Energies
|-
| rowspan="1" | Jeudi 01/02/18
| style="width: 225px;" |
* Choix des fonctionnalités de l'application mobile
| style="width: 225px;" |
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Prise en main des cartes LoRa
|-
| rowspan="1" | Vendredi 02/02/18
| style="width: 225px;" |
* Réflexions sur l'implémentation de l'application
* Démarrage de l'application mobile
* Mises à jour d'Ionic, de Android Studio
| style="width: 225px;" |
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Premières communications fructueuses des cartes Semtech LoRaMote
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 2
|-

|-
| rowspan="1" | Lundi 05/02/18
| style="width: 225px;" |
* Configuration Login et Mot de Passe, Identification base
| style="width: 225px;" |
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Réflexion et création de la base de données
|-
| rowspan="1" | Mardi 06/02/18
| style="width: 225px;" |
* Configuration Login, Mot de passe
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
| style="width: 225px;" |
* Création de l'API REST EN PHP
|-
| rowspan="1" | Mercredi 07/02/18
| style="width: 225px;" |
* Réunion avec Rémi CHOLLET et 3 PEIP D
* Assimilation du fonctionnement de Leaflet
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
| style="width: 225px;" |
* Réunion avec Rémi CHOLLET et 3 PEIP D
* Création de l'API REST en PHP
|-
| rowspan="1" | Jeudi 08/02/18
| style="width: 225px;" |
* Ajout de marqueurs sur Leaflet
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
| style="width: 225px;" |
* Création de l'API REST EN PHP
|-
| rowspan="1" | Vendredi 09/02/18
| style="width: 225px;" |
* Hackathon Vinci Energies
| style="width: 225px;" |
* Hackathon Vinci Energies
| style="width: 225px;" |
* Hackathon Vinci Energies
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 3
|-

|-
| rowspan="1" | Lundi 12/02/18
| style="width: 225px;" |
* Préparation Soutenance
| style="width: 225px;" |
* Mise en place d'un Contiki/Cooja pour faciliter le développement
| style="width: 225px;" |
* Préparation Soutenance
|-
| rowspan="1" | Mardi 13/02/18
| style="width: 225px;" |
* Mise à jour de AIR
* Préparation Soutenance
* Répétition soutenance
| style="width: 225px;" |
* Préparation Soutenance
* Répétition soutenance
* Mise en place d'un Contiki/Cooja pour faciliter le dévelloppement
| style="width: 225px;" |
* Préparation Soutenance
* Répétition soutenance
|-
| rowspan="1" | Mercredi 14/02/18
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
|-
| rowspan="1" | Jeudi 15/02/18
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
|-
| rowspan="1" | Vendredi 16/02/18
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 4
|-

|-
| rowspan="1" | Lundi 26/02/18
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Travail sur l'affichage des éléments sur la carte utilisateur
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Travail sur Contiki, création d'un protocole de routage
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Corrections de l'API en accord avec l'application mobile
* Modifications sur la base de données
|-
| rowspan="1" | Mardi 27/02/18
| style="width: 225px;" |
* Création de la page de création d'un nouvel utilisateur
* Design de l'application mobile
| style="width: 225px;" |
* Fin du protocole de routage Contiki, tests virtuels de fonctionnement
| style="width: 225px;" |
* Liaison entre l'application mobile et l'API
|-
| rowspan="1" | Mercredi 28/02/18
| style="width: 225px;" |
* Fin de la page de création d'un nouvel utilisateur
* Ajout de l'utilisation des sessions dans l'application
| style="width: 225px;" |
* Panne ordinateur personnel
* Travail sur l'application mobile avec Hugo
| style="width: 225px;" |
* API : Création d'un utilisateur
* API : Récupération des informations nécessaires pour la carte
* API : Ajout de l'utilisation des sessions pour stocker l'utilisateur connecté
|-
| rowspan="1" | Jeudi 01/03/18
| style="width: 225px;" |
* Affichage des informations sur la carte
| style="width: 225px;" |
* Affichage des informations sur la carte
| style="width: 225px;" |
* API : Récupération des informations nécessaires pour la carte
|-
| rowspan="1" | Vendredi 03/03/18
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Réparation d'ordinateur personnel
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Renseignements sur Swagger
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 5
|-

|-
| rowspan="1" | Lundi 05/03/18
| style="width: 225px;" |
* Ajout de la page de modification d'un utilisateur
* Restructuration de l'application
| style="width: 225px;" |
* Finalisation de la carte, et ajout de la gestion des différentes cartes
* Restructuration de l'application
| style="width: 225px;" |
* Création d'une page Swagger
* Corrections de l'API
* Ajout des cartes dans la base de données
* Récupération des éléments liés à la carte dans l'API
|-
| rowspan="1" | Mardi 06/03/18
| style="width: 225px;" |
* Fin de la modification d'un utilisateur
* Ajout de changement de mot de passe
* Ajout gestion secouriste
| style="width: 225px;" |
* Ajout gestion secouriste
* Création vues côté secouristes
| style="width: 225px;" |
* Fin du Swagger
* API : Modifications utilisateur
* API : Modifications mot de passe
* Base de données : Ajout affectations secouristes-cartes
* API : Récupération des cartes pour un secouriste
|-
| rowspan="1" | Mercredi 07/03/18
| style="width: 225px;" |
* Ajout des notifications
| style="width: 225px;" |
* Corrections du menu et de la navigation
| style="width: 225px;" |
* Journaux sur air.imag.fr
* Programme de récupération des messages à la racine et inscription des données dans la base de données
|-
| rowspan="1" | Jeudi 08/03/18
| style="width: 225px;" |
* Extraction des dents de sagesse
| style="width: 225px;" |
*
| style="width: 225px;" |
* Création du programme de communication LoRa et récupération des coordonnées GPS depuis la carte SodaqONE
* Tests de temps de synchronisation et précision du GPS
|-
| rowspan="1" | Vendredi 09/03/18
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Design du LogoV2, Embellie CSS de l'application mobile
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
*
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Finition du programme de communication LoRa
* Tests d'envoi de la carte SodaqONE vers la base de données en passant par une racine (carte Arduino LoRa)
|-
| rowspan="1" | Samedi 10/03/18
| style="width: 225px;" |
* Réflexions et implémentations des Usercases concernant la gestion des licences
* Ajout de notifications mobiles
* Ajout d'une page liée à la gestion des Trackers
* Poster Anniversaire
| style="width: 225px;" |
* Réflexions et implémentations des Usercases concernant la gestion des licences
| style="width: 225px;" |
* Tests du programme de communication avec les LoRas
|-
| rowspan="1" | Dimanche 11/03/18
| style="width: 225px;" |
*
| style="width: 225px;" |
*
| style="width: 225px;" |
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 6
|-

|-
| rowspan="1" | Lundi 12/03/18
| style="width: 225px;" |
* Ajouts de fonctionnalités dans l'application
| style="width: 225px;" |
* Correctifs programme de communication
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Correctifs programme de communication
|-
| rowspan="1" | Mardi 13/03/18
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Finalisation des fonctionnalités de l'application
* Correctifs des bugs
* Test Réel à la Bastille
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Finalisation des fonctionnalités de l'application
* Correctifs des bugs
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
* Préparation des capteurs pour le test réel
* Test Réel à la Bastille
|-
| rowspan="1" | Mercredi 14/03/18
| style="width: 225px;" |
* Préparation de la soutenance
* Finalisation du Poster
* Test Réel aux Taillées
| style="width: 225px;" |
* Préparation de la soutenance
* Préparation de la démonstration
* Dernier correctifs de l'application
| style="width: 225px;" |
* Préparation de la soutenance
* Finalisation du Poster
* Test Réel aux Taillées
|-
| rowspan="1" | Jeudi 15/03/18
| style="width: 225px;" |
* Soutenance de Projet
| style="width: 225px;" |
* Soutenance de Projet
| style="width: 225px;" |
* Soutenance de Projet
|}

=Collaboration avec le DUT RT et les PEIPs D=
L'objectif de cette collaboration est de familiariser des étudiants en PEIP D avec des projets qu'ils seront amenés à développer dans les prochaines années. Nous avons rencontré Rémi CHOLLET et 3 étudiants Mercredi 7 Février, en voici un résumé écrit par Mr CHOLLET définissant les contours de cette collaboration.

"Un rapide résumé de la rencontre que nous avons eu ce matin avec le projet R’Montagne.

Présents :
- RCIM5 Gwenael Moreau, Hugo Amodru-Favin
- PEIP-D : Yoann Goma-Missamou, Vincent Cadoux, Philippe Charrat
- IUT : Rémy Chollet, tuteur pédagogique des PEIP-D
Excusés : Didier Donsez, blessé (aie ! courage …), Antoine Delise en cours de marketing

Contexte :
Les PEIP-D participent aux projets RICM5 en prenant une tâche « annexe » (hors chemin critique) en charge. L’objectif est une expérience d’immersion + notation liée au PEIP.

Déroulé :
Les étudiant RCIM5 ont présenté le projet dans son principe et état d’avancement. Les échanges se sont portés sur l’idée de mener une étude (simulation et mesure) sur la consommation des balises par les PEIP-D avec pour objectif de dimensionner la réserve d’énergie.

Ceci implique :
- coté RCIM5 : mise à disposition d’une carte prototype.

- cote PEIP-D : inventaire des paramètres à prendre en compte :
* consommation carte (GPS + puce LoRa) = > veille + temps d’activation (recherche à faire sur le temps de synchronisation du GPS)
* puissance d’émission à calibrer en fonction de la couverture voulue et débit (voir Spread Factor ?)
* temps d’émission-réception (émission jusqu’à acquittement)

- cote PEIP-D : penser la manip pour valider ce modèle
* mesure moyenne du courant
* configuration effective du réseau
* réserver le matériel (voir Jean-Yves Frau au département R&T ?)

- cote PEIP-D : paramètrer les simulations et mesures en fonction de puissance d’émission (ou autre élément pouvant apparaitre comme pertinent)

D’une manière générale, pour les PEID-D :
- penser bibliographie (pour commencer : https://fr.wikipedia.org/wiki/LoRaWAN et aussi https://fr.wikipedia.org/wiki/Format_des_piles_et_accumulateurs_électriques :-) )
- planifier
- communiquer : reporting !!!"

=Description du sujet=

==Randonnée et risques==

Ouvert à tous, la randonnée est un sport et un loisir qui prend de plus en plus d’ampleur de nos jours. Ne nécessitant pas de grands prérequis, des milliers de personnes se lancent en montagne chaque jour, malheureusement parfois sans connaître toutes les mesures de sécurité associées.

En effet, de janvier à juin 2016, en randonnée et en alpinisme, l’Association Nationale pour l’Étude de la Neige et des Avalanches (ANENA) a comptabilisé 21 accidents notables, dont 8 accidents mortels, impliquant 15 décès.

Aujourd’hui, les mesures de sécurités préconisent que chaque groupe de randonneur se doivent de se munir d’un téléphone portable afin d’appeler les secours en cas de problème. Malheureusement, la communication mobile dépendant de la couverture réseau, peu présente en montagne, l’impossibilité de joindre les secours reste un problème.

==Solutions existantes==

La solution la plus répandue, est celle du téléphone à connexion satellite. Ayant une communication vers les satellites, cela permet une couverture réseau beaucoup plus répandue dans les montagnes, partout dans le monde (ou presque). Cependant, les téléphones portables satellitaires coûtent chers, et ne sont pas forcément abordables par la plupart des personnes, surtout celles ne sortant qu’occasionnellement.

[https://fall-alarm.net/ Fall Alarm] est un système de détection de chute sur chantier utilisant les mêmes technologies dont nous avons besoin pour notre projet.

==Quelles zones géographiques ?==

Toutes les zones montagneuses peuvent présenter des zones blanches, démunies de connexion quelconque autre que les connexions satellitaires. Certaines chaînes de montagne comme la Cordillaire des Andes ne présentent aucune connexion possible quelconque.

Dans le cadre de notre projet, nous fonctionnerons essentiellement dans la localisation grenobloise avec l'objectif que notre solution soit applicable partout dans le monde. Une contrainte intervient tout de même étant donnée que la fréquence d'utilisation du LoRa en Europe est de 868MHz, 915MHz en Amérique et 433MHz en Asie.

= Fonctionnalités =

Afin de remplir au mieux ses attentes, le principal objectif de ce dispositif sera premièrement de pouvoir communiquer avec les secours à n’importe quel moment, et surtout n’importe où. De plus, il sera capable de détecter de nombreux cas de détresse de la part de l’usager afin de pouvoir lancer un appel d’urgence sans interaction avec l’usager, au cas où il serait inconscient, ou incapable de lancer un appel manuel.

Grâce aux accéléromètres, le dispositif sera à même de détecter un mouvement brutal du randonneur, ce qui pourrait s’apparenter à une chute. Ils pourront également détecter une position anormale, ou une immobilité prolongée, ce qui déclencherait le dispositif d’urgence automatiquement.

Grâce à des tests réalisés au préalable, le boîtier pourra détecter correctement les chûtes de simples mouvements, afin de ne pas lancer l’appel sans raison valable.

Avant de lancer une alerte automatique, le dispositif émettra un signal auditif et visuel à l’utilisateur quelques secondes auparavant, afin de le prévenir l'émission du signal d’urgence, et de lui proposer de le désactiver sur simple pression d’un bouton, afin d’éviter les communications inutiles.

Également, le randonneur sera à même d'émettre volontairement un appel d’urgence à l’aide du bouton, ce qui permet à tout moment d’appeler de l’aide sans effort. Cela peut permettre également à appeler les secours pour une personne en danger qui ne porterait pas le dispositif.

L’appel au secours se représente par un envoi de coordonnées GPS aux secours, via une communication radio LoRa vers des bornes relais placées au préalables en montagne. Cette communication irait de relai de relai jusqu’au centre de sécurité, d’où le message serait transmis aux secours.

De plus, une application mobile verra le jour afin de connecter tous les utilisateurs du module de sécurité, de les visualiser sur une map, et de partager leurs données. En effet, à chaque incident, l’application mettra à jour la position et de la date de l’accident, afin de permettre aux prochains utilisateurs d’être prévenus. Ils pourraient, s'ils sont à proximité, d'assister la personne en détresse en attendant l'arrivée des secours. Bien évidemment, cette application ne sera accessible uniquement si le smartphone de l'utilisateur est relié à une connexion 4G ou Wi-Fi.

Cette prévention pourrait les sensibiliser aux risques de la montagne, leur permettre d’éviter le secteur mais aussi d’aider les personnes en danger si la distance le permet.

= Exigences =
== Fonctionnelles ==

*Batterie garantie fonctionnelle 1 semaine
*Rechargement possible via le panneau solaire portable
*Dispositif pouvant être allumé et éteint par l'utilisateur
*Alarme s’enclenche automatiquement dès qu'elle est considérée nécessaire, signal sonore
*Utilisateur a la possibilité d’activer/désactiver l’alarme quand il le souhaite
*Lorsque l’alarme est active, l’appareil ne peut s’éteindre
*...

== Non-Fonctionnelles ==

*Résistance : aux chocs, impacts, waterproof (utilisé en permanence en plein air)
*Disponibilité : Appareil de secours -> Doit être au plus possible performant
*Performance : Minimiser les pertes réseaux
*Accessible : Utilisateur pas forcément familier avec des appareils électroniques (facile d’utilisation)
*Fiabilité : Précision du GPS (rayon de 10m), données non-éronnées
*Coût : Le plus faible possible pour vendre le moins cher possible
*Efficacité : Réduire la consommation, utiliser le moins possible les ressources

= Composants =
== LoRaONE ==
Pour le coeur du projet, après avoir cherché et comparés plusieurs modules LoRa, GPS ou encore accéléromètres, nous avons finalement opté pour le projet LoRaONE.

LoRaONE est un projet de SODAQ regroupant plusieurs composants dans une seule et même carte, de taille réduite.

https://www.kickstarter.com/projects/sodaq/loraone-the-lora-iot-development-board

“The one IoT development board to rule them all” --SODAQ

Cette carte regroupe plusieurs capteurs afin de respecter aux mieux nos exigences :

Un émetteur/récepteur LoRa afin de pouvoir communiquer au mieux avec les antennes relai à longue distance

Un module + antenne GPS de bonne précision (< 10m) pour connaître en tout temps notre position, et ainsi faciliter l’arrivée des secours, ainsi que la recherche de l’individu en détresse

Un accéléromètre sur 3 axes afin de pouvoir détecter tout mouvement, vitesse ou rotation dans l’espace, ce qui permet la détection de chutes ou d’arrêt de mouvements

3 LED RGB afin de pouvoir signaler à l’utilisateur un manque de batterie, un signal d’urgence ou plus si nécessaire

Un bouton poussoir pour le signal d’alarme

Un connecteur de charge par panneau solaire, afin de faire durer chaque batterie le plus longtemps possible

Un connecteur micro-USB ainsi que des lignes pour se connecter à une base Arduino si besoin

[[File:LoRaOne.png||400px|Spécifications carte LoRaOne]]

De plus, grâce au starter pack, nous pouvons avoir accès à la base ONEBase qui nous permettrait d’étendre plus loin la facilité d’utilisation du produit :

[[File:LoRaOneBase.png||400px|Spécifications base LoRaOneBase]]

Comme nous pouvons le voir, cette base nous permettra de connecter la batterie ainsi que le panneau solaire qui sont fournis dans le pack.

Nous pourrons également connecter jusqu’à 4 modules supplémentaires.

La batterie fournie aura une capacité de 800 mAh, le panneau solaire fourni pouvant délivrer jusqu’à 500 mW de puissance.

Le total atteint une taille d’environ 10*5 cm, ce qui n’est pas excessif, ce qui le rend aisément portatif sur une jambe ou à la taille.

'''Coût : 115€'''

Ce module pourra également servir d’antenne relai, l'alimentation solaire devrait maintenir le dispositif chargé en permanence. Des tests seront effectués pour savoir si un panneau solaire plus puissant est requis.

== Boîtier ==

Le boîtier sécurisé devant respecter plusieurs exigences, nous pouvons le construire en plastique résistant, ce qui le rendrait léger tout en respectant une rigidité suffisante. Les antennes pourront être placées le long du boîtier, à l’intérieur si la connexion est suffisante, ou à l’extérieur. Dans ce dernier cas les trous réalisés sur le boîtier afin de laisser passer les câbles seront colmatés afin de garantir une étanchéité.

[[File:SchemaBoitier.png||100px|Schéma boitier d'alarme]]

== Balises ==

Afin de remonter les informations transmises par les boitiers, des balises seront mises en places sur la zone à couvrir, leur nombre et leur positions dépendra du terrain (obstacles, dénivelés). On distinguera deux types de balises. Tout d’abord, les balises racines qui permettront une communication GSM afin de faire remonter les données vers le serveur. Viennent ensuite les balises standard qui se contenteront de faire remonter vers leur balise racine associée. L’architecture de liaison des balises est détaillée dans une prochaine partie.

Chaque balise est composée d’une barre de fer pouvant être plantée dans le sol, d’un système de lest afin d’immobiliser la balise, d’un paratonnerre, d’un panneau solaire ainsi que d’un LoraOne et d’une batterie. Les balises racines seront équippée en plus d’un dispositif de communication GSM (téléphone portable, émetteur GSM).

[[File:SchemaBalise.png||150px|Schéma balises d'alarme]]

== Application mobile ==
Une application mobile est téléchargeable par les utilisateurs. Ils peuvent voir les autres utilisateurs présents dans leur zone. Lorsqu’un utilisateur est en position de danger, une notification apparaît si les utilisateurs sont proches de la situation de danger.

Cette application n’est pas directement reliée au dispositif. Elle ne fonctionne qu’avec la connexion du mobile, et est destinée à être un niveau de sécurité supérieur. Un randonneur proche d’une zone de danger pourrait arriver sur place plus rapidement que les secours.

= Communication =

Pour un envoi de position + numéro d’identification (X chiffres) :

*Temps de communication : < 2 s
*Communication régulière, intervalle de 15 minutes

On peut donc au maximum avoir 15 * 60 / 2 = 450 individus pouvant communiquer avec la même antenne relai, donc dans le même cercle d’environ 15 km de diamètre.

On communique donc au minimum 2 secondes sur 15 minutes, donc 1/450 << 1%, le temps de communication est respecté.

En cas de problème, nous pouvons envoyer jusqu’à 9x plus avec la borne sans dépasser le temps de communication autorisé (1%). Donc 1 envoi d’appel d’urgence toutes les 2 minutes environ.

La balise racine peut être directement connectée au serveur, dans ce cas, il n’y a pas de communication GSM nécessaire et pas de Gateway. Si la racine n’est pas directement connectée au serveur, elle devra au minimum garantir une communication GSM (ce qu’elle peut faire, il n’y a pas de Gateway nécessaire) pour remonter l’information vers le serveur, et donc la base de données.

GSM : Si Racine connectée à Serveur -> No GSM + Gateway
Else : GSM + Gateway : LoRa Racine connectée ordi (RaspberryPI) + ordi connecté GSM

= Stabilisation et gestion d’erreurs =

== Choix du routage ==

Notre réseau n'est pas un réseau traditionnel. Les seules communications existantes sont soit une remontée d'information vers la racine soit une innondation d'alerte vers les clients. Pour celà nous avons donc décidé d'utiliser un algorithme de routage simplifié basé uniquement sur un arbre en largeur des balises. Nous rajoutons en option la possibilité de créer plusieurs racines et donc plusieurs arbres dont les racines communiquent par gsm. Nous nous basons sur des papiers de recherches afin de déterminer quel algorithme auto-stabilisant est le plus adapté au système LoRa (Tel que le papier "A self-stabilizing algorithm for constructing breadth-first trees" par Shing-Tsaan Huang, Nian-Shing Chen).

== Stabilisation ==

Afin de gérer la communication de chaque message vers le serveur, nous allons prendre un noeud (balise LoRa) dit “racine” connecté directement au serveur, nous ne nous occuperons pas de la communication au serveur dans cet onglet. Chaque message reçu de la part d’un noeud du système doit être relayé jusqu’à la racine du système afin de communiquer avec les secours (ou serveur simplement).

Pour cela, il faudra assurer que chaque balise LoRa soit connecté au réseau, afin d’avoir au départ un graphe de communication connexe. Par dessus ce graphe, nous allons utiliser un processus silencieux auto-stabilisant qui construira un arbre de parcours en largeur, avec pour racine le noeud “racine” décidé ci-dessus.

Au lancement du système, il faut prévoir un léger temps de stabilisation, qui dépendrait de l’algorithme et de la taille du graphe (nombre de balises). Cependant, après cela, l’algorithme assure un arbre en profondeur minimal qui nous permettrai de communiquer avec la racine le plus rapidement possible, et donc une qualité de service maximale.

== Gestion d’erreurs ==

Dans un réseau comme celui-ci, plusieurs types d’erreurs peuvent se produire :
Délai de communication trop important vers une balise
“Crash” d’une balise de communication
Surpopulation d’une balise ou congestion de messages

Afin de palier au premier type d’incident rencontré, il faut nécessairement qu’à chaque emplacement dans la zone couverte, l’utilisateur soit à même de communiquer avec au minimum 2 balises différentes. Ainsi, dans le cas d’une communication trop longue sur une balise, l’autre aurait de grandes chances de délivrer le message plus rapidement.

Au niveau de la défaillance d’une balise, l’algorithme d’arbre en profondeur nous fournit déjà une solution intégrée grâce à son auto-stabilisation. Dans le cas de déconnexion d’une balise, l’algorithme mettrai à jour automatiquement l’arbre de communication, et n’importe quel message d’alerte émis serait délivré dans un délai raisonnable.

Pour le troisième cas d’erreur, il n’y aurait pas de solution réelle, si ce n’est de limiter le nombre de communications données, en ne prenant plus en compte les “ping” de chaque utilisateur mais seulement les messages d’alertes, ce qui permettrai une bien plus grande gestion de la congestion à un endroit donné. Également, une balise en dessous d’un lien congestionné pourrait communiquer avec ses autres voisins (non-fils dans l’arbre) afin de libérer de l’espace dans le lien avec son père dans l’arbre. Également, le système ne pourra accepter que jusqu’à 1000 utilisateurs par noeud, et également 4000 utilisateurs par cluster (dans le cas d’un réseau avec plusieurs clusters donc plusieurs racines cette limite augmente).

Plusieurs types de paquets circulent sur le réseau de balise:
Les pings, messages envoyés spontanéments à intervalle régulier par les utilisateur contenant l’id ainsi que les deux coordonées gps (27 bits chacun)
Les incidents, identique à un ping mais à priorité haute.
Les alertes, messages brodcastés par le serveur afin d’envoyer un message en chaine de caractères courts et compressés.

=Coûts matériels=

Que ce soit pour le dispositif utilisateur ou la balise (racine ou non), le LoRaOne correspond pour permettre les actions recherchées. Afin de réaliser un prototype pertinent, 6 kits LoRaOne sont requis. Ces kits sont accessibles sur le site de Sodaq au prix de 115€ chacun (prix variable).
Disponible [https://shop.sodaq.com/en/one-eu-rn2483-v2.html ici], voir avant dernier bundle : starter "ONE EU starter" actuellement à 112,10€.

Un [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer buzzer] est à ajouter au dispositif utilisateur afin de lui délivrer un signal sonore.

Un shield GSM est requis pour que la balise racine communique avec l'extérieur. Sodaq en propose un designé pour fonctionner sur leurs produits mais est éctuellement en rupture de stock. Un shield GSM arduino convient tout autant et peut être trouvé sur le site arduino [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna ici].

Aucun boitier ne sera commandé car nous avons fait le choix de les manufacturer nous même au fablab. Le besoin d'étanchéité n'est pas primordial pour notre prototype, bien que nous tenterons de l'assurer.

{|class="récap commande"
|+ Récapitulatif
|-
|
!scope="col" style="width: 320px;"| Produit
!scope="col" style="width: 80px;"| Lien
!scope="col" style="width: 80px;"| Quantité
!scope="col" style="width: 80px;"| Prix Unitaire
|-

!scope="row"| 1
| LoRaOne EU Starter
| [https://shop.sodaq.com/en/one-eu-rn2483-v2.html Achat]
| 6
| 115€
|-

!scope="row"| 2
| Buzzer
| [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer Achat]
| 3
| 5.49€
|-

!scope="row"| 3
| Shield GSM
| [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna Achat]
| 1
| 65€
|-

|}

=Développement=

Nous utiliserons les librairies standards Arduino ainsi que celle de SODAQ/Arduino pour le LoRa.

L'IDE Arduino sera utilisé, plus pratique pour l'utilisation de Git (comparé à Mbed).

= Mise sur le marché =

Ce dispositif a pour but d’être utilisé en montagne, lors de randonnée. Il n’est pas destiné à un usage quotidien, c’est pourquoi nous considérons qu’il est plus judicieux de louer les dispositifs plutôt que de les vendre, même si l’achat n’est pas à omettre de notre stratégie.

Le dispositif peut être commandé en ligne, puis retourné par la poste après usage. Le client louerait le dispositif pour une certaine durée avec un possible nombre supplémentaire de batterie. Les tarifs varient en fonction de la durée et du nombre de batteries louées. Des offres de groupes pourraient être applicables. A long terme, des boutiques pourraient être disséminées dans des grandes villes proches des zones montagneuses, zones à randonnées (Grenoble, Annecy, etc.).

L’application est téléchargeable gratuitement par quiconque, mais utilisable seulement par les clients. Un code d’accès sera envoyé avec le dispositif expirant après la fin de la location.

Il faudra tenir compte de la bande passante du LoRa, variante en fonction des continents.

=Planning prévisonnel=

Sprint 1 : 29/01 --> 09/02 : Création du prototype logiciel #1
*Prise en main du matériel
*Premiers tests de transmissions LoRa
*Création du protocole d'architecture des balises
*Application sur les cartes et tests
*Tests de performances des cartes (durabilité, chargement, batterie)
*Tests de maintenabilité de l'algorithme (déconnexions, latences)

Sprint 2 : 12/02 --> 23/02 : Prototype logiciel #2 et prototype matériel
*Création du programme embarqué (utilisateur)
*Communication avec la racine et le serveur
*Création des maquettes boîtier et balise
*Construction des maquettes
*Finalisation du premier prototype

Sprint 3 : 26/02 --> 09/03 : Fonctionnalités supplémentaires
*Ajout de la communication entre le LoRa et le GSM sur la balise racine
*Création application mobile utilisateur
*Tests sur l'application
*Tests sur la transmission totale depuis l'utilisateur vers le serveur via le GSM
*Finalisation du projet

Sprint 4 : 12/03 --> 16/03 : Fin du projet
*Création de la documentation finale (à partir de la documentation réalisée en continu)
*Pause café
*Temps supplémentaire en cas de problèmes importants
*Préparation de la soutenance

R'Montagne

2018-03-12T14:13:41Z

Hugo.Amodru-Favin: /* Journal */

=Équipe=
{|class="wikitable"
|-
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Rôle
|-
| Hugo Amodru-Favin
| Chef de Projet
|-
| Antoine Delise
| Lead Developer
|-
| Gwenaël Moreau
| Kanban Master
|-

|}

==Tâches==

Répartition générale des tâches
{|class="wikitable"
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Tâche
|-
| Hugo Amodru-Favin
| Application Ionic
|-
| Antoine Delise
| Développement Arduino
|-
| Gwenaël Moreau
| BDD - API
|-

|}

Détail des tâches : [https://waffle.io/delisea/R-Montagne Waffle.io]

=Journal=

{|class="wikitable"
|+
|-
!scope="col" width="120px"| Date
!scope="col"| Hugo AMODRU-FAVIN
!scope="col"| Antoine DELISE
!scope="col"| Gwenaël MOREAU
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 1
|-

|-
| rowspan="1" | Lundi 29/01/18
| style="width: 225px;" |
* Ré-assimilation du sujet
| style="width: 225px;" |
* Ré-assimilation du sujet
| style="width: 225px;" |
* Ré-assimilation du sujet
* Mise en place d'un Kanban
|-
| rowspan="1" | Mardi 30/01/18
| style="width: 225px;" |
* Mise à jour de la page AIR
* Réflexions sur l'implémentation du LoRa
| style="width: 225px;" |
* Mise à jour de la page AIR
* Réflexions sur l'implémentation du LoRa
| style="width: 225px;" |
* Mise en place du calendrier prévisionnel
* Définition et répartition des tâches
|-
| rowspan="1" | Mercredi 31/01/18
| style="width: 225px;" |
* Récupération des cartes Semtech
* Présentation du Hackathon Vinci Energies
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Récupération des cartes Semtech
* Présentation du Hackathon
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Récupération et prise en main des cartes Semtech LoRaMote
* Présentation du Hackathon Vinci Energies
|-
| rowspan="1" | Jeudi 01/02/18
| style="width: 225px;" |
* Choix des fonctionnalités de l'application mobile
| style="width: 225px;" |
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Prise en main des cartes LoRa
|-
| rowspan="1" | Vendredi 02/02/18
| style="width: 225px;" |
* Réflexions sur l'implémentation de l'application
* Démarrage de l'application mobile
* Mises à jour d'Ionic, de Android Studio
| style="width: 225px;" |
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Premières communications fructueuses des cartes Semtech LoRaMote
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 2
|-

|-
| rowspan="1" | Lundi 05/02/18
| style="width: 225px;" |
* Configuration Login et Mot de Passe, Identification base
| style="width: 225px;" |
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Réflexion et création de la base de données
|-
| rowspan="1" | Mardi 06/02/18
| style="width: 225px;" |
* Configuration Login, Mot de passe
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
| style="width: 225px;" |
* Création de l'API REST EN PHP
|-
| rowspan="1" | Mercredi 07/02/18
| style="width: 225px;" |
* Réunion avec Rémi CHOLLET et 3 PEIP D
* Assimilation du fonctionnement de Leaflet
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
| style="width: 225px;" |
* Réunion avec Rémi CHOLLET et 3 PEIP D
* Création de l'API REST en PHP
|-
| rowspan="1" | Jeudi 08/02/18
| style="width: 225px;" |
* Ajout de marqueurs sur Leaflet
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
| style="width: 225px;" |
* Création de l'API REST EN PHP
|-
| rowspan="1" | Vendredi 09/02/18
| style="width: 225px;" |
* Hackathon Vinci Energies
| style="width: 225px;" |
* Hackathon Vinci Energies
| style="width: 225px;" |
* Hackathon Vinci Energies
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 3
|-

|-
| rowspan="1" | Lundi 12/02/18
| style="width: 225px;" |
* Préparation Soutenance
| style="width: 225px;" |
* Mise en place d'un Contiki/Cooja pour faciliter le développement
| style="width: 225px;" |
* Préparation Soutenance
|-
| rowspan="1" | Mardi 13/02/18
| style="width: 225px;" |
* Mise à jour de AIR
* Préparation Soutenance
* Répétition soutenance
| style="width: 225px;" |
* Préparation Soutenance
* Répétition soutenance
* Mise en place d'un Contiki/Cooja pour faciliter le dévelloppement
| style="width: 225px;" |
* Préparation Soutenance
* Répétition soutenance
|-
| rowspan="1" | Mercredi 14/02/18
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
|-
| rowspan="1" | Jeudi 15/02/18
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
|-
| rowspan="1" | Vendredi 16/02/18
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
| style="width: 225px;" |
* Prise en main de la LoRaOne
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 4
|-

|-
| rowspan="1" | Lundi 26/02/18
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Travail sur l'affichage des éléments sur la carte utilisateur
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Travail sur Contiki, création d'un protocole de routage
| style="width: 225px;" |
* Réunion post-interruption pédagogique
* Corrections de l'API en accord avec l'application mobile
* Modifications sur la base de données
|-
| rowspan="1" | Mardi 27/02/18
| style="width: 225px;" |
* Création de la page de création d'un nouvel utilisateur
* Design de l'application mobile
| style="width: 225px;" |
* Fin du protocole de routage Contiki, tests virtuels de fonctionnement
| style="width: 225px;" |
* Liaison entre l'application mobile et l'API
|-
| rowspan="1" | Mercredi 28/02/18
| style="width: 225px;" |
* Fin de la page de création d'un nouvel utilisateur
* Ajout de l'utilisation des sessions dans l'application
| style="width: 225px;" |
* Panne ordinateur personnel
* Travail sur l'application mobile avec Hugo
| style="width: 225px;" |
* API : Création d'un utilisateur
* API : Récupération des informations nécessaires pour la carte
* API : Ajout de l'utilisation des sessions pour stocker l'utilisateur connecté
|-
| rowspan="1" | Jeudi 01/03/18
| style="width: 225px;" |
* Affichage des informations sur la carte
| style="width: 225px;" |
* Affichage des informations sur la carte
| style="width: 225px;" |
* API : Récupération des informations nécessaires pour la carte
|-
| rowspan="1" | Vendredi 03/03/18
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Réparation d'ordinateur personnel
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Renseignements sur Swagger
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 5
|-

|-
| rowspan="1" | Lundi 05/03/18
| style="width: 225px;" |
* Ajout de la page de modification d'un utilisateur
* Restructuration de l'application
| style="width: 225px;" |
* Finalisation de la carte, et ajout de la gestion des différentes cartes
* Restructuration de l'application
| style="width: 225px;" |
* Création d'une page Swagger
* Corrections de l'API
* Ajout des cartes dans la base de données
* Récupération des éléments liés à la carte dans l'API
|-
| rowspan="1" | Mardi 06/03/18
| style="width: 225px;" |
* Fin de la modification d'un utilisateur
* Ajout de changement de mot de passe
* Ajout gestion secouriste
| style="width: 225px;" |
* Ajout gestion secouriste
* Création vues côté secouristes
| style="width: 225px;" |
* Fin du Swagger
* API : Modifications utilisateur
* API : Modifications mot de passe
* Base de données : Ajout affectations secouristes-cartes
* API : Récupération des cartes pour un secouriste
|-
| rowspan="1" | Mercredi 07/03/18
| style="width: 225px;" |
* Ajout des notifications
| style="width: 225px;" |
* Corrections du menu et de la navigation
| style="width: 225px;" |
* Journaux sur air.imag.fr
* Programme de récupération des messages à la racine et inscription des données dans la base de données
|-
| rowspan="1" | Jeudi 08/03/18
| style="width: 225px;" |
* Extraction des dents de sagesse
| style="width: 225px;" |
*
| style="width: 225px;" |
* Création du programme de communication LoRa et récupération des coordonnées GPS depuis la carte SodaqONE
* Tests de temps de synchronisation et précision du GPS
|-
| rowspan="1" | Vendredi 09/03/18
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Design du LogoV2, Embellie CSS de l'application mobile
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
*
| style="width: 225px;" |
* Réunion et préparation rendez-vous avec M.Donsez
* Finition du programme de communication LoRa
* Tests d'envoi de la carte SodaqONE vers la base de données en passant par une racine (carte Arduino LoRa)
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 6
|-

|-
| rowspan="1" | Lundi 12/03/18
| style="width: 225px;" |
*
| style="width: 225px;" |
*
| style="width: 225px;" |
* Rédaction du dossier Management de Projet Innovant
|-
| rowspan="1" | Mardi 13/03/18
| style="width: 225px;" |
*
| style="width: 225px;" |
*
| style="width: 225px;" |
*
|-
| rowspan="1" | Mercredi 14/03/18
| style="width: 225px;" |
*
| style="width: 225px;" |
*
| style="width: 225px;" |
*
|-
| rowspan="1" | Jeudi 15/03/18
| style="width: 225px;" |
*
| style="width: 225px;" |
*
| style="width: 225px;" |
*
|}

=Collaboration avec le DUT RT et les PEIPs D=
L'objectif de cette collaboration est de familiariser des étudiants en PEIP D avec des projets qu'ils seront amenés à développer dans les prochaines années. Nous avons rencontré Rémi CHOLLET et 3 étudiants Mercredi 7 Février, en voici un résumé écrit par Mr CHOLLET définissant les contours de cette collaboration.

"Un rapide résumé de la rencontre que nous avons eu ce matin avec le projet R’Montagne.

Présents :
- RCIM5 Gwenael Moreau, Hugo Amodru-Favin
- PEIP-D : Yoann Goma-Missamou, Vincent Cadoux, Philippe Charrat
- IUT : Rémy Chollet, tuteur pédagogique des PEIP-D
Excusés : Didier Donsez, blessé (aie ! courage …), Antoine Delise en cours de marketing

Contexte :
Les PEIP-D participent aux projets RICM5 en prenant une tâche « annexe » (hors chemin critique) en charge. L’objectif est une expérience d’immersion + notation liée au PEIP.

Déroulé :
Les étudiant RCIM5 ont présenté le projet dans son principe et état d’avancement. Les échanges se sont portés sur l’idée de mener une étude (simulation et mesure) sur la consommation des balises par les PEIP-D avec pour objectif de dimensionner la réserve d’énergie.

Ceci implique :
- coté RCIM5 : mise à disposition d’une carte prototype.

- cote PEIP-D : inventaire des paramètres à prendre en compte :
* consommation carte (GPS + puce LoRa) = > veille + temps d’activation (recherche à faire sur le temps de synchronisation du GPS)
* puissance d’émission à calibrer en fonction de la couverture voulue et débit (voir Spread Factor ?)
* temps d’émission-réception (émission jusqu’à acquittement)

- cote PEIP-D : penser la manip pour valider ce modèle
* mesure moyenne du courant
* configuration effective du réseau
* réserver le matériel (voir Jean-Yves Frau au département R&T ?)

- cote PEIP-D : paramètrer les simulations et mesures en fonction de puissance d’émission (ou autre élément pouvant apparaitre comme pertinent)

D’une manière générale, pour les PEID-D :
- penser bibliographie (pour commencer : https://fr.wikipedia.org/wiki/LoRaWAN et aussi https://fr.wikipedia.org/wiki/Format_des_piles_et_accumulateurs_électriques :-) )
- planifier
- communiquer : reporting !!!"

=Description du sujet=

==Randonnée et risques==

Ouvert à tous, la randonnée est un sport et un loisir qui prend de plus en plus d’ampleur de nos jours. Ne nécessitant pas de grands prérequis, des milliers de personnes se lancent en montagne chaque jour, malheureusement parfois sans connaître toutes les mesures de sécurité associées.

En effet, de janvier à juin 2016, en randonnée et en alpinisme, l’Association Nationale pour l’Étude de la Neige et des Avalanches (ANENA) a comptabilisé 21 accidents notables, dont 8 accidents mortels, impliquant 15 décès.

Aujourd’hui, les mesures de sécurités préconisent que chaque groupe de randonneur se doivent de se munir d’un téléphone portable afin d’appeler les secours en cas de problème. Malheureusement, la communication mobile dépendant de la couverture réseau, peu présente en montagne, l’impossibilité de joindre les secours reste un problème.

==Solutions existantes==

La solution la plus répandue, est celle du téléphone à connexion satellite. Ayant une communication vers les satellites, cela permet une couverture réseau beaucoup plus répandue dans les montagnes, partout dans le monde (ou presque). Cependant, les téléphones portables satellitaires coûtent chers, et ne sont pas forcément abordables par la plupart des personnes, surtout celles ne sortant qu’occasionnellement.

[https://fall-alarm.net/ Fall Alarm] est un système de détection de chute sur chantier utilisant les mêmes technologies dont nous avons besoin pour notre projet.

==Quelles zones géographiques ?==

Toutes les zones montagneuses peuvent présenter des zones blanches, démunies de connexion quelconque autre que les connexions satellitaires. Certaines chaînes de montagne comme la Cordillaire des Andes ne présentent aucune connexion possible quelconque.

Dans le cadre de notre projet, nous fonctionnerons essentiellement dans la localisation grenobloise avec l'objectif que notre solution soit applicable partout dans le monde. Une contrainte intervient tout de même étant donnée que la fréquence d'utilisation du LoRa en Europe est de 868MHz, 915MHz en Amérique et 433MHz en Asie.

= Fonctionnalités =

Afin de remplir au mieux ses attentes, le principal objectif de ce dispositif sera premièrement de pouvoir communiquer avec les secours à n’importe quel moment, et surtout n’importe où. De plus, il sera capable de détecter de nombreux cas de détresse de la part de l’usager afin de pouvoir lancer un appel d’urgence sans interaction avec l’usager, au cas où il serait inconscient, ou incapable de lancer un appel manuel.

Grâce aux accéléromètres, le dispositif sera à même de détecter un mouvement brutal du randonneur, ce qui pourrait s’apparenter à une chute. Ils pourront également détecter une position anormale, ou une immobilité prolongée, ce qui déclencherait le dispositif d’urgence automatiquement.

Grâce à des tests réalisés au préalable, le boîtier pourra détecter correctement les chûtes de simples mouvements, afin de ne pas lancer l’appel sans raison valable.

Avant de lancer une alerte automatique, le dispositif émettra un signal auditif et visuel à l’utilisateur quelques secondes auparavant, afin de le prévenir l'émission du signal d’urgence, et de lui proposer de le désactiver sur simple pression d’un bouton, afin d’éviter les communications inutiles.

Également, le randonneur sera à même d'émettre volontairement un appel d’urgence à l’aide du bouton, ce qui permet à tout moment d’appeler de l’aide sans effort. Cela peut permettre également à appeler les secours pour une personne en danger qui ne porterait pas le dispositif.

L’appel au secours se représente par un envoi de coordonnées GPS aux secours, via une communication radio LoRa vers des bornes relais placées au préalables en montagne. Cette communication irait de relai de relai jusqu’au centre de sécurité, d’où le message serait transmis aux secours.

De plus, une application mobile verra le jour afin de connecter tous les utilisateurs du module de sécurité, de les visualiser sur une map, et de partager leurs données. En effet, à chaque incident, l’application mettra à jour la position et de la date de l’accident, afin de permettre aux prochains utilisateurs d’être prévenus. Ils pourraient, s'ils sont à proximité, d'assister la personne en détresse en attendant l'arrivée des secours. Bien évidemment, cette application ne sera accessible uniquement si le smartphone de l'utilisateur est relié à une connexion 4G ou Wi-Fi.

Cette prévention pourrait les sensibiliser aux risques de la montagne, leur permettre d’éviter le secteur mais aussi d’aider les personnes en danger si la distance le permet.

= Exigences =
== Fonctionnelles ==

*Batterie garantie fonctionnelle 1 semaine
*Rechargement possible via le panneau solaire portable
*Dispositif pouvant être allumé et éteint par l'utilisateur
*Alarme s’enclenche automatiquement dès qu'elle est considérée nécessaire, signal sonore
*Utilisateur a la possibilité d’activer/désactiver l’alarme quand il le souhaite
*Lorsque l’alarme est active, l’appareil ne peut s’éteindre
*...

== Non-Fonctionnelles ==

*Résistance : aux chocs, impacts, waterproof (utilisé en permanence en plein air)
*Disponibilité : Appareil de secours -> Doit être au plus possible performant
*Performance : Minimiser les pertes réseaux
*Accessible : Utilisateur pas forcément familier avec des appareils électroniques (facile d’utilisation)
*Fiabilité : Précision du GPS (rayon de 10m), données non-éronnées
*Coût : Le plus faible possible pour vendre le moins cher possible
*Efficacité : Réduire la consommation, utiliser le moins possible les ressources

= Composants =
== LoRaONE ==
Pour le coeur du projet, après avoir cherché et comparés plusieurs modules LoRa, GPS ou encore accéléromètres, nous avons finalement opté pour le projet LoRaONE.

LoRaONE est un projet de SODAQ regroupant plusieurs composants dans une seule et même carte, de taille réduite.

https://www.kickstarter.com/projects/sodaq/loraone-the-lora-iot-development-board

“The one IoT development board to rule them all” --SODAQ

Cette carte regroupe plusieurs capteurs afin de respecter aux mieux nos exigences :

Un émetteur/récepteur LoRa afin de pouvoir communiquer au mieux avec les antennes relai à longue distance

Un module + antenne GPS de bonne précision (< 10m) pour connaître en tout temps notre position, et ainsi faciliter l’arrivée des secours, ainsi que la recherche de l’individu en détresse

Un accéléromètre sur 3 axes afin de pouvoir détecter tout mouvement, vitesse ou rotation dans l’espace, ce qui permet la détection de chutes ou d’arrêt de mouvements

3 LED RGB afin de pouvoir signaler à l’utilisateur un manque de batterie, un signal d’urgence ou plus si nécessaire

Un bouton poussoir pour le signal d’alarme

Un connecteur de charge par panneau solaire, afin de faire durer chaque batterie le plus longtemps possible

Un connecteur micro-USB ainsi que des lignes pour se connecter à une base Arduino si besoin

[[File:LoRaOne.png||400px|Spécifications carte LoRaOne]]

De plus, grâce au starter pack, nous pouvons avoir accès à la base ONEBase qui nous permettrait d’étendre plus loin la facilité d’utilisation du produit :

[[File:LoRaOneBase.png||400px|Spécifications base LoRaOneBase]]

Comme nous pouvons le voir, cette base nous permettra de connecter la batterie ainsi que le panneau solaire qui sont fournis dans le pack.

Nous pourrons également connecter jusqu’à 4 modules supplémentaires.

La batterie fournie aura une capacité de 800 mAh, le panneau solaire fourni pouvant délivrer jusqu’à 500 mW de puissance.

Le total atteint une taille d’environ 10*5 cm, ce qui n’est pas excessif, ce qui le rend aisément portatif sur une jambe ou à la taille.

'''Coût : 115€'''

Ce module pourra également servir d’antenne relai, l'alimentation solaire devrait maintenir le dispositif chargé en permanence. Des tests seront effectués pour savoir si un panneau solaire plus puissant est requis.

== Boîtier ==

Le boîtier sécurisé devant respecter plusieurs exigences, nous pouvons le construire en plastique résistant, ce qui le rendrait léger tout en respectant une rigidité suffisante. Les antennes pourront être placées le long du boîtier, à l’intérieur si la connexion est suffisante, ou à l’extérieur. Dans ce dernier cas les trous réalisés sur le boîtier afin de laisser passer les câbles seront colmatés afin de garantir une étanchéité.

[[File:SchemaBoitier.png||100px|Schéma boitier d'alarme]]

== Balises ==

Afin de remonter les informations transmises par les boitiers, des balises seront mises en places sur la zone à couvrir, leur nombre et leur positions dépendra du terrain (obstacles, dénivelés). On distinguera deux types de balises. Tout d’abord, les balises racines qui permettront une communication GSM afin de faire remonter les données vers le serveur. Viennent ensuite les balises standard qui se contenteront de faire remonter vers leur balise racine associée. L’architecture de liaison des balises est détaillée dans une prochaine partie.

Chaque balise est composée d’une barre de fer pouvant être plantée dans le sol, d’un système de lest afin d’immobiliser la balise, d’un paratonnerre, d’un panneau solaire ainsi que d’un LoraOne et d’une batterie. Les balises racines seront équippée en plus d’un dispositif de communication GSM (téléphone portable, émetteur GSM).

[[File:SchemaBalise.png||150px|Schéma balises d'alarme]]

== Application mobile ==
Une application mobile est téléchargeable par les utilisateurs. Ils peuvent voir les autres utilisateurs présents dans leur zone. Lorsqu’un utilisateur est en position de danger, une notification apparaît si les utilisateurs sont proches de la situation de danger.

Cette application n’est pas directement reliée au dispositif. Elle ne fonctionne qu’avec la connexion du mobile, et est destinée à être un niveau de sécurité supérieur. Un randonneur proche d’une zone de danger pourrait arriver sur place plus rapidement que les secours.

= Communication =

Pour un envoi de position + numéro d’identification (X chiffres) :

*Temps de communication : < 2 s
*Communication régulière, intervalle de 15 minutes

On peut donc au maximum avoir 15 * 60 / 2 = 450 individus pouvant communiquer avec la même antenne relai, donc dans le même cercle d’environ 15 km de diamètre.

On communique donc au minimum 2 secondes sur 15 minutes, donc 1/450 << 1%, le temps de communication est respecté.

En cas de problème, nous pouvons envoyer jusqu’à 9x plus avec la borne sans dépasser le temps de communication autorisé (1%). Donc 1 envoi d’appel d’urgence toutes les 2 minutes environ.

La balise racine peut être directement connectée au serveur, dans ce cas, il n’y a pas de communication GSM nécessaire et pas de Gateway. Si la racine n’est pas directement connectée au serveur, elle devra au minimum garantir une communication GSM (ce qu’elle peut faire, il n’y a pas de Gateway nécessaire) pour remonter l’information vers le serveur, et donc la base de données.

GSM : Si Racine connectée à Serveur -> No GSM + Gateway
Else : GSM + Gateway : LoRa Racine connectée ordi (RaspberryPI) + ordi connecté GSM

= Stabilisation et gestion d’erreurs =

== Choix du routage ==

Notre réseau n'est pas un réseau traditionnel. Les seules communications existantes sont soit une remontée d'information vers la racine soit une innondation d'alerte vers les clients. Pour celà nous avons donc décidé d'utiliser un algorithme de routage simplifié basé uniquement sur un arbre en largeur des balises. Nous rajoutons en option la possibilité de créer plusieurs racines et donc plusieurs arbres dont les racines communiquent par gsm. Nous nous basons sur des papiers de recherches afin de déterminer quel algorithme auto-stabilisant est le plus adapté au système LoRa (Tel que le papier "A self-stabilizing algorithm for constructing breadth-first trees" par Shing-Tsaan Huang, Nian-Shing Chen).

== Stabilisation ==

Afin de gérer la communication de chaque message vers le serveur, nous allons prendre un noeud (balise LoRa) dit “racine” connecté directement au serveur, nous ne nous occuperons pas de la communication au serveur dans cet onglet. Chaque message reçu de la part d’un noeud du système doit être relayé jusqu’à la racine du système afin de communiquer avec les secours (ou serveur simplement).

Pour cela, il faudra assurer que chaque balise LoRa soit connecté au réseau, afin d’avoir au départ un graphe de communication connexe. Par dessus ce graphe, nous allons utiliser un processus silencieux auto-stabilisant qui construira un arbre de parcours en largeur, avec pour racine le noeud “racine” décidé ci-dessus.

Au lancement du système, il faut prévoir un léger temps de stabilisation, qui dépendrait de l’algorithme et de la taille du graphe (nombre de balises). Cependant, après cela, l’algorithme assure un arbre en profondeur minimal qui nous permettrai de communiquer avec la racine le plus rapidement possible, et donc une qualité de service maximale.

== Gestion d’erreurs ==

Dans un réseau comme celui-ci, plusieurs types d’erreurs peuvent se produire :
Délai de communication trop important vers une balise
“Crash” d’une balise de communication
Surpopulation d’une balise ou congestion de messages

Afin de palier au premier type d’incident rencontré, il faut nécessairement qu’à chaque emplacement dans la zone couverte, l’utilisateur soit à même de communiquer avec au minimum 2 balises différentes. Ainsi, dans le cas d’une communication trop longue sur une balise, l’autre aurait de grandes chances de délivrer le message plus rapidement.

Au niveau de la défaillance d’une balise, l’algorithme d’arbre en profondeur nous fournit déjà une solution intégrée grâce à son auto-stabilisation. Dans le cas de déconnexion d’une balise, l’algorithme mettrai à jour automatiquement l’arbre de communication, et n’importe quel message d’alerte émis serait délivré dans un délai raisonnable.

Pour le troisième cas d’erreur, il n’y aurait pas de solution réelle, si ce n’est de limiter le nombre de communications données, en ne prenant plus en compte les “ping” de chaque utilisateur mais seulement les messages d’alertes, ce qui permettrai une bien plus grande gestion de la congestion à un endroit donné. Également, une balise en dessous d’un lien congestionné pourrait communiquer avec ses autres voisins (non-fils dans l’arbre) afin de libérer de l’espace dans le lien avec son père dans l’arbre. Également, le système ne pourra accepter que jusqu’à 1000 utilisateurs par noeud, et également 4000 utilisateurs par cluster (dans le cas d’un réseau avec plusieurs clusters donc plusieurs racines cette limite augmente).

Plusieurs types de paquets circulent sur le réseau de balise:
Les pings, messages envoyés spontanéments à intervalle régulier par les utilisateur contenant l’id ainsi que les deux coordonées gps (27 bits chacun)
Les incidents, identique à un ping mais à priorité haute.
Les alertes, messages brodcastés par le serveur afin d’envoyer un message en chaine de caractères courts et compressés.

=Coûts matériels=

Que ce soit pour le dispositif utilisateur ou la balise (racine ou non), le LoRaOne correspond pour permettre les actions recherchées. Afin de réaliser un prototype pertinent, 6 kits LoRaOne sont requis. Ces kits sont accessibles sur le site de Sodaq au prix de 115€ chacun (prix variable).
Disponible [https://shop.sodaq.com/en/one-eu-rn2483-v2.html ici], voir avant dernier bundle : starter "ONE EU starter" actuellement à 112,10€.

Un [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer buzzer] est à ajouter au dispositif utilisateur afin de lui délivrer un signal sonore.

Un shield GSM est requis pour que la balise racine communique avec l'extérieur. Sodaq en propose un designé pour fonctionner sur leurs produits mais est éctuellement en rupture de stock. Un shield GSM arduino convient tout autant et peut être trouvé sur le site arduino [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna ici].

Aucun boitier ne sera commandé car nous avons fait le choix de les manufacturer nous même au fablab. Le besoin d'étanchéité n'est pas primordial pour notre prototype, bien que nous tenterons de l'assurer.

{|class="récap commande"
|+ Récapitulatif
|-
|
!scope="col" style="width: 320px;"| Produit
!scope="col" style="width: 80px;"| Lien
!scope="col" style="width: 80px;"| Quantité
!scope="col" style="width: 80px;"| Prix Unitaire
|-

!scope="row"| 1
| LoRaOne EU Starter
| [https://shop.sodaq.com/en/one-eu-rn2483-v2.html Achat]
| 6
| 115€
|-

!scope="row"| 2
| Buzzer
| [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer Achat]
| 3
| 5.49€
|-

!scope="row"| 3
| Shield GSM
| [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna Achat]
| 1
| 65€
|-

|}

=Développement=

Nous utiliserons les librairies standards Arduino ainsi que celle de SODAQ/Arduino pour le LoRa.

L'IDE Arduino sera utilisé, plus pratique pour l'utilisation de Git (comparé à Mbed).

= Mise sur le marché =

Ce dispositif a pour but d’être utilisé en montagne, lors de randonnée. Il n’est pas destiné à un usage quotidien, c’est pourquoi nous considérons qu’il est plus judicieux de louer les dispositifs plutôt que de les vendre, même si l’achat n’est pas à omettre de notre stratégie.

Le dispositif peut être commandé en ligne, puis retourné par la poste après usage. Le client louerait le dispositif pour une certaine durée avec un possible nombre supplémentaire de batterie. Les tarifs varient en fonction de la durée et du nombre de batteries louées. Des offres de groupes pourraient être applicables. A long terme, des boutiques pourraient être disséminées dans des grandes villes proches des zones montagneuses, zones à randonnées (Grenoble, Annecy, etc.).

L’application est téléchargeable gratuitement par quiconque, mais utilisable seulement par les clients. Un code d’accès sera envoyé avec le dispositif expirant après la fin de la location.

Il faudra tenir compte de la bande passante du LoRa, variante en fonction des continents.

=Planning prévisonnel=

Sprint 1 : 29/01 --> 09/02 : Création du prototype logiciel #1
*Prise en main du matériel
*Premiers tests de transmissions LoRa
*Création du protocole d'architecture des balises
*Application sur les cartes et tests
*Tests de performances des cartes (durabilité, chargement, batterie)
*Tests de maintenabilité de l'algorithme (déconnexions, latences)

Sprint 2 : 12/02 --> 23/02 : Prototype logiciel #2 et prototype matériel
*Création du programme embarqué (utilisateur)
*Communication avec la racine et le serveur
*Création des maquettes boîtier et balise
*Construction des maquettes
*Finalisation du premier prototype

Sprint 3 : 26/02 --> 09/03 : Fonctionnalités supplémentaires
*Ajout de la communication entre le LoRa et le GSM sur la balise racine
*Création application mobile utilisateur
*Tests sur l'application
*Tests sur la transmission totale depuis l'utilisateur vers le serveur via le GSM
*Finalisation du projet

Sprint 4 : 12/03 --> 16/03 : Fin du projet
*Création de la documentation finale (à partir de la documentation réalisée en continu)
*Pause café
*Temps supplémentaire en cas de problèmes importants
*Préparation de la soutenance

R'Montagne

2018-03-02T11:43:47Z

Hugo.Amodru-Favin: /* Journal */

=Équipe=
{|class="wikitable"
|-
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Rôle
|-
| Hugo Amodru-Favin
| Chef de Projet
|-
| Antoine Delise
| Lead Developer
|-
| Gwenaël Moreau
| Kanban Master
|-

|}

==Tâches==

Répartition générale des tâches
{|class="wikitable"
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Tâche
|-
| Hugo Amodru-Favin
| Application Ionic
|-
| Antoine Delise
| Développement Arduino
|-
| Gwenaël Moreau
| BDD - API
|-

|}

Détail des tâches : [https://waffle.io/delisea/R-Montagne Waffle.io]

=Journal=

{|class="wikitable"
|+
|-
!scope="col" width="120px"| Date
!scope="col"| Hugo AMODRU-FAVIN
!scope="col"| Antoine DELISE
!scope="col"| Gwenaël MOREAU
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 1
|-

|-
| rowspan="1" | Lundi 29/01/18
| style="width: 225px;" |
* Ré-assimilation du sujet
| style="width: 225px;" |
* Ré-assimilation du sujet
| style="width: 225px;" |
* Ré-assimilation du sujet
* Mise en place d'un Kanban
|-
| rowspan="1" | Mardi 30/01/18
| style="width: 225px;" |
* Mise à jour de la page AIR
* Réflexions sur l'implémentation du LoRa
| style="width: 225px;" |
* Mise à jour de la page AIR
* Réflexions sur l'implémentation du LoRa
| style="width: 225px;" |
* Mise en place du calendrier prévisionnel
* Définition et répartition des tâches
|-
| rowspan="1" | Mercredi 31/01/18
| style="width: 225px;" |
* Récupération des cartes Semtech
* Présentation du Hackathon Vinci Energies
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Récupération des cartes Semtech
* Présentation du Hackathon
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Récupération et prise en main des cartes Semtech LoRaMote
* Présentation du Hackathon Vinci Energies
|-
| rowspan="1" | Jeudi 01/02/18
| style="width: 225px;" |
* Choix des fonctionnalités de l'application mobile
| style="width: 225px;" |
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Prise en main des cartes LoRa
|-
| rowspan="1" | Vendredi 02/02/18
| style="width: 225px;" |
* Réflexions sur l'implémentation de l'application
* Démarrage de l'application mobile
* Mises à jour d'Ionic, de Android Studio
| style="width: 225px;" |
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Premières communications fructueuses des cartes Semtech LoRaMote
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 2
|-

|-
| rowspan="1" | Lundi 05/02/18
| style="width: 225px;" |
* Configuration Login et Mot de Passe, Identification base
| style="width: 225px;" |
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Réflexion et création de la base de données
|-
| rowspan="1" | Mardi 06/02/18
| style="width: 225px;" |
* Configuration Login, Mot de passe
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
| style="width: 225px;" |
* Création de l'API REST EN PHP
|-
| rowspan="1" | Mercredi 07/02/18
| style="width: 225px;" |
* Réunion avec Rémi CHOLLET et 3 PEIP D
* Assimilation du fonctionnement de Leaflet
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
| style="width: 225px;" |
* Réunion avec Rémi CHOLLET et 3 PEIP D
* Création de l'API REST en PHP
|-
| rowspan="1" | Jeudi 08/02/18
| style="width: 225px;" |
* Ajout de marqueurs sur Leaflet
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
| style="width: 225px;" |
* Création de l'API REST EN PHP
|-
| rowspan="1" | Vendredi 09/02/18
| style="width: 225px;" |
* Hackathon Vinci Energies
| style="width: 225px;" |
* Hackathon Vinci Energies
| style="width: 225px;" |
* Hackathon Vinci Energies
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 3
|-

|-
| rowspan="1" | Lundi 12/02/18
| style="width: 225px;" |
* Préparation Soutenance
| style="width: 225px;" |
* Mise en place d'un Contiki/Cooja pour faciliter le développement
| style="width: 225px;" |
* Préparation Soutenance
|-
| rowspan="1" | Mardi 13/02/18
| style="width: 225px;" |
* Mise à jour de AIR
* Préparation Soutenance
* Répétition soutenance
| style="width: 225px;" |
* Préparation Soutenance
* Répétition soutenance
* Mise en place d'un Contiki/Cooja pour faciliter le dévelloppement
| style="width: 225px;" |
* Préparation Soutenance
* Répétition soutenance
|-
| rowspan="1" | Mercredi 14/02/18
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
| style="width: 225px;" |
* Soutenance de mi-projet
* Réunion post-soutenance pour redéfinir certains aspects
|-
| rowspan="1" | Jeudi 15/02/18
| style="width: 225px;" |
* Prise en main de la LoraOne
| style="width: 225px;" |
* Prise en main de la LoraOne
| style="width: 225px;" |
* Prise en main de la LoraOne
|-
| rowspan="1" | Vendredi 16/02/18
| style="width: 225px;" |
*
| style="width: 225px;" |
*
| style="width: 225px;" |
*
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 4
|-

|-
| rowspan="1" | Lundi 26/02/18
| style="width: 225px;" |
| style="width: 225px;" |
| style="width: 225px;" |
|-
| rowspan="1" | Mardi 27/02/18
| style="width: 225px;" |

| style="width: 225px;" |

| style="width: 225px;" |

|-
| rowspan="1" | Mercredi 28/02/18
| style="width: 225px;" |
*
| style="width: 225px;" |
*
| style="width: 225px;" |
*
|-
| rowspan="1" | Jeudi 01/03/18
| style="width: 225px;" |
*
| style="width: 225px;" |
*
| style="width: 225px;" |
*
|-
| rowspan="1" | Vendredi 03/03/18
| style="width: 225px;" |
*
| style="width: 225px;" |
*
| style="width: 225px;" |
*
|-
|}

=Collaboration avec le DUT RT et les PEIPs D=
L'objectif de cette collaboration est de familiariser des étudiants en PEIP D avec des projets qu'ils seront amenés à développer dans les prochaines années. Nous avons rencontré Rémi CHOLLET et 3 étudiants Mercredi 7 Février, en voici un résumé écrit par Mr CHOLLET définissant les contours de cette collaboration.

"Un rapide résumé de la rencontre que nous avons eu ce matin avec le projet R’Montagne.

Présents :
- RCIM5 Gwenael Moreau, Hugo Amodru-Favin
- PEIP-D : Yoann Goma-Missamou, Vincent Cadoux, Philippe Charrat
- IUT : Rémy Chollet, tuteur pédagogique des PEIP-D
Excusés : Didier Donsez, blessé (aie ! courage …), Antoine Delise en cours de marketing

Contexte :
Les PEIP-D participent aux projets RICM5 en prenant une tâche « annexe » (hors chemin critique) en charge. L’objectif est une expérience d’immersion + notation liée au PEIP.

Déroulé :
Les étudiant RCIM5 ont présenté le projet dans son principe et état d’avancement. Les échanges se sont portés sur l’idée de mener une étude (simulation et mesure) sur la consommation des balises par les PEIP-D avec pour objectif de dimensionner la réserve d’énergie.

Ceci implique :
- coté RCIM5 : mise à disposition d’une carte prototype.

- cote PEIP-D : inventaire des paramètres à prendre en compte :
* consommation carte (GPS + puce LoRa) = > veille + temps d’activation (recherche à faire sur le temps de synchronisation du GPS)
* puissance d’émission à calibrer en fonction de la couverture voulue et débit (voir Spread Factor ?)
* temps d’émission-réception (émission jusqu’à acquittement)

- cote PEIP-D : penser la manip pour valider ce modèle
* mesure moyenne du courant
* configuration effective du réseau
* réserver le matériel (voir Jean-Yves Frau au département R&T ?)

- cote PEIP-D : paramètrer les simulations et mesures en fonction de puissance d’émission (ou autre élément pouvant apparaitre comme pertinent)

D’une manière générale, pour les PEID-D :
- penser bibliographie (pour commencer : https://fr.wikipedia.org/wiki/LoRaWAN et aussi https://fr.wikipedia.org/wiki/Format_des_piles_et_accumulateurs_électriques :-) )
- planifier
- communiquer : reporting !!!"

=Description du sujet=

==Randonnée et risques==

Ouvert à tous, la randonnée est un sport et un loisir qui prend de plus en plus d’ampleur de nos jours. Ne nécessitant pas de grands prérequis, des milliers de personnes se lancent en montagne chaque jour, malheureusement parfois sans connaître toutes les mesures de sécurité associées.

En effet, de janvier à juin 2016, en randonnée et en alpinisme, l’Association Nationale pour l’Étude de la Neige et des Avalanches (ANENA) a comptabilisé 21 accidents notables, dont 8 accidents mortels, impliquant 15 décès.

Aujourd’hui, les mesures de sécurités préconisent que chaque groupe de randonneur se doivent de se munir d’un téléphone portable afin d’appeler les secours en cas de problème. Malheureusement, la communication mobile dépendant de la couverture réseau, peu présente en montagne, l’impossibilité de joindre les secours reste un problème.

==Solutions existantes==

La solution la plus répandue, est celle du téléphone à connexion satellite. Ayant une communication vers les satellites, cela permet une couverture réseau beaucoup plus répandue dans les montagnes, partout dans le monde (ou presque). Cependant, les téléphones portables satellitaires coûtent chers, et ne sont pas forcément abordables par la plupart des personnes, surtout celles ne sortant qu’occasionnellement.

[https://fall-alarm.net/ Fall Alarm] est un système de détection de chute sur chantier utilisant les mêmes technologies dont nous avons besoin pour notre projet.

==Quelles zones géographiques ?==

Toutes les zones montagneuses peuvent présenter des zones blanches, démunies de connexion quelconque autre que les connexions satellitaires. Certaines chaînes de montagne comme la Cordillaire des Andes ne présentent aucune connexion possible quelconque.

Dans le cadre de notre projet, nous fonctionnerons essentiellement dans la localisation grenobloise avec l'objectif que notre solution soit applicable partout dans le monde. Une contrainte intervient tout de même étant donnée que la fréquence d'utilisation du LoRa en Europe est de 868MHz, 915MHz en Amérique et 433MHz en Asie.

= Fonctionnalités =

Afin de remplir au mieux ses attentes, le principal objectif de ce dispositif sera premièrement de pouvoir communiquer avec les secours à n’importe quel moment, et surtout n’importe où. De plus, il sera capable de détecter de nombreux cas de détresse de la part de l’usager afin de pouvoir lancer un appel d’urgence sans interaction avec l’usager, au cas où il serait inconscient, ou incapable de lancer un appel manuel.

Grâce aux accéléromètres, le dispositif sera à même de détecter un mouvement brutal du randonneur, ce qui pourrait s’apparenter à une chute. Ils pourront également détecter une position anormale, ou une immobilité prolongée, ce qui déclencherait le dispositif d’urgence automatiquement.

Grâce à des tests réalisés au préalable, le boîtier pourra détecter correctement les chûtes de simples mouvements, afin de ne pas lancer l’appel sans raison valable.

Avant de lancer une alerte automatique, le dispositif émettra un signal auditif et visuel à l’utilisateur quelques secondes auparavant, afin de le prévenir l'émission du signal d’urgence, et de lui proposer de le désactiver sur simple pression d’un bouton, afin d’éviter les communications inutiles.

Également, le randonneur sera à même d'émettre volontairement un appel d’urgence à l’aide du bouton, ce qui permet à tout moment d’appeler de l’aide sans effort. Cela peut permettre également à appeler les secours pour une personne en danger qui ne porterait pas le dispositif.

L’appel au secours se représente par un envoi de coordonnées GPS aux secours, via une communication radio LoRa vers des bornes relais placées au préalables en montagne. Cette communication irait de relai de relai jusqu’au centre de sécurité, d’où le message serait transmis aux secours.

De plus, une application mobile verra le jour afin de connecter tous les utilisateurs du module de sécurité, de les visualiser sur une map, et de partager leurs données. En effet, à chaque incident, l’application mettra à jour la position et de la date de l’accident, afin de permettre aux prochains utilisateurs d’être prévenus. Ils pourraient, s'ils sont à proximité, d'assister la personne en détresse en attendant l'arrivée des secours. Bien évidemment, cette application ne sera accessible uniquement si le smartphone de l'utilisateur est relié à une connexion 4G ou Wi-Fi.

Cette prévention pourrait les sensibiliser aux risques de la montagne, leur permettre d’éviter le secteur mais aussi d’aider les personnes en danger si la distance le permet.

= Exigences =
== Fonctionnelles ==

*Batterie garantie fonctionnelle 1 semaine
*Rechargement possible via le panneau solaire portable
*Dispositif pouvant être allumé et éteint par l'utilisateur
*Alarme s’enclenche automatiquement dès qu'elle est considérée nécessaire, signal sonore
*Utilisateur a la possibilité d’activer/désactiver l’alarme quand il le souhaite
*Lorsque l’alarme est active, l’appareil ne peut s’éteindre
*...

== Non-Fonctionnelles ==

*Résistance : aux chocs, impacts, waterproof (utilisé en permanence en plein air)
*Disponibilité : Appareil de secours -> Doit être au plus possible performant
*Performance : Minimiser les pertes réseaux
*Accessible : Utilisateur pas forcément familier avec des appareils électroniques (facile d’utilisation)
*Fiabilité : Précision du GPS (rayon de 10m), données non-éronnées
*Coût : Le plus faible possible pour vendre le moins cher possible
*Efficacité : Réduire la consommation, utiliser le moins possible les ressources

= Composants =
== LoRaONE ==
Pour le coeur du projet, après avoir cherché et comparés plusieurs modules LoRa, GPS ou encore accéléromètres, nous avons finalement opté pour le projet LoRaONE.

LoRaONE est un projet de SODAQ regroupant plusieurs composants dans une seule et même carte, de taille réduite.

https://www.kickstarter.com/projects/sodaq/loraone-the-lora-iot-development-board

“The one IoT development board to rule them all” --SODAQ

Cette carte regroupe plusieurs capteurs afin de respecter aux mieux nos exigences :

Un émetteur/récepteur LoRa afin de pouvoir communiquer au mieux avec les antennes relai à longue distance

Un module + antenne GPS de bonne précision (< 10m) pour connaître en tout temps notre position, et ainsi faciliter l’arrivée des secours, ainsi que la recherche de l’individu en détresse

Un accéléromètre sur 3 axes afin de pouvoir détecter tout mouvement, vitesse ou rotation dans l’espace, ce qui permet la détection de chutes ou d’arrêt de mouvements

3 LED RGB afin de pouvoir signaler à l’utilisateur un manque de batterie, un signal d’urgence ou plus si nécessaire

Un bouton poussoir pour le signal d’alarme

Un connecteur de charge par panneau solaire, afin de faire durer chaque batterie le plus longtemps possible

Un connecteur micro-USB ainsi que des lignes pour se connecter à une base Arduino si besoin

[[File:LoRaOne.png||400px|Spécifications carte LoRaOne]]

De plus, grâce au starter pack, nous pouvons avoir accès à la base ONEBase qui nous permettrait d’étendre plus loin la facilité d’utilisation du produit :

[[File:LoRaOneBase.png||400px|Spécifications base LoRaOneBase]]

Comme nous pouvons le voir, cette base nous permettra de connecter la batterie ainsi que le panneau solaire qui sont fournis dans le pack.

Nous pourrons également connecter jusqu’à 4 modules supplémentaires.

La batterie fournie aura une capacité de 800 mAh, le panneau solaire fourni pouvant délivrer jusqu’à 500 mW de puissance.

Le total atteint une taille d’environ 10*5 cm, ce qui n’est pas excessif, ce qui le rend aisément portatif sur une jambe ou à la taille.

'''Coût : 115€'''

Ce module pourra également servir d’antenne relai, l'alimentation solaire devrait maintenir le dispositif chargé en permanence. Des tests seront effectués pour savoir si un panneau solaire plus puissant est requis.

== Boîtier ==

Le boîtier sécurisé devant respecter plusieurs exigences, nous pouvons le construire en plastique résistant, ce qui le rendrait léger tout en respectant une rigidité suffisante. Les antennes pourront être placées le long du boîtier, à l’intérieur si la connexion est suffisante, ou à l’extérieur. Dans ce dernier cas les trous réalisés sur le boîtier afin de laisser passer les câbles seront colmatés afin de garantir une étanchéité.

[[File:SchemaBoitier.png||100px|Schéma boitier d'alarme]]

== Balises ==

Afin de remonter les informations transmises par les boitiers, des balises seront mises en places sur la zone à couvrir, leur nombre et leur positions dépendra du terrain (obstacles, dénivelés). On distinguera deux types de balises. Tout d’abord, les balises racines qui permettront une communication GSM afin de faire remonter les données vers le serveur. Viennent ensuite les balises standard qui se contenteront de faire remonter vers leur balise racine associée. L’architecture de liaison des balises est détaillée dans une prochaine partie.

Chaque balise est composée d’une barre de fer pouvant être plantée dans le sol, d’un système de lest afin d’immobiliser la balise, d’un paratonnerre, d’un panneau solaire ainsi que d’un LoraOne et d’une batterie. Les balises racines seront équippée en plus d’un dispositif de communication GSM (téléphone portable, émetteur GSM).

[[File:SchemaBalise.png||150px|Schéma balises d'alarme]]

== Application mobile ==
Une application mobile est téléchargeable par les utilisateurs. Ils peuvent voir les autres utilisateurs présents dans leur zone. Lorsqu’un utilisateur est en position de danger, une notification apparaît si les utilisateurs sont proches de la situation de danger.

Cette application n’est pas directement reliée au dispositif. Elle ne fonctionne qu’avec la connexion du mobile, et est destinée à être un niveau de sécurité supérieur. Un randonneur proche d’une zone de danger pourrait arriver sur place plus rapidement que les secours.

= Communication =

Pour un envoi de position + numéro d’identification (X chiffres) :

*Temps de communication : < 2 s
*Communication régulière, intervalle de 15 minutes

On peut donc au maximum avoir 15 * 60 / 2 = 450 individus pouvant communiquer avec la même antenne relai, donc dans le même cercle d’environ 15 km de diamètre.

On communique donc au minimum 2 secondes sur 15 minutes, donc 1/450 << 1%, le temps de communication est respecté.

En cas de problème, nous pouvons envoyer jusqu’à 9x plus avec la borne sans dépasser le temps de communication autorisé (1%). Donc 1 envoi d’appel d’urgence toutes les 2 minutes environ.

La balise racine peut être directement connectée au serveur, dans ce cas, il n’y a pas de communication GSM nécessaire et pas de Gateway. Si la racine n’est pas directement connectée au serveur, elle devra au minimum garantir une communication GSM (ce qu’elle peut faire, il n’y a pas de Gateway nécessaire) pour remonter l’information vers le serveur, et donc la base de données.

GSM : Si Racine connectée à Serveur -> No GSM + Gateway
Else : GSM + Gateway : LoRa Racine connectée ordi (RaspberryPI) + ordi connecté GSM

= Stabilisation et gestion d’erreurs =

== Choix du routage ==

Notre réseau n'est pas un réseau traditionnel. Les seules communications existantes sont soit une remontée d'information vers la racine soit une innondation d'alerte vers les clients. Pour celà nous avons donc décidé d'utiliser un algorithme de routage simplifié basé uniquement sur un arbre en largeur des balises. Nous rajoutons en option la possibilité de créer plusieurs racines et donc plusieurs arbres dont les racines communiquent par gsm. Nous nous basons sur des papiers de recherches afin de déterminer quel algorithme auto-stabilisant est le plus adapté au système LoRa (Tel que le papier "A self-stabilizing algorithm for constructing breadth-first trees" par Shing-Tsaan Huang, Nian-Shing Chen).

== Stabilisation ==

Afin de gérer la communication de chaque message vers le serveur, nous allons prendre un noeud (balise LoRa) dit “racine” connecté directement au serveur, nous ne nous occuperons pas de la communication au serveur dans cet onglet. Chaque message reçu de la part d’un noeud du système doit être relayé jusqu’à la racine du système afin de communiquer avec les secours (ou serveur simplement).

Pour cela, il faudra assurer que chaque balise LoRa soit connecté au réseau, afin d’avoir au départ un graphe de communication connexe. Par dessus ce graphe, nous allons utiliser un processus silencieux auto-stabilisant qui construira un arbre de parcours en largeur, avec pour racine le noeud “racine” décidé ci-dessus.

Au lancement du système, il faut prévoir un léger temps de stabilisation, qui dépendrait de l’algorithme et de la taille du graphe (nombre de balises). Cependant, après cela, l’algorithme assure un arbre en profondeur minimal qui nous permettrai de communiquer avec la racine le plus rapidement possible, et donc une qualité de service maximale.

== Gestion d’erreurs ==

Dans un réseau comme celui-ci, plusieurs types d’erreurs peuvent se produire :
Délai de communication trop important vers une balise
“Crash” d’une balise de communication
Surpopulation d’une balise ou congestion de messages

Afin de palier au premier type d’incident rencontré, il faut nécessairement qu’à chaque emplacement dans la zone couverte, l’utilisateur soit à même de communiquer avec au minimum 2 balises différentes. Ainsi, dans le cas d’une communication trop longue sur une balise, l’autre aurait de grandes chances de délivrer le message plus rapidement.

Au niveau de la défaillance d’une balise, l’algorithme d’arbre en profondeur nous fournit déjà une solution intégrée grâce à son auto-stabilisation. Dans le cas de déconnexion d’une balise, l’algorithme mettrai à jour automatiquement l’arbre de communication, et n’importe quel message d’alerte émis serait délivré dans un délai raisonnable.

Pour le troisième cas d’erreur, il n’y aurait pas de solution réelle, si ce n’est de limiter le nombre de communications données, en ne prenant plus en compte les “ping” de chaque utilisateur mais seulement les messages d’alertes, ce qui permettrai une bien plus grande gestion de la congestion à un endroit donné. Également, une balise en dessous d’un lien congestionné pourrait communiquer avec ses autres voisins (non-fils dans l’arbre) afin de libérer de l’espace dans le lien avec son père dans l’arbre. Également, le système ne pourra accepter que jusqu’à 1000 utilisateurs par noeud, et également 4000 utilisateurs par cluster (dans le cas d’un réseau avec plusieurs clusters donc plusieurs racines cette limite augmente).

Plusieurs types de paquets circulent sur le réseau de balise:
Les pings, messages envoyés spontanéments à intervalle régulier par les utilisateur contenant l’id ainsi que les deux coordonées gps (27 bits chacun)
Les incidents, identique à un ping mais à priorité haute.
Les alertes, messages brodcastés par le serveur afin d’envoyer un message en chaine de caractères courts et compressés.

=Coûts matériels=

Que ce soit pour le dispositif utilisateur ou la balise (racine ou non), le LoRaOne correspond pour permettre les actions recherchées. Afin de réaliser un prototype pertinent, 6 kits LoRaOne sont requis. Ces kits sont accessibles sur le site de Sodaq au prix de 115€ chacun (prix variable).
Disponible [https://shop.sodaq.com/en/one-eu-rn2483-v2.html ici], voir avant dernier bundle : starter "ONE EU starter" actuellement à 112,10€.

Un [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer buzzer] est à ajouter au dispositif utilisateur afin de lui délivrer un signal sonore.

Un shield GSM est requis pour que la balise racine communique avec l'extérieur. Sodaq en propose un designé pour fonctionner sur leurs produits mais est éctuellement en rupture de stock. Un shield GSM arduino convient tout autant et peut être trouvé sur le site arduino [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna ici].

Aucun boitier ne sera commandé car nous avons fait le choix de les manufacturer nous même au fablab. Le besoin d'étanchéité n'est pas primordial pour notre prototype, bien que nous tenterons de l'assurer.

{|class="récap commande"
|+ Récapitulatif
|-
|
!scope="col" style="width: 320px;"| Produit
!scope="col" style="width: 80px;"| Lien
!scope="col" style="width: 80px;"| Quantité
!scope="col" style="width: 80px;"| Prix Unitaire
|-

!scope="row"| 1
| LoRaOne EU Starter
| [https://shop.sodaq.com/en/one-eu-rn2483-v2.html Achat]
| 6
| 115€
|-

!scope="row"| 2
| Buzzer
| [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer Achat]
| 3
| 5.49€
|-

!scope="row"| 3
| Shield GSM
| [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna Achat]
| 1
| 65€
|-

|}

=Développement=

Nous utiliserons les librairies standards Arduino ainsi que celle de SODAQ/Arduino pour le LoRa.

L'IDE Arduino sera utilisé, plus pratique pour l'utilisation de Git (comparé à Mbed).

= Mise sur le marché =

Ce dispositif a pour but d’être utilisé en montagne, lors de randonnée. Il n’est pas destiné à un usage quotidien, c’est pourquoi nous considérons qu’il est plus judicieux de louer les dispositifs plutôt que de les vendre, même si l’achat n’est pas à omettre de notre stratégie.

Le dispositif peut être commandé en ligne, puis retourné par la poste après usage. Le client louerait le dispositif pour une certaine durée avec un possible nombre supplémentaire de batterie. Les tarifs varient en fonction de la durée et du nombre de batteries louées. Des offres de groupes pourraient être applicables. A long terme, des boutiques pourraient être disséminées dans des grandes villes proches des zones montagneuses, zones à randonnées (Grenoble, Annecy, etc.).

L’application est téléchargeable gratuitement par quiconque, mais utilisable seulement par les clients. Un code d’accès sera envoyé avec le dispositif expirant après la fin de la location.

Il faudra tenir compte de la bande passante du LoRa, variante en fonction des continents.

=Planning prévisonnel=

Sprint 1 : 29/01 --> 09/02 : Création du prototype logiciel #1
*Prise en main du matériel
*Premiers tests de transmissions LoRa
*Création du protocole d'architecture des balises
*Application sur les cartes et tests
*Tests de performances des cartes (durabilité, chargement, batterie)
*Tests de maintenabilité de l'algorithme (déconnexions, latences)

Sprint 2 : 12/02 --> 23/02 : Prototype logiciel #2 et prototype matériel
*Création du programme embarqué (utilisateur)
*Communication avec la racine et le serveur
*Création des maquettes boîtier et balise
*Construction des maquettes
*Finalisation du premier prototype

Sprint 3 : 26/02 --> 09/03 : Fonctionnalités supplémentaires
*Ajout de la communication entre le LoRa et le GSM sur la balise racine
*Création application mobile utilisateur
*Tests sur l'application
*Tests sur la transmission totale depuis l'utilisateur vers le serveur via le GSM
*Finalisation du projet

Sprint 4 : 12/03 --> 16/03 : Fin du projet
*Création de la documentation finale (à partir de la documentation réalisée en continu)
*Pause café
*Temps supplémentaire en cas de problèmes importants
*Préparation de la soutenance

R'Montagne

2018-03-02T11:36:38Z

Hugo.Amodru-Favin: /* Journal */

=Équipe=
{|class="wikitable"
|-
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Rôle
|-
| Hugo Amodru-Favin
| Chef de Projet
|-
| Antoine Delise
| Lead Developer
|-
| Gwenaël Moreau
| Kanban Master
|-

|}

==Tâches==

Répartition générale des tâches
{|class="wikitable"
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Tâche
|-
| Hugo Amodru-Favin
| Application Ionic
|-
| Antoine Delise
| Développement Arduino
|-
| Gwenaël Moreau
| BDD - API
|-

|}

Détail des tâches : [https://waffle.io/delisea/R-Montagne Waffle.io]

=Journal=

{|class="wikitable"
|+
|-
!scope="col" width="120px"| Date
!scope="col"| Hugo AMODRU-FAVIN
!scope="col"| Antoine DELISE
!scope="col"| Gwenaël MOREAU
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 1
|-

|-
| rowspan="1" | Lundi 29/01/18
| style="width: 225px;" |
* Ré-assimilation du sujet
| style="width: 225px;" |
* Ré-assimilation du sujet
| style="width: 225px;" |
* Ré-assimilation du sujet
* Mise en place d'un Kanban
|-
| rowspan="1" | Mardi 30/01/18
| style="width: 225px;" |
* Mise à jour de la page AIR
* Réflexions sur l'implémentation du LoRa
| style="width: 225px;" |
* Mise à jour de la page AIR
* Réflexions sur l'implémentation du LoRa
| style="width: 225px;" |
* Mise en place du calendrier prévisionnel
* Définition et répartition des tâches
|-
| rowspan="1" | Mercredi 31/01/18
| style="width: 225px;" |
* Récupération des cartes Semtech
* Présentation du Hackathon Vinci Energies
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Récupération des cartes Semtech
* Présentation du Hackathon
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Récupération et prise en main des cartes Semtech LoRaMote
* Présentation du Hackathon Vinci Energies
|-
| rowspan="1" | Jeudi 01/02/18
| style="width: 225px;" |
* Choix des fonctionnalités de l'application mobile
| style="width: 225px;" |
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Prise en main des cartes LoRa
|-
| rowspan="1" | Vendredi 02/02/18
| style="width: 225px;" |
* Réflexions sur l'implémentation de l'application
* Démarrage de l'application mobile
* Mises à jour d'Ionic, de Android Studio
| style="width: 225px;" |
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Premières communications fructueuses des cartes Semtech LoRaMote
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 2
|-

|-
| rowspan="1" | Lundi 05/02/18
| style="width: 225px;" |
* Configuration Login et Mot de Passe, Identification base
| style="width: 225px;" |
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Réflexion et création de la base de données
|-
| rowspan="1" | Mardi 06/02/18
| style="width: 225px;" |
* Configuration Login, Mot de passe
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
| style="width: 225px;" |
* Création de l'API REST EN PHP
|-
| rowspan="1" | Mercredi 07/02/18
| style="width: 225px;" |
* Réunion avec Rémi CHOLLET et 3 PEIP D
* Assimilation du fonctionnement de Leaflet
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
| style="width: 225px;" |
* Réunion avec Rémi CHOLLET et 3 PEIP D
* Création de l'API REST en PHP
|-
| rowspan="1" | Jeudi 08/02/18
| style="width: 225px;" |
* Ajout de marqueurs sur Leaflet
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
| style="width: 225px;" |
* Création de l'API REST EN PHP
|-
| rowspan="1" | Vendredi 09/02/18
| style="width: 225px;" |
* Hackathon Vinci Energies
| style="width: 225px;" |
* Hackathon Vinci Energies
| style="width: 225px;" |
* Hackathon Vinci Energies
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 3
|-

|-
| rowspan="1" | Lundi 12/02/18
| style="width: 225px;" |
* Préparation Soutenance
| style="width: 225px;" |
* Mise en place d'un Contiki/Cooja pour faciliter le développement
| style="width: 225px;" |
* Préparation Soutenance
|-
| rowspan="1" | Mardi 13/02/18
| style="width: 225px;" |
* Mise à jour de AIR
* Préparation Soutenance
* Répétition soutenance
| style="width: 225px;" |
* Préparation Soutenance
* Répétition soutenance
* Mise en place d'un Contiki/Cooja pour faciliter le dévelloppement
| style="width: 225px;" |
* Préparation Soutenance
* Répétition soutenance
|-
| rowspan="1" | Mercredi 14/02/18
| style="width: 225px;" |
*
| style="width: 225px;" |
*
| style="width: 225px;" |
*
|-
| rowspan="1" | Jeudi 15/02/18
| style="width: 225px;" |
*
| style="width: 225px;" |
*
| style="width: 225px;" |
*
|-
| rowspan="1" | Vendredi 16/02/18
| style="width: 225px;" |
*
| style="width: 225px;" |
*
| style="width: 225px;" |
*
|-
| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 4
|-

|-
| rowspan="1" | Lundi 26/02/18
| style="width: 225px;" |
| style="width: 225px;" |
| style="width: 225px;" |
|-
| rowspan="1" | Mardi 27/02/18
| style="width: 225px;" |

| style="width: 225px;" |

| style="width: 225px;" |

|-
| rowspan="1" | Mercredi 28/02/18
| style="width: 225px;" |
*
| style="width: 225px;" |
*
| style="width: 225px;" |
*
|-
| rowspan="1" | Jeudi 01/03/18
| style="width: 225px;" |
*
| style="width: 225px;" |
*
| style="width: 225px;" |
*
|-
| rowspan="1" | Vendredi 03/03/18
| style="width: 225px;" |
*
| style="width: 225px;" |
*
| style="width: 225px;" |
*
|-
|}

=Collaboration avec le DUT RT et les PEIPs D=
L'objectif de cette collaboration est de familiariser des étudiants en PEIP D avec des projets qu'ils seront amenés à développer dans les prochaines années. Nous avons rencontré Rémi CHOLLET et 3 étudiants Mercredi 7 Février, en voici un résumé écrit par Mr CHOLLET définissant les contours de cette collaboration.

"Un rapide résumé de la rencontre que nous avons eu ce matin avec le projet R’Montagne.

Présents :
- RCIM5 Gwenael Moreau, Hugo Amodru-Favin
- PEIP-D : Yoann Goma-Missamou, Vincent Cadoux, Philippe Charrat
- IUT : Rémy Chollet, tuteur pédagogique des PEIP-D
Excusés : Didier Donsez, blessé (aie ! courage …), Antoine Delise en cours de marketing

Contexte :
Les PEIP-D participent aux projets RICM5 en prenant une tâche « annexe » (hors chemin critique) en charge. L’objectif est une expérience d’immersion + notation liée au PEIP.

Déroulé :
Les étudiant RCIM5 ont présenté le projet dans son principe et état d’avancement. Les échanges se sont portés sur l’idée de mener une étude (simulation et mesure) sur la consommation des balises par les PEIP-D avec pour objectif de dimensionner la réserve d’énergie.

Ceci implique :
- coté RCIM5 : mise à disposition d’une carte prototype.

- cote PEIP-D : inventaire des paramètres à prendre en compte :
* consommation carte (GPS + puce LoRa) = > veille + temps d’activation (recherche à faire sur le temps de synchronisation du GPS)
* puissance d’émission à calibrer en fonction de la couverture voulue et débit (voir Spread Factor ?)
* temps d’émission-réception (émission jusqu’à acquittement)

- cote PEIP-D : penser la manip pour valider ce modèle
* mesure moyenne du courant
* configuration effective du réseau
* réserver le matériel (voir Jean-Yves Frau au département R&T ?)

- cote PEIP-D : paramètrer les simulations et mesures en fonction de puissance d’émission (ou autre élément pouvant apparaitre comme pertinent)

D’une manière générale, pour les PEID-D :
- penser bibliographie (pour commencer : https://fr.wikipedia.org/wiki/LoRaWAN et aussi https://fr.wikipedia.org/wiki/Format_des_piles_et_accumulateurs_électriques :-) )
- planifier
- communiquer : reporting !!!"

=Description du sujet=

==Randonnée et risques==

Ouvert à tous, la randonnée est un sport et un loisir qui prend de plus en plus d’ampleur de nos jours. Ne nécessitant pas de grands prérequis, des milliers de personnes se lancent en montagne chaque jour, malheureusement parfois sans connaître toutes les mesures de sécurité associées.

En effet, de janvier à juin 2016, en randonnée et en alpinisme, l’Association Nationale pour l’Étude de la Neige et des Avalanches (ANENA) a comptabilisé 21 accidents notables, dont 8 accidents mortels, impliquant 15 décès.

Aujourd’hui, les mesures de sécurités préconisent que chaque groupe de randonneur se doivent de se munir d’un téléphone portable afin d’appeler les secours en cas de problème. Malheureusement, la communication mobile dépendant de la couverture réseau, peu présente en montagne, l’impossibilité de joindre les secours reste un problème.

==Solutions existantes==

La solution la plus répandue, est celle du téléphone à connexion satellite. Ayant une communication vers les satellites, cela permet une couverture réseau beaucoup plus répandue dans les montagnes, partout dans le monde (ou presque). Cependant, les téléphones portables satellitaires coûtent chers, et ne sont pas forcément abordables par la plupart des personnes, surtout celles ne sortant qu’occasionnellement.

[https://fall-alarm.net/ Fall Alarm] est un système de détection de chute sur chantier utilisant les mêmes technologies dont nous avons besoin pour notre projet.

==Quelles zones géographiques ?==

Toutes les zones montagneuses peuvent présenter des zones blanches, démunies de connexion quelconque autre que les connexions satellitaires. Certaines chaînes de montagne comme la Cordillaire des Andes ne présentent aucune connexion possible quelconque.

Dans le cadre de notre projet, nous fonctionnerons essentiellement dans la localisation grenobloise avec l'objectif que notre solution soit applicable partout dans le monde. Une contrainte intervient tout de même étant donnée que la fréquence d'utilisation du LoRa en Europe est de 868MHz, 915MHz en Amérique et 433MHz en Asie.

= Fonctionnalités =

Afin de remplir au mieux ses attentes, le principal objectif de ce dispositif sera premièrement de pouvoir communiquer avec les secours à n’importe quel moment, et surtout n’importe où. De plus, il sera capable de détecter de nombreux cas de détresse de la part de l’usager afin de pouvoir lancer un appel d’urgence sans interaction avec l’usager, au cas où il serait inconscient, ou incapable de lancer un appel manuel.

Grâce aux accéléromètres, le dispositif sera à même de détecter un mouvement brutal du randonneur, ce qui pourrait s’apparenter à une chute. Ils pourront également détecter une position anormale, ou une immobilité prolongée, ce qui déclencherait le dispositif d’urgence automatiquement.

Grâce à des tests réalisés au préalable, le boîtier pourra détecter correctement les chûtes de simples mouvements, afin de ne pas lancer l’appel sans raison valable.

Avant de lancer une alerte automatique, le dispositif émettra un signal auditif et visuel à l’utilisateur quelques secondes auparavant, afin de le prévenir l'émission du signal d’urgence, et de lui proposer de le désactiver sur simple pression d’un bouton, afin d’éviter les communications inutiles.

Également, le randonneur sera à même d'émettre volontairement un appel d’urgence à l’aide du bouton, ce qui permet à tout moment d’appeler de l’aide sans effort. Cela peut permettre également à appeler les secours pour une personne en danger qui ne porterait pas le dispositif.

L’appel au secours se représente par un envoi de coordonnées GPS aux secours, via une communication radio LoRa vers des bornes relais placées au préalables en montagne. Cette communication irait de relai de relai jusqu’au centre de sécurité, d’où le message serait transmis aux secours.

De plus, une application mobile verra le jour afin de connecter tous les utilisateurs du module de sécurité, de les visualiser sur une map, et de partager leurs données. En effet, à chaque incident, l’application mettra à jour la position et de la date de l’accident, afin de permettre aux prochains utilisateurs d’être prévenus. Ils pourraient, s'ils sont à proximité, d'assister la personne en détresse en attendant l'arrivée des secours. Bien évidemment, cette application ne sera accessible uniquement si le smartphone de l'utilisateur est relié à une connexion 4G ou Wi-Fi.

Cette prévention pourrait les sensibiliser aux risques de la montagne, leur permettre d’éviter le secteur mais aussi d’aider les personnes en danger si la distance le permet.

= Exigences =
== Fonctionnelles ==

*Batterie garantie fonctionnelle 1 semaine
*Rechargement possible via le panneau solaire portable
*Dispositif pouvant être allumé et éteint par l'utilisateur
*Alarme s’enclenche automatiquement dès qu'elle est considérée nécessaire, signal sonore
*Utilisateur a la possibilité d’activer/désactiver l’alarme quand il le souhaite
*Lorsque l’alarme est active, l’appareil ne peut s’éteindre
*...

== Non-Fonctionnelles ==

*Résistance : aux chocs, impacts, waterproof (utilisé en permanence en plein air)
*Disponibilité : Appareil de secours -> Doit être au plus possible performant
*Performance : Minimiser les pertes réseaux
*Accessible : Utilisateur pas forcément familier avec des appareils électroniques (facile d’utilisation)
*Fiabilité : Précision du GPS (rayon de 10m), données non-éronnées
*Coût : Le plus faible possible pour vendre le moins cher possible
*Efficacité : Réduire la consommation, utiliser le moins possible les ressources

= Composants =
== LoRaONE ==
Pour le coeur du projet, après avoir cherché et comparés plusieurs modules LoRa, GPS ou encore accéléromètres, nous avons finalement opté pour le projet LoRaONE.

LoRaONE est un projet de SODAQ regroupant plusieurs composants dans une seule et même carte, de taille réduite.

https://www.kickstarter.com/projects/sodaq/loraone-the-lora-iot-development-board

“The one IoT development board to rule them all” --SODAQ

Cette carte regroupe plusieurs capteurs afin de respecter aux mieux nos exigences :

Un émetteur/récepteur LoRa afin de pouvoir communiquer au mieux avec les antennes relai à longue distance

Un module + antenne GPS de bonne précision (< 10m) pour connaître en tout temps notre position, et ainsi faciliter l’arrivée des secours, ainsi que la recherche de l’individu en détresse

Un accéléromètre sur 3 axes afin de pouvoir détecter tout mouvement, vitesse ou rotation dans l’espace, ce qui permet la détection de chutes ou d’arrêt de mouvements

3 LED RGB afin de pouvoir signaler à l’utilisateur un manque de batterie, un signal d’urgence ou plus si nécessaire

Un bouton poussoir pour le signal d’alarme

Un connecteur de charge par panneau solaire, afin de faire durer chaque batterie le plus longtemps possible

Un connecteur micro-USB ainsi que des lignes pour se connecter à une base Arduino si besoin

[[File:LoRaOne.png||400px|Spécifications carte LoRaOne]]

De plus, grâce au starter pack, nous pouvons avoir accès à la base ONEBase qui nous permettrait d’étendre plus loin la facilité d’utilisation du produit :

[[File:LoRaOneBase.png||400px|Spécifications base LoRaOneBase]]

Comme nous pouvons le voir, cette base nous permettra de connecter la batterie ainsi que le panneau solaire qui sont fournis dans le pack.

Nous pourrons également connecter jusqu’à 4 modules supplémentaires.

La batterie fournie aura une capacité de 800 mAh, le panneau solaire fourni pouvant délivrer jusqu’à 500 mW de puissance.

Le total atteint une taille d’environ 10*5 cm, ce qui n’est pas excessif, ce qui le rend aisément portatif sur une jambe ou à la taille.

'''Coût : 115€'''

Ce module pourra également servir d’antenne relai, l'alimentation solaire devrait maintenir le dispositif chargé en permanence. Des tests seront effectués pour savoir si un panneau solaire plus puissant est requis.

== Boîtier ==

Le boîtier sécurisé devant respecter plusieurs exigences, nous pouvons le construire en plastique résistant, ce qui le rendrait léger tout en respectant une rigidité suffisante. Les antennes pourront être placées le long du boîtier, à l’intérieur si la connexion est suffisante, ou à l’extérieur. Dans ce dernier cas les trous réalisés sur le boîtier afin de laisser passer les câbles seront colmatés afin de garantir une étanchéité.

[[File:SchemaBoitier.png||100px|Schéma boitier d'alarme]]

== Balises ==

Afin de remonter les informations transmises par les boitiers, des balises seront mises en places sur la zone à couvrir, leur nombre et leur positions dépendra du terrain (obstacles, dénivelés). On distinguera deux types de balises. Tout d’abord, les balises racines qui permettront une communication GSM afin de faire remonter les données vers le serveur. Viennent ensuite les balises standard qui se contenteront de faire remonter vers leur balise racine associée. L’architecture de liaison des balises est détaillée dans une prochaine partie.

Chaque balise est composée d’une barre de fer pouvant être plantée dans le sol, d’un système de lest afin d’immobiliser la balise, d’un paratonnerre, d’un panneau solaire ainsi que d’un LoraOne et d’une batterie. Les balises racines seront équippée en plus d’un dispositif de communication GSM (téléphone portable, émetteur GSM).

[[File:SchemaBalise.png||150px|Schéma balises d'alarme]]

== Application mobile ==
Une application mobile est téléchargeable par les utilisateurs. Ils peuvent voir les autres utilisateurs présents dans leur zone. Lorsqu’un utilisateur est en position de danger, une notification apparaît si les utilisateurs sont proches de la situation de danger.

Cette application n’est pas directement reliée au dispositif. Elle ne fonctionne qu’avec la connexion du mobile, et est destinée à être un niveau de sécurité supérieur. Un randonneur proche d’une zone de danger pourrait arriver sur place plus rapidement que les secours.

= Communication =

Pour un envoi de position + numéro d’identification (X chiffres) :

*Temps de communication : < 2 s
*Communication régulière, intervalle de 15 minutes

On peut donc au maximum avoir 15 * 60 / 2 = 450 individus pouvant communiquer avec la même antenne relai, donc dans le même cercle d’environ 15 km de diamètre.

On communique donc au minimum 2 secondes sur 15 minutes, donc 1/450 << 1%, le temps de communication est respecté.

En cas de problème, nous pouvons envoyer jusqu’à 9x plus avec la borne sans dépasser le temps de communication autorisé (1%). Donc 1 envoi d’appel d’urgence toutes les 2 minutes environ.

La balise racine peut être directement connectée au serveur, dans ce cas, il n’y a pas de communication GSM nécessaire et pas de Gateway. Si la racine n’est pas directement connectée au serveur, elle devra au minimum garantir une communication GSM (ce qu’elle peut faire, il n’y a pas de Gateway nécessaire) pour remonter l’information vers le serveur, et donc la base de données.

GSM : Si Racine connectée à Serveur -> No GSM + Gateway
Else : GSM + Gateway : LoRa Racine connectée ordi (RaspberryPI) + ordi connecté GSM

= Stabilisation et gestion d’erreurs =

== Choix du routage ==

Notre réseau n'est pas un réseau traditionnel. Les seules communications existantes sont soit une remontée d'information vers la racine soit une innondation d'alerte vers les clients. Pour celà nous avons donc décidé d'utiliser un algorithme de routage simplifié basé uniquement sur un arbre en largeur des balises. Nous rajoutons en option la possibilité de créer plusieurs racines et donc plusieurs arbres dont les racines communiquent par gsm. Nous nous basons sur des papiers de recherches afin de déterminer quel algorithme auto-stabilisant est le plus adapté au système LoRa (Tel que le papier "A self-stabilizing algorithm for constructing breadth-first trees" par Shing-Tsaan Huang, Nian-Shing Chen).

== Stabilisation ==

Afin de gérer la communication de chaque message vers le serveur, nous allons prendre un noeud (balise LoRa) dit “racine” connecté directement au serveur, nous ne nous occuperons pas de la communication au serveur dans cet onglet. Chaque message reçu de la part d’un noeud du système doit être relayé jusqu’à la racine du système afin de communiquer avec les secours (ou serveur simplement).

Pour cela, il faudra assurer que chaque balise LoRa soit connecté au réseau, afin d’avoir au départ un graphe de communication connexe. Par dessus ce graphe, nous allons utiliser un processus silencieux auto-stabilisant qui construira un arbre de parcours en largeur, avec pour racine le noeud “racine” décidé ci-dessus.

Au lancement du système, il faut prévoir un léger temps de stabilisation, qui dépendrait de l’algorithme et de la taille du graphe (nombre de balises). Cependant, après cela, l’algorithme assure un arbre en profondeur minimal qui nous permettrai de communiquer avec la racine le plus rapidement possible, et donc une qualité de service maximale.

== Gestion d’erreurs ==

Dans un réseau comme celui-ci, plusieurs types d’erreurs peuvent se produire :
Délai de communication trop important vers une balise
“Crash” d’une balise de communication
Surpopulation d’une balise ou congestion de messages

Afin de palier au premier type d’incident rencontré, il faut nécessairement qu’à chaque emplacement dans la zone couverte, l’utilisateur soit à même de communiquer avec au minimum 2 balises différentes. Ainsi, dans le cas d’une communication trop longue sur une balise, l’autre aurait de grandes chances de délivrer le message plus rapidement.

Au niveau de la défaillance d’une balise, l’algorithme d’arbre en profondeur nous fournit déjà une solution intégrée grâce à son auto-stabilisation. Dans le cas de déconnexion d’une balise, l’algorithme mettrai à jour automatiquement l’arbre de communication, et n’importe quel message d’alerte émis serait délivré dans un délai raisonnable.

Pour le troisième cas d’erreur, il n’y aurait pas de solution réelle, si ce n’est de limiter le nombre de communications données, en ne prenant plus en compte les “ping” de chaque utilisateur mais seulement les messages d’alertes, ce qui permettrai une bien plus grande gestion de la congestion à un endroit donné. Également, une balise en dessous d’un lien congestionné pourrait communiquer avec ses autres voisins (non-fils dans l’arbre) afin de libérer de l’espace dans le lien avec son père dans l’arbre. Également, le système ne pourra accepter que jusqu’à 1000 utilisateurs par noeud, et également 4000 utilisateurs par cluster (dans le cas d’un réseau avec plusieurs clusters donc plusieurs racines cette limite augmente).

Plusieurs types de paquets circulent sur le réseau de balise:
Les pings, messages envoyés spontanéments à intervalle régulier par les utilisateur contenant l’id ainsi que les deux coordonées gps (27 bits chacun)
Les incidents, identique à un ping mais à priorité haute.
Les alertes, messages brodcastés par le serveur afin d’envoyer un message en chaine de caractères courts et compressés.

=Coûts matériels=

Que ce soit pour le dispositif utilisateur ou la balise (racine ou non), le LoRaOne correspond pour permettre les actions recherchées. Afin de réaliser un prototype pertinent, 6 kits LoRaOne sont requis. Ces kits sont accessibles sur le site de Sodaq au prix de 115€ chacun (prix variable).
Disponible [https://shop.sodaq.com/en/one-eu-rn2483-v2.html ici], voir avant dernier bundle : starter "ONE EU starter" actuellement à 112,10€.

Un [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer buzzer] est à ajouter au dispositif utilisateur afin de lui délivrer un signal sonore.

Un shield GSM est requis pour que la balise racine communique avec l'extérieur. Sodaq en propose un designé pour fonctionner sur leurs produits mais est éctuellement en rupture de stock. Un shield GSM arduino convient tout autant et peut être trouvé sur le site arduino [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna ici].

Aucun boitier ne sera commandé car nous avons fait le choix de les manufacturer nous même au fablab. Le besoin d'étanchéité n'est pas primordial pour notre prototype, bien que nous tenterons de l'assurer.

{|class="récap commande"
|+ Récapitulatif
|-
|
!scope="col" style="width: 320px;"| Produit
!scope="col" style="width: 80px;"| Lien
!scope="col" style="width: 80px;"| Quantité
!scope="col" style="width: 80px;"| Prix Unitaire
|-

!scope="row"| 1
| LoRaOne EU Starter
| [https://shop.sodaq.com/en/one-eu-rn2483-v2.html Achat]
| 6
| 115€
|-

!scope="row"| 2
| Buzzer
| [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer Achat]
| 3
| 5.49€
|-

!scope="row"| 3
| Shield GSM
| [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna Achat]
| 1
| 65€
|-

|}

=Développement=

Nous utiliserons les librairies standards Arduino ainsi que celle de SODAQ/Arduino pour le LoRa.

L'IDE Arduino sera utilisé, plus pratique pour l'utilisation de Git (comparé à Mbed).

= Mise sur le marché =

Ce dispositif a pour but d’être utilisé en montagne, lors de randonnée. Il n’est pas destiné à un usage quotidien, c’est pourquoi nous considérons qu’il est plus judicieux de louer les dispositifs plutôt que de les vendre, même si l’achat n’est pas à omettre de notre stratégie.

Le dispositif peut être commandé en ligne, puis retourné par la poste après usage. Le client louerait le dispositif pour une certaine durée avec un possible nombre supplémentaire de batterie. Les tarifs varient en fonction de la durée et du nombre de batteries louées. Des offres de groupes pourraient être applicables. A long terme, des boutiques pourraient être disséminées dans des grandes villes proches des zones montagneuses, zones à randonnées (Grenoble, Annecy, etc.).

L’application est téléchargeable gratuitement par quiconque, mais utilisable seulement par les clients. Un code d’accès sera envoyé avec le dispositif expirant après la fin de la location.

Il faudra tenir compte de la bande passante du LoRa, variante en fonction des continents.

=Planning prévisonnel=

Sprint 1 : 29/01 --> 09/02 : Création du prototype logiciel #1
*Prise en main du matériel
*Premiers tests de transmissions LoRa
*Création du protocole d'architecture des balises
*Application sur les cartes et tests
*Tests de performances des cartes (durabilité, chargement, batterie)
*Tests de maintenabilité de l'algorithme (déconnexions, latences)

Sprint 2 : 12/02 --> 23/02 : Prototype logiciel #2 et prototype matériel
*Création du programme embarqué (utilisateur)
*Communication avec la racine et le serveur
*Création des maquettes boîtier et balise
*Construction des maquettes
*Finalisation du premier prototype

Sprint 3 : 26/02 --> 09/03 : Fonctionnalités supplémentaires
*Ajout de la communication entre le LoRa et le GSM sur la balise racine
*Création application mobile utilisateur
*Tests sur l'application
*Tests sur la transmission totale depuis l'utilisateur vers le serveur via le GSM
*Finalisation du projet

Sprint 4 : 12/03 --> 16/03 : Fin du projet
*Création de la documentation finale (à partir de la documentation réalisée en continu)
*Pause café
*Temps supplémentaire en cas de problèmes importants
*Préparation de la soutenance

R'Montagne

2018-03-02T11:35:26Z

Hugo.Amodru-Favin: /* Journal */

=Équipe=
{|class="wikitable"
|-
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Rôle
|-
| Hugo Amodru-Favin
| Chef de Projet
|-
| Antoine Delise
| Lead Developer
|-
| Gwenaël Moreau
| Kanban Master
|-

|}

==Tâches==

Répartition générale des tâches
{|class="wikitable"
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Tâche
|-
| Hugo Amodru-Favin
| Application Ionic
|-
| Antoine Delise
| Développement Arduino
|-
| Gwenaël Moreau
| BDD - API
|-

|}

Détail des tâches : [https://waffle.io/delisea/R-Montagne Waffle.io]

=Journal=

{|class="wikitable"
|+
|-
!scope="col" width="120px"| Date
!scope="col"| Hugo AMODRU-FAVIN
!scope="col"| Antoine DELISE
!scope="col"| Gwenaël MOREAU
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 1
|-

|-
| rowspan="1" | Lundi 29/01/18
| style="width: 225px;" |
* Ré-assimilation du sujet
| style="width: 225px;" |
* Ré-assimilation du sujet
| style="width: 225px;" |
* Ré-assimilation du sujet
* Mise en place d'un Kanban
|-
| rowspan="1" | Mardi 30/01/18
| style="width: 225px;" |
* Mise à jour de la page AIR
* Réflexions sur l'implémentation du LoRa
| style="width: 225px;" |
* Mise à jour de la page AIR
* Réflexions sur l'implémentation du LoRa
| style="width: 225px;" |
* Mise en place du calendrier prévisionnel
* Définition et répartition des tâches
|-
| rowspan="1" | Mercredi 31/01/18
| style="width: 225px;" |
* Récupération des cartes Semtech
* Présentation du Hackathon Vinci Energies
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Récupération des cartes Semtech
* Présentation du Hackathon
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Récupération et prise en main des cartes Semtech LoRaMote
* Présentation du Hackathon Vinci Energies
|-
| rowspan="1" | Jeudi 01/02/18
| style="width: 225px;" |
* Choix des fonctionnalités de l'application mobile
| style="width: 225px;" |
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Prise en main des cartes LoRa
|-
| rowspan="1" | Vendredi 02/02/18
| style="width: 225px;" |
* Réflexions sur l'implémentation de l'application
* Démarrage de l'application mobile
* Mises à jour d'Ionic, de Android Studio
| style="width: 225px;" |
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Premières communications fructueuses des cartes Semtech LoRaMote
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 2
|-

|-
| rowspan="1" | Lundi 05/02/18
| style="width: 225px;" |
* Configuration Login et Mot de Passe, Identification base
| style="width: 225px;" |
* Prise en main des cartes LoRa
| style="width: 225px;" |
* Réflexion et création de la base de données
|-
| rowspan="1" | Mardi 06/02/18
| style="width: 225px;" |
* Configuration Login, Mot de passe
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
| style="width: 225px;" |
* Création de l'API REST EN PHP
|-
| rowspan="1" | Mercredi 07/02/18
| style="width: 225px;" |
* Réunion avec Rémi CHOLLET et 3 PEIP D
* Assimilation du fonctionnement de Leaflet
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
| style="width: 225px;" |
* Réunion avec Rémi CHOLLET et 3 PEIP D
* Création de l'API REST en PHP
|-
| rowspan="1" | Jeudi 08/02/18
| style="width: 225px;" |
* Ajout de marqueurs sur Leaflet
| style="width: 225px;" |
* Création d'une structure pour l'application Lora
| style="width: 225px;" |
* Création de l'API REST EN PHP
|-
| rowspan="1" | Vendredi 09/02/18
| style="width: 225px;" |
* Hackathon Vinci Energies
| style="width: 225px;" |
* Hackathon Vinci Energies
| style="width: 225px;" |
* Hackathon Vinci Energies
|-

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 3
|-

|-
| rowspan="1" | Lundi 12/02/18
| style="width: 225px;" |
* Préparation Soutenance
| style="width: 225px;" |
* Mise en place d'un Contiki/Cooja pour faciliter le développement
| style="width: 225px;" |
* Préparation Soutenance
|-
| rowspan="1" | Mardi 13/02/18
| style="width: 225px;" |
* Mise à jour de AIR
* Préparation Soutenance
* Répétition soutenance
| style="width: 225px;" |
* Préparation Soutenance
* Répétition soutenance
* Mise en place d'un Contiki/Cooja pour faciliter le dévelloppement
| style="width: 225px;" |
* Préparation Soutenance
* Répétition soutenance
|-
| rowspan="1" | Mercredi 14/02/18
| style="width: 225px;" |
*
| style="width: 225px;" |
*
| style="width: 225px;" |
*
|-
| rowspan="1" | Jeudi 15/02/18
| style="width: 225px;" |
*
| style="width: 225px;" |
*
| style="width: 225px;" |
*
|-
| rowspan="1" | Vendredi 16/02/18
| style="width: 225px;" |
*
| style="width: 225px;" |
*
| style="width: 225px;" |
*
|-
|}

| colspan="5" style="background-color:#1c531c; width:225px;"| Semaine 4
|-

|-
| rowspan="1" | Lundi 26/02/18
| style="width: 225px;" |
| style="width: 225px;" |
| style="width: 225px;" |
|-
| rowspan="1" | Mardi 27/02/18
| style="width: 225px;" |

| style="width: 225px;" |

| style="width: 225px;" |

|-
| rowspan="1" | Mercredi 28/02/18
| style="width: 225px;" |
*
| style="width: 225px;" |
*
| style="width: 225px;" |
*
|-
| rowspan="1" | Jeudi 01/03/18
| style="width: 225px;" |
*
| style="width: 225px;" |
*
| style="width: 225px;" |
*
|-
| rowspan="1" | Vendredi 03/03/18
| style="width: 225px;" |
*
| style="width: 225px;" |
*
| style="width: 225px;" |
*
|-
|}

=Collaboration avec le DUT RT et les PEIPs D=
L'objectif de cette collaboration est de familiariser des étudiants en PEIP D avec des projets qu'ils seront amenés à développer dans les prochaines années. Nous avons rencontré Rémi CHOLLET et 3 étudiants Mercredi 7 Février, en voici un résumé écrit par Mr CHOLLET définissant les contours de cette collaboration.

"Un rapide résumé de la rencontre que nous avons eu ce matin avec le projet R’Montagne.

Présents :
- RCIM5 Gwenael Moreau, Hugo Amodru-Favin
- PEIP-D : Yoann Goma-Missamou, Vincent Cadoux, Philippe Charrat
- IUT : Rémy Chollet, tuteur pédagogique des PEIP-D
Excusés : Didier Donsez, blessé (aie ! courage …), Antoine Delise en cours de marketing

Contexte :
Les PEIP-D participent aux projets RICM5 en prenant une tâche « annexe » (hors chemin critique) en charge. L’objectif est une expérience d’immersion + notation liée au PEIP.

Déroulé :
Les étudiant RCIM5 ont présenté le projet dans son principe et état d’avancement. Les échanges se sont portés sur l’idée de mener une étude (simulation et mesure) sur la consommation des balises par les PEIP-D avec pour objectif de dimensionner la réserve d’énergie.

Ceci implique :
- coté RCIM5 : mise à disposition d’une carte prototype.

- cote PEIP-D : inventaire des paramètres à prendre en compte :
* consommation carte (GPS + puce LoRa) = > veille + temps d’activation (recherche à faire sur le temps de synchronisation du GPS)
* puissance d’émission à calibrer en fonction de la couverture voulue et débit (voir Spread Factor ?)
* temps d’émission-réception (émission jusqu’à acquittement)

- cote PEIP-D : penser la manip pour valider ce modèle
* mesure moyenne du courant
* configuration effective du réseau
* réserver le matériel (voir Jean-Yves Frau au département R&T ?)

- cote PEIP-D : paramètrer les simulations et mesures en fonction de puissance d’émission (ou autre élément pouvant apparaitre comme pertinent)

D’une manière générale, pour les PEID-D :
- penser bibliographie (pour commencer : https://fr.wikipedia.org/wiki/LoRaWAN et aussi https://fr.wikipedia.org/wiki/Format_des_piles_et_accumulateurs_électriques :-) )
- planifier
- communiquer : reporting !!!"

=Description du sujet=

==Randonnée et risques==

Ouvert à tous, la randonnée est un sport et un loisir qui prend de plus en plus d’ampleur de nos jours. Ne nécessitant pas de grands prérequis, des milliers de personnes se lancent en montagne chaque jour, malheureusement parfois sans connaître toutes les mesures de sécurité associées.

En effet, de janvier à juin 2016, en randonnée et en alpinisme, l’Association Nationale pour l’Étude de la Neige et des Avalanches (ANENA) a comptabilisé 21 accidents notables, dont 8 accidents mortels, impliquant 15 décès.

Aujourd’hui, les mesures de sécurités préconisent que chaque groupe de randonneur se doivent de se munir d’un téléphone portable afin d’appeler les secours en cas de problème. Malheureusement, la communication mobile dépendant de la couverture réseau, peu présente en montagne, l’impossibilité de joindre les secours reste un problème.

==Solutions existantes==

La solution la plus répandue, est celle du téléphone à connexion satellite. Ayant une communication vers les satellites, cela permet une couverture réseau beaucoup plus répandue dans les montagnes, partout dans le monde (ou presque). Cependant, les téléphones portables satellitaires coûtent chers, et ne sont pas forcément abordables par la plupart des personnes, surtout celles ne sortant qu’occasionnellement.

[https://fall-alarm.net/ Fall Alarm] est un système de détection de chute sur chantier utilisant les mêmes technologies dont nous avons besoin pour notre projet.

==Quelles zones géographiques ?==

Toutes les zones montagneuses peuvent présenter des zones blanches, démunies de connexion quelconque autre que les connexions satellitaires. Certaines chaînes de montagne comme la Cordillaire des Andes ne présentent aucune connexion possible quelconque.

Dans le cadre de notre projet, nous fonctionnerons essentiellement dans la localisation grenobloise avec l'objectif que notre solution soit applicable partout dans le monde. Une contrainte intervient tout de même étant donnée que la fréquence d'utilisation du LoRa en Europe est de 868MHz, 915MHz en Amérique et 433MHz en Asie.

= Fonctionnalités =

Afin de remplir au mieux ses attentes, le principal objectif de ce dispositif sera premièrement de pouvoir communiquer avec les secours à n’importe quel moment, et surtout n’importe où. De plus, il sera capable de détecter de nombreux cas de détresse de la part de l’usager afin de pouvoir lancer un appel d’urgence sans interaction avec l’usager, au cas où il serait inconscient, ou incapable de lancer un appel manuel.

Grâce aux accéléromètres, le dispositif sera à même de détecter un mouvement brutal du randonneur, ce qui pourrait s’apparenter à une chute. Ils pourront également détecter une position anormale, ou une immobilité prolongée, ce qui déclencherait le dispositif d’urgence automatiquement.

Grâce à des tests réalisés au préalable, le boîtier pourra détecter correctement les chûtes de simples mouvements, afin de ne pas lancer l’appel sans raison valable.

Avant de lancer une alerte automatique, le dispositif émettra un signal auditif et visuel à l’utilisateur quelques secondes auparavant, afin de le prévenir l'émission du signal d’urgence, et de lui proposer de le désactiver sur simple pression d’un bouton, afin d’éviter les communications inutiles.

Également, le randonneur sera à même d'émettre volontairement un appel d’urgence à l’aide du bouton, ce qui permet à tout moment d’appeler de l’aide sans effort. Cela peut permettre également à appeler les secours pour une personne en danger qui ne porterait pas le dispositif.

L’appel au secours se représente par un envoi de coordonnées GPS aux secours, via une communication radio LoRa vers des bornes relais placées au préalables en montagne. Cette communication irait de relai de relai jusqu’au centre de sécurité, d’où le message serait transmis aux secours.

De plus, une application mobile verra le jour afin de connecter tous les utilisateurs du module de sécurité, de les visualiser sur une map, et de partager leurs données. En effet, à chaque incident, l’application mettra à jour la position et de la date de l’accident, afin de permettre aux prochains utilisateurs d’être prévenus. Ils pourraient, s'ils sont à proximité, d'assister la personne en détresse en attendant l'arrivée des secours. Bien évidemment, cette application ne sera accessible uniquement si le smartphone de l'utilisateur est relié à une connexion 4G ou Wi-Fi.

Cette prévention pourrait les sensibiliser aux risques de la montagne, leur permettre d’éviter le secteur mais aussi d’aider les personnes en danger si la distance le permet.

= Exigences =
== Fonctionnelles ==

*Batterie garantie fonctionnelle 1 semaine
*Rechargement possible via le panneau solaire portable
*Dispositif pouvant être allumé et éteint par l'utilisateur
*Alarme s’enclenche automatiquement dès qu'elle est considérée nécessaire, signal sonore
*Utilisateur a la possibilité d’activer/désactiver l’alarme quand il le souhaite
*Lorsque l’alarme est active, l’appareil ne peut s’éteindre
*...

== Non-Fonctionnelles ==

*Résistance : aux chocs, impacts, waterproof (utilisé en permanence en plein air)
*Disponibilité : Appareil de secours -> Doit être au plus possible performant
*Performance : Minimiser les pertes réseaux
*Accessible : Utilisateur pas forcément familier avec des appareils électroniques (facile d’utilisation)
*Fiabilité : Précision du GPS (rayon de 10m), données non-éronnées
*Coût : Le plus faible possible pour vendre le moins cher possible
*Efficacité : Réduire la consommation, utiliser le moins possible les ressources

= Composants =
== LoRaONE ==
Pour le coeur du projet, après avoir cherché et comparés plusieurs modules LoRa, GPS ou encore accéléromètres, nous avons finalement opté pour le projet LoRaONE.

LoRaONE est un projet de SODAQ regroupant plusieurs composants dans une seule et même carte, de taille réduite.

https://www.kickstarter.com/projects/sodaq/loraone-the-lora-iot-development-board

“The one IoT development board to rule them all” --SODAQ

Cette carte regroupe plusieurs capteurs afin de respecter aux mieux nos exigences :

Un émetteur/récepteur LoRa afin de pouvoir communiquer au mieux avec les antennes relai à longue distance

Un module + antenne GPS de bonne précision (< 10m) pour connaître en tout temps notre position, et ainsi faciliter l’arrivée des secours, ainsi que la recherche de l’individu en détresse

Un accéléromètre sur 3 axes afin de pouvoir détecter tout mouvement, vitesse ou rotation dans l’espace, ce qui permet la détection de chutes ou d’arrêt de mouvements

3 LED RGB afin de pouvoir signaler à l’utilisateur un manque de batterie, un signal d’urgence ou plus si nécessaire

Un bouton poussoir pour le signal d’alarme

Un connecteur de charge par panneau solaire, afin de faire durer chaque batterie le plus longtemps possible

Un connecteur micro-USB ainsi que des lignes pour se connecter à une base Arduino si besoin

[[File:LoRaOne.png||400px|Spécifications carte LoRaOne]]

De plus, grâce au starter pack, nous pouvons avoir accès à la base ONEBase qui nous permettrait d’étendre plus loin la facilité d’utilisation du produit :

[[File:LoRaOneBase.png||400px|Spécifications base LoRaOneBase]]

Comme nous pouvons le voir, cette base nous permettra de connecter la batterie ainsi que le panneau solaire qui sont fournis dans le pack.

Nous pourrons également connecter jusqu’à 4 modules supplémentaires.

La batterie fournie aura une capacité de 800 mAh, le panneau solaire fourni pouvant délivrer jusqu’à 500 mW de puissance.

Le total atteint une taille d’environ 10*5 cm, ce qui n’est pas excessif, ce qui le rend aisément portatif sur une jambe ou à la taille.

'''Coût : 115€'''

Ce module pourra également servir d’antenne relai, l'alimentation solaire devrait maintenir le dispositif chargé en permanence. Des tests seront effectués pour savoir si un panneau solaire plus puissant est requis.

== Boîtier ==

Le boîtier sécurisé devant respecter plusieurs exigences, nous pouvons le construire en plastique résistant, ce qui le rendrait léger tout en respectant une rigidité suffisante. Les antennes pourront être placées le long du boîtier, à l’intérieur si la connexion est suffisante, ou à l’extérieur. Dans ce dernier cas les trous réalisés sur le boîtier afin de laisser passer les câbles seront colmatés afin de garantir une étanchéité.

[[File:SchemaBoitier.png||100px|Schéma boitier d'alarme]]

== Balises ==

Afin de remonter les informations transmises par les boitiers, des balises seront mises en places sur la zone à couvrir, leur nombre et leur positions dépendra du terrain (obstacles, dénivelés). On distinguera deux types de balises. Tout d’abord, les balises racines qui permettront une communication GSM afin de faire remonter les données vers le serveur. Viennent ensuite les balises standard qui se contenteront de faire remonter vers leur balise racine associée. L’architecture de liaison des balises est détaillée dans une prochaine partie.

Chaque balise est composée d’une barre de fer pouvant être plantée dans le sol, d’un système de lest afin d’immobiliser la balise, d’un paratonnerre, d’un panneau solaire ainsi que d’un LoraOne et d’une batterie. Les balises racines seront équippée en plus d’un dispositif de communication GSM (téléphone portable, émetteur GSM).

[[File:SchemaBalise.png||150px|Schéma balises d'alarme]]

== Application mobile ==
Une application mobile est téléchargeable par les utilisateurs. Ils peuvent voir les autres utilisateurs présents dans leur zone. Lorsqu’un utilisateur est en position de danger, une notification apparaît si les utilisateurs sont proches de la situation de danger.

Cette application n’est pas directement reliée au dispositif. Elle ne fonctionne qu’avec la connexion du mobile, et est destinée à être un niveau de sécurité supérieur. Un randonneur proche d’une zone de danger pourrait arriver sur place plus rapidement que les secours.

= Communication =

Pour un envoi de position + numéro d’identification (X chiffres) :

*Temps de communication : < 2 s
*Communication régulière, intervalle de 15 minutes

On peut donc au maximum avoir 15 * 60 / 2 = 450 individus pouvant communiquer avec la même antenne relai, donc dans le même cercle d’environ 15 km de diamètre.

On communique donc au minimum 2 secondes sur 15 minutes, donc 1/450 << 1%, le temps de communication est respecté.

En cas de problème, nous pouvons envoyer jusqu’à 9x plus avec la borne sans dépasser le temps de communication autorisé (1%). Donc 1 envoi d’appel d’urgence toutes les 2 minutes environ.

La balise racine peut être directement connectée au serveur, dans ce cas, il n’y a pas de communication GSM nécessaire et pas de Gateway. Si la racine n’est pas directement connectée au serveur, elle devra au minimum garantir une communication GSM (ce qu’elle peut faire, il n’y a pas de Gateway nécessaire) pour remonter l’information vers le serveur, et donc la base de données.

GSM : Si Racine connectée à Serveur -> No GSM + Gateway
Else : GSM + Gateway : LoRa Racine connectée ordi (RaspberryPI) + ordi connecté GSM

= Stabilisation et gestion d’erreurs =

== Choix du routage ==

Notre réseau n'est pas un réseau traditionnel. Les seules communications existantes sont soit une remontée d'information vers la racine soit une innondation d'alerte vers les clients. Pour celà nous avons donc décidé d'utiliser un algorithme de routage simplifié basé uniquement sur un arbre en largeur des balises. Nous rajoutons en option la possibilité de créer plusieurs racines et donc plusieurs arbres dont les racines communiquent par gsm. Nous nous basons sur des papiers de recherches afin de déterminer quel algorithme auto-stabilisant est le plus adapté au système LoRa (Tel que le papier "A self-stabilizing algorithm for constructing breadth-first trees" par Shing-Tsaan Huang, Nian-Shing Chen).

== Stabilisation ==

Afin de gérer la communication de chaque message vers le serveur, nous allons prendre un noeud (balise LoRa) dit “racine” connecté directement au serveur, nous ne nous occuperons pas de la communication au serveur dans cet onglet. Chaque message reçu de la part d’un noeud du système doit être relayé jusqu’à la racine du système afin de communiquer avec les secours (ou serveur simplement).

Pour cela, il faudra assurer que chaque balise LoRa soit connecté au réseau, afin d’avoir au départ un graphe de communication connexe. Par dessus ce graphe, nous allons utiliser un processus silencieux auto-stabilisant qui construira un arbre de parcours en largeur, avec pour racine le noeud “racine” décidé ci-dessus.

Au lancement du système, il faut prévoir un léger temps de stabilisation, qui dépendrait de l’algorithme et de la taille du graphe (nombre de balises). Cependant, après cela, l’algorithme assure un arbre en profondeur minimal qui nous permettrai de communiquer avec la racine le plus rapidement possible, et donc une qualité de service maximale.

== Gestion d’erreurs ==

Dans un réseau comme celui-ci, plusieurs types d’erreurs peuvent se produire :
Délai de communication trop important vers une balise
“Crash” d’une balise de communication
Surpopulation d’une balise ou congestion de messages

Afin de palier au premier type d’incident rencontré, il faut nécessairement qu’à chaque emplacement dans la zone couverte, l’utilisateur soit à même de communiquer avec au minimum 2 balises différentes. Ainsi, dans le cas d’une communication trop longue sur une balise, l’autre aurait de grandes chances de délivrer le message plus rapidement.

Au niveau de la défaillance d’une balise, l’algorithme d’arbre en profondeur nous fournit déjà une solution intégrée grâce à son auto-stabilisation. Dans le cas de déconnexion d’une balise, l’algorithme mettrai à jour automatiquement l’arbre de communication, et n’importe quel message d’alerte émis serait délivré dans un délai raisonnable.

Pour le troisième cas d’erreur, il n’y aurait pas de solution réelle, si ce n’est de limiter le nombre de communications données, en ne prenant plus en compte les “ping” de chaque utilisateur mais seulement les messages d’alertes, ce qui permettrai une bien plus grande gestion de la congestion à un endroit donné. Également, une balise en dessous d’un lien congestionné pourrait communiquer avec ses autres voisins (non-fils dans l’arbre) afin de libérer de l’espace dans le lien avec son père dans l’arbre. Également, le système ne pourra accepter que jusqu’à 1000 utilisateurs par noeud, et également 4000 utilisateurs par cluster (dans le cas d’un réseau avec plusieurs clusters donc plusieurs racines cette limite augmente).

Plusieurs types de paquets circulent sur le réseau de balise:
Les pings, messages envoyés spontanéments à intervalle régulier par les utilisateur contenant l’id ainsi que les deux coordonées gps (27 bits chacun)
Les incidents, identique à un ping mais à priorité haute.
Les alertes, messages brodcastés par le serveur afin d’envoyer un message en chaine de caractères courts et compressés.

=Coûts matériels=

Que ce soit pour le dispositif utilisateur ou la balise (racine ou non), le LoRaOne correspond pour permettre les actions recherchées. Afin de réaliser un prototype pertinent, 6 kits LoRaOne sont requis. Ces kits sont accessibles sur le site de Sodaq au prix de 115€ chacun (prix variable).
Disponible [https://shop.sodaq.com/en/one-eu-rn2483-v2.html ici], voir avant dernier bundle : starter "ONE EU starter" actuellement à 112,10€.

Un [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer buzzer] est à ajouter au dispositif utilisateur afin de lui délivrer un signal sonore.

Un shield GSM est requis pour que la balise racine communique avec l'extérieur. Sodaq en propose un designé pour fonctionner sur leurs produits mais est éctuellement en rupture de stock. Un shield GSM arduino convient tout autant et peut être trouvé sur le site arduino [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna ici].

Aucun boitier ne sera commandé car nous avons fait le choix de les manufacturer nous même au fablab. Le besoin d'étanchéité n'est pas primordial pour notre prototype, bien que nous tenterons de l'assurer.

{|class="récap commande"
|+ Récapitulatif
|-
|
!scope="col" style="width: 320px;"| Produit
!scope="col" style="width: 80px;"| Lien
!scope="col" style="width: 80px;"| Quantité
!scope="col" style="width: 80px;"| Prix Unitaire
|-

!scope="row"| 1
| LoRaOne EU Starter
| [https://shop.sodaq.com/en/one-eu-rn2483-v2.html Achat]
| 6
| 115€
|-

!scope="row"| 2
| Buzzer
| [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer Achat]
| 3
| 5.49€
|-

!scope="row"| 3
| Shield GSM
| [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna Achat]
| 1
| 65€
|-

|}

=Développement=

Nous utiliserons les librairies standards Arduino ainsi que celle de SODAQ/Arduino pour le LoRa.

L'IDE Arduino sera utilisé, plus pratique pour l'utilisation de Git (comparé à Mbed).

= Mise sur le marché =

Ce dispositif a pour but d’être utilisé en montagne, lors de randonnée. Il n’est pas destiné à un usage quotidien, c’est pourquoi nous considérons qu’il est plus judicieux de louer les dispositifs plutôt que de les vendre, même si l’achat n’est pas à omettre de notre stratégie.

Le dispositif peut être commandé en ligne, puis retourné par la poste après usage. Le client louerait le dispositif pour une certaine durée avec un possible nombre supplémentaire de batterie. Les tarifs varient en fonction de la durée et du nombre de batteries louées. Des offres de groupes pourraient être applicables. A long terme, des boutiques pourraient être disséminées dans des grandes villes proches des zones montagneuses, zones à randonnées (Grenoble, Annecy, etc.).

L’application est téléchargeable gratuitement par quiconque, mais utilisable seulement par les clients. Un code d’accès sera envoyé avec le dispositif expirant après la fin de la location.

Il faudra tenir compte de la bande passante du LoRa, variante en fonction des continents.

=Planning prévisonnel=

Sprint 1 : 29/01 --> 09/02 : Création du prototype logiciel #1
*Prise en main du matériel
*Premiers tests de transmissions LoRa
*Création du protocole d'architecture des balises
*Application sur les cartes et tests
*Tests de performances des cartes (durabilité, chargement, batterie)
*Tests de maintenabilité de l'algorithme (déconnexions, latences)

Sprint 2 : 12/02 --> 23/02 : Prototype logiciel #2 et prototype matériel
*Création du programme embarqué (utilisateur)
*Communication avec la racine et le serveur
*Création des maquettes boîtier et balise
*Construction des maquettes
*Finalisation du premier prototype

Sprint 3 : 26/02 --> 09/03 : Fonctionnalités supplémentaires
*Ajout de la communication entre le LoRa et le GSM sur la balise racine
*Création application mobile utilisateur
*Tests sur l'application
*Tests sur la transmission totale depuis l'utilisateur vers le serveur via le GSM
*Finalisation du projet

Sprint 4 : 12/03 --> 16/03 : Fin du projet
*Création de la documentation finale (à partir de la documentation réalisée en continu)
*Pause café
*Temps supplémentaire en cas de problèmes importants
*Préparation de la soutenance

Projets 2017-2018

2018-02-14T08:22:41Z

Hugo.Amodru-Favin: /* Affectations */

<<[[Projets 2016-2017]] | [[Projets]] | [[Projets 2018-2019]]>>
=RICM=
==RICM3==

==RICM4==
===Projet Semestre S8===

Enseignants responsables : Olivier Richard, Didier Donsez

* Dates : Lundi après-midi, Mardi après-midi
* Lancement: 15/01/2018 en 257 à 15h45
* Soutenance: A définir
* Soutenance à mi-parcours: A définir

* '''Evaluation à mi-parcours le lundi/mardi ???''': Format: 10min (5min de présentation 3 slides au plus, 5min de discussion). Cette évaluation sera prise en compte dans la note finale.

'''Consignes générales:'''

* '''Vous devez être pro-actifs !!!''': Si des points sont pas ou mals spécifiés, vous le faîtes et vous justifiez vos choix. Pour les problèmes techniques éventuels vous pouvez: creuser la question, contacter l'auteur du code si il y a lieu, écrire un rapport de bug ('''Attention:''' ca se prépare !), soumettre un patch/pull request, contacter l'enseignant ou la personne référente du projet.

* '''Vous devez maintenir une fiche de suivi de projet''': elle doit être mise à jour chaque semaine, elle rassemble les élements essentiels du projet, elle indique les évolutions du projet et présente sa feuille de route. '''Note:''' le nom de la fiche doit être composé du nom du projet et suffixé par ricm4_2017_2018. '''Cette fiche compte pour la note finale'''

* '''Votre code''' pour doit être hébergé sur le gitlab et à l'URL suivante https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18 , vous utiliserez votre compte UGA.

* Les documents public doivent être rédigés en anglais (README, documentation, commentaires de code, nom de variables et de fonctions). Une bonnification sera accordée si le rapport et les transparents sont en anglais (la soutenance sera en francais).

'''Propositions de projets:'''

# [[QCM C2I]] , Pierre Gillois, Didier Donsez
# [[Dashboard pour gestionnaire de tâches]] (Angular 5): Olivier Richard
# [[Moteur de workflows distribué]] (WDL/Cromwell): Olivier Richard
# [[ESP32 et language D]]: Olivier Richard
# [[Serious game multi-joueurs pour tables tactiles en réseau]] : Didier Donsez, Anne-Laure Finkel, Stéphanie Diligent.
# [[Challenge OpenCity]] : Georges-Pierre Bonneau, Didier Donsez
# Projet [[UltraTeam]] avec des trackers [[ESP32-LoRa]] + GPS : Reprise partielle du projet eCOM de gestion des courses sportives et du projet [[UltraTeam]] 2017 pour la partie backend et frontend du projet : Didier Donsez
# Projet [[Réseau Social LoRa]] avec des pods [[ESP32-LoRa]] : Olivier Richard.
# Contribution et evaluation au/du projet [https://github.com/IntelLabs/hpat HPAT] (A compiler-based big data framework in Python): Olivier Richard.
# [[Ruche connectée LoRa]] : Nicolas Palix
# [[Serres connectées]] : Nicolas Palix
# [[I-Greenhouse]] : [[Serre connectée aquaponie]] : Nicolas Palix
# Projet "Plateforme de mise en relation pour les entrepreneurs sociaux" : Didier Donsez
# [[Chatbot pour borne d'accueil handicap]] : Didier Donsez, Marie-Paule Balicco et Jérôme Maisonnasse (service accueil handicap COMUE UGA)
# Connected Shop (avec [[Eclipse SmartHome]]) : Didier Donsez.
# [[Deploiment Nucleo | Déploiement sécurisé et sans fil pour carte Nucleo]]: Olivier Richard et Sylain Toru
# [[RobAIR]] : Cobot Majordome : Jérôme Maisonnasse, Germain Lemasson, Bastien Scher (FabMSTIC).

==== Affectations ====
{|class="wikitable alternance"
|+ Affectation des projets RICM4 2017-2018
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Enseignant(s)
!scope="col"| Fiche de suivi
!scope="col"| Dépot git
|-

!scope="row"| 1
| [[QCM C2I]]
| NON ATTRIBUÉ
| Pierre Gillois, Didier Donsez
| [[RICM4_2017_2018_-_| Fiche]] - [[RICM4_2017_2018_-_/_SRS|SRS]] - [[RICM4_2017_2018_-_/UML | UML]]
|
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 2
| [[Dashboard pour gestionnaire de tâches]] (Angular 5)
| BELGUENDOUZ Sekina, LARNICOL Titouan
| Olivier Richard
| [[RICM4_2017_2018_-_Dashboard| Fiche]] - [[RICM4_2017_2018_-_Dashboard/_SRS|SRS]] - [[RICM4_2017_2018_-_Dashboard/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/2 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 3
| [[Moteur de workflows distribué]] (WDL/Cromwell)
| NON ATTRIBUÉ
| Olivier Richard
| [[RICM4_2017_2018_-_| Fiche]] - [[RICM4_2017_2018_-_/_SRS|SRS]] - [[RICM4_2017_2018_-_/UML | UML]]
|
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 4
| [[ESP32 et language D]]
| MANGER Raphael, HOUBRON Adrian
| Olivier Richard
| [[RICM4_2017_2018_-_ESP32_D| Fiche]] - [[RICM4_2017_2018_-_ESP32_D/_SRS|SRS]] - [[RICM4_2017_2018_-_ESP32_D/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/4 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 5
| [[Serious game multi-joueurs pour tables tactiles en réseau]]
| LEPAGE Tim, SERGEANT Dimitri
| Didier Donsez, Anne-Laure Finkel, Stéphanie Diligent
| [[RICM4_2017_2018_-SeriousGame Polystar | Fiche]] - [[RICM4_2017_2018_- SeriousGame Polystar /_SRS|SRS]] - [[RICM4_2017_2018_- SeriousGame Polystar /UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/5 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 6
| [[Challenge OpenCity]]
| BOUCHERIMA Amina, FOMBARON Quentin
| Georges-Pierre Bonneau, Didier Donsez
| [[RICM4_2017_2018_-_OpenCity| Fiche]] - [[RICM4_2017_2018_-_OpenCity/_SRS|SRS]] - [[RICM4_2017_2018_-_OpenCity/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/6 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 7.1
| Projet [[UltraTeam]] avec des trackers [[ESP32-LoRa]] + GPS
| TERRIER Bastien, GROS-DAILLON Hugo
| Didier Donsez
| [[RICM4_2017_2018_-_UltraTeam_7.1| Fiche]] - [[RICM4_2017_2018_-_UltraTeam_7.1/_SRS|SRS]] - [[RICM4_2017_2018_-_UltraTeam_7.1/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/7.1 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 7.2
| Projet [[UltraTeam]] avec des trackers [[ESP32-LoRa]] + GPS
| MOLION Enzo, VALETTE Léo
| Didier Donsez
| [[RICM4_2017_2018_-_UltraTeamMV| Fiche]] - [[RICM4_2017_2018_-_UltraTeamMV_:_SRS|SRS]] - [[RICM4_2017_2018_-_UltraTeamMV_:_UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/7.2 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 8
| Projet [[Réseau Social LoRa]] avec des pods [[ESP32-LoRa]]
| VEGREVILLE Thibaud, GENTILLON Loris, ZHENG Jian
| Olivier Richard
| [[RICM4_2017_2018_-_Réseau_Social_LoRa| Fiche]] - [[RICM4_2017_2018_-_Réseau_Social_LoRa/_SRS|SRS]] - [[RICM4_2017_2018_-_Réseau_Social_LoRa/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/8 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 9
| Contribution et evaluation au/du projet [https://github.com/IntelLabs/hpat HPAT]
| NON ATTRIBUÉ
| Olivier Richard
| [[RICM4_2017_2018_-_| Fiche]] - [[RICM4_2017_2018_-_/_SRS|SRS]] - [[RICM4_2017_2018_-_/UML | UML]]
|
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 10
| [[Ruche connectée LoRa]]
| BESNIER Benjamin, LÉVESQUE Théo, WEILL William
| Nicolas Palix
| [[RICM4_2017_2018_-_Ruche_Connectee_| Fiche]] - [[RICM4_2017_2018_-_Ruche_Connectee_/_SRS|SRS]] - [[RICM4_2017_2018_-_Ruche_Connectee/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/10 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 11
| [[Serres connectées]]
| BESNARD Guillaume, DEPRIESTER Timothée
| Nicolas Palix
| [[RICM4_2017_2018_-_Serre_Connectee| Fiche]] - [[RICM4_2017_2018_-_Serre_Connectee_/_SRS|SRS]] - [[RICM4_2017_2018_-_Serre_Connecte/UML | UML]] - [[RICM4_2017_2018_-_Serre_Connecte/Schedule | Schedule]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/11 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 12
| [[I-Greenhouse]] : [[Serre connectée aquaponie]]
| SURIER GAROFALO Aurélien, FERREIRA Joffrey, OZENDA Thomas
| Nicolas Palix
| [[RICM4_2017_2018_-_IGreenHouse| Fiche]] - [[RICM4_2017_2018_-_IGreenHouse_/_SRS|SRS]] - [[IGreenHouse/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/12 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 13
| Projet "Plateforme de mise en relation pour les entrepreneurs sociaux"
| AUBERT Vincent, COURTIAL Julien
| Didier Donsez
| [[RICM4_2017_2018_-_| Fiche]] - [[RICM4_2017_2018_-_Entrepreneur_AUBERT_COURTIAL/_SRS|SRS]] - [[RICM4_2017_2018_-_/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/13 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 14
| [[Chatbot pour borne d'accueil handicap]]
| AUCLAIR-CORDAT Julien, BAMBA Samuel
| Didier Donsez, Marie-Paule Balicco et Jérôme Maisonnasse (service accueil handicap COMUE UGA)
| [[RICM4_2017_2018_-_| Fiche]] - [[RICM4_2017_2018_-_/_SRS|SRS]] - [[RICM4_2017_2018_-_/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/14 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 15
| Connected Shop (avec [[Eclipse SmartHome]])
| CUZIN Florian, ECHEVET Théo
| Didier Donsez
| [[RICM4_2017_2018_-_| Fiche]] - [[RICM4_2017_2018_-_/_SRS|SRS]] - [[RICM4_2017_2018_-_/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/15 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 16
| [[Deploiment Nucleo | Déploiement sécurisé et sans fil pour carte Nucleo]]
| CHANET Zoran, CHARLOT Servan
| Olivier Richard, Sylain Toru
| [[RICM4_2017_2018_-_Nucleo | Fiche]] - [[RICM4_2017_2018_-_Nucleo/_SRS|SRS]] - [[RICM4_2017_2018_-_Nucleo/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/16 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 17.1
| [[RobAIR]] : Robot Majordome
| DEVOS Xavier, LAFRASSE Cédric
| Jérôme Maisonnasse, Germain Lemasson, Bastien Scher (FabMSTIC)
| [[RICM4_2017_2018_-_RobAIR17-1| Fiche]] - [[RICM4_2017_2018_-_RobAIRDL/_SRS|SRS]] - [[RICM4_2017_2018_-_RobAIRDL/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/17.1 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 17.2
| [[RobAIR]] : Robot Majordome
| JEAN Jordan, EZ-ZINE Najwa
| Jérôme Maisonnasse, Germain Lemasson, Bastien Scher (FabMSTIC)
| [[RICM4_2017_2018_-_robair2| Fiche]] - [[RICM4_2017_2018_-_robair2/_SRS|SRS]] - [[RICM4_2017_2018_-_robair2/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/17.2 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

|}

==RICM5==
===Projet IoT S9===
Enseignants responsables : Bernard Tourancheau

Calendrier: ??? Septembre à ??? Décembre 2017.

* Projet IoT 3 : [[Ski-locator]] (Bernard Tourancheau)

===Projet Semestre S10===

Enseignants responsables : Didier Donsez

Calendrier: 29 Janvier à 15 Mars 2018.

Séances de Management de projets innovants:
* Mercredi 31/01 de 8h à 12h: Stéphanie Diligent
* Mercredi 7 février de 8h à 12h : Stéphanie Diligent
* Mardi 15 février de 8h à 12 : Emmanuelle Tréhoust
* Lundi 26 février de 8h à 12h : Olivier Gilles
* Mardi 13 mars de 8h à 12h : Stéphanie Diligent et Emmanuelle Tréhoust

Réunion de présentation : 8 Janvier 2018 Matin à 9H00-10H00 (RdV Salle P257 et Salle AIR P259). Faire couler le café.

Hackathon Vinci (8,9,10/02) : http://hacktogether.vinci-energies.com/

Démarrage : Lundi 29 Janvier 2018

Soutenance à mi-parcours : Mercredi 14 Février 2018, 8H00-11H00 (30 minutes par équipe).

Soutenance (puis Pot de la fin) : Jeudi 15 Mars 2018

Vendredi 16 Mars : 10000 ans de RICM

==== Planning soutenances mi-parcours ====
Mercredi 14 Février 2018, salle P144, 8H00-11H00 (25 minutes TTC par équipe).

* 8H00-8H30 [[Real Time Subtitles 2017-2018| Real Time Subtitles]]
* 8H30-9H00 [[Deep Learning 2017-2018 | Deep Learning]]
* 9H00-9H30 [[EasyFlight]]
* 9H30-10H00 [[ Réalité virtuelle et Augmentée pour la maintenance d'usines]]
* 10H00-10H30 [[R'Montagne]]
* 10H30-11H00 [[SmartMove]]
* 11H00-11H30 [[RICM5 2017 2018 - UGAChain|UGAChain]]

==== Planning soutenances finales ====
Jeudi 15 Mars 2018
* 8H00-9H00 [[R'Montagne]] (50 minutes TTC)
* 9H00-10H00 [[SmartMove]] (50 minutes TTC)
* 10H00-11H00 (50 minutes TTC) [[ Réalité virtuelle et Augmentée pour la maintenance d'usines]]
* 11H00-12H00 (50 minutes TTC) [[RICM5 2017 2018 - UGAChain|UGAChain]] : Blockchain for Education
Pause déjeuner
* 13H00-14H00 [[Real Time Subtitles 2017-2018| Real Time Subtitles]] (50 minutes TTC)
* 14H00-15H00 [[Deep Learning 2017-2018 | Deep Learning]] (50 minutes TTC)
* 15H00-16H00 [[EasyFlight]] (50 minutes TTC)

==== Affectations ====
{|class="wikitable alternance"
|+ Affectation des projets RICM5 2017-2018
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Enseignant(s)
!scope="col"| Fiche de suivi
!scope="col"| Dépot git
|-

!scope="row"| 1
| [[Real Time Subtitles 2017-2018| Sous-titre d'un cours en temps réel]]
| '''Estelle ALLARD''' / Aymeric BROCHIER / Louis COCHINHO / Oriane DALLE / Alexandre FERRERA / Alice RIVOAL
| Didier Donsez, Laurent Besacier, François Portet, Marie-Paule Balicco, Jérome Maisonnasse
| [[Real Time Subtitles 2017-2018| Fiche]] - [[Real_Time_Subtitles_2017-2018/SRS|SRS]]
| [https://gitlab.com/LouisCochinho/RealTimeSubtitles GitLab]
| [[Media:RICM5_2017_2018_XYZ.pdf|Rapport final]] - [[Media:RICM5_2017_2018_XYZ.pdf|Presentation finale FR]] - [[Media:RICM5_2017_2018_XYZ.pdf|Final Presentation EN]] - [[Media:RICM5_2017_2018_XYZ.pdf|Flyer]] - [[Media:RICM5_2017_2018_XYZ.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 2
| [[Réalité Augmentée pour le Smart Campus 2018|Réalité Augmentée pour le Smart Campus]]
| Lucas LESAGE / '''Denis LACHARTRE''' / Douria ZENNOUCHE / Gilles BONHOURE / Maxime DEREYMEZ
| Didier Donsez, Georges-Pierre Bonneau
| [[RVA2018_Fiche_de_suivi|Fiche]] - [[Media:ProjetAR_2018_SRS.pdf‎|SRS]]
|
| [[Media:RICM5_2017_2018_XYZ.pdf|Rapport final]] - [[Media:RICM5_2017_2018_XYZ.pdf|Presentation finale FR]] - [[Media:RICM5_2017_2018_XYZ.pdf|Final Presentation EN]] - [[Media:RICM5_2017_2018_XYZ.pdf|Flyer]] - [[Media:Presentation_Mi_parcours_ProjetAR_2018.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 3
| [[SmartRecruiting|Deep Learning]] avec [[TensorFlow]] sur les référentiels de compétence
| Héloise FERNANDES DE ALMEIDA / '''Romane GALLIER''' / Alicia AUBERTIN / Antoine GAMBRO / Qianqian FU
| Didier Donsez
| [[SmartRecruiting| Fiche]] - [[SmartRecruiting/SRS|SRS]]
| [https://github.com/Projet-DeepLearning-RICM5-2018 Organisation Git]
| [[Media:RICM5_2017_2018_XYZ.pdf|Rapport final]] - [[Media:RICM5_2017_2018_XYZ.pdf|Presentation finale FR]] - [[Media:RICM5_2017_2018_XYZ.pdf|Final Presentation EN]] - [[Media:RICM5_2017_2018_XYZ.pdf|Flyer]] - [[Media:RICM5_2017_2018_DeepLearning_mi-parcours.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 5
| [[RICM5 2017 2018 - UGAChain|UGAChain]] : Blockchain for Education
| Charles MARCHAND / '''Antoine BOISADAM''' / Ahmed NASSIK / Simon CHAMBONNET / Lucas GUERRY / Aymeric VIAL-GRELIER
| Didier Donsez & co
| [[RICM5 2017 2018 - UGAChain| Fiche]] - [[RICM5 2017 2018 - UGAChain /_SRS|SRS]]
| [https://github.com/RICM5-BlockChain Github]
| [[Media:RICM5_2017_2018_UGAChain.pdf|Rapport final]] - [[Media:RICM5_2017_2018_UGAChain.pdf|Présentation finale FR]] - [[Media:RICM5_2017_2018_UGAChain.pdf|Final Présentation EN]] - [[Media:RICM5_2017_2018_UGAChain.pdf|Flyer]] - [[Media:RICM5_2017_2018_UGAChain.pdf|Présentation de mi-parcours]] -- [[Media:RICM5_2017_2018_UGAChain.mp4|Screencast]]
|-

!scope="row"| 6
| [[R'Montagne]]
| '''Hugo AMODRU-FAVIN''' / Antoine DELISE / Gwenaël MOREAU
| Bernard Tourancheau
| [[R'Montagne| Fiche]] - [[RICM5_2017_2018_-_RMontagne_/_SRS|SRS]]
| [https://github.com/delisea/R-Montagne Github]
| [[Media:RICM5_2017_2018_XYZ.pdf|Rapport final]] - [[Media:RICM5_2017_2018_XYZ.pdf|Presentation finale FR]] - [[Media:RICM5_2017_2018_XYZ.pdf|Final Presentation EN]] - [[Media:RICM5_2017_2018_XYZ.pdf|Flyer]] - [[Media:RICM5_2017_2018_XYZ.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 7
| [[SmartMove]]
| '''Anthony GEOURJON''' / Timothée LEMAIRE / Clément ROUQUIER / Vincent TURRIN
| Bernard Tourancheau
| [[RICM5_2017-2018 - SmartMove| Fiche]] - [[RICM5_2017-2018-SmartMove-SRS|SRS]]
| [https://github.com/orgs/SmartMove-PolytechGrenoble/dashboard Github]
| [[Media:RICM5_2017_2018_XYZ.pdf|Rapport final]] - [[Media:RICM5_2017_2018_XYZ.pdf|Presentation finale FR]] - [[Media:RICM5_2017_2018_XYZ.pdf|Final Presentation EN]] - [[Media:RICM5_2017_2018_XYZ.pdf|Flyer]] - [[Media:RICM5_2017_2018_XYZ.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 8
| [[EasyFlight - 2017/18 - RICM5|EasyFlight]]
| '''Boris ODIEVRE''' / Remi SAVARY / Lambert ROCHER / Hervé BECHER
| Didier Donsez
| [[EasyFlight 2017-2018| Fiche]] - [[RICM5_2017-2018-EasyFlight-SRS|SRS]]
| [https://github.com/Hbecher/EasyFlight Github]
| [[Media:RICM5_2017_2018_XYZ.pdf|Rapport final]] - [[Media:RICM5_2017_2018_XYZ.pdf|Presentation finale FR]] - [[Media:RICM5_2017_2018_XYZ.pdf|Final Presentation EN]] - [[Media:RICM5_2017_2018_XYZ.pdf|Flyer]] - [[Media:RICM5_2017_2018_XYZ.pdf|Presentation de mi-parcours]]
|-

|}

==== Sujets non choisis ====
* [[Contributions open-source au projet JHipster]] (Didier Donsez)
* [[Contributions à Software Heritage]] (Didier Donsez and co)
* Projet IoT 3 : [[Ski-locator]] (Bernard Tourancheau)

= Projets collectifs MAT/IESE =

== Années 3 et 4 ==

* [[ASAC/SJC|Serres connectées @ Jardin du coteau]]
* [[ASAC/GEJC|Gestion de l'eau @ Jardin du coteau]]
* [[ASAC/AP|Aquaponie @ Polytech]]

=[[Projets M2PGI Services Machine-to-Machine et Internet-of-Things]]=
==[[PM2M/2018/TP|PM2M]]==

=Réserve (boite à idées)=
# [http://www.opti-solar.com/french/ap_applications.fr.html |Interface contrôleur de charge batterie/PV]
# [[Sonotone à apprentissage profond]]
# [[StartAIR2]] (Nicolas Palix)
# [[Tag et Paint Ball en réalité augmentée]] (Michaël Périn)
# [[Passe moi ton fichier]] (Michaël Périn)
# [[Extensions à Fab Server]] (Jean-Michel Molenaar) sous reserve (CM ou SR)
# [[Table multijeux de café 2.0]]
# [[ GPIO_Qemu_RasPI| Emulation des GPIO dans QEMU pour le carte Raspberry Pi]] (Olivier Richard)
# [[ Qemu et STM32F0-Discovery ]] (Olivier Richard)
# [[Serrure à clé MIDI multifactorielle]] (Didier Donsez)
# [[Table interactive musicale]] (Didier Donsez)
# [[iMailbox]] (Didier Donsez)
# [[AmILight]] (eclairage d'ambience intelligent) (Didier Donsez)
# [[PDAmeetPDA]] (synchronisation d'agenda) (Michaël Périn)
# [[1 000 000 VMs]] (expérimentation d'application distribuée à très grande échelle) (Olivier Richard) (2-3 RICM4)
# [[Multiple Kinect]] (utilisation simultanée de plusieurs Kinect) (Olivier Richard) (RICM ou 3I)
# [[Kinect musicale]] (Didier Donsez) (RICM)
# [[Ktechlab Simavr Arduino | Ktechlab et integration de Simavr(Arduino)]] (Olivier Richard) (2-3 RICM4-SR)
# Ocaml on AVR (Arduino)
# Ocaml on Cortex-M3
# [[Arduino on STM32 Discovery]]
# [[Reverse Geocache Puzzle Box]]
# [[OSGi ME]] (Didier Donsez)
# [[Affichage Etudiant à Polytech]]
# Synthèse 3D + motion capture Kinect
# Logiciel d'[[apprentissage du calcul]] sur tablette Android (reconnaissance de chiffres manuscrits)
# Plancher de verre (saint gobain) à la [http://www.wat.tv/video/mickael-jackson-billie-jean-oewj_2ey2h_.html Mickael Jackson dans Billie Jean] ! woo
# [[Ktechlab Simavr Arduino | Ktechlab et integration de Simavr(Arduino)]] (Olivier Richard) (2-3 RICM4-SR)
# [[CNC]]
# [[Idées en Vrac]]
# Scheme Everywhere (Olivier Richard) (2-3 RICM4-SR)
# [[Projet Station Météo]]
# Ocaml on AVR (Arduino)
# [[Table interactive musicale]] (Didier Donsez)
# [[AmILight]] (eclairage d'amnbience intelligent) (Didier Donsez)
# [[Cube pointeur]] d'activité ingénieur
# [http://www.instructables.com/id/Puppeteer-Motion-Capture-Costume/ Puppeteer Motion-Capture Costume]
# [[Musical Staircase]] @ Polytech (Didier Donsez, 1 RICM4 + 1 3I4)
# [[Total Recall]] (Didier Donsez)
# [[SoundMachine]]
# [[IGN-OSM|Importation de données IGN publiques dans OSM]]
# [[Speed-limit-OSM|Analyse de traces GPX pour déterminer les limitations de vitesse]]
# [[Multi perceptual cameras]] (Didier Donsez)
# [[Photomaton 3D]] (Didier Donsez)
# [[ArduCopter]]
# [[Parking Intelligent]]
# Frontend Web multi-utilisateur pour un jeu sérieux d'entreprise : Didier Donsez, Stéphanie Diligent, Emmanuelle Tréhoust.
# Construction d'un roadbook d'ultratrail (mais aussi trek, randonnée, cyclisme, ...) à partir de traces GPX et des réseaux sociaux (Strava, Trace de Trail, ...): Didier Donsez

Projets 2017-2018

2018-02-14T08:18:33Z

Hugo.Amodru-Favin: /* Affectations */

<<[[Projets 2016-2017]] | [[Projets]] | [[Projets 2018-2019]]>>
=RICM=
==RICM3==

==RICM4==
===Projet Semestre S8===

Enseignants responsables : Olivier Richard, Didier Donsez

* Dates : Lundi après-midi, Mardi après-midi
* Lancement: 15/01/2018 en 257 à 15h45
* Soutenance: A définir
* Soutenance à mi-parcours: A définir

* '''Evaluation à mi-parcours le lundi/mardi ???''': Format: 10min (5min de présentation 3 slides au plus, 5min de discussion). Cette évaluation sera prise en compte dans la note finale.

'''Consignes générales:'''

* '''Vous devez être pro-actifs !!!''': Si des points sont pas ou mals spécifiés, vous le faîtes et vous justifiez vos choix. Pour les problèmes techniques éventuels vous pouvez: creuser la question, contacter l'auteur du code si il y a lieu, écrire un rapport de bug ('''Attention:''' ca se prépare !), soumettre un patch/pull request, contacter l'enseignant ou la personne référente du projet.

* '''Vous devez maintenir une fiche de suivi de projet''': elle doit être mise à jour chaque semaine, elle rassemble les élements essentiels du projet, elle indique les évolutions du projet et présente sa feuille de route. '''Note:''' le nom de la fiche doit être composé du nom du projet et suffixé par ricm4_2017_2018. '''Cette fiche compte pour la note finale'''

* '''Votre code''' pour doit être hébergé sur le gitlab et à l'URL suivante https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18 , vous utiliserez votre compte UGA.

* Les documents public doivent être rédigés en anglais (README, documentation, commentaires de code, nom de variables et de fonctions). Une bonnification sera accordée si le rapport et les transparents sont en anglais (la soutenance sera en francais).

'''Propositions de projets:'''

# [[QCM C2I]] , Pierre Gillois, Didier Donsez
# [[Dashboard pour gestionnaire de tâches]] (Angular 5): Olivier Richard
# [[Moteur de workflows distribué]] (WDL/Cromwell): Olivier Richard
# [[ESP32 et language D]]: Olivier Richard
# [[Serious game multi-joueurs pour tables tactiles en réseau]] : Didier Donsez, Anne-Laure Finkel, Stéphanie Diligent.
# [[Challenge OpenCity]] : Georges-Pierre Bonneau, Didier Donsez
# Projet [[UltraTeam]] avec des trackers [[ESP32-LoRa]] + GPS : Reprise partielle du projet eCOM de gestion des courses sportives et du projet [[UltraTeam]] 2017 pour la partie backend et frontend du projet : Didier Donsez
# Projet [[Réseau Social LoRa]] avec des pods [[ESP32-LoRa]] : Olivier Richard.
# Contribution et evaluation au/du projet [https://github.com/IntelLabs/hpat HPAT] (A compiler-based big data framework in Python): Olivier Richard.
# [[Ruche connectée LoRa]] : Nicolas Palix
# [[Serres connectées]] : Nicolas Palix
# [[I-Greenhouse]] : [[Serre connectée aquaponie]] : Nicolas Palix
# Projet "Plateforme de mise en relation pour les entrepreneurs sociaux" : Didier Donsez
# [[Chatbot pour borne d'accueil handicap]] : Didier Donsez, Marie-Paule Balicco et Jérôme Maisonnasse (service accueil handicap COMUE UGA)
# Connected Shop (avec [[Eclipse SmartHome]]) : Didier Donsez.
# [[Deploiment Nucleo | Déploiement sécurisé et sans fil pour carte Nucleo]]: Olivier Richard et Sylain Toru
# [[RobAIR]] : Cobot Majordome : Jérôme Maisonnasse, Germain Lemasson, Bastien Scher (FabMSTIC).

==== Affectations ====
{|class="wikitable alternance"
|+ Affectation des projets RICM4 2017-2018
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Enseignant(s)
!scope="col"| Fiche de suivi
!scope="col"| Dépot git
|-

!scope="row"| 1
| [[QCM C2I]]
| NON ATTRIBUÉ
| Pierre Gillois, Didier Donsez
| [[RICM4_2017_2018_-_| Fiche]] - [[RICM4_2017_2018_-_/_SRS|SRS]] - [[RICM4_2017_2018_-_/UML | UML]]
|
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 2
| [[Dashboard pour gestionnaire de tâches]] (Angular 5)
| BELGUENDOUZ Sekina, LARNICOL Titouan
| Olivier Richard
| [[RICM4_2017_2018_-_Dashboard| Fiche]] - [[RICM4_2017_2018_-_Dashboard/_SRS|SRS]] - [[RICM4_2017_2018_-_Dashboard/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/2 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 3
| [[Moteur de workflows distribué]] (WDL/Cromwell)
| NON ATTRIBUÉ
| Olivier Richard
| [[RICM4_2017_2018_-_| Fiche]] - [[RICM4_2017_2018_-_/_SRS|SRS]] - [[RICM4_2017_2018_-_/UML | UML]]
|
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 4
| [[ESP32 et language D]]
| MANGER Raphael, HOUBRON Adrian
| Olivier Richard
| [[RICM4_2017_2018_-_ESP32_D| Fiche]] - [[RICM4_2017_2018_-_ESP32_D/_SRS|SRS]] - [[RICM4_2017_2018_-_ESP32_D/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/4 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 5
| [[Serious game multi-joueurs pour tables tactiles en réseau]]
| LEPAGE Tim, SERGEANT Dimitri
| Didier Donsez, Anne-Laure Finkel, Stéphanie Diligent
| [[RICM4_2017_2018_-SeriousGame Polystar | Fiche]] - [[RICM4_2017_2018_- SeriousGame Polystar /_SRS|SRS]] - [[RICM4_2017_2018_- SeriousGame Polystar /UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/5 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 6
| [[Challenge OpenCity]]
| BOUCHERIMA Amina, FOMBARON Quentin
| Georges-Pierre Bonneau, Didier Donsez
| [[RICM4_2017_2018_-_OpenCity| Fiche]] - [[RICM4_2017_2018_-_OpenCity/_SRS|SRS]] - [[RICM4_2017_2018_-_OpenCity/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/6 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 7.1
| Projet [[UltraTeam]] avec des trackers [[ESP32-LoRa]] + GPS
| TERRIER Bastien, GROS-DAILLON Hugo
| Didier Donsez
| [[RICM4_2017_2018_-_UltraTeam_7.1| Fiche]] - [[RICM4_2017_2018_-_UltraTeam_7.1/_SRS|SRS]] - [[RICM4_2017_2018_-_UltraTeam_7.1/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/7.1 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 7.2
| Projet [[UltraTeam]] avec des trackers [[ESP32-LoRa]] + GPS
| MOLION Enzo, VALETTE Léo
| Didier Donsez
| [[RICM4_2017_2018_-_UltraTeamMV| Fiche]] - [[RICM4_2017_2018_-_UltraTeamMV_:_SRS|SRS]] - [[RICM4_2017_2018_-_UltraTeamMV_:_UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/7.2 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 8
| Projet [[Réseau Social LoRa]] avec des pods [[ESP32-LoRa]]
| VEGREVILLE Thibaud, GENTILLON Loris, ZHENG Jian
| Olivier Richard
| [[RICM4_2017_2018_-_Réseau_Social_LoRa| Fiche]] - [[RICM4_2017_2018_-_Réseau_Social_LoRa/_SRS|SRS]] - [[RICM4_2017_2018_-_Réseau_Social_LoRa/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/8 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 9
| Contribution et evaluation au/du projet [https://github.com/IntelLabs/hpat HPAT]
| NON ATTRIBUÉ
| Olivier Richard
| [[RICM4_2017_2018_-_| Fiche]] - [[RICM4_2017_2018_-_/_SRS|SRS]] - [[RICM4_2017_2018_-_/UML | UML]]
|
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 10
| [[Ruche connectée LoRa]]
| BESNIER Benjamin, LÉVESQUE Théo, WEILL William
| Nicolas Palix
| [[RICM4_2017_2018_-_Ruche_Connectee_| Fiche]] - [[RICM4_2017_2018_-_Ruche_Connectee_/_SRS|SRS]] - [[RICM4_2017_2018_-_Ruche_Connectee/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/10 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 11
| [[Serres connectées]]
| BESNARD Guillaume, DEPRIESTER Timothée
| Nicolas Palix
| [[RICM4_2017_2018_-_Serre_Connectee| Fiche]] - [[RICM4_2017_2018_-_Serre_Connectee_/_SRS|SRS]] - [[RICM4_2017_2018_-_Serre_Connecte/UML | UML]] - [[RICM4_2017_2018_-_Serre_Connecte/Schedule | Schedule]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/11 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 12
| [[I-Greenhouse]] : [[Serre connectée aquaponie]]
| SURIER GAROFALO Aurélien, FERREIRA Joffrey, OZENDA Thomas
| Nicolas Palix
| [[RICM4_2017_2018_-_IGreenHouse| Fiche]] - [[RICM4_2017_2018_-_IGreenHouse_/_SRS|SRS]] - [[IGreenHouse/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/12 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 13
| Projet "Plateforme de mise en relation pour les entrepreneurs sociaux"
| AUBERT Vincent, COURTIAL Julien
| Didier Donsez
| [[RICM4_2017_2018_-_| Fiche]] - [[RICM4_2017_2018_-_Entrepreneur_AUBERT_COURTIAL/_SRS|SRS]] - [[RICM4_2017_2018_-_/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/13 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 14
| [[Chatbot pour borne d'accueil handicap]]
| AUCLAIR-CORDAT Julien, BAMBA Samuel
| Didier Donsez, Marie-Paule Balicco et Jérôme Maisonnasse (service accueil handicap COMUE UGA)
| [[RICM4_2017_2018_-_| Fiche]] - [[RICM4_2017_2018_-_/_SRS|SRS]] - [[RICM4_2017_2018_-_/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/14 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 15
| Connected Shop (avec [[Eclipse SmartHome]])
| CUZIN Florian, ECHEVET Théo
| Didier Donsez
| [[RICM4_2017_2018_-_| Fiche]] - [[RICM4_2017_2018_-_/_SRS|SRS]] - [[RICM4_2017_2018_-_/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/15 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 16
| [[Deploiment Nucleo | Déploiement sécurisé et sans fil pour carte Nucleo]]
| CHANET Zoran, CHARLOT Servan
| Olivier Richard, Sylain Toru
| [[RICM4_2017_2018_-_Nucleo | Fiche]] - [[RICM4_2017_2018_-_Nucleo/_SRS|SRS]] - [[RICM4_2017_2018_-_Nucleo/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/16 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 17.1
| [[RobAIR]] : Robot Majordome
| DEVOS Xavier, LAFRASSE Cédric
| Jérôme Maisonnasse, Germain Lemasson, Bastien Scher (FabMSTIC)
| [[RICM4_2017_2018_-_RobAIR17-1| Fiche]] - [[RICM4_2017_2018_-_RobAIRDL/_SRS|SRS]] - [[RICM4_2017_2018_-_RobAIRDL/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/17.1 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 17.2
| [[RobAIR]] : Robot Majordome
| JEAN Jordan, EZ-ZINE Najwa
| Jérôme Maisonnasse, Germain Lemasson, Bastien Scher (FabMSTIC)
| [[RICM4_2017_2018_-_robair2| Fiche]] - [[RICM4_2017_2018_-_robair2/_SRS|SRS]] - [[RICM4_2017_2018_-_robair2/UML | UML]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/17.2 gitlab]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-

|}

==RICM5==
===Projet IoT S9===
Enseignants responsables : Bernard Tourancheau

Calendrier: ??? Septembre à ??? Décembre 2017.

* Projet IoT 3 : [[Ski-locator]] (Bernard Tourancheau)

===Projet Semestre S10===

Enseignants responsables : Didier Donsez

Calendrier: 29 Janvier à 15 Mars 2018.

Séances de Management de projets innovants:
* Mercredi 31/01 de 8h à 12h: Stéphanie Diligent
* Mercredi 7 février de 8h à 12h : Stéphanie Diligent
* Mardi 15 février de 8h à 12 : Emmanuelle Tréhoust
* Lundi 26 février de 8h à 12h : Olivier Gilles
* Mardi 13 mars de 8h à 12h : Stéphanie Diligent et Emmanuelle Tréhoust

Réunion de présentation : 8 Janvier 2018 Matin à 9H00-10H00 (RdV Salle P257 et Salle AIR P259). Faire couler le café.

Hackathon Vinci (8,9,10/02) : http://hacktogether.vinci-energies.com/

Démarrage : Lundi 29 Janvier 2018

Soutenance à mi-parcours : Mercredi 14 Février 2018, 8H00-11H00 (30 minutes par équipe).

Soutenance (puis Pot de la fin) : Jeudi 15 Mars 2018

Vendredi 16 Mars : 10000 ans de RICM

==== Planning soutenances mi-parcours ====
Mercredi 14 Février 2018, salle P144, 8H00-11H00 (25 minutes TTC par équipe).

* 8H00-8H30 [[Real Time Subtitles 2017-2018| Real Time Subtitles]]
* 8H30-9H00 [[Deep Learning 2017-2018 | Deep Learning]]
* 9H00-9H30 [[EasyFlight]]
* 9H30-10H00 [[ Réalité virtuelle et Augmentée pour la maintenance d'usines]]
* 10H00-10H30 [[R'Montagne]]
* 10H30-11H00 [[SmartMove]]
* 11H00-11H30 [[RICM5 2017 2018 - UGAChain|UGAChain]]

==== Planning soutenances finales ====
Jeudi 15 Mars 2018
* 8H00-9H00 [[R'Montagne]] (50 minutes TTC)
* 9H00-10H00 [[SmartMove]] (50 minutes TTC)
* 10H00-11H00 (50 minutes TTC) [[ Réalité virtuelle et Augmentée pour la maintenance d'usines]]
* 11H00-12H00 (50 minutes TTC) [[RICM5 2017 2018 - UGAChain|UGAChain]] : Blockchain for Education
Pause déjeuner
* 13H00-14H00 [[Real Time Subtitles 2017-2018| Real Time Subtitles]] (50 minutes TTC)
* 14H00-15H00 [[Deep Learning 2017-2018 | Deep Learning]] (50 minutes TTC)
* 15H00-16H00 [[EasyFlight]] (50 minutes TTC)

==== Affectations ====
{|class="wikitable alternance"
|+ Affectation des projets RICM5 2017-2018
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Enseignant(s)
!scope="col"| Fiche de suivi
!scope="col"| Dépot git
|-

!scope="row"| 1
| [[Real Time Subtitles 2017-2018| Sous-titre d'un cours en temps réel]]
| '''Estelle ALLARD''' / Aymeric BROCHIER / Louis COCHINHO / Oriane DALLE / Alexandre FERRERA / Alice RIVOAL
| Didier Donsez, Laurent Besacier, François Portet, Marie-Paule Balicco, Jérome Maisonnasse
| [[Real Time Subtitles 2017-2018| Fiche]] - [[Real_Time_Subtitles_2017-2018/SRS|SRS]]
| [https://gitlab.com/LouisCochinho/RealTimeSubtitles GitLab]
| [[Media:RICM5_2017_2018_XYZ.pdf|Rapport final]] - [[Media:RICM5_2017_2018_XYZ.pdf|Presentation finale FR]] - [[Media:RICM5_2017_2018_XYZ.pdf|Final Presentation EN]] - [[Media:RICM5_2017_2018_XYZ.pdf|Flyer]] - [[Media:RICM5_2017_2018_XYZ.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 2
| [[Réalité Augmentée pour le Smart Campus 2018|Réalité Augmentée pour le Smart Campus]]
| Lucas LESAGE / '''Denis LACHARTRE''' / Douria ZENNOUCHE / Gilles BONHOURE / Maxime DEREYMEZ
| Didier Donsez, Georges-Pierre Bonneau
| [[RVA2018_Fiche_de_suivi|Fiche]] - [[Media:ProjetAR_2018_SRS.pdf‎|SRS]]
|
| [[Media:RICM5_2017_2018_XYZ.pdf|Rapport final]] - [[Media:RICM5_2017_2018_XYZ.pdf|Presentation finale FR]] - [[Media:RICM5_2017_2018_XYZ.pdf|Final Presentation EN]] - [[Media:RICM5_2017_2018_XYZ.pdf|Flyer]] - [[Media:Presentation_Mi_parcours_ProjetAR_2018.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 3
| [[SmartRecruiting|Deep Learning]] avec [[TensorFlow]] sur les référentiels de compétence
| Héloise FERNANDES DE ALMEIDA / '''Romane GALLIER''' / Alicia AUBERTIN / Antoine GAMBRO / Qianqian FU
| Didier Donsez
| [[SmartRecruiting| Fiche]] - [[SmartRecruiting/SRS|SRS]]
| [https://github.com/Projet-DeepLearning-RICM5-2018 Organisation Git]
| [[Media:RICM5_2017_2018_XYZ.pdf|Rapport final]] - [[Media:RICM5_2017_2018_XYZ.pdf|Presentation finale FR]] - [[Media:RICM5_2017_2018_XYZ.pdf|Final Presentation EN]] - [[Media:RICM5_2017_2018_XYZ.pdf|Flyer]] - [[Media:RICM5_2017_2018_DeepLearning_mi-parcours.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 5
| [[RICM5 2017 2018 - UGAChain|UGAChain]] : Blockchain for Education
| Charles MARCHAND / '''Antoine BOISADAM''' / Ahmed NASSIK / Simon CHAMBONNET / Lucas GUERRY / Aymeric VIAL-GRELIER
| Didier Donsez & co
| [[RICM5 2017 2018 - UGAChain| Fiche]] - [[RICM5 2017 2018 - UGAChain /_SRS|SRS]]
| [https://github.com/RICM5-BlockChain Github]
| [[Media:RICM5_2017_2018_UGAChain.pdf|Rapport final]] - [[Media:RICM5_2017_2018_UGAChain.pdf|Présentation finale FR]] - [[Media:RICM5_2017_2018_UGAChain.pdf|Final Présentation EN]] - [[Media:RICM5_2017_2018_UGAChain.pdf|Flyer]] - [[Media:RICM5_2017_2018_UGAChain.pdf|Présentation de mi-parcours]] -- [[Media:RICM5_2017_2018_UGAChain.mp4|Screencast]]
|-

!scope="row"| 6
| [[R'Montagne]]
| '''Hugo AMODRU-FAVIN''' / Antoine DELISE / Gwenaël MOREAU
| Bernard Tourancheau
| [[RICM5_2017_2018_-_| Fiche]] - [[RICM5_2017_2018_-_RMontagne_/_SRS|SRS]]
| [https://github.com/delisea/R-Montagne Github]
| [[Media:RICM5_2017_2018_XYZ.pdf|Rapport final]] - [[Media:RICM5_2017_2018_XYZ.pdf|Presentation finale FR]] - [[Media:RICM5_2017_2018_XYZ.pdf|Final Presentation EN]] - [[Media:RICM5_2017_2018_XYZ.pdf|Flyer]] - [[Media:RICM5_2017_2018_XYZ.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 7
| [[SmartMove]]
| '''Anthony GEOURJON''' / Timothée LEMAIRE / Clément ROUQUIER / Vincent TURRIN
| Bernard Tourancheau
| [[RICM5_2017-2018 - SmartMove| Fiche]] - [[RICM5_2017-2018-SmartMove-SRS|SRS]]
| [https://github.com/orgs/SmartMove-PolytechGrenoble/dashboard Github]
| [[Media:RICM5_2017_2018_XYZ.pdf|Rapport final]] - [[Media:RICM5_2017_2018_XYZ.pdf|Presentation finale FR]] - [[Media:RICM5_2017_2018_XYZ.pdf|Final Presentation EN]] - [[Media:RICM5_2017_2018_XYZ.pdf|Flyer]] - [[Media:RICM5_2017_2018_XYZ.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 8
| [[EasyFlight - 2017/18 - RICM5|EasyFlight]]
| '''Boris ODIEVRE''' / Remi SAVARY / Lambert ROCHER / Hervé BECHER
| Didier Donsez
| [[EasyFlight 2017-2018| Fiche]] - [[RICM5_2017-2018-EasyFlight-SRS|SRS]]
| [https://github.com/Hbecher/EasyFlight Github]
| [[Media:RICM5_2017_2018_XYZ.pdf|Rapport final]] - [[Media:RICM5_2017_2018_XYZ.pdf|Presentation finale FR]] - [[Media:RICM5_2017_2018_XYZ.pdf|Final Presentation EN]] - [[Media:RICM5_2017_2018_XYZ.pdf|Flyer]] - [[Media:RICM5_2017_2018_XYZ.pdf|Presentation de mi-parcours]]
|-

|}

==== Sujets non choisis ====
* [[Contributions open-source au projet JHipster]] (Didier Donsez)
* [[Contributions à Software Heritage]] (Didier Donsez and co)
* Projet IoT 3 : [[Ski-locator]] (Bernard Tourancheau)

= Projets collectifs MAT/IESE =

== Années 3 et 4 ==

* [[ASAC/SJC|Serres connectées @ Jardin du coteau]]
* [[ASAC/GEJC|Gestion de l'eau @ Jardin du coteau]]
* [[ASAC/AP|Aquaponie @ Polytech]]

=[[Projets M2PGI Services Machine-to-Machine et Internet-of-Things]]=
==[[PM2M/2018/TP|PM2M]]==

=Réserve (boite à idées)=
# [http://www.opti-solar.com/french/ap_applications.fr.html |Interface contrôleur de charge batterie/PV]
# [[Sonotone à apprentissage profond]]
# [[StartAIR2]] (Nicolas Palix)
# [[Tag et Paint Ball en réalité augmentée]] (Michaël Périn)
# [[Passe moi ton fichier]] (Michaël Périn)
# [[Extensions à Fab Server]] (Jean-Michel Molenaar) sous reserve (CM ou SR)
# [[Table multijeux de café 2.0]]
# [[ GPIO_Qemu_RasPI| Emulation des GPIO dans QEMU pour le carte Raspberry Pi]] (Olivier Richard)
# [[ Qemu et STM32F0-Discovery ]] (Olivier Richard)
# [[Serrure à clé MIDI multifactorielle]] (Didier Donsez)
# [[Table interactive musicale]] (Didier Donsez)
# [[iMailbox]] (Didier Donsez)
# [[AmILight]] (eclairage d'ambience intelligent) (Didier Donsez)
# [[PDAmeetPDA]] (synchronisation d'agenda) (Michaël Périn)
# [[1 000 000 VMs]] (expérimentation d'application distribuée à très grande échelle) (Olivier Richard) (2-3 RICM4)
# [[Multiple Kinect]] (utilisation simultanée de plusieurs Kinect) (Olivier Richard) (RICM ou 3I)
# [[Kinect musicale]] (Didier Donsez) (RICM)
# [[Ktechlab Simavr Arduino | Ktechlab et integration de Simavr(Arduino)]] (Olivier Richard) (2-3 RICM4-SR)
# Ocaml on AVR (Arduino)
# Ocaml on Cortex-M3
# [[Arduino on STM32 Discovery]]
# [[Reverse Geocache Puzzle Box]]
# [[OSGi ME]] (Didier Donsez)
# [[Affichage Etudiant à Polytech]]
# Synthèse 3D + motion capture Kinect
# Logiciel d'[[apprentissage du calcul]] sur tablette Android (reconnaissance de chiffres manuscrits)
# Plancher de verre (saint gobain) à la [http://www.wat.tv/video/mickael-jackson-billie-jean-oewj_2ey2h_.html Mickael Jackson dans Billie Jean] ! woo
# [[Ktechlab Simavr Arduino | Ktechlab et integration de Simavr(Arduino)]] (Olivier Richard) (2-3 RICM4-SR)
# [[CNC]]
# [[Idées en Vrac]]
# Scheme Everywhere (Olivier Richard) (2-3 RICM4-SR)
# [[Projet Station Météo]]
# Ocaml on AVR (Arduino)
# [[Table interactive musicale]] (Didier Donsez)
# [[AmILight]] (eclairage d'amnbience intelligent) (Didier Donsez)
# [[Cube pointeur]] d'activité ingénieur
# [http://www.instructables.com/id/Puppeteer-Motion-Capture-Costume/ Puppeteer Motion-Capture Costume]
# [[Musical Staircase]] @ Polytech (Didier Donsez, 1 RICM4 + 1 3I4)
# [[Total Recall]] (Didier Donsez)
# [[SoundMachine]]
# [[IGN-OSM|Importation de données IGN publiques dans OSM]]
# [[Speed-limit-OSM|Analyse de traces GPX pour déterminer les limitations de vitesse]]
# [[Multi perceptual cameras]] (Didier Donsez)
# [[Photomaton 3D]] (Didier Donsez)
# [[ArduCopter]]
# [[Parking Intelligent]]
# Frontend Web multi-utilisateur pour un jeu sérieux d'entreprise : Didier Donsez, Stéphanie Diligent, Emmanuelle Tréhoust.
# Construction d'un roadbook d'ultratrail (mais aussi trek, randonnée, cyclisme, ...) à partir de traces GPX et des réseaux sociaux (Strava, Trace de Trail, ...): Didier Donsez

R'Montagne

2018-02-13T10:27:50Z

Hugo.Amodru-Favin: /* Journal */

R'Montagne

2018-02-13T10:21:59Z

Hugo.Amodru-Favin: /* Journal */

R'Montagne

2018-02-13T10:16:37Z

Hugo.Amodru-Favin: /* Journal */

R'Montagne

2018-02-13T10:15:54Z

Hugo.Amodru-Favin: /* Journal */

R'Montagne

2018-02-13T10:04:40Z

Hugo.Amodru-Favin: /* Journal */

R'Montagne

2018-02-13T09:58:53Z

Hugo.Amodru-Favin: /* Journal */

R'Montagne

2018-02-13T09:58:23Z

Hugo.Amodru-Favin: /* Journal */

R'Montagne

2018-02-13T09:57:44Z

Hugo.Amodru-Favin: /* Journal */

R'Montagne

2018-02-13T09:18:02Z

Hugo.Amodru-Favin: /* Journal */

R'Montagne

2018-02-12T10:34:09Z

Hugo.Amodru-Favin: /* Collaboration avec le DUT RT et les PEIPs D */

R'Montagne

2018-02-12T10:23:40Z

Hugo.Amodru-Favin: /* Journal */

R'Montagne

2018-02-12T10:20:48Z

Hugo.Amodru-Favin: /* Tâches */

R'Montagne

2018-02-12T10:20:25Z

Hugo.Amodru-Favin: /* Planning */

R'Montagne

2018-02-12T10:12:29Z

Hugo.Amodru-Favin: /* Présentation du projet */

R'Montagne

2018-02-12T10:12:11Z

Hugo.Amodru-Favin: /* Journal */

=Présentation du projet=

==Équipe==
{|class="wikitable"
|-
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Rôle
|-
| Hugo Amodru-Favin
| Chef de Projet
|-
| Antoine Delise
| Lead Developer
|-
| Gwenaël Moreau
| Kanban Master
|-

|}

==Tâches==

Répartition générale des tâches
{|class="wikitable"
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Tâche
|-
| Hugo Amodru-Favin
| Application Ionic
|-
| Antoine Delise
| Développement Arduino
|-
| Gwenaël Moreau
| BDD - API
|-

|}

Détail des tâches : [https://waffle.io/delisea/R-Montagne Lien Waffle.io]

=Journal=

{|class="wikitable"
|+
|-
!scope="col" width="100px"| Date
!scope="col"| Hugo AMODRU-FAVIN
!scope="col"| Antoine DELISE
!scope="col"| Gwenaël MOREAU
|-

| colspan="5" style="text-align: center; background-color:#1c531c; width:225px;"| SPRINT 1
|-

|-
| rowspan="1" | Lundi 29/01/18
| style="width: 225px;" |
* efoed
| style="width: 225px;" |
* sidfjeso
| style="width: 225px;" |
* zdokz
|-
|}

=Description du sujet=

==Randonnée et risques==

Ouvert à tous, la randonnée est un sport et un loisir qui prend de plus en plus d’ampleur de nos jours. Ne nécessitant pas de grands prérequis, des milliers de personnes se lancent en montagne chaque jour, malheureusement parfois sans connaître toutes les mesures de sécurité associées.

En effet, de janvier à juin 2016, en randonnée et en alpinisme, l’Association Nationale pour l’Étude de la Neige et des Avalanches (ANENA) a comptabilisé 21 accidents notables, dont 8 accidents mortels, impliquant 15 décès.

Aujourd’hui, les mesures de sécurités préconisent que chaque groupe de randonneur se doivent de se munir d’un téléphone portable afin d’appeler les secours en cas de problème. Malheureusement, la communication mobile dépendant de la couverture réseau, peu présente en montagne, l’impossibilité de joindre les secours reste un problème.

==Solutions existantes==

La solution la plus répandue, est celle du téléphone à connexion satellite. Ayant une communication vers les satellites, cela permet une couverture réseau beaucoup plus répandue dans les montagnes, partout dans le monde (ou presque). Cependant, les téléphones portables satellitaires coûtent chers, et ne sont pas forcément abordables par la plupart des personnes, surtout celles ne sortant qu’occasionnellement.

[https://fall-alarm.net/ Fall Alarm] est un système de détection de chute sur chantier utilisant les mêmes technologies dont nous avons besoin pour notre projet.

==Quelles zones géographiques ?==

Toutes les zones montagneuses peuvent présenter des zones blanches, démunies de connexion quelconque autre que les connexions satellitaires. Certaines chaînes de montagne comme la Cordillaire des Andes ne présentent aucune connexion possible quelconque.

Dans le cadre de notre projet, nous fonctionnerons essentiellement dans la localisation grenobloise avec l'objectif que notre solution soit applicable partout dans le monde. Une contrainte intervient tout de même étant donnée que la fréquence d'utilisation du LoRa en Europe est de 868MHz, 915MHz en Amérique et 433MHz en Asie.

= Fonctionnalités =

Afin de remplir au mieux ses attentes, le principal objectif de ce dispositif sera premièrement de pouvoir communiquer avec les secours à n’importe quel moment, et surtout n’importe où. De plus, il sera capable de détecter de nombreux cas de détresse de la part de l’usager afin de pouvoir lancer un appel d’urgence sans interaction avec l’usager, au cas où il serait inconscient, ou incapable de lancer un appel manuel.

Grâce aux accéléromètres, le dispositif sera à même de détecter un mouvement brutal du randonneur, ce qui pourrait s’apparenter à une chute. Ils pourront également détecter une position anormale, ou une immobilité prolongée, ce qui déclencherait le dispositif d’urgence automatiquement.

Grâce à des tests réalisés au préalable, le boîtier pourra détecter correctement les chûtes de simples mouvements, afin de ne pas lancer l’appel sans raison valable.

Avant de lancer une alerte automatique, le dispositif émettra un signal auditif et visuel à l’utilisateur quelques secondes auparavant, afin de le prévenir l'émission du signal d’urgence, et de lui proposer de le désactiver sur simple pression d’un bouton, afin d’éviter les communications inutiles.

Également, le randonneur sera à même d'émettre volontairement un appel d’urgence à l’aide du bouton, ce qui permet à tout moment d’appeler de l’aide sans effort. Cela peut permettre également à appeler les secours pour une personne en danger qui ne porterait pas le dispositif.

L’appel au secours se représente par un envoi de coordonnées GPS aux secours, via une communication radio LoRa vers des bornes relais placées au préalables en montagne. Cette communication irait de relai de relai jusqu’au centre de sécurité, d’où le message serait transmis aux secours.

De plus, une application mobile verra le jour afin de connecter tous les utilisateurs du module de sécurité, de les visualiser sur une map, et de partager leurs données. En effet, à chaque incident, l’application mettra à jour la position et de la date de l’accident, afin de permettre aux prochains utilisateurs d’être prévenus. Ils pourraient, s'ils sont à proximité, d'assister la personne en détresse en attendant l'arrivée des secours. Bien évidemment, cette application ne sera accessible uniquement si le smartphone de l'utilisateur est relié à une connexion 4G ou Wi-Fi.

Cette prévention pourrait les sensibiliser aux risques de la montagne, leur permettre d’éviter le secteur mais aussi d’aider les personnes en danger si la distance le permet.

= Exigences =
== Fonctionnelles ==

*Batterie garantie fonctionnelle 1 semaine
*Rechargement possible via le panneau solaire portable
*Dispositif pouvant être allumé et éteint par l'utilisateur
*Alarme s’enclenche automatiquement dès qu'elle est considérée nécessaire, signal sonore
*Utilisateur a la possibilité d’activer/désactiver l’alarme quand il le souhaite
*Lorsque l’alarme est active, l’appareil ne peut s’éteindre
*...

== Non-Fonctionnelles ==

*Résistance : aux chocs, impacts, waterproof (utilisé en permanence en plein air)
*Disponibilité : Appareil de secours -> Doit être au plus possible performant
*Performance : Minimiser les pertes réseaux
*Accessible : Utilisateur pas forcément familier avec des appareils électroniques (facile d’utilisation)
*Fiabilité : Précision du GPS (rayon de 10m), données non-éronnées
*Coût : Le plus faible possible pour vendre le moins cher possible
*Efficacité : Réduire la consommation, utiliser le moins possible les ressources

= Composants =
== LoRaONE ==
Pour le coeur du projet, après avoir cherché et comparés plusieurs modules LoRa, GPS ou encore accéléromètres, nous avons finalement opté pour le projet LoRaONE.

LoRaONE est un projet de SODAQ regroupant plusieurs composants dans une seule et même carte, de taille réduite.

https://www.kickstarter.com/projects/sodaq/loraone-the-lora-iot-development-board

“The one IoT development board to rule them all” --SODAQ

Cette carte regroupe plusieurs capteurs afin de respecter aux mieux nos exigences :

Un émetteur/récepteur LoRa afin de pouvoir communiquer au mieux avec les antennes relai à longue distance

Un module + antenne GPS de bonne précision (< 10m) pour connaître en tout temps notre position, et ainsi faciliter l’arrivée des secours, ainsi que la recherche de l’individu en détresse

Un accéléromètre sur 3 axes afin de pouvoir détecter tout mouvement, vitesse ou rotation dans l’espace, ce qui permet la détection de chutes ou d’arrêt de mouvements

3 LED RGB afin de pouvoir signaler à l’utilisateur un manque de batterie, un signal d’urgence ou plus si nécessaire

Un bouton poussoir pour le signal d’alarme

Un connecteur de charge par panneau solaire, afin de faire durer chaque batterie le plus longtemps possible

Un connecteur micro-USB ainsi que des lignes pour se connecter à une base Arduino si besoin

[[File:LoRaOne.png||400px|Spécifications carte LoRaOne]]

De plus, grâce au starter pack, nous pouvons avoir accès à la base ONEBase qui nous permettrait d’étendre plus loin la facilité d’utilisation du produit :

[[File:LoRaOneBase.png||400px|Spécifications base LoRaOneBase]]

Comme nous pouvons le voir, cette base nous permettra de connecter la batterie ainsi que le panneau solaire qui sont fournis dans le pack.

Nous pourrons également connecter jusqu’à 4 modules supplémentaires.

La batterie fournie aura une capacité de 800 mAh, le panneau solaire fourni pouvant délivrer jusqu’à 500 mW de puissance.

Le total atteint une taille d’environ 10*5 cm, ce qui n’est pas excessif, ce qui le rend aisément portatif sur une jambe ou à la taille.

'''Coût : 115€'''

Ce module pourra également servir d’antenne relai, l'alimentation solaire devrait maintenir le dispositif chargé en permanence. Des tests seront effectués pour savoir si un panneau solaire plus puissant est requis.

== Boîtier ==

Le boîtier sécurisé devant respecter plusieurs exigences, nous pouvons le construire en plastique résistant, ce qui le rendrait léger tout en respectant une rigidité suffisante. Les antennes pourront être placées le long du boîtier, à l’intérieur si la connexion est suffisante, ou à l’extérieur. Dans ce dernier cas les trous réalisés sur le boîtier afin de laisser passer les câbles seront colmatés afin de garantir une étanchéité.

[[File:SchemaBoitier.png||100px|Schéma boitier d'alarme]]

== Balises ==

Afin de remonter les informations transmises par les boitiers, des balises seront mises en places sur la zone à couvrir, leur nombre et leur positions dépendra du terrain (obstacles, dénivelés). On distinguera deux types de balises. Tout d’abord, les balises racines qui permettront une communication GSM afin de faire remonter les données vers le serveur. Viennent ensuite les balises standard qui se contenteront de faire remonter vers leur balise racine associée. L’architecture de liaison des balises est détaillée dans une prochaine partie.

Chaque balise est composée d’une barre de fer pouvant être plantée dans le sol, d’un système de lest afin d’immobiliser la balise, d’un paratonnerre, d’un panneau solaire ainsi que d’un LoraOne et d’une batterie. Les balises racines seront équippée en plus d’un dispositif de communication GSM (téléphone portable, émetteur GSM).

[[File:SchemaBalise.png||150px|Schéma balises d'alarme]]

== Application mobile ==
Une application mobile est téléchargeable par les utilisateurs. Ils peuvent voir les autres utilisateurs présents dans leur zone. Lorsqu’un utilisateur est en position de danger, une notification apparaît si les utilisateurs sont proches de la situation de danger.

Cette application n’est pas directement reliée au dispositif. Elle ne fonctionne qu’avec la connexion du mobile, et est destinée à être un niveau de sécurité supérieur. Un randonneur proche d’une zone de danger pourrait arriver sur place plus rapidement que les secours.

= Communication =

Pour un envoi de position + numéro d’identification (X chiffres) :

*Temps de communication : < 2 s
*Communication régulière, intervalle de 15 minutes

On peut donc au maximum avoir 15 * 60 / 2 = 450 individus pouvant communiquer avec la même antenne relai, donc dans le même cercle d’environ 15 km de diamètre.

On communique donc au minimum 2 secondes sur 15 minutes, donc 1/450 << 1%, le temps de communication est respecté.

En cas de problème, nous pouvons envoyer jusqu’à 9x plus avec la borne sans dépasser le temps de communication autorisé (1%). Donc 1 envoi d’appel d’urgence toutes les 2 minutes environ.

La balise racine peut être directement connectée au serveur, dans ce cas, il n’y a pas de communication GSM nécessaire et pas de Gateway. Si la racine n’est pas directement connectée au serveur, elle devra au minimum garantir une communication GSM (ce qu’elle peut faire, il n’y a pas de Gateway nécessaire) pour remonter l’information vers le serveur, et donc la base de données.

GSM : Si Racine connectée à Serveur -> No GSM + Gateway
Else : GSM + Gateway : LoRa Racine connectée ordi (RaspberryPI) + ordi connecté GSM

= Stabilisation et gestion d’erreurs =

== Choix du routage ==

Notre réseau n'est pas un réseau traditionnel. Les seules communications existantes sont soit une remontée d'information vers la racine soit une innondation d'alerte vers les clients. Pour celà nous avons donc décidé d'utiliser un algorithme de routage simplifié basé uniquement sur un arbre en largeur des balises. Nous rajoutons en option la possibilité de créer plusieurs racines et donc plusieurs arbres dont les racines communiquent par gsm. Nous nous basons sur des papiers de recherches afin de déterminer quel algorithme auto-stabilisant est le plus adapté au système LoRa (Tel que le papier "A self-stabilizing algorithm for constructing breadth-first trees" par Shing-Tsaan Huang, Nian-Shing Chen).

== Stabilisation ==

Afin de gérer la communication de chaque message vers le serveur, nous allons prendre un noeud (balise LoRa) dit “racine” connecté directement au serveur, nous ne nous occuperons pas de la communication au serveur dans cet onglet. Chaque message reçu de la part d’un noeud du système doit être relayé jusqu’à la racine du système afin de communiquer avec les secours (ou serveur simplement).

Pour cela, il faudra assurer que chaque balise LoRa soit connecté au réseau, afin d’avoir au départ un graphe de communication connexe. Par dessus ce graphe, nous allons utiliser un processus silencieux auto-stabilisant qui construira un arbre de parcours en largeur, avec pour racine le noeud “racine” décidé ci-dessus.

Au lancement du système, il faut prévoir un léger temps de stabilisation, qui dépendrait de l’algorithme et de la taille du graphe (nombre de balises). Cependant, après cela, l’algorithme assure un arbre en profondeur minimal qui nous permettrai de communiquer avec la racine le plus rapidement possible, et donc une qualité de service maximale.

== Gestion d’erreurs ==

Dans un réseau comme celui-ci, plusieurs types d’erreurs peuvent se produire :
Délai de communication trop important vers une balise
“Crash” d’une balise de communication
Surpopulation d’une balise ou congestion de messages

Afin de palier au premier type d’incident rencontré, il faut nécessairement qu’à chaque emplacement dans la zone couverte, l’utilisateur soit à même de communiquer avec au minimum 2 balises différentes. Ainsi, dans le cas d’une communication trop longue sur une balise, l’autre aurait de grandes chances de délivrer le message plus rapidement.

Au niveau de la défaillance d’une balise, l’algorithme d’arbre en profondeur nous fournit déjà une solution intégrée grâce à son auto-stabilisation. Dans le cas de déconnexion d’une balise, l’algorithme mettrai à jour automatiquement l’arbre de communication, et n’importe quel message d’alerte émis serait délivré dans un délai raisonnable.

Pour le troisième cas d’erreur, il n’y aurait pas de solution réelle, si ce n’est de limiter le nombre de communications données, en ne prenant plus en compte les “ping” de chaque utilisateur mais seulement les messages d’alertes, ce qui permettrai une bien plus grande gestion de la congestion à un endroit donné. Également, une balise en dessous d’un lien congestionné pourrait communiquer avec ses autres voisins (non-fils dans l’arbre) afin de libérer de l’espace dans le lien avec son père dans l’arbre. Également, le système ne pourra accepter que jusqu’à 1000 utilisateurs par noeud, et également 4000 utilisateurs par cluster (dans le cas d’un réseau avec plusieurs clusters donc plusieurs racines cette limite augmente).

Plusieurs types de paquets circulent sur le réseau de balise:
Les pings, messages envoyés spontanéments à intervalle régulier par les utilisateur contenant l’id ainsi que les deux coordonées gps (27 bits chacun)
Les incidents, identique à un ping mais à priorité haute.
Les alertes, messages brodcastés par le serveur afin d’envoyer un message en chaine de caractères courts et compressés.

=Coûts matériels=

Que ce soit pour le dispositif utilisateur ou la balise (racine ou non), le LoRaOne correspond pour permettre les actions recherchées. Afin de réaliser un prototype pertinent, 6 kits LoRaOne sont requis. Ces kits sont accessibles sur le site de Sodaq au prix de 115€ chacun (prix variable).
Disponible [https://shop.sodaq.com/en/one-eu-rn2483-v2.html ici], voir avant dernier bundle : starter "ONE EU starter" actuellement à 112,10€.

Un [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer buzzer] est à ajouter au dispositif utilisateur afin de lui délivrer un signal sonore.

Un shield GSM est requis pour que la balise racine communique avec l'extérieur. Sodaq en propose un designé pour fonctionner sur leurs produits mais est éctuellement en rupture de stock. Un shield GSM arduino convient tout autant et peut être trouvé sur le site arduino [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna ici].

Aucun boitier ne sera commandé car nous avons fait le choix de les manufacturer nous même au fablab. Le besoin d'étanchéité n'est pas primordial pour notre prototype, bien que nous tenterons de l'assurer.

{|class="récap commande"
|+ Récapitulatif
|-
|
!scope="col" style="width: 320px;"| Produit
!scope="col" style="width: 80px;"| Lien
!scope="col" style="width: 80px;"| Quantité
!scope="col" style="width: 80px;"| Prix Unitaire
|-

!scope="row"| 1
| LoRaOne EU Starter
| [https://shop.sodaq.com/en/one-eu-rn2483-v2.html Achat]
| 6
| 115€
|-

!scope="row"| 2
| Buzzer
| [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer Achat]
| 3
| 5.49€
|-

!scope="row"| 3
| Shield GSM
| [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna Achat]
| 1
| 65€
|-

|}

=Développement=

Nous utiliserons les librairies standards Arduino ainsi que celle de SODAQ/Arduino pour le LoRa.

L'IDE Arduino sera utilisé, plus pratique pour l'utilisation de Git (comparé à Mbed).

= Mise sur le marché =

Ce dispositif a pour but d’être utilisé en montagne, lors de randonnée. Il n’est pas destiné à un usage quotidien, c’est pourquoi nous considérons qu’il est plus judicieux de louer les dispositifs plutôt que de les vendre, même si l’achat n’est pas à omettre de notre stratégie.

Le dispositif peut être commandé en ligne, puis retourné par la poste après usage. Le client louerait le dispositif pour une certaine durée avec un possible nombre supplémentaire de batterie. Les tarifs varient en fonction de la durée et du nombre de batteries louées. Des offres de groupes pourraient être applicables. A long terme, des boutiques pourraient être disséminées dans des grandes villes proches des zones montagneuses, zones à randonnées (Grenoble, Annecy, etc.).

L’application est téléchargeable gratuitement par quiconque, mais utilisable seulement par les clients. Un code d’accès sera envoyé avec le dispositif expirant après la fin de la location.

Il faudra tenir compte de la bande passante du LoRa, variante en fonction des continents.

=Planning=

Sprint 1 : 29/01 --> 09/02 : Création du prototype logiciel #1
*Prise en main du matériel
*Premiers tests de transmissions LoRa
*Création du protocole d'architecture des balises
*Application sur les cartes et tests
*Tests de performances des cartes (durabilité, chargement, batterie)
*Tests de maintenabilité de l'algorithme (déconnexions, latences)

Sprint 2 : 12/02 --> 23/02 : Prototype logiciel #2 et prototype matériel
*Création du programme embarqué (utilisateur)
*Communication avec la racine et le serveur
*Création des maquettes boîtier et balise
*Construction des maquettes
*Finalisation du premier prototype

Sprint 3 : 26/02 --> 09/03 : Fonctionnalités supplémentaires
*Ajout de la communication entre le LoRa et le GSM sur la balise racine
*Création application mobile utilisateur
*Tests sur l'application
*Tests sur la transmission totale depuis l'utilisateur vers le serveur via le GSM
*Finalisation du projet

Sprint 4 : 12/03 --> 16/03 : Fin du projet
*Création de la documentation finale (à partir de la documentation réalisée en continu)
*Pause café
*Temps supplémentaire en cas de problèmes importants
*Préparation de la soutenance

R'Montagne

2018-02-12T10:11:53Z

Hugo.Amodru-Favin: /* Journal */

=Présentation du projet=

==Équipe==
{|class="wikitable"
|-
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Rôle
|-
| Hugo Amodru-Favin
| Chef de Projet
|-
| Antoine Delise
| Lead Developer
|-
| Gwenaël Moreau
| Kanban Master
|-

|}

==Tâches==

Répartition générale des tâches
{|class="wikitable"
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Tâche
|-
| Hugo Amodru-Favin
| Application Ionic
|-
| Antoine Delise
| Développement Arduino
|-
| Gwenaël Moreau
| BDD - API
|-

|}

Détail des tâches : [https://waffle.io/delisea/R-Montagne Lien Waffle.io]

=Journal=

{|class="wikitable"
|+
|-
!scope="col" width="100px"| Date
!scope="col"| Hugo AMODRU-FAVIN
!scope="col"| Antoine DELISE
!scope="col"| Gwenaël MOREAU
|-

| colspan="5" style="text-align: center; background-color:#1c531c; width:225px;"| SPRINT 1
|-

|-
| rowspan="1" | Lundi 29/01/18
| style="width: 225px;" |
* efoed
| style="width: 225px;" |
* sidfjeso
| style="width: 225px;" |
* zdokz
|-
|}

==Randonnée et risques==

Ouvert à tous, la randonnée est un sport et un loisir qui prend de plus en plus d’ampleur de nos jours. Ne nécessitant pas de grands prérequis, des milliers de personnes se lancent en montagne chaque jour, malheureusement parfois sans connaître toutes les mesures de sécurité associées.

En effet, de janvier à juin 2016, en randonnée et en alpinisme, l’Association Nationale pour l’Étude de la Neige et des Avalanches (ANENA) a comptabilisé 21 accidents notables, dont 8 accidents mortels, impliquant 15 décès.

Aujourd’hui, les mesures de sécurités préconisent que chaque groupe de randonneur se doivent de se munir d’un téléphone portable afin d’appeler les secours en cas de problème. Malheureusement, la communication mobile dépendant de la couverture réseau, peu présente en montagne, l’impossibilité de joindre les secours reste un problème.

==Solutions existantes==

La solution la plus répandue, est celle du téléphone à connexion satellite. Ayant une communication vers les satellites, cela permet une couverture réseau beaucoup plus répandue dans les montagnes, partout dans le monde (ou presque). Cependant, les téléphones portables satellitaires coûtent chers, et ne sont pas forcément abordables par la plupart des personnes, surtout celles ne sortant qu’occasionnellement.

[https://fall-alarm.net/ Fall Alarm] est un système de détection de chute sur chantier utilisant les mêmes technologies dont nous avons besoin pour notre projet.

==Quelles zones géographiques ?==

Toutes les zones montagneuses peuvent présenter des zones blanches, démunies de connexion quelconque autre que les connexions satellitaires. Certaines chaînes de montagne comme la Cordillaire des Andes ne présentent aucune connexion possible quelconque.

Dans le cadre de notre projet, nous fonctionnerons essentiellement dans la localisation grenobloise avec l'objectif que notre solution soit applicable partout dans le monde. Une contrainte intervient tout de même étant donnée que la fréquence d'utilisation du LoRa en Europe est de 868MHz, 915MHz en Amérique et 433MHz en Asie.

= Fonctionnalités =

Afin de remplir au mieux ses attentes, le principal objectif de ce dispositif sera premièrement de pouvoir communiquer avec les secours à n’importe quel moment, et surtout n’importe où. De plus, il sera capable de détecter de nombreux cas de détresse de la part de l’usager afin de pouvoir lancer un appel d’urgence sans interaction avec l’usager, au cas où il serait inconscient, ou incapable de lancer un appel manuel.

Grâce aux accéléromètres, le dispositif sera à même de détecter un mouvement brutal du randonneur, ce qui pourrait s’apparenter à une chute. Ils pourront également détecter une position anormale, ou une immobilité prolongée, ce qui déclencherait le dispositif d’urgence automatiquement.

Grâce à des tests réalisés au préalable, le boîtier pourra détecter correctement les chûtes de simples mouvements, afin de ne pas lancer l’appel sans raison valable.

Avant de lancer une alerte automatique, le dispositif émettra un signal auditif et visuel à l’utilisateur quelques secondes auparavant, afin de le prévenir l'émission du signal d’urgence, et de lui proposer de le désactiver sur simple pression d’un bouton, afin d’éviter les communications inutiles.

Également, le randonneur sera à même d'émettre volontairement un appel d’urgence à l’aide du bouton, ce qui permet à tout moment d’appeler de l’aide sans effort. Cela peut permettre également à appeler les secours pour une personne en danger qui ne porterait pas le dispositif.

L’appel au secours se représente par un envoi de coordonnées GPS aux secours, via une communication radio LoRa vers des bornes relais placées au préalables en montagne. Cette communication irait de relai de relai jusqu’au centre de sécurité, d’où le message serait transmis aux secours.

De plus, une application mobile verra le jour afin de connecter tous les utilisateurs du module de sécurité, de les visualiser sur une map, et de partager leurs données. En effet, à chaque incident, l’application mettra à jour la position et de la date de l’accident, afin de permettre aux prochains utilisateurs d’être prévenus. Ils pourraient, s'ils sont à proximité, d'assister la personne en détresse en attendant l'arrivée des secours. Bien évidemment, cette application ne sera accessible uniquement si le smartphone de l'utilisateur est relié à une connexion 4G ou Wi-Fi.

Cette prévention pourrait les sensibiliser aux risques de la montagne, leur permettre d’éviter le secteur mais aussi d’aider les personnes en danger si la distance le permet.

= Exigences =
== Fonctionnelles ==

*Batterie garantie fonctionnelle 1 semaine
*Rechargement possible via le panneau solaire portable
*Dispositif pouvant être allumé et éteint par l'utilisateur
*Alarme s’enclenche automatiquement dès qu'elle est considérée nécessaire, signal sonore
*Utilisateur a la possibilité d’activer/désactiver l’alarme quand il le souhaite
*Lorsque l’alarme est active, l’appareil ne peut s’éteindre
*...

== Non-Fonctionnelles ==

*Résistance : aux chocs, impacts, waterproof (utilisé en permanence en plein air)
*Disponibilité : Appareil de secours -> Doit être au plus possible performant
*Performance : Minimiser les pertes réseaux
*Accessible : Utilisateur pas forcément familier avec des appareils électroniques (facile d’utilisation)
*Fiabilité : Précision du GPS (rayon de 10m), données non-éronnées
*Coût : Le plus faible possible pour vendre le moins cher possible
*Efficacité : Réduire la consommation, utiliser le moins possible les ressources

= Composants =
== LoRaONE ==
Pour le coeur du projet, après avoir cherché et comparés plusieurs modules LoRa, GPS ou encore accéléromètres, nous avons finalement opté pour le projet LoRaONE.

LoRaONE est un projet de SODAQ regroupant plusieurs composants dans une seule et même carte, de taille réduite.

https://www.kickstarter.com/projects/sodaq/loraone-the-lora-iot-development-board

“The one IoT development board to rule them all” --SODAQ

Cette carte regroupe plusieurs capteurs afin de respecter aux mieux nos exigences :

Un émetteur/récepteur LoRa afin de pouvoir communiquer au mieux avec les antennes relai à longue distance

Un module + antenne GPS de bonne précision (< 10m) pour connaître en tout temps notre position, et ainsi faciliter l’arrivée des secours, ainsi que la recherche de l’individu en détresse

Un accéléromètre sur 3 axes afin de pouvoir détecter tout mouvement, vitesse ou rotation dans l’espace, ce qui permet la détection de chutes ou d’arrêt de mouvements

3 LED RGB afin de pouvoir signaler à l’utilisateur un manque de batterie, un signal d’urgence ou plus si nécessaire

Un bouton poussoir pour le signal d’alarme

Un connecteur de charge par panneau solaire, afin de faire durer chaque batterie le plus longtemps possible

Un connecteur micro-USB ainsi que des lignes pour se connecter à une base Arduino si besoin

[[File:LoRaOne.png||400px|Spécifications carte LoRaOne]]

De plus, grâce au starter pack, nous pouvons avoir accès à la base ONEBase qui nous permettrait d’étendre plus loin la facilité d’utilisation du produit :

[[File:LoRaOneBase.png||400px|Spécifications base LoRaOneBase]]

Comme nous pouvons le voir, cette base nous permettra de connecter la batterie ainsi que le panneau solaire qui sont fournis dans le pack.

Nous pourrons également connecter jusqu’à 4 modules supplémentaires.

La batterie fournie aura une capacité de 800 mAh, le panneau solaire fourni pouvant délivrer jusqu’à 500 mW de puissance.

Le total atteint une taille d’environ 10*5 cm, ce qui n’est pas excessif, ce qui le rend aisément portatif sur une jambe ou à la taille.

'''Coût : 115€'''

Ce module pourra également servir d’antenne relai, l'alimentation solaire devrait maintenir le dispositif chargé en permanence. Des tests seront effectués pour savoir si un panneau solaire plus puissant est requis.

== Boîtier ==

Le boîtier sécurisé devant respecter plusieurs exigences, nous pouvons le construire en plastique résistant, ce qui le rendrait léger tout en respectant une rigidité suffisante. Les antennes pourront être placées le long du boîtier, à l’intérieur si la connexion est suffisante, ou à l’extérieur. Dans ce dernier cas les trous réalisés sur le boîtier afin de laisser passer les câbles seront colmatés afin de garantir une étanchéité.

[[File:SchemaBoitier.png||100px|Schéma boitier d'alarme]]

== Balises ==

Afin de remonter les informations transmises par les boitiers, des balises seront mises en places sur la zone à couvrir, leur nombre et leur positions dépendra du terrain (obstacles, dénivelés). On distinguera deux types de balises. Tout d’abord, les balises racines qui permettront une communication GSM afin de faire remonter les données vers le serveur. Viennent ensuite les balises standard qui se contenteront de faire remonter vers leur balise racine associée. L’architecture de liaison des balises est détaillée dans une prochaine partie.

Chaque balise est composée d’une barre de fer pouvant être plantée dans le sol, d’un système de lest afin d’immobiliser la balise, d’un paratonnerre, d’un panneau solaire ainsi que d’un LoraOne et d’une batterie. Les balises racines seront équippée en plus d’un dispositif de communication GSM (téléphone portable, émetteur GSM).

[[File:SchemaBalise.png||150px|Schéma balises d'alarme]]

== Application mobile ==
Une application mobile est téléchargeable par les utilisateurs. Ils peuvent voir les autres utilisateurs présents dans leur zone. Lorsqu’un utilisateur est en position de danger, une notification apparaît si les utilisateurs sont proches de la situation de danger.

Cette application n’est pas directement reliée au dispositif. Elle ne fonctionne qu’avec la connexion du mobile, et est destinée à être un niveau de sécurité supérieur. Un randonneur proche d’une zone de danger pourrait arriver sur place plus rapidement que les secours.

= Communication =

Pour un envoi de position + numéro d’identification (X chiffres) :

*Temps de communication : < 2 s
*Communication régulière, intervalle de 15 minutes

On peut donc au maximum avoir 15 * 60 / 2 = 450 individus pouvant communiquer avec la même antenne relai, donc dans le même cercle d’environ 15 km de diamètre.

On communique donc au minimum 2 secondes sur 15 minutes, donc 1/450 << 1%, le temps de communication est respecté.

En cas de problème, nous pouvons envoyer jusqu’à 9x plus avec la borne sans dépasser le temps de communication autorisé (1%). Donc 1 envoi d’appel d’urgence toutes les 2 minutes environ.

La balise racine peut être directement connectée au serveur, dans ce cas, il n’y a pas de communication GSM nécessaire et pas de Gateway. Si la racine n’est pas directement connectée au serveur, elle devra au minimum garantir une communication GSM (ce qu’elle peut faire, il n’y a pas de Gateway nécessaire) pour remonter l’information vers le serveur, et donc la base de données.

GSM : Si Racine connectée à Serveur -> No GSM + Gateway
Else : GSM + Gateway : LoRa Racine connectée ordi (RaspberryPI) + ordi connecté GSM

= Stabilisation et gestion d’erreurs =

== Choix du routage ==

Notre réseau n'est pas un réseau traditionnel. Les seules communications existantes sont soit une remontée d'information vers la racine soit une innondation d'alerte vers les clients. Pour celà nous avons donc décidé d'utiliser un algorithme de routage simplifié basé uniquement sur un arbre en largeur des balises. Nous rajoutons en option la possibilité de créer plusieurs racines et donc plusieurs arbres dont les racines communiquent par gsm. Nous nous basons sur des papiers de recherches afin de déterminer quel algorithme auto-stabilisant est le plus adapté au système LoRa (Tel que le papier "A self-stabilizing algorithm for constructing breadth-first trees" par Shing-Tsaan Huang, Nian-Shing Chen).

== Stabilisation ==

Afin de gérer la communication de chaque message vers le serveur, nous allons prendre un noeud (balise LoRa) dit “racine” connecté directement au serveur, nous ne nous occuperons pas de la communication au serveur dans cet onglet. Chaque message reçu de la part d’un noeud du système doit être relayé jusqu’à la racine du système afin de communiquer avec les secours (ou serveur simplement).

Pour cela, il faudra assurer que chaque balise LoRa soit connecté au réseau, afin d’avoir au départ un graphe de communication connexe. Par dessus ce graphe, nous allons utiliser un processus silencieux auto-stabilisant qui construira un arbre de parcours en largeur, avec pour racine le noeud “racine” décidé ci-dessus.

Au lancement du système, il faut prévoir un léger temps de stabilisation, qui dépendrait de l’algorithme et de la taille du graphe (nombre de balises). Cependant, après cela, l’algorithme assure un arbre en profondeur minimal qui nous permettrai de communiquer avec la racine le plus rapidement possible, et donc une qualité de service maximale.

== Gestion d’erreurs ==

Dans un réseau comme celui-ci, plusieurs types d’erreurs peuvent se produire :
Délai de communication trop important vers une balise
“Crash” d’une balise de communication
Surpopulation d’une balise ou congestion de messages

Afin de palier au premier type d’incident rencontré, il faut nécessairement qu’à chaque emplacement dans la zone couverte, l’utilisateur soit à même de communiquer avec au minimum 2 balises différentes. Ainsi, dans le cas d’une communication trop longue sur une balise, l’autre aurait de grandes chances de délivrer le message plus rapidement.

Au niveau de la défaillance d’une balise, l’algorithme d’arbre en profondeur nous fournit déjà une solution intégrée grâce à son auto-stabilisation. Dans le cas de déconnexion d’une balise, l’algorithme mettrai à jour automatiquement l’arbre de communication, et n’importe quel message d’alerte émis serait délivré dans un délai raisonnable.

Pour le troisième cas d’erreur, il n’y aurait pas de solution réelle, si ce n’est de limiter le nombre de communications données, en ne prenant plus en compte les “ping” de chaque utilisateur mais seulement les messages d’alertes, ce qui permettrai une bien plus grande gestion de la congestion à un endroit donné. Également, une balise en dessous d’un lien congestionné pourrait communiquer avec ses autres voisins (non-fils dans l’arbre) afin de libérer de l’espace dans le lien avec son père dans l’arbre. Également, le système ne pourra accepter que jusqu’à 1000 utilisateurs par noeud, et également 4000 utilisateurs par cluster (dans le cas d’un réseau avec plusieurs clusters donc plusieurs racines cette limite augmente).

Plusieurs types de paquets circulent sur le réseau de balise:
Les pings, messages envoyés spontanéments à intervalle régulier par les utilisateur contenant l’id ainsi que les deux coordonées gps (27 bits chacun)
Les incidents, identique à un ping mais à priorité haute.
Les alertes, messages brodcastés par le serveur afin d’envoyer un message en chaine de caractères courts et compressés.

=Coûts matériels=

Que ce soit pour le dispositif utilisateur ou la balise (racine ou non), le LoRaOne correspond pour permettre les actions recherchées. Afin de réaliser un prototype pertinent, 6 kits LoRaOne sont requis. Ces kits sont accessibles sur le site de Sodaq au prix de 115€ chacun (prix variable).
Disponible [https://shop.sodaq.com/en/one-eu-rn2483-v2.html ici], voir avant dernier bundle : starter "ONE EU starter" actuellement à 112,10€.

Un [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer buzzer] est à ajouter au dispositif utilisateur afin de lui délivrer un signal sonore.

Un shield GSM est requis pour que la balise racine communique avec l'extérieur. Sodaq en propose un designé pour fonctionner sur leurs produits mais est éctuellement en rupture de stock. Un shield GSM arduino convient tout autant et peut être trouvé sur le site arduino [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna ici].

Aucun boitier ne sera commandé car nous avons fait le choix de les manufacturer nous même au fablab. Le besoin d'étanchéité n'est pas primordial pour notre prototype, bien que nous tenterons de l'assurer.

{|class="récap commande"
|+ Récapitulatif
|-
|
!scope="col" style="width: 320px;"| Produit
!scope="col" style="width: 80px;"| Lien
!scope="col" style="width: 80px;"| Quantité
!scope="col" style="width: 80px;"| Prix Unitaire
|-

!scope="row"| 1
| LoRaOne EU Starter
| [https://shop.sodaq.com/en/one-eu-rn2483-v2.html Achat]
| 6
| 115€
|-

!scope="row"| 2
| Buzzer
| [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer Achat]
| 3
| 5.49€
|-

!scope="row"| 3
| Shield GSM
| [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna Achat]
| 1
| 65€
|-

|}

=Développement=

Nous utiliserons les librairies standards Arduino ainsi que celle de SODAQ/Arduino pour le LoRa.

L'IDE Arduino sera utilisé, plus pratique pour l'utilisation de Git (comparé à Mbed).

= Mise sur le marché =

Ce dispositif a pour but d’être utilisé en montagne, lors de randonnée. Il n’est pas destiné à un usage quotidien, c’est pourquoi nous considérons qu’il est plus judicieux de louer les dispositifs plutôt que de les vendre, même si l’achat n’est pas à omettre de notre stratégie.

Le dispositif peut être commandé en ligne, puis retourné par la poste après usage. Le client louerait le dispositif pour une certaine durée avec un possible nombre supplémentaire de batterie. Les tarifs varient en fonction de la durée et du nombre de batteries louées. Des offres de groupes pourraient être applicables. A long terme, des boutiques pourraient être disséminées dans des grandes villes proches des zones montagneuses, zones à randonnées (Grenoble, Annecy, etc.).

L’application est téléchargeable gratuitement par quiconque, mais utilisable seulement par les clients. Un code d’accès sera envoyé avec le dispositif expirant après la fin de la location.

Il faudra tenir compte de la bande passante du LoRa, variante en fonction des continents.

=Planning=

Sprint 1 : 29/01 --> 09/02 : Création du prototype logiciel #1
*Prise en main du matériel
*Premiers tests de transmissions LoRa
*Création du protocole d'architecture des balises
*Application sur les cartes et tests
*Tests de performances des cartes (durabilité, chargement, batterie)
*Tests de maintenabilité de l'algorithme (déconnexions, latences)

Sprint 2 : 12/02 --> 23/02 : Prototype logiciel #2 et prototype matériel
*Création du programme embarqué (utilisateur)
*Communication avec la racine et le serveur
*Création des maquettes boîtier et balise
*Construction des maquettes
*Finalisation du premier prototype

Sprint 3 : 26/02 --> 09/03 : Fonctionnalités supplémentaires
*Ajout de la communication entre le LoRa et le GSM sur la balise racine
*Création application mobile utilisateur
*Tests sur l'application
*Tests sur la transmission totale depuis l'utilisateur vers le serveur via le GSM
*Finalisation du projet

Sprint 4 : 12/03 --> 16/03 : Fin du projet
*Création de la documentation finale (à partir de la documentation réalisée en continu)
*Pause café
*Temps supplémentaire en cas de problèmes importants
*Préparation de la soutenance

R'Montagne

2018-02-12T10:09:44Z

Hugo.Amodru-Favin: /* Journal */

=Présentation du projet=

==Équipe==
{|class="wikitable"
|-
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Rôle
|-
| Hugo Amodru-Favin
| Chef de Projet
|-
| Antoine Delise
| Lead Developer
|-
| Gwenaël Moreau
| Kanban Master
|-

|}

==Tâches==

Répartition générale des tâches
{|class="wikitable"
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Tâche
|-
| Hugo Amodru-Favin
| Application Ionic
|-
| Antoine Delise
| Développement Arduino
|-
| Gwenaël Moreau
| BDD - API
|-

|}

Détail des tâches : [https://waffle.io/delisea/R-Montagne Lien Waffle.io]

==Journal==

{|class="wikitable"
|+
|-
!scope="col" width="100px"| Date
!scope="col"| Hugo AMODRU-FAVIN
!scope="col"| Antoine DELISE
!scope="col"| Gwenaël MOREAU
|-

| colspan="5" style="text-align: center; background-color:#1c531c; width:225px;"| SPRINT 1
|-

|-
| rowspan="1" | Lundi 29/01/18
| style="width: 225px;" |
* efoed
| style="width: 225px;" |
* sidfjeso
| style="width: 225px;" |
* zdokz
|-
|}

==Randonnée et risques==

Ouvert à tous, la randonnée est un sport et un loisir qui prend de plus en plus d’ampleur de nos jours. Ne nécessitant pas de grands prérequis, des milliers de personnes se lancent en montagne chaque jour, malheureusement parfois sans connaître toutes les mesures de sécurité associées.

En effet, de janvier à juin 2016, en randonnée et en alpinisme, l’Association Nationale pour l’Étude de la Neige et des Avalanches (ANENA) a comptabilisé 21 accidents notables, dont 8 accidents mortels, impliquant 15 décès.

Aujourd’hui, les mesures de sécurités préconisent que chaque groupe de randonneur se doivent de se munir d’un téléphone portable afin d’appeler les secours en cas de problème. Malheureusement, la communication mobile dépendant de la couverture réseau, peu présente en montagne, l’impossibilité de joindre les secours reste un problème.

==Solutions existantes==

La solution la plus répandue, est celle du téléphone à connexion satellite. Ayant une communication vers les satellites, cela permet une couverture réseau beaucoup plus répandue dans les montagnes, partout dans le monde (ou presque). Cependant, les téléphones portables satellitaires coûtent chers, et ne sont pas forcément abordables par la plupart des personnes, surtout celles ne sortant qu’occasionnellement.

[https://fall-alarm.net/ Fall Alarm] est un système de détection de chute sur chantier utilisant les mêmes technologies dont nous avons besoin pour notre projet.

==Quelles zones géographiques ?==

Toutes les zones montagneuses peuvent présenter des zones blanches, démunies de connexion quelconque autre que les connexions satellitaires. Certaines chaînes de montagne comme la Cordillaire des Andes ne présentent aucune connexion possible quelconque.

Dans le cadre de notre projet, nous fonctionnerons essentiellement dans la localisation grenobloise avec l'objectif que notre solution soit applicable partout dans le monde. Une contrainte intervient tout de même étant donnée que la fréquence d'utilisation du LoRa en Europe est de 868MHz, 915MHz en Amérique et 433MHz en Asie.

= Fonctionnalités =

Afin de remplir au mieux ses attentes, le principal objectif de ce dispositif sera premièrement de pouvoir communiquer avec les secours à n’importe quel moment, et surtout n’importe où. De plus, il sera capable de détecter de nombreux cas de détresse de la part de l’usager afin de pouvoir lancer un appel d’urgence sans interaction avec l’usager, au cas où il serait inconscient, ou incapable de lancer un appel manuel.

Grâce aux accéléromètres, le dispositif sera à même de détecter un mouvement brutal du randonneur, ce qui pourrait s’apparenter à une chute. Ils pourront également détecter une position anormale, ou une immobilité prolongée, ce qui déclencherait le dispositif d’urgence automatiquement.

Grâce à des tests réalisés au préalable, le boîtier pourra détecter correctement les chûtes de simples mouvements, afin de ne pas lancer l’appel sans raison valable.

Avant de lancer une alerte automatique, le dispositif émettra un signal auditif et visuel à l’utilisateur quelques secondes auparavant, afin de le prévenir l'émission du signal d’urgence, et de lui proposer de le désactiver sur simple pression d’un bouton, afin d’éviter les communications inutiles.

Également, le randonneur sera à même d'émettre volontairement un appel d’urgence à l’aide du bouton, ce qui permet à tout moment d’appeler de l’aide sans effort. Cela peut permettre également à appeler les secours pour une personne en danger qui ne porterait pas le dispositif.

L’appel au secours se représente par un envoi de coordonnées GPS aux secours, via une communication radio LoRa vers des bornes relais placées au préalables en montagne. Cette communication irait de relai de relai jusqu’au centre de sécurité, d’où le message serait transmis aux secours.

De plus, une application mobile verra le jour afin de connecter tous les utilisateurs du module de sécurité, de les visualiser sur une map, et de partager leurs données. En effet, à chaque incident, l’application mettra à jour la position et de la date de l’accident, afin de permettre aux prochains utilisateurs d’être prévenus. Ils pourraient, s'ils sont à proximité, d'assister la personne en détresse en attendant l'arrivée des secours. Bien évidemment, cette application ne sera accessible uniquement si le smartphone de l'utilisateur est relié à une connexion 4G ou Wi-Fi.

Cette prévention pourrait les sensibiliser aux risques de la montagne, leur permettre d’éviter le secteur mais aussi d’aider les personnes en danger si la distance le permet.

= Exigences =
== Fonctionnelles ==

*Batterie garantie fonctionnelle 1 semaine
*Rechargement possible via le panneau solaire portable
*Dispositif pouvant être allumé et éteint par l'utilisateur
*Alarme s’enclenche automatiquement dès qu'elle est considérée nécessaire, signal sonore
*Utilisateur a la possibilité d’activer/désactiver l’alarme quand il le souhaite
*Lorsque l’alarme est active, l’appareil ne peut s’éteindre
*...

== Non-Fonctionnelles ==

*Résistance : aux chocs, impacts, waterproof (utilisé en permanence en plein air)
*Disponibilité : Appareil de secours -> Doit être au plus possible performant
*Performance : Minimiser les pertes réseaux
*Accessible : Utilisateur pas forcément familier avec des appareils électroniques (facile d’utilisation)
*Fiabilité : Précision du GPS (rayon de 10m), données non-éronnées
*Coût : Le plus faible possible pour vendre le moins cher possible
*Efficacité : Réduire la consommation, utiliser le moins possible les ressources

= Composants =
== LoRaONE ==
Pour le coeur du projet, après avoir cherché et comparés plusieurs modules LoRa, GPS ou encore accéléromètres, nous avons finalement opté pour le projet LoRaONE.

LoRaONE est un projet de SODAQ regroupant plusieurs composants dans une seule et même carte, de taille réduite.

https://www.kickstarter.com/projects/sodaq/loraone-the-lora-iot-development-board

“The one IoT development board to rule them all” --SODAQ

Cette carte regroupe plusieurs capteurs afin de respecter aux mieux nos exigences :

Un émetteur/récepteur LoRa afin de pouvoir communiquer au mieux avec les antennes relai à longue distance

Un module + antenne GPS de bonne précision (< 10m) pour connaître en tout temps notre position, et ainsi faciliter l’arrivée des secours, ainsi que la recherche de l’individu en détresse

Un accéléromètre sur 3 axes afin de pouvoir détecter tout mouvement, vitesse ou rotation dans l’espace, ce qui permet la détection de chutes ou d’arrêt de mouvements

3 LED RGB afin de pouvoir signaler à l’utilisateur un manque de batterie, un signal d’urgence ou plus si nécessaire

Un bouton poussoir pour le signal d’alarme

Un connecteur de charge par panneau solaire, afin de faire durer chaque batterie le plus longtemps possible

Un connecteur micro-USB ainsi que des lignes pour se connecter à une base Arduino si besoin

[[File:LoRaOne.png||400px|Spécifications carte LoRaOne]]

De plus, grâce au starter pack, nous pouvons avoir accès à la base ONEBase qui nous permettrait d’étendre plus loin la facilité d’utilisation du produit :

[[File:LoRaOneBase.png||400px|Spécifications base LoRaOneBase]]

Comme nous pouvons le voir, cette base nous permettra de connecter la batterie ainsi que le panneau solaire qui sont fournis dans le pack.

Nous pourrons également connecter jusqu’à 4 modules supplémentaires.

La batterie fournie aura une capacité de 800 mAh, le panneau solaire fourni pouvant délivrer jusqu’à 500 mW de puissance.

Le total atteint une taille d’environ 10*5 cm, ce qui n’est pas excessif, ce qui le rend aisément portatif sur une jambe ou à la taille.

'''Coût : 115€'''

Ce module pourra également servir d’antenne relai, l'alimentation solaire devrait maintenir le dispositif chargé en permanence. Des tests seront effectués pour savoir si un panneau solaire plus puissant est requis.

== Boîtier ==

Le boîtier sécurisé devant respecter plusieurs exigences, nous pouvons le construire en plastique résistant, ce qui le rendrait léger tout en respectant une rigidité suffisante. Les antennes pourront être placées le long du boîtier, à l’intérieur si la connexion est suffisante, ou à l’extérieur. Dans ce dernier cas les trous réalisés sur le boîtier afin de laisser passer les câbles seront colmatés afin de garantir une étanchéité.

[[File:SchemaBoitier.png||100px|Schéma boitier d'alarme]]

== Balises ==

Afin de remonter les informations transmises par les boitiers, des balises seront mises en places sur la zone à couvrir, leur nombre et leur positions dépendra du terrain (obstacles, dénivelés). On distinguera deux types de balises. Tout d’abord, les balises racines qui permettront une communication GSM afin de faire remonter les données vers le serveur. Viennent ensuite les balises standard qui se contenteront de faire remonter vers leur balise racine associée. L’architecture de liaison des balises est détaillée dans une prochaine partie.

Chaque balise est composée d’une barre de fer pouvant être plantée dans le sol, d’un système de lest afin d’immobiliser la balise, d’un paratonnerre, d’un panneau solaire ainsi que d’un LoraOne et d’une batterie. Les balises racines seront équippée en plus d’un dispositif de communication GSM (téléphone portable, émetteur GSM).

[[File:SchemaBalise.png||150px|Schéma balises d'alarme]]

== Application mobile ==
Une application mobile est téléchargeable par les utilisateurs. Ils peuvent voir les autres utilisateurs présents dans leur zone. Lorsqu’un utilisateur est en position de danger, une notification apparaît si les utilisateurs sont proches de la situation de danger.

Cette application n’est pas directement reliée au dispositif. Elle ne fonctionne qu’avec la connexion du mobile, et est destinée à être un niveau de sécurité supérieur. Un randonneur proche d’une zone de danger pourrait arriver sur place plus rapidement que les secours.

= Communication =

Pour un envoi de position + numéro d’identification (X chiffres) :

*Temps de communication : < 2 s
*Communication régulière, intervalle de 15 minutes

On peut donc au maximum avoir 15 * 60 / 2 = 450 individus pouvant communiquer avec la même antenne relai, donc dans le même cercle d’environ 15 km de diamètre.

On communique donc au minimum 2 secondes sur 15 minutes, donc 1/450 << 1%, le temps de communication est respecté.

En cas de problème, nous pouvons envoyer jusqu’à 9x plus avec la borne sans dépasser le temps de communication autorisé (1%). Donc 1 envoi d’appel d’urgence toutes les 2 minutes environ.

La balise racine peut être directement connectée au serveur, dans ce cas, il n’y a pas de communication GSM nécessaire et pas de Gateway. Si la racine n’est pas directement connectée au serveur, elle devra au minimum garantir une communication GSM (ce qu’elle peut faire, il n’y a pas de Gateway nécessaire) pour remonter l’information vers le serveur, et donc la base de données.

GSM : Si Racine connectée à Serveur -> No GSM + Gateway
Else : GSM + Gateway : LoRa Racine connectée ordi (RaspberryPI) + ordi connecté GSM

= Stabilisation et gestion d’erreurs =

== Choix du routage ==

Notre réseau n'est pas un réseau traditionnel. Les seules communications existantes sont soit une remontée d'information vers la racine soit une innondation d'alerte vers les clients. Pour celà nous avons donc décidé d'utiliser un algorithme de routage simplifié basé uniquement sur un arbre en largeur des balises. Nous rajoutons en option la possibilité de créer plusieurs racines et donc plusieurs arbres dont les racines communiquent par gsm. Nous nous basons sur des papiers de recherches afin de déterminer quel algorithme auto-stabilisant est le plus adapté au système LoRa (Tel que le papier "A self-stabilizing algorithm for constructing breadth-first trees" par Shing-Tsaan Huang, Nian-Shing Chen).

== Stabilisation ==

Afin de gérer la communication de chaque message vers le serveur, nous allons prendre un noeud (balise LoRa) dit “racine” connecté directement au serveur, nous ne nous occuperons pas de la communication au serveur dans cet onglet. Chaque message reçu de la part d’un noeud du système doit être relayé jusqu’à la racine du système afin de communiquer avec les secours (ou serveur simplement).

Pour cela, il faudra assurer que chaque balise LoRa soit connecté au réseau, afin d’avoir au départ un graphe de communication connexe. Par dessus ce graphe, nous allons utiliser un processus silencieux auto-stabilisant qui construira un arbre de parcours en largeur, avec pour racine le noeud “racine” décidé ci-dessus.

Au lancement du système, il faut prévoir un léger temps de stabilisation, qui dépendrait de l’algorithme et de la taille du graphe (nombre de balises). Cependant, après cela, l’algorithme assure un arbre en profondeur minimal qui nous permettrai de communiquer avec la racine le plus rapidement possible, et donc une qualité de service maximale.

== Gestion d’erreurs ==

Dans un réseau comme celui-ci, plusieurs types d’erreurs peuvent se produire :
Délai de communication trop important vers une balise
“Crash” d’une balise de communication
Surpopulation d’une balise ou congestion de messages

Afin de palier au premier type d’incident rencontré, il faut nécessairement qu’à chaque emplacement dans la zone couverte, l’utilisateur soit à même de communiquer avec au minimum 2 balises différentes. Ainsi, dans le cas d’une communication trop longue sur une balise, l’autre aurait de grandes chances de délivrer le message plus rapidement.

Au niveau de la défaillance d’une balise, l’algorithme d’arbre en profondeur nous fournit déjà une solution intégrée grâce à son auto-stabilisation. Dans le cas de déconnexion d’une balise, l’algorithme mettrai à jour automatiquement l’arbre de communication, et n’importe quel message d’alerte émis serait délivré dans un délai raisonnable.

Pour le troisième cas d’erreur, il n’y aurait pas de solution réelle, si ce n’est de limiter le nombre de communications données, en ne prenant plus en compte les “ping” de chaque utilisateur mais seulement les messages d’alertes, ce qui permettrai une bien plus grande gestion de la congestion à un endroit donné. Également, une balise en dessous d’un lien congestionné pourrait communiquer avec ses autres voisins (non-fils dans l’arbre) afin de libérer de l’espace dans le lien avec son père dans l’arbre. Également, le système ne pourra accepter que jusqu’à 1000 utilisateurs par noeud, et également 4000 utilisateurs par cluster (dans le cas d’un réseau avec plusieurs clusters donc plusieurs racines cette limite augmente).

Plusieurs types de paquets circulent sur le réseau de balise:
Les pings, messages envoyés spontanéments à intervalle régulier par les utilisateur contenant l’id ainsi que les deux coordonées gps (27 bits chacun)
Les incidents, identique à un ping mais à priorité haute.
Les alertes, messages brodcastés par le serveur afin d’envoyer un message en chaine de caractères courts et compressés.

=Coûts matériels=

Que ce soit pour le dispositif utilisateur ou la balise (racine ou non), le LoRaOne correspond pour permettre les actions recherchées. Afin de réaliser un prototype pertinent, 6 kits LoRaOne sont requis. Ces kits sont accessibles sur le site de Sodaq au prix de 115€ chacun (prix variable).
Disponible [https://shop.sodaq.com/en/one-eu-rn2483-v2.html ici], voir avant dernier bundle : starter "ONE EU starter" actuellement à 112,10€.

Un [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer buzzer] est à ajouter au dispositif utilisateur afin de lui délivrer un signal sonore.

Un shield GSM est requis pour que la balise racine communique avec l'extérieur. Sodaq en propose un designé pour fonctionner sur leurs produits mais est éctuellement en rupture de stock. Un shield GSM arduino convient tout autant et peut être trouvé sur le site arduino [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna ici].

Aucun boitier ne sera commandé car nous avons fait le choix de les manufacturer nous même au fablab. Le besoin d'étanchéité n'est pas primordial pour notre prototype, bien que nous tenterons de l'assurer.

{|class="récap commande"
|+ Récapitulatif
|-
|
!scope="col" style="width: 320px;"| Produit
!scope="col" style="width: 80px;"| Lien
!scope="col" style="width: 80px;"| Quantité
!scope="col" style="width: 80px;"| Prix Unitaire
|-

!scope="row"| 1
| LoRaOne EU Starter
| [https://shop.sodaq.com/en/one-eu-rn2483-v2.html Achat]
| 6
| 115€
|-

!scope="row"| 2
| Buzzer
| [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer Achat]
| 3
| 5.49€
|-

!scope="row"| 3
| Shield GSM
| [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna Achat]
| 1
| 65€
|-

|}

=Développement=

Nous utiliserons les librairies standards Arduino ainsi que celle de SODAQ/Arduino pour le LoRa.

L'IDE Arduino sera utilisé, plus pratique pour l'utilisation de Git (comparé à Mbed).

= Mise sur le marché =

Ce dispositif a pour but d’être utilisé en montagne, lors de randonnée. Il n’est pas destiné à un usage quotidien, c’est pourquoi nous considérons qu’il est plus judicieux de louer les dispositifs plutôt que de les vendre, même si l’achat n’est pas à omettre de notre stratégie.

Le dispositif peut être commandé en ligne, puis retourné par la poste après usage. Le client louerait le dispositif pour une certaine durée avec un possible nombre supplémentaire de batterie. Les tarifs varient en fonction de la durée et du nombre de batteries louées. Des offres de groupes pourraient être applicables. A long terme, des boutiques pourraient être disséminées dans des grandes villes proches des zones montagneuses, zones à randonnées (Grenoble, Annecy, etc.).

L’application est téléchargeable gratuitement par quiconque, mais utilisable seulement par les clients. Un code d’accès sera envoyé avec le dispositif expirant après la fin de la location.

Il faudra tenir compte de la bande passante du LoRa, variante en fonction des continents.

=Planning=

Sprint 1 : 29/01 --> 09/02 : Création du prototype logiciel #1
*Prise en main du matériel
*Premiers tests de transmissions LoRa
*Création du protocole d'architecture des balises
*Application sur les cartes et tests
*Tests de performances des cartes (durabilité, chargement, batterie)
*Tests de maintenabilité de l'algorithme (déconnexions, latences)

Sprint 2 : 12/02 --> 23/02 : Prototype logiciel #2 et prototype matériel
*Création du programme embarqué (utilisateur)
*Communication avec la racine et le serveur
*Création des maquettes boîtier et balise
*Construction des maquettes
*Finalisation du premier prototype

Sprint 3 : 26/02 --> 09/03 : Fonctionnalités supplémentaires
*Ajout de la communication entre le LoRa et le GSM sur la balise racine
*Création application mobile utilisateur
*Tests sur l'application
*Tests sur la transmission totale depuis l'utilisateur vers le serveur via le GSM
*Finalisation du projet

Sprint 4 : 12/03 --> 16/03 : Fin du projet
*Création de la documentation finale (à partir de la documentation réalisée en continu)
*Pause café
*Temps supplémentaire en cas de problèmes importants
*Préparation de la soutenance

R'Montagne

2018-02-12T10:09:34Z

Hugo.Amodru-Favin: /* Journal */

=Présentation du projet=

==Équipe==
{|class="wikitable"
|-
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Rôle
|-
| Hugo Amodru-Favin
| Chef de Projet
|-
| Antoine Delise
| Lead Developer
|-
| Gwenaël Moreau
| Kanban Master
|-

|}

==Tâches==

Répartition générale des tâches
{|class="wikitable"
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Tâche
|-
| Hugo Amodru-Favin
| Application Ionic
|-
| Antoine Delise
| Développement Arduino
|-
| Gwenaël Moreau
| BDD - API
|-

|}

Détail des tâches : [https://waffle.io/delisea/R-Montagne Lien Waffle.io]

==Journal==

{|class="wikitable"
|+
|-
!scope="col" width="225px"| Date
!scope="col"| Hugo AMODRU-FAVIN
!scope="col"| Antoine DELISE
!scope="col"| Gwenaël MOREAU
|-

| colspan="5" style="text-align: center; background-color:#1c531c; width:225px;"| SPRINT 1
|-

|-
| rowspan="1" | Lundi 29/01/18
| style="width: 225px;" |
* efoed
| style="width: 225px;" |
* sidfjeso
| style="width: 225px;" |
* zdokz
|-
|}

==Randonnée et risques==

Ouvert à tous, la randonnée est un sport et un loisir qui prend de plus en plus d’ampleur de nos jours. Ne nécessitant pas de grands prérequis, des milliers de personnes se lancent en montagne chaque jour, malheureusement parfois sans connaître toutes les mesures de sécurité associées.

En effet, de janvier à juin 2016, en randonnée et en alpinisme, l’Association Nationale pour l’Étude de la Neige et des Avalanches (ANENA) a comptabilisé 21 accidents notables, dont 8 accidents mortels, impliquant 15 décès.

Aujourd’hui, les mesures de sécurités préconisent que chaque groupe de randonneur se doivent de se munir d’un téléphone portable afin d’appeler les secours en cas de problème. Malheureusement, la communication mobile dépendant de la couverture réseau, peu présente en montagne, l’impossibilité de joindre les secours reste un problème.

==Solutions existantes==

La solution la plus répandue, est celle du téléphone à connexion satellite. Ayant une communication vers les satellites, cela permet une couverture réseau beaucoup plus répandue dans les montagnes, partout dans le monde (ou presque). Cependant, les téléphones portables satellitaires coûtent chers, et ne sont pas forcément abordables par la plupart des personnes, surtout celles ne sortant qu’occasionnellement.

[https://fall-alarm.net/ Fall Alarm] est un système de détection de chute sur chantier utilisant les mêmes technologies dont nous avons besoin pour notre projet.

==Quelles zones géographiques ?==

Toutes les zones montagneuses peuvent présenter des zones blanches, démunies de connexion quelconque autre que les connexions satellitaires. Certaines chaînes de montagne comme la Cordillaire des Andes ne présentent aucune connexion possible quelconque.

Dans le cadre de notre projet, nous fonctionnerons essentiellement dans la localisation grenobloise avec l'objectif que notre solution soit applicable partout dans le monde. Une contrainte intervient tout de même étant donnée que la fréquence d'utilisation du LoRa en Europe est de 868MHz, 915MHz en Amérique et 433MHz en Asie.

= Fonctionnalités =

Afin de remplir au mieux ses attentes, le principal objectif de ce dispositif sera premièrement de pouvoir communiquer avec les secours à n’importe quel moment, et surtout n’importe où. De plus, il sera capable de détecter de nombreux cas de détresse de la part de l’usager afin de pouvoir lancer un appel d’urgence sans interaction avec l’usager, au cas où il serait inconscient, ou incapable de lancer un appel manuel.

Grâce aux accéléromètres, le dispositif sera à même de détecter un mouvement brutal du randonneur, ce qui pourrait s’apparenter à une chute. Ils pourront également détecter une position anormale, ou une immobilité prolongée, ce qui déclencherait le dispositif d’urgence automatiquement.

Grâce à des tests réalisés au préalable, le boîtier pourra détecter correctement les chûtes de simples mouvements, afin de ne pas lancer l’appel sans raison valable.

Avant de lancer une alerte automatique, le dispositif émettra un signal auditif et visuel à l’utilisateur quelques secondes auparavant, afin de le prévenir l'émission du signal d’urgence, et de lui proposer de le désactiver sur simple pression d’un bouton, afin d’éviter les communications inutiles.

Également, le randonneur sera à même d'émettre volontairement un appel d’urgence à l’aide du bouton, ce qui permet à tout moment d’appeler de l’aide sans effort. Cela peut permettre également à appeler les secours pour une personne en danger qui ne porterait pas le dispositif.

L’appel au secours se représente par un envoi de coordonnées GPS aux secours, via une communication radio LoRa vers des bornes relais placées au préalables en montagne. Cette communication irait de relai de relai jusqu’au centre de sécurité, d’où le message serait transmis aux secours.

De plus, une application mobile verra le jour afin de connecter tous les utilisateurs du module de sécurité, de les visualiser sur une map, et de partager leurs données. En effet, à chaque incident, l’application mettra à jour la position et de la date de l’accident, afin de permettre aux prochains utilisateurs d’être prévenus. Ils pourraient, s'ils sont à proximité, d'assister la personne en détresse en attendant l'arrivée des secours. Bien évidemment, cette application ne sera accessible uniquement si le smartphone de l'utilisateur est relié à une connexion 4G ou Wi-Fi.

Cette prévention pourrait les sensibiliser aux risques de la montagne, leur permettre d’éviter le secteur mais aussi d’aider les personnes en danger si la distance le permet.

= Exigences =
== Fonctionnelles ==

*Batterie garantie fonctionnelle 1 semaine
*Rechargement possible via le panneau solaire portable
*Dispositif pouvant être allumé et éteint par l'utilisateur
*Alarme s’enclenche automatiquement dès qu'elle est considérée nécessaire, signal sonore
*Utilisateur a la possibilité d’activer/désactiver l’alarme quand il le souhaite
*Lorsque l’alarme est active, l’appareil ne peut s’éteindre
*...

== Non-Fonctionnelles ==

*Résistance : aux chocs, impacts, waterproof (utilisé en permanence en plein air)
*Disponibilité : Appareil de secours -> Doit être au plus possible performant
*Performance : Minimiser les pertes réseaux
*Accessible : Utilisateur pas forcément familier avec des appareils électroniques (facile d’utilisation)
*Fiabilité : Précision du GPS (rayon de 10m), données non-éronnées
*Coût : Le plus faible possible pour vendre le moins cher possible
*Efficacité : Réduire la consommation, utiliser le moins possible les ressources

= Composants =
== LoRaONE ==
Pour le coeur du projet, après avoir cherché et comparés plusieurs modules LoRa, GPS ou encore accéléromètres, nous avons finalement opté pour le projet LoRaONE.

LoRaONE est un projet de SODAQ regroupant plusieurs composants dans une seule et même carte, de taille réduite.

https://www.kickstarter.com/projects/sodaq/loraone-the-lora-iot-development-board

“The one IoT development board to rule them all” --SODAQ

Cette carte regroupe plusieurs capteurs afin de respecter aux mieux nos exigences :

Un émetteur/récepteur LoRa afin de pouvoir communiquer au mieux avec les antennes relai à longue distance

Un module + antenne GPS de bonne précision (< 10m) pour connaître en tout temps notre position, et ainsi faciliter l’arrivée des secours, ainsi que la recherche de l’individu en détresse

Un accéléromètre sur 3 axes afin de pouvoir détecter tout mouvement, vitesse ou rotation dans l’espace, ce qui permet la détection de chutes ou d’arrêt de mouvements

3 LED RGB afin de pouvoir signaler à l’utilisateur un manque de batterie, un signal d’urgence ou plus si nécessaire

Un bouton poussoir pour le signal d’alarme

Un connecteur de charge par panneau solaire, afin de faire durer chaque batterie le plus longtemps possible

Un connecteur micro-USB ainsi que des lignes pour se connecter à une base Arduino si besoin

[[File:LoRaOne.png||400px|Spécifications carte LoRaOne]]

De plus, grâce au starter pack, nous pouvons avoir accès à la base ONEBase qui nous permettrait d’étendre plus loin la facilité d’utilisation du produit :

[[File:LoRaOneBase.png||400px|Spécifications base LoRaOneBase]]

Comme nous pouvons le voir, cette base nous permettra de connecter la batterie ainsi que le panneau solaire qui sont fournis dans le pack.

Nous pourrons également connecter jusqu’à 4 modules supplémentaires.

La batterie fournie aura une capacité de 800 mAh, le panneau solaire fourni pouvant délivrer jusqu’à 500 mW de puissance.

Le total atteint une taille d’environ 10*5 cm, ce qui n’est pas excessif, ce qui le rend aisément portatif sur une jambe ou à la taille.

'''Coût : 115€'''

Ce module pourra également servir d’antenne relai, l'alimentation solaire devrait maintenir le dispositif chargé en permanence. Des tests seront effectués pour savoir si un panneau solaire plus puissant est requis.

== Boîtier ==

Le boîtier sécurisé devant respecter plusieurs exigences, nous pouvons le construire en plastique résistant, ce qui le rendrait léger tout en respectant une rigidité suffisante. Les antennes pourront être placées le long du boîtier, à l’intérieur si la connexion est suffisante, ou à l’extérieur. Dans ce dernier cas les trous réalisés sur le boîtier afin de laisser passer les câbles seront colmatés afin de garantir une étanchéité.

[[File:SchemaBoitier.png||100px|Schéma boitier d'alarme]]

== Balises ==

Afin de remonter les informations transmises par les boitiers, des balises seront mises en places sur la zone à couvrir, leur nombre et leur positions dépendra du terrain (obstacles, dénivelés). On distinguera deux types de balises. Tout d’abord, les balises racines qui permettront une communication GSM afin de faire remonter les données vers le serveur. Viennent ensuite les balises standard qui se contenteront de faire remonter vers leur balise racine associée. L’architecture de liaison des balises est détaillée dans une prochaine partie.

Chaque balise est composée d’une barre de fer pouvant être plantée dans le sol, d’un système de lest afin d’immobiliser la balise, d’un paratonnerre, d’un panneau solaire ainsi que d’un LoraOne et d’une batterie. Les balises racines seront équippée en plus d’un dispositif de communication GSM (téléphone portable, émetteur GSM).

[[File:SchemaBalise.png||150px|Schéma balises d'alarme]]

== Application mobile ==
Une application mobile est téléchargeable par les utilisateurs. Ils peuvent voir les autres utilisateurs présents dans leur zone. Lorsqu’un utilisateur est en position de danger, une notification apparaît si les utilisateurs sont proches de la situation de danger.

Cette application n’est pas directement reliée au dispositif. Elle ne fonctionne qu’avec la connexion du mobile, et est destinée à être un niveau de sécurité supérieur. Un randonneur proche d’une zone de danger pourrait arriver sur place plus rapidement que les secours.

= Communication =

Pour un envoi de position + numéro d’identification (X chiffres) :

*Temps de communication : < 2 s
*Communication régulière, intervalle de 15 minutes

On peut donc au maximum avoir 15 * 60 / 2 = 450 individus pouvant communiquer avec la même antenne relai, donc dans le même cercle d’environ 15 km de diamètre.

On communique donc au minimum 2 secondes sur 15 minutes, donc 1/450 << 1%, le temps de communication est respecté.

En cas de problème, nous pouvons envoyer jusqu’à 9x plus avec la borne sans dépasser le temps de communication autorisé (1%). Donc 1 envoi d’appel d’urgence toutes les 2 minutes environ.

La balise racine peut être directement connectée au serveur, dans ce cas, il n’y a pas de communication GSM nécessaire et pas de Gateway. Si la racine n’est pas directement connectée au serveur, elle devra au minimum garantir une communication GSM (ce qu’elle peut faire, il n’y a pas de Gateway nécessaire) pour remonter l’information vers le serveur, et donc la base de données.

GSM : Si Racine connectée à Serveur -> No GSM + Gateway
Else : GSM + Gateway : LoRa Racine connectée ordi (RaspberryPI) + ordi connecté GSM

= Stabilisation et gestion d’erreurs =

== Choix du routage ==

Notre réseau n'est pas un réseau traditionnel. Les seules communications existantes sont soit une remontée d'information vers la racine soit une innondation d'alerte vers les clients. Pour celà nous avons donc décidé d'utiliser un algorithme de routage simplifié basé uniquement sur un arbre en largeur des balises. Nous rajoutons en option la possibilité de créer plusieurs racines et donc plusieurs arbres dont les racines communiquent par gsm. Nous nous basons sur des papiers de recherches afin de déterminer quel algorithme auto-stabilisant est le plus adapté au système LoRa (Tel que le papier "A self-stabilizing algorithm for constructing breadth-first trees" par Shing-Tsaan Huang, Nian-Shing Chen).

== Stabilisation ==

Afin de gérer la communication de chaque message vers le serveur, nous allons prendre un noeud (balise LoRa) dit “racine” connecté directement au serveur, nous ne nous occuperons pas de la communication au serveur dans cet onglet. Chaque message reçu de la part d’un noeud du système doit être relayé jusqu’à la racine du système afin de communiquer avec les secours (ou serveur simplement).

Pour cela, il faudra assurer que chaque balise LoRa soit connecté au réseau, afin d’avoir au départ un graphe de communication connexe. Par dessus ce graphe, nous allons utiliser un processus silencieux auto-stabilisant qui construira un arbre de parcours en largeur, avec pour racine le noeud “racine” décidé ci-dessus.

Au lancement du système, il faut prévoir un léger temps de stabilisation, qui dépendrait de l’algorithme et de la taille du graphe (nombre de balises). Cependant, après cela, l’algorithme assure un arbre en profondeur minimal qui nous permettrai de communiquer avec la racine le plus rapidement possible, et donc une qualité de service maximale.

== Gestion d’erreurs ==

Dans un réseau comme celui-ci, plusieurs types d’erreurs peuvent se produire :
Délai de communication trop important vers une balise
“Crash” d’une balise de communication
Surpopulation d’une balise ou congestion de messages

Afin de palier au premier type d’incident rencontré, il faut nécessairement qu’à chaque emplacement dans la zone couverte, l’utilisateur soit à même de communiquer avec au minimum 2 balises différentes. Ainsi, dans le cas d’une communication trop longue sur une balise, l’autre aurait de grandes chances de délivrer le message plus rapidement.

Au niveau de la défaillance d’une balise, l’algorithme d’arbre en profondeur nous fournit déjà une solution intégrée grâce à son auto-stabilisation. Dans le cas de déconnexion d’une balise, l’algorithme mettrai à jour automatiquement l’arbre de communication, et n’importe quel message d’alerte émis serait délivré dans un délai raisonnable.

Pour le troisième cas d’erreur, il n’y aurait pas de solution réelle, si ce n’est de limiter le nombre de communications données, en ne prenant plus en compte les “ping” de chaque utilisateur mais seulement les messages d’alertes, ce qui permettrai une bien plus grande gestion de la congestion à un endroit donné. Également, une balise en dessous d’un lien congestionné pourrait communiquer avec ses autres voisins (non-fils dans l’arbre) afin de libérer de l’espace dans le lien avec son père dans l’arbre. Également, le système ne pourra accepter que jusqu’à 1000 utilisateurs par noeud, et également 4000 utilisateurs par cluster (dans le cas d’un réseau avec plusieurs clusters donc plusieurs racines cette limite augmente).

Plusieurs types de paquets circulent sur le réseau de balise:
Les pings, messages envoyés spontanéments à intervalle régulier par les utilisateur contenant l’id ainsi que les deux coordonées gps (27 bits chacun)
Les incidents, identique à un ping mais à priorité haute.
Les alertes, messages brodcastés par le serveur afin d’envoyer un message en chaine de caractères courts et compressés.

=Coûts matériels=

Que ce soit pour le dispositif utilisateur ou la balise (racine ou non), le LoRaOne correspond pour permettre les actions recherchées. Afin de réaliser un prototype pertinent, 6 kits LoRaOne sont requis. Ces kits sont accessibles sur le site de Sodaq au prix de 115€ chacun (prix variable).
Disponible [https://shop.sodaq.com/en/one-eu-rn2483-v2.html ici], voir avant dernier bundle : starter "ONE EU starter" actuellement à 112,10€.

Un [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer buzzer] est à ajouter au dispositif utilisateur afin de lui délivrer un signal sonore.

Un shield GSM est requis pour que la balise racine communique avec l'extérieur. Sodaq en propose un designé pour fonctionner sur leurs produits mais est éctuellement en rupture de stock. Un shield GSM arduino convient tout autant et peut être trouvé sur le site arduino [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna ici].

Aucun boitier ne sera commandé car nous avons fait le choix de les manufacturer nous même au fablab. Le besoin d'étanchéité n'est pas primordial pour notre prototype, bien que nous tenterons de l'assurer.

{|class="récap commande"
|+ Récapitulatif
|-
|
!scope="col" style="width: 320px;"| Produit
!scope="col" style="width: 80px;"| Lien
!scope="col" style="width: 80px;"| Quantité
!scope="col" style="width: 80px;"| Prix Unitaire
|-

!scope="row"| 1
| LoRaOne EU Starter
| [https://shop.sodaq.com/en/one-eu-rn2483-v2.html Achat]
| 6
| 115€
|-

!scope="row"| 2
| Buzzer
| [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer Achat]
| 3
| 5.49€
|-

!scope="row"| 3
| Shield GSM
| [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna Achat]
| 1
| 65€
|-

|}

=Développement=

Nous utiliserons les librairies standards Arduino ainsi que celle de SODAQ/Arduino pour le LoRa.

L'IDE Arduino sera utilisé, plus pratique pour l'utilisation de Git (comparé à Mbed).

= Mise sur le marché =

Ce dispositif a pour but d’être utilisé en montagne, lors de randonnée. Il n’est pas destiné à un usage quotidien, c’est pourquoi nous considérons qu’il est plus judicieux de louer les dispositifs plutôt que de les vendre, même si l’achat n’est pas à omettre de notre stratégie.

Le dispositif peut être commandé en ligne, puis retourné par la poste après usage. Le client louerait le dispositif pour une certaine durée avec un possible nombre supplémentaire de batterie. Les tarifs varient en fonction de la durée et du nombre de batteries louées. Des offres de groupes pourraient être applicables. A long terme, des boutiques pourraient être disséminées dans des grandes villes proches des zones montagneuses, zones à randonnées (Grenoble, Annecy, etc.).

L’application est téléchargeable gratuitement par quiconque, mais utilisable seulement par les clients. Un code d’accès sera envoyé avec le dispositif expirant après la fin de la location.

Il faudra tenir compte de la bande passante du LoRa, variante en fonction des continents.

=Planning=

Sprint 1 : 29/01 --> 09/02 : Création du prototype logiciel #1
*Prise en main du matériel
*Premiers tests de transmissions LoRa
*Création du protocole d'architecture des balises
*Application sur les cartes et tests
*Tests de performances des cartes (durabilité, chargement, batterie)
*Tests de maintenabilité de l'algorithme (déconnexions, latences)

Sprint 2 : 12/02 --> 23/02 : Prototype logiciel #2 et prototype matériel
*Création du programme embarqué (utilisateur)
*Communication avec la racine et le serveur
*Création des maquettes boîtier et balise
*Construction des maquettes
*Finalisation du premier prototype

Sprint 3 : 26/02 --> 09/03 : Fonctionnalités supplémentaires
*Ajout de la communication entre le LoRa et le GSM sur la balise racine
*Création application mobile utilisateur
*Tests sur l'application
*Tests sur la transmission totale depuis l'utilisateur vers le serveur via le GSM
*Finalisation du projet

Sprint 4 : 12/03 --> 16/03 : Fin du projet
*Création de la documentation finale (à partir de la documentation réalisée en continu)
*Pause café
*Temps supplémentaire en cas de problèmes importants
*Préparation de la soutenance

R'Montagne

2018-02-12T10:09:06Z

Hugo.Amodru-Favin: /* Journal */

=Présentation du projet=

==Équipe==
{|class="wikitable"
|-
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Rôle
|-
| Hugo Amodru-Favin
| Chef de Projet
|-
| Antoine Delise
| Lead Developer
|-
| Gwenaël Moreau
| Kanban Master
|-

|}

==Tâches==

Répartition générale des tâches
{|class="wikitable"
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Tâche
|-
| Hugo Amodru-Favin
| Application Ionic
|-
| Antoine Delise
| Développement Arduino
|-
| Gwenaël Moreau
| BDD - API
|-

|}

Détail des tâches : [https://waffle.io/delisea/R-Montagne Lien Waffle.io]

==Journal==

{|class="wikitable"
|+
|-
!scope="col" width:"225px"| Date
!scope="col"| Hugo AMODRU-FAVIN
!scope="col"| Antoine DELISE
!scope="col"| Gwenaël MOREAU
|-

| colspan="5" style="text-align: center; background-color:#1c531c; width:225px;"| SPRINT 1
|-

|-
| rowspan="1" | Lundi 29/01/18
| style="width: 225px;" |
* efoed
| style="width: 225px;" |
* sidfjeso
| style="width: 225px;" |
* zdokz
|-
|}

==Randonnée et risques==

Ouvert à tous, la randonnée est un sport et un loisir qui prend de plus en plus d’ampleur de nos jours. Ne nécessitant pas de grands prérequis, des milliers de personnes se lancent en montagne chaque jour, malheureusement parfois sans connaître toutes les mesures de sécurité associées.

En effet, de janvier à juin 2016, en randonnée et en alpinisme, l’Association Nationale pour l’Étude de la Neige et des Avalanches (ANENA) a comptabilisé 21 accidents notables, dont 8 accidents mortels, impliquant 15 décès.

Aujourd’hui, les mesures de sécurités préconisent que chaque groupe de randonneur se doivent de se munir d’un téléphone portable afin d’appeler les secours en cas de problème. Malheureusement, la communication mobile dépendant de la couverture réseau, peu présente en montagne, l’impossibilité de joindre les secours reste un problème.

==Solutions existantes==

La solution la plus répandue, est celle du téléphone à connexion satellite. Ayant une communication vers les satellites, cela permet une couverture réseau beaucoup plus répandue dans les montagnes, partout dans le monde (ou presque). Cependant, les téléphones portables satellitaires coûtent chers, et ne sont pas forcément abordables par la plupart des personnes, surtout celles ne sortant qu’occasionnellement.

[https://fall-alarm.net/ Fall Alarm] est un système de détection de chute sur chantier utilisant les mêmes technologies dont nous avons besoin pour notre projet.

==Quelles zones géographiques ?==

Toutes les zones montagneuses peuvent présenter des zones blanches, démunies de connexion quelconque autre que les connexions satellitaires. Certaines chaînes de montagne comme la Cordillaire des Andes ne présentent aucune connexion possible quelconque.

Dans le cadre de notre projet, nous fonctionnerons essentiellement dans la localisation grenobloise avec l'objectif que notre solution soit applicable partout dans le monde. Une contrainte intervient tout de même étant donnée que la fréquence d'utilisation du LoRa en Europe est de 868MHz, 915MHz en Amérique et 433MHz en Asie.

= Fonctionnalités =

Afin de remplir au mieux ses attentes, le principal objectif de ce dispositif sera premièrement de pouvoir communiquer avec les secours à n’importe quel moment, et surtout n’importe où. De plus, il sera capable de détecter de nombreux cas de détresse de la part de l’usager afin de pouvoir lancer un appel d’urgence sans interaction avec l’usager, au cas où il serait inconscient, ou incapable de lancer un appel manuel.

Grâce aux accéléromètres, le dispositif sera à même de détecter un mouvement brutal du randonneur, ce qui pourrait s’apparenter à une chute. Ils pourront également détecter une position anormale, ou une immobilité prolongée, ce qui déclencherait le dispositif d’urgence automatiquement.

Grâce à des tests réalisés au préalable, le boîtier pourra détecter correctement les chûtes de simples mouvements, afin de ne pas lancer l’appel sans raison valable.

Avant de lancer une alerte automatique, le dispositif émettra un signal auditif et visuel à l’utilisateur quelques secondes auparavant, afin de le prévenir l'émission du signal d’urgence, et de lui proposer de le désactiver sur simple pression d’un bouton, afin d’éviter les communications inutiles.

Également, le randonneur sera à même d'émettre volontairement un appel d’urgence à l’aide du bouton, ce qui permet à tout moment d’appeler de l’aide sans effort. Cela peut permettre également à appeler les secours pour une personne en danger qui ne porterait pas le dispositif.

L’appel au secours se représente par un envoi de coordonnées GPS aux secours, via une communication radio LoRa vers des bornes relais placées au préalables en montagne. Cette communication irait de relai de relai jusqu’au centre de sécurité, d’où le message serait transmis aux secours.

De plus, une application mobile verra le jour afin de connecter tous les utilisateurs du module de sécurité, de les visualiser sur une map, et de partager leurs données. En effet, à chaque incident, l’application mettra à jour la position et de la date de l’accident, afin de permettre aux prochains utilisateurs d’être prévenus. Ils pourraient, s'ils sont à proximité, d'assister la personne en détresse en attendant l'arrivée des secours. Bien évidemment, cette application ne sera accessible uniquement si le smartphone de l'utilisateur est relié à une connexion 4G ou Wi-Fi.

Cette prévention pourrait les sensibiliser aux risques de la montagne, leur permettre d’éviter le secteur mais aussi d’aider les personnes en danger si la distance le permet.

= Exigences =
== Fonctionnelles ==

*Batterie garantie fonctionnelle 1 semaine
*Rechargement possible via le panneau solaire portable
*Dispositif pouvant être allumé et éteint par l'utilisateur
*Alarme s’enclenche automatiquement dès qu'elle est considérée nécessaire, signal sonore
*Utilisateur a la possibilité d’activer/désactiver l’alarme quand il le souhaite
*Lorsque l’alarme est active, l’appareil ne peut s’éteindre
*...

== Non-Fonctionnelles ==

*Résistance : aux chocs, impacts, waterproof (utilisé en permanence en plein air)
*Disponibilité : Appareil de secours -> Doit être au plus possible performant
*Performance : Minimiser les pertes réseaux
*Accessible : Utilisateur pas forcément familier avec des appareils électroniques (facile d’utilisation)
*Fiabilité : Précision du GPS (rayon de 10m), données non-éronnées
*Coût : Le plus faible possible pour vendre le moins cher possible
*Efficacité : Réduire la consommation, utiliser le moins possible les ressources

= Composants =
== LoRaONE ==
Pour le coeur du projet, après avoir cherché et comparés plusieurs modules LoRa, GPS ou encore accéléromètres, nous avons finalement opté pour le projet LoRaONE.

LoRaONE est un projet de SODAQ regroupant plusieurs composants dans une seule et même carte, de taille réduite.

https://www.kickstarter.com/projects/sodaq/loraone-the-lora-iot-development-board

“The one IoT development board to rule them all” --SODAQ

Cette carte regroupe plusieurs capteurs afin de respecter aux mieux nos exigences :

Un émetteur/récepteur LoRa afin de pouvoir communiquer au mieux avec les antennes relai à longue distance

Un module + antenne GPS de bonne précision (< 10m) pour connaître en tout temps notre position, et ainsi faciliter l’arrivée des secours, ainsi que la recherche de l’individu en détresse

Un accéléromètre sur 3 axes afin de pouvoir détecter tout mouvement, vitesse ou rotation dans l’espace, ce qui permet la détection de chutes ou d’arrêt de mouvements

3 LED RGB afin de pouvoir signaler à l’utilisateur un manque de batterie, un signal d’urgence ou plus si nécessaire

Un bouton poussoir pour le signal d’alarme

Un connecteur de charge par panneau solaire, afin de faire durer chaque batterie le plus longtemps possible

Un connecteur micro-USB ainsi que des lignes pour se connecter à une base Arduino si besoin

[[File:LoRaOne.png||400px|Spécifications carte LoRaOne]]

De plus, grâce au starter pack, nous pouvons avoir accès à la base ONEBase qui nous permettrait d’étendre plus loin la facilité d’utilisation du produit :

[[File:LoRaOneBase.png||400px|Spécifications base LoRaOneBase]]

Comme nous pouvons le voir, cette base nous permettra de connecter la batterie ainsi que le panneau solaire qui sont fournis dans le pack.

Nous pourrons également connecter jusqu’à 4 modules supplémentaires.

La batterie fournie aura une capacité de 800 mAh, le panneau solaire fourni pouvant délivrer jusqu’à 500 mW de puissance.

Le total atteint une taille d’environ 10*5 cm, ce qui n’est pas excessif, ce qui le rend aisément portatif sur une jambe ou à la taille.

'''Coût : 115€'''

Ce module pourra également servir d’antenne relai, l'alimentation solaire devrait maintenir le dispositif chargé en permanence. Des tests seront effectués pour savoir si un panneau solaire plus puissant est requis.

== Boîtier ==

Le boîtier sécurisé devant respecter plusieurs exigences, nous pouvons le construire en plastique résistant, ce qui le rendrait léger tout en respectant une rigidité suffisante. Les antennes pourront être placées le long du boîtier, à l’intérieur si la connexion est suffisante, ou à l’extérieur. Dans ce dernier cas les trous réalisés sur le boîtier afin de laisser passer les câbles seront colmatés afin de garantir une étanchéité.

[[File:SchemaBoitier.png||100px|Schéma boitier d'alarme]]

== Balises ==

Afin de remonter les informations transmises par les boitiers, des balises seront mises en places sur la zone à couvrir, leur nombre et leur positions dépendra du terrain (obstacles, dénivelés). On distinguera deux types de balises. Tout d’abord, les balises racines qui permettront une communication GSM afin de faire remonter les données vers le serveur. Viennent ensuite les balises standard qui se contenteront de faire remonter vers leur balise racine associée. L’architecture de liaison des balises est détaillée dans une prochaine partie.

Chaque balise est composée d’une barre de fer pouvant être plantée dans le sol, d’un système de lest afin d’immobiliser la balise, d’un paratonnerre, d’un panneau solaire ainsi que d’un LoraOne et d’une batterie. Les balises racines seront équippée en plus d’un dispositif de communication GSM (téléphone portable, émetteur GSM).

[[File:SchemaBalise.png||150px|Schéma balises d'alarme]]

== Application mobile ==
Une application mobile est téléchargeable par les utilisateurs. Ils peuvent voir les autres utilisateurs présents dans leur zone. Lorsqu’un utilisateur est en position de danger, une notification apparaît si les utilisateurs sont proches de la situation de danger.

Cette application n’est pas directement reliée au dispositif. Elle ne fonctionne qu’avec la connexion du mobile, et est destinée à être un niveau de sécurité supérieur. Un randonneur proche d’une zone de danger pourrait arriver sur place plus rapidement que les secours.

= Communication =

Pour un envoi de position + numéro d’identification (X chiffres) :

*Temps de communication : < 2 s
*Communication régulière, intervalle de 15 minutes

On peut donc au maximum avoir 15 * 60 / 2 = 450 individus pouvant communiquer avec la même antenne relai, donc dans le même cercle d’environ 15 km de diamètre.

On communique donc au minimum 2 secondes sur 15 minutes, donc 1/450 << 1%, le temps de communication est respecté.

En cas de problème, nous pouvons envoyer jusqu’à 9x plus avec la borne sans dépasser le temps de communication autorisé (1%). Donc 1 envoi d’appel d’urgence toutes les 2 minutes environ.

La balise racine peut être directement connectée au serveur, dans ce cas, il n’y a pas de communication GSM nécessaire et pas de Gateway. Si la racine n’est pas directement connectée au serveur, elle devra au minimum garantir une communication GSM (ce qu’elle peut faire, il n’y a pas de Gateway nécessaire) pour remonter l’information vers le serveur, et donc la base de données.

GSM : Si Racine connectée à Serveur -> No GSM + Gateway
Else : GSM + Gateway : LoRa Racine connectée ordi (RaspberryPI) + ordi connecté GSM

= Stabilisation et gestion d’erreurs =

== Choix du routage ==

Notre réseau n'est pas un réseau traditionnel. Les seules communications existantes sont soit une remontée d'information vers la racine soit une innondation d'alerte vers les clients. Pour celà nous avons donc décidé d'utiliser un algorithme de routage simplifié basé uniquement sur un arbre en largeur des balises. Nous rajoutons en option la possibilité de créer plusieurs racines et donc plusieurs arbres dont les racines communiquent par gsm. Nous nous basons sur des papiers de recherches afin de déterminer quel algorithme auto-stabilisant est le plus adapté au système LoRa (Tel que le papier "A self-stabilizing algorithm for constructing breadth-first trees" par Shing-Tsaan Huang, Nian-Shing Chen).

== Stabilisation ==

Afin de gérer la communication de chaque message vers le serveur, nous allons prendre un noeud (balise LoRa) dit “racine” connecté directement au serveur, nous ne nous occuperons pas de la communication au serveur dans cet onglet. Chaque message reçu de la part d’un noeud du système doit être relayé jusqu’à la racine du système afin de communiquer avec les secours (ou serveur simplement).

Pour cela, il faudra assurer que chaque balise LoRa soit connecté au réseau, afin d’avoir au départ un graphe de communication connexe. Par dessus ce graphe, nous allons utiliser un processus silencieux auto-stabilisant qui construira un arbre de parcours en largeur, avec pour racine le noeud “racine” décidé ci-dessus.

Au lancement du système, il faut prévoir un léger temps de stabilisation, qui dépendrait de l’algorithme et de la taille du graphe (nombre de balises). Cependant, après cela, l’algorithme assure un arbre en profondeur minimal qui nous permettrai de communiquer avec la racine le plus rapidement possible, et donc une qualité de service maximale.

== Gestion d’erreurs ==

Dans un réseau comme celui-ci, plusieurs types d’erreurs peuvent se produire :
Délai de communication trop important vers une balise
“Crash” d’une balise de communication
Surpopulation d’une balise ou congestion de messages

Afin de palier au premier type d’incident rencontré, il faut nécessairement qu’à chaque emplacement dans la zone couverte, l’utilisateur soit à même de communiquer avec au minimum 2 balises différentes. Ainsi, dans le cas d’une communication trop longue sur une balise, l’autre aurait de grandes chances de délivrer le message plus rapidement.

Au niveau de la défaillance d’une balise, l’algorithme d’arbre en profondeur nous fournit déjà une solution intégrée grâce à son auto-stabilisation. Dans le cas de déconnexion d’une balise, l’algorithme mettrai à jour automatiquement l’arbre de communication, et n’importe quel message d’alerte émis serait délivré dans un délai raisonnable.

Pour le troisième cas d’erreur, il n’y aurait pas de solution réelle, si ce n’est de limiter le nombre de communications données, en ne prenant plus en compte les “ping” de chaque utilisateur mais seulement les messages d’alertes, ce qui permettrai une bien plus grande gestion de la congestion à un endroit donné. Également, une balise en dessous d’un lien congestionné pourrait communiquer avec ses autres voisins (non-fils dans l’arbre) afin de libérer de l’espace dans le lien avec son père dans l’arbre. Également, le système ne pourra accepter que jusqu’à 1000 utilisateurs par noeud, et également 4000 utilisateurs par cluster (dans le cas d’un réseau avec plusieurs clusters donc plusieurs racines cette limite augmente).

Plusieurs types de paquets circulent sur le réseau de balise:
Les pings, messages envoyés spontanéments à intervalle régulier par les utilisateur contenant l’id ainsi que les deux coordonées gps (27 bits chacun)
Les incidents, identique à un ping mais à priorité haute.
Les alertes, messages brodcastés par le serveur afin d’envoyer un message en chaine de caractères courts et compressés.

=Coûts matériels=

Que ce soit pour le dispositif utilisateur ou la balise (racine ou non), le LoRaOne correspond pour permettre les actions recherchées. Afin de réaliser un prototype pertinent, 6 kits LoRaOne sont requis. Ces kits sont accessibles sur le site de Sodaq au prix de 115€ chacun (prix variable).
Disponible [https://shop.sodaq.com/en/one-eu-rn2483-v2.html ici], voir avant dernier bundle : starter "ONE EU starter" actuellement à 112,10€.

Un [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer buzzer] est à ajouter au dispositif utilisateur afin de lui délivrer un signal sonore.

Un shield GSM est requis pour que la balise racine communique avec l'extérieur. Sodaq en propose un designé pour fonctionner sur leurs produits mais est éctuellement en rupture de stock. Un shield GSM arduino convient tout autant et peut être trouvé sur le site arduino [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna ici].

Aucun boitier ne sera commandé car nous avons fait le choix de les manufacturer nous même au fablab. Le besoin d'étanchéité n'est pas primordial pour notre prototype, bien que nous tenterons de l'assurer.

{|class="récap commande"
|+ Récapitulatif
|-
|
!scope="col" style="width: 320px;"| Produit
!scope="col" style="width: 80px;"| Lien
!scope="col" style="width: 80px;"| Quantité
!scope="col" style="width: 80px;"| Prix Unitaire
|-

!scope="row"| 1
| LoRaOne EU Starter
| [https://shop.sodaq.com/en/one-eu-rn2483-v2.html Achat]
| 6
| 115€
|-

!scope="row"| 2
| Buzzer
| [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer Achat]
| 3
| 5.49€
|-

!scope="row"| 3
| Shield GSM
| [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna Achat]
| 1
| 65€
|-

|}

=Développement=

Nous utiliserons les librairies standards Arduino ainsi que celle de SODAQ/Arduino pour le LoRa.

L'IDE Arduino sera utilisé, plus pratique pour l'utilisation de Git (comparé à Mbed).

= Mise sur le marché =

Ce dispositif a pour but d’être utilisé en montagne, lors de randonnée. Il n’est pas destiné à un usage quotidien, c’est pourquoi nous considérons qu’il est plus judicieux de louer les dispositifs plutôt que de les vendre, même si l’achat n’est pas à omettre de notre stratégie.

Le dispositif peut être commandé en ligne, puis retourné par la poste après usage. Le client louerait le dispositif pour une certaine durée avec un possible nombre supplémentaire de batterie. Les tarifs varient en fonction de la durée et du nombre de batteries louées. Des offres de groupes pourraient être applicables. A long terme, des boutiques pourraient être disséminées dans des grandes villes proches des zones montagneuses, zones à randonnées (Grenoble, Annecy, etc.).

L’application est téléchargeable gratuitement par quiconque, mais utilisable seulement par les clients. Un code d’accès sera envoyé avec le dispositif expirant après la fin de la location.

Il faudra tenir compte de la bande passante du LoRa, variante en fonction des continents.

=Planning=

Sprint 1 : 29/01 --> 09/02 : Création du prototype logiciel #1
*Prise en main du matériel
*Premiers tests de transmissions LoRa
*Création du protocole d'architecture des balises
*Application sur les cartes et tests
*Tests de performances des cartes (durabilité, chargement, batterie)
*Tests de maintenabilité de l'algorithme (déconnexions, latences)

Sprint 2 : 12/02 --> 23/02 : Prototype logiciel #2 et prototype matériel
*Création du programme embarqué (utilisateur)
*Communication avec la racine et le serveur
*Création des maquettes boîtier et balise
*Construction des maquettes
*Finalisation du premier prototype

Sprint 3 : 26/02 --> 09/03 : Fonctionnalités supplémentaires
*Ajout de la communication entre le LoRa et le GSM sur la balise racine
*Création application mobile utilisateur
*Tests sur l'application
*Tests sur la transmission totale depuis l'utilisateur vers le serveur via le GSM
*Finalisation du projet

Sprint 4 : 12/03 --> 16/03 : Fin du projet
*Création de la documentation finale (à partir de la documentation réalisée en continu)
*Pause café
*Temps supplémentaire en cas de problèmes importants
*Préparation de la soutenance

R'Montagne

2018-02-12T10:08:43Z

Hugo.Amodru-Favin: /* Journal */

=Présentation du projet=

==Équipe==
{|class="wikitable"
|-
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Rôle
|-
| Hugo Amodru-Favin
| Chef de Projet
|-
| Antoine Delise
| Lead Developer
|-
| Gwenaël Moreau
| Kanban Master
|-

|}

==Tâches==

Répartition générale des tâches
{|class="wikitable"
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Tâche
|-
| Hugo Amodru-Favin
| Application Ionic
|-
| Antoine Delise
| Développement Arduino
|-
| Gwenaël Moreau
| BDD - API
|-

|}

Détail des tâches : [https://waffle.io/delisea/R-Montagne Lien Waffle.io]

==Journal==

{|class="wikitable"
|+
|-
!scope="col"| Date
!scope="col"| Hugo AMODRU-FAVIN
!scope="col"| Antoine DELISE
!scope="col"| Gwenaël MOREAU
|-

| colspan="5" style="text-align: center; background-color:#1c531c; width:225px;"| SPRINT 1
|-

|-
| rowspan="1" | Lundi 29/01/18
| style="width: 225px;" |
* efoed
| style="width: 225px;" |
* sidfjeso
| style="width: 225px;" |
* zdokz
|-
|}

==Randonnée et risques==

Ouvert à tous, la randonnée est un sport et un loisir qui prend de plus en plus d’ampleur de nos jours. Ne nécessitant pas de grands prérequis, des milliers de personnes se lancent en montagne chaque jour, malheureusement parfois sans connaître toutes les mesures de sécurité associées.

En effet, de janvier à juin 2016, en randonnée et en alpinisme, l’Association Nationale pour l’Étude de la Neige et des Avalanches (ANENA) a comptabilisé 21 accidents notables, dont 8 accidents mortels, impliquant 15 décès.

Aujourd’hui, les mesures de sécurités préconisent que chaque groupe de randonneur se doivent de se munir d’un téléphone portable afin d’appeler les secours en cas de problème. Malheureusement, la communication mobile dépendant de la couverture réseau, peu présente en montagne, l’impossibilité de joindre les secours reste un problème.

==Solutions existantes==

La solution la plus répandue, est celle du téléphone à connexion satellite. Ayant une communication vers les satellites, cela permet une couverture réseau beaucoup plus répandue dans les montagnes, partout dans le monde (ou presque). Cependant, les téléphones portables satellitaires coûtent chers, et ne sont pas forcément abordables par la plupart des personnes, surtout celles ne sortant qu’occasionnellement.

[https://fall-alarm.net/ Fall Alarm] est un système de détection de chute sur chantier utilisant les mêmes technologies dont nous avons besoin pour notre projet.

==Quelles zones géographiques ?==

Toutes les zones montagneuses peuvent présenter des zones blanches, démunies de connexion quelconque autre que les connexions satellitaires. Certaines chaînes de montagne comme la Cordillaire des Andes ne présentent aucune connexion possible quelconque.

Dans le cadre de notre projet, nous fonctionnerons essentiellement dans la localisation grenobloise avec l'objectif que notre solution soit applicable partout dans le monde. Une contrainte intervient tout de même étant donnée que la fréquence d'utilisation du LoRa en Europe est de 868MHz, 915MHz en Amérique et 433MHz en Asie.

= Fonctionnalités =

Afin de remplir au mieux ses attentes, le principal objectif de ce dispositif sera premièrement de pouvoir communiquer avec les secours à n’importe quel moment, et surtout n’importe où. De plus, il sera capable de détecter de nombreux cas de détresse de la part de l’usager afin de pouvoir lancer un appel d’urgence sans interaction avec l’usager, au cas où il serait inconscient, ou incapable de lancer un appel manuel.

Grâce aux accéléromètres, le dispositif sera à même de détecter un mouvement brutal du randonneur, ce qui pourrait s’apparenter à une chute. Ils pourront également détecter une position anormale, ou une immobilité prolongée, ce qui déclencherait le dispositif d’urgence automatiquement.

Grâce à des tests réalisés au préalable, le boîtier pourra détecter correctement les chûtes de simples mouvements, afin de ne pas lancer l’appel sans raison valable.

Avant de lancer une alerte automatique, le dispositif émettra un signal auditif et visuel à l’utilisateur quelques secondes auparavant, afin de le prévenir l'émission du signal d’urgence, et de lui proposer de le désactiver sur simple pression d’un bouton, afin d’éviter les communications inutiles.

Également, le randonneur sera à même d'émettre volontairement un appel d’urgence à l’aide du bouton, ce qui permet à tout moment d’appeler de l’aide sans effort. Cela peut permettre également à appeler les secours pour une personne en danger qui ne porterait pas le dispositif.

L’appel au secours se représente par un envoi de coordonnées GPS aux secours, via une communication radio LoRa vers des bornes relais placées au préalables en montagne. Cette communication irait de relai de relai jusqu’au centre de sécurité, d’où le message serait transmis aux secours.

De plus, une application mobile verra le jour afin de connecter tous les utilisateurs du module de sécurité, de les visualiser sur une map, et de partager leurs données. En effet, à chaque incident, l’application mettra à jour la position et de la date de l’accident, afin de permettre aux prochains utilisateurs d’être prévenus. Ils pourraient, s'ils sont à proximité, d'assister la personne en détresse en attendant l'arrivée des secours. Bien évidemment, cette application ne sera accessible uniquement si le smartphone de l'utilisateur est relié à une connexion 4G ou Wi-Fi.

Cette prévention pourrait les sensibiliser aux risques de la montagne, leur permettre d’éviter le secteur mais aussi d’aider les personnes en danger si la distance le permet.

= Exigences =
== Fonctionnelles ==

*Batterie garantie fonctionnelle 1 semaine
*Rechargement possible via le panneau solaire portable
*Dispositif pouvant être allumé et éteint par l'utilisateur
*Alarme s’enclenche automatiquement dès qu'elle est considérée nécessaire, signal sonore
*Utilisateur a la possibilité d’activer/désactiver l’alarme quand il le souhaite
*Lorsque l’alarme est active, l’appareil ne peut s’éteindre
*...

== Non-Fonctionnelles ==

*Résistance : aux chocs, impacts, waterproof (utilisé en permanence en plein air)
*Disponibilité : Appareil de secours -> Doit être au plus possible performant
*Performance : Minimiser les pertes réseaux
*Accessible : Utilisateur pas forcément familier avec des appareils électroniques (facile d’utilisation)
*Fiabilité : Précision du GPS (rayon de 10m), données non-éronnées
*Coût : Le plus faible possible pour vendre le moins cher possible
*Efficacité : Réduire la consommation, utiliser le moins possible les ressources

= Composants =
== LoRaONE ==
Pour le coeur du projet, après avoir cherché et comparés plusieurs modules LoRa, GPS ou encore accéléromètres, nous avons finalement opté pour le projet LoRaONE.

LoRaONE est un projet de SODAQ regroupant plusieurs composants dans une seule et même carte, de taille réduite.

https://www.kickstarter.com/projects/sodaq/loraone-the-lora-iot-development-board

“The one IoT development board to rule them all” --SODAQ

Cette carte regroupe plusieurs capteurs afin de respecter aux mieux nos exigences :

Un émetteur/récepteur LoRa afin de pouvoir communiquer au mieux avec les antennes relai à longue distance

Un module + antenne GPS de bonne précision (< 10m) pour connaître en tout temps notre position, et ainsi faciliter l’arrivée des secours, ainsi que la recherche de l’individu en détresse

Un accéléromètre sur 3 axes afin de pouvoir détecter tout mouvement, vitesse ou rotation dans l’espace, ce qui permet la détection de chutes ou d’arrêt de mouvements

3 LED RGB afin de pouvoir signaler à l’utilisateur un manque de batterie, un signal d’urgence ou plus si nécessaire

Un bouton poussoir pour le signal d’alarme

Un connecteur de charge par panneau solaire, afin de faire durer chaque batterie le plus longtemps possible

Un connecteur micro-USB ainsi que des lignes pour se connecter à une base Arduino si besoin

[[File:LoRaOne.png||400px|Spécifications carte LoRaOne]]

De plus, grâce au starter pack, nous pouvons avoir accès à la base ONEBase qui nous permettrait d’étendre plus loin la facilité d’utilisation du produit :

[[File:LoRaOneBase.png||400px|Spécifications base LoRaOneBase]]

Comme nous pouvons le voir, cette base nous permettra de connecter la batterie ainsi que le panneau solaire qui sont fournis dans le pack.

Nous pourrons également connecter jusqu’à 4 modules supplémentaires.

La batterie fournie aura une capacité de 800 mAh, le panneau solaire fourni pouvant délivrer jusqu’à 500 mW de puissance.

Le total atteint une taille d’environ 10*5 cm, ce qui n’est pas excessif, ce qui le rend aisément portatif sur une jambe ou à la taille.

'''Coût : 115€'''

Ce module pourra également servir d’antenne relai, l'alimentation solaire devrait maintenir le dispositif chargé en permanence. Des tests seront effectués pour savoir si un panneau solaire plus puissant est requis.

== Boîtier ==

Le boîtier sécurisé devant respecter plusieurs exigences, nous pouvons le construire en plastique résistant, ce qui le rendrait léger tout en respectant une rigidité suffisante. Les antennes pourront être placées le long du boîtier, à l’intérieur si la connexion est suffisante, ou à l’extérieur. Dans ce dernier cas les trous réalisés sur le boîtier afin de laisser passer les câbles seront colmatés afin de garantir une étanchéité.

[[File:SchemaBoitier.png||100px|Schéma boitier d'alarme]]

== Balises ==

Afin de remonter les informations transmises par les boitiers, des balises seront mises en places sur la zone à couvrir, leur nombre et leur positions dépendra du terrain (obstacles, dénivelés). On distinguera deux types de balises. Tout d’abord, les balises racines qui permettront une communication GSM afin de faire remonter les données vers le serveur. Viennent ensuite les balises standard qui se contenteront de faire remonter vers leur balise racine associée. L’architecture de liaison des balises est détaillée dans une prochaine partie.

Chaque balise est composée d’une barre de fer pouvant être plantée dans le sol, d’un système de lest afin d’immobiliser la balise, d’un paratonnerre, d’un panneau solaire ainsi que d’un LoraOne et d’une batterie. Les balises racines seront équippée en plus d’un dispositif de communication GSM (téléphone portable, émetteur GSM).

[[File:SchemaBalise.png||150px|Schéma balises d'alarme]]

== Application mobile ==
Une application mobile est téléchargeable par les utilisateurs. Ils peuvent voir les autres utilisateurs présents dans leur zone. Lorsqu’un utilisateur est en position de danger, une notification apparaît si les utilisateurs sont proches de la situation de danger.

Cette application n’est pas directement reliée au dispositif. Elle ne fonctionne qu’avec la connexion du mobile, et est destinée à être un niveau de sécurité supérieur. Un randonneur proche d’une zone de danger pourrait arriver sur place plus rapidement que les secours.

= Communication =

Pour un envoi de position + numéro d’identification (X chiffres) :

*Temps de communication : < 2 s
*Communication régulière, intervalle de 15 minutes

On peut donc au maximum avoir 15 * 60 / 2 = 450 individus pouvant communiquer avec la même antenne relai, donc dans le même cercle d’environ 15 km de diamètre.

On communique donc au minimum 2 secondes sur 15 minutes, donc 1/450 << 1%, le temps de communication est respecté.

En cas de problème, nous pouvons envoyer jusqu’à 9x plus avec la borne sans dépasser le temps de communication autorisé (1%). Donc 1 envoi d’appel d’urgence toutes les 2 minutes environ.

La balise racine peut être directement connectée au serveur, dans ce cas, il n’y a pas de communication GSM nécessaire et pas de Gateway. Si la racine n’est pas directement connectée au serveur, elle devra au minimum garantir une communication GSM (ce qu’elle peut faire, il n’y a pas de Gateway nécessaire) pour remonter l’information vers le serveur, et donc la base de données.

GSM : Si Racine connectée à Serveur -> No GSM + Gateway
Else : GSM + Gateway : LoRa Racine connectée ordi (RaspberryPI) + ordi connecté GSM

= Stabilisation et gestion d’erreurs =

== Choix du routage ==

Notre réseau n'est pas un réseau traditionnel. Les seules communications existantes sont soit une remontée d'information vers la racine soit une innondation d'alerte vers les clients. Pour celà nous avons donc décidé d'utiliser un algorithme de routage simplifié basé uniquement sur un arbre en largeur des balises. Nous rajoutons en option la possibilité de créer plusieurs racines et donc plusieurs arbres dont les racines communiquent par gsm. Nous nous basons sur des papiers de recherches afin de déterminer quel algorithme auto-stabilisant est le plus adapté au système LoRa (Tel que le papier "A self-stabilizing algorithm for constructing breadth-first trees" par Shing-Tsaan Huang, Nian-Shing Chen).

== Stabilisation ==

Afin de gérer la communication de chaque message vers le serveur, nous allons prendre un noeud (balise LoRa) dit “racine” connecté directement au serveur, nous ne nous occuperons pas de la communication au serveur dans cet onglet. Chaque message reçu de la part d’un noeud du système doit être relayé jusqu’à la racine du système afin de communiquer avec les secours (ou serveur simplement).

Pour cela, il faudra assurer que chaque balise LoRa soit connecté au réseau, afin d’avoir au départ un graphe de communication connexe. Par dessus ce graphe, nous allons utiliser un processus silencieux auto-stabilisant qui construira un arbre de parcours en largeur, avec pour racine le noeud “racine” décidé ci-dessus.

Au lancement du système, il faut prévoir un léger temps de stabilisation, qui dépendrait de l’algorithme et de la taille du graphe (nombre de balises). Cependant, après cela, l’algorithme assure un arbre en profondeur minimal qui nous permettrai de communiquer avec la racine le plus rapidement possible, et donc une qualité de service maximale.

== Gestion d’erreurs ==

Dans un réseau comme celui-ci, plusieurs types d’erreurs peuvent se produire :
Délai de communication trop important vers une balise
“Crash” d’une balise de communication
Surpopulation d’une balise ou congestion de messages

Afin de palier au premier type d’incident rencontré, il faut nécessairement qu’à chaque emplacement dans la zone couverte, l’utilisateur soit à même de communiquer avec au minimum 2 balises différentes. Ainsi, dans le cas d’une communication trop longue sur une balise, l’autre aurait de grandes chances de délivrer le message plus rapidement.

Au niveau de la défaillance d’une balise, l’algorithme d’arbre en profondeur nous fournit déjà une solution intégrée grâce à son auto-stabilisation. Dans le cas de déconnexion d’une balise, l’algorithme mettrai à jour automatiquement l’arbre de communication, et n’importe quel message d’alerte émis serait délivré dans un délai raisonnable.

Pour le troisième cas d’erreur, il n’y aurait pas de solution réelle, si ce n’est de limiter le nombre de communications données, en ne prenant plus en compte les “ping” de chaque utilisateur mais seulement les messages d’alertes, ce qui permettrai une bien plus grande gestion de la congestion à un endroit donné. Également, une balise en dessous d’un lien congestionné pourrait communiquer avec ses autres voisins (non-fils dans l’arbre) afin de libérer de l’espace dans le lien avec son père dans l’arbre. Également, le système ne pourra accepter que jusqu’à 1000 utilisateurs par noeud, et également 4000 utilisateurs par cluster (dans le cas d’un réseau avec plusieurs clusters donc plusieurs racines cette limite augmente).

Plusieurs types de paquets circulent sur le réseau de balise:
Les pings, messages envoyés spontanéments à intervalle régulier par les utilisateur contenant l’id ainsi que les deux coordonées gps (27 bits chacun)
Les incidents, identique à un ping mais à priorité haute.
Les alertes, messages brodcastés par le serveur afin d’envoyer un message en chaine de caractères courts et compressés.

=Coûts matériels=

Que ce soit pour le dispositif utilisateur ou la balise (racine ou non), le LoRaOne correspond pour permettre les actions recherchées. Afin de réaliser un prototype pertinent, 6 kits LoRaOne sont requis. Ces kits sont accessibles sur le site de Sodaq au prix de 115€ chacun (prix variable).
Disponible [https://shop.sodaq.com/en/one-eu-rn2483-v2.html ici], voir avant dernier bundle : starter "ONE EU starter" actuellement à 112,10€.

Un [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer buzzer] est à ajouter au dispositif utilisateur afin de lui délivrer un signal sonore.

Un shield GSM est requis pour que la balise racine communique avec l'extérieur. Sodaq en propose un designé pour fonctionner sur leurs produits mais est éctuellement en rupture de stock. Un shield GSM arduino convient tout autant et peut être trouvé sur le site arduino [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna ici].

Aucun boitier ne sera commandé car nous avons fait le choix de les manufacturer nous même au fablab. Le besoin d'étanchéité n'est pas primordial pour notre prototype, bien que nous tenterons de l'assurer.

{|class="récap commande"
|+ Récapitulatif
|-
|
!scope="col" style="width: 320px;"| Produit
!scope="col" style="width: 80px;"| Lien
!scope="col" style="width: 80px;"| Quantité
!scope="col" style="width: 80px;"| Prix Unitaire
|-

!scope="row"| 1
| LoRaOne EU Starter
| [https://shop.sodaq.com/en/one-eu-rn2483-v2.html Achat]
| 6
| 115€
|-

!scope="row"| 2
| Buzzer
| [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer Achat]
| 3
| 5.49€
|-

!scope="row"| 3
| Shield GSM
| [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna Achat]
| 1
| 65€
|-

|}

=Développement=

Nous utiliserons les librairies standards Arduino ainsi que celle de SODAQ/Arduino pour le LoRa.

L'IDE Arduino sera utilisé, plus pratique pour l'utilisation de Git (comparé à Mbed).

= Mise sur le marché =

Ce dispositif a pour but d’être utilisé en montagne, lors de randonnée. Il n’est pas destiné à un usage quotidien, c’est pourquoi nous considérons qu’il est plus judicieux de louer les dispositifs plutôt que de les vendre, même si l’achat n’est pas à omettre de notre stratégie.

Le dispositif peut être commandé en ligne, puis retourné par la poste après usage. Le client louerait le dispositif pour une certaine durée avec un possible nombre supplémentaire de batterie. Les tarifs varient en fonction de la durée et du nombre de batteries louées. Des offres de groupes pourraient être applicables. A long terme, des boutiques pourraient être disséminées dans des grandes villes proches des zones montagneuses, zones à randonnées (Grenoble, Annecy, etc.).

L’application est téléchargeable gratuitement par quiconque, mais utilisable seulement par les clients. Un code d’accès sera envoyé avec le dispositif expirant après la fin de la location.

Il faudra tenir compte de la bande passante du LoRa, variante en fonction des continents.

=Planning=

Sprint 1 : 29/01 --> 09/02 : Création du prototype logiciel #1
*Prise en main du matériel
*Premiers tests de transmissions LoRa
*Création du protocole d'architecture des balises
*Application sur les cartes et tests
*Tests de performances des cartes (durabilité, chargement, batterie)
*Tests de maintenabilité de l'algorithme (déconnexions, latences)

Sprint 2 : 12/02 --> 23/02 : Prototype logiciel #2 et prototype matériel
*Création du programme embarqué (utilisateur)
*Communication avec la racine et le serveur
*Création des maquettes boîtier et balise
*Construction des maquettes
*Finalisation du premier prototype

Sprint 3 : 26/02 --> 09/03 : Fonctionnalités supplémentaires
*Ajout de la communication entre le LoRa et le GSM sur la balise racine
*Création application mobile utilisateur
*Tests sur l'application
*Tests sur la transmission totale depuis l'utilisateur vers le serveur via le GSM
*Finalisation du projet

Sprint 4 : 12/03 --> 16/03 : Fin du projet
*Création de la documentation finale (à partir de la documentation réalisée en continu)
*Pause café
*Temps supplémentaire en cas de problèmes importants
*Préparation de la soutenance

R'Montagne

2018-02-12T10:08:29Z

Hugo.Amodru-Favin: /* Journal */

=Présentation du projet=

==Équipe==
{|class="wikitable"
|-
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Rôle
|-
| Hugo Amodru-Favin
| Chef de Projet
|-
| Antoine Delise
| Lead Developer
|-
| Gwenaël Moreau
| Kanban Master
|-

|}

==Tâches==

Répartition générale des tâches
{|class="wikitable"
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Tâche
|-
| Hugo Amodru-Favin
| Application Ionic
|-
| Antoine Delise
| Développement Arduino
|-
| Gwenaël Moreau
| BDD - API
|-

|}

Détail des tâches : [https://waffle.io/delisea/R-Montagne Lien Waffle.io]

==Journal==

{|class="wikitable"
|+
|-
|
!scope="col"| Date
!scope="col"| Hugo AMODRU-FAVIN
!scope="col"| Antoine DELISE
!scope="col"| Gwenaël MOREAU
|-

| colspan="5" style="text-align: center; background-color:#1c531c; width:225px;"| SPRINT 1
|-

|-
| rowspan="1" | Lundi 29/01/18
| style="width: 225px;" |
* efoed
| style="width: 225px;" |
* sidfjeso
| style="width: 225px;" |
* zdokz
|-
|}

==Randonnée et risques==

Ouvert à tous, la randonnée est un sport et un loisir qui prend de plus en plus d’ampleur de nos jours. Ne nécessitant pas de grands prérequis, des milliers de personnes se lancent en montagne chaque jour, malheureusement parfois sans connaître toutes les mesures de sécurité associées.

En effet, de janvier à juin 2016, en randonnée et en alpinisme, l’Association Nationale pour l’Étude de la Neige et des Avalanches (ANENA) a comptabilisé 21 accidents notables, dont 8 accidents mortels, impliquant 15 décès.

Aujourd’hui, les mesures de sécurités préconisent que chaque groupe de randonneur se doivent de se munir d’un téléphone portable afin d’appeler les secours en cas de problème. Malheureusement, la communication mobile dépendant de la couverture réseau, peu présente en montagne, l’impossibilité de joindre les secours reste un problème.

==Solutions existantes==

La solution la plus répandue, est celle du téléphone à connexion satellite. Ayant une communication vers les satellites, cela permet une couverture réseau beaucoup plus répandue dans les montagnes, partout dans le monde (ou presque). Cependant, les téléphones portables satellitaires coûtent chers, et ne sont pas forcément abordables par la plupart des personnes, surtout celles ne sortant qu’occasionnellement.

[https://fall-alarm.net/ Fall Alarm] est un système de détection de chute sur chantier utilisant les mêmes technologies dont nous avons besoin pour notre projet.

==Quelles zones géographiques ?==

Toutes les zones montagneuses peuvent présenter des zones blanches, démunies de connexion quelconque autre que les connexions satellitaires. Certaines chaînes de montagne comme la Cordillaire des Andes ne présentent aucune connexion possible quelconque.

Dans le cadre de notre projet, nous fonctionnerons essentiellement dans la localisation grenobloise avec l'objectif que notre solution soit applicable partout dans le monde. Une contrainte intervient tout de même étant donnée que la fréquence d'utilisation du LoRa en Europe est de 868MHz, 915MHz en Amérique et 433MHz en Asie.

= Fonctionnalités =

Afin de remplir au mieux ses attentes, le principal objectif de ce dispositif sera premièrement de pouvoir communiquer avec les secours à n’importe quel moment, et surtout n’importe où. De plus, il sera capable de détecter de nombreux cas de détresse de la part de l’usager afin de pouvoir lancer un appel d’urgence sans interaction avec l’usager, au cas où il serait inconscient, ou incapable de lancer un appel manuel.

Grâce aux accéléromètres, le dispositif sera à même de détecter un mouvement brutal du randonneur, ce qui pourrait s’apparenter à une chute. Ils pourront également détecter une position anormale, ou une immobilité prolongée, ce qui déclencherait le dispositif d’urgence automatiquement.

Grâce à des tests réalisés au préalable, le boîtier pourra détecter correctement les chûtes de simples mouvements, afin de ne pas lancer l’appel sans raison valable.

Avant de lancer une alerte automatique, le dispositif émettra un signal auditif et visuel à l’utilisateur quelques secondes auparavant, afin de le prévenir l'émission du signal d’urgence, et de lui proposer de le désactiver sur simple pression d’un bouton, afin d’éviter les communications inutiles.

Également, le randonneur sera à même d'émettre volontairement un appel d’urgence à l’aide du bouton, ce qui permet à tout moment d’appeler de l’aide sans effort. Cela peut permettre également à appeler les secours pour une personne en danger qui ne porterait pas le dispositif.

L’appel au secours se représente par un envoi de coordonnées GPS aux secours, via une communication radio LoRa vers des bornes relais placées au préalables en montagne. Cette communication irait de relai de relai jusqu’au centre de sécurité, d’où le message serait transmis aux secours.

De plus, une application mobile verra le jour afin de connecter tous les utilisateurs du module de sécurité, de les visualiser sur une map, et de partager leurs données. En effet, à chaque incident, l’application mettra à jour la position et de la date de l’accident, afin de permettre aux prochains utilisateurs d’être prévenus. Ils pourraient, s'ils sont à proximité, d'assister la personne en détresse en attendant l'arrivée des secours. Bien évidemment, cette application ne sera accessible uniquement si le smartphone de l'utilisateur est relié à une connexion 4G ou Wi-Fi.

Cette prévention pourrait les sensibiliser aux risques de la montagne, leur permettre d’éviter le secteur mais aussi d’aider les personnes en danger si la distance le permet.

= Exigences =
== Fonctionnelles ==

*Batterie garantie fonctionnelle 1 semaine
*Rechargement possible via le panneau solaire portable
*Dispositif pouvant être allumé et éteint par l'utilisateur
*Alarme s’enclenche automatiquement dès qu'elle est considérée nécessaire, signal sonore
*Utilisateur a la possibilité d’activer/désactiver l’alarme quand il le souhaite
*Lorsque l’alarme est active, l’appareil ne peut s’éteindre
*...

== Non-Fonctionnelles ==

*Résistance : aux chocs, impacts, waterproof (utilisé en permanence en plein air)
*Disponibilité : Appareil de secours -> Doit être au plus possible performant
*Performance : Minimiser les pertes réseaux
*Accessible : Utilisateur pas forcément familier avec des appareils électroniques (facile d’utilisation)
*Fiabilité : Précision du GPS (rayon de 10m), données non-éronnées
*Coût : Le plus faible possible pour vendre le moins cher possible
*Efficacité : Réduire la consommation, utiliser le moins possible les ressources

= Composants =
== LoRaONE ==
Pour le coeur du projet, après avoir cherché et comparés plusieurs modules LoRa, GPS ou encore accéléromètres, nous avons finalement opté pour le projet LoRaONE.

LoRaONE est un projet de SODAQ regroupant plusieurs composants dans une seule et même carte, de taille réduite.

https://www.kickstarter.com/projects/sodaq/loraone-the-lora-iot-development-board

“The one IoT development board to rule them all” --SODAQ

Cette carte regroupe plusieurs capteurs afin de respecter aux mieux nos exigences :

Un émetteur/récepteur LoRa afin de pouvoir communiquer au mieux avec les antennes relai à longue distance

Un module + antenne GPS de bonne précision (< 10m) pour connaître en tout temps notre position, et ainsi faciliter l’arrivée des secours, ainsi que la recherche de l’individu en détresse

Un accéléromètre sur 3 axes afin de pouvoir détecter tout mouvement, vitesse ou rotation dans l’espace, ce qui permet la détection de chutes ou d’arrêt de mouvements

3 LED RGB afin de pouvoir signaler à l’utilisateur un manque de batterie, un signal d’urgence ou plus si nécessaire

Un bouton poussoir pour le signal d’alarme

Un connecteur de charge par panneau solaire, afin de faire durer chaque batterie le plus longtemps possible

Un connecteur micro-USB ainsi que des lignes pour se connecter à une base Arduino si besoin

[[File:LoRaOne.png||400px|Spécifications carte LoRaOne]]

De plus, grâce au starter pack, nous pouvons avoir accès à la base ONEBase qui nous permettrait d’étendre plus loin la facilité d’utilisation du produit :

[[File:LoRaOneBase.png||400px|Spécifications base LoRaOneBase]]

Comme nous pouvons le voir, cette base nous permettra de connecter la batterie ainsi que le panneau solaire qui sont fournis dans le pack.

Nous pourrons également connecter jusqu’à 4 modules supplémentaires.

La batterie fournie aura une capacité de 800 mAh, le panneau solaire fourni pouvant délivrer jusqu’à 500 mW de puissance.

Le total atteint une taille d’environ 10*5 cm, ce qui n’est pas excessif, ce qui le rend aisément portatif sur une jambe ou à la taille.

'''Coût : 115€'''

Ce module pourra également servir d’antenne relai, l'alimentation solaire devrait maintenir le dispositif chargé en permanence. Des tests seront effectués pour savoir si un panneau solaire plus puissant est requis.

== Boîtier ==

Le boîtier sécurisé devant respecter plusieurs exigences, nous pouvons le construire en plastique résistant, ce qui le rendrait léger tout en respectant une rigidité suffisante. Les antennes pourront être placées le long du boîtier, à l’intérieur si la connexion est suffisante, ou à l’extérieur. Dans ce dernier cas les trous réalisés sur le boîtier afin de laisser passer les câbles seront colmatés afin de garantir une étanchéité.

[[File:SchemaBoitier.png||100px|Schéma boitier d'alarme]]

== Balises ==

Afin de remonter les informations transmises par les boitiers, des balises seront mises en places sur la zone à couvrir, leur nombre et leur positions dépendra du terrain (obstacles, dénivelés). On distinguera deux types de balises. Tout d’abord, les balises racines qui permettront une communication GSM afin de faire remonter les données vers le serveur. Viennent ensuite les balises standard qui se contenteront de faire remonter vers leur balise racine associée. L’architecture de liaison des balises est détaillée dans une prochaine partie.

Chaque balise est composée d’une barre de fer pouvant être plantée dans le sol, d’un système de lest afin d’immobiliser la balise, d’un paratonnerre, d’un panneau solaire ainsi que d’un LoraOne et d’une batterie. Les balises racines seront équippée en plus d’un dispositif de communication GSM (téléphone portable, émetteur GSM).

[[File:SchemaBalise.png||150px|Schéma balises d'alarme]]

== Application mobile ==
Une application mobile est téléchargeable par les utilisateurs. Ils peuvent voir les autres utilisateurs présents dans leur zone. Lorsqu’un utilisateur est en position de danger, une notification apparaît si les utilisateurs sont proches de la situation de danger.

Cette application n’est pas directement reliée au dispositif. Elle ne fonctionne qu’avec la connexion du mobile, et est destinée à être un niveau de sécurité supérieur. Un randonneur proche d’une zone de danger pourrait arriver sur place plus rapidement que les secours.

= Communication =

Pour un envoi de position + numéro d’identification (X chiffres) :

*Temps de communication : < 2 s
*Communication régulière, intervalle de 15 minutes

On peut donc au maximum avoir 15 * 60 / 2 = 450 individus pouvant communiquer avec la même antenne relai, donc dans le même cercle d’environ 15 km de diamètre.

On communique donc au minimum 2 secondes sur 15 minutes, donc 1/450 << 1%, le temps de communication est respecté.

En cas de problème, nous pouvons envoyer jusqu’à 9x plus avec la borne sans dépasser le temps de communication autorisé (1%). Donc 1 envoi d’appel d’urgence toutes les 2 minutes environ.

La balise racine peut être directement connectée au serveur, dans ce cas, il n’y a pas de communication GSM nécessaire et pas de Gateway. Si la racine n’est pas directement connectée au serveur, elle devra au minimum garantir une communication GSM (ce qu’elle peut faire, il n’y a pas de Gateway nécessaire) pour remonter l’information vers le serveur, et donc la base de données.

GSM : Si Racine connectée à Serveur -> No GSM + Gateway
Else : GSM + Gateway : LoRa Racine connectée ordi (RaspberryPI) + ordi connecté GSM

= Stabilisation et gestion d’erreurs =

== Choix du routage ==

Notre réseau n'est pas un réseau traditionnel. Les seules communications existantes sont soit une remontée d'information vers la racine soit une innondation d'alerte vers les clients. Pour celà nous avons donc décidé d'utiliser un algorithme de routage simplifié basé uniquement sur un arbre en largeur des balises. Nous rajoutons en option la possibilité de créer plusieurs racines et donc plusieurs arbres dont les racines communiquent par gsm. Nous nous basons sur des papiers de recherches afin de déterminer quel algorithme auto-stabilisant est le plus adapté au système LoRa (Tel que le papier "A self-stabilizing algorithm for constructing breadth-first trees" par Shing-Tsaan Huang, Nian-Shing Chen).

== Stabilisation ==

Afin de gérer la communication de chaque message vers le serveur, nous allons prendre un noeud (balise LoRa) dit “racine” connecté directement au serveur, nous ne nous occuperons pas de la communication au serveur dans cet onglet. Chaque message reçu de la part d’un noeud du système doit être relayé jusqu’à la racine du système afin de communiquer avec les secours (ou serveur simplement).

Pour cela, il faudra assurer que chaque balise LoRa soit connecté au réseau, afin d’avoir au départ un graphe de communication connexe. Par dessus ce graphe, nous allons utiliser un processus silencieux auto-stabilisant qui construira un arbre de parcours en largeur, avec pour racine le noeud “racine” décidé ci-dessus.

Au lancement du système, il faut prévoir un léger temps de stabilisation, qui dépendrait de l’algorithme et de la taille du graphe (nombre de balises). Cependant, après cela, l’algorithme assure un arbre en profondeur minimal qui nous permettrai de communiquer avec la racine le plus rapidement possible, et donc une qualité de service maximale.

== Gestion d’erreurs ==

Dans un réseau comme celui-ci, plusieurs types d’erreurs peuvent se produire :
Délai de communication trop important vers une balise
“Crash” d’une balise de communication
Surpopulation d’une balise ou congestion de messages

Afin de palier au premier type d’incident rencontré, il faut nécessairement qu’à chaque emplacement dans la zone couverte, l’utilisateur soit à même de communiquer avec au minimum 2 balises différentes. Ainsi, dans le cas d’une communication trop longue sur une balise, l’autre aurait de grandes chances de délivrer le message plus rapidement.

Au niveau de la défaillance d’une balise, l’algorithme d’arbre en profondeur nous fournit déjà une solution intégrée grâce à son auto-stabilisation. Dans le cas de déconnexion d’une balise, l’algorithme mettrai à jour automatiquement l’arbre de communication, et n’importe quel message d’alerte émis serait délivré dans un délai raisonnable.

Pour le troisième cas d’erreur, il n’y aurait pas de solution réelle, si ce n’est de limiter le nombre de communications données, en ne prenant plus en compte les “ping” de chaque utilisateur mais seulement les messages d’alertes, ce qui permettrai une bien plus grande gestion de la congestion à un endroit donné. Également, une balise en dessous d’un lien congestionné pourrait communiquer avec ses autres voisins (non-fils dans l’arbre) afin de libérer de l’espace dans le lien avec son père dans l’arbre. Également, le système ne pourra accepter que jusqu’à 1000 utilisateurs par noeud, et également 4000 utilisateurs par cluster (dans le cas d’un réseau avec plusieurs clusters donc plusieurs racines cette limite augmente).

Plusieurs types de paquets circulent sur le réseau de balise:
Les pings, messages envoyés spontanéments à intervalle régulier par les utilisateur contenant l’id ainsi que les deux coordonées gps (27 bits chacun)
Les incidents, identique à un ping mais à priorité haute.
Les alertes, messages brodcastés par le serveur afin d’envoyer un message en chaine de caractères courts et compressés.

=Coûts matériels=

Que ce soit pour le dispositif utilisateur ou la balise (racine ou non), le LoRaOne correspond pour permettre les actions recherchées. Afin de réaliser un prototype pertinent, 6 kits LoRaOne sont requis. Ces kits sont accessibles sur le site de Sodaq au prix de 115€ chacun (prix variable).
Disponible [https://shop.sodaq.com/en/one-eu-rn2483-v2.html ici], voir avant dernier bundle : starter "ONE EU starter" actuellement à 112,10€.

Un [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer buzzer] est à ajouter au dispositif utilisateur afin de lui délivrer un signal sonore.

Un shield GSM est requis pour que la balise racine communique avec l'extérieur. Sodaq en propose un designé pour fonctionner sur leurs produits mais est éctuellement en rupture de stock. Un shield GSM arduino convient tout autant et peut être trouvé sur le site arduino [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna ici].

Aucun boitier ne sera commandé car nous avons fait le choix de les manufacturer nous même au fablab. Le besoin d'étanchéité n'est pas primordial pour notre prototype, bien que nous tenterons de l'assurer.

{|class="récap commande"
|+ Récapitulatif
|-
|
!scope="col" style="width: 320px;"| Produit
!scope="col" style="width: 80px;"| Lien
!scope="col" style="width: 80px;"| Quantité
!scope="col" style="width: 80px;"| Prix Unitaire
|-

!scope="row"| 1
| LoRaOne EU Starter
| [https://shop.sodaq.com/en/one-eu-rn2483-v2.html Achat]
| 6
| 115€
|-

!scope="row"| 2
| Buzzer
| [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer Achat]
| 3
| 5.49€
|-

!scope="row"| 3
| Shield GSM
| [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna Achat]
| 1
| 65€
|-

|}

=Développement=

Nous utiliserons les librairies standards Arduino ainsi que celle de SODAQ/Arduino pour le LoRa.

L'IDE Arduino sera utilisé, plus pratique pour l'utilisation de Git (comparé à Mbed).

= Mise sur le marché =

Ce dispositif a pour but d’être utilisé en montagne, lors de randonnée. Il n’est pas destiné à un usage quotidien, c’est pourquoi nous considérons qu’il est plus judicieux de louer les dispositifs plutôt que de les vendre, même si l’achat n’est pas à omettre de notre stratégie.

Le dispositif peut être commandé en ligne, puis retourné par la poste après usage. Le client louerait le dispositif pour une certaine durée avec un possible nombre supplémentaire de batterie. Les tarifs varient en fonction de la durée et du nombre de batteries louées. Des offres de groupes pourraient être applicables. A long terme, des boutiques pourraient être disséminées dans des grandes villes proches des zones montagneuses, zones à randonnées (Grenoble, Annecy, etc.).

L’application est téléchargeable gratuitement par quiconque, mais utilisable seulement par les clients. Un code d’accès sera envoyé avec le dispositif expirant après la fin de la location.

Il faudra tenir compte de la bande passante du LoRa, variante en fonction des continents.

=Planning=

Sprint 1 : 29/01 --> 09/02 : Création du prototype logiciel #1
*Prise en main du matériel
*Premiers tests de transmissions LoRa
*Création du protocole d'architecture des balises
*Application sur les cartes et tests
*Tests de performances des cartes (durabilité, chargement, batterie)
*Tests de maintenabilité de l'algorithme (déconnexions, latences)

Sprint 2 : 12/02 --> 23/02 : Prototype logiciel #2 et prototype matériel
*Création du programme embarqué (utilisateur)
*Communication avec la racine et le serveur
*Création des maquettes boîtier et balise
*Construction des maquettes
*Finalisation du premier prototype

Sprint 3 : 26/02 --> 09/03 : Fonctionnalités supplémentaires
*Ajout de la communication entre le LoRa et le GSM sur la balise racine
*Création application mobile utilisateur
*Tests sur l'application
*Tests sur la transmission totale depuis l'utilisateur vers le serveur via le GSM
*Finalisation du projet

Sprint 4 : 12/03 --> 16/03 : Fin du projet
*Création de la documentation finale (à partir de la documentation réalisée en continu)
*Pause café
*Temps supplémentaire en cas de problèmes importants
*Préparation de la soutenance

R'Montagne

2018-02-12T10:07:49Z

Hugo.Amodru-Favin: /* Journal */

=Présentation du projet=

==Équipe==
{|class="wikitable"
|-
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Rôle
|-
| Hugo Amodru-Favin
| Chef de Projet
|-
| Antoine Delise
| Lead Developer
|-
| Gwenaël Moreau
| Kanban Master
|-

|}

==Tâches==

Répartition générale des tâches
{|class="wikitable"
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Tâche
|-
| Hugo Amodru-Favin
| Application Ionic
|-
| Antoine Delise
| Développement Arduino
|-
| Gwenaël Moreau
| BDD - API
|-

|}

Détail des tâches : [https://waffle.io/delisea/R-Montagne Lien Waffle.io]

==Journal==

{|class="wikitable"
|+
|-
|
!scope="col"| Date
!scope="col"| Hugo AMODRU-FAVIN
!scope="col"| Antoine DELISE
!scope="col"| Gwenaël MOREAU
|-

| colspan="5" style="text-align: center; background-color:#1c531c; width:225px;"| SPRINT 1
|-

|-
| rowspan="1" | Lundi 29/01/18
| rowspan="1" | Tâches
| style="width: 225px;" |
* efoed
| style="width: 225px;" |
* sidfjeso
| style="width: 225px;" |
* zdokz
|-
|}

==Randonnée et risques==

Ouvert à tous, la randonnée est un sport et un loisir qui prend de plus en plus d’ampleur de nos jours. Ne nécessitant pas de grands prérequis, des milliers de personnes se lancent en montagne chaque jour, malheureusement parfois sans connaître toutes les mesures de sécurité associées.

En effet, de janvier à juin 2016, en randonnée et en alpinisme, l’Association Nationale pour l’Étude de la Neige et des Avalanches (ANENA) a comptabilisé 21 accidents notables, dont 8 accidents mortels, impliquant 15 décès.

Aujourd’hui, les mesures de sécurités préconisent que chaque groupe de randonneur se doivent de se munir d’un téléphone portable afin d’appeler les secours en cas de problème. Malheureusement, la communication mobile dépendant de la couverture réseau, peu présente en montagne, l’impossibilité de joindre les secours reste un problème.

==Solutions existantes==

La solution la plus répandue, est celle du téléphone à connexion satellite. Ayant une communication vers les satellites, cela permet une couverture réseau beaucoup plus répandue dans les montagnes, partout dans le monde (ou presque). Cependant, les téléphones portables satellitaires coûtent chers, et ne sont pas forcément abordables par la plupart des personnes, surtout celles ne sortant qu’occasionnellement.

[https://fall-alarm.net/ Fall Alarm] est un système de détection de chute sur chantier utilisant les mêmes technologies dont nous avons besoin pour notre projet.

==Quelles zones géographiques ?==

Toutes les zones montagneuses peuvent présenter des zones blanches, démunies de connexion quelconque autre que les connexions satellitaires. Certaines chaînes de montagne comme la Cordillaire des Andes ne présentent aucune connexion possible quelconque.

Dans le cadre de notre projet, nous fonctionnerons essentiellement dans la localisation grenobloise avec l'objectif que notre solution soit applicable partout dans le monde. Une contrainte intervient tout de même étant donnée que la fréquence d'utilisation du LoRa en Europe est de 868MHz, 915MHz en Amérique et 433MHz en Asie.

= Fonctionnalités =

Afin de remplir au mieux ses attentes, le principal objectif de ce dispositif sera premièrement de pouvoir communiquer avec les secours à n’importe quel moment, et surtout n’importe où. De plus, il sera capable de détecter de nombreux cas de détresse de la part de l’usager afin de pouvoir lancer un appel d’urgence sans interaction avec l’usager, au cas où il serait inconscient, ou incapable de lancer un appel manuel.

Grâce aux accéléromètres, le dispositif sera à même de détecter un mouvement brutal du randonneur, ce qui pourrait s’apparenter à une chute. Ils pourront également détecter une position anormale, ou une immobilité prolongée, ce qui déclencherait le dispositif d’urgence automatiquement.

Grâce à des tests réalisés au préalable, le boîtier pourra détecter correctement les chûtes de simples mouvements, afin de ne pas lancer l’appel sans raison valable.

Avant de lancer une alerte automatique, le dispositif émettra un signal auditif et visuel à l’utilisateur quelques secondes auparavant, afin de le prévenir l'émission du signal d’urgence, et de lui proposer de le désactiver sur simple pression d’un bouton, afin d’éviter les communications inutiles.

Également, le randonneur sera à même d'émettre volontairement un appel d’urgence à l’aide du bouton, ce qui permet à tout moment d’appeler de l’aide sans effort. Cela peut permettre également à appeler les secours pour une personne en danger qui ne porterait pas le dispositif.

L’appel au secours se représente par un envoi de coordonnées GPS aux secours, via une communication radio LoRa vers des bornes relais placées au préalables en montagne. Cette communication irait de relai de relai jusqu’au centre de sécurité, d’où le message serait transmis aux secours.

De plus, une application mobile verra le jour afin de connecter tous les utilisateurs du module de sécurité, de les visualiser sur une map, et de partager leurs données. En effet, à chaque incident, l’application mettra à jour la position et de la date de l’accident, afin de permettre aux prochains utilisateurs d’être prévenus. Ils pourraient, s'ils sont à proximité, d'assister la personne en détresse en attendant l'arrivée des secours. Bien évidemment, cette application ne sera accessible uniquement si le smartphone de l'utilisateur est relié à une connexion 4G ou Wi-Fi.

Cette prévention pourrait les sensibiliser aux risques de la montagne, leur permettre d’éviter le secteur mais aussi d’aider les personnes en danger si la distance le permet.

= Exigences =
== Fonctionnelles ==

*Batterie garantie fonctionnelle 1 semaine
*Rechargement possible via le panneau solaire portable
*Dispositif pouvant être allumé et éteint par l'utilisateur
*Alarme s’enclenche automatiquement dès qu'elle est considérée nécessaire, signal sonore
*Utilisateur a la possibilité d’activer/désactiver l’alarme quand il le souhaite
*Lorsque l’alarme est active, l’appareil ne peut s’éteindre
*...

== Non-Fonctionnelles ==

*Résistance : aux chocs, impacts, waterproof (utilisé en permanence en plein air)
*Disponibilité : Appareil de secours -> Doit être au plus possible performant
*Performance : Minimiser les pertes réseaux
*Accessible : Utilisateur pas forcément familier avec des appareils électroniques (facile d’utilisation)
*Fiabilité : Précision du GPS (rayon de 10m), données non-éronnées
*Coût : Le plus faible possible pour vendre le moins cher possible
*Efficacité : Réduire la consommation, utiliser le moins possible les ressources

= Composants =
== LoRaONE ==
Pour le coeur du projet, après avoir cherché et comparés plusieurs modules LoRa, GPS ou encore accéléromètres, nous avons finalement opté pour le projet LoRaONE.

LoRaONE est un projet de SODAQ regroupant plusieurs composants dans une seule et même carte, de taille réduite.

https://www.kickstarter.com/projects/sodaq/loraone-the-lora-iot-development-board

“The one IoT development board to rule them all” --SODAQ

Cette carte regroupe plusieurs capteurs afin de respecter aux mieux nos exigences :

Un émetteur/récepteur LoRa afin de pouvoir communiquer au mieux avec les antennes relai à longue distance

Un module + antenne GPS de bonne précision (< 10m) pour connaître en tout temps notre position, et ainsi faciliter l’arrivée des secours, ainsi que la recherche de l’individu en détresse

Un accéléromètre sur 3 axes afin de pouvoir détecter tout mouvement, vitesse ou rotation dans l’espace, ce qui permet la détection de chutes ou d’arrêt de mouvements

3 LED RGB afin de pouvoir signaler à l’utilisateur un manque de batterie, un signal d’urgence ou plus si nécessaire

Un bouton poussoir pour le signal d’alarme

Un connecteur de charge par panneau solaire, afin de faire durer chaque batterie le plus longtemps possible

Un connecteur micro-USB ainsi que des lignes pour se connecter à une base Arduino si besoin

[[File:LoRaOne.png||400px|Spécifications carte LoRaOne]]

De plus, grâce au starter pack, nous pouvons avoir accès à la base ONEBase qui nous permettrait d’étendre plus loin la facilité d’utilisation du produit :

[[File:LoRaOneBase.png||400px|Spécifications base LoRaOneBase]]

Comme nous pouvons le voir, cette base nous permettra de connecter la batterie ainsi que le panneau solaire qui sont fournis dans le pack.

Nous pourrons également connecter jusqu’à 4 modules supplémentaires.

La batterie fournie aura une capacité de 800 mAh, le panneau solaire fourni pouvant délivrer jusqu’à 500 mW de puissance.

Le total atteint une taille d’environ 10*5 cm, ce qui n’est pas excessif, ce qui le rend aisément portatif sur une jambe ou à la taille.

'''Coût : 115€'''

Ce module pourra également servir d’antenne relai, l'alimentation solaire devrait maintenir le dispositif chargé en permanence. Des tests seront effectués pour savoir si un panneau solaire plus puissant est requis.

== Boîtier ==

Le boîtier sécurisé devant respecter plusieurs exigences, nous pouvons le construire en plastique résistant, ce qui le rendrait léger tout en respectant une rigidité suffisante. Les antennes pourront être placées le long du boîtier, à l’intérieur si la connexion est suffisante, ou à l’extérieur. Dans ce dernier cas les trous réalisés sur le boîtier afin de laisser passer les câbles seront colmatés afin de garantir une étanchéité.

[[File:SchemaBoitier.png||100px|Schéma boitier d'alarme]]

== Balises ==

Afin de remonter les informations transmises par les boitiers, des balises seront mises en places sur la zone à couvrir, leur nombre et leur positions dépendra du terrain (obstacles, dénivelés). On distinguera deux types de balises. Tout d’abord, les balises racines qui permettront une communication GSM afin de faire remonter les données vers le serveur. Viennent ensuite les balises standard qui se contenteront de faire remonter vers leur balise racine associée. L’architecture de liaison des balises est détaillée dans une prochaine partie.

Chaque balise est composée d’une barre de fer pouvant être plantée dans le sol, d’un système de lest afin d’immobiliser la balise, d’un paratonnerre, d’un panneau solaire ainsi que d’un LoraOne et d’une batterie. Les balises racines seront équippée en plus d’un dispositif de communication GSM (téléphone portable, émetteur GSM).

[[File:SchemaBalise.png||150px|Schéma balises d'alarme]]

== Application mobile ==
Une application mobile est téléchargeable par les utilisateurs. Ils peuvent voir les autres utilisateurs présents dans leur zone. Lorsqu’un utilisateur est en position de danger, une notification apparaît si les utilisateurs sont proches de la situation de danger.

Cette application n’est pas directement reliée au dispositif. Elle ne fonctionne qu’avec la connexion du mobile, et est destinée à être un niveau de sécurité supérieur. Un randonneur proche d’une zone de danger pourrait arriver sur place plus rapidement que les secours.

= Communication =

Pour un envoi de position + numéro d’identification (X chiffres) :

*Temps de communication : < 2 s
*Communication régulière, intervalle de 15 minutes

On peut donc au maximum avoir 15 * 60 / 2 = 450 individus pouvant communiquer avec la même antenne relai, donc dans le même cercle d’environ 15 km de diamètre.

On communique donc au minimum 2 secondes sur 15 minutes, donc 1/450 << 1%, le temps de communication est respecté.

En cas de problème, nous pouvons envoyer jusqu’à 9x plus avec la borne sans dépasser le temps de communication autorisé (1%). Donc 1 envoi d’appel d’urgence toutes les 2 minutes environ.

La balise racine peut être directement connectée au serveur, dans ce cas, il n’y a pas de communication GSM nécessaire et pas de Gateway. Si la racine n’est pas directement connectée au serveur, elle devra au minimum garantir une communication GSM (ce qu’elle peut faire, il n’y a pas de Gateway nécessaire) pour remonter l’information vers le serveur, et donc la base de données.

GSM : Si Racine connectée à Serveur -> No GSM + Gateway
Else : GSM + Gateway : LoRa Racine connectée ordi (RaspberryPI) + ordi connecté GSM

= Stabilisation et gestion d’erreurs =

== Choix du routage ==

Notre réseau n'est pas un réseau traditionnel. Les seules communications existantes sont soit une remontée d'information vers la racine soit une innondation d'alerte vers les clients. Pour celà nous avons donc décidé d'utiliser un algorithme de routage simplifié basé uniquement sur un arbre en largeur des balises. Nous rajoutons en option la possibilité de créer plusieurs racines et donc plusieurs arbres dont les racines communiquent par gsm. Nous nous basons sur des papiers de recherches afin de déterminer quel algorithme auto-stabilisant est le plus adapté au système LoRa (Tel que le papier "A self-stabilizing algorithm for constructing breadth-first trees" par Shing-Tsaan Huang, Nian-Shing Chen).

== Stabilisation ==

Afin de gérer la communication de chaque message vers le serveur, nous allons prendre un noeud (balise LoRa) dit “racine” connecté directement au serveur, nous ne nous occuperons pas de la communication au serveur dans cet onglet. Chaque message reçu de la part d’un noeud du système doit être relayé jusqu’à la racine du système afin de communiquer avec les secours (ou serveur simplement).

Pour cela, il faudra assurer que chaque balise LoRa soit connecté au réseau, afin d’avoir au départ un graphe de communication connexe. Par dessus ce graphe, nous allons utiliser un processus silencieux auto-stabilisant qui construira un arbre de parcours en largeur, avec pour racine le noeud “racine” décidé ci-dessus.

Au lancement du système, il faut prévoir un léger temps de stabilisation, qui dépendrait de l’algorithme et de la taille du graphe (nombre de balises). Cependant, après cela, l’algorithme assure un arbre en profondeur minimal qui nous permettrai de communiquer avec la racine le plus rapidement possible, et donc une qualité de service maximale.

== Gestion d’erreurs ==

Dans un réseau comme celui-ci, plusieurs types d’erreurs peuvent se produire :
Délai de communication trop important vers une balise
“Crash” d’une balise de communication
Surpopulation d’une balise ou congestion de messages

Afin de palier au premier type d’incident rencontré, il faut nécessairement qu’à chaque emplacement dans la zone couverte, l’utilisateur soit à même de communiquer avec au minimum 2 balises différentes. Ainsi, dans le cas d’une communication trop longue sur une balise, l’autre aurait de grandes chances de délivrer le message plus rapidement.

Au niveau de la défaillance d’une balise, l’algorithme d’arbre en profondeur nous fournit déjà une solution intégrée grâce à son auto-stabilisation. Dans le cas de déconnexion d’une balise, l’algorithme mettrai à jour automatiquement l’arbre de communication, et n’importe quel message d’alerte émis serait délivré dans un délai raisonnable.

Pour le troisième cas d’erreur, il n’y aurait pas de solution réelle, si ce n’est de limiter le nombre de communications données, en ne prenant plus en compte les “ping” de chaque utilisateur mais seulement les messages d’alertes, ce qui permettrai une bien plus grande gestion de la congestion à un endroit donné. Également, une balise en dessous d’un lien congestionné pourrait communiquer avec ses autres voisins (non-fils dans l’arbre) afin de libérer de l’espace dans le lien avec son père dans l’arbre. Également, le système ne pourra accepter que jusqu’à 1000 utilisateurs par noeud, et également 4000 utilisateurs par cluster (dans le cas d’un réseau avec plusieurs clusters donc plusieurs racines cette limite augmente).

Plusieurs types de paquets circulent sur le réseau de balise:
Les pings, messages envoyés spontanéments à intervalle régulier par les utilisateur contenant l’id ainsi que les deux coordonées gps (27 bits chacun)
Les incidents, identique à un ping mais à priorité haute.
Les alertes, messages brodcastés par le serveur afin d’envoyer un message en chaine de caractères courts et compressés.

=Coûts matériels=

Que ce soit pour le dispositif utilisateur ou la balise (racine ou non), le LoRaOne correspond pour permettre les actions recherchées. Afin de réaliser un prototype pertinent, 6 kits LoRaOne sont requis. Ces kits sont accessibles sur le site de Sodaq au prix de 115€ chacun (prix variable).
Disponible [https://shop.sodaq.com/en/one-eu-rn2483-v2.html ici], voir avant dernier bundle : starter "ONE EU starter" actuellement à 112,10€.

Un [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer buzzer] est à ajouter au dispositif utilisateur afin de lui délivrer un signal sonore.

Un shield GSM est requis pour que la balise racine communique avec l'extérieur. Sodaq en propose un designé pour fonctionner sur leurs produits mais est éctuellement en rupture de stock. Un shield GSM arduino convient tout autant et peut être trouvé sur le site arduino [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna ici].

Aucun boitier ne sera commandé car nous avons fait le choix de les manufacturer nous même au fablab. Le besoin d'étanchéité n'est pas primordial pour notre prototype, bien que nous tenterons de l'assurer.

{|class="récap commande"
|+ Récapitulatif
|-
|
!scope="col" style="width: 320px;"| Produit
!scope="col" style="width: 80px;"| Lien
!scope="col" style="width: 80px;"| Quantité
!scope="col" style="width: 80px;"| Prix Unitaire
|-

!scope="row"| 1
| LoRaOne EU Starter
| [https://shop.sodaq.com/en/one-eu-rn2483-v2.html Achat]
| 6
| 115€
|-

!scope="row"| 2
| Buzzer
| [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer Achat]
| 3
| 5.49€
|-

!scope="row"| 3
| Shield GSM
| [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna Achat]
| 1
| 65€
|-

|}

=Développement=

Nous utiliserons les librairies standards Arduino ainsi que celle de SODAQ/Arduino pour le LoRa.

L'IDE Arduino sera utilisé, plus pratique pour l'utilisation de Git (comparé à Mbed).

= Mise sur le marché =

Ce dispositif a pour but d’être utilisé en montagne, lors de randonnée. Il n’est pas destiné à un usage quotidien, c’est pourquoi nous considérons qu’il est plus judicieux de louer les dispositifs plutôt que de les vendre, même si l’achat n’est pas à omettre de notre stratégie.

Le dispositif peut être commandé en ligne, puis retourné par la poste après usage. Le client louerait le dispositif pour une certaine durée avec un possible nombre supplémentaire de batterie. Les tarifs varient en fonction de la durée et du nombre de batteries louées. Des offres de groupes pourraient être applicables. A long terme, des boutiques pourraient être disséminées dans des grandes villes proches des zones montagneuses, zones à randonnées (Grenoble, Annecy, etc.).

L’application est téléchargeable gratuitement par quiconque, mais utilisable seulement par les clients. Un code d’accès sera envoyé avec le dispositif expirant après la fin de la location.

Il faudra tenir compte de la bande passante du LoRa, variante en fonction des continents.

=Planning=

Sprint 1 : 29/01 --> 09/02 : Création du prototype logiciel #1
*Prise en main du matériel
*Premiers tests de transmissions LoRa
*Création du protocole d'architecture des balises
*Application sur les cartes et tests
*Tests de performances des cartes (durabilité, chargement, batterie)
*Tests de maintenabilité de l'algorithme (déconnexions, latences)

Sprint 2 : 12/02 --> 23/02 : Prototype logiciel #2 et prototype matériel
*Création du programme embarqué (utilisateur)
*Communication avec la racine et le serveur
*Création des maquettes boîtier et balise
*Construction des maquettes
*Finalisation du premier prototype

Sprint 3 : 26/02 --> 09/03 : Fonctionnalités supplémentaires
*Ajout de la communication entre le LoRa et le GSM sur la balise racine
*Création application mobile utilisateur
*Tests sur l'application
*Tests sur la transmission totale depuis l'utilisateur vers le serveur via le GSM
*Finalisation du projet

Sprint 4 : 12/03 --> 16/03 : Fin du projet
*Création de la documentation finale (à partir de la documentation réalisée en continu)
*Pause café
*Temps supplémentaire en cas de problèmes importants
*Préparation de la soutenance

R'Montagne

2018-02-12T10:06:45Z

Hugo.Amodru-Favin: /* Journal */

=Présentation du projet=

==Équipe==
{|class="wikitable"
|-
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Rôle
|-
| Hugo Amodru-Favin
| Chef de Projet
|-
| Antoine Delise
| Lead Developer
|-
| Gwenaël Moreau
| Kanban Master
|-

|}

==Tâches==

Répartition générale des tâches
{|class="wikitable"
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Tâche
|-
| Hugo Amodru-Favin
| Application Ionic
|-
| Antoine Delise
| Développement Arduino
|-
| Gwenaël Moreau
| BDD - API
|-

|}

Détail des tâches : [https://waffle.io/delisea/R-Montagne Lien Waffle.io]

==Journal==

{|class="wikitable"
|+
|-
|
!scope="col"| Date
!scope="col"| Hugo AMODRU-FAVIN
!scope="col"| Antoine DELISE
!scope="col"| Gwenaël MOREAU
|-

| colspan="5" style="text-align: center; background-color:#1c531c; width:225px;"| SPRINT 1
|-

|-
| rowspan="2" | Lundi 29/01/18
| rowspan="1" | Tâches
| style="width: 225px;" |
* efoed
| style="width: 225px;" |
* sidfjeso
| style="width: 225px;" |
* zdokz
|-
|}

==Randonnée et risques==

Ouvert à tous, la randonnée est un sport et un loisir qui prend de plus en plus d’ampleur de nos jours. Ne nécessitant pas de grands prérequis, des milliers de personnes se lancent en montagne chaque jour, malheureusement parfois sans connaître toutes les mesures de sécurité associées.

En effet, de janvier à juin 2016, en randonnée et en alpinisme, l’Association Nationale pour l’Étude de la Neige et des Avalanches (ANENA) a comptabilisé 21 accidents notables, dont 8 accidents mortels, impliquant 15 décès.

Aujourd’hui, les mesures de sécurités préconisent que chaque groupe de randonneur se doivent de se munir d’un téléphone portable afin d’appeler les secours en cas de problème. Malheureusement, la communication mobile dépendant de la couverture réseau, peu présente en montagne, l’impossibilité de joindre les secours reste un problème.

==Solutions existantes==

La solution la plus répandue, est celle du téléphone à connexion satellite. Ayant une communication vers les satellites, cela permet une couverture réseau beaucoup plus répandue dans les montagnes, partout dans le monde (ou presque). Cependant, les téléphones portables satellitaires coûtent chers, et ne sont pas forcément abordables par la plupart des personnes, surtout celles ne sortant qu’occasionnellement.

[https://fall-alarm.net/ Fall Alarm] est un système de détection de chute sur chantier utilisant les mêmes technologies dont nous avons besoin pour notre projet.

==Quelles zones géographiques ?==

Toutes les zones montagneuses peuvent présenter des zones blanches, démunies de connexion quelconque autre que les connexions satellitaires. Certaines chaînes de montagne comme la Cordillaire des Andes ne présentent aucune connexion possible quelconque.

Dans le cadre de notre projet, nous fonctionnerons essentiellement dans la localisation grenobloise avec l'objectif que notre solution soit applicable partout dans le monde. Une contrainte intervient tout de même étant donnée que la fréquence d'utilisation du LoRa en Europe est de 868MHz, 915MHz en Amérique et 433MHz en Asie.

= Fonctionnalités =

Afin de remplir au mieux ses attentes, le principal objectif de ce dispositif sera premièrement de pouvoir communiquer avec les secours à n’importe quel moment, et surtout n’importe où. De plus, il sera capable de détecter de nombreux cas de détresse de la part de l’usager afin de pouvoir lancer un appel d’urgence sans interaction avec l’usager, au cas où il serait inconscient, ou incapable de lancer un appel manuel.

Grâce aux accéléromètres, le dispositif sera à même de détecter un mouvement brutal du randonneur, ce qui pourrait s’apparenter à une chute. Ils pourront également détecter une position anormale, ou une immobilité prolongée, ce qui déclencherait le dispositif d’urgence automatiquement.

Grâce à des tests réalisés au préalable, le boîtier pourra détecter correctement les chûtes de simples mouvements, afin de ne pas lancer l’appel sans raison valable.

Avant de lancer une alerte automatique, le dispositif émettra un signal auditif et visuel à l’utilisateur quelques secondes auparavant, afin de le prévenir l'émission du signal d’urgence, et de lui proposer de le désactiver sur simple pression d’un bouton, afin d’éviter les communications inutiles.

Également, le randonneur sera à même d'émettre volontairement un appel d’urgence à l’aide du bouton, ce qui permet à tout moment d’appeler de l’aide sans effort. Cela peut permettre également à appeler les secours pour une personne en danger qui ne porterait pas le dispositif.

L’appel au secours se représente par un envoi de coordonnées GPS aux secours, via une communication radio LoRa vers des bornes relais placées au préalables en montagne. Cette communication irait de relai de relai jusqu’au centre de sécurité, d’où le message serait transmis aux secours.

De plus, une application mobile verra le jour afin de connecter tous les utilisateurs du module de sécurité, de les visualiser sur une map, et de partager leurs données. En effet, à chaque incident, l’application mettra à jour la position et de la date de l’accident, afin de permettre aux prochains utilisateurs d’être prévenus. Ils pourraient, s'ils sont à proximité, d'assister la personne en détresse en attendant l'arrivée des secours. Bien évidemment, cette application ne sera accessible uniquement si le smartphone de l'utilisateur est relié à une connexion 4G ou Wi-Fi.

Cette prévention pourrait les sensibiliser aux risques de la montagne, leur permettre d’éviter le secteur mais aussi d’aider les personnes en danger si la distance le permet.

= Exigences =
== Fonctionnelles ==

*Batterie garantie fonctionnelle 1 semaine
*Rechargement possible via le panneau solaire portable
*Dispositif pouvant être allumé et éteint par l'utilisateur
*Alarme s’enclenche automatiquement dès qu'elle est considérée nécessaire, signal sonore
*Utilisateur a la possibilité d’activer/désactiver l’alarme quand il le souhaite
*Lorsque l’alarme est active, l’appareil ne peut s’éteindre
*...

== Non-Fonctionnelles ==

*Résistance : aux chocs, impacts, waterproof (utilisé en permanence en plein air)
*Disponibilité : Appareil de secours -> Doit être au plus possible performant
*Performance : Minimiser les pertes réseaux
*Accessible : Utilisateur pas forcément familier avec des appareils électroniques (facile d’utilisation)
*Fiabilité : Précision du GPS (rayon de 10m), données non-éronnées
*Coût : Le plus faible possible pour vendre le moins cher possible
*Efficacité : Réduire la consommation, utiliser le moins possible les ressources

= Composants =
== LoRaONE ==
Pour le coeur du projet, après avoir cherché et comparés plusieurs modules LoRa, GPS ou encore accéléromètres, nous avons finalement opté pour le projet LoRaONE.

LoRaONE est un projet de SODAQ regroupant plusieurs composants dans une seule et même carte, de taille réduite.

https://www.kickstarter.com/projects/sodaq/loraone-the-lora-iot-development-board

“The one IoT development board to rule them all” --SODAQ

Cette carte regroupe plusieurs capteurs afin de respecter aux mieux nos exigences :

Un émetteur/récepteur LoRa afin de pouvoir communiquer au mieux avec les antennes relai à longue distance

Un module + antenne GPS de bonne précision (< 10m) pour connaître en tout temps notre position, et ainsi faciliter l’arrivée des secours, ainsi que la recherche de l’individu en détresse

Un accéléromètre sur 3 axes afin de pouvoir détecter tout mouvement, vitesse ou rotation dans l’espace, ce qui permet la détection de chutes ou d’arrêt de mouvements

3 LED RGB afin de pouvoir signaler à l’utilisateur un manque de batterie, un signal d’urgence ou plus si nécessaire

Un bouton poussoir pour le signal d’alarme

Un connecteur de charge par panneau solaire, afin de faire durer chaque batterie le plus longtemps possible

Un connecteur micro-USB ainsi que des lignes pour se connecter à une base Arduino si besoin

[[File:LoRaOne.png||400px|Spécifications carte LoRaOne]]

De plus, grâce au starter pack, nous pouvons avoir accès à la base ONEBase qui nous permettrait d’étendre plus loin la facilité d’utilisation du produit :

[[File:LoRaOneBase.png||400px|Spécifications base LoRaOneBase]]

Comme nous pouvons le voir, cette base nous permettra de connecter la batterie ainsi que le panneau solaire qui sont fournis dans le pack.

Nous pourrons également connecter jusqu’à 4 modules supplémentaires.

La batterie fournie aura une capacité de 800 mAh, le panneau solaire fourni pouvant délivrer jusqu’à 500 mW de puissance.

Le total atteint une taille d’environ 10*5 cm, ce qui n’est pas excessif, ce qui le rend aisément portatif sur une jambe ou à la taille.

'''Coût : 115€'''

Ce module pourra également servir d’antenne relai, l'alimentation solaire devrait maintenir le dispositif chargé en permanence. Des tests seront effectués pour savoir si un panneau solaire plus puissant est requis.

== Boîtier ==

Le boîtier sécurisé devant respecter plusieurs exigences, nous pouvons le construire en plastique résistant, ce qui le rendrait léger tout en respectant une rigidité suffisante. Les antennes pourront être placées le long du boîtier, à l’intérieur si la connexion est suffisante, ou à l’extérieur. Dans ce dernier cas les trous réalisés sur le boîtier afin de laisser passer les câbles seront colmatés afin de garantir une étanchéité.

[[File:SchemaBoitier.png||100px|Schéma boitier d'alarme]]

== Balises ==

Afin de remonter les informations transmises par les boitiers, des balises seront mises en places sur la zone à couvrir, leur nombre et leur positions dépendra du terrain (obstacles, dénivelés). On distinguera deux types de balises. Tout d’abord, les balises racines qui permettront une communication GSM afin de faire remonter les données vers le serveur. Viennent ensuite les balises standard qui se contenteront de faire remonter vers leur balise racine associée. L’architecture de liaison des balises est détaillée dans une prochaine partie.

Chaque balise est composée d’une barre de fer pouvant être plantée dans le sol, d’un système de lest afin d’immobiliser la balise, d’un paratonnerre, d’un panneau solaire ainsi que d’un LoraOne et d’une batterie. Les balises racines seront équippée en plus d’un dispositif de communication GSM (téléphone portable, émetteur GSM).

[[File:SchemaBalise.png||150px|Schéma balises d'alarme]]

== Application mobile ==
Une application mobile est téléchargeable par les utilisateurs. Ils peuvent voir les autres utilisateurs présents dans leur zone. Lorsqu’un utilisateur est en position de danger, une notification apparaît si les utilisateurs sont proches de la situation de danger.

Cette application n’est pas directement reliée au dispositif. Elle ne fonctionne qu’avec la connexion du mobile, et est destinée à être un niveau de sécurité supérieur. Un randonneur proche d’une zone de danger pourrait arriver sur place plus rapidement que les secours.

= Communication =

Pour un envoi de position + numéro d’identification (X chiffres) :

*Temps de communication : < 2 s
*Communication régulière, intervalle de 15 minutes

On peut donc au maximum avoir 15 * 60 / 2 = 450 individus pouvant communiquer avec la même antenne relai, donc dans le même cercle d’environ 15 km de diamètre.

On communique donc au minimum 2 secondes sur 15 minutes, donc 1/450 << 1%, le temps de communication est respecté.

En cas de problème, nous pouvons envoyer jusqu’à 9x plus avec la borne sans dépasser le temps de communication autorisé (1%). Donc 1 envoi d’appel d’urgence toutes les 2 minutes environ.

La balise racine peut être directement connectée au serveur, dans ce cas, il n’y a pas de communication GSM nécessaire et pas de Gateway. Si la racine n’est pas directement connectée au serveur, elle devra au minimum garantir une communication GSM (ce qu’elle peut faire, il n’y a pas de Gateway nécessaire) pour remonter l’information vers le serveur, et donc la base de données.

GSM : Si Racine connectée à Serveur -> No GSM + Gateway
Else : GSM + Gateway : LoRa Racine connectée ordi (RaspberryPI) + ordi connecté GSM

= Stabilisation et gestion d’erreurs =

== Choix du routage ==

Notre réseau n'est pas un réseau traditionnel. Les seules communications existantes sont soit une remontée d'information vers la racine soit une innondation d'alerte vers les clients. Pour celà nous avons donc décidé d'utiliser un algorithme de routage simplifié basé uniquement sur un arbre en largeur des balises. Nous rajoutons en option la possibilité de créer plusieurs racines et donc plusieurs arbres dont les racines communiquent par gsm. Nous nous basons sur des papiers de recherches afin de déterminer quel algorithme auto-stabilisant est le plus adapté au système LoRa (Tel que le papier "A self-stabilizing algorithm for constructing breadth-first trees" par Shing-Tsaan Huang, Nian-Shing Chen).

== Stabilisation ==

Afin de gérer la communication de chaque message vers le serveur, nous allons prendre un noeud (balise LoRa) dit “racine” connecté directement au serveur, nous ne nous occuperons pas de la communication au serveur dans cet onglet. Chaque message reçu de la part d’un noeud du système doit être relayé jusqu’à la racine du système afin de communiquer avec les secours (ou serveur simplement).

Pour cela, il faudra assurer que chaque balise LoRa soit connecté au réseau, afin d’avoir au départ un graphe de communication connexe. Par dessus ce graphe, nous allons utiliser un processus silencieux auto-stabilisant qui construira un arbre de parcours en largeur, avec pour racine le noeud “racine” décidé ci-dessus.

Au lancement du système, il faut prévoir un léger temps de stabilisation, qui dépendrait de l’algorithme et de la taille du graphe (nombre de balises). Cependant, après cela, l’algorithme assure un arbre en profondeur minimal qui nous permettrai de communiquer avec la racine le plus rapidement possible, et donc une qualité de service maximale.

== Gestion d’erreurs ==

Dans un réseau comme celui-ci, plusieurs types d’erreurs peuvent se produire :
Délai de communication trop important vers une balise
“Crash” d’une balise de communication
Surpopulation d’une balise ou congestion de messages

Afin de palier au premier type d’incident rencontré, il faut nécessairement qu’à chaque emplacement dans la zone couverte, l’utilisateur soit à même de communiquer avec au minimum 2 balises différentes. Ainsi, dans le cas d’une communication trop longue sur une balise, l’autre aurait de grandes chances de délivrer le message plus rapidement.

Au niveau de la défaillance d’une balise, l’algorithme d’arbre en profondeur nous fournit déjà une solution intégrée grâce à son auto-stabilisation. Dans le cas de déconnexion d’une balise, l’algorithme mettrai à jour automatiquement l’arbre de communication, et n’importe quel message d’alerte émis serait délivré dans un délai raisonnable.

Pour le troisième cas d’erreur, il n’y aurait pas de solution réelle, si ce n’est de limiter le nombre de communications données, en ne prenant plus en compte les “ping” de chaque utilisateur mais seulement les messages d’alertes, ce qui permettrai une bien plus grande gestion de la congestion à un endroit donné. Également, une balise en dessous d’un lien congestionné pourrait communiquer avec ses autres voisins (non-fils dans l’arbre) afin de libérer de l’espace dans le lien avec son père dans l’arbre. Également, le système ne pourra accepter que jusqu’à 1000 utilisateurs par noeud, et également 4000 utilisateurs par cluster (dans le cas d’un réseau avec plusieurs clusters donc plusieurs racines cette limite augmente).

Plusieurs types de paquets circulent sur le réseau de balise:
Les pings, messages envoyés spontanéments à intervalle régulier par les utilisateur contenant l’id ainsi que les deux coordonées gps (27 bits chacun)
Les incidents, identique à un ping mais à priorité haute.
Les alertes, messages brodcastés par le serveur afin d’envoyer un message en chaine de caractères courts et compressés.

=Coûts matériels=

Que ce soit pour le dispositif utilisateur ou la balise (racine ou non), le LoRaOne correspond pour permettre les actions recherchées. Afin de réaliser un prototype pertinent, 6 kits LoRaOne sont requis. Ces kits sont accessibles sur le site de Sodaq au prix de 115€ chacun (prix variable).
Disponible [https://shop.sodaq.com/en/one-eu-rn2483-v2.html ici], voir avant dernier bundle : starter "ONE EU starter" actuellement à 112,10€.

Un [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer buzzer] est à ajouter au dispositif utilisateur afin de lui délivrer un signal sonore.

Un shield GSM est requis pour que la balise racine communique avec l'extérieur. Sodaq en propose un designé pour fonctionner sur leurs produits mais est éctuellement en rupture de stock. Un shield GSM arduino convient tout autant et peut être trouvé sur le site arduino [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna ici].

Aucun boitier ne sera commandé car nous avons fait le choix de les manufacturer nous même au fablab. Le besoin d'étanchéité n'est pas primordial pour notre prototype, bien que nous tenterons de l'assurer.

{|class="récap commande"
|+ Récapitulatif
|-
|
!scope="col" style="width: 320px;"| Produit
!scope="col" style="width: 80px;"| Lien
!scope="col" style="width: 80px;"| Quantité
!scope="col" style="width: 80px;"| Prix Unitaire
|-

!scope="row"| 1
| LoRaOne EU Starter
| [https://shop.sodaq.com/en/one-eu-rn2483-v2.html Achat]
| 6
| 115€
|-

!scope="row"| 2
| Buzzer
| [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer Achat]
| 3
| 5.49€
|-

!scope="row"| 3
| Shield GSM
| [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna Achat]
| 1
| 65€
|-

|}

=Développement=

Nous utiliserons les librairies standards Arduino ainsi que celle de SODAQ/Arduino pour le LoRa.

L'IDE Arduino sera utilisé, plus pratique pour l'utilisation de Git (comparé à Mbed).

= Mise sur le marché =

Ce dispositif a pour but d’être utilisé en montagne, lors de randonnée. Il n’est pas destiné à un usage quotidien, c’est pourquoi nous considérons qu’il est plus judicieux de louer les dispositifs plutôt que de les vendre, même si l’achat n’est pas à omettre de notre stratégie.

Le dispositif peut être commandé en ligne, puis retourné par la poste après usage. Le client louerait le dispositif pour une certaine durée avec un possible nombre supplémentaire de batterie. Les tarifs varient en fonction de la durée et du nombre de batteries louées. Des offres de groupes pourraient être applicables. A long terme, des boutiques pourraient être disséminées dans des grandes villes proches des zones montagneuses, zones à randonnées (Grenoble, Annecy, etc.).

L’application est téléchargeable gratuitement par quiconque, mais utilisable seulement par les clients. Un code d’accès sera envoyé avec le dispositif expirant après la fin de la location.

Il faudra tenir compte de la bande passante du LoRa, variante en fonction des continents.

=Planning=

Sprint 1 : 29/01 --> 09/02 : Création du prototype logiciel #1
*Prise en main du matériel
*Premiers tests de transmissions LoRa
*Création du protocole d'architecture des balises
*Application sur les cartes et tests
*Tests de performances des cartes (durabilité, chargement, batterie)
*Tests de maintenabilité de l'algorithme (déconnexions, latences)

Sprint 2 : 12/02 --> 23/02 : Prototype logiciel #2 et prototype matériel
*Création du programme embarqué (utilisateur)
*Communication avec la racine et le serveur
*Création des maquettes boîtier et balise
*Construction des maquettes
*Finalisation du premier prototype

Sprint 3 : 26/02 --> 09/03 : Fonctionnalités supplémentaires
*Ajout de la communication entre le LoRa et le GSM sur la balise racine
*Création application mobile utilisateur
*Tests sur l'application
*Tests sur la transmission totale depuis l'utilisateur vers le serveur via le GSM
*Finalisation du projet

Sprint 4 : 12/03 --> 16/03 : Fin du projet
*Création de la documentation finale (à partir de la documentation réalisée en continu)
*Pause café
*Temps supplémentaire en cas de problèmes importants
*Préparation de la soutenance

R'Montagne

2018-02-12T10:06:34Z

Hugo.Amodru-Favin: /* Journal */

=Présentation du projet=

==Équipe==
{|class="wikitable"
|-
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Rôle
|-
| Hugo Amodru-Favin
| Chef de Projet
|-
| Antoine Delise
| Lead Developer
|-
| Gwenaël Moreau
| Kanban Master
|-

|}

==Tâches==

Répartition générale des tâches
{|class="wikitable"
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Tâche
|-
| Hugo Amodru-Favin
| Application Ionic
|-
| Antoine Delise
| Développement Arduino
|-
| Gwenaël Moreau
| BDD - API
|-

|}

Détail des tâches : [https://waffle.io/delisea/R-Montagne Lien Waffle.io]

==Journal==

{|class="wikitable"
|+
|-
|
!scope="col"| Date
!scope="col"| Hugo AMODRU-FAVIN
!scope="col"| Antoine DELISE
!scope="col"| Gwenaël MOREAU
|-

| colspan="5" style="text-align: center; background-color:#1c531c; width:225px;"| SPRINT 1
|-

|-
| rowspan="2" | Lundi 29/01/18
| rowspan="1" | Tâches
| style="width: 225px;" |
* efoed
| style="width: 225px;" |
* sidfjeso
| style="width: 225px;" |
* zdokz
|-
|}

==Randonnée et risques==

Ouvert à tous, la randonnée est un sport et un loisir qui prend de plus en plus d’ampleur de nos jours. Ne nécessitant pas de grands prérequis, des milliers de personnes se lancent en montagne chaque jour, malheureusement parfois sans connaître toutes les mesures de sécurité associées.

En effet, de janvier à juin 2016, en randonnée et en alpinisme, l’Association Nationale pour l’Étude de la Neige et des Avalanches (ANENA) a comptabilisé 21 accidents notables, dont 8 accidents mortels, impliquant 15 décès.

Aujourd’hui, les mesures de sécurités préconisent que chaque groupe de randonneur se doivent de se munir d’un téléphone portable afin d’appeler les secours en cas de problème. Malheureusement, la communication mobile dépendant de la couverture réseau, peu présente en montagne, l’impossibilité de joindre les secours reste un problème.

==Solutions existantes==

La solution la plus répandue, est celle du téléphone à connexion satellite. Ayant une communication vers les satellites, cela permet une couverture réseau beaucoup plus répandue dans les montagnes, partout dans le monde (ou presque). Cependant, les téléphones portables satellitaires coûtent chers, et ne sont pas forcément abordables par la plupart des personnes, surtout celles ne sortant qu’occasionnellement.

[https://fall-alarm.net/ Fall Alarm] est un système de détection de chute sur chantier utilisant les mêmes technologies dont nous avons besoin pour notre projet.

==Quelles zones géographiques ?==

Toutes les zones montagneuses peuvent présenter des zones blanches, démunies de connexion quelconque autre que les connexions satellitaires. Certaines chaînes de montagne comme la Cordillaire des Andes ne présentent aucune connexion possible quelconque.

Dans le cadre de notre projet, nous fonctionnerons essentiellement dans la localisation grenobloise avec l'objectif que notre solution soit applicable partout dans le monde. Une contrainte intervient tout de même étant donnée que la fréquence d'utilisation du LoRa en Europe est de 868MHz, 915MHz en Amérique et 433MHz en Asie.

= Fonctionnalités =

Afin de remplir au mieux ses attentes, le principal objectif de ce dispositif sera premièrement de pouvoir communiquer avec les secours à n’importe quel moment, et surtout n’importe où. De plus, il sera capable de détecter de nombreux cas de détresse de la part de l’usager afin de pouvoir lancer un appel d’urgence sans interaction avec l’usager, au cas où il serait inconscient, ou incapable de lancer un appel manuel.

Grâce aux accéléromètres, le dispositif sera à même de détecter un mouvement brutal du randonneur, ce qui pourrait s’apparenter à une chute. Ils pourront également détecter une position anormale, ou une immobilité prolongée, ce qui déclencherait le dispositif d’urgence automatiquement.

Grâce à des tests réalisés au préalable, le boîtier pourra détecter correctement les chûtes de simples mouvements, afin de ne pas lancer l’appel sans raison valable.

Avant de lancer une alerte automatique, le dispositif émettra un signal auditif et visuel à l’utilisateur quelques secondes auparavant, afin de le prévenir l'émission du signal d’urgence, et de lui proposer de le désactiver sur simple pression d’un bouton, afin d’éviter les communications inutiles.

Également, le randonneur sera à même d'émettre volontairement un appel d’urgence à l’aide du bouton, ce qui permet à tout moment d’appeler de l’aide sans effort. Cela peut permettre également à appeler les secours pour une personne en danger qui ne porterait pas le dispositif.

L’appel au secours se représente par un envoi de coordonnées GPS aux secours, via une communication radio LoRa vers des bornes relais placées au préalables en montagne. Cette communication irait de relai de relai jusqu’au centre de sécurité, d’où le message serait transmis aux secours.

De plus, une application mobile verra le jour afin de connecter tous les utilisateurs du module de sécurité, de les visualiser sur une map, et de partager leurs données. En effet, à chaque incident, l’application mettra à jour la position et de la date de l’accident, afin de permettre aux prochains utilisateurs d’être prévenus. Ils pourraient, s'ils sont à proximité, d'assister la personne en détresse en attendant l'arrivée des secours. Bien évidemment, cette application ne sera accessible uniquement si le smartphone de l'utilisateur est relié à une connexion 4G ou Wi-Fi.

Cette prévention pourrait les sensibiliser aux risques de la montagne, leur permettre d’éviter le secteur mais aussi d’aider les personnes en danger si la distance le permet.

= Exigences =
== Fonctionnelles ==

*Batterie garantie fonctionnelle 1 semaine
*Rechargement possible via le panneau solaire portable
*Dispositif pouvant être allumé et éteint par l'utilisateur
*Alarme s’enclenche automatiquement dès qu'elle est considérée nécessaire, signal sonore
*Utilisateur a la possibilité d’activer/désactiver l’alarme quand il le souhaite
*Lorsque l’alarme est active, l’appareil ne peut s’éteindre
*...

== Non-Fonctionnelles ==

*Résistance : aux chocs, impacts, waterproof (utilisé en permanence en plein air)
*Disponibilité : Appareil de secours -> Doit être au plus possible performant
*Performance : Minimiser les pertes réseaux
*Accessible : Utilisateur pas forcément familier avec des appareils électroniques (facile d’utilisation)
*Fiabilité : Précision du GPS (rayon de 10m), données non-éronnées
*Coût : Le plus faible possible pour vendre le moins cher possible
*Efficacité : Réduire la consommation, utiliser le moins possible les ressources

= Composants =
== LoRaONE ==
Pour le coeur du projet, après avoir cherché et comparés plusieurs modules LoRa, GPS ou encore accéléromètres, nous avons finalement opté pour le projet LoRaONE.

LoRaONE est un projet de SODAQ regroupant plusieurs composants dans une seule et même carte, de taille réduite.

https://www.kickstarter.com/projects/sodaq/loraone-the-lora-iot-development-board

“The one IoT development board to rule them all” --SODAQ

Cette carte regroupe plusieurs capteurs afin de respecter aux mieux nos exigences :

Un émetteur/récepteur LoRa afin de pouvoir communiquer au mieux avec les antennes relai à longue distance

Un module + antenne GPS de bonne précision (< 10m) pour connaître en tout temps notre position, et ainsi faciliter l’arrivée des secours, ainsi que la recherche de l’individu en détresse

Un accéléromètre sur 3 axes afin de pouvoir détecter tout mouvement, vitesse ou rotation dans l’espace, ce qui permet la détection de chutes ou d’arrêt de mouvements

3 LED RGB afin de pouvoir signaler à l’utilisateur un manque de batterie, un signal d’urgence ou plus si nécessaire

Un bouton poussoir pour le signal d’alarme

Un connecteur de charge par panneau solaire, afin de faire durer chaque batterie le plus longtemps possible

Un connecteur micro-USB ainsi que des lignes pour se connecter à une base Arduino si besoin

[[File:LoRaOne.png||400px|Spécifications carte LoRaOne]]

De plus, grâce au starter pack, nous pouvons avoir accès à la base ONEBase qui nous permettrait d’étendre plus loin la facilité d’utilisation du produit :

[[File:LoRaOneBase.png||400px|Spécifications base LoRaOneBase]]

Comme nous pouvons le voir, cette base nous permettra de connecter la batterie ainsi que le panneau solaire qui sont fournis dans le pack.

Nous pourrons également connecter jusqu’à 4 modules supplémentaires.

La batterie fournie aura une capacité de 800 mAh, le panneau solaire fourni pouvant délivrer jusqu’à 500 mW de puissance.

Le total atteint une taille d’environ 10*5 cm, ce qui n’est pas excessif, ce qui le rend aisément portatif sur une jambe ou à la taille.

'''Coût : 115€'''

Ce module pourra également servir d’antenne relai, l'alimentation solaire devrait maintenir le dispositif chargé en permanence. Des tests seront effectués pour savoir si un panneau solaire plus puissant est requis.

== Boîtier ==

Le boîtier sécurisé devant respecter plusieurs exigences, nous pouvons le construire en plastique résistant, ce qui le rendrait léger tout en respectant une rigidité suffisante. Les antennes pourront être placées le long du boîtier, à l’intérieur si la connexion est suffisante, ou à l’extérieur. Dans ce dernier cas les trous réalisés sur le boîtier afin de laisser passer les câbles seront colmatés afin de garantir une étanchéité.

[[File:SchemaBoitier.png||100px|Schéma boitier d'alarme]]

== Balises ==

Afin de remonter les informations transmises par les boitiers, des balises seront mises en places sur la zone à couvrir, leur nombre et leur positions dépendra du terrain (obstacles, dénivelés). On distinguera deux types de balises. Tout d’abord, les balises racines qui permettront une communication GSM afin de faire remonter les données vers le serveur. Viennent ensuite les balises standard qui se contenteront de faire remonter vers leur balise racine associée. L’architecture de liaison des balises est détaillée dans une prochaine partie.

Chaque balise est composée d’une barre de fer pouvant être plantée dans le sol, d’un système de lest afin d’immobiliser la balise, d’un paratonnerre, d’un panneau solaire ainsi que d’un LoraOne et d’une batterie. Les balises racines seront équippée en plus d’un dispositif de communication GSM (téléphone portable, émetteur GSM).

[[File:SchemaBalise.png||150px|Schéma balises d'alarme]]

== Application mobile ==
Une application mobile est téléchargeable par les utilisateurs. Ils peuvent voir les autres utilisateurs présents dans leur zone. Lorsqu’un utilisateur est en position de danger, une notification apparaît si les utilisateurs sont proches de la situation de danger.

Cette application n’est pas directement reliée au dispositif. Elle ne fonctionne qu’avec la connexion du mobile, et est destinée à être un niveau de sécurité supérieur. Un randonneur proche d’une zone de danger pourrait arriver sur place plus rapidement que les secours.

= Communication =

Pour un envoi de position + numéro d’identification (X chiffres) :

*Temps de communication : < 2 s
*Communication régulière, intervalle de 15 minutes

On peut donc au maximum avoir 15 * 60 / 2 = 450 individus pouvant communiquer avec la même antenne relai, donc dans le même cercle d’environ 15 km de diamètre.

On communique donc au minimum 2 secondes sur 15 minutes, donc 1/450 << 1%, le temps de communication est respecté.

En cas de problème, nous pouvons envoyer jusqu’à 9x plus avec la borne sans dépasser le temps de communication autorisé (1%). Donc 1 envoi d’appel d’urgence toutes les 2 minutes environ.

La balise racine peut être directement connectée au serveur, dans ce cas, il n’y a pas de communication GSM nécessaire et pas de Gateway. Si la racine n’est pas directement connectée au serveur, elle devra au minimum garantir une communication GSM (ce qu’elle peut faire, il n’y a pas de Gateway nécessaire) pour remonter l’information vers le serveur, et donc la base de données.

GSM : Si Racine connectée à Serveur -> No GSM + Gateway
Else : GSM + Gateway : LoRa Racine connectée ordi (RaspberryPI) + ordi connecté GSM

= Stabilisation et gestion d’erreurs =

== Choix du routage ==

Notre réseau n'est pas un réseau traditionnel. Les seules communications existantes sont soit une remontée d'information vers la racine soit une innondation d'alerte vers les clients. Pour celà nous avons donc décidé d'utiliser un algorithme de routage simplifié basé uniquement sur un arbre en largeur des balises. Nous rajoutons en option la possibilité de créer plusieurs racines et donc plusieurs arbres dont les racines communiquent par gsm. Nous nous basons sur des papiers de recherches afin de déterminer quel algorithme auto-stabilisant est le plus adapté au système LoRa (Tel que le papier "A self-stabilizing algorithm for constructing breadth-first trees" par Shing-Tsaan Huang, Nian-Shing Chen).

== Stabilisation ==

Afin de gérer la communication de chaque message vers le serveur, nous allons prendre un noeud (balise LoRa) dit “racine” connecté directement au serveur, nous ne nous occuperons pas de la communication au serveur dans cet onglet. Chaque message reçu de la part d’un noeud du système doit être relayé jusqu’à la racine du système afin de communiquer avec les secours (ou serveur simplement).

Pour cela, il faudra assurer que chaque balise LoRa soit connecté au réseau, afin d’avoir au départ un graphe de communication connexe. Par dessus ce graphe, nous allons utiliser un processus silencieux auto-stabilisant qui construira un arbre de parcours en largeur, avec pour racine le noeud “racine” décidé ci-dessus.

Au lancement du système, il faut prévoir un léger temps de stabilisation, qui dépendrait de l’algorithme et de la taille du graphe (nombre de balises). Cependant, après cela, l’algorithme assure un arbre en profondeur minimal qui nous permettrai de communiquer avec la racine le plus rapidement possible, et donc une qualité de service maximale.

== Gestion d’erreurs ==

Dans un réseau comme celui-ci, plusieurs types d’erreurs peuvent se produire :
Délai de communication trop important vers une balise
“Crash” d’une balise de communication
Surpopulation d’une balise ou congestion de messages

Afin de palier au premier type d’incident rencontré, il faut nécessairement qu’à chaque emplacement dans la zone couverte, l’utilisateur soit à même de communiquer avec au minimum 2 balises différentes. Ainsi, dans le cas d’une communication trop longue sur une balise, l’autre aurait de grandes chances de délivrer le message plus rapidement.

Au niveau de la défaillance d’une balise, l’algorithme d’arbre en profondeur nous fournit déjà une solution intégrée grâce à son auto-stabilisation. Dans le cas de déconnexion d’une balise, l’algorithme mettrai à jour automatiquement l’arbre de communication, et n’importe quel message d’alerte émis serait délivré dans un délai raisonnable.

Pour le troisième cas d’erreur, il n’y aurait pas de solution réelle, si ce n’est de limiter le nombre de communications données, en ne prenant plus en compte les “ping” de chaque utilisateur mais seulement les messages d’alertes, ce qui permettrai une bien plus grande gestion de la congestion à un endroit donné. Également, une balise en dessous d’un lien congestionné pourrait communiquer avec ses autres voisins (non-fils dans l’arbre) afin de libérer de l’espace dans le lien avec son père dans l’arbre. Également, le système ne pourra accepter que jusqu’à 1000 utilisateurs par noeud, et également 4000 utilisateurs par cluster (dans le cas d’un réseau avec plusieurs clusters donc plusieurs racines cette limite augmente).

Plusieurs types de paquets circulent sur le réseau de balise:
Les pings, messages envoyés spontanéments à intervalle régulier par les utilisateur contenant l’id ainsi que les deux coordonées gps (27 bits chacun)
Les incidents, identique à un ping mais à priorité haute.
Les alertes, messages brodcastés par le serveur afin d’envoyer un message en chaine de caractères courts et compressés.

=Coûts matériels=

Que ce soit pour le dispositif utilisateur ou la balise (racine ou non), le LoRaOne correspond pour permettre les actions recherchées. Afin de réaliser un prototype pertinent, 6 kits LoRaOne sont requis. Ces kits sont accessibles sur le site de Sodaq au prix de 115€ chacun (prix variable).
Disponible [https://shop.sodaq.com/en/one-eu-rn2483-v2.html ici], voir avant dernier bundle : starter "ONE EU starter" actuellement à 112,10€.

Un [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer buzzer] est à ajouter au dispositif utilisateur afin de lui délivrer un signal sonore.

Un shield GSM est requis pour que la balise racine communique avec l'extérieur. Sodaq en propose un designé pour fonctionner sur leurs produits mais est éctuellement en rupture de stock. Un shield GSM arduino convient tout autant et peut être trouvé sur le site arduino [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna ici].

Aucun boitier ne sera commandé car nous avons fait le choix de les manufacturer nous même au fablab. Le besoin d'étanchéité n'est pas primordial pour notre prototype, bien que nous tenterons de l'assurer.

{|class="récap commande"
|+ Récapitulatif
|-
|
!scope="col" style="width: 320px;"| Produit
!scope="col" style="width: 80px;"| Lien
!scope="col" style="width: 80px;"| Quantité
!scope="col" style="width: 80px;"| Prix Unitaire
|-

!scope="row"| 1
| LoRaOne EU Starter
| [https://shop.sodaq.com/en/one-eu-rn2483-v2.html Achat]
| 6
| 115€
|-

!scope="row"| 2
| Buzzer
| [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer Achat]
| 3
| 5.49€
|-

!scope="row"| 3
| Shield GSM
| [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna Achat]
| 1
| 65€
|-

|}

=Développement=

Nous utiliserons les librairies standards Arduino ainsi que celle de SODAQ/Arduino pour le LoRa.

L'IDE Arduino sera utilisé, plus pratique pour l'utilisation de Git (comparé à Mbed).

= Mise sur le marché =

Ce dispositif a pour but d’être utilisé en montagne, lors de randonnée. Il n’est pas destiné à un usage quotidien, c’est pourquoi nous considérons qu’il est plus judicieux de louer les dispositifs plutôt que de les vendre, même si l’achat n’est pas à omettre de notre stratégie.

Le dispositif peut être commandé en ligne, puis retourné par la poste après usage. Le client louerait le dispositif pour une certaine durée avec un possible nombre supplémentaire de batterie. Les tarifs varient en fonction de la durée et du nombre de batteries louées. Des offres de groupes pourraient être applicables. A long terme, des boutiques pourraient être disséminées dans des grandes villes proches des zones montagneuses, zones à randonnées (Grenoble, Annecy, etc.).

L’application est téléchargeable gratuitement par quiconque, mais utilisable seulement par les clients. Un code d’accès sera envoyé avec le dispositif expirant après la fin de la location.

Il faudra tenir compte de la bande passante du LoRa, variante en fonction des continents.

=Planning=

Sprint 1 : 29/01 --> 09/02 : Création du prototype logiciel #1
*Prise en main du matériel
*Premiers tests de transmissions LoRa
*Création du protocole d'architecture des balises
*Application sur les cartes et tests
*Tests de performances des cartes (durabilité, chargement, batterie)
*Tests de maintenabilité de l'algorithme (déconnexions, latences)

Sprint 2 : 12/02 --> 23/02 : Prototype logiciel #2 et prototype matériel
*Création du programme embarqué (utilisateur)
*Communication avec la racine et le serveur
*Création des maquettes boîtier et balise
*Construction des maquettes
*Finalisation du premier prototype

Sprint 3 : 26/02 --> 09/03 : Fonctionnalités supplémentaires
*Ajout de la communication entre le LoRa et le GSM sur la balise racine
*Création application mobile utilisateur
*Tests sur l'application
*Tests sur la transmission totale depuis l'utilisateur vers le serveur via le GSM
*Finalisation du projet

Sprint 4 : 12/03 --> 16/03 : Fin du projet
*Création de la documentation finale (à partir de la documentation réalisée en continu)
*Pause café
*Temps supplémentaire en cas de problèmes importants
*Préparation de la soutenance

R'Montagne

2018-02-12T10:06:02Z

Hugo.Amodru-Favin: /* Journal */

=Présentation du projet=

==Équipe==
{|class="wikitable"
|-
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Rôle
|-
| Hugo Amodru-Favin
| Chef de Projet
|-
| Antoine Delise
| Lead Developer
|-
| Gwenaël Moreau
| Kanban Master
|-

|}

==Tâches==

Répartition générale des tâches
{|class="wikitable"
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Tâche
|-
| Hugo Amodru-Favin
| Application Ionic
|-
| Antoine Delise
| Développement Arduino
|-
| Gwenaël Moreau
| BDD - API
|-

|}

Détail des tâches : [https://waffle.io/delisea/R-Montagne Lien Waffle.io]

==Journal==

{|class="wikitable"
|+
|-
|
!scope="col"| Date
!scope="col"| Hugo AMODRU-FAVIN
!scope="col"| Antoine DELISE
!scope="col"| Gwenaël MOREAU
|-

| colspan="5" style="text-align: center; background-color:#1c531c;"| SPRINT 1
|-

|-
| rowspan="2" | Lundi 29/01/18
| rowspan="1" | Tâches
| style="width: 225px;" |
* efoed
| style="width: 225px;" |
* sidfjeso
| style="width: 225px;" |
* zdokz
|-
|}

==Randonnée et risques==

Ouvert à tous, la randonnée est un sport et un loisir qui prend de plus en plus d’ampleur de nos jours. Ne nécessitant pas de grands prérequis, des milliers de personnes se lancent en montagne chaque jour, malheureusement parfois sans connaître toutes les mesures de sécurité associées.

En effet, de janvier à juin 2016, en randonnée et en alpinisme, l’Association Nationale pour l’Étude de la Neige et des Avalanches (ANENA) a comptabilisé 21 accidents notables, dont 8 accidents mortels, impliquant 15 décès.

Aujourd’hui, les mesures de sécurités préconisent que chaque groupe de randonneur se doivent de se munir d’un téléphone portable afin d’appeler les secours en cas de problème. Malheureusement, la communication mobile dépendant de la couverture réseau, peu présente en montagne, l’impossibilité de joindre les secours reste un problème.

==Solutions existantes==

La solution la plus répandue, est celle du téléphone à connexion satellite. Ayant une communication vers les satellites, cela permet une couverture réseau beaucoup plus répandue dans les montagnes, partout dans le monde (ou presque). Cependant, les téléphones portables satellitaires coûtent chers, et ne sont pas forcément abordables par la plupart des personnes, surtout celles ne sortant qu’occasionnellement.

[https://fall-alarm.net/ Fall Alarm] est un système de détection de chute sur chantier utilisant les mêmes technologies dont nous avons besoin pour notre projet.

==Quelles zones géographiques ?==

Toutes les zones montagneuses peuvent présenter des zones blanches, démunies de connexion quelconque autre que les connexions satellitaires. Certaines chaînes de montagne comme la Cordillaire des Andes ne présentent aucune connexion possible quelconque.

Dans le cadre de notre projet, nous fonctionnerons essentiellement dans la localisation grenobloise avec l'objectif que notre solution soit applicable partout dans le monde. Une contrainte intervient tout de même étant donnée que la fréquence d'utilisation du LoRa en Europe est de 868MHz, 915MHz en Amérique et 433MHz en Asie.

= Fonctionnalités =

Afin de remplir au mieux ses attentes, le principal objectif de ce dispositif sera premièrement de pouvoir communiquer avec les secours à n’importe quel moment, et surtout n’importe où. De plus, il sera capable de détecter de nombreux cas de détresse de la part de l’usager afin de pouvoir lancer un appel d’urgence sans interaction avec l’usager, au cas où il serait inconscient, ou incapable de lancer un appel manuel.

Grâce aux accéléromètres, le dispositif sera à même de détecter un mouvement brutal du randonneur, ce qui pourrait s’apparenter à une chute. Ils pourront également détecter une position anormale, ou une immobilité prolongée, ce qui déclencherait le dispositif d’urgence automatiquement.

Grâce à des tests réalisés au préalable, le boîtier pourra détecter correctement les chûtes de simples mouvements, afin de ne pas lancer l’appel sans raison valable.

Avant de lancer une alerte automatique, le dispositif émettra un signal auditif et visuel à l’utilisateur quelques secondes auparavant, afin de le prévenir l'émission du signal d’urgence, et de lui proposer de le désactiver sur simple pression d’un bouton, afin d’éviter les communications inutiles.

Également, le randonneur sera à même d'émettre volontairement un appel d’urgence à l’aide du bouton, ce qui permet à tout moment d’appeler de l’aide sans effort. Cela peut permettre également à appeler les secours pour une personne en danger qui ne porterait pas le dispositif.

L’appel au secours se représente par un envoi de coordonnées GPS aux secours, via une communication radio LoRa vers des bornes relais placées au préalables en montagne. Cette communication irait de relai de relai jusqu’au centre de sécurité, d’où le message serait transmis aux secours.

De plus, une application mobile verra le jour afin de connecter tous les utilisateurs du module de sécurité, de les visualiser sur une map, et de partager leurs données. En effet, à chaque incident, l’application mettra à jour la position et de la date de l’accident, afin de permettre aux prochains utilisateurs d’être prévenus. Ils pourraient, s'ils sont à proximité, d'assister la personne en détresse en attendant l'arrivée des secours. Bien évidemment, cette application ne sera accessible uniquement si le smartphone de l'utilisateur est relié à une connexion 4G ou Wi-Fi.

Cette prévention pourrait les sensibiliser aux risques de la montagne, leur permettre d’éviter le secteur mais aussi d’aider les personnes en danger si la distance le permet.

= Exigences =
== Fonctionnelles ==

*Batterie garantie fonctionnelle 1 semaine
*Rechargement possible via le panneau solaire portable
*Dispositif pouvant être allumé et éteint par l'utilisateur
*Alarme s’enclenche automatiquement dès qu'elle est considérée nécessaire, signal sonore
*Utilisateur a la possibilité d’activer/désactiver l’alarme quand il le souhaite
*Lorsque l’alarme est active, l’appareil ne peut s’éteindre
*...

== Non-Fonctionnelles ==

*Résistance : aux chocs, impacts, waterproof (utilisé en permanence en plein air)
*Disponibilité : Appareil de secours -> Doit être au plus possible performant
*Performance : Minimiser les pertes réseaux
*Accessible : Utilisateur pas forcément familier avec des appareils électroniques (facile d’utilisation)
*Fiabilité : Précision du GPS (rayon de 10m), données non-éronnées
*Coût : Le plus faible possible pour vendre le moins cher possible
*Efficacité : Réduire la consommation, utiliser le moins possible les ressources

= Composants =
== LoRaONE ==
Pour le coeur du projet, après avoir cherché et comparés plusieurs modules LoRa, GPS ou encore accéléromètres, nous avons finalement opté pour le projet LoRaONE.

LoRaONE est un projet de SODAQ regroupant plusieurs composants dans une seule et même carte, de taille réduite.

https://www.kickstarter.com/projects/sodaq/loraone-the-lora-iot-development-board

“The one IoT development board to rule them all” --SODAQ

Cette carte regroupe plusieurs capteurs afin de respecter aux mieux nos exigences :

Un émetteur/récepteur LoRa afin de pouvoir communiquer au mieux avec les antennes relai à longue distance

Un module + antenne GPS de bonne précision (< 10m) pour connaître en tout temps notre position, et ainsi faciliter l’arrivée des secours, ainsi que la recherche de l’individu en détresse

Un accéléromètre sur 3 axes afin de pouvoir détecter tout mouvement, vitesse ou rotation dans l’espace, ce qui permet la détection de chutes ou d’arrêt de mouvements

3 LED RGB afin de pouvoir signaler à l’utilisateur un manque de batterie, un signal d’urgence ou plus si nécessaire

Un bouton poussoir pour le signal d’alarme

Un connecteur de charge par panneau solaire, afin de faire durer chaque batterie le plus longtemps possible

Un connecteur micro-USB ainsi que des lignes pour se connecter à une base Arduino si besoin

[[File:LoRaOne.png||400px|Spécifications carte LoRaOne]]

De plus, grâce au starter pack, nous pouvons avoir accès à la base ONEBase qui nous permettrait d’étendre plus loin la facilité d’utilisation du produit :

[[File:LoRaOneBase.png||400px|Spécifications base LoRaOneBase]]

Comme nous pouvons le voir, cette base nous permettra de connecter la batterie ainsi que le panneau solaire qui sont fournis dans le pack.

Nous pourrons également connecter jusqu’à 4 modules supplémentaires.

La batterie fournie aura une capacité de 800 mAh, le panneau solaire fourni pouvant délivrer jusqu’à 500 mW de puissance.

Le total atteint une taille d’environ 10*5 cm, ce qui n’est pas excessif, ce qui le rend aisément portatif sur une jambe ou à la taille.

'''Coût : 115€'''

Ce module pourra également servir d’antenne relai, l'alimentation solaire devrait maintenir le dispositif chargé en permanence. Des tests seront effectués pour savoir si un panneau solaire plus puissant est requis.

== Boîtier ==

Le boîtier sécurisé devant respecter plusieurs exigences, nous pouvons le construire en plastique résistant, ce qui le rendrait léger tout en respectant une rigidité suffisante. Les antennes pourront être placées le long du boîtier, à l’intérieur si la connexion est suffisante, ou à l’extérieur. Dans ce dernier cas les trous réalisés sur le boîtier afin de laisser passer les câbles seront colmatés afin de garantir une étanchéité.

[[File:SchemaBoitier.png||100px|Schéma boitier d'alarme]]

== Balises ==

Afin de remonter les informations transmises par les boitiers, des balises seront mises en places sur la zone à couvrir, leur nombre et leur positions dépendra du terrain (obstacles, dénivelés). On distinguera deux types de balises. Tout d’abord, les balises racines qui permettront une communication GSM afin de faire remonter les données vers le serveur. Viennent ensuite les balises standard qui se contenteront de faire remonter vers leur balise racine associée. L’architecture de liaison des balises est détaillée dans une prochaine partie.

Chaque balise est composée d’une barre de fer pouvant être plantée dans le sol, d’un système de lest afin d’immobiliser la balise, d’un paratonnerre, d’un panneau solaire ainsi que d’un LoraOne et d’une batterie. Les balises racines seront équippée en plus d’un dispositif de communication GSM (téléphone portable, émetteur GSM).

[[File:SchemaBalise.png||150px|Schéma balises d'alarme]]

== Application mobile ==
Une application mobile est téléchargeable par les utilisateurs. Ils peuvent voir les autres utilisateurs présents dans leur zone. Lorsqu’un utilisateur est en position de danger, une notification apparaît si les utilisateurs sont proches de la situation de danger.

Cette application n’est pas directement reliée au dispositif. Elle ne fonctionne qu’avec la connexion du mobile, et est destinée à être un niveau de sécurité supérieur. Un randonneur proche d’une zone de danger pourrait arriver sur place plus rapidement que les secours.

= Communication =

Pour un envoi de position + numéro d’identification (X chiffres) :

*Temps de communication : < 2 s
*Communication régulière, intervalle de 15 minutes

On peut donc au maximum avoir 15 * 60 / 2 = 450 individus pouvant communiquer avec la même antenne relai, donc dans le même cercle d’environ 15 km de diamètre.

On communique donc au minimum 2 secondes sur 15 minutes, donc 1/450 << 1%, le temps de communication est respecté.

En cas de problème, nous pouvons envoyer jusqu’à 9x plus avec la borne sans dépasser le temps de communication autorisé (1%). Donc 1 envoi d’appel d’urgence toutes les 2 minutes environ.

La balise racine peut être directement connectée au serveur, dans ce cas, il n’y a pas de communication GSM nécessaire et pas de Gateway. Si la racine n’est pas directement connectée au serveur, elle devra au minimum garantir une communication GSM (ce qu’elle peut faire, il n’y a pas de Gateway nécessaire) pour remonter l’information vers le serveur, et donc la base de données.

GSM : Si Racine connectée à Serveur -> No GSM + Gateway
Else : GSM + Gateway : LoRa Racine connectée ordi (RaspberryPI) + ordi connecté GSM

= Stabilisation et gestion d’erreurs =

== Choix du routage ==

Notre réseau n'est pas un réseau traditionnel. Les seules communications existantes sont soit une remontée d'information vers la racine soit une innondation d'alerte vers les clients. Pour celà nous avons donc décidé d'utiliser un algorithme de routage simplifié basé uniquement sur un arbre en largeur des balises. Nous rajoutons en option la possibilité de créer plusieurs racines et donc plusieurs arbres dont les racines communiquent par gsm. Nous nous basons sur des papiers de recherches afin de déterminer quel algorithme auto-stabilisant est le plus adapté au système LoRa (Tel que le papier "A self-stabilizing algorithm for constructing breadth-first trees" par Shing-Tsaan Huang, Nian-Shing Chen).

== Stabilisation ==

Afin de gérer la communication de chaque message vers le serveur, nous allons prendre un noeud (balise LoRa) dit “racine” connecté directement au serveur, nous ne nous occuperons pas de la communication au serveur dans cet onglet. Chaque message reçu de la part d’un noeud du système doit être relayé jusqu’à la racine du système afin de communiquer avec les secours (ou serveur simplement).

Pour cela, il faudra assurer que chaque balise LoRa soit connecté au réseau, afin d’avoir au départ un graphe de communication connexe. Par dessus ce graphe, nous allons utiliser un processus silencieux auto-stabilisant qui construira un arbre de parcours en largeur, avec pour racine le noeud “racine” décidé ci-dessus.

Au lancement du système, il faut prévoir un léger temps de stabilisation, qui dépendrait de l’algorithme et de la taille du graphe (nombre de balises). Cependant, après cela, l’algorithme assure un arbre en profondeur minimal qui nous permettrai de communiquer avec la racine le plus rapidement possible, et donc une qualité de service maximale.

== Gestion d’erreurs ==

Dans un réseau comme celui-ci, plusieurs types d’erreurs peuvent se produire :
Délai de communication trop important vers une balise
“Crash” d’une balise de communication
Surpopulation d’une balise ou congestion de messages

Afin de palier au premier type d’incident rencontré, il faut nécessairement qu’à chaque emplacement dans la zone couverte, l’utilisateur soit à même de communiquer avec au minimum 2 balises différentes. Ainsi, dans le cas d’une communication trop longue sur une balise, l’autre aurait de grandes chances de délivrer le message plus rapidement.

Au niveau de la défaillance d’une balise, l’algorithme d’arbre en profondeur nous fournit déjà une solution intégrée grâce à son auto-stabilisation. Dans le cas de déconnexion d’une balise, l’algorithme mettrai à jour automatiquement l’arbre de communication, et n’importe quel message d’alerte émis serait délivré dans un délai raisonnable.

Pour le troisième cas d’erreur, il n’y aurait pas de solution réelle, si ce n’est de limiter le nombre de communications données, en ne prenant plus en compte les “ping” de chaque utilisateur mais seulement les messages d’alertes, ce qui permettrai une bien plus grande gestion de la congestion à un endroit donné. Également, une balise en dessous d’un lien congestionné pourrait communiquer avec ses autres voisins (non-fils dans l’arbre) afin de libérer de l’espace dans le lien avec son père dans l’arbre. Également, le système ne pourra accepter que jusqu’à 1000 utilisateurs par noeud, et également 4000 utilisateurs par cluster (dans le cas d’un réseau avec plusieurs clusters donc plusieurs racines cette limite augmente).

Plusieurs types de paquets circulent sur le réseau de balise:
Les pings, messages envoyés spontanéments à intervalle régulier par les utilisateur contenant l’id ainsi que les deux coordonées gps (27 bits chacun)
Les incidents, identique à un ping mais à priorité haute.
Les alertes, messages brodcastés par le serveur afin d’envoyer un message en chaine de caractères courts et compressés.

=Coûts matériels=

Que ce soit pour le dispositif utilisateur ou la balise (racine ou non), le LoRaOne correspond pour permettre les actions recherchées. Afin de réaliser un prototype pertinent, 6 kits LoRaOne sont requis. Ces kits sont accessibles sur le site de Sodaq au prix de 115€ chacun (prix variable).
Disponible [https://shop.sodaq.com/en/one-eu-rn2483-v2.html ici], voir avant dernier bundle : starter "ONE EU starter" actuellement à 112,10€.

Un [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer buzzer] est à ajouter au dispositif utilisateur afin de lui délivrer un signal sonore.

Un shield GSM est requis pour que la balise racine communique avec l'extérieur. Sodaq en propose un designé pour fonctionner sur leurs produits mais est éctuellement en rupture de stock. Un shield GSM arduino convient tout autant et peut être trouvé sur le site arduino [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna ici].

Aucun boitier ne sera commandé car nous avons fait le choix de les manufacturer nous même au fablab. Le besoin d'étanchéité n'est pas primordial pour notre prototype, bien que nous tenterons de l'assurer.

{|class="récap commande"
|+ Récapitulatif
|-
|
!scope="col" style="width: 320px;"| Produit
!scope="col" style="width: 80px;"| Lien
!scope="col" style="width: 80px;"| Quantité
!scope="col" style="width: 80px;"| Prix Unitaire
|-

!scope="row"| 1
| LoRaOne EU Starter
| [https://shop.sodaq.com/en/one-eu-rn2483-v2.html Achat]
| 6
| 115€
|-

!scope="row"| 2
| Buzzer
| [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer Achat]
| 3
| 5.49€
|-

!scope="row"| 3
| Shield GSM
| [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna Achat]
| 1
| 65€
|-

|}

=Développement=

Nous utiliserons les librairies standards Arduino ainsi que celle de SODAQ/Arduino pour le LoRa.

L'IDE Arduino sera utilisé, plus pratique pour l'utilisation de Git (comparé à Mbed).

= Mise sur le marché =

Ce dispositif a pour but d’être utilisé en montagne, lors de randonnée. Il n’est pas destiné à un usage quotidien, c’est pourquoi nous considérons qu’il est plus judicieux de louer les dispositifs plutôt que de les vendre, même si l’achat n’est pas à omettre de notre stratégie.

Le dispositif peut être commandé en ligne, puis retourné par la poste après usage. Le client louerait le dispositif pour une certaine durée avec un possible nombre supplémentaire de batterie. Les tarifs varient en fonction de la durée et du nombre de batteries louées. Des offres de groupes pourraient être applicables. A long terme, des boutiques pourraient être disséminées dans des grandes villes proches des zones montagneuses, zones à randonnées (Grenoble, Annecy, etc.).

L’application est téléchargeable gratuitement par quiconque, mais utilisable seulement par les clients. Un code d’accès sera envoyé avec le dispositif expirant après la fin de la location.

Il faudra tenir compte de la bande passante du LoRa, variante en fonction des continents.

=Planning=

Sprint 1 : 29/01 --> 09/02 : Création du prototype logiciel #1
*Prise en main du matériel
*Premiers tests de transmissions LoRa
*Création du protocole d'architecture des balises
*Application sur les cartes et tests
*Tests de performances des cartes (durabilité, chargement, batterie)
*Tests de maintenabilité de l'algorithme (déconnexions, latences)

Sprint 2 : 12/02 --> 23/02 : Prototype logiciel #2 et prototype matériel
*Création du programme embarqué (utilisateur)
*Communication avec la racine et le serveur
*Création des maquettes boîtier et balise
*Construction des maquettes
*Finalisation du premier prototype

Sprint 3 : 26/02 --> 09/03 : Fonctionnalités supplémentaires
*Ajout de la communication entre le LoRa et le GSM sur la balise racine
*Création application mobile utilisateur
*Tests sur l'application
*Tests sur la transmission totale depuis l'utilisateur vers le serveur via le GSM
*Finalisation du projet

Sprint 4 : 12/03 --> 16/03 : Fin du projet
*Création de la documentation finale (à partir de la documentation réalisée en continu)
*Pause café
*Temps supplémentaire en cas de problèmes importants
*Préparation de la soutenance

R'Montagne

2018-02-12T10:05:34Z

Hugo.Amodru-Favin: /* Journal */

=Présentation du projet=

==Équipe==
{|class="wikitable"
|-
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Rôle
|-
| Hugo Amodru-Favin
| Chef de Projet
|-
| Antoine Delise
| Lead Developer
|-
| Gwenaël Moreau
| Kanban Master
|-

|}

==Tâches==

Répartition générale des tâches
{|class="wikitable"
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Tâche
|-
| Hugo Amodru-Favin
| Application Ionic
|-
| Antoine Delise
| Développement Arduino
|-
| Gwenaël Moreau
| BDD - API
|-

|}

Détail des tâches : [https://waffle.io/delisea/R-Montagne Lien Waffle.io]

==Journal==

{|class="wikitable"
|+
|-
|
!scope="col"| Date
!scope="col"| Hugo AMODRU-FAVIN
!scope="col"| Antoine DELISE
!scope="col"| Gwenaël MOREAU
|-

| colspan="5" style="text-align: center; background-color:#1c531c;"| SPRINT 1
|-

|-
| rowspan="2" | Lundi 29/01/18
| rowspan="1" | Tâches
| style="width: 225px;" |
* efoed
| style="width: 225px;" |
* sidfjeso
| style="width: 225px;" |
* zdokz
|-
|}

==Randonnée et risques==

Ouvert à tous, la randonnée est un sport et un loisir qui prend de plus en plus d’ampleur de nos jours. Ne nécessitant pas de grands prérequis, des milliers de personnes se lancent en montagne chaque jour, malheureusement parfois sans connaître toutes les mesures de sécurité associées.

En effet, de janvier à juin 2016, en randonnée et en alpinisme, l’Association Nationale pour l’Étude de la Neige et des Avalanches (ANENA) a comptabilisé 21 accidents notables, dont 8 accidents mortels, impliquant 15 décès.

Aujourd’hui, les mesures de sécurités préconisent que chaque groupe de randonneur se doivent de se munir d’un téléphone portable afin d’appeler les secours en cas de problème. Malheureusement, la communication mobile dépendant de la couverture réseau, peu présente en montagne, l’impossibilité de joindre les secours reste un problème.

==Solutions existantes==

La solution la plus répandue, est celle du téléphone à connexion satellite. Ayant une communication vers les satellites, cela permet une couverture réseau beaucoup plus répandue dans les montagnes, partout dans le monde (ou presque). Cependant, les téléphones portables satellitaires coûtent chers, et ne sont pas forcément abordables par la plupart des personnes, surtout celles ne sortant qu’occasionnellement.

[https://fall-alarm.net/ Fall Alarm] est un système de détection de chute sur chantier utilisant les mêmes technologies dont nous avons besoin pour notre projet.

==Quelles zones géographiques ?==

Toutes les zones montagneuses peuvent présenter des zones blanches, démunies de connexion quelconque autre que les connexions satellitaires. Certaines chaînes de montagne comme la Cordillaire des Andes ne présentent aucune connexion possible quelconque.

Dans le cadre de notre projet, nous fonctionnerons essentiellement dans la localisation grenobloise avec l'objectif que notre solution soit applicable partout dans le monde. Une contrainte intervient tout de même étant donnée que la fréquence d'utilisation du LoRa en Europe est de 868MHz, 915MHz en Amérique et 433MHz en Asie.

= Fonctionnalités =

Afin de remplir au mieux ses attentes, le principal objectif de ce dispositif sera premièrement de pouvoir communiquer avec les secours à n’importe quel moment, et surtout n’importe où. De plus, il sera capable de détecter de nombreux cas de détresse de la part de l’usager afin de pouvoir lancer un appel d’urgence sans interaction avec l’usager, au cas où il serait inconscient, ou incapable de lancer un appel manuel.

Grâce aux accéléromètres, le dispositif sera à même de détecter un mouvement brutal du randonneur, ce qui pourrait s’apparenter à une chute. Ils pourront également détecter une position anormale, ou une immobilité prolongée, ce qui déclencherait le dispositif d’urgence automatiquement.

Grâce à des tests réalisés au préalable, le boîtier pourra détecter correctement les chûtes de simples mouvements, afin de ne pas lancer l’appel sans raison valable.

Avant de lancer une alerte automatique, le dispositif émettra un signal auditif et visuel à l’utilisateur quelques secondes auparavant, afin de le prévenir l'émission du signal d’urgence, et de lui proposer de le désactiver sur simple pression d’un bouton, afin d’éviter les communications inutiles.

Également, le randonneur sera à même d'émettre volontairement un appel d’urgence à l’aide du bouton, ce qui permet à tout moment d’appeler de l’aide sans effort. Cela peut permettre également à appeler les secours pour une personne en danger qui ne porterait pas le dispositif.

L’appel au secours se représente par un envoi de coordonnées GPS aux secours, via une communication radio LoRa vers des bornes relais placées au préalables en montagne. Cette communication irait de relai de relai jusqu’au centre de sécurité, d’où le message serait transmis aux secours.

De plus, une application mobile verra le jour afin de connecter tous les utilisateurs du module de sécurité, de les visualiser sur une map, et de partager leurs données. En effet, à chaque incident, l’application mettra à jour la position et de la date de l’accident, afin de permettre aux prochains utilisateurs d’être prévenus. Ils pourraient, s'ils sont à proximité, d'assister la personne en détresse en attendant l'arrivée des secours. Bien évidemment, cette application ne sera accessible uniquement si le smartphone de l'utilisateur est relié à une connexion 4G ou Wi-Fi.

Cette prévention pourrait les sensibiliser aux risques de la montagne, leur permettre d’éviter le secteur mais aussi d’aider les personnes en danger si la distance le permet.

= Exigences =
== Fonctionnelles ==

*Batterie garantie fonctionnelle 1 semaine
*Rechargement possible via le panneau solaire portable
*Dispositif pouvant être allumé et éteint par l'utilisateur
*Alarme s’enclenche automatiquement dès qu'elle est considérée nécessaire, signal sonore
*Utilisateur a la possibilité d’activer/désactiver l’alarme quand il le souhaite
*Lorsque l’alarme est active, l’appareil ne peut s’éteindre
*...

== Non-Fonctionnelles ==

*Résistance : aux chocs, impacts, waterproof (utilisé en permanence en plein air)
*Disponibilité : Appareil de secours -> Doit être au plus possible performant
*Performance : Minimiser les pertes réseaux
*Accessible : Utilisateur pas forcément familier avec des appareils électroniques (facile d’utilisation)
*Fiabilité : Précision du GPS (rayon de 10m), données non-éronnées
*Coût : Le plus faible possible pour vendre le moins cher possible
*Efficacité : Réduire la consommation, utiliser le moins possible les ressources

= Composants =
== LoRaONE ==
Pour le coeur du projet, après avoir cherché et comparés plusieurs modules LoRa, GPS ou encore accéléromètres, nous avons finalement opté pour le projet LoRaONE.

LoRaONE est un projet de SODAQ regroupant plusieurs composants dans une seule et même carte, de taille réduite.

https://www.kickstarter.com/projects/sodaq/loraone-the-lora-iot-development-board

“The one IoT development board to rule them all” --SODAQ

Cette carte regroupe plusieurs capteurs afin de respecter aux mieux nos exigences :

Un émetteur/récepteur LoRa afin de pouvoir communiquer au mieux avec les antennes relai à longue distance

Un module + antenne GPS de bonne précision (< 10m) pour connaître en tout temps notre position, et ainsi faciliter l’arrivée des secours, ainsi que la recherche de l’individu en détresse

Un accéléromètre sur 3 axes afin de pouvoir détecter tout mouvement, vitesse ou rotation dans l’espace, ce qui permet la détection de chutes ou d’arrêt de mouvements

3 LED RGB afin de pouvoir signaler à l’utilisateur un manque de batterie, un signal d’urgence ou plus si nécessaire

Un bouton poussoir pour le signal d’alarme

Un connecteur de charge par panneau solaire, afin de faire durer chaque batterie le plus longtemps possible

Un connecteur micro-USB ainsi que des lignes pour se connecter à une base Arduino si besoin

[[File:LoRaOne.png||400px|Spécifications carte LoRaOne]]

De plus, grâce au starter pack, nous pouvons avoir accès à la base ONEBase qui nous permettrait d’étendre plus loin la facilité d’utilisation du produit :

[[File:LoRaOneBase.png||400px|Spécifications base LoRaOneBase]]

Comme nous pouvons le voir, cette base nous permettra de connecter la batterie ainsi que le panneau solaire qui sont fournis dans le pack.

Nous pourrons également connecter jusqu’à 4 modules supplémentaires.

La batterie fournie aura une capacité de 800 mAh, le panneau solaire fourni pouvant délivrer jusqu’à 500 mW de puissance.

Le total atteint une taille d’environ 10*5 cm, ce qui n’est pas excessif, ce qui le rend aisément portatif sur une jambe ou à la taille.

'''Coût : 115€'''

Ce module pourra également servir d’antenne relai, l'alimentation solaire devrait maintenir le dispositif chargé en permanence. Des tests seront effectués pour savoir si un panneau solaire plus puissant est requis.

== Boîtier ==

Le boîtier sécurisé devant respecter plusieurs exigences, nous pouvons le construire en plastique résistant, ce qui le rendrait léger tout en respectant une rigidité suffisante. Les antennes pourront être placées le long du boîtier, à l’intérieur si la connexion est suffisante, ou à l’extérieur. Dans ce dernier cas les trous réalisés sur le boîtier afin de laisser passer les câbles seront colmatés afin de garantir une étanchéité.

[[File:SchemaBoitier.png||100px|Schéma boitier d'alarme]]

== Balises ==

Afin de remonter les informations transmises par les boitiers, des balises seront mises en places sur la zone à couvrir, leur nombre et leur positions dépendra du terrain (obstacles, dénivelés). On distinguera deux types de balises. Tout d’abord, les balises racines qui permettront une communication GSM afin de faire remonter les données vers le serveur. Viennent ensuite les balises standard qui se contenteront de faire remonter vers leur balise racine associée. L’architecture de liaison des balises est détaillée dans une prochaine partie.

Chaque balise est composée d’une barre de fer pouvant être plantée dans le sol, d’un système de lest afin d’immobiliser la balise, d’un paratonnerre, d’un panneau solaire ainsi que d’un LoraOne et d’une batterie. Les balises racines seront équippée en plus d’un dispositif de communication GSM (téléphone portable, émetteur GSM).

[[File:SchemaBalise.png||150px|Schéma balises d'alarme]]

== Application mobile ==
Une application mobile est téléchargeable par les utilisateurs. Ils peuvent voir les autres utilisateurs présents dans leur zone. Lorsqu’un utilisateur est en position de danger, une notification apparaît si les utilisateurs sont proches de la situation de danger.

Cette application n’est pas directement reliée au dispositif. Elle ne fonctionne qu’avec la connexion du mobile, et est destinée à être un niveau de sécurité supérieur. Un randonneur proche d’une zone de danger pourrait arriver sur place plus rapidement que les secours.

= Communication =

Pour un envoi de position + numéro d’identification (X chiffres) :

*Temps de communication : < 2 s
*Communication régulière, intervalle de 15 minutes

On peut donc au maximum avoir 15 * 60 / 2 = 450 individus pouvant communiquer avec la même antenne relai, donc dans le même cercle d’environ 15 km de diamètre.

On communique donc au minimum 2 secondes sur 15 minutes, donc 1/450 << 1%, le temps de communication est respecté.

En cas de problème, nous pouvons envoyer jusqu’à 9x plus avec la borne sans dépasser le temps de communication autorisé (1%). Donc 1 envoi d’appel d’urgence toutes les 2 minutes environ.

La balise racine peut être directement connectée au serveur, dans ce cas, il n’y a pas de communication GSM nécessaire et pas de Gateway. Si la racine n’est pas directement connectée au serveur, elle devra au minimum garantir une communication GSM (ce qu’elle peut faire, il n’y a pas de Gateway nécessaire) pour remonter l’information vers le serveur, et donc la base de données.

GSM : Si Racine connectée à Serveur -> No GSM + Gateway
Else : GSM + Gateway : LoRa Racine connectée ordi (RaspberryPI) + ordi connecté GSM

= Stabilisation et gestion d’erreurs =

== Choix du routage ==

Notre réseau n'est pas un réseau traditionnel. Les seules communications existantes sont soit une remontée d'information vers la racine soit une innondation d'alerte vers les clients. Pour celà nous avons donc décidé d'utiliser un algorithme de routage simplifié basé uniquement sur un arbre en largeur des balises. Nous rajoutons en option la possibilité de créer plusieurs racines et donc plusieurs arbres dont les racines communiquent par gsm. Nous nous basons sur des papiers de recherches afin de déterminer quel algorithme auto-stabilisant est le plus adapté au système LoRa (Tel que le papier "A self-stabilizing algorithm for constructing breadth-first trees" par Shing-Tsaan Huang, Nian-Shing Chen).

== Stabilisation ==

Afin de gérer la communication de chaque message vers le serveur, nous allons prendre un noeud (balise LoRa) dit “racine” connecté directement au serveur, nous ne nous occuperons pas de la communication au serveur dans cet onglet. Chaque message reçu de la part d’un noeud du système doit être relayé jusqu’à la racine du système afin de communiquer avec les secours (ou serveur simplement).

Pour cela, il faudra assurer que chaque balise LoRa soit connecté au réseau, afin d’avoir au départ un graphe de communication connexe. Par dessus ce graphe, nous allons utiliser un processus silencieux auto-stabilisant qui construira un arbre de parcours en largeur, avec pour racine le noeud “racine” décidé ci-dessus.

Au lancement du système, il faut prévoir un léger temps de stabilisation, qui dépendrait de l’algorithme et de la taille du graphe (nombre de balises). Cependant, après cela, l’algorithme assure un arbre en profondeur minimal qui nous permettrai de communiquer avec la racine le plus rapidement possible, et donc une qualité de service maximale.

== Gestion d’erreurs ==

Dans un réseau comme celui-ci, plusieurs types d’erreurs peuvent se produire :
Délai de communication trop important vers une balise
“Crash” d’une balise de communication
Surpopulation d’une balise ou congestion de messages

Afin de palier au premier type d’incident rencontré, il faut nécessairement qu’à chaque emplacement dans la zone couverte, l’utilisateur soit à même de communiquer avec au minimum 2 balises différentes. Ainsi, dans le cas d’une communication trop longue sur une balise, l’autre aurait de grandes chances de délivrer le message plus rapidement.

Au niveau de la défaillance d’une balise, l’algorithme d’arbre en profondeur nous fournit déjà une solution intégrée grâce à son auto-stabilisation. Dans le cas de déconnexion d’une balise, l’algorithme mettrai à jour automatiquement l’arbre de communication, et n’importe quel message d’alerte émis serait délivré dans un délai raisonnable.

Pour le troisième cas d’erreur, il n’y aurait pas de solution réelle, si ce n’est de limiter le nombre de communications données, en ne prenant plus en compte les “ping” de chaque utilisateur mais seulement les messages d’alertes, ce qui permettrai une bien plus grande gestion de la congestion à un endroit donné. Également, une balise en dessous d’un lien congestionné pourrait communiquer avec ses autres voisins (non-fils dans l’arbre) afin de libérer de l’espace dans le lien avec son père dans l’arbre. Également, le système ne pourra accepter que jusqu’à 1000 utilisateurs par noeud, et également 4000 utilisateurs par cluster (dans le cas d’un réseau avec plusieurs clusters donc plusieurs racines cette limite augmente).

Plusieurs types de paquets circulent sur le réseau de balise:
Les pings, messages envoyés spontanéments à intervalle régulier par les utilisateur contenant l’id ainsi que les deux coordonées gps (27 bits chacun)
Les incidents, identique à un ping mais à priorité haute.
Les alertes, messages brodcastés par le serveur afin d’envoyer un message en chaine de caractères courts et compressés.

=Coûts matériels=

Que ce soit pour le dispositif utilisateur ou la balise (racine ou non), le LoRaOne correspond pour permettre les actions recherchées. Afin de réaliser un prototype pertinent, 6 kits LoRaOne sont requis. Ces kits sont accessibles sur le site de Sodaq au prix de 115€ chacun (prix variable).
Disponible [https://shop.sodaq.com/en/one-eu-rn2483-v2.html ici], voir avant dernier bundle : starter "ONE EU starter" actuellement à 112,10€.

Un [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer buzzer] est à ajouter au dispositif utilisateur afin de lui délivrer un signal sonore.

Un shield GSM est requis pour que la balise racine communique avec l'extérieur. Sodaq en propose un designé pour fonctionner sur leurs produits mais est éctuellement en rupture de stock. Un shield GSM arduino convient tout autant et peut être trouvé sur le site arduino [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna ici].

Aucun boitier ne sera commandé car nous avons fait le choix de les manufacturer nous même au fablab. Le besoin d'étanchéité n'est pas primordial pour notre prototype, bien que nous tenterons de l'assurer.

{|class="récap commande"
|+ Récapitulatif
|-
|
!scope="col" style="width: 320px;"| Produit
!scope="col" style="width: 80px;"| Lien
!scope="col" style="width: 80px;"| Quantité
!scope="col" style="width: 80px;"| Prix Unitaire
|-

!scope="row"| 1
| LoRaOne EU Starter
| [https://shop.sodaq.com/en/one-eu-rn2483-v2.html Achat]
| 6
| 115€
|-

!scope="row"| 2
| Buzzer
| [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer Achat]
| 3
| 5.49€
|-

!scope="row"| 3
| Shield GSM
| [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna Achat]
| 1
| 65€
|-

|}

=Développement=

Nous utiliserons les librairies standards Arduino ainsi que celle de SODAQ/Arduino pour le LoRa.

L'IDE Arduino sera utilisé, plus pratique pour l'utilisation de Git (comparé à Mbed).

= Mise sur le marché =

Ce dispositif a pour but d’être utilisé en montagne, lors de randonnée. Il n’est pas destiné à un usage quotidien, c’est pourquoi nous considérons qu’il est plus judicieux de louer les dispositifs plutôt que de les vendre, même si l’achat n’est pas à omettre de notre stratégie.

Le dispositif peut être commandé en ligne, puis retourné par la poste après usage. Le client louerait le dispositif pour une certaine durée avec un possible nombre supplémentaire de batterie. Les tarifs varient en fonction de la durée et du nombre de batteries louées. Des offres de groupes pourraient être applicables. A long terme, des boutiques pourraient être disséminées dans des grandes villes proches des zones montagneuses, zones à randonnées (Grenoble, Annecy, etc.).

L’application est téléchargeable gratuitement par quiconque, mais utilisable seulement par les clients. Un code d’accès sera envoyé avec le dispositif expirant après la fin de la location.

Il faudra tenir compte de la bande passante du LoRa, variante en fonction des continents.

=Planning=

Sprint 1 : 29/01 --> 09/02 : Création du prototype logiciel #1
*Prise en main du matériel
*Premiers tests de transmissions LoRa
*Création du protocole d'architecture des balises
*Application sur les cartes et tests
*Tests de performances des cartes (durabilité, chargement, batterie)
*Tests de maintenabilité de l'algorithme (déconnexions, latences)

Sprint 2 : 12/02 --> 23/02 : Prototype logiciel #2 et prototype matériel
*Création du programme embarqué (utilisateur)
*Communication avec la racine et le serveur
*Création des maquettes boîtier et balise
*Construction des maquettes
*Finalisation du premier prototype

Sprint 3 : 26/02 --> 09/03 : Fonctionnalités supplémentaires
*Ajout de la communication entre le LoRa et le GSM sur la balise racine
*Création application mobile utilisateur
*Tests sur l'application
*Tests sur la transmission totale depuis l'utilisateur vers le serveur via le GSM
*Finalisation du projet

Sprint 4 : 12/03 --> 16/03 : Fin du projet
*Création de la documentation finale (à partir de la documentation réalisée en continu)
*Pause café
*Temps supplémentaire en cas de problèmes importants
*Préparation de la soutenance

R'Montagne

2018-02-12T10:05:27Z

Hugo.Amodru-Favin: /* Journal */

=Présentation du projet=

==Équipe==
{|class="wikitable"
|-
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Rôle
|-
| Hugo Amodru-Favin
| Chef de Projet
|-
| Antoine Delise
| Lead Developer
|-
| Gwenaël Moreau
| Kanban Master
|-

|}

==Tâches==

Répartition générale des tâches
{|class="wikitable"
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Tâche
|-
| Hugo Amodru-Favin
| Application Ionic
|-
| Antoine Delise
| Développement Arduino
|-
| Gwenaël Moreau
| BDD - API
|-

|}

Détail des tâches : [https://waffle.io/delisea/R-Montagne Lien Waffle.io]

==Journal==

{|class="wikitable"
|+
|-
|
!scope="col"| Date
!scope="col"| Hugo AMODRU-FAVIN
!scope="col"| Antoine DELISE
!scope="col"| Gwenaël MOREAU
|-

| colspan="5" style="text-align: center; background-color:#1c531c;"| SPRINT 1
|-

|-
| rowspan="2" | Lundi 29/01/18
| rowspan="1" | Tâches
| style="width: 225px;" |
* efoed
| style="width: 225px;" |
* sidfjeso
| style="width: 225px;" |
* zdokz
|-
|}

==Randonnée et risques==

Ouvert à tous, la randonnée est un sport et un loisir qui prend de plus en plus d’ampleur de nos jours. Ne nécessitant pas de grands prérequis, des milliers de personnes se lancent en montagne chaque jour, malheureusement parfois sans connaître toutes les mesures de sécurité associées.

En effet, de janvier à juin 2016, en randonnée et en alpinisme, l’Association Nationale pour l’Étude de la Neige et des Avalanches (ANENA) a comptabilisé 21 accidents notables, dont 8 accidents mortels, impliquant 15 décès.

Aujourd’hui, les mesures de sécurités préconisent que chaque groupe de randonneur se doivent de se munir d’un téléphone portable afin d’appeler les secours en cas de problème. Malheureusement, la communication mobile dépendant de la couverture réseau, peu présente en montagne, l’impossibilité de joindre les secours reste un problème.

==Solutions existantes==

La solution la plus répandue, est celle du téléphone à connexion satellite. Ayant une communication vers les satellites, cela permet une couverture réseau beaucoup plus répandue dans les montagnes, partout dans le monde (ou presque). Cependant, les téléphones portables satellitaires coûtent chers, et ne sont pas forcément abordables par la plupart des personnes, surtout celles ne sortant qu’occasionnellement.

[https://fall-alarm.net/ Fall Alarm] est un système de détection de chute sur chantier utilisant les mêmes technologies dont nous avons besoin pour notre projet.

==Quelles zones géographiques ?==

Toutes les zones montagneuses peuvent présenter des zones blanches, démunies de connexion quelconque autre que les connexions satellitaires. Certaines chaînes de montagne comme la Cordillaire des Andes ne présentent aucune connexion possible quelconque.

Dans le cadre de notre projet, nous fonctionnerons essentiellement dans la localisation grenobloise avec l'objectif que notre solution soit applicable partout dans le monde. Une contrainte intervient tout de même étant donnée que la fréquence d'utilisation du LoRa en Europe est de 868MHz, 915MHz en Amérique et 433MHz en Asie.

= Fonctionnalités =

Afin de remplir au mieux ses attentes, le principal objectif de ce dispositif sera premièrement de pouvoir communiquer avec les secours à n’importe quel moment, et surtout n’importe où. De plus, il sera capable de détecter de nombreux cas de détresse de la part de l’usager afin de pouvoir lancer un appel d’urgence sans interaction avec l’usager, au cas où il serait inconscient, ou incapable de lancer un appel manuel.

Grâce aux accéléromètres, le dispositif sera à même de détecter un mouvement brutal du randonneur, ce qui pourrait s’apparenter à une chute. Ils pourront également détecter une position anormale, ou une immobilité prolongée, ce qui déclencherait le dispositif d’urgence automatiquement.

Grâce à des tests réalisés au préalable, le boîtier pourra détecter correctement les chûtes de simples mouvements, afin de ne pas lancer l’appel sans raison valable.

Avant de lancer une alerte automatique, le dispositif émettra un signal auditif et visuel à l’utilisateur quelques secondes auparavant, afin de le prévenir l'émission du signal d’urgence, et de lui proposer de le désactiver sur simple pression d’un bouton, afin d’éviter les communications inutiles.

Également, le randonneur sera à même d'émettre volontairement un appel d’urgence à l’aide du bouton, ce qui permet à tout moment d’appeler de l’aide sans effort. Cela peut permettre également à appeler les secours pour une personne en danger qui ne porterait pas le dispositif.

L’appel au secours se représente par un envoi de coordonnées GPS aux secours, via une communication radio LoRa vers des bornes relais placées au préalables en montagne. Cette communication irait de relai de relai jusqu’au centre de sécurité, d’où le message serait transmis aux secours.

De plus, une application mobile verra le jour afin de connecter tous les utilisateurs du module de sécurité, de les visualiser sur une map, et de partager leurs données. En effet, à chaque incident, l’application mettra à jour la position et de la date de l’accident, afin de permettre aux prochains utilisateurs d’être prévenus. Ils pourraient, s'ils sont à proximité, d'assister la personne en détresse en attendant l'arrivée des secours. Bien évidemment, cette application ne sera accessible uniquement si le smartphone de l'utilisateur est relié à une connexion 4G ou Wi-Fi.

Cette prévention pourrait les sensibiliser aux risques de la montagne, leur permettre d’éviter le secteur mais aussi d’aider les personnes en danger si la distance le permet.

= Exigences =
== Fonctionnelles ==

*Batterie garantie fonctionnelle 1 semaine
*Rechargement possible via le panneau solaire portable
*Dispositif pouvant être allumé et éteint par l'utilisateur
*Alarme s’enclenche automatiquement dès qu'elle est considérée nécessaire, signal sonore
*Utilisateur a la possibilité d’activer/désactiver l’alarme quand il le souhaite
*Lorsque l’alarme est active, l’appareil ne peut s’éteindre
*...

== Non-Fonctionnelles ==

*Résistance : aux chocs, impacts, waterproof (utilisé en permanence en plein air)
*Disponibilité : Appareil de secours -> Doit être au plus possible performant
*Performance : Minimiser les pertes réseaux
*Accessible : Utilisateur pas forcément familier avec des appareils électroniques (facile d’utilisation)
*Fiabilité : Précision du GPS (rayon de 10m), données non-éronnées
*Coût : Le plus faible possible pour vendre le moins cher possible
*Efficacité : Réduire la consommation, utiliser le moins possible les ressources

= Composants =
== LoRaONE ==
Pour le coeur du projet, après avoir cherché et comparés plusieurs modules LoRa, GPS ou encore accéléromètres, nous avons finalement opté pour le projet LoRaONE.

LoRaONE est un projet de SODAQ regroupant plusieurs composants dans une seule et même carte, de taille réduite.

https://www.kickstarter.com/projects/sodaq/loraone-the-lora-iot-development-board

“The one IoT development board to rule them all” --SODAQ

Cette carte regroupe plusieurs capteurs afin de respecter aux mieux nos exigences :

Un émetteur/récepteur LoRa afin de pouvoir communiquer au mieux avec les antennes relai à longue distance

Un module + antenne GPS de bonne précision (< 10m) pour connaître en tout temps notre position, et ainsi faciliter l’arrivée des secours, ainsi que la recherche de l’individu en détresse

Un accéléromètre sur 3 axes afin de pouvoir détecter tout mouvement, vitesse ou rotation dans l’espace, ce qui permet la détection de chutes ou d’arrêt de mouvements

3 LED RGB afin de pouvoir signaler à l’utilisateur un manque de batterie, un signal d’urgence ou plus si nécessaire

Un bouton poussoir pour le signal d’alarme

Un connecteur de charge par panneau solaire, afin de faire durer chaque batterie le plus longtemps possible

Un connecteur micro-USB ainsi que des lignes pour se connecter à une base Arduino si besoin

[[File:LoRaOne.png||400px|Spécifications carte LoRaOne]]

De plus, grâce au starter pack, nous pouvons avoir accès à la base ONEBase qui nous permettrait d’étendre plus loin la facilité d’utilisation du produit :

[[File:LoRaOneBase.png||400px|Spécifications base LoRaOneBase]]

Comme nous pouvons le voir, cette base nous permettra de connecter la batterie ainsi que le panneau solaire qui sont fournis dans le pack.

Nous pourrons également connecter jusqu’à 4 modules supplémentaires.

La batterie fournie aura une capacité de 800 mAh, le panneau solaire fourni pouvant délivrer jusqu’à 500 mW de puissance.

Le total atteint une taille d’environ 10*5 cm, ce qui n’est pas excessif, ce qui le rend aisément portatif sur une jambe ou à la taille.

'''Coût : 115€'''

Ce module pourra également servir d’antenne relai, l'alimentation solaire devrait maintenir le dispositif chargé en permanence. Des tests seront effectués pour savoir si un panneau solaire plus puissant est requis.

== Boîtier ==

Le boîtier sécurisé devant respecter plusieurs exigences, nous pouvons le construire en plastique résistant, ce qui le rendrait léger tout en respectant une rigidité suffisante. Les antennes pourront être placées le long du boîtier, à l’intérieur si la connexion est suffisante, ou à l’extérieur. Dans ce dernier cas les trous réalisés sur le boîtier afin de laisser passer les câbles seront colmatés afin de garantir une étanchéité.

[[File:SchemaBoitier.png||100px|Schéma boitier d'alarme]]

== Balises ==

Afin de remonter les informations transmises par les boitiers, des balises seront mises en places sur la zone à couvrir, leur nombre et leur positions dépendra du terrain (obstacles, dénivelés). On distinguera deux types de balises. Tout d’abord, les balises racines qui permettront une communication GSM afin de faire remonter les données vers le serveur. Viennent ensuite les balises standard qui se contenteront de faire remonter vers leur balise racine associée. L’architecture de liaison des balises est détaillée dans une prochaine partie.

Chaque balise est composée d’une barre de fer pouvant être plantée dans le sol, d’un système de lest afin d’immobiliser la balise, d’un paratonnerre, d’un panneau solaire ainsi que d’un LoraOne et d’une batterie. Les balises racines seront équippée en plus d’un dispositif de communication GSM (téléphone portable, émetteur GSM).

[[File:SchemaBalise.png||150px|Schéma balises d'alarme]]

== Application mobile ==
Une application mobile est téléchargeable par les utilisateurs. Ils peuvent voir les autres utilisateurs présents dans leur zone. Lorsqu’un utilisateur est en position de danger, une notification apparaît si les utilisateurs sont proches de la situation de danger.

Cette application n’est pas directement reliée au dispositif. Elle ne fonctionne qu’avec la connexion du mobile, et est destinée à être un niveau de sécurité supérieur. Un randonneur proche d’une zone de danger pourrait arriver sur place plus rapidement que les secours.

= Communication =

Pour un envoi de position + numéro d’identification (X chiffres) :

*Temps de communication : < 2 s
*Communication régulière, intervalle de 15 minutes

On peut donc au maximum avoir 15 * 60 / 2 = 450 individus pouvant communiquer avec la même antenne relai, donc dans le même cercle d’environ 15 km de diamètre.

On communique donc au minimum 2 secondes sur 15 minutes, donc 1/450 << 1%, le temps de communication est respecté.

En cas de problème, nous pouvons envoyer jusqu’à 9x plus avec la borne sans dépasser le temps de communication autorisé (1%). Donc 1 envoi d’appel d’urgence toutes les 2 minutes environ.

La balise racine peut être directement connectée au serveur, dans ce cas, il n’y a pas de communication GSM nécessaire et pas de Gateway. Si la racine n’est pas directement connectée au serveur, elle devra au minimum garantir une communication GSM (ce qu’elle peut faire, il n’y a pas de Gateway nécessaire) pour remonter l’information vers le serveur, et donc la base de données.

GSM : Si Racine connectée à Serveur -> No GSM + Gateway
Else : GSM + Gateway : LoRa Racine connectée ordi (RaspberryPI) + ordi connecté GSM

= Stabilisation et gestion d’erreurs =

== Choix du routage ==

Notre réseau n'est pas un réseau traditionnel. Les seules communications existantes sont soit une remontée d'information vers la racine soit une innondation d'alerte vers les clients. Pour celà nous avons donc décidé d'utiliser un algorithme de routage simplifié basé uniquement sur un arbre en largeur des balises. Nous rajoutons en option la possibilité de créer plusieurs racines et donc plusieurs arbres dont les racines communiquent par gsm. Nous nous basons sur des papiers de recherches afin de déterminer quel algorithme auto-stabilisant est le plus adapté au système LoRa (Tel que le papier "A self-stabilizing algorithm for constructing breadth-first trees" par Shing-Tsaan Huang, Nian-Shing Chen).

== Stabilisation ==

Afin de gérer la communication de chaque message vers le serveur, nous allons prendre un noeud (balise LoRa) dit “racine” connecté directement au serveur, nous ne nous occuperons pas de la communication au serveur dans cet onglet. Chaque message reçu de la part d’un noeud du système doit être relayé jusqu’à la racine du système afin de communiquer avec les secours (ou serveur simplement).

Pour cela, il faudra assurer que chaque balise LoRa soit connecté au réseau, afin d’avoir au départ un graphe de communication connexe. Par dessus ce graphe, nous allons utiliser un processus silencieux auto-stabilisant qui construira un arbre de parcours en largeur, avec pour racine le noeud “racine” décidé ci-dessus.

Au lancement du système, il faut prévoir un léger temps de stabilisation, qui dépendrait de l’algorithme et de la taille du graphe (nombre de balises). Cependant, après cela, l’algorithme assure un arbre en profondeur minimal qui nous permettrai de communiquer avec la racine le plus rapidement possible, et donc une qualité de service maximale.

== Gestion d’erreurs ==

Dans un réseau comme celui-ci, plusieurs types d’erreurs peuvent se produire :
Délai de communication trop important vers une balise
“Crash” d’une balise de communication
Surpopulation d’une balise ou congestion de messages

Afin de palier au premier type d’incident rencontré, il faut nécessairement qu’à chaque emplacement dans la zone couverte, l’utilisateur soit à même de communiquer avec au minimum 2 balises différentes. Ainsi, dans le cas d’une communication trop longue sur une balise, l’autre aurait de grandes chances de délivrer le message plus rapidement.

Au niveau de la défaillance d’une balise, l’algorithme d’arbre en profondeur nous fournit déjà une solution intégrée grâce à son auto-stabilisation. Dans le cas de déconnexion d’une balise, l’algorithme mettrai à jour automatiquement l’arbre de communication, et n’importe quel message d’alerte émis serait délivré dans un délai raisonnable.

Pour le troisième cas d’erreur, il n’y aurait pas de solution réelle, si ce n’est de limiter le nombre de communications données, en ne prenant plus en compte les “ping” de chaque utilisateur mais seulement les messages d’alertes, ce qui permettrai une bien plus grande gestion de la congestion à un endroit donné. Également, une balise en dessous d’un lien congestionné pourrait communiquer avec ses autres voisins (non-fils dans l’arbre) afin de libérer de l’espace dans le lien avec son père dans l’arbre. Également, le système ne pourra accepter que jusqu’à 1000 utilisateurs par noeud, et également 4000 utilisateurs par cluster (dans le cas d’un réseau avec plusieurs clusters donc plusieurs racines cette limite augmente).

Plusieurs types de paquets circulent sur le réseau de balise:
Les pings, messages envoyés spontanéments à intervalle régulier par les utilisateur contenant l’id ainsi que les deux coordonées gps (27 bits chacun)
Les incidents, identique à un ping mais à priorité haute.
Les alertes, messages brodcastés par le serveur afin d’envoyer un message en chaine de caractères courts et compressés.

=Coûts matériels=

Que ce soit pour le dispositif utilisateur ou la balise (racine ou non), le LoRaOne correspond pour permettre les actions recherchées. Afin de réaliser un prototype pertinent, 6 kits LoRaOne sont requis. Ces kits sont accessibles sur le site de Sodaq au prix de 115€ chacun (prix variable).
Disponible [https://shop.sodaq.com/en/one-eu-rn2483-v2.html ici], voir avant dernier bundle : starter "ONE EU starter" actuellement à 112,10€.

Un [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer buzzer] est à ajouter au dispositif utilisateur afin de lui délivrer un signal sonore.

Un shield GSM est requis pour que la balise racine communique avec l'extérieur. Sodaq en propose un designé pour fonctionner sur leurs produits mais est éctuellement en rupture de stock. Un shield GSM arduino convient tout autant et peut être trouvé sur le site arduino [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna ici].

Aucun boitier ne sera commandé car nous avons fait le choix de les manufacturer nous même au fablab. Le besoin d'étanchéité n'est pas primordial pour notre prototype, bien que nous tenterons de l'assurer.

{|class="récap commande"
|+ Récapitulatif
|-
|
!scope="col" style="width: 320px;"| Produit
!scope="col" style="width: 80px;"| Lien
!scope="col" style="width: 80px;"| Quantité
!scope="col" style="width: 80px;"| Prix Unitaire
|-

!scope="row"| 1
| LoRaOne EU Starter
| [https://shop.sodaq.com/en/one-eu-rn2483-v2.html Achat]
| 6
| 115€
|-

!scope="row"| 2
| Buzzer
| [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer Achat]
| 3
| 5.49€
|-

!scope="row"| 3
| Shield GSM
| [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna Achat]
| 1
| 65€
|-

|}

=Développement=

Nous utiliserons les librairies standards Arduino ainsi que celle de SODAQ/Arduino pour le LoRa.

L'IDE Arduino sera utilisé, plus pratique pour l'utilisation de Git (comparé à Mbed).

= Mise sur le marché =

Ce dispositif a pour but d’être utilisé en montagne, lors de randonnée. Il n’est pas destiné à un usage quotidien, c’est pourquoi nous considérons qu’il est plus judicieux de louer les dispositifs plutôt que de les vendre, même si l’achat n’est pas à omettre de notre stratégie.

Le dispositif peut être commandé en ligne, puis retourné par la poste après usage. Le client louerait le dispositif pour une certaine durée avec un possible nombre supplémentaire de batterie. Les tarifs varient en fonction de la durée et du nombre de batteries louées. Des offres de groupes pourraient être applicables. A long terme, des boutiques pourraient être disséminées dans des grandes villes proches des zones montagneuses, zones à randonnées (Grenoble, Annecy, etc.).

L’application est téléchargeable gratuitement par quiconque, mais utilisable seulement par les clients. Un code d’accès sera envoyé avec le dispositif expirant après la fin de la location.

Il faudra tenir compte de la bande passante du LoRa, variante en fonction des continents.

=Planning=

Sprint 1 : 29/01 --> 09/02 : Création du prototype logiciel #1
*Prise en main du matériel
*Premiers tests de transmissions LoRa
*Création du protocole d'architecture des balises
*Application sur les cartes et tests
*Tests de performances des cartes (durabilité, chargement, batterie)
*Tests de maintenabilité de l'algorithme (déconnexions, latences)

Sprint 2 : 12/02 --> 23/02 : Prototype logiciel #2 et prototype matériel
*Création du programme embarqué (utilisateur)
*Communication avec la racine et le serveur
*Création des maquettes boîtier et balise
*Construction des maquettes
*Finalisation du premier prototype

Sprint 3 : 26/02 --> 09/03 : Fonctionnalités supplémentaires
*Ajout de la communication entre le LoRa et le GSM sur la balise racine
*Création application mobile utilisateur
*Tests sur l'application
*Tests sur la transmission totale depuis l'utilisateur vers le serveur via le GSM
*Finalisation du projet

Sprint 4 : 12/03 --> 16/03 : Fin du projet
*Création de la documentation finale (à partir de la documentation réalisée en continu)
*Pause café
*Temps supplémentaire en cas de problèmes importants
*Préparation de la soutenance

R'Montagne

2018-02-12T10:03:26Z

Hugo.Amodru-Favin: /* Journal */

=Présentation du projet=

==Équipe==
{|class="wikitable"
|-
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Rôle
|-
| Hugo Amodru-Favin
| Chef de Projet
|-
| Antoine Delise
| Lead Developer
|-
| Gwenaël Moreau
| Kanban Master
|-

|}

==Tâches==

Répartition générale des tâches
{|class="wikitable"
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Tâche
|-
| Hugo Amodru-Favin
| Application Ionic
|-
| Antoine Delise
| Développement Arduino
|-
| Gwenaël Moreau
| BDD - API
|-

|}

Détail des tâches : [https://waffle.io/delisea/R-Montagne Lien Waffle.io]

==Journal==

{|class="wikitable"
|+
|-
|
!scope="col"| Date
!scope="col"| Hugo AMODRU-FAVIN
!scope="col"| Antoine DELISE
!scope="col"| Gwenaël MOREAU
|-

| colspan="5" style="text-align: center; background-color:#1c531c;"| SPRINT 1
|-

|-
| rowspan="2" | Lundi 29/01/18
| rowspan="1" | Tâches
| style="width: 225px;" |
* efoed
| style="width: 225px;" |
* sidfjeso
| style="width: 225px;" |
* zdokz
|-
|}

==Randonnée et risques==

Ouvert à tous, la randonnée est un sport et un loisir qui prend de plus en plus d’ampleur de nos jours. Ne nécessitant pas de grands prérequis, des milliers de personnes se lancent en montagne chaque jour, malheureusement parfois sans connaître toutes les mesures de sécurité associées.

En effet, de janvier à juin 2016, en randonnée et en alpinisme, l’Association Nationale pour l’Étude de la Neige et des Avalanches (ANENA) a comptabilisé 21 accidents notables, dont 8 accidents mortels, impliquant 15 décès.

Aujourd’hui, les mesures de sécurités préconisent que chaque groupe de randonneur se doivent de se munir d’un téléphone portable afin d’appeler les secours en cas de problème. Malheureusement, la communication mobile dépendant de la couverture réseau, peu présente en montagne, l’impossibilité de joindre les secours reste un problème.

==Solutions existantes==

La solution la plus répandue, est celle du téléphone à connexion satellite. Ayant une communication vers les satellites, cela permet une couverture réseau beaucoup plus répandue dans les montagnes, partout dans le monde (ou presque). Cependant, les téléphones portables satellitaires coûtent chers, et ne sont pas forcément abordables par la plupart des personnes, surtout celles ne sortant qu’occasionnellement.

[https://fall-alarm.net/ Fall Alarm] est un système de détection de chute sur chantier utilisant les mêmes technologies dont nous avons besoin pour notre projet.

==Quelles zones géographiques ?==

Toutes les zones montagneuses peuvent présenter des zones blanches, démunies de connexion quelconque autre que les connexions satellitaires. Certaines chaînes de montagne comme la Cordillaire des Andes ne présentent aucune connexion possible quelconque.

Dans le cadre de notre projet, nous fonctionnerons essentiellement dans la localisation grenobloise avec l'objectif que notre solution soit applicable partout dans le monde. Une contrainte intervient tout de même étant donnée que la fréquence d'utilisation du LoRa en Europe est de 868MHz, 915MHz en Amérique et 433MHz en Asie.

= Fonctionnalités =

Afin de remplir au mieux ses attentes, le principal objectif de ce dispositif sera premièrement de pouvoir communiquer avec les secours à n’importe quel moment, et surtout n’importe où. De plus, il sera capable de détecter de nombreux cas de détresse de la part de l’usager afin de pouvoir lancer un appel d’urgence sans interaction avec l’usager, au cas où il serait inconscient, ou incapable de lancer un appel manuel.

Grâce aux accéléromètres, le dispositif sera à même de détecter un mouvement brutal du randonneur, ce qui pourrait s’apparenter à une chute. Ils pourront également détecter une position anormale, ou une immobilité prolongée, ce qui déclencherait le dispositif d’urgence automatiquement.

Grâce à des tests réalisés au préalable, le boîtier pourra détecter correctement les chûtes de simples mouvements, afin de ne pas lancer l’appel sans raison valable.

Avant de lancer une alerte automatique, le dispositif émettra un signal auditif et visuel à l’utilisateur quelques secondes auparavant, afin de le prévenir l'émission du signal d’urgence, et de lui proposer de le désactiver sur simple pression d’un bouton, afin d’éviter les communications inutiles.

Également, le randonneur sera à même d'émettre volontairement un appel d’urgence à l’aide du bouton, ce qui permet à tout moment d’appeler de l’aide sans effort. Cela peut permettre également à appeler les secours pour une personne en danger qui ne porterait pas le dispositif.

L’appel au secours se représente par un envoi de coordonnées GPS aux secours, via une communication radio LoRa vers des bornes relais placées au préalables en montagne. Cette communication irait de relai de relai jusqu’au centre de sécurité, d’où le message serait transmis aux secours.

De plus, une application mobile verra le jour afin de connecter tous les utilisateurs du module de sécurité, de les visualiser sur une map, et de partager leurs données. En effet, à chaque incident, l’application mettra à jour la position et de la date de l’accident, afin de permettre aux prochains utilisateurs d’être prévenus. Ils pourraient, s'ils sont à proximité, d'assister la personne en détresse en attendant l'arrivée des secours. Bien évidemment, cette application ne sera accessible uniquement si le smartphone de l'utilisateur est relié à une connexion 4G ou Wi-Fi.

Cette prévention pourrait les sensibiliser aux risques de la montagne, leur permettre d’éviter le secteur mais aussi d’aider les personnes en danger si la distance le permet.

= Exigences =
== Fonctionnelles ==

*Batterie garantie fonctionnelle 1 semaine
*Rechargement possible via le panneau solaire portable
*Dispositif pouvant être allumé et éteint par l'utilisateur
*Alarme s’enclenche automatiquement dès qu'elle est considérée nécessaire, signal sonore
*Utilisateur a la possibilité d’activer/désactiver l’alarme quand il le souhaite
*Lorsque l’alarme est active, l’appareil ne peut s’éteindre
*...

== Non-Fonctionnelles ==

*Résistance : aux chocs, impacts, waterproof (utilisé en permanence en plein air)
*Disponibilité : Appareil de secours -> Doit être au plus possible performant
*Performance : Minimiser les pertes réseaux
*Accessible : Utilisateur pas forcément familier avec des appareils électroniques (facile d’utilisation)
*Fiabilité : Précision du GPS (rayon de 10m), données non-éronnées
*Coût : Le plus faible possible pour vendre le moins cher possible
*Efficacité : Réduire la consommation, utiliser le moins possible les ressources

= Composants =
== LoRaONE ==
Pour le coeur du projet, après avoir cherché et comparés plusieurs modules LoRa, GPS ou encore accéléromètres, nous avons finalement opté pour le projet LoRaONE.

LoRaONE est un projet de SODAQ regroupant plusieurs composants dans une seule et même carte, de taille réduite.

https://www.kickstarter.com/projects/sodaq/loraone-the-lora-iot-development-board

“The one IoT development board to rule them all” --SODAQ

Cette carte regroupe plusieurs capteurs afin de respecter aux mieux nos exigences :

Un émetteur/récepteur LoRa afin de pouvoir communiquer au mieux avec les antennes relai à longue distance

Un module + antenne GPS de bonne précision (< 10m) pour connaître en tout temps notre position, et ainsi faciliter l’arrivée des secours, ainsi que la recherche de l’individu en détresse

Un accéléromètre sur 3 axes afin de pouvoir détecter tout mouvement, vitesse ou rotation dans l’espace, ce qui permet la détection de chutes ou d’arrêt de mouvements

3 LED RGB afin de pouvoir signaler à l’utilisateur un manque de batterie, un signal d’urgence ou plus si nécessaire

Un bouton poussoir pour le signal d’alarme

Un connecteur de charge par panneau solaire, afin de faire durer chaque batterie le plus longtemps possible

Un connecteur micro-USB ainsi que des lignes pour se connecter à une base Arduino si besoin

[[File:LoRaOne.png||400px|Spécifications carte LoRaOne]]

De plus, grâce au starter pack, nous pouvons avoir accès à la base ONEBase qui nous permettrait d’étendre plus loin la facilité d’utilisation du produit :

[[File:LoRaOneBase.png||400px|Spécifications base LoRaOneBase]]

Comme nous pouvons le voir, cette base nous permettra de connecter la batterie ainsi que le panneau solaire qui sont fournis dans le pack.

Nous pourrons également connecter jusqu’à 4 modules supplémentaires.

La batterie fournie aura une capacité de 800 mAh, le panneau solaire fourni pouvant délivrer jusqu’à 500 mW de puissance.

Le total atteint une taille d’environ 10*5 cm, ce qui n’est pas excessif, ce qui le rend aisément portatif sur une jambe ou à la taille.

'''Coût : 115€'''

Ce module pourra également servir d’antenne relai, l'alimentation solaire devrait maintenir le dispositif chargé en permanence. Des tests seront effectués pour savoir si un panneau solaire plus puissant est requis.

== Boîtier ==

Le boîtier sécurisé devant respecter plusieurs exigences, nous pouvons le construire en plastique résistant, ce qui le rendrait léger tout en respectant une rigidité suffisante. Les antennes pourront être placées le long du boîtier, à l’intérieur si la connexion est suffisante, ou à l’extérieur. Dans ce dernier cas les trous réalisés sur le boîtier afin de laisser passer les câbles seront colmatés afin de garantir une étanchéité.

[[File:SchemaBoitier.png||100px|Schéma boitier d'alarme]]

== Balises ==

Afin de remonter les informations transmises par les boitiers, des balises seront mises en places sur la zone à couvrir, leur nombre et leur positions dépendra du terrain (obstacles, dénivelés). On distinguera deux types de balises. Tout d’abord, les balises racines qui permettront une communication GSM afin de faire remonter les données vers le serveur. Viennent ensuite les balises standard qui se contenteront de faire remonter vers leur balise racine associée. L’architecture de liaison des balises est détaillée dans une prochaine partie.

Chaque balise est composée d’une barre de fer pouvant être plantée dans le sol, d’un système de lest afin d’immobiliser la balise, d’un paratonnerre, d’un panneau solaire ainsi que d’un LoraOne et d’une batterie. Les balises racines seront équippée en plus d’un dispositif de communication GSM (téléphone portable, émetteur GSM).

[[File:SchemaBalise.png||150px|Schéma balises d'alarme]]

== Application mobile ==
Une application mobile est téléchargeable par les utilisateurs. Ils peuvent voir les autres utilisateurs présents dans leur zone. Lorsqu’un utilisateur est en position de danger, une notification apparaît si les utilisateurs sont proches de la situation de danger.

Cette application n’est pas directement reliée au dispositif. Elle ne fonctionne qu’avec la connexion du mobile, et est destinée à être un niveau de sécurité supérieur. Un randonneur proche d’une zone de danger pourrait arriver sur place plus rapidement que les secours.

= Communication =

Pour un envoi de position + numéro d’identification (X chiffres) :

*Temps de communication : < 2 s
*Communication régulière, intervalle de 15 minutes

On peut donc au maximum avoir 15 * 60 / 2 = 450 individus pouvant communiquer avec la même antenne relai, donc dans le même cercle d’environ 15 km de diamètre.

On communique donc au minimum 2 secondes sur 15 minutes, donc 1/450 << 1%, le temps de communication est respecté.

En cas de problème, nous pouvons envoyer jusqu’à 9x plus avec la borne sans dépasser le temps de communication autorisé (1%). Donc 1 envoi d’appel d’urgence toutes les 2 minutes environ.

La balise racine peut être directement connectée au serveur, dans ce cas, il n’y a pas de communication GSM nécessaire et pas de Gateway. Si la racine n’est pas directement connectée au serveur, elle devra au minimum garantir une communication GSM (ce qu’elle peut faire, il n’y a pas de Gateway nécessaire) pour remonter l’information vers le serveur, et donc la base de données.

GSM : Si Racine connectée à Serveur -> No GSM + Gateway
Else : GSM + Gateway : LoRa Racine connectée ordi (RaspberryPI) + ordi connecté GSM

= Stabilisation et gestion d’erreurs =

== Choix du routage ==

Notre réseau n'est pas un réseau traditionnel. Les seules communications existantes sont soit une remontée d'information vers la racine soit une innondation d'alerte vers les clients. Pour celà nous avons donc décidé d'utiliser un algorithme de routage simplifié basé uniquement sur un arbre en largeur des balises. Nous rajoutons en option la possibilité de créer plusieurs racines et donc plusieurs arbres dont les racines communiquent par gsm. Nous nous basons sur des papiers de recherches afin de déterminer quel algorithme auto-stabilisant est le plus adapté au système LoRa (Tel que le papier "A self-stabilizing algorithm for constructing breadth-first trees" par Shing-Tsaan Huang, Nian-Shing Chen).

== Stabilisation ==

Afin de gérer la communication de chaque message vers le serveur, nous allons prendre un noeud (balise LoRa) dit “racine” connecté directement au serveur, nous ne nous occuperons pas de la communication au serveur dans cet onglet. Chaque message reçu de la part d’un noeud du système doit être relayé jusqu’à la racine du système afin de communiquer avec les secours (ou serveur simplement).

Pour cela, il faudra assurer que chaque balise LoRa soit connecté au réseau, afin d’avoir au départ un graphe de communication connexe. Par dessus ce graphe, nous allons utiliser un processus silencieux auto-stabilisant qui construira un arbre de parcours en largeur, avec pour racine le noeud “racine” décidé ci-dessus.

Au lancement du système, il faut prévoir un léger temps de stabilisation, qui dépendrait de l’algorithme et de la taille du graphe (nombre de balises). Cependant, après cela, l’algorithme assure un arbre en profondeur minimal qui nous permettrai de communiquer avec la racine le plus rapidement possible, et donc une qualité de service maximale.

== Gestion d’erreurs ==

Dans un réseau comme celui-ci, plusieurs types d’erreurs peuvent se produire :
Délai de communication trop important vers une balise
“Crash” d’une balise de communication
Surpopulation d’une balise ou congestion de messages

Afin de palier au premier type d’incident rencontré, il faut nécessairement qu’à chaque emplacement dans la zone couverte, l’utilisateur soit à même de communiquer avec au minimum 2 balises différentes. Ainsi, dans le cas d’une communication trop longue sur une balise, l’autre aurait de grandes chances de délivrer le message plus rapidement.

Au niveau de la défaillance d’une balise, l’algorithme d’arbre en profondeur nous fournit déjà une solution intégrée grâce à son auto-stabilisation. Dans le cas de déconnexion d’une balise, l’algorithme mettrai à jour automatiquement l’arbre de communication, et n’importe quel message d’alerte émis serait délivré dans un délai raisonnable.

Pour le troisième cas d’erreur, il n’y aurait pas de solution réelle, si ce n’est de limiter le nombre de communications données, en ne prenant plus en compte les “ping” de chaque utilisateur mais seulement les messages d’alertes, ce qui permettrai une bien plus grande gestion de la congestion à un endroit donné. Également, une balise en dessous d’un lien congestionné pourrait communiquer avec ses autres voisins (non-fils dans l’arbre) afin de libérer de l’espace dans le lien avec son père dans l’arbre. Également, le système ne pourra accepter que jusqu’à 1000 utilisateurs par noeud, et également 4000 utilisateurs par cluster (dans le cas d’un réseau avec plusieurs clusters donc plusieurs racines cette limite augmente).

Plusieurs types de paquets circulent sur le réseau de balise:
Les pings, messages envoyés spontanéments à intervalle régulier par les utilisateur contenant l’id ainsi que les deux coordonées gps (27 bits chacun)
Les incidents, identique à un ping mais à priorité haute.
Les alertes, messages brodcastés par le serveur afin d’envoyer un message en chaine de caractères courts et compressés.

=Coûts matériels=

Que ce soit pour le dispositif utilisateur ou la balise (racine ou non), le LoRaOne correspond pour permettre les actions recherchées. Afin de réaliser un prototype pertinent, 6 kits LoRaOne sont requis. Ces kits sont accessibles sur le site de Sodaq au prix de 115€ chacun (prix variable).
Disponible [https://shop.sodaq.com/en/one-eu-rn2483-v2.html ici], voir avant dernier bundle : starter "ONE EU starter" actuellement à 112,10€.

Un [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer buzzer] est à ajouter au dispositif utilisateur afin de lui délivrer un signal sonore.

Un shield GSM est requis pour que la balise racine communique avec l'extérieur. Sodaq en propose un designé pour fonctionner sur leurs produits mais est éctuellement en rupture de stock. Un shield GSM arduino convient tout autant et peut être trouvé sur le site arduino [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna ici].

Aucun boitier ne sera commandé car nous avons fait le choix de les manufacturer nous même au fablab. Le besoin d'étanchéité n'est pas primordial pour notre prototype, bien que nous tenterons de l'assurer.

{|class="récap commande"
|+ Récapitulatif
|-
|
!scope="col" style="width: 320px;"| Produit
!scope="col" style="width: 80px;"| Lien
!scope="col" style="width: 80px;"| Quantité
!scope="col" style="width: 80px;"| Prix Unitaire
|-

!scope="row"| 1
| LoRaOne EU Starter
| [https://shop.sodaq.com/en/one-eu-rn2483-v2.html Achat]
| 6
| 115€
|-

!scope="row"| 2
| Buzzer
| [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer Achat]
| 3
| 5.49€
|-

!scope="row"| 3
| Shield GSM
| [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna Achat]
| 1
| 65€
|-

|}

=Développement=

Nous utiliserons les librairies standards Arduino ainsi que celle de SODAQ/Arduino pour le LoRa.

L'IDE Arduino sera utilisé, plus pratique pour l'utilisation de Git (comparé à Mbed).

= Mise sur le marché =

Ce dispositif a pour but d’être utilisé en montagne, lors de randonnée. Il n’est pas destiné à un usage quotidien, c’est pourquoi nous considérons qu’il est plus judicieux de louer les dispositifs plutôt que de les vendre, même si l’achat n’est pas à omettre de notre stratégie.

Le dispositif peut être commandé en ligne, puis retourné par la poste après usage. Le client louerait le dispositif pour une certaine durée avec un possible nombre supplémentaire de batterie. Les tarifs varient en fonction de la durée et du nombre de batteries louées. Des offres de groupes pourraient être applicables. A long terme, des boutiques pourraient être disséminées dans des grandes villes proches des zones montagneuses, zones à randonnées (Grenoble, Annecy, etc.).

L’application est téléchargeable gratuitement par quiconque, mais utilisable seulement par les clients. Un code d’accès sera envoyé avec le dispositif expirant après la fin de la location.

Il faudra tenir compte de la bande passante du LoRa, variante en fonction des continents.

=Planning=

Sprint 1 : 29/01 --> 09/02 : Création du prototype logiciel #1
*Prise en main du matériel
*Premiers tests de transmissions LoRa
*Création du protocole d'architecture des balises
*Application sur les cartes et tests
*Tests de performances des cartes (durabilité, chargement, batterie)
*Tests de maintenabilité de l'algorithme (déconnexions, latences)

Sprint 2 : 12/02 --> 23/02 : Prototype logiciel #2 et prototype matériel
*Création du programme embarqué (utilisateur)
*Communication avec la racine et le serveur
*Création des maquettes boîtier et balise
*Construction des maquettes
*Finalisation du premier prototype

Sprint 3 : 26/02 --> 09/03 : Fonctionnalités supplémentaires
*Ajout de la communication entre le LoRa et le GSM sur la balise racine
*Création application mobile utilisateur
*Tests sur l'application
*Tests sur la transmission totale depuis l'utilisateur vers le serveur via le GSM
*Finalisation du projet

Sprint 4 : 12/03 --> 16/03 : Fin du projet
*Création de la documentation finale (à partir de la documentation réalisée en continu)
*Pause café
*Temps supplémentaire en cas de problèmes importants
*Préparation de la soutenance

R'Montagne

2018-02-12T10:03:11Z

Hugo.Amodru-Favin: /* Journal */

=Présentation du projet=

==Équipe==
{|class="wikitable"
|-
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Rôle
|-
| Hugo Amodru-Favin
| Chef de Projet
|-
| Antoine Delise
| Lead Developer
|-
| Gwenaël Moreau
| Kanban Master
|-

|}

==Tâches==

Répartition générale des tâches
{|class="wikitable"
!scope="col" style="width: 150px;"| Étudiant
!scope="col" style="width: 200px;"| Tâche
|-
| Hugo Amodru-Favin
| Application Ionic
|-
| Antoine Delise
| Développement Arduino
|-
| Gwenaël Moreau
| BDD - API
|-

|}

Détail des tâches : [https://waffle.io/delisea/R-Montagne Lien Waffle.io]

==Journal==

{|class="wikitable"
|+
|-
|
!scope="col"| Date
!scope="col"| Hugo AMODRU-FAVIN
!scope="col"| Antoine DELISE
!scope="col"| Gwenaël MOREAU
|-

| colspan="5" style="text-align: center; background-color:#1c531c;"| SPRINT 1
|-

|-
| rowspan="2" | Lundi 29/01/18
| rowspan="1" | Tâches
| style="width: 225px;" |
* efoed
| style="width: 225px;" |
* sidfjeso
| style="width: 225px;" |
* zdokz
|-
|}

==Randonnée et risques==

Ouvert à tous, la randonnée est un sport et un loisir qui prend de plus en plus d’ampleur de nos jours. Ne nécessitant pas de grands prérequis, des milliers de personnes se lancent en montagne chaque jour, malheureusement parfois sans connaître toutes les mesures de sécurité associées.

En effet, de janvier à juin 2016, en randonnée et en alpinisme, l’Association Nationale pour l’Étude de la Neige et des Avalanches (ANENA) a comptabilisé 21 accidents notables, dont 8 accidents mortels, impliquant 15 décès.

Aujourd’hui, les mesures de sécurités préconisent que chaque groupe de randonneur se doivent de se munir d’un téléphone portable afin d’appeler les secours en cas de problème. Malheureusement, la communication mobile dépendant de la couverture réseau, peu présente en montagne, l’impossibilité de joindre les secours reste un problème.

==Solutions existantes==

La solution la plus répandue, est celle du téléphone à connexion satellite. Ayant une communication vers les satellites, cela permet une couverture réseau beaucoup plus répandue dans les montagnes, partout dans le monde (ou presque). Cependant, les téléphones portables satellitaires coûtent chers, et ne sont pas forcément abordables par la plupart des personnes, surtout celles ne sortant qu’occasionnellement.

[https://fall-alarm.net/ Fall Alarm] est un système de détection de chute sur chantier utilisant les mêmes technologies dont nous avons besoin pour notre projet.

==Quelles zones géographiques ?==

Toutes les zones montagneuses peuvent présenter des zones blanches, démunies de connexion quelconque autre que les connexions satellitaires. Certaines chaînes de montagne comme la Cordillaire des Andes ne présentent aucune connexion possible quelconque.

Dans le cadre de notre projet, nous fonctionnerons essentiellement dans la localisation grenobloise avec l'objectif que notre solution soit applicable partout dans le monde. Une contrainte intervient tout de même étant donnée que la fréquence d'utilisation du LoRa en Europe est de 868MHz, 915MHz en Amérique et 433MHz en Asie.

= Fonctionnalités =

Afin de remplir au mieux ses attentes, le principal objectif de ce dispositif sera premièrement de pouvoir communiquer avec les secours à n’importe quel moment, et surtout n’importe où. De plus, il sera capable de détecter de nombreux cas de détresse de la part de l’usager afin de pouvoir lancer un appel d’urgence sans interaction avec l’usager, au cas où il serait inconscient, ou incapable de lancer un appel manuel.

Grâce aux accéléromètres, le dispositif sera à même de détecter un mouvement brutal du randonneur, ce qui pourrait s’apparenter à une chute. Ils pourront également détecter une position anormale, ou une immobilité prolongée, ce qui déclencherait le dispositif d’urgence automatiquement.

Grâce à des tests réalisés au préalable, le boîtier pourra détecter correctement les chûtes de simples mouvements, afin de ne pas lancer l’appel sans raison valable.

Avant de lancer une alerte automatique, le dispositif émettra un signal auditif et visuel à l’utilisateur quelques secondes auparavant, afin de le prévenir l'émission du signal d’urgence, et de lui proposer de le désactiver sur simple pression d’un bouton, afin d’éviter les communications inutiles.

Également, le randonneur sera à même d'émettre volontairement un appel d’urgence à l’aide du bouton, ce qui permet à tout moment d’appeler de l’aide sans effort. Cela peut permettre également à appeler les secours pour une personne en danger qui ne porterait pas le dispositif.

L’appel au secours se représente par un envoi de coordonnées GPS aux secours, via une communication radio LoRa vers des bornes relais placées au préalables en montagne. Cette communication irait de relai de relai jusqu’au centre de sécurité, d’où le message serait transmis aux secours.

De plus, une application mobile verra le jour afin de connecter tous les utilisateurs du module de sécurité, de les visualiser sur une map, et de partager leurs données. En effet, à chaque incident, l’application mettra à jour la position et de la date de l’accident, afin de permettre aux prochains utilisateurs d’être prévenus. Ils pourraient, s'ils sont à proximité, d'assister la personne en détresse en attendant l'arrivée des secours. Bien évidemment, cette application ne sera accessible uniquement si le smartphone de l'utilisateur est relié à une connexion 4G ou Wi-Fi.

Cette prévention pourrait les sensibiliser aux risques de la montagne, leur permettre d’éviter le secteur mais aussi d’aider les personnes en danger si la distance le permet.

= Exigences =
== Fonctionnelles ==

*Batterie garantie fonctionnelle 1 semaine
*Rechargement possible via le panneau solaire portable
*Dispositif pouvant être allumé et éteint par l'utilisateur
*Alarme s’enclenche automatiquement dès qu'elle est considérée nécessaire, signal sonore
*Utilisateur a la possibilité d’activer/désactiver l’alarme quand il le souhaite
*Lorsque l’alarme est active, l’appareil ne peut s’éteindre
*...

== Non-Fonctionnelles ==

*Résistance : aux chocs, impacts, waterproof (utilisé en permanence en plein air)
*Disponibilité : Appareil de secours -> Doit être au plus possible performant
*Performance : Minimiser les pertes réseaux
*Accessible : Utilisateur pas forcément familier avec des appareils électroniques (facile d’utilisation)
*Fiabilité : Précision du GPS (rayon de 10m), données non-éronnées
*Coût : Le plus faible possible pour vendre le moins cher possible
*Efficacité : Réduire la consommation, utiliser le moins possible les ressources

= Composants =
== LoRaONE ==
Pour le coeur du projet, après avoir cherché et comparés plusieurs modules LoRa, GPS ou encore accéléromètres, nous avons finalement opté pour le projet LoRaONE.

LoRaONE est un projet de SODAQ regroupant plusieurs composants dans une seule et même carte, de taille réduite.

https://www.kickstarter.com/projects/sodaq/loraone-the-lora-iot-development-board

“The one IoT development board to rule them all” --SODAQ

Cette carte regroupe plusieurs capteurs afin de respecter aux mieux nos exigences :

Un émetteur/récepteur LoRa afin de pouvoir communiquer au mieux avec les antennes relai à longue distance

Un module + antenne GPS de bonne précision (< 10m) pour connaître en tout temps notre position, et ainsi faciliter l’arrivée des secours, ainsi que la recherche de l’individu en détresse

Un accéléromètre sur 3 axes afin de pouvoir détecter tout mouvement, vitesse ou rotation dans l’espace, ce qui permet la détection de chutes ou d’arrêt de mouvements

3 LED RGB afin de pouvoir signaler à l’utilisateur un manque de batterie, un signal d’urgence ou plus si nécessaire

Un bouton poussoir pour le signal d’alarme

Un connecteur de charge par panneau solaire, afin de faire durer chaque batterie le plus longtemps possible

Un connecteur micro-USB ainsi que des lignes pour se connecter à une base Arduino si besoin

[[File:LoRaOne.png||400px|Spécifications carte LoRaOne]]

De plus, grâce au starter pack, nous pouvons avoir accès à la base ONEBase qui nous permettrait d’étendre plus loin la facilité d’utilisation du produit :

[[File:LoRaOneBase.png||400px|Spécifications base LoRaOneBase]]

Comme nous pouvons le voir, cette base nous permettra de connecter la batterie ainsi que le panneau solaire qui sont fournis dans le pack.

Nous pourrons également connecter jusqu’à 4 modules supplémentaires.

La batterie fournie aura une capacité de 800 mAh, le panneau solaire fourni pouvant délivrer jusqu’à 500 mW de puissance.

Le total atteint une taille d’environ 10*5 cm, ce qui n’est pas excessif, ce qui le rend aisément portatif sur une jambe ou à la taille.

'''Coût : 115€'''

Ce module pourra également servir d’antenne relai, l'alimentation solaire devrait maintenir le dispositif chargé en permanence. Des tests seront effectués pour savoir si un panneau solaire plus puissant est requis.

== Boîtier ==

Le boîtier sécurisé devant respecter plusieurs exigences, nous pouvons le construire en plastique résistant, ce qui le rendrait léger tout en respectant une rigidité suffisante. Les antennes pourront être placées le long du boîtier, à l’intérieur si la connexion est suffisante, ou à l’extérieur. Dans ce dernier cas les trous réalisés sur le boîtier afin de laisser passer les câbles seront colmatés afin de garantir une étanchéité.

[[File:SchemaBoitier.png||100px|Schéma boitier d'alarme]]

== Balises ==

Afin de remonter les informations transmises par les boitiers, des balises seront mises en places sur la zone à couvrir, leur nombre et leur positions dépendra du terrain (obstacles, dénivelés). On distinguera deux types de balises. Tout d’abord, les balises racines qui permettront une communication GSM afin de faire remonter les données vers le serveur. Viennent ensuite les balises standard qui se contenteront de faire remonter vers leur balise racine associée. L’architecture de liaison des balises est détaillée dans une prochaine partie.

Chaque balise est composée d’une barre de fer pouvant être plantée dans le sol, d’un système de lest afin d’immobiliser la balise, d’un paratonnerre, d’un panneau solaire ainsi que d’un LoraOne et d’une batterie. Les balises racines seront équippée en plus d’un dispositif de communication GSM (téléphone portable, émetteur GSM).

[[File:SchemaBalise.png||150px|Schéma balises d'alarme]]

== Application mobile ==
Une application mobile est téléchargeable par les utilisateurs. Ils peuvent voir les autres utilisateurs présents dans leur zone. Lorsqu’un utilisateur est en position de danger, une notification apparaît si les utilisateurs sont proches de la situation de danger.

Cette application n’est pas directement reliée au dispositif. Elle ne fonctionne qu’avec la connexion du mobile, et est destinée à être un niveau de sécurité supérieur. Un randonneur proche d’une zone de danger pourrait arriver sur place plus rapidement que les secours.

= Communication =

Pour un envoi de position + numéro d’identification (X chiffres) :

*Temps de communication : < 2 s
*Communication régulière, intervalle de 15 minutes

On peut donc au maximum avoir 15 * 60 / 2 = 450 individus pouvant communiquer avec la même antenne relai, donc dans le même cercle d’environ 15 km de diamètre.

On communique donc au minimum 2 secondes sur 15 minutes, donc 1/450 << 1%, le temps de communication est respecté.

En cas de problème, nous pouvons envoyer jusqu’à 9x plus avec la borne sans dépasser le temps de communication autorisé (1%). Donc 1 envoi d’appel d’urgence toutes les 2 minutes environ.

La balise racine peut être directement connectée au serveur, dans ce cas, il n’y a pas de communication GSM nécessaire et pas de Gateway. Si la racine n’est pas directement connectée au serveur, elle devra au minimum garantir une communication GSM (ce qu’elle peut faire, il n’y a pas de Gateway nécessaire) pour remonter l’information vers le serveur, et donc la base de données.

GSM : Si Racine connectée à Serveur -> No GSM + Gateway
Else : GSM + Gateway : LoRa Racine connectée ordi (RaspberryPI) + ordi connecté GSM

= Stabilisation et gestion d’erreurs =

== Choix du routage ==

Notre réseau n'est pas un réseau traditionnel. Les seules communications existantes sont soit une remontée d'information vers la racine soit une innondation d'alerte vers les clients. Pour celà nous avons donc décidé d'utiliser un algorithme de routage simplifié basé uniquement sur un arbre en largeur des balises. Nous rajoutons en option la possibilité de créer plusieurs racines et donc plusieurs arbres dont les racines communiquent par gsm. Nous nous basons sur des papiers de recherches afin de déterminer quel algorithme auto-stabilisant est le plus adapté au système LoRa (Tel que le papier "A self-stabilizing algorithm for constructing breadth-first trees" par Shing-Tsaan Huang, Nian-Shing Chen).

== Stabilisation ==

Afin de gérer la communication de chaque message vers le serveur, nous allons prendre un noeud (balise LoRa) dit “racine” connecté directement au serveur, nous ne nous occuperons pas de la communication au serveur dans cet onglet. Chaque message reçu de la part d’un noeud du système doit être relayé jusqu’à la racine du système afin de communiquer avec les secours (ou serveur simplement).

Pour cela, il faudra assurer que chaque balise LoRa soit connecté au réseau, afin d’avoir au départ un graphe de communication connexe. Par dessus ce graphe, nous allons utiliser un processus silencieux auto-stabilisant qui construira un arbre de parcours en largeur, avec pour racine le noeud “racine” décidé ci-dessus.

Au lancement du système, il faut prévoir un léger temps de stabilisation, qui dépendrait de l’algorithme et de la taille du graphe (nombre de balises). Cependant, après cela, l’algorithme assure un arbre en profondeur minimal qui nous permettrai de communiquer avec la racine le plus rapidement possible, et donc une qualité de service maximale.

== Gestion d’erreurs ==

Dans un réseau comme celui-ci, plusieurs types d’erreurs peuvent se produire :
Délai de communication trop important vers une balise
“Crash” d’une balise de communication
Surpopulation d’une balise ou congestion de messages

Afin de palier au premier type d’incident rencontré, il faut nécessairement qu’à chaque emplacement dans la zone couverte, l’utilisateur soit à même de communiquer avec au minimum 2 balises différentes. Ainsi, dans le cas d’une communication trop longue sur une balise, l’autre aurait de grandes chances de délivrer le message plus rapidement.

Au niveau de la défaillance d’une balise, l’algorithme d’arbre en profondeur nous fournit déjà une solution intégrée grâce à son auto-stabilisation. Dans le cas de déconnexion d’une balise, l’algorithme mettrai à jour automatiquement l’arbre de communication, et n’importe quel message d’alerte émis serait délivré dans un délai raisonnable.

Pour le troisième cas d’erreur, il n’y aurait pas de solution réelle, si ce n’est de limiter le nombre de communications données, en ne prenant plus en compte les “ping” de chaque utilisateur mais seulement les messages d’alertes, ce qui permettrai une bien plus grande gestion de la congestion à un endroit donné. Également, une balise en dessous d’un lien congestionné pourrait communiquer avec ses autres voisins (non-fils dans l’arbre) afin de libérer de l’espace dans le lien avec son père dans l’arbre. Également, le système ne pourra accepter que jusqu’à 1000 utilisateurs par noeud, et également 4000 utilisateurs par cluster (dans le cas d’un réseau avec plusieurs clusters donc plusieurs racines cette limite augmente).

Plusieurs types de paquets circulent sur le réseau de balise:
Les pings, messages envoyés spontanéments à intervalle régulier par les utilisateur contenant l’id ainsi que les deux coordonées gps (27 bits chacun)
Les incidents, identique à un ping mais à priorité haute.
Les alertes, messages brodcastés par le serveur afin d’envoyer un message en chaine de caractères courts et compressés.

=Coûts matériels=

Que ce soit pour le dispositif utilisateur ou la balise (racine ou non), le LoRaOne correspond pour permettre les actions recherchées. Afin de réaliser un prototype pertinent, 6 kits LoRaOne sont requis. Ces kits sont accessibles sur le site de Sodaq au prix de 115€ chacun (prix variable).
Disponible [https://shop.sodaq.com/en/one-eu-rn2483-v2.html ici], voir avant dernier bundle : starter "ONE EU starter" actuellement à 112,10€.

Un [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer buzzer] est à ajouter au dispositif utilisateur afin de lui délivrer un signal sonore.

Un shield GSM est requis pour que la balise racine communique avec l'extérieur. Sodaq en propose un designé pour fonctionner sur leurs produits mais est éctuellement en rupture de stock. Un shield GSM arduino convient tout autant et peut être trouvé sur le site arduino [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna ici].

Aucun boitier ne sera commandé car nous avons fait le choix de les manufacturer nous même au fablab. Le besoin d'étanchéité n'est pas primordial pour notre prototype, bien que nous tenterons de l'assurer.

{|class="récap commande"
|+ Récapitulatif
|-
|
!scope="col" style="width: 320px;"| Produit
!scope="col" style="width: 80px;"| Lien
!scope="col" style="width: 80px;"| Quantité
!scope="col" style="width: 80px;"| Prix Unitaire
|-

!scope="row"| 1
| LoRaOne EU Starter
| [https://shop.sodaq.com/en/one-eu-rn2483-v2.html Achat]
| 6
| 115€
|-

!scope="row"| 2
| Buzzer
| [https://www.amazon.fr/G%C3%A9n%C3%A9rateur-Raspberry-g%C3%A9n%C3%A9rateur-fr%C3%A9quence-A1373/dp/B06XVQYF3N/ref=sr_1_1?ie=UTF8&qid=1511907697&sr=8-1&keywords=arduino+buzzer Achat]
| 3
| 5.49€
|-

!scope="row"| 3
| Shield GSM
| [https://store.arduino.cc/arduino-gsm-shield-2-integrated-antenna Achat]
| 1
| 65€
|-

|}

=Développement=

Nous utiliserons les librairies standards Arduino ainsi que celle de SODAQ/Arduino pour le LoRa.

L'IDE Arduino sera utilisé, plus pratique pour l'utilisation de Git (comparé à Mbed).

= Mise sur le marché =

Ce dispositif a pour but d’être utilisé en montagne, lors de randonnée. Il n’est pas destiné à un usage quotidien, c’est pourquoi nous considérons qu’il est plus judicieux de louer les dispositifs plutôt que de les vendre, même si l’achat n’est pas à omettre de notre stratégie.

Le dispositif peut être commandé en ligne, puis retourné par la poste après usage. Le client louerait le dispositif pour une certaine durée avec un possible nombre supplémentaire de batterie. Les tarifs varient en fonction de la durée et du nombre de batteries louées. Des offres de groupes pourraient être applicables. A long terme, des boutiques pourraient être disséminées dans des grandes villes proches des zones montagneuses, zones à randonnées (Grenoble, Annecy, etc.).

L’application est téléchargeable gratuitement par quiconque, mais utilisable seulement par les clients. Un code d’accès sera envoyé avec le dispositif expirant après la fin de la location.

Il faudra tenir compte de la bande passante du LoRa, variante en fonction des continents.

=Planning=

Sprint 1 : 29/01 --> 09/02 : Création du prototype logiciel #1
*Prise en main du matériel
*Premiers tests de transmissions LoRa
*Création du protocole d'architecture des balises
*Application sur les cartes et tests
*Tests de performances des cartes (durabilité, chargement, batterie)
*Tests de maintenabilité de l'algorithme (déconnexions, latences)

Sprint 2 : 12/02 --> 23/02 : Prototype logiciel #2 et prototype matériel
*Création du programme embarqué (utilisateur)
*Communication avec la racine et le serveur
*Création des maquettes boîtier et balise
*Construction des maquettes
*Finalisation du premier prototype

Sprint 3 : 26/02 --> 09/03 : Fonctionnalités supplémentaires
*Ajout de la communication entre le LoRa et le GSM sur la balise racine
*Création application mobile utilisateur
*Tests sur l'application
*Tests sur la transmission totale depuis l'utilisateur vers le serveur via le GSM
*Finalisation du projet

Sprint 4 : 12/03 --> 16/03 : Fin du projet
*Création de la documentation finale (à partir de la documentation réalisée en continu)
*Pause café
*Temps supplémentaire en cas de problèmes importants
*Préparation de la soutenance