E-SAVIOR: A WEARABLE PROTOTYPE DEVICE AND A MOBILE APPLICATION FOR PILGRIMS SAFETY. April 2017

Transcription

1 E-SAVIOR: A WEARABLE PROTOTYPE DEVICE AND A MOBILE APPLICATION FOR PILGRIMS SAFETY April 2017

2 Abstract Since the chronic heart diseases are the main cause of death, a lot of medical alert systems are created. However, these alert systems involve the participation of patients, which seems almost impossible in some cases such as fainting or extreme discomfort. This has led to automate the detection 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 pilgrims is increasing yearly (Over 1.9 million pilgrims performed the Hajj in September 2016). Crowd management and Pilgrims safety become a must especially when the average age of pilgrims is around 55 years and the climate is not propitious for them. Despite the continuous efforts that are provided by the authorities, a very noteworthy number of deaths and losses are signaled in this extremely crowded gathering. So, this project aims to: 1. Develop a prototype of wearable device in order to monitor pilgrims with chronic heart diseases. The prototype will be able to track pilgrims heart rate and pinpoint their location in case of emergency. 2. Design and develop a mobile application that gathers all data sent by the prototype and alerts the hajj campaign responsible. II

3 Contents Contents List of Tables List of Figures V VI VIII 1 Introduction Context and motivation Problem statement Project Objectives Project Scope Target users Report organization Domain related Concepts and Systems Introduction Adopted Methodology Pre-project phase Technical feasibility Hardware Components Micro-controllers Sensors Synthesis Programming Languages and Libraries Software Components Challenges Operational Feasibility Schedule Feasibility Budget feasibility Requirements Gathering Competitor analysis of existing products Pilgrims Bracelet Apple watch Alert Life call Better alerts Lively Synthesis and Discussion Conclusion III

4 3 System Analysis and Design Introduction Domain Requirements Description Emergency Decision Product backlog User Stories System WorkFlow System Architecture Domain class diagram Hardware Design Connection between hardware and software components Sprint Definition Conclusion Implementation and Testing Introduction Programming Environment Hardware Components Software Components Testing techniques Code Testing Non-Functional Requirements Testing Sprint Description Hardware design Mobile design Implementation Hardware Development Software Development Testing Unit Testing Integration Testing Non-Functional Requirement Testing Sprint Description Hardware design Mobile design Implementation Sprint Description Hardware design Mobile design Implementation Conclusion References 51 Appendix 55 A Survey 56 A.1 Survey Results IV

5 B Interviews 64 B.1 Interview questions with campaign administrator B.2 Interview questions with Cardiologist B.3 Interview questions with Nurse V

6 List of Tables 2.1 Comparison between Arduino and Netdunio Arduino Different Boards Comparison between PPG and ECG sensors technology [49][23] E-savior hardware components Project Budget Estimation Competitor Analysis Competitor Analysis (Services) General Estimation Guideline Users stories, Features, and Benefits Sprint 1 Backlog GPS and Arduino Pins Wiring Sprint1 Unit Testing Cases Sprint 2 Backlog PPG sensor and Arduino Pins Wiring Thermistor sensor and Arduino Pins Wiring Sprint 3 Backlog VI

7 List of Figures 1.1 Pilgrims performing Tawaf in Makkah Statistics of Death Causes Scrum Sprint Workflow High Level Design of Smart Medical Alert System Arduino Microcontoller [6] Netduino Microcontoller [33] E-Savior work-plan with respect to scrum methodology Gantt chart of the E-Savior work-plan Apple watch product Alert1 product Lifecall product Better alerts product Lively Smart watch product Algorithm of Reading a pulse Alert Flow Chart Workflow of E-Savior prototype E-Savior System Architecture Domain Class Diagram Breadboard hardware components wiring WiFi shield Ublox-NEO6 GPS module Max30100 Heart rate sensor thermistor sensor Connection between hardware and software Sprints overall output E-savior GPS hardware design E-savior GPS class diagram Pilgrims locations on the map GUI GPS output data Sprint 1 Structure Sprint 1 GUI Connectivity Positive Testing Connectivity Negative Testing Add Marker Positive Testing Add Marker Positive Testing GPS Serial Monitor Sprint 1 Arduino Unit Testing Sprint1 Integration Testing Sprint1 Reliability Testing VII

8 4.15 GPS GUI E-Savior PPG sensor hardware design E-Savior temperature hardware design E-Savior health monitoring class diagram Pilgrim profile GUI Application alerts class diagram Alerts generated GUI VIII

9 Chapter 1 Introduction 1.1 Context and motivation Older adults present a higher risk for many types of diseases that can lead to severe health problems such as a variety of heat-related illnesses or death. In addition, warm weather and outdoor activity can complicate the situation. For these reasons, it is important to help older people 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 this obligation in case of health illness or lack of money. However, we notice that the number of pilgrims 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 age of pilgrims is around 55 years [16] and the climate is not propitious for them. Despite the continuous efforts that are provided by the authorities, a significant number of deaths and losses are 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 of Internet 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 application technologies that help campaigns and Hajj authorities in the identification of pilgrims as well as in pilgrims health control. Our motivation consists on the development of a wearable prototype device and a mobile application to monitor and track pilgrims. The wearable prototype device contains microcontroller, sensors and shields to monitor the exact heartbeats and pinpoint the exact position of the pilgrims that we are looking for. The mobile application gathers all information (heartbeats and position) sent by the wearable prototype device and alerts the campaigns responsible in emergency cases. 1

