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

Transcription

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

2 Abstract E-savior is a medical alert system in the form of a wearable prototype device that monitors blood pressure, heart rate and temperature to automatically signals the presence of malaise requiring urgent attention. When a malaise is detected, the wearable prototype device will connect to E-savior mobile application to summon emergency personnel. It is composed of micro-controller, sensors and shields that will be used by pilgrims. So that, E-savior system can help pilgrims to be safe and protect them in an emergency situation. Keywords: Medical alert system, wearable devices, Arduino, Android. II

3 Contents Abstract Contents List of Tables List of Figures II 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 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 Functional Requirements (Product backlog) User Stories System WorkFlow System Architecture Domain class diagram Hardware Design Connection between hardware and software components Non-Functional Requirements Conclusion Implementation and Testing Introduction Programming Environment Hardware Components Software Components Testing techniques Code Testing Non-Functional Requirements Testing Sprint Definition 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 Hardware Development Software Development Testing Integration Testing Non-Functional Requirements Testing Sprint Description Hardware design Mobile design Implementation Hardware Development Software Development IV

5 4.7.3 Testing Integration Testing Conclusion Conclusion Challenges and solutions Future Plans References 53 Appendix 57 A Survey 58 A.1 Survey Results B Interviews 66 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 [60][34] E-savior hardware components Project Budget Estimation Competitor Analysis Competitor Analysis (Services) General Estimation Guideline Users stories, Features, and Benefits Sprint 1 Backlog Sprint1 - GPS and Arduino Pins Wiring Sprint1 Unit Testing Cases Sprint 2 Backlog PPG, Thermistor and Accelerometer sensors and Arduino Pins 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 [14] Netduino Microcontoller [43] 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 Pulse Sensor Alarm Buzzer Thermistor Sensor Sprints Overall Output Sprint1 - Hardware Component Design (E-savior GPS) Sprint1 - Software Design Components Sprint1 - Software Prototype Design Sprint1 - GPS output data Sprint1 - Software Abstract Architecture Sprint1 - Software Release Sprint1 - Connectivity Positive Testing Sprint1 - Unit Testing Sprint1 - GPS Serial Monitor Sprint1 - Arduino Unit Testing Sprint1 - GPS Serial Monitor Sprint1 - Integration Testing Sprint1 - Reliability Testing Encrypted Password VII

8 4.16 Sprint1 - MD5 Security test Sprint2 - Hardware Component Design Sprint2 - Software Design Class Diagram Sprint2 - Pilgrim profile GUI Sprint2 - Arduino Serial Monitor Sprint2 - Pilgrim Details GUI Sprint2 - Integration Test Arduino Sprint2 - Integration Test Android Sprint2 - Heart Rate from Arduino Sprint2 - Heart Rate from OMRON Sprint3 - Hardware Component Design Sprint3 - Design Class Diagram Sprint3 - Alert Management Sprint3 - Alert Management Sprint3 - Integration Testing 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) [26]. Crowd management and Pilgrims safety become a must especially when the average age of pilgrims is around 55 years [26] 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 [61], 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 accurate 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 [44]. 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 [44] Detection of malaise can be based on the use of accelerometers and Gyroscopes to interpret changes in a body s position [37]. However, this detection is not so reliable and false alerts can be occurred by rapid movements. According to the American heart association [16], 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, 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 interprets 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 dint of 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. The campaign responsible receives an alert when a critical situation happens. The alert contains a description of the situation and the pilgrim 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. Informing campaign responsible about pilgrims heart rate, blood pressure and temperature as well as fall detection; 2. Making pilgrims feel safe and secure; 3. 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 heartbeat, 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 five 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 study and an the overview of competitors systems, interviews and surveys. Chapter 3 shows the analysis and design of the wearable hardware followed by the software components, as well as how to connect them. In addition, it presents the domain and non-functional requirements. Chapter 4 gives an overview of the implemented sprints and how the functional and non-functional requirements are tested. Finally, Chapter 5 enumerates all challenges that we faced and how they are fixed. 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 through a feasibility study in which an overview of existing medical alert systems and their main features, strengths and weakness are presented. Based on our analysis of similar systems, the availability of hardware and software components, and the interview with cardiologists, we present an abstract design of E-Savior. 2.2 Adopted Methodology The development of any information system follows a framework that is used to structure, organize and control it. this framework is called Software Development Methodology (SDM) [45].There are different types of SDM that are classified by category: from linear to agile. In order to build our system, we use Scrum, which is an agile methodology to build E-savior. Scrum is an iterative framework that is used to manage the development of either complex software or product. By following Scrum, the system is grown increment by increment. Each of them is tested to ensure a high quality of the release [47]. 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 Scrum development process is expressed with the use of fixed-length iterations called sprints. The duration of each sprint is approximately between two and four weeks (See Fig. 3.6). The process starts when the product owner specifies the product requirements in order to create 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 [40], from which is extracted the sprint backlog. The later, user stories will be presented as a list and it is identified by the scrum team to be achieved within the sprint period. The scrum team identifies the tasks necessary to complete each user story. Figure 2.1: Scrum Sprint Workflow [40] We chose Scrum to develop E-savior for these reasons: 1. Scrum is suitable for complex products [50]; 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. 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 which are 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 [59]. 5

