Interactive Real-time Interface for Smart Health ...web-ext.u-aizu.ac.jp/~benab/publications/theses/Achraf-MS-12/m5151161_2012_MS_thesis.pdftos presented a hardware implementation

A thesis submitted in partial satisfaction of the

requirements for the degree of

Master of Computer Science and Engineering

in the Graduate School of the

University of Aizu

Interactive Real-time Interface for

Smart Health Monitoring

and Analysis

by

m5151161

Achraf Ben Ahmed

February 2013

The thesis titled

Interactive Real-time Interface forSmart Health Monitoring

and Analysis

by

m5151161Achraf Ben Ahmed

is reviewed and approved by:

Main referee

Senior Associate Professor Date

Ben Abdallah Abdrazek

Professor Date

Kenichi Kuroda

Senior Associate Professor Date

Song Guo

The University of Aizu

February 2013

Contents

Chapter 1 Introduction and Background 1

1.1 Application Specific Multicore SoC . . . . . . . . . . . . . . . . . . 1

1.2 Elderly Monitoring Methods . . . . . . . . . . . . . . . . . . . . . . 5

1.2.1 12 Leads System . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2.2 Holter Based Systems . . . . . . . . . . . . . . . . . . . . . 6

1.2.3 Wearable Health Monitoring Systems Based . . . . . . . . . 8

1.2.4 ECG Management System . . . . . . . . . . . . . . . . . . . 10

1.3 Problems and Motivation . . . . . . . . . . . . . . . . . . . . . . . . 11

1.4 Thesis Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Chapter 2 BANSMOM: Heterogeneous Embedded MCSoC for Application

Specific Domain 14

2.1 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1.1 Multicore SoC Architecture . . . . . . . . . . . . . . . . . . 14

2.1.2 Signal reading . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1.3 Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1.4 Data Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2 Period Peak ECG Detection Algorithm . . . . . . . . . . . . . . . . . 17

iii

2.2.1 Period Detection . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2.2 Peaks Detection . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3 Data Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Chapter 3 Real Time Interactive Interface 24

3.1 Monitoring Platform Main Stages . . . . . . . . . . . . . . . . . . . 24

3.2 Data Acquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.3 Data Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.3.1 Data Base Structure . . . . . . . . . . . . . . . . . . . . . . . 26

3.3.2 Data Base Maintain . . . . . . . . . . . . . . . . . . . . . . . 28

3.4 Data Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.4.1 IRTI Access Management . . . . . . . . . . . . . . . . . . . 30

3.4.2 Data Display . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.4.3 ECG Data Format . . . . . . . . . . . . . . . . . . . . . . . 34

3.4.4 ECG Database Analysis . . . . . . . . . . . . . . . . . . . . 36

Chapter 4 Evaluation 38

4.1 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2 Test-Driven Development . . . . . . . . . . . . . . . . . . . . . . . . 38

4.3 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.3.1 Real-Time Visualization . . . . . . . . . . . . . . . . . . . . 40

4.3.2 Security and Vulnerability Issues . . . . . . . . . . . . . . . 43

4.3.3 Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.3.4 User Friendly . . . . . . . . . . . . . . . . . . . . . . . . . . 45

iv

Chapter 5 Conclusion and Future Work 49

Appendix A Models 53

Appendix B Views 57

Appendix C Controller 70

Appendix D Database 75

v

List of Figures

Figure 1.1 Standard ECG Diagram . . . . . . . . . . . . . . . . . . . . . 6

Figure 1.2 ECG monitoring flow with the Holter monitor. . . . . . . . . . 7

Figure 1.3 Wireless Body Area Network of Intelligent Sensors for Ambu-

latory Health Monitoring. [10] . . . . . . . . . . . . . . . . . . . . . 9

Figure 2.1 BANSMOM System Architecture. . . . . . . . . . . . . . . . 14

Figure 2.2 PPD Algorithm Find Maximum Values Phase. . . . . . . . . . 18

Figure 2.3 PPD Algorithm Reduce negatives values Phase. . . . . . . . . 19

Figure 2.4 PPD Algorithm Peak Detection From ACF Result Phase. . . . 20

Figure 2.5 PPD Algorithm Find Base Points Phase. . . . . . . . . . . . . 21

Figure 2.6 PPD Algorithm Sort Base points Phase. . . . . . . . . . . . . 22

Figure 2.7 PPD Algorithm Find Interval Phase. . . . . . . . . . . . . . . 22

Figure 2.8 BANSMOM running on DSP FPGA Stratix III. . . . . . . . . 23

Figure 2.9 12 leads ECG graph. . . . . . . . . . . . . . . . . . . . . . . . 23

Figure 3.1 Monitoring Platform Main Stages. . . . . . . . . . . . . . . . 25

27

Figure 3.3 Database EER model. . . . . . . . . . . . . . . . . . . . . . . 29

Figure 3.4 Database update management. . . . . . . . . . . . . . . . . . 30

vi

Figure 3.5 IRTI access. . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Figure 3.6 IRTI peak display process. . . . . . . . . . . . . . . . . . . . 32

Figure 3.7 Buffer insertion mechanism in the Database level. . . . . . . . 35

Figure 3.8 12 leads data format. . . . . . . . . . . . . . . . . . . . . . . 36

Figure 3.9 Heart rate and rhythm analysis. . . . . . . . . . . . . . . . . . 37

Figure 4.1 Live visualization mode after database update. . . . . . . . . . 41

Figure 4.2 Security and Vulnerability rapport. . . . . . . . . . . . . . . . 44

Figure 4.3 IRTI login page. . . . . . . . . . . . . . . . . . . . . . . . . . 46

Figure 4.4 IRTI nodes list. . . . . . . . . . . . . . . . . . . . . . . . . . 47

Figure 4.5 IRTI old records view . . . . . . . . . . . . . . . . . . . . . . 48

vii

List of Tables

Table 4.1 IRTI code complexity. . . . . . . . . . . . . . . . . . . . . . . 45

viii

Acknowledgement

I want to express my thanks and gratitude to Dr. Ben Abdallah Abderazek for his

support, encouragement and his efforts and guidance to achieve this project. Also I

would like to thank both of Dr. Kenichi Kuroda and Dr. Song Guo of University of

Aizu for taking the time to revise my thesis. Moreover, my sincere gratitude to Dr.

Kenichi Kuroda, Dr. Yuichi Okuyama, and Dr. Junji Kitamichi for their help and

support during the past two years.

Finally, I want to thank all the members of the Adaptive Systems Laboratory at the

University of Aizu, my friends and family. Their supportive words and encouraging

messages kept me motivated to work harder and be a better researcher and person .

ix

Abstract

Recent technological advances in sensors, low-power microelectronics, and wire-

less networking enabled the development of single-chip solutions for computationally-

intensive biomedical applications with potential health benefits for a large number of

individuals.

One important application, in this respect, is the real-time remote and accurate

analysis of human heart activity, which has always been a challenging problem for

biomedical engineers. Despite the decreased mortality rate, heart disorders (like Car-

diovascular Disease) are one of the main causes of death around the world. As a result,

detection of irregularities in the rhythms of the heart is a growing concern in medical

research. In addition to the detection, the collection and the visualization process for

such kind of data is crucial due to the huge amount of data that produce an electrocar-

diogram especially when the records are made for a long time. Another concern is the

real time monitoring and the capability to monitor and analyze the produced data at

real time.

In this thesis, an interactive real-time (IRT) interface, integrated with a multi-lead

period-peak detection (PPD) algorithm for ECG processing, has been designed to over-

come the limitations of existing ECG monitoring systems.

The evaluation results show that our proposed monitoring platform is characterized

to be scalable by the capability to handle huge data coming from many nodes at the

same time. Moreover, the interface was built following the MVC pattern (Models-

Views-Controllers) and using a SSL protocol (Secure -Sockets-Layer) for the data ex-

change, which made our interface secure and the data privacy of the nodes is ensured.

The simulation shows also that the real time monitoring can be ensured by our tool

which contains a live visualization mode which is activated as soon as there is new

incoming data.

xi

xii

Chapter 1

Introduction and Background

1.1 Application Specific Multicore SoC

Digital signal processing has been with us for decades now with some astronom-

ical development in the area over the years. The world of science and engineering is

filled with signals: images from remote space probes, voltages generated by the heart

and brain, radar and sonar echoes, seismic vibrations, and countless other applications.

Digital Signal Processing is the science of using computers to understand these types

of data. This includes a wide variety of goals: filtering, speech recognition, image

enhancement, data compression, neural networks, and much more. DSP is one of the

most powerful technologies that will shape science and engineering in the twenty-first

century. DSP, or Digital Signal Processing, as the term suggests, is the processing

of signals by digital means. A signal in this context can mean a number of different

things. Historically the origins of signal processing are in electrical engineering, and

a signal here means an electrical signal carried by a wire or telephone line, or perhaps

by a radio wave. More generally, however, a signal is a stream of information repre-

senting anything from stock prices to data from a remote-sensing satellite. A digital

signal consists of a stream of numbers, usually (but not necessarily) in binary format.

1

The processing of a digital signal is done by performing numerical calculations. One

of the important factors that enhanced DSP performance is the evolution of the pro-

cessor architecture. As the computing needs of each processor type grew rapidly, the

first response of the computer architects and semiconductor companies was to increase

the speed of the single processor. Higher performance was mainly achieved by refin-

ing manufacturing processes to improve the operating speed. However, this method

requires finding solutions for increased leakage power and other problems, making it

unable to keep pace with the current rate of evolution.

After several decades of single processor core devices production, major CPU mak-

ers, such as Intel and AMD, decided to switch to multicore processor chips because it

was found that several smaller processor cores running at a lower frequency can per-

form the same amount of work without consuming as much energy and power. More

precisely, this shift started when Intel’s hardware engineers launched the Pentium 4; at

that time, they expected single processor chip to scale up to 10 GHz or even more us-

ing advanced process technologies below 90 nm. However, they did not really achieve

their expectation since the fastest processor never exceeded 4 GHz. As a result, the

trends followed by all major hardware makers is to use a higher number of slower logic

gates, building parallel devices made with denser chips that work at low clock speed.

One of the areas that takes advantage from the evolution of the processor architecture

and digital signals processing is the embedded systems targeted for health monitoring.

Such systems require small devices capable to process a bio-medical data at real time

and with the minimum energy use. Many micro-watt power processors have been pro-

posed to improve the processing efficiency for the possible application to Bio Signal

2

Processing. The first group is the general purposed processor. They have developed

for low power operation. Yet, they still require the long operating time, which is the

important factor of the energy consumption. Thus, the application specific processor

rather than general purpose processor has been developed. Even though it consumes

more power than the general purposed processors, the operating time can be reduced

remarkably due to the dedicated hardware and instructions. Thus, if the application is

clearly defined such as the Bio Signal Processing, it becomes very attractive to improve

the energy efficiency.

Recently, with the increase of the interests in the healthcare, the need for the am-

bulatory arrhythmia monitoring system has been rising exponentially. The monitoring

system records ECG signal continuously in ambulatory condition for a sizable time like

several hours. The system transmits the record data to the user or the healthcare center

like hospital when the alert ECG signal is detected or the recording period is finished.

In order to monitor and analyze the ECG signal, the functions operated at the clini-

cal instrument such as signal sensing and the classification should be integrated into

the light-weight, ambulatory monitoring system. The most important requirements for

the ambulatory monitoring system are ultra low energy operation for the long battery

life time and a small footprint for wearability. In general, since the highest energy

consuming parts are the memory transaction blocks and the wireless communication

blocks than the processing block, the data processing as much as possible before trans-

mission is the most efficient method to reduce the total system energy consumption.

However, the development of such systems faces several challenging tasks since they

need to often address conflicting requirements for performance, size, and accuracy.

3

In addition, Electrocardiography (ECG) may face many computational challenges, es-

pecially when 12 or more lead signals should be analyzed in parallel, at real-time,

and under high sampling frequencies. A number of recent research efforts focus on

hardware implementations and the real time visualization of the ECG signals Chris-

tos presented a hardware implementation of the Pan and Tompkins QRS detection

algorithm [1]. The system achieved a speed up of 250% compared to the software im-

plementation. Yutana Jewajinda presented an FPGA-based Online-learning for ECG

Signal Classification [2], where the complete ECG signal classification can be imple-

mented in hardware. Another challenge is the analysis of huge amounts of data that

may grow depending on the recording range time and also the Visualization outputs of

such systems on an environment that can be consulted at real time. Recent techniques

deployed for monitoring heart activity is the 12-leads ECG which uses data coming

from twelve ECG leads serially. The leads produce huge amounts of data, especially

when used for a long number of hours. The monitoring part is also crucial for the real

time diagnosis. This importance came from the fact that in order to make clinical stud-

ies or heart diseases diagnosis, researchers and doctors are required to be in immediate

proximity to patients which is not always practical. Traditionally, personal medical

monitoring systems, such as ambulatory electrocardiography devices [3], have been

used to record data. Data processing and analysis are performed off-line, making such

devices impractical for continual monitoring and early detection of medical disorders,