10 1.2 Problem statement Chronic diseases are the main cause of death as shown in figure 1.2 [34]. For that, many medical alert systems were created. The first systems were introduced in 1970, which are classified as basic push-button devices. These alert systems requires the user participation when he/she feels a certain discomfort by pushing a button that will transmit a signal to a base line. It is connected to a home line phone to alert the emergency operator. However, the user participation might get 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 interpret changes in a body s position [26]. However, this detection is not so reliable and false alerts can be occurred by rapid movements. According to the American heart association [8], a sudden decline or a change in blood pressure is interpreted as a sign of dizziness, fainting or heart attack. By measuring blood pressure, heart rate and temperature, the robust medical alert system, becomes more accurate and reliable. The project aims to: 1. Develop a prototype of wearable device in order to monitor pilgrims with chronic heart diseases. The prototype will be able to track pilgrims heart rate disorder and pinpoint their physical position in case of emergency. Appropriate modules and sensors have to be chosen for an accurate result. 2. Design and develop a mobile application that gathers all data sent by the prototype and alerts the hajj campaign responsible. 2

11 1.3 Project Objectives This project is meant to be used by Hajj campaigns to help in protecting their pilgrims from getting hurt or even die. The main aim of E-savior is to reduce the probability of accidents and help the pilgrims stay safe and by remotely monitoring pilgrims anywhere and anytime. In order 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, a signal 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 of pilgrims 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 pilgrims by: 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 heart rate, blood pressure as will as temperature; and then alerts the campaign responsible in case of emergency. The project will be completed by May The Prototype modules will include a heartbeats, blood pressure and temperature measurements, an alert generator and a GPS module to pinpoint the pilgrim. 1.5 Target users E-Savior is targeting both pilgrims with chronic diseases, Ministry of Hajj and hajj campaigns that 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 statement that encourage us to implement E-Savior, an overview of the contribution is defined in the first chapter. Chapter 2 presents the adopted software development methodology (Scrum) and the pre-project phase. The outcome of preproject phase is presented through the feasibility tests as well as the overview of competitors systems, the interviews and surveys. Chapter 3 discusses the analysis of the wearable hardware design followed by the software components that is used to conduct this project. 3

12 Chapter 2 Domain related Concepts and Systems 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 the preproject phase in terms of feasibility study in which an overview of existing medical alert systems and their main features, strengths and weakness is presented. Based on our analysis of the similar systems, the available hardware and software components as well as the interview with 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, organize and control the process of developing information systems [35]. There are different types of SDM that are classified by category: from linear to agile. In order to build our system, we will use an agile methodology. More specifically, Scrum [38] is chosen. Scrum is an iterative framework that is used for managing the development of complex software and product since the early of 1990s. By following Scrum, the system is grown increment by 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 can be: Product owner. His/her main task is to ensure that the product is delivered at the most value, provide a clear guidance for the team and manage the product backlog that is basically a list of things that needs to be done within the project. Scrum master. He/she manages how information is exchanged, facilitates the Scrum process and 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 sprint with skill sets, and cross-train. All members of the team collaborate and assist one another to ensure a successful sprint completion. 4

13 Sprints Scrum development process is expressed with the use of fixed-length iterations development cycles called Sprints. A sprint usually take two to four weeks (See Fig. 3.6). The process starts when the product owner specifies the product requirements in order to create a prioritized stories that called a product backlog then the team selects some of the stories to be implemented and add 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 is extracted the sprint backlog. The later is a list of user stories that are identified by the Scrum team to be completed during the Scrum sprint. The scrum team identifies the tasks necessary to 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, members can add new stuff to product backlog. 3. Scrum increases the team productivity by focusing on the collaboration and daily communication between scrum team member. 4. Scrum improves the deliverable quality. Since at the end of each sprint, a test is conducted to assess and validate the release,so it s quality is enhanced. 5. Scrum identifies easily the problems. Because of the continual feedback and its iterative nature that allows to discover problems. 5

14 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 four tests are conducted technical, operational, economic, and schedule tests. In this section, we describe the outcome of each of these tests Technical feasibility The purpose of technical feasibility is to provide information on how to deliver the project from a 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 hardware requirements as well as their existence. Smart medical alert systems are considered as embedded systems (See Fig. 2.2), which involve the use of micro-controller, sensors, and software. The choice of these components has an impact on the efficiency of the resulting product. In the following sections, we describe the hardware components in terms of availability, connectivity, strengths and limitations in order to choose the suitable ones. Figure 2.2: High Level Design of Smart Medical Alert System 6

15 Hardware Components This section describes the kind and type of the microcontroller and sensors used in the project Micro-controllers Arduino. Arduino is an open-source cross-platform microcontroller (See Fig.2.3) that is able to read inputs from various kind of sensors and shields then turns those readings into an output by using the Arduino Integrated Development Environment (IDE) [10]. The IDE assists the communication with the micro-controller and helps the bootloader to upload C/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 software Framework (See Fig. 2.4) [50]. Its pins are similar to Arduino s pins because of that it becomes compatible with some of Arduino s shields. Microsoft Visual Studio is used to communicate 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 has taken in account three aspects. First of all, the flexibility to build projects. In fact, a lot of shields and sensors are compatible with Arduino micro-controller. Second the availability of libraries which makes the process easier to implement. Finally, the existence of a large community with different level of expertise that will facilitate our learning process. 7

16 Table 2.1: Comparison between Arduino and Netdunio Criteria Arduino Netduino Hardware Shield availability[50] Open-source electronics platform A Lot of compatible shields Open-source.NET Microsoft Not all Arduino shields are tested and proven to work on Netduino Some Arduino libraries needs a modification to be used by Netduino compatible with any sensor Cross-platform runs on mac,windows and linux Visual C,.NET Libraries[27] Hundreds of additional libraries that can be used with Arduino Sensors compatible with any sensor OS Platform Cross-platform runs on mac, windows and linux Software Programming C/C++ language[50] Connectivity[7] Arduino Integrated Development Environment Visual Studio IDE Users Anyone Experts Prototyping Process is straightforward,large Process is less straight- Environment[27] community forward Community[50] Large community Small community Price[50] Inexpensive (less than 50$) Expensive (more than 69$) There are several Arduino board models available in market (See Table.2.2). We have chosen Arduino UNO board for many reasons which are 1)it is compatible with shields, 2) it is the best board to get started with electronics and coding, 3) it is suitable for prototyping purpose and 4) it is the most robust board. In addition, UNO is the most used and documented board of the whole Arduino and Genuino family [46]. 8

