E-SAVIOR: A WEARABLE PROTOTYPE DEVICE AND A … · Develop a prototype of wearable device in order...

E-SAVIOR: A WEARABLE PROTOTYPE DEVICE AND A MOBILEAPPLICATION FOR PILGRIMS SAFETY

April 2017

Abstract

Since the chronic heart diseases are the main cause of death, a lot of medical alert systems arecreated. However, these alert systems involve the participation of patients, which seems almostimpossible in some cases such as fainting or extreme discomfort. This has led to automate thedetection of malaise that is used in newer medical alert systems.

Going on Hajj is one of Muslim’s duties. However, we notice that the number of pilgrimsis increasing yearly (Over 1.9 million pilgrims performed the Hajj in September 2016). Crowdmanagement and Pilgrims’ safety become a must especially when the average age of pilgrims isaround 55 years and the climate is not propitious for them. Despite the continuous efforts thatare provided by the authorities, a very noteworthy number of deaths and losses are signaled inthis extremely crowded gathering.

So, this project aims to:

1. Develop a prototype of wearable device in order to monitor pilgrims with chronic heartdiseases. The prototype will be able to track pilgrims heart rate and pinpoint their locationin case of emergency.

2. Design and develop a mobile application that gathers all data sent by the prototype andalerts the hajj campaign responsible.

�HñÖÏ @ I. �.� ù

ë

�éJÓ QÖÏ @ I. Ê

�®Ë @

�@QÓ

@

à

@ úÎ« ZA

JK.

�H

A

��

� @

�éJJ.¢Ë@ P@

Y

KB

@�éÒ

¢

� @ áÓ @Q�

�J» : �

jÊÖÏ @

�ªK. ú

¯ ÉJj

��Ó Ñî

EðAª

�K

àñºK Y

�¯ð Q�J.» É¾

��. úæ

�QÖÏ @

àðAª

�K úÍ@

h. A

�Jm�

�' �

éÒ

¢� B@ è

Yëð . ú

æ�J

KQË @

.�é�JKYmÌ'@

�éJ

KA

�®Ê

�JË @

ñJ.

��JË @

�éÒ

¢

� @ Ð @Y

j

�J�@ úÍ@

øX

@ AÜØ YKY

��Ë@

��AëPB

@ ð

@ ZAÔ

«B

A¿

�HBAmÌ'@

àñJÊÓ 9.1 á« YK

QK) É�@ñ�JÓ XAKX P@

ú

¯ h. Aj. mÌ'@ XY«

à

@ AÖß.ð , ÕÎ�Ó É¿ úÎ« I. k. @ð i. mÌ'@

�é

��Q

¯ Z @X

@

à

@ A

JQ̄« @

X @

�é�A

g . Ð QÊÓ @QÓ

@ h. Aj. mÌ'@ l .

�'ñ®�K áÓ

@ iJ.�

@ Y

�®