14 We emphasize through technical feasibility study, our needs in terms of software and hardware requirements as well as their availability in the market. 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 according to these criteria: availability, connectivity, strengths and limitations in order to choose the suitable ones. Figure 2.2: High Level Design of Smart Medical Alert System 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) [18]. 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 [14] Netduino. Netduino is an open-source cross-platform micro-controller based on.net Micro software Framework (See Fig. 2.4) [62]. 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. 6

15 Figure 2.4: Netduino Microcontoller [43] The table 2.1 shows 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. Table 2.1: Comparison between Arduino and Netdunio Criteria Arduino Netduino Hardware Shield availability[62] 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 operates on windows, linux and mac Visual C,.NET Libraries[38] Hundreds of additional libraries that can be used with Arduino Sensors compatible with any sensor OS Platform Cross platform operates on windows, mac and linux Software Programming C/C++ language[62] Connectivity[15] Arduino Integrated Development Environment Visual Studio IDE Users Anyone Experts Prototyping Process is straightforward,large Process is less straight- Environment[38] community forward Community[62] Large community Small community Price[62] 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) compatible with shields, 2) suitable for beginners, 3) 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 [57]. 7

16 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 8

17 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 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 help them. They replied that most of pilgrims dies because of having heart issues especially heart attacks and the low performance of the heart muscles. Also, they 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). Is the frequency of a complete heartbeat from the origin of the heartbeat till the beginning of the next beat within a specific period of time. The metric used to measure the HR is beats per minute (bpm), and it can be measured by using ECG and PPG sensors [34]. 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 [24]. 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 [35]. It can be used as a replacement of ECG of HRV 1 analysis health subjects. Also it measures of vessel stiffness [24]. 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. First, It is a small-sized sensor that can easily connected to Arduino board without additional health shield. Also, it is a dry sensor. 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 measures the heart rate and blood pressure with a PPG sensor located on the back of the prototype device. The heart rate sensor based on the photoplethysmography technology [46]. The later depends on a plain fact which is, since the blood has a red color so it s going to absorbs green light and reflects the red light. Therefore, the technology will measure the heart rate and blood pressure with an LED light sensor through finger by detecting the amount of blood flow at any time. It starts by flashing the light through the skin, and when heart beats the absorption of the green light is increasing in the blood, and the reflection is decreasing. Between beats, green light absorption become less and the reflection is increasing. However by repeating the process of flashing the LED lights for more than a hundred times per second, E-Savior can calculate the variations in the light reflections that interpreted as heartbeats and blood pressure [48]. E-savior measure the temperature using thermistor sensor. Body temperature can be measured from different parts of body, for this project the temperature is measured from the finger. 1 Heart Rate Variability (HRV) Represent the variation of Inter-Beat-Interval (IBI) values from one beat to another. 9

18 Table 2.3: Comparison between PPG and ECG sensors technology [60][34] 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 10

19 Synthesis As explained in previous sections, we use a number of hardware components in order to measure the heart rate and pinpoint the location of pilgrim in case of emergency. 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 be 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 [12]. (b) Arduino Software (IDE) to make it easy to write code and upload it to the Arduino board memory [10]. (c) Fritzing is an open source hardware initiative for documenting the prototype [22]. 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 [28]. (b) HR spark-fun library: Heart rate library will help to calculate Pulse, Signal, HRV, BPM, QS,and Scale [54]. (c) SoftwareSerial Library: it allows the Atmega processing unit chip to receive serial communication [13]. (d) AXDL456 Library: it helps to calculate the postion of the device at different angles from the ground [51]. 11

20 Software Components This section, enumerate the programming languages and tools that are used to develop E-savior mobile application. That later will be used by the hajj campaign responsible and pilgrims. 1. The Android IDE programming language that is based on JAVA and Xml for programming the application [8]. 2. PHP, SQL are required for connecting with the database [7]. 3. Genymotion is a Android emulator for app developers and testers [6] 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, the result of the interview (See Appendix.B) is that, this prototype will help them to reduce the cost of having a supervisor for each group of pilgrims, monitor their pilgrims easily and 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. 12