17 Table 2.2: Arduino Different Boards Arduino board Processor speed Digital I/O Pins Analog Input Serial Port Shield compatibility Special Features Uno 16 MHz Excellent Uno Ethernequire 16 MHz Very Good Has Ethernet Port. Re- FTDI cable to program Mega 16 MHz Good Mega 16 MHz Good Works with Android development ADK kit Leonardo 84 MHz Fair USB programming Port Due 16 MHz Poor Fastest processor Micro 32 MHz N/A Smallest board size Flora 32 MHz N/A Fabric-friendly DC Boarduino 16 MHz N/A Build without header. Require FTDI cable to program 16 MHz N/A Build without header. Require FTDI cable to program USB Boarduino Menta 16 MHz Excellent Mint-Tin size. Require FTDI cable to program 9

18 Sensors Before describing the sensors that are available, we will start by explaining how to measure the heart rate. An interview was conducted with a cardiologist and a nurse to specify which measures 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 them if heart diseases can lead to death and whether we can know if there is a problem with the pilgrim by measuring the heart beats to try and help them. They replied that yes most of pilgrims dies because of having heart issues especially heart attacks and the low performance of the heart muscles. Also, they replies with yes that measuring heartbeats is the first step to protect pilgrims but they should immediately get checked by a doctor to know what is the exact problem. Heart Rate (HR). HR reflects the frequency of a complete heartbeat from its generation to the beginning of the next beat within a specific time. It is typically expressed as beats per minute (bpm). HR can be extracted using ECG and PPG sensors[23]. Electrocardiography (ECG). ECG measures the heart s electrical activity represented as a vector between two point charges, using electrodes placed on the skin. It is mainly used for measuring heart rate and monitoring hearts electrical system[15]. Photoplethysmography (PPG). It is an optical measurement technique that uses light based technology to sense the rate of blood flow by measuring the amount of the reflected light by blood flow [24]. It can be used as a replacement of ECG of HRV 1 analysis health subjects. Also it measures of vessel stiffness. Based on the following comparison (See Table. 2.3), we decided to choose the PPG sensors Technology because it is more convenient with our project for many reasons. First, It is a small-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 it suitable with wearable devices. In addition, it provides accurate heart rate measurements with good response time. Photoplethysmography Procedure. E-savior will measures the heart rate and blood pressure with a PPG sensor located on the back of the bracelet device. The heart rate sensor based on the photoplethysmography technology, the later depends on a simple fact which is, since the color of blood is red because it reflects red light and absorbs green light, so the technology will measure the heart rate and blood pressure with an optical LED light source and an LED light sensor to detect the amount of blood flowing through the wrist at 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 by flashing its LED lights hundreds of times per second, E-Savior can calculate the variations in the light reflections that interpreted as heartbeats and blood pressure. [39]. beat. E-savior will measures the temperature using thermistor sensor. Body temperature can be measured from different parts of body, but for this project temperature will be measured from the wrist. 1 Heart Rate Variability (HRV) expresses the natural variation of Inter-Beat-Interval (IBI) values from beat to 10

19 Table 2.3: Comparison between PPG and ECG sensors technology [49][23] Criteria ECG PPG Response Time Don t require long settling times Require short-settling times, but take longer than the ECG sensor Accuracy Accurate Less accurate than ECG Technology Electrodes connected to different body LED that sends light into the tissue used parts Size Large size Small size Connectivity Require additional health shield Connected directly to the Arduino. Equip Sensor - Four electrodes place on the chest - - Fingertip, earlobe and wrist - No Use of conductive gel need for gel Limitations - Large size of the sensors - Limited - Separate noise - Different skin tones connection to the body need for conductive absorb light differently - The loca- gel - Impractical and not easy tion of the sensor on the body presents to equip unique challenges 11

20 Synthesis As explained in previous sections, we will use a number of hardware components in order to measure the heart rate and to pinpoint the location of pilgrim in case of emergency. The table 2.4 summarizes the different components that will be used to develop E-saviour hardware prototype. Table 2.4: E-savior hardware components Module name Arduino UNO Heart Rate sensor GPS module Wi-fi shield Battery 5-9v DC Breadboard How to be used? Main board that will used to build the project in top of it To read the pulse and send it as an input to Arduino UNO To get the latitude and longitude of a specific location To send data over the internet(to and from) the mobile application To power the board externally without the need of USB cable after code installation Facilitate building circuits Programming Languages and Libraries In this section, we are going to discuss the languages, software and the libraries used in order to 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 the hardware component. (b) Arduino Software (IDE) to make it easy to write code and upload it to the Arduino board 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 code that 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 serial communication Software Components In this section, we enumerate the programming languages and tools that are used to develop E-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 programming the application. 12