¯ .(2016 Q�.Ò

�J�. � ú

¯ i. mÌ'@ Z @X

AK. @ñÓA

�¯ h. Ag

Xñêk. ¼AJë

à

@ áÓ Ñ

«QËAK. ð . ÑêË Õç

'CÓ Q�

« ÐAªË@ pA

JÖÏ @

à

@ úÍ@

�é¯A

�@

AÓA« 55 ñë h. Aj. mÌ'@ QÔ« ¡�ñ

�JÓ

@Yë ú

¯

à@Y

�®

®Ë @ð

�HñÖÏ @

�HBAg áÓ

�é

£ñjÊÓ X@Y«

@

�IÊm.

�� Y�¯ é

K @ B@

�éËð

ñ�ÖÏ @

�HAêm.

Ì'@ ÈC

g áÓ�éËð

YJ.Ó

.Q�J.ºË@ ©Òj.�JË @

: úÎK AÒ» ¨ðQå

��ÖÏ @ @

Yë

¬@Yë

@

àñº

�J� ½Ë

X úÎ«ð

��QÖÏ @ I. Ê

�¯

�HA

�J.

K ©J.

��K úÎ«

�èPY

�®Ë@ PAêm.

Ì'@ @YêËð .

�éJÓ QÖÏ @

�@QÓ

B@ ø

ð

X h. Aj. mÌ'@ I.

�¯@QK

PAêk. QKñ¢�� -1

.�é KPA¢Ë@

�HBAmÌ'@ ú

¯ é

K A¾Ó YKYm�

�'ð

�éÊÒmÌ'@ Èð

ñ�Ó éJJ.

��Kð PAêm.

Ì'@ @Yë áÓ

�é�JªJ.

JÖÏ @

�HA

KAJJ. Ë @ ©Òm.

�'. Ðñ

�®K È@ñm.

Ì'AK. �A

g�

�JJ.¢�� QKñ¢

��ð Õæ

Ò�

�� -2

. h. AmÌ'@ @YîE.

�é�A

mÌ'@

II

Contents

Contents V

List of Tables VI

List of Figures VIII

1 Introduction 11.1 Context and motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Problem statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Project Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Project Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5 Target users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.6 Report organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Domain related Concepts and Systems 42.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Adopted Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.3 Pre-project phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3.1 Technical feasibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3.1.1 Hardware Components . . . . . . . . . . . . . . . . . . . . . . . 7

2.3.1.1.1 Micro-controllers . . . . . . . . . . . . . . . . . . . . . 72.3.1.1.2 Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.1.1.3 Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.1.1.4 Programming Languages and Libraries . . . . . . . . . 12

2.3.1.2 Software Components . . . . . . . . . . . . . . . . . . . . . . . . 122.3.1.3 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3.2 Operational Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3.3 Schedule Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3.4 Budget feasibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.4 Requirements Gathering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.4.1 Competitor analysis of existing products . . . . . . . . . . . . . . . . . . . 15

2.4.1.1 Pilgrims Bracelet . . . . . . . . . . . . . . . . . . . . . . . . . . 152.4.1.2 Apple watch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.4.1.3 Alert1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.4.1.4 Life call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.4.1.5 Better alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.4.1.6 Lively . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.4.1.7 Synthesis and Discussion . . . . . . . . . . . . . . . . . . . . . . 20

2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

III

3 System Analysis and Design 213.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2 Domain Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2.2 Emergency Decision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3 Product backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.3.1 User Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.3.2 System WorkFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.3.3 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.3.3.1 Domain class diagram . . . . . . . . . . . . . . . . . . . . . . . . 273.3.3.2 Hardware Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.4 Connection between hardware and software components . . . . . . . . . . . . . . 313.5 Sprint Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4 Implementation and Testing 344.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.2 Programming Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2.1 Hardware Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.2.2 Software Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.3 Testing techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.3.1 Code Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.3.2 Non-Functional Requirements Testing . . . . . . . . . . . . . . . . . . . . 36

4.4 Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.4.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.4.1.1 Hardware design . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.4.1.2 Mobile design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.4.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.4.2.1 Hardware Development . . . . . . . . . . . . . . . . . . . . . . . 394.4.2.2 Software Development . . . . . . . . . . . . . . . . . . . . . . . . 39

4.4.3 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.4.3.1 Unit Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.4.3.2 Integration Testing . . . . . . . . . . . . . . . . . . . . . . . . . 444.4.3.3 Non-Functional Requirement Testing . . . . . . . . . . . . . . . 45

4.5 Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.5.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.5.1.1 Hardware design . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.5.1.2 Mobile design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.5.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.6 Sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.6.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.6.1.1 Hardware design . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.6.1.2 Mobile design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.6.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

References 51

Appendix 55

A Survey 56A.1 Survey Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

IV

B Interviews 64B.1 Interview questions with campaign administrator . . . . . . . . . . . . . . . . . . 64B.2 Interview questions with Cardiologist . . . . . . . . . . . . . . . . . . . . . . . . . 65B.3 Interview questions with Nurse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

V

List of Tables

2.1 Comparison between Arduino and Netdunio . . . . . . . . . . . . . . . . . . . . . 82.2 Arduino Different Boards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3 Comparison between PPG and ECG sensors technology [49][23] . . . . . . . . . . 112.4 E-savior hardware components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.5 Project Budget Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.6 Competitor Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.7 Competitor Analysis (Services) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1 General Estimation Guideline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2 Users stories, Features, and Benefits . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1 Sprint 1 Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.2 GPS and Arduino Pins Wiring . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.3 Sprint1 Unit Testing Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.4 Sprint 2 Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.5 PPG sensor and Arduino Pins Wiring . . . . . . . . . . . . . . . . . . . . . . . . 474.6 Thermistor sensor and Arduino Pins Wiring . . . . . . . . . . . . . . . . . . . . . 474.7 Sprint 3 Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

VI

List of Figures

1.1 Pilgrims performing Tawaf in Makkah . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Statistics of Death Causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1 Scrum Sprint Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 High Level Design of Smart Medical Alert System . . . . . . . . . . . . . . . . . 62.3 Arduino Microcontoller [6] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4 Netduino Microcontoller [33] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.5 E-Savior work-plan with respect to scrum methodology . . . . . . . . . . . . . . 142.6 Gantt chart of the E-Savior work-plan . . . . . . . . . . . . . . . . . . . . . . . . 142.7 Apple watch product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.8 Alert1 product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.9 Lifecall product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.10 Better alerts product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.11 Lively Smart watch product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1 Algorithm of Reading a pulse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2 Alert Flow Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.3 Workflow of E-Savior prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.4 E-Savior System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.5 Domain Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.6 Breadboard hardware components wiring . . . . . . . . . . . . . . . . . . . . . . 293.7 WiFi shield . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.8 Ublox-NEO6 GPS module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.9 Max30100 Heart rate sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.10 thermistor sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.11 Connection between hardware and software . . . . . . . . . . . . . . . . . . . . . 323.12 Sprints overall output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1 E-savior GPS hardware design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.2 E-savior GPS class diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.3 Pilgrims locations on the map GUI . . . . . . . . . . . . . . . . . . . . . . . . . . 384.4 GPS output data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.5 Sprint 1 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.6 Sprint 1 GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.7 Connectivity Positive Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.8 Connectivity Negative Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.9 Add Marker Positive Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.10 Add Marker Positive Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.11 GPS Serial Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.12 Sprint 1 Arduino Unit Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.13 Sprint1 Integration Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.14 Sprint1 Reliability Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

VII

4.15 GPS GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.16 E-Savior PPG sensor hardware design . . . . . . . . . . . . . . . . . . . . . . . . 474.17 E-Savior temperature hardware design . . . . . . . . . . . . . . . . . . . . . . . 484.18 E-Savior health monitoring class diagram . . . . . . . . . . . . . . . . . . . . . . 484.19 Pilgrim profile GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.20 Application alerts class diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.21 Alerts generated GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

VIII

Chapter 1

Introduction

1.1 Context and motivation

Older adults present a higher risk for many types of diseases that can lead to severe healthproblems such as a variety of heat-related illnesses or death. In addition, warm weather andoutdoor activity can complicate the situation. For these reasons, it is important to help olderpeople to avoid it or to take action.

Going on Hajj is one of Muslim’s duties (See Fig.1.1). Some muslims are excused from thisobligation in case of health illness or lack of money. However, we notice that the number ofpilgrims is increasing yearly (Over 1.9 million pilgrims performed the Hajj in September 2016)[16]. Crowd management and Pilgrims’ safety become a must especially when the average ageof pilgrims is around 55 years [16] and the climate is not propitious for them. Despite thecontinuous efforts that are provided by the authorities, a significant number of deaths and lossesare signaled in this extremely crowded gathering.

Figure 1.1: Pilgrims performing Tawaf in Makkah

As technology becomes more and more embedded in our lives and with the emergence ofInternet of Things, we must recognize that pilgrims can take benefits from them. In this project,We will present a solution based on the use of microcontrollers, sensors and mobile applicationtechnologies that help campaigns and Hajj authorities in the identification of pilgrims as well asin pilgrims’ health control.

Our motivation consists on the development of a wearable prototype device and a mobileapplication to monitor and track pilgrims. The wearable prototype device contains microcon-troller, sensors and shields to monitor the exact heartbeats and pinpoint the exact position ofthe pilgrims that we are looking for. The mobile application gathers all information (heartbeatsand position) sent by the wearable prototype device and alerts the campaigns’ responsible inemergency cases.

1

1.2 Problem statement

Chronic diseases are the main cause of death as shown in figure 1.2 [34]. For that, many medicalalert systems were created. The first systems were introduced in 1970, which are classified asbasic push-button devices. These alert systems requires the user participation when he/she feelsa certain discomfort by pushing a button that will transmit a signal to a base line. It is connectedto a home line phone to alert the emergency operator. However, the user participation mightget impossible in some cases such as fainting or extreme discomfort. To overcome this problem,many new automated detection of malaise systems has been created.

Figure 1.2: Statistics of Death Causes[34]

Detection of malaise can be based on the use of accelerometers and Gyroscopes to interpretchanges in a body’s position [26]. However, this detection is not so reliable and false alerts canbe occurred by rapid movements. According to the American heart association [8], a suddendecline or a change in blood pressure is interpreted as a sign of dizziness, fainting or heartattack. By measuring blood pressure, heart rate and temperature, the robust medical alertsystem, becomes more accurate and reliable.

The project aims to:

1. Develop a prototype of wearable device in order to monitor pilgrims with chronic heartdiseases. The prototype will be able to track pilgrims heart rate disorder and pinpointtheir physical position in case of emergency. Appropriate modules and sensors have to bechosen for an accurate result.

2. Design and develop a mobile application that gathers all data sent by the prototype andalerts the hajj campaign responsible.

2

1.3 Project Objectives

This project is meant to be used by Hajj campaigns to help in protecting their pilgrims fromgetting hurt or even die. The main aim of E-savior is to reduce the probability of accidentsand help the pilgrims stay safe and by remotely monitoring pilgrims anywhere and anytime. Inorder to achieve that, E-savior should fulfill the following objectives:

1. Monitoring and controlling the pilgrims health.

E-savior is designed to observe and record faintness or extreme discomfort of pilgrims, asignal is sent to campaign responsible to take the right decision and control the situation.

2. Emergency Assistance. In emergency cases, the campaign responsible is alerted ofpilgrims location by dint of the use of geo-localisation service.

This project will make benefit to hajj campaign that needs to provide safety for its pilgrimsby:

1. Providing campaigns with pilgrims heart rate, blood pressure and temperate ;

2. Helping to determine pilgrims necessary situation;

3. Making pilgrims feel safe and secure;

4. Reducing death rate, by detecting possible medical emergency situations.

1.4 Project Scope

This project consists of creating a wearable prototype device that monitors the pilgrims heartrate, blood pressure as will as temperature; and then alerts the campaign responsible in case ofemergency. The project will be completed by May 2017. The Prototype modules will includea heartbeats, blood pressure and temperature measurements, an alert generator and a GPSmodule to pinpoint the pilgrim.

1.5 Target users

E-Savior is targeting both pilgrims with chronic diseases, Ministry of Hajj and hajj campaignsthat arrange the whole process for the pilgrim to complete hajj.

1.6 Report organization

This project contains three chapters. After describing the context and the problem statementthat encourage us to implement ”E-Savior”, an overview of the contribution is defined in thefirst chapter. Chapter 2 presents the adopted software development methodology (Scrum) andthe pre-project phase. The outcome of preproject phase is presented through the feasibility testsas well as the overview of competitors systems, the interviews and surveys. Chapter 3 discussesthe analysis of the wearable hardware design followed by the software components that is usedto conduct this project.

3

Chapter 2

Domain related Concepts andSystems

2.1 Introduction

In this chapter, we start by describing the selected methodology that is used to develop E-savior, which is a wearable prototype device and a mobile application. Then, we detail thepreproject phase in terms of feasibility study in which an overview of existing medical alertsystems and their main features, strengths and weakness is presented. Based on our analysis ofthe similar systems, the available hardware and software components as well as the interviewwith cardiologists, we present an abstract design of ”E-Savior”.

2.2 Adopted Methodology

Software Development Methodology (SDM) is a framework that is used to structure, organizeand control the process of developing information systems [35]. There are different types ofSDM that are classified by category: from linear to agile. In order to build our system, we willuse an agile methodology. More specifically, Scrum [38] is chosen.

Scrum is an iterative framework that is used for managing the development of complexsoftware and product since the early of 1990s. By following Scrum, the system is grown incrementby increment. Each of them is tested to ensure a high quality of the release [37].

The scrum staff is recognized as a small-sized team. Each member plays a role which canbe:

Product owner. His/her main task is to ensure that the product is delivered at the mostvalue, provide a clear guidance for the team and manage the product backlog that isbasically a list of things that needs to be done within the project.

Scrum master. He/she manages how information is exchanged, facilitates the Scrum processand makes sure that the Scrum team coheres to Scrum theory, practices, and rules.

Scrum team. Usually 5 to 7 members who are responsible for driving the plan for each sprintwith skill sets, and cross-train. All members of the team collaborate and assist one anotherto ensure a successful sprint completion.

4

Sprints

Scrum development process is expressed with the use of fixed-length iterations developmentcycles called Sprints. A sprint usually take two to four weeks (See Fig. 3.6). The process startswhen the product owner specifies the product requirements in order to create a prioritized storiesthat called a product backlog then the team selects some of the stories to be implemented andadd them to the sprint backlog to start the iteration [30].

Figure 2.1: Scrum Sprint Workflow

The product owner has the responsibility to elaborate the product backlog from which isextracted the sprint backlog. The later is a list of user stories that are identified by the Scrumteam to be completed during the Scrum sprint. The scrum team identifies the tasks necessaryto complete each user story.

We will use Scrum to develop our project for these reasons:

1. Scrum is suitable for complex products [41].

2. Scrum is flexible. In fact, scrum copes up with requirements change. In any stage, memberscan add new stuff to product backlog.

3. Scrum increases the team productivity by focusing on the collaboration and daily commu-nication between scrum team member.

4. Scrum improves the deliverable quality. Since at the end of each sprint, a test is conductedto assess and validate the release,so it’s quality is enhanced.

5. Scrum identifies easily the problems. Because of the continual feedback and its iterativenature that allows to discover problems.

5

2.3 Pre-project phase

The main aim of pre-project phase is to determine whether it would be technically, economically,and operationally feasible to develop a system. For that, a feasibility study is done where fourtests are conducted technical, operational, economic, and schedule tests. In this section, wedescribe the outcome of each of these tests.

2.3.1 Technical feasibility

The purpose of technical feasibility is to provide information on how to deliver the project froma technical aspect and what technologies will be used to produce the project efficiently [48].We emphasize through technical feasibility study, our needs in terms of software and hardwarerequirements as well as their existence.

Smart medical alert systems are considered as embedded systems (See Fig. 2.2), whichinvolve the use of micro-controller, sensors, and software. The choice of these components hasan impact on the efficiency of the resulting product. In the following sections, we describe thehardware components in terms of availability, connectivity, strengths and limitations in orderto choose the suitable ones.

Figure 2.2: High Level Design of Smart Medical Alert System

6

2.3.1.1 Hardware Components

This section describes the kind and type of the microcontroller and sensors used in the project.

2.3.1.1.1 Micro-controllers

Arduino. Arduino is an open-source cross-platform microcontroller (See Fig.2.3) that is ableto read inputs from various kind of sensors and shields then turns those readings into anoutput by using the Arduino Integrated Development Environment (IDE) [10]. The IDEassists the communication with the micro-controller and helps the bootloader to uploadC/C++code file into the Arduino memory. So, it will get executed immediately.

Figure 2.3: Arduino Microcontoller [6]

Netduino. Netduino is an open-source electronics platform based on .NET Micro softwareFramework (See Fig. 2.4) [50]. Its pins are similar to Arduino’s pins because of that itbecomes compatible with some of Arduino’s shields. Microsoft Visual Studio is used tocommunicate with the micro-controller using visual C sharp language.

Figure 2.4: Netduino Microcontoller [33]

The table 2.1 is a comparison between Arduino and Netduino microcontrollers. Based on it,we concluded that the suitable micro-controller for this project is Arduino. The selection hastaken in account three aspects. First of all, the flexibility to build projects. In fact, a lot of shieldsand sensors are compatible with Arduino micro-controller. Second the availability of librarieswhich makes the process easier to implement. Finally, the existence of a large community withdifferent level of expertise that will facilitate our learning process.

7

Table 2.1: Comparison between Arduino and Netdunio

Criteria Arduino Netduino

Hardware Open-source electronicsplatform

Open-source .NET Mi-crosoft

Shieldavailability[50]

A Lot of compatibleshields

Not all Arduino shieldsare tested and proven towork on Netduino

Libraries[27] Hundreds of additionallibraries that can beused with Arduino

Some Arduino librariesneeds a modification tobe used by Netduino

Sensors compatible with anysensor

compatible with anysensor

OS Platform Cross-platform runs onmac, windows and linux

Cross-platform runs onmac,windows and linux

Software Program-ming language[50]

C/C++ Visual C],.NET