21 2.3.3 Schedule Feasibility Schedule feasibility is determined as the probability of a project to be carried out within its scheduled time limits [19]. 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 by dint of a Gantt Chart that is created with Project Management Software (See Fig. 2.6). Figure 2.5: E-Savior work-plan with respect to scrum methodology Figure 2.6: Gantt chart of the E-Savior work-plan 13

22 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 [63]. 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 to buy all sensors and shields of the wearable prototype device. However, this cost does not include cost of our effort to develop the software, hardware components as well as their integration. 2.4 Requirements Gathering Competitor analysis This section discuss some of our competitors and briefly describe the outcome of the competitor analysis. The comparison is done from services view and general view (See. Table 2.6 and 2.7) Pilgrims Bracelet Pilgrims bractlets is given to pilgrims whom going to makkah, it is basically an electronic identification bractlet that holds pilgrims data [4]. Features: Contain the pilgrim identification and medical information; Water-resistant; Connected to GPS for tracking pilgrims; Notify pilgrims on prayer times; Supports several languages for non-arabic speakers Apple Watch Apple Watch is the ultimate smartwatch device for a healthy life style and for runners, athletes and people with disabilities [9]. Features: Sense heart rate, temperature and bloodpressure; Water resistance; Use GPS for running tracking to calculate the distances; 14

23 Figure 2.7: Apple watch product Wirelessly listen to music right from your watch; Measure movement; Reminding any user to keep up with your regimens and routines Alert1 Medical alert system for those who are prone to fall and could not push the alert button in the event of an emergency [3]. Features: Figure 2.8: Alert1 product Microphone, speaker, and a wearable neck pendant; Service support 190 languages; Provide a self-testing unit, which runs checks to ensure everything will work properly during an emergency Life Call Life call is a 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 case of an emergency [33]. Figure 2.9: Lifecall product 15

24 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 [20]. Features: Reminds patient of dosage time; Support fall Detection; Figure 2.10: Better alerts product Contain built in GPS to monitor the patient safe zone; In case of calling the caregiver will be called Lively Lively is a medical alert system consists of Smart Watch, in Home-Hub, and activity sensors, that capture insightful data on behavior patterns [42]. 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. 16

25 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$ 17

26 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 18

27 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, it present the pre-project phase that shows the result of the technical, operational, schedule, and budget feasibility tests. Requirement analysis comes finally to show competitor analysis, a summary of interviews results with cardiologist and campaign responsible, as well as a synthesis of pilgrims survey. 19

28 Chapter 3 System Analysis and Design 3.1 Introduction Scrum development process is driven by requirements. Thus, we describe in this chapter all requirements that are essential to a successful software. We start by enumerating the domain requirements that reflect the characteristics of the application domain such as how to measure the heart rate and blood pressure as well as how to know that such situation is critical. Then, we define statements of services that the system should provide and how the system will react to specific inputs. We conclude the chapter by specifying a set of non-functional requirements that define the constraints on the services offered by E-savior systems. 3.2 Domain Requirements Description The measurement of pilgrims heart rate is done by using photoplethysmograph (PPG) technology [46]. The PPG produces a predictable wave shape [5] 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 [39]. 20

29 Figure 3.1: Algorithm of Reading a pulse [39] Emergency Decision The E-savior wearable prototype device is composed of a ring that pilgrim wears it 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 [41]. 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 30 seconds by the pilgrim, the system will send an emergency alert to the campaign responsible. The following scenario (See Figure 3.2)shows 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, the ring will vibrate for 30 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. Some constraints must be set to take the right decision (See. Table 3.1). Based on the National Institute of Health [16], the ideal range of resting heart rate for adults and seniors ranges between BPM. In the other hand, for well-trained athletes, the average resting heart rate is BPM [17]. However, the normal heart-rate of pilgrims differs from person to person while doing a moderate intense activity that starts from walking 4 mile per hour [29] the heart rate is increasing accordingly. Pilgrims speed will be measured by using an GPS Module that is also used to get the location [27], 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 [17], 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 is: between 70%-90% and during the moderate intense activities, between 21

30 Figure 3.2: Alert Flow Chart 70% - 90%, for that the adopted general guideline from the heart rate [16] association is the average zone between 50% - 85%. 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 Sunstroke Temperature Above 40C 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) the 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 may slow the pulse or raise it [31]. In addition, the decision will be made depending on the pilgrims temperature if any sunstroke happen to them, in case of sunstroke, the temperature will raise to more than 40C [1]. Moreover, the wearable device is also taking the blood pressure measures into consideration, the normal blood pressure for people aged is 120/80 and 22