21 (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 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 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 know if any pilgrims are willing to use this prototype, we spread a survey to them just to know how are they willing to use this prototype and if they are going to get comfortable with it. We found out that 82% of pilgrims are agreeing to use this prototype to monitor health, therefore targeted users (pilgrims) can use E-savior without difficulties (See Appendix.A). From campaigns viewpoint that, this prototype will help them to reduce the cost of having a supervisor for each group of pilgrims, to monitor their pilgrims easily and to reduce the probability of pilgrims death. The implementation of this project has many benefits either for pilgrims side or campaigns side. In fact, each hajj campaign should provide this wearable medical alert systems for high risk pilgrims. We mean by that pilgrims with illness or old ones. This wearable prototype device offers the opportunity for pilgrims to feel safe. It also utilizes GPS tracking that allows the campaign responsible to pinpoint and find pilgrims when they need assistance. So, we concluded that Hajj campaigns and pilgrims are willing to use such technology to reduce the probability of pilgrims death and taking care of pilgrims fast and easy Schedule Feasibility Schedule feasibility is determined as the probability of a project to be carried out within its scheduled time limits [12]. In many cases, a project will be unsuccessful if it takes more than it was estimated. Schedule feasibility shows the work plan of the project with respect of scrum methodology (See Fig. 2.5). The following figure describes in detail our estimation in terms of Gantt Chart that is created by using Project Management Software (See Fig. 2.6). 13

22 Figure 2.5: E-Savior work-plan with respect to scrum methodology Figure 2.6: Gantt chart of the E-Savior work-plan 14

23 2.3.4 Budget feasibility Budget feasibility is a necessary step to determine the financial viability of this project development and to make a well informed decision on going forwards [51]. Table 2.5: Project Budget Estimation Prototype Budget Summary Arduino Uno PPG sensor thermistor sensor GPS module Bluetooth or Wifi Breadboard Battery 9v Jumber wires Grand Total 25.SR 20.SR 5.SR 35.SR 35.SR 12.SR 5.SR 10.SR 147.SR Based on this study, we found out that the estimated budget will be around 142SR. 2.4 Requirements Gathering Competitor analysis of existing products This section discuss some of our competitors and briefly describe the outcome of the competitor analysis 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 Apple watch Apple Watch is the ultimate smartwatch device for a healthy life style and for runners, athletes and 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

24 Figure 2.7: Apple watch product Measure movement Reminding any user to keep up with your regimens and routines Alert1 Medical alert system for those who are prone to falls and could not push the alert button in the event of an emergency [2]. Features: Figure 2.8: Alert1 product 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 properly during an emergency Life call Base unit and a small, waterproof pendant that is based on fall detection technology. This pendant notifies the base unit, which connects to the monitoring center, in the event of an emergency [22]. Figure 2.9: Lifecall product 16

25 Features: Press the button on the Medical Alert pendant to get help. Waterproof and Offers support in 150 different languages Better alerts The Better alerts consist of Pebble Smart Watch, smartphone Application, and a subscription to Better Alerts web service [13]. Features: Figure 2.10: Better alerts product Medicine Reminders sent to Pebble Smart Watch and Caregiver App. Text and 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 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

26 Table 2.6: Competitor Analysis Name Alert1 LifeCall Better alerts lively Pilgrims Bracelet Apple Watch E-Savior IT Device medical alert system Vision Better way to customer service pendant medical alert system Provide check in service Pebble Smart Watch Revolutionizes the way caregivers and their loved ones connect Safety Watch Wearable Band To avoid future deadly disasters Smart watch The ultimate device for your healthy life A wearable prototype device and mobile application. To keep an eye on the pilgrims safety to provide the best customer experience to help our customers live safely and independently Scope Patient Patient For seniors For older Awearable For athlete Pilgrims with with that want adult to let device for and people chronic chronic to maintain live safely pilgrims with conditions conditions their independencpendently. and inde- disabilities price $ $ free Almost 40$ 18

27 Table 2.7: Competitor Analysis (Services) Services Alert 1 Life call Better alerts lively Pilgrims Bracelet Apple watch Display yes yes yes yes yes yes no screen Waterproof yes no no yes no yes yes Measure yes no no no no yes yes heart-rate Measure no no no no no no yes blood pressure fall detection no no yes yes no yes yes Step yes no no yes no yes no counting Receiving yes yes yes yes no yes no medication reminders Built-in yes yes yes yes yes yes yes GPS Bluetooth yes yes yes no no yes yes GPRS yes yes yes yes no yes yes WIFI yes no no no no yes yes Emergency no yes yes yes no no no button E-Savior 19

28 Synthesis and Discussion The study of related work, the analysis of questioner and the interview results (See Appex.A and 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 measure heart 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 focuses on 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-project phase that contains the technical, operational, schedule, and budget feasibility studies. Requirement analysis comes finally to show the competitor analysis and the summary results of interviews with cardiologist, campaign responsible, and pilgrims. 20

29 Chapter 3 System Analysis and Design 3.1 Introduction This Chapter describes what are the requirements needed to implement the heart rate and blood 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 that starts by collecting the user stories in order to establish the Sprint Backlog. In addition, the activity diagram and the domain class diagram are presented to model the system workflow and structure. 3.2 Domain Requirements Description The measurement of pilgrims heart rate is done by using photoplethysmograph (PPG) technology [36]. The PPG produces a predictable wave shape [4] using two LED lights to detect the pulse wave when the heart pumps and the blood travels faster than the actual blood circulates along all arteries. The produced analog signal needs to be processed in order to get the actual heart rate. For that, some essential values need to be measured such as: 1)PPG data that holds the analog raw data sensed using PPG sensor, 2)IBI value that determines the time interval 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 avoid high frequency noise, then analyzed it by a set of calculations to get the desired value. The process starts (See Fig. 3.1) by identifying the peaks, if a peak is detected the IBI is calculated between beats and stored into an array of size 10 based on the adopted algorithm, these steps are repeated until the array is filled. When the previous condition is true, the BPM is calculated as an average of all ten IBI values stored in the array [28]. 21

30 Figure 3.1: Algorithm of Reading a pulse Source: Lim Chun Keat, Asral Bahari Jambek, and Uda Hashim[2016, p.286] 22