Connectivity[7] Arduino Integrated De-velopment Environment

Visual Studio IDE

Users Anyone Experts

PrototypingEnvironment[27]

Process is straightfor-ward,large community

Process is less straight-forward

Community[50] Large community Small community

Price[50] Inexpensive (less than50$)

Expensive (more than69$)

There are several Arduino board models available in market (See Table.2.2). We have chosenArduino UNO board for many reasons which are 1)it is compatible with shields, 2) it is the bestboard to get started with electronics and coding, 3) it is suitable for prototyping purpose and4) it is the most robust board. In addition, UNO is the most used and documented board ofthe whole Arduino and Genuino family [46].

8

Tab

le2.

2:A

rdu

ino

Diff

eren

tB

oard

s

Ard

uin

ob

oard

Pro

cess

or

speed

Dig

ital

I/O

Pin

s

An

alo

gIn

pu

tS

eri

al

Port

Sh

ield

com

pati

-b

ilit

y

Sp

ecia

lFeatu

res

Un

o16

MH

z14

61

Exce

llen

t

Un

oE

th-

ern

et

16M

Hz

146

1V

ery

Good

Has

Eth

ern

etP

ort.

Re-

qu

ire

FT

DI

cab

leto

pro

gram

Mega

16M

Hz

5416

4G

ood

Mega

AD

K16

MH

z54

164

Good

Wor

ks

wit

hA

nd

roid

de-

velo

pm

ent

kit

Leon

ard

o84

MH

z20

121

Fai

rU

SB

pro

gram

min

gP

ort

Du

e16

MH

z54

124

Poor

Fast

est

pro

cess

or

Mic

ro32

MH

z20

121

N/A

Sm

all

est

boar

dsi

ze

Flo

ra32

MH

z8

41

N/A

Fab

ric-

frie

nd

ly

DC

Boar-

du

ino

16M

Hz

146

1N

/AB

uil

dw

ith

ou

th

ead

er.

Req

uir

eF

TD

Ica

ble

top

rogr

am

US

BB

oard

-u

ino

16M

Hz

146

1N

/AB

uil

dw

ith

ou

th

ead

er.

Req

uir

eF

TD

Ica

ble

top

rogr

am

Menta

16M

Hz

146

1E

xce

llen

tM

int-

Tin

size

.R

equ

ire

FT

DI

cab

leto

pro

gram

9

2.3.1.1.2 Sensors

Before describing the sensors that are available, we will start by explaining how to measurethe heart rate. An interview was conducted with a cardiologist and a nurse to specify whichmeasures can be used to detect a faintness, and emergency situation. Heart rate, temperature,and blood pressure are key measures to predict a crisis. While interviewing we asked themif heart diseases can lead to death and whether we can know if there is a problem with thepilgrim by measuring the heart beats to try and help them. They replied that yes most ofpilgrims dies because of having heart issues especially heart attacks and the low performanceof the heart muscles. Also, they replies with yes that measuring heartbeats is the first step toprotect pilgrims but they should immediately get checked by a doctor to know what is the exactproblem.

Heart Rate (HR). HR reflects the frequency of a complete heartbeat from its generation tothe beginning of the next beat within a specific time. It is typically expressed as beatsper minute (bpm). HR can be extracted using ECG and PPG sensors[23].

Electrocardiography (ECG). ECG measures the heart’s electrical activity represented as avector between two point charges, using electrodes placed on the skin. It is mainly usedfor measuring heart rate and monitoring hearts electrical system[15].

Photoplethysmography (PPG). It is an optical measurement technique that uses lightbased technology to sense the rate of blood flow by measuring the amount of the re-flected light by blood flow [24]. It can be used as a replacement of ECG of HRV1 analysishealth subjects. Also it measures of vessel stiffness.

Based on the following comparison (See Table. 2.3), we decided to choose the PPG sensorsTechnology because it is more convenient with our project for many reasons. First, It is asmall-sized sensor that can easily connected to Arduino board with out additional health shield.Also it is dry sensors so it can be attached much quicker to the wrist or fingertip, which make itsuitable with wearable devices. In addition, it provides accurate heart rate measurements withgood response time.

Photoplethysmography Procedure. E-savior will measures the heart rate and blood pres-sure with a PPG sensor located on the back of the bracelet device. The heart rate sensorbased on the photoplethysmography technology, the later depends on a simple fact whichis, since the color of blood is red because it reflects red light and absorbs green light, sothe technology will measure the heart rate and blood pressure with an optical LED lightsource and an LED light sensor to detect the amount of blood flowing through the wristat any given moment. First the light shines through the skin ,so when the heart beats,the blood flow in the wrist and the green light absorption is greater and reflection are less.Between beats,green light absorbtion become less and the reflection is greater. However byflashing its LED lights hundreds of times per second, E-Savior can calculate the variationsin the light reflections that interpreted as heartbeats and blood pressure. [39].

E-savior will measures the temperature using thermistor sensor. Body temperature can bemeasured from different parts of body , but for this project temperature will be measuredfrom the wrist.

1Heart Rate Variability (HRV) expresses the natural variation of Inter-Beat-Interval (IBI) values from beat tobeat.

10

Tab

le2.

3:C

om

pari

son

bet

wee

nP

PG

and

EC

Gse

nso

rste

chn

ology

[49][

23]

Cri

teri

aE

CG

PP

G

Resp

on

seT

ime

Don

’tre

qu

ire

long

sett

lin

gti

mes

Req

uir

esh

ort

-set

tlin

gti

mes

,b

ut

take

lon

ger

than

the

EC

Gse

nso

r

Accu

racy

Acc

ura

teL

ess

accu

rate

than

EC

G

Tech

nolo

gy

use

dE

lect

rod

esco

nn

ecte

dto

diff

eren

tb

od

yp

art

sL

ED

that

sen

ds

ligh

tin

toth

eti

ssu

e

Siz

eL

arg

esi

zeS

mal

lsi

ze

Con

necti

vit

yR

equ

ire

ad

dit

ion

alh

ealt

hsh

ield

Con

nec

ted

dir

ectl

yto

the

Ard

uin

o.

Equ

ipS

en

sor

-F

ou

rel

ectr

od

esp

lace

onth

ech

est

-U

seof

con

du

ctiv

ege

l-

Fin

gert

ip,

earl

ob

ean

dw

rist

-N

on

eed

for

gel

Lim

itati

on

s-

Larg

esi

zeof

the

sen

sors

-L

imit

edco

nn

ecti

on

toth

eb

od

yn

eed

for

con

-d

uct

ive

gel

-Im

pra

ctic

alan

dn

otea

syto

equ

ip

-S

epar

ate

nois

e-

Diff

eren

tsk

into

nes

abso

rbli

ght

diff

eren

tly

-T

he

loca

-ti

onof

the

sen

sor

onth

eb

od

yp

rese

nts

un

iqu

ech

alle

nge

s

11

2.3.1.1.3 Synthesis

As explained in previous sections, we will use a number of hardware components in order tomeasure the heart rate and to pinpoint the location of pilgrim in case of emergency. The table 2.4summarizes the different components that will be used to develop E-saviour hardware prototype.

Table 2.4: E-savior hardware components

Module name How to be used?

Arduino UNO Main board that will used to build the projectin top of it

Heart Rate sensor To read the pulse and send it as an input toArduino UNO

GPS module To get the latitude and longitude of a specificlocation

Wi-fi shield To send data over the internet(to and from) themobile application

Battery 5-9v DC To power the board externally without the needof USB cable after code installation

Breadboard Facilitate building circuits

2.3.1.1.4 Programming Languages and Libraries

In this section, we are going to discuss the languages, software and the libraries used in orderto develop the hardware component of E-Savior.

1. Programming languages and general software.

(a) The Arduino programming language that is based on C/C++ for programming thehardware component.

(b) Arduino Software (IDE) to make it easy to write code and upload it to the Arduinoboard memory.

(c) Fritzing is an open source hardware initiative for documenting the prototype.

2. Libraries. A software library is a collection of data and precompiled programming codethat a programmer can use to develop software programs and applications [11].

(a) TinyGps++ library: This library is by mikalhart that does a lot of the ’heavy lifting’required for receiving data from GPS module.

(b) HR spark-fun library: Heart rate library will help to calculate Pulse, Signal, HRV,BPM, QS ,and Scale.

(c) SoftwareSerial Library: it allows the Atmega processing unit chip to receive serialcommunication.

2.3.1.2 Software Components

In this section, we enumerate the programming languages and tools that are used to developE-savior mobile application. The later will be by the hajj campaign responsible.

1. Programming languages

(a) The Android IDE programming language that is based on JAVA and Xml for pro-gramming the application.

12

(b) PHP, SQL are required for connecting with the database.

2. General softwares

(a) Android studio (IDE) to build an Android application.

(b) Mamp is a local server environment for accessing a local PHP server.

(c) Genymotion is a Android emulator for app developers and testers.

2.3.1.3 Challenges

This project requires a strong expertise and a background view on the following aspects :

1. Wearable technology;

2. Electronic circuits;

3. Mobile application development;

4. Interaction between hardware and software components.

All mentioned aspects are not previously covered and challenging to our knowledge.

2.3.2 Operational Feasibility

Operational feasibility is about supporting and performing the most important tasks of a project.It mainly focuses on how stakeholders will receive and operate on this project. In order to knowif any pilgrims are willing to use this prototype, we spread a survey to them just to know howare they willing to use this prototype and if they are going to get comfortable with it. We foundout that 82% of pilgrims are agreeing to use this prototype to monitor health, therefore targetedusers (pilgrims) can use E-savior without difficulties (See Appendix.A).

