Fili ere Informatique Projet de Bachelor Rapport :...

110
Fili` ere Informatique Projet de Bachelor 2017 Rapport : RMMA Resident Monitoring Mobile App Etudiant : Aur´ elien Etienne Superviseurs : Pascal Bruegger Fran¸ cois Kilchoer Expert : Marc Wuergler Fribourg, juillet 2017

Transcript of Fili ere Informatique Projet de Bachelor Rapport :...

Page 1: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Filiere Informatique

Projet de Bachelor

2017

Rapport :

RMMA

Resident Monitoring Mobile App

Etudiant :

Aurelien Etienne

Superviseurs : Pascal BrueggerFrancois Kilchoer

Expert : Marc Wuergler

Fribourg, juillet 2017

Page 2: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017
Page 3: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Historique

Version Date Auteur(s) Modifications

1.0 14/07/2017 Aurelien Etienne Rapport final0.3 03/07/2017 Aurelien Etienne Implementation des objectifs primaires0.2 16/06/2017 Aurelien Etienne Conception des objectifs primaires0.1 07/06/2017 Aurelien Etienne Analyse des objectifs primaires

1

Page 4: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017
Page 5: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Table des matieres

1 Introduction 51.1 Contexte du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2 Contexte de realisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3 Gestion des documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.4 Gestion du code source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.5 Planification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.6 Structure du rapport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Analyse 72.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 Etat de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3.1 Fade : fall detector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3.2 FallSafety Pro - Fall Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3.3 EgiGeoZone Geofence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.4 Geofency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.5 Moniteur Frequence Cardiaque et Frequence Cardiaque+ . . . . . . . . . . . . . 112.3.6 Runtastic Pro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.7 Google Fit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.8 Patient Data Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.9 Synthese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4 Specification de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.6 Choix de la plateforme de developpement . . . . . . . . . . . . . . . . . . . . . . . . . . 162.7 Communication entre l’application mobile et le serveur . . . . . . . . . . . . . . . . . . . 162.8 Generation d’alarmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.9 Localisation d’un resident . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.9.1 Geolocalisation d’un resident . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.9.2 Georeperage du resident . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.10 Suivi d’activite d’un resident . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.10.1 PathSense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.10.2 ActivityRecognitionAPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.10.3 Comparatif suivi d’activite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.11 Recuperation de la frequence cardiaque . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.11.1 Ceinture Zephyr HxM Heart Rate Monitor BT . . . . . . . . . . . . . . . . . . . 262.11.2 Jawbone UP3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.12 Gestion de la prise de medicament . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.13 Messagerie resident-personnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.14 Detection de la chute d’un resident . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.15 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3 Conception 303.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.2 Maquettes de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.3 Diagrammes de sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.3.1 Connexion a l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2

Page 6: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

3.3.2 Deconnexion de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.3.3 Initialisation des capteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.3.4 Recuperation des donnees des capteurs . . . . . . . . . . . . . . . . . . . . . . . . 373.3.5 Capteur frequence cardiaque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.3.6 Geolocalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.3.7 Suivi d’activite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.3.8 Rappel de medicament . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.3.9 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.4 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.4.1 Gestion des capteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.4.2 Communication client-serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.4.3 Navigation de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.5 Communication entre l’application mobile et le serveur . . . . . . . . . . . . . . . . . . . 453.5.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.5.2 Client HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.5.3 JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.5.4 Definition des routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.6 Suivi de l’activite d’un resident . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.7 Recuperation de la frequence cardiaque d’un resident . . . . . . . . . . . . . . . . . . . . 513.8 Messagerie resident-responsable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4 Implementation 584.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.2 Vue de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.3 Communication entre l’application mobile et le serveur . . . . . . . . . . . . . . . . . . . 624.4 Localisation d’un resident . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.4.1 Mise en place de IndoorAtlas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.4.2 Utilisation de IndoorAtlas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.5 Generation d’alarmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.6 Suivi de l’activite d’un resident . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.6.1 Detection d’une inactivite suspecte . . . . . . . . . . . . . . . . . . . . . . . . . . 694.7 Recuperation de la frequence cardiaque d’un resident . . . . . . . . . . . . . . . . . . . . 70

4.7.1 Detection d’un probleme de frequence cardiaque . . . . . . . . . . . . . . . . . . 714.8 Gestion de la prise de medicament . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.9 Messagerie resident-personnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4.9.1 Reception d’un message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.9.2 Envoi d’un message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4.10 Detection de la chute d’un resident . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5 Tests et validations 745.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.2 Tests fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.2.1 Connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.2.2 Deconnexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.2.3 Mise a jour du resident . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.2.4 Envoi d’alarme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.2.5 Localisation d’un resident . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.2.6 Suivi d’activite d’un resident . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.2.7 Recuperation de la frequence cardiaque . . . . . . . . . . . . . . . . . . . . . . . 765.2.8 Gestion de la prise de medicament . . . . . . . . . . . . . . . . . . . . . . . . . . 785.2.9 Messagerie resident-personnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785.2.10 Detection de la chute d’un resident . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5.3 Tests utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

3

Page 7: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

6 Conclusion 806.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806.2 Objectifs atteints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806.3 Points d’ameliorations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806.4 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806.5 Remerciements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 816.6 Conclusions personnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 816.7 Contenu du CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 816.8 Declaration d’honneur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

A Annexes 88A.1 Logiciels et librairie utilises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

A.1.1 Android Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88A.1.2 GSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88A.1.3 OkHttp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88A.1.4 ActivityRecognitionApi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88A.1.5 IndoorAtlas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88A.1.6 TeXstudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88A.1.7 GanttProject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88A.1.8 Visual Paradigm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

A.2 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89A.3 Tests unitaire pour la frequence cardiaque . . . . . . . . . . . . . . . . . . . . . . . . . . 91A.4 Tests utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

4

Page 8: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017
Page 9: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

1 Introduction

1.1 Contexte du projet

De nos jours, les infirmiers (-eres), aide-soignants (es) ou educateurs (-trices) sont confronte(e)s a unnombre de patients ou de residents a s’occuper de plus en plus important. Dans les homes et les lieuxde residence pour personnes agees ou handicapees, le personnel est souvent en sous-effectif et la super-vision de ces personnes devient problematique. De plus, dans le cas des personnes agees, il est assezdifficile pour elles de passer d’une vie independante a une vie supervisee, assistee. L’idee est de donnerune certaine independance tout en monitorant les aspects securitaires comme une chute, une inactivitesuspecte ou, pour les personnes atteintes de la maladie d’Alzeimer, un mouvement hors du lieu de vie.

L’idee du projet ”Resident Monitoring Mobile App” est de realiser une application mobile permettantde suivre les mouvements des personnes dans le batiment et de generer des alarmes en cas de problemes.Le personnel soignant est alors immediatement prevenu et un systeme de priorite dans l’interventionest mis en place. Soit la personne de reference intervient ou alors, en cas de probleme plus grave, lapersonne la plus proche ou un medecin interviendront.

Le projet consiste en la mise en place d’un systeme avec une application interagissant avec un serveurqui centralise les informations de localisation des residents. Cette application mobile sera capable delocaliser et de detecter l’activite d’un resident. En cas de probleme avec un resident, l’applicationgenerera une alarme sur le serveur. L’application mobile sera capable de se connecter et d’envoyer lesinformations necessaires au serveur afin qu’il puisse prendre une decision d’intervention.

1.2 Contexte de realisation

RMMA (Resident Monitoring Mobile App) est une application mobile realisee dans le cadre du projetde Bachelor.Ce projet fait partie d’un projet plus vaste qui sera combine avec deux autres projets.

— Une application mobile HMMA (Health Monitoring Mobile App) qui est le pendant de l’appli-cation mobile RMMA pour le personnel soignant et qui recevra les alarmes.

— Un environnement intelligent SEMS (Smart Environment Monitor System) qui consiste en lamise en place d’un serveur pour la gestion des differents residents. Il permettra de recevoir etd’envoyer des requetes HTTP a l’application et centralisera les donnees par residents.

Figure 1.1 – Architecture du projet

5

Page 10: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

1.3 Gestion des documents

Toute la documentation realisee durant ce projet se trouve a l’adresse suivante :

https ://redmine.forge.hefr.ch/projects/resident-monitoring-mobile-app

1.4 Gestion du code source

La gestion des versions du code source, s’est faite a l’aide de Gitlab. Le code source se trouve a l’adressesuivante :

https ://gitlab.forge.hefr.ch/aurelien.etienne/RMMA-Code

1.5 Planification

Le planning est disponible a l’annexe A.2.

1.6 Structure du rapport

Ce rapport final contient les chapitres suivants :— Introduction : contient le contexte et la description du projet.— Analyse : contient l’etat de l’art, la specification de l’application, le diagramme de cas d’utilisa-

tion, ainsi que l’analyse des differents composants de l’application.— Conception : contient les maquettes, les diagrammes de sequences et de classes ainsi que la

conception des differents composants de l’application.— Implementation : contient les vues de l’application et des extraits du code source.— Tests et validations : contient les tests utilisateurs et fonctionnels.— Conclusion : contient les objectifs atteints, les points d’ameliorations et les perspectives futures.

6

Page 11: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

2 Analyse

2.1 Introduction

Ce chapitre a pour but d’analyser de facon detaillee les differents objectifs a realiser pour le projet.De part cette analyse, il sera possible d’extraire les specifications correspondantes afin de faciliter laphase de conception.

2.2 Contexte

L’application mobile ”Resident Monitoring Mobile App” fait partie d’un projet plus vaste combinantdeux autres projets :

— Une application mobile HMMA (Health Monitoring Mobile App) qui est le pendant de l’appli-cation mobile RMMA pour le personnel soignant.

— Un environnement intelligent SEMS (Smart Environment Monitor System) qui consiste en lamise en place d’un serveur pour la gestion des residents. Il dispose d’un serveur permettant derecevoir et d’envoyer des requetes HTTP aux applications.

Comme dit precedemment, l’application mobile RMMA s’occupe principalement de recuperer des infor-mations sur le resident (localisation, frequence cardiaque, activite). Ces informations sont envoyees defacon continue au serveur SEMS. L’application mobile RMMA s’occupe aussi de detecter et de trans-mettre des alarmes au serveur SEMS quand il y a un probleme avec le resident (frequence cardiaque,inactivite suspecte, chute).Le serveur SEMS s’occupe lui, de la gestion de la geolocalisation des residents et du personnel ettransmets les alarmes recues par les residents a une personne du personnel soignant en fonction decertains criteres (personne de reference, proximite, competence).L’application mobile HMMA s’occupe principalement de la gestion des residents et de traiter les alarmesrecues du serveur SEMS.

Figure 2.1 – Gestion des alarmes

7

Page 12: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

Les trois differents projets utilisent la geolocalisation, RMMA pour la geolocalisation d’un resident,HMMA pour la geolocalisation d’un employe du personnel soignant et SEMS pour envoyer les alertesen fonction de la position du resident et des employes du personnel soignant. Pour cette raison, uneresidence fictive a ete creee en commun entre les trois projets. Cette residence sera utilisee pour testerle bon fonctionnement de la geolocalisation pour les differents projets. Cette residence comporte lessalles suivantes :

1. Chambre pour resident2. Chambre pour resident3. Chambre pour resident4. Chambre pour resident5. Chambre pour resident6. Espace de vie pour les residents7. Local pour le personnel soignant

Figure 2.2 – Schema de la residence

8

Page 13: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

2.3 Etat de l’art

L’etat de l’art permettra de faire un etat des lieux des applications existantes ayant un rapport avecle projet RMMA. L’etat de l’art couvrira les fonctionnalites de detection de chute, de georeperage, desuivi d’activite et de recuperation de la frequence cardiaque.

2.3.1 Fade : fall detector

Fade [1] est une application mobile pour Android capable de detecter la chute d’une personne enutilisant les informations de certains capteurs du telephone mobile comme l’accelerometre.Fade permet de configurer un systeme d’alerte. En cas de chute, l’application peut envoyer une alertepar SMS, appel ou E-mail a une personne de contact. L’alerte transmet des informations sur l’heureet la localisation.

Figure 2.3 – Application mobile Fade fall detector

2.3.2 FallSafety Pro - Fall Detection

FallSafety Pro [2] est une application mobile pour Android et IOS permettant de detecter la chuted’une personne. Elle peut envoyer une alerte par SMS, appel ou E-mail a une personne de contact.FallSafety Pro s’adresse essentiellement aux entreprises ayant des employes qui ont des risques dechutes sur leur place de travail. Il offre une plateforme web permettant de visualiser en temps reel lasituation de chaque employe.

Figure 2.4 – Plateforme web FallSafety Pro

9

Page 14: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

2.3.3 EgiGeoZone Geofence

EgiGeoZone Geofence [3] est une application mobile pour Android de georeperage qui offre a sesutilisateurs la possibilite de declencher diverses actions lors de l’entree ou la sortie de zones predefinies.Les actions suivantes peuvent etre declenchees :

— Controle de serveur domotique— Coordination pour le covoiturage— Activation / desactivation du Bluetooth— Gestion de la tonalite du telephone mobile

Figure 2.5 – Application mobile EgiGeoZone

2.3.4 Geofency

Tout comme EgiGeoZone[3], Geofency [4] est une application mobile pour IOS de georeperage quioffre a ses utilisateurs la possibilite de declencher diverses actions lors de l’entree ou la sortie de zonespredefinies. Les actions suivantes peuvent etre declenchees :

— Controle de serveur domotique— Visualisation du temps passe dans une zone definie

Figure 2.6 – Application mobile Geofency

10

Page 15: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

2.3.5 Moniteur Frequence Cardiaque et Frequence Cardiaque+

Moniteur Frequence Cardiaque [5] est une application mobile pour Android et Frequence Cardiaque+sont equivalent pour IOS. Ce sont deux applications mobiles permettent de mesurer la frequencecardiaque en utilisant le capteur de l’appareil photo du telephone mobile. L’application utilise l’appareilphoto pour suivre les changements de couleur sur le bout des doigts de l’utilisateur qui sont directementlies a son pouls.

Figure 2.7 – Application mobile Moniteur Frequence Cardiaque

2.3.6 Runtastic Pro

Runstatic Pro [6] est une application mobile pour Android qui permet de connecter une ceinture decapteur de frequence cardiaque. L’application utilise le Bluetooth pour communiquer avec la ceinture.

Figure 2.8 – Application mobile Runtastic Pro

11

Page 16: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

2.3.7 Google Fit

Google Fit [7] est une application mobile pour Android qui permet de suivre l’activite d’un utilisateur.Avec les donnees traquees, l’application offre des statistiques par rapport a l’activite de l’utilisateur(sessions de courses, marches, sorties a velo).

Figure 2.9 – Application mobile Google Fit

2.3.8 Patient Data Viewer

Patient Data viewer [8] est une application mobile faite pour le personnel soignant, l’application mobilecommunique avec un serveur qui stocke des informations sur des patients.Le concept est assez semblable a ce projet, le patient porte sur lui des capteurs (frequence cardiaque,temperature, pression sanguine, ...). Les donnees des capteurs sont ensuite transmises a un controleur,qui lui s’occupe de transmettre les donnees au serveur central. Le serveur central emet des alarmesaux docteurs en cas de necessite. Une fois l’alarme emise, le docteur recoit une notification sur sontelephone mobile.

Figure 2.10 – Application mobile Patient Data Viewer [8]

12

Page 17: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

2.3.9 Synthese

Jusqu’a present, il n’y a pas d’equivalent au projet RMMA. Cependant plusieurs applications mobilesproposent certaines fonctionnalites semblables (georeperage, recuperation de la frequence cardiaque,suivi d’activite, detection d’une chute).L’application la plus semblable au projet RMMA est l’application ”Patient Data Viewer”, celle-ci offreun suivi pour le medecin de ses patients et une generation d’alerte en cas de probleme avec un patient.Cependant, cette application ne prend pas en compte la localisation du patient et du medecin. De plus,le patient n’est affilie qu’a un seul medecin.L’application mobile RMMA couplee aux projets SEMS et HMMA est une idee innovante pour lasurveillance et gestion de resident.

2.4 Specification de l’application

La specification permet de decrire les exigences generales du cahier des charges. L’application doitoffrir les fonctionnalites suivantes :

Communication entre l’application mobile et le serveur : L’application mobile doit pouvoircommuniquer avec le serveur et lui transmettre les informations du resident (sa localisation, son acti-vite, sa frequence cardiaque) de facon continue et recevoir des messages du serveur (pour la prise demedicaments).

Generation d’alarmes : L’application mobile doit pouvoir envoyer des alarmes au serveur lorsqu’unresident fait une chute, a un probleme avec sa frequence cardiaque et lorsqu’un resident a une activitesuspecte.

Localisation d’un resident : L’application mobile doit etre capable de localiser en continu unresident et transmettre ses informations au serveur.

Suivi de l’activite d’un resident : L’application mobile doit pouvoir suivre l’activite d’un resident.L’activite principale a detecter est le fait qu’un resident soit immobile durant une certaine periode detemps, ce qui peut signifier que le resident peut avoir un probleme.

Georeperage d’un resident : L’application mobile doit etre capable de detecter lorsqu’un residentsort d’une zone predefinie. Le georeperage peut aussi etre realise cote serveur.

Recuperation frequence cardiaque : L’application mobile doit etre capable de recuperer lafrequence cardiaque d’un resident et de transmettre les informations au serveur.

Detection de la chute d’un resident : L’application mobile doit pouvoir detecter la chute d’unresident et envoyer une alarme au serveur avec la position GPS du resident.

Gestion de la prise de medicaments d’un resident : L’application mobile doit pouvoir recevoirdes notifications de rappel pour la prise de medicament. Le resident peut indiquer que les medicamentsont ete pris, une reponse est transmise au serveur.

Messagerie entre le resident et la personne responsable du resident : L’application mobiledoit offrir un systeme de messagerie basique entre le resident et son responsable. Cette messageriepermet au responsable du resident de lui transmettre des messages, l’application mobile du residentdoit offrir un moyen simple de reponse.

13

Page 18: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

2.5 Diagramme de cas d’utilisation

Se connecter

Consulter les informationsdes capteurs

Activer un capteurDésactiver un capteur

extension points

Consulter la liste des capteurs

Accéder à la messagerie

Répondre à un message

Répondre à un rappel de médicament

Se déconnecter

Désactiver un capteur

Activer un capteur

Résident

Utilisateur

<<Extend>>

<<Extend>>

Visual Paradigm Standard Edition(Ecole d'ingenieurs et d'architectes de Fribourg)

Figure 2.11 – Diagramme de cas d’utilisation

Se connecter : Ce cas d’utilisation permet a un utilisateur de se connecter a l’application mobile.

Se deconnecter : Ce cas d’utilisation permet a un resident de se deconnecter de l’application mobile.

Consulter les informations des capteurs : Ce cas d’utilisation permet au resident d’acceder auxinformations des divers capteurs utilises.

Activer un capteur : Ce cas d’utilisation permet au resident d’activer un capteur.

Desactiver un capteur : Ce cas d’utilisation permet au resident de desactiver un capteur.

Consulter la liste des capteurs : Ce cas d’utilisation permet au resident de consulter la liste descapteurs connectes/deconnectes, et de les connecter/deconnecter.

Acceder a la messagerie : Ce cas d’utilisation permet au resident d’acceder a la messagerie etd’envoyer un message simple a son responsable.

Repondre a un message : Ce cas d’utilisation permet au resident de repondre a un message envoyepar un responsable.

Repondre a un rappel de medicament : Ce cas d’utilisation permet au resident de valider laprise de medicaments.

14

Page 19: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

2.6 Choix de la plateforme de developpement

Le tableau 2.1 represente le comparatif des differentes plateformes de developpement pour l’applicationmobile.

Points de comparaison Android IOS XamarinCross-plateforme non non ouiCode partage non non ouiContraintes materiel aucune oui ouiTemps de developpement bon bon moyenAisance dans ledeveloppement

oui moyen moyen

Table 2.1 – Choix plateforme de developpement

L’application mobile sera developpee sur Android pour les raisons suivantes :— Une ceinture pour la recuperation de la frequence cardiaque est fournie pour le projet. Cette

ceinture a une API qui n’est disponible que sur Android, ce qui necessiterait le developpementd’un equivalent pour IOS ou pour la version IOS de Xamarin.

— L’interet principal de l’utilisation de Xamarin est d’avoir une partie de code partage entre lesplateformes de developpement (Android et IOS), ce qui n’est pas le cas dans ce projet etantdonne que le suivi d’activite et la recuperation de la frequence ne peuvent pas faire partie ducode commun.

— Le developpement cross-plateforme avec Xamarin necessite l’emploi de plus d’outils, ce qui com-plique et rallonge le developpement.

2.7 Communication entre l’application mobile et le serveur

Le serveur ”SEMS” met a disposition un serveur avec une architecture REST.

REST (Reprensentational State Transfer) est un style d’architecture permettant de construire desapplications Web, Intranet et des Web Service. Les caracteristiques principales de REST sont lessuivantes [9] :

— application client/serveur : le transport sur le reseau est assure par HTTP— interface uniforme : les elements offerts par le serveur sont nommes et sont identifies de maniere

unique par les URI (Uniform Ressource Identifier).

Deux types de schemas d’URI sont distingues :— URI member : une URI designant une seule ressource— URI collection : une URI designant une liste de ressources de meme type.

La semantique des messages transmis par le client au serveur est celle de HTTP :— GET URI : recuperer la representation d’une ressource (member) ou d’une liste de ressources

(collection).— POST URI (collection) : ajout d’une ressource a une liste de ressources.— PUT URI (member) : modifier une ressource existante ou ajouter une nouvelle ressource.— DELETE URI : destruction d’une ressource (member) ou de plusieurs ressources (collection).

Les reponses du serveur aux clients utilisent egalement les messages HTTP, en particulier les codessuivants :

— 200 : La requete est un succes.— 201 : La requete est un succes et la ressource a ete creee.— 404 : La ressource n’est pas trouvee.

15

Page 20: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

Le tableau 2.2 est un exemple de schemas URI pour un serveur REST.

VerbeHTTP

Schema URI Explications

GET http ://server/persons Recupere la liste de toutes les personnesGET http ://server/persons/id person Recupere la personne identifiee par id personPOST http ://server/persons/ Ajoute une nouvelle personnePUT http ://server/persons/id person Modifie la personne identifiee par id personDELETE http ://server/persons/id person Efface la personne identifiee par id person

Table 2.2 – Exemple de schemas URI

Pour communiquer avec le serveur REST du projet ”SEMS”, l’application mobile doit avoir un clientHTTP. Un client HTTP est un logiciel concu pour communiquer avec un serveur HTTP.

Figure 2.12 – Architecture du projet

Lorsque le serveur REST recoit une requete de type GET, le format dans lequel la ressource estrepresentee est obtenu par negociation grace aux entetes HTTP. Le client indique le format qu’ilsouhaite dans l’entete HTTP ”Accept”. Le client et le serveur utilisent l’entete ”Content-type” pourdefinir le format de representation de la ressource. Le serveur REST du projet ”SEMS” utilise le formatde donnees JSON pour la representation de ressources.JSON est un format de donnees, il permet de representer de l’information de facon structuree. Il permetde representer les deux types de ressources (member, collection).

Figure 2.13 – Exemple JSON ressource member

16

Page 21: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

Figure 2.14 – Exemple JSON ressources collection

2.8 Generation d’alarmes

La generation d’alarmes est utilisee dans ce projet pour envoyer des informations au serveur ”SEMS”lorsque le resident a un probleme (de frequence cardiaque, inactivite suspecte, fait une chute).Lorsque l’application mobile detecte un probleme avec le resident, une alerte est envoyee au serveur”SEMS”. Le message est envoye a l’aide du client HTTP de l’application mobile.

2.9 Localisation d’un resident

La localisation est utilisee dans ce projet, pour fournir au serveur de facon continue la position duresident a l’interieur de la residence, le georeperage permettra quant a lui de detecter lorsqu’un utili-sateur sort de la residence.

2.9.1 Geolocalisation d’un resident

La geolocalisation est utilisee dans ce projet, pour fournir au serveur de facon continue la position duresident.Android fournit des outils pour localiser un appareil mobile. Android permet de geolocaliser untelephone mobile de deux manieres differentes. La premiere utilise le GPS, qui permet une locali-sation precise mais qui est plus couteuse en batterie. La deuxieme utilise les points d’acces WI-FI aproximite et la distance mesuree avec les antennes relais du reseau mobile les plus proches (par trian-gulation).

La geolocalisation par GPS pose un probleme lorsqu’elle est faite a l’interieur d’un batiment, car lescomposants GPS peuvent recevoir un signal insuffisant ce qui va rendre la geolocalisation inutilisable.De plus, le GPS ne permet pas de se localiser a l’interieur d’un batiment a plusieurs etages. Pourpallier a ces problemes, il existe la geolocalisation indoor. Ci-dessous sont presentees succinctement,les technologies disponibles pour faire de la geolocalisation indoor ainsi que les API disponible.

Localisation par mesure du RSS (Received Signal Strength) :

La technique de positionnement par point d’acces Wi-Fi est basee sur la mesure de l’intensite du signalrecu (Received Signal Strength ou RSS) et sur la methode d’empreinte. Une empreinte est constitueedu RSS, du SSID du point d’acces, et de l’adresse MAC du routeur. Il n’est pas necessaire de seconnecter au reseau. Un ping est suffisant pour determiner la force du signal.L’appareil consulte ensuite une base de donnees distante pour faire l’association entre l’empreinte etla position. La precision du positionnement depend du nombre de positions enregistrees dans la base

17

Page 22: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

de donnees. [10]

Figure 2.15 – Localisation par mesure du RSS

Localisation avec des beacons :

Un beacon est un peripherique qui diffuse un signal en utilisant le Bluetooth Low Energy.

Figure 2.16 – Beacons de la marque Estimote[11]

Le signal est envoye a intervalle regulier dans un perimetre definit, il contient les informations suivantes :— proximity UUID : Un identifiant unique pouvant representer le fabricant, l’application ou le

proprietaire. (ex : musee)— major : Une information permettant d’identifier un groupe de beacons. (ex : salle d’un musee )— minor : Une information permettant d’identifier un beacon. (ex : sculpture se trouvant dans une

salle d’un musee)

Avec les donnees transmises par les beacons, l’application mobile peut trouver sa localisation.La technologie beacons peut etre utilisee pour faire de la localisation, mais est plus adaptee pour fairedu georeperage.

Localisation par champs magnetique :

La localisation par champs magnetique se base sur le fait que les batiments modernes ont tous unpaysage magnetique unique produit par le champ magnetique de la Terre qui interagit avec l’acieret les autres materiaux trouves dans les structures des batiments. Un telephone mobile, equipe d’uneboussole peut utiliser le champs magnetique a l’interieur d’un batiment comme une carte pour localiseret suivre le deplacement d’une personne [12].Pour fonctionner, la localisation par champs magnetique a besoin d’une phase de calibration.La localisation par champs magnetique peut aussi etre utilisee pour faire du georeperage.

18

Page 23: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

Figure 2.17 – Champs magnetique dans un batiment [13]

API disponible de localisation interieure :

Il existe differentes API disponibles pour faire de la localisation interieure, les principales sont :— Anyplace [14] est un service de localisation d’interieure qui combine la localisation par mesure

du RSS et la navigation inertielle pour localiser un utilisateur.— IndoorAtlas [15] est un service de localisation d’interieur qui combinent la localisation par champs

magnetique, la localisation par mesure du RSS et la localisation par Beacons.— Redpin [16] est un service de localisation d’interieur qui utilise la localisation par mesure du RSS.— Estimote Indoor Location [17] est un service de localisation d’interieur utilisant la localisation

par beacon.

IndoorAtlas sera utilise pour le projet, car il permet d’obtenir une tres bonne precision de la loca-lisation en combinant differentes technologies (WI-FI, champs magnetique, Beacon). IndoorAtlas aaussi l’avantage de fournir une application Android permettant de faire la calibration du batimentaisement. Pour le projet la localisation d’interieure combinera la localisation par WI-FI et par champsmagnetique, ceci a l’avantage de ne necessite aucun materiel.

2.9.2 Georeperage du resident

Le georeperage consiste a utiliser la position GPS ou l’identification par radiofrequence (RFID) pourdefinir une limite geographique. Ensuite, une fois que cette ”barriere virtuelle” est etablie, il est possiblede definir des evenements (envoi de message, email, notification) a l’entree ou a la sortie de la zone[18].

Figure 2.18 – Georeperage [19]

19

Page 24: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

Le georeperage est utilise dans ce projet, pour permettre aux responsables des residents d’avoir uneinformation lorsqu’un resident sort du lieu de vie.

Deux options sont envisagees pour le georeperage d’un resident, soit le realiser du cote du telephone mo-bile ou du cote du serveur. Ci-dessous est presente, une liste d’API permettant de faire du georeperagecote telephone mobile.

PathSense

PathSense propose une solution alternative au GPS permettant une meilleure precision dans la locali-sation et la gestion de la batterie du telephone mobile.PathSense offre un kit de developpement de logiciel, incluant les fonctionnalites suivantes :

— Georeperage (Android)— Suivi d’activites (Android)— TruePath (Android et IOS)

PathSense commence par recuperer les coordonnees GPS du telephone mobile pour son initialisationpuis se base sur plusieurs techniques de localisation comprenant la fusion de capteurs et la navigationinertielle. Il utilise la variete de capteurs transmettant des donnees de localisation dont sont dotes lestelephones mobiles. Ces donnees sont ensuite mises en contexte a travers la navigation inertielle quiest utilisee afin de determiner le mouvement d’un vehicule ou d’une personne, grace a sa vitesse et sonacceleration [20].PathSensse offre un kit de developpement de logiciel ”Android Geofencing SDK” qui propose les classessuivantes :PathsenseLocationProviderApi : Cette classe est le point d’entree pour interagir avec l’API de geo-reperage. Elle permet en outre d’ajouter et de supprimer des zones geographiques a surveiller.

Une zone est definit par un centre (latitude, longitude) et un rayon.

PathsenseGeofenceEvent : Cette classe represente un evenement de la classe ”PathsenseLocationPro-viderApi”. L’evenement peut etre :

— Un evenement lors de l’entree dans la zone geographique.— Un evenement lors de la sortie de la zone geographique.

PathsenseGeofenceEventReceiver : Cette classe permet de recuperer les evenements lors de l’entree oula sortie d’une zone.

Geofences

Geofences est inclus dans le kit de developpement de logiciel fournit par Android. Il utilise le GPSpour localiser le telephone mobile.Geofences propose les classes suivantes :

GeofencingApi : Cette classe est le point d’entree pour interagir avec l’API de georeperage. Elle permeten outre d’ajouter et de supprimer des zones geographiques a surveiller.

GeofencingEvent : Cette classe represente un evenement de la classe ”GeofencingApi”. L’evenementpeut etre :

— Un evenement lors de l’entree dans la zone geographique.— Un evenement lors de la sortie de la zone geographique.— Une erreur apres qu’une zone delimitee ait ete creee et pendant sa surveillance.

Georeperage cote serveur

Le serveur dispose d’une liste de batiments et de salles avec pour chacun la liste de leurs coordonneesGPS pour chaque extremites. Le serveur recevant les coordonnees GPS d’un resident peut gerer legeoreperage.

20

Page 25: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

Comparatif Georeperage

Le georeperage peut aussi etre effectue a l’aide de la localisation par beacons 2.9.1 et la localisationpar champs magnetique 2.9.1.Le tableau 2.3 represente le comparatif des differents moyens pour realiser le georeperage d’un resident.

Points de compa-raison

PathSense Geofences Cote ser-veur

Beacon Champsmagnetique

Consommationbatterie

faible gourmande - faible faible

Zone cercle cercle aucunerestriction

aucunerestriction

aucunerestriction

Taille minimalede la zone

50m derayon

100m derayon

aucunerestriction

aucunerestriction

aucunerestriction

Compatibilite Android Android Cross-plateforme

Cross-plateforme

Cross-plateforme

Besoin materiel - - - beacons -Precision GPS* GPS* Depend de la

localisationMoins de 4m Moins de 2m

Etage d’unbatiment

Non Non Depend de lalocalisation

Oui Oui

Table 2.3 – Comparatif georeperage

* GPS : l’utilisation du GPS a l’interieur d’un batiment n’offre pas une precision acceptable.Le georeperage se fera du cote serveur etant donnee qu’il n’y a pas de restriction sur la forme et lataille de la zone definie. De plus, l’application uMove cote serveur permet de trouver l’emplacementd’un resident dans un batiment, une salle, ce qui permet aisement de faire du georeperage.La compatibilite cross-plateforme est aussi un avantage certain, cela evitera de developper pour chaqueplateforme un systeme de georeperage.

21

Page 26: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

2.10 Suivi d’activite d’un resident

Le suivi d’activite est utilise dans le cadre de ce projet pour detecter une inactivite suspecte d’unresident, mais aussi pour avoir des informations supplementaires pour le calcul de la frequence car-diaque.

2.10.1 PathSense

PathSense est decrit dans la section 2.9.2.

PathSense offre une API pour le suivi d’activite pour Android, il est possible de detecter les activitessuivantes :

— En vehicule— A pied— Immobile— Inclinaison

Le kit de developpement de logiciel ”Android Activity SDK” offre les classes suivantes :

PathsenseDetectedActivity : Cette classe permet de recuperer l’activite detectee du telephonemobile avec un niveau de confiance.

PathsenseDetectedActivityEnum : Cette enumeration definit les types d’activites que PathSensereconnaıt.

2.10.2 ActivityRecognitionAPI

ActivityRecognitionAPI est une API fournit par Google pour faire du suivi d’activite pour Android.L’API lit periodiquement les valeurs de certains capteurs pour detecter l’activite de l’utilisateur. L’APIutilise des capteurs a faible consommation pour economiser la batterie du telephone mobile.

— En vehicule— En velo— A pied— En train de courir— Immobile— Inclinaison

ActivityRecognitionAPI fournit les classes suivantes :

ActivityRecognitionApi : Cette classe est le point d’entree pour interagir avec l’API de suivid’activite.

ActivityRecognitionResult : Cette classe permet de recuperer l’activite la plus probable de l’uti-lisateur avec un indice de confiance.

DetectedActivity : Cette classe liste les differentes activites pouvant etre detectees.

2.10.3 Comparatif suivi d’activite

Le tableau 2.4 represente le comparatif des differents moyens pour realiser le suivi d’activite d’unresident.

22

Page 27: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

Points de comparaison PathSense Activity Recog-nitionApi

Consommation batterie faible moyenneActivite detectee : immobile oui ouiActivite detectee : a pied oui ouiActivite detectee : en velo non ouiActivite detectee : en train de courir non ouiActivite detectee : en voiture oui ouiActivite detectee : incline oui oui

Table 2.4 – Comparatif suivi d’activite

ActivityRecognitionAPI sera utilise pour le projet, car il permet de detecter toutes les activitesnecessaires au projet (immobile, a pied, en train de courir).L’activite ”en train de courir” est importante car elle permettra une meilleure evaluation de la frequencecardiaque du resident. L’activite ”en velo” est aussi interessante du fait qu’elle a aussi une influencesur la frequence cardiaque du resident.

2.11 Recuperation de la frequence cardiaque

La frequence cardiaque est le nombre de battements cardiaques (ou pulsations) par minute. Le poulsdesigne la perception au toucher de l’artere battante permettant d’evaluer les battements cardiaques.Le rythme cardiaque designe la maniere avec laquelle s’effectue une revolution cardiaque, la manieredont les cycles se succedent. La frequence cardiaque donne une information quantitative, alors que lerythme cardiaque donne une information qualitative [21].

Avec la frequence cardiaque, il est donc possible de detecter lorsque le pouls d’une personne est troprapide ou trop lent. Cela, peut entrainer par exemple, des problemes de tachycardie et de bradycardie.

La tachycardie est une acceleration du rythme cardiaque. La frequence cardiaque est controlee pardes signaux electriques envoyes a travers les tissus cardiaques. La tachycardie survient quand uneanomalie du coeur produit des signaux electriques plus rapides que la normale. Dans certains cas, unetachycardie peut ne causer aucun symptome ou complication. Toutefois, une tachycardie peut aussigravement perturber la fonction cardiaque normale, augmentant ainsi le risque d’accident vasculairecerebral ou provoquant un arret cardiaque soudain et meme la mort. Lorsque le rythme cardiaqueest trop rapide, le coeur ne peut pas pomper efficacement le sang vers le reste du corps, ce qui privecertains organes et certains tissus de l’oxygene dont ils ont besoin, cela peut entraıner les symptomessuivants [22] :

— Des vertiges— Des etourdissements— Des douleurs a la poitrine— Des evanouissements

La bradycardie se caracterise par un rythme cardiaque trop bas par rapport a la normale. Elle estopposee a la tachycardie. Lors d’une bradycardie, le cœur n’apporte plus assez d’oxygene a l’organisme.Ce qui peut entrainer les symptomes suivants [23] :

— Une fatigue extreme— Des etourdissements— Des malaises— Une impression que le coeur va s’arreter

La frequence cardiaque varie en fonction de plusieurs parametres, mais principalement en fonction del’age et de l’activite de la personne.Le tableau 2.5 represente l’intervalle des frequences cardiaques acceptables pour une personne enfonction de son age au repos.

23

Page 28: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

Age Frequence cardiaqueNouveau-ne 140 +/- 501–2 ans 110 +/- 403–5 ans 105 +/- 356–12 ans 95 +/- 30adolescent ou adulte 70 +/- 10personne agee 65 +/- 5

Table 2.5 – Frequence cardiaque par age au repos [21]

Pour une activite physique d’intensite moderee (ce qui correspond a de la marche), le rythme cardiaqued’une personne devrait etre de 50% a 70% de son rythme cardiaque maximum. Pour une activitephysique intense (ce qui correspond a de la course a pied), le rythme cardiaque d’une personne devraitetre de 70% a 80%.Le rythme cardiaque maximal d’une personne peut etre calcule de la facon suivante :

220 - l’age de la personne

Le tableau 2.6 represente l’intervalle des frequences cardiaques acceptables pour une personne enfonction de son age lorsqu’elle marche.

Age Frequence cardiaque10 ans 110-14520 ans 100-14030 ans 95-13340 ans 90-12650 ans 85-11960 ans 80-11270 ans 75-10580 ans 70-9890 ans 65-91100 ans 60-84

Table 2.6 – Frequence cardiaque par age durant une marche

Le tableau 2.7 represente l’intervalle des frequences cardiaques acceptables pour une personne enfonction de son age lorsqu’elle court.

Age Frequence cardiaque10 ans 145-16820 ans 140-16030 ans 133-15240 ans 126-14450 ans 119-13660 ans 112-12870 ans 105-12080 ans 98-11290 ans 91-104100 ans 84-96

Table 2.7 – Frequence cardiaque par age durant une course a pied

24

Page 29: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

2.11.1 Ceinture Zephyr HxM Heart Rate Monitor BT

La ceinture Zephyr [24] peut se connecter en Bluetooth 2.0 a un telephone mobile et offre des capteurspermettant de mesurer :

— La frequence cardiaque :— Le nombre de calories utilisees— La vitesse— La distance parcourue

Figure 2.19 – Ceinture Zephyr HxM Heart Rate Monitor BT [24]

Pour se connecter a la ceinture Zephyr, les etapes suivantes sont necessaires [25] :1. Activer le service Bluetooth sur le telephone mobile.2. Rechercher les peripheriques Bluetooth disponibles.3. Pairing avec le peripherique HxM.4. Decouverte des services proposes par le peripherique HxM.5. Connexion au serial port service du peripherique HxM.

Le pairing est utilise pour definir la toute premiere connexion Bluetooth entre les deux peripheriques.Ceci permet aux appareils de s’identifier et de creer une connexion unique et permanente entre lesdeux peripheriques.La ceinture Zephyr HxM offre un le serial port service. Ce service Bluetooth est ideal pour l’envoi demultiples donnees entre plusieurs peripherique. Avec ce service, deux peripheriques peuvent envoyer etrecevoir des donnees comme si des lignes RX et TX existaient entre eux.

API ceinture Zephyr

Zephyr fournit une API disponible sur Android. Cette API permet de faciliter la communicationBluetooth entre le peripherique HxM et une application mobile. L’API fournit des classes et methodespour la gestion de la connexion et de la communication entre le telephone mobile et le peripheriqueHxM. L’API offre aussi des classes et methodes pour la lecture et ecriture des donnees envoyees etrecues.

2.11.2 Jawbone UP3

Le bracelet Jawbone UP3 [26] est un bracelet d’activite qui est equipe d’un capteur de frequencecardiaque. Il peut se connecter a une application mobile en utilisant le Bluetooth Low Energy. Il offredes capteurs permettant de recuperer les donnees suivantes :

— frequence cardiaque— nombre de pas— distance parcourue— altitude— respiration— temperature de la peau et temperature ambiante

25

Page 30: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

Figure 2.20 – Bracelet Jawbone UP3 [26]

La ceinture Zephyr etant une contrainte materiel est utilisee pour le projet.

2.12 Gestion de la prise de medicament

Le rappel de la prise de medicament permet a un resident de recevoir une notification lorsqu’il a unmedicament a prendre. Pour demarrer une action a un temps defini, Android fournit un gestionnaired’alarmes. Le gestionnaire d’alarmes permet d’ajouter et de supprimer des evenements a un momentprecis.

2.13 Messagerie resident-personnel

La messagerie entre un resident et un membre du personnel medical permet au resident de transmettreun message predefini a un responsable du personnel medical si une assistance est necessaire. Un membredu personnel medical peut aussi transmettre un message avec des reponses predefinies a un resident.Le serveur du projet ”SEMS” met a disposition un serveur PUSH pour l’envoi de donnees entre lesapplications mobiles. Le serveur du projet ”SEMS” utilise Firebase Cloud Messaging pour l’envoi denotifications PUSH.Firebase Cloud Messaging (FCM) est une solution de messagerie multi-plateforme fournie par Google.FCM permet d’envoyer des notifications. L’interet d’utiliser un serveur de PUSH vient du fait que c’estle serveur qui contacte le client.Pour fonctionner FCM definit les informations suivantes :

— Sender ID : une valeur numerique unique assignee a la creation du projet Firebase. Cette id estutilisee pour identifier quelle application serveur peut envoyer des notifications a un client.

— API Key : une cle qui donne au serveur l’acces au service de Firebase.— App ID : l’identifiant de l’application cliente.— Registration Token : un jeton d’enregistrement unique pour l’application cliente d’un telephone

mobile.

Pour recevoir des notifications, une application mobile doit en premier lieu s’enregistrer sur le serveurFCM.L’enregistrement d’un client sur Firebase Cloud Messaging fonctionne de la facon suivante :

1. L’application cliente contacte le serveur FCM en lui transmettant les informations necessaires(sender ID, API KEY, App ID) pour obtenir un jeton d’enregistrement

2. Le serveur FCM retourne un jeton d’enregistrement.3. (Optionnel) L’application cliente transmet son jeton d’enregistrement au serveur.

Le fait de transmettre le jeton d’enregistrement au serveur, lui permettra de faire des notificationspersonnalisees (par client, par groupe de client).

26

Page 31: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

Figure 2.21 – Fonctionnement Firebase Cloud Messaging [27]

Pour envoyer des notifications a ses clients, FCM fonctionne de la facon suivante :1. L’application serveur transmet le message au serveur FCM.2. Si le client n’est pas disponible, le message est stocke.3. FCM transmet la notification a l’application cliente.4. L’application cliente affiche la notification.

Figure 2.22 – Envoi de notifications avec Firebase Cloud Messaging [27]

2.14 Detection de la chute d’un resident

Pour la detection de la chute d’un resident, l’accelerometre du telephone mobile peut etre utilise.Android offre la possibilite de recuperer deux types d’acceleration :

— Accelerometre : mesure l’acceleration sur les trois axes (x,y,z) appliquee au telephone en prenanten compte la force de gravite.

27

Page 32: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

— Accelerometre lineaire : mesure l’acceleration sur les trois axes (x,y,z) en excluant la force degravite.

L’accelerometre qui prend en compte la gravite peut etre utilise pour detecter la chute d’un resident.Lorsque le telephone mobile est pose sur une table et ne subit aucune acceleration, l’accelerometre litune grandeur de g = 9,81 m/s2. Lorsque le telephone mobile est en chute libre et donc accelere vers lesol a 9,81 m/s2, l’accelerometre lit une grandeur de g = 0 m/s2.

D’autres indicateurs disponibles permettraient eux, d’enrichir la detection de la chute pour eviter des”faux-positifs”, par ex : se baser sur la distance de la chute, se baser sur la frequence cardiaque (uneaugmentation de l’adrenaline due a une chute fait augmenter la frequence cardiaque), se baser surl’activite du resident (le fait que l’utilisateur marche apres la chute indique que la chute n’en etait pasune).

2.15 Conclusion

Ce chapitre d’analyse a permis d’identifier les differentes technologies, API, librairie, pour la realisationdes differentes fonctionnalites de l’application. Le tableau 2.8 est un recapitulatif de ce qui va etre utilisedans le projet.

Plateforme de developpement AndroidCommunication avec le serveur HTTP/JSONLocalisation IndoorAtlasGeoreperage Cote serveurSuivi d’activite APIActivityRecognitionRecuperation frequence cardiaque Bluetooth/Ceinture ZephyrRappel de medicament AlarmManagerMessagerie Firebase cloud messagingDetection de chute Accelerometre

Table 2.8 – Recapitulatif analyse

28

Page 33: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

3 Conception

3.1 Introduction

Apres avoir analyse les differentes parties de l’application, la partie de conception presentera principa-lement : les maquettes de l’application, les diagrammes de sequences et le diagramme de classe.

3.2 Maquettes de l’application

Figure 3.1 – Maquette de la page de login Figure 3.2 – Maquette du menu

La maquette 3.1 represente la vue de login de l’application.

La maquette 3.2 represente le menu de l’application. Depuis le menu, il est possible d’acceder a :— La vue d’accueil— La vue de la messagerie— La vue de de configuration— La deconnexion de l’application

29

Page 34: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

Figure 3.3 – Maquette de la page d’accueilFigure 3.4 – Maquette de la page de configu-ration

La maquette 3.3 represente la vue d’accueil de l’application. Depuis cette vue, le resident a acces auxinformations suivantes :

— Les informations du residents :— Nom du resident— Prenom du resident

— Les informations sur la frequence cardiaque :— L’etat du capteur (connecte/deconnecte)— Le pouls du resident

— Les informations sur l’activite du resident :— L’etat du capteur (connecte/deconnecte)— L’activite du resident

— Les informations sur la localisation du resident :— L’etat du capteur (connecte/deconnecte)

La maquette 3.4 presente la vue de configuration de l’application. Depuis cette vue, le resident a accesa la liste des capteurs disponibles. Le resident peut activer/desactiver les differents capteurs.

30

Page 35: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

Figure 3.5 – Maquette de la page de message-rie

Figure 3.6 – Maquette de la pop-up pour lareception d’un message

La maquette 3.5 represente la vue de la messagerie de l’application . Depuis cette vue, le resident aacces a une liste predefinie de messages. Un clic sur un message envoie une alarme au serveur.

La maquette 3.6 represente la vue permettant la reception d’un message. Lorsque le responsable d’unresident envoie un message a un resident, cette pop-pup est affichee. Cette pop-up peut etre afficheesur les vues suivantes de l’application :

— La vue d’accueil— La vue de la messagerie— La vue de la configuration

31

Page 36: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

Figure 3.7 – Maquette de la pop-up pour laprise de medicament

La maquette 3.7 represente la vue pour le rappel de medicament. Lorsque le resident a un medicament aprendre, cette pop-up est affichee. Cette pop-up peut etre affichee sur les vues suivantes de l’application :

— La vue d’accueil— La vue de la messagerie— La vue de la configuration

32

Page 37: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

3.3 Diagrammes de sequences

3.3.1 Connexion a l’application

Le diagramme 3.8 represente le diagramme de sequence pour la connexion d’un utilisateur a l’applica-tion.

loo

p

alt

[!isC

onne

cted

]

[If h

ttp s

tatu

s co

de =

200

&&

logi

n ok

]

mai

nAct

ivity

Ser

ver

SE

MS

http

Req

uest

resi

dent

logi

nAct

ivity

logi

nGU

Iut

ilisa

teur

7: n

ew in

tent

6.2:

set

res

iden

t inf

orm

atio

n

8: r

es

2: n

ew h

ttpR

eque

st

8.1:

dis

play

err

or

6.1:

dis

play

ok6:

res

iden

t inf

orm

atio

n

5.2:

res

ult

5.1:

pos

t /lo

gin/

resi

dent

5: c

heck

logi

n

4.1:

che

ck lo

gin

1: n

ew v

iew

4: c

lick

on b

utto

n "C

onne

xion

"

3: in

sert

logi

n in

form

atio

ns

Vis

ual P

arad

igm

Sta

ndar

d E

ditio

n(E

cole

d'in

geni

eurs

et d

'arc

hite

ctes

de

Frib

ourg

)

Figure 3.8 – Diagramme de sequence pour la connexion

33

Page 38: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

3.3.2 Deconnexion de l’application

Le diagramme 3.9 represente le diagramme de sequence pour la deconnexion de l’application.

op

t

op

t

op

t

op

t

[If s

enso

r en

able

d]

[If s

enso

r en

able

d]

[If s

enso

r en

able

d]

[if s

enso

r en

able

d]

resi

dent

Ser

ver

SE

MS

http

Req

uest

drug

Rec

all

logi

nAct

ivity

hear

tRat

eSen

sor

activ

ityS

enso

rlo

catio

nSen

sor

sens

orM

anag

erS

ervi

cem

ainA

ctiv

ity

3.1:

pos

t /lo

gout

3: lo

gout

1: c

lic d

isco

nnec

t

2.4:

sto

p dr

ug r

ecal

l 4: n

ew in

tent

2.3:

sto

p se

nsor

2.2:

sto

p se

nsor

2.1:

sto

p se

nsor

2: d

isab

le s

enso

r

Vis

ual P

arad

igm

Sta

ndar

d E

ditio

n(E

cole

d'in

geni

eurs

et d

'arc

hite

ctes

de

Frib

ourg

)

Figure 3.9 – Diagramme de sequence pour la deconnexion

34

Page 39: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

3.3.3 Initialisation des capteurs

Le diagramme 3.10 represente le diagramme de sequence pour l’initialisation des capteurs de l’ap-plication. Cette initialisation est faite au demarrage de l’application, apres que l’utilisateur se soitconnecte.

alt

[If s

enso

r ac

tived

]

ref

loca

tion

alt

[If s

enso

r ac

tived

]

ref

hear

t-ra

te

alt

[If s

enso

r ac

tived

]

ref

activ

ity-t

rack

er

alt

[if d

rug

reca

ll ac

tived

]

ref

drug

-rec

all

mai

nAct

ivity

sens

orM

anag

erS

ervi

ce

hom

eGU

I

hom

eFra

gmen

t

http

Req

uest

1: n

ew fr

agm

ent 4:

get

sen

sorM

anag

erS

ervi

ce in

stan

ce

5: n

ew h

ttpR

eque

st

2: n

ew v

iew

3: d

ispl

ay r

esid

ent i

nfos

Vis

ual P

arad

igm

Sta

ndar

d E

ditio

n(E

cole

d'in

geni

eurs

et d

'arc

hite

ctes

de

Frib

ourg

)

Figure 3.10 – Diagramme de sequence pour l’initialisation des capteurs

35

Page 40: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

3.3.4 Recuperation des donnees des capteurs

Le diagramme 3.11 represente le diagramme de sequence pour la recuperation des donnees des capteurset l’envoi de ses donnees au serveur SEMS.

loo

p alt

[Eac

h x

seco

nds

for

activ

ed s

enso

rs]

[ ! If

sta

tus

code

==

200

]

hom

eGU

Iho

meF

ragm

ent

hear

tRat

eSen

sor

loca

tionS

enso

rac

tivity

Sen

sor

Ser

ver

SE

MS

http

Req

uest

mai

nAct

ivity

sens

orM

anag

erS

ervi

ce

4.1:

upd

ate

view

4: u

pdat

e la

titud

e, lo

ngitu

de, a

ctiv

ity, h

eart

rat

e3.

1: h

eart

rat

e

3: g

et h

eart

rat

e

1.1:

latit

ude,

long

itude

1: g

et la

titud

e, lo

ngitu

de

2.1:

act

ivity

2: g

et a

ctiv

ity

4.2.

2: r

es

4.2.

1: p

ost /

upda

te/r

esid

ent

5: d

ispl

ay e

rror

4.2:

sen

d in

form

atio

ns

Vis

ual P

arad

igm

Sta

ndar

d E

ditio

n(E

cole

d'in

geni

eurs

et d

'arc

hite

ctes

de

Frib

ourg

)

Figure 3.11 – Diagramme de sequence pour la recuperation de donnees des capteurs

36

Page 41: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

3.3.5 Capteur frequence cardiaque

Le diagramme 3.12 represente le diagramme de sequence pour l’initialisation du capteur de la frequencecardiaque.

alt

op

t

alt[If

con

nect

ion

ok]

[If p

robl

em w

ith h

eart

rat

e]

[If s

tatu

s co

de =

= 2

00]

btC

lient

btLi

sten

er

Ser

ver

SE

MS

mai

nAct

ivity

hear

tRat

eSen

sor

sens

orM

anag

erS

ervi

ceht

tpR

eque

st

6: s

tart

Com

mun

icat

ion

4: a

ddC

onne

cted

Eve

ntLi

sten

er(b

tLis

tene

r)

3: n

ew b

tLis

tene

r

5: is

Con

nect

ed

2.1:

new

btC

lient

2: s

tart

Sen

sor

1: n

ew h

eart

Rat

eSen

sor

8.3:

upd

ate

hear

t rat

e =

-1

&&

sto

p se

nsor

8: u

pdat

e he

art r

ate

7: o

nRec

eive

8.2:

ala

rm

8.1:

det

ectS

uspi

ciou

sHea

rtR

ate

9.1:

res

ult

9: p

ost /

alar

m/r

esid

ent

8.2.

1: s

end

alar

m

12.1

: dis

able

sen

sor

8.4.

1: d

ispl

ay e

rror

12.2

: dis

play

err

or

11: d

ispl

ay a

larm

8.4:

dis

able

sen

sor

12: e

rror

10: d

ispl

ay a

larm

Vis

ual P

arad

igm

Sta

ndar

d E

ditio

n(E

cole

d'in

geni

eurs

et d

'arc

hite

ctes

de

Frib

ourg

)

Figure 3.12 – Diagramme de sequence pour l’initialisation du capteur de frequence cardiaque

37

Page 42: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

3.3.6 Geolocalisation

Le diagramme 3.13 represente le diagramme de sequence pour l’initialisation du capteur pour la loca-lisation.

alt

[If lo

catio

n ok

]

mai

nAct

ivity

sens

orM

anag

erS

ervi

ce

loca

tionS

enso

r

loca

tionM

anag

er

loca

tionL

iste

ner

7.1:

dis

play

err

or

7: d

isab

le s

enso

r

6.1:

sto

p se

nsor

6: e

rror

2.1:

new

Loc

atio

nMan

ager

2: s

tart

Sen

sor

1: n

ew L

ocat

ionS

enso

r

5: u

pdat

e la

titud

e, lo

ngitu

de

4: o

nLoc

atio

nCha

nged

3: n

ew lo

catio

nLis

tene

r

Vis

ual P

arad

igm

Sta

ndar

d E

ditio

n(E

cole

d'in

geni

eurs

et d

'arc

hite

ctes

de

Frib

ourg

)

Figure 3.13 – Diagramme de sequence pour l’initialisation du capteur de geolocalisation

38

Page 43: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

3.3.7 Suivi d’activite

Le diagramme 3.14 represente le diagramme de sequence pour l’initialisation du capteur pour le suivid’activite.

op

t

[If s

uspi

ciou

s ac

tivity

]

alt

alt

[If s

tatu

s co

de =

= 2

00]

[ ! If

suc

cess

full]

mai

nAct

ivity

activ

ityS

ervi

ce

activ

ityR

ecog

nitio

nAP

I

activ

ityS

enso

r

Ser

ver

SE

MS

http

Req

uest

sens

orM

anag

erS

ervi

ce

3.1:

sto

p se

nsor

6.1:

dis

play

err

or

5.1:

dis

play

ala

rm5:

dis

play

ala

rm

6: d

ispl

ay e

rror

3.2.

1: d

ispl

ayE

rror

3.2:

dis

able

sen

sor

3: e

rror

4.1:

han

dleD

etec

tedA

ctiv

ities

4.2:

upd

ate

activ

ity

4: u

pdat

e ac

tivity

2.3:

req

uest

Act

ivity

Upd

ate(

activ

ityS

ervi

ce, x

sec

onde

s)

2.1:

new

Act

ivity

Rec

ogni

tionA

PI

2.2:

new

act

ivity

Ser

vice

(act

ivity

Rec

ogni

tionA

PI)

2: s

tart

Sen

sor

1: n

ewA

ctiv

ityS

enso

r

4.2.

2: a

larm

4.2.

1: d

etec

tsS

uspi

ciou

sAct

ivity

4.2.

2.1.

2: r

esul

t

4.2.

2.1.

1: p

ost /

alar

m/r

esid

ent

4.2.

2.1:

sen

d al

arm

Vis

ual P

arad

igm

Sta

ndar

d E

ditio

n(E

cole

d'in

geni

eurs

et d

'arc

hite

ctes

de

Frib

ourg

)

Figure 3.14 – Diagramme de sequence pour l’initialisation du capteur de suivi d’activite

39

Page 44: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

3.3.8 Rappel de medicament

Le diagramme 3.15 represente le diagramme de sequence pour l’initialisation du rappel de medicaments.

residentdrugRecallsensorManagerService

3.1: set all recall

3: return drugs

2.1: get drugs information

2: start drugRecall

1: new drugRecall

Visual Paradigm Standard Edition(Ecole d'ingenieurs et d'architectes de Fribourg)

Figure 3.15 – Diagramme de sequence pour l’initialisation du rappel de medicaments

3.3.9 Configuration

Le diagramme 3.16 represente le diagramme de sequence pour la configuration des capteurs (activa-tion/desactivation).

alt

[If enable]

sensorManagerService aSensormainActivity

Actor

configurationGUI

configurationFragment

5: stop sensor

4: start sensor

3.1: enable/disable sensor

3: enable/disable sensor

2.1: enable/disable sensor

2: click on a sensor

1: new view

Visual Paradigm Standard Edition(Ecole d'ingenieurs et d'architectes de Fribourg)

Figure 3.16 – Diagramme de sequence pour la configuration des capteurs

40

Page 45: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

3.4 Diagramme de classe

Le diagramme de classe complet se trouve a l’annexe A.4. Par soucis de clarte et de lisibilite, lesclasses utilises pour la serialisation/deserialisation pour la communication avec le serveur et les classesqui etendent de ”BroadcastReceiver” pour la communication entre service et activite ne sont paspresentees.

3.4.1 Gestion des capteurs

Le diagramme 3.17 represente le diagramme de classe concernant la gestion des capteurs.

-context : Context-isHeartRateSensorEnable : boolean-LocationSensorEnable : boolean-ActivitySensorEnable : boolean-FallSensorEnable : boolean-heartRateSensor : HeartRatesensor-locationSensor : LocationSensor-activitySensor : ActivitySensor-fallSensor : FallSensor-drugRecall : DrugRecall-drugRecallEnable : boolean-httpRequest : HTTPRequest

-SensorManager(context : Context)+getSensorsData() : void+getHeartRateSensorEnable() : boolean+setHeartRateSensorEnable(isHeartRateSensorEnable : boolean) : void+getLocationSensorEnable() : boolean+setLocationSensorEnable(isLocationSensorEnable : boolean) : void+getActivitySensorEnable() : boolean+setActivitySensorEnable(isActivitySensorEnable : boolean) : void+getFallSensorEnable() : boolean+setFallSensorEnable(isFallSensorEnable : boolean) : void+sendAlarm(type : String, value : int) : void+getDrugRecallEnable() : boolean+setDrugRecallEnable(drugRecallEnable : boolean) : void+resetHeartRateSensor(boolean start) : void+resetActivitySensor(boolean start) : void+resetLocationSensor(boolean start) : void+resetDrugRecall(boolean start) : void

SensorManagerService-btClient : BTClient-btListener : BTListener-heartRate : int-context : Context

+HeartRateSensor(context : Context)+updateHeartRate(frequency : int)+detectSuspiciousHeartRate() : void+getHeartRate() : int+setHeartRate(heartRate : int) : void

HeartRateSensor

-locationManager : LocationManager-locationListener : LocationListener-latitude : double-longitude : double

+LocationSensor(sms : SensorManagerService)+updateLocation(latitude : double, longitude : double) : void+getLatitude() : double+setLatitude(latitude : double) : void+getLongitude() : double+setLongitude(longitude : double) : void

LocationSensor

+startSensor() : void+sendAlarm() : void+stopSensor() : void+error(type : String, error : String) : void

<<Interface>>Sensor

-activityRecognitionAPI : ActivityRecognitionAPI-activity : String-activityService : ActivityService-context : Context

+ActivitySensor(context : Context)+updateActivity(activity : String) : void+detectSuspiciousActivity() : void+getActivity() : String+setActivity(activity : String) : void

ActivitySensor

+FallSensor(context : Context)

FallSensor

ActivityRecognitionAPI

BTClient

-heartRateSensor : HeartRateSensor

+BTListener(heartRateSensor : HeartRateSensor)

BTListener

<<Interface>>ConnectListenerImpl

-activitySensor : ActivitySensor

+ActivityService(activitySensor : ActivitySensor)+handleActivities(activities : List<Activities>) : void

ActivityService

<<Interface>>GoogleApiClient.ConnectionCallbacks

IALocationManager

IALocationListener

-context : Context

+DrugRecall(context : Context)

DrugRecall

Visual Paradigm Standard Edition(Ecole d'ingenieurs et d'architectes de Fribourg)

Figure 3.17 – Diagramme de classe pour la gestion des capteurs

SensorManagerService : Un service Android qui s’occupe, en arriere plan, de gerer l’ensemble descapteurs de l’application.

Sensor : Une interface representant un capteur.

41

Page 46: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

HeartRateSensor : Une classe permettant de gerer le capteur Bluetooth pour la recuperation dela frequence cardiaque.

BTClient : Une classe provenant de la librairie HxMBT (librairie fournit par le constructeur dela ceinture Bluetooth). BTClient permet de gerer la connexion Bluetooth entre la ceinture Zephyr etl’application mobile.

BTListener : Une classe qui implemente l’interface ”ConnectListenerImpl” et qui permet de recupererles informations recues durant la communication Bluetooth.

ConnectListenerImpl : Une interface provenant de la librairie HxMBT qui definit des methodespour la reception des donnees durant la communication Bluetooth.

LocationSensor : Une classe permettant de gerer la localisation.

IALocationManager : Une classe provenant de l’API de IndoorAtlas qui fournit un acces auxservice de localisation d’IndoorAtlas.

IALocationListener : Une interface provenant de l’API de IndoorAtlas utilisee pour recevoir lalocalisation, lorsque celle-ci change.

ActivitySensor : Une classe qui implemente l’interface ”GoogleApiClient.ConnectionCallbacks” etqui permet de gerer la connexion avec l’API de Google.

GoogleApiClient.ConnectionCallbacks : Une interface fournit par l’API de suivi d’activite deGoogle permettant de gerer la connexion a l’API.

ActivityService : Un service Android qui s’occupe, en arriere plan, de recuperer le suivi d’activitede l’API Google.

ActivityRecognitionAPI : Une classe fournit par l’API de suivi d’activite de Google qui permetde gerer la communication avec l’API.

FallSensor : Une classe permettant de gerer le capteur pour la detection de chute.

DrugRecall : Une classe permettant de gerer le rappel de medicament.

42

Page 47: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

3.4.2 Communication client-serveur

Le diagramme 3.18 represente le diagramme de classe concernant la communication entre l’applicationmobile et le serveur.

-serverURL : String-client : OkHTTPClient

+HTTPRequest()+login(username : String, password : String) : Resident+updateResident(id : int, heartRate : int, lat : double, lon : double, activity : String)+sendAlarm(alarm : Alarm) : void+logout()+sendMessage(message : String)+respondMessage(message : String, idResp : int)+drugRecall(take : boolean)

HTTPRequest

OkHTTPClient

Visual Paradigm Standard Edition(Ecole d'ingenieurs et d'architectes de Fribourg)

Figure 3.18 – Diagramme de classe pour la communication client-serveur

HTTPRequest : Cette classe permet de communiquer avec le serveur. Elle utilisera le client HTTPOkHttp decrit dans la section 3.5.2.

OKHTTPClient : Cette classe est fournie par la librairie OkHttp et est utilisee pour faire desrequetes HTTP.

3.4.3 Navigation de l’application

Le diagramme 3.19 represente le diagramme de classe concernant la navigation de l’application.

-sms : SensorManager-fragmentManager : FragmentManager

#onCreate(savedInstance : Bundle) : void#onDestroy() : void+onBackPressed()+changeFragment(menuItem : MenuItem)-setupDrawer(navigationView nativationView)+updateLocation(lat : double, lon : double) : void+updateActivity(activity : String) : void+updateHeartRate(heartRate : int)+displayAlarm(type : String)+displayError(type : String, error : String)+enableSensor(type : String, enable : boolean)

MainActivity

#onCreateView()+updateLocation(lat : double, lon : double) : void+updateHeartRate(heartRate : int) : void+updateActivity(activity : String) : void+setResidentInformations() : void+enableSensor(type : String, enable : boolean)

HomeFragment

-httpRequest : HTTPRequest

#onCreate(savedInstance : Bundle) : void+checkLogin() : void

LoginActivity

-mainActivity : MainActivity

#onCreateView()+enableSensor(type : String, enable : boolean)

ConfigurationFragment

+onCreateView()

MessagingFragment

<<use>>

<<use>>

<<use>>

Visual Paradigm Standard Edition(Ecole d'ingenieurs et d'architectes de Fribourg)

Figure 3.19 – Diagramme de classe pour la navigation

LoginActivity : Une activite pour la vue de connexion de l’application.

43

Page 48: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

MainActivity : Une activite utilise pour la gestion des differents fragments de l’application.

HomeFragment : Un fragment representant la vue principale de l’application.

ConfigurationFragment : Un fragment representant la vue de configuration de l’application.

MessagingFragment : Un fragment representant la vue de la messagerie.

3.5 Communication entre l’application mobile et le serveur

3.5.1 Architecture

L’illustration 3.20 represente l’architecture complete du projet.

Figure 3.20 – Architecture du projet

RMMA et HMMA : Les applications mobiles communiquent avec le server ”SEMS” en HTTP.Les donnees sont transmises en format JSON.

SEMS : Le serveur REST definit des routes (schema URI) que les applications mobiles peuventappeler et s’occupe de traiter les demandes. Le serveur SEMS communique avec l’application uMovepour recuperer les informations des residents et des responsables.

uMove : L’application uMove est un systeme intelligent. uMove est utilise pour representer virtuel-lement l’etat de la residence :

— Les residents : les informations sur les residents (nom, prenom,...), leurs localisations et lescapteurs qui leurs sont affilies.

— Les responsables : leurs localisations et la liste de leurs patients.

uMove aide a la prise de decision lorsqu’une alarme est generee en se basant sur les informationssuivantes :

— personne de reference— proximite entre le responsable et le resident— competence du responsable

3.5.2 Client HTTP

L’application mobile utilisera le client HTTP OkHttp. OkHttp est un client HTTP base sur Okiopour la lecture/ecriture de flux de donnees. Il est utilise car il compatible avec les differentes versionsd’Android ce qui n’est pas le cas des versions des clients HTTP d’Android. Depuis la version Android4.4, OkHttp fait partie integrante de l’implementation sur Android.OkHttp offre la possibilite de faire des requetes HTTP asynchrones :

44

Page 49: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

String urlPost="http://jsonplaceholder.typicode.com/posts";

String json="data: {\n" +" title: 'foo',\n" +" body: 'bar',\n" +" userId:

1\n" +" }";↪→

MediaType JSON= MediaType.parse("application/json; charset=utf-8");

private String postAStuff() throws IOException {

OkHttpClient client = new OkHttpClient();

RequestBody body = RequestBody.create(JSON, json);

Request request = new Request.Builder()

.url(urlPost)

.post(body)

.build();

Call postCall=getClient().newCall(request);

postCall.enqueue(new Callback() {

@Override

public void onFailure(Request request, IOException e) {

// Failed

}

@Override

public void onResponse(Response response) throws IOException {

//Succeeded

}

});

}

Code 3.5.1: Exemple requete asynchrone [28]

La methode onFailure permet de traiter les exceptions, elle est appelee lorsque la requete a ete annulee,lorsqu’il y a un probleme de connexion ou lors d’un timeout.La methode onResponse est appelee lorsque la requete est un succes. Dans cette methode, il estimportant de verifier le code de la reponse. Un code 404 n’est pas considere comme une erreur ou uneexception, donc pas traite dans la methode onFailure.

3.5.3 JSON

Pour lire et ecrire des donnees en format JSON, l’application utilisera GSON. GSON est une librairiequi peut etre utilisee pour convertir des objets java dans leur representation JSON. Elle peut aussiconvertir un string JSON dans son equivalent en objet java.

Serialisation avec GSON

Le code 3.5.2 est un exemple de la conversion d’un objet java en string en format JSON.

45

Page 50: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

//JSON input

{

NAME:"Albert Attard",

LOCATION:"Malta"

}

//Call when HTTP response successfully returned by the remote server

@Override

public void onResponse(Response response) throws IOException {

Gson gson = new GsonBuilder().create();

Person p = gson.fromJson(response.body().charStream(), Person.class);

}

//object Person

public class Person {

private String NAME; //("Albert Attard")

private String LOCATION; //("Malta")

}

Code 3.5.2: Exemple serialisation avec GSON [29]

Deserialisation avec GSON

Le code 3.5.3 est un exemple de la conversion d’un string en format JSON en objet java.

//JSON input

{

NAME:"Albert Attard",

LOCATION:"Malta"

}

//Call when HTTP response successfully returned by the remote server

@Override

public void onResponse(Response response) throws IOException {

Gson gson = new GsonBuilder().create();

Person p = gson.fromJson(response.body().charStream(), Person.class);

}

//object Person

public class Person {

private String NAME; //("Albert Attard")

private String LOCATION; //("Malta")

}

Code 3.5.3: Exemple deserialisation avec GSON [29]

46

Page 51: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

3.5.4 Definition des routes

Pour l’echange de donnees entre l’application mobile et le serveur, les routes suivantes sont offertes parle serveur REST ”SEMS” :

Route Methode HTTP Explications/login/resident POST cette route permet au resident de se connecter

au serveur/logout/resident POST cette route permet au resident de se

deconnecter du serveur/alarm POST cette route permet de generer des alarmes

lorsque le resident a un probleme/update/resident PUT cette route permet de mettre a jour les infor-

mations du resident/message/residen/ POST cette route permet de repondre a un message

recu/message/resident/new POST cette route permet d’envoyer un message a un

membre du personnel/resident/drugs/take POST cette route permet de valider la prise d’un

medicament

Table 3.1 – Definitions des routes du serveur REST

/login/resident

Cette route prend quatres parametres :— username : le nom d’utilisateur du resident— password : le mot de passe du resident— token : le token fourni par Firebase— phone : le numero de telephone

{

"username": "",

"password": "",

"token": "",

"phone": ""

}

Code 3.5.4: JSON envoye a la connexion

Le serveur repond en transmettant un JSON contenant les informations suivantes :— id : l’identifiant unique du resident— firstname : le prenom du resident— lastname : le nom du resident— bornDate : la date de naissance du resident— illness : La liste des maladies du resident— nameIllness : le nom d’une des maladies— type : le type d’une des maladies— drugs : La liste des medicaments necessaires pour l’une des maladies— nameDrugs : Le nom d’un medicament— periods : La liste des periodes pour la prise d’un medicament— hour : l’heure de la prise d’un medicament— minute : la minute de la prise de medicament

47

Page 52: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

{

"id":"",

"firstname":"",

"lastname":"",

"bornDate":"",

"ilness":[

{

"nameIllness":"",

"type":""

}

],

"drugs":[

{

"nameDrugs":"",

"periods":[

{

"hour":1,

"minute":1

}

]

}

]

}

Code 3.5.5: JSON recu a la connexion

/resident/logout

Cette route prend un parametre :— idResident : l’identifiant du resident

{

"idResident" : "",

}

Code 3.5.6: JSON envoye lors de la deconnexion

/alarm

Cette route prend cinq parametres :— id : l’identifiant du resident.— type : le type de l’alarme (frequence cardiaque, chute, activite suspecte).— valeur : si le type d’alarme est un probleme de frequence cardiaque. La frequence est transmise.— latitude : la latitude a laquelle se trouve le resident.— longitude : la longitude a laquelle se trouve le resident.— phone : le numero de telephone du resident

48

Page 53: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

{

"id": "",

"type": "",

"value": "",

"longitude": "",

"latitude": "",

"phone": ""

}

Code 3.5.7: JSON envoye lors d’une alarme

/update/resident

Cette route prend cinq parametres :— id : l’identifiant du resident.— heartRate : la frequence cardiaque du resident.— activity : l’activite du resident.— latitude : la latitude a laquelle se trouve le resident.— longitude : la longitude a laquelle se trouve le resident.

{

"id": "",

"heartRate": "",

"activity": "",

"longitude": "",

"latitude": ""

}

Code 3.5.8: JSON envoye lors de la mise a jour

/message/resident

Cette route prend trois parametres :— idResident : l’identifiant du resident.— idResponsable : l’identifiant de l’expediteur.— message : la reponse

{

"idResident": "",

"idResponsable": "",

"message": "",

}

Code 3.5.9: JSON envoye lors de la reponse a un message

/message/resident/new

Cette route prend trois parametres :— idResident : l’identifiant du resident.— idResponsable : l’identifiant de l’expediteur.

49

Page 54: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

— message : le message

{

"idResident": "",

"idResponsable": "",

"message": "",

}

Code 3.5.10: JSON envoye lors de l’envoi de message

/resident/drugs/take

Cette route prend un parametre :— isTaken : la reponse a la prise de medicament (yes ou no)

{

"isTaken": "",

}

Code 3.5.11: JSON envoye lors de la prise de medicament

3.6 Suivi de l’activite d’un resident

Le suivi d’activite est utilise pour recuperer trois types d’activites (immobile, marche, course). L’acti-vite ”immobile” pour detecter une inactivite suspecte du resident, les activites ”marche” et ”course”pour une meilleure evaluation de la frequence cardiaque. Les autres activites fournies par l’API desuivi d’activite ne peuvent pas etre ignorees, elles sont donc associees a l’une de ces trois activites(immobile, marche, course).

Activite detectee Activite utiliseeEn vehicule ImmobileMarche MarcheCourse CourseEn velo CourseImmobile ImmobileInclinaison Immobile

Table 3.2 – Activite utilisee

3.7 Recuperation de la frequence cardiaque d’un resident

La frequence cardiaque depend de beaucoup de parametres (homme/femme, activite, poids,...), il a etedecide de donner la possibilite au personnel soignant d’entrer dans l’application mobile du resident,un intervalle de frequence acceptable pour un resident en fonction de son activite (immobile, marche,course).Pour detecter un probleme avec la frequence cardiaque du resident, l’application mobile se base sur safrequence cardiaque et son activite. La detection doit pouvoir prendre en compte le fait qu’un residentait fait un effort physique (course), puis se retrouve au repos avec une frequence cardiaque plus eleveeque son intervalle de frequence acceptable. Cette situation ne doit pas generer d’alarme pour autantque la frequence cardiaque diminue de facon continue jusqu’a se retrouver dans l’intervalle acceptable.

50

Page 55: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

Figure 3.21 – Frequence cardiaque en fonction de l’activite

De plus, l’application doit aussi prendre en compte le fait que la mise a jour de l’activite du residentest faite a une frequence moins elevee que la recuperation de la frequence cardiaque. Il est possible quela frequence cardiaque du resident augmente, alors que son activite indique qu’il est au repos.

La ceinture donne une indication sur la vitesse, si la vitesse n’augmente pas et que la frequence car-diaque oui, il faut generer une alarme.

Pour eviter des problemes de coordination entre l’activite et la frequence cardiaque, c’est l’activitequi decidera de l’intervalle de frequence cardiaque acceptable pour un resident. Lorsqu’une activite estdetectee, elle notifie le capteur de frequence cardiaque qui se met a jour. Le capteur de frequence car-diaque prend alors le relai et va verifier la frequence cardiaque du resident, en se basant sur sa frequencecardiaque et la vitesse donnee par la ceinture. Pour detecter un probleme de frequence cardiaque, dixetats ont ete definis (still, walk, run, stillAfterWalk, stillAfterRun, walkAfterStill, walkAfterRun, ru-nAfterStill, runAfterWalk, alarm). A chaque reception d’une nouvelle activite, le resident passe dansun des etats suivants (still, walk, run), puis peut changer d’etat en fonction de la vitesse de la ceintureet de sa frequence cardiaque.

Le tableau 3.3 indique les vitesses utilisees en fonction de l’activite du resident.

Activite VitesseImmobile 0 a 1 km/hMarche 1 a 7 km/hCourse plus de 7 km/h

Table 3.3 – Vitesse en fonction de l’activite

51

Page 56: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

Le diagramme 3.22 illustre les transitions que peut presenter l’etat immobile.

Figure 3.22 – Etat immobile

Le diagramme 3.23 illustre les transitions que peut presenter l’etat marche.

Figure 3.23 – Etat marche

Le diagramme 3.24 illustre les transitions que peut presenter l’etat course.

Figure 3.24 – Etat course

52

Page 57: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

Le diagramme 3.25 illustre les transitions que peut presenter l’etat repos qui survient apres une marche.

Figure 3.25 – Etat immobile apres une marche

Le diagramme 3.26 illustre les transitions que peut presenter l’etat repos qui survient apres une course.

Figure 3.26 – Etat immobile apres une course

53

Page 58: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

Le diagramme 3.27 illustre les transitions que peut presenter l’etat marche qui survient apres un repos.

Figure 3.27 – Etat marche apres un repos

Le diagramme 3.28 illustre les transitions que peut presenter l’etat l’etat marche qui survient apresune course.

Figure 3.28 – Etat marche apres une course

54

Page 59: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

Le diagramme 3.29 illustre les transitions que peut presenter l’etat course qui survient apres un repos.

Figure 3.29 – Etat course apres un repos

Le diagramme 3.30 illustre les transitions que peut presenter l’etat course qui survient apres unemarche.

Figure 3.30 – Etat course apres une marche

55

Page 60: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

3.8 Messagerie resident-responsable

Les messages envoyes entre un resident et un responsable sont transmis au serveur SEMS, puis leserveur SEMS envoie une notification PUSH au destinataire. L’illustration 3.31 represente l’envoi d’unmessage d’un resident a un responsable, l’envoi d’un message d’un responsable a un resident fonctionnede la meme facon.

1. Le resident transmet un message au serveur SEMS en envoyant une requete HTTP.2. Le serveur SEMS recupere le message et le transmet au serveur Firebase.3. Firebase envoie une notification au responsable.4. L’application mobile du responsable affiche la notification.

Figure 3.31 – Fonctionnement messagerie

3.9 Conclusion

Ce chapitre de conception a permis de modeliser le fonctionnement de l’application, ce qui faciliterason implementation.

56

Page 61: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

4 Implementation

4.1 Introduction

Le chapitre d’implementation presentera principalement les vues de l’application, ainsi que des partiesde code jugees interessantes pour les differentes fonctionnalites de l’application.

4.2 Vue de l’application

Figure 4.1 – Vue de la page de login Figure 4.2 – Vue du menu

La vue 4.1 represente la vue de login de l’application. Cette vue offre :— Un champs d’edition pour entrer le nom d’utilisateur— Un champs d’edition pour entrer le mot de passe de l’utilisateur— Un bouton pour valider la connexion

La vue 4.2 represente le menu de l’application. Depuis le menu, il est possible d’acceder a :— La vue d’accueil— La vue de la messagerie— La vue de de configuration— La deconnexion de l’application

57

Page 62: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

Figure 4.3 – Vue de la page d’accueil Figure 4.4 – Vue de la page de messagerie

La vue 4.3 represente la vue d’accueil de l’application. Depuis cette vue, il est possible d’acceder auxinformations suivantes :

— Les informations sur le resident— Les informations sur le capteur de frequence cardiaque— Les informations sur le suivi d’activite— Les informations sur la localisation— Les informations sur le rappel de medicament

La vue 4.4 represente la vue pour la messagerie. Cette vue offre :— Une liste de messages permettant d’envoyer une alarme au serveur.— Un bouton permettant d’ajouter un message dans la liste des messages predefini.

58

Page 63: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

Figure 4.5 – Vue de l’ajout de message Figure 4.6 – Vue de la notification de message

La vue 4.5 represente la pop-up pour l’insertion d’un nouveau message. Cette pop-up offre :— Un champs d’edition pour entrer le nouveau message— Un bouton pour valider l’ajout du message— Un bouton pour annuler l’ajout du message

La vue 4.6 represente la notification pour la reception d’un message d’un responsable du corps medical.Cette pop-up offre :

— Deux boutons contenant des reponses a la question. Ses reponses sont definies par le responsabledu corps medical.

Cette vue differe de ce qui a ete presentee dans la partie de conception, la notification etant pluspratique car elle peut etre accessible aussi en dehors de l’application.

59

Page 64: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

Figure 4.7 – Vue de la page de configuration Figure 4.8 – Vue de la page de configuration

La vue 4.7 represente la premiere partie de la configuration. Cette vue offre :— Un bouton switch pour activer/desactiver le capteur de frequence cardiaque— Un bouton switch pour activer/desactiver le capteur de suivi d’activite— Un bouton switch pour activer/desactiver le capteur de localisation— Un bouton switch pour activer/desactiver la detection d’une chute— Un bouton switch pour activer/desactiver le le rappel des medicaments

La vue 4.8 represente la deuxieme partie de la configuration. Cette vue offre :— Un champs d’edition pour entrer la frequence cardiaque minimale au repos.— Un champs d’edition pour entrer la frequence cardiaque maximale au repos.— Un champs d’edition pour entrer la frequence cardiaque minimale en marchant.— Un champs d’edition pour entrer la frequence cardiaque maximale en marchant.— Un champs d’edition pour entrer la frequence cardiaque minimale en courant.— Un champs d’edition pour entrer la frequence cardiaque maximale en courant.— Un bouton pour sauvegarder les modifications

60

Page 65: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

Figure 4.9 – Vue de la notification de rappelde medicament

La vue 4.9 represente la notification pour le rappel d’un medicament, cette notification offre :— Un bouton pour indiquer qu’un medicament a ete pris— Un bouton pour indiquer qu’un medicament n’a pas ete pris

Cette vue differe de ce qui a ete presentee dans la partie de conception, la notification etant pluspratique car elle peut etre accessible aussi en dehors de l’application.

4.3 Communication entre l’application mobile et le serveur

Pour faire des requetes HTTP, le fichier de Manifest de l’application doit inclure l’autorisation suivante :

<uses-permission android:name="android.permission.INTERNET" />

Code 4.3.1: Ajout de la permission internet

Pour la communication avec le serveur, la librairie OkHttp est utilisee et doit etre incluse dans le fichier”build.gradle”.

compile 'com.squareup.okhttp:okhttp:2.5.0'

Code 4.3.2: Ajout de la librairie OkHttp

Pour la serialisation/deserialisation des donnees envoyees et recues en format JSON, GSON est utiliseet doit etre inclus dans le fichier ”build.gradle”.

61

Page 66: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

compile 'com.google.code.gson:gson:2.2.4

Code 4.3.3: Ajout de la librairie GSON

Le code 4.3.4 est appele toutes les minutes par le service qui gere les differents capteurs de l’appli-cation. La methode ”updateResident” creee en premier lieu un objet ”ModelInfoResident” contenantles informations du resident. A l’aide de GSON, l’objet est serialise en format JSON, puis transmisau serveur avec OkHttp. En cas d’indisponibilite du serveur, l’erreur est transmise au manager descapteurs.

public void updateResident(double lat, double lon, String activity, String

heartRate) {↪→

ModelInfoResident res = new ModelInfoResident(Resident.getInstance().getId(),

lon, lat, activity, heartRate);↪→

String json = new Gson().toJson(res);

RequestBody body = RequestBody.create(JSON, json);

Request request = new Request.Builder()

.url(url+UPDATE_RESIDENT)

.post(body)

.build();

Call postCall=client.newCall(request);

postCall.enqueue(new Callback() {

@Override

public void onFailure(Request request, IOException e) {

SendHttpResponse sendHttpResponse = new SendHttpResponse();

sendHttpResponse.httpResponse(false);

}

@Override

public void onResponse(Response response) throws IOException {

}

});

}

Code 4.3.4: Mise a jour du resident

Lorsqu’il y a un probleme de communication entre l’application mobile et le serveur, une erreur estgeneree. L’utilisateur de l’application est alors averti par un bip sonore.

62

Page 67: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

4.4 Localisation d’un resident

Pour utiliser la localisation, le fichier de Manifest de l’application doit inclure les autorisations sui-vantes :

<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />

<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />

Code 4.4.1: Ajout des permissions pour la localisation

La librairie IndoorAtlas pour la localisation doit etre ajoutee dans le fichier ”build.gradle”.

compile 'com.indooratlas.android:indooratlas-android-sdk:2.4.2@aar'

Code 4.4.2: Ajout de la librairie IndoorAtlas

4.4.1 Mise en place de IndoorAtlas

IndoorAtlas a besoin d’une phase de calibration. La calibration est faite avec les plans officiels de laHEIA pour le batiment D a l’etage 2.

Figure 4.10 – Plan HEIA batiment D etage 2

63

Page 68: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

Cette phase de calibration est faite a l’aide de l’application ”MapCreator2”. Sur l’illustration 4.11, lespoints gris representent les points qui ont ete calibres. La trace grise represente le chemin empruntepour la calibration.

Figure 4.11 – Calibration avec IndoorAtlas

L’illustration 4.12 represente le resultat de la calibration faite avec l’application MapCreator2. La tracejaune et verte represente la couverture de la cartographie magnetique. Les parties en couleurs verterepresentent une bonne precision, les parties en jaune, une precision acceptable.

Figure 4.12 – Resultat calibration avec IndoorAtlas

64

Page 69: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

4.4.2 Utilisation de IndoorAtlas

Le code 4.4.3 est appele au demarrage du capteur de localisation. Le code demarre le service permettantde communiquer avec le service de localisation d’IndoorAtlas. Un broadcastreceiver est enregistre etpermet de recuperer les broadcast transmis par le service.

public void startSensor() {

if (ActivityCompat.checkSelfPermission(this.context,

android.Manifest.permission.ACCESS_FINE_LOCATION) !=

PackageManager.PERMISSION_GRANTED &&

ActivityCompat.checkSelfPermission(this.context,

android.Manifest.permission.ACCESS_COARSE_LOCATION) !=

PackageManager.PERMISSION_GRANTED) {

↪→

↪→

↪→

↪→

↪→

return;

}

mManager = IALocationManager.create(context);

LocalBroadcastManager.getInstance(context).registerReceiver(mReceiver,

new IntentFilter(SensorType.LOCATION_BROADCAST));

mManager.requestLocationUpdates(IALocationRequest.create(),

getPendingIntent());↪→

}

PendingIntent getPendingIntent() {

return PendingIntent.getService(context, 0, new Intent(context,

LocationService.class), 0);↪→

}

private BroadcastReceiver mReceiver = new BroadcastReceiver() {

@Override

public void onReceive(Context context, Intent intent) {

if (intent.hasExtra("location")) {

IALocation location = intent.getParcelableExtra("location");

updateLocation(location.getLatitude(), location.getLongitude());

}

}

};

Code 4.4.3: Initialisation de la localisation avec Indoor Atlas

65

Page 70: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

4.5 Generation d’alarmes

Le code 4.5.1 permet d’envoyer une alarme au serveur.

public void alarm(double lat, double lon, String type, String value, String

phone) {↪→

Alarm alarm = new Alarm(Resident.getInstance().getId(), type, value, lat,

lon, phone);↪→

String json = new Gson().toJson(alarm);

RequestBody body = RequestBody.create(JSON, json);

Request request = new Request.Builder()

.url(url+ALARM)

.post(body)

.build();

Call postCall=client.newCall(request);

postCall.enqueue(new Callback() {

@Override

public void onFailure(Request request, IOException e) {

SendHttpResponse sendHttpResponse = new SendHttpResponse();

sendHttpResponse.httpResponse(false);

}

@Override

public void onResponse(Response response) throws IOException {

SendHttpResponse sendHttpResponse = new SendHttpResponse();

sendHttpResponse.httpResponse(true);

}

});

}

Code 4.5.1: Envoi d’alarmes au serveur

4.6 Suivi de l’activite d’un resident

Pour utiliser le suivi d’activite, le fichier de Manifest de l’application doit inclure l’autorisation sui-vante :

<uses-permission

android:name="com.google.android.gms.permission.ACTIVITY_RECOGNITION" />↪→

Code 4.6.1: Ajout de la permission pour le suivi d’activite

Pour utiliser l’API ActivityRecognitionApi, le kit de developpement Google Play services doit etreajoute dans le fichier ”build.gradle”.

compile 'com.google.android.gms:play-services:9.6.1'

Code 4.6.2: Ajout des Google play services

Le code 4.6.3 permet de se connecter a l’API de suivi d’activite.

66

Page 71: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

@Override

public void startSensor() {

mApiClient = new GoogleApiClient.Builder(context)

.addApi(ActivityRecognition.API)

.addConnectionCallbacks(this)

.addOnConnectionFailedListener(this)

.build();

mApiClient.connect();

}

Code 4.6.3: Initialisation du suivi d’activite avec ActivityRecognitionApi

Le code 4.6.4 est appele lorsque la connexion a l’API de suivi d’activite est reussie. Le code demarre unservice permettant de communiquer avec l’API et enregistre un broadcastReceiver pour la receptiondes donnees transmises par le service.

@Override

public void onConnected(@Nullable Bundle bundle) {

Intent intent = new Intent( context, ActivityService.class );

pendingIntent = PendingIntent.getService( context, 0, intent,

PendingIntent.FLAG_UPDATE_CURRENT );↪→

ActivityRecognition.ActivityRecognitionApi.requestActivityUpdates(

mApiClient, DETECTIONINTERVALL, pendingIntent );↪→

context.registerReceiver(broadcastReceiver, filter);

}

Code 4.6.4: Suivi d’activite avec ActivityRecognitionApi

67

Page 72: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

4.6.1 Detection d’une inactivite suspecte

Pour la detection d’une inactivite suspecte, a chaque mise a jour de l’activite, le code test l’activiterecue. Si le resident est immobile, un ”Handler” est lance, un ”Handler” permet de retarder l’executiond’une action (une alarme dans ce cas). Si une autre activite est detectee, le ”Handler” est supprime.

@Override

public void onConnected(@Nullable Bundle bundle) {

broadcastReceiver = new BroadcastReceiver() {

@Override

public void onReceive(Context context, Intent intent) {

activity = intent.getStringExtra("activity");

if(!activity.equals(still)){

handler.removeCallbacks(runnable);

isStilling = false;

}else{

if(!isStilling){

handler = new Handler();

handler.postDelayed(runnable, DETECTIONINTERVALL);

isStilling = true;

}

}

}

};

}

private Runnable runnable = new Runnable() {

@Override

public void run() {

sendAlarm();

}

};

Code 4.6.5: Detection d’une inactivite suspecte

68

Page 73: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

4.7 Recuperation de la frequence cardiaque d’un resident

Pour communiquer en Bluetooth avec la ceinture Zephyr, les permissions suivantes sont necessairesdans le fichier de Manifest de l’application.

<uses-permission android:name="android.permission.BLUETOOTH" />

<uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />

Code 4.7.1: Ajout des permissions Bluetooth

Le code 4.7.2 permet d’initialiser la communication Bluetooth avec la ceinture Zephyr. Le code permetd’enregistrer deux broadcastReceiver pour recuperer le resultat du pairing et du bonding entre l’appli-cation mobile et la ceinture. Si la connexion entre les deux peripheriques s’est effectuee avec succes, lacommunication demarre. Dans le cas contraire, une erreur est transmise au manager des capteurs.

@Override

public void startSensor() {

String BhMacID = "";

bluetoothAdapter = BluetoothAdapter.getDefaultAdapter();

Set<BluetoothDevice> pairedDevices = bluetoothAdapter.getBondedDevices();

if (pairedDevices.size() > 0)

{

for (BluetoothDevice device : pairedDevices)

{

if (device.getName().startsWith("HXM"))

{

BluetoothDevice btDevice = device;

BhMacID = btDevice.getAddress();

break;

}

}

}

bTClient = new BTClient(bluetoothAdapter, BhMacID);

btListener = new BTListener(Newhandler,Newhandler);

bTClient.addConnectedEventListener(btListener);

if(bTClient.IsConnected())

{

bTClient.start();

isConnected = true;

}else{

isConnected = false;

Intent intent = new Intent(ErrorType.HEARTRATE_BROADCAST_ERROR);

intent.putExtra("type", SensorType.HEARTRATE);

context.sendBroadcast(intent);

}

}

Code 4.7.2: Initialisation de la communication Bluetooth

69

Page 74: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

4.7.1 Detection d’un probleme de frequence cardiaque

La detection d’un probleme avec la frequence cardiaque se base sur l’activite courante du resident(immobilite, marche, course) recuperee avec le suivi d’activite. Lorsqu’une activite est recue, l’activitedecide de l’etat du resident. Les diagrammes d’etats de la section 3.7 decrivent les etats et les transitionspossibles entre les etats. Dans un premier temps, l’activite impose l’etat du resident, puis l’etat duresident peut changer en fonction de la vitesse mesuree par la ceinture Zephyr. La vitesse de la ceintureest utilisee, car il n’est possible d’obtenir avec l’API de suivi d’activite, une detection d’activite aussirapide que celle transmise par la frequence cardiaque (a cause des restrictions de l’API et pour preserverla batterie du telephone). Un broadcastReceiver est enregistre et permet de recuperer l’activite.

this.stateContext = new StateContext(context,this);

this.stateContext.setState(new Still());

this.stateContext.getState().initHeartRate(context);

private class ActivityReceiver extends BroadcastReceiver {

@Override

public void onReceive(Context context, Intent intent) {

int activity = intent.getIntExtra("iActivity", 0);

stateContext.setState(getActivity(activity));

}

}

Code 4.7.3: Detection d’un probleme de frequence cardiaque

4.8 Gestion de la prise de medicament

Les medicaments a prendre sont recus lors de la connexion a l’application, puis ajouter un a un entant que notification.Le code 4.8.1 permet d’ajouter les rappels de medicaments en utilisant la classe AlarmManager fourniepar Android.

Intent intent = new Intent(context, DrugRecallReceiver.class);

intent.putExtra("drugs",

Resident.getInstance().getDrugs().get(k).getName());↪→

intent.putExtra("idNotification", pendingCounter);

PendingIntent pendingIntent = PendingIntent.getBroadcast(context,

pendingCounter, intent, PendingIntent.FLAG_UPDATE_CURRENT);↪→

arrayListIntent.add(pendingIntent);

AlarmManager alarmManager = (AlarmManager)

context.getSystemService(ALARM_SERVICE);↪→

alarmManager.set(AlarmManager.RTC_WAKEUP, System.currentTimeMillis()

+ (delay), pendingIntent);

pendingCounter++;

Code 4.8.1: Ajout des rappels de medicaments

70

Page 75: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

4.9 Messagerie resident-personnel

4.9.1 Reception d’un message

Pour la reception d’un message sous forme de notification PUSH envoye par Firebase, deux servicesdoivent etre demarres et inscrits dans le fichier de Manifest de l’application.

<service android:name=".Messaging.MyFireBaseMessagingService">

<intent-filter>

<action android:name="com.google.firebase.MESSAGING_EVENT" />

</intent-filter>

</service>

<service android:name=".Messaging.FirebaseIDService">

<intent-filter>

<action android:name="com.google.firebase.INSTANCE_ID_EVENT" />

</intent-filter>

</service>

Code 4.9.1: Ajout des services Firebase

Firebase doit etre ajoute dans le fichier ”build.gradle”.

compile 'com.google.firebase:firebase-messaging:9.6.1'

Code 4.9.2: Ajout de Firebase

Le code 4.9.3 est appele lorsqu’une notification PUSH est envoyee par Firebase.

public void onMessageReceived(RemoteMessage remoteMessage) {

try

{

Map<String, String> params = remoteMessage.getData();

JSONObject object = new JSONObject(params);

ModelQuestion question = new ModelQuestion();

question.setIdResident(object.getInt("idResident"));

question.setIdResponsable(object.getInt("idResponsable"));

question.setQuestion(object.getString("question"));

JSONArray array = new JSONArray(object.getString("responses"));

List<String> responses = new ArrayList<String>();

responses.add(array.getJSONObject(0).getString("response"));

responses.add(array.getJSONObject(1).getString("response"));

question.setResponses(responses);

createNotifications(question);

}catch (Exception e){

Log.d("Error with Firebase", e.toString());

}

}

Code 4.9.3: Reception notification PUSH de Firebase

71

Page 76: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

4.9.2 Envoi d’un message

Pour l’envoi d’un message ou la reponse a un message, les messages sont envoyes sous forme de requeteHTTP au serveur ”SEMS”, qui lui enverra une notification PUSH avec Firebase au destinataire.Le code 4.9.4 permet d’envoyer une requete HTTP au serveur ”SEMS” contenant un message.

public void sendMessage(String value) {

ModelMessage message = new ModelMessage(Resident.getInstance().getId(), value);

String json = new Gson().toJson(message);

RequestBody body = RequestBody.create(JSON, json);

Request request = new Request.Builder()

.url(url+SEND_MESSAGE)

.post(body)

.build();

Call postCall=client.newCall(request);

postCall.enqueue(new Callback() {

@Override

public void onFailure(Request request, IOException e) {

SendHttpResponse sendHttpResponse = new SendHttpResponse();

sendHttpResponse.httpResponse(false);

}

@Override

public void onResponse(Response response) throws IOException {

SendHttpResponse sendHttpResponse = new SendHttpResponse();

sendHttpResponse.httpResponse(true);

}

});

}

Code 4.9.4: Envoi de message

4.10 Detection de la chute d’un resident

Le code 4.10.1 est utilise pour detecter la chute d’un resident.

rride

ic void onSensorChanged(SensorEvent sensorEvent) {

Sensor mySensor = sensorEvent.sensor;

if (mySensor.getType() == Sensor.TYPE_ACCELEROMETER) {

float x = sensorEvent.values[0];

float y = sensorEvent.values[1];

float z = sensorEvent.values[2];

if(sqrt(x*x+y*y+z*z) < GFALL){

sendAlarm();

}

}

Code 4.10.1: Detection de chute

72

Page 77: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

5 Tests et validations

5.1 Introduction

Apres la partie d’implementation, ce chapitre presente les differents tests realises. Deux types detests sont realises. Premierement, des tests fonctionnels permettant de valider le fonctionnement del’application. Deuxiemement des tests utilisateurs permettant d’evaluer l’utilisabilite de l’application.

5.2 Tests fonctionnels

Les tests permettant de verifier le bon fonctionnement de la communication avec le serveur ont ete faitavec le serveur du projet ”SEMS” et a l’aide d’un serveur web en Node.js.

5.2.1 Connexion

Le tableau 5.1 represente les tests effectues pour la connexion a l’application.

Tests ResultatLes informations (username, password, token, phone) sont envoyees dans la requete OkUne pop-up apparaıt si le nom d’utilisateur ou mot de passe est vide OkUne pop-up apparaıt lorsque le serveur est indisponible OkUne pop-up apparaıt lorsque le nom d’utilisateur et/ou mot de passe est faux OkUne pop-up apparaıt lorsque le compte est deja connecte OkLorsque les informations de connexion sont correctes, l’utilisateur est redirige versla page d’accueil

Ok

Lorsque la connexion est reussie, les informations du resident sont recuperees Ok

Table 5.1 – Tests connexion

5.2.2 Deconnexion

Le tableau 5.2 represente les tests effectues pour la deconnexion a l’application.

Tests ResultatUne deconnexion envoi un une requete au serveur OkUne deconnexion redirige l’utilisateur vers la page de connexion Ok

Table 5.2 – Tests deconnexion

5.2.3 Mise a jour du resident

Le tableau 5.3 represente les tests effectues pour la mise a jour des informations du resident.

73

Page 78: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

Tests ResultatLes informations du resident (id, heartrate, activity, longitude, latitude) sont en-voyees au serveur tous les X secondes

Ok

Si le serveur n’est plus disponible, une erreur est generee Ok

Table 5.3 – Tests mise a jour informations resident

5.2.4 Envoi d’alarme

Le tableau 5.4 represente les tests effectues pour l’envoi d’alarme.

Tests ResultatLes informations de l’alarme (id, type, value, longitude, latitude, phone) sont trans-mises au serveur

Ok

L’utilisateur est averti qu’une alarme est envoyee par un bip sonore OkL’utilisateur est averti par un bip sonore si l’alarme n’a pas ete envoyee au serveur OkSi le serveur n’est plus disponible, une erreur est generee Ok

Table 5.4 – Tests envoie d’alarmes

5.2.5 Localisation d’un resident

Le tableau 5.5 represente les tests effectues pour la localisation.

Tests ResultatLes informations de localisation sont recuperees quand le capteur est active OkLes informations de localisation ne sont pas recuperees quand le capteur estdesactive

Ok

Le service est stoppe correctement lorsqu’il est desactive dans la configuration OkLe service est allume correctement lorsqu’il est active dans la configuration OkLe service est stoppe en cas de deconnexion avec l’API Ok

Table 5.5 – Tests localisation

La precision de la localisation a ete testee avec l’application fournie par IndoorAtlas [30]. La precisionest d’approximativement 3 a 4 metres pour les salles les mieux calibrees, pour les autres salles laprecision est d’environ 5 a 8 metres.

5.2.6 Suivi d’activite d’un resident

Le tableau 5.6 represente les tests effectues pour le suivi d’activite.

Tests ResultatLes informations de suivi d’activite sont recuperees quand le capteur est active OkLes informations de suivi d’activite ne sont pas recuperees quand le capteur estdesactive

Ok

Le service est stoppe correctement lorsqu’il est desactive dans la configuration OkLe service est allume correctement lorsqu’il est active dans la configuration OkLe service est stoppe en cas de deconnexion avec l’API Ok

Table 5.6 – Tests suivi d’activite

Detection d’une inactivite suspecte

Le tableau 5.7 represente les tests effectues pour la detection d’une inactivite suspecte.

74

Page 79: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

Tests ResultatLa detection d’une inactivite demarre lorsque l’activite est egale a ”still” OkLa detection d’une inactivite est stoppee lorsque l’activite n’est pas egale a ”still” OkUne alarme est generee lorsque l’utilisateur est immobile durant un temps X Ok

Table 5.7 – Tests detection inactivite suspecte

5.2.7 Recuperation de la frequence cardiaque

Le tableau 5.8 represente les tests effectues pour la recuperation de la frequence cardiaque.

Tests ResultatLes informations de la frequence cardiaque sont recuperees quand le capteur estactive

Ok

Les informations de la frequence cardiaque ne sont pas recuperees quand le capteurest desactive

Ok

Le service est stoppe correctement lorsqu’il est desactive dans la configuration OkLe service est allume correctement lorsqu’il est active dans la configuration OkLe service est stoppe en cas de deconnexion avec la ceinture OkL’application verifie que le Bluetooth est active, et si necessaire l’active OkEn cas de probleme de connexion, un message est affiche Ok

Table 5.8 – Tests recuperation frequence cardiaque

Detection d’un probleme de frequence cardiaque

Le tableau 5.9 represente les differents tests realises pour la detection d’un probleme de frequencecardiaque. Cette partie a ete testee a l’aide de tests unitaires disponibles a l’annexe A.3

75

Page 80: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

Tests ResultatRester dans l’etat immobile OkPasser de l’etat immobile a l’etat ”marche apres immobile” OkPasser de l’etat immobile a l’etat ”course apres immobile” OkPasser de l’etat immobile a l’etat alarme OkRester dans l’etat marche OkPasser de l’etat marche a l’etat ”immobile apres marche” OkPasser de l’etat marche a l’etat ”course apres marche” OkPasser de l’etat marche a l’etat alarme OkRester dans l’etat course OkPasser de l’etat course a l’etat ”immobile apres course” OkPasser de l’etat course a l’etat ”marche apres course” OkPasser de l’etat course a l’etat alarme OkRester dans l’etat ”immobile apres une marche” OkPasser de l’etat ”immobile apres marche” a l’etat immobile OkPasser de l’etat ”immobile apres marche” a l’etat ”marche apres immobile” OkPasser de l’etat ”immobile apres marche” a l’etat ”course apres immobile” OkPasser de l’etat ”immobile apres marche” a l’etat alarme OkRester dans l’etat ”immobile apres une course” OkPasser de l’etat ”immobile apres course” a l’etat immobile OkPasser de l’etat ”immobile apres course” a l’etat ”marche apres immobile” OkPasser de l’etat ”immobile apres course” a l’etat ”course apres immobile” OkPasser de l’etat ”immobile apres course” a l’etat alarme OkRester dans l’etat ”marche apres immobile” OkPasser de l’etat ”marche apres immobile” a l’etat marche OkPasser de l’etat ”marche apres immobile” a l’etat ”immobile apres marche” OkPasser de l’etat ”marche apres immobile” a l’etat ”course apres marche” OkPasser de l’etat ”marche apres immobile” a l’etat alarme OkRester dans l’etat ”marche apres course” OkPasser de l’etat ”marche apres course” a l’etat marche OkPasser de l’etat ”marche apres course” a l’etat ”immobile apres marche” OkPasser de l’etat ”marche apres course” a l’etat ”course apres marche” OkPasser de l’etat ”marche apres course” a l’etat alarme OkRester dans l’etat ”course apres immobile” OkPasser de l’etat ”course apres immobile” a l’etat course OkPasser de l’etat ”course apres immobile” a l’etat ”immobile apres course” OkPasser de l’etat ”course apres immobile” a l’etat ”marche apres course” OkPasser de l’etat ”course apres immobile” a l’etat alarme OkRester dans l’etat ”course apres marche” OkPasser de l’etat ”course apres marche” a l’etat course OkPasser de l’etat ”course apres marche” a l’etat ”immobile apres course” OkPasser de l’etat ”course apres marche” a l’etat ”marche apres course” OkPasser de l’etat ”course apres marche” a l’etat alarme Ok

Table 5.9 – Tests detection probleme frequence cardiaque

76

Page 81: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

5.2.8 Gestion de la prise de medicament

Le tableau 5.10 represente les tests effectues pour le rappel de la prise de medicament.

Tests ResultatUne notification est creee lorsque les rappels sont actives, a l’heure de la prise d’unmedicament

Ok

Une notification n’est pas creee lorsque les rappels sont desactives OkLa validation de la prise de medicament envoie une requete au serveur OkLa non validation de la prise de medicament envoie une requete au serveur OkUne deuxieme notification n’ecrase pas la premiere notification Ok

Table 5.10 – Tests rappel prise de medicament

5.2.9 Messagerie resident-personnel

Le tableau 5.11 represente les tests effectues pour la messagerie entre un resident et un membre dupersonnel.

Tests ResultatLors d’un clic sur un message, il est transmis au serveur OkLors de la reception d’un message, une notification est creee OkLe clic sur une reponse envoie une reponse au serveur OkUne deuxieme notification n’ecrase pas la premiere notification Ok

Table 5.11 – Tests messagerie

5.2.10 Detection de la chute d’un resident

La detection de la chute d’une personne a ete testee en condition reelle et ne permet actuellementpas de detecter correctement une chute. La phase de tests a demontre que l’application serait capablede detecter une chute d’une hauteur d’approximativement un metre, mais ne permet pas dans l’etatactuel de detecter une chute, lorsque le telephone mobile de l’utilisateur se trouve dans sa poche depantalon.

5.3 Tests utilisateurs

Les tests utilisateurs permettent d’evaluer la facilite d’utilisation de l’application mobile ainsi que leniveau d’apprentissage que l’utilisateur peut avoir avec l’application. L’application mobile a ete testeeavec les profils de personnes suivantes :

— 3 utilisateurs retraites (plus de 70 ans)— 2 utilisateurs dans la vie active (25 ans et 52 ans)

Les tests ayant ete realises sur deux profils de personnes (retraite, actif), les resultats s’interesserontprincipalement aux resultats des personnes retraitees. De facon globale, l’application mobile est jugeeutilisable par les utilisateurs (4 des 5 utilisateurs) ayant deja utilises une application mobile. La navi-gation dans l’application, la vue d’accueil, l’activation/desactivation de capteurs et l’envoi de messagesont juges faciles d’utilisation par les utilisateurs. Les utilisateurs ont particulierement apprecie la na-vigation avec le menu ”drawer”, car cela leur permettaient d’avoir facilement acces a tout le contenude l’application, sans devoir utiliser la touche retour pour changer de vue. La configuration de l’in-tervalle de la frequence cardiaque pour les differentes activites est jugee plus compliquee a utiliser.Pour chaque valeur entrees, il est necessaire d’appuyer sur le bouton retour pour descendre le clavieret le bouton permettant de valider les changements est parfois oublie. Pour une meilleure utilisationde l’application, les modifications suivantes peuvent etre apportees :

— Une barre de chargement lors de la connexion Bluetooth entre le telephone mobile et la ceintureZephyr

— Un retour utilisateur lors de l’envoi d’un message a un resident

77

Page 82: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

— Une pop-up pour valider la modification des parametres lorsque l’utilisateur change de vue, pourautant que les modifications n’aient pas deja ete sauvees.

Le scenario de tests et les resultats des tests se trouvent a l’annexe A.4.

78

Page 83: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

6 Conclusion

6.1 Introduction

Afin de terminer ce rapport, le chapitre de conclusion traite des objectifs atteints, des points a ameliorer,des perspectives futures de l’application et des remerciements.

6.2 Objectifs atteints

L’application RMMA est fonctionnelle, les objectifs principaux ont ete realises.En ce qui concerne les objectifs secondaires, une partie des objectifs secondaires ont ete implementes.Le tableau 6.1 represente l’etat des differents objectifs.

Objectifs ResultatCommunication entre l’application mobile et le serveur OkGeneration d’alarmes OkLocalisation d’un resident OkSuivi de l’activite d’un resident OkRecuperation de la frequence cardiaque OkGestion de la prise de medicament OkMessagerie resident-personnel OkDetection de chute d’un resident NOk

Table 6.1 – Recapitulatif des objectifs

6.3 Points d’ameliorations

Les ameliorations suivantes peuvent etre interessantes pour le projet RMMA :— Pour le respect de la protection des donnees medicale du resident, il serait necessaire de securiser

la communication entre le serveur et l’application mobile et de crypter les donnees stockees surle telephone mobile. La premiere mesure de securite serait d’utiliser imperativement le protocoleHTTPS au lieu de HTTP, ensuite mettre en place un systeme de Token (par ex : JSON WebToken) pour echanger de l’informations de maniere securisee via un jeton signe. La deuxiememesure de securite serait de crypter cote application mobile toutes les donnees sensibles del’utilisateur.

— Ajuster la detection de chute d’un resident.

6.4 Perspectives

Plusieurs perspectives peuvent etre imaginees pour le projet RMMA :— L’application RMMA pourrait etre portee sur une montre connectee equipee du WI-FI. Cette

solution pourrait etre interessante pour les residents n’etant pas a l’aise avec un telephone mobile.— L’application RMMA permet de localiser le resident dans une zone definie, il serait interessant

de pouvoir demarrer le GPS du telephone mobile lorsque le resident sort du perimetre de lieu devie. Ce qui permettrait de suivre ses deplacements en dehors de la residence.

79

Page 84: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

— Il existe sur le marche d’autres capteurs que pourraient integrer RMMA, par exemple unelectrocardiographe pour la detection d’un infarctus ou un capteur permettant de mesurer lafrequence respiratoire.

— Pour la recuperation de la frequence cardiaque, le bracelet Jawbone UP3 pourrait etre utilise,car il presente une meilleure alternative a la ceinture Zephyr, etant donne qu’il communique enBluetooth Low Energy ce qui permet une consommation moins elevee de la batterie. De plus, lebracelet Jawbone UP3 est plus confortable a porter.

6.5 Remerciements

Je tiens a exprimer mes remerciements les plus sinceres aux personnes qui m’ont aide, suivi et aiguilledurant l’ensemble du projet.

— Monsieur Pascal Bruegger, professeur en informatique a la Haute ecole d’Ingenierie et d’Archi-tecture de Fribourg pour avoir suivi mon projet en tant que superviseur.

— Monsieur Francois Kilchoer, professeur en Informatique a la Haute ecole d’ingenierie et d’archi-tecture Fribourg pour avoir suivi mon projet en tant que superviseur.

— Monsieur Marc Wuergler pour avoir suivi mon projet en tant qu’expert.— Monsieur Rafic Galli et Monsieur William Greppi pour leur collaboration durant le projet.— Les differentes personnes ayant pris du temps pour la realisation des tests utilisateurs.

6.6 Conclusions personnelles

J’ai trouve ce projet interessant et enrichissant. Ce projet m’a permis d’approfondir mes connaissancesdans le developpement mobile avec Android. J’ai particulierement apprecie mettre en place la partiede localisation d’interieur avec IndoorAtlas.

6.7 Contenu du CD

— Code source de l’application— Cahier des charges— Planning— Proces-verbaux— Rapport— Poster— Flyers

6.8 Declaration d’honneur

Je, soussignee, Aurelien Etienne, declare sur l’honneur que le travail rendu est le fruit d’un travailpersonnel. Je certifie ne pas avoir eu recours au plagiat ou a toutes autres formes de fraudes. Toutesles sources d’information utilisees et les citations d’auteurs ont ete clairement mentionnees.

Lieu et date : Fribourg, le 14.07.17Signature : Aurelien Etienne

80

Page 85: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Table des figures

1.1 Architecture du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1 Gestion des alarmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Schema de la residence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 Application mobile Fade fall detector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4 Plateforme web FallSafety Pro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.5 Application mobile EgiGeoZone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.6 Application mobile Geofency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.7 Application mobile Moniteur Frequence Cardiaque . . . . . . . . . . . . . . . . . . . . . 112.8 Application mobile Runtastic Pro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.9 Application mobile Google Fit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.10 Application mobile Patient Data Viewer [8] . . . . . . . . . . . . . . . . . . . . . . . . . 132.11 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.12 Architecture du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.13 Exemple JSON ressource member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.14 Exemple JSON ressources collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.15 Localisation par mesure du RSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.16 Beacons de la marque Estimote[11] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.17 Champs magnetique dans un batiment [13] . . . . . . . . . . . . . . . . . . . . . . . . . 202.18 Georeperage [19] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.19 Ceinture Zephyr HxM Heart Rate Monitor BT [24] . . . . . . . . . . . . . . . . . . . . . 262.20 Bracelet Jawbone UP3 [26] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.21 Fonctionnement Firebase Cloud Messaging [27] . . . . . . . . . . . . . . . . . . . . . . . 282.22 Envoi de notifications avec Firebase Cloud Messaging [27] . . . . . . . . . . . . . . . . . 28

3.1 Maquette de la page de login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.2 Maquette du menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.3 Maquette de la page d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.4 Maquette de la page de configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.5 Maquette de la page de messagerie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.6 Maquette de la pop-up pour la reception d’un message . . . . . . . . . . . . . . . . . . . 323.7 Maquette de la pop-up pour la prise de medicament . . . . . . . . . . . . . . . . . . . . 333.8 Diagramme de sequence pour la connexion . . . . . . . . . . . . . . . . . . . . . . . . . . 343.9 Diagramme de sequence pour la deconnexion . . . . . . . . . . . . . . . . . . . . . . . . 353.10 Diagramme de sequence pour l’initialisation des capteurs . . . . . . . . . . . . . . . . . . 363.11 Diagramme de sequence pour la recuperation de donnees des capteurs . . . . . . . . . . 373.12 Diagramme de sequence pour l’initialisation du capteur de frequence cardiaque . . . . . 383.13 Diagramme de sequence pour l’initialisation du capteur de geolocalisation . . . . . . . . 393.14 Diagramme de sequence pour l’initialisation du capteur de suivi d’activite . . . . . . . . 403.15 Diagramme de sequence pour l’initialisation du rappel de medicaments . . . . . . . . . . 413.16 Diagramme de sequence pour la configuration des capteurs . . . . . . . . . . . . . . . . 413.17 Diagramme de classe pour la gestion des capteurs . . . . . . . . . . . . . . . . . . . . . . 423.18 Diagramme de classe pour la communication client-serveur . . . . . . . . . . . . . . . . 443.19 Diagramme de classe pour la navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.20 Architecture du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.21 Frequence cardiaque en fonction de l’activite . . . . . . . . . . . . . . . . . . . . . . . . 52

81

Page 86: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

3.22 Etat immobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.23 Etat marche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.24 Etat course . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.25 Etat immobile apres une marche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.26 Etat immobile apres une course . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.27 Etat marche apres un repos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.28 Etat marche apres une course . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.29 Etat course apres un repos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.30 Etat course apres une marche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.31 Fonctionnement messagerie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.1 Vue de la page de login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.2 Vue du menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.3 Vue de la page d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.4 Vue de la page de messagerie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.5 Vue de l’ajout de message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.6 Vue de la notification de message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.7 Vue de la page de configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.8 Vue de la page de configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.9 Vue de la notification de rappel de medicament . . . . . . . . . . . . . . . . . . . . . . . 624.10 Plan HEIA batiment D etage 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.11 Calibration avec IndoorAtlas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.12 Resultat calibration avec IndoorAtlas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

A.1 Planning du projet - partie 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89A.2 Planning du projet - partie 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

82

Page 87: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Liste des tableaux

2.1 Choix plateforme de developpement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2 Exemple de schemas URI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3 Comparatif georeperage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.4 Comparatif suivi d’activite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.5 Frequence cardiaque par age au repos [21] . . . . . . . . . . . . . . . . . . . . . . . . . . 252.6 Frequence cardiaque par age durant une marche . . . . . . . . . . . . . . . . . . . . . . . 252.7 Frequence cardiaque par age durant une course a pied . . . . . . . . . . . . . . . . . . . 252.8 Recapitulatif analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.1 Definitions des routes du serveur REST . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.2 Activite utilisee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.3 Vitesse en fonction de l’activite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.1 Tests connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.2 Tests deconnexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.3 Tests mise a jour informations resident . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.4 Tests envoie d’alarmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.5 Tests localisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.6 Tests suivi d’activite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.7 Tests detection inactivite suspecte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765.8 Tests recuperation frequence cardiaque . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765.9 Tests detection probleme frequence cardiaque . . . . . . . . . . . . . . . . . . . . . . . . 775.10 Tests rappel prise de medicament . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785.11 Tests messagerie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

6.1 Recapitulatif des objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

A.1 Tests utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101A.2 Tests utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102A.3 Tests utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103A.4 Tests utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104A.5 Tests utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105A.6 Tests utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

83

Page 88: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Bibliographie

[1] Iter, “fade.” http ://fade.iter.es/, 2015.

[2] FallSafety, “Fallsafety pro.” https ://www.fallsafetyapp.com/how-it-works, 2017.

[3] EgiGeoZone, “Egigeozone.” https ://www.egigeozone.de/, 2014.

[4] Tion, “Geofency app.” http ://www.geofency.com/, 2017.

[5] Azumio, “Instant heart rate.” http ://www.azumio.com/s/instantheartrate/index.html, 2016.

[6] Runtastic, “Connect a heart rate monitor.” https ://help.runtastic.com/hc/en-us/articles/201751442-Connect-a-Heart-Rate-Monitor, 2015.

[7] Google, “Step up your fitness.” https ://www.google.com/fit/, 2016.

[8] G. G. Samyuktha Challa, “Patient data viewer : An android application for healthcare.”http ://ieeexplore.ieee.org/stamp/stamp.jsp ?arnumber=6139641&tag=1, 2010.

[9] P. Gambarotto, “Les services web de type rest.” https ://www.projet-plume.org/ressource/les-services-web-de-type-rest, 2010.

[10] L. Creurer, “Les technologies de geolocalisation indoor.” https ://blog.clever-age.com/fr/2015/05/21/les-technologies-de-geolocalisation-indoor/, 2015.

[11] Sketch, “Estimote beacons sketch resource.” https ://www.sketchappsources.com/free-source/1297-estimote-beacon-sketch-freebie-resource.html, 2017.

[12] IndoorAtlas, “Magnetic positioning.” http ://www.indooratlas.com/how-it-works/, 2017.

[13] Opusresearch, “Magnetic positioning.” http ://www.indooratlas.com/wp-content/uploads/2016/03/magnetic positioning opus jun2014.pdf, 2014.

[14] Anyplace, “Anyplace.” https ://anyplace.cs.ucy.ac.cy/, 2017.

[15] IndoorAtlas, “Indooratlas.” http ://www.indooratlas.com/, 2017.

[16] Redpin, “Redpin.” http ://redpin.org/, 2014.

[17] Estimote, “Estimote indoor location,” 2017.

[18] L. Chamberlain, “Geomarketing 101 : What is geofencing ?.”http ://www.geomarketing.com/geomarketing-101-what-is-geofencing, 2016.

[19] A. Developper, “Creating and monitoring geofences.” https ://develo-per.android.com/training/location/geofencing.html, 2014.

[20] N. Dore, “L’outil : Pathsense propose une solution alternative au gps sur smartphone.”https ://www.lesechos.fr/28/11/2014/lesechos.fr/0203975040237, 2014.

[21] Wikipedia, “Frequence cardiaque.” https ://fr.wikipedia.org/wiki/Fr

[22] T. informations, “Tachycardie.” http ://tachycardie.info/.

[23] G. Denis, “Bradycardie : definition, symptomes, traitement, de quoi s’agit-il ?.”http ://www.maxisciences.com/bradycardie/bradycardie-definition-symptomes-traitement-de-quoi-s-039-agit-il art37216.html, 2016.

[24] Z. technology, “Hxm heart rate monitor bt brochure.” https ://www.zephyranywhere.com/media/download/hxm1-br-p-zephyr-hxm-bt-brochure-201001-v01.pdf, 2010.

[25] Z. technology, “Hxm bluetooth api guide.” https ://www.zephyranywhere.com/media/download/hxm1-api-p-bluetooth-hxm-api-guide-20100722-v01.pdf, 2010.

[26] Jawbone, “Up3.” https ://jawbone.com/fitness-tracker/up3, 2016.

84

Page 89: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

[27] X. developper, “Firebase cloud messaging.” https ://develo-per.xamarin.com/guides/android/application fundamentals/notifications/firebase-cloud-messaging/, 2017.

[28] M. Seguy, “Apprendre a utiliser retrofit, okio, okhttp et moshi.” http ://mathias-seguy.developpez.com/tutoriels/android/utiliser-retrofit/, 2016.

[29] A. Attard, “Simple gson example.” http ://www.javacreed.com/simple-gson-example/, 2013.

[30] IndoorAtlas, “Example applications for indooratlas android sdk.”https ://github.com/IndoorAtlas/android-sdk-examples, 2017.

85

Page 90: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Glossaire

REST Representational State TransferHTTP Hypertext Transfer ProtocolURI Uniform Resource IdentifierRSS Received Signal StrengthSSID Service Set IDentifierMAC Media Access ControlPING Packet INternet GroperRFID Radio Frequency IdentificationGPS Global Positioning SystemAPI Application Programming Interface

86

Page 91: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

A Annexes

A.1 Logiciels et librairie utilises

Pour la realisation de ce projet, les logiciels et librairies suivant ont ete utilises :

A.1.1 Android Studio

Android Studio est l’environnement de developpement que Google fournit aux developpeurs Android.La version 2.2.1 a ete utilisee. Android studio est sous licence ”Apache License 2.0”.

A.1.2 GSON

GSON est une librairie qui peut etre utilise pour convertir des objects java dans leur representationJSON et inversement. La version 2.2.4 a ete utilisee. GSON est sous license ”Apache License 2.0”.

A.1.3 OkHttp

OkHttp est une librairie facilitant la communication HTTP. La version 2.5.0 a ete utilisee. OkHttp estsous license ”Apache License 2.0”.

A.1.4 ActivityRecognitionApi

ActivityRecognitionApi est utilise pour faire de la reconnaissance d’activite.

A.1.5 IndoorAtlas

IndoorAtlas est une API utilisee pour faire de la geolocalisation Indoor. La version 2.5 a ete utilisee.IndoorAtlas est sous license ”Non-Commercial API License Agreement”

A.1.6 TeXstudio

TeXstudio est un editeur de code Latex. La version 5.6.1 a ete utilisee. TexStudio est sous licence”GNU General Public License”.

A.1.7 GanttProject

GanttProject est un outil permettant de creer des planifications de projet. La version 2.8.1 a eteutilisee. GanttProject est sous licence ”GNU GPL”.

A.1.8 Visual Paradigm

Visual Paradigm est un logiciel permettant de faire de la modelisation UML. La version 13.1 a eteutilise. Visual Paradigm est sous license ”License Academic”.

87

Page 92: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rap

port

RM

MA

Pro

jetd

eB

achelor

A.2 Planning

Figure A.1 – Planning du projet - partie 1

88

Page 93: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rap

port

RM

MA

Pro

jetd

eB

achelor

Figure A.2 – Planning du projet - partie 2

89

Page 94: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

A.3 Tests unitaire pour la frequence cardiaque

@Test

public void testHeartRateState() throws Exception {

StateContext context = new StateContext();

/**

* Test still state

*/

context.setState(new Still());

assertThat(context.getState(), instanceOf(Still.class));

//The resident is still

context.getState().update(40, 0, context);

assertThat(context.getState(), instanceOf(Still.class));

//The resident was still and is now walking

context.getState().update(50,2,context);

assertThat(context.getState(), instanceOf(WalkAfterStill.class));

//The resident was still and is now running

context.setState(new Still());

context.getState().update(70,8,context);

assertThat(context.getState(), instanceOf(RunAfterStill.class));

//The resident is still

context.setState(new Still());

context.getState().update(50,0,context);

assertThat(context.getState(), instanceOf(Still.class));

//The resident was still and now have a heart rate problem

context.setState(new Still());

context.getState().update(70,0,context);

assertThat(context.getState(), instanceOf(Still.class));

context.getState().update(70,0,context);

assertThat(context.getState(), instanceOf(Still.class));

context.getState().update(70,0,context);

assertThat(context.getState(), instanceOf(Still.class));

context.getState().update(70,0,context);

assertThat(context.getState(), instanceOf(Still.class));

context.getState().update(70,0,context);

assertThat(context.getState(), instanceOf(Alarm.class));

Code A.3.1: Tests unitaire - etat immobile

90

Page 95: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

/**

* Test walk state

*/

context.setState(new Walk());

assertThat(context.getState(), instanceOf(Walk.class));

//The resident is Walking

context.getState().update(50, 3, context);

assertThat(context.getState(), instanceOf(Walk.class));

//The resident walked and is now walking

context.getState().update(40,0,context);

assertThat(context.getState(), instanceOf(StillAfterWalk.class));

//The resident walked and is now running

context.setState(new Walk());

context.getState().update(70,8,context);

assertThat(context.getState(), instanceOf(RunAfterWalk.class));

//The resident is walking

context.setState(new Walk());

context.getState().update(50,3,context);

assertThat(context.getState(), instanceOf(Walk.class));

//The resident walked and have a heart rate problem

context.setState(new Walk());

context.getState().update(90,3,context);

assertThat(context.getState(), instanceOf(Walk.class));

context.getState().update(90,3,context);

assertThat(context.getState(), instanceOf(Walk.class));

context.getState().update(90,3,context);

assertThat(context.getState(), instanceOf(Walk.class));

context.getState().update(90,3,context);

assertThat(context.getState(), instanceOf(Walk.class));

context.getState().update(90,3,context);

assertThat(context.getState(), instanceOf(Alarm.class));

Code A.3.2: Tests unitaire - etat marche

91

Page 96: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

/**

* Test run state

*/

context.setState(new Run());

assertThat(context.getState(), instanceOf(Run.class));

//The resident is running

context.getState().update(80, 8, context);

assertThat(context.getState(), instanceOf(Run.class));

//The resident runned and is now stilling

context.getState().update(80,0,context);

assertThat(context.getState(), instanceOf(StillAfterRun.class));

//The resident runned and is now walking

context.setState(new Run());

context.getState().update(70,5,context);

assertThat(context.getState(), instanceOf(WalkAfterRun.class));

//The resident is running

context.setState(new Run());

context.getState().update(70,8,context);

assertThat(context.getState(), instanceOf(Run.class));

//The resident walked and now have a heart rate problem

context.setState(new Run());

context.getState().update(110,8,context);

assertThat(context.getState(), instanceOf(Run.class));

context.getState().update(110,8,context);

assertThat(context.getState(), instanceOf(Run.class));

context.getState().update(110,8,context);

assertThat(context.getState(), instanceOf(Run.class));

context.getState().update(110,8,context);

assertThat(context.getState(), instanceOf(Run.class));

context.getState().update(110,8,context);

assertThat(context.getState(), instanceOf(Alarm.class));

Code A.3.3: Tests unitaire - etat course

92

Page 97: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

/**

* Test StillAfterWalk

*/

context.setState(new StillAfterWalk());

assertThat(context.getState(), instanceOf(StillAfterWalk.class));

//The resident is stillAfterWalk

context.getState().update(80, 0, context);

assertThat(context.getState(), instanceOf(StillAfterWalk.class));

//The resident was still and is now walking

context.getState().update(80,3,context);

assertThat(context.getState(), instanceOf(WalkAfterStill.class));

//The resident was still and is now running

context.setState(new StillAfterWalk());

context.getState().update(80,8,context);

assertThat(context.getState(), instanceOf(RunAfterStill.class));

//The resident is still

context.setState(new StillAfterWalk());

context.getState().update(110,0,context);

assertThat(context.getState(), instanceOf(StillAfterWalk.class));

context.getState().update(110,0,context);

assertThat(context.getState(), instanceOf(StillAfterWalk.class));

context.getState().update(109,0,context);

assertThat(context.getState(), instanceOf(StillAfterWalk.class));

context.getState().update(100,0,context);

assertThat(context.getState(), instanceOf(StillAfterWalk.class));

context.getState().update(90,0,context);

assertThat(context.getState(), instanceOf(StillAfterWalk.class));

context.getState().update(60,0,context);

assertThat(context.getState(), instanceOf(Still.class));

//The resident is still and have a heart rate problem

context.setState(new StillAfterWalk());

context.getState().update(110,0,context);

assertThat(context.getState(), instanceOf(StillAfterWalk.class));

context.getState().update(110,0,context);

assertThat(context.getState(), instanceOf(StillAfterWalk.class));

context.getState().update(110,0,context);

assertThat(context.getState(), instanceOf(StillAfterWalk.class));

context.getState().update(110,0,context);

assertThat(context.getState(), instanceOf(StillAfterWalk.class));

context.getState().update(110,0,context);

assertThat(context.getState(), instanceOf(StillAfterWalk.class));

context.getState().update(110,0,context);

assertThat(context.getState(), instanceOf(Alarm.class));

Code A.3.4: Tests unitaire - etat immobile apres marche

93

Page 98: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

/**

* Test StillAfterRun

*/

context.setState(new StillAfterRun());

assertThat(context.getState(), instanceOf(StillAfterRun.class));

//The resident is StillAfterRun

context.getState().update(80, 0, context);

assertThat(context.getState(), instanceOf(StillAfterRun.class));

//The resident was still and is now walking

context.getState().update(80,3,context);

assertThat(context.getState(), instanceOf(WalkAfterStill.class));

//The resident was still and is now running

context.setState(new StillAfterRun());

context.getState().update(80,8,context);

assertThat(context.getState(), instanceOf(RunAfterStill.class));

//The resident is still

context.setState(new StillAfterRun());

context.getState().update(110,0,context);

assertThat(context.getState(), instanceOf(StillAfterRun.class));

context.getState().update(110,0,context);

assertThat(context.getState(), instanceOf(StillAfterRun.class));

context.getState().update(109,0,context);

assertThat(context.getState(), instanceOf(StillAfterRun.class));

context.getState().update(100,0,context);

assertThat(context.getState(), instanceOf(StillAfterRun.class));

context.getState().update(90,0,context);

assertThat(context.getState(), instanceOf(StillAfterRun.class));

context.getState().update(60,0,context);

assertThat(context.getState(), instanceOf(Still.class));

//The resident is still and have a heart rate problem

context.setState(new StillAfterRun());

context.getState().update(110,0,context);

assertThat(context.getState(), instanceOf(StillAfterRun.class));

context.getState().update(110,0,context);

assertThat(context.getState(), instanceOf(StillAfterRun.class));

context.getState().update(110,0,context);

assertThat(context.getState(), instanceOf(StillAfterRun.class));

context.getState().update(110,0,context);

assertThat(context.getState(), instanceOf(StillAfterRun.class));

context.getState().update(110,0,context);

assertThat(context.getState(), instanceOf(StillAfterRun.class));

context.getState().update(110,0,context);

assertThat(context.getState(), instanceOf(Alarm.class));

Code A.3.5: Tests unitaire - etat immobile apres course

94

Page 99: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

/**

* Test WalkAfterStill

*/

context.setState(new WalkAfterStill());

assertThat(context.getState(), instanceOf(WalkAfterStill.class));

//The resident is WalkAfterStill

context.getState().update(84, 3, context);

assertThat(context.getState(), instanceOf(WalkAfterStill.class));

//The resident was walking and is now stilling

context.getState().update(80,0,context);

assertThat(context.getState(), instanceOf(StillAfterWalk.class));

//The resident was walking and is now running

context.setState(new WalkAfterStill());

context.getState().update(80,8,context);

assertThat(context.getState(), instanceOf(RunAfterWalk.class));

//The resident is walking

context.setState(new WalkAfterStill());

context.getState().update(110,3,context);

assertThat(context.getState(), instanceOf(WalkAfterStill.class));

context.getState().update(110,3,context);

assertThat(context.getState(), instanceOf(WalkAfterStill.class));

context.getState().update(109,3,context);

assertThat(context.getState(), instanceOf(WalkAfterStill.class));

context.getState().update(100,3,context);

assertThat(context.getState(), instanceOf(WalkAfterStill.class));

context.getState().update(90,3,context);

assertThat(context.getState(), instanceOf(WalkAfterStill.class));

context.getState().update(60,3,context);

assertThat(context.getState(), instanceOf(Walk.class));

//The resident is walking and have a heart rate problem

context.setState(new WalkAfterStill());

context.getState().update(110,3,context);

assertThat(context.getState(), instanceOf(WalkAfterStill.class));

context.getState().update(110,3,context);

assertThat(context.getState(), instanceOf(WalkAfterStill.class));

context.getState().update(110,3,context);

assertThat(context.getState(), instanceOf(WalkAfterStill.class));

context.getState().update(110,3,context);

assertThat(context.getState(), instanceOf(WalkAfterStill.class));

context.getState().update(110,3,context);

assertThat(context.getState(), instanceOf(WalkAfterStill.class));

context.getState().update(110,3,context);

assertThat(context.getState(), instanceOf(Alarm.class));

Code A.3.6: Tests unitaire - etat marche apres immobile

95

Page 100: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

/**

* Test WalkAfterRun

*/

context.setState(new WalkAfterRun());

assertThat(context.getState(), instanceOf(WalkAfterRun.class));

//The resident is WalkAfterRun

context.getState().update(84, 3, context);

assertThat(context.getState(), instanceOf(WalkAfterRun.class));

//The resident was walking and is now stilling

context.getState().update(80,0,context);

assertThat(context.getState(), instanceOf(StillAfterWalk.class));

//The resident was walking and is now running

context.setState(new WalkAfterRun());

context.getState().update(80,8,context);

assertThat(context.getState(), instanceOf(RunAfterWalk.class));

//The resident is walking

context.setState(new WalkAfterRun());

context.getState().update(110,3,context);

assertThat(context.getState(), instanceOf(WalkAfterRun.class));

context.getState().update(110,3,context);

assertThat(context.getState(), instanceOf(WalkAfterRun.class));

context.getState().update(109,3,context);

assertThat(context.getState(), instanceOf(WalkAfterRun.class));

context.getState().update(100,3,context);

assertThat(context.getState(), instanceOf(WalkAfterRun.class));

context.getState().update(90,3,context);

assertThat(context.getState(), instanceOf(WalkAfterRun.class));

context.getState().update(60,3,context);

assertThat(context.getState(), instanceOf(Walk.class));

//The resident is walking and have a heart rate problem

context.setState(new WalkAfterRun());

context.getState().update(110,3,context);

assertThat(context.getState(), instanceOf(WalkAfterRun.class));

context.getState().update(110,3,context);

assertThat(context.getState(), instanceOf(WalkAfterRun.class));

context.getState().update(110,3,context);

assertThat(context.getState(), instanceOf(WalkAfterRun.class));

context.getState().update(110,3,context);

assertThat(context.getState(), instanceOf(WalkAfterRun.class));

context.getState().update(110,3,context);

assertThat(context.getState(), instanceOf(WalkAfterRun.class));

context.getState().update(110,3,context);

assertThat(context.getState(), instanceOf(Alarm.class));

Code A.3.7: Tests unitaire - etat marche apres course

96

Page 101: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

/**

* Test runAfterStill

*/

context.setState(new RunAfterStill());

assertThat(context.getState(), instanceOf(RunAfterStill.class));

//The resident is runAfterStill

context.getState().update(50, 8, context);

assertThat(context.getState(), instanceOf(RunAfterStill.class));

//The resident was running and is now stilling

context.getState().update(80,0,context);

assertThat(context.getState(), instanceOf(StillAfterRun.class));

//The resident was running and is now walking

context.setState(new RunAfterStill());

context.getState().update(80,3,context);

assertThat(context.getState(), instanceOf(WalkAfterRun.class));

//The resident is running

context.setState(new RunAfterStill());

context.getState().update(110,8,context);

assertThat(context.getState(), instanceOf(RunAfterStill.class));

context.getState().update(110,8,context);

assertThat(context.getState(), instanceOf(RunAfterStill.class));

context.getState().update(109,8,context);

assertThat(context.getState(), instanceOf(RunAfterStill.class));

context.getState().update(102,8,context);

assertThat(context.getState(), instanceOf(RunAfterStill.class));

context.getState().update(70,8,context);

assertThat(context.getState(), instanceOf(Run.class));

//The resident is walking and have a heart rate problem

context.setState(new RunAfterStill());

context.getState().update(110,8,context);

assertThat(context.getState(), instanceOf(RunAfterStill.class));

context.getState().update(110,8,context);

assertThat(context.getState(), instanceOf(RunAfterStill.class));

context.getState().update(110,8,context);

assertThat(context.getState(), instanceOf(RunAfterStill.class));

context.getState().update(110,8,context);

assertThat(context.getState(), instanceOf(RunAfterStill.class));

context.getState().update(110,8,context);

assertThat(context.getState(), instanceOf(RunAfterStill.class));

context.getState().update(110,8,context);

assertThat(context.getState(), instanceOf(Alarm.class));

Code A.3.8: Tests unitaire - etat course apres immobile

97

Page 102: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

/**

* Test runAfterWalk

*/

context.setState(new RunAfterWalk());

assertThat(context.getState(), instanceOf(RunAfterWalk.class));

//The resident is runAfterWalk

context.getState().update(50, 8, context);

assertThat(context.getState(), instanceOf(RunAfterWalk.class));

//The resident was running and is now stilling

context.getState().update(80,0,context);

assertThat(context.getState(), instanceOf(StillAfterRun.class));

//The resident was running and is now walking

context.setState(new RunAfterWalk());

context.getState().update(80,3,context);

assertThat(context.getState(), instanceOf(WalkAfterRun.class));

//The resident is running

context.setState(new RunAfterWalk());

context.getState().update(110,8,context);

assertThat(context.getState(), instanceOf(RunAfterWalk.class));

context.getState().update(110,8,context);

assertThat(context.getState(), instanceOf(RunAfterWalk.class));

context.getState().update(109,8,context);

assertThat(context.getState(), instanceOf(RunAfterWalk.class));

context.getState().update(102,8,context);

assertThat(context.getState(), instanceOf(RunAfterWalk.class));

context.getState().update(70,8,context);

assertThat(context.getState(), instanceOf(Run.class));

//The resident is walking and have a heart rate problem

context.setState(new RunAfterWalk());

context.getState().update(110,8,context);

assertThat(context.getState(), instanceOf(RunAfterWalk.class));

context.getState().update(110,8,context);

assertThat(context.getState(), instanceOf(RunAfterWalk.class));

context.getState().update(110,8,context);

assertThat(context.getState(), instanceOf(RunAfterWalk.class));

context.getState().update(110,8,context);

assertThat(context.getState(), instanceOf(RunAfterWalk.class));

context.getState().update(110,8,context);

assertThat(context.getState(), instanceOf(RunAfterWalk.class));

context.getState().update(110,8,context);

assertThat(context.getState(), instanceOf(Alarm.class));

Code A.3.9: Tests unitaire - etat course apres marche

98

Page 103: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rapport RMMA Projet de Bachelor

A.4 Tests utilisateurs

L’annexe ci-dessous contient le scenario de tests propose aux utilisateurs et le resultat des differentstests utilisateurs qui ont ete realises.L’application a ete teste avec les profils de personnes suivantes :

1. 25 ans, gestionnaire en intendance, bonne aisance avec un telephone mobile (tableau A.2)2. 52 ans, employe de commerce, aisance moyenne avec un telephone mobile (tableau A.3)3. 74 ans, retraite, aisance moyenne avec un telephone mobile (tableau A.4)4. 70 ans, retraite, peu d’aisance avec un telephone mobile (tableau A.5)5. 75 ans, retraite, aisance moyenne avec un telephone mobile (tableau A.6)

99

Page 104: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rap

port

RM

MA

Pro

jetd

eB

achelor

Attributs d’utili-sabilite

Mesure Temps Temps ok Erreurs Erreurs ok

Initiale Connectez-vous avec le nom d’utilisateur � 1� et le mot de passe � 1 �

8 0

Initiale Accedez a la page de configuration 3 1Initiale Activez le capteur de frequence cardiaque 6 0Initiale Activez le capteur de suivi d’activite 6 0Initiale Changez la frequence minimale (60) et maxi-

male (80) pour l’activite immobile, puis enre-gistrez la configuration

10 1

Initiale Consulter la page d’accueil et verifier votrefrequence cardiaque et votre suivi d’activite

8 0

Initiale Accedez a la messagerie et transmettez unmessage

8 1

Initiale Repondez a un message recu sous forme denotification

8 1

Initiale Verifiez vos notifications pour la prise demedicament

5 1

Initiale Deconnectez-vous de l’application 5 1Apprentissage Connectez-vous avec le nom d’utilisateur � 1

� et le mot de passe � 1 �6 0

Apprentissage Desactiver le capteur de suivi d’activite 5 0Apprentissage Changez la frequence minimale (50) et maxi-

male (70) pour l’activite immobile, puis enre-gistrez la configuration

8 0

Apprentissage Accedez a la messagerie et transmettez unmessage

6 0

Apprentissage Repondez a un message recu sous forme denotification

6 0

Apprentissage Verifiez vos notifications pour la prise demedicament

6 0

Apprentissage Verifiez votre frequence cardiaque 6 0Apprentissage Deconnectez-vous de l’application 5 0

Table A.1 – Tests utilisateurs

100

Page 105: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rap

port

RM

MA

Pro

jetd

eB

achelor

Attributs d’utili-sabilite

Mesure Temps Temps ok Erreurs Erreurs ok

Initiale Connectez-vous avec le nom d’utilisateur � 1� et le mot de passe � 1 �

4 8 0 0

Initiale Accedez a la page de configuration 3 3 0 1Initiale Activez le capteur de frequence cardiaque 3 6 0 0Initiale Activez le capteur de suivi d’activite 3 6 0 0Initiale Changez la frequence minimale (60) et maxi-

male (80) pour l’activite immobile, puis enre-gistrez la configuration

8 10 0 1

Initiale Consulter la page d’accueil et verifier votrefrequence cardiaque et votre suivi d’activite

6 8 0 0

Initiale Accedez a la messagerie et transmettez unmessage

4 8 0 1

Initiale Repondez a un message recu sous forme denotification

6 8 0 1

Initiale Verifiez vos notifications pour la prise demedicament

4 5 0 1

Initiale Deconnectez-vous de l’application 4 5 0 1Apprentissage Connectez-vous avec le nom d’utilisateur � 1

� et le mot de passe � 1 �4 6 0 0

Apprentissage Desactiver le capteur de suivi d’activite 2 5 0 0Apprentissage Changez la frequence minimale (50) et maxi-

male (70) pour l’activite immobile, puis enre-gistrez la configuration

5 81

0

Apprentissage Accedez a la messagerie et transmettez unmessage

3 6 0 0

Apprentissage Repondez a un message recu sous forme denotification

3 6 0 0

Apprentissage Verifiez vos notifications pour la prise demedicament

2 6 0 0

Apprentissage Verifiez votre frequence cardiaque 2 6 0 0Apprentissage Deconnectez-vous de l’application 2 5 0 0

Table A.2 – Tests utilisateurs

101

Page 106: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rap

port

RM

MA

Pro

jetd

eB

achelor

Attributs d’utili-sabilite

Mesure Temps Temps ok Erreurs Erreurs ok

Initiale Connectez-vous avec le nom d’utilisateur � 1� et le mot de passe � 1 �

6 8 0 0

Initiale Accedez a la page de configuration 2 3 0 1Initiale Activez le capteur de frequence cardiaque 2 6 0 0Initiale Activez le capteur de suivi d’activite 2 6 0 0Initiale Changez la frequence minimale (60) et maxi-

male (80) pour l’activite immobile, puis enre-gistrez la configuration

6 10 0 1

Initiale Consulter la page d’accueil et verifier votrefrequence cardiaque et votre suivi d’activite

3 8 0 0

Initiale Accedez a la messagerie et transmettez unmessage

3 8 0 1

Initiale Repondez a un message recu sous forme denotification

4 8 0 1

Initiale Verifiez vos notifications pour la prise demedicament

3 5 0 1

Initiale Deconnectez-vous de l’application 2 5 0 1Apprentissage Connectez-vous avec le nom d’utilisateur � 1

� et le mot de passe � 1 �3 6 0 0

Apprentissage Desactiver le capteur de suivi d’activite 3 5 0 0Apprentissage Changez la frequence minimale (50) et maxi-

male (70) pour l’activite immobile, puis enre-gistrez la configuration

6 82

0

Apprentissage Accedez a la messagerie et transmettez unmessage

3 6 0 0

Apprentissage Repondez a un message recu sous forme denotification

4 6 0 0

Apprentissage Verifiez vos notifications pour la prise demedicament

2 6 0 0

Apprentissage Verifiez votre frequence cardiaque 2 6 0 0Apprentissage Deconnectez-vous de l’application 2 5 0 0

Table A.3 – Tests utilisateurs

102

Page 107: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rap

port

RM

MA

Pro

jetd

eB

achelor

Attributs d’utili-sabilite

Mesure Temps Temps ok Erreurs Erreurs ok

Initiale Connectez-vous avec le nom d’utilisateur � 1� et le mot de passe � 1 �

8 8 0 0

Initiale Accedez a la page de configuration4

3 0 1

Initiale Activez le capteur de frequence cardiaque 5 6 0 0Initiale Activez le capteur de suivi d’activite 4 6 0 0Initiale Changez la frequence minimale (60) et maxi-

male (80) pour l’activite immobile, puis enre-gistrez la configuration

1510 0 1

Initiale Consulter la page d’accueil et verifier votrefrequence cardiaque et votre suivi d’activite

6 8 0 0

Initiale Accedez a la messagerie et transmettez unmessage

7 8 0 1

Initiale Repondez a un message recu sous forme denotification

8 8 0 1

Initiale Verifiez vos notifications pour la prise demedicament

6 5 0 1

Initiale Deconnectez-vous de l’application 4 5 0 1Apprentissage Connectez-vous avec le nom d’utilisateur � 1

� et le mot de passe � 1 � 76 0 0

Apprentissage Desactiver le capteur de suivi d’activite 5 5 0 0Apprentissage Changez la frequence minimale (50) et maxi-

male (70) pour l’activite immobile, puis enre-gistrez la configuration

108

20

Apprentissage Accedez a la messagerie et transmettez unmessage

5 6 0 0

Apprentissage Repondez a un message recu sous forme denotification

5 6 0 0

Apprentissage Verifiez vos notifications pour la prise demedicament

4 6 0 0

Apprentissage Verifiez votre frequence cardiaque 5 6 0 0Apprentissage Deconnectez-vous de l’application 4 5 0 0

Table A.4 – Tests utilisateurs

103

Page 108: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rap

port

RM

MA

Pro

jetd

eB

achelor

Attributs d’utili-sabilite

Mesure Temps Temps ok Erreurs Erreurs ok

Initiale Connectez-vous avec le nom d’utilisateur � 1� et le mot de passe � 1 � 15

8 0 0

Initiale Accedez a la page de configuration8

3 0 1

Initiale Activez le capteur de frequence cardiaque 6 6 0 0Initiale Activez le capteur de suivi d’activite 6 6 0 0Initiale Changez la frequence minimale (60) et maxi-

male (80) pour l’activite immobile, puis enre-gistrez la configuration

1510

21

Initiale Consulter la page d’accueil et verifier votrefrequence cardiaque et votre suivi d’activite

7 8 0 0

Initiale Accedez a la messagerie et transmettez unmessage 10

8 0 1

Initiale Repondez a un message recu sous forme denotification 10

8 0 1

Initiale Verifiez vos notifications pour la prise demedicament

5 5 0 1

Initiale Deconnectez-vous de l’application 5 5 0 1Apprentissage Connectez-vous avec le nom d’utilisateur � 1

� et le mot de passe � 1 � 86 0 0

Apprentissage Desactiver le capteur de suivi d’activite 3 5 0 0Apprentissage Changez la frequence minimale (50) et maxi-

male (70) pour l’activite immobile, puis enre-gistrez la configuration

128

20

Apprentissage Accedez a la messagerie et transmettez unmessage

5 6 0 0

Apprentissage Repondez a un message recu sous forme denotification

4 6 0 0

Apprentissage Verifiez vos notifications pour la prise demedicament

5 6 0 0

Apprentissage Verifiez votre frequence cardiaque 5 6 0 0Apprentissage Deconnectez-vous de l’application 4 5 0 0

Table A.5 – Tests utilisateurs

104

Page 109: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

Rap

port

RM

MA

Pro

jetd

eB

achelor

Attributs d’utili-sabilite

Mesure Temps Temps ok Erreurs Erreurs ok

Initiale Connectez-vous avec le nom d’utilisateur � 1� et le mot de passe � 1 �

6 8 0 0

Initiale Accedez a la page de configuration 3 3 0 1Initiale Activez le capteur de frequence cardiaque 5 6 0 0Initiale Activez le capteur de suivi d’activite 5 6 0 0Initiale Changez la frequence minimale (60) et maxi-

male (80) pour l’activite immobile, puis enre-gistrez la configuration

1410 0 1

Initiale Consulter la page d’accueil et verifier votrefrequence cardiaque et votre suivi d’activite

7 8 0 0

Initiale Accedez a la messagerie et transmettez unmessage

8 8 0 1

Initiale Repondez a un message recu sous forme denotification

6 8 0 1

Initiale Verifiez vos notifications pour la prise demedicament

5 5 0 1

Initiale Deconnectez-vous de l’application 4 5 0 1Apprentissage Connectez-vous avec le nom d’utilisateur � 1

� et le mot de passe � 1 �5 6 0 0

Apprentissage Desactiver le capteur de suivi d’activite 4 5 0 0Apprentissage Changez la frequence minimale (50) et maxi-

male (70) pour l’activite immobile, puis enre-gistrez la configuration

128 0 0

Apprentissage Accedez a la messagerie et transmettez unmessage

5 6 0 0

Apprentissage Repondez a un message recu sous forme denotification

4 6 0 0

Apprentissage Verifiez vos notifications pour la prise demedicament

4 6 0 0

Apprentissage Verifiez votre frequence cardiaque 5 6 0 0Apprentissage Deconnectez-vous de l’application 2 5 0 0

Table A.6 – Tests utilisateurs

105

Page 110: Fili ere Informatique Projet de Bachelor Rapport : RMMApascal.bruegger.home.hefr.ch/RMS/project_reports/rapport_RMMA_v1.0.pdfHistorique Version Date Auteur(s) Modi cations 1.0 14/07/2017

-context : Context-isHeartRateSensorEnable : boolean-LocationSensorEnable : boolean-ActivitySensorEnable : boolean-FallSensorEnable : boolean-heartRateSensor : HeartRatesensor-locationSensor : LocationSensor-activitySensor : ActivitySensor-fallSensor : FallSensor-drugRecall : DrugRecall-drugRecallEnable : boolean-httpRequest : HTTPRequest

-SensorManager(context : Context)+getSensorsData() : void+getHeartRateSensorEnable() : boolean+setHeartRateSensorEnable(isHeartRateSensorEnable : boolean) : void+getLocationSensorEnable() : boolean+setLocationSensorEnable(isLocationSensorEnable : boolean) : void+getActivitySensorEnable() : boolean+setActivitySensorEnable(isActivitySensorEnable : boolean) : void+getFallSensorEnable() : boolean+setFallSensorEnable(isFallSensorEnable : boolean) : void+sendAlarm(type : String, value : int) : void+getDrugRecallEnable() : boolean+setDrugRecallEnable(drugRecallEnable : boolean) : void+resetHeartRateSensor(boolean start) : void+resetActivitySensor(boolean start) : void+resetLocationSensor(boolean start) : void+resetDrugRecall(boolean start) : void

SensorManagerService

-btClient : BTClient-btListener : BTListener-heartRate : int-context : Context

+HeartRateSensor(context : Context)+updateHeartRate(frequency : int)+detectSuspiciousHeartRate() : void+getHeartRate() : int+setHeartRate(heartRate : int) : void

HeartRateSensor

-locationManager : LocationManager-locationListener : LocationListener-latitude : double-longitude : double

+LocationSensor(sms : SensorManagerService)+updateLocation(latitude : double, longitude : double) : void+getLatitude() : double+setLatitude(latitude : double) : void+getLongitude() : double+setLongitude(longitude : double) : void

LocationSensor

+startSensor() : void+sendAlarm() : void+stopSensor() : void+error(type : String, error : String) : void

<<Interface>>Sensor

-activityRecognitionAPI : ActivityRecognitionAPI-activity : String-activityService : ActivityService-context : Context

+ActivitySensor(context : Context)+updateActivity(activity : String) : void+detectSuspiciousActivity() : void+getActivity() : String+setActivity(activity : String) : void

ActivitySensor

+FallSensor(context : Context)

FallSensor

ActivityRecognitionAPI

BTClient

-heartRateSensor : HeartRateSensor

+BTListener(heartRateSensor : HeartRateSensor)

BTListener

<<Interface>>ConnectListenerImpl

-activitySensor : ActivitySensor

+ActivityService(activitySensor : ActivitySensor)+handleActivities(activities : List<Activities>) : void

ActivityService

<<Interface>>GoogleApiClient.ConnectionCallbacks

-sms : SensorManager-fragmentManager : FragmentManager

#onCreate(savedInstance : Bundle) : void#onDestroy() : void+onBackPressed()+changeFragment(menuItem : MenuItem)-setupDrawer(navigationView nativationView)+updateLocation(lat : double, lon : double) : void+updateActivity(activity : String) : void+updateHeartRate(heartRate : int)+displayAlarm(type : String)+displayError(type : String, error : String)+enableSensor(type : String, enable : boolean)

MainActivity

#onCreateView()+updateLocation(lat : double, lon : double) : void+updateHeartRate(heartRate : int) : void+updateActivity(activity : String) : void

HomeFragment

-serverURL : String-client : OkHTTPClient

+HTTPRequest()+login(username : String, password : String) : Resident+updateResident(id : int, heartRate : int, lat : double, lon : double, activity : String)+sendAlarm(alarm : Alarm) : void+logout()+sendMessage(message : String)+respondMessage(message : String, idResp : int)+drugRecall(take : boolean)

HTTPRequest

-type : String-value : int-latitude : double-longitude : double

+getType() : String+setType(type : String) : void+getValue() : int+setValue(value : int) : void+getLatitude() : double+setLatitude(latitude : double) : void+getLongitude() : double+setLongitude(longitude : double) : void

Alarm

-httpRequest : HTTPRequest

#onCreate(savedInstance : Bundle) : void+checkLogin() : void

LoginActivity

-mainActivity : MainActivity

#onCreateView()+enableSensor(type : String, enable : boolean)

ConfigurationFragment

-resident : Resident-id : int-firstname : String-lastname : String-bornDate : String-illness : List<Illness>-drugs : List<Drugs>

-resident()+getInstance() : Resident+getId() : int+setId(id : int) : void+getFirstname() : String+setFirstname(firstname : String) : void+getLastname() : String+setLastname(lastname : String) : void+getBornDate() : String+setBornDate(bornDate : String) : void+getIllness() : List<Illness>+setIllness(illness : List<Illness>) : void+getDrugs() : List<Drugs>+setDrugs(drugs : List<Drugs>) : void

Resident

-name : String-type : String-drugs : List<String>

+getName() : String+setName(name : String) : void+getType() : String+setType(type : String) : void+getDrugs() : List<String>+setDrugs(drugs : List<String>) : void

Illness

+onCreateView()

MessagingFragment

-HEARTRATE-ACTIVITY-FALL-HTTP

ErrorType

-HEARTRATE-ACTIVITY-FALL

SensorType

-name : String-periods : Periods

+getName() : String+setName(name : String) : void+getPeriods() : Periods+setPeriods(periods : Periods) : void

Drugs

IALocationManager

IALocationListener

-context : Context

+DrugRecall(context : Context)

DrugRecall

OkHTTPClient

<<use>>

<<use>>

<<use>>

<<use>>

<<use>>

<<use>>

<<use>>

<<use>>

<<use>>

<<use>>

<<use>>

<<use>>

<<use>>

<<use>>

Visual Paradigm Standard Edition(Ecole d'ingenieurs et d'architectes de Fribourg)