31 3.2.2 Emergency Decision The E-savior wearable device is composed of a ring wearing by pilgrim in order to monitor his/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 order to prevent false alerts from happening, a reset button is included.in case of emergency, the ring will vibrate until the reset button is pressed by the pilgrim to cancel the alarm. If the alarm was not canceled within 60 seconds by the pilgrim, the system will send an emergency alert to the campaign responsible. The following scenario (See Figure 3.2) is representing how the system will work to generate alarms. First, it starts when the pilgrim wears the ring to detect his/her health status. In case the pilgrim has a malaise an alarm is sent to the campaign responsible but in case of abnormal condition occurs, the ring will vibrate for 60 seconds, if there was no emergency the pilgrim shall press the button to cancel the emergency help, else if the button is not pressed and the vibration period passed, an alarm is sent to the campaign responsible to get an immediate help. Figure 3.2: Alert Flow Chart In order to make an accurate estimation about the pilgrims condition, some constraints must be set (See. Table 3.1). Based on the National Institute of Health, the ideal range of resting heart rate for adults and seniors ranges between BPM. In the other hand, the average resting heart rate for well-trained athletes is BPM [9]. However, the normal heart-rate of pilgrims differ from person to person while doing a moderate intense activity that starts from walking 4 mile per hour [18] the heart rate is increasing accordingly. Pilgrims speed will be measured by using an GPS Module that is also used to get the location [17], these increases in BPM can be limited by the use of estimated target heart rates for 50%-85% zone which used as a general guideline estimation [9], to keep the heart rate below a certain level to adequately safeguard 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 during the heart physical activates it is between 70% - 90%, for that the adopted general guideline from the 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 may increases with weight but not exceeding 100BPM, 2) air temperature may affect the heart rate but usually no more than 5-10 beats a minute, 3) while movement and changing of body position the heart rate may be affected by go up a little bit for couple of minutes, 4) Medication use 23

32 Table 3.1: General Estimation Guideline General Guidline Age Blood Pressure Heartrate Moderate Intensity 4 mph (50%-85%) / / / / / / / / / / For Non athlete Heartrate Light Intensity For Non athlete Body Temperature 36.1 C-37.2C may slow the pulse or raise it [20]. In addition, the decision will be made also depending on the pilgrim temperature, the normal body temperature is between C and any Increase or decrease considered as an emergency. Moreover, The wearable device is also taking the blood pressure measures into consideration, the normal blood pressure for people aged is 120/80 and it increases with age. These two numbers systolic and diastolic values are measured by PPG techology [42]. The systolic value is the reflection of the blood pressure in vessels when the heart beats, in the other hand, the diastolic value is the reflection of the blood pressure in vessels when the heart rest. These measurement guidelines are according to Health institutes and they were validated by three expert doctors who had agree on the guidelines ability to detect emergency and minimize the danger. 3.3 Product backlog The Scrum development process advocates the use of product backlog rather than the use case diagram and system sequence diagram, the reason is: since in agile project, the code changes frequently 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. In addition, 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] User Stories User stories are collected from the campaign responsible and pilgrims in order to create the product backlog. For that, all user stories were documented (See Table.3.2) to identify the functionalities desired for the deliverable product. 24

33 Table 3.2: Users stories, Features, and Benefits Story number From which view Story A As a campaign responsible User Story description I want to pinpoint the location of any pilgrim Story B As a campaign responsible I want to receive accurate alerts about the emergency situations Story C As a campaign responsible I want to have a visual display of an aggregation of sensed information Story D As a pilgrim I want to have a convenient wearable device that monitors my health Expectation Features Benefits To reach them anytime and anywhere To help the pilgrims immediately To take the right decision To carry it and use it easily to perform Hajj safely Include Built-In GPS Receive emergency alert Viewing all information through mobile application Measure blood pressure, temperature, heart rate and speed To reach the pilgrims faster To Control the possible deadly emergency To facilitate the process of keeping pilgrims safe To monitor the pilgrim overall health in order to help him/her if he/she gets in danger 25

34 3.3.2 System WorkFlow The system workflow is useful for clarifying the series of activities necessary to complete the system work process. The activity diagram of UML is used to model the workflow which is a set of activates. The below activity diagram illustrates the activities required for a potential pilgrim 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 on previous 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 to the pilgrim place and do the necessary. (b) If there is no emergency detected, the system keeps measuring the heart rate and the blood pressure. Figure 3.3: Workflow of E-Savior prototype 26

35 3.3.3 System Architecture The system architecture (See Fig.3.4) is composed of hardware and software components that need 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 to read the data and send it to the web host to be stored. In the meanwhile, E-savior application reads the data from the web host database and presents it to the campaign responsible in a good manner that shows the health status and location of pilgrims without specifying a priority for each case, since every alert sent is going to be for an emergency case and they are equally important. Figure 3.4: E-Savior System Architecture Domain class diagram A UML package diagram organizes elements and diagrams into groups. In addition, it depicts the generalizations and dependencies between the packages that make up a model. A domain class diagram is a modeling notation that defines the attributes, methods and relationships among 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 dependents on the Pilgrim Information package. Pilgrim Information package contains three classes that are pilgrims personal information, disease and the treatments. The health monitoring package contains four classes that are the health status of the pilgrims by retrieving the blood 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 associated to the alert class that generates an alert and sends a notification to the campaign responsible. Campaign module package contains two classes Campaign Responsible and the Notification class. The Campaign Responsible class contains the name of the responsible and the number of pilgrims that he is responsible of, and the Notification class that shows that alert if any ab normal situation happened to a pilgrim. 27

36 28 Figure 3.5: Domain Class Diagram

37 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 programmable 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 correctly and send the data gathered to the microcontroller and then send it to the web host to be stored though the Internet network using WiFi shield (See Fig.3.7) that plugged into the Arduino directly. Figure 3.7: WiFi shield Figure 3.7 shows the Arduino WiFi shield that connects the wearable with a wireless network to enable the transmission of data between the modules and sensors with the mobile application. The data transmitted is gathered using: 29

38 1. GPS module The GPS module is tiny receiver device (See Figure.3.8) that calculates the exact position and time by getting the data location from the satellites. There are 24 active satellites in space and it constructed to always contain at most 12 satellites in any location. In addition, the GPS comes attached to an antenna that will allow any receiving of data that sent by those satellites. The accuracy of the GPS parameters can be determined by the number of the satellites captured by the antennas, the number of satellites should be more than four for an accurate result [44]. Figure 3.8: Ublox-NEO6 GPS module 2. PPG sensor The PPG based technology sensor is used to sense the heart rate and blood pressure as mentioned in Section The measures will be handled and collected by the max30100 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