From campaigns viewpoint that, this prototype will help them to reduce the cost of havinga supervisor for each group of pilgrims, to monitor their pilgrims easily and to reduce theprobability of pilgrims death.

The implementation of this project has many benefits either for pilgrims side or campaignsside. In fact, each hajj campaign should provide this wearable medical alert systems for high riskpilgrims. We mean by that pilgrims with illness or old ones. This wearable prototype deviceoffers the opportunity for pilgrims to feel safe. It also utilizes GPS tracking that allows thecampaign responsible to pinpoint and find pilgrims when they need assistance.

So, we concluded that Hajj campaigns and pilgrims are willing to use such technology toreduce the probability of pilgrims death and taking care of pilgrims fast and easy.

2.3.3 Schedule Feasibility

Schedule feasibility is determined as the probability of a project to be carried out within itsscheduled time limits [12]. In many cases, a project will be unsuccessful if it takes more thanit was estimated. Schedule feasibility shows the work plan of the project with respect of scrummethodology (See Fig. 2.5). The following figure describes in detail our estimation in terms ofGantt Chart that is created by using Project Management Software (See Fig. 2.6).

13

Figure 2.5: E-Savior work-plan with respect to scrum methodology

Figure 2.6: Gantt chart of the E-Savior work-plan

14

2.3.4 Budget feasibility

Budget feasibility is a necessary step to determine the financial viability of this project devel-opment and to make a well informed decision on going forwards [51].

Table 2.5: Project Budget Estimation

Prototype Budget Summary

Arduino Uno 25.SRPPG sensor 20.SRthermistor sensor 5.SRGPS module 35.SRBluetooth or Wifi 35.SRBreadboard 12.SRBattery 9v 5.SRJumber wires 10.SRGrand Total 147.SR

Based on this study, we found out that the estimated budget will be around 142SR.

2.4 Requirements Gathering

2.4.1 Competitor analysis of existing products

This section discuss some of our competitors and briefly describe the outcome of the competitoranalysis .

2.4.1.1 Pilgrims Bracelet

An electronic identification bracelets for all pilgrims heading to Mecca as part of a safety drive [3].

Features:

• Contain the pilgrim identification and medical informations.

• Water-resistant.

• Connected to GPS for tracking pilgrims.

• Instruct worshippers on timings of prayers.

• Contain a multi-language desk to guide especially non-Arabic speaking pilgrims.

2.4.1.2 Apple watch

Apple Watch is the ultimate smartwatch device for a healthy life style and for runners, athletesand people with disabilities [5].

Features:

• Sense heart rate, temperature and bloodpressure.

• Water resistance

• Use GPS for running tracking to calculate the distances,

• Wirelessly listen to music right from your watch.

15

Figure 2.7: Apple watch product

• Measure movement

• Reminding any user to keep up with your regimens and routines.

2.4.1.3 Alert1

Medical alert system for those who are prone to falls and could not push the alert button in theevent of an emergency [2].

Figure 2.8: Alert1 product

Features:

• Microphone and speaker, and a wearable neck pendant.

• Service support 190 languages

• Provides a self-testing unit, which runs checks to ensure everything will work properlyduring an emergency.

2.4.1.4 Life call

Base unit and a small, waterproof pendant that is based on fall detection technology. Thispendant notifies the base unit, which connects to the monitoring center, in the event of anemergency [22].

Figure 2.9: Lifecall product

16

Features:

• Press the button on the Medical Alert pendant to get help.

• Waterproof and Offers support in 150 different languages.

2.4.1.5 Better alerts

The Better alerts consist of Pebble Smart Watch, smartphone Application , and a subscriptionto Better Alerts web service [13].

Figure 2.10: Better alerts product

Features:

• Medicine Reminders sent to Pebble Smart Watch and Caregiver App.

• Text and Email Alerts and Fall Detection.

• Safe zone with GPS Tracking and daily activity reports.

• Direct call to caregiver when a fall occurs or on pebble smart watch button press.

2.4.1.6 Lively

Lively is a medical alert system consist of Smart Watch, in Home-Hub, and activity sensors,that capture insightful data on behavior patterns [32].

Figure 2.11: Lively Smart watch product

Features:

• Keep track of steps throughout the day.

• Monitor daily medication activity.

• Offer advanced fall-detection to avoid having to push a button.

• Infer when food is prepared or consumed.

17

Tab

le2.

6:C

omp

etit

orA

nal

ysi

s

Nam

eA

lert

1L

ifeC

all

Bett

er

ale

rts

lively

Pilgri

ms

Bra

cele

tA

pp

leW

atc

hE

-Savio

r

ITD

evic

em

edic

alal

ert

sys-

tem

pen

dant

med

ical

ale

rtsy

s-te

m

Peb

ble

Sm

art

Wat

ch

Saf

ety

Wat

chW

eara

ble

Ban

dS

mar

tw

atch

Aw

eara

ble

pro

toty

pe

dev

ice

and

mob

ile

app

lica

tion

.

Vis

ion

Bet

ter

way

tocu

stom

erse

rvic

e

Pro

vid

ech

eck

inse

rvic

e

Rev

olu

tion

izes

the

way

care

give

rsan

dth

eir

love

don

esco

nn

ect

top

rovid

eth

eb

est

cust

omer

exp

erie

nce

toh

elp

our

cust

omer

sli

vesa

fely

and

ind

e-p

end

entl

y

To

avoi

dfu

-tu

red

ead

lyd

isas

ters

”T

he

ult

i-m

ate

dev

ice

for

you

rh

ealt

hy

life

”

To

keep

aney

eon

the

pil

gri

ms

safe

ty”

Scop

eP

ati

ent

wit

hch

ron

icco

nd

itio

ns

Pati

ent

wit

hch

ron

icco

nd

itio

ns

For

sen

iors

that

wan

tto

mai

nta

inth

eir

ind

e-p

end

ence

For

old

erad

ult

tole

tli

vesa

fely

and

ind

e-p

end

entl

y.

Aw

eara

ble

dev

ice

for

pil

grim

s

For

ath

lete

an

dp

eo-

ple

wit

hd

isab

ilit

ies

Pil

gri

ms

pri

ce

$249.9

919

.95−

29.9

549

.95

$fr

ee26

9−12

49A

lmost

40$

18

Tab

le2.

7:C

omp

etit

orA

nal

ysi

s(S

ervic

es)

Serv

ices

Ale

rt1

Lif

ecall

Bett

er

ale

rts

lively

Pilgri

ms

Bra

cele

tA

pp

lew

atc

hE

-Savio

r

Dis

pla

ysc

reen

yes

yes

yes

yes

yes

yes

no

Wate

r-p

roof

yes

no

no

yes

no

yes

yes

Measu

reh

eart

-rate

yes

no

no

no

no

yes

yes

Measu

reb

lood

pre

ssu

re

no

no

no

no

no

no

yes

fall

dete

c-

tion

no

no

yes

yes

no

yes

yes

Ste

pcou

nti

ng

yes

no

no

yes

no

yes

no

Receiv

ing

med

i-cati

on

rem

ind

ers

yes

yes

yes

yes

no

yes

no

Bu

ilt-

inG

PS

yes

yes

yes

yes

yes

yes

yes

Blu

eto

oth

yes

yes

yes

no

no

yes

yes

GP

RS

yes

yes

yes

yes

no

yes

yes

WIF

Iye

sn

on

on

on

oye

sye

s

Em

erg

en

cy

bu

tton

no

yes

yes

yes

no

no

no

19

2.4.1.7 Synthesis and Discussion

The study of related work, the analysis of questioner and the interview results (See Appex.Aand B) show that:

1. Most products depend on push buttons to signal an emergency.

2. There are some products that have common characteristics, some has the ability to measureheart rate but without a GPS tracking and vice versa.

3. Most products does not include built-in sensors.

4. Pilgrim bracelet only shows records of pilgrims medical care unlike E-savior that focuseson measuring pilgrims health

5. Most wearable are expensive so we will try to lower the cost.

2.5 Conclusion

This chapter concluded that the adopted methodology is Scrum. Then there is the pre-projectphase that contains the technical, operational, schedule, and budget feasibility studies. Re-quirement analysis comes finally to show the competitor analysis and the summary results ofinterviews with cardiologist, campaign responsible, and pilgrims.

20

Chapter 3

System Analysis and Design

3.1 Introduction

This Chapter describes what are the requirements needed to implement the heart rate andblood pressure measurements, also showing how the emergency cases are going to be handled.As mentioned in chapter two, that this project is following the Scrum development process thatstarts by collecting the user stories in order to establish the Sprint Backlog. In addition, theactivity diagram and the domain class diagram are presented to model the system workflow andstructure.

3.2 Domain Requirements

3.2.1 Description

The measurement of pilgrims heart rate is done by using photoplethysmograph (PPG) tech-nology [36]. The PPG produces a predictable wave shape [4] using two LED lights to detectthe pulse wave when the heart pumps and the blood travels faster than the actual blood circu-lates along all arteries. The produced analog signal needs to be processed in order to get theactual heart rate. For that, some essential values need to be measured such as: 1)PPG datathat holds the analog raw data sensed using PPG sensor, 2)IBI value that determines the timeinterval between beats, 3)BPM value that represents the actual beat of the heart per minute.The PPG reads data every 2ms after a minimum amount of time (250ms) has to pass to avoidhigh frequency noise, then analyzed it by a set of calculations to get the desired value. Theprocess starts (See Fig. 3.1) by identifying the peaks, if a peak is detected the IBI is calculatedbetween beats and stored into an array of size 10 based on the adopted algorithm, these stepsare repeated until the array is filled. When the previous condition is true, the BPM is calculatedas an average of all ten IBI values stored in the array [28].

21

Figure 3.1: Algorithm of Reading a pulse

Source: Lim Chun Keat, Asral Bahari Jambek, and Uda Hashim[2016, p.286]

22

3.2.2 Emergency Decision