31 it increases with age. These two numbers systolic and diastolic values are measured by PPG techology [52]. 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. They were validated by three expert doctors who had agree on the guidelines ability to detect emergency and minimize the danger (See Table. 3.1). 3.3 Functional Requirements (Product backlog) The Scrum development process advocates the use of product backlog rather than system sequence and use case diagrams and, 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 [30] 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 desired functionalities for the deliverable product. 23

32 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 Story D As a pilgrim I want to have a way to check my health condition during the day 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 To check my vital signs continually Include Built-In GPS Receive emergency alert Viewing all information through mobile application Measure blood pressure, temperature, heart rate, fall Present the data in an easy and readable way 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 To ensure vital signs stability 24

33 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 activities. The below activity diagram illustrates the activities required for a potential pilgrim to use the wearable device 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 E-savior prototype retrieves the pilgrim medical information from the database; 3. The E-savior prototype Detect fall situation; 4. The E-savior prototype measures the heart rate with heart rate sensor; 5. The E-savior prototype measures the blood pressure with blood pressure sensor; 6. The E-savior prototype measures the temperature with temperature sensor; 7. The E-savior prototype 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 pilgrim location of the pilgrim, heads to the pilgrim place and do the necessary. (b) If there is no emergency detected, E-savior keeps detecting fall situation and measuring the heart rate, blood pressure and temperature. 25

34 Figure 3.3: Workflow of E-Savior prototype System Architecture The system architecture (See Fig.3.4) is composed of two components: hardware and software, both components 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 mobile 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 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 which outline the methods and relationships associated with the system objects. 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 26

35 Figure 3.4: E-Savior System Architecture 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 [56]. 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. 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 the web host to be stored by using WiFi shield (See Fig.3.7) that is 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: 1. 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 calculated by the sum of the satellites captured by the module antennas, satellites number should be more than four for an accurate result [55]. 29

38 Figure 3.8: Ublox-NEO6 GPS Module 2. The pulse sensor (See Fig. 3.9) is provided from PulseSensor.com, the sensor uses ppg technology to measure the heart rate [23]. Figure 3.9: Pulse Sensor 3. Buzzer (See Fig. 3.10) is tiny vibration device that can be connected directly to an Arduino. Figure 3.10: Alarm Buzzer 4. The thermistor sensor (See Fig.3.11) 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.11: Thermistor Sensor 30

39 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 previous figure (See. Fig 3.4), 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 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. 3.4 Non-Functional Requirements The non-functional requirements are different from the functional requirements. They are mainly defined as the system attributes that specify how the system should work [32]. This project described four non-functional requirements and why they important for E-savior system. 1. System reliability that is defined as the capability of a software to maintain its performance overtime [58] 2. System usability that will be attained through user friendly interface design and easy navigation through Android activities. 3. Measures accuracy that ensures the validity of the system outputs. 4. System security will be reached by encrypting the user password using the hash function. These non-functional requirements are important because the system has to be reliable and accurate in order to generate real emergency case and to prevent false alarms. In addition, since this project is relevant to The Ministry Of Hajj, it has to be secured to protect pilgrims personal information. Moreover, the system must be easy and simple, since it is going to be used by different people with different technical skills. 3.5 Conclusion In this chapter, we documented the functional requirements in terms of the user stories that have been gathered in order to start the sprint planning. In addition, we present both the hardware design and the software analysis for each sprint and how to link between them for an effective development model. 31

40 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. Each sprint is clearly defined by giving the description of all tasks to build the sprint release as well as time estimation, then we describe all the hardware and software design for each sprint, followed by the implementation and test. 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 describes the hardware and software components needed in order to fulfill the objective of this project Hardware Components As discussed in chapter 2, the programming languages and libraries that is used in hardware development are Arduino IDE that uses C,C++ and Fritzing to design the prototype. In addition to some libraries that are necessary for the development Software Components As mentioned in chapter 2, the programming languages and tools used to build E-savior mobile application which are: Android IDE that uses Java and Xml to represent the layout and Genymotion to simulate. In addition to the back-end server languages which include php and sql to access the database. 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 system meets its functional and non-functional requirements [36]. In this section we present briefly the techniques used to test the code and to check if the non-functional requirements are respected. 32