39 3. Thermistor sensor The thermistor sensor (See Fig.3.10) is used to measure the temperature of the pilgrim through an analog pin. It sense the temperature by capturing precise change in electrical resistance 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 displayed and reads from Arduino microcontroller using the E-Savior application. First of all, database should be created in MySQL server according the class diagram shown in section to allow storing data from the Arduino; so it can be visualized using the android studio IDE. As shown in the following figure (See Fig.3.11), the data gathered is handled by the microcontroller then the microcontroller makes a HTTP request to store data in the MySQL database. In order to send the request, the Arduino must be connected to the Internet network, which is done by using Wifi shield that is plugged in the Arduino. After that, the developed Android application developed can read and process the data after connecting it to MySQL database, However, the connection 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 request using AsyncTask class. 31

40 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 the final product (See Fig. 3.12). In order to plan the sprints, first of all, after all stories have been gathered as shown in Section 3.3.1, the product backlog is created which contains a list of all features that needs to be done in the product [40]. The product backlog may change throughout the project time in case of new requirements were added or existing requirement has been modified [40]. The entries in the product backlog are prioritized and ordered accordingly with placing priority rank and story points. 1. Story points : The story point is a measure of the effort required to implement an individual story. 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 the product 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 be completed during a Scrum sprint. those tasks are identified by the Scrum team along with the estimation of hours for each task and its priority. 32

41 Figure 3.12: Sprints overall output 3.6 Conclusion This chapter documented the user stories that have been gathered in order to start the sprint planning. In addition, it presented both the hardware design and the software analysis for each sprint and how to link between them for an effective development model. 33

42 Chapter 4 Implementation and Testing 4.1 Introduction This chapter gives an overview of the programming environment and presents the sprints required to implement this project. Sprints are clearly defined by giving the description of each sprint with 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. The final section of each sprint is testing which is going to test the output of each spring followed by the integration testing. 4.2 Programming Environment This Section will describe the hardware and software components needed in order to fulfill the objective of this project Hardware Components The project prototype will be build using a number of hardware components, in one hand, Arduino microcontroller will be used, basically it is an open-source cross-platform microcontroller that is able to read inputs from various kind of sensors and shields then turns those readings into an output by using the Arduino Integrated Development Environment (IDE) [10]. The IDE assists the communication with the micro-controller and helps the boot loader to upload C/C++code file into the Arduino memory. So, it will get executed immediately. There are several Arduino board models available in market and this project is using Arduino UNO board for many reasons which are 1)it is compatible with shields, 2) it is the best board to get started with electronics and coding, 3) it is suitable for prototyping purpose and 4) it is the most robust board. In addition, UNO is the most used and documented board of the whole Arduino and Genuino family [46]. In the other hand, a number of modules and sensors will be used such as: GPS module, PPG sensor, WIFI shield, thermistor and accelerometer. However, in order to develop the hardware components of E-Savior, some software, languages and libraries must be used which are: 1. Programming languages and general software. (a) The Arduino programming language that is based on C/C++ for programming the hardware component. (b) Arduino Software (IDE) to make it easy to write code and upload it to the Arduino board memory. (c) Fritzing is an open source hardware initiative for documenting the prototype. 34

43 2. Libraries. A software library is a collection of data and precompiled programming code that 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 serial communication Software Components In this area, we enumerate the programming languages and tools that are used to develop E-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 programming 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, it validates and verifies whether the project meets its functional and non-functional requirements [25] Code Testing The code unit testing will involve the test of Arduino and Android code. From the Arduino side, there is no predefined methods that support the unit testing, it is usually done in different ways depend on the programmer. From the other side, the Android code will be tested using JUnit 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 an APK that runs on the device alongside the app under test. The system runs the test APK and the app under tests in the same process, so the tests can invoke methods and modify fields in the app, and automate user interaction with the application. These tests are the fundamental tests in the android application testing strategy. The unit test generally exercises the functionality of the smallest possible unit of code which is methods or classes in a repeatable way. And it is conducted to verify the logic of specific code in the application. So after running unit tests against the code, we can easily verify that the logic of individual units is correct. Moreover, running unit tests after every build helps us to quickly catch and fix software regressions introduce by code changes to the application[14]. After the unit tests passes, an integration test must be conducted between the two components to ensure the validity and correctness of the integration, and it is done though simulation between them. 35

44 4.3.2 Non-Functional Requirements Testing The non-functional requirements is different from the functional requirements, it is mainly defined as the system attribute that specify how the system should work [21]. This project described 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 performance overtime [47] 2. System usability that will be attained through user friendly interface design and easy navigation 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 Description The first scrum sprint is composed of story C and story A that is considered with accessing the pilgrims longitude and latitude to locate the exact location of any pilgrim in the same hajj campaign and present it to the campaign responsible through a mobile application using Google Android API. In the other hand, story C aims to present those data through visual display used by the campaign responsible. The stories are simplified into smaller pieces or chunks called tasks (See Table.4.1) to be implemented. Story Business Priority Story Priority Table 4.1: Sprint 1 Backlog Sprint 1 Backlog Story A 1 4 Design electronic circuit to get the GPS location Connect the GPS module to the Arduino Develop a code that retrieve the coordinates from GPS module Story C 4 2 Develop a mobile interface that displays the coordinates of each pilgrim Tasks Priority Week Effort 1 2 days 2 3 days 3 2 weeks 4 1 week Hardware design The GPS module consists of an external antenna and four pins that are used to connect the GPS 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

45 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 module VCC RX TX GND GPS datasheet Arduino UNO PIN5 NA PIN10 GND Figure 4.1: E-savior GPS hardware design 37