The E-savior wearable device is composed of a ring wearing by pilgrim in order to monitorhis/her health. It is designed as a ring to ensure readings stability and accuracy. The sensor(PPG pulse sensor) will start getting accurate measurements after the first 250ms [31]. In orderto prevent false alerts from happening, a reset button is included.In case of emergency, the ringwill vibrate until the reset button is pressed by the pilgrim to cancel the alarm. If the alarm wasnot canceled within 60 seconds by the pilgrim, the system will send an emergency alert to thecampaign responsible. The following scenario (See Figure 3.2) is representing how the systemwill work to generate alarms. First, it starts when the pilgrim wears the ring to detect his/herhealth status. In case the pilgrim has a malaise an alarm is sent to the campaign responsiblebut in case of abnormal condition occurs, the ring will vibrate for 60 seconds, if there was noemergency the pilgrim shall press the button to cancel the emergency help, else if the buttonis not pressed and the vibration period passed, an alarm is sent to the campaign responsible toget an immediate help.

Figure 3.2: Alert Flow Chart

In order to make an accurate estimation about the pilgrims condition, some constraints mustbe set (See. Table 3.1). Based on the National Institute of Health, the ideal range of restingheart rate for adults and seniors ranges between 60-100 BPM. In the other hand, the averageresting heart rate for well-trained athletes is 40 - 60 BPM [9]. However, the normal heart-rateof pilgrims differ from person to person while doing a moderate intense activity that starts fromwalking 4 mile per hour [18] the heart rate is increasing accordingly. Pilgrims speed will bemeasured by using an GPS Module that is also used to get the location [17], these increases inBPM can be limited by the use of estimated target heart rates for 50%-85% zone which usedas a general guideline estimation [9], to keep the heart rate below a certain level to adequatelysafeguard their health. The BPM is calculated using the formula (220 - your age*zone/100).The heart rate zone in moderately intense activates is usually between 50% - 69% and duringthe heart physical activates it is between 70% - 90%, for that the adopted general guideline fromthe heart rate association is the average zone which is between 50% - 85%.

Even though, the BPM may be affected by some factors such as 1) their body size that mayincreases with weight but not exceeding 100BPM, 2) air temperature may affect the heart ratebut usually no more than 5-10 beats a minute, 3) while movement and changing of body positionthe heart rate may be affected by go up a little bit for couple of minutes, 4) Medication use

23

Table 3.1: General Estimation Guideline

AgeBlood

Pressure

HeartrateModerateIntensity4 mph

(50%-85%)

HeartrateLight

Intensity

BodyTemperature

GeneralGuidline

20 120/80 100-170

For Non athlete60-100

For Non athlete40-60

36.1 C-37.2C

30 122/81 95-16235 123/82 93-15740 125/83 90-15345 127/84 88-14950 129/85 85-14555 131/86 83-14060 134/87 80-16365 134/87 78-13270 134/87 75-128

may slow the pulse or raise it [20]. In addition, the decision will be made also depending on thepilgrim temperature, the normal body temperature is between 36.1 -37.2 C and any Increase ordecrease considered as an emergency. Moreover, The wearable device is also taking the bloodpressure measures into consideration, the normal blood pressure for people aged 20-24 is 120/80and it increases with age. These two numbers systolic and diastolic values are measured byPPG techology [42]. The systolic value is the reflection of the blood pressure in vessels whenthe heart beats, in the other hand, the diastolic value is the reflection of the blood pressure invessels when the heart rest.

These measurement guidelines are according to Health institutes and they were validated bythree expert doctors who had agree on the guidelines ability to detect emergency and minimizethe danger.

3.3 Product backlog

The Scrum development process advocates the use of product backlog rather than the use casediagram and system sequence diagram, the reason is: since in agile project, the code changesfrequently that UML diagrams become obsolete after few days and have to redraw. So that,the following section will describe the functional requirements in terms of Product Backlog. Inaddition, an overview of the system workflow and architecture are also presented.The product owner has the responsibility to specify the product backlog as a set of users stories[19]. The product backlog is a list of all features that needs to be done in the product [40].

3.3.1 User Stories

User stories are collected from the campaign responsible and pilgrims in order to create theproduct backlog. For that, all user stories were documented (See Table.3.2) to identify thefunctionalities desired for the deliverable product.

24

Tab

le3.

2:U

sers

stor

ies,

Fea

ture

s,an

dB

enefi

ts

Sto

rynu

mb

er

Fro

mw

hic

hvie

wU

ser

Sto

ryd

e-

scri

pti

on

Exp

ecta

tion

Featu

res

Ben

efi

ts

Sto

ryA

As

aca

mp

aig

nre

-sp

on

sib

leI

wan

tto

pin

-p

oint

the

loca

tion

ofan

yp

ilgr

im

To

reac

hth

eman

yti

me

and

anyw

her

e

Incl

ud

eB

uil

t-In

GP

ST

ore

ach

the

pil

-gr

ims

fast

er

Sto

ryB

As

aca

mp

aig

nre

-sp

on

sib

leI

wan

tto

rece

ive

accu

rate

aler

tsab

out

the

emer

-ge

ncy

situ

atio

ns

To

hel

pth

ep

ilgr

ims

imm

edi-

atel

y

Rec

eive

emer

-ge

ncy

ale

rtT

oC

ontr

olth

ep

ossi

ble

dea

dly

emer

gen

cy

Sto

ryC

As

aca

mp

aig

nre

-sp

on

sib

leI

wan

tto

hav

ea

vis

ual

dis

pla

yof

anag

greg

atio

nof

sen

sed

info

rma-

tion

To

take

the

righ

td

ecis

ion

Vie

win

gall

info

r-m

atio

nth

rou

gh

mob

ile

app

lica

-ti

on

To

faci

lita

teth

ep

roce

ssof

keep

ing

pil

gri

ms

safe

Sto

ryD

As

apil

grim

Iw

ant

toh

ave

aco

nven

ient

wea

rab

led

evic

eth

atm

onit

ors

my

hea

lth

To

carr

yit

and

use

itea

sily

top

erfo

rmH

ajj

safe

ly

Mea

sure

blo

od

pre

ssu

re,

tem

per

-at

ure

,h

eart

rate

and

spee

d

To

mon

itor

the

pil

gri

mov

erall

hea

lth

inor

der

toh

elp

him

/h

erif

he/

she

gets

ind

an

ger

25

3.3.2 System WorkFlow

The system workflow is useful for clarifying the series of activities necessary to complete thesystem work process. The activity diagram of UML is used to model the workflow which is aset of activates. The below activity diagram illustrates the activities required for a potentialpilgrim to use the project and the campaign role through mobile application (See Fig.3.3).

1. The workflow starts when a pilgrim wears the E-Savior device;

2. The system retrieves the pilgrim medical information from the database;

3. The system measures the heart rate with the heart rate sensor;

4. The system measures the blood pressure with the blood pressure sensor;

5. The system checks if there an emergency is happening, and takes an action based onprevious conditions.

(a) When an emergency is detected, the system will:

i. Determine the pilgrim location;

ii. Activate the alarm;

iii. Display the alerts for each detected locations in the mobile application;

iv. The responsible receives a notification with the location of the pilgrim, heads tothe pilgrim place and do the necessary.

(b) If there is no emergency detected, the system keeps measuring the heart rate and theblood pressure.

Figure 3.3: Workflow of E-Savior prototype

26

3.3.3 System Architecture

The system architecture (See Fig.3.4) is composed of hardware and software components thatneed to be linked and integrated together in order to fulfill the main objectives of the project.The hardware component has a number of modules and sensors connected to a microcontroller toread the data and send it to the web host to be stored. In the meanwhile, E-savior applicationreads the data from the web host database and presents it to the campaign responsible in agood manner that shows the health status and location of pilgrims without specifying a priorityfor each case, since every alert sent is going to be for an emergency case and they are equallyimportant.

Figure 3.4: E-Savior System Architecture

3.3.3.1 Domain class diagram

A UML package diagram organizes elements and diagrams into groups. In addition, it depictsthe generalizations and dependencies between the packages that make up a model. A domainclass diagram is a modeling notation that defines the attributes, methods and relationshipsamong the objects in the system.

The domain class diagram (See Figure. 3.5) is divided into three packages ”Geo location”,”Pilgrim module”, and ”campaign module”. The ”Geo location” package contains the ”location”class that retrieves the location of the pilgrim. The ”Pilgrim Module” contains two sub packages”Pilgrim Information” and ”Health Monitoring”. The ”Health Monitoring” package dependentson the ”Pilgrim Information” package. ”Pilgrim Information” package contains three classesthat are ”pilgrims” personal information, ”disease” and the ”treatments”. The ”health moni-toring” package contains four classes that are the health status of the pilgrims by retrieving theblood pressure and the heart rate measurements from ”Heart Rate” class and ”Blood Pressure”class, and it shows that each pilgrim may have one or many ”health status”. It is also asso-ciated to the ”alert” class that generates an alert and sends a ”notification” to the campaignresponsible. ”Campaign module” package contains two classes ”Campaign Responsible” and the”Notification” class. The ”Campaign Responsible” class contains the name of the responsibleand the number of pilgrims that he is responsible of, and the Notification class that shows thatalert if any ab normal situation happened to a pilgrim.

27

Fig

ure

3.5:

Dom

ain

Cla

ssD

iagr

am

28

3.3.3.2 Hardware Design

The Arduino Uno is a microcontroller board that consists of both a microcontroller(ATmega328)and an IDE [45]. This section will present as a whole the units linked to the physical pro-grammable circuit board that referred to as a microcontroller (See fig.3.6).

Figure 3.6: Breadboard hardware components wiring

The micro-controller breadboard is linked to several components that serve this project.Each circuit is wired based on some electricity basics to allow the units to power up correctlyand send the data gathered to the microcontroller and then send it to the web host to be storedthough the Internet network using WiFi shield (See Fig.3.7) that plugged into the Arduinodirectly.

Figure 3.7: WiFi shield

Figure 3.7 shows the Arduino WiFi shield that connects the wearable with a wireless networkto enable the transmission of data between the modules and sensors with the mobile application.The data transmitted is gathered using:

29

1. GPS module

The GPS module is tiny receiver device (See Figure.3.8) that calculates the exact positionand time by getting the data location from the satellites. There are 24 active satellitesin space and it constructed to always contain at most 12 satellites in any location. Inaddition, the GPS comes attached to an antenna that will allow any receiving of data thatsent by those satellites. The accuracy of the GPS parameters can be determined by thenumber of the satellites captured by the antennas, the number of satellites should be morethan four for an accurate result [44].