41 4.3.1 Code Testing The code unit testing involves the test of Arduino and Android code. From the Arduino side, there is no predefined methods that support the unit testing[36]. It is usually done in different ways depend on the programmer. From the other side, the Android code will be tested using JUnit testing by building the APK on a particular device containing the test required. Then it runs by calling methods and modify fields to automate the interaction of the user, tests are done continuously to reduce bugs and errors [21]. 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 by simulation Non-Functional Requirements Testing Non-Functional Requirements testing is done to ensure validity of the project. As discussed in chapter 3 this project have defined four non-functional requirements which are reliability, usability, security and accuracy. The techniques used in order to check that the project respect them are simulation and comparison. 4.4 Sprint Definition This section presents the definition of sprints. Each sprint must be completed to deliver the final product (See Fig. 4.1). 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 [49]. As mentioned [49], changed the product backlog throughout the project time by adding new requirements and modifying existing once [49]. 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 [2]. 2. Priority rank: In order to start prioritizing, there are four factors to keep in consideration [53]: 1. Uncertainty of the skills required to implement the increment; 2. Reducing the risk associated with implementing the increment; 3. Value returned from implementing the increment; 4. The implemented increment cost. 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. 33

42 Figure 4.1: Sprints Overall Output 34

43 4.5 Sprint Description The first scrum sprint is composed of story C and story A. the sprint release consists on the visualisation of pilgrims longitude and latitude to locate their exact location 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 Develop a mobile interface that let the user register and login 2 2 days 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.2). GPS module pins are described as follow: 1. VCC is basically used to power the module with 5 voltage. 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 35

44 Table 4.2: Sprint1 - GPS and Arduino Pins Wiring GPS module VCC RX TX GND GPS datasheet Arduino UNO PIN5 NA PIN8 GND Figure 4.2: Sprint1 - Hardware Component Design (E-savior GPS) Mobile design 1. We have chosen the model/view/controller as architectural style model to define the software architecture of E-savior mobile application. Figure 4.3 depicts this software architecture to the model package composed of the package GEO-location, which contains Location class that has variables latitude, longitude, time and accuracy. The coordinates are sensed from the GPS sensor, as well as, it contains getlocation() operation in order to compute the coordinates of each pilgrim. The predefined API of Android Google Map is used to visualise the map and the current coordination of pilgrims [25]. Figure 4.3: Sprint1 - Software Design Components 36

45 2. The mobile prototype illustrates how location information are going to be displayed to the campaign responsible through the mobile application (See Fig.4.4). Figure 4.4: Sprint1 - Software Prototype Design Implementation Hardware Development The GPS module developed according to the design sketch done earlier (See Fig.4.2). 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.5a) and then the Arduino Uno fetches that data and process it to extract the latitude and longitude of the pilgrim location (See Fig.4.5b) and stores it in the database to allow E-savior application accessing the data. (a) NMEA. (b) NMEA After Processing. Figure 4.5: Sprint1 - GPS output data 37

46 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.7). The application reads and accesses the data stored by the wearable device that is tighten by the pilgrim so that, the mobile application sends an HTTP request (See Fig. 4.6) 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.6: Sprint1 - Software Abstract Architecture Figure 4.7: Sprint1 - Software Release Testing In this section we, 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 In this sprint, unit testing is conducted for both Arduino and Android application. First, testing the connectivity of the android application to the server by checking the doinbackgroung() method by asserting the result the String URL that inserted (See Fig.4.8). This test is conducted repeatedly for each sprint since all calculations will be held in the hardware components. Next test was conducted on the addmarker() method to check if the function is working properly by inserting fixed float GPS values(see Fig.4.9). 38

47 Figure 4.8: Sprint1 - Connectivity Positive Testing Figure 4.9: Sprint1 - Unit Testing Table 4.3: Sprint1 Unit Testing Cases Test case ID 1 2 Test case description This test case verifies the connectivity method by asserting the result with a correct URL input This test case to verifies the method addmarker() by inserting correct double inputs of GPS location Input data String strurl = 000webhostapp.com /retrieve.php ; double lat= ; double lng= ; Expected result Get Connected Adding marker on Obhur Actual result Pass/ fail Remark Get Connected Pass Positive test Adding marker on Obhur Pass Positive test 39

48 The second unit test is related to the GPS module to check if the output data is correct or not. The output latitude and longitude were taken from the Arduino serial monitor (See Fig. 4.10) 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.11). Figure 4.10: Sprint1 - GPS Serial Monitor (a) Real location on GoogleMaps (b) Inserting GPS Data on GoogleMaps Figure 4.11: Sprint1 - 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 section 4.3.1, the integration testing is done after both Unit testing passes. This test is conducted by far distance simulation where the first party has connected the GPS from Obhur neighborhood to calculate the current location(see Fig.4.12), the second party was having the application running in Alrehab neighborhood to track the first party to check if the addmarker() method presented the coordinated properly (See Fig.4.13). The result shows that components are integrated together and well performed. Figure 4.12: Sprint1 - GPS Serial Monitor The blue marker labeled Nala in Figure 4.13 present the location of the hardware in that time, and the other red markers are all static for the sake of testing the application. Also, the blue circle shows the current location of the mobile application holder. 40