especially for patients needing immediate medical interventions.

A lot of research have been conducted to perform the transfer and the diagnosis of the

ECG signals at real time, Farah Magrabi et al [4] presented a Web Based Longitudinal

4

ECG Monitoring, Jun Dong et al [5] presented A Remote Diagnosis Service Platform

for Wearable ECG Monitors where they present a patient location independent and

continuous ECG monitoring and diagnosis system.

1.2 Elderly Monitoring Methods

Despite the decreased mortality rate, heart diseases and their associated complica-

tions are one of the main causes of death around the world. As a result, detection of ir-

regularities in the rhythms of the heart is a growing concern in medical research.Before

presenting the existing methods used to perform an ECG monitoring, let us review the

12 leads system, which is the most used approach in ECG diagnosis.

1.2.1 12 Leads System

The standard electrocardiogram is a representation of the heart’s electrical activity

recorded from electrodes on the body surface. This section describes the basic com-

ponents of the ECG and the standard lead system used to record the ECG tracings.

Figure 1.1 shows an ECG waves and intervals as well as standard time and voltage

measures on the ECG paper. One of the most known techniques used for the heart

activity monitoring is the 12 Lead system.This systems use only 9 sensors distributed

in specifics places on the Human body to show a spatial information of the heart’s

electrical activity .Those 9 leads are (i) three points on the limbs labeled as RA, LA,

LL, and (ii) six points on the chest labeled as V1,V2, V3, V4, V5, and V6. The inter-

connection of those 9 sensors give a 12 signals, known in biomedical terms as: Lead

I, Lead II, Lead III, aVR, aVL, aVF,V1, V2, V3, V4, V5, and V6. The most important

5

points for the ECG signal are the peaks: P, Q, R, S, T, and U. Each peak is related to

an important heart action in the medical analysis. Many ECG analysis methods use

the three peaks Q, R, S and the corresponding intervals between these three peaks. In

biomedical terms, this interval from Q to R to S is known as the QRS complex [6, 7].

The well known QRS Pan-Tompkins algorithm locates R-peaks in the ECG signal and

calculates the heart period [8].

Figure 1.1: Standard ECG Diagram

1.2.2 Holter Based Systems

In medicine, a Holter monitor (often simply ”Holter” or occasionally ambulatory

electrocardiography device) is a portable device for continuously monitoring various

electrical activity of the cardiovascular system for at least 24 hours. Its extended

recording period is sometimes useful for observing occasional cardiac arrhythmia or

epileptic events which would be difficult to identify in a shorter period of time. For

patients having more transient symptoms, a cardiac event monitor which can be worn

for a month or more can be used.

The Holter monitor is named upon the physicist Norman J. Holter who invented

6

telemetric cardiac monitoring in 1949 [9]. When used for the heart, much like stan-

dard electrocardiography, the Holter monitor records electrical signals from the heart

via a series of electrodes attached to the chest. Electrodes are placed over bones to min-

imize artifacts from muscular activity. The number and position of electrodes varies

by model, but most Holter monitors employ between three and eight. These electrodes

are connected to a small piece of equipment that is attached to the patient’s belt or hung

around the neck, and is responsible for keeping a log of the heart’s electrical activity

throughout the recording period. These electrodes wires may limit the patient’s activ-

ity and level of comfort and thus negatively influence the measured results. Figure 1.2

shows the processing flow of the Holter device.

Figure 1.2: ECG monitoring flow with the Holter monitor.

7

1.2.3 Wearable Health Monitoring Systems Based

Wearable Health Monitoring Systems (WHMS) are novel information technology

that will be able to support early detection of abnormal conditions and prevention of

its serious consequences. Many patients can benefit from continuous ambulatory mon-

itoring as a part of a diagnostic procedure, optimal maintenance of a chronic condition

or during supervised recovery from an acute event or surgical procedure. Figure1.3

shows a general overview of a WHMS; the lowest level encompasses a set of intel-

ligent physiological sensors; the second level is the personal server (Internet enabled

PDA, cell-phone, or home computer); and the third level encompasses a network of

remote health care servers and related services (Caregiver, Physician, Clinic, Emer-

gency, Weather). Each level represents a fairly complex subsystem with a local hierar-

chy employed to ensure efficiency, portability, security, and reduced cost. The personal

server, running on a PDA or a 3G cell phone, provides the human-computer interface

and communicates with the remote server(s).

The well known scenario where Body Sensors Network (BSNs) are used is for the

elderly monitoring. With the number of elderly people in industrialized nations is set to

increase in average life expectancy [11]. Identifying the ways of monitoring those peo-

ples became very important because elderly patients are at increased risk of requiring

hospital admission or intervention and high risk of vulnerability [12] [13]. This vul-

nerability came from the fact that they are not able to seek medical help early enough

for simple and treatable conditions,which eventually may lead to significant increase

in the mortality rate. When correlated with physiological vital signs measurement, this

system has the potential to clearly identify those most at risk. It is also demonstrates

8

Figure 1.3: Wireless Body Area Network of Intelligent Sensors for AmbulatoryHealth Monitoring. [10]

an instance in which a wireless sensors network (WSN), set up in the patients home,

and a BSN (on the patients body) may overlap in their applications. Therefore, that

monitoring elderly patients in their home environment will allow earlier detection of

any deterioration in their condition, for which prompt treatment may reduce the need

for hospital admission, associated morbidity and even mortality. The concept of an

home sensor network to monitor an elderly persons social health and giving feedback

not only to that persons carers, but also to the elderly individual themselves, is one

that is being developed by several companies such as Intel [14] [15]. Many health-care

institutes and research organizations proposed a WHMS targeted for the ECG signals.

U. Anliker et al proposed a high-risk cardiac- respiratory patients [16] with the wireless

2.4 radio wave and GPRS as communication modules. M. Di Rienzo et al proposed

a recording of cardio-respiratory and motion signals during spontaneous behavior in

daily life and in clinical environment [17] the system consists of a vest with textile sen-

9

sors connected by Bluetooth to a PDA. WSN U-Healthcare system proposed a health

monitor and remote identification of suspicious health patterns for further evaluation

by physicians [18], [19]. European Union IST program proposed a general health

monitoring measuring the ECG signals [20], [21] the system consists of garment with

knitted dry electrodes and a PDA.

1.2.4 ECG Management System

In addition to the processing of the ECG signals, the management which consists

of the visualization and the analysis of the obtained records has became a growing

concern in medical research. Many famous private research organizations proposed a

whole ECG management system, which is compatible with many ECG sensors ven-

dors. Those systems take in charge the collection, the visualization and the diagnosis of

the ECG wave form. One of the most known is the one proposed by Philips health care

branch [22] which is an ECG Management System (EMS) that includes, in addition

to the visualization and diagnosis capabilities, their own relational database manage-

ment systems [23] where Structured Query Language (SQL) server is the core in this

system. The Philips EMS database is composed of normalized tables containing pa-

tient demographics, digital ECG waveforms, measurements and ECG interpretation.

Essentially, most ECG data are exposed via individual columns in relational tables.

This design enables the use of simple data to advanced SQL queries for information

retrieval [24]. In the academics area many ECG management systems were proposed,

Trigo et al. [25] proposed a solution to standardize the ECG format for End-to-End

exchange and homogeneous management. They tried the normalization of integrated,

standardized healthcare information systems and finding an appropriate combination

10

of ECG formats that enables standardized exchange and homogeneous management of

ECG formats. Shizhong et al [26] proposed a meta-data registry to facilitate the search

and retrieval of electrocardiograms and demonstrating a useful framework for ECG

sharing through the Internet.

1.3 Problems and Motivation

Multicore systems are becoming a common design alternative in portable devices

because it is possible to manufacture a silicon chip including only necessary elements.

Certain medical applications require devices capable of providing very accurate in-

formation about monitored patients in places where complex clinical systems are not

available and where also parameters such as electrocardiogram (ECG) characteristics

are important to be determined.

Starting from the need of such hardware capable to satisfy the grow demand in health

monitoring especially for the ECG monitoring in our case, the collection, visualization

and diagnosis of the output of such systems should follow the enhancement of the pro-

cessing part. Thus, the real time processing in bio-medical sensors become senseless

if there are no tools capable to collect and visualize the obtained data at real time.

Whatever the system is based upon, web applications or PDAs, the visualization part

should be capable to deal with the obtained data. Especially in our case, where the

ECG data may be recorded for a long time, and for some cases the real time monitor-

ing became a must (ie. people suffer from myocardial infraction) where the interven-

tion should me made in few minutes, otherwise the patient will die. The ideal practice

in ECG monitoring is where we have the capabilities to get the 12 leads records in

parallel and visualize them in real time. But, such practices need a monitoring plat-

11

form capable to receive this huge amount of data, as much as possible, in parallel from

different nodes and at real time. However, conventional monitoring approaches are

impractical since patients and research facilities are often geographically distributed.

The existing methods of ECG monitoring are characterized by a manually-intensive

work flow for data acquisition, formatting and visualization. Besides, they are most

often relying on multiple serial processes and several software packages (ie. Holter

monitor). All these reasons make ECG monitoring requiring a robust system for the

collection, visualization, and analysis of ECG signals capable to deal with the huge

amount of data produced by the ECG records. Previously, in our research group, we

proposed a In-Body Wireless Sensor Network System for Elderly Monitoring (BANS-

MOM) which is a multicore architecture where a period peak detection algorithm run

on it, with the capability to process 12 leads on parallel. The proposed system suffer

from a lack of monitoring and the outputs are displayed only on the DSP FPGA screen,

which is not suitable for accurate diagnosis. The obtained ECG data are illustrated by

the coordinates of each peak, with the processing time and the corresponding value.

Starting from all these facts, the main motivation of this work is to propose an Interac-

tive Real Time Interface (IRTI) for smart health monitoring targeted for ECG signals.

The proposed interface use BANSMOM outputs as input, which are the data of 12

leads processed in parallel. As a result, the initially peaks coordinates will be dis-

played as wave form, which perform the suitable diagnosis that we want to perform in

our BANSMOM system. In addition, our tools will be capable of handling real time

data by displaying them as soon as they are processed by BANSMOM system. In this

thesis, we present a complete architecture and design of the IRTI in a fair amount of

12

details. Evaluation results are also presented. We provide more details about the differ-

ent components of the IRTI including our proposed real time visualization capability.

We show how our interface can display a real time data as soon as the are proceed by

our BANSMOM platform.

1.4 Thesis Organization

The rest of this dissertation is organized as follows: In Chapter 2, we present

BANSMOM system overview. Chapter 3 presents the Real time interactive interface.

Chapter 4 is dedicated to the evaluation methodology and results. Finally, we end the

thesis with concluding remarks and future works in Chapter 5.

13

Chapter 2

BANSMOM: HeterogeneousEmbedded MCSoC for ApplicationSpecific Domain

2.1 System Architecture

2.1.1 Multicore SoC Architecture

Figure 2.1 shows the BANSMOM system architecture. Signal processing is per-

formed in four major phases: (1) signal reading, (2) filtering, (3) analysis, and (4)

display.

Figure 2.1: BANSMOM System Architecture.

14

2.1.2 Signal reading

The number of the data inputs from the sensors is extensible to 15 or more. The

size of data is included in data read from the sensors. Analog Digital Converter (ADC)

converts analog data into a digital one. So a contiguous ECG signal is converted into

a discrete ECG signal. As a result, filter processing and analysis processing can easily

be done.

2.1.3 Filtering

Noise filtering uses a bandpass filter that is based on the Finite Impulse Response

(FIR) filter. The bandpass filter reduces the influence of muscle noise, 50 Hz inter-

ference, baseline wander, and T-wave interference. Digital filters process digitized or

sampled signals. A digital filter computes a quantized time-domain representation of

the convolution of the sampled input time function and a representation of the weight-

ing function of the filter. They are realized by an extended sequence of multiplications

and additions carried out at a uniformly spaced sample interval. The digitized input

signal is mathematically influenced by the DSP program. These signals are passed

through structures that shift the clocked data into summers (adders), delay blocks and

multipliers. These structures change the mathematical values in a predetermined way:

the resulting data represents the filtered or transformed signal.

Digital filters are very important parts of DSP. They have two uses: signal sep-

aration and signal restoration. Signal separation is needed when a signal has been

contaminated with interference, noise, or other signals. For instance, a device for mea-

suring the electrical activity of a baby’s heart (EKG) while still in the womb. The raw

signal will likely be corrupted by the breathing and heartbeat of the mother. A filter

15

might be used to separate these signals so that they can be individually analyzed. Sig-

nal restoration is used when a signal has been distorted in some way. For example,

an audio recording made with poor equipment may be filtered to better represent the

sound as it actually occurred.

Finite Impulse Response (FIR) filter is a basic type of digital filter. FIR filters

have no non-zero feedback coefficient in the general form of the digital filter difference

equation. That is, the filter has only zeros, and once it has been excited with an impulse,

the output is present for only a finite N number of computational cycles. The FIR filter

uses noise rejection and waveform extraction for the ECG algorithm. The data from

analog/digital converter is finite and is a discrete digital signal; therefore, our system