Figure 3.8: Ublox-NEO6 GPS module

2. PPG sensorThe PPG based technology sensor is used to sense the heart rate and blood pressureas mentioned in Section 2.3.1.1.2. The measures will be handled and collected by themax30100 sensor (See Fig.3.9) that is used in some application [29] such as:

(a) Assistant Devices,

(b) Medical Monitoring Devices and,

(c) Wearable Devices

Figure 3.9: Max30100 Heart rate sensor

30

3. Thermistor sensorThe thermistor sensor (See Fig.3.10) is used to measure the temperature of the pilgrimthrough an analog pin. It sense the temperature by capturing precise change in electricalresistance when change occurs in pilgrim temperature.

Figure 3.10: thermistor sensor

3.4 Connection between hardware and software components

This section explains how the output data from the connected sensors and modules is displayedand reads from Arduino microcontroller using the E-Savior application. First of all, databaseshould be created in MySQL server according the class diagram shown in section 3.3.3.1 to allowstoring data from the Arduino; so it can be visualized using the android studio IDE. As shownin the following figure (See Fig.3.11), the data gathered is handled by the microcontroller thenthe microcontroller makes a HTTP request to store data in the MySQL database. In order tosend the request, the Arduino must be connected to the Internet network, which is done byusing Wifi shield that is plugged in the Arduino. After that, the developed Android applicationdeveloped can read and process the data after connecting it to MySQL database, However, theconnection between Android application and MySQL database can not happen directly. So that,a PHP code should be converted to JSON format or Xml to be handled through HTTP requestusing AsyncTask class.

31

Figure 3.11: Connection between hardware and software

3.5 Sprint Definition

This section presents the definition of sprints. Each sprint must be completed to deliver thefinal product (See Fig. 3.12). In order to plan the sprints, first of all, after all stories havebeen gathered as shown in Section 3.3.1, the product backlog is created which contains a listof all features that needs to be done in the product [40]. The product backlog may changethroughout the project time in case of new requirements were added or existing requirement hasbeen modified [40]. The entries in the product backlog are prioritized and ordered accordinglywith placing priority rank and story points.

1. Story points : The story point is a measure of the effort required to implement an individualstory. It indicates the team of how complex and hard the story is [1].

2. Priority rank: In order to start prioritizing, there are four factors to keep in consideration[43] :

(a) Degree of uncertainty and the amount of new knowledge gained by developing theproduct increment;

(b) The amount of risk removed by developing the product increment;

(c) The value of having the product increment;

(d) The cost of developing the product increment.

Secondly, a sprint backlog is created for each sprint to specify the list of tasks that must becompleted during a Scrum sprint. those tasks are identified by the Scrum team along with theestimation of hours for each task and its priority.

32

Figure 3.12: Sprints overall output

3.6 Conclusion

This chapter documented the user stories that have been gathered in order to start the sprintplanning. In addition, it presented both the hardware design and the software analysis for eachsprint and how to link between them for an effective development model.

33

Chapter 4

Implementation and Testing

4.1 Introduction

This chapter gives an overview of the programming environment and presents the sprints requiredto implement this project. Sprints are clearly defined by giving the description of each sprintwith it’s tasks and time estimation, also showing the hardware and software design for each one,followed by the implementation section that shows the hardware and software development. Thefinal section of each sprint is testing which is going to test the output of each spring followed bythe integration testing.

4.2 Programming Environment

This Section will describe the hardware and software components needed in order to fulfill theobjective of this project.

4.2.1 Hardware Components

The project prototype will be build using a number of hardware components, in one hand, Ar-duino microcontroller will be used, basically it is an open-source cross-platform microcontrollerthat is able to read inputs from various kind of sensors and shields then turns those readingsinto an output by using the Arduino Integrated Development Environment (IDE) [10]. TheIDE assists the communication with the micro-controller and helps the boot loader to uploadC/C++code file into the Arduino memory. So, it will get executed immediately. There areseveral Arduino board models available in market and this project is using Arduino UNO boardfor many reasons which are 1)it is compatible with shields, 2) it is the best board to get startedwith electronics and coding, 3) it is suitable for prototyping purpose and 4) it is the most robustboard. In addition, UNO is the most used and documented board of the whole Arduino andGenuino family [46]. In the other hand, a number of modules and sensors will be used suchas: GPS module, PPG sensor, WIFI shield, thermistor and accelerometer. However, in order todevelop the hardware components of E-Savior, some software, languages and libraries must beused which are:

1. Programming languages and general software.

(a) The Arduino programming language that is based on C/C++ for programming thehardware component.

(b) Arduino Software (IDE) to make it easy to write code and upload it to the Arduinoboard memory.

(c) Fritzing is an open source hardware initiative for documenting the prototype.

34

2. Libraries. A software library is a collection of data and precompiled programming codethat a programmer can use to develop software programs and applications [11].

(a) TinyGps++ library: This library is by mikalhart that does a lot of the ’heavy lifting’required for receiving data from GPS module.

(b) HR spark-fun library: Heart rate library will help to calculate Pulse, Signal, HRV,BPM, QS ,and Scale.

(c) SoftwareSerial Library: it allows the Atmega processing unit chip to receive serialcommunication.

4.2.2 Software Components

In this area, we enumerate the programming languages and tools that are used to developE-savior mobile application. The later will be by the hajj campaign responsible.

1. Programming languages

(a) The Android IDE programming language that is based on JAVA and Xml for pro-gramming the application.

(b) PHP, SQL are required for connecting with the database.

2. General softwares

(a) Android studio (IDE) to build an Android application.

(b) Mamp is a local server environment for accessing a local PHP server.

(c) Genymotion is a Android emulator for app developers and testers.

4.3 Testing techniques

Testing is the process of checking bugs or errors when executing a program. In addition, itvalidates and verifies whether the project meets its functional and non-functional requirements[25].

4.3.1 Code Testing

The code unit testing will involve the test of Arduino and Android code. From the Arduinoside, there is no predefined methods that support the unit testing, it is usually done in differentways depend on the programmer. From the other side, the Android code will be tested usingJUnit testing which is either conducted on JVM or instrumented tests on an Android device.The test conducted for E-savior is the instrumented test. Instrumented tests are built into anAPK that runs on the device alongside the app under test. The system runs the test APK andthe app under tests in the same process, so the tests can invoke methods and modify fields inthe app, and automate user interaction with the application.

These tests are the fundamental tests in the android application testing strategy. The unittest generally exercises the functionality of the smallest possible unit of code which is methodsor classes in a repeatable way. And it is conducted to verify the logic of specific code in theapplication. So after running unit tests against the code, we can easily verify that the logic ofindividual units is correct. Moreover, running unit tests after every build helps us to quicklycatch and fix software regressions introduce by code changes to the application[14]. After theunit tests passes, an integration test must be conducted between the two components to ensurethe validity and correctness of the integration, and it is done though simulation between them.

35

4.3.2 Non-Functional Requirements Testing

The non-functional requirements is different from the functional requirements, it is mainly de-fined as the system attribute that specify how the system should work [21]. This project de-scribed four Non functional requirements that must be tested to ensure it validity, which are:

1. System reliability that defined as ”the capability of a software to maintain its performanceovertime”[47]

2. System usability that will be attained through user friendly interface design and easynavigation through Android activities.

3. Measures Accuracy that ensure the validity of the system outputs.

4. System security will be reached by encrypting the user password using the hash function.

4.4 Sprint 1

4.4.1 Description

The first scrum sprint is composed of story C and story A that is considered with accessingthe pilgrims longitude and latitude to locate the exact location of any pilgrim in the same hajjcampaign and present it to the campaign responsible through a mobile application using GoogleAndroid API. In the other hand, story C aims to present those data through visual display usedby the campaign responsible. The stories are simplified into smaller pieces or chunks called tasks(See Table.4.1) to be implemented.

Table 4.1: Sprint 1 Backlog

Sprint 1 Backlog

Story BusinessPrior-ity

StoryPrior-ity

Tasks Priority Week Ef-fort

Story A 1 4Design electronic circuitto get the GPS location

1 2 days

Connect the GPS mod-ule to the Arduino

2 3 days

Develop a code that re-trieve the coordinatesfrom GPS module

3 2 weeks

Story C 4 2 Develop a mobile inter-face that displays thecoordinates of each pil-grim

4 1 week

4.4.1.1 Hardware design

The GPS module consists of an external antenna and four pins that are used to connect theGPS with Arduino (See Table.4.2). Those connections are made through wires between the pins(See Fig.4.1). GPS module pins are described as follow:

1. VCC: is basically used to power the module with 5 voltage.

36

2. RX: this pin is not wired.

3. TX: is used to transmit the NMEA sentences TO Arduino.

4. GND: is used to provide the module with a low voltage that equal to zero

Table 4.2: GPS and Arduino Pins Wiring

GPS datasheet

GPS module Arduino UNO

VCC PIN5

RX NA

TX PIN10

GND GND

Figure 4.1: E-savior GPS hardware design

37

4.4.1.2 Mobile design

1. The package ”Geo Location” (See Fig.4.2) contains the ”Location” class that has variableslatitude, longitude, time and accuracy which is going to be sensed from the GPS sensor,as well as, it contains ”getLocation()” operation in order to compute the coordinates ofeach pilgrim.

Figure 4.2: E-savior GPS class diagram

2. The mobile prototype illustrates how location information are going to be displayed to thecampaign responsible through the mobile application (See Fig.4.3).

Figure 4.3: Pilgrims locations on the map GUI

38

4.4.2 Implementation

4.4.2.1 Hardware Development

The GPS module developed according to the design sketch done earlier (See Fig.4.1). It connectsthe GPS with Arduino Uno board in order to run properly by allowing the external antennaof GPS to receive NMEA sentences (GPS raw data) (See Fig.4.4a) and then the Arduino Unofetches that data and process it to extract the latitude and longitude of the pilgrim location(See Fig.4.4b) and stores it in the database to allow E-savior application accessing the data.

(a) NMEA.

(b) NMEA After Processing.

Figure 4.4: GPS output data

4.4.2.2 Software Development