49 Figure 4.13: Sprint1 - Integration Testing Non-Functional Requirement Testing The Reliability is tested through the comparison of 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 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 Another non-functional test was conducted for this sprint that is security test. It was conducted to check the password security when registering or logging in. Hash function is used which is MD5 function. Figure 4.16a shows the function used when user is registering and Figure 4.16b shows the use of it when logging in. Also, figure 4.15 shows the result of the hashed password. Figure 4.15: Encrypted Password 41

50 (a) MD5 On Register (b) MD5 On Log In Figure 4.16: Sprint1 - MD5 Security test 4.6 Sprint Description The second scrum sprint is composed of story D and story B (See Table.4.4). Story D is about 1. measuring the heart rate, blood pressure and temperature, 2. calculating the speed using Arduino sensors and 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 notifying 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 Design electronic circuit Story D 1 4 to measure heart rate, blood pressure, fall detection and temperature Connect the Heart Rate, blood pressure, fall detection and temperature sensor to the Arduino Develop a code to get the heart rate, blood pressure, fall detection and temperature values Story B 1 4 Develop a service that notifies the campaign responsible in case of emergency Tasks Priority Week Effort 1 2 days 2 5 days 3 2 weeks 4 1 week 42

51 Hardware design 1. The Pulse sensor consists of two LEDs that is used to measure heart rate signals. By connecting four pins to the Arduino (See Table.4.5 and Fig.4.17) 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 (LM53) consists of two wires that are used to connect the sensor to Arduino (See Table.4.5 and Fig.4.17). The measure of temperature is done through an analog pin with the help of 10k resistor. 3. The Accelerometer (ADXL345) consists of three wires that are used to connect Arduino (See Table.4.5 and Fig.4.17). Figure 4.17: Sprint2 - Hardware Component Design 43

52 Table 4.5: PPG, Thermistor and Accelerometer sensors and Arduino Pins Pulse Sensor Datasheet Pulse module Arduino UNO SDL A0 GND GND VDD 3V Thermistor Sensor Datasheet Thermistor sensor Arduino UNO R A1 VDD 5V GND GND Accelerometer Sensor Datasheet Accelometer sensor GND VDD SCL SDL Arduino UNO GND 5V A5 A Mobile design 1. The software design class diagram of sprint 2 (See Fig.4.18) is composed of Health Monitoring package that contains Health status class that is a generalized class to get the calculation of heart rate, temperature and blood pressure. An alert will be sent according to the result of the calculation, an it will be shown in the mobile application in the pilgrims vital signs view. Figure 4.18: Sprint2 - Software Design Class Diagram 44

53 2. The mobile prototype illustrates how heart rate,temperature values are going to be displayed to the campaign responsible through the mobile application, and displays alert notification in case of emergency detection. Figure 4.19: Sprint2 - Pilgrim profile GUI Figure 4.19 shows the profile page prototype that is used to know the pilgrim health condition and status 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 Hardware Development The implementation of the hardware is done according to the design sketch (See Fig. 4.17). Connecting the sensor to the Arduino board, Green LED light is used to measure live user s heartbeats and calculation of BPM and IBI will be done. On the other hand the Thermistor sensor is sensing the temperature through touching the human skin. Finally the Accelerometer sensor that detect fall situation (See Fig. 4.20). (a) Heart Rate and Temperature (b) Fall Detection Figure 4.20: Sprint2 - Arduino Serial Monitor 45

54 Software Development The GUI for this sprint is pilgrims details that shows the pilgrims basic data and health data. This is done by linking the hardware measurements with the software components. The linking was done by sending the measured data from the Arduino hardware to the server and then ready and displayed on the E-savior mobile application (See Fig. 4.21). Figure 4.21: Sprint2 - Pilgrim Details GUI Testing In this section we, present the result of all tests conducted including: unit testing, integration testing between both hardware and software, and finally non-functional requirements testing that are related to sprint Integration Testing This test is conducted to check if the data is sent from the Arduino and displayed correctly in the E-savior mobile application. Figure 4.22 shows the measurements on the Arduino and Figure 4.23 shows how it is displayed on the mobile application. The result shows that the hardware and software are well integrated. Figure 4.22: Sprint2 - Integration Test Arduino 46

55 Figure 4.23: Sprint2 - Integration Test Android Non-Functional Requirements Testing In this sprint, we are conducting accuracy test to check wether the data measured from the Arduino sensor is matching with the measurements of a specialized device. For that, we conducted a comparison test between these two components: 1. E-Savior Pulse sensor. 2. OMRON medical home device that is used to measure and track heart rate (See Fig. 4.25). The test was conducted concurrently to check if E-savior pulse sensor gives a convergent result to the medical home device. So the value we got was 74 bpm for OMRON device and 80 bpm for Arduino. Therefore, the threshold of errors is 8 percent.the results of the test shows that the measurements of the E-Savior heart rate are presented accurately (See Fig and Fig. 4.25) Figure 4.24: Sprint2 - Heart Rate from Arduino 47

