Sistema Embebido para Aplicac¸oes Biom˜ edicas´His vision was an inspiration throughout this...

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


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


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


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


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


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


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


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.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


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


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


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


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


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


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


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


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.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


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).


64


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.


65


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.


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.


66


send pkgDescription: Sends a package to a UART peripheral.


Include: communication COM.hPrototype: void send pkg(unsigned char cmd, char* data, unsigned char

size)Arguments: cmd - command byte


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)


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


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


67


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).


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).


68


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.


69


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.


receive pkg SPMDescription: Receives a package from a UART peripheral.


Include: communication COM.hPrototype: void receive pkg SPM(unsigned char* cmd, char* data, unsigned

char* size)Arguments: cmd - command byte


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.


70


send pkg SPMDescription: Sends a package to a UART peripheral.


Include: communication COM.hPrototype: void send pkg SPM(unsigned char cmd, char* data, unsigned

char size)Arguments: cmd - command byte


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)


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


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


71


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


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.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


bool Disconnect ( )Description: Closes a connection to a serial port.return value: true if the serial port is closed, false otherwiseParameters: none


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


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


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



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



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.


77


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.


void configureSerialPort ( SerialPortSettings settings )Description: Configures the serial port used by the component.return value: noneParameters: settings - structure containing the serial port’s configuration


SerialPortSettings getSerialPortConfiguration ( )Description: Gets the serial port’s configuration.return value: structure containing the configuration of the internal serial portParameters: none


78

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.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


void Add ( GraphPoint value )Description: Adds a point to the series.return value: noneParameters: value - point to be added


80


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.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


82


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


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.


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


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.


84

Sistema Embebido para Aplicac¸oes Biom˜ edicas´His vision was an inspiration throughout this...

Documents

Transcript of Sistema Embebido para Aplicac¸oes Biom˜ edicas´His vision was an inspiration throughout this...