Sistema Embebido para Aplicacoes Biomedicas
Rui Miguel Marme Ramalho
Dissertacao para obtencao do Grau de Mestre emEngenharia Electrotecnica e de Computadores
JuriPresidente: Doutor Jose Antonio Beltran GeraldOrientador: Doutor Leonel Augusto Pires Seabra de SousaVogais: Doutor Bertinho Manuel D’Andrade da Costa
Setembro de 2008
Acknowledgments
Firstly, I would like to thank my supervisor, Doutor Leonel Sousa, for entrusting me with this
project. His vision was an inspiration throughout this work, and his availability to answer questions
is commendable. Another very special thanks goes to MSc. Jose Germano, who was a de facto
co-supervisor. His commitment to this project and his availability to discuss the problems that
inevitably arise are both praiseworthy.
I would also like to thank all the people from the SiPS group at INESC-ID, who welcomed me
into their midst with open arms, and whose help was invaluable to the successful completion of
this thesis.
My academic life was filled with ups and downs, with questions and answers, with hard work
and light hearted fun. Through all these times there was one constant: colleagues. During both
good and trying times, the people I have met during the course were always there, always ready
to raise an unthought question, to answer a tough question, to debate an issue, or simply to make
a witty remark. They certainly made college a more interesting and pleasant place to be. Many
thanks to all of you.
Lastly, I would like to thank my family, who have given me the opportunity to attend college
and have been a source of support and encouragement throughout my whole life.
Abstract
This document presents a modular, generic architecture for biomedical applications. It was
designed to incorporate seamlessly and transparently different biomedical solutions from different
developers, ranging from sensing devices to data processing software. The architecture itself
consists on three tiers. The lowest tier harbors the sensors, the middle tier houses an user
interface and the top tier stores the acquired data. The lower tier is comprised of two blocks:
a sensing and processing module, which holds the sensors themselves, and an autonomous
communication module, which acts as an interface between the sensors and the middle tier.
This architecture was prototyped in a movement monitoring system and in a biomolecular
recognition system. The prototypes are not only capable of acquiring data with their specialized
sensors, but also forward it, through wired or wireless links to a database running on a remote
computer. The data then, is made available through web services and web browsers. The device
in the middle tier, a personal digital assistant, is capable of displaying the acquired data in a
graphic in real-time. As part of this thesis, several software techniques were identified and tested
for increasing the system’s autonomy, resulting in an increase of up to 80%.
Keywords
Modular and generic architecture, biomedical applications, wireless communication, graphical
user interface, web services, remote database.
iii
Resumo
Este documento apresenta uma arquitectura modular e generica para aplicacoes biomedicas.
Foi projectada de forma a incorporar de forma simples e transparente diferentes solucoes bio-
medicas, desde sensores ate software, de diferentes fabricantes. A arquitectura e constituıda
por tres camadas. A primeira inclui os sensores, a segunda controla todo o sistema servindo
de interface entre a primeira e a terceira, enquanto a terceira armazena e processa os dados
adquiridos. A primeira camada encontra-se ainda subdividida em dois modulos: sensing and
processing module, onde estao os sensores, e autonomous communication module, que serve
de interface entre os sensores e a segunda camada.
Esta arquitectura foi prototipada num sistema de monitorizacao do movimento e num sistema
de reconhecimento biomolecular. O prototipo e capaz de nao so adquirir dados atraves dos seus
sensores especializados, mas tambem de os enviar para uma base de dados existente num servi-
dor remoto atraves de comunicaoes com e sem fios. Os dados sao depois disponibilizados via
web services e web browsers. O dispositivo na segunda camada, um personal digital assistant,
e capaz de gerar um grafico em tempo real com os dados adquiridos. Durante esta tese foram
ainda identificadas tecnicas em software para aumentar a autonomia do sistema, obtendo-se
melhorias de 80%.
Palavras Chave
Arquitectura generica e modular, aplicacoes biomedicas, comunicacao sem fios, interface
grafica do utilizador, web services, base de dados remota.
v
Contents
1 Introduction 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Objectives and Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Dissertation Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 State of the Art 5
2.1 Biomedical Digital Assistants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Advanced Medical Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Personal Care Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Assisted-Living And Residential Monitoring Network . . . . . . . . . . . . . . . . . 10
2.5 Wearable Health Monitoring Systems . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6 The proposed system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3 Platform Architecture 13
3.1 Biomedical system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.1 Sensing and Processing Module . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.2 Autonomous Communication Module . . . . . . . . . . . . . . . . . . . . . 16
3.2 Master Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Remote Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4 Comparison of the Proposed Architecture with the State of the Art . . . . . . . . . 20
4 Prototyping of Biomedical Systems 25
4.1 Autonomous Communication Module . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.1 Lowering power consumption . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2 Communication Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.4 Sensing and Processing Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4.1 Biochip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4.2 Movement Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.5 Master Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
vii
Contents
4.5.1 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.5.2 Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.5.3 Data Displaying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.6 Remote Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.6.1 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.6.2 PHP Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5 Experimental Results 45
5.1 Experimental Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.2 Autonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2.1 Autonomous Communication Module . . . . . . . . . . . . . . . . . . . . . 47
5.2.2 Sensing and Processing Modules . . . . . . . . . . . . . . . . . . . . . . . 49
5.3 Data Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.4 Master Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.5 Remote Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.6 Detection of Biomolecules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6 Conclusions 55
6.1 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
A ACoM library documentation 63
A.1 Communication with the Master Device . . . . . . . . . . . . . . . . . . . . . . . . 64
A.2 Communication with SPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
B Master Device library documentation 73
B.1 Communication Namespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
B.1.1 Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
B.1.2 Communicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
B.2 Graphic Namespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
B.2.1 GraphPoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
B.2.2 ListData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
B.2.3 ListGraphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
B.2.4 GraphMotor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
viii
List of Figures
2.1 AMON system architecture, source [1] . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 PCC system architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 ALARM-NET system architecture, source [2] . . . . . . . . . . . . . . . . . . . . . 10
2.4 Wearable Health Monitoring System architecture, source [3] . . . . . . . . . . . . . 12
3.1 Architecture of the biomedical system. . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Architecture of the embedded system. . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3 Architecture of the master device. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4 Remote server’s architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1 Autonomous communication module . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2 Packet structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3 Read/Write package procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.4 Biomolecular recognition process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.5 Biomolecular recognition SPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.6 Movement monitoring SPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.7 Stored classes in the Master Device . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.8 Program flow in a typical use of the graphics component . . . . . . . . . . . . . . . 38
4.9 Setting up the graphics component . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.10 Picture with an example plot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.11 Structure of the database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.12 Methods provided by the server webservice . . . . . . . . . . . . . . . . . . . . . . 42
4.13 Plain HTTP interface for the biochip system . . . . . . . . . . . . . . . . . . . . . . 43
5.1 The complete system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.2 Graphical User Interface: Serial Port Configuration . . . . . . . . . . . . . . . . . . 51
5.3 Graphical User Interface: Real-time graphic display . . . . . . . . . . . . . . . . . . 51
5.4 Plain HTML interface to the Remote Server . . . . . . . . . . . . . . . . . . . . . . 52
5.5 Result of a biorecognition experiment . . . . . . . . . . . . . . . . . . . . . . . . . 53
ix
List of Figures
x
List of Tables
5.1 Autonomy test results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2 Impact of encryption in autonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.3 Autonomy Improvement for the Biochip SPM . . . . . . . . . . . . . . . . . . . . . 49
5.4 Autonomy improvement for the accelerometer SPM . . . . . . . . . . . . . . . . . . 49
5.5 Effective data rate in bytes per second . . . . . . . . . . . . . . . . . . . . . . . . . 50
xi
List of Tables
xii
List of Acronyms
ACoM autonomous communication module
ADC analog to digital converter
AES advanced encryption standard
ALARM-NET assisted-living and residential monitoring network
AMON advanced medical monitor
API application programming interface
ASCII american standard code for information interchange
CAR circadian activity rhythm
CPU central processing unit
DAC digital to analog converter
DBMS database management system
DCM duty cycle modulated
DNA deoxyribonucleic acid
DSP digital signal processor
ECG electrocardiogram
EDR enhanced data rate
GSM/GPRS global system for mobile communications/general packet radio service
GSM global system for mobile communications
GUI graphical user interface
HTML hypertext markup language
HTTP hypertext transfer protocol
xiii
List of Acronyms
HTTPS secure hypertext transfer protocol
I2C inter-integrated circuit
IP internet protocol
MIPS million instructions per second
PAN personal area network
PCB printed circuit board
PCC personal care connect
PDA personal digital assistant
PHP PHP: Hypertext Preprocessor
PIC programmable intelligent computer
PPG photoplethysmograph
SMS short message service
SOAP simple object access protocol
SPI serial peripheral interface
SPM sensing and processing module
SRP secure remote password protocol
SSL secure socket layer
TCP/IP transmission control protocol/internet protocol
UART universal asynchronous receiver transmitter
USB universal serial bus
VPN virtual private network
WISE wireless intelligent sensors
XML extensible markup language
xiv
1Introduction
Contents1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Objectives and Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Dissertation Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1
1. Introduction
In the recent years there has been a growing interest in biological and medical applications
supported on the capabilities of sensor networks. This thesis revolves around a platform designed
to be a generic framework where developers can build their innovative biomedical applications.
1.1 Motivation
The recent years have seen a rise in the interest on biological and medical areas. People are
now more aware of both health and quality of life issues than they have ever been. This euphoria
quickly spread to other areas of society creating huge opportunities in the integration of areas
previously considered disjunct. In particular, the area concerning sensors and sensor networks
has an enormous potential. The emergence of these new applications related to biomedicine
has created a wealth of information that needs to be extracted and processed in order to become
useful, hence the importance of sensors as cornerstones in these new fields. Sensors and sensor
networks are also the building blocks of a very promising area, remote monitoring. With the
increased prevalence of chronic diseases, and the ageing of the global population, there has
been a growing interest in remote medical monitoring systems. Such systems allow people who
need to be monitored by health professionals to be so, in the comfort of their houses instead of
a hospital, clinic or nursing home. These systems allow people to have a more autonomous life,
in a familiar environment, while being monitored by medical professionals, which increases their
quality of life without degrading their healthcare quality.
So far the majority of the development in the area of sensor networks for biomedical applica-
tions has relied mostly on solitary efforts. Every developer must develop the full scope of their
applications, using in many cases proprietary technology in the process. The lack of standards in
the area mirrors this fact. The consequence of this state of affairs is that the development costs
more and takes a longer time to finish. Furthermore, having to develop every portion of a solu-
tion, disperses developers’ focus, preventing them from focusing on their core areas, the areas
where they really excel. The development of a unifying framework, an architecture suitable for a
great range of biomedical applications upon which developers can build their solutions, would be
a great aid for the developers. Developers would be able to focus on what’s really important: their
innovative ideas for new biomedical applications, instead of wasting time reinventing the wheel.
Such a platform would be an asset for all the stakeholders involved. A whole new market segment
would open, centered around the development, manufacturing and marketing of these platforms.
As these unifying platforms can be a common element for many applications, it would be possible
for them to be mass produced. The scale economies associated with mass production would
drive down the costs (and prices) of the biomedical solutions, resulting in a cost reduction for
both patients and medical providers, making them more competitive. Furthermore, the use of the
framework will allow the vendors of biomedical solutions to focus on what they do best, their core
2
1.2 Objectives and Contributions
competencies, resulting in an increased efficiency, further driving down the costs and increasing
competitiveness.
The development of such unifying platform is a humongous challenge, as the biomedical ap-
plications that currently exist are many and varied. Such platform needs to accommodate the
currently existing solutions, and be flexible enough so that it might respond to the challenges
posed by tomorrow’s solutions.
1.2 Objectives and Contributions
The grand objective of this project, and consequently of this thesis, is to build a portable
modular framework upon which different biomedical solutions can be developed. In order to be as
inviting as possible for independent developers, this framework needs to be very extensible and
flexible. It must be easy to customize to respond to each application’s specific needs.
The operational objectives for this thesis are more modest, however. Having the hardware
components that make up the system been prototyped before the beginning of this thesis, the
only major challenge left was to integrate them into a cohesive whole. This includes choosing and
implementing communication protocols so that these components can communicate amongst
themselves. To make the system more attractive for developers, the communication protocols
should be flexible and standards based. With the completion of this step the prototype system is
minimally functional.
As the proposed system is portable, possibly even battery powered, it is important to ensure
it uses its battery’s energy as efficiently as possible. Another objective of this thesis is to study
software techniques for lowering power consumption that can further increase the autonomy of
the battery powered, portable system.
When transmitting medical data, security and privacy are always important concerns. As this
system is being developed having in mind biomedical applications it is imperative that steps are
taken to protect sensitive information. Part of this thesis consists on the implementation of a
cryptographic module, to assure secure communications within the system. Another important
facet of this work was the development of a user interface in a hand-held device (personal digital
assistant (PDA)). This graphical user interface (GUI) not only provides an interface from which a
human user can communicate with the system, but is also capable of displaying the data being
acquired during a measurement in a simples scatter plot in real time. This is an important feature,
as it gives the user feedback on the measurement as it happens, allowing the user to take action
as the problems occur, rather than having to wait until the measurement is complete and the data
processed.
3
1. Introduction
1.3 Dissertation Outline
This dissertation is organized in 6 chapters, that are introduced next. Chapter 1 introduces the
void this work is trying to fill. It also lists the objectives of this thesis, as well as the contributions
made by the author. In chapter 2 it is presented a number of related work described in the liter-
ature. In chapter 3 the proposed architecture is exposed and detailed. The architecture’s main
components are also disclosed in this chapter. This includes the autonomous communication
module, the Master Device and the Remote Server’s architecture. In this chapter it is also made a
comparison between the architectures proposed in the literature, and exposed in chapter 2, and
the architecture proposed in this thesis. Chapter 4 presents the details of the prototype imple-
mentation of the architecture presented in chapter 3. In this chapter, and in accordance to the
objectives described in section 1.2, several software techniques for lowering power consumption
are also presented. The performance of the prototype described chapter 4 was measured, being
the results presented in chapter 5. This includes the results of the experimental evaluation of
the techniques for lowering power consumption presented in chapter 4, as well as snapshots of
the rest of the system (Master Device, Remote Server) working. Lastly, chapter 6 concludes this
dissertation and a number of possible future improvements on this work are enumerated.
4
2State of the Art
Contents2.1 Biomedical Digital Assistants . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Advanced Medical Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Personal Care Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4 Assisted-Living And Residential Monitoring Network . . . . . . . . . . . . . . 102.5 Wearable Health Monitoring Systems . . . . . . . . . . . . . . . . . . . . . . . . 112.6 The proposed system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5
2. State of the Art
An aging society has lead to a growing interest in ubiquitous healthcare monitors, supported
on the ever growing capabilities of sensor networks. The following sections present some of the
developed research projects in this area.
2.1 Biomedical Digital Assistants
Tae-Soo Lee et al. [4] proposed a biomedical digital assistant based on a personal digital
assistant (PDA) or a mobile phone. The prototype presented by Tae-Soo Lee is capable of not only
measuring heart rate and respiratory activity, but also monitoring the patients movement state.
The heart rate is determined by an electrocardiogram (ECG) sensor implemented in a necklace-
type accessory. The movement monitoring was performed by a 3 axis acceleration sensor, also
set up on the necklace device. Both of these sensors used a Zigbee communication controller to
communicate with the biomedical digital assistant (PDA or mobile phone). Another sensor devel-
oped for this prototype was a bracelet-type photoplethysmograph (PPG) wireless sensor. A 3-axis
acceleration sensor was also added to the bracelet in order to monitor the wearer’s movement.
As with the necklace ECG sensor, this bracelet communicates with the biomedical digital assis-
tant (PDA or mobile phone) through a Zigbee connection. Additionally, a pedometer was also
implemented out of a printed circuit board (PCB) with a 3-axis acceleration sensor connected
to the mobile phone. All of these sensory devices were optimized to perform continuous mea-
surements for 24 hours, without the need to recharge the battery. This optimization was done
at the hardware level by using low power consumption components: microcontroller, amplifiers
and communication controllers where carefully chosen for their power consumption characteris-
tics. The biomedical digital assistant not only collects the data provided by these sensors, but
also processes it in real-time. When an anomalous situation is found, the assistant is capable of
issuing an alarm message to a remote server through the cellular phone network.
2.2 Advanced Medical Monitor
Urs Anliker et al. implemented a ubiquitous remote medical monitor, the advanced medical
monitor (AMON) [1]. This device, specifically targeted at high-risk cardiac or respiratory patients,
continuously monitors several signals of medical relevance.
The Fig. 2.1 depicts the architecture presented by Urs Anliker. It is comprised of two modules:
a wrist-worn sensor apparatus and a remote telemedicine center. The wrist-worn sensor is capa-
ble of measuring blood pressure, oxygen saturation and a one lead ECG. The accurate measure
of the blood pressure at the wrist requires the wearer to position the device at the same level as the
heart, making continuous monitoring of blood pressure uncomfortable. The ECG measurement
is even worse, requiring the wearer of the device to maintain a cumbersome position throughout
the measurement. Aside from these signals, the AMON bracelet possesses a 2-axis accelerom-
6
2.2 Advanced Medical Monitor
Figure 2.1: AMON system architecture, source [1]
eter, allowing it to measure activity, and correlate it with the remaining biomedical signs, and a
temperature sensor. The temperature sensor can be useless for medical applications, as there
is no known relation between wrist temperature and the core body temperature. The bracelet’s
interface can be extended to accommodate a few more external sensors, including a full 12 lead
ECG.
The wrist worn AMON bracelet also analyzes the data in real time and is capable of issuing
warnings when an emergency situation is detected. The bracelet has a built in global system
for mobile communications (GSM) transceiver, allowing it to use the mobile phone network to
communicate with the telemedicine center, where specialized physicians and technicians analyze
the data. The bracelet can use several communication media: short message service (SMS),
virtual circuit switched communication channel, establishing a real-time connections between the
telemedicine center and the AMON bracelet, through a mobile phone link. The real-time link is
particularly important during emergencies when the medical personnel at the telemedicine center
need to know what is happening to the patient in real time. Lastly, the device can also commu-
nicate using transmission control protocol/internet protocol (TCP/IP) through the internet. The
communication is secured by authenticating and encrypting the data. It is used the authentication
and encryption provided by the global system for mobile communications/general packet radio
service (GSM/GPRS) protocol.
Unfortunately, the experimental results fell short of the expectations. Although the blood pres-
sure sensor could accurately measure the systolic pressure, the same could not be said about the
diastolic pressure. The oxygen saturation sensor proved to be unreliable. The high noise levels
in the device prevented any useful information from being drawn from the one lead ECG sensor,
including heart rate. However, the heart rate was accurately measured using the information from
the blood pressure sensor. These experimental observations allow to conclude that the signal
acquisition/processing part of the system is crucial for its performance.
7
2. State of the Art
2.3 Personal Care Connect
In an effort to facilitate remote monitoring of chronic patients, Blount et al. developed personal
care connect (PCC) [5]. More than a mere remote monitoring device, PCC is in fact a whole
architecture for the development and deployment of remote monitoring systems. It was developed
having in mind five important aspects: patient usability, scalability, reliability, extensibility and
financial resources. Usability is always an important aspect, especially if the people using the
device are not experts, such as patients. Scalability is an important feature. The system should
be prepared for a growing number of monitored patients, with a growing number of measured
biomedical signals. All devices should be reliable, but the need for reliability is greatly reinforced
when tackling human health and safety challenges. As this projects goal is to provide a platform
upon which both sensor manufacturers and software vendors can integrate their products, the
system needs to be fairly extensible. Not only to accommodate the existing kinds of sensors and
processing software, but especially to accommodate future devices and software. Lastly, such
device must be available cheaply if it is to hit the masses.
Wireless Sensor
WirelessSensor
WirelessSensor
Internet
Data Collection Hub
Data Collection Hub
Server
Database
Bluetooth
Bluetooth
Bluetooth
WWAN
WWAN
Tier 1 Tier 2 Tier 3
Figure 2.2: PCC system architecture
The architecture, whose schematic representation is depicted in Fig. 2.2, is structured in three
tiers. The lowest tier is comprised by the sensing devices, which communicate their readings to
an intermediate level device, a data collection hub. The hub is responsible for collecting data from
several sensor devices, and forwards it to a server on the upper tier, where it is accessible to be
processed by both medical applications and health professionals. The goal of this architecture
is to become an open, standards-based platform, upon which developers can implement their
biomedical monitoring solutions. The tiered architecture allows vendors to focus on only one of
8
2.3 Personal Care Connect
the ends of the system (developing new sensors or data processing applications), reducing the
development costs and decreasing time to market.
Sensing devices in the lowest tier can be pretty much anything, their only requirement is that
they communicate with the middle tier hub through a bluetooth link. According to the authors,
bluetooth was chosen as it is a widely used standard in consumer electronics. Secure and private
communication between the sensor devices and the hub device is ensured by the bluetooth’s
pairing, authentication and link encryption.
The cornerstone of this architecture is the data collection hub in the middle tier. This device
receives data from the sensor devices in the lower tier using bluetooth and forwards it to a server
in the top tier. The hub device can be either a PDA, a mobile phone or any other device with
bluetooth and internet connectivity. The current prototype version of PCC uses a mobile phone.
The hub is implemented in a blackboard-like structure, making it very extensible to new applica-
tions. In a blackboard communication model there are two kinds of application components: a
blackboard and several agents. The agents are completely isolated from one another, not even
aware of the other agents’ existence. The only means of communication they have available is
posting data on the blackboard and retrieving data from the blackboard. Thus, the blackboard is
the only commonly accessible area to all agents. The agents can only affect each other’s behav-
ior by changing the input data on the blackboard. This obliviousness makes adding, removing
or replacing agents a simple local matter, with little implications for the remaining agents. The
blackboard is also a scheduler, as it decides which agent will be the next to run and operate over
the data in the blackboard.
A top tier server interacts with several data collection hubs through an internet-based con-
nection. The current prototype of PCC uses hypertext transfer protocol (HTTP). The server is
a database and a set of applications processing the information it contains. To address the ex-
tensibility premise the server is not only prepared to communicate with the data collection hub
that was developed for this project, but it can in fact communicate with any hub device. To that
end hub devices are classified into families, each interacting with the server through an internet
based connection. As each of these families can follow different protocols it becomes necessary
to implement in the server a hub-specific adapter. Another required element of this database is
a data normalizer. As the server can interact with innumerous kinds of hub devices, which can in
turn interact with innumerous kinds of biomedical sensors, it becomes necessary to convert the
data into de database’s internal representation structures. This normalization makes it easier for
third party applications to operate on the collected data. The communication between the data
collection hub and the server is secured by the many internet-based secure technologies present
nowadays, namely secure hypertext transfer protocol (HTTPS), secure socket layer (SSL) or vir-
tual private network (VPN). The present version of the PCC prototype uses a VPN to ensure
secure communications. Currently the PCC project has no privacy control mechanism, but it is a
9
2. State of the Art
foreseen addition to the future versions of PCC.
2.4 Assisted-Living And Residential Monitoring Network
Wood et al. describe in [2] a wireless sensor network for assisted-living and residential moni-
toring network (ALARM-NET). ALARM-NET is a rather complex architecture, integrating several
heterogeneous devices into a single remote monitoring network. This network is comprised of
mobile body networks, emplaced sensor networks, AlarmGates, back-end systems and user in-
terfaces as can be seen in Fig. 2.3.
Figure 2.3: ALARM-NET system architecture, source [2]
Mobile body networks are a network of wireless sensor devices worn by a resident. These
sensors vary from person to person according to their needs. The current prototype supports a
pulse, blood oxygenation, ECG and acceleration sensors. These sensors are built on top of the
commercially available MICAz wireless measurement system [6]. Mobile body networks can also
contain a user interface, the SeeMote [7]. Data collected by the body network is forwarded to the
back end servers and user interfaces through the emplaced sensor network. Emplaced sensor
networks are a set of immobile networks that not only sense environmental data, but also form a
multi-hop wireless network that interconnects the various sensors (both emplaced and body net-
works) and the AlarmGates. The developed emplaced sensors for this project are temperature,
dust, light and motion sensors. As the emplaced sensors are not supposed to be mobile they can
be either battery powered or wire powered. AlarmGate applications manage the whole system
10
2.5 Wearable Health Monitoring Systems
and act as intermediaries between the wireless sensor networks and the internet protocol (IP)
networks. The various AlarmGates communicate with each other through IP networks. Alarm-
Gates are responsible for managing system queries, privacy, power consumption, and security.
Back-end systems store the sensors data in a database, and analyze its contents. Finally, the
user interfaces allow anyone with legitimate access to query the system for sensor information.
One of the most important and unique back-end application is a circadian activity rhythm (CAR)
analyzer [8]. This application uses the data collected from the sensors to statistically predict the
residents’ rhythmic behavioral activity. This information is then used to detect anomalies in the
patients’ routine life and to aid the system’s privacy and power manager modules. The privacy
manager can dynamically change the privacy policies according to the context. With such a
system it is possible for the data collected from a patient only be revealed to medical personnel
and in the event of an emergency. The power manager is similarly able to dynamically adjust its
behavior to the routines and habits of the residents’. Using the information about the residents
routines provided by the CAR analyzer, and power management policies defined by the system’s
administrator, the power manager adapts the operational state of each of the sensors in the
network, minimizing power consumption.
Security is an important feature of ALARM-NET. In order to protect the privacy of the mon-
itored residents all users that access the system are authenticated. Furthermore, any data that
travels in the system is encrypted. For encryption purposes advanced encryption standard (AES)
is used by both the wireless sensor network and the IP network. For authentication it is used the
secure remote password protocol (SRP) [9] on the IP network. On the wireless sensor network,
authentication is achieved using CBC-MAC [10], or CCM [11] with AES.
2.5 Wearable Health Monitoring Systems
Emil Jovanov et al. developed a remote monitoring architecture supported in wireless intelli-
gent sensors (WISE) [12]. Jovanov proposes the hierarchical architecture organized in three tiers
depicted in Fig. 2.4.
At the lower tier lie the WISE sensors. These sensors communicate with a personal server
in the middle tier, using wireless technologies. The personal server then communicates with a
telemedical server at the upper tier, again using wireless technologies. WISE sensors are capable
of acquiring local data and simple signal processing (filtering for example). The structure of the
WISE sensor is comprised by a programable microcontroller, a wireless transceiver, a biomedical
amplifier, and an A/D converter. The WISE are not specific to any particular measurement, being
able to interface any analog biomedical sensor. The personal server acts as a master of the WISE
slaves. The personal server has the responsibility of managing the personal area network (PAN),
of storing the collected data, of providing a user interface. The prototype described in [12] can
11
2. State of the Art
Figure 2.4: Wearable Health Monitoring System architecture, source [3]
measure ECG, breathing and movement signals, and uses a digital signal processor (DSP) board
as a personal server. A more recent version of the wearable health monitoring system is presented
in [3]. One of the most significant changes in the system’s architecture is the replacement of the
custom made DSP based PCB personal server by a more generic one, a mobile phone or a PDA.
2.6 The proposed system
In this thesis it is proposed a generic modular data acquisition system designed for biomedi-
cal applications. The main goal is to provide an open generic, modular system, upon which new
biomedical applications can be developed. The system should use standards wherever possible,
and keep its components as independent from one another as possible. It should also be flexible
and easy to modify, in order to make the development of new biomedical applications as simple
as possible. In order to not restrict developer’s design choices, it should be a portable system,
incorporating wireless technologies to make it as unobtrusive as possible. Moreover, the archi-
tecture of the system and the individual modules should be designed having in mind low energy
consumption, and low cost.
This project differs from the ones listed above in a number of aspects, both in its goals and im-
plementation aspects. In the next chapter we discuss the main difference of the system proposed
in this thesis regarding the ones previously referred in the state of the art sections.
12
3Platform Architecture
Contents3.1 Biomedical system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2 Master Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3 Remote Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.4 Comparison of the Proposed Architecture with the State of the Art . . . . . . 20
13
3. Platform Architecture
The architecture is divided in three tiers, as can be seen in Fig. 3.1. At the lowest tier lies the
sensor itself. This tier is also capable of some data processing. The middle tier’s primary function
is to manage the local system of lower tier sensors. With this purpose, it communicates with the
nearby sensors, collects and aggregates the data they produce and sends it to a database located
in the upper tier. As the devices in this middle tier will be managing the system, they also require
a user interface upon which a user can access and control the system. The upper tier is mostly
responsible for the proper storage of the acquired information. At its core this tier has a database.
However, as a more computationally capable platform this tier will provide an environment where
more computationally demanding applications can run and operate over the collected data. It is
noteworthy that the computationally capabilities of these devices rises as one climbs this three
tiered structure.
Internet
Database and Web Server
Embedded System 11Master 1
Master M
Embedded System M1
...
Embedded System MK
Figure 3.1: Architecture of the biomedical system.
3.1 Biomedical system
In the lowest tier lies the biomedical measurement system per se. It is this system that will
perform the actual measurements. The system is comprised of two subsystems, the sensing
and processing module (SPM) and the autonomous communication module (ACoM), as depicted
in Fig. 3.2. This architecture was chosen, according to the scope of this project, as a way of
simplifying the development of new sensors and covering different applications whilst giving the
developers the maximum degrees of freedom. The SPM is the platform actually custom built for
every sensor, according to its needs, whilst the ACoM addresses the sensor’s need to commu-
nicate with the Master Device in the middle tier. The ACoM remains the same for every sensor
type, however its programable nature allows the developer to change the way it operates to take
into account the specific needs of each class of biomedical applications.
14
3.1 Biomedical system
Sensing and Processing Module (SPM)
Master
Biological or Biomedical System
Power Manager
Autonomous Communication Module (ACoM)
Cryptographic Engine
Com. Module
Data Formatter......
Com. Module
Data Transfer Manager
SerialData
Wire
Wireless
Bio-sensor
SignalProcessor
SensorInterface
Device
Figure 3.2: Architecture of the embedded system.
3.1.1 Sensing and Processing Module
The SPM is the only component whose hardware is custom built for each sensor. As such
the generic architecture presented in Fig 3.2 is flexible and does not restrict any development
choices. The SPM not only harbors the sensor but also acquires the sensor’s signal, processes
and formats the data acquired and forwards it to the rest of the system through the ACoM.
Data Formatter
The only strict requirement of the SPM is that it communicates with the ACoM in a standard
way. That is where the Data Formatter comes in. The data formatter is responsible for the se-
rialization of the transmitted data, and its transmission according to the chosen protocol. The
data formatter can be implemented directly by a digital signal processor (DSP), which has the
advantage of increasing the SPM’s flexibility, by reprogramming the DSP. Furthermore, it would
be possible to create synergies between the data formatter and the signal processor, by using the
same DSP to both format the data and process it.
Signal Processor
Although not a strict requirement in the design of an SPM, a digital signal processor can be
a valuable addition to any SPM. The presence of a programable digital processor will not only
make the SPM a more flexible platform, but it will also allow data to be, to some extent, locally
processed. Local processing of data diminishes the amount of bandwidth required to transmit it.
Biosensor
The need for a biosensor is fairly obvious, but it can be pretty much any kind of sensor, namely
sensors for: biomolecular recognition, motion, temperature, cardiac rhythm, blood pressure, oxy-
15
3. Platform Architecture
gen saturation, electrocardiogram (ECG).
Sensor Interface
Not a strict requirement, a Sensor Interface is a common element amongst most sensing
platforms. Its responsibilities include interacting directly with the sensors, and performing the
conditioning of the acquired signals. Typically acquired signals will need to be amplified, so a
signal amplifier is usually required. As for the remainder of the system the acquired signals will
be manipulated in digital format, therefore the sensor interface block should also have an analog
to digital converter (ADC).
3.1.2 Autonomous Communication Module
The ACoM’s primary function is to communicate with both SPM and Master Device. The ACoM
also isolates the sensor in the SPM from the rest of the system. It provides an interface to both
SPM and Master Device. To keep the ACoM as generic as possible, it should communicate with
SPMs through standard serial interfaces and with master devices through standard wire and wire-
less communication systems. Security can be an issue when transmitting sensitive biomedical
data. To be effectively protect the data security has to be a concern throughout all the the system.
The ACoM, as the first step of the data’s journey, must take the necessary steps to protect such
information.
Data Transfer Manager
At the core of the ACoM there is the transfer manager. This block is responsible for managing
the communication with both SPM and master devices. It is up to the transfer manager to not
only decide which communication medium will use, but also to format the messages according to
the chosen transmission protocol. Being the scope of this project to develop a generic acquisition
platform upon which new biomedical applications can be easily developed, the ACoM should be
easily customizable. As such this transfer manager should be flexible enough to allow different
protocols to be chosen, even be dynamically changed at run-time.
Communication Modules
The communication modules existing in an ACoM can be many and varied. Each of these can
be either wired or wireless. Nonetheless, in accordance with the scope of this project, they need
to be standard communication systems such as universal serial bus (USB) or Bluetooth to name
few. Communication modules must support different standard serial communication schemes,
providing the corresponding interfaces and implementing the required protocols to communicate.
16
3.2 Master Device
Power Manager
Since this architecture was developed having a battery-powered portable device in mind, the
efficient management of the energy consumption is crucial in order to maximize the system’s au-
tonomy. That’s the function of the power manager: not only manage the energy consumption of
the device, but also monitor the state of charge of the battery and control its recharge. Further-
more, the SPM might also be powered by the ACoM. If that is the case, then the power manager
also has to manage the power that is supplied to the SPM. Since power sources can be a great
source of noise, the power manager should have the ability of cutting off external power supply,
relying only on the battery, for the duration of a sensitive measurement.
Cryptographic Engine
Since not all communication mediums can be deemed safe, and biomedical data can have
a sensitive nature, it becomes imperative to assure data security and privacy over these unsafe
links. The cryptographic engine addresses this need by encrypting any sensitive data before send-
ing it to a remote master. Both symmetric and asymmetric encryption algorithms can be used. As
the scope of this project requires the system components to be as generic as possible, in order
to not restrict the developers’ freedom, the encryption module should be made in software. That
way it is relatively easy to switch it off, if it isn’t needed, or even completely replacing its encryption
algorithm by another, if the one previously available does not suit a particular application’s needs.
3.2 Master Device
The master device is a more general purpose computer, laptop, personal digital assistant
(PDA) or a mobile phone, and exerts full control of the embedded system. As a controlling agent,
its primary function is to provide an interface between a user and the embedded system. This
interface must be customized in order to interact with all types of SPMs. However, a set of func-
tionalities can be identified as common amongst most biomedical SPMs. The Master Device must
communicate with the SPM, through the ACoM, as well as the remote server. It must also be able
to store and retrieve data from both a remote database, in the remote server, and from a local
repository. Another key functionality of the master device, is the ability to display the received
data in real-time. This is important as it allows the user to know in real-time what is happening in
the system. Lastly, the Master Device must guaranty the safety and privacy of the sensitive data
that travels through it. This includes encrypting and decrypting data coming and going from the
Master Device. Fig. 3.3 presents a schematic representation of the Master Device’s architecture.
17
3. Platform Architecture
Figure 3.3: Architecture of the master device.
User Interface
The User Interface is the core of the Master Device. As the Master Device’s primary function
is to control and manage the rest of the system, it must provide a user with means to exert this
control. As it requires human intervention, the user interface should be designed to be as intuitive
as possible, and hide all unneeded details that might confuse the user. In other words it should
be kept simple and its usage intuitive in order to increase its intelligibility. This component is
application specific, and as such it needs to be customized for each class of application.
Communication Manager
In order to control the embedded biomedical system, the Master Device must communicate
with it. That’s the purpose of the Communication Manager, to communicate commands and data
to and from the ACoM. It is the Communication Manager’s responsibility to enforce the communi-
cation protocol. The Communication Manager is subject to change, for example at transmission
protocol level, so it must be easy to modify.
Database Client
The Master Device must be able to store and retrieve data from a database. Since the Master
Device has very limited resources it is implausible to think that it will have the capabilities required
to store and manipulate a significant amount of data acquired in biomedical applications. It be-
comes necessary to store this information in a remote server. The Database Client manages the
communication between the Master Device and the Remote Server.
18
3.3 Remote Server
Security
Transversally to the Communication Manager and Database Client is the Security block. As
the communication channels might not be safe, any sensitive data traveling through them needs
to be encrypted. Furthermore, security doesn’t only protect the data from being eavesdropped,
it must also ensure the privacy of the transmitted data and authenticate anyone who attempts to
use the system.
Storage
In any data acquisition system it is important to store the collected data. this allows data to
be further analyzed, with a greater scrutiny, at a later date. The data collected by the system is
supposed to be stored in a database running on a remote server, as it is unlikely that the limited
resources of the Master Device will be enough to cope with the requirements of a great number of
applications. Nonetheless it is important that the Master Device is able to store a small amount of
data, for a single experience, or as a communication buffer. This is essential when, for example,
the remote server is temporarily unavailable; or, due to the location, no internet connection is
available.
Real-time display
It is deemed that for a better control of the experiment the user should be able to examine
the incoming data as the experience unfolds in real-time. This will allow the user to notice in
advance any errors that might be happening and act upon them sooner rather that later. It is also
very reassuring for a human user to be able to see that ”something is happening”. Lastly, if the
application requires user interaction in real-time, the user must be able to see what it is happening
in real-time.
3.3 Remote Server
The low range, portable nature of the ACoM makes the Master Device a proximity device that
must operate in close proximity with the sensor devices. As a portable device, Master Device’s
have few resources and capabilities. Since this project’s scope revolves around creating a plat-
form for the development of new biomedical applications, it becomes important to assure that the
system will have enough resources to store and process the data that is generated from the most
demanding applications. The remote server provides these required resources, both in terms
of computational and storage capabilities. An environment upon which relatively large amounts
of data can be safely stored and where more demanding software can run, operating over the
collected data.
19
3. Platform Architecture
Server
SOAP Interface
HTTP Plain Interface
Web Server
Client A Client BStoreDownloadListVisualize
(Master Device) (Web Browser)StoreDownloadListVisualize
HTTPS request (XML)
HTTPS response
(XML)
HTTPS request (plain)
HTTPS response
(plain)
Database Client Page Link
Figure 3.4: Remote server’s architecture
The remote server’s nature as a data repository clearly hints towards a database. Databases
tend to be a safe and reliable way of not only storing information, but also making it available to
whomever might legitimately need it. In order to do that the remote server will need to provide
interfaces so that the data can be stored and retrieved from the database. While it is possible that
such interfaces are built using only the database management system (DBMS)’s interface, that
would ultimately rend the Master Device and the other users of the remote server, database de-
pendent. The inclusion of an intermediary built around other, easier to modify technologies allows
the remaining components of the system to operate with any remote server with little or no alter-
ation. The technologies chosen for these interfaces were plain hypertext transfer protocol (HTTP)
and web services. These technologies were chosen for their wide availability and easiness to
modify. Thus the remote server will have two interfaces to the world, a web services, which
should be the preferred manner for applications to store and retrieve data from the database,
and a plain HTTP interface, primarily suited for human users to access the information in the
database through the commonly available web browsers. Another important advantage of using
these technologies is the amount of security solutions already developed for them.
Fig. 3.4 also depicts the most basic functionalities available when interacting with the remote
server. As with any data repository the remote server should be able to store and retrieve data.
Furthermore it should also be able to list the contents of its database. Obviously, for security
purposes, the agent requiring this information needs to be authenticated, and any sensitive infor-
mation traveling to and from the remote server needs to be encrypted.
3.4 Comparison of the Proposed Architecture with the Stateof the Art
In the chapter 2 several architectures from the literature were presented. In this section they
are compared with the architecture presented above, emphasizing the points where the architec-
tures diverge.
20
3.4 Comparison of the Proposed Architecture with the State of the Art
Biomedical Digital Assistants
Tae-Soo Lee proposed architecture (section 2.1) can clearly be divided in two tiers. In a first
tier data is collected by sensors. It is then forwarded to the second tier (a mobile phone or a PDA)
using the Zigbee standard. The data arriving at this device is then analyzed, and if an emergency
is detected by the software running in the PDA or mobile phone, an alarm is generated and sent
to a remote server using the mobile network. The system proposed in this thesis adds a third tier
on top of Tae-Soo Lee’s. In this third tier lies a remote server. This server is in contact with the
middle tier device through internet-based technologies, namely the simple object access protocol
(SOAP). The server is responsible for storing the acquired data in a database. In addition the
server provides an environment where more computationally intensive applications can operate
over the acquired data. Unlike Tae-Soo Lee’s work, the prototype presented in this thesis is
not capable of detecting emergencies, although that functionality could easily be integrated into
the system. However, the most significant difference between Tae-Soo Lee’s work and the one
proposed in this thesis is its openness. The architecture in this thesis is a general architecture,
designed to be a framework on which developers can implement their solutions for biomedical
applications. These include, but are not limited to, remote patient monitoring.
Advanced Medical Monitor
The advanced medical monitor (AMON) prototype, described in section 2.2, is a perfect exam-
ple of a custom made ubiquitous remote health monitoring system. Pretty much every detail was
custom built making it hard and expensive to extend the device’s functionality. The architecture
presented in this thesis addresses these concerns, by providing a generic interface upon which
new functionalities can be as effortless as possible added to the system.
The need to develop a medical monitoring system as unobtrusive as possible lead the de-
velopers to concentrate all sensors in a single device. The temperature measurement is a good
example of why this isn’t always such a good idea. Furthermore, having many sensors very close
to each other increases the chances of one sensor’s activity interfering with another’s, thus in-
creasing the noise levels in the measurement circuit. By severely restricting the places where the
sensors can be placed the developer is compromising their effectivity. The architecture presented
in this thesis allows the sensor devices to be placed where they will be most effective, while a
wireless connection will make sure the system remains wire-free, thus unobtrusive.
Personal Care Connect
The architecture and goals presented for personal care connect in section 2.3, are very sim-
ilar to the ones proposed in this thesis. Both projects try to be a platform upon which others
can develop their biomedical solutions. They both projects have the same three tiered architec-
21
3. Platform Architecture
ture. Perhaps the most important difference with the work proposed in this thesis is the fact that
personal care connect (PCC) requires that sensor devices have bluetooth connectivity. In the
architecture proposed by this thesis the sensor devices only have to have a serial interface. This
reduces the complexity for the sensor developers, as they won’t have to delve into the bluetooth
standard. The ACoM described in the section 3.1.2 provides an interface between the sensor per
se and a communication medium. This communication medium is provided by the communica-
tion module described in section 3.1.2 and can follow any serial communication standard. The
developers can for example use a Zigbee or USB, instead of bluetooth. Moreover, due to the re-
programmable nature of the ACoM controller, the developer also has the freedom of dynamically
changing the communication medium being used, or adjusting the connection parameters to the
applications particular needs at any given time, making the architecture presented in this thesis
more flexible than the one presented by Blount.
Assisted-Living And Residential Monitoring Network
The assisted-living and residential monitoring network (ALARM-NET), described in section 2.4,
is a rather complex system incorporating many kinds of sensors. It also possesses very sophisti-
cated context-aware privacy and power managers that adapt the whole system’s behavior accord-
ing to not only pre-defined policies, but also, thanks to the circadian activity rhythm (CAR) analysis,
to the very routine of the monitored patients. One important shortcoming of ALARM-NET is the
fact that the data from the sensors that comprise the mobile body network (medical sensors) must
be forwarded through the emplaced sensor network (environmental sensors), in order to reach
the AlarmGates and the databases. The system only works adequately when monitoring the pa-
tients indoors, and only if an adequate number of emplaced sensors are present and properly
distributed throughout the living space.
Another shortcoming of ALARM-NET is the fact that it is a closed environment. Even though
the system can deploy several kinds of sensors and additional sensors can be added to existing
ALARM-NET networks, its reliance on commercial (proprietary) technology and its closed struc-
ture introduces barriers to independent vendors and developers. The architecture presented in
this thesis was developed as generic as possible in order to tackle issues such as these.
Wearable Health Monitoring Systems
The wearable health monitoring systems’ architecture, described in section 2.5, is similar to the
one proposed in this thesis. They both use the same three tiered architecture. Even the wireless
intelligent sensors (WISE) sensors are very similar to the ACoM presented in section 3.1.2, in the
sense that it acts as an interface between the sensor devices and the rest of the system. There
is however on main difference between the ACoM and the WISE: the WISE sensor interfaces
an analog signal directly, using its 12 bit A/D converter to convert the analog signal into a digital
22
3.4 Comparison of the Proposed Architecture with the State of the Art
one. The architecture proposed in this thesis interfaces the digital signal directly. This means the
developer of the sensor has more freedom to choose the A/D converter that better fits his needs,
instead of being forced to use the one in the sensor interface platform (ACoM or WISE).
23
3. Platform Architecture
24
4Prototyping of Biomedical Systems
Contents4.1 Autonomous Communication Module . . . . . . . . . . . . . . . . . . . . . . . 264.2 Communication Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.4 Sensing and Processing Module . . . . . . . . . . . . . . . . . . . . . . . . . . 324.5 Master Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.6 Remote Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
25
4. Prototyping of Biomedical Systems
4.1 Autonomous Communication Module
The autonomous communication module (ACoM) architecture described in section 3.1.2 was
implemented in a printed circuit board (PCB) (Fig. 4.1) with an approximate area of 32 cm2.
1
32
4
Figure 4.1: Autonomous communication module1) microcontroller; 2) power supply circuits; 3) Bluetooth adapter; and 4) USB interface.
The centerpiece of the ACoM is a 16-bit microcontroller, Fig. 4.1(1). This microcontroller [13]
plays the role of the transfer manager described in section 3.1.2 as well as overall manager of
the ACoM. It can execute as high as 16 million instructions per second (MIPS) and comes with
a number of integrated communication peripherals and several advanced power-saving features.
Amongst its communication peripherals there are: a universal asynchronous receiver transmitter
(UART), a serial peripheral interface (SPI) and an inter-integrated circuit (I2C). The microcontroller
consumes about 50 mW at peak clock frequency although that consumption is lowered to 12 mW
in idle mode and 30 µW in sleep mode.
Fig. 4.1(2) shows the power supply circuits. These are responsible for monitoring the state of
the battery and recharging it when need. The battery can be recharged from either a universal
serial bus (USB) bus or a DC adapter. Two low-noise power rails power the sensing and pro-
cessing module (SPM). They can provide a current of up to 500 mA, and can be adjusted from
1.2 V to 5 V. A fixed high efficiency 3.3 V, 800 mA powers the digital circuitry. In order to prevent
the propagation of noise from the power sources to the SPM during a sensitive experiment, the
microcontroller can disconnect entirely the external power sources, relying only on the battery.
The prototype is equipped with two communication systems: bluetooth, made available by
a bluetooth adapter 4.1(3), and USB, provided by a USB serial converter, Fig. 4.1(4). Both of
them are controlled by the microcontroller using the same UART peripheral, which reduces the
prototype area. The bluetooth module [14] has an area of 35×14 mm and operates from a 3.3 V
power rail. The module fully implements Bluetooth 2.0 standard with enhanced data rate (EDR). It
26
4.1 Autonomous Communication Module
has a maximum data rate of 3 Mbps and as it is a class 1 device has a range of up to 300 m. The
module consumes up to 560 mW during transmission, but has much lower power requirements in
idle mode, 10 mW, or in sleep mode, 1.2 mW. This bluetooth module also provides a user interface
that allows the adjustment of connection parameters such as transmission power, data rate and
power saving profiles by the microcontroller. The used USB serial converter [15] is USB 2.0 full
speed compatible and supports data rates up to 1 Mbaud.
The signal path that carries the data between the ACoM and the SPM travels through an
optocoupler isolation block. This block not only reduces the noise induced in the signal, but is
also capable of voltage level adaption. Thereby the ACoM can interface with SPMs operating at
voltage levels as low as 3.0 V and as high as 5.5 V.
4.1.1 Lowering power consumption
As this is a battery-powered portable device it is very important to minimize its energy con-
sumption in order to increase its autonomy. Of the four blocks depicted in Fig. 4.1, only two are
worth optimizing. The power supply circuits (Fig. 4.1(2)) have already been optimized at hardware
level and can not be further optimized through software. The USB interface block, Fig. 4.1(4), is
powered by USB, with no impact whatsoever in the device’s autonomy. That leaves only the
bluetooth module, Fig. 4.1(3), and the microcontroller, Fig. 4.1(1).
Bluetooth module
The bluetooth module possesses several features designed for lowering its power consump-
tion, namely low power modes of operation. By default the module is in active mode while com-
municating and in idle mode when no connection is active. Nonetheless the module can also
enter a sniff mode, park mode and deep sleep mode. These modes require less power than the
default ones. When operating in sniff mode the bluetooth module only checks the piconet at spec-
ified intervals, thus trading bit rate for less power consumption. These intervals can be adjusted
dynamically by the user, making sniff a very flexible mode of operation as the user can decrease
the interval, increasing the bit rate when it has more information to transmit, and increase this in-
terval, decreasing power consumption when there is less information to be communicated. When
the device is in park state, although it is still connected to the piconet, it does not participate in its
traffic. This mode requires less power than sniff mode. The device can still enter a deep sleep
mode which requires even less power.
The used device is power class 1 compliant with a maximum range of about 300 m. The
module also gives the user the chance to change its power class to a less power demanding
one. A drawback of a less power-hungry power class is a diminished range. Nonetheless, a
class 2 device still has a range of around 10 m, which is deemed suitable for a very large number
of applications. Switching the module’s power class is a very simple method of reducing the
27
4. Prototyping of Biomedical Systems
device’s power consumption, increasing its autonomy. In addition, the bluetooth module allows
this change to occur at run-time, meaning that the range, and power consumption, of the device
can be adjusted as needed at each particular time. In this prototype implementation the device’s
power class was set to 2 (about 10 m range).
Microcontroller
The microcontroller’s power consumption can also be optimized, namely through the usage of
its power saving features: clock throttling and power saving modes of operation. A well known
method of lowering power consumption is reducing the clock frequency. Notwithstanding it is not
clear that lowering clock speed will increase system autonomy. Even though the power consump-
tion is reduced, computations will require more time to finish, making it unclear whether by the end
of the calculation less energy has been spent. Another technique that can be used to lower the
power consumption of the processor is the power saving modes. Aside from an active mode the
device also has available an idle mode, a sleep mode and a doze mode. Sleep mode shuts down
the processor’s clock source, thus powering down the whole processor and all of its peripherals.
This might be undesirable as it may be necessary for the device to be reachable at all times, or for
a peripheral to continue operations. This mode is the one which consumes the least power. In idle
mode, instead of shutting down the clock source, the device prevents the clock signal from reach-
ing both the processor and a configurable number of peripherals. The effect is somewhat similar
to sleep mode, only it is more flexible and saves less power. Doze mode is an unusual power
saving mode where both peripherals and central processing unit (CPU) are allowed to continue
operations, but the CPU uses a lower clock speed, henceforth lowering the power consumption.
The device ensures that the faster peripherals’ clock remains synchronized with the slower CPU
clock. This mode is particularly useful when working in an environment very sensitive to timing
issues.
The ACoM software was mostly written in C using the development tools made available by the
microcontroller’s manufacturer, Microchip [16]. The fact that Microchip’s microcontrollers can be
programmed using the widely known C language, makes the ACoM’s software easier to modify.
This in turn reduces the effort required by developers to attune the ACoM to the specific needs of
their biomedical system.
4.2 Communication Protocol
One of the advantages of the ACoM’s architecture is its flexibility when it comes to communi-
cation protocols. The programmable nature of the transfer manager makes it possible to change
the communication protocol to best fit the needs of any SPM. The protocol developed for the pro-
totypes is comprised of two kinds of packets: a fixed length packet and a variable length packet,
28
4.2 Communication Protocol
N Data NCommand ...
1 byte 1 byte
ACK Data 1
4 bytes 4 bytes
receiverfixed length variable length
ACK
receiver
Figure 4.2: Packet structure
as depicted in Fig. 4.2. A fixed length packet contains not only the command to be performed
by the receiver, but also the length of the following variable length packet. After sending the
fixed length packet, the sender awaits for an acknowledgement from the receiver signaling the
receiver’s readiness to receive the variable length packet. The data is then sent in the variable
length packet. Finally the sender waits for an acknowledgement signaling a successful reception
by the receiver.
While this is a simple protocol, it inherently has one flaw that, if unaccounted for, may catas-
trophically bring the whole system to a halt. Should an acknowledgement message be lost in the
channel, the communication end expecting it will wait for ever for the acknowledgement that will
never come, thus leading to a deadlock situation. To tackle this issue the operations associated
with waiting for the other end to reply were given a maximum duration. If this waiting time expires,
the communication is aborted. This is nothing more than a simple timeout mechanism present
in many current technologies. Albeit a simple addition to the protocol, this change required a
slightly more complex approach during implementation. The implementation on the Master De-
vice’s side was fairly straightforward as the .NET compact framework manages the timeouts of
read and write operations to serial ports. The increased complexity was due to the simplicity of
the microcontrollers used by both ACoM and SPMs. Being simple devices these processors have
no inherent timeout mechanism associated with their serial ports. Such behavior needs to be
emulated through the use of timers and interruptions external to the serial port peripherals.
The routines for both reading and writing a package using this protocol are schematized in
Fig. 4.3. The read procedure starts by reading two bytes from the serial port, the fixed length
packet. If the first byte, the command, is invalid the functions returns an error message. If the
command is valid the function sends an acknowledgement and proceeds to reading the data in
the variable length packet. However, before calling the read function a timer is initiated. This
prevents the system from entering into a deadlock state if not enough bytes are received. When
the procedure returns from the read operation, one of two things have happened: either the read
procedure has read the number of bytes it was supposed to read, or a timeout event has occurred.
If the flag indicating a timeout event is set, the received bytes are discarded and the procedure
returns an error. If no timeout event occurred, the timeout timer is stopped to prevent it from
”firing” at the wrong time. Lastly an acknowledgement message is sent to the sender, signaling
the conclusion of the transmission process. There is no timeout associated with the first read
operation, because slave devices are required to wait indefinitely for instructions.
29
4. Prototyping of Biomedical Systems
The routine for sending a package starts by writing to the serial port the fixed packet. Then
the sender starts reading characters from the serial port until the acknowledgement message is
received. The data portion of the package is then written to the serial port in a variable length
packet. The sender then awaits for an acknowledgement message signaling a successful recep-
tion on the other side. As the wait for acknowledgement is blocking and the acknowledge might
never come, these instructions need to be protected by timeout timers. Should any timeout event
trigger during these instructions, the communication is aborted and an error returned.
Receive 2 bytes (command, size)
Send ACK
Return ErrorReturn the read package (command + size + data)
Start timeout timer
Receive N bytes(data)
Valid command?
Timeout occured?
Y
N
Y
N
Send ACK
Stop timeout timer
(a) Read package procedure
Wait for ACK message
Send N bytes(data)
Return ErrorReturn Success
Start timeout timer
Wait for ACK message
Timeout occured?
Timeout occured?
Y
N
N
Y
Stop timeout timer
Send 2 bytes(command, size)
Start timeout timer
Stop timeout timer
(b) Write package procedure
Figure 4.3: Read/Write package procedure
For debug purposes another protocol was implemented. This one is quite simpler than the pre-
vious one, relying not on packages but on termination characters. In this case the sender sends
commands and data in plain american standard code for information interchange (ASCII) format
until it sends the termination character. At this time it relinquishes the control of the channel. As
the controller of the channel the receiver can then send a reply to the sender in ASCII format. This
30
4.3 Security
reply is terminated by the termination character, returning the channel’s control to the sender. As
this protocol was implemented having in mind nothing more than debug purposes, it is still rather
crude lacking important features, namely the ability to codify a termination character so that it can
be transmitted as data. As it is, it is the responsibility of the user/programmer that the terminating
character is not used in the middle of commands or data. However, this restriction is not too limit-
ing as both data and commands are codified as ASCII verbose messages, it is fairly easy to make
sure they are not codified using the termination character. Nonetheless, the platform’s flexibility
makes it relatively easy for, in some future time, extend this protocol to incorporate such features
(or even design a new protocol from scratch).
4.3 Security
The encryption module addresses the problem of transferring confidential information over
an unsafe connection. In this prototype it is used an implementation of advanced encryption
standard (AES). AES is a symmetric key algorithm deemed suitable to protect information up to
SECRET level, if a 128 bit key is used, and up to TOP SECRET information, if the encryption
keys have 192 or 256 bits [17] [18]. AES is a block cipher algorithm, meaning that it encrypts
data in blocks with a predetermined size. In the case o AES in particular, only 128-bit blocks are
supported. AES’s 128 bits blocks are organized in 4×4 bytes array called the state. The algorithm
itself consists on a series of iterations over this two dimensional array. In each step of the itera-
tive procedure the matrix suffers a byte substitution, a bit permutation and arithmetic operations
in finite fields, more specifically, addition and multiplications in the Galois Field 28 [19]. For each
block of data the process is repeated 10, 12 or 14 times, according to the size of the key: 128, 192
or 256 bits, respectively. The developed cryptographic engine uses a 128 bits implementation of
AES, based on Microchip’s cryptographic libraries, specifically designed for programmable intel-
ligent computer (PIC) microprocessors [20]. On the master’s side the cryptographic module was
implemented using the libraries developed by James McCaffrey [21]. As any key can eventually
be discovered if enough information is provided it becomes imperative to change it from time to
time. To further complicate matters AES is a symmetric key algorithm, which means that both
sides of the connection, encrypter and decrypter, must use the same key. In this implementation
the master device was placed in charge of managing the key. From time to time the master device
generates a new key randomly and sends it to the ACoM through the still secure link (i.e. encrypt-
ing the new key with the old one). Any subsequent messages are already encrypted with the new
key.
31
4. Prototyping of Biomedical Systems
4.4 Sensing and Processing Module
For this project two SPMs were developed: a biomolecular recognition system, and a move-
ment monitoring system. The main characteristics of these SPMs are described in the following
sections.
4.4.1 Biochip
The architecture of the biological recognition system is the one presented in [22]. This archi-
tecture allows the detection of unknown biomolecules and can be used in a variety of scenarios,
namely in the detection of genetic diseases in human deoxyribonucleic acid (DNA) strands, and
in the detection of bacteria and other cells. This approach is based on magnetoresistive sensors,
and described in greater detail in [23].
The experiment proceeds as follows: Firstly, the unknown DNA strand is marked with a small
biochemical agent such as biotin. This is the target DNA. The probe DNA, a known DNA strand,
is then ”attached” to the sensor. If both target DNA and probe DNA are complementary then a
biomolecular reaction will bind these two molecules. Then, magnetic labels functionalized with
streptavidin, the complementary molecule to the biochemical marker biotin, are introduced. The
streptavidin will react with the biotin, binding the magnetic label to the target DNA. Next, the
target DNA is washed away leaving only the target DNA that has been bound with the probe DNA,
the DNA that has actually been recognized. The magnetic particles of the remaining target DNA
produce a magnetic fringe field. This magnetic field is then detected by magnetoresistive sensors,
integrated in a biochip, in a matrix organization [22]. Typically chips with 256 sensing sites are
used, arranged in a squared 16×16 matrix. The signal acquired in this manner is proportional to
the number of recognized molecules within an experiment. The main reason why the target DNA
is labeled with biotin instead of being directly marked by the magnetic label is that a magnetic label
is considerably bigger than a biotin label. This large size hinders the biomolecular reactions and
might even prevent some target DNA molecules from binding with immobile probe DNA molecules
in close proximity [24].
The aforementioned biorecognition process is schematized in Fig. 4.4. In a first step the known
probe DNA is immobilized on a magnetoresistive sensor and the unknown DNA is labeled with bi-
otin. If the probe DNA and target DNA are complementary hybridization occurs and the molecules
are bound together. The biomolecular recognition has just happened. In the next step, strepta-
vidin functionalized magnetic labels are introduced into the mixture. The streptavidin will bind with
the biotin, binding the magnetic labels to the target DNA. A washing step then removes all the
target DNA that has not been recognized (i.e. bound with the probe DNA). The remaining mag-
netic particles produce a magnetic fringe field that is detected by the magnetoresistive sensors.
This magnetic field is proportional to the amount of recognized biomolecules.
32
4.4 Sensing and Processing Module
Immobilized single strain DNA
Sensor
probe DNA
unkown DNA labeled with biotin
target DNA
Hybridization
After the washing step the remaining magnetic fringe field
is detected by the sensor
Introduced magnetic labels bind with the biotin
Figure 4.4: Biomolecular recognition process
The core of this SPM lies in a 16-bit digital signal processor (DSP) [25]. It can perform up
to 30 MIPS and its embedded peripherals provide interfaces with which it controls the remaining
PCB’s components. The processor not only controls the whole board and manages the com-
munication with the ACoM, but also processes the acquired signals locally, which reduces the
bandwidth required to transmit the acquired data. The local processing of data has a rather sig-
nificant impact, as it leads to roughly one sample per second per sensor. In turn, this reduction
allows the ACoM to use a lower bit rate, increasing the autonomy of the whole system.
The signals produced by the magnetoresistive sensors are amplified by an instrumentation
amplifier [26], that has an AC gain that can be set between 50 and 1000. After being amplified
the signal is acquired by a sigma-delta high resolution converter. The converter [27], has a 24 bit
resolution and can operate at a maximum conversion rate of 3.5 kHz. As it is natural in sigma-
33
4. Prototyping of Biomedical Systems
Figure 4.5: Biomolecular recognition SPM
delta converters a higher rate of conversion leads to a lower bit resolution. Another important
component of this SPM is the current generator and the sensor addressing circuits. The current
generator provides the drive current to the Biochip sensors. The generator, made of a digital
to analog converter (DAC) and a voltage-to-current converter, can generate several current lev-
els [22]. It is very accurate, having an error no greater than 0.13% while supplying currents from
144 µA to 1.16 mA. The addressing circuits allow each and every single sensor in the matrix to
be addressed individually, which reduces the number of ”wires” coming out of the Biochip. The
biochip SPM consumes up to 500 mW, however it is configured to consume roughly 200 mW [28].
Fig. 4.5 shows the prototype of the biochip SPM.
4.4.2 Movement Monitoring
The developed movement monitoring system is a very simple biomedical monitoring system
that can, notwithstanding, produce invaluable information. With such a system it is possible,
among other things, to measure the wearer’s activity levels, which might be useful if correlated
with other sensor’s information, such as cardiac activity measurement. Another very important
information that can be extracted from such sensors is the detection of falls. As monitored patients
might have mobility problems, especially the elderly, it might be difficult for them to stand up again,
thus making a remote fall detector a useful tool for enhancing this group’s autonomy and overall
quality of life.
In the built prototype’s movement monitoring system [29], the movement is detected by a 3D
accelerometer made of two micro machined 2D accelerometers [30], placed in orthogonal planes.
34
4.5 Master Device
Figure 4.6: Movement monitoring SPM
Each sensor is capable of detecting accelerations of up to ± 2g in two orthogonal directions. The
output of these sensors is a couple of digital duty cycle modulated (DCM) signals, one for each
direction. These signals can be easily decoded by a microprocessor with a counter, simplifying
the board’s design as no analog to digital converter (ADC) is required. This electronic module
includes a microcontroller that decodes and pre-processes the accelerometer’s data. This 8-bit
microcontroller was chosen having in mind low cost and small size, and is capable of performing
up to 5 MIPS, while consuming 50 mW [31]. The total power consumption of the SPM was
experimentally measured as roughly 140 mW. Fig. 4.6 shows the prototype of the movement
monitoring SPM.
4.5 Master Device
The master device is a more general purpose computing device that also provides an interface
between a human user and the ACoM. In this work a master device was implemented on a
Pocket Loox 720, with an Intel XScale PXA 272 520 Mhz processor. This device has 128 MB
of RAM memory and bluetooth 1.2 and USB 1.1 host capabilities. The developed graphical user
interface (GUI) implements the most basic functionalities of a master device: communication,
storage and data displaying. All software developed for the master device was written in C# under
the .NET compact framework 2.0 for increasing portability.
4.5.1 Communication
The most basic functionality of any master device is the ability to communicate with the em-
bedded system. The developed software communicates with the ACoM through a bluetooth link
masquerading as a serial port. From the program’s point of view, it is sending and receiving mes-
sages from a serial port. This makes it somewhat easier to, on a later date, adapt it to other
communication mediums. It is also at this level that the communication protocol described in
35
4. Prototyping of Biomedical Systems
section 4.2 is enforced.
In addition to communicate with the embedded system, according to the architecture pre-
sented in chapter 3, the Master Device must also be capable of communicating with the re-
mote server. To that end internet-based technologies were chosen, namely simple object access
protocol (SOAP). SOAP is an advantageous choice especially because of its simplicity, extensi-
bility and portability. SOAP can be implemented over a number of different protocols, including
hypertext transfer protocol (HTTP) which was used in this prototype. As the information in SOAP
is exchanged in verbose extensible markup language (XML) files, it is also not only easily extend-
able, but also platform and language independent. Making it, under the scope of this project, an
ideal candidate for a communication protocol between the Master Device and the remote server.
4.5.2 Storage
Another core functionality of the master device is the ability to store and retrieve experimental
data. In the majority of applications it is important to keep a record of the experiments and store
the data collected in each of them to be further analyzed at a later time. The limited resources
of the Master Device make it an unlikely recipient and indexer of such records, especially if there
are many of these experiences. The solution for this problem lies in storing this information in
a remote location, properly maintained, indexed and controlled under a database management
system (DBMS). However, the device might temporarily loose connectivity to this remote server,
making it impossible to temporarily send the information to the remote database. Hence the need
to store the data locally on the device until the connection to the remote server is restored and
data transmission can be resumed.
The current prototype can store information either locally or in a database running on a remote
computer. The data stored locally is stored in a XML file. With this objective, the data, which is
internally gathered in three different object classes, is serialized using the .NET Compact Frame-
work’s native XML serializer. Fig. 4.7 shows the classes that are stored. The class BiochipSpec
contains the information about the SPM sensor device used. The class PlatformState keeps the
information on the state of the acquisition platform at the time of the acquisition. The class Mea-
sureData stores the acquired data per se on an array of PointPair objects. These classes are
stored in three different XML files: BiochipSpec is stored in a *.cfgBio.xml file, the class Platform-
State is stored in a file with the extension *.cfgPlt.xml and MeasureData is stored in a file ending
in *.dat.xml. The data can also be stored and retrieved from a database running on a remote
machine. In order to keep the generic scope of the Master Device, the communication with the
remote machine was done using SOAP, which allowed the Master Device to remain independent
of the database used.
36
4.5 Master Device
PlatformState
string ID int AmpModeint AmpSourceint AmpRefdouble AmpGainACdouble AmpGainDCdouble OffsetCurrentdouble OffsetMagneticdouble AmplitudeMagneticint SensorAddress string Shuntdouble ParticleFreqdouble VosAmpdoube VfilterAdouble VfilterBdouble Iosdouble Rmuxdouble Icorrint DFTfreq int DFTosrint NumColint NumRow
BiochipSpec
string IDstring Typeint[ ] SensAddrListint Size
MeasureData
string IDPointPair [ ] PointPairListdouble Bandwidth int NumSweepSamplesstring DriveType int RefSensorstring[ ] Descriptionstring BiochipSpecID string PlatformStateID
PointPair
double Xdouble Y
Figure 4.7: Stored classes in the Master Device
4.5.3 Data Displaying
In order to increase a user’s control over an experiment it is important for him/her to know
what is happening. Hence the need for displaying the data being transmitted by the SPM through
the ACoM. Data in a plain numeric format is not only hard to read, but also difficult to interpret,
especially if there are many samples. It is not the best way of conveying information to a human
being. A graphic is a much more intelligible way of presenting information to people. To address
this issue, the Master Device was made capable of generating simple graphics with the incoming
data in real-time. This component displays the data in a two axis graphic. It supports several data
series, each with its own colour. Furthermore, the component is not only capable of automatically
scaling the axis, but can also zoom in and out and scroll through the graphic. The latest two are
rather important features considering the size of a personal digital assistant (PDA)’s (or mobile
phone’s) display screen.
The graphic itself is simply a bunch of squares drawn on the screen. Each square represents
a point. These points are scaled so that their relative values are properly displayed in the distance
separating them. Their absolute value is given by the value inscribed in the graphic’s axis. In order
to support features such as zooming or scrolling the graphic revolves around the concept of a
window. The display area is nothing more than a window which allows the user to see the portion
of the graphic. In order to see another part of the graphic this window needs to be pointed at
another ”direction”. Every time the user changes the ”direction” the window is pointed at all points
need to reevaluated in order to determine if and where they should be on the display screen. In
37
4. Prototyping of Biomedical Systems
addition the visible screen, pertaining to the old window, is invalid so it must be redrawn. A typical
use of the component is depicted in the Fig. 4.8.
Set up the component
Add data points
Define the window size
Refresh the form
- Scale the data points- Repaint the form
Figure 4.8: Program flow in a typical use of the graphics component
Before using the component a number of variables have to be set up. Some can be seen in
the Fig. 4.9(a). The variables gXorig, gYorig, gWidth and gHeight define the area the graphic
will occupy within a form. This is the actual area in which the graphic will be drawn. Further-
more, one also needs to specify the colour in which the axis will be drawn, mAxisColor, and the
font type in which the axis will be labeled, mFont. It’s also necessary to define the names of
both axis, by giving the strings Xaxisnames and Yaxisnames their correct value. The variables
XaxisnameVerticalCorrection, XaxisnameHorizontalCorrection, YaxisnameVerticalCorrection and
YaxisnameHorizontalCorrection give the programmer the freedom to write the axis name pretty
much everywhere on the screen. Moreover, the variables Xdiv and Ydiv indicate the number of
divisions each of the axis will have. For each division a small line, perpendicular to the axis, will
be drawn. The value at the division will also be written close by (slightly to the left in the vertical
axis and slightly bellow in the horizontal axis). Each of the points in a series is represented as
a square on the screen. The programmer also needs to specify rsize, the length of the side of
such squares, thus determining the square’s size. Lastly, the programmer needs to associate the
painting event of the form in which the graphic lies, with the component’s plotgraphic function so
that whenever the form is repainted on the screen so is the graphic. Fig. 4.9(b) shows the result
on a real PDA of a successfully set up graphic component: a set of axis drawn at the edge of the
38
4.5 Master Device
graphic area, the axis’ subdivision markers and the title of the axis.
(a) schematic representation (b) Picture of the PDA display
Figure 4.9: Setting up the graphics component
The data to be plotted is stored within the graphics component as a collection of data points.
Data points contain two variables, X and Y, and are grouped in series. Series are stored in an array
within the component. In short the component has an array of series. Each element in the array,
a series, has a collection of data points, each point being a value in the X scale and another in the
Y scale. A series contains a little more information than the data points themselves, namely the
colour of the series graphical representation, the amount of data points present in the series, and
the maximum and minimum values of the data points presented in the series for both dimension
X and dimension Y. This latest information is useful when determining a suitable window size.
As soon as the data is loaded into the component the user needs to specify which window it
would like to watch. The component also has available functions to calculate the window which
will show all the points, i.e. the biggest window possible. The functions getextremes return the
extremes, i.e. the highest and the lowest values, of both horizontal and vertical dimensions, of all
the data series in the component. This function is very useful when determining the maximum
window. The component also provides another very useful function when determining a good
window size, GetInterval, which rounds any given interval to a interval determined in multiples of
10. Naturally the lower interval extremity is rounded to the closest power of ten below it, and the
higher interval is rounded to the multiple of ten immediately after it. Therefore, the new interval
always includes the original one, so the user will always see what it wanted to see in the first
place. Having the interval defined in multiples of ten tends to make the graphic’s axis, especially
its division more intelligible.
39
4. Prototyping of Biomedical Systems
Figure 4.10: Picture with an example plot
The next step after determining the window is refreshing the form. By calling the form’s func-
tion refresh, the current view is invalidated and repainted. All the points, in all series are then
evaluated. If the point is within the window then it is scaled according to equations (4.1) and (4.2)
and a square placed at the corresponding coordinates. X and Y are the square’s screen coordi-
nates, while pX and pY are the point’s actual values. gXorig, gYorig, gHeight and gWidth are the
ones shown in Fig. 4.9(a), and define the graphic’s area on the screen. Xmax, Xmin, Ymax and
Ymin are the edges of the window. This is a very simple normalization: any point whose value
equals that of the window’s limits is placed at the very edge of the graphic’s area, all the other
points visible in the current window are linearly scaled in between. At this stage the axis are also
painted, as well as the axis’s name and values.
X = gXorig +pX −Xmin
Xmax−Xmin× gWidth (4.1)
Y = (gY orig + gHeight)− pY − Y min
Y max− Y min× gHeight (4.2)
Fig. 4.10 shows an actual picture from the graphics component at work on a PDA. The
graphic’s data is nothing more than three points divided in two series. As it is possible to see
each series has its own colour. Another noteworthy detail is the number of divisions in the vertical
axis, five instead of the default value of 10. Since this picture had so few points, their size was
increased, this can however, have negative effects as the points look slightly to the right and down
to where they were supposed to be. This happens because the squares representing the points
are placed in such a way that their upper left corner of the square is exactly were the point is
supposed to be. This problem is greatly attenuated if smaller rectangles are used to represent
points.
40
4.6 Remote Server
The component does not really produce graphics in real-time. However, as the whole compo-
nent is repainted every time a new window size is chosen or new points are added, it is possible to
simulate such behavior. The only requirement for plotting the graphic in real-time is that the com-
ponent is painted quickly enough. As biomedical reactions tend to be quite slow when compared
with modern days electronic devices, this is not such a serious restriction.
4.6 Remote Server
The remote server was implemented as a MySQL database [32] and a PHP server [33]. The
PHP: Hypertext Preprocessor (PHP) server was chosen as an intermediary between the database
and the Master Device, as MySQL databases have no support for SOAP. Even if it had SOAP
support, it would leave the Master Device platform dependent which is undesirable considering
the scope and goals of this project. It is therefore desirable to have an application serving as
an interface between the database and the Master Device, as communications to and from the
database can be made database independent. PHP is a particularly appropriate technology in
which to make such an interface as it has built in connectors to many databases from many
different vendors [34], as well as support for webservices, namely a SOAP client and a SOAP
server.
4.6.1 Database
In general the database’s structure will need to be adapted to each particular SPM’s needs.
However, in the majority of the applications it is possible to identify three structures that need to
be stored: information on the kind of sensor that took the measurement, information on the state
of the acquisition platform at the time of the measurement, i.e. how the SPM was configured to
conduct and acquire the experiment, and the acquired data itself. The biochip prototype is no
exception, it is stored in the database the specifications (type) of the biochip sensor, the state of
the sensing and acquisition platform at the moment of the acquisition and the measured data per
se. This information is stored in three tables named BiochipSpec, PlatformState and MeasureData
respectively. Fig. 4.11 shows the database’s table structured, as well as the fields that are stored
in each.
Let us look with a little more detail to the tables for the biochip prototype. In each of the
tables the field ID is a primary key. The fields BiochipSpecID and PlatformStateID from the table
MeasureData are foreign keys to the tables BiochipSpec and PlatformState, respectively. The
fields whose type is BLOB, SensAddrList in BiochipSpec and PointPairList in MeasureData, hold
vectorial information. MySQL does not have a way of representing variable length vectors, so such
information must be serialized first and then stored in the special BLOB format. The serialization
of the vectors is done at the PHP level. When retrieving information from the database it is
41
4. Prototyping of Biomedical Systems
PlatformState
ID VARCHAR(255)AmpMode INTAmpSource INTAmpRef INTAmpGainAC DOUBLEAmpGainDC DOUBLEOffsetCurrent DOUBLEOffsetMagnetic DOUBLEAmplitudeMagnetic DOUBLESensorAddress INTShunt VARCHAR(255)ParticleFreq DOUBLEVosAmp DOUBLEVfilterA DOUBLEVfilterB DOUBLEIos DOUBLERmux DOUBLEIcorr DOUBLEDFTfreq INTDFTosr INTNumCol INTNumRow INT
BiochipSpec
ID VARCHAR(255) Type VARCHAR(255)SensAddrList BLOBSize INT
MeasureData
ID VARCHAR(255)PointPairList BLOBBandwidth DOUBLENumSweepSamples INTDriveType VARCHAR(255)RefSensor INTDescription TEXTBiochipSpecID VARCHAR(255)PlatformStateID VARCHAR(255)
Figure 4.11: Structure of the database
important to use the right unserialization method, i.e. the unserialization method than undoes
the PHP serialization function. If such information is accessed only via the PHP interface, as
the Master Device would, then this shouldn’t really be a problem as both the serialization and
unserialization methods are the ones defined in PHP.
4.6.2 PHP Interface
The PHP interface is a simple SOAP server. The methods made available by this webservice
are shown in the Fig. 4.12.
string hello(string name)string UploadBiochipSpec(BiochipSpec BS)string UploadMeasureData(MeasureData MD)string UploadPlatformState(PlatformState PS)string[] GetBiochipSpecIDs(void)string[] GetPlatformStateIDs(void)MeasureData GetMeasureData(string ID)
WebService
Figure 4.12: Methods provided by the server webservice
The hello method is a very simple hello world method, implemented in the very early stages
of development. The functions UploadBiochipSpec, UploadMeasureData, UploadPlatformState
add an entry to the database tables BiochipSpec, MeasureData and PlatformState, respectively.
42
4.6 Remote Server
These functions argument is a structure containing the corresponding fields of the database ta-
bles. All of these functions return a string stating that the operation has been performed success-
fully, or that an error has occurred (followed by the error message). The functions GetBiochip-
SpecIDs and GetPlatformStateIDs return an array of strings containing a list of the identifiers, i.e.
primary keys, in the database tables BiochipSpec and PlatformState, respectively. The method
GetMeasureData returns a structure containing the row identified by ID from the table Measure-
Data. This structure contains an array of points, PointPairList, which contains the data actually
acquired during a measurement. As the database isn’t capable of storing arrays, especially vari-
able length arrays such as this one, it is stored under a BLOB in a serialized form. It is therefore
necessary to unserialize it before sending it over to the SOAP client. As of yet, no security
mechanism has been implemented at this layer in the architecture. Future developments will give
this layer encryption and authentication capabilities in order ensure privacy, confidentiality and
integrity on the whole system.
Figure 4.13: Plain HTTP interface for the biochip system
Another key advantage of building this interface layer in PHP technology is its compatibility
with web browsers and hypertext markup language (HTML). This allows another interface to
be easily built centered around web pages. It allows the database, and more importantly the
information contained within, to be accessible using the widely available web browsing tools.
Fig 4.13 depicts the web interface used for the biochip application, described in section 4.4.1. In
it, it is possible to see a drop down list of the measurements registered in the database, a table
containing information on the bogus ”testA” measurement, and, to the right a graphical plot of the
43
4. Prototyping of Biomedical Systems
data acquired in the fictitious measurement.
44
5Experimental Results
Contents5.1 Experimental Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.2 Autonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.3 Data Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.4 Master Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.5 Remote Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.6 Detection of Biomolecules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
45
5. Experimental Results
5.1 Experimental Setup
A number of characteristics from the architecture presented in chapter 3 were experimentally
evaluated using the prototype described in chapter 4. Experimental results of those evaluations
are presented in this chapter. Fig. 5.1 shows the complete implemented system. In it we can see,
from left to right, the Remote Server (the computer), the autonomous communication module
(ACoM), the biochip sensing and processing module (SPM) and the Master Device (personal
digital assistant (PDA)). Slightly above the ACoM’s printed circuit board (PCB) is the battery used
during the system’s tests.
ACoMSPM
Master Device
Remote Server
Battery
Figure 5.1: The complete systemFrom left to right: Remote Server, ACoM, SPM and Master Device
Two metrics were chosen to evaluate the devices in the lower tier: autonomy and data rate.
The devices on the lower tier (ACoM and SPM) are portable devices that may in some applications
be powered by a battery. Autonomy is a crucial aspect of any battery powered device. The device
is required to complete its work before the battery running out of energy. Furthermore, a device
that is constantly requiring a recharge can be very annoying. It is important then to ensure that
the device will manage the energy available in its battery in the most efficient way possible. The
data rate is important for any device whose primary purpose is to communicate. It measures the
amount of information the device can communicate each unit of time, and therefore how long it will
take for it to transmit every piece of information it needs to. The focus of these measurements was
on the ACoM’s performance, as this is the component that remains unchanged, while the SPMs
are different for every kind of biosensor. Later in the chapter, experimental results, in the form of
snapshots, are shown for both middle tier’s Master Device and upper tier’s Remote Server.
46
5.2 Autonomy
5.2 Autonomy
As the source of energy of a battery powered device is limited, its consumption must be care-
fully managed. Throughout this section the techniques for improving the system’s autonomy that
were described in the previous chapters of this dissertation were put to the test.
5.2.1 Autonomous Communication Module
The ACoM is a generic intermediary between the sensors in the custom built SPM and the
middle tier devices (PDA, laptop or mobile phone). The ACoM not only isolates the SPM from
the middle tier device, but also gives it access to several communications media, through its
communication modules, as explained in chapter 3.
The techniques described in section 4.1.1 for increasing the autonomy of the system were
tested on the prototype described in section 4.1. For these tests the ACoM was configured to
reply to the master’s commands with a package containing 16 bytes of data. It should be reminded
that 16 bytes is the block size of advanced encryption standard (AES). The master device was
configured to send a command every 5 seconds until the ACoM stopped replying. Between
commands the microcontroller waits in idle mode. The bluetooth module was configured as a
power class 2 device, with a range of around 10 m, and to not reply to service discovery inquiries.
The universal asynchronous receiver transmitter (UART) connection between the programmable
intelligent computer (PIC) microcontroller and the bluetooth module was configured with a baud
rate of 115200 symbols per second. The serial port that masks the bluetooth connection between
the ACoM and the master device was configured with a baud rate of 9600 symbols per second.
All tests used the same 3.8 V Li-ion battery, with a stated capacity of 630 mAh. The results are
presented in Tab. 5.1.
The baseline test acts as a reference for the other tests. In this test no optimizations were
performed on both PIC and bluetooth module.
For test 1 the bluetooth module was configured to operate in sniff mode, with a sniff parameter
of 80. The PIC was not optimized. This test measures the effectiveness of the sniff mode in
reducing the power consumption.
In test 2 the bluetooth module was maintained in sniff mode, with a sniff parameter of 80. The
PIC was configured to shut down all peripherals when it entered idle mode. This test measures the
cumulative effect of both an optimization at the microcontroller level, shutting down peripherals,
as well as an optimization at the bluetooth module level, sniff mode.
In test 3 the bluetooth module was configured not only to operate in sniff mode (with a pa-
rameter of 80), but also to enter a deep sleep state whilst it waited between packets. The PIC
microcontroller was configured as in test 2. This test measures the impact of the bluetooth’s
module sleep mode in the ACoM’s autonomy.
47
5. Experimental Results
For test 4 the bluetooth module was not optimized. The PIC was instructed to shut down all
peripherals. This test measures the impact of the microcontroller’s peripherals on the system’s
power consumption.
The conditions for test 5 were the same as in test 1, only the bluetooth’s sniff parameter was
halved from 80 to 40. In conjunction with test 1, test 5 measures the impact of the sniff mode’s
parameter on power consumption.
Lastly, test 6 was configured as test 2, only the clock frequency was halved. This test mea-
sures the impact of the clock frequency in the system’s autonomy.
Table 5.1: Autonomy test resultsTest Autonomy Improvement
baseline 19h20m -test 1 21h38m 11,9%test 2 35h16m 82,4%test 3 34h45m 79,7%test 4 19h57m 3,2%test 5 33h55m 75,4%test 6 35h41m 84,6%
The best results were achieved while reducing the power consumption both the microcontroller
and the bluetooth module. The introduction of the deep sleep state in the bluetooth module did
not produce a significant impact on system autonomy, as test 3 shows. Test 4 indicates that
the microcontroller’s peripherals have a very little impact on power consumption. Similarly the
application of sniff mode, with a sniff parameter of 80 on the bluetooth module, by itself only
resulted on a small improvement of roughly 10% as shown in test 1. However, when both of
these optimizations were combined in test 2 the autonomy of the system was improved by over
80%. Test 5 revealed that, as expected the sniff parameter has some importance on system
autonomy. Comparing tests 2 and 6 it is possible to see that a 50% reduction in clock frequency
only increased autonomy by a measly 2%. The conclusion one can take from test 6 is that
although reducing clock frequency does have a direct impact on power consumption, it does not
necessarily mean it will have a big impact on energy consumption and autonomy.
Cryptography
The impact of cryptography on system autonomy was also measured. Test 2 was redone, this
time encrypting the data before it left the ACoM. The result is shown in Table 5.2. Table 5.2 shows
Table 5.2: Impact of encryption in autonomyAutonomy
With Encryption Without Encryption ReductionTest 2 34h52m 35h16m 1.1%
that encryption hardly has an impact on the autonomy of the system (less than 2%).
48
5.3 Data Rate
5.2.2 Sensing and Processing Modules
The sensing and processing modules, as described in section 3.1.1, are the components
that actually harbor the sensors. In addition the SPM also performs the signal acquisition and
normalizes the data before transmitting it to the ACoM. The developed prototypes used two kinds
of SPM: one for biomolecular recognition and another for movement monitoring.
Biomolecular Recognition System
The introduction of the techniques described in section 4.1.1 in the biomolecular recognition
system (section 4.4.1) improved it’s autonomy by 11,4% as can be seen in table 5.3.
Table 5.3: Autonomy Improvement for the Biochip SPMhours min improvement
baseline 3 40optimized 4 5 11,4%
The explanation for such a meager improvement is the fact that the biochip SPM consumes
a lot of power, and the optimizations described in section 4.1.1 only reduce the ACoM’s power
consumption.
Movement Monitoring System
The improvement for the movement monitoring system (section 4.4.2) was far more substantial
than the one for the biomolecular recognition system, increasing the autonomy of this system by
71,7%, from 13h 50m to 23h 45m as can be seen in table 5.4.
Table 5.4: Autonomy improvement for the accelerometer SPMhours min improvement
baseline 13 50optimized 23 45 71,7%
The techniques described in section 4.1.1 reduce the power consumption only of the ACoM.
As the movement monitoring system is very simple, its SPM consumes very little power, meaning
that the ACoM is responsible for the majority of the energy consumption in the system (exactly
the opposite of what happens in the biomolecular recognition system).
5.3 Data Rate
The data rate is an important metric on any system that involves communicating large amounts
of data from one place to another. The proposed system is centered around collecting data in a
sensor specific platform and transmitting it to a general database on a remote location. There are
three links the data must pass trough. The link between the SPM and the ACoM, the link between
49
5. Experimental Results
the ACoM and the Master Device and the link between the Master Device and the Remote Server.
This thesis is focused on the link between the ACoM and the Master Device, and on the perfor-
mance of the communication protocol proposed in section 4.2. To that end, the speed at which
information can travel between the ACoM and the Master Device was measured. The metric cho-
sen for this measurement was the effective data rate. In all tests the bluetooth connection was
set up as a serial port with a baud rate of 9600 symbols per second. The results are presented in
Table. 5.5.
In test A, the ACoM was configured to encrypt and send a large amount of data through a
bluetooth connection, to a master in 16 byte chunks. The time it took between sending the request
for the data and the reception of the last data chunk was measured. The protocol described in 4.2
was used for this test.
In order to measure the maximum effective data rate allowed by the protocol, test B was
conducted. This test was set up as test A, only the data was not encrypted and the data was
gathered in chunks of 1020 bytes, the maximum allowed by the protocol.
Table 5.5: Effective data rate in bytes per secondsniff mode 80 sniff mode 40 sniff mode off
test A 92 142 210test B 4036 5098 5913
The results from table 5.5 show that sniff mode does indeed have a visible impact on the
data rate, and that impact is proportional to the sniff parameter. Nonetheless, the most important
information contained in the table 5.5 is the gigantic gap between tests A and B. These results
clearly show that the efficiency of the protocol described in section 4.2 is very dependant on the
size of the packets used. If an application requires a high data rate then it should gather the data
in larger packets or a new protocol must be implemented.
5.4 Master Device
The Master Device, whose architecture was described in section 3.2 and implementation in
section 4.5, is the device responsible for managing the whole system. It must be centered on a
user interface, to allow a user to control the system. Naturally, this user interface needs to be
customized for each biomedical application. In the snapshot depicted in Fig. 5.2 it is possible to
see a serial port being configured. All communications with the embedded system’s ACoM are
emulated by a serial port, which makes it somewhat easier to port the software to interact with
other serial communication media.
In Fig. 5.3 it is possible to see the real-time graphic display, described in section 4.5.3, display-
ing the graphic of an actual biorecognition experiment, using the SPM described in section 4.4.1.
This experiment is actually a sequence of biorecognition experiments, using a successively higher
50
5.4 Master Device
Figure 5.2: Graphical User Interface: Serial Port Configuration
concentration of magnetic markers. Each experiment is comprised of three steps. Firstly, a base-
line is acquired for 5 minutes. Then the solution containing the magnetic markers is dropped on
the sensors. After 20 minutes, the biochip is washed with a phosphate buffer. As there were no
target deoxyribonucleic acid (DNA) on the biosensor, there was no hybridization, thus during the
washing phase the measured valor returned to the baseline. The process is repeated for various
solutions’ concentrations. In the last three experiments the effect of the magnetic nanoparticles is
clearly visible.
Figure 5.3: Graphical User Interface: Real-time graphic display
51
5. Experimental Results
5.5 Remote Server
As explained in section 3.3 the remote server is at its core a data repository. It stores the
data collected in the experiments under the watchful eye of a database management system
(DBMS). The remote server provides two interfaces to the outside world. A web services interface,
using extensible markup language (XML) encapsulated simple object access protocol (SOAP)
messages, and an web browser using plain hypertext transfer protocol (HTTP). The web services
interface is primarily suited for interactions with software, while the web browser is more suitable
for human users. Both of these interfaces were built in PHP: Hypertext Preprocessor (PHP)
technology. PHP is an easy to modify technology, which also acts as an isolator between the
DBMS and the applications that would post or retrieve data from the database. This allows those
applications to stay independent from the DBMS. Fig. 5.4 shows the web browser interface to
the Remote Server. It is possible to see the plot of an experiment, as well as some additional
information pertaining to the measurement.
Figure 5.4: Plain HTML interface to the Remote Server
5.6 Detection of Biomolecules
To further illustrate the measurement capabilities of the system described in this thesis, the
following biomolecular recognition experiment was conducted. Three magnetic labeled solutions
were prepared, by successively diluting by a factor of 10, stock solutions with phosphate buffer.
The magnetic labels used are commercially available 130 nm Nanomag particles [35]. The biochip
52
5.6 Detection of Biomolecules
used is the same as the one described in [36], having 25 magnetoresistive sensors, each with a
minimum resistance of 771±45Ω and a magnetoresistive ratio of 6.56±0.02 %. The sensors were
biased with a 1 mA DC current and the magnetic drive was set to 30 Oe DC and 13.5 Oe rms
AC at 211 Hz. The amplifier on the SPM was set with a gain of 40 and the ADC was configured
to acquire 844 samples per second. The acquired signal then went through a digital bandpass
filter with 1 Hz bandwidth, implemented on the SPM’s microcontroller. Fig. 5.5 shows the results
of the experiment for one of the sensors in the biochip. Each solution was analyzed, starting with
the least concentrated to the most concentrated, in three steps. In the first step a baseline was
acquired for 5 minutes. Then 10 µl of solution were dropped onto the sensors. After 10 minutes,
the biochip was washed with a phosphate buffer. As there were no DNA probes the signal returns
to the baseline previously determined. The results prove that the system can detect 130 nm
magnetic labels in solutions with concentrations of 48×10−12 mol/dm3.
Figure 5.5: Result of a biorecognition experiment
53
5. Experimental Results
54
6Conclusions
Contents6.1 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
55
6. Conclusions
This dissertation presented a generic platform for the development of biological and biomed-
ical systems. The devised architecture allows the system’s components to be isolated from one
another while retaining a great deal of flexibility, which simplifies the process of designing new
biomedical applications. The platform has been in development for quite some time and there is
already a working prototype version of it.
The platform is a three tiered structure. At the lowest tier lie the sensor devices them-
selves. The devices in this tier have two main components: an autonomous communication
module (ACoM) and a sensing and processing module (SPM). The SPM is the only component
custom built for each sensor, and harbors not only the sensors, but also the signal acquisition
system. The ACoM is an intermediary between the sensors in the SPM and the middle tier. The
ACoM isolates the sensors in the SPM from the devices in the middle tier. It also seamlessly
integrates several communication media with the sensors at the SPM. The middle tier aggregates
the data generated by the lower tier sensors and forwards it to the upper tier, thus isolating the
lower tier from the upper tier. The upper tier provides a data repository and an environment where
computationally demanding software can operate over the collected data. In order to make the
system extensible and ease the effort of integrating new components and applications, the plat-
form uses standards wherever possible. So far two biomedical systems have been implemented
in the platform: a biomolecular recognition system, based on magnetoresistive sensors, and a
movement monitoring system, based on accelerometers. The work developed for this thesis was
centered on the development of new functionalities for the already available hardware prototype.
These ranged from communication protocols, to encryption and decryption routines and plotting
graphics.
Communication is an essential capability of any system, as its components will need to com-
municate amongst themselves and with the outside world. In this thesis a number of communica-
tion protocols were developed and implemented in the platform. The throughput of the protocol
chosen to communicate between the lower tier and the middle tier devices was measured, which
revealed shortcomings that might dictate the ineligibility of that protocol for data rate demanding
applications. The communication between the middle tier and the upper tier is assured by a stan-
dard communication protocol, simple object access protocol (SOAP). SOAP web services have
the advantage of being very flexible, and easy to program and modify, precisely the qualities that
this project tries to embody. Another important component of communication is the protection of
the transmitted data. To keep the data traveling between the lower and the middle tier secure, an
encryption module was developed. The module uses a 128-bits implementation of the symmetric
key, block cipher, advanced encryption standard (AES) algorithm which is considered suitable to
protect sensitive information.
As the lower tier devices can be battery-powered portable devices, it is important to minimize
power consumption in order to maximize the device’s autonomy. Having this in mind, several
56
6.1 Future work
software techniques were studied and presented in this thesis. The impact of these techniques on
autonomy was measured in the prototype hardware. Applying these techniques it was possible
to increase the ACoM’s autonomy by over 80%. This lead to an increase in the biorecognition
system’s autonomy of 11% (4h05m of continuous operation) and over 70% (23h45m of continuous
operation) for the movement monitoring system.
During the course of this thesis, a graphics component was built for the Master Device in the
middle tier. The purpose of this component is to provide a human user with feedback from the
lower tier system in real-time. This was done by displaying the incoming data from the lower tier
system on a two axis scatter plot. The end result was not only able to draw a two dimensional
graphic on the Master Device’s screen, but also capable of both zooming and scrolling the graphic.
Those are rather important features when one considers the size of a personal digital assistant
(PDA) screen.
The third tier was also under the scope of this thesis. This tier was implemented with a MySQL
database running on a remote computer. The third tier interacts with both the middle tier devices
using SOAP and web browsers via plain hypertext transfer protocol (HTTP). Both of these inter-
faces were built in PHP: Hypertext Preprocessor (PHP) technology supported by a PHP server.
6.1 Future work
The project presented in this thesis is at a quite advanced state. There is already a working
prototype, in which a couple of biomedical measurement systems have already been successfully
implemented. Nevertheless, there is a large range of issues that can still be improved. Even
though the link between the ACoM and the Master Device is secured via AES, other securities
algorithms may be analyzed, especially when considering the limited resources of the devices
involved. The reason why security algorithms are worth investigating is that there are so many
varieties of them (symmetric key, asymmetric key, block ciphers, stream ciphers), and this project
has only just scratched the surface when it comes to security.
Being a battery-powered portable device, another key concern in this system is its power
consumption, and its autonomy. As with security we have only scratched the surface on this topic.
In this thesis several techniques for lowering power consumption were identified and its impact
on system autonomy was measured. This is just a necessary first step. The next step will be
to develop a control mechanism that dynamically applies and adjusts these techniques to the
application’s needs. Tailoring the system’s energy consumption to its immediate needs, would
maximize the battery’s autonomy.
The life force of the platform presented in this thesis is its applications. The design can en-
dure only as long as there are useful applications developed for it. So far there have only been
two applications developed for this system, a biomolecular recognition system, and a movement
57
6. Conclusions
monitoring one. A larger portfolio would make the system more attractive for developers making
it important to develop more applications for the system. These can be elements of a remote
health monitoring system, like oximeters, blood pressure, electrocardiogram (ECG), etc. Another
interesting feature that might be added is the real-time processing of the collected data. This will
allow emergency situations to be detected as they occur and alarm messages to be generated
and sent to the people best suited to answer the distress call. This would be a great showcase of
the platform’s capabilities.
58
Bibliography
[1] U. Anliker, J. Ward, and P. L. et al., “AMON: a wearable multiparameter medical monitoring
and alert system,” IEEE Transactions on Information Technology in Biomedicine, vol. 8, no. 4,
pp. 415–427, 2004.
[2] A. Wood, G. Virone, T. Doan, Q. Cao, L. Selavo, Y. Wu, L. Fang, Z. He, S. Lin, and
J. Stankovic, “Alarm-net: Wireless sensor networks for assisted-living and residential mon-
itoring,” Department of Computer Science, University of Virginia, Tech. Rep. CS-2006-11,
2006.
[3] C. Otto, A. Milenkovi, C. Sanders, and E. Jovanov, “System architecture of a wireless body
area sensor network for ubiquitous health monitoring,” Journal of Mobile Multimedia, vol. 1,
no. 4, pp. 307–326, 2006.
[4] Tae-Soo Lee, Joo-Hyun Hong, and Myeong-Chan Cho, “Biomedical digital assistant for ubiq-
uitous healthcare,” Engineering in Medicine and Biology Society, 2007. EMBS 2007. 29th
Annual International Conference of the IEEE, pp. 1790–1793, 22-26 Aug. 2007.
[5] M. Blount, V. Batra, A. Capella, M. Ebling, W. Jerome, S. Martin, M. Nidd, M. Niemi, and
S. Wright, “Remote health-care monitoring using personal care connect,” IBM Systems
Journal, vol. 46, no. 1, pp. 95–113, 2007.
[6] Crossbow Technology Inc., “MICAz Wireless Measurement System,” www.xbow.com.
[7] L. Selavo, G. Zhou, and J. Stankovic, “Seemote: In-situ visualization and logging device
for wireless sensor networks,” Broadband Communications, Networks and Systems, 2006.
BROADNETS 2006. 3rd International Conference on, pp. 1–9, Oct. 2006.
[8] G. Virone, M. Alwan, S. Dalal, S. Kell, B. Turner, J. Stankovic, and R. Felder, “Behavioral
patterns of older adults in assisted living,” Information Technology in Biomedicine, IEEE
Transactions on, vol. 12, no. 3, pp. 387–398, May 2008.
[9] T. Wu, “The secure remote password protocol,” 1998 Internet Society Symposium on Network
and Distributed System Security, pp. 97–111, 1998.
59
Bibliography
[10] “FIPS PUB 113, Standard on Computer Data Authentication,” National Institute of Standards
and Technology, May 1985.
[11] D. Whiting, R. Hously, and N. Fergusson, “RFC 3610 - Counter with CBC-MAC (CCM),” IETF,
2003.
[12] E. Jovanov, D. Raskovic, J. Price, J. Chapman, A. Moore, and A. Krishnamurthy, “Patient
monitoring using personal area networks of wireless intelligent sensors,” Biomed Sci Instrum,
vol. 37, pp. 373–378, 2001.
[13] M. T. Inc., “PIC24FJ64GA004 Family Data Sheet,” 2007, ref: DS39881B.
[14] Bluegiga Tech., “WT11 Bluetooth Module,” 2006, version 2.3.
[15] Future Technology Devices International, “FT232R USB UART I.C. Datasheet,” 2005, version
1.04.
[16] M. T. Inc., “Microchip mplab ide,” www.microchip.com.
[17] “Announcing the advanced encryption standard (aes),” Federal Information Processing Stan-
dards Publication 197, 2001.
[18] “National Policy on the Use of the Advanced Encryption Standard (AES) to Protect National
Security Systems and National Security Information,” Committee on Nat. Security Systems
Policy No.15, Fact Sheet No.1, 2003.
[19] R. Chaves, “Secure computing on reconfigurable systems,” Ph.D. dissertation, Delft Univer-
sity of Technology/Instituto Superior Tcnico, UTL, December 2007.
[20] M. T. Inc., “Data Encryption Routines for PIC24 and dsPIC Devices,” 2006, ref: DS01044A.
[21] J. McCaffrey, “Encrypt it: Keep your data secure with the new advanced encryption standard,”
MSDN Magazine, November 2003.
[22] M. Piedade, L. Sousa, T. Almeida, J. Germano, B. Costa, J. Lemos, P. Freitas, H. Ferreira,
and F. Cardoso, “A New Hand-held Microsystem Architecture for Biological Analysis,” IEEE
Trans. on Circuits and Systems I: Regular Papers, vol. 53, no. 11, pp. 2384–2395, Nov. 2006.
[23] D. L. Graham, H. A. Ferreira, and P. P. Freitas, “Magnetoresistive-based biosensors and
biochips,” Trends in Biotechnology, vol. Volume 22, no. 9, pp. 455–462, September 2004.
[24] H. A. Ferreira, D. L. Graham, P. P. Freitas, and J. M. S. Cabral, “Biodetection using mag-
netically labeled biomolecules and arrays of spin valve sensors (invited),” Journal of Applied
Physics, vol. 93, no. 10, pp. 7281–7286, 2003.
60
Bibliography
[25] M. T. Inc., “High Performance Digital Signal Controllers - dsPIC30F6011/6012/6013/6014
DataSheet,” 2006, ref: DS70117F.
[26] T. I. Incorporated, “Ina327: Precision, rail-to-rail i/o instrumentation amplifier,”
http://focus.ti.com/docs/prod/folders/print/ina327.html, last visited on April 2006,
http://focus.ti.com/docs/prod/folders/print/ina327.html.
[27] L. Technology, “Ltc2440: 24-bit high speed differential delta sigma adc with selectable
speed/resolution,” http://www.linear.com/, last visited on April 2006, ref: 2440fa.
[28] J. Germano, “Portable system for dna analysis based on a biochip,” IST, 2006.
[29] P. Silva and R. Matos, “@TOY,” Master’s thesis, Tecnical University of Lisbon, July 2002.
[30] Analog Devices, “ADXL202 Low-Cost ±2 g Dual-Axis Accelerometer with Duty Cycle Out-
put,” REV. A, 2000.
[31] M. T. Inc., “PIC16F84A Data Sheet,” 2001, ref: DS35007B.
[32] I. MySQL AB/Sun Microsystems, “Mysql community edition 5.0,” www.mysql.com.
[33] T. P. Group, “Php: Hypertext preprocessor,” www.php.net.
[34] H. E. Williams and D. J. Lane, Web Database Applications with PHP and MySQL, 2nd ed.
O’Reilly Media, May 2004.
[35] micromod Partikeltechnologie GmbH, “nanomag -D (streptavidin),” www.micromod.de.
[36] H. A. Ferreira, F. A. Cardoso, R. Ferreira, S. Cardoso, and P. P. Freitas, “Magnetoresistive
dna chips based on ac field focusing of magnetic labels,” J. App. Phys., vol. 99, 2006.
61
Bibliography
62
AACoM library documentation
ContentsA.1 Communication with the Master Device . . . . . . . . . . . . . . . . . . . . . . 64A.2 Communication with SPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
63
A. ACoM library documentation
This appendix documents the software application programming interface (API) developed for
the ACoM.
A.1 Communication with the Master Device
This section documents the API for interfacing the ACoM with the Master Device in the middle
tier.
ReadUART from RS232Description: Reads a number of bytes using the UART peripheral
Include: communication COM.hPrototype: char* ReadUART from RS232(int nbytes)
Arguments: nbytes number of bytes to readReturn Value: Pointer to the received data buffer (DataFromPC)
Remarks: - The receiving is interrupt driven: the UART interruptions mustbe enabled.- To save power the processor placed in idle until an UART re-ceive interrupt is triggered.- This function is blocking and only returns when nbytes havebeen received, or a timeout event has occurred (if timeout is en-abled).
Source File: communication COM.c
ReadUART from RS232 strDescription: Reads a stream of bytes using the UART peripheral until a termi-
nation character is receivedInclude: communication COM.h
Prototype: char* ReadUART from RS232 str(char tchar)Arguments: tchar - termination character
Return Value: Pointer to the received data buffer (DataFromPC)Remarks: - The receiving is interrupt driven: the UART interruptions must
be enabled.- To save power the processor placed in idle until an UART re-ceive interrupt is triggered.- This function is blocking and only returns when the terminationcharacter has been received, or a timeout event has occurred (iftimeout is enabled).
Source File: communication COM.c
64
A.1 Communication with the Master Device
receive command pkgDescription: Receives the first portion of a package using a UART peripheral:
- a command byte- size of the rest of the package (data)
Include: communication COM.hPrototype: char receive command pkg(unsigned char *n)
Arguments: n - size of the second portion of the package (the data portion)Return Value: If the command byte received is a valid command then the com-
mand byte is returned, else ’\0’ is returned.Remarks: - The first portion of a package contains two bytes: the first byte
contains the command to be executed, the second byte containsthe size of the following portion of the package (the actual data)- This function is blocking and only returns when 2 bytes havebeen received.- the argument size is NOT the real size of the data portion of thepackage, but the size of the data portion of the package in multi-ples of DATA SIZE (specified by the communication protocol)- The receiving is interrupt driven: the UART interruptions mustbe enabled.- To save power the processor placed in idle until an UART re-ceive interrupt is triggered.
Source File: communication COM.c
65
A. ACoM library documentation
receive data pkgDescription: Receives the second portion of a package:
- dataInclude: communication COM.h
Prototype: void receive data pkg (int n, char* str)Arguments: n - size of the second portion of the package (the data portion)
str - destination bufferReturn Value: none: the received data is returned in the str argument. Should
there be a timeout event, an empty string will be returned (””)Remarks: - This function does NOT create the destination buffer. A large
enough destination buffer should be allocated BEFORE callingthis function.- This function is blocking and only returns when all data byteshave been received, or a timeout event has occurred (if timeoutis enabled).- The argument n is NOT the real size of the data array, but thesize of the array in multiples of DATA SIZE (specified by the com-munication protocol)- The receiving is interrupt driven: the UART interruptions mustbe enabled.- To save power the processor placed in idle until an UART re-ceive interrupt is triggered.
Source File: communication COM.c
receive pkgDescription: Receives a package from a UART peripheral.
A package has:- a command byte- an array of data bytes- the size of the aforementioned array
Include: communication COM.hPrototype: void receive pkg(unsigned char* cmd, char* data, unsigned char*
size)Arguments: cmd - command byte
data - pointer to an array containing the data bytessize - size of the data array
Return Value: none:- the command byte received is returned in the cmd argument.Should the communication fail, cmd will be set to ’\0’.- the received data is returned in the data argument
Remarks: - This function does NOT create the data array. A large enoughdata array should be allocated BEFORE calling this function.- This function is blocking and only returns when a package hasbeen successfully received, or a timeout event has occurred (iftimeout is enabled).- the argument size is NOT the real size of the data array, butthe size of the array in multiples of DATA SIZE (specified by thecommunication protocol)- The receiving is interrupt driven: the UART interruptions mustbe enabled.- To save power the processor placed in idle until an UART re-ceive interrupt is triggered.
Source File: communication COM.c
66
A.1 Communication with the Master Device
send pkgDescription: Sends a package to a UART peripheral.
A package has:- a command byte- an array of data bytes- the size of the aforementioned array
Include: communication COM.hPrototype: void send pkg(unsigned char cmd, char* data, unsigned char
size)Arguments: cmd - command byte
data - pointer to an array containing the data bytessize - size of the data array
Return Value: noneRemarks: - This function is blocking and only returns when a package has
been successfully sent (i.e. an ack confirming the reception of themessage has been received), or a timeout event has occurred (iftimeout is enabled).- The size of the array specified in data MUST be a multiple ofDATA SIZE.- the argument size is NOT the real size of the data array, butthe size of the array in multiples of DATA SIZE (specified by thecommunication protocol)
Source File: communication COM.c
receive strDescription: Receives a string from a remote device using a termination char-
acter protocol.Include: communication COM.h
Prototype: void receive str(char *str)Arguments: str - received string
Return Value: none: the received string is returned in the str argumentRemarks: - The received string must be allocated before calling this func-
tion.- The terminating character is defined in the TERM CHAR macro.- The received string str does NOT include the termination char-acter
Source File: communication COM.c
send strDescription: Sends a string to a remote device over UART, using a termination
character protocol.Include: communication COM.h
Prototype: void send str(char *str)Arguments: str - string to be sent
Return Value: noneRemarks: - The termination character is defined in the TERM CHAR macro.
- The string to be sent, str, MUST NOT include the terminationcharacter
Source File: communication COM.c
67
A. ACoM library documentation
A.2 Communication with SPM
This section documents the API for interfacing the ACoM with the SPM in which the sensors
lie. The developed functions are very similar to the ones presented in the appendix A.1, however
they use a different UART port, making them independent from the others.
ReadUART from RS232 SPMDescription: Reads a number of bytes using the UART peripheral
Include: communication COM.hPrototype: char* ReadUART from RS232 SPM(int nbytes)
Arguments: nbytes number of bytes to readReturn Value: Pointer to the received data buffer (DataFromPC)
Remarks: - The receiving is interrupt driven: the UART interruptions mustbe enabled.- To save power the processor placed in idle until an UART re-ceive interrupt is triggered.- This function is blocking and only returns when nbytes havebeen received, or a timeout event has occurred (if timeout is en-abled).
Source File: communication COM.c
ReadUART from RS232 SPM strDescription: Reads a stream of bytes using the UART peripheral until a termi-
nation character is receivedInclude: communication COM.h
Prototype: char* ReadUART from RS232 SPM str(char tchar)Arguments: tchar - termination character
Return Value: Pointer to the received data buffer (DataFromPC)Remarks: - The receiving is interrupt driven: the UART interruptions must
be enabled.- To save power the processor placed in idle until an UART re-ceive interrupt is triggered.- This function is blocking and only returns when the terminationcharacter has been received, or a timeout event has occurred (iftimeout is enabled).
Source File: communication COM.c
68
A.2 Communication with SPM
receive command pkg SPMDescription: Receives the first portion of a package using a UART peripheral:
- a command byte- size of the rest of the package (data)
Include: communication COM.hPrototype: char receive command pkg SPM(unsigned char *n)
Arguments: n - size of the second portion of the package (the data portion)Return Value: If the command byte received is a valid command then the com-
mand byte is returned, else ’\0’ is returned.Remarks: - The first portion of a package contains two bytes: the first byte
contains the command to be executed, the second byte containsthe size of the following portion of the package (the actual data)- This function is blocking and only returns when 2 bytes havebeen received.- the argument size is NOT the real size of the data portion of thepackage, but the size of the data portion of the package in multi-ples of DATA SIZE (specified by the communication protocol)- The receiving is interrupt driven: the UART interruptions mustbe enabled.- To save power the processor placed in idle until an UART re-ceive interrupt is triggered.
Source File: communication COM.c
69
A. ACoM library documentation
receive data pkg SPMDescription: Receives the second portion of a package:
- dataInclude: communication COM.h
Prototype: void receive data pkg SPM (int n, char* str)Arguments: n - size of the second portion of the package (the data portion)
str - destination bufferReturn Value: none: the received data is returned in the str argument. Should
there be a timeout event, an empty string will be returned (””)Remarks: - This function does NOT create the destination buffer. A large
enough destination buffer should be allocated BEFORE callingthis function.- This function is blocking and only returns when all data byteshave been received, or a timeout event has occurred (if timeoutis enabled).- The argument n is NOT the real size of the data array, but thesize of the array in multiples of DATA SIZE (specified by the com-munication protocol)- The receiving is interrupt driven: the UART interruptions mustbe enabled.- To save power the processor placed in idle until an UART re-ceive interrupt is triggered.
Source File: communication COM.c
receive pkg SPMDescription: Receives a package from a UART peripheral.
A package has:- a command byte- an array of data bytes- the size of the aforementioned array
Include: communication COM.hPrototype: void receive pkg SPM(unsigned char* cmd, char* data, unsigned
char* size)Arguments: cmd - command byte
data - pointer to an array containing the data bytessize - size of the data array
Return Value: none:- the command byte received is returned in the cmd argument.Should the communication fail, cmd will be set to ’\0’.- the received data is returned in the data argument
Remarks: - This function does NOT create the data array. A large enoughdata array should be allocated BEFORE calling this function.- This function is blocking and only returns when a package hasbeen successfully received, or a timeout event has occurred (iftimeout is enabled).- the argument size is NOT the real size of the data array, butthe size of the array in multiples of DATA SIZE (specified by thecommunication protocol)- The receiving is interrupt driven: the UART interruptions mustbe enabled.- To save power the processor placed in idle until an UART re-ceive interrupt is triggered.
Source File: communication COM.c
70
A.2 Communication with SPM
send pkg SPMDescription: Sends a package to a UART peripheral.
A package has:- a command byte- an array of data bytes- the size of the aforementioned array
Include: communication COM.hPrototype: void send pkg SPM(unsigned char cmd, char* data, unsigned
char size)Arguments: cmd - command byte
data - pointer to an array containing the data bytessize - size of the data array
Return Value: noneRemarks: - This function is blocking and only returns when a package has
been successfully sent (i.e. an ack confirming the reception of themessage has been received), or a timeout event has occurred (iftimeout is enabled).- The size of the array specified in data MUST be a multiple ofDATA SIZE.- the argument size is NOT the real size of the data array, butthe size of the array in multiples of DATA SIZE (specified by thecommunication protocol)
Source File: communication COM.c
receive str SPMDescription: Receives a string from a remote device using a termination char-
acter protocol.Include: communication COM.h
Prototype: void receive str SPM(char *str)Arguments: str - received string
Return Value: none: the received string is returned in the str argumentRemarks: - The received string must be allocated before calling this func-
tion.- The terminating character is defined in the TERM CHAR macro.- The received string str does NOT include the termination char-acter
Source File: communication COM.c
send str SPMDescription: Sends a string to a remote device over UART, using a termination
character protocol.Include: communication COM.h
Prototype: void send str SPM(char *str)Arguments: str - string to be sent
Return Value: noneRemarks: - The termination character is defined in the TERM CHAR macro.
- The string to be sent, str, MUST NOT include the terminationcharacter
Source File: communication COM.c
71
A. ACoM library documentation
72
BMaster Device library
documentation
ContentsB.1 Communication Namespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74B.2 Graphic Namespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
73
B. Master Device library documentation
This appendix describes the classes, properties and methods that make up the API developed
for the Master Device.
B.1 Communication Namespace
For communication purposes two classes were developed, the class Message containing the
package that is communicated, and the class Communicator which manages the communication.
B.1.1 Message
Message that is communicated with the package based protocol.
Public Attributes
char command: Command byteint size: size of the data portion of the message, in multiples of DATASIZE
String data: Data in string format. Deprecated, use bdata insteadbyte[] bdata: The actual data in an array of bytes
Constructors
Message ( )Description: Default constructor.Parameters: none
Remarks:Source File: Message.cs
Message (char cmd, int sz, String dt)Description: Creates a message to be sent in the package based protocol.Parameters: cmd - comand byte
sz - size of the data to be sent, in multiples of DATASIZEdt - data portion of the packet in a string format
Remarks: deprecated, use the Message(char cmd, int sz, byte[] dt) insteadSource File: Message.cs
74
B.1 Communication Namespace
Message ( char cmd, int sz, byte[] dt )Description: Creates a message to be sent in the package based protocol.Parameters: cmd - comand byte
sz - size of the data to be sent, in multiples of DATASIZEdt - data portion of the packet in a byte array format
Remarks:Source File: Message.cs
Public Methods
N/A
75
B. Master Device library documentation
B.1.2 Communicator
Encapsulates communications to and from a serial port.
Public Attributes
N/A
Constructor
Communicator ( )Description: Default Constructor.Parameters: none
Remarks:Source File: Communicator.cs
Public Methods
bool Connect ( )Description: Opens a connection through a serial port.return value: true if the serial port is open, false otherwiseParameters: none
Remarks:Source File: Communicator.cs
bool Disconnect ( )Description: Closes a connection to a serial port.return value: true if the serial port is closed, false otherwiseParameters: none
Remarks:Source File: Communicator.cs
bool Read ( Message msg )Description: Reads a package from a serial port using the package based
protocol.return value: true the package is received successfully, false otherwiseParameters: msg - package to be filled with the received information
Remarks: This function is blocking, however, it should return false if a time-out event occurs.
Source File: Communicator.cs
76
B.1 Communication Namespace
String Read ( )Description: Reads all data accumulated on the serial port buffer.return value: a string containing the data on the serial port’s reception bufferParameters: none
Remarks:Source File: Communicator.cs
bool Write ( Message msg )Description: Writes a package to a serial port using the package based proto-
col.return value: true the package is sent successfully, false otherwiseParameters: msg - package to be sent
Remarks: This function is blocking, however, it should return false if a time-out event occurs.
Source File: Communicator.cs
bool Write ( String str )Description: Writes a string to a serial port.return value: true the string is sent successfully, false otherwiseParameters: str - string to be sent
Remarks: This function is blocking, however, it should return false if a time-out event occurs.
Source File: Communicator.cs
String Read str ( )Description: Reads a string from a serial port using a termination character
protocol.return value: the read string, or null if an error occuredParameters: none
Remarks: This function is blocking, however, it should return null if a timeoutevent occurs.The returned string does not include the termination character.
Source File: Communicator.cs
77
B. Master Device library documentation
bool Write str ( String str )Description: Writes a string to a serial port using a termination character pro-
tocol.return value: true the string was sent successfully, false otherwiseParameters: str - string to be sent
Remarks: This function is blocking, however, it should return false if a time-out event occurs.The string to be sent must not contain the termination character.
Source File: Communicator.cs
void configureSerialPort ( SerialPortSettings settings )Description: Configures the serial port used by the component.return value: noneParameters: settings - structure containing the serial port’s configuration
Remarks:Source File: Communicator.cs
SerialPortSettings getSerialPortConfiguration ( )Description: Gets the serial port’s configuration.return value: structure containing the configuration of the internal serial portParameters: none
Remarks:Source File: Communicator.cs
78
B.2 Graphic Namespace
B.2 Graphic Namespace
This component draws a 2D scatter plot. It is comprised by four classes. The class GraphPoint
stores the information on a single point. The class ListData aggregates these points into a data
series. The class ListGraphs gathers a collection of data series. Lastly, the class GraphMotor
scales plots and paints the graphic.
B.2.1 GraphPoint
Point to represent in the graph
Public Attributes
decimal X: X coordinatedecimal Y: Y coordinate
Constructors
GraphPoint ( )Description: Default constructor.Parameters: none
Remarks:Source File: GraphPoint.cs
Public Methods
N/A
79
B. Master Device library documentation
B.2.2 ListData
A collection of data points
Public Attributes
decimal XMax: Maximum value of X in the points in the componentdecimal YMax: Maximum value of Y in the points in the componentdecimal XMin: Minimum value of X in the points in the componentdecimal YMin: Minimum value of Y in the points in the component
System.Drawing.Color DisplayColor: Gets or sets the colour of the seriesGraphPoint this [int i]: Data point
int Count: Gets the number of points in the series
Constructors
ListData ( )Description: Default constructor.Parameters: none
Remarks:Source File: ListData.cs
Public Methods
void Add ( GraphPoint value )Description: Adds a point to the series.return value: noneParameters: value - point to be added
Remarks:Source File: ListData.cs
void Add ( GraphPoint value )Description: Adds a point to the series.return value: noneParameters: value - point to be added
Remarks:Source File: ListData.cs
80
B.2 Graphic Namespace
void CalculateMax ( )Description: Calculates the maximum and minimum values of all the points in
the present series.return value: noneParameters: none
Remarks: The results are stored in the class’ propertiesXmax,Xmin,Ymax,Ymin
Source File: ListData.cs
decimal[] CalculateMax ( decimal xmin, decimal xmax )Description: Calculates the maximum and minimum values of all the data
points in the series, within a given interval.return value: An array with the minimum and maximum values of all the points
in a given interval:in the position 0 is the minimum Y value,in the position 1 is the maximum Y value
Parameters: xmax upper limit if the intervalxmin lower limit of the interval
Remarks: This method is mostly useful to autoscale the Y axis whilescrolling through the graphic.
Source File: ListData.cs
81
B. Master Device library documentation
B.2.3 ListGraphs
A collection of data series.
Public Attributes
int Count: Counts the number of series in the component
Constructors
ListGraphs ( )Description: Default constructor.Parameters: none
Remarks:Source File: ListGraphs.cs
Public Methods
void Add ( ListData value )Description: Adds a series to the component.return value: noneParameters: value - data series to be added
Remarks:Source File: ListData.cs
82
B.2 Graphic Namespace
B.2.4 GraphMotor
Graphics component top level entity
Public Attributes
int gXorig: Left marginint gYorig: Top Margin
int gHeight: Graphic’s Heightint gWidth: Graphic’s Width
decimal Xmax: Window’s upper limit in the X axisdecimal Xmin: Windows’s lower limit in the X axis
int Xdiv: Number of divisions on the X axisdecimal Ymax: Window’s upper limit in the Y axisdecimal Ymin: Window’s lower limit in the Y axis
int Ydiv: Number of divisions on the Y axisint rsize: Size of the drawn points
string Xaxisname: Title of the horizontal axisstring Yaxisname: Title of the vertical axis
int XaxisnameVerticalCorrection: Corrects the position of the axis’ titleint XaxisnameHorizontalCorrection: Corrects the position of the axis’ title
int YaxisnameVerticalCorrection: Corrects the position of the axis’ titleint YaxisnameHorizontalCorrection: Corrects the position of the axis’ title
ListGraphs Graphs: Collection of graphsSystem.Drawing.Color AxisColor: Color of X Axis and Y Axis
System.Drawing.Color LegendColor: Color for data in X Axis and y AxisSystem.Drawing.Font LegendFont: Color for data in X Axis and y Axis
Constructors
GraphMotor ( )Description: Default constructor.Parameters: none
Remarks:Source File: GraphMotor.cs
Public Methods
void drawaxis ( System.Windows.Forms.PaintEventArgs e )Description: Paints the axis on the screen.return value: noneParameters: e - The guy who actually does the drawing
Remarks: This function not only draws the axis, but also the axis’ divisions,titles and values.
Source File: GraphMotor.cs
83
B. Master Device library documentation
void plotgraphic ( System.Windows.Forms.PaintEventArgs e )Description: Plots and paints the graphic.return value: noneParameters: e - The guy who actually does the drawing
Remarks: This function does it all: paints the axis, scales the points andpaints the points.This function should be called by the paint event of a form, sothat every time the form is repainted so is the graphic.
Source File: GraphMotor.cs
decimal [] getextremes ( )Description: Calculates the maximum and minimum values of all the data
points in all series.return value: An array with the minimum and maximum values of all the points
in the component:in the position 0 is the minimum X value,in the position 1 is the maximum X value,in the position 2 is the minimum Yvalue, in the position 3 is the maximum Y value
Parameters: noneRemarks: Useful function when autoscaling a graphic
Source File: GraphMotor.cs
decimal [] getextremes ( decimal xmin, decimal xmax )Description: Calculates the maximum and minimum values of all the data
points in all series, within a given interval.return value: An array with the minimum and maximum values of all the points
in a given interval:in the position 0 is the minimum Y valuein the position 1 is the maximum Y value
Parameters: xmax - upper limit if the intervalxmin - lower limit of the interval
Remarks: This method is mostly useful to autoscale the Y axis whilescrolling through the graphic.
Source File: GraphMotor.cs
84