56 Figure 4.25: Sprint2 - Heart Rate from OMRON 4.7 Sprint Description The third sprint is composed of Story C (See Table.4.6). 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.6: Sprint 3 Backlog Sprint 3 Backlog Story Business Story Prioritfort Tasks Priority Week Ef- Priority Story C 3 8 Aggregate data of emergency cases 1 1 week 2 2 Integrate and 2 2 weeks Test the overall system 2 2 Develop alarm 1 2 days buzzer circuite Hardware design The hardware components of this sprint is the buzzer that will vibrate on the pilgrim side if an emergency occurred (See Fig.4.26). 48

57 Figure 4.26: Sprint3 - Hardware Component Design 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.28) 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.27: Sprint3 - Design Class Diagram 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. 49

58 Figure 4.28: Sprint3 - Alert Management Hardware Development In this sprint, the hardware implementation was done for the buzzer which is used to make the alarm on the pilgrim side. The buzzer is going to be set in case of an emergency the buzzer will vibrate for 30 seconds, if the pilgrim did not turn it off a notification will be sent the responsible Software Development The objective of this sprint is, to generate a notification in case an emergency happen to the pilgrim. The notification is going to be sent the campaign responsible through the E-savior mobile application, then the campaign responsible can check the alert details and navigate to the pilgrim s location (See Fig. 4.29). Figure 4.29: Sprint3 - Alert Management 50

59 4.7.3 Testing In this section, we present the result of all tests that are related to sprint 3, including both unit testing, and integration testing between both hardware and software components Integration Testing In this Sprint, integration testing is conducted to check wether a notification will be sent immediately if an emergency occurred and the pilgrim did not turn the alarm off after the 30 seconds (See Fig.4.30). Figure 4.30: Sprint3 - Integration Testing 4.8 Conclusion The conclusion of this chapter shows that, this project has been implemented with different technologies by following the Scrum framework: sprint by sprint. Connecting the wearable hardware with software to generate an emergency alert, followed by the various types of testing. 51

60 Chapter 5 Conclusion The aim of E-savior is to track pilgrims, monitor their health, reach them in a case of emergency and help them immediately. We started by identifying the problem statement and how to overcome it. Then, we chose Scrum as development process. Before building the system, we conducted the pre-project phase according to four feasibility studies which are technical, operational, schedule and budget feasibility. After that, we gathered the requirements through competitors analysis, and we identified the different situations that lead to the emergency condition. According to scrum methodology, we described the functional requirements in terms of user stories and we defined the system workflow by using an activity diagram. We also defined the system architecture by drawing the domain class diagram for the software components, the hardware components design, and the connection between them. Finally, we give a brief overview of the programming environment and then we define each sprint by giving its description, showing the hardware and software components design, followed by, the implementation and testing of each. 5.1 Challenges and solutions We have faced some challenges during the development of E-savior, starting with our poorly knowledge in such domain. However, we overcome these challenges with hard working and patience. This journey passed working on the project has teach us a lot, we learned how to practice self-learning and integrity in work. The most concern we have faced was dealing with electronic devices which we are not familiar with in the first place. To overcome this obstacle, we took online course, tutorials and searched in electronic books to support our learning process. The second challenge was to develop an android application. Although we are familiar with JAVA language but the android IDE environment and mobile app development in general were the new worries. The third challenge was exploring in a native domain which is the medical domain. We had to read a lot of researches, surfing the internet, and talking to doctors. The last challenge was the ability to speed up the learning process since we have a large quantity of knowledge to learn several new things in such short period of time. To conclude, this experience was something worthy and we figured out that self-learning is the best way to learn. We really hope for everyone to have similar experience as ours and get the most benefit of this short period of their life. 52

61 5.2 Future Plans The continuous development of a project is a mandatory and whenever it stops to be maintained, the project is dead. For that, we are willing to continue supporting this project for its extreme usefulness. We planned to do that by firstly, adding the blood pressure measurements functionality for it is necessity as discussed earlier in the document. Secondly, transforming E-Savior prototype into a real product used by pilgrims. Thirdly, continuous improvement of the application by integrating E-Savior application with The Ministry Of Hajj database to enhance the functionality of the system in importing the pilgrims data from the database directly. Furthermore, we are willing to add more functionalities like measuring the breathing average and making the wearable device waterproof. 53