uses FIR filter. This filter is popular among liner digital filters and the most safety

in another filter within finite data. The FIR filter is composed of three parts: delay

element, multiplier, and adder. The following equation is the difference equation for

FIR filter that is defined by the relationship between the input signal and the output

signal.

y[n] = a0xn + a1xn−1 + · · ·+ aNxn−N (2.1)

=N∑i=0

aixn−i (2.2)

N is the filter’s order that corresponds to the number of taps. xn are current or previ-

ous filter’s inputs. y[n] is the current filter output. ai are the filters’ coefficients that

correspond to the impulse response. A FIR filter works by multiplying an array of the

most recent n data samples by an array of constants, and summing the elements of the

resulting array. The filter then inputs another sample of data and repeats the process.

16

2.1.4 Data Analysis

Correlation is calculated between the acquired segment and a pattern which has

been previously obtained. For each analyzed patient, the pattern segment is assumed

to contain regular ECG signals where a signal’s QRS complex is contained so that any

further ECG pulses can be correlated with it. High correlation values correspond to the

pulse detection. Pattern extraction is performed by the main processor. Once obtained,

it is transferred and stored to the off-chip memory. The off-chip memory starts to re-

ceive data samples directly from the ADC. Data samples are stored in a Queue (FIFO).

The correlation pattern is calculated, and the pulse alignment is evaluated. When the

input signals in the Queue are aligned with the pattern, a high correlation value will be

obtained, and a signal indicating the presence of a new pulse is generated.

2.2 Period Peak ECG Detection Algorithm

The Period-Peak-Detection Algorithm [27] detects first the period and then looks

for all peaks. We detect first the period before finding peaks because there is a high

degree of randomness in the ECG signals. The randomness makes finding peaks an

erroneous process. What we would get by doing this is the level of correlation that

these signals have. Our PPD algorithm computes the required parameters: heart period,

typical peaks (P, Q, R, S, T, and U), and inter-peak time spans (R-R interval). Peak

height and inter-peak time ranging outside normal values, indicating different kinds

of diseases, are detected with our algorithm. The algorithm consists of two execution

flows: one finds the period using the auto-correlation function, and the other one finds

the number, amplitude and time interval of the peaks.

17

2.2.1 Period Detection

Our PPD algorithm consists of 4 phases: (1) Data reading, (2) Derivation, (3) Auto-

correlation, and (4) Find intervals. Those phases are illustrated in Figures 2.2, 2.3, 2.4,

2.5, 2.6, 2.7.

Figure 2.2: PPD Algorithm Find Maximum Values Phase.

The derivation phase finds the discrete derivative of the ECG signal. The deriva-

tive function is the best function we can run that can aid in amplifying signal peaks.

Therefore, after reading the data from the signal y with samples from memory, a very

helpful step is to calculate the derivative of the signal y(t). The following equation is

the derivative function used by this algorithm:

∂y

∂t(t) ≈ y[n+ 1]− y[n]

(n+ 1)− n= y[n+ 1]− y[n] (2.3)

With this derivative, a peak will be amplified relatively to the samples before it. If the

values of y[n] and y[n+ 1] are close to each others (i.e. no peaks), then the difference

18

Figure 2.3: PPD Algorithm Reduce negatives values Phase.

will look relatively small on the new derivative graph. The advantage of taking the

derivative is that the fluctuations taking place in the signal, especially those around

the peaks, would be reduced to a near-zero-value. In addition, performance overhead

associated with derivative calculation of the ECG signal is negligible compared to the

rest of the algorithm.

The autocorrelation phase finds the period of ECG signals. This phase uses auto-

correlation function (ACF). The ACF, whose function is shown in (2.4), is a statistical

method used to measure the degree of association between values in a single series

separated by some lags. The fixed length of ACF is defined by (2.5). By running the

ACF on the function y over the recorded data sample, we can get the coefficients of

the ACF. The following equation is the used auto-correlation function:

Ry[k] =n=∞∑n=−∞

y[n]× y[n− k] (2.4)

Ry[L] =N∑

n=0

y[n]× y[n− L] (2.5)

19

where Ry is the auto-correlation function, y[n] is the filtered ECG signal. L is a pos-

itive natural number related to the number of times needed for the calculations to get

the period. It is the same as the number of lags of the auto-correlation. Finally, the

find interval phase finds interval point in ECG signals based on results of the auto-

correlation phase.

Figure 2.4: PPD Algorithm Peak Detection From ACF Result Phase.

2.2.2 Peaks Detection

The peaks detection phase consists of 3 main phases: Extraction, Discrimination

and Store-results. The extraction phase discriminates significant peaks from calculated

interval information in period detection flow. The discrimination phase finds 6 peak

points (P, Q, R, S, T and U) from the extracted peaks [28, 29]. Finally, the Store-results

phase stores interval and peak information in a buffer that is reused for calculations

period detection.

20

Figure 2.5: PPD Algorithm Find Base Points Phase.

2.3 Data Display

External monitor outputs the analyzed results. The output data are peaks of each

typical wave (P, Q, R, S and T), heart rate and entire waveform. While running the

system, the external monitor outputs the results at real-time. Figure2.8 shows the out-

puts of BANMSOM system running in DSP FPGA Stratix III. As can be seen from this

picture, there is no additional information concerning the node being processed such as

node location or the real recording time or even the name and other useful information

to perform better diagnosis.

Comparing with the real ECG graph shown in fig. 2.9 , the existing BANSMOM out-

puts seem to be non suitable for conventional diagnosis where the ECG should be rep-

resented in wave form instead of numbers format. Starting from this fact, we present

a novel monitoring platform, named Interactive Real Time Interface(IRTI), which is

capable to handle BANSMOM outputs and display them in wave form at real time. In

the coming chapters the IRTI will be explained in a fair amount of details.

21

Figure 2.6: PPD Algorithm Sort Base points Phase.

Figure 2.7: PPD Algorithm Find Interval Phase.

22

Figure 2.8: BANSMOM running on DSP FPGA Stratix III.

Figure 2.9: 12 leads ECG graph.

23

Chapter 3

Real Time Interactive Interface

We build our visualization tool as web-based application, recent technologies in

web design were used to get better performance. The interface was build following the

MVC pattern (Models-Views-Controllers) [30] and as test driven development (TDD)

processes the interface was tested by Agile software development [31] which software

development methods based on iterative and incremental development. In this chap-

ter we give details about the implementation of our proposed interface while in next

chapter we evaluate our tools based on the MVC pattern and Agile testing process.

3.1 Monitoring Platform Main Stages

In Fig. 3.1 the main phases of the proposed interface are shown, which are the data

capturing phase from BANSMOM system. The captured data are the typical peaks in

the ECG wave form. Next, the data will be stored for each node in the corresponding

database table and ordered by capture time. In the next stage, the data will be processed

by the web server in response to request of the user of the interface. And finally the

visualization step, where the peaks are displayed. In the following sections we give

more details about the implementation of the mentioned phases.

24

nod

e 2

n

ode

1

node

n

Rem

ote

Server

Supe

rvis

er S

ide

BA

NSM

OM

Pla

tfor

m

Hos

t Pc

UA

RT

Zig

bee

Blu

etoo

thW

ifi3G

TC

P/IP

Inte

ract

ive

Rea

l Tim

e In

terf

ace

Sup

2

Sup

1

Sup

n

PH

PM

YS

QL

SSL

SS

L

SSL

Figure 3.1: Monitoring Platform Main Stages.

25

3.2 Data Acquisition

The multiprocessor characterization of BANSMOM system allows us to obtain

the result of different leads in parallel and at real-time. The output data are peaks of

each typical wave (P, Q, R, S and T). While running the system, the external moni-

tor outputs the results at real-time. Figure 3.2 shows a part of the obtained outputs

while running the system. This figure shows the outputs of the lead aVF for node

number 1 (Lead1 aVF). We used a sample data from MIT-BIH Normal Sinus Rhythm

Database No.16265 from PhysioBank. The start time of the processing is [2012-12-

01 06:00:00.000]. The processing is divided in range, and each range contains the P,

Q, R, S, T, U peaks with the names respectively PPP, QPP, RPP, SPP, TPP, UPP. Ev-

ery peaks has as parameters the time in milliseconds and the value in millivolts. The

obtained data will be stored and classified by the date of the processing time so the

corresponding table for the node will contain a successive of P, Q, R, S, T, U peaks.

3.3 Data Storage

3.3.1 Data Base Structure

We design the database that will contain our static and dynamic data as follows:

one table named node were we store a list of nodes classified by id number, one table

for the historic of the node containing the date of the intervention and the type of

the intervention, one table for the information related to the node (demographic and

clinical information) and finally the three main tables dedicated to the dynamic data

coming from BANSMOM systems which are the leads table, the information leads and

the last point table used as reference to display the peaks in order. For design purposes

26

Figure 3.2: BANSMOM outputs with a sample from MIT-BIHNormal Sinus Rhythm Database

No.16265 from PhysioBank.

27

we choose to separate these three tables.

The output of our processing part is the coordinates of each peak for each corre-

sponding node. To continue on the same way of mobility, the processing data coming

from DSP are transmitted to the database through the Internet and the correspond-

ing table in MySQL will be updated automatically. The incoming data is stored in a

dedicated table in the database. Each node has its own tables for static data such as

node history, demographic information and clinical information and for incoming ECG

peaks wave which are stored separately and classified by capture date. This classifica-

tion allows the supervisor to visualize any specific data at any desired date. Figure 3.3

illustrates the enhanced entity relationship diagram (EER) [32] for the used database.

For the complete description please see Appendix D.

This diagram is a basic object model that outlines our primary data entities, their

respective attributes, and some of the relationships between them. A node can be asso-

ciated with one or more leads (12 leads in our case), historic, responsible, information

node and information lead(leads data). Similarly, a responsible can be associated to

one or many nodes.

3.3.2 Data Base Maintain

To avoid any conflict or data base overflow we assign each node to a specific re-

sponsible or a group of responsible. Next, the data are received, ordered by time and

classified also by lead number. As illustrated in Fig. 3.4, after receiving a data we

check if the database is free. If so, the data is stored, otherwise we need to delete some

previous data. In order to do this, we check for the abnormality in the last 3 days, if

data is normal we delete it and we store the new incoming data. Otherwise, we check

28

Figure 3.3: Database EER model.

29

the previous three days and so on until we find a normal data to delete it and replace it

with the new data.

Figure 3.4: Database update management.

3.4 Data Analysis

3.4.1 IRTI Access Management

As depicted in Fig.3.5, the access to the interface starts by the login of the supervi-

sor, after that there is a login check. If the login is successful, the interface is displayed

and only the list of nodes assigned to the logged supervisor are displayed. In front of

each node there is a possibility to chose either old data or live data. To do this, there is

a check done in parallel that verifies if there is a new data stored in the corresponding

node table. Next, the supervisor will have the choice between different nodes. After the

supervisor chooses a node to consult, a connection is established between the browser

30

and the web server using the secure socket layer (SSL), since we deal with private et

confidential data. Finally the information related to the node including clinical and

demographic information are displayed, in addition to the historic information.

Figure 3.5: IRTI access.

3.4.2 Data Display

The visualization process has 2 modes: live mode which displays at real time the

new incoming data from BANSMOM system and a second mode which allows to

visualize old records since we keep an archive of previous data.

After choosing a node, if there is no new incoming data, the supervisor can request

the old data to be displayed. First, he chooses a range of time and the corresponding

data (peaks) will be fetched from the data base. The next step is the processing of the

31

Figure 3.6: IRTI peak display process.

received data by the chart libraries which is a JavaScript code using the j-Query library.

Code 3.1 shows a part of the corresponding code responsible of the processing of the

retrieved data. After that, the processed peaks will be displayed.

32

Code 3.1: Old data processing