46 Mobile design 1. The package Geo Location (See Fig.4.2) contains the Location class that has variables latitude, 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 of each pilgrim. Figure 4.2: E-savior GPS class diagram 2. The mobile prototype illustrates how location information are going to be displayed to the campaign responsible through the mobile application (See Fig.4.3). Figure 4.3: Pilgrims locations on the map GUI 38

47 4.4.2 Implementation Hardware Development The GPS module developed according to the design sketch done earlier (See Fig.4.1). It connects the GPS with Arduino Uno board in order to run properly by allowing the external antenna of GPS to receive NMEA sentences (GPS raw data) (See Fig.4.4a) and then the Arduino Uno fetches 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 Software Development The implemented GUI of this sprint is consist of Google map API v2 and a search bar that will lead the campaign responsible to easily pinpoint the exact location of pilgrims to reach them faster. This process is done by linking the software with the hardware component in order to make them exchanging the coordinates of pilgrims which presented as red markers on the map(see Fig.4.6). The application reads and accesses the data stored by the wearable attached 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 and longitude then pass it along to the function responsible of adding a marker. Figure 4.5: Sprint 1 Structure 39

48 Figure 4.6: Sprint 1 GUI Testing This area will present the result of all tests conducted including: unit testing of both hardware and software components, integration testing between them, and finally non-functional requirements testing that are related to sprint Unit Testing The unit testing is conducted for two components, first of all, the first test is related to the Android 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

49 Figure 4.7: Connectivity Positive Testing Figure 4.8: Connectivity Negative Testing 41

50 Next test was conducted on the addmarker() method to check adding of the markers on the maps by inserting double GPS location values on Obhur, and then we try on some string inputs and it doest not shows the marker. Figure 4.9: Add Marker Positive Testing Figure 4.10: Add Marker Positive Testing 42

51 Table 4.3: Sprint1 Unit Testing Cases Test case ID Test case description This test case to verify the connectivity method by asserting the result with correct URL input This test case to verify the connectivity method by asserting the result with incorrect URL input This test case to verify the method addmarker by inserting correct double inputs of GPS location This test case to verify the method addmarker by inserting incorrect String inputs of GPS location Input data String strurl = 000webhostapp.com /retrieve.php ; StringstrUrl= webhostapp.com /retrieve4.php ; double lat= ; double lng= ; String lat= ; String lng= ; Expected result Get Connected Not Connected Adding marker on Obhur Adding marker on Obhur Actual result Pass/ fail Remark Get Connected Pass Positive test Not Connected Fail Negative test Adding marker on Obhur No marker is adedd Pass Fail Positive test Negative tets The second unit test is related to the GPS module to check if the output data is correct or not, this test was held from three different geographical areas. The output latitude and longitude were taken from the Arduino serial monitor (See Fig. 4.11) and inserted into google map to check if the antenna read the data correctly from the satellite and whether the Arduino processed it efficiently. For that, a comparison is done using Google Maps by comparing the real location and the location retrieved from the GPS module. The result of this test shows that the GPS module is working properly (See Fig. 4.12). Figure 4.11: GPS Serial Monitor 43

52 (a) Real location on GoogleMaps (b) inserting GPS Data on GoogleMaps Figure 4.12: Sprint 1 Arduino Unit Testing Integration Testing The integration testing is done between the hardware which is the GPS module that is connected to 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 far distance simulation (See Fig.4.13) where the first party has connected the GPS from Obhur neighborhood (showing in the map as a blue marker named Nala), the second party was having the application running to track the first party (showing in the map as a blue current location marker). The result shows that components are integrated together and well performed. Figure 4.13: Sprint1 Integration Testing 44

53 Non-Functional Requirement Testing This sprint has two non-functional requirement, the first one is reliability and it tested through comparing 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 first location in Alsameir neighborhood. These two Figures shows the system output is consistence over time and place. (a) From Alrehab neighborhood (b) From Alsameir neighborhood Figure 4.14: Sprint1 Reliability Testing The second non-functional requirement is usability, its test is conducted to make sure that the application is user usable. By developing simple and user friendly interface, For E-Savior application is designed to show the coordinates of any pilgrim s location as a simple marker that is displayed on the map (See Fig. 4.15), showing also the search bar that can direct to any other pilgrim s marker and easily navigate them. Figure 4.15: GPS GUI 45

54 4.5 Sprint Description The second scrum sprint is composed of story D and story B (See Table.4.4). Story D is about measuring the heart rate and blood pressure, temperature and calculating the speed using Arduino sensors, then sending the measured values to the E-savior mobile application. Story B is about developing a mobile service that will check if the heart rate and the blood pressure are abnormal and notify the campaign responsible by showing the notification on the E-saviour mobile application. Table 4.4: Sprint 2 Backlog Story Business Priority Story Priority Sprint 2 Backlog Story D 1 4 Design electronic circuit to measure heart rate, blood pressure and temperature Connect the Heart Rate, blood pressure and temperature sensor to the Arduino Develop a code to get the heart rate, blood pressure and temperature values Story B 1 4 Develop a service that notifies the campaign responsibles in case of emergency Tasks Priority Week Effort 1 2 days 2 5 days 3 2 weeks 4 1 week Hardware design 1. The MAX30100 sensor consist of two LEDs, a photodetector, optimized optics, and lownoise analog signal processing to detect heart rate signals. Also it has four pins that used to 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 (See Table.4.6 and Fig.4.17). The measure of temperature is done through an analog pin with the help of 10k resistor. 46

55 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

56 Figure 4.17: E-Savior temperature hardware design Mobile design 1. The heart rate, temperature and blood pressure class diagram (See Fig.4.18) which are included inside Health Monitoring that contains the health status class that is a generalization of the heart rate, temperature and blood pressure measurements that describe a specific status. Those measurements are going to be calculated using specialization classes 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 values are going to be displayed to the campaign responsible through the mobile application, and displays 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 health condition and status. 48