62 References [1] 3rbdr. sunstrokes and its symptoms. Last visited in October [2] agilefaq.wordpress.com. What is a story point. Last visited in november [3] alert 1.com. Alert1. Last visited in October [4].aljazeera.com. Saudiarabia introduces bracelets hajj safety html, Last visited in October [5] amgalbu. Heart beat detection. 6 heart-beat-detection, Last visited in February [6] Android. Genymotion. Last visited in February [7] Android. How to connect android with php, mysql. Last visited in February [8] Android. The official ide for android. Last visited in February [9] apple.com. Apple watch series. Last visited in October [10] arduino. Arduino ide. Last visited in November [11] Arduino. Arduino libraries. Last visited in November [12] arduino. Arduno programming langues. Last visited in November [13] Arduino. Software serial library. Last visited in November [14] arduino.cc. arduinoboarduno. Last visited in October [15] Arduino.com. Arduino software. Last visited in october [16] American Heart Association. Heart attacks, strokes, heart failure reasons and consequences. Last visited in November

63 [17] American Heart Association. Target heart rates. Last visited in October [18] Steven F. Barrett. Arduino Microcontroller Processing for Everyone. Morgan and Claypool Publishers, [19] By Vangie Beal. What is schedule feasibility. Last visited in october [20] betteralerts.com. Better alerts. Last visited in October [21] Andriod Developers. Getting started with testing. Last visited in october [22] Fritzing. Fritzing. Last visited in November [23] Spark fun. Pulse sensor, Last visited in February [24] gezondheid.infonu.nl. Elektrocardiografie: Meting elektrische activiteit van hart. Last visited in october [25] google. Google map api. Last visited in October [26] KSA Government. Hajj statistics. hajj 1437 ar.pdf, Last visited in November [27] Mikal hart. Arduino wisdom and gems. Last visited in February [28] Mikal hart. Tinygps. Last visited in November [29] harvard school of health. Measuring physical activity. Last visited in October [30] Shane Hastie and Angela Wick. User stories and use cases - don?t use both! Last visited in March [31] American heart association. All about heart rate, Last visited in February [32] Functional requirements vs non functional requirements. Last visited in March [33] ifecall.com. Lifecall. Last visited in October [34] imotions.com. Ecg and ppg sensor s technology. Last visited in October [35] instructables. Led pulse sensor (ppg) for arduino. Last visited in october [36] ISTQB. Fundamentals of testing. Last visited in october

64 [37] 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. [38] lifewire.com. Arduino vs netduino: Which platform is on top? Last visited in october [39] Asral Bahari Jambek Lim Chun Keat and Uda Hashim. Heart-rate monitoring system design and analysis using a nios ii soft-core processor. 62: , [40] mikewcohn. Sprint backlog and the scrum sprint. Last visited in october [41] Joel Murphy and Yury Gitman. pulse sensor algorithim. Last visited in october [42] mylively.com. My lively smatrwatch. Last visited in October [43] netduino.com. arduinoboarduno. Last visited in October [44] World Health Oganization. Top 10 causes of death. Last visited in November [45] IT Knowledge Portal. Software development methodologies. Last visited in November [46] Dan Radigan. Measurment of heart rate using ppg. Last visited in January [47] Dan Radigan. Scrum:a brief look into using the scrum framework for software developement. Last visited in october [48] samsung.com. How to measure heart rate samsung gear. Last visited in October [49] scrum institute.org. The scrum product backlog. Scrum Product Backlog.php, Last visited in October [50] scrumalliance.org. learn about scrum. Last visited in october [51] Philips Semiconductors. Analog devices. Last visited in February [52] HS Oh JS Lee IY Kim SH Song, JS Cho. Estimation of blood pressure using photoplethysmography on the wrist. Last visited in March [53] slideshare.net. Creating a product backlog. Last visited in october

65 [54] sparkfun. Pulse sensor. Last visited in November [55] sparkfun.com. Gps basics. Last visited in December [56] sparkfun.com. What is an arduino? Last visited in December [57] sparkfun.com. arduinoboarduno. Last visited in October [58] Anderw Stellman. Understanding nonfunctional requirements. Last visited in March [59] thebalance.com. How to write an awesome technical feasibility study. Last visited in october [60] valencell.com. Ppg sensor s technology. Last visited in October [61] Stefanie Voortman. Technology is weaving its way into our lives. Last visited in November [62] Chris Walker. Getting Started with Netduino. Make Books - Imprint of: O Reilly Media, Sebastopol, CA, [63] woodleycoles.co.uk. Feasibility studies and budgets. Last visited in october

66 Appendix A Survey A.1 Survey Results 58

67 59

68 60

69 61

70 62

71 63

72 64

73 65