$("#btnSubmit").click(function() {if(startDateTextBox.val()!="" && endDateTextBox.val()!=""){$.ajax({type: "get",url: "<?php echo CController::createUrl(’ecg/GetSensorsData’); ?>",data: {"ecgId" : "<?php echo $modelecg[’node_id’] ;?>" ,"sDate": $(’#startDate’).val() , "eDate": $(’#endDate’).val()},dataType:"json",success: function(response, status) {var chart;

chart = new Highcharts.Chart({

chart: {

renderTo: ’container’,type: ’spline’

},title: {text: ’ECG records for node <?php echo $modelecg[’node_id’] ;?> ’

},

In the live mode, if after selecting the node there is new incoming data, the super-

visor can request to view these data, and an Ajax call is made to the corresponding

database table. The received peak from the database is processed by the chart using

the function add-point and the peak is displayed. Code 3.2 shows a part of the code

responsible for the live update.

Code 3.2: Live data processing

$(document).ready(function() {

function requestData() {$.ajax ({

type:"get" ,url: "<?php echo CController::createUrl(’ecg/GetSensorsDataLive’) ?>",

data: {"ecgId" : "<?php echo $modelecg[’node_id’] ?>", "lead_name": "lead1 aVF" },dataType: "json",

success: function(point) {

var series = chart.series[0],

shift = series.data.length > 8;// shift if the series are longer than 20chart.series[0].addPoint(eval(point),true, false); // add the peakssetTimeout(requestData,1000); // call it again after one second to

add the following peaks

},

33

cache: false});

}

This cycle is repeated until the update process of the table is finished and then

the user will be informed that no new incoming data are available. At this point, the

process of showing old data restarts. All these steps are illustrated with the flowchart

given in Fig. 3.6.

In order to ensure the real time capability of the proposed interface and to prevent

any additional delay that can happen, a buffer mechanism insertion was introduced in

a region of the database dedicated to handle live data. This mechanism is illustrated

in fig.3.7 . The two tables are the information lead table which contains the incoming

data and the last retrieved peak which contains a reference time. Initially the first table

is empty and the second one contains the current time as reference. At the beginning

the data table is being updated and an Ajax call is made to the remote agent. After

receiving this Ajax call, the remote agent compares the first peak time value inserted

with the reference time, if the peak time is greater then the reference this peak will be

fetched and returned to the chart to be displayed and the reference time is updated with

the value of the retrieved peak. Those step are made until there is no incoming data

and the server issues a flag informing the end of the live data stream.

3.4.3 ECG Data Format

The most important functionality that we want to perform in our interface is the

real time visualization. This capability depends on many factors, one of them is the

data format of the ECG peaks. Since the ECG records are saved for a long period, we

34

Figure 3.7: Buffer insertion mechanism in the Database level.

35

have to deal with this huge amount of data. The interface use Json [33] format for the

ECG wave, which is a JavaScript Object Notation, lightweight data interchange and

highcharts compatible.

Figure 3.8: 12 leads data format.

Figure 3.8 shows the 12-leads received from the database in Json format. As shown

in this figure the received data contains 12 series which are the 12 leads, the informa-

tion in each series are the lead name and the data contains the peaks belonging to the

range of time chosen by the user. In this example the data contains 53 peaks.

3.4.4 ECG Database Analysis

In addition to the display capability, we added a small analysis algorithm to our

IRTI which has the task to analyze the database to first check for abnormalities in order

to keep or delete records in case where the database is full. It also gives a feedback to

the user about the state of the ECG data. Many algorithms were developed to do such

analysis for ECG interpretation or heart disease prediction. But in our case, the aim of

36

such implementation is to give a basic information to the user, and we are not doing

the ECG interpretation.

The basics information from where we start the analysis are the heart rhythm

(which is the number of heart beats in one minute) and the heart rate which is re-

lated to the regularity of the heart beat. This capability was implemented following the

flow chart given in Fig. 3.9. The heart rate and rhythm analysis are made in parallel.

First the heart rate where we calculate the number of RR intervals in one minute. The

normal rate is between 60 to 100 beats per minute. Moreover, to calculate the heart

rhythm we check the similarity of successive RR intervals by calculating every RR

interval and compare it with the previous one.

Figure 3.9: Heart rate and rhythm analysis.

37

Chapter 4

Evaluation

4.1 Methodology

The proposed IRTI is designed following the MVC pattern (Model-View-Controller)

which is a software architecture characterized by the separation of the representation of

information from the user’s interaction with it, the code re-usability and the separation

of concerns. YII framework [34] was used as MVC framework. As server-side, PHP

was used with the 5.4.3 version and MySQL as database management system with the

version 5.5.24.

On the client side, HTML5, CSS3 and JavaScript were used. For the ECG viewer

where the ECG waves are displayed, Highcharts [35] charting library is used which is

a library written in pure JavaScript.

4.2 Test-Driven Development

The Test-Driven Development (TDD) is a software development methodology that

helps to create an environment of comfort and confidence by ensuring a test suite that

grows organically with our application. We used functional tests where we focus on

testing the end-to-end feature functionality of the application. These tests exist at a

38

higher level and typically do not require multiple classes or objects to run. Their pur-

pose is to validate that a given feature of the application is working as expected. We

will use Selenium Remote Control Server (Selenium RC) [36] which is integrated in

YII framework. Code 4.1 shows the code used to validate the features and functionali-

ties of the interface.

Code 4.1: Functionality and Features Testing

<?php

define(’TEST_BASE_URL’,’https://localhost/bansmom/index.php/’);

/*** The base class for functional test cases.

* In this class, we set the base URL for the test application.

* We also provide some common methods to be used by concrete test classes.

*/class WebTestCase extends CWebTestCase{/*** Sets up before each test method runs.

* This mainly sets the base URL for the test application.

*/

public static $browsers = array(array(’name’ => ’Firefox on seven’,’browser’ => ’*firefox’,’host’ => ’my.linux.box’,’port’ => 4444,’timeout’ => 30000,

),array(’name’ => ’ie on seven’,’browser’ => ’*custom C:\Program Files\Internet Explorer\iexplore.exe -url’,’host’ => ’my.ie.box’,’port’ => 4444,’timeout’ => 30000,

),array(’name’ => ’chrome on seven’,’browser’ => ’*custom C:\Users\Achraf\AppData\Local\

Google\Chrome\Application\chrome.exe -url’,’host’ => ’my.windowsxp.box’,’port’ => 4444,’timeout’ => 30000,

),

);protected function setUp(){

$this->setBrowserUrl(TEST_BASE_URL);}public function testTitle(){

$this->open(TEST_BASE_URL);$this->assertTitle(’BANSMOM Site’);

}}

39

4.3 Evaluation

The evaluation of our interface will cover the real-time visualization process per-

formed by our interface, the security and vulnerability issues, the code complexity and

finally we present the different views and the behavior of the proposed interface.

4.3.1 Real-Time Visualization

Before evaluating the real time capability of the proposed interface, we introduce

BANSMOM processing distribution to have an idea about the real time requirement.

We define TEt, Rt, PPDt, St which are respectively total execution time, lead read-

ing time, period peak detection algorithm execution time and storing time. The total

execution time is given by the sum of the other parameters. As example, a data sample

from MIT-database has been used containing 10 seconds, 14 periods and 84 peaks.

The total execution time is TEt= 5.753(s) We introduce also TEtp, DBup and IFp

which are respectively total execution time/peak, database update/peak and insertion

frequency/peak.

In order to simulate the live data visualization and the real time monitoring capa-

bility of our tools, we simulate an update of the database, as it is coming from BANS-

MOM system. Code 4.2 shows the used script to update the database. As shown in

this code, we update the table information lead which contains the ECG data, with a

sample of 2 seconds containing 15 peaks. We choose an update frequency equal to the

sum of TEtp and DBup. The result of this update is shown in fig. 4.1, where the peaks

are added to the graph as soon as they are stored in the database using a JavaScript

code as shown in Code 4.3

Code 4.2: Database update simulation.

40

Figure 4.1: Live visualization mode after database update.

41

<?php\\\\\\mysql_select_db("bansmom");set_time_limit(800000);

mysql_query("INSERT INTO ‘information_lead‘

VALUES ( NULL , ’2012-12-01 20:10:00’,281 , 95,’Lead1 I’ ) ");usleep(800000);mysql_query("INSERT INTO ‘information_lead‘

VALUES ( NULL , ’2012-12-01 20:10:00’,375, -825,’Lead1 I’ ) ");usleep(800000);


VALUES ( NULL , ’2012-12-01 20:10:00’,422 , 1496,’Lead1 I’ ) ");usleep(800000);


VALUES ( NULL , ’2012-12-01 20:10:00’,469 , -766,’Lead1 I’ ) ");usleep(800000);




VALUES ( NULL , ’2012-12-01 20:10:00’,984 , -816,’Lead1 I’ ) ");usleep(800000);mysql_query("INSERT INTO ‘information_lead‘






VALUES ( NULL , ’2012-12-01 20:10:01’, 586 , -859,’Lead1 I’ ) ");usleep(800000);mysql_query("INSERT INTO ‘information_lead‘

VALUES ( NULL , ’2012-12-01 20:10:01’, 633 , 1496,’Lead1 I’ ) ");usleep(800000);mysql_query("INSERT INTO ‘information_lead‘

VALUES ( NULL , ’2012-12-01 20:10:01’,680 , -757,’Lead1 I’ ) ");usleep(800000);mysql_query("INSERT INTO ‘information_lead‘

VALUES ( NULL , ’2012-12-01 20:10:01’,789 , 46,’Lead1 I’ ) ");

42

usleep(800000);mysql_query("INSERT INTO ‘information_lead‘


?>

Code 4.3: Live data retrieving.




data: {"ecgId" : "<?php echo $modelecg[’node_id’] ?>" },dataType: "json",



shift = series.data.length > 1;// shift if the series is longer than 20chart.series[0].addPoint(eval(point),true, false); // add the pointsetTimeout(requestData,1000); // call it again after one second

},

4.3.2 Security and Vulnerability Issues

As mentioned in the previous sections, the proposed interface was built follow-

ing the MVC pattern and use the secure socket layer for the data exchange, these two

properties ensure a maximum security for any given web application and prevent from

almost all possible vulnerability and security issues. To test our tool we used a free

web security testing tool which is the Netsparker Web Vulnerability Scanner [37]. Us-

ing this tool we performed a multitude of tests which are: Static Tests, Find Backup

Files, SQL Injection, Boolean SQL Injection, Blind SQL Injection, Cross-site Script-

ing, Command Injection, Blind Command Injection, Local File Inclusion, Remote File

Inclusion, Remote Code Evaluation, HTTP Header Injection, Open Redirection and

43

Expression Language Injection. The rapport given by the tool contains basically some

recommendations or misconfiguration issues rather then a critical alert. For exam-

ple, the version of PHP is recognized as out of date, the auto complete function in

the browser should be disabled, and other misconfiguration and recommendations that

should be taken into account. The complete generated rapport is illustrated if Fig.4.2.

Figure 4.2: Security and Vulnerability rapport.

4.3.3 Complexity

As a controller, we used only one named EcgContoller.php. For the files models,

we used 9 models for the database connection and finally for the views we used 7

views. Table 4.1 shows a summary of the code’s complexity and the list of the used

views, models and controllers. Although the proposed IRTI SW tool has required

features with RT capability, the total code is small and only about 700 lines.

44

Table 4.1: IRTI code complexity.Models View Controllers

Files (.php)

Ecg, Index EcgEcghistory Contact

Ecginfo loginEcginfomodel History

Loginform ListResponsible Info

sensor, livesensorinfo

userCodes (lines) 70 430 200

4.3.4 User Friendly

In addition to the conventional views required for any web application such the in-

dex and the contact views and the live data, the interface contains the login page. After

the login, the user will be directed to a list of nodes assigned only to him, where he

can choose between visualizing live or old records. Our interface contains the required

capability in adequate arrangement and with the minimal resources. Figures 4.3, 4.4,

4.5 explain the previous mentioned views.

45

Figure 4.3: IRTI login page.

46

Figure 4.4: IRTI nodes list.

47

Figure 4.5: IRTI old records view

48

Chapter 5

Conclusion and Future Work

The penetration of ECG monitors into different departments has resulted in grow-

ing demand for ECG data management solutions for collecting and visualizing data at

real time. In this thesis we presented an Interactive Real Time Interface (IRTI) as a

solution for the lack of monitoring capability of the previously designed BANSMOM

system. Our interface is characterized as a user friendly and scalable with the capa-

bility of accepting different data from different nodes at the same time. The security

issues were taken into consideration by securing the access to the interface and by mak-

ing a secure code following the MVC pattern, which despite that the IRTI contains all

required features, the total code is about 700 lines. The data exchange is also secured

by using the secure socket layer as data exchange protocol .

As a future work, we will try to standardize the database following the existing

ECG database such as the Japanese or the European standards. We will try also to

integrate other bio-signals data, such as pulse and blood pressure, to be displayed in the

interface in addition to the ECG wave form to have more suitable conditions for better

diagnosis. Moreover, an efficient Compression and Encryption Algorithms should be

investigated for more secure communication.

49

References

[1] M.G. Carey, Electrocardiographic predictors of sudden cardiac death, Journalof Cardiovascular Nursing 23, no. 2, 175-182, 2008.

[2] Yutana Jewajinda, Prabhas Chongstitvatana Electrical Engineering/Electron-ics Computer Telecommunications and Information Technology (ECTI-CON)IEEE, 1050-1054, 2010.

[3] B.U. Kohler, C. Hennig and R. Orglmeister, The Principles of Software QRSDetection, Engineering in Medicine and Biology Magazine, IEEE, Volume 21,Issue 1, pp 42-57, Jan./Feb. 2002

[4] Farah Magrabi, Nigel H., Branko G. Celler, web based longitudinal ECG mon-itoring, Engineering in Medicine and Biology Society, Proceedings of the 20thAnnual International Conference of the IEEE 1155-1158, 1998.

[5] Jun Dong, Jia-wei Zhang, Hong-hai Zhu, Li-ping Wang, Xia Liu, Zhen-jiangLi, Intelligent Systems, IEEE, no. 1, 36-43, 2012.

[6] A.D. Desai, T.S. Yaw, T. Yamazaki, A. Kaykha, S. Chun, and V.F. Froelicher,Prognostic significance of quantitative qrs duration, The American Journal ofMedicine 119 , no. 7, 600-606, 2006.

[7] G. M. Friesen, T.C. Jannett, M.A. Jadallah, S.L. Yates, and S.R. Quintand H.T.Nagle, A comparison of the noise sensitivity, IEEE Transactions on Biomedi-cal Engineering 37, no. 1, 85-89, 1990.

[8] A real-time QRS detection algorithm”, Pan, J. and Tompkins, W.J.”, IEEETransactions on Biomedical Engineering”,pp.230-236,1985.

[9] Hilbel, Thomas; Thomas M Helms, Gerd Mikus, Hugo A Ka-tus, Christian Zugck (01/10/2008). ”Telemetry in the clinical setting”.Herzschrittmachertherapie & Elektrophysiologie. Retrieved 2009-Aug-04.

[10] www.ece.uah.edu/ jovanov/whrms/figs/whrms-fig1.jpg.

[11] Butler RN. Population aging and health. British Medical Journal 1997;315(7115):1082-1084.

[12] Aronow WS, Ahn C. Elderly nursing home patients with congestive heart fail-ure after myocardial infarction living in New York City have a higher preva-lence of mortality in cold weather and warm weather months. Journals of

50

Gerontology A: Biological Sciences and Medical Sciences 2004; 59(2):146-147.

[13] Koken PJ, Piver WT, Ye F, Elixhauser A, Olsen LM, Portier CJ. Temperature,air pollution, and hospitalization for cardiovascular diseases among elderlypeople in Denver. Environmental Health Perspectives 2003; 111(10):1312-1317.

[14] Dishongh T, Rhodes K, Needham B. Room to room location using wearablesensors for tracking social health of elders. In: Proceedings of the SecondInternational Workshop on Wearable and Implantable Body Sensor Networks2005; 18-20.

[15] http://www.linear.com/products/Wireless-Sensor-Networks.

[16] M. Sung, C. Marci, and A. Pentland, Wearable feedback systems for rehabili-tation, J. NeuroEng. Rehabil., vol. 2, p. 17, Jun. 2005.

[17] M. Di Rienzo, F. Rizzo, G. Parati, G. Brambilla, M. Ferratini, and P. Cas-tiglioni, MagIC system: A new textile-based wearable device for biologicalsignal monitoring applicability in daily life and clinical setting, in Proc. 27thAnn. Int. IEEE EMBS Conf pp.7167-7169,2005.

[18] W. Y. Chung, S. C. Lee, and S. H. Toh, WSN based mobile u-healthcare systemwith ECG, blood pressure measurement function, in Proc. 30th Ann. Int. IEEEMBS Conf., 2008, pp.1533-1536.

[19] W. Y. Chung, Y. D. Lee, and S. J. Jung, A wireless sensor network compatiblewearable u-healthcare monitoring system using integrated ECG, accelerometerand SpO2, in Proc. 30th Ann. Int. IEE EMBS Conf., 2008, pp. 1529-1532.

[20] J. L. Weber and F. Porotte, Medical remote monitoring with clothes, presentedat the Int. workshop on PHealth, Luzern, Switzerland, 2006.

[21] P. S. Pandian, K. Mohanavelu, K. P. Safeer, T. M. Kotresh, D. T. Shakun-thala, P. Gopal, and V. C. Padaki, Smart vest: Wearable multiparameter remotephysiological monitoring system, Med. Eng. Phys., vol. 30, pp. 466-477, May2008.

[22] Philips ECG management systems http://www.healthcare.philips.com/my-en/index.wpd.

[23] Codd EF: The Relational Model for Database Management: Version 2,Addison-Wesley, 2002.

[24] Date CJ: An Introduction to Database Systems. 8th edition, Addison-Wesley,2003.

51

[25] Trigo, J.D., Martinez, I., Alesanco, A., Kollmann, A., Escayola, J., Hayn,D., Schreier, G., Garcia, J. ”An Integrated Healthcare Information System forEnd-to-End Standardized Exchange and Homogeneous Management of DigitalECG Formats ” Information Technology in Biomedicine, IEEE Transactions.2012 pp518-529.

[26] Shizhong Yuan, Daming Wei, Weimin Xu, Wenfeng Shen ”A Metadata Reg-istry to Facilitate the Search and Retrieval of Electrocardiograms” Computerand Information Technology, 2009. CIT ’09. Ninth IEEE International Confer-ence.2009 pp.269-273.

[27] A. Ben Abdallah, Y. Haga, K. Kuroda,An Efficient Algorithm and EmbeddedMulticore Implementation for ECG Analysis in Multi-lead ElectrocardiogramRecords, IEEE Proc. of the 39th he International Conference on Parallel Pro-cessing Workshop, San Diego, pp.99-103, Sept. 13-16, 2010.

[28] H. Yasuyoshi, A. Ben Addallah, Architecture and Design of Application Spe-cific Multicore SoC, Graduation Thesis, The Univ. of Aizu, Feb. 2010.

[29] Y. Haga, A. Ben Abdallah, A.B. and Kuroda, K.,Embedded MCSoC Architec-ture and Period-Peak Detection (PPD) Algorithm for ECG/EKG Processing,The 19th Intelligent System Symposium (FAN 2009), 298-303, 2009.

[30] MVC patternhttp://en.wikipedia.org/wiki/Model-view-controller

[31] Hu Ran, Wang Zhuo, Xu Jianfeng.”Web Quality of Agile Web Development”Services Science, Management and Engineering, 2009. SSME ’09. IITA Inter-national Conference. pp.426-429

[32] MySQL Workbenchhttp://dev.mysql.com/doc/index-gui.html

[33] Jsonhttp://www.json.org/

[34] YII PHP Frameworkhttp://www.yiiframework.com/

[35] Charting libraryhttp://www.highcharts.com/

[36] Selenium Remote Control Serverhttp://seleniumhq.org/projects/remote-control/

[37] Netsparker Web Vulnerability Scannerhttps://netsparker.zendesk.com/

52

Appendix A

Models

Code A.1: Model For table Historic node (ECGHistory.php)

<?php

class ecgHistory extends CActiveRecord{

public static function model($className=__CLASS__){return parent::model($className);

}

public function tableName(){

return ’historique_node’;}

}

Code A.2: Model for table information node (ECGInfo.php)

<?php

class ecgInfo extends CActiveRecord{


}


return ’information_node’;}

}

Code A.3: Model for table responsible (Responsible.php)

<?php

53

class Responsible extends CActiveRecord{


}


return ’responsable’;}

}

Code A.4: Model for table lead (Sensor.php)

<?php

class Sensor extends CActiveRecord{


}


return ’lead’;}

}

Code A.5: Model for table information lead (SensorInfo.php)

<?php

class SensorInfo extends CActiveRecord{


}


return ’information_lead’;}

}

Code A.6: Model for login page (LoginForm.php)

<?php

/*** LoginForm class.

* LoginForm is the data structure for keeping

54

* user login form data. It is used by the ’login’ action of ’EcgController’.

*/class LoginForm extends CFormModel{public $username;public $password;public $rememberMe;

private $_identity;

/*** Declares the validation rules.

* The rules state that username and password are required,

* and password needs to be authenticated.

*/public function rules(){return array(// username and password are requiredarray(’username, password’, ’required’),// rememberMe needs to be a booleanarray(’rememberMe’, ’boolean’),// password needs to be authenticatedarray(’password’, ’authenticate’),

);}

/*** Declares attribute labels.

*/public function attributeLabels(){return array(’rememberMe’=>’Remember me next time’,

);}

/*** Authenticates the password.

* This is the ’authenticate’ validator as declared in rules().

*/public function authenticate($attribute,$params){if(!$this->hasErrors()){$this->_identity=new UserIdentity($this->username,$this->password);if(!$this->_identity->authenticate())$this->addError(’password’,’Incorrect username or password.’);

}}

/*** Logs in the user using the given username and password in the model.

* @return boolean whether login is successful

*/public function login(){if($this->_identity===null){$this->_identity=new UserIdentity($this->username,$this->password);$this->_identity->authenticate();

}if($this->_identity->errorCode===UserIdentity::ERROR_NONE){$duration=$this->rememberMe ? 3600*24*30 : 0; // 30 daysYii::app()->user->login($this->_identity,$duration);return true;

}

55

elsereturn false;

}}

Code A.7: Model for Contact Form (ContactForm.php)

<?phpContactForm extends CFormModel{public $name;public $email;public $subject;public $body;public $verifyCode;

/*** Declares the validation rules.

*/public function rules(){return array(// name, email, subject and body are requiredarray(’name, email, subject, body’, ’required’),// email has to be a valid email addressarray(’email’, ’email’),// verifyCode needs to be entered correctlyarray(’verifyCode’, ’captcha’, ’allowEmpty’=>!CCaptcha::checkRequirements()),

);}

public function attributeLabels(){return array(’verifyCode’=>’Verification Code’,

);}

}

56

Appendix B

Views

Code B.1: Main view

<?php /* @var $this Controller */ ?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8" /><meta name="language" content="en" />

<link rel="stylesheet" type="text/css" href="<?php echo Yii::app()->request->baseUrl; ?>/css/screen.css" media="screen, projection" /><link rel="stylesheet" type="text/css" href="<?php echo Yii::app()->request->baseUrl; ?>/css/print.css" media="print" />

<link rel="stylesheet" type="text/css" href="<?php echo Yii::app()->request->baseUrl; ?>/css/form.css" /><link rel="stylesheet" type="text/css" href="<?php echo Yii::app()->request->baseUrl; ?>/css/main.css" />

<title><?php echo CHtml::encode($this->pageTitle); ?></title></head>

<body>

<div class="container" id="page">

<div id="header">

</div>

<div id="mainmenu"><?php $this->widget(’zii.widgets.CMenu’,array(’items’=>array(array(’label’=>’Home’, ’url’=>array(’/ecg/index’)),array(’label’=>’Contact’, ’url’=>array(’/ecg/contact’)),array(’label’=>’Login’, ’url’=>array(’/ecg/login’),’visible’=>Yii::app()->user->isGuest ),array(’label’=>’Logout (’.Yii::app()->user->name.’)’,’url’=>array(’/ecg/logout’), ’visible’=>!Yii::app()->user->isGuest)

57

),)); ?>

</div><?php if(isset($this->breadcrumbs)):?><?php $this->widget(’zii.widgets.CBreadcrumbs’, array(’links’=>$this->breadcrumbs,

)); ?><?php endif?>

<?php echo $content; ?>

<div class="clear"></div>

<div id="footer">Copyright © <?php echo date(’Y’); ?> ASL <br/>All Rights Reserved.<br/><a href="http://aslweb.u-aizu.ac.jp/benlab/index.php">Advanced System Architectures Group</a>

</div>

</div>

</body></html>

Code B.2: index.php

<?php/* @var $this SiteController */

$this->pageTitle=Yii::app()->name;?>

<h1>Welcome to <i><?php echo CHtml::encode(Yii::app()->name); ?></i></h1><div><p>Recent technological advances in wireless networking,microelectronicsand the Internet allow us to fundamentally change the way elderlyhealth care services are practiced.Traditionally, embedded personal medical monitoring systems havebeen used only to collect data.Data processing and analysis are performed off-line, making suchdevices impractical forcontinual monitoring and early detection of medical disorders.

The goal of this project is to research about efficient novelin-body snartembedded system to effectively monitor elderly health status remotely.In particular, we investigate an extreme area in the design space ofnetworked embedded objects:the domain of low energy, and real-time. Issues related to the design,implementation anddeployment of such systems are also studied.</p>

<div style="text-align:center;"><img src="images/bansmom.png" alt="BANSMOM"/></div></div>

<?php

?>

Code B.3: Node list (list.php)

58

<?php$this->pageTitle=Yii::app()->name;//Yii::app()->clientScript->registerScriptFile(Yii::app()->baseUrl.’/helpers/hijri.php’);Yii::app()->clientScript->registerScriptFile(Yii::app()->baseUrl.’/helpers/datatables/media/js/jquery.dataTables.min.js’);Yii::app()->clientScript->registerScriptFile(Yii::app()->baseUrl.’/helpers/datatables/media/js/jquery.dataTables.js’);Yii::app()->clientScript->registerScriptFile(Yii::app()->baseUrl.’/helpers/datatables/media/js/jquery.dataTables.columnFilter.js’);Yii::app()->clientScript->registerCssFile(Yii::app()->baseUrl.’/helpers/jQuery-Timepicker-Addon-master/jquery-ui-timepicker-addon.css’);Yii::app()->clientScript->registerScriptFile(Yii::app()->baseUrl.’/helpers/datatables/media/js/css/demo_table.css’);

?>

<script type="text/javascript" charset="utf-8">

$(document).ready( function() {$(’#list’).dataTable( {} );

} )</script>

<table id="list" class="table table-borderedtable-striped table-hover table-condensed " ><caption></caption>

<thead><tr><th>id </th><th>Name</th>

<th>Age</th><th><i class="icon-globe"></i> Location</th><th > Live records</th>

<th> Old records </th></tr>

</thead><tbody >

<?php foreach($model as $models) : ?>

<tr><td> <?php echo $models[’node_id’] ; ?></td><td><?php echo $models[’node_name’] ; ?></td><td><?php echo $models[’node_age’] ; ?></td><td><?php echo $models[’node_location’] ; ?></td>

<td>

<?php

echo CHtml::linkButton(’<i class="icon-time"> </i>’,

array(’submit’=>array(’ecg/live’),’params’=>array(’ecgId’=>$models[’node_id’])));

?>

</td>

<td><?php

echo CHtml::linkButton(’<i class="icon-eye-open"></i>’,array(’submit’=>array(’ecg/info’),

59

’params’=>array(’ecgId’=>$models[’node_id’])));?>

</td>

</tr>

<?php endforeach; ?>

</tbody>

</table>

Code B.4: Node Information (info.php)

<?php

$this->pageTitle=Yii::app()->name;Yii::app()->clientScript->registerCoreScript(’jquery’);Yii::app()->clientScript->registerCoreScript(’jquery.ui’);Yii::app()->clientScript->registerCoreScript(’Timepicker’);Yii::app()->clientScript->registerScriptFile(Yii::app()->baseUrl.’/helpers/jQuery-Timepicker-Addon-master/jquery-ui-sliderAccess.js’);Yii::app()->clientScript->registerScriptFile(Yii::app()->baseUrl.’/helpers/jQuery-Timepicker-Addon-master/jquery-ui-timepicker-addon.js’);Yii::app()->clientScript->registerScriptFile(Yii::app()->baseUrl.’/helpers/lib-highcharts/highcharts.js’);Yii::app()->clientScript->registerScriptFile(Yii::app()->baseUrl.’/helpers/lib-highcharts/themes/grid.js’);Yii::app()->clientScript->registerScriptFile(Yii::app()->baseUrl.’/helpers/datatables/media/js/jquery.dataTables.min.js’);Yii::app()->clientScript->registerScriptFile(Yii::app()->baseUrl.’/helpers/datatables/media/js/jquery.dataTables.js’);Yii::app()->clientScript->registerScriptFile(Yii::app()->baseUrl.’/helpers/datatables/media/js/jquery.dataTables.columnFilter.js’);Yii::app()->clientScript->registerCssFile(Yii::app()->baseUrl.’/helpers/jQuery-Timepicker-Addon-master/jquery-ui-timepicker-addon.css’);Yii::app()->clientScript->registerScriptFile(Yii::app()->baseUrl.’/helpers/datatables/media/js/css/demo_table.css’);

?>

<script type="text/javascript" >

$(document).ready(function(){

var startDateTextBox = $(’#startDate’);var endDateTextBox = $(’#endDate’);

$("#btnSubmit").click(function() {if(startDateTextBox.val()!="" && endDateTextBox.val()!=""){$.ajax({type: "get",url: "<?php echo CController::createUrl(’ecg/GetSensorsData’); ?>",data: {"ecgId" : "<?php echo $modelecg[’node_id’] ;?>" ,"sDate": $(’#startDate’).val() , "eDate": $(’#endDate’).val()},dataType:"json",success: function(response, status) {var chart;

60

chart = new Highcharts.Chart({

chart: {

renderTo: ’graph2’,

type: ’spline’

},title: {text: ’ECG records for node <?php echo $modelecg[’node_id’] ;?> ’

},

xAxis: {type: ’datetime’,dateTimeLabelFormats: {second: ’%H:%M:%S’,

minute: ’%H:%M’,hour: ’%H:%M’,

month: ’%e. %b’,year: ’%b’

},

labels: {enabled: false

},

gridLineDashStyle: ’longdash’ ,lineColor: ’#FF0000’,

lineWidth: 1,tickPixelInterval: 30,

title: {text: ’Time (ms)’

},

},yAxis: {title: {text: ’Peaks value (mv)’

},

lineColor: ’#FF0000’,lineWidth: 1,

gridLineDashStyle: ’longdash’ ,minorGridLineWidth: 0,

minorTickInterval: ’auto’,minorTickLength: 10,minorTickWidth: 1

},tooltip: {

crosshairs: [

{width: 1,color: ’blue’

},{width: 1,color: ’blue’

}

],

61

formatter: function() {return ’<b>’+ this.series.name +’</b><br/>’+Highcharts.dateFormat(’%H:%S:%m’,this.x) +’<br/>’+Highcharts.numberFormat(this.y,0.2);

}

},

series: response});

},error: function (response, status) {

alert("An error occured while loading data!");}

});}

}

else

{alert("Choose date range!")

}

});startDateTextBox.datetimepicker({showSecond: true,dateFormat : ’yy-mm-dd’,timeFormat: ’HH:mm ’,stepHour: 1,stepMinute: 1,stepSecond: 0.5,

onClose: function(dateText, inst) {if (endDateTextBox.val() != ’’) {var testStartDate = startDateTextBox.datetimepicker(’getDate’);var testEndDate = endDateTextBox.datetimepicker(’getDate’);if (testStartDate > testEndDate)endDateTextBox.datetimepicker(’setDate’, testStartDate);

}else {endDateTextBox.val(dateText);

}},onSelect: function (selectedDateTime){endDateTextBox.datetimepicker(’option’, ’minDate’,startDateTextBox.datetimepicker(’getDate’) );

}});

endDateTextBox.datetimepicker({showSecond: true,dateFormat : ’yy-mm-dd’,timeFormat: ’HH:mm:ss’,stepHour: 1,stepMinute: 1,stepSecond: 0.5,onClose: function(dateText, inst) {if (startDateTextBox.val() != ’’) {var testStartDate = startDateTextBox.datetimepicker(’getDate’);var testEndDate = endDateTextBox.datetimepicker(’getDate’);if (testStartDate > testEndDate)startDateTextBox.datetimepicker(’setDate’, testEndDate);

}else {startDateTextBox.val(dateText);

}},

62

onSelect: function (selectedDateTime){startDateTextBox.datetimepicker(’option’, ’maxDate’,endDateTextBox.datetimepicker(’getDate’) );

}});

});</script>

<div >

<div style="text-align:center; margin-top:10px; margin-left:120px;">

<span><input id="startDate" type="text" placeholder="Choose start date..."></span>to<span><input id="endDate" type="text" placeholder="Choose end date..."></span><span style= "margin-left:10px; margin-top:0px;">

<button id="btnSubmit" class="btn btn-primary" type="button">Get Data</button></span>

</div>

<div id="graph2" style=" width:65; height:170 ;display:inline-block;margin-right:20px; float:right; margin-top:150 px;"></div>

<div id="information_table" style="width:30; margin-bottom:50px; margin-left:100 px; float:left; display:inline; ">

<table id="example1" class="dataTable"><thead><tr><th scope="col">Node Infomarmatio</th><th scope="col">parameter</th></tr></thead><tbody><tr><td>Name</td><td><?php echo $modelecg[’node_name’] ;?> </td></tr><tr><td>Sex</td><td><?php echo $modelResponsible[’responsable_sexe’] ;?> </td></tr><tr><td>Age</td><td><?php echo $modelecg[’node_age’] ;?> </td></tr><tr><td>Weight</td><td><?php echo $modelecg[’node_weight’] ;?> </td></tr><tr><td>Height</td><td><?php echo $modelecg[’node_height’] ;?> </td></tr><tr><td>location</td><td><?php echo $modelecg[’node_location’] ;?> </td></tr><tr><td> phone </td>

63

<td> <?php echo $modelResponsible[’responsable_phone’] ;?> </td></tr><tr><td>Doctor in charge</td><td> <?php echo $modelResponsible[’responsable_name’] ;?> </td></tr>

</tbody></table>

</div>

<div id="historique_table" style=" width:30%; margin-bottom:50px; "><script type="text/javascript" charset="utf-8">


$(".dataTable").dataTable()({

"bJQueryUI":true

})

})</script><table id ="example2" class="dataTable">

<thead><tr><th ><i class="icon-calendar"></i> Date</th><th><i class="icon-wrench"></i> Intervention</th></tr></thead><tbody><?php if(count($modelHistory)>=1) {foreach($modelHistory as $models) : ?><tr><td><h6><?php echo $models[’historic_node_date’] ; ?></h6></td><td><a><?php echo $models[’historic_node_intervention’] ; ?></a></td></tr><?php endforeach;}else {?><tr><td colspan=’2’ style="text-align:center;">Sorry no history found for this Node</td></tr><?php } ?></tbody></table></div>

<div id="lead_data" style="width:70; margin-bottom:50px; float:center; display:inline-block; " >

<table id ="example22" class="dataTable" >

<thead><tr><th><i class="icon-wrench"></i> Peak number </th><th><i class="icon-calendar"></i> Peak Time</th><th><i class="icon-wrench"></i> Peak Value</th><th><i class="icon-wrench"></i> sensors Name</th></tr></thead><tbody><?php if(count($modelSensors)>=1) {foreach($modelSensors as $models) : ?><tr>

64

<td> <?php echo $models[’information_lead_id’] ; ?> </td><td> <?php echo $models[’information_lead_temps’] ; ?> </td><td> <?php echo $models[’information_lead_valeur’] ; ?> </td><td> <?php echo $models[’lead_id’] ; ?> </td></tr><?php endforeach;}else {?>

<tr><td colspan=’2’ style="text-align:center;">Sorry no history found for this Node</td>

</tr><?php } ?></tbody>

</table></div>

Code B.5: Live data (live.php)

<?php

$this->pageTitle=Yii::app()->name;Yii::app()->clientScript->registerCoreScript(’jquery’);Yii::app()->clientScript->registerCoreScript(’jquery.ui’);Yii::app()->clientScript->registerScriptFile(Yii::app()->baseUrl.’/helpers/jQuery-Timepicker-Addon-master/jquery-ui-sliderAccess.js’);Yii::app()->clientScript->registerScriptFile(Yii::app()->baseUrl.’/helpers/jQuery-Timepicker-Addon-master/jquery-ui-timepicker-addon.js’);Yii::app()->clientScript->registerScriptFile(Yii::app()->baseUrl.’/helpers/lib-highcharts/highcharts.js’);Yii::app()->clientScript->registerScriptFile(Yii::app()->baseUrl.’/helpers/lib-highcharts/themes/grid.js’);Yii::app()->clientScript->registerCssFile(Yii::app()->baseUrl.’/helpers/jQuery-Timepicker-Addon-master/jquery-ui-timepicker-addon.css’);Yii::app()->clientScript->registerScriptFile(Yii::app()->baseUrl.’/helpers/datatables/media/js/jquery.dataTables.min.js’);Yii::app()->clientScript->registerScriptFile(Yii::app()->baseUrl.’/helpers/datatables/media/js/jquery.dataTables.js’);Yii::app()->clientScript->registerScriptFile(Yii::app()->baseUrl.’/helpers/datatables/media/js/jquery.dataTables.columnFilter.js’);?>

<script type="text/javascript">




data: {"ecgId" : "<?php echo $modelecg[’node_id’] ?>" },dataType: "json",



shift = series.data.length > 1;// shift if the series is longer than 20chart.series[0].addPoint(eval(point),true, false); // add the pointsetTimeout(requestData,1000); // call it again after one second

65

},

cache: false});

}

chart = new Highcharts.Chart({chart: {

renderTo: ’graph’,type: ’spline’,events: {

load: requestData}

},

xAxis: {labels: {enabled: true

},

gridLineDashStyle: ’longdash’ ,lineColor: ’#FF0000’,

lineWidth: 1,

tickPixelInterval: 30,title: {text: ’Time (ms)’

},

},yAxis: {title: {text: ’Peaks value (mv)’

},

lineColor: ’#FF0000’,lineWidth: 1,

gridLineDashStyle: ’longdash’ ,minorGridLineWidth: 0,

minorTickInterval: ’auto’,minorTickLength: 10,minorTickWidth: 1

},tooltip: {

crosshairs: [

{width: 1,color: ’blue’

},{width: 1,color: ’blue’

}

],

formatter: function() {return ’<b>’+ this.series.name +’</b><br/>’+Highcharts.numberFormat(this.x,0.2) +’<br/>’+

66

Highcharts.numberFormat(this.y,0.2);}

},

series: [{name: ’Live Data From Node <?php echo $modelecg[’node_id’] ;?> ’,data:[]

}]

});

});