The implemented GUI of this sprint is consist of Google map API v2 and a search bar thatwill lead the campaign responsible to easily pinpoint the exact location of pilgrims to reachthem faster. This process is done by linking the software with the hardware component inorder to make them exchanging the coordinates of pilgrims which presented as red markerson the map(See Fig.4.6). The application reads and accesses the data stored by the wearableattached to the pilgrim by sending an HTTP request (See Fig. 4.5) that will return a response.The response is converted to string and parsed from JSON format to extract the latitude andlongitude then pass it along to the function responsible of adding a marker.

Figure 4.5: Sprint 1 Structure

39

Figure 4.6: Sprint 1 GUI

4.4.3 Testing

This area will present the result of all tests conducted including: unit testing of both hard-ware and software components, integration testing between them, and finally non-functionalrequirements testing that are related to sprint 1.

4.4.3.1 Unit Testing

The unit testing is conducted for two components, first of all, the first test is related to theAndroid application, so first we test the connection to the server to test the doInBackground()method by asserting the result with the String URL that inserted.

40

Figure 4.7: Connectivity Positive Testing

Figure 4.8: Connectivity Negative Testing

41

Next test was conducted on the addmarker() method to check adding of the markers on themaps by inserting double GPS location values on Obhur, and then we try on some string inputsand it doest not shows the marker.

Figure 4.9: Add Marker Positive Testing

Figure 4.10: Add Marker Positive Testing

42

Table 4.3: Sprint1 Unit Testing Cases

TestcaseID

Test casedescription

Inputdata

Expectedresult

Actualresult

Pass/fail

Remark

1

This test caseto verify theconnectivitymethod by assertingthe result withcorrect URL input

String strUrl =”https://esavior.000webhostapp.com/retrieve.php”;

GetConnected

GetConnected

PassPositivetest

2

This test caseto verify theconnectivitymethod by assertingthe result withincorrect URL input

StringstrUrl=”https://esavior.000webhostapp.com/retrieve4.php”;

NotConnected

NotConnected

FailNegativetest

3

This test caseto verify the methodaddmarker byinserting correctdouble inputs ofGPS location

double lat=21.759992;double lng=39.110633;

Addingmarkeron Obhur


PassPositivetest

4

This test caseto verify the methodaddmarker byinserting incorrectString inputs ofGPS location

String lat=”21.759992”;String lng=”39.110633”;


Nomarker isadedd

FailNegativetets

The second unit test is related to the GPS module to check if the output data is corrector not, this test was held from three different geographical areas. The output latitude andlongitude were taken from the Arduino serial monitor (See Fig. 4.11) and inserted into googlemap to check if the antenna read the data correctly from the satellite and whether the Arduinoprocessed it efficiently. For that, a comparison is done using Google Maps by comparing the reallocation and the location retrieved from the GPS module. The result of this test shows that theGPS module is working properly (See Fig. 4.12).

Figure 4.11: GPS Serial Monitor

43

(a) Real location onGoogleMaps

(b) inserting GPSData on GoogleMaps

Figure 4.12: Sprint 1 Arduino Unit Testing

4.4.3.2 Integration Testing

The integration testing is done between the hardware which is the GPS module that is connectedto Arduino microcontroller and the E-Savior android software. As mentioned in section4.3.1,the integration testing is done after both Unit testing passes. This test is conducted by fardistance simulation (See Fig.4.13) where the first party has connected the GPS from Obhurneighborhood (showing in the map as a blue marker named Nala), the second party was havingthe application running to track the first party (showing in the map as a blue current locationmarker). The result shows that components are integrated together and well performed.

Figure 4.13: Sprint1 Integration Testing

44

4.4.3.3 Non-Functional Requirement Testing

This sprint has two non-functional requirement, the first one is reliability and it tested throughcomparing the output of E-Savior GPS location against Smartphone GPS location (See Fig.4.14). This test was conducted from two different geographical locations to insure it is reliability.Figure 4.14a shows the first location in Alrehab neighborhood and Figure 4.14b shows the firstlocation in Alsameir neighborhood. These two Figures shows the system output is consistenceover time and place.

(a) From Alrehabneighborhood

(b) From Alsameirneighborhood

Figure 4.14: Sprint1 Reliability Testing

The second non-functional requirement is usability, its test is conducted to make sure thatthe application is user usable. By developing simple and user friendly interface, For E-Saviorapplication is designed to show the coordinates of any pilgrim’s location as a simple marker thatis displayed on the map (See Fig. 4.15), showing also the search bar that can direct to any otherpilgrim’s marker and easily navigate them.

Figure 4.15: GPS GUI

45

4.5 Sprint 2

4.5.1 Description

The second scrum sprint is composed of story D and story B (See Table.4.4). Story D is aboutmeasuring the heart rate and blood pressure, temperature and calculating the speed usingArduino sensors, then sending the measured values to the E-savior mobile application. StoryB is about developing a mobile service that will check if the heart rate and the blood pressureare abnormal and notify the campaign responsible by showing the notification on the E-saviourmobile application.


Sprint 2 Backlog


StoryPrior-ity


Story D 1 4Design electronic circuitto measure heart rate,blood pressure and tem-perature

1 2 days

Connect the HeartRate, blood pressureand temperature sensorto the Arduino

2 5 days

Develop a code to getthe heart rate, bloodpressure and tempera-ture values

3 2 weeks

Story B 1 4 Develop a service thatnotifies the campaignresponsibles in case ofemergency

4 1 week


1. The MAX30100 sensor consist of two LEDs, a photodetector, optimized optics, and low-noise analog signal processing to detect heart rate signals. Also it has four pins that usedto connect the module to the Arduino (See Table.4.5 and Fig.4.16) described as follow:

(a) VDD: is basically used to power the module with 3.3 voltage;

(b) SCL: is a serial clock line used to transmit clock pulses;

(c) SDL: is a serial data line used to transfer data;

(d) GND: is used to provide the module with a low voltage that equal to zero.

2. The thermistor consists of two wires that is used to connect the sensor to Arduino (SeeTable.4.6 and Fig.4.17). The measure of temperature is done through an analog pin withthe help of 10k resistor.

46

Table 4.5: PPG sensor and Arduino Pins Wiring

PPG sensor datasheet

PPG module Arduino UNO

SCL A5

SDL A4

GND GND

VDD 5V

Figure 4.16: E-Savior PPG sensor hardware design

Table 4.6: Thermistor sensor and Arduino Pins Wiring

Thermistor sensor datasheet

Thermistor sensor Arduino UNO

R A0

VDD 5V

47

Figure 4.17: E-Savior temperature hardware design


1. The heart rate, temperature and blood pressure class diagram (See Fig.4.18) which areincluded inside ”Health Monitoring” that contains the ”health status” class that is a gen-eralization of the heart rate, temperature and blood pressure measurements that describea specific status. Those measurements are going to be calculated using specializationclasses ”Heart Rate”,”Temperature” and ”Blood pressure” classes. In case of emergency,an ”alert” and a notification will be generated the alert notification.

Figure 4.18: E-Savior health monitoring class diagram

2. The mobile prototype illustrates how heart rate,temperature and blood pressure valuesare going to be displayed to the campaign responsible through the mobile application, anddisplays alert notification in case of emergency detection (See Fig.4.19).

Figure 4.19 shows the profile page prototype that is used to know the pilgrim healthcondition and status.

48

Figure 4.19: Pilgrim profile GUI


The output of this sprint is heart rate and blood pressure measurements that will be sent to themobile application to let the campaign responsible monitor the pilgrims health and to receive analert if an emergency occurred to the pilgrim. The measurements will be read from the databaseon real time.

4.6 Sprint 3

4.6.1 Description

The third sprint is composed of Story C (See Table.?? and Table.4.7). It is about wrappingall the data of emergency cases, pilgrims location and heart rate and blood pressure measures.And to integrate all the system functions and test it as an overall.


Sprint 2 Backlog


StoryPrior-ity


Story C 3 8 Aggregate data of emer-gency cases

1 1 week

Integrateand Testtheoverallsystem

2 2 weeks

49


This sprint does not include any physical and hardware component.


The classes used for storing and generating the alert data is presented in Fig.4.20. Those classespresent the output of alerts in a GUI (See Fig.4.21) to make the campaign responsible managethe pilgrims immediately when harm occurs. The prototype of the sprint aims to show the alertsthat are generated based on some rules and functions.

Figure 4.20: Application alerts class diagram

50

(a) Alerts. (b) Alert details.

Figure 4.21: Alerts generated GUI


The output of this sprint is to generate statistics about emergency cases and their locations tohave an integrated system with all functions connected together, and to test the functionalitiesof the overall integrated system.

4.7 Conclusion

The conclusion of this chapter shows that, this project has been implemented with differenttechnologies by following the Scrum sprints, sprint by sprint. Connecting the wearable hardwarewith software to generate an emergency alert, followed by the various types of testing.

51

References

[1] agilefaq.wordpress.com. What is a story point. https://agilefaq.wordpress.com/2007/11/13/what-is-a-story-point/, Last visited in november 2016.

[2] alert 1.com. Alert1. https://www.alert-1.com/, Last visited in October 2016.

[3] .aljazeera.com. Saudiarabia introduces bracelets hajj safety.http://www.aljazeera.com/news/2016/06/saudi-arabia-introduces-bracelets-hajj-safety-160630131905794.html, Last visited in October 2016.

[4] amgalbu. Heart beat detection. https://www.element14.com/community/community/design-challenges/enchanted-objects/blog/2015/04/09/magichat–6–heart-beat-detection, Lastvisited in February 2016.

[5] apple.com. Apple watch series. http://www.apple.com/sa/apple-watch-series-1/, Last vis-ited in October 2016.

[6] arduino.cc. arduinoboarduno. https://www.arduino.cc/en/Main/arduinoBoardUno, Lastvisited in October 2016.

[7] Arduino.com. Arduino software. https://www.arduino.cc/en/main/software, Last visitedin october 2016.

[8] American Heart Association. Heart attacks, strokes, heart failure reasons and consequences.http://www.heart.org/HEARTORG/, Last visited in November 2016.

[9] American Heart Association. Target heart rates. http://www.heart.org, Last visited inOctober 2016.