57 Figure 4.19: Pilgrim profile GUI Implementation The output of this sprint is heart rate and blood pressure measurements that will be sent to the mobile application to let the campaign responsible monitor the pilgrims health and to receive an alert if an emergency occurred to the pilgrim. The measurements will be read from the database on real time. 4.6 Sprint Description The third sprint is composed of Story C (See Table.?? and Table.4.7). It is about wrapping all 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. Table 4.7: Sprint 3 Backlog Story Business Priority Story Priority Sprint 2 Backlog Story C 3 8 Aggregate data of emergency cases Integrate 2 2 weeks and Test the overall system Tasks Priority Week Effort 1 1 week 49

58 Hardware design This sprint does not include any physical and hardware component Mobile design The classes used for storing and generating the alert data is presented in Fig Those classes present the output of alerts in a GUI (See Fig.4.21) to make the campaign responsible manage the pilgrims immediately when harm occurs. The prototype of the sprint aims to show the alerts that are generated based on some rules and functions. Figure 4.20: Application alerts class diagram 50

59 (a) Alerts. (b) Alert details. Figure 4.21: Alerts generated GUI Implementation The output of this sprint is to generate statistics about emergency cases and their locations to have an integrated system with all functions connected together, and to test the functionalities of the overall integrated system. 4.7 Conclusion The conclusion of this chapter shows that, this project has been implemented with different technologies by following the Scrum sprints, sprint by sprint. Connecting the wearable hardware with software to generate an emergency alert, followed by the various types of testing. 51

60 References [1] agilefaq.wordpress.com. What is a story point. Last visited in november [2] alert 1.com. Alert1. Last visited in October [3].aljazeera.com. Saudiarabia introduces bracelets hajj safety html, Last visited in October [4] amgalbu. Heart beat detection. 6 heart-beat-detection, Last visited in February [5] apple.com. Apple watch series. Last visited in October [6] arduino.cc. arduinoboarduno. Last visited in October [7] Arduino.com. Arduino software. Last visited in october [8] American Heart Association. Heart attacks, strokes, heart failure reasons and consequences. Last visited in November [9] American Heart Association. Target heart rates. Last visited in October [10] Steven F. Barrett. Arduino Microcontroller Processing for Everyone. Morgan and Claypool Publishers, [11] By Vangie Beal. library. Last visited in october [12] By Vangie Beal. What is schedule feasibility. Last visited in october [13] betteralerts.com. Better alerts. Last visited in October [14] Andriod Developers. Getting started with testing. Last visited in october [15] gezondheid.infonu.nl. Elektrocardiografie: Meting elektrische activiteit van hart. Last visited in october

61 [16] KSA Government. Hajj statistics. hajj 1437 ar.pdf, Last visited in November [17] Mikal hart. Arduino wisdom and gems. Last visited in February [18] harvard school of health. Measuring physical activity. Last visited in October [19] Shane Hastie and Angela Wick. User stories and use cases - don?t use both! Last visited in March [20] American heart association. All about heart rate, Last visited in February [21] Functional requirements vs non functional requirements. Last visited in March [22] ifecall.com. Lifecall. Last visited in October [23] imotions.com. Ecg and ppg sensor s technology. Last visited in October [24] instructables. Led pulse sensor (ppg) for arduino. Last visited in october [25] ISTQB. Fundamentals of testing. Last visited in october [26] Qiang Li, John A. Stankovic, Mark A. Hanson, Adam T. Barth, John Lach, and Gang Zhou. Accurate, fast fall detection using gyroscopes and accelerometer-derived posture information. In Proceedings of the 2009 Sixth International Workshop on Wearable and Implantable Body Sensor Networks, BSN 09, pages , Washington, DC, USA, IEEE Computer Society. [27] lifewire.com. Arduino vs netduino: Which platform is on top? Last visited in october [28] Asral Bahari Jambek Lim Chun Keat and Uda Hashim. Heart-rate monitoring system design and analysis using a nios ii soft-core processor. 62: , [29] maximintegrated.com. Pulse oximeter and heart-rate sensor ic for wearable health. Last visited in December [30] mikewcohn. Sprint backlog and the scrum sprint. Last visited in october [31] Joel Murphy and Yury Gitman. pulse sensor algorithim. Last visited in october [32] mylively.com. My lively smatrwatch. Last visited in October [33] netduino.com. arduinoboarduno. Last visited in October

62 [34] World Health Oganization. Top 10 causes of death. Last visited in November [35] IT Knowledge Portal. Software development methodologies. Last visited in November [36] Dan Radigan. Measurment of heart rate using ppg. Last visited in January [37] Dan Radigan. Scrum:a brief look into using the scrum framework for software developement. Last visited in october [38] Kenneth S. Rubin. Essential Scrum: A Practical Guide To The Most Popular Agile Process. Addison-Wesley Professional, [39] samsung.com. How to measure heart rate samsung gear. Last visited in October [40] scrum institute.org. The scrum product backlog. Scrum Product Backlog.php, Last visited in October [41] scrumalliance.org. learn about scrum. Last visited in october [42] HS Oh JS Lee IY Kim SH Song, JS Cho. Estimation of blood pressure using photoplethysmography on the wrist. Last visited in March [43] slideshare.net. Creating a product backlog. Last visited in october [44] sparkfun.com. Gps basics. Last visited in December [45] sparkfun.com. What is an arduino? Last visited in December [46] sparkfun.com. arduinoboarduno. Last visited in October [47] Anderw Stellman. Understanding nonfunctional requirements. Last visited in March [48] thebalance.com. How to write an awesome technical feasibility study. Last visited in october [49] valencell.com. Ppg sensor s technology. Last visited in October [50] Chris Walker. Getting Started with Netduino. Make Books - Imprint of: O Reilly Media, Sebastopol, CA,

63 [51] woodleycoles.co.uk. Feasibility studies and budgets. Last visited in october

64 Appendix A Survey A.1 Survey Results 56

65 57

66 58

67 59

68 60

69 61

70 62

71 63