</script>

<div id="graph" style="min-width: 300px; height: 350px; margin-top:100px "></div>

Code B.6: Contact Form (contact.php)

<?php/* @var $this SiteController *//* @var $model ContactForm *//* @var $form CActiveForm */

$this->pageTitle=Yii::app()->name . ’ - Contact Us’;$this->breadcrumbs=array(’Contact’,

);?>

<h1>Contact Us</h1>

<?php if(Yii::app()->user->hasFlash(’contact’)): ?>

<div class="flash-success"><?php echo Yii::app()->user->getFlash(’contact’); ?>

</div>

<?php else: ?>

<p>If you have business inquiries or other questions,please fill out the following form to contact us. Thank you.</p>

<div class="form">

<?php $form=$this->beginWidget(’CActiveForm’, array(’id’=>’contact-form’,’enableClientValidation’=>true,’clientOptions’=>array(’validateOnSubmit’=>true,

),)); ?>

<p class="note">Fields with <span class="required">

*</span> are required.</p>

<?php echo $form->errorSummary($model); ?>

<div class="row"><?php echo $form->labelEx($model,’name’); ?>

67

<?php echo $form->textField($model,’name’); ?><?php echo $form->error($model,’name’); ?>

</div>

<div class="row"><?php echo $form->labelEx($model,’email’); ?><?php echo $form->textField($model,’email’); ?><?php echo $form->error($model,’email’); ?>

</div>

<div class="row"><?php echo $form->labelEx($model,’subject’); ?><?php echo $form->textField($model,’subject’,array(’size’=>60,’maxlength’=>128)); ?><?php echo $form->error($model,’subject’); ?>

</div>

<div class="row"><?php echo $form->labelEx($model,’body’); ?><?php echo $form->textArea($model,’body’,array(’rows’=>6, ’cols’=>50)); ?><?php echo $form->error($model,’body’); ?>

</div>

<?php if(CCaptcha::checkRequirements()): ?><div class="row"><?php echo $form->labelEx($model,’verifyCode’); ?><div><?php $this->widget(’CCaptcha’); ?><?php echo $form->textField($model,’verifyCode’); ?></div><div class="hint">Please enter the letters as they are shown in the image above.<br/>Letters are not case-sensitive.</div><?php echo $form->error($model,’verifyCode’); ?>

</div><?php endif; ?>

<div class="row buttons"><?php echo CHtml::submitButton(’Submit’); ?>

</div>

<?php $this->endWidget(); ?>

</div>

<?php endif; ?>

Code B.7: Login Form:login.php

<?php/* @var $this SiteController *//* @var $model LoginForm *//* @var $form CActiveForm */

$this->pageTitle=Yii::app()->name . ’ - Login’;$this->breadcrumbs=array(’Login’,

);?>