[10] Steven F. Barrett. Arduino Microcontroller Processing for Everyone. Morgan and ClaypoolPublishers, 2013.

[11] By Vangie Beal. library. http://www.webopedia.com/term/l/library.html, Last visited inoctober 2016.

[12] By Vangie Beal. What is schedule feasibility. http://www.taskmanagementguide.com/glossary/what-is-schedule-feasibility.php, Last visited in october 2016.

[13] betteralerts.com. Better alerts. https://betteralerts.com/, Last visited in October 2016.

[14] Andriod Developers. Getting started with testing.https://developer.android.com/training/testing/start/index.html, Last visited in oc-tober 2016.

[15] gezondheid.infonu.nl. Elektrocardiografie: Meting elektrische activiteit van hart.http://mens-en-gezondheid.infonu.nl/aandoeningen/175050-elektrocardiografie-meting-elektrische-activiteit-van-hart.html, Last visited in october 2016.

52

[16] KSA Government. Hajj statistics. http://www.stats.gov.sa/sites/default/files/ hajj 1437 ar.pdf,Last visited in November 2016.

[17] Mikal hart. Arduino wisdom and gems. http://arduiniana.org, Last visited in February2016.

[18] harvard school of health. Measuring physical activity. https://www.hsph.harvard.edu, Lastvisited in October 2016.

[19] Shane Hastie and Angela Wick. User stories and use cases - don?t useboth! https://www.batimes.com/articles/user-stories-and-use-cases-dont-use-both.html,Last visited in March 2016.

[20] American heart association. All about heart rate, Last visited in February 2016.

[21] http://reqtest.com/. Functional requirements vs non functional requirements.http://reqtest.com/requirements-blog/functional-vs-non-functional-requirements/, Lastvisited in March 2016.

[22] ifecall.com. Lifecall. http://lifecall.com/, Last visited in October 2016.

[23] imotions.com. Ecg and ppg sensor’s technology. https://imotions.com/blog/what-is-ecg/,Last visited in October 2016.

[24] instructables. Led pulse sensor (ppg) for arduino. http://www.instructables.com/id/led-pulse-sensor-ppg-for-arduino/, Last visited in october 2016.

[25] ISTQB. Fundamentals of testing. http://istqbexamcertification.com, Last visited in october2016.

[26] Qiang Li, John A. Stankovic, Mark A. Hanson, Adam T. Barth, John Lach, and GangZhou. Accurate, fast fall detection using gyroscopes and accelerometer-derived postureinformation. In Proceedings of the 2009 Sixth International Workshop on Wearable andImplantable Body Sensor Networks, BSN ’09, pages 138–143, Washington, DC, USA, 2009.IEEE Computer Society.

[27] lifewire.com. Arduino vs netduino: Which platform is on top?https://www.lifewire.com/arduinovsnetduino2495292, Last visited in october 2016.

[28] Asral Bahari Jambek Lim Chun Keat and Uda Hashim. Heart-rate monitoring systemdesign and analysis using a nios ii soft-core processor. 62:283–288, 2016.

[29] maximintegrated.com. Pulse oximeter and heart-rate sensor ic for wearablehealth. https://www.maximintegrated.com/en/products/analog/sensors-and-sensor-interface/MAX30100.html, Last visited in December 2016.

[30] mikewcohn. Sprint backlog and the scrum sprint.https://www.mountaingoatsoftware.com/agile/scrum/product-owner, Last visited inoctober 2016.

[31] Joel Murphy and Yury Gitman. pulse sensor algorithim. https://pulsesensor.com, Lastvisited in october 2012.

[32] mylively.com. My lively smatrwatch. http://www.mylively.com/, Last visited in October2016.

[33] netduino.com. arduinoboarduno. http://www.netduino.com/hardware/, Last visited inOctober 2016.

53

[34] World Health Oganization. Top 10 causes of death.http://www.who.int/mediacentre/factsheets/fs310/en/index1.html, Last visited inNovember 2016.

[35] IT Knowledge Portal. Software development methodologies.http://www.itinfo.am/eng/softwaredevelopmentmethodologies/, Last visited in November2016.

[36] Dan Radigan. Measurment of heart rate using ppg.http://cse.buet.ac.bd/heqep/public/uploads/measurement-of-heart-rate-using-photoplethysmography.pdf, Last visited in January 2016.

[37] Dan Radigan. Scrum:a brief look into using the scrum framework for software developement.https://www.atlassian.com/agile/scrum, Last visited in october 2016.

[38] Kenneth S. Rubin. Essential Scrum: A Practical Guide To The Most Popular Agile Process.Addison-Wesley Professional, 2012.

[39] samsung.com. How to measure heart rate samsung gear.http://www.samsung.com/us/heartratesensor/, Last visited in October 2016.

[40] scrum institute.org. The scrum product backlog. http://www.scrum-institute.org/TheScrum Product Backlog.php, Last visited in October 2016.

[41] scrumalliance.org. learn about scrum. https://www.scrumalliance.org/why-scrum, Lastvisited in october 2016.

[42] HS Oh JS Lee IY Kim SH Song, JS Cho. Estimation of blood pressure using photoplethys-mography on the wrist. http://www.cinc.org/archives/2009/pdf/0741.pdf, Last visited inMarch 2016.

[43] slideshare.net. Creating a product backlog. http://www.slideshare.net/rpannone/creating-a-product-backlog, Last visited in october 2016.

[44] sparkfun.com. Gps basics. https://learn.sparkfun.com/tutorials/gps-basics, Last visited inDecember 2016.

[45] sparkfun.com. What is an arduino? https://learn.sparkfun.com/tutorials/what-is-an-arduino, Last visited in December 2016.

[46] sparkfun.com. arduinoboarduno. https://www.sparkfun.com/news/1982, Last visited inOctober 2016.

[47] Anderw Stellman. Understanding nonfunctional requirements.http://broadcast.oreilly.com/2010/02/nonfunctional-requirements-how.html, Last vis-ited in March 2016.

[48] thebalance.com. How to write an awesome technical feasibility study.https://www.thebalance.com/writing-technical-feasibility-study-3515778, Last visitedin october 2016.

[49] valencell.com. Ppg sensor’s technology. http://valencell.com/blog/2015/10/optical-heart-rate-monitoring-what-you-need-to-know, Last visited in October 2016.

[50] Chris Walker. Getting Started with Netduino. Make Books - Imprint of: O’Reilly Media,Sebastopol, CA, 2012.

54

[51] woodleycoles.co.uk. Feasibility studies and budgets.http://www.woodleycoles.co.uk/services/feasibility-studies-and-budgets/, Last visitedin october 2016.

55

Appendix A

Survey

A.1 Survey Results

56

Appendix B

Interviews

B.1 Interview questions with campaign administrator

1. Do you use any method to watch your pilgrims health? If yes please mention it.

2. If any of your pilgrims is in a bad situation how will you know?

3. Do you think that campaigns should focusing and give more attention for pilgrims health?

4. Do you think that the existence of such bracelet will reduce the death rate?

5. Do you think it would be acceptable and carried on by both campaigns and pilgrims?

6. Would you like to add some recommendation and improvement thoughts for this project ?

64

B.2 Interview questions with Cardiologist

First interview was with consultant cardiologist doctor, and we obtain those answers from him.

1. Do you think that heart diseases are one of the major reasons of pilgrims death? Certainlyheart disease is one of the most common causes of death among the pilgrims, especiallybecause of angina and the weakness of the heart muscles.

2. Why it is useful to measure heart rate? It is known that the heart rate is one of the basicvital signs that’s everyone has which is a temperature, heart rate and the rate of arterialblood pressure and this marks a key for each examination because they give us an exactdescription of the state of the patient’s general and to the height or fall of a direct impacton the general condition of the patient.

3. Can we predict bad heart situation from the heart rate? Some heart disease is directlylinked to the rate of electrical impulses disturbance of the heart, for example, but I warnabout the heart rate is a key indicator of the state of the public body may be the basiccause another organ or for some other reason is reflected in the heartbeat so the heart ratetaken at the beginning of examining the patient.

4. Is it enough to predict emergency based on heart rate measurement? Heartbeat give aninitial overview of the heart status, but needs further tests to confirm the diagnosis maybe linked to disruption of an organ or other organ in the body.

5. What is the range of normal heart rate for people with chronic diseases? The normal rangefor the majority of people is from 60-90 per minute strike but may be low in the elderly tolack of movement and physical activity in the case that the heart is normal. But it mayrise or fall with some chronic diseases.

6. Can the heart rate be measured accurately from the wrist ? Certainly the wrist is the firstplace to measure heartbeat. In the case of the difficulty of feeling the pulse of the wristwe we measure from the neck or groin.

7. What do you think of this project ? A beautiful project and the existence of such devicecould easily monitor the status of some of the pilgrims from the old people with chronicdiseases and awareness of their locations through their campaigns. Where the campaignscan filter their pilgrims and find out which of them require follow-up and find out the typeof activity that they performing and the impact on the patient’s status. Sometimes a highheart rate or falling unacceptable. But it must not exceed the acceptable limits.

8. Do you have any recommendation for E-savior project ? I suggested to be linked tocampaigns pilgrims directly and not your health service provider, especially in periods ofovercrowding, such as the Hajj. I also hope to develop the project to include the measure-ment of pressure also when the device gives readings for heart rates. But I emphasize thatthe current functionality provided to measure the pulse of the heart will be very useful,God willing and good luck.

65

B.3 Interview questions with Nurse

Second interview was with a nurse, and we obtain those answers from her.

1. Do you think heart diseases one of the major reasons of pilgrims death? Heart disease, thecause of death overall. But in the pilgrimage of deaths increases due to increased effort onthe Hajj, especially the elderly and those with chronic diseases.

2. Can we predict bad heart situation from the heart rate? Yes, it is possible.

3. Can the heart rate be measured accurately from the wrist ? Yes.

4. Is it enough to predict emergency based on heart rate measurement? No, but that can bea sign.

5. What do you think of this project ? Excellent and useful.

66

E-SAVIOR: A WEARABLE PROTOTYPE DEVICE AND A … · Develop a prototype of wearable device in order...

Documents

Transcript of E-SAVIOR: A WEARABLE PROTOTYPE DEVICE AND A … · Develop a prototype of wearable device in order...