interactive real-time interface for smart health...
TRANSCRIPT
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);
mysql_query("INSERT INTO ‘information_lead‘
VALUES ( NULL , ’2012-12-01 20:10:00’,422 , 1496,’Lead1 I’ ) ");usleep(800000);
mysql_query("INSERT INTO ‘information_lead‘
VALUES ( NULL , ’2012-12-01 20:10:00’,469 , -766,’Lead1 I’ ) ");usleep(800000);
mysql_query("INSERT INTO ‘information_lead‘
VALUES ( NULL , ’2012-12-01 20:10:00’,578 , 39,’Lead1 I’ ) ");usleep(800000);mysql_query("INSERT INTO ‘information_lead‘
VALUES ( NULL , ’2012-12-01 20:10:00’,883 , 104,’Lead1 I’ ) ");usleep(800000);mysql_query("INSERT INTO ‘information_lead‘
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’,23 , 1457,’Lead1 I’ ) ");usleep(800000);
mysql_query("INSERT INTO ‘information_lead‘
VALUES ( NULL , ’2012-12-01 20:10:01’,188 , 52,’Lead1 I’ ) ");usleep(800000);
mysql_query("INSERT INTO ‘information_lead‘
VALUES ( NULL , ’2012-12-01 20:10:01’,484 , 86,’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‘
VALUES ( NULL , ’2012-12-01 20:10:01’,928 , 95,’Lead1 I’ ) ");usleep(800000);
?>
Code 4.3: Live data retrieving.
$(document).ready(function() {
function requestData() {$.ajax ({
type:"get" ,url: "<?php echo CController::createUrl(’ecg/GetSensorsDataLive’) ?>",
data: {"ecgId" : "<?php echo $modelecg[’node_id’] ?>" },dataType: "json",
success: function(point) {
var series = chart.series[0],
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{
public static function model($className=__CLASS__){return parent::model($className);
}
public function tableName(){
return ’information_node’;}
}
Code A.3: Model for table responsible (Responsible.php)
<?php
53
class Responsible extends CActiveRecord{
public static function model($className=__CLASS__){return parent::model($className);
}
public function tableName(){
return ’responsable’;}
}
Code A.4: Model for table lead (Sensor.php)
<?php
class Sensor extends CActiveRecord{
public static function model($className=__CLASS__){return parent::model($className);
}
public function tableName(){
return ’lead’;}
}
Code A.5: Model for table information lead (SensorInfo.php)
<?php
class SensorInfo extends CActiveRecord{
public static function model($className=__CLASS__){return parent::model($className);
}
public function tableName(){
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" />
<!-- blueprint CSS framework --><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" /><!--[if lt IE 8]><link rel="stylesheet" type="text/css" href="<?php echo Yii::app()->request->baseUrl; ?>/css/ie.css" media="screen, projection" /><![endif]-->
<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 id="logo"><?php //echo CHtml::encode(Yii::app()->name); ?></div> -->
</div><!-- header -->
<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><!-- mainmenu --><?php if(isset($this->breadcrumbs)):?><?php $this->widget(’zii.widgets.CBreadcrumbs’, array(’links’=>$this->breadcrumbs,
)); ?><!-- 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><!-- footer -->
</div><!-- page -->
</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">
$(document).ready(function() {
$(".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">
$(document).ready(function() {
function requestData() {$.ajax ({
type:"get" ,url: "<?php echo CController::createUrl(’ecg/GetSensorsDataLive’) ?>",
data: {"ecgId" : "<?php echo $modelecg[’node_id’] ?>" },dataType: "json",
success: function(point) {
var series = chart.series[0],
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><!-- form -->
<?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><!-- form -->
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’];
$modelecg=ecg::model()->findBySql(’SELECT * FROM node where node_id = "’.$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.’";’);
foreach ($sensorsIds as $s){
$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’];
$modelecg=ecg::model()->findBySql(’SELECT * FROM node where node_id = "’.$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.’";’);
foreach ($sensorsIds as $s){
$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‘)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;
---- 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‘)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=2 ;
---- 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