<h1>Login</h1>

<p>Please fill out the following form with yourlogin credentials:</p>

<div class="form">

68

<?php $form=$this->beginWidget(’CActiveForm’, array(’id’=>’login-form’,’enableClientValidation’=>true,’clientOptions’=>array(’validateOnSubmit’=>true,

),)); ?>

<p class="note">Fields with <span class="required">

*</span> are required.</p>

<div class="row"><?php echo $form->labelEx($model,’username’); ?><?php echo $form->textField($model,’username’); ?><?php echo $form->error($model,’username’); ?>

</div>

<div class="row"><?php echo $form->labelEx($model,’password’); ?><?php echo $form->passwordField($model,’password’); ?><?php echo $form->error($model,’password’); ?><p class="hint">Hint: You may login with <kbd>demo</kbd>/<kbd>demo</kbd> or <kbd>admin</kbd>/<kbd>admin</kbd>.

</p></div>

<div class="row rememberMe"><?php echo $form->checkBox($model,’rememberMe’); ?><?php echo $form->label($model,’rememberMe’); ?><?php echo $form->error($model,’rememberMe’); ?>

</div>

<div class="row buttons"><?php echo CHtml::submitButton(’Login’); ?>

</div>

<?php $this->endWidget(); ?></div>

69

Appendix C

Controller

Code C.1: Main controller (EcgController.php)

<?php

class EcgController extends Controller{/*** Declares class-based actions.

*/public function actions(){return array(// captcha action renders the CAPTCHA image displayed on the contact page’captcha’=>array(’class’=>’CCaptchaAction’,’backColor’=>0xFFFFFF,

),

’class’=>’CViewAction’,),

);}

/*** This is the default ’index’ action that is invoked

* when an action is not explicitly requested by users.

*/public function actionIndex(){

$this->render(’index’);

}

public function actionList($respId=’1’){$model=ecg::model()->findAllBySql(’SELECT * FROM node where responsable_id = "’.$respId.’"’);$this->render(’list’,array(’model’=>$model));

}

public function actionInfo( ){if(isset($_POST[’ecgId’]))$ecgId = $_POST[’ecgId’];

70

$modelecg=ecg::model()->findBySql(’SELECT * FROM node where node_id = "’.$ecgId.’"’);

if(count($modelecg)<1)throw new CHttpException(’ : Node not found !’,’Make sure that youentered a valid Node’);

$modelResponsible=Responsible::model()->findBySql(’SELECT * FROM responsable where responsable_id ="’.$modelecg[’responsable_id’].’"’);

$modelHistory=ecgHistory::model()->findAllBySql(’SELECT * FROM historique_node where node_id ="’.$ecgId.’" ORDER BY historique_node_date DESC ’);// get all sensors

$sensorsIds=Sensor::model()->findAllBySql(’SELECT lead_id FROM lead where node_id="’.$ecgId.’";’);

foreach ($sensorsIds as $s){

$modelSensors = SensorInfo::model()->findAllBySql(’SELECT * FROM information_lead order by information_lead_id;’);

}

$this->render(’info’,array(’modelecg’=>$modelecg,’modelResponsible’=>$modelResponsible,’modelHistory’=>$modelHistory ,’modelSensors’=>$modelSensors,’sensorIds’=>$sensorsIds ));

}

public function actionTable( $sDate1,$eDate1 ){if(isset($_POST[’ecgId’]))$ecgId = $_POST[’ecgId’];


if(count($modelecg)<1)throw new CHttpException(’ : Node not found !’,’Make sure that you entered a valid Node’);

// get all sensors$sensorsIds=Sensor::model()->findAllBySql(’SELECT lead_id FROM lead where node_id="’.$ecgId.’";’);


$modelSensors = SensorInfo::model()->findAllBySql(’SELECT * FROM information_lead where

"’.$sDate1.’" <= information_lead_temps and

information_lead_temps <= "’.$eDate1.’"

order by information_lead_id;’);

}

$this->render(’info’,array(’modelecg’=>$modelecg ,’modelSensors’=>$modelSensors,’sensorIds’=>$sensorsIds ));

}

71

/////////////////////// live action begin/////////////////////////public function actionLive(){if(isset($_POST[’ecgId’]))$ecgId = $_POST[’ecgId’];


if(count($modelecg)<1)throw new CHttpException(’ : ecg not found !’,’Make sure that you entered a valid ecg’);

$modelSensors = SensorInfo2::model()->findBySql(’SELECT * FROM information_lead2 where

lead_id= "Lead1 I" order by information_lead2_id DESC;’ );

$this->render(’live’,array(’modelSensors’=>$modelSensors ,’modelecg’=>$modelecg)) ;

}

//////////////////// live action end /////////////////////////

///////////// get old sensors data begin/////////////////////////

public function actionGetSensorsData($ecgId,$sDate,$eDate){$result = array();

header(’Content-Type: application/json; charset="UTF-8"’);

// get all sensors$sensorsIds=Sensor::model()->findAllBySql(’SELECT lead_id FROM lead where node_id="’.$ecgId.’";’);


$sResult = array();

$modelSensors = SensorInfo::model()->findAllBySql(’SELECT * FROM information_leadwhere lead_id= "’.$s[’lead_id’].’" and

"’.$sDate.’" <= information_lead_temps and

information_lead_temps <= "’.$eDate.’"

order by information_lead_temps ASC;’);

foreach($modelSensors as $res){

$sResult[] = array(($res[’information_lead_temps’]),intval($res[’information_lead_valeur’]));

}

$data= array(’data’=>$sResult);$name = array(’name’=>$s[’lead_id’]);$result[]=array(’name’=>$s[’lead_id’],’data’=>$sResult);

72

}

$json = CJSON::encode($result);echo $json ;Yii::app()->end();

}///////////////////////////// get old sensors data end/////////////////////////

////////////////////////////// get live sensors data begin/////////////////////////public function actionGetSensorsDataLive($ecgId) {

header(’Content-Type: application/json; charset="UTF-8"’);$sensorsIds = Sensor::model()->findAllBySql(’SELECT lead_id FROM lead where

node_id="’ . $ecgId . ’" and lead_name = "I" ;’);

foreach ($sensorsIds as $s) {

$sResult = array();$sensors = SensorInfo2::model()->findBySql(’SELECT * FROM information_lead2 where lead_id= "’.$s[’lead_id’].’"

ORDER BY information_lead2_id DESC ’);

$sResult = array((float)($sensors->information_lead2_milli ),(float)($sensors->information_lead2_valeur ));

foreach ($sensors as $sensor) {$lastPointId = 1;$lastPoint = Lastpoint::model()->findByPk($lastPointId);$lastPoint->last_point_temps = $sensors->information_lead2_temps;if ( ! $lastPoint->save()) {

throw new CException(’Unable to save last point.’);}}

}echo json_encode($sResult);Yii::app()->end();

}

////////////////////////////////// get live sensors data end/////////////////////////

/*** This is the action to handle external exceptions.

*/public function actionError(){

if($error=Yii::app()->errorHandler->error){if(Yii::app()->request->isAjaxRequest)echo $error[’message’];

else$this->render(’error’, $error);

}}

/*** Displays the contact page

*/public function actionContact()

73

{$model=new ContactForm;if(isset($_POST[’ContactForm’])){$model->attributes=$_POST[’ContactForm’];if($model->validate()){$name=’=?UTF-8?B?’.base64_encode($model->name).’?=’;$subject=’=?UTF-8?B?’.base64_encode($model->subject).’?=’;$headers="From: $name <{$model->email}>\r\n"."Reply-To: {$model->email}\r\n"."MIME-Version: 1.0\r\n"."Content-type: text/plain; charset=UTF-8";

mail(Yii::app()->params[’adminEmail’],$subject,$model->body,$headers);Yii::app()->user->setFlash(’contact’,’Thank you for contacting us. We willrespond to you as soon as possible.’);$this->refresh();

}}$this->render(’contact’,array(’model’=>$model));

}

/*** Displays the login page

*/

///////////////////// login begin //////////

public function actionLogin(){$model=new LoginForm;

// if it is ajax validation requestif(isset($_POST[’ajax’]) && $_POST[’ajax’]===’login-form’){echo CActiveForm::validate($model);Yii::app()->end();

}

// collect user input dataif(isset($_POST[’LoginForm’])){$model->attributes=$_POST[’LoginForm’];// validate user input and redirect to the previous page if validif($model->validate() && $model->login())

$this->redirect(’list’,array(’model’=>$model));

//’url’=>array(’/site/logout’)}// display the login form$this->render(’login’,array(’model’=>$model));

}

////// //////// login end////////////////////

/*** Logs out the current user and redirect to homepage.

*/public function actionLogout(){Yii::app()->user->logout();$this->redirect(Yii::app()->homeUrl);

}}

74

Appendix D

Database

Code D.1: Database for 12 leads

-- phpMyAdmin SQL Dump-- version 3.3.9-- http://www.phpmyadmin.net---- Host: localhost-- Generation Time: Jan 18, 2013 at 09:58 AM-- Server version: 5.5.8-- PHP Version: 5.3.5

SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;/*!40101 SET NAMES utf8 */;

---- Database: ‘bansmom‘--

-- --------------------------------------------------------

---- Table structure for table ‘historic_node‘---- Creation: Jan 18, 2013 at 05:11 PM--

DROP TABLE IF EXISTS ‘historic_node‘;CREATE TABLE IF NOT EXISTS ‘historic_node‘ (‘historic_node_id‘ int(11) NOT NULL AUTO_INCREMENT,‘historic_node_date‘ datetime DEFAULT NULL,‘historic_node_intervention‘ text,‘node_id‘ int(11) NOT NULL,PRIMARY KEY (‘historique_node_id‘),KEY ‘node_id‘ (‘node_id‘)

) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=121 ;

---- RELATIONS FOR TABLE ‘historic_node‘:-- ‘node_id‘-- ‘node‘ -> ‘node_id‘--

75

---- Dumping data for table ‘historic_node‘--

INSERT INTO ‘historic_node‘ (‘historic_node_id‘,‘historic_node_date‘, ‘historic_node_intervention‘,‘node_id‘) VALUES(1, ’2012-11-19 00:00:00’, ’\r\n\r\nMedical Check\r\n’, 1),(2, ’2012-10-05 00:00:00’, ’\r\n\r\nMedical Check’, 1),(3, ’2010-11-05 00:00:00’, ’\r\n\r\nMedical Check’, 5);

-- --------------------------------------------------------

---- Table structure for table ‘information_lead‘---- Creation: Jan 18, 2013 at 05:13 PM--

DROP TABLE IF EXISTS ‘information_lead‘;CREATE TABLE IF NOT EXISTS ‘information_lead‘ (‘information_lead_id‘ int(11) NOT NULL AUTO_INCREMENT,‘information_lead_time‘ timestamp NULL DEFAULT NULL,‘information_lead_valeur‘ float DEFAULT NULL,‘lead_id‘ varchar(11) DEFAULT NULL,PRIMARY KEY (‘information_lead_id‘)


---- Dumping data for table ‘information_lead‘--

INSERT INTO ‘information_lead‘ (‘information_lead_id‘,‘information_lead_time‘, ‘information_lead_value‘,‘lead_id‘) VALUES(1, ’2012-12-01 15:00:00’, 95, ’Lead1 I’),(2, ’2012-12-01 15:00:00’, -825, ’Lead1 I’),///(53, ’2012-12-01 15:00:06’, 46, ’Lead1 I’),(138, ’2012-12-01 15:00:00’, 95, ’Lead1 II’),////(275, ’2012-12-01 15:00:00’, 95, ’Lead1 III’),(276, ’2012-12-01 15:00:00’, -825, ’Lead1 III’),(277, ’2012-12-01 15:00:00’, 1496, ’Lead1 III’),////(412, ’2012-12-01 15:00:00’, 95, ’Lead1 aVR’),(413, ’2012-12-01 15:00:00’, -825, ’Lead1 aVR’),/////(549, ’2012-12-01 15:00:00’, 95, ’Lead1 aVL’),(550, ’2012-12-01 15:00:00’, -825, ’Lead1 aVL’),//////(823, ’2012-12-01 15:00:00’, 95, ’Lead1 V1’),(824, ’2012-12-01 15:00:00’, -825, ’Lead1 V1’),///////(960, ’2012-12-01 15:00:00’, 95, ’Lead1 V2’),(961, ’2012-12-01 15:00:00’, -825, ’Lead1 V2’),///////(1098, ’2012-12-01 15:00:00’, -825, ’Lead1 V3’),(1099, ’2012-12-01 15:00:00’, 1496, ’Lead1 V3’),(1100, ’2012-12-01 15:00:00’, -776, ’Lead1 V3’),//////(1234, ’2012-12-01 15:00:00’, 95, ’Lead1 V4’),(1235, ’2012-12-01 15:00:00’, -825, ’Lead1 V4’),(1236, ’2012-12-01 15:00:00’, 1496, ’Lead1 V4’),//////(1372, ’2012-12-01 15:00:00’, -825, ’Lead1 V5’),(1373, ’2012-12-01 15:00:00’, 1496, ’Lead1 V5’),(1374, ’2012-12-01 15:00:00’, -776, ’Lead1 V5’),

76

/////(1508, ’2012-12-01 15:00:00’, 95, ’Lead1 V6’),(1509, ’2012-12-01 15:00:00’, -825, ’Lead1 V6’),(1561, ’2012-12-01 15:00:00’, 95, ’Lead1 V6’);

-- --------------------------------------------------------

---- Table structure for table ‘information_node‘---- Creation: Jan 18, 2013 at 05:23 PM--

DROP TABLE IF EXISTS ‘information_node‘;CREATE TABLE IF NOT EXISTS ‘information_node‘ (‘information_node_id‘ int(11) NOT NULL AUTO_INCREMENT,‘information_node_age‘ float DEFAULT NULL,‘information_node_weight‘ float DEFAULT NULL,‘information_node_height‘ float DEFAULT NULL,‘information_node_localisation‘ varchar(45) DEFAULT NULL,‘node_id‘ int(11) NOT NULL,PRIMARY KEY (‘information_node_id‘),KEY ‘node_id‘ (‘node_id‘)


---- RELATIONS FOR TABLE ‘information_node‘:-- ‘node_id‘-- ‘node‘ -> ‘node_id‘--

---- Dumping data for table ‘information_node‘--

INSERT INTO ‘information_node‘ (‘information_node_id‘,‘information_node_age‘,‘information_node_weight‘, ‘information_node_height‘,‘information_node_localisation‘, ‘node_id‘) VALUES(1, 12, 152, 11, ’Tokyo’, 1);

-- --------------------------------------------------------

---- Table structure for table ‘lead‘---- Creation: Jan 18, 2013 at 05:11 PM--

DROP TABLE IF EXISTS ‘lead‘;CREATE TABLE IF NOT EXISTS ‘lead‘ (‘lead_id‘ varchar(11) NOT NULL,‘lead_name‘ varchar(45) DEFAULT NULL,‘node_id‘ int(11) NOT NULL,PRIMARY KEY (‘lead_id‘),KEY ‘node_id‘ (‘node_id‘)

) ENGINE=InnoDB DEFAULT CHARSET=latin1;

---- RELATIONS FOR TABLE ‘lead‘:-- ‘node_id‘-- ‘node‘ -> ‘node_id‘--

---- Dumping data for table ‘lead‘--

77

INSERT INTO ‘lead‘ (‘lead_id‘, ‘lead_name‘, ‘node_id‘) VALUES(’Lead1 aVF’, ’aVF’, 1),(’Lead1 aVL’, ’aVL’, 1),(’Lead1 aVR’, ’aVR’, 1),(’Lead1 I’, ’I’, 1),(’Lead1 II’, ’II’, 1),(’Lead1 III’, ’III’, 1),(’Lead1 V1’, ’V1’, 1),(’Lead1 V2’, ’V2’, 1),(’Lead1 V3’, ’V3’, 1),(’Lead1 V4’, ’V4’, 1),(’Lead1 V5’, ’V5’, 1),(’Lead1 V6’, ’V6’, 1),(’Lead2 aVF’, ’aVF’, 2),(’Lead2 aVL’, ’aVL’, 2),(’Lead2 aVR’, ’aVR’, 2),(’Lead2 I’, ’I’, 2),(’Lead2 II’, ’II’, 2),(’Lead2 III’, ’III’, 2),(’Lead2 V1’, ’V1’, 2),(’Lead2 V2’, ’V2’, 2),(’Lead2 V3’, ’V3’, 2),(’Lead2 V4’, ’V4’, 2),(’Lead2 V5’, ’V5’, 2),(’Lead2 V6’, ’V6’, 2),(’Lead3 aVF’, ’aVF’, 3),(’Lead3 aVL’, ’aVL’, 3),(’Lead3 aVR’, ’aVR’, 3),(’Lead3 I’, ’I’, 3),(’Lead3 II’, ’II’, 3),(’Lead3 III’, ’III’, 3),(’Lead3 V1’, ’V1’, 3),(’Lead3 V2’, ’V2’, 3),(’Lead3 V3’, ’V3’, 3),(’Lead3 V4’, ’V4’, 3),(’Lead3 V5’, ’V5’, 3),(’Lead3 V6’, ’V6’, 3),(’Lead4 aVF’, ’aVF’, 4),(’Lead4 aVL’, ’aVL’, 4),(’Lead4 aVR’, ’aVR’, 4),(’Lead4 I’, ’I’, 4),(’Lead4 II’, ’II’, 4),(’Lead4 III’, ’III’, 4),(’Lead4 V1’, ’V1’, 4),(’Lead4 V2’, ’V2’, 4),(’Lead4 V3’, ’V3’, 4),(’Lead4 V4’, ’V4’, 4),(’Lead4 V5’, ’V5’, 4),(’Lead4 V6’, ’V6’, 4),(’Lead5 aVF’, ’aVF’, 5),(’Lead5 aVL’, ’aVL’, 5),(’Lead5 aVR’, ’aVR’, 5),(’Lead5 I’, ’I’, 5),(’Lead5 II’, ’II’, 5),(’Lead5 III’, ’III’, 5),(’Lead5 V1’, ’V1’, 5),(’Lead5 V2’, ’V2’, 5),(’Lead5 V3’, ’V3’, 5),(’Lead5 V4’, ’V4’, 5),(’Lead5 V5’, ’V5’, 5),(’Lead5 V6’, ’V6’, 5);

-- --------------------------------------------------------

---- Table structure for table ‘node‘---- Creation: Jan 18, 2013 at 05:21 PM

78

--

DROP TABLE IF EXISTS ‘node‘;CREATE TABLE IF NOT EXISTS ‘node‘ (‘node_id‘ int(11) NOT NULL,‘node_name‘ varchar(45) DEFAULT NULL,‘node_age‘ int(11) NOT NULL,‘node_weight‘ int(11) NOT NULL,‘node_hauteur‘ int(11) NOT NULL,‘node_location‘ varchar(45) NOT NULL,‘responsable_id‘ int(11) NOT NULL,PRIMARY KEY (‘node_id‘),KEY ‘responsable_id‘ (‘responsable_id‘)

) ENGINE=InnoDB DEFAULT CHARSET=latin1;

---- RELATIONS FOR TABLE ‘node‘:-- ‘responsable_id‘-- ‘responsable‘ -> ‘responsable_id‘--

---- Dumping data for table ‘node‘--

INSERT INTO ‘node‘ (‘node_id‘, ‘node_name‘, ‘node_age‘,‘node_weight‘, ‘node_hauteur‘, ‘node_location‘, ‘responsable_id‘) VALUES(1, ’Andrea’, 65, 55, 167, ’Tokyo’, 1),(2, ’Morinho’, 80, 60, 158, ’Aizuwakamatsu ’, 1),(3, ’Sato’, 77, 65, 162, ’Tokyo’, 1),(4, ’Gomez’, 89, 55, 167, ’Aizuwakamastu’, 1),(5, ’Valdez’, 45, 74, 170, ’Aizuwakamastu’, 1),(6, ’Fabine’, 45, 75, 140, ’Aizuwakamastu’, 1),(7, ’valdez’, 45, 73, 150, ’Aizuwakamastu’, 1),(8, ’Salem’, 72, 62, 162, ’Tokyo’, 1),(9, ’Aakram’, 76, 61, 182, ’Koriyama’, 1),(10, ’Sato’, 87, 75, 152, ’Tokyo’, 1),(11, ’Shneider’, 97, 55, 156, ’Tokyo’, 1),(12, ’Sato’, 77, 45, 178, ’Aizuwakamatsu’, 1),(13, ’Perez’, 79, 75, 188, ’Tokyo’, 1),(14, ’Sato’, 73, 85, 134, ’Tokyo’, 1),(15, ’Bakari’, 57, 65, 189, ’Koriyama’, 1),(16, ’Angela’, 67, 65, 189, ’Tokyo’, 1),(17, ’Fatma’, 77, 58, 167, ’Aizuwakamatsu’, 1),(18, ’Suzuki’, 87, 60, 162, ’Tokyo’, 1),(19, ’Azumi’, 37, 55, 152, ’Tokyo’, 1);

-- --------------------------------------------------------

---- Table structure for table ‘responsable‘---- Creation: Jan 18, 2013 at 05:17 PM--

DROP TABLE IF EXISTS ‘responsable‘;CREATE TABLE IF NOT EXISTS ‘responsable‘ (‘responsable_id‘ int(11) NOT NULL,‘user_id‘ int(11) NOT NULL,‘responsable_name‘ varchar(45) DEFAULT NULL,‘responsable_lastname‘ varchar(45) DEFAULT NULL,‘responsable_age‘ int(11) DEFAULT NULL,‘responsable_sexe‘ varchar(45) DEFAULT NULL,‘responsable_city‘ varchar(45) DEFAULT NULL,‘responsable_phone‘ varchar(45) DEFAULT NULL,‘responsable_email‘ varchar(45) DEFAULT NULL,‘reponsable_adress‘ varchar(45) DEFAULT NULL,‘responsable_fonction‘ varchar(45) DEFAULT NULL,

79

PRIMARY KEY (‘responsable_id‘)) ENGINE=InnoDB DEFAULT CHARSET=latin1;

---- Dumping data for table ‘responsable‘--

INSERT INTO ‘responsable‘ (‘responsable_id‘, ‘user_id‘,‘responsable_name‘, ‘responsable_lastname‘, ‘responsable_age‘,‘responsable_sexe‘, ‘responsable_city‘, ‘responsable_phone‘,‘responsable_email‘, ‘reponsable_adress‘, ‘responsable_fonction‘)VALUES(1, 0, ’achraf’, ’ben’, NULL, NULL, NULL, NULL, NULL, NULL, NULL);

---- Constraints for dumped tables--

---- Constraints for table ‘historic_node‘--ALTER TABLE ‘historic_node‘ADD CONSTRAINT ‘historic_node_ibfk_1‘ FOREIGN KEY(‘node_id‘) REFERENCES ‘node‘ (‘node_id‘);

---- Constraints for table ‘information_node‘--ALTER TABLE ‘information_node‘ADD CONSTRAINT ‘node_id‘ FOREIGN KEY (‘node_id‘)REFERENCES ‘node‘ (‘node_id‘) ON DELETE NO ACTION ON UPDATE NO ACTION;

---- Constraints for table ‘lead‘--ALTER TABLE ‘lead‘ADD CONSTRAINT ‘lead_ibfk_1‘FOREIGN KEY (‘node_id‘) REFERENCES ‘node‘ (‘node_id‘);

---- Constraints for table ‘node‘--ALTER TABLE ‘node‘ADD CONSTRAINT ‘responsable_id‘ FOREIGN KEY(‘responsable_id‘) REFERENCES ‘responsable‘(‘responsable_id‘) ON DELETE NO ACTION ON UPDATE NO ACTION;

80

Interactive Real-time Interface for Smart Health ...web-ext.u-aizu.ac.jp/~benab/publications/theses/Achraf-MS-12/m5151161_2012_MS_thesis.pdftos presented a hardware implementation

Documents