CASE2011_Libro_de_Trabajos.pdf

7/15/2019 CASE2011_Libro_de_Trabajos.pdf

http://slidepdf.com/reader/full/case2011librodetrabajospdf 1/234

CASE 2011www.sase.com.ar

2 al 4 de Marzo de 2011

UTN-FRBA, Buenos Aires, Argentina

Libro de TrabajosLibro de Trabajos

Publicación realizada con el apoyo de: Agencia Nacional de Promoción Científica y Tecnológica

CONICET - Consejo Nacional de Investigaciones Científicas y Técnicas

TWAS - The Academy of Sciences for the Developing World





CASE 2011CASE 2011

Libro de Trabajos

Congreso Argentinode

Sistemas Embebidos

2 al 4 de Marzo de 2011UTN-FRBA, Buenos Aires, Argentina

i





ISBN 978-987-9374-69-6

Libro de TrabajosCASE-Congreso Argentino de Sistemas Embebidos 2011

Edición de contenido: Diego J. Brengi y Ariel Lutenberg

Copyright © 2011. FIUBA- Facultad de Ingeniería - Universidad de Buenos Aires.Copyright © 2011. UTN-FRBA - Universidad Tecnológica Nacional - Facultad Regional

Buenos Aires.Copyright © 2011. INTI- Instituto Nacional de Tecnología Industrial.

Se otorga permiso para copiar y redistribuir este libro de trabajos, siempreque se mantengan los mensajes de copyright y autoría de la obra y sus partes.

ii



Prefacio

“Sistema embebido” es el nombre que reciben los equipos electrónicos queincluyen el procesamiento de datos, pero que a diferencia de una computa-dora personal, están diseñados para satisfacer una función específica, comoser un reloj, un reproductor de MP3, un teléfono celular, un router o el con-trol de un automóvil (ECU).

El cerebro de un sistema embebido (S.E.) es típicamente un microcontrolador,aunque los datos también pueden ser procesados por un DSP, una FPGA, unmicroprocesador o un ASIC, y su diseño está optimizado para reducir su ta-maño, su costo y/o su consumo, aumentar su confiabilidad y mejorar su de-sempeño.

El diseño de sistemas embebidos es un motor clave de la industria y del desa-rrollo científico y tecnológico, y es un campo que en los últimos años ha creci-do notablemente en la Argentina, tanto en la academia como en la industria.

Entre el 3 y el 5 de Marzo de 2010 se desarrolló en la FIUBA el primer SimposioArgentino de Sistemas Embebidos, SASE 2010. Del evento participaron 500personas (58% Academia, 42% Industria), contando con el auspicio de 32 uni-versidades, 13 empresas y 10 instituciones, y se ofrecieron 34 tutoriales, 6plenarias, 5 workshops y 2 concursos (ver www.sase.com.ar).

El SASE 2011 se desarrolló entre el 2 y el 4 de Marzo de 2011 en la UTN-FRBA yparticiparon cerca de 1000 personas de la industria y la academia, contandocon el auspicio de 50 universidades, 30 empresas y 15 instituciones, en elmarco de un evento de bajo costo, orientado a la comunidad argentina y lati-noamericana, y abierto a todos los interesados en participar.

Como parte del SASE 2011 se realizaron las siguientes actividades:

• CASE - Congreso Argentino de Sistemas Embebidos, presentación traba-jos científicos.

• Workshops: 15 talleres prácticos en la modalidad hands-on.• Tutoriales: 120 charlas de capacitación.• Plenarias: 6 conferencias y debates abiertos.• Concurso de proyectos estudiantiles: sobre trabajos finales de gradua-

ción.• Concurso de emprendimientos tecnológicos: destinado a promover em-

prendimientos electrónicos con viabilidad económica.• Programa de equipamiento para universidades: para transferir a las uni-

versidades las donaciones de los auspiciantes.• Becas de viaje y alojamiento: se entregaron 116 ayudas económicas

para estudiantes de grado, estudiantes de doctorado, docentes e inves-

tigadores, de Argentina y Latinoamérica.

iii



El CASE fue una de las actividades centrales del evento, siendo sus objetivos:

• Ofrecer un lugar de encuentro para investigadores y becarios de todo el

país, fomentando la colaboración.• Difundir en el medio académico los adelantos científicos y tecnológicos

producidos a nivel mundial.• Propiciar la presentación y discusión de trabajos de investigación desa-

rrollados en Argentina.• Estimular en los estudiantes universitarios avanzados el interés por la

investigación en el área de los S.E.• Difundir los proyectos de investigación mediante el desarrollo de un si-

tio web.• Coordinar y actualizar los contenidos de S.E. de los programas de grado

y posgrado de las universidades argentinas.

Entre los temas de interés del CASE pueden mencionarse ASICs, Arquitecturasde microcontroladores, DSPs, Electrónica espacial, FPGAs, Linux embebido,Low-power, Robótica, RTOS, Softcores, Software embebido, Verilog y VHDL,entre otras.

Los trabajos presentados al CASE fueron sometidos a un proceso de revisión ycorrección. De este modo fueron seleccionados 28 artículos y 22 pósters. Estos50 trabajos se publican en esta memoria y también están disponibles en formaonline en la página www.sase.com.ar/2011

Esperamos que los trabajos recopilados en esta memoria sean de su interés ycontamos con su participación en futuras ediciones del evento.

Atentamente,

Dr. Ariel LutenbergComité Organizador CASE 2011

iv



Empresas Auspiciantes

Electrocomponentes S.A. (Argentina) Cika S.R.L. (Argentina) ELKO/Arrow Argentina (Argentina) Electrónica Elemon S.A. (Argentina) ARM Ltd. (USA) Agilent Technologies (USA) NXP Semiconductors (USA) Motorola Solutions (USA) Atmel Corp. (USA) Freescale Semiconductor (USA) Texas Instruments Inc. (USA) Microchip Technology Inc. (USA) Emtech Embedded Technologies (Argentina) Apexar Technologies (Argentina) Synopsis (USA) Intel Argentina (Argentina) Inarci S.A. (Argentina) Dai Ichi Circuitos S.A.(Argentina) Mayer S.A.(Argentina) ST Microelectronics Inc. (USA) SmartCore uBlox (Brasil) Probattery (Argentina) Macon Máquinarias y consumibles S.R.L. (Argentina) Sequoia Space (Colombia) Revista Mercado Electrónico (Argentina) INVAP S.E. (Argentina) Miteco S.R.L. (Argentina) Clariphy Argentina S.A. (Argentina) Semak S.A. (Argentina) HT S.A. (Argentina) Tecnonergía (Argentina)

v



Instituciones Auspiciantes

MinCyT

ANPCyT (Agencia)

CONICET

CONAE

CONEA

CITEDEF

INTI

CADIEEL

IEEE Argentina

AADECA PAE-37079

TWAS

Universidades Auspiciantes

Instituto Tecnológico de Buenos Aires

Instituto Universitario Aeronáutico

Universidad Blas Pascal Córdoba Universidad CAECE de Mar del Plata

Universidad Católica de Córdoba

Universidad Católica de Santiago del Estero

Universidad Católica del Uruguay (Uruguay)

Universidad de Buenos Aires

Universidad de la República (Uruguay)

Universidad de Mendoza

Universidad Nacional de Catamarca

Universidad Nacional del Centro

Universidad Nacional del Comahue

Universidad Nacional de Córdoba

Universidad Nacional de Cuyo

Universidad Nacional de Entre Ríos

Universidad Nacional de La Matanza

vi



Universidad Nacional de La Patagonia

Universidad Nacional de La Plata

Universidad Nacional de Mar del Plata

Universidad Nacional de Misiones

Universidad Nacional de Quilmes

Universidad Nacional de La Patagonia

Universidad Nacional de Río Cuarto

Universidad Nacional de Rosario

Universidad Nacional de Salta

Universidad Nacional de San Juan

Universidad Nacional de San Luis

Universidad Nacional de San Martín

Universidad Nacional del Sur

Universidad Nacional de Tres de Febrero

Universidad Nacional de Tucumán

UTN-FRA (Avellaneda)

UTN-FRBA (Buenos Aires)

UTN-FRBB (Bahía Blanca)

UTN-FRC (Córdoba)

UTN-FRD (Delta)

UTN-FRH (Haedo)

UTN-FRLR (La Rioja)

UTN-FRM (Mendoza)

UTN-FRN (Neuquén)

UTN-FRP (Paraná)

UTN-FRRG (Río Grande)

UTN-FRSF (San Francisco)

UTN-FRSN (San Nicolás)

UTN-FRVT (Venado Tuerto)

UTN-FRVM (Villa María)

UTN-FRT (Tucumán)

vii



Comité Organizador

Dra. Patricia Borensztejn (FCEN-UBA)

Ing. Diego Brengi (INTI/UNLaM)

Ing. Julián Bruno (UTN-FRBA)

Ing. Milton Castro Genovese (UNTreF)

Dr. Armentano Feijoo (UTN-FRBA)

Dr. Claudio Delrieux (UNS)

Dra. Luciana De Micco (UNMDP)

Ing. Alejandro Furfaro (UTN-FRBA)

Msc. Guillermo Guichal (Emtech/UTN-FRBB) Pedro Julián (UNS)

Dra. Hilda Larrondo (UNMDP)

Dr. José Lipovetzky (FI-UBA)

Dr. Ariel Lutenberg (FI-UBA)

Dr. Mario Mastriani (UNTreF)

Dr. Pablo Mandolesi (UNS)

Ing. Gustavo Mercado (UTN-FRM)

Dr. Leonardo Rey Vega (FI-UBA)

Ing. Aníbal Romandetta (UNTreF) Dr. Ricardo Sánchez Peña (ITBA)

Ing. Gerardo Sager (UNLP)

Msc. Cristian Sisterna (UNSJ)

Dr. Elías Todorovich (UNICEN)

Ing. Salvador Tropea (INTI) Ing. Ignacio Zaradnik (UNLaM)

Coordinación General

Dr. Ariel Lutenberg (FI-UBA)

Ing. Diego Brengi (INTI/UNLaM)

viii



Revisores

Jorge Alberto Mauro Koenig

Ricardo Arias Hilda Angela Larrondo

German Bassi Jose Lipovetzky

Patricia Borenzstejn Ariel Lutenberg

Diego Brengi Pedro Martos

Daniel Cabbibo Gustavo Mercado

Lucas Chiesa Rafael Oliva

Claudio Delrieux Franco Pessana

Carlos Demarziani Leonardo Rey Vega

Luciana Demicco Gaston Rodriguez

Francisco Ditaranto Cristian Sisterna

Andrés Djordjalian Hernán E. Tacca

Fabiana Ferreira Elías Todorovich

Alejandro Furfaro Salvador Tropea

Mariano Andrés García Inza Claudio Verrastro

Carlos Arturo Gayoso Gustavo Zabaleta

Juan Carlos Gómez Ignacio Zaradnik

Pedro Julian

ix



ÍNDICE

ARTÍCULOS 1

ASICs 3

Sistema de Medición Remoto Basado en Dispositivos FPGA 5

Red de Sensores Hospitalaria para la Medición de Presión Endotraqueal 10

Post-silicon Validation Procedure for a PWL ASIC MicroprocessorArchitecture

15

DSPs 21

Desarrollo e Implementacion de un Controlador Activo de Ruido de BandaAngosta Adaptativo 23

Prototipado rápido para sistemas embebidos en FPGA - Desarrollo de latrasformada Wavewlet en 2-D 29

FPGA, Verilog, VHDL y HDLs 35

Implementación en FPGA de decodificadores LDPC de baja complejidad 37

Generador de Números Pseudoaleatorios Mediante el Sistema Numérico deResiduos, Implementación en FPGA 42

Implementación del algoritmo QRD-RLS sobre FPGA,Aplicación a un SistemaCancelador de Ruido 48

Diseño de un Sistema para el Control de Posición de un Motor DC Basado enFPGA 53

Implementación del procesador CortexM0 DesignStart en una fpga de rangobajo 59

Sistemas en Chip acelerados por hardware: comparación de performanceen aplicaciones criptográficas 64

Linux Embebido 71

El papel del Hardware copyleft en la Enseñanza de Sistemas Embebidos 73

Desarrollo de un equipo para grabar los sonidos de los bovinos a laintemperie 79

Dispositivo de rehabilitación visual basado en sistemas embebidos del tipoARM 85

Protocolos y Comunicaciones 89

Análisis del Desempeño de un Algoritmo de Localización para Redes deSensores 91

Tecnología inalámbrica Near Field Communication y sus aplicaciones ensistemas embebidos 97

Cost Effective Cross-layer Protocol Testing: A Case Study 103

Robótica 109

Butiá: Plataforma robótica genérica para la enseñanza de la informática 111

x



Librerías embebidas para microcontroladores LPC2000 de aplicación enrobótica 115

Filtro complementario para estimación de actitud aplicado al controladorembebido de un cuatrirrotor 120

Software Embebido 127

Aplicación Web embebida para el control de payload de un satélite 129

Enfoque embebido para una Estación Meteorológica con Interfaz Web 135

Diseño de un sistema de actualización de firmware para un sistemaembebido 140

Actualización parcial de software embebido en tiempo de ejecución ensistemas sin RTOS 146

Muestreo y Adquisición Inteligente de Señales Sensoriales en SistemasEmbebidos 152

Controlador de carga para un sistema fotovoltaico aislado 158

Sistema de Emergencia Remoto Basado en GSM 163

Ventricular Fibrillation Detection Algorithm Implemented in a Cell-PhonePlatform 168

POSTERS 175

Arquitecturas de Microcontroladores 177

Comparación del desempeño de microcontroladores AVR de 4ta generación 179Anemómetro Ultrasónico 3D empleando Arquitecturas Analógica-DigitalReconfigurables

180

ASICs 181

Detector Activo de Corrientes de Fuga 183

Fabricación de un circuito integrado digital conversor Serie-Paralelo yParalelo-Serie en un proceso CMOS de 0.5 mμ

184

FPGA, Verilog, VHDL y HDLs 185

Control Automático de Ganancia sobre un CPLD 187

Aplicaciones de FPGA de tecnología flash al control de motores eléctricos decorriente alterna 188

Montaje de Experimentación para Óptica Adaptativa Astronómica con FPGA 189

Implementación de MODBUS en FPGA mediante VHDL, Capa de Enlace 190

Implementación en FPGA de Ruido Gaussiano para simulaciones enHardware

191

Implementación de Sistemas Embebidos 193

Sistema para medición optoelectrónica del secado de pinturas 195

Kit Educativo basado en microprocesador de 32 bits 196

Sistema de adquisición de datos para estudios interferométricos 197

xi



Anotador Braille Electrónico Parlante 198

Esquema de control de un microdisplay LCD 199

Linux Embebido 201

Single Board Computer Basada en ARM9 y FPGA para Procesamiento deImágenes Digitales 203

Diseño de un reloj sidereo sobre una plataforma uClinux y FPGA 204

Protocolos y Comunicaciones 205

Herramienta para depuración de redes de sensores inalámbricos 207

The Wireless Embedded Internet 208

Robótica 209

Implementación de rutinas de Control óptimo en micros de 8/32 bits 211

Sensado basado en visión para el control de un sistema Ball & Beam 212

RTOS 213

Sistema portátil para adquisición, monitorización y registro de señales deECG en tiempo real

215

Estación de Control para Red de Sensores Inalámbricos Implementada conRTOS

216

xii



1

www.sase.com.ar www.sase.com.ar

2 al 4 de marzo de 20112 al 4 de marzo de 2011

UTN-FRBA, Buenos Aires, Argentina UTN-FRBA, Buenos Aires, Argentina

ARTÍCULOS



2






3




ASICs



4






5




Sistema de Medicion Remoto Basado en

Dispositivos FPGA

Pablo D. Pareja Obregon, Alfredo Falcon, Martın Di Federico

Pablo S. Mandolesi, Pedro M. JulianDpto de Ing. Electrica y de Computadoras


Bahıa Blanca, Argentina

[email protected]

Resumen—En el presente trabajo, se desarrolla un sistemade medicion automatizado utilizando un dispositivo FPGA comonodo de medicion y una computadora como nodo maestro derecoleccion de datos. La arquitectura es extendible a distintos

dispositivos de medida, cambiando las variables a controlar ypudiendo utilizarse en aplicaciones remotas.

Este sistema fue desarrollado por el Grupo de Investigaci onen Sistemas Electronicos y Electromecatronicos (GISEE) de laUniversidad Nacional del Sur.1

En el trabajo se trata la concepcion, el dise ˜ no, y el desarrollodel sistema hasta llegar al sistema terminado.

I. INTRODUCCION

Las redes de datos son una de las areas tecnologicas con

mayor desarrollo en la actualidad. Sus aplicaciones van desde

las telecomunicaciones, sistemas de seguridad, sistemas mul-

timedia, hasta redes de sensores y sistemas embebidos[1][2].

Esto trae como consecuencia la tendencia actual a utilizarredes LAN o incluso conexiones directas a internet para

controlar diversos dispositivos de la vida cotidiana[3]. Acorde

con dicha tendencia, muchos modulos de sistemas embebidos

ya vienen con soluciones y herramientas para redes Ethernet

incorporadas. Esto facilita su incorporacion en sistemas de

medicion remotos, ası como acelera el tiempo de desarrollo

de aplicaciones controlables a distancia.

Otra tecnologıa que esta ganando terreno, debido a su

flexibilidad y potencia son los arreglos logicos programables

en campo (FPGA)[4]. La posibilidad de programar las FPGA

en tiempo de ejecucion, sin moverlas del lugar de aplicacion,

es un factor clave a la hora de definir la arquitectura a utilizar

en el diseno[5]. Actualmente los desarrollos con FPGAs,pueden aprovechar modulos de Ethernet y microprocesadores

que ya vienen embebidos en las mismas.

1El presente trabajo fue sustentado parcialmente por la Agencia Nacionalde Promocion Cientıfica y Tecnologica (ANPCyT), Proyecto PICT 14628, ypor la UNS, Proyecto PGI 24/ZK12.

P. Julian es miembro del Consejo Nacional de Investigaciones Cient ıficasy Tecnicas CONICET, Av. Rivadavia 1517, Buenos Aires, Argentina.

P. Mandolesi es miembro de CIC (Comision de Investigaciones Cientıficas),Pcia. Bs. As, La Plata, Argentina.

P. Pareja Obregon es becario del Consejo Nacional de InvestigacionesCientıficas y Tecnicas CONICET, Av. Rivadavia 1517, Buenos Aires, Ar-gentina.

A. Falcon es becario PRH de la Universidad Nacional del Sur, Av. Colon80, Bahıa Blanca, Argentina.

Como ventaja adicional de los sistemas de medida remotos,

se encuentra la posibilidad de enviar comandos desde una

estacion de trabajo, sin la necesidad de encontrarse f ısicamente

en el lugar donde se esta realizando la medida. Esto resultaparticularmente util cuando la variable a medir se encuentra

en lugares de dif ıcil acceso, como es el caso de variables

ambientales en zonas geograficas protegidas.

Este paradigma de sistemas de medida descentralizados,

viene con problematicas de sincronizacion asociadas. Definir

el nodo maestro y los nodos esclavos en estas comunicaciones,

es uno de los puntos clave a la hora de comenzar el desarrollo

de cualquier sistema. La sincronizacion de los mismos debera,

a su vez, tener en cuenta como se almacenaran los datos

recibidos y discriminar las fuentes de datos en el caso de

contar con mas de un nodo. Al mismo tiempo, la informacion

temporal de los datos es un parametro clave en transmisiones

sujetas al ruido con posible perdida de informacion en elcamino.

Una red de sensores consiste en un conjunto de nodos con

capacidad de sensado y calculo limitadas, que pueden coor-

dinarse a traves de comunicaciones inalambricas o cableadas,

con el proposito de llevar adelante alguna tarea. La utilizacion

de redes de sensores nos permite disponer de diversos tipos

de informacion, al instante y desde cualquier sitio. En el

presente trabajo, se desarrolla un sistema de medicion remoto

utilizando un dispositivo FPGA como nodo de medicion

y una computadora como nodo maestro de recoleccion de

datos[6][7].

El dispositivo a medir consiste en un conversor de corriente

a corriente, utilizado en la medicion de los tiempos de respues-ta de un fototransistor. El objetivo del trabajo es obtener las

mınimas corrientes necesarias en el emisor, para cada valor de

tiempo de encendido del mismo. De esta manera, contando con

todos los pares de valores de corrientes de emisor y tiempos

de encendido, se puede obtener el punto optimo de trabajo

para cualquier aplicacion en particular.

El presente trabajo se divide de la siguiente manera: en la

seccion II se describe la arquitectura del sistema de medicion

propuesto, para luego desarrollar con mayor profundidad cada

uno de los bloques implementados. En la seccion III se

muestran los resultados experimentales obtenidos, durante la

etapa de evaluacion del sistema, ası como un analisis de los



6




tiempos de medida resultantes en relacion con la resolucion

de los datos. En la seccion IV se describen futuras mejoras en

el sistema de medida y finalmente en la seccion V se detallan

las conclusiones del trabajo.

II. DESARROLLO

El sistema propuesto ha sido disenado de forma de asegurar

maxima flexibilidad y facilidad de uso. Dado que en nues-

tra aplicacion en particular, se requieren variar los diversos

parametros de la medicion, es necesario que los algoritmos

sean genericos y de f acil extension. Ası se logran modificar

los tiempos y resoluciones de la medicion de manera sencilla

y en tiempo de ejecucion.

Aun cuando el uso de redes de sensores es muy venta-

joso en muchas aplicaciones, se deben tener en cuenta sus

limitaciones[8][9]. Cuando las redes utilizadas estan compues-

tas por nodos inalambricos, para evitar el cambio periodico de

las fuentes de alimentacion, un bajo consumo de energıa es unrequerimiento fundamental en el diseno. En nuestra aplicacion

en particular, debido a que todos los nodos utilizados por el

momento cuentan con conexion directa a la red de energıa,

el bajo consumo no es un parametro de peso en el diseno del

sistema. Por otra parte, tambien existe un lımite en cuanto a la

memoria que disponen los nodos (FPGA) y su capacidad de

procesamiento. En el sistema desarrollado, para evitar trabajar

en el lımite de la memoria de nuestra FPGA los datos son

enviados de manera asincronica en el momento en que son

adquiridos, utilizando el protocolo estandar de comunicaciones

RS232.

La aplicacion de un sistema de medicion descentralizado es

un proceso que comprende diversas etapas a mencionar, nodode control maestro, nodos de medicion esclavos, relevamiento

de datos, transmision de paquetes obtenidos, y finalmente

analisis de datos relevados. Cada una de estas etapas sera ex-

plicada con mayor detalle en las secciones siguientes.

II-A. Sistema

Un esquema del sistema completo se muestra en la Fig.

1. Nuestro dispositivo a medir consiste en un circuito, cuyos

parametros a modificar son la corriente de entrada (I e) y el

tiempo de encendido (tduty)[10]. Para cada par de valores

tiempo-corriente, obtenemos una tension de salida V out =f (I e, tduty). Dicha salida es una senal digital que puede valer

0 o 1, es decir tiene un bit de ancho de palabra. Por otra parte,tambien existe una senal de reset que nos permite efectuar una

nueva medicion. El objetivo de nuestro ensayo, consiste en

levantar la curva de corrientes I e mınimas necesarias para que

transicione la salida, en funcion del tiempo tduty de encendido.

El sistema de medida disenado consiste en una FPGA, que

es la encargada de manejar las senales digitales del banco

de pruebas, una computadora que actua como nodo maestro,

y una fuente de corriente de precision Agilent E5270B. El

ensayo, que se muestra en la Fig. 2, consiste en ir tomando

sucesivos valores de corriente I e, los cuales son controlados

entre un valor mınimo de 5 µ A y un valor maximo de 15 mA.

Estos valores son ajustados mediante un script en Matlab,

Figura 1. Sistema total

que a su vez se comunica con la fuente de corriente Agilent

E5270B para fijar los valores propiamente dichos. Por otra

parte, para cada valor de corriente, se envıa una senal de

control a la FPGA para que comience las mediciones. Dicha

senal de control se transmite mediante una comunicacion serie

RS232[11]. Para cada medicion, la FPGA reiniciara el circuito

mediante un pulso digital de reset. A su vez, controlar a la senal

tduty a traves de la llave S 1 que permite que la corriente I ellegue a un diodo emisor de luz. Durante los tiempos de apa-

gado de la llave S 1, la corriente I e es derivada a tierra. La luz

emitida llegara a la base de un fototransistor, que producir a la

corriente de entrada al circuito de pruebas. Dicha corriente

se integrara sobre una capacidad que finalmente producira la

tension de salida V out. Al variar el tiempo de encendido tdutyse puede controlar la cantidad de tiempo que se integra luz,

y en consecuencia obtener el mınimo tiempo necesario para

detectar una corriente determinada. A su vez, la tension digital

de salida es muestreada por la FPGA. La misma transmitira el

dato resultante a la computadora, mediante una comunicacion

serie. El script en Matlab recibira los datos, los almacenara en

una variable y comenzara el proceso nuevamente para unacorriente mayor.

En este esquema, donde la computadora corriendo Matlab

representa el nodo maestro, y tanto la fuente de corrien-

te Agilent E5270B como la FPGA los nodos esclavos, la

principal problematica a abordar es la sincronizacion entre

el nodo maestro y los nodos esclavos. Para simplificar di-

cha sincronizacion, se decidio utilizar un protocolo estandar,

robusto y ampliamente probado, como es el protocolo serie

de comunicacion RS232. Para la fuente de corriente Agilent

E5270B, sin embargo, se decidio establecer la comunicacion

utilizando el protocolo GPIB, debido a la disponibilidad de

las librerıas necesarias.



7




Figura 2. Ensayo realizado

II-B. Nodo de Control Maestro

El control del nodo maestro se realiza mediante un script

de Matlab. Un esquema del mismo se muestra en la Fig.

3. Basicamente consiste en ir fijando sucesivos valores de

corriente en la fuente Agilent E5270B, dar la orden a la FPGA

de comenzar una nueva corrida de mediciones, y esperar los

resultados de la misma. La comunicacion entre Matlab y la

fuente de corriente Agilent E5270B se realiza por medio de

una comunicacion GPIB. Es importante tener en cuenta, que la

fuente de corriente Agilent no permite manejar con presicion

el tiempo en que se fija una variable o se toma una muestra.

Debido a esto, la variacion de los pulsos de corriente de emisor

se realiza mediante llaves controladas por la FPGA, y no

directamente mediante la fuente de corriente.

Por otra parte, los comandos a la FPGA se implementaron

mediante una comunicacion serie. Para los mismos se utili-

zaron librerıas estandar provistas por Matlab. Para simplificar

el sistema, se realizo una recepcion asincronica de los datos.

Luego de enviado el comando de inicio a la FPGA, se esperaun tiempo determinado. Este tiempo se corresponde con el

tiempo total de medida de la FPGA, mas un agregado de

tiempo extra para tener en cuenta las variaciones debidas a que

el planificador de tareas del sistema operativo no es de tiempo

real. Los datos se reciben de manera asincronica, por bloques.

Cada bloque contiene la totalidad de las medidas realizadas en

esa corrida de datos. La configuracion de comunicacion serie

RS232 es 115200 baudios, 8 bits de datos, sin bit paridad, 2

bits de stop. Luego de este proceso, se varıa nuevamente la

corriente y se comienza una nueva medicion. Al finalizar la

medicion de todas las corrientes requeridas, se almacenan los

datos en un archivo para su posterior analisis.

II-C. Nodo de Medici´ on Esclavo

Como se menciono anteriormente, la FPGA es la encargada

de generar las senales digitales que controlan nuestro circuito

de pruebas. Estas senales controlan por un lado la tension de

reset (V reset), y en segundo lugar manejan la llave CMOS

(S 1) conectada en paralelo con la fuente de corriente Agilent

E5270B. Uno de los motivos principales para utilizar llaves

Figura 3. Algoritmo implementado en el nodo maestro



8




Figura 4. Algoritmo implementado en el nodo esclavo

CMOS es su consumo practicamente nulo en la entrada de

control, que debe ser manejada por la FPGA.

Un esquema del algoritmo utilizado se muestra en la Fig.

4. Dicho algoritmo maneja las llamadas ventanas de tiempo,

durante las cuales se mantiene encendida la llave S 1, permi-

tiendo el paso de la corriente I e al diodo emisor. Estas ventanas

deben variar entre dos valores conocidos, que seran el tiempo

mınimo y maximo de la medicion. Una vez finalizado cada

pulso de corriente, se realiza la medida de la tension de salida

y se envıa el resultado al nodo maestro.

El algoritmo fue implementado en Verilog, utilizando un

kit de desarrollo Spartan 3 para la FPGA. El sistema consiste

en una maquina de estados y dos contadores. La maquina

de estados es la encargada de esperar la recepcion de un

comando RS232, el cual reiniciara los contadores. La maquina

de estados a su vez, es la encargada de tomar muestras de la

salida y envıar los datos mediante el protocolo serie RS232.Los contadores son los encargados de generar un barrido

en las ventanas de tiempo. El primer contador almacena el

tamano de la ventana de tiempo actual. Por otra parte, el

segundo contador genera la ventana de tiempo propiamente

dicha, manteniendo abierta la llave S 1 mientras su cuenta

sea menor que el tamano indicado por el primer contador.

Al finalizar la cuenta del segundo contador, se emite la se nal

finBarrido a la maquina de estados, indicando que se debe

enviar un dato nuevo. A continuacion se incrementa el primer

contador, y se repite el proceso hasta llegar al maximo tamano

de ventana que se desea medir.

Para recibir y transmitir los datos mediante el protocolo

serie, se necesito desarrollar un modulo encargado de dichatarea. El esquema utilizado se desarrolla en la seccion siguien-

te.

II-D. Trasmisi´ on de Paquetes

El sistema encargado de trasmitir y recibir datos serie fue

desarrollado en Verilog. El mismo se divide en 3 partes, un

generador de baudios, un transmisor y un receptor. Como se

comento anteriormente, la velocidad de transmision utilizada

es 115200 baudios. Las FPGAs, sin embargo usualmente

utilizan velocidades mucho mayores a 115200 Hz. En nuestro

caso en particular, el reloj con que contamos es de 50 MHz.

Eso significa que utilizaremos un reloj de alta velocidad, que

dividiremos para obtener un perıodo tan cerca a 115200 veces

por segundo como nos sea posible. Al contar con un reloj

de 50 MHz, para generar 115200 Hz se debe dividir por un

numero que no es entero. La solucion es dividir por el numero

potencia de 2 mas cercano a la velocidad que queremos

generar. Esto tendra como consecuencia que en ocasiones se

utilice un perıodo menor y en ocasiones un perıodo mayor. En

promedio, la velocidad generada sera la que estamos buscando

y al contar con un reloj mucho mayor que la tasa de baudios, el

error estara dentro de la variacion aceptable por el protocolo.

Cuando se recibe la senal TxD start , que es emitida por

la maquina de estados de la seccion II-C, se toma un dato

de 8 bits y se lo serializa utilizando un multiplexor. En ese

momento la senal busy es emitida y se mantiene durante toda

la transmision. La senal TxD start es ignorada durante ese

tiempo.

El receptor, por otra parte, va ensamblando los datos de la

lınea de entrada ( RxD) a medida que arriban. Esta lınea sera laque reciba los datos entrantes del protocolo RS232. Con cada

byte recibido, se emite la senal data ready durante un perıodo

de reloj. Para determinar cuando arriba un nuevo dato o bit de

inicio, sobremuestreamos la senal a un multiplo de la tasa de

baudios. Una vez que detectamos el bit de inicio, muestreamos

la lınea a la tasa de baudios conocida, para adquirir los bits de

datos. En nuestro caso utilizamos un sobremuestreo de 8 veces.

Al ser asincronica, la senal RxD de entrada no tiene ninguna

relacion con nuestro reloj. Para solucionar esto, se utilizan dos

flip flops tipo D, logrando ası la sincronizacion con nuestro

reloj. Los datos son a su vez filtrados, para evitar que picos de

tension en la lınea RxD sean confundidos con bits de inicio.

Para esto, se utiliza un algoritmo de decision que muestrea

3 veces la senal. Finalmente, un registro de desplazamiento

recolecta los bits de datos a medida que son recibidos.

III. RESULTADOS EXPERIMENTALES

El sistema fue probado en laboratorio y funciono correc-

tamente. Para la validacion de los algoritmos de Verilog, se

simulo el codigo desarrollado inyectando valores de entrada

mediante una transmision RS232 emulada. Por otra parte, para

comprobar el correcto funcionamiento del sistema completo,

se inyectaron datos conocidos y se comprobo que llegarancorrectamente a la estacion central. Debido a que la matriz a

medir es amplia, es conveniente realizar pruebas intermedias

con pocos datos, para acortar los tiempos de prueba del

sistema de medida. El numero total de muestras a tomar es

n(I e) ∗ n(tduty), donde n es el numero de puntos. Entre las

pruebas llevadas a cabo, se realizaron comunicaciones entre

terminales serie y Matlab, y por ultimo entre Matlab y la

FPGA.

Finalmente se relevaron multiples datos de manera continua,

contrastandolos con los datos obtenidos a partir de resultados

teoricos. En la figura 5 se muestran los resultados experimen-

tales obtenidos durante una de las pruebas de laboratorio.



9




I e [ m A ]

Tduty [ms]

Corriente minima de transicion en funcion del t iempo de encendido

0

2

4

6

8

10

12

14

0 0.2 0.4 0.6 0.8 1 1.2

Figura 5. Resultados experimentales obtenidos

IV. FUTURAS MEJORAS

Como futura mejora se propone desarrollar un sistema de

control embebido, que permita recibir los datos recolectados

por la FPGA y almacenarlos en una memoria interna. Es

importante mencionar, que se deberıa ademas disenar una

fuente de corriente programable de alta precision. De esta

manera, se podrıa reemplazar la fuente Agilent E5270B. Entre

las ventajas de este metodo, se encuentra la mayor portabilidad

del sistema, pudiendo incluir los modulos de medida en el

mismo circuito que conforma el dispositivo a medir.

Es importante mencionar que en cuanto a la sincronizacion

de la medicion, en el presente trabajo no se encuentran ma-

yores dificultades dado que las mediciones son relativamentelentas, y en un solo nodo. Sin embargo, dicha sincronizaci on

es un punto crıtico para tener en cuenta en mediciones de mas

alta frecuencia y multiples nodos.

Para poder realizar y controlar las mediciones de varios

dispositivos en paralelo, se propone ademas transmitir los

datos mediante una red Ethernet[12]. De esta manera, la

recepcion se realiza en una computadora conectada a la red,

que sera la encargada de procesar la informacion de todos los

nodos y almacenarla para su posterior analisis[3]. Para acceder

a la comunicacion a traves de la red Ethernet, se realizo una

interfaz grafica desarrollada con las librerıas graficas Qt[13],

que vuelca los datos obtenidos a un archivo de texto. Sin

embargo, como en un principio se requerıa medir los datos

de un unico dispositivo, dicha interfaz luego no fue utilizada.

Finalmente como alternativa al uso de una FPGA en los

nodos de sensado, se podrıa utilizar un CPLD de bajo con-

sumo. Esto permite disminuir el consumo, para su posterior

inclusion en un nodo funcionando a baterıas. Sin embargo,

como en nuestro caso se propone utilizar redes Ethernet en

futuras versiones, el uso de nodos con FPGA permite mayor

flexibilidad en el diseno.

V. CONCLUSIONES

En el presente trabajo se trato la implementacion de un

sistema automatico de medicion y validacion, implementado

con dispositivos FPGA. Esta aplicacion resulta particularmente

practica para sistemas de medicion con bajas constantes de

tiempo, donde se debe iterar sobre distintos parametros y cada

medicion lleva grandes cantidades de tiempo. De esta manera,

dichos parametros son configurables en el servidor, quien se

encarga de supervisar las mediciones de manera automatica y

a su vez almacenando los datos resultantes.

Todo proyecto consta de varias etapas a mencionar, concep-

cion, diseno e implementacion, y testeo. Todas ellas han sido

desarrolladas a lo largo del trabajo, mostrando la metodolog ıa

con la que se ataco el problema que se pretendıa resolver.

En particular, el sistema fue probado satisfactoriamente en

laboratorio. Se proponen algunas mejoras al sistema, las cuales

seran implementadas una vez que se evalue la eficacia del

metodo y determinen las condiciones optimas de trabajo.

REFERENCIAS

[1] G. J. Pottie and W. J. Kaiser, “Wireless integrated network sensors,”Communications of the ACM , vol. 43, no. 5, pp. 51–58, May 2000.

[2] C. Chong and S. Kumar, “Sensor networks: evolution, opportunities, andchallenges,” Proceedings of the IEEE , vol. 91, no. 8, pp. 1247–1256,Aug. 2003.

[3] H. E. Williams and D. Lane, Web database applications with PHP & MySQL. O’Reilly & Associates, 2004.

[4] C. D. Araujo, M. D. Santos, and E. Barros, “A FPGA-based implemen-tation of an intravenous infusion controller system,” IEEE InternationalConference on Application-Specific Systems, Architectures and Proces-sors, pp. 402–411, Jul. 1997.

[5] W. Wolf, FPGA-based system design. Prentice Hall PTR Upper SaddleRiver, NJ, USA, 2004.

[6] Y. Bai and C. Hsu, “Design and Implementation of an EmbeddedRemote Electronic Measurement System,” Proceedings of the IEEE

Instrumentation and Measurement Technology Conference, pp. 1311–1316, Apr. 2007.

[7] F. Yu, X. Shen, X. Song, and J. Chen, “Implementation and evaluationof object-oriented flexible measurement system,” 9th International Con-

ference on Electronic Measurement & Instruments, pp. 310–314, Aug.2009.

[8] B. Sadler, “Fundamentals of energy-constrained sensor network sys-tems,” Aerospace and Electronic Systems Magazine, IEEE , vol. 20, no. 8,pp. 17–35, Aug. 2005.

[9] P. Bustamante, U. Bilbao, N. Guarretxena, and G. Solas, “Wirelesssensor for intravenous dripping detection,” 14th IEEE InternationalConference on Electronics, Circuits and Systems, pp. 399–402, Dec.2007.

[10] G. Ferri and N. C. Guerrini, Low Voltage, Low Power CMOS Current Conveyors, 1st ed. Springer, Nov. 2010.

[11] J. Campbell, C Programmer’s Guide to Serial Communications, 2nd ed.Sams, Sep. 1993.

[12] A. Lofgren, L. Lodesten, S. Sjoholm, and H. Hansson, “An analysis of FPGA-based UDP/IP stack parallelism for embedded Ethernet connec-tivity,” 23rd NORCHIP Conference, pp. 94–97, Nov. 2005.

[13] M. K. Dalheimer, Programming with Qt . O’Reilly, 2002.[14] D. Johns and K. Martin, Analog Integrated Circuit Design, 1st ed.

Wiley, Nov. 1996.[15] B. Razavi, Design of Analog CMOS Integrated Circuits, 1st ed.

McGraw-Hill Science/Engineering/Math, Aug. 2000.



10




Red de Sensores Hospitalaria para la Medicion de

Presion Endotraqueal

Pablo D. Pareja Obregon, Alfredo Falcon, Martın Di Federico

Pablo S. Mandolesi, Pedro M. JulianDpto de Ing. Electrica y de Computadoras


Bahıa Blanca, Argentina

[email protected]

Resumen—En el presente trabajo se desarrolla la concepcion,dise˜ no e implementacion de un sistema de medicion de presion en-dotraqueal para pacientes intubados. El mismo fue probado tantoen laboratorio, como en condiciones normales de funcionamiento.

Los bloques de sensado forman a su vez parte de una red desensores hospitalaria, cuyo objetivo es adquirir tantas variablessobre los pacientes como sean requeridas por el personal medico.

Este sistema fue desarrollado por el Grupo de Investigaci onen Sistemas Electronicos y Electromecatronicos (GISEE) de laUniversidad Nacional del Sur.1

En el trabajo se trata la concepcion, el dise ˜ no, y el desarrollodel sistema hasta llegar al producto terminado.

I. INTRODUCCION

La microelectronica y las redes de sensores se encuentran

entre las areas tecnologicas con mayor diversidad de cam-

pos de aplicacion[1]. En particular, la medicina es una de

las disciplinas afectadas con mayor impacto asociado[2][3].Muchas de las aplicaciones electronicas en medicina tienen

como objetivo mejorar la calidad de los procedimientos, el

control y la supervision del paciente antes, durante o despues

de una determinada intervencion[4][5][6].

Como resultado de un proyecto de colaboracion entre un

hospital local y la Universidad Nacional del Sur, se detecto la

necesidad de llevar a cabo algun tipo de control sobre la

presion endotraqueal en pacientes intubados. En la actualidad

no existe ningun sistema de sensado de dicha presion, que-

dando la tarea relevada por las enfermeras de turno. Esto trae

como consecuencia una apreciacion subjetiva y poco confiable

de las medidas realizadas. Por otra parte, por el hecho que

la supervision no es permanente, la deteccion de cualquierproblema se puede realizar con una demora tal que el dano

sea irreversible[7][8][9].

1El presente trabajo fue sustentado parcialmente por la Agencia Nacionalde Promocion Cientıfica y Tecnologica (ANPCyT), Proyecto PICT 14628, ypor la UNS, Proyecto PGI 24/ZK12.

P. Julian es miembro del Consejo Nacional de Investigaciones Cient ıficasy Tecnicas CONICET, Av. Rivadavia 1517, Buenos Aires, Argentina.

P. Mandolesi es miembro de CIC (Comision de Investigaciones Cientıficas),Pcia. Bs. As, La Plata, Argentina.

P. Pareja Obregon es becario del Consejo Nacional de InvestigacionesCientıficas y Tecnicas CONICET, Av. Rivadavia 1517, Buenos Aires, Ar-gentina.

A. Falcon es becario PRH de la Universidad Nacional del Sur, Av. Colon80, Bahıa Blanca, Argentina.

Una red de sensores consiste en un conjunto de nodos

con capacidad de sensado y calculo limitadas, que pueden

coordinarse a traves de comunicaciones inalambricas con el

proposito de llevar adelante alguna tarea. La utilizacion deredes de sensores nos permite disponer de diversos tipos de

informacion, al instante y desde cualquier sitio[10][11].

La motivacion del presente trabajo es realizar una red de

sensores hospitalarias, que incluya un sistema de medicion de

la presion del tubo endotraqueal en pacientes intubados. Este

sistema debe realizar mediciones periodicas de la presion, y

transmitirlas de manera inalambrica a un nodo de procesa-

miento central. El nodo central sera el encargado de almacenar

los datos resultantes de la medicion, y mostrar la informacion

a traves de una computadora al personal medico adecuado.

El presente trabajo se divide de la siguiente manera: en la

seccion II se describe la arquitectura del sistema de medicion

propuesto, para luego desarrollar con mayor profundidad cadauno de los bloques implementados. En la seccion III se

muestran los resultados experimentales obtenidos, durante la

etapa de evaluacion del sistema, ası como pruebas realizadas

sobre pacientes en una sala de terapia intensiva. En la seccion

IV se describen futuras mejoras en el sistema de medida y

finalmente en la seccion V se detallan las conclusiones del

trabajo.

II. DESARROLLO

El sistema propuesto ha sido disenado teniendo en cuenta

la facilidad de su uso, ası como el mınimo consumo y mayor

precision posibles en la medida. Otro factor de peso en el

diseno es la robustez del producto terminado, debido a quesera transportado continuamente de lugar y por personal no

especializado.

Si bien la utilizacion de redes de sensores tiene diversas

ventajas en muchas aplicaciones, se deben tener en cuenta

sus limitaciones[11]. En particular, cuando las redes utilizadas

tienen como medio de comunicacion nodos inalambricos, un

bajo consumo de energıa es un requerimiento fundamental en

el diseno. Esto es debido principalmente a que se debe evitar

el cambio periodico de las fuentes de alimentacion. Es por ello

que en este tipo de redes se debe minimizar la comunicacion,

que es la tarea que mayor consumo de energıa requiere. Para

abordar esta problematica, se busco realizar comunicaciones



11




periodicas de datos, en lugar de transmitir continuamente

variables del paciente. Esta metodologıa utilizada se desarrolla

en la seccion II-A.

La aplicacion de una red de sensores para medicion de

variables hospitalarios es un proceso que comprende diver-sas etapas a mencionar, sistema de medicion, transmision y

recepcion de los paquetes de informacion, analisis de los

datos, y finalmente visualizacion de los mismos. Cada una de

estas etapas sera explicada con mayor detalle en las secciones

siguientes.

II-A. Sistema

Un esquema del sistema completo se muestra en la Fig. 1.

El sistema se puede dividir en dos bloques, nodo sensor y

base central. El nodo sensor es el encargado de adquirir la

senal resultante de la medicion y transmitirla a la base por

radiofrecuencia. La base recibe la senal y luego de su proce-

samiento, la muestra en una interfaz realizada especıficamente

para dichos fines.

Figura 1. Diagrama en bloques del sistema completo

Como el nodo sensor es alimentado por una baterıa, es

necesario que el consumo de energıa sea lo mas eficiente po-

sible. Por otra parte, como la presion cambia muy lentamente

con el tiempo, no es necesario medirla de manera continua.

Es por esto, que para disminuir el consumo de energıa, se

decidio colocar un reloj de tiempo real encargado de prender

el sistema periodicamente para realizar la medicion. De estamanera, el reloj genera una senal que habilita el regulador

principal, encendiendo a su vez un microcontrolador CC1010.

Durante la medicion de la presion, el microcontrolador prende

otro regulador que alimenta el puente sensor de presion y su

amplificador asociado.

Este esquema de manejo de energıa, es utilizado para reducir

notablemente el consumo. Esto se logra realizando medicio-

nes durante 10 segundos, cada 15 minutos. La medicion se

realiza durante 10 segundos con el fin de obtener parametros

adicionales del paciente y detectar cualquier anomalıa. Entre

los parametros adicionales medidos se encuentran la presion

capilar y el pulso del paciente, entre otros.

Para poder prender y apagar periodicamente el sistema,

se necesita un circuito con una muy buena precision en

cuanto a su base de tiempos. El circuito integrado utilizado,

que implementa el reloj de tiempo real, es el PCF8593.

Entre las caracterısticas principales que influyeron sobre su

eleccion, podemos encontrar el bajo consumo que presenta.

Es importante mencionar, que dicho consumo es uno de los

factores de mayor peso sobre el consumo total, ya que es el

unico componente del sistema que nunca sera apagado.

Otra de las caracterısticas importantes del circuito integrado

PCF8593, es la posibilidad de contar desde centesimas de

segundo, hasta dıas e incluso meses. El mismo posee 16

registros de 8 bits, los cuales cumplen distintas funciones.

Entre ellas se encuentra configurar su comportamiento. Esto es

importante, ya que dichos registros deberan ser configurados

de manera previa al ser conectados al circuito, que sera apa-

gado y prendido de manera periodica.

Para suministrar energıa al circuito, se utilizaron dos tiposde reguladores. El regulador principal es un convertidor de

tension en base a capacitores conmutados MCP1253. El mo-

tivo de dicha eleccion, es fundamentalmente su bajo consumo

de energıa mientras se encuentra en modo de apagado. Dicho

consumo es de 0, 1µA. Sin embargo, el problema de este re-

gulador es que al presentar conmutaciones, se introduce ruido

al alimentar el puente del sensor MPX2010. Al introducir

ruido en la etapa de sensado, el mismo es amplificado por

las sucesivas etapas, obteniendo una medicion poco confiable.

Para disminuir este ruido, la solucion fue agregar un segundo

amplificador de mayor consumo y menor ruido, pero que

fuera prendido unicamente mientras se realiza la medicion. El

regulador utilizado para esta segunda tarea fue un reguladorlineal LDO2980. Si bien estos reguladores son menos eficien-

tes en cuanto al uso de la energıa, no introducen el ruido de

conmutacion asociado a los reguladores basados en circuitos

conmutados.

II-B. Sistema de Medici´ on

El sistema de medicion y acondicionamiento de senal debe

ser capaz de medir presiones entre 0 y 50mmHg. Estos

valores de presion se deben convertir de manera lineal, en

una tension entre 0 y 3, 3V , con una precision de 1mmHga fondo de escala. Este valor de tension sera la entrada del

conversor A/D del transmisor.La topologıa del sistema de medicion utilizado se muestra

en la Fig. 2. Se decidio utilizar el sensor MPX2010 debido

a que posee compensacion en temperatura y sus valores de

resistencia estan ajustados por laser, obteniendo una lectura

final muy precisa. Este sensor posee una sensibilidad ksensor

de 110µV/mmHg cuando se lo polariza con 3, 3V . Con este

valor y los rangos de presion de entrada y tension se salida se

puede calcular la ganancia del amplificador como se muestra

en la Ec. 1.

Av

=SpamentradaA/D

ksensor∗

SpamPresión

= 600 (1)



12




Figura 2. Sensado y acondicionamiento de la senal

La topologıa utilizada posee tres fuentes posibles de error.

La primer fuente de error analizada es el ruido, para el cual

se utilizo un ancho de banda maximo de 100Hz. Como el

sensor es resistivo se puede calcular el ruido del mismo como

se indica en la Ec. 2

V nsensor =

100

f =0

r2(f )df = 380nV (2)

A continuacion, podemos calcular el valor de presion de

ruido como se indica en la Ec. 3. El ruido del sensor se puede

despreciar, ya que el mismo deberıa dividirse por el modulo dela ganancia al cuadrado. En consecuencia basta con elegir un

amplificador de bajo ruido, por lo que se eligio el amplificador

de instrumentacion INA333 que posee una densidad espectral

de ruido de 50nV/√ Hz.

P nsensor =V nsensorksensor

= 3, 45e−3mmHg (3)

Otra fuente de error es la variacion de la ganancia. Dicha

variacion se puede controlar con la precision de la resistencia

RG. Se decidio que la variacion maxima de ganancia admisible

es de 1/3mmHg a fondo de escala. Para comenzar este

analisis calculamos el valor de tension correspondiente a1/3mmHg, como se muestra en la Ec. 4.

V 1/3mmHg = Av ksensor 1/3 (4)

Por otra parte tenemos que la variacion en la ganancia a

fondo de escala es

∆V inA/D = ∆Av ksensor Pmax (5)

Igualando 4 y 5 tenemos

∆Av =Av 1/3

Pmax

= 4 (6)

De la ecuacion de ganancia del amplificador, tenemos que

RG debe ser 166, 94Ω. Asumiendo que la ganancia es 600±2tenemos que la resistencia RG debe ser 166, 94 ± 0, 1 %Ω

Por ultimo, analizamos la variacion de la tension de ali-

mentacion. Dichas variaciones cambian tanto la sensibilidad

del sensor de presion, como la referencia del conversor A/D.

Es decir, se produce una variacion de la presion medida a

pesar de que su entrada se mantenga constante. Luego de tener

en cuenta los distintos parametros que afectan esta variacion,

se llego a la conclusion que la maxima variacion de tension

admisible es 16, 5mV para un error maximo en la medicion

de 1/3mmHg a fondo de escala. Este valor pone restriccionessobre el ripple de salida de los reguladores. Los mismos

deberan poseer un ripple maximo de 0, 5 % para una tension

nominal de salida de 3, 3V .Es importante mencionar que el amplificador seleccionado

posee bajo offset de entrada, y por lo tanto no influye en el

desempeno del sistema.

II-C. Transmisi´ on y Recepci´ on

Para implementar la transmision y recepcion de los datos, se

utilizan las facilidades del microcontrolador CC1010 utilizado.

El mismo posee una entrada analogica, en la cual se conecta

la salida del amplificador. Esta entrada es convertida en una

palabra digital mediante un conversor analogico-digital de 10bits de resolucion. Una vez convertida la senal en un valor

digital, es transmitida por radiofrecuencia a un nodo receptor

implementado utilizando el mismo microcontrolador. La banda

frecuencia utilizada es 433MHz.

Durante la etapa de transmision de datos, el consumo de

corriente es de 14mA. Es por esto que en el transmisor se

deben limitar los tiempos de uso del canal de radiofrecuencia

al mınimo. Para esto, el microcontrolador utilizado cuenta con

la posibilidad de apagar el modulo de transmision de datos

mientras no se necesite. Para nuestra aplicacion, se realiza

la conversion analogica-digital en primer lugar, se procesan

los datos y se prende el modulo de radiofrecuencia recien



13




cuando se vaya a enviar el resultado. Por otra parte, en el

receptor no existen problemas de consumo, debido a que se

puede extraer energıa de la red electrica, o incluso del puerto

con que este conectado el nodo a la computadora.

II-D. Presentaci ´ on de datos

Una vez que el receptor obtiene los datos de una medici on,

la senal adquirida es almacenada para su posterior uso. Sin em-

bargo, es conveniente mostrar los resultados obtenidos, a me-

dida que se realizan las mediciones. Para ello se desarrollo un

programa de computadora utilizando librerıas graficas Qt[12].

En la figura 3 se muestra una captura de pantalla del mismo.

Es importante en este tipo de interfaces, ademas de mostrar

la forma de los valores obtenidos y su variacion a lo largo del

tiempo, incluir condiciones de alarma. Para asegurar que las

alarmas sean atendidas, su condicion de apagado no puede ser

temporal, sino que debe requerir la intervencion del personal

de turno.

Figura 3. Programa desarrollado para el historial de presiones


Durante el proceso de validacion del sistema, se realizaron

tanto pruebas de calibrado en laboratorio, como pruebas de

funcionamiento bajo condiciones normales de uso. Para con-

trastar los datos obtenidos con los valores de presion reales,

se utilizo una columna de mercurio estandar conectada en

paralelo con nuestro sensor. En la figura 4 se muestra el

resultado de variar la presion de entrada entre 0 y 50 mmHg,

que seran las condiciones normales de funcionamiento. Como

se puede observar, los resultados obtenidos concuerdan con

los valores indicados por la columna de presion de referencia.

Por otra parte, es necesario caracterizar la variacion de

la medida entre distintos sensores. Para esto, se realizaronmediciones de ganancia y offset sobre una poblacion de 10

sensores de presion. Los resultados concuerdan con el 1%

de variacion en la ganancia de los sensores, y una variacion

debida al offset de entrada menor a 1/3mmHg. Estos valores

permiten utilizar nuestro sistema sin necesidad de calibrado,

caracterıstica fundamental a la hora de producir un dispositivo

en grandes cantidades.

Por otra parte, el consumo del sensor es relativamente

grande, debido a que presenta una impedancia de entrada

de 3kΩ. Sin embargo, el sensor sera conectado unicamente

durante un instante de tiempo, mientras se esta realizando la

medicion. Como luego el sensor sera apagado en el resto del

Figura 4. Caracterizacion del sistema

proceso, dicho consumo no sera significativo en el consumo

total del sistema.

Por ultimo se realizaron mediciones en la sala de terapia

intensiva en un hospital local. El motivo de dichas medidas

fue obtener senales reales de presion endotraqueal, y ası poder

optimizar el calculo de los filtros y demas parametros del

sistema. Para corroborar la validez de los valores obtenidos, se

conecto ademas una placa adquisidora en paralelo con la salida

de nuestro amplificador. Dicha placa adquisidora se conecta

por un puerto USB con una computadora portatil donde se

registran los datos. La tension de alimentacion de la placa

adquisidora se obtiene de la misma computadora. Esto esnecesario, ya que en todo equipamiento medico se requiere que

no haya un camino de alimentacion directo entre el paciente

y la red electrica. Los resultados obtenidos se muestran en la

Fig. 5. En la misma se puede observar la presion de salida del

sensor amplificado y su correspondiente valor en mmHg. Se

incluye ademas la informacion espectral de la senal.

Figura 5. Medidas del sistema realizadas en un hospital local



14




IV. FUTURAS MEJORAS

Como futura mejora se propone incluir en el sistema mayor

cantidad de sensores, que realicen el relevamiento de otras

variables medicas como podrıan ser el ritmo cardıaco y presion

sanguınea, entre otras[13].Para poder realizar y controlar las mediciones de varios

pacientes en paralelo, se propone ademas realizar una interfaz

que se conecte a internet. De esta manera, se pueden relevar

datos de distintas habitaciones distribuidas a lo largo del

hospital, o incluso entre distintos hospitales que compartan

el sistema. Esto es particularmente util ya que la recepcion

se puede realizar en cualquier computadora conectada a la

red[14]. Por otra parte, el medico a cargo podrıa acceder a los

datos desde cualquier computadora con acceso a dicha red.

V. CONCLUSIONES

En el presente trabajo se trato la implementacion de unared de sensores hospitalaria para la medicion de la presion

endotraqueal en pacientes intubados. Dicha red es implementa-

da con circuitos de aplicacion especıfica y microprocesadores

de proposito general. Esta aplicacion resulta particularmente

util, ya que se obtienen variables de pacientes internados

que en la actualidad no se miden con regularidad. Esto a su

vez podrıa disminuir enormemente los gastos en que incurren

los hospitales locales, debidos a tratamientos posteriores a la

internacion, y causados por lesiones del tubo endotraqueal.

Todo proyecto consta de varias etapas a mencionar, concep-

cion, diseno e implementacion, y testeo. Todas ellas han sido

desarrolladas a lo largo del trabajo, mostrando la metodologıa

con la que se ataco el problema que se pretendıa resolver. En

particular, el sistema fue probado satisfactoriamente en labo-

ratorio y en un hospital local. Se proponen algunas mejoras al

sistema, las cuales seran implementadas una vez que se evalue

la eficacia del sistema y determinen las condiciones optimas

de trabajo.

REFERENCIAS

[1] C. Chong and S. Kumar, “Sensor networks: evolution, opportunities, andchallenges,” Proceedings of the IEEE , vol. 91, no. 8, pp. 1247–1256,Aug. 2003.

[2] P. Bustamante, U. Bilbao, N. Guarretxena, and G. Solas, “Wirelesssensor for intravenous dripping detection,” 14th IEEE International

Conference on Electronics, Circuits and Systems, pp. 399–402, Dec.2007.

[3] T. Fulford-Jones, G. Wei, and M. Welsh, “A portable, low-power,wireless two-lead EKG system,” 26th Annual International Conferenceof the Engineering in Medicine and Biology Society of the IEEE , vol. 1,pp. 2141–2144, Sep. 2004.

[4] S. Young and K. Hsiao, “A pharmacokinetic model to study adminis-tration of intravenous anaesthetic agents,” Engineering in Medicine and

Biology Magazine, IEEE , vol. 13, no. 2, pp. 263–268, May 1994.

[5] C. D. Araujo, M. D. Santos, and E. Barros, “A FPGA-based imple-mentation of an intravenous infusion controller system,” Proceedingsof the IEEE International Conference on Application-Specific Systems,

Architectures and Processors, pp. 402–411, Jul. 1997.

[6] G. Dullerud, M. Csete, and J. Doyle, “Application of multivariablefeedback methods to intravenous anesthetic pharmacodynamics,” Pro-ceedings of the American Control Conference, vol. 1, pp. 791–795, Jun.1995.

[7] J. L. Stauffer, D. E. Olson, and T. L. Petty, “Complications andconsequences of endotracheal intubation and tracheotomy. a prospectivestudy of 150 critically ill adult patients,” The American journal of medicine, vol. 70, no. 1, pp. 65–76, Jan. 1981.

[8] J. R. Braz, L. H. Navarro, I. H. Takata, and P. N. Junior, “Endotrachealtube cuff pressure: need for precise measurement,” S ao Paulo medical

journal, vol. 117, no. 6, pp. 243–7, Nov. 1999.[9] C. Ganner, “The accurate measurement of endotracheal tube cuff pres-

sures,” British journal of nursing, vol. 10, no. 17, pp. 1127–34, Sep.2001.

[10] G. J. Pottie and W. J. Kaiser, “Wireless integrated network sensors,”Communications of the ACM , vol. 43, no. 5, pp. 51–58, May 2000.

[11] B. Sadler, “Fundamentals of energy-constrained sensor network sys-tems,” Aerospace and Electronic Systems Magazine, IEEE , vol. 20, no. 8,pp. 17–35, Aug. 2005.

[12] M. K. Dalheimer, Programming with Qt . O’Reilly, 2002.[13] R. Weber, “Transtracheal doppler: a new method of cardiac output

measurement,” Proceedings of the Annual International Conference of

the IEEE Engineering in Engineering in Medicine and Biology Society,vol. 5, pp. 1571–1572, Nov. 1989.

[14] H. E. Williams and D. Lane, Web database applications with PHP & MySQL. O’Reilly & Associates, 2004.

[15] D. Johns and K. Martin, Analog Integrated Circuit Design, 1st ed.

Wiley, Nov. 1996.[16] B. Razavi, Design of Analog CMOS Integrated Circuits, 1st ed.

McGraw-Hill, Aug. 2000.



15




Post-silicon Validation Procedure for a PWL ASIC

Microprocessor Architecture

O. Lifschitz, J. A. Rodr ıguez,

P. Juli´ an, O. AgamennoniInstituto de Investigaciones en Ingenierıa Electrica - IIIE

(UNS-CONICET)

Departamento de Ingenierıa Electrica y de Computadoras


Av. Alem 1253, (8000) Bahıa Blanca

Abstract— In this paper, we present the environment set forvalidation and testing a particular ASIC that implements apiecewise linear (PWL) architecture. Description for a packagedebug propose is included. Methodologies for power consumptionand envelope and maximum operation frequency estimation,

based on laboratory measurements, are described.

I. INTRODUCTION

Piecewise linear functions are a mathematical abstraction

widely used in circuit theory, computer graphics, and system

identification [1]. The evaluation of this type of functions

has been approached in different ways by diverse algorithms

such as: simplicial paths [2], comparator architecture [3], and

more recently neural networks [4]. A dedicated microprocessor

named PWLR6 was designed using a full EDA flow using

standard AMI 05 OSU standard cells library [5]. The µP

was designed in order to execute the calculation of a six-

input PWL function with a high degree of flexibility [6].A micro-programmed control unit enables the setup of dif-

ferent configurations using the PWLR6 ISA (Instruction Set

Architecture). Absolute and relative jumps, ALU (Arithmetic

Logic Unit), memory read and write, and register access

instructions, provide a rich environment to exploit the PWLR6

µP functionalities. In this paper, we present a set of debug

features and methodologies to proceed with a Post-silicon

validation and testing environment requirements to deal with

the complexity of the PWL µP.

Specific Design For Testability (DFT) and observability

features were introduced in the early ASIC design stage. These

DFT features run the whole verification flow together with thePWL silicon. In order to create an efficient testing environ-

ment, a synchronization between silicon results and simulation

data within a clock period resolution was achieved. Random

tests procedure were used to ensure a better test coverage in

order to guarantee the correct chip functionality. Morevoer,

a Well known pre-silicon tests scenarios were prepared to

consistently evaluate each of the PWLs blocks separately in

case of a bug or a missfunctionality occurs. Methodologies

for power measurements and maximun operational frequency

were developed and are shown in the paper, together with

experimental results.

II . BRIEF DESCRIPTION OF THE PWLR6 ARCHITECTURE

In this section, a brief description of a digital architecture

that implements an R6 PWL is presented. The idea is to

explain the complextity level of the ASIC to evalute. The

proposed architecture is based on a microprocessor [7] schemethat includes an ALU (Arithmetic Logic Unit), a register file

and a control unit [8].

Figure 1 illustrates the block diagram of the PWL chip.

Reg.1

Reg.2

Reg.3

Reg.4

Reg.5

Reg.6

Acc

Tag1

Tag2

Tag3

Tag4

Tag5

Tag6Reg.B

Reg.A

RSX

Rout

VRT

CNT

ALU

MUX MUX

MADR

SR38

Data Memory Bus

XYBus

MPC

MIR

SR-PM

Program Memory

Program Bus

Decode Logic

Bypass Logic

DFT

Control Unit Datapath

Fetch

Logic

ControlBits

Test Bits

Test MUX

Scan chain

DFTBus

Fig. 1. PWL blocks.

Figure 2 ilustrates PWL Chip.

Fig. 2. PWL chip.



16




III. TESTING ENVIRONMENT

A. Hardware environment

In this section, a brief description of the hardware (HW)

environment is presented. The HW consists of a master-slave

configuration where the PWL is in the role of slave and

the master is implemented on a Xilinx Test board with a

Virtex5 FPGA. The PWL uses a DDR2 Device where thecontrolller and the memory transfer hub (MTH) are realized

on the Virtex5. The MTH is responsable for adapted the

memory controller with the PWL chip memory protocol,

also allows the functionality of the systems at different

frequencies between the memory controller and the PWL

chip. The systems frequencies are: Master@100MHz, Memory

controller@160MHz and the PWL@[6,25Mhz - 50MHz]. The

master interconnects with a PC, through RS232, with the

Matlab interface. The PWL chip is placed on a two layer PCB.

This PCB includes some pin connectors for the logic analyzer

and for an easy power measurement.

Figure 3 ilustrates system hardware scheme.

Fig. 3. System view.

B. Software environment

There are several software (SW) levels in the system, each

of them running on a different part of the HW environment.

PWL Assembler.- This assembler activates the PWL for the

N-dimensional input data X from the master, calculates and

sends the results back to the master. Besides that, other assem-

bler codes were development based on the debug necessity.

These assembles allow to activate different parts inside thePWL chip or, in the case of power, to activate the ALU at

maximun load. The PWL has 256 by 20 bits wide instruction

ROM space. The master programs the PWL ROM while

the PWL is in programming mode. The assembler code is

hardcoded in the FPGA. The programming and execution

modes are set by the master.

Master SW.- The master SW has four state machines and

the PicoBlaze micro-controller. The PicoBlaze is an eigth bit

VHDL micro-processor and operates the RS232 interacting

between the state machines and the Matlab command instruc-

tion sets. The state machines control the PWL activation and

functionality. The state machines are:

ASM Load.- Programs the PWL ROM with the assem-

bler. This was done using two asynchrony signals: data

and clock. Both signals are generated by the master.

Chip clk gen.- Generated the PWL clock. This machine im-

plements the Stop clock and Do 1 clk features. (See DFT part)

Exe calc func.- Executes the PWL activation. This machine

puts the PWL to work by sending the start signal and seriesXi inputs (Xi ε R6) to the PWL and then wait for the PWL

to transfers the result back. This machine will send the final

results to the Human Interface.

DFT block.- Generates the debug features activation: Scan,

Bypass-Scan and Bypass. (See DFT part). The selection will

be set by the picoblaze based on the human interface decision.

This state machine performs the first data format before reach

the PC interface.

PC SW.- Its a Matlab interface dealing with the instruction

commands to the PicoBlaze and formatting the data for the

human interface. Also, creates the random cases and compares

the chip results with the PWL implemented in a Matlab private

toolbox.

IV. DESIGN FOR TESTABILITY

The main idea of the following structures is to help the

designer during the validation process. This DFT strategy

development started in the design stage together with the chip

development and its functionality was checked on simulations

at pre-silicon stage. Six DFT were created:

Stop Clk.- Some events, internally or externally, could enable

the PWL chip clk freezing the execution. These events could

be completely synchronized with the simulation tool in the

case the user needs a time correlation for simulator compari-

son. This synchronization allowed an easy verification registerby register for clock by clock operation. The syncronization

was achived by a counter that has the number of clocks,

this ensures the correlation between the simulation and the

chip. The option for an external Stop Clk signal assertion is

available but this is asynchronous and no time correlation can

be guaranteed.

Do 1 Clk.- Triggers a one PWL clock pulse allowing the

execution of the PWL routines step by step. This signal

activation can be external or internal. In the internal case

will be when other DFT are using it. In the external case

the activation is from the human interface command.

The following two DFT: Mux and Scan are related to theobservability. The idea was to carry internal signals out. These

signals are selected from the data and control flow path.

Mux.- This is an externally activated multiplexer that takes

different internal signals out to I/O pins. The mux out is in

parallel format. The relation between the number of bits and

the number of observable registers is a trade-off and depends

on design considerations. This DFT has ”on the fly” activation,

meaning that it is capable of taking out signals while the chip

is running. Of course, this is an expensive DFT due to the

amount of I/O pins but, on the other hand, is the simplest one

to build. Also, this mux allows the creation of a ”signature”



17




signals on the logic analizer creating an easy scenario to

compare with the simulator.

Scan.- This takes out a number of different bits coming from

different internal PWL block. The scan out is serial on a daisy

chain format. As opposite to the Mux, the scan has to be

activated when the PWL is stopped by the Stop Clk signal. In

terms of out pins, this feature is cheaper because used only to

out pins: data and clock.Bypass-Scan.- It is similar to the Scan but acts only on the

Control-Register. Due to its complexity and importance the

control register has a dedicated DFT. The Control-Register

has the ASM instructions that are 20 bits.

Bypass.- The Bypass DFT allows writing the control register

from the outside world putting aside the ROM interface. This

DFT should be perfectly synchronized with the PWL clock

to allow the correct work. The Bypass-scan and Bypass DFT

were introduced in the PWL silicon to replace the internal

ROM device in case of design or manufacturing failure. The

idea was to allow the ”onion peeling” procedure, means that

if ROM failure was detected, the chip debug would continue

using the Bypass DFT and validation process would not stop.

V. POS T-S ILICON

A. Block functional verification

The block functional verification requires to test every block

independently. Asserting the functionality of each block allows

to build a step by step process and isolate problems when they

appear. This verification was done using a friendly and flexible

PWL assembler compiler. Six main blocks were included in

this verification process:

Design for testability.- Much of these features were tested

in pre-silicon using a logic analyzer but due to fact that the

PWL was the first silicion including these kind of validationhardware, a validation slot for these blocks was included

(These blocks are not part of the PWL evaluation). Ideally,

these blocks should be a legacy well know HW design that is

inherited from design to design.

FPGA State Machines.- The state machines were checked

with a logic analyzer before PWL silicon arrival. Signal

protocol and timing were checked with the simulation results

comparison.

ROM Memory.- It was verified using a observavility DFT

that allowed to check the correct data was being written. This

was a big concern because no pre-silicon test could be done.

Xi Protocol.- Includes all the asynchronous protocol betweenmaster and slave. A DFT and a logic analyzer were used to

verify all the signals to ensure the correctness of the Xi data.

Sorting.- Due its strong dependency with the n-dimensional

value, different set of inputs were used and the correct order

after sorting routine were check with an obserbavility DFT.

Changing different data sets and comparing with simulation

results allowed to verified the correct sorting routine.

External Memory Access.- A bi-directional I/O was involved

here so a particular PWL assembler was used to read and write

to different memory addresses. The data was verified using a

DFT and a logic analyzer. Moreover, the whole system: PWL,

MTH and memory controller had a special attention during

validation due to the different frequencies operations.

ALU.- Besides the PWL calculations, a set of different mathe-

matical operations were test and the results checked using the

address I/O pins.

B. Functional verification

Two set of cases where used in this stage: from simulationsand random cases. The simulation cases used for DFT and

correlations test with the simulator. Random cases were com-

pared with matlab toolbox using a ”Linear-Function” space

instead of no-linear to get a direct error calculation. The main

difference between these cases is the run speed. Means, the

simulations are some reduced set of Xi values running on the

simulations and all the DFT (Scan and Mux) values are gen-

erated and used for comparison between Modelsim simulator

and the chip. In this case, the memory size used was very

small and the values were hardcode on the simulated VHDL

code. On the other hand, the random cases are generated by

matlab and the whole 16MB memory map was used. Matlab

created a random Xi input, send it to the PWL and the resultwas compared with the matlab calculation. The correct results

of all these cases were the base for the maximum frequency

test on next section.

Figure 4 shows some of the random test results. The error

between PWL-chip and Matlab should be 0 as expected.

0 500 1000 1500 20000

20

40

60

80

Nº of running

F ( x 1 , . . .

x 6 )

PWL−chip Vs Matlab

Matlab

Chip PWL

0 500 1000 1500 2000−1

−0.5

0

0.5

1Percentage Relative Error − PWL−chip Vs Matlab

Nº of running

Fig. 4. Matlab Vs Chip comparison .

VI. FREQUENCY MEASUREMENTS

The idea was to verify the maximum PWL operational

attainable frequency for this design and technology. The I/O

and core power planes in the PWL are unified. This unification

limited the highest voltage applied to the PWL due the I/O

clamping connection with the FPGA.

In order to overcome to this voltage limitation the procedure

was to define a test that allowed extrapolation of the maximum

PWL frequency, without changing the PWL core-I/O voltage

beyond the FPGA I/O limits. This test exercises the critical



18




path obtained from simulations. This critical was the part

related with the ALU execution and was verified in the

laboratory by exercising different parts inside the PWL circuit

till we have a functional failure. The failure or success of this

test was our fail/pass criteria in the Frequency Vs PWL Vcc

core graph. The test consisted on reducing Vcc, maintaining a

fix PWL frequency, until a failure result occurred. A fail result

was the one that gave a different number comparing with thesimulation results but the chip was still functional. The idea of

functionality was that only the numerical result was the error

and not the PWL protocol behaviour. The PWL frequency

change was done using the DCM block in the FPGA.

Figure 5 exemplifies the DCM connection.

Fig. 5. Frequency shmoo .

Figure 6 ilustrate the maximum PWL operational frequency

for each Vcc value with a different coverage level.

3 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.835

40

45

50

55

60

Vcc [ V ]

F r e q [ M H z ]

Weak coverage

Strong coverage

Fig. 6. Freq. Vs Vcc.

The difference in coverage is related with the simulation

and random cases mentioned before. Although boths kind of

test point to the ALU execution, the random test were more

than twenty thousand cases and simulations cases are nine.

Thats why the difference in the frequency results observed

on picture Frequency Vs Vcc results.

V II. POWER MEASUREMENTS

The power consumption has three main components: static

consumption, clk tree and the dynamic consumption. The

procedure to measured each components was done following

the next table:

Power Item CLK Reset Running

Static off on off

Clock Tree on on off

Dynamic on off on

The running condition means that the PWL is executing the

assembler instructions.

Power consumption was measured using a series resistor

on the PWL Vcc connection. The value of this resistor is

calculated to keep the voltage on the resistor at working range

between 600mV and 1500mV. The idea was to maintain the

same resistor value for all the measurments. The resistor was

100Ω. The measurements were done with two devices: digital

scope (Agilent DSO3062A) and a multimeter Hewlett Packard

(HP34401A). The idea of using both elements was to correlate

the results.

A. Consumption time picture

To get an idea of the PWL power consumption, a scope

picture was captured showing the consumption while a test is

on execution.

Figure 7 shows the power consumption Vs time during a test

execution.

−20 0 20 40 60 80−4

−2

0

2

4

6

8

10

Time [ us ]

P o w e r [ m W ]

Power PWL (Freq: 6,25MHz)

Stand by

Getting Xi

Sorting

Calculation & mem access

Sending results

Wait for a new Xi

Req

Fig. 7. Power Activity.

In the Figure 7 the Req signal belongs to the asynchrony

protocol and is shown here just as an activity reference. (This

signal does not have the correct voltage scale.)

The consumption time picture was a base for the creation

of a ”Power Virus”. The worst power consumption occurred

during ”calculation and memory access”, based on these facts

a PWL assembler which fully activates the ALU and the I/O

was done. This assembler is called Power Virus because is

the maximum power that the PWL can dissipate. The ALU,

which is the highest consuming block, was running at the



19




maximum execution velocity on an infinite assembler loop. In

this power virus an I/O out instruction was added, this gives

the power virus with pad activity. The power virus assembler

was used to calculate the consumption for different Vcc cores

and operation frequencies. Also, gives the worst case power

envelope for disipations considerations.

B. Power measurements

The static power was around 160nW. As mentioned before,

this static power was when the PWL clk tree was off and the

PWL reset was asserted. Using the power virus assembler, the

procedure was to measure the power consumption for different

operation frequencies. As expected, the maximum power quote

was for the power virus with full I/O activity. Table I shows the

power measurements results for the: clock tree, power virus

with and without I/O activity.

TABLE I

POWER @3,3V

PWL Power [ mW ]Freq. [ MHz ] Clock Tree P. Virus P. Virus + I/O

25 22,70 34,91 49,68

12,5 11,42 17,60 24,87

6,25 5,69 8,75 12,40

VIII. CONCLUSIONS

In this paper we have presented a post-silicon validation and

testing methodology. Three important conclusions were: the

proactive work done with the environment preparations, like:

DFT features, different assembler codes, assembler compiler,

etc.

Defined methodologies setups for power consumption, blocks

validation and the attainable maximum frequency for this kind

of silicon.

Studied the importance of defining a correct coverage during

silicon validation specially when the pre-silicon could not

cover all the cases due to the complexity of the testbench

scenarios.

IX . ACKNOWLEDGMENT

We would like to thanks to Ing. Ariel Arelovich for the PWL

assembler compiler that fruitful helped us during validation.

REFERENCES

[1] L. Castro, J. Figueroa, O. Agamennoni, “BIBO stability for NOEmodel structure using HL CPWL functions”, in Proc. of Modelling,

Identification, and Control, 2005.

[2] M. Chien and E.Kuh, “Solving nonlinear resistive networks usingpiecewise-linear analysis and simplicial subdivision”, IEEE Transactionson Circuits and Systems, Vol.24, pp. 305-317, 1977.

[3] P. Mandolesi, P. Julian, and A. Andreou, “A scalable and programmablesimplicial CNN digital pixel processor architecture”, IEEE Transactionson Circuits and Systems-I: Regular papers, Vol.51, pp. 988-996, 2004.

[4] Xusheng Sun, Shuning Wang, “A Special Kind of Neural Networks:Continuous Piecewise Linear Functions”, ISNN (1) 2005: 375-379.

[5] J. E. Stine, J. Grad, I. Castellanos, J. Blank, V. Dave, M. Prakash, N. Iliev,and N. Jachimiec, “A Framework for High-Level Synthesis of System-on-Chip Designs”,, International Conference on Microelectronic SystemsEducation, IEEE Computer Society, pp. 11-12, 2005.

[6] V. M. Jimenez, J. A. Rodriguez, P. M. Julian, O. Agamennoni, O. Lifs-chitz, “VLSI Microprocessor Architecture for a Simplicial PWL FunctionEvaluation Core”, in Proc. Arg. School of Micro Nanoelectronics, pp. 1-6,2008.

[7] Intel Co., “Microprocessor and Peripheral Handbook, Volume 1-Microprocessors”, Intel, 1987.

[8] V. M. Jimenez, J. A. Rodriguez, P. M. Julian, O. Agamennoni, M. DiFederico, “Digital architecture for R6 PWL function computation”, in

Proc. Arg. School of Micro Nanoelectronics, pp. 1-6, 2007.



20






21




DSPs



22






23




Desarrollo e Implementación de un Controlador Activo de Ruido de Banda Angosta Adaptativo

F. A. González, R. Rossi, G. R. Molina y G. ParlantiLaboratorio de Procesamiento Digital de Señales

Universidad Nacional de CórdobaCórdoba, Argentina

[email protected]

[email protected]

Resumen —Se presenta en este trabajo el diseño y construcción de

un sistema Controlador Activo de Ruido (CAR) adaptativo,

basado en un Procesador Digital de Señales de uso comercial. El

sistema apunta a cancelar el ruido de banda angosta de baja

frecuencia remanente en la cavidad de un auricular. Este ruido

de baja frecuencia es especialmente difícil de cancelar por medios

pasivos de cancelación acústica, pero utilizando técnicas activascomo la presentada, se logran atenuaciones apropiadas y

eficientes para el uso comercial.

Palabras claves: CAR, Controlador Adaptativo, FxLMS

I. I NTRODUCCION

En ambientes industriales, receptáculos cercanos a motores(como en la cabina de un avión o automóvil) o en entornosruidosos en general, los auriculares utilizados para lacancelación acústica pasiva de ruido suelen ser efectivossolamente a frecuencias superiores a los 500 Hz. Comocomplemento de los auriculares pasivos, los sistemas de

Control Activo de Ruido (CAR), apuntan a cancelar componentes de ruido de baja frecuencia. Cuando estacancelación se produce en un espacio reducido, como dentrode un auricular, el sistema CAR se lo denomina “unimodal” ysu objetivo es producir una señal de igual amplitud y fasecontraria al ruido remanente dentro de la cavidad del auricular,comúnmente llamado “antiruido”[1].

El ruido dentro de la cavidad del auricular puede variar enel tiempo, ya sea porque la fuente de ruido ha variado, o porquela transferencia acústica del auricular ha cambiado, por ejemplo

por diferencias anatómicas de quien lo usa. El sistema CAR debe ser capaz de adaptarse a estas variaciones, modificando enconsecuencia la señal antiruido producida. A tal fin utiliza la

diferencia entre la señal producida y la deseada (el ruido acancelar) para modificar su propia función de transferenciamediante algún algoritmo apropiado, “aprendiendo” entoncesde sus errores [2]. Los filtros adaptativos de un sistema CAR suelen realizarse con filtros de respuesta al impulso finita (FIR,Finite Impulse Response) por ser más sencillos de realizar y

por ser incondicionalmente estables, en contrapartida con losfiltros de respuesta al impulso infinita (IIR, Infinite ImpulseResponse). La modificación de la función de transferenciarequerida se realiza entonces modificando en forma automáticalos coeficientes del filtro. Los filtros FIR requieren de mayor cantidad de coeficientes que los IIR, pero con el advenimiento

de Procesadores Digitales de Señales (DSP, Digital SignalProcessors), de gran capacidad de procesamiento, tanto laadaptación de los coeficientes como el proceso de la señal deentrada del CAR pueden realizarse en tiempo real.

En este trabajo se presentan detalles del diseño y de la

implementación de un sistema CAR en un dispositivo DSPcomercial, aplicado a la cancelación de ruido dentro de lacavidad de un auricular comercial.

II. CARACTERÍSTICAS DE DISEÑO

A. Arquitectura general de un sistema adaptativo

En general, un sistema adaptativo modifica su propiatransferencia partiendo de cuán diferente sea su salida respectode la salida ideal o deseada. Este principio puede aplicarse adiferentes fines, en un variado campo de las ciencias. Elesquema de la Fig. 1, muestra el caso de un sistema adaptativodiseñado para identificar un sistema desconocido. La señal de

entrada, también llamada referencia, se representa por la señal x(n), la transferencia del sistema desconocido por P(z) y lasalida del mismo, d(n), representa la señal que se deseacancelar. La señal de referencia se introduce al sistemaadaptativo, compuesto por un controlador con transferencia

H(z) que produce la salida y(n) y el algoritmo de adaptación delcontrolador.

De lo expuesto, se define a la señal de error como:

e(n) = d(n) – y(n) = x(n)*p(n) – x(n)* h(n). (1)

Figura 1. Sistema Adaptativo

e(n)

P z

H(z)

Alg.

x(n)d(n)

y(n)

+ _

SistemaAdaptativo



24




La señal e(n) es quien gobierna el proceso de aprendizaje.En (1), * denota convolución, y p(n) y h(n) son las respuestasal impulso de P(z) y H(z) respectivamente. Se dice que elsistema ha convergido cuando e(n) ≈ 0 y H(z) ≈ P(z), deteniéndose la adaptación. Esto sucede siempre que x(n) tengasuficiente contenido espectral para excitar todos loscoeficientes del filtro FIR en el proceso de aprendizaje. Elalgoritmo de adaptación más utilizado por su sencillez y

robustez es el llamado Least Mean Squares, LMS, [3] que produce la adaptación iterativa de los coeficientes del FIR H(z) según:

hk (n+1 ) = hk (n) + µe(n)x(n) (2)

donde k = 1, 2 , … L, siendo L la cantidad de coeficientes delfiltro FIR, y µ el paso o velocidad de adaptación entre laiteración n y la n+1. Un valor de µ pequeño hará el aprendizajelento, pero logrará un error e(n) remanente pequeño. Un valor de µ alto hará el aprendizaje rápido, a expensas de un e(n) remanente más alto además de poner en riesgo la convergenciahacia el valor ideal, normalmente llamada solución de Wiener.

Una variante del algoritmo LMS, ampliamente utilizada, esel llamado Normalized Least Mean Squares, NLMS, queadapta el paso µ a la potencia de la señal de entrada según:

µ(n)= α /LP x(n) (3)

donde α es una constante y P x(n) es la potencia de la señal dereferencia x(n) en el instante n. De esta forma el paso µ(n) utilizado con señales de baja potencia será mayor, acelerandoel proceso de convergencia, mientras que con señales de mayor

potencia µ(n) será menor, asegurando la estabilidad delsistema.

B. Arquitectura de un CAR en un auricular

En el caso del sistema CAR aplicado a la cavidad de unauricular, P(z) representa la transferencia acústica entre elexterior y el interior del auricular, y la señal de referencia x(n) el ruido fuera del auricular. La señal deseada d(n) representa elruido a cancelar, remanente en el interior de la cavidad. En estecaso, la señal de error se encuentra en el entorno acústico y noen el eléctrico. Esta situación se muestra en la Fig. 2.

En este caso, el controlador H(z) no podrá gobernar la señalantiruido directamente, sino a través de elementos físicos comoun conversor Digital/Analógico y un parlante. Del mismomodo, el error acústico y la señal de referencia deberán ser

captados por micrófonos y ser convertidas a digital por unconversor Analógico/Digital, para transformarse en la señaldiscreta e(n) y x(n) respectivamente. Además de estos bloques,normalmente son necesarios amplificadores y atenuadores.Todos estos bloques adicionales, se suelen representar por unasola función de transferencia llamada “camino secundario”S(z).

Para compensar el efecto de S(z) y aplicar los mismoscriterios de aprendizaje de (2), la señal de referencia x(n) debeafectarse o filtrarse por la misma función de transferencia S(z).

Figura 2. CAR en un auricular

El algoritmo de adaptación en este caso se llama LMS dereferencia filtrada o FxLMS (por sus siglas en ingles deFiltered x Least Mean Squares) [4].

C. Estimación del camino secundario

La Fig. 2 supone que la transferencia S(z) se conoce, ya quedebe usársela para filtrar la señal de referencia x(n). En generalesto no será así. Además la función de transferencia puedevariar en el tiempo, producto del envejecimiento de losmateriales utilizados, etc. Es por eso que la presencia del

camino secundario desconocido o variante en el tiempo, obligaa introducir un segundo sistema adaptativo para estimar sufunción de transferencia. El esquema se muestra en la Fig. 3.Una vez convergido este segundo sistema adaptativo, sufunción de transferencia Sp(z), será una buena aproximación aS(z), y se utilizará una copia de la misma, cSp(z), para filtrar laseñal de referencia x(n), produciendo la señal de referenciafiltrada x’(n).

En la Fig. 3, la señal v(n) es una señal de aprendizajeestadísticamente independiente de x(n) para que los procesosde aprendizaje no interfieran entre sí. La señal f(n) representa elerror conjunto, calculado como:

f(n) = e(n) – v(n)*s p(n) = x(n)*p(n) – x(n)*h(n)*s(n)

+ v(n)*s(n) – v(n)*s p(n). (4)

La señal f(n) es utilizada en ambos procesos de aprendizaje.Reemplaza a e(n) en (2) para el proceso adaptativo del caminosecundario, y se usa para adaptar los coeficientes de H(z) como

hk (n+1 ) = hk (n) + µ f(n)x’(n) (5)

Cuando ambos sistemas han convergido, f(n) ≈ 0, Sp(z) ≈ S(z), y H(z) ≈ [P(z)/S(z)], deteniéndose ambas adaptaciones. Siambos procesos adaptativos se realizan simultáneamente, sedice que el camino secundario se modela “on-line”.

La señal v(n), requerida en una estimación on-line, siempreestá presente en el error e(n), siendo esta última la señal que elusuario escucha. Por ello, es conveniente disminuir o anular v(n) una vez que el proceso adaptativo de estimación delcamino secundario ha convergido [5]. En la práctica, tambiénes común realizar una estimación “off-line” del caminosecundario. En este caso se produce primero el aprendizaje deSp(z) y luego el de H(z). Si S(z) cambia por algún motivo, elsistema adaptativo Sp(z) vuelve a activarse para emular esoscambios.

P z

H(z)

LMS

ruidodeseada

y(n)

error

+ _

Entorno Acústico

S z

antiruido

S(z)

x(n)e(n)



25




Figura 3. Sistema CAR con estimación del camino secundario

Es importante notar que para que el filtro H(z) sea causal eltiempo de proceso del sistema adaptativo más el retraso delcamino secundario S(z) debe ser menor al retraso de latransferencia P(z).

D. Alcance del CAR

Al diseñar un sistema CAR, lo primero que debe definirsees el tipo de ruido que se desea cancelar, dependiendo éste delambiente donde se deba desempeñar. En ambientes con

motores, turbinas, aire acondicionado, sirenas, etc, el ruido acancelar será principalmente de banda angosta, es decir suespectro estará concentrado alrededor de frecuencias bastantedefinidas y su aspecto temporal será repetitivo. En cambio enambientes donde el ruido represente música, conversacionesentre personas, ruido blanco gausseano, etc, el ruido a cancelar será de banda ancha, encontrándose un contenido espectral másdistribuido. Este trabajo se concentra en el primer caso, lacancelación de ruido de banda angosta.

La Fig. 3 muestra una arquitectura que puede cancelar tantoruido de banda ancha como de banda angosta, ya que sedispone de la señal de referencia x(n), y cualquiera sea suespectro el sistema podrá aprender partiendo de ella. La señal

de referencia debe tomarse desde el exterior del auricular,mediante un micrófono adicional al del error, denominadomicrófono de referencia. Si se desea que el CAR sólo actúesobre ruidos de banda angosta, como en nuestro caso, elesquema de la Fig. 3 puede simplificarse, prescindiendo delmicrófono de referencia. En ese caso la señal x(n) podráestimarse dentro del mismo proceso, según se muestra en laFig. 4.

La señal de referencia x(n) se calcula como:

x(n) = y(n)*cs p(n) + f(n) = y(n)*cs p(n) + d(n) – y(n)*s(n)

+ v(n)*s(n) – v(n)*s p(n). (6)

Una vez convergidos ambos sistemas cSp(z)=Sp(z)≈S(z) yentonces x(n)≈d(n), por lo que el esquema de la Fig. 4, puedeasimilarse a un proceso de control inverso adaptativo, con

H(z)≈1/S(z).

Es importante notar que el esquema de la Fig. 4 cancelarátoda señal periódica componente de d(n), mientras que elesquema de la Fig. 3 solo cancelará las componentes de d(n) relacionadas con x(n), no afectando, por ejemplo al ruido

propio de P(z), o al ruido no captado por el micrófono dereferencia.

Figura 4. CAR para ruidos de banda angosta

En contrapartida, el esquema de la Fig. 4 solamentefuncionará para cancelar ruidos de banda angosta (periódicos)

pues si no el retraso del conjunto H(z)S(z) debería ser cero.

III. IMPLEMENTACIÓN DEL SISTEMA

La implementación del CAR aplicado a un auricular, serealizó sobre el DSP StarCore MSC7116 de alto rendimiento

de la empresa Freescale Semiconductor Inc. El StarCoreMSC7116 es un DSP de punto fijo de 16 bits de ancho de palabra, de bajo costo, con un núcleo de cuatro ALUs, capaz derealizar 1000 MMACS a 266MHz. La capacidad de

procesamiento del DSP es suficiente para realizar el cálculocomputacional complejo que requiere la realización de losfiltros adaptativos para ambos canales dentro del tiempo de un

período de muestreo (procesamiento en tiempo real por muestras simples).

El software del controlador o programa de aplicación estámontado sobre un sistema operativo de tiempo real o RTOS(por sus siglas en inglés Real Time Operating System), quecorre sobre el DSP. Dicho sistema operativo es el SmartDSP de

la empresa Freescale Semiconductor Inc, diseñadoespecialmente para los DSP de la familia StarCore. La interfacede programación de aplicación o API (por sus siglas en inglésApplication Program Interface) del SmartDSP [6], estaformada por funciones desarrolladas en lenguaje C, que

permiten una fácil configuración y utilización de los periféricosdel DSP. Para cada tipo de estos periféricos, existe un driver del sistema operativo, que permite la comunicación del

programa de aplicación con los mismos. En el software delcontrolador se empleó el driver del periférico TDM (del inglésTime Division Multiplexing) para la entrada y salida de datosde ambos canales de audio (derecho e izquierdo) en el DSP. Lavelocidad de entrada y salida de datos es la frecuencia de

muestreo del sistema, fijada en 8KHz. Este valor de frecuenciade muestreo es suficiente para la aplicación, ya que el rango defrecuencias de interés de un sistema CAR corresponde afrecuencias por debajo de los 500Hz.

El programa de aplicación fue desarrollado íntegramente enlenguaje C, empleando funciones denominadas “intrínsecas” ala hora de realizar y optimizar el procesamiento de los filtrosadaptativos. Estas funciones intrínsecas son funciones en C queno pertenecen a la API del RTOS, sino que son funciones

propias del compilador [7], especialmente diseñadas pararealizar operaciones fraccionarias y optimizar el programa de

e(n)

-

P(z)

H(z)

LMS

x(n)d(n)

y(n)

+ _

S(z)

q(n)

cSp(z)

+

v(n)

+

LMS

S z

f(n)

_ _

x’(n)

x(n)

d(n)e(n)

H(z) y(n)

+ _

S(z)

q(n)

cSp(z)

+

v(n)

+

LMS

Sp(z)

f(n)cSp(z)

+

_ _

LMS



26




aplicación, aprovechando las características de procesamiento paralelo del DSP. Las funciones intrínsecas se intercalandirectamente en el código en lenguaje C, permitiendo al

programador aproximarse a la eficiencia propia del lenguajeensamblador del DSP.

La precisión de la mayoría de los datos se fijó en unalongitud de palabra de 16 bits en el formato de punto fijo. Paralos coeficientes de H(z) se experimentó con 16 y 32 bits. Paramejorar la actualización de los coeficientes de los filtros en el

proceso adaptativo y evitar que la adaptación se detuviera prematuramente por falta de precisión, se utilizaron 32 bits para el resultado del producto entre el paso de adaptación µ y laseñal de error f(n), implicando esto la realización demultiplicaciones de 32 x 16 bits en la actualización de loscoeficientes de H(z) en el segundo sumando de (5). Esto llevó auna mejora importante en el desempeño de todo el sistema.

El modelo experimental implementado para evaluar eldesempeño del CAR aplicado a un auricular, se basó en aplicar

para cada canal de audio en forma independiente, un esquemacomo el presentado en la Fig. 4, utilizando el algoritmo FxLMSen su versión normalizada. El diagrama en bloques para cadacanal del sistema CAR, se muestra en la Fig. 5. A continuaciónse explican cada una de las partes de este modelo.

A. Placa de evaluación del Procesador Digital de Señales

El módulo MSC711xEVMT [8], es una placa de desarrollode software para aplicaciones que utilizan los DSP StarCoreMSC711x. El uso de la misma permitió y facilitó la descarga yevaluación del software del controlador sobre el DSP, vía

puerto paralelo con una PC portátil. Además por medio delCODEC integrado en la misma, ingresan y salen al DSP lasseñales analógicas de los transductores electroacústicos.

El CODEC es el AK4554 de 16 bits estéreo de la empresa

AKM Semiconductor Inc., el cual realiza las conversiones A/Dy D/A para ambos canales, además de efectuar los filtrados“antialiasing” y de reconstrucción (filtros pasa bajos)correspondientes. La entrada y salida de datos dentro del DSP

para ambos canales del controlador, es realizada a través de su periférico TDM, el cual se comunica con el CODEC.

B. Sistema acústico

El auricular utilizado es el auricular circumaural estéreoSHP1900 de Philips, de una relación calidad-precioconveniente. Dada la característica de ser un auricular circumaural, las orejas de quien escucha son cubiertastotalmente por las almohadillas del auricular, creándose

pequeñas cavidades acústicas en torno a cada uno de los oídos.Como sensores de error se usaron los micrófonosomnidireccionales ECM-30, los cuales son micrófonos del tipo

Electret . Este tipo de micrófonos tienen características que sonmás que suficientes para aplicaciones de CAR (en lo querespecta a sus anchos de banda, sensibilidades y relacionesseñal-ruido), además de ser de tamaño físico muy reducido, por lo que son ideales para nuestra aplicación.

La ubicación de los micrófonos de error dentro delauricular determina la zona de quietud, y fue sugerida por losautores de [9] y [10] como la ubicación ideal.

Figura 5. Diagrama en bloques de un canal del modelo experimental.

Dicha ubicación corresponde a la más cercana al tímpanodel oído, además de demostrarse experimentalmente que estaconfiguración presenta la respuesta en frecuencia de lamagnitud del camino secundario, más plana que otrasconfiguraciones [9, 10].

C.

Placa amplificadoraSe desarrolló un preamplificador para cada micrófono y el

amplificador de potencia del auricular. Cada preamplificador esdel tipo transistorizado y tiene como función el acondicionar elnivel bajo de la señal de cada micrófono hasta un nivel de señaladecuado para cada conversor A/D. El amplificador de

potencia basado en el integrado LM386, entrega la potencianecesaria para excitar los parlantes del auricular.

IV. R ESULTADOS

Para poder analizar y graficar los resultados obtenidos delas mediciones del sistema CAR se empleo el programacomputacional MATLAB. Los datos de las mediciones se

exportaron del DSP al programa MATLAB.

A. Identificación del camino secundario S(z)

Como hemos visto anteriormente, y se mostró en la Fig. 4,la estimación de S(z), que llamamos Sp(z), es necesaria paraestimar la señal de referencia x(n). Además, se la utiliza parala actualización de los coeficientes del controlador H(z) con elalgoritmo FxLMS, según (5). En la presente implementación serealizó una identificación del camino secundario S(z) demanera off-line.

Para realizar la identificación off-line de S(z), Sp(z) seimplementó con un filtro adaptativo FIR de longitud Ls = 128coeficientes de tal manera de cubrir la mayor parte de surespuesta al impulso. Los coeficientes de Sp(z) fueronadaptados con el algoritmo LMS, según (2). Como señal deaprendizaje v(n) se empleó ruido blanco de media cero yvarianza 0,03 generado internamente por el DSP. Se empleó un

paso de adaptación µ = 0,01 en (2).

La Fig.6 muestra la respuesta al impulso obtenida, en dondese observa un retardo de aproximadamente 40 coeficientes, o5ms para una frecuencia de muestreo de 8kHz. La hoja dedatos del CODEC indica que él mismo introduce un retardofijo de 36 muestras, que representa casi todo el retardo presenteen Sp(z).



27




Figura 6. Respuesta al impulso de Sp(z).

De ser necesario, el retardo temporal mostrado en la Fig. 6, puede disminuirse aumentando la frecuencia de muestreo. LaFig. 7 muestra la magnitud de la respuesta en frecuencia de laestimación de S(z).

Para observar la evolución temporal del procesoaprendizaje de Sp(z), se utilizó una ventana temporal de 16.000

muestras, es decir 2 segundos. El proceso de aprendizaje semuestra en la Fig. 8. En la misma la señal de ruido blancofiltrada por S(z) esta graficada en azul (en este caso la únicacomponente de e(n) en la Fig. 4), el ruido blanco filtrado por elfiltro adaptativo Sp(z) en verde y el error de identificación enrojo (en este caso la única componente de f(n) en la Fig. 4).

B. Desempeño del controlador H(z)

Para evaluar el desempeño del controlador, se generaron enMATLAB diferentes ruidos de prueba. Luego se los emitió conlos parlantes de una PC portátil. Una persona portando losauriculares se ubicó de frente a los parlantes de la PC,recibiendo el ruido generado de manera uniforme en cada oído.

Durante el proceso de las mediciones se empleo laestimación de S(z) obtenida previamente de manera off-line.Para la adaptación de los coeficientes del controlador H(z) seutilizó la versión normalizada de FxLMS, el algoritmoFxNLMS, que combina (5) y (3). Para H(z) se empleó un filtroadaptativo FIR de longitud Lh = 160 coeficientes. En (3) seutilizó α = 0,016 y para calcular de manera eficiente unaaproximación P’ x de la potencia P x se utilizó una ventanaexponencial de la forma:

Figura 7. Magnitud de la respuesta en frecuencia de Sp(z).

Figura 8. Evolución temporal de la identificación de S(z).

P’ x(n) = (1-β) P’ x(n-1 ) + β x2(n) (7)

lo que requiere almacenar un solo valor ( P’ x(n-1 )) entreiteraciones, y utilizar un factor β que determina la rapidez enque los cambios de x(n) se reflejarán en P’ x(n). Para ello seeligió β = 0,002 como compromiso entre una aproximación

buena y estable de P x y el seguimiento rápido de cambios en x(n). Para evitar que valores cercanos a cero de x(n) produzcanµ muy grande en (3) se aseguró por software que (7) tenga unvalor mínimo P’ xMIN (n) = 0,01.

El primer ruido de prueba generado en MATLAB fue untono de 200Hz, con una amplitud tal que distorsione la salidade los parlantes de la PC portátil, generando así suficientecontenido armónico. La Fig. 9 muestra en azul el espectro de

potencia del ruido generado (d(n) en la Fig. 4), en verde el

espectro atenuado por el sistema CAR (e(n) en la Fig. 4) concoeficientes de 16 bits y en rojo con coeficientes de 32 bits.Dicha medición se obtuvo luego de 3 segundos (24.000muestras) de comenzado el proceso de aprendizaje de H(z).

En la Fig. 9 se observa el tono de 200Hz con sus armónicas,casi de la misma amplitud, y un tono de 50Hz, presente en elcircuito. La atenuación que se logró para el tono de 200Hz, susarmónicas y el tono de 50Hz se muestran en la Tabla I, paraambas precisiones de los coeficientes de H(z). Para armónicassiguientes a 600Hz prácticamente no se percibe atenuación.

El desempeño del controlador también fue probado con untípico ruido de maquina [11], también generado en MATLAB,y reproducido sin distorsión por los parlantes de una PC

portátil. El mismo está formado por 12 componentes múltiplosde 60Hz de distinta amplitud, con la mayor potenciaconcentrada en las componentes de 240, 300, 360, 420 y480Hz. La medición también fue hecha luego de haber transcurrido 3 segundos (24.000 muestras) de comenzado aactuar el aprendizaje del controlador H(z).

La Fig. 10 muestra en azul el espectro de potencia delruido, en verde el de la señal error para coeficientes de H(z) de16 bits y en rojo para coeficientes de 32 bits. La atenuación delas componentes más significativas del ruido de maquina sedetalla en la Tabla II para ambas precisiones de coeficientes.

A m p l i t u d

Cantidad de Coeficientes del Filtro

M a g n i t u d ( d B )

Frecuencia (kHz)

A m p l i t u d

Muestras



28




Figura 9. Espectro de potencia de ruido de 200 Hz distorsionado (líneaazul), señal error con coeficientes de 16 bits (línea verde) y 32 bits (línea roja).

TABLA I. ATENUACIÓN DEL TONO Y SUS ARMÓNICAS

Frecuencia(Hz)

Atenuación

coeficientes 16 bits

(dB)

Atenuación


(dB)

50 33,5 29,5

200 51 85,3

400 44 67,4

600 35,5 59,5

Figura 10. Espectro de potencia del ruido de maquina (línea azul), señalerror con coeficientes de 16 bits (línea verde) y 32 bits (línea roja).

TABLA II. ATENUACIÓN DEL RUIDO DE MÁQUINA

Frecuencia

(Hz)

Atenuación


(dB)

Atenuación


(dB)

240 31,3 56,1

300 46,7 64,6

360 35,2 63,1

420 38,7 64,5

480 25,6 45,2

V. CONCLUSIONES Y DIRECCIONES FUTURAS

A partir del análisis y los resultados presentados en estetrabajo se resumen las siguientes conclusiones:

• El sistema CAR diseñado e implementado atenúa enforma aceptable diferentes ruidos periódicos (o de

banda angosta) en la banda de frecuencia de interés.

• La precisión y capacidad de cómputo del DSP utilizadofue suficiente para realizar el procesamiento de amboscanales independientes de audio en tiempo real enforma simultánea.

• Es apreciable la mejora al utilizar coeficientes de 32 bits para H(z).

• Para las señales de prueba utilizadas el usuariomanifestó que el ruido remanente en la cavidad delauricular resultó en niveles confortables, y fuesensiblemente menor al percibido sin la activación delCAR.

Las direcciones futuras se orientarán al análisis, diseño e

implementación de un CAR aplicado a la cancelación de ruidode banda ancha en un auricular. Asimismo, se investigarán yanalizarán otros algoritmos de adaptación, implementándolosen condiciones reales y con componentes disponiblescomercialmente.

AGRADECIMIENTOS

A la Secretaria de Ciencia y Tecnología de la Universidad Nacional de Córdoba, a la empresa Freescale Semiconductor,Inc.

R EFERENCIAS [1] S. M. Kuo and D. R. Morgan, Active Noise Control Systems-Algorithms

and DSP Implementations, 1st ed., Hoboken, NJ: Wiley, 1996, pp.1–15.[2] B. Widrow and S. Stearns, Adaptive Signal Processing, 1st ed.,

Englewood Cliffs,NJ:Prentice-Hall, 1985, pp.3–96.

[3] B. Widrow, “Adaptive filters” in Aspects of Network and SustemsTheory, R. E. Kalman and N. DeClaris, Eds. New York: Holt, Rinehartand Wiston, 1970, pp. 563–587.

[4] B. Widrow, D. Shur and S. Shaffer “On adaptive inverse control” inProc. 15th Asilomar Conf., 1981, pp. 185-189.

[5] M. T. Akhtar, M. Abe and M. Kawamata “Noise power scheduling inactive noise control systems with online secondary path modeling” inIEICE Electronic Express, Vol. 4 No. 2, 2007, pp. 66-71.

[6] SmartDSP OS Reference Manual , Rev. 1.42, Metrowerks, Austin, TX,Sept. 2005.

[7] CodeWarrior Development Studio for StarCore DSP Architectures: CCompiler User Guide, Freescale, Austin, TX, Aug. 2009.

[8] MSC711XEVM User’s Guide, Rev. 0, Freescale, Austin, TX, Apr. 2005.

[9] W. S. Gan and S. M. Kuo, “Adaptive Feedback Active Noise ControlHeadset: Implementation, Evaluation and Its Extensions”, IEEE Transaction on Consumer Electronics, vol. 51, no. 3, pp. 975-982, Aug.2005.

[10] S. M. Kuo and W. S. Gan, “Active Noise Control System for HeadphoneApplications”, IEEE Transaction on Control Systems Technology, vol.14, no. 2, pp. 331-335, Mar. 2006.

[11] MathWorks. Filter design toolbox. Active Noise Control Using aFiltered-X LMS FIR Adaptive Filter. [Online]. Available:http://www.mathworks.com/products/filterdesign/demos.html?file=/products/demos/shipping/filterdesign/adaptfxlmsdemo.html



29




Prototipado rápido para sistemas embebidos en FPGADesarrollo de la trasformada Wavewlet en 2-D

Melo Hugo Maximiliano; Gutierrez Guillermo; Perez Alejandro; Cavallero RodolfoCentro Universitario de Desarrollo en Automación y RobóticaUniversidad Tecnológica Nacional

Facultad Regional Córdoba

Abstract — Se presenta la metodología de implementación de

prototipos funcionales incorporables a sistemas embebidosbasados en tecnología FPGA. Se describen las herramientas dealto nivel utilizadas y se desarrolla, paso a paso, un módulo IP

que luego es incorporado al sistema embebido. El IP desarrolladoes el banco de filtros para transformada Wavelet en 2-D.

Keywords: Wavelet, prototipado rápido, Filtros FIR, XPS, EDK,

SDK.

I. I NTRODUCCIÓN

Uno de los proyectos desarrollados en el CUDAR de laUniversidad Tecnológica Nacional Facultad Regional Córdobaes la Compresión de Video con Wavelet en Lógica Programable. Como plataforma de Hardware se ha utilizado laFPGA VirtexII Pro de la empresa XILINX, la cual cuenta condos procesadores embebidos en silicio tipo PowerPC. Elsistema hace uso de estos procesadores y los distintos periféricos son incorporados como IP utilizando como soporte

de desarrollo el sistema XPS de la empresa XILINX.Para la compresión de video es necesaria la implementación

de varias operaciones y algoritmos matemáticos, mucho de loscuales son implementados directamente como hardware.Durante el proceso de desarrollo se investigaron y probarondistintos métodos disponibles para prototipado rápido defunciones. El método descripto en el presente trabajo hace usode uno de los programas más difundidos en el área matemática:MatLab perteneciente a la empresa MathWorks y su móduloasociado Simulink, que es una plataforma versátil de diseño ysimulación de sistemas dinámicos, lo que permitió queintegrantes del proyecto con poca experiencia en lametodología de desarrollo en lógica programable, pudiesen

probar ideas y realizar simulaciones que con poco esfuerzo pueden ser llevadas al hardware. Con el importante crecimientoque está mostrando la tecnología de las FPGAs, las cualesincluyen con mas frecuencia procesadores embebidos ensilicio, la posibilidad de portar todos los conocimientosmatemáticos a hardware programable de manera simpledisminuye de forma importante el número de horas hombres ytiempo de depuración, lo cual tiene un marcado impacto en loscostos y el tiempo de prototipado necesario para el desarrollode nuevos productos. Los costos asociados con la adquisiciónde las distintas herramientas utilizadas son amortizadosrápidamente con los frutos de su aplicación.

Las empresas fabricantes de FPGA han invertido muchoesfuerzo en el desarrollo de herramientas de alto nivel quefaciliten la implementación de sistemas complejos en susdispositivos. Un ejemplo de este tipo de software es el SystemGenerator de la empresa XILINX. Este programa contiene unconjunto de bloques para utilizar con el SimuLink. Emplea elconcepto de “cajas negras” y de abstracción de hardware, con

el objetivo de poder llevar a cabo un diseño en bloquesfuncionales y así obtener una concepción de alto nivel que pueda ser simulada utilizando recursos ya disponibles enSimuLink. El System Generator puede ser también utilizadocomo herramienta de integración, ya que es posible definir nuevos bloques con códigos VHDL propietarios.

Una vez implementado y simulado el prototipo es necesario bajar el sistema a la plataforma de Hardware. La empresaXILINX propone como herramienta de alto nivel paradesarrollo de sistemas embebidos el EDK (EmbeddedDevelopment Kit). Esta plataforma de software se componedel XPS (Xilinx Plataform Studio) para el desarrollo delhardware y el SDK (Software Development Kit) para el

desarrollo de software. Estas herramientas están pensadas paraacortar el tiempo de desarrollo. El EDK permite diseñar sistemas mediante gráficos, utilizando bloques funcionales,como en este caso el bloque generado por SimuLink y SystemGenerator. Cada bloque funcional es un dispositivo dehardware distribuido en forma de IP (Intellectual Property).Los mismos hacen uso de las celdas de las FPGAs para generar el dispositivo físico.

Los códigos de MatLab auxiliares serán reemplazados por código de programa implementado en los PowerPC disponiblesen la plataforma.

El sistema fue desarrollado sobre la placa de desarrolloXUPV2P que contiene una FPGA Virtex-II Pro de XILINX.

II. WAVELET

Las Wavelets son familias de funciones que se encuentranen el espacio y se emplean para el análisis, examinan a la señalde interés para obtener determinadas características de espaciotamaño y dirección. La familia está definida por:



30




0,,

abaa

a

b xh

h ba

La familia Wavelet se genera desde una función madre

h(x), que es modificada con las variables a y b para obtener traslaciones y escalado temporal. De esta manera se logra lamejor concentración en información de tiempo y frecuencia[1].

Las transformadas Wavelet se clasifican en TransformadasWavelet Discretas (DWT) y Transformadas Wavelet Continuas(CWT) [2].

A. Tipos de Wavelets

Segun la aplicación se selecciona la Wavelet madre de lacual se derivan las familias de señales por dilatación,

contracción y desplazamiento temporal.

Figura 1. Funciones madres de Wavelets.

B. Transformada Discreta Wavelet en 2-D

Para realizar la Transformada Discreta de Wavelet (DWT)se puede aplicar la metodología de bancos de filtros, pasa bajosy pasa altos seguido de etapas de down sampling que generanla descomposición, como se aprecia en la Figura 2. De lamisma forma la recontrucción es realizada por bancos de filtrosy up sampling de la señal.

El decimado (Down Sampling) y undecimado (Up

Sampling) indican decremento o incremento, respectivamente,de números de muestras, lo cual se logra eliminando unamuestra o intercalando un cero entre ellas [3].

Figura 2. Descomposición Simple

Una imagen es una matriz de datos en donde cada elementorepresenta un pixel, en caso de ser imagen color la misma puede representarse por sus componentes RGB o YCrCb, paraaplicar la transformada Wavelet en dos dimensiones utilizandoel metodo de filtros separables, es necesario recorrer la matrizde dos maneras, primero por filas y luego por columnas como puede verse en la Figura 3.

Figura 3. Wavelet 2-D

La energía normalizada de una sub-imagen formada por N coeficientes de Wavelet se define como:

k j

ni

k jni N

E bb D,

2

)],([1

La característica de energía Wavelet Eni n=1...d, i= H, V, D refleja la distribución de energía a lo largo del eje defrecuencia sobre una escala y en una orientación determinada.

La energía de las imágenes se concentra en las frecuencias bajas. Una imagen tiene un espectro que se reduce con elincremento de las frecuencias. Estas propiedades quedanreflejadas en la Transformada Wavelet Discreta de la imagen[4].



31




En compresión y en algunas otras aplicaciones de latransformada se hace necesario aplicar una técnica multinivel.Esta se obtiene aplicando sucesivamente las transformadas a la parte de aproximación de la etapa anterior como puede verse enla Figura 4.

Figura 4. 3 Niveles de Wavelet en 2-D

III. IMPLEMENTACIÓN

Para la implementación de la transformada Wavelet en 2-Des necesario recorrer las matrices de datos por filas y luego por columnas. A modo de prueba de concepto se optó por implementar modularmente las distintas etapas de latransformada.

Cada una de las etapas se presenta con un móduloindependiente y la unión entre ambos se realiza con un códigode MatLab que posteriormente será reemplazado en la FPGA

por rutinas de manipulación de datos ejecutadas en los procesadores embebidos. A continuación se describe el métodoempleado y los resultados obtenidos.

A. Implementación del prototipado rápido

1) Filtro FIRFiltro FIR en su forma directa

Figura 5. Estructura filtro FIR.

La salida Y[n] del filtro no depende de los valores previosde sí misma, solo de los valores actuales y/o previos de laentrada X[n], es decir, es un sistema no recursivo. Esto haceque los FIR (Finite Impulse Response) sean siempre estables.

Se destaca que el parámetro M-1 es el orden del polinomioy orden del filtro, mientras que la cantidad de coeficientes delfiltro es M .

2) Características.

Los filtros FIR a implementar son los que permiten realizar la transformada Wavelet por el método de bancos de filtros.

Estos coeficientes se obtienen desde la ventana de comando deMatLab con la siguiente expresión:

[LO_D,HI_D,LO_R,HI_R]= WFILTERS('db3')

'db3' le indica a la función de MatLab que la Waveletmadre es una Daubechies 3. Los filtros resultantes para estaWavelet son de orden 5 con un total 6 coeficientes.

A continuación se realiza el esquemático de la Figura 6 enentorno SimuLink, utilizando bloques propios de SimuLink ySystem Generator.

Figura 6. Primera Descomposición Simple

Se toma como entrada la componente de Crominancia roja(Cr) de una imagen de 100 x 100 píxeles.

Luego de la decimación de la primera descomposiciónsimple, los filtros arrojan N+2 coeficientes con valor numérico,donde N es el número que se espera luego de una decimación.Estos dos valores podrían ser interpretados como extras, producto de:

entera parteTruncación

filtrodel Ordenentradade Datos N

222

Ejemplo:

Cantidad de datos a la entrada= 10000



32




Orden del filtro = 5

50022

5

2

10000


Cantidad de coeficientes a la salida = 5002.

3) Propuesta de implementación

El presente trabajo propone implementar rápidamente enhardware un prototipo funcional del sistema que permita hacer una evaluación conceptual y funcional del diseño, sin atacar aún el problema de optimización del mismo.

Para realizar los distintos barridos necesarios de la matrizde datos, se utiliza programación directa en MatLab, y se aplicala señal a SimuLink directamente en forma de vector, lo cual

hace transparente el recorrido de la matriz para este último.MatLab esta diseñado para trabajar con matrices, por lo que

las operaciones con este tipo de arreglo de datos sonextremadamente simples de realizar, la mayoría de ellas sereducen a operadores, como la que devuelve un vector, a partir de recorrer la matriz por columnas. Para obtener el barridohorizontal y vertical se utiliza la misma función pero aplicada ala matriz original o a su transpuesta. Para poder hacer uso deeste método es necesario que la matriz sea cuadrada y ademásdebe respetar la apariencia de la imagen original.

Como método de prueba se trabajó sobre la siguiente proposición: a la salida de la primera descomposición seobtienen 5002 datos, lo cual no es compatible con una matriz

rectangular. A los efectos de lograr una matriz rectangular seensayaron las siguientes soluciones: a) se agregaron 98 ceros para hacer compatible el número de datos con una matrizrectangular necesaria para la siguiente etapa, lo que dio comoresultado una alteración de la imagen reconstruida ya que losceros quedaban embebidos en el análisis. b) se optó por truncar el número de datos, considerando válidos 5000 datos. Durantelos ensayos se determinó que no se puede descartar cualquier dato, ya que esto repercute en los resultados de la posterior reconstrucción. Para cada descomposición simple, se optó por tomar como validos los N primeros datos, eliminando M datosde la descomposición, el valor de M se obtiene truncando la parte entera de la siguiente relación:


filtrodel Orden M

2

La cantidad N de datos útiles se calcula con la siguientefórmula:

2

Entradade Datos N

De esta forma se obtienen los datos para formar la matrizrectangular necesaria para los siguientes pasos.

Este método se utilizó tanto en la etapa de descomposicióncomo en la de reconstrucción.

Figura 7. Recomposición Simple

Se debe tener en cuenta que para una reconstruccióncorrecta, utilizando el presente método, se debe aplicar elrecorte de datos de manera invertida. Es decir si en la etapa dedescomposición se utilizaron los primeros N datos, en lasetapas de reconstrucción se deben utilizar los últimos N’ datos.

2)(' entradade Datos N

Dejando de tener en cuenta una cantidad M de coeficientesde salida.

4) Distorsión en los bordes de una imagen.

La teoría de banco de filtros utilizada para laimplementación de la transformada Wavelet, está planteada yfunciona adecuadamente para señales infinitas, pero se producen distorsiones en los límites de las señales finitas, comoes en el caso de una imagen [5].

Se han propuesto varios métodos para solucionar este problema. Todos ellos proponen extender la señal de algunamanera. La bibliografía consultada propone entre otros elmétodo de convolución circular y la reflexión simétrica, que seobtienen mediante la reflexión y la repetición simétrica de lasmuestras en la frontera. MatLab también plantea la posibilidadde relleno con ceros.

Estas ampliaciones no son arbitrarias y dependenexclusivamente del orden del filtro. Pese a la extensión, lasalida continúa generando distorsión en los bordes, sinembargo es bastante fácil ver la reflexión simétrica también ala salida de los filtros. Eliminando dicha distorsión simétrica,se obtiene la salida recuperada perfecta, que puede ser verificada con MatLab a través de:

[Ap De]= dwt (entrada, ‘db3’);



33




Donde entrada es un vector de valores finitos, db3corresponde al tipo de onda utilizado para el cálculo decoeficientes y las salidas son Ap y De corresponden a laAproximación y Detalle respectivamente.

5) Resultado de la implementación propuesta

Al comparar la imagen reconstruida con la imagen originalutilizando el método implementado, se hallaron errores en elmargen superior izquierdo de la imagen, de manera másespecífica en una submatriz de n x n donde n es la cantidad decoeficientes del filtro implementado para Daubechies 3.

Como solución a este problema se agregaron marcos a laimagen original. En esta experiencia para prototipado rápido seutilizó un marco cuyo valor numérico era el uno, esto permitióapreciar el comienzo de la imagen al finalizar el marco, y pesea que no se empleó ninguna extensión de frontera se logró unareconstrucción perfecta. Esto se debe a que los errores de los procesos de truncación de información para la formación dematrices auxiliares de recorrido, descriptos anteriormente, se

sitúan dentro del perímetro del marco, figura 8, que posteriormente es eliminado.

Figura 8. Marcos agregados a la imagen original.

El Centro Universitario de Desarrollo en Automación yRobótica (CUDAR) actualmente está incorporando estosmétodos a las etapas de transformación para la compresión devideo.

B. Incorporación del módulo Wavelet a un sistema

embebido en FPGA con XPS

La etapa final del desarrollo es la incorporación del módulodesarrollado en un sistema real.

La plataforma de trabajo con la que se cuenta está basadaen una FPGA VirtexII-Pro de XILINX, la cual tieneincorporado en silicio dos procesadores PowerPC.

La forma más fácil e intuitiva de implementar sistemasembebidos en esta plataforma es con el XPS utilizando el

EDK. Una vez generado el Hardware se utilizará el SDK paragenerar y depurar el software.

Del trabajo realizado con System Generator resulta unmódulo que tendrá por puertos en la entidad principal dosregistros de entrada/salida de 8 bits, una entrada para el relojdel sistema y una entrada de chip enable. Para embeber elmismo se ejecuta el asistente “Create or import Peripheral” delentorno XPS [6].

Los pasos para implementar un sistema embebidoutilizando el entorno XPS son:

Generar gráficamente la plataforma base, Micro, bus,controladores de memorias, periféricos de IO genéricos etc.

Generar un nuevo IP para poder incorporar la entidad principal de los bloques Wavelet. Esto se debe contemplar dentro de las funciones que se seleccionan durante el asistente para generación de la interfaz funcional para propiedadintelectual (IPIF). La existencia de los dos registros accesibles por software que serán los mismos que necesita el módulogenerado por System Generator.

Instanciar las fuentes de los archivos generados por SystemGenerator en los archivos “user:logic.hdl” y “top_entidad.hdl.”.

Una vez verificada la incorporación, mediante la síntesis delas fuentes, se agrega el IP desde el repositorio en el entornoEDK, se conecta al bus correspondiente y se generan las posiciones de memoria del sistema .

Figura 9. Esquema del módulo encapsulado en el IPIF.

Una vez incorporado el filtro al sistema, se crea una rutina

en SDK, la cual escribirá en el registro de entrada del filtrodatos enviados por el puerto serie de una PC conectada alsistema. Los datos procesados se leen del registro de salida y seenvian a una PC por el puerto serie, los mismos sonalmacenados y posterirmente contrastados con los resultadosde las simulaciones realizadas en SimuLink.



34




IV. CONCLUSIÓN Y FUTUROS TRABAJOS

Las pruebas realizadas con la metodología utilizadademostró ser efectiva para la implementación de módulos IP, lainteracción entre las herramientas de alto nivel demostró ser robusta y confiable. La posibilidad de utilizar la potencia deMatLab en desarrollo de algoritmos y verificaciones abren la puerta a la implementación de hipótesis de manera rápida para

validación o refutación, acortando los tiempos de investigacióny desarrollo. La evolución de las herramientas de desarrollo desistemas embebidos en plataformas FPGA muestran uncrecimiento importante y sostenido de este campo en este tipode tecnologías.

En el CUDAR se continuará con la exploración de este tipode alternativas en todos los proyectos que involucrenalgoritmos matemáticos.

R EFERENCIAS

[1] Jalali, Payman. “Wavelets and aplication.” Energy Tecnology

Department. Lappeenranta University of Tecnology.[2] Kobayashi, Mei. “Wavelets Analisys: Application in Industry” Tokyo

Research Laboratory.

[3] Burrus, Sidney; Gopinath, Ramesh; Guo Haitao. “Introduction toWavelets and Wavelets Transforms”. Electrical and computer

engenieering departament. Rice University. Houston, Texas.

[4] Borja José García Menéndez; Eva Mancilla Ambrona; Ruth MontesFraile. “Optimizacion de la transformada Wavelet Discreta” Universidadcomplutense de Madrid – Facultad de informática 2004 – 2005.

[5] Strang ,Gilbert; Nguyen, Truong. “Wavelets and Filter Banks” .

[6] Perez, Alejandro; Gutierrez, Francisco, Rodolfo Cavallero, NicolasRavotti “Desarr ollo de sistemas embebidos en FPGAs. Diseño eincorporación de periféricos”.



35




FPGA, Verilog,

VHDL y HDLs



36






37




Implementacion en FPGA de decodificadores LDPC

de baja complejidad

L. Arnone C. Gayoso C. Gonzalez M. Rabini J. Castineira MoreiraFacultad de Ingenierıa

Universidad Nacional de Mar del Plata

Email: [email protected]

Abstract—Los codigos con matriz de paridad de baja densidadLDPC son considerados ampliamente como uno de los codigoscorrectores de errores a ser usados en sistemas de comunica-ciones de la proxima generacion. En este trabajo se presentala implementacion de dos decodificadores LDPC en FPGA, quepermiten trabajar con cualquier tipo de matriz paridad (incluidas

las generadas aleatoriamente, las generadas con una determinadaregla de construccion, como las quasi-cıclicas, sean de tiposistematico, o no sistematico), y se adapta en forma parametricacualquiera sea la tasa del codigo k/n.

Ambas implementaciones son de baja complejidad, debido aque solo utilizan operaciones de suma-resta y busqueda en tablas.

El segundo decodificador implementado tiene la ventaja queno requiere el conocimiento de la proporcion de se ˜ nal a ruido dela se ˜ nal recibida del canal.

I. INTRODUCCION

Los codigos de paridad de baja densidad (LDPC) estan reci-

biendo mucha atencion debido a su funcionamiento cercano

al lımite de Shannon [1]. Un metodo que permite decodificarrapidamente codigos LDPC es el algoritmo de suma-producto

(SP) propuesto por Gallager [2].

Por otro lado, el algoritmo de distancia-suave (DS) [3][4],

que utiliza como metrica la distancia Euclidiana mınima

cuadrada, tiene la ventaja de no requerir el conocimiento de la

proporcion de senal a ruido de la senal recibida. El desempeno

de este algoritmo es similar al del algoritmo de suma-producto.

Los cocientes y productos involucrados en estos algoritmos

hacen que sean difıcil su implementacion en forma sencilla en

logica programable.

En este trabajo se muestra como es posible implementar

ambos decodificadores LDPC (suma-producto y distancia-

suave) en FPGA [5] utilizando solo operaciones de suma-restay tablas de busqueda. Estos decodificador pueden trabajar con

cualquier tamano y tipo de matriz de paridad H (incluidas las

generadas aleatoriamente, las generadas con una determinada

regla de construccion, como las quasi-cıclicas [6],[7], sean de

tipo sistematico, o no sistematico) y su arquitectura puede ser

f acilmente configurada para diferentes tasas de codigo.

Los resultados obtenidos muestran que no hay una gran

diferencia en el desempeno de decodificacion al utilizar los

decodificadores propuestos con respecto a decodificar usando

los algoritmos de suma-productos (SP) y distancia-suave (DS).

Esto permite, implementar decodificadores en logica progra-

mable de muy baja complejidad con muy buen desempeno.

I I . DECODIFICADOR LDPC

En los codigos LDPC [1] existe una matriz de paridad H,

la cual cumple con la condicion H r = 0 para todo vector

r del codigo. La esencia del algoritmo de decodificacion [1]

es encontrar el vector r, (el cual es una estimacion del vector

r ), que cumpla con la condicion:

H r = 0 (1)

En este algoritmo se produce un intercambio de informacion

[2] entre cada nodo sımbolo (representativo de los sımbolos

del vector r), y los nodos de paridad, (representativos de las

ecuaciones de paridad que se vinculan con los sımbolos de r).

Este proceso de intercambio de informacion entre nodos es

iterativo. El proceso se detiene si se cumple la condicion dada

por (1), con lo cual se obtiene un mensaje valido, o bien, si

el numero de iteraciones establecido es alcanzado sin que se

cumpla la condicion anterior, se habra producido un error.

III. ALGORITMO DE DECODIFICACION DE SUMA-RESTA

El algoritmo de suma-resta, es descripto en [8] y esta

basado en el algoritmo de decodificacion de suma- producto

introducido por D. J. C. MacKay y R. M. Neal [1]. A

continuacion se detalla brevemente su funcionamiento.

Si yj es el sımbolo obtenido a la salida del canal en el

tiempo j, la probabilidad a priori F xj de que el j−esimo

sımbolo sea x, con x = 0, 1 esta dada por:

F 1j = e−f 1j =1

1 + e−2yj/σ2(2)

F 0

j= e−f 0j = 1 − F 1

j(3)

se pueden hallar |f 1j | y |f 0j | como:

|f 1j | = ln

1 + e−2yj/σ2

= f +(2yj/σ2, 0)

|f 0j | = 2yj/σ2 + f +(2yj/σ

2, 0) (4)

donde f +(a, b) es una tabla de busqueda con entrada |a− b|[9], [10]. La Tabla I resume los pasos del algoritmo utilizado.

Dada una matriz de paridad H, se denomina N (i) al conjunto

de columnas que tienen elementos no nulos para la fila i, y

M ( j) al conjunto de filas con elementos no nulos para la

columna j. Igualmente f −

(a, b) es una tabla de busqueda con

entrada |a− b| (Ver apendice A).



38




TABLA IRESUMEN DEL ALGORITMO SR

Inicializacion

q0ij

= f 0j

q1ij

= f 1j

Paso horizontal 1

δqij = max(−q0ij,−q1

ij) + f

−(q0ij, q1ij

)

sij = 0 si −q0ij≥ −q1

ijsino sij = 0

Paso horizontal 2

δrij =

N (i)

δqij − δqij

sδrij =

N (i)

sij − sij

Paso horizontal 3

si sδrij es par

r0ij

= lg(2)− f +(δrij , 0)

r1ij

= lg(2) + f −

(δrij , 0)

si sδrij es impar

r0ij

= lg(2) + f −

(δrij , 0)

r1ij

= lg(2)− f +(δrij , 0)

Paso vertical

cxij = −f xj +

M (j)

rxij − rxij

q0ij = −c0ij −max(c0ij , c1ij

) + f −

(c0ij , c1ij

)

q1ij = −c1ij −max(c0ij , c1ij

) + f −

(c0ij , c1ij

)

Estimacion del sımbolo decodificado r( j)

cxj

= −f xj−

M (j)

rxij

rj = 0 si c0j≥ c1

jsino rj = 1

IV. ARQUITECTURA DEL DECODIFICADOR DE

SUMA-RESTA (SR)

En la Fig. 1 se observa el decodificador implementado. La

memoria ROM H solo almacena la ubicacion de cada “uno”en la matriz H, su tamano depende del numero de columnas

con “unos” en cada fila y del numero de filas que posee. Por

ejemplo, para una matriz H1 generada aleatoriamente, de 60×30, el tamano de ROM H es de 256 palabras de 6 bits, y para

una matriz H2 generada aleatoriamente, de 1008× 504, es de

4096 palabras de 10 bits. La ROM num unos fil almacena

el numero de columnas con “unos” que tiene cada fila. Esta

memoria se utiliza para poder indexar y poder ası recuperar

junto con la ROM H , la posicion de cada “uno” en la matriz

H. Las memorias ROM ftabla+ y ROM ftabla- contienen las

tablas de busquedas f +(a, b) y f −

(a, b). Ambas tablas son de

256 palabras de 16 bits, tanto para H1 y H2. Las RAM f 0 y

ROM_H ROM_num_unos_fil

RAM_f0 RAM_f1 RAM_q0 RAM_q1

ROM_ftabla+

CONTROL

ROM_ftabla-

r(j)y(j)

Salidadel

canal

Salidaestimada

Fig. 1. Arquitectura del decodificador SR implementado en FPGA deALTERA [5]

RAM f 1 almacenan a f 0 y f 1 cada vez que ingresa una nueva

palabra al decodificador. Su tamano depende de la longitud de

palabra utilizada.

Las memorias RAM q0 y RAM q1, poseen igual cantidadde palabras que la memoria ROM H , pero son de 16 bits. Las

RAM q0 y RAM q1 realizan varias funciones: En la inicializa-

cion almacenan los valores de q 0ij y q 1ij . En el paso horizontal

1, RAM q0 guarda los valores de δq ij y RAM q1 guarda los

valores de sij. En el paso horizontal 2 se almacenan los valores

de δrij y sδrij . En el paso horizontal 3 se almacenan los

valores de r0ij y r1ij . Finalmente en el paso vertical se vuelven

a almacenar los valores de q 0ij y q 1ij. Esto le da un alto grado

de reutilizacion a estas memorias.

V. ALGORITMO DE DECODIFICACION DE DISTANCIA

SUAVE SIMPLIFICADO (DSS)

En el algoritmo de decodificacion clasico de suma-producto,si yj es el sımbolo obtenido a la salida del canal en el tiempo

j, suponiendo que la informacion es transmitida con formato

polar normalizado con amplitud ±1; la probabilidad a priori

F xj de que el j−esimo sımbolo sea x, con x = 0, 1 esta

dada por (2) y (3).

En el algoritmo de decodificacion de distancia suave (DS) el

calculo de probabilidades [3][4] es reemplazado por el calculo

de la distancia Euclidiana cuadrada:

d21( j) = (yj − 1)2

d20( j) = (yj + 1)2 (5)

De forma similar a lo propuesto en [8], en este caso tambien

se realiza un desarrollo logarıtmico [11] para obtener el algo-

ritmo de decodificacion de distancia suave simplificado (DSS).

La Tabla II resume el algoritmo DSS. Como se puede observar

solo se realizan comparaciones, sumas, restas y busquedas en

tablas.

VI . ARQUITECTURA DEL DECODIFICADOR DS S

En la Fig.2 se observa el decodificador implementado. La

memoria ROM H solo almacena la ubicacion de cada ”uno”

en la matriz H, su tamano depende del numero de columnas

con ”unos” en cada fila y del numero de filas que posee. Por

ejemplo, para una matriz H1 generada aleatoriamente, de 60×30, el tamano de ROM H es de 256 palabras de 6 bits, y para



39




TABLA IIRESUMEN DEL ALGORITMO DSS

Inicializacion

q0ij

= d0j

( j) q1ij

= d1j

( j)

Paso horizontal 1

σqij = +f +(q0ij

, q1ij

)

δqij = −f −

(q0ij

, q1ij

)

sij = 0 si −q0ij≥ −q1

ijsino sij = 1

Paso horizontal 2

σrij =

N (i)

σqij − σqij

δrij =

N (i)

δqij − δqij

sδrij =

N (i)

sij − sij

Paso horizontal 3

si sδrij es par

r0ij

= −f +(σrij , δrij)

r1ij

= +f −

(σrij , δrij)

si sδrij es impar

r0ij

= +f −

(σrij , δrij)

r1ij

= −f +(σrij , δrij)

Paso vertical

q

0

ij = d

2

0( j) +M (j) r

0

ij − r

0

ij

q1ij

= d21( j) +

M (j)

r1ij− r1

ij

Estimacion del sımbolo decodificado r( j)

r20( j) = q0ij

+ r0ij

r21( j) = q1ij

+ r1ij

rj = 1 si r21( j) < r20( j) sino rj = 0

una matriz H2 generada aleatoriamente, de 1008× 504, es de

4096 palabras de 10 bits. La ROM num unos fil almacenael numero de columnas con ”unos” que tiene cada fila. Esta

memoria se utiliza para poder indexar y poder as ı recuperar

junto con la ROM H , la posicion de cada ”uno” en la matriz

H. Las memorias ROM ftabla+ y ROM ftabla- contienen las

tablas de busquedas f +(a, b) y f −

(a, b). Ambas tablas son de

256 palabras 16 bits tanto para H1 y H2.

Las RAM d 20 y RAM d 21 almacenan a d20 y d21 cada vez

que ingresa una nueva palabra al decodificador. Su tamano

depende de la longitud de palabra utilizada.

Las memorias RAM q0 y RAM q1, poseen igual cantidad

de palabras que la memoria ROM H , pero son de 16 bits. Las

RAM q0 y RAM q1 realizan varias funciones: En la inicializa-

ROM_H ROM_num_unos_fil

RAM_d20 RAM_d21 RAM_q0 RAM_q1

ROM_ftabla+

CONTROL

ROM_ftabla-

r(j)

y(j)

Salidadel

canal

Salidaestimada

RAM_signo

Fig. 2. Arquitectura del decodificador DSS implementado en FPGA deALTERA [5]

cion almacenan los valores de d20 y d21. En el paso horizontal

1, RAM q0 guarda los valores de σq ij y RAM q1 guarda los

valores de δq ij . En el paso horizontal 2 se almacenan los

valores deσrij

yδrij

. En el paso horizontal 3 se almacenan

los valores de r0ij y r1ij .

Finalmente en el paso vertical se vuelven a almacenar los

valores de q 0ij y q 1ij, esto le da un alto grado de reutilizacion

a estas memorias. La RAM signo almacena sij en el paso

horizontal 1 y sδrij en el paso horizontal 2.

VII. COMPLEJIDAD

El analisis del numero de operaciones involucradas en los

algoritmos presentados permite tener una idea del costo en

terminos de hardware que supone su implementacion.

Dada una matriz H, con N columnas y M filas, se define

a t = M ( j) prom como el numero promedio de unos por

columna, y v = N (i) prom al numero promedio de unos porfila. Tıpicamente se tiene:

v = N · t/M (6)

Para un codigo LDPC de velocidad 1/2, M = N/2,

entonces:

v = 2 · t (7)

A continuacion se se evalua el grado de complejidad para los

algoritmos tratados (utilizando t = 3 y v = 6)

SP (Mackay and Neal)

productos: 2(v + 2t− 6)Nt = 36N sumas y restas: 5Nt = 15N

cocientes: 2Nt = 6N

SR

sumas y restas (paso horizontal): (3+ 2(v− 2))Nt = 33N comparaciones (paso horizontal): 3Nt = 9N busquedas en tablas (paso horizontal): 3Nt = 9N sumas y restas (paso vertical): (11+(t− 2) + t)Nt = 45N comparaciones (paso vertical): 5Nt = 15N busquedas en tablas (paso vertical): 4Nt = 12N

DSS

sumas y restas (paso horizontal): (6+ 3(v− 2))Nt = 54N comparaciones (paso horizontal): 6Nt = 18N busquedas en tablas (paso horizontal): 4Nt = 12N



40




TABLA IIIANALISIS DE LA COMPLEJIDAD DE LA IMPLEMENTACION DEL

ALGORITMO DE DECODIFICACION USANDO t = 3 .

operaciones SP (Mackay-Neal) SR [8] DSSproductos 36N – –cocientes 6N – –

sumas y restas 15N 78N 72N comparaciones – 24N 21N

busquedas en tabla – 21N 12N

TABLA IVRESULTADOS OBTENIDOS EN LA IMPLEMENTACI ON DE UN

DECODIFICADOR SR Y DSS DE TAMANO (60× 30)

Hardware utilizado SR DSS

Dispositivo EP2C35F672C6 EP2C35F672C6

Familia Cyclone II Cyclone II

Elementos logicos 1036 882

Registros 394 387

Bits de memoria 15968 20320

Frecuencia del reloj 101, 67MHz 112, 38MHz

sumas y restas (paso vertical): (2(t− 2) + 4)Nt = 18N

comparaciones (paso vertical): Nt = 3N En la Tabla III, se resume el grado de complejidad de los al-

goritmos tratados. Como se puede observar, el algoritmo DSS

posee menos operaciones que el SR [8]. Si bien los algoritmos

DSS y SR requieren mas operaciones de sumas y restas que

el algoritmo de decodificacion tradicional de Mackay-Neal, la

complejidad del DSS y SR se ven notablemente reducidas por

el hecho que no utilizar productos ni cocientes.

VIII. RESULTADOS OBTENIDOS

Ambos decodificadores LDPC (60× 30) y LDPC

(1008× 504) se implementaron usando lenguaje VHDL

[12] y la herramientas de sıntesis del programa QUARTUS

II [13] de ALTERA. En la Tabla IV se pueden ver losresultados obtenidos en la implementacion del decodificador

LDPC (60× 30) y en la Tabla V los resultados para el

decodificador (1008× 504). En ambos casos se observa que

el decodificador DSS es mas veloz que el SR, y utiliza menos

elementos logicos y registros.

En la Fig. 3 se muestra los resultados obtenidos haciendo

una simulacion del codigo LDPC (60×30) en una transmision

de 10000 bloques de 30 bits de mensajes, y en la Fig.

4 los resultados del codigo LDPC (1008 × 504) en una

transmision de 10000 bloques de 504 bits de mensajes. En

ambos decodificadores se utilizaron 16 iteraciones y factores

de correccion tabulados en tablas de 256 elementos.

TABLA VRESULTADOS OBTENIDOS EN LA IMPLEMENTACION DE UN

DECODIFICADOR SR Y DSS DE TAMANO (1008× 504)

Hardware utilizado SR DSS

Dispositivo EP2C35F672C6 EP2C35F672C6

Familia Cyclone II Cyclone II

Elementos logicos 1109 951

Registros 435 428

Bits de memoria 210944 219136

Frecuencia del reloj 94, 43MHz 118, 11MHz

0 1 2 3 4 510

−4

10−3

10−2

10−1

Eb/No [dB]

P r o b a b i l i d a d

b i n a r i a

d e

e r r o r

Sin codificar

DS ideal

SP Mackay−Neal

SR tabla de 256 entradas

DSS tabla de 256 entradas

Fig. 3. Desempeno de un decodificador LDPC 60 × 30 para diferentesalgoritmos de decodificacion

En la Fig. 3 el BER (Bit Error Rate) es cero para ambos de-

codificadores (SR y DSS) cuando E b/N 0 ∼ 5dB (σ = 0.56) y

en la Fig. 4 el BER es cero cuando E b/N 0 ∼ 3dB (σ = 0.7).

Se puede apreciar que el desempeno al usar tablas de 256entradas no muestra diferencias apreciables con respecto al

uso de la funcion ideal (SP Mackay-Neal y DS).

Por tanto se ve que es posible implementar decodificadoresde baja complejidad sin tener una perdida apreciable en la tasa

de error, usando tablas de busqueda de tamano razonable.

I X. CONCLUSIONES

Se han disenado e implementado en FPGA dos decodifi-

cadores LDPC. Ambos pueden trabajar con cualquier tamano

y tipo de matriz de paridad H (incluidas las generadas aleato-

riamente, las generadas con una determinada regla de cons-

truccion, como las quasi-cıclicas, sean de tipo sistematico, o

no sistematico), y se adaptan en forma parametrica cualquiera

sea la tasa del codigo k/n. El decodificador DSS presenta

la ventaja de no requerir informacion del nivel del ruido del



41




1 1.5 2 2.5 310

−4

10−3

10−2

10−1

Eb/No [dB]

P r o b a b i l i d a d

b i n a r i a

d e

e r r o r

Sin codificar

DS ideal

SP Mackay−NealSR tabla de 256 entradas

DSS tabla de 256 entradas

Fig. 4. Desempeno de un decodificador LDPC 1008× 504 para diferentesalgoritmos de decodificacion

canal.

Ambas implementaciones muestran una gran versatilidad deaplicacion y no presentan diferencias apreciables en el de-

sempeno de tasa de error con respecto al uso del decodificador

de suma-producto ideal introducido por D. J. C. MacKay y R.

M. Neal.

APENDICE A

ALGEBRA LOGARITMICA

En caso de tener C = ec, A = ea y B = eb, para C = A+B

se tiene:

c = max(a, b) + ln(1 + e−|a−b|) (8)

Para C = A − B o C = (−1)zec = (−1)z|C | con |C | =|A − B| y z = 0 si A > B sino z = 1, entonces:

c = max(a, b) + ln(1 − e−|a−b|)

= max(a, b) − | ln(1 − e−|a−b|)| (9)

El calculo de los logaritmos involucrados en (8) y (9) pueden

ser evitados usando tablas de busqueda f +(a, b) y f −(a, b)con entradas |a − b|.

REFERENCIAS

[1] D.J.C. MacKay and R.M. Neal, “Near Shannon limit performance of low density parity check codes,” Electronics Letters, vol. 33, pp 457-458(1997).

[2] R.G. Gallager, “Low Density Parity Check Codes,” IRE Trans. Informa-tion Theory, IT-8, 21-28 (1962).

[3] P. G. Farrell,“Decoding Error-Control Codes with Soft Distance as theMetric,” in Proc. Workshop on Mathematical Techniques in CodingTheory, Edinburgh, UK, (2008).

[4] P. G. Farrell and J. Castineira Moreira, “Soft-Input Soft-Output EuclideanDistance Metric Iterative Decoder for LDPC Codes,” in Proc. ArgentineSymposium on Computing Technology (AST 2008), Santa Fe, Argentina,(2008).

[5] www.altera.com, “Cyclone II FPGAs,” On Line.[6] J. Sha, M. Gao, Z. Zhang, L. Li and Z. Wang, “A Memory Efficient FPGA

Implementation of Quasi-Cyclic LDPC Decoder,” Proc. 5th WSEAS Int.

Conf. on Instrumentation, Measurement, Circuits and Systems,, vol 1, pp218-223 (2006).

[7] M.K. Ku, H.S. Li and Y.H.. Chien, “Code Design And Decoder Imple-mentation of Low Density Parity Check Code,” Emerging InformationTechnology Conference, (2005).

[8] L. Arnone, C. Gayoso, C. Gonzalez and J. Castineira, “Sum-SubtractFixed Point LDPC Decoder,” Latin American Applied Research, vol 37,pp 17-20 (2007).

[9] J.P. Woodard and L. Hanzo, “Comparative Study of Turbo DecodingTechniques,” IEEE Transaction on Vehicular Technology, vol. 49, (2000).

[10] T. Bhatt, K. Narayanan and N. Kehtarnavaz, “Fixed point DSPimplementation of Low-Density Parity Check Codes,” Proc IEEE

DSP2000,(2000).[11] P. G. Farrell L. Arnone and J. Castineira Moreira, “FPGA imple-

mentation of a Euclidean distance metric SISO Decoder,” Proceedingsof the Tenth International Symposium in Communications Theory and

Applications. ISCTA’ 09, vol 1, pp 1-5 (2009).[12] L. Teres, Y. Torroja, S. Olcoz, E. Villar VHDL. Lenguaje Est andar

de Dise˜ no Electr´ onico, McGraw Hill/Interamericana de Espana, Madrid

(1997).[13] www.altera.com, “Quartus II Software,” Available: On Line.



42




Generador de Números Pseudoaleatorios Mediante elSistema Numérico de Residuos, Implementación en

FPGA

Carlos Arturo Gayoso, Claudio Marcelo González, Leonardo Arnone y Miguel RabiniLaboratorio de Componentes Electrónicos, Departamento de Electrónica

Universidad Nacional de Mar del PlataMar del Plata, República Argentina

[email protected]

Resumen — Este trabajo estudia la implementación en

hardware de generadores de números pseudo aleatorios ( Pseudo

Random Number Generators, PRNGs o Generadores de Números

Pseudoaleatorios, GNPA), en lógica programable (Field

Programmable Gate Arrays o FPGA). Se investiga el empleo del

sistema numérico de residuos ( Residue Number System o RNS)para incrementar la velocidad a la que los generadores producen

los números aleatorios y para que posea una dinámica distinta a

los generadores conocidos. El circuito propuesto se evaluó desde

el punto de vista estadístico mediante tests básicos y el conjunto

de tests propuesto por George Marsaglia para su generador die

hard. El trabajo está organizado de la siguiente manera. Se

comienza con la definición de sistemas determinísticos y

aleatorios junto con la presentación del test die hard y su empleo.

Se describe el generador de números pseudo aleatorios propuesto

junto la explicación de cada uno de los bloques que lo

constituyen. Se finaliza presentando los aportes y conclusiones

del trabajo realizado.

Palabras clave; Sistema Numérico de Residuos; Aritmética de

residuos; Números pseudoaleatorios; Lógica Programable.

I. I NTRODUCCIÓN

A. Determinismo y aleatoriedad

Los sistemas, desde el punto de vista de sucomportamiento, se puede clasificar como deterministas,aleatorios o caóticos. En los sistemas deterministas se puede

precisar cualquiera de sus futuros estados conociendo su estado presente, no hay participación del azar en ninguna de susvariables ni en las relaciones entre ellas. Por el contrario en lossistemas aleatorios el azar es el componente esencial [1], [2].Tal es así, que no se puede determinar la evolución del mismo,ni siquiera su próximo estado, conociendo con una precisiónilimitada su salida actual y las anteriores, no se puede encontrar ningún tipo de patrón o regularidad. Existen diversos circuitoso algoritmos que tienen la particularidad de generar secuenciasde números aleatorios. En este caso, a diferencia de procesosnaturales, las series generadas tienen un período, que si bien

puede ser muy grande, es finito. Por esta razón a estos sistemasse los denomina pseudoaleatorios.

B. Tests de aleatoriedad

Los test de aleatoriedad se emplean para analizar unasecuencia de números, provenientes de una fuente natural oartificial, para determinar si se trata de un proceso estocástico

[1], [2]. Un estudio preliminar de la secuencia de datos, por ejemplo uniformidad, o autocorrelación, puede poner enevidencia un patrón de comportamiento fácilmente predecibleque descarte un comportamiento aleatorio. Sin embargo, enotros casos, con las herramientas estadísticas tradicionales nose puede detectar una estructura determinista. Es por ello quese han ideado distintos tipos de test a los que es sometida lasecuencia numérica bajo estudio en busca de concluir sobre sucarácter deterministico o aleatorio.

Entre los test más utilizados para medir la calidad de unasecuencia de números supuestos aleatorios se encuentra diehard [3], [4]. En realidad es un conjunto de 17 testsdesarrollados por George Marsaglia de manera progresivadesde 1985 y publicados por primera vez juntos en 1995.

El generador propuesto en este trabajo se sometió al test diehard pues es uno de los más díficiles de superar. El paquete diehard tiene como entrada un archivo de al menos 11 Mbytes conla secuencia de números cuya aleatoriadad se desea determinar y entrega una serie de 229 valores denominados p, cada uno delos cuales debe cumplir 0,025 < p < 0,975 para que la serie seconsidere aleatoria. Finalmente calcula el p de los 229 pscalculados previamente, que debe cumplir con la mismadesigualdad.

C. El Sistema Numérico de Residuos

Los circuitos aritméticos, por ejemplo sumadores, basadosen la notación de complemento a 2, deben propagar lainformación de acarreo desde el bit menos significativo al mássignificativo, de manera que a medida que el número de éstosaumenta el rendimiento se degrada. El RNS [5], [6], [7] es unatécnica eficiente para superar este problema, dado que setrabaja sobre canales independientes sin necesidad deintercambio de información entre ellos. De esta manera lossistemas basados en el RNS están compuestos de una serie decanales pero, cada uno de ellos, con un número reducido de

bits. Los circuitos aritméticos de n bits se pueden transformar,



43




mediante el empleo del RNS, en O(n/log2(n)) canales de

log2(n) bits cada uno [8], Fig. 1. Esta característica lo hace

apropiado para la realización de un número importante de

aplicaciones en procesamiento digital de señales [9], [10],

[11].

Figura 1. Esquema general de un circuito RNS.

Un sistema basado en RNS se define mediante un conjuntode enteros relativamente primos entre si m1, m2..., m L,

llamados módulos. Su rango dinámico, el número decantidades distintas que se puede representar, es M = ∏mi

(i=1, 2, …, L), y de manera que cualquier entero 0 ≤ X < M se

representa mediante un conjunto de L residuos [ x1, x2, ..., x L],

con xi= X mod mi (i=1, 2, …, L). La principal ventaja del RNS

radica en su capacidad para realizar sumas, restas y

multiplicaciones a alta velocidad, debido a que la aritmética de

residuos se define sobre un anillo de enteros módulo M tal que:

( ) ( ) ( ) Limmód y x z M mód Y X Z iiii ,...,1=◊=↔◊= (1)

donde ◊ significa suma, resta o multiplicación en módulo. En

la ecuación (1) se puede apreciar el potencial del RNS, puestoque las operaciones en módulo M se computan en paralelo

sobre L canales independientes, Fig. 1. Debido a que no se

presentan dependencias de acarreo o de datos entre los

canales, el rendimiento total del sistema estará dado por la

velocidad de procesamiento o throughput de cada canal en

módulo mi. Aunque operaciones tales como división o

comparación son muy difíciles de realizar, esto no limita la

aplicación del RNS, de hecho el procesamiento digital de

señales se ha transformado en su campo de aplicación

preferido. De esta manera los algoritmos de multiplicación y

suma, muy comunes en DSP (procesamiento digital de

señales), pueden incrementar su velocidad de funcionamiento

mediante su implementación en RNS, como se ha demostradoen aplicaciones tales como transformadas discretas, filtrado

digital o procesamiento de imágenes [12], [13].

Por otro lado los fabricantes de dispositivos lógicos

programables ( Field Programmable Logic) proveen circuitos

integrados programables en campo para casi todas las

aplicaciones de la electrónica digital. Para la implementación

de circuitos aritméticos en el RNS los FPLs [14], [15] se han

convertido en una seria alternativa al empleo de circuitos

implementados con aritmética convencional [16]. Por esta

razón el circuito propuesto se ha implementado sobre una

FPGA FLEX10K20RC240-4 [17] de Atera Corporation.

II. GENERADOR PSEUDOALEATORIO PROPUESTO (RNS-

LCG)

El generador propuesto, denominado RNS-LCG ( Residue

Number System-Linear Congruential Generator ) se basa en el

Linear Congruential Generator (LCG). Sin embargo sudinámica es distinta. En efecto, no se trata de realizar un LCG

mediante RNS sino en usar el RNS para obtrener un generador

de números pseudoaleatorios con una dináminca

completamente distinta. Un LCG común responde a la

siguiente ecuación:

( ) M mód b xa x ii += −1 (2)

con a y b constantes y M el módulo que determina el rango

dinámico del sistema.La implementación circuital para los generadores RNS-

LCG Tipo I y II para n canales, cada uno de los cuales trabajacon h j bits, se muestra en Fig. 2. Cada canal es un pequeño

generador lineal congruente que realiza el cálculo de la Ec. 3.

En esta g j y m j son la raíz primitiva y el módulo de trabajo de

cada uno de los canales y residuo j, i es el residuo del canal j para la iteración i.

ji ji j ji j mmód bresiduo g residuo ,2,, +=−

(3)

Figura 2 Generadores RNS-LCG-I y RNS-LCG-II. Diagrama en bloques para

un canal genérico j, arriba. Esquemático total, abajo.



44




Para introducir un mayor desorden los canales se

perturban entre sí, de manera que el valor b de la Ec. (2) ya no

es una constante. En los generadores Tipo I (RNS-LCG-I), con

n igual al número de módulos, para el canal j en la iteración i

se tiene:

∑−=

≠

=

−=

1

01,,

nk

jk

k ik i j residuob

(4)

en tanto que para los Tipo II (RNS-LCG-II), siendo Θ laoperación or exclusiva bit a bit, será:

1,

1

0, −

−=

≠

=

Θ= ik

nk

jk k

i j residuosb(5)

Ahora bien, si se desea generar números de t bits se

presenta la siguiente dificultad. Para trabajar en el RNS se debe

elegir un conjunto m de módulos relativamente primos con lo

que se obtiene un rango dinámico M igual al producto de los

módulos, con 2t < M < 2t +1. Es decir que M no es una potenciaexacta de 2. Por lo tanto para trabajar con t bits se selecciona

un conjunto m que siempre excederá a 2t , lo que trae aparejado

el siguiente inconveniente. Aún cuando los números leídos en

decimal sean equiprobables, los 0s y 1s en cada posición no loserán. Este problema se ejemplifica en la TABLA I, para tener

M = 11 se necesita t = 4. Como se puede observar se tiene:

unos ycerosb

unos ycerosb

unos ycerosb

unos ycerosb

posiciónla Para

38

47

56

56

3

2

1

0

Los 0s y 1s no son equiprobables en cada posición, algo

indeseado en un buen GNPAs. Esto ocurre a pesar de que los

números del 0 al 10 tengan una distribución uniforme perfecta.

Para salvar esta situación se implementaron tres

estrategias, denominadas A, B y C.

TABLA I. Ejemplo para M = 11 y t = 4.

b3 b2 b1 b0

0 0 0 0 0

1 0 0 0 1

2 0 0 1 0

3 0 0 1 1

4 0 1 0 0

5 0 1 0 1

6 0 1 1 0

7 0 1 1 1

8 1 0 0 0

9 1 0 0 1

10 1 0 1 0

11 1 0 1 1

12 1 1 0 0

13 1 1 0 1

14 1 1 1 0

15 1 1 1 1

A. Estrategía A

Se toma un conjunto m tal que cumpla con 2t

< M < 2t+1

.

Para el caso, t = 32, se eligió m = 3, 11, 17, 19, 23, 29, 31, 37con lo que se obtiene M = 8.154.657.291 > 2

32=

4.294.967.296, es decir se puede representar el rango deseado.

Si el GNPA bajo estudio es bueno, cosa que se demostrará

mediante los test posteriores, se pueden tomar sólo aquellos

valores que sean menores que 232

y descartar el resto. Por

ejemplo, si el GNPA tiene distribución uniforme entre 0 y M –

1, la serie obtenida tendrá distribución uniforme entre 0 y 232

–

1. Trabajar de esta manera trae dos consecuencias, una

intuitiva y otra práctica. La intuitiva dice que si existiera alguna

estructura en la secuencia generada, al quitar algunos de sus

elementos, en este caso un número importante, casi uno de

cada dos, en la nueva serie esa estructura se desvanecerá o

atenuará. En el caso práctico se tiene el problema de que no se

entregará, debido al descarte, un número en cada iteración.

Esto puede subsanarse mediante el agregado de hardware, por

ejemplo una memoria FIFO, para la cual habrá de realizarse un

estudio a fin de determinar su capacidad y con el GNPA

funcionando a una frecuencia mayor que el circuito que los procesa, por ejemplo el que encripta.

B. Estrategia B

En este caso se trata de seleccionar un conjunto m que

cumpla con 2t < M < 2

t+1, pero de manera tal que la diferencia

M - 232

sea mínima, y puesto que el número de bits es 33

simplemente se descarta el más significativo. En el caso

ejemplificado en la TABLA I se obtendrán números

comprendidos entre 0 y 10 en la que al descartar el bit de

mayor peso se reducirá a una cadena de dígitos entre 0 y 7. Las

consecuencias son las siguientes. Se mejora el throughput, puesto que en cada iteración se obtiene un dato. Se empeora su

función distribución puesto que la combinación “000” es más

probable que la “111”, dado que la primera puede ocurrir si el

número presentado por el generador fue “0000” o “1000” en

tanto que la segunda de dará sólo cuando su salida sea “0111”.

Cuanto menor sea la diferencia entre M y 2t

menor será la

“perturbación” en la función distribución, supuesta uniforme.

Como ventaja tiene la característica de su sencillez, puesto que

ni siquiera es necesario un comparador, en efecto, de las tres

clases de circuitos desarrollados es el más sencillo en su

hardware. Para identificar los conjuntos de módulos que mejor se adaptan a esta estrategia se realizó un estudio exhaustivo con

módulos primos de hasta 7 bits es decir con el conjunto 3, 5,

7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67, 71,73, 79, 83, 89, 97, 101, 103, 107, 109, 113, 127. Se buscaron

aquellos conjuntos de módulos que superaran a 232

en no más

de un 0,01%. Es decir combinaciones de los 30 módulos

tomados de a 4, 5, 6, 7 y 8. Con 4 módulos no se puede llegar a

232

, en los restantes casos los mejores resultados fueron los que

se ilustran en la TABLA II.

Como se puede apreciar si se toma el primer conjunto, m =

3, 43, 47, 67, 97, 109, que es el grupo con el cual se trabajó,

la función distribución de probabilidad uniforme se verá

“alterada”, habrá números más probable que otros, pero serán



45




sólo el 0,000171% del total. De manera que se puede afirmar

que para la mayoría de los fines prácticos los 0s y 1s serán

prácticamente equiprobables en cada posición y que la función

densidad de probabilidad es uniforme.

TABLA II. Conjuntos de módulos que más se aproximan a 232 en exceso.

Exceso de 232

en porcentajem0 m1 m2 m3 m4 m5 m6 m7

0,000171% 3 43 47 67 97 109

0,000329% 5 11 13 17 53 59 113

0,001602% 3 7 13 37 47 83 109

0,001765% 5 11 17 23 29 71 97

0,001930% 11 23 53 59 61 89

0,002493% 5 11 13 19 61 71 73

0,002979% 3 11 13 23 67 73 89

0,003663% 7 31 41 43 103 109

0,003954% 3 7 13 37 53 71 113

0,004044% 13 17 37 61 79 109

0,004114% 13 19 53 59 67 83

0,005759% 3 7 13 19 71 107 109

0,005835% 3 7 11 13 29 31 37 43

0,006079% 3 5 7 53 73 97 109

0,006208% 3 17 23 31 41 43 67

0,006232% 11 17 31 79 83 113

0,006623% 5 37 47 67 73 101

0,006680% 7 17 37 89 97 113

0,007078% 3 7 19 31 67 71 73

0,008061% 13 23 47 53 73 79

0,008383% 17 19 41 47 67 103

0,009021% 3 19 59 89 113 127

0,009294% 11 23 43 67 71 83

0,009370% 3 5 7 13 23 41 47 71

0,009494% 3 7 19 29 43 89 97

0,009509% 5 13 19 23 37 61 67

C. Estrategia C

Este enfoque elimina las limitaciones que tienen las

estrategias A y B. Puesto que entrega un número en cada

iteración y la distribución es uniforme en toda su extensión.

Como en el caso B se toma un conjunto m tal que M sea

mayor que 232

pero cercano a él. Es decir que el generador

entregará números que requieren para su representación en

binario 33 bits. Los números entregados por el GNPA ingresanal bloque que se ilustra en Fig. 3, denominado circuito de

corrección. Como se puede apreciar, si el bit más significativo

entregado por el conversor RNS a binario es cero (a32 = 0), el

número entregado por el GNPA sigue sin cambios su camino

hasta la salida, Registro d. El Registro e periódicamente

actualiza su valor de la siguiente manera. Si un determinado

número de los bits menos significativos, por ejemplo 5, del

Registro c, son iguales a un valor predeterminado, elegido de

manera arbitraria, se almacena un nuevo valor. Esto significa

que estadísticamente su valor se modifica, en caso de tomar los

5 bits menos significativos de Registro c, con una frecuencia de

1 cada 32 iteraciones y el valor que se almacena es el del

Registro d. Se realimenta y almacena el contenido de Registro

d y no en el Registro c, de lo contrario los últimos bits de

Registro e serían siempre los mismos. La idea es que cuando el

conversor RNS a binario entregue un número tal que a32 = 1 los

bits a31… a0 sean reemplazados por alguna operación entre

éstos y el valor de Registro e, que se almacenó en algún

momento en el pasado. Estadísticamente tanto más alejados delvalor actual cuanto mayor sea el número de bits tomados de

Registro c para cargar al Registro e. La operación entre

Registro e y a31… a0 debe ser una relación sencilla en la que,

además, para cada bit del resultado los 0s y 1s sean

equiprobables. El elemento que cumple con esta condición es

la or exclusiva realizada bit a bit.Con este circuito de corrección se logran dos cosas.

Primero, en cada iteración se obtiene un número de la serie

pseudoaleatoria. Segundo, no se altera la distribución uniforme,

puesto que no existen valores privilegiados, como en la

estrategia denominada B, dado que para cada bit f 31 a f 0 los 0s y

1s son equiprobables.

Figura 3 Esquema de corrección para los circuitos tipo C.

III. TESTEO DE LOS GENERADORES PROPUESTOS

Para el testeo de los generadores propuestos se tomó m =

3, 11, 17, 19, 23, 29, 31, 37 para los algoritmos A, en tanto

que para los B y C m = 3, 43, 47, 67, 97, 109. Los

coeficientes que operan sobre los valores anteriores en cada

tipo de generador son las raíces primitivas g = 2, 2, 3, 2, 5, 2,3, 2 en el primer caso y g = 2, 3, 5, 2, 5, 6 en el segundo y

tercero.

A. Testeo básico

A fin de poder comparar los generadores propuestos con

otros ya testeados y conocidos se generaron series de 32 bits

con:



46




• Uniforme, computada por el MatLab 7.01.• MWCG, Multiply With Carry Generator, con el

programa Makewhat del paquete Diehard.• MTHR4, “the mother of all random number

generators” del paquete Diehard• SWBMWC, es una combinación de los generadores

Subtract With Borrow y Multiply With Carry, del paquete Diehard

Se realizaron los tests básicos de autocorrelación, análisisespectral y uniformidad y se compararon los resultados de lasseries generadas por los GNPAs propuestos con los decontraste. En todos los casos los resultados obtenidos sonindistinguibles de aquellos tomados como referencia.

TABLA III. Valores de p calculados por Diehard para 10 series para losgeneradores RNS-LCG-I y RNS-LCG-II tipo A.

RNS-LCG-I RNS-LCG-IISimulación

p p

0 0,407911 0,6076891 0,269137 0,071269

2 0,407911 0,1439743 0,176487 0,7896474 0,872657 0,5103815 0,181225 0,1104326 0,452626 0,2926167 0,429352 0,3124988 0,305565 0,1193209 0,048907 0,619312

TABLA IV. Valores de p calculados por Diehard para 10 series para losgeneradores RNS-LCG-I y RNS-LCG-II, tipo B.


p p

0 0,800747 0,316036

1 0,907225 0,2634292 0,326950 0,4733773 0,930700 0,6492564 0,087136 0,5419255 0,401577 0,9726506 0,949964 0,0276647 0,207195 0,1412598 0,038877 0,8850849 0,053990 0,855836

TABLA V. Valores de p calculados por Diehard para 10 series para losgeneradores RNS-LCG-I y RNS-LCG-II tipo C.


p p

0 0,101530 0,0844411 0,134149 0,4551882 0,676679 0,9745043 0,205915 0,5543484 0,361947 0,9177245 0,544443 0,6232396 0,148867 0,0310287 0,052875 0,2018488 0,658070 0,3205129 0,114893 0,457464

1 Copyright 1984-2004, The MathWorks Inc.

B. Testeo mediante die hard

Para realizar este test se generaron 10 series de 3.000.000de puntos, de 32 bits, para cada GNPA. En los generadoresClase A los archivos no tienen el mismo tamaño, puesto que eneste caso se descartan aquellos valores superiores 232, eltamaño de estos archivos está comprendido entre los 11 y los12 Mbytes. En los generadores Clase B el tamaño es en todoslos casos de 12 Mbytes. Y finalmente para los Clase C sontodos de 11.999.992 de bytes puesto que los primeros valoresdeben descartarse por el empleo del circuito de corrección. Losresultados obtenidos para las 300 series son los que semuestran en las siguientes tablas.

Como puede apreciarse las series pasan satisfactoriamenteeste test. Se puede aseverar entonces que todos los generadores

propuestos, en sus distintas variantes, pasan exitosamente unade las baterías de test más exigentes para la determinación dealeatoriedad sobre una serie de números.

IV. IMPLEMENTACIÓN EN LÓGICA PROGRAMABLE

Debido a que los circuitos sumadores y multiplicadores sonel núcleo de la mayor parte del hardware RNS, se realizó unamplio estudio sobre este tipo de operaciones en el sistemanumérico de residuos [18] y [19]. Esta investigación incluyódistintos tipos de sumadores y multiplicadores presentados endistintos trabajos [20], [21], [22], [23] y [24]. De los resultadosobtenidos en [18] y [19] se puede determinar que la frecuenciade operación es de 93,4 MHz cuando se emplea unaFLEX10K20RC240-4 y trabajando con 32 bits.

V. CONCLUSIONES

En el presente trabajo se presentaron una serie de

generadores de números pseudoaleatorios basados en elsistema numérico de residuos que pasan exitosamente, ademásde las estadísticas básicas, uno de los test de aleatoriedad másexigentes como es el die hard.

R EFERENCIAS [1] M. Naito, N. Tanaka, H. Okamoto, “Distinguishing chaos from random

fractal sequences by the comparison of forward predictions: utilizationof the difference in time reversal symetry of time series,” IEEE Proc. Of First International Conference on Knokledge-Based IntelligentElectronic System, 21-23 de mayo de1997, pp. 101-107.

[2] K. Ozdemir, S. Kilinc. S Ozoguz, “Random Number Generator DesignUsing Continuous-time Chaos,” IEEE Signal Processing,Communication and Applications Conference, 20-22 de abril de 2008. pp 1-4.

[3] M. Alioto, S. Bernardi, A. Fort , S. Rocchi and V. Vignoli, “On thesuitability of digital maps for integrated pseudo-RNGs,” Proc. ECCTDCracow, Poland, Sep. 2003, p. III/349.

[4] J. Savir “A new empirical test for the quality of random integer generators,” IEEE Trans. Comput., vol. C-32, pp. 960, Oct. 1983.

[5] Fred J. Taylor. “Residue arithmetic: A tutorial with examples,”Computer Magazine, IEEE Mayo. 1984. pp. 59-62.

[6] M. A. Bayoumi and G. A. Jullien, “A VLSI Implementation of ResidueAdders,” IEEE Transactions on Circuits and Systems, vol. 34, no. 3, pp.284-288, Mar. 1987.



47




[7] Fred J. Taylor. “Large moduli multipliers for signal procesing,” IEEETransactions on circuits and systems, Volumen CAS-28, Número 7,Julio 1981.

[8] Chin-Liang Wang. “IEEE Transactions on Circuits and Systems II:Analog and Digital Signal Processing,” Noviembre 1994, pp. 768-772.

[9] G. A. Jullien, Implementation of Multiplication, Modulo a Prime Number, with Applications to Number Theoretic Transforms, IEEETransactions on Computers, vol. C-29, no. 10, pp. 899-905, Oct. 1980.

[10] J. C. Smith and F. J. Taylor, A fault-tolerant GEQRNS processing

element for linear systolic array DSP application, IEEE Transactions onComputers, vol. 44, no. 9, pp. 1121-1130, Sep. 1995.

[11] J. Ramírez, P. G. Fernández, U. Meyer-Bäse, F. J. Taylor, A. García andA. Lloris, Design of Index-based RNS-DWT Architectures for CustomIC Designs, Proc. of 2001 IEEE Workshop on Signal ProcessingSystems SiPS’2001, pp. 70-79, Sep. 2001.

[12] W. A. Chren, “RNS-Based Enhancements for Direct Digital FrequencySynthesis,” IEEE Transactions on Circuits and Systems II, vol. 42. no. 8, pp. 516-524, Aug. 1995.

[13] J. Ramírez, A. García, P. G. Fernández, L., “Parrilla and A. Lloris, RNS-FPL Merged Architectures for Orthogonal DWT,” Electronics Letters,vol. 36, no. 14, pp. 1198-1199, Jul. 2000.

[14] N. S. Szabo and R. I. Tanaka, “Residue Arithmetic and Its Applicationsto Computer Technology,” McGraw-Hill, NY, 1967.

[15] M. A. Soderstrand, W. K. Jenkins, G. A. Jullien and F. J. Taylor,

“Residue Number System Arithmetic: Modern Applications in DigitalSignal Processing,” IEEE Press, 1986.

[16] U. Meyer-Bäse, A. Garcia and F. J. Taylor, “Implementation of aCommunications Channelizer using FPGAs and RNS Arithmetic Journalof VLSI Signal Processing,” vol. 28, no. 1/2, pp. 115-128, May 2001.

[17] Altera Corporation, “Cyclone II Handbook,”http://www.altera.com/literature/ds/cycloneIIhandbook.pdf, Nov. 2007.

[18] C. A. Gayoso, A. García, C. M. González, L. Arnone, J. C. García, E.Boemo, “Estudio sobre el diseño de sumadores en aritmética de residuosen lógica programable “, II Jornadas sobre Computación Reconfigurabley Aplicaciones. 10 al 20 de septiembre de 2002, Almuñecar, Granada,España. Anales pág 203. ISBN: 84-600-9928-8.

[19] C. A. Gayoso, C. González, M. Rabini, L. Arnone, “Estudio demultiplicadores en aritmética de residuos empleando lógica

programable”, Décimo Tercera Reunión de Trabajo en Procesamiento de laInformación y Control RPIC 2009, 16 al 18 de septiembre de 2009. Rosario,Argentina. Pág. 954-959. ISBN: 950-665-340-2.

[20] M. A. Bayoumi and G. A. Jullien, “A VLSI Implementation of ResidueAdders”, IEEE Transactions on Circuits and Systems, vol. 34, no. 3, pp.284-288, Mar. 1987.

[21] M Dugdale, “VLSI Implementation of Residue Adders based on BinaryAdders”, IEEE Transactions on Circuits and Systems II: Analog andDigital Signal Processing, vol. 39, no. 5, pp. 325-329, Mar. 1987.

[22] G. A. Jullien, “Implementation of Multiplication, Modulo a Prime Number, with Applications to Number Theoretic Transforms”, IEEETransactions on Computers, vol. C-29, no. 10, pp. 899-905, Oct. 1980.

[23] J. C. Smith and F. J. Taylor, “A fault-tolerant GEQRNS processingelement for linear systolic array DSP application”, IEEE Transactions onComputers, vol. 44, no. 9, pp. 1121-1130, Sep. 1995.

[24] J. Ramírez, P. G. Fernández, U. Meyer-Bäse, F. J. Taylor, A. García andA. Lloris, “Design of Index-based RNS-DWT Architectures for CustomIC Designs”, Proc. of 2001 IEEE Workshop on Signal ProcessingSystems SiPS’2001, pp. 70-79, Sep. 2001.



48




Implementación del algoritmo QRD-RLS sobre FPGA

Aplicación a un Sistema Cancelador de Ruido

Miguel Enrique Iglesias Martínez

Departamento de Investigación y DesarrolloCentro de Desarrollo de la Electrónica y la Automática, CDEA

Pinar del Río, Cuba


Abstract —En este artículo se describe una de lastantas aplicaciones de los algoritmos de filtradoadaptativo, en este caso la reducción o cancelación deruido en particular usando el algoritmo QRD-RLS,llevando a cabo su implementación sobre FPGA ytomando como eje fundamental del trabajo, la

flexibilidad de estos dispositivos y las ventajas de laaceleración de algoritmos por hardware endeterminadas aplicaciones.

Keywords- FPGA,QRD-RLS, algoritmos

I. INTRODUCCION

En algunos casos cuando se utilizan filtros digitales,

las señales o los sistemas pueden sufrir algunos cambios

con el tiempo, y la naturaleza exacta del cambio no es

predecible; en tales casos es altamente deseable diseñar

un filtro que pueda aprender del proceso mismo, demanera que se pueda adaptar para manejar la situación.

Para resolver muchos de estos problemas se propone el

uso de filtros adaptativos, cuya característica principal es

que estos pueden modificar sus parámetros durante la

operación con el fin de lograr un comportamiento

deseado [3].

Los sistemas adaptativos en la actualidad han

encontrado su lugar en muchas aplicaciones donde la

capacidad de aprendizaje del sistema es un factor

importante. Estas aplicaciones van desde el

modelamiento de plantas con propiedades desconocidas,

hasta el uso de estos sistemas en filtros capaces decancelar el ruido [2].

Existen varios algoritmos para lograr el cálculo de los

coeficientes en un sistema dado, los cuales varían en

complejidad. Entre los más sencillos se encuentra el

algoritmo Least Mean Square (LMS). Este algoritmo es

muy usado debido a su facilidad de implementación y

baja utilización de recursos computacionales.

Cuando el medio es altamente dinámico se requiere

de algoritmos que se adapten rápidamente a los cambios,

para estos casos el algoritmo LMS no brinda un buen

desempeño. Con esos propósitos se crearon algoritmos

de rápida respuesta, tales como el algoritmo RLS [2].

El cual su característica fundamental es que actualiza

los coeficientes del filtro en cada iteración, basado en el

lema de inversión de matrices, lo cual conlleva a un gran

consumo de recursos computacionales siendo esta sumayor desventaja, imposibilitando su uso en

aplicaciones de tiempo real en la mayoría de los sistemas

basados en microcontroladores y DSP los cuales no

cuentan con una arquitectura de procesamiento adecuada

para ello.

El presente trabajo muestra la implementación del

algoritmo RLS en su variante QRD-RLS sobre una

arquitectura reconfigurable para lo cual se lleva a cabo

primeramente el diseño del algoritmo en la herramientas

de simulación de sistemas Matlab, para luego obtener su

sintetización en código HDL mediante la plataforma de

trabajo de Xilinx, AccelDSP, y su posterior inclusión enun sistema para la reducción de ruido.

El trabajo se ha organizado de la siguiente manera:

La sección 2 explicará los conceptos básicos sobre

algoritmos adaptivos en general, además del algoritmo

QRD-RLS en particular. La sección 3 muestra la

arquitectura y la plataforma de diseño. La sección 4

muestra los resultados obtenidos a partir del diseño

planteado y su comparación con los obtenidos en

simulación, y finalmente las secciones 5 y 6 recogen las

conclusiones obtenidas de este trabajo y las referencias

consultadas.

II. ALGORITMOS ADAPTATIVOS

Un sistema adaptativo puede modelarse según lo

mostrado en la figura 1. Como se puede apreciar se tiene

una planta con características definidas, cuya salida es

ingresada al mecanismo adaptativo luego de ser restada

de una señal deseada, con lo que dicho mecanismo

puede calcular los coeficientes nuevos necesarios para

adaptar la respuesta de la planta a la señal deseada.



49




Figura 1 Diagrama de un sistema adaptativo

Las ecuaciones mostradas modelan el funcionamientode un sistema adaptativo [1].

)(*)()( t wt ut y = (1)

)()()( t yt d t e −= (2)

Donde u(t) es la señal de entrada, y(t) es la señal desalida ya filtrada, d(t) es la señal deseada a la salida ye(t) es el error entre d(t) e y(t). En este caso, la señal deentrada u(n) pasa a la Planta que contiene loscoeficientes w(n) (un filtro FIR) y devuelve una señal

y(t) cuyo resultado se muestra en (1). En el momentoque la planta entrega el resultado y(t), esta resta a unaseñal d(t) y produce una señal de error e(t) cuyoresultado se muestra en la ecuación (2), la cual es el

parámetro que le permite saber al mecanismo adaptivo

que tan “lejos” se encuentra la planta de tener unarespuesta similar a la señal deseada d(t). Conjuntamentecon la señal u(t) se calculan los nuevos coeficientes w(t )

para la planta usando un Mecanismo Adaptativo deControl de Coeficientes [1].

A. Algoritmo QRD-RLS

Dentro de los algoritmos adaptativos existentes elRLS (Recursive Least Square), es generalmente

preferido por su rápida convergencia. El método basadoen mínimos cuadrados intenta encontrar un juego de

coeficientes que minimicen la suma del error cuadrático.El cálculo directo del nuevo vector de coeficientesinvolucra la inversión de matrices, lo cual esgeneralmente indeseado en las implementaciones dehardware debido al alto consumo de recursos. Ladescomposición de matrices basada en esquemas demínimos cuadrados tales como, SVD (Singular ValueDescomposition) y QR evitan explícitamente lainversión de matrices, son más robustas y más asequiblesu implementación en hardware [5].

El método de descomposición QR comienza desde lamatriz de datos usando transformación unitaria. Para unamatriz Q(n) unitaria dada, la función de coste puede ser expresada como:

22/12/1

22/1

||)()()()()()()(||)(

||)()()(||)(

nwnnnQnd nnQn E

nennQn E

ΑΑ−Α=

Α=

(3)

Para el problema de minimización definido por lafunción de coste, la matriz unitaria Q(n) es elegida paratriangular la matriz de datos de manera exponencial

ponderada tal que:

⎥⎦

⎤⎢⎣

⎡=ΑΑ

0

)()()()( 2/1

n RnnnQ (4)

Donde R(n) es una matriz triangular superior dedimensión KxK y 0 es una matriz nula de dimensión (n-K)xK. El vector de señal deseado, después de estar transformado, esta definido por:

⎥⎦

⎤⎢⎣

⎡=Α

)(

)()()()( 2/1

nv

n pnd nnQ (5)

Donde p(n) es un vector de Kx1 elementos y v(n) es unvector de (n-K) x1 elementos, luego se puede reescribir la función de coste de la siguiente manera:

2||)(0

)()()(||)( nwn R

nvn pn E ⎥

⎦⎤⎢

⎣⎡−⎥

⎦⎤⎢

⎣⎡=

2||)(

)()()(|| ⎥

⎦

⎤⎢⎣

⎡ −=

nv

nwn Rn p (6) Es obvio que la estimación de mínimos cuadrados parael vector de pesos debe satisfacer que:

)()()(

10)()()(

1'

'

n pn Rnw

xnwn Rn pK

−=

=− (7)

La matriz unitaria Q(n), la matriz triangular superior R(n), y el vector p(n) , pueden ser calculadosrecursivamente usando:

⎢⎢⎢

⎣

⎡

−−

xK

xK K n

n R

10

)1(0

)(

⎥⎥⎥

⎦

⎤

−−

)(

1)1(0

)(

n

xK n

n p

α



50




⎢⎢⎢

⎣

⎡

−−

−

=

)(

)1(0

)1(

)(

2/1

'

nu

xK K n

n R

nQ

T

λ

⎥⎥⎥

⎦

⎤

−−

−

)(

1)1(0

)1(2/1

nd

xK n

n pλ

⎢⎣

⎡ −=

0

)1()()( '

nQnQnQ

⎥⎦

⎤

1

0 (8)

Por lo tanto el vector de coeficientes óptimos puedeser obtenido. Pero en algunas aplicaciones tales comoreducción de ruido y predicción linear e(n), es la señal desalida. Desarrollando la ecuación anterior podemosobtener e(n) directamente sin extraer el vector de pesosexplícitamente. Este resultado puede resumirse en lasiguiente ecuación:

⎢⎣

⎡

xK

n R

10

)(

)(

)(

n

n p

α

⎥⎥⎦

⎤−

*))((

)()(

2/1

1

n

nun R

γ (9)

)('' nQ=⎢⎢⎣

⎡ −)(

)1(2/1

nu

n RT

λ

)(

)1(2/1

nd

n p −λ ⎥

⎦⎤

1

0 1Kx (10)

La descomposición QR se puede realizar mediante la

utilización de rotaciones de Givens [6], encargadas de

diagonalizar la matriz cada vez que un nuevo dato entra,

con un coste computacional muy bajo.

III. ARQUITECTURA Y PLATAFORMA DE DISEÑO

A partir de lo mencionado anteriormente se inicia el

diseño y simulación del algoritmo QRD-RLS según los parámetros de señal para los cuales el sistema deberáresponder de acuerdo a la características de ruido

presente en la señal útil, para lo cual se utiliza como señalinterferente ruido blanco gaussiano de valor medio cero yvarianza constante, y como señal útil de prueba, un tonosinusoidal de frecuencia 1KHz muestreado a 16 KHz.Como se muestra en la figura 2.

Figura 2 Señales utilizadas en la Aplicación

El diagrama de la arquitectura propuesta se observa acontinuación en la figura 3 donde se puede apreciar laforma clásica de un sistema adaptativo utilizado paracancelar ruido, donde en este caso, se toma comoreferencia del sistema ,la señal contaminada( d(n)+N(n)) , y como señal de entrada al filtro, una muestra de ruido

correlacionado( N’(n)) con el presente en la señal,obteniendo como resultado a la salida del filtro unaréplica del ruido contaminante de la señal útil , lo que alefectuar la diferencia entre estas dos señales , se obtienecomo salida la señal útil inicial, correspondiente al error entre la referencia y la salida del filtro. La diferencia deeste sistema con respecto a las demás arquitecturas desistemas adaptativos es que la salida del mismo es laseñal de error [2].

Figura 3 Filtro Adaptativo como reductor de ruido

La elección de la estructura de cancelación adaptativamostrada en la figura 3 y usada para la verificación delalgoritmo QRD-RLS pudiera no ser la mas óptima encuanto a la cantidad de información que necesita el

sistema para adaptarse, pudiendo usarse otro tipo deestructura de cancelación de ruido, como la predictiva, lacual no requiere el conocimiento previo de la naturalezadel ruido aditivo a la señal, ni tampoco que el mismodeba estar correlacionado. Sin embargo, esto puedeimplicar un aumento en el consumo de recursos hardwaredel algoritmo QRD-RLS imposibilitando la fiabilidad desu sinterización sobre una arquitectura reconfigurable.

Que el ruido que se toma como muestra de entrada alfiltro, este correlacionado con el incidente en la señal útil,implica mejores resultados y un menor número deoperaciones para la convergencia del algoritmo, lo cual

se traduce en un ahorro de recursos computacionales,siendo este último punto, y la síntesis del algoritmoQRD-RLS, los objetivos fundamentales del trabajo.

A. AccelDSP

AccelDSP es una herramienta de síntesis

proporcionada por Xilinx, la cual permite transformar un

diseño en punto flotante desarrollado en Matlab, en un

módulo hardware, que puede ser implementado en un

FPGA.



51




Posee una interfaz de usuario fácil de usar que

controla un ambiente integrado con otras herramientas

de diseño, tales como: Matlab, Xilinx ISE, System

Generator y otras como simuladores de código HDL y

sintetizadores lógicos [4].

B. Capacidades de AccelDSP

AccelDSP proporciona las siguientes capacidades:• Lee y analiza un diseño en punto flotante

desarrollado en Matlab.

• Crea automáticamente el diseño equivalente en

punto fijo.

• Invoca a Matlab para simular y verificar el

diseño tanto en punto fijo como en punto

flotante.

• Crea un modelo HDL sintetizable con su fichero

de simulación correspondiente (Testbench) [4].

C. Flujo de diseño AccelDSP

En la figura 4 se puede observar el flujo de diseño deAccelDSP cuando se utiliza Xilinx System Generator

como herramienta de diseño, para adicionar el

sistema generado como una librería más y reutilizar

esta en posteriores diseños, aunque se puede emplear

también Xilinx ISE .

Figura 4 Flujo de Diseño AccelDSP-XSG [4].

Una vez generado el bloque del algoritmo QRD-RLSa través de la herramienta de síntesis AccelDSP yexportado a System Generator, se adiciona este a unsistema diseñado para comprobar su funcionamiento. Elsistema de comprobación del algoritmo se diseñó enSystem Generator, mediante el cual se generan, tanto laseñal útil correspondiente al tono sinusoidal, como el

ruido blanco gaussiano. Posteriormente la señal obtenida pasa a través de un conversor DAC para ser visualizada ycomparada con los resultados obtenidos en la simulación.

Todo el sistema fue implementado sobre laarquitectura FPGA SPARTAN-3AN, la cual posee 700K compuertas y 20 multiplicadores embebidos, de loscuales solo se usa el 60 % de los mismo. Teniendo en

cuenta que este es un punto crítico a la hora deimplementar el algoritmo, es este un buen resultado conrespecto al consumo de recursos del sistema. La figura 5muestra el diagrama completo del sistema.

Figura 5 Arquitectura del Sistema en SystemGenerator

IV. RESULTADOS

En orden de comparar los resultados obtenidos en lasimulación del sistema cancelador de ruido, con losmostrados en la implementación del algoritmo QRD-RLS, se presentan a continuación una serie de gráficas

para la comparación de los mismos, la cuales detallan laeficiencia del algoritmo en tareas de reducción ocancelación de ruido, utilizando como secuencia deadaptación, una señal de referencia.

Figura 6 Salida del sistema y comportamiento defrecuencias

Como se puede apreciar en la figura anterior la salidadel sistema generada en el modelo de punto flotante



52




descrito en Matlab y la salida del modelo punto fijogenerado por la herramienta coinciden, así mismo elcomportamiento de frecuencias, lo cual demuestra laconvergencia de los coeficientes del filtro a la atenuaciónde las frecuencias fuera del rango dinámico de señal útil.

A continuación se puede ver la comparación entre laseñal de entrada contaminada y salida del sistema, con lo

cual se muestra la coincidencia del modelo desimulación en Matlab con el modelo real implementadosobre el FPGA.

Figura 7 Entrada contaminada y señal a la salida delsistema en System Generator

En cuanto a los recursos utilizados en laimplementación del algoritmo QRD-RLS, la tabla 1muestra el consumo que originó la implementación delmismo. Cabe destacar que el procesamiento de los datosmediante el algoritmo QRD-RLS se hizo tomando comolongitud máxima, 24 bits, forzando el diseño del mismo a

esta longitud de datos, teniendo en cuenta los recursos deldispositivo con el cual se llevó a cabo la implementación,y sin comprometer la eficiencia del algoritmo en cuanto a

presentar a su salida, un resultado óptimo.

Tabla 1 Consumo de Recursos del Algoritmo

QRD-RLS

CONCLUSIONES

El algoritmo QRD-RLS es una excelente manera de

filtrar una señal cualquiera usando una señal de

referencia d(t) como modelo, pero, lamentablemente, su

implementación se traduce en un costo computacional

elevado, aunque se pueden llegar a diseños como el

mostrado aquí, donde se prefije la longitud de los datos

sin comprometer los resultados esperados, lo que puede

representar un ahorro de recursos y área de trabajo , si

este representa un punto clave en la implementación, ya

que los mayores problemas de este algoritmo, son los

cálculos de la matriz de autocorrelación inversa de la

señal de entrada P(n), la cual es de NxN, y del vector de

ganancia de Kalman K(n). Es importante notar que dado

que las operaciones involucradas son operaciones entre

vectores y matrices, significa que existe un gran

consumo de elementos dedicados, en este caso

multiplicadores como caso crítico en el diseño. No

obstante se logró sintetizar el algoritmo QRD-RLS sobreuna arquitectura paralela y reconfigurable lo que

posibilita su reutilización en posteriores diseños.

REFERENCIAS

[1] Jorge Benavides Aspiazu, Walter Calienes Bartraand Carlos Silva Cárdenas,”Diseño de unaarquitectura para la implementacion de un filtroadaptativo rls sobre un fpga”, XV WorkshopIberchip, Buenos Aires - Argentina,Marzo 2009.

[2] Saeed V. Vaseghi, Advanced Digital SignalProcessing and Noise Reduction, Third Edition,2006, John Wiley & Sons Ltd.

[3] S. Haykin,”Adaptive Filter Theory”, 3rd ed. Upper Saddle River, NJ:Prentice-Hall, 1994.

[4] AccelDSP Synthesis Tool User Guide obtenido de:http://www.xilinx.com/acceldsp_user.pdf .

[5] Implementation of CORDIC-Based QRD-RLSAlgorithm on Altera Stratix FPGA with Embedded

Nios Soft Processor Technology obtenido de:www.altera.com/literature/wp/wp_qrd.pdf

[6] B. Yang and J. F. Bohme, “Rotation-based RLSalgorithms: Unified derivations, numerical

properties, and parallel implementations,” IEEE Trans. Signal Processing, vol. 40, pp. 1151–1167,May 1992.



53




Diseno de un Sistema para el Control de Posicion

de un Motor DC Basado en FPGA

Luis F. Castano Londono, Gustavo A. Osorio Londono

Grupo en Percepcion y Control InteligenteDepartamento de Ingenierıa Electrica, Electronica y Computacion

Universidad Nacional de Colombia - Sede Manizales

Resumen—En este artıculo se presenta el dise ˜ no e imple-mentacion de un sistema para el control de posicion de un motorDC basado en FPGA. Se describen los modulos implementadosen la FPGA que se encargan de la generaci on de la trayectoriade arranque, la lectura de la se ˜ nal del encoder, el controlador PIy el generador de la se ˜ nal de control PWM. El sistema de controles implementado en la tarjeta DE3 de Terasic Technologies Inc.usando VHDL y diagramas de bloques bajo el entorno Quartus II de Altera Corporation. Se presentan simulaciones realizadas con

Simulink y resultados experimentales del sistema desarrollado. Palabras Clave—Servocontrol, PID, VHDL, FPGA

I. INTRODUCCI ON

Actualmente existen varias aplicaciones y herramientas para

la implementacion de servocontroladores digitales ya sea con

el uso de microcontroladores como en [2] [11], DSP como en

[1] [5] [10] [12] y FPGA como en [4] [7]. Este tipo de sistemas

pueden ser empleados para control de posicion en impresoras,

plotters y escaners, ofreciendo multiples ventajas con relacion

a los sistemas que emplean motores de paso[11]. Tambien se

emplean en aplicaciones de robotica [8] y automatizacion[1].

La mayorıa de estos sistemas son implementados con eluso de microcontroladores estandar, microcontroladores de

16 bits de gama alta o DSP cuando se desea incrementar

el desempeno[11]. La seleccion del tipo de dispositivo para

la implementacion del servocontrolador depende de los re-

querimientos del sistema y las caracterısticas de la aplicacion

deseada. Generalmente los criterios de seleccion se basan en

la relacion costo-rendimiento y llevan a una decision entre

microcontroladores estandar y DSP [10].

Fig. 1. Esquema basico del sistema de control de posicion del motor DC

Los microcontroladores estandar son los mas adecuados

para aplicaciones con requerimientos relativamente bajos de

control en tiempo real y que ademas requieren desarrollar

otras tareas como el control de interfaces de usuario. Los

DSP son empleados cuando los requerimientos del algoritmo

de control en tiempo real son mayores [10]. Tanto para

aplicaciones con microcontroladores como con DSP se

emplean circuitos externos para el manejo de algunas tareas

de la aplicacion. Particularmente en el caso de aplicaciones

con DSP se emplean CPLD o FPGA como en [1] y [5].

En la ultima decada la implementacion sistemas de servo-

control sobre FPGA se ha convertido en la solucion alternativa,

dado que este tipo de circuitos proporcionan bajo consumo

de potencia y mayor estabilidad en el desempeno [6] [7].

Al no depender de una arquitectura especıfica los FPGA

permiten el diseno de sistemas flexibles que funcionan con

una mayor velocidad de procesamiento debido a su capacidad

de concurrencia. Por otra parte hoy en dıa las herramientas

de diseno, simulacion y sıntesis sobre FPGA ofrecen variadas

prestaciones para el diseno e implementacion de todo tipo desistemas embebidos de bajo costo. En este artıculo se presenta

la implementacion de un servocontrolador para un motor DC

basado en FPGA. En la seccion II se describen cada uno

de los componentes del sistema que fueron desarrollados en

VHDL y con diagramas de bloques bajo el entorno Quartus

II e implementados en la tarjeta DE3. En la seccion III

se presentan simulaciones y resultados experimentales del

sistema desarrollado. Finalmente se presentan las conclusiones

en la seccion IV.



54




II. IMPLEMENTACION DEL SISTEMA DE CONTROL

El esquema basico del servocontrol desarrollado se muestra

en Fig. 1. El sistema a controlar es un motor DC de im an

permanente instrumentado con un encoder incremental de 400

PPR (pulsos por revolucion). La etapa de potencia consiste

en un circuito inversor que permite el manejo de la corriente

y el control del sentido de giro del motor. En la FPGA son

implementados los modulos que se encargan de la generacionde la trayectoria para el arranque, la lectura de la senal del

encoder, el controlador PI y el generador de la senal de control

PWM. El diagrama de bloques del sistema de control realizado

en Quartus II se muestra en Fig. 2.

A. Generaci´ on de la funci´ on de arranque del motor

Para el arranque del motor se debe tener en cuenta los

efectos de la resistencia por friccion seca y el transitorio de la

corriente de armadura. El voltaje aplicado en el devanado debe

ser suficiente para que el torque del motor supere el torque

resistivo debido a la friccion seca. Por otra parte cuando se

aplica una referencia de tipo escalon la corriente de arranque esmuy alta debido a la inductancia de armadura. Esta situacion

puede ocasionar desgaste en los componentes mecanicos y

electricos del motor debido a los movimientos abruptos y la

disipacion de potencia. Un metodo para evitar la sobrecorriente

en el transitorio es el arranque progresivo por medio de una

curva de tension. La generacion de esta curva se realiza a partir

de una funcion de velocidad de forma trapezoidal como la que

se muestra en la parte superior de Fig. 3. La implementaci on

de esta funcion se realiza con base en la expresion que se

muestra en (1).

Fig. 2. Diagrama de bloques del sistema de control de posicion

ωref =

4ωmaxt/τ, si t ≤ τ/4

ωmax, si τ/4 ≤ t ≤ 3τ/4

−4ωmaxt/τ + 4ωmax, si t ≥ 3τ/4

(1)

Las caracter´ısticas de este trapecio est

án determinadas porla velocidad maxima (ωmax) y la posicion final (θf ) que se

alcanza en el tiempo (τ ). El valor de τ se define como tf − tiy es calculado como θf /ωmax.

Fig. 3. Funciones de velocidad y posicion para el arranque del motor. Elvalor de tf − ti determina el tiempo τ para el cual se desea que el motoralcance la posicion final θf .



55




Esta funcion de velocidad se integra para obtener una

funcion de referencia de posicion como la que se muestra en

la parte inferior de Fig. 3. El esquema para la implementacion

del generador de la funcion de arranque se muestra en Fig. 4.

Fig. 4. Esquema del generador de funciones de las trayectorias de velocidady posicion para el arranque del motor

B. Medida de la posici´ on

La medida de la posicion es realizada con un encoder

magnetico incremental de 400 PPR acoplado al rotor del

motor. Este encoder entrega dos senales en cuadratura como

se muestra en Fig. 5. Estas senales permiten detectar el

desplazamiento y el sentido de giro del rotor. Cuando el rotor

gira en el sentido de las agujas del reloj la fase A se encuentra

adelantada 90 a la fase B como se muestra en Fig. 5(a).

Cuando el rotor gira en el sentido contrario a las agujas del

reloj la fase B se encuentra adelantada 90 a la fase A como

se muestra en Fig. 5(b).

(a) Fase A adenlatada 90 a la fase B

(b) Fase B adenlatada 90 a la fase A

Fig. 5. Senales del encoder

La deteccion del sentido de giro a partir de las senales del

encoder se realiza a traves de un circuito secuencial cuyo

diagrama de transicion de estados se muestra en Fig. 6. El

anillo interno es la secuencia para la deteccion de la direccion

del giro en el sentido de las agujas del reloj, siendo la salida 0.

El anillo externo es la secuencia para la deteccion la direccion

del giro en el sentido contrario a las agujas del reloj, siendo la

salida 1. Las transiciones entre los estados del anillo interno

al externo o del anillo externo al interno permiten la deteccion

del cambio de sentido de giro. El circuito planteado de esta

forma se puede implementar de manera sencilla a traves de

una descripcion comportamental algorıtmica en VHDL.

Fig. 6. Diagrama de transicion de estados del circuito de deteccion de sentidode giro del motor

La medida de la posicion se realiza con un contador de

pulsos ascendente/descendente de n bits. La senal de reloj

para este contador se obtiene de la xor entre las dos fases del

encoder dando lugar a una medida de 800 ppr. Este contadorse incrementa o decrementa en funcion del desplazamiento y

el sentido de giro del rotor. El contador esta disenado para dar

una medida tanto positiva como negativa del desplazamiento

del rotor con relacion a su posicion inicial cuando se enciende

el circuito. Para garantizar una lectura correcta de las senales

del encoder tanto para la deteccion del sentido de giro como

para determinar la posicion, se implementa un circuito antire-

bote como parte de este modulo, ya que la duracion de un

pulso para cada una de estas senales es de 500µs cuando el

motor trabaja a 2000 rpm.

C. Controlador proporcional integral

El control basado en el esquema PID convencional es

ampliamente usado debido a su simplicidad y desempeno [6]

[8]. Algunos sistemas de servocontrol poseen tres lazos de

control (posicion, velocidad y corriente) permitiendo un mejor

comportamiento de las caracterısticas estaticas y dinamicas del

sistema [3] [4] [9]. El lazo de posicion es el principal para el

servocontrol. El lazo de velocidad limita las fluctuaciones de

velocidad para mejorar la respuesta en el transitorio y frente

a perturbaciones en la carga. El lazo de corriente limita la

interferencia de la corriente de armadura y la corriente maxima

para proteger el motor [4] [9]. Tambien se pueden encontrar



56




sistemas basados en lazos de posicion y velocidad como

en [2]. El sistema implementado posee unicamente un lazo

de posicion con un controlador PI, siendo los controladores

proporcional e integral los mas comunes para los lazos de

posicion, velocidad y corriente en este tipo de sistemas de

control. La salida del controlador PI se calcula como se

muestra en (2) y determina el valor del porcentaje de ciclo util

de la senal de control PWM tal como se muestra en Fig. 8.

u(t) = sat

K p e(t) + K i sat

e(t) dt

(2)

El control proporcional es elaborado con un circuito mul-

tiplicador generado con la herramienta MegaWizard Plug-In

Manager del Quartus II. El control integral es implementado

con base en (3) y el diagrama de bloques mostrado en Fig. 7.

El valor de la constante h esta determinado por la frecuencia

de reloj del circuito de integracion (e.g. h = 50µs para

f clk = 20KHz ). Los valores de K p y K i son definidos a

traves de entradas externas.

e(t) dt = h

2

(e(k) + e(k − 1)) (3)

Fig. 7. Diagrama de bloques para la implementacion del control integral

D. Generador de la se˜ nal de control PWM

El generador de la senal PWM se basa en el diagrama

de bloques mostrado en Fig. 8. Este modulo consta de un

contador, un circuito aritmetico, un comparador y un demulti-

plexor. El contador permite generar una senal diente de sierra

de 20 KHz. El circuito aritmetico se emplea para el calculo

del valor de referencia que es comparado con la senal diente

de sierra para generar la senal PWM. El circuito demultiplexor

se encarga de llevar la senal de control PWM a las entradas

del puente inversor segun el signo de la senal de control para

determinar el sentido de giro del motor.

Fig. 8. Diagrama de bloques para la implementacion del generador de lasenal de control PWM

E. Descripci´ on del sistema f ısico

El modelo de un motor DC de iman permanente puede ser

representado por las expresiones mostradas en (4a)-(4d). Estas

ecuaciones son obtenidas de los sistemas electrico y mecanico

mostrados en el circuito equivalente de Fig. 9.

E a = Ra ia + La

dia

dt + ea (4a)

τ m = J d2θ

dt+ B

dθ

dt(4b)

τ m = K t ia (4c)

ea = K e ω (4d)

Fig. 9. Circuito equivalente del motor DC de iman permanente

La representacion en el espacio de estados del modelo del

motor se muestra en (5).

x =

x1

x2

x3

=

0 1 0

0 a b0 c d

x1

x2

x3

+

0

0f

u

(5)

y =

1 0 0 x1

x2

x3

donde a = −B/J, b = K t/J, c = −K e/La, d = −Ra/La

y f = 1/La, estan definidos por los parametros del motor. Los

valores de los parametros obtenidos con la identificacion del

motor son: B = 1.2e−6Nms/rad, K t = 14.5e−6Nm/A,

J = 0.5e−6N ms2/rad, K e = 0.35V s/rad, Ra = 3.3 Ω y

La = 36 µ H .

III. SIMULACION Y RESULTADOS EXPERIMENTALES

Las simulaciones del sistema implementado son realizadas

en MATLAB usando Simulink con base en el modelo desarrol-

lado en la seccion II-E. Para obtener los datos experimentales

se emplea el Signal Tap II Logic Analyzer del Quartus II. Con

el uso de esta herramienta para cada experimento se toman

65536 muestras de cada una de las variables que se desea

medir.



57




A. Experimento A: respuesta en lazo abierto

Las pruebas para observar la respuesta del motor en lazo

abierto se realizaron para valores de E a entre 0.5V y 24V. En

Fig. 10 se muestra la respuesta del sistema en lazo abierto para

una valor de ea de 4V. La lınea continua muestra la respuesta

de la simulacion y la lınea punteada corresponde a los valores

experimentales medidos con el encoder.

Fig. 10. Respuesta del sistema en lazo abierto a un escalon de 4V. La lıneacontinua muestra la respuesta de la simulacion y la lınea punteada correspondea los valores experimentales medidos con el encoder.

B. Experimento B: respuesta en lazo cerrado

En la parte superior de Fig. 11 se muestra la simulacion

para la respuesta del sistema en lazo cerrado con K p = 20,

K i = 4 y una alimentacion para circuito de potencia de 15 V.

La lınea solida corresponde a la referencia y la l ınea punteada

corresponde a la respuesta del motor. En la parte inferior

de Fig. 11 se muestra la respuesta experimental del sistemaen lazo cerrado para los mismos valores de K p y K i. La

lınea continua corresponde a la referencia y la lınea punteada

corresponde a la respuesta del motor. En Fig. 12 se muestran

las senales de error. La lınea continua corresponde a los

resultados de la simulacion y la lınea discontinua corresponde

a los datos experimentales. Los valores de K p y K i se

escogieron experimentalmente de tal forma que la respuesta

del sistema fuera estable.

IV. CONCLUSIONES

En este artıculo se presenta el diseno e implementacion

del control de posicion para un motor DC basado en FPGA.

El diseno es realizado con el uso de VHDL y diagramas de

bloques e implementado en la FPGA. Debido a la modularidad

del diseno y la independencia de una arquitectura especıfica

es posible implementar diferentes topologıas basadas en el

esquema convencional PID. En este artıculo se realiza la

descripcion y se presentan los resultados del sistema con un

controlador PI aplicado a un lazo de posicion.

La comparacion entre los resultados de la simulacion y

los datos experimentales permiten validar el funcionamiento

del sistema desarrollado tanto en lazo abierto como en lazo

Fig. 11. Respuesta del sistema en lazo cerrado con controlador PI. K p =

20, K i = 4. El grafico superior muestra los resultados de la simulaciony el grafico inferior muestra los resultados experimentales. La lınea solidacorresponde a la referencia y la lınea punteada corresponde a la respuesta d elmotor.

Fig. 12. Senal de error del sistema en lazo cerrado con controlador PI.K p = 20, K p = 4. La lınea continua corresponde a los resultados de lasimulacion y la lınea discontinua corresponde a los datos experimentales.

cerrado. La diferencia en el comportamiento de la senal de

error para los resultados de la simulacion y los resultados

experimentales se relaciona principalmente con el modelado

del motor. Sin embargo se puede observar un comportamiento

bastante aproximado del sistema tanto en el transitorio como

en estado estacionario.

Las caracterısticas del sistema desarrollado y las herramien-

tas empleadas permitiran realizar el estudio de la dinamica

del sistema aplicando otras topologıas y esquemas de control.

Existe principal interes en la implementacion de controladores

basados en esquemas diferentes al PID (ie. controladores

basados en la estrategia zero average dynamics (ZAD)), en

los cuales resulta fundamental la capacidad de concurrencia y

velocidad que brindan los FPGA.



58




REFERENCIAS

[1] X. Zhou, L. Sundong, W. Li, Implementation of a High PerformanceStand-Alone Motion Controller , in Proceedings of International Confer-ence on Advanced Intelligent Mechatronics, 2009. IEEE/ASME 2009.,pp.269-273, 14-17 July. 2009

[2] H. Zhou, DC Servo Motor PID Control in Mobile Robots with Embedded DSP, in Proceedings of the International Conference on IntelligentComputation Technology and Automation, 2008. ICICTA 2008., vol.1,pp.332-336, 20-22 Oct. 2008

[3] K. Yu, H. Guo, D. Wang, L. Li, Design of position servo-systemof BLDCM based on frequency domain method , in Proceedings of International Conference on Electrical Machines and Systems, 2008.ICEMS 2008., pp.1612-1617, 17-20 Oct. 2008

[4] T. Ya, Z. Runjing, H. Xiaoxia, Application of FPGA in Direct Current Motor Servo System, in Proceedings of the 27 Chinese Control Confer-ence. CCC 2008., pp.261-265, 16-18 July 2008

[5] J. Xu, B. You, L. Ma, Research and development of DSP based servomotion controller , in Proceedings of the 7th World Congress on IntelligentControl and Automation, 2008. WCICA 2008., pp.7720-7725, 25-27 June2008

[6] J. Kim, H. Jeon, S. Jung, Hardware implementation of nonlinear PIDcontroller with FPGA based on floating point operation for 6-DOF manipulator robot arm, in Proceedings of the International Conferenceon Control, Automation and Systems, 2007. ICCAS ’07., pp.1066-1071,17-20 Oct. 2007

[7] Y. F. Chan, M. Moallem, W. Wang, Design and Implementation of Mod-ular FPGA-Based PID Controllers, in IEEE Transactions on IndustrialElectronics, vol.54, no.4, pp.1898-1906, Aug. 2007

[8] J. Lima, R. Menotti, J. M. P.Cardoso, E. Marques, A Methodologyto Design FPGA-based PID Controllers, in Proceedings of the IEEEInternational Conference on Systems, Man and Cybernetics, 2006. SMC’06., vol.3, pp.2577-2583, 8-11 Oct. 2006

[9] Z. Runjing, D. Yu, Y. Weiting, Application of Fuzzy-PI Controller with Feedforward Control in Direct Current Motor Servo System, inProceedings of the International Conference on Neural Networks andBrain, 2005. ICNN &B ’05., vol.2, pp.1262-1267, 13-15 Oct. 2005

[10] Freescale Semiconductor Inc., D. Wilson, Aplication Note 1213:16-Bit DSP Servo Control With the MC68HC16Z1 [en l´ ınea],http://cache.freescale.com/files/microcontrollers/doc/app note/AN1213.pdf

[11] Microchip Technology Inc., T. Bucella, Aplication Note532: Servo Control of a DC-Brush Motor [en l´ ınea],http://ww1.microchip.com/downloads/en/AppNotes/00532c.pdf

[12] G. Qingding, W. Limei, L. Ruifu, Completely digital PMSM servosystem based on new self-tuning PID algorithm and DSP, in Proceedingsof The IEEE International Conference on Industrial Technology, 1996.ICIT ’96, pp.71-75, 2-6 Dec. 1996



59




Implementación del procesador Cortex-M0

DesignStart en una FPGA de rango bajo

Pedro Ignacio Martos y Fabricio Baglivo

Laboratorio de Sistemas Embebidos

Facultad de Ingeniería - UBABuenos Aires, Argentina

[email protected] / [email protected]

Abstract — Los procesadores de la línea CortexTM-M de ARM ltd.

están orientados a la implementación de microcontroladores ydispositivos mixtos (mixed signal) de bajo costo y bajo consumo;tanto como dispositivos en silicio como softcores o hardblocks enFPGA. Actualmente hay soluciones de Cortex-M en FPGA deAltera (Cortex-M1 como softcore) y de Actel (Cortex-M1 como

softcore y Cortex-M3 como hardblock); mientras que Xilinx noofrece soluciones de Cortex-M para su línea de FPGA. Por otraparte, ARM ha lanzado recientemente una versión reducida y de

bajo costo del procesador Cortex-M0 (Cortex-M0 DesignStart™)sintetizable tanto para FPGA como para silicio. En el presentetrabajo se muestran los resultados de la implementación de dichoprocesador en una FPGA de rango bajo de Xilinx, lográndose deesta manera ampliar el rango de implementaciones de losprocesadores Cortex-M en FPGA.

Keywords- Cortex-M0, FPGA

I. I NTRODUCCION

A. Descripción de las familias de procesadores de ARM

En la línea de procesadores de ARM, la familia Cortexconsiste en cores que van desde soluciones orientadas amicrocontroladores de bajo costo hasta procesadores de alta

perfomance con capacidad de ejecutar sistemas operativoscomplejos. Las lineas clásicas incluyen a las familias ARM7,ARM9 y ARM11 y las series especializadas SecurCore™ paraaplicaciones de seguridad y criptografía. En la Fig. 1 se puedeapreciar la ubicación relativa de cada familia en relación a sucapacidad y funcionalidad.

Figura 1. Relación performance-capacidades de las distintas familias de procesadores de ARM

El procesador Cortex-M0 es el miembro de menor rangodentro de la familia Cortex-M de procesadores de ARM. Estafamilia permite realizar distintos tipos de compromisos entrecosto, simpleza de diseño, consumo, performance y capacidad de procesamiento dentro del segmento Embedded Processors.El Cortex-M0 apunta principalmente a lograr bajo consumo y

la menor área de silicio, a fin de competir ventajosamente con procesadores de 8 bits de alta gama o procesadores de 16 bitsmientras mantiene la compatibilidad de código con

procesadores más potentes de la familia como el Cortex-M3.

La menor implementación de Cortex-M0 consume 85μW/MHzy ocupa un área equivalente de 12.000 compuertas. Comoreferencia, un procesador clásico como el i8051 ocupatípicamente alrededor de 8.000 compuertas [1][2]. En la Fig. 2vemos la ubicación relativa de cada miembro de la familiaCortex-M en función de su performance y plataforma deimplementación.

Figura 2. Comparación entre los distintos miembros de la familia Cortex-M

B. Arquitectura del procesador Cortex-M0

Este procesador esta basado en la arquitectura ARMv6-M

(Von Neumann) con un pipeline de 3 etapas, obteniendo unDhrystone de 0,9 DMIPS/MHz; implementa hasta 32interrupciones enmascarables más una no enmascarable através de un controlador de interrupciones integrado (NVIC-

Nested Vectored Interrupt Controller) con una latencia fija de16 ciclos de máquina [3]. La Fig. 3 muestra un diagrama en

bloques del procesador Cortex-M0



60




Figura 3. Diagrama en bloques de un procesador Cortex-M0

Su interfase con otros periféricos es a través de una versiónreducida del bus Advanced Microcontroller Bus Architecture(AMBA®), denominada AMBA AHB–Lite. Este bus fuediseñado como un bus de alta performance para transferenciasrápidas entre el procesador y periféricos que requieran granancho de banda y/o altas tasas de transferencia de datos.Generalmente se lo implementa con un único dispositivo queactúa como maestro y el resto como esclavos, aunque laespecificación del bus permite la implementación de múltiplesmaestros. Sus principales características son que permite

transferencias en ráfaga, sus operaciones se realizan en un ciclode reloj (sincronizado con su flanco), no implementa tri-state yes configurable el ancho del bus (32, 64, 128, 256, 512 y 1024

bits) [4]. La Fig. 4 muestra una implementación del bus y lasFigs. 5 y 6 muestran las señales de un dispositivo maestro y undispositivo esclavo respectivamente.

Figura 4. Ejemplo de un sistema con bus AMBA-Lite

Figura 5. Señales de un dispositivo AMBA-Lite maestro

Figura 6. Señales de un dispositivo AMBA-Lite esclavo

C. Procesador Cortex-M0 DesignStart

El procesador Cortex-M0 DesignStart (M0DS) es una versiónreducida del procesador Cortex-M0 standard (M0S) y fuelanzado al mercado el 4 de agosto de 2010. Sus principalesdiferencias con el procesador M0S son: El procesador M0S

posee interfaces del bus AMBA-Lite como maestro y comoesclavo, mientras que el M0DS sólo posee la interfase comomaestro; el M0S puede implementarse con un multiplicador rápido de 1 ciclo de reloj o con uno lento de 32 ciclos de reloj,mientras que el M0DS sólo implementa el multiplicador lento.El M0S puede implementar de 1 a 32 interrupciones, el M0DSimplementa 16 interrupciones fijas. El M0S opcionalmente

puede incluir un controlador de interrupción para bajo consumo(WakeUp Interrupt Controller), control selectivo de relojinterno (arquitectural clock gating), hardware e interfaces dedebugging (hasta 4 breakpoints por hardware y comunicaciónserial o JTAG) y un timer de referencia de 24 bits; el M0DS noincluye ninguna de las facilidades antes mencionadas [5][6][7].

II. IMPLEMENTACIÓN

A. Hardware y software utilizado

La FPGA empleada es de una línea madura y de rango bajode Xilinx: S3E500-4; sus principales características son: 500K compuertas, 10500 celdas lógicas (equivalentes a 1100 bloqueslógicos configurables (CLB) o 4600 slices), 20 multiplicadores

por hardware, 360Kbits de bloques dedicados de ram, 73kbitsde ram distribuida, 4 controladores de reloj y una frecuenciamáxima de trabajo de 300MHz [8].

La placa utilizada es una placa básica (starter board) de lafirma Digilent, modelo Nexys2. Cuenta con una FPGAS3E500, una interfase de programación y comunicaciones por USB, 16 Mbytes de PSDRAM y 16 Mbytes de Flash ROM,más una PROM de configuración; incluye un oscilador de50MHz, 8 LEDS, 4 displays de 7 segmentos, 4 pulsadores y 8interruptores. Hay disponibles 60 pines de I/O de la FPGA [9].

La Fig. 7 muestra un diagrama en bloque de la placa utilizada.

Figura 7. Diagrama en bloques de la placa de desarrollos utilizada

Una de las ventajas de esta placa es que, mediante unsoftware que se obtiene de la página web del fabricante(Adept), es posible utilizar directamente las herramientas de

programación de Xilinx (Impact, Chipscope Pro, Xmd, etc.), loque permite programarla y ver su estado interno fácilmente.



61




Como herramientas de software se utilizó el entorno dedesarrollo para FPGA de Xilinx ISE versión 12.2; para lageneración de programas ejecutables en el procesador se utilizóel entorno de desarrollo ARM MDK de Keil Gmbh.

B. Elementos que integran el Cortex-M0 DesignStart Kit

Este kit tiene dos componentes: el procesador, representado por dos archivos en verilog sintetizable y un test bench que permite realizar pruebas básicas. Por otra parte se incluye undocumento en formato PDF correspondiente a las notas delanzamiento (Release Notes) [5].

El test bench se compone de un módulo no sintetizable enverilog que implementa al procesador conectado a unamemoria preinicializada con un programa simple. Completan eltest bench el código fuente en C del programa; la imagen enformato binario del programa y un makefile que permiteobtener la imagen en formato binario a partir del código fuenteen C. En la Fig. 8 se vé el diagrama en bloques del test bench.

Figura 8. Diagrama en bloques del test bench

C. Plan de trabajo de la implementación

La secuencia de actividades planificada fue: 1) verificar queel procesador sea sintetizable en la FPGA seleccionada. 2)crear un proyecto en la herramienta ISE de Xilinx queimplemente el test bench y verificar su correctofuncionamiento mediante simulación. 3) generar el archivo binario a partir del código fuente utilizando el makefile provisto. 4) verificar en el test bench que el archivo binariogenerado sea correcto mediante simulación. 5) crear un proyecto en la herramienta ISE de Xilinx que implemente concomponentes sintetizables el sistema de test bench. 6) generar un programa que permita interactuar con los recursos dehardware de la placa, a fin de verificar la correctaimplementación del procesador. Verificar el mismo mediantesimulación en el entorno de desarrollo del programa. 7)Integrar la imagen binaria del programa generado al proyecto

que implementa el sistema sintetizable. Verificar su correctofuncionamiento mediante simulación funcional en el entornoISE. 8) Sintetizar el proyecto con el programa integrado eimplementarlo en la placa de desarrollos. Verificar el correctoacceso a los recursos de hardware de la placa.

D. Secuencia de implementación realizada

El ítem 1) se realizó sin mayor inconveniente, resultando enun uso aproximado del 50% de los Slices de la FPGA, lo que

determinó la viabilidad de realizar la implementación. Durantela ejecución del ítem 2), en la simulación se encontró que el procesador no llegaba a ejecutar la rutina principal del programa, sino que entraba en un estado bloqueado. A fin deencontrar la razón de ello, se continuó con el ítem 3), paraobtener una simulación de la ejecución del software en el

entorno de desarrollo del mismo. Para ello se utilizó el entornode desarrollo ARM MDK de la firma Keil Gmbh, ya que era laherramienta que se indicaba en las notas de lanzamiento.

Al analizar en detalle el makefile para utilizarlo con elMDK se encontró que el mismo no era consistente: si bien lasherramientas de compilación y enlazado eran del MDK (Armccy Armlink), los parámetros pasados no correspondían a dichasherramientas. Buscando en la documentación de otros proveedores de herramientas de software para procesadoresARM se llegó a la conclusión que los parámetroscorrespondían a las herramientas del IAR Embedded Workbench de la firma IAR (Iccarm e Ilinkarm); por lo que elmakefile provisto era en realidad compuesto por distintosmakefiles y no servía para generar el archivo binario a partir

del archivo fuente.Ante esta situación, se decidió implementar un proyecto en

MDK con el archivo fuente provisto, obtener un archivo binario, y utilizar este en la simulación para verificar si serepetía el problema del procesador bloqueado. Una vezrealizado esto, nuevamente se obtuvo un estado de procesador bloqueado, pero al disponer del proyecto en MDK, era posiblecomparar la simulación de software en MDK con la simulaciónfuncional del test bench en ISIM de Xilinx. Al realizar dichacomparación, se encontró que la simulación del software enMDK funcionaba correctamente, mientras que la simulaciónfuncional en el ISIM mostraba valores que no correspondían enlos buses de datos. Un análisis detallado del problema mostróque el test bench no estaba correctamente implementado: la

parte del mismo encargada de inicializar la memoria realizabauna lectura del archivo binario mediante la función de verilog$fread asumiendo que la misma realizaba una lectura de 4 bytes simultáneamente (32bits), cuando la misma en laimplementación de verilog de Xilinx realiza una lectura de 1 byte (8bits) a la vez; por lo que se corrigió el test bench a fin deque se realice correctamente la inicialización de la memoria; yde esa manera la simulación de software del MDK coincidiócon la simulación funcional de ISIM para el código fuente provisto.

Habiendo subsanado los inconvenientes antesmencionados, se paso a los ítems 5) Sistema Sintetizable y 6)Programa que utilice el hardware de la placa de desarrollos. Sedecidió empezar por el programa. A fin de no implementar undispositivo esclavo con el que comunicar el procesador (lo que

agregaría complejidad al proyecto), se decidió implementar un programa que cargara dos valores distintos constantes en unavariable con un cierto retardo entre cada carga. Esto generaríaun programa que buscara dichos valores constantes enmemoria, lo que obligaría a aparecer a dichos valores sobre el bus de datos del procesador, permitiendo su detección. Este programa se simuló en el entorno MDK y se verificó el accesoa memoria en busca de los valores constantes antesmencionados. En la Fig. 9 se observa una captura de la pantalladel simulador de software. Una vez realizada esta verificación,



62




se cargo el programa en el test bench y se verifico en lasimulación funcional con ISIM que los valores elegidosaparecían sobre el bus de datos. En la Fig. 10 se ve una capturade la simulación funcional en ISIM.

Figura 9. Simulación de software mostrando el acceso a memoria

Figura 10. Simulación funcional mostrando el acceso a memoria

Siendo exitosas las simulaciones, se implemento el sistemasintetizable. El mismo consta de las siguientes partes:“Procesador”, con el código verilog del procesador Cortex-M0DS; “Sincronizador de reset”, implementado con uncontador que fija una señal en nivel alto al llegar al final delconteo, a fin de generar una señal de reset sincrónica con elreloj del sistema. Memoria”, implementado como una RAM

preinicializada con el archivo binario generado en MDK.“Reloj”, que implementa la señal de reloj de referencia, através de un DCM de la FPGA fijado a 10MHz a partir deloscilador de 50MHz que provee la placa de desarrollos. Yfinalmente “Detector de Bus”, que detecta sobre el bus de datoslos valores constantes programados y comanda un Led de la

placa de desarrollos que se prende cuando detecta un valor programado y se apaga cuando detecta el otro valor. Cabe

destacar que fue necesario desarrollar un software queconvirtiera el formato binario del archivo de programa alformato COE necesario para inicializar la memoria. Se verificómediante simulación funcional en el ISIM el correctofuncionamiento del sistema completo, en particular del detector de bus, el cual reaccionó correctamente frente a los datos queaparecían sucesivamente sobre el bus de datos.

Finalmente se implemento completamente el sistema y se programó la placa con el mismo, realizándose las siguientesverificaciones: con la herramienta ChipScope Pro, que permite

ver señales internas de la FPGA, se verificó la aparición de losvalores constantes programados; y visualmente se verificó quea los intervalos programados para los accesos a memoria, unled de la placa de desarrollos cambiaba de estado de encendidoa apagado, dándose así por validada la implementación del

procesador en la FPGA.

III. R ESULTADOS Y CONCLUSIONES

El resultado más destacable es que es posible implementar este procesador en una FPGA de rango bajo, lo que permite suaplicación en sistemas embebidos sobre FPGA de bajo costo.Asimismo se amplió el espectro de implementación del

procesador Cortex-M0, ya que ahora es posible implementarlosobre los tres principales proveedores de tecnologias de FPGA(Xilinx, Altera y Actel), lo que lo convierte en una plataforma aconsiderar en situaciones en las que la portabilidad entredistintos fabricantes de FPGA es un requisito.

Como estadísticas de implementación, en la Fig. 11 semuestran los resultados de uso de la FPGA:

Figura 11. Estadisticas de uso de la FPGA una vez realizada la

implementación del sistema

Como resultados de temporización, la herramienta desíntesis y los resultados Post Place and Route indicaron unafrecuencia máxima de trabajo de alrededor de 40MHz. Cabeaclarar que no se realizaron ningún tipo de restricciones detemporización o ubicación de componentes en el sistema.

Otra particularidad de este procesador es que es posibleacceder directamente a los registros internos del mismo, lo quelo hace útil en aplicaciones educativas, ya que es posibleobservar la total concordancia entre la simulación de software,la simulación funcional en ISIM, y la verificación de laimplementación a través de ChipScope Pro a nivel de registrosinternos del procesador.

Como aspecto a considerar sería las mejoras al test bench

provisto; acortaría mucho el tiempo de desarrollo tener un test bench completo que permita generar el archivo binario a partir del archivo fuente. Esto no fue posible con los elementos

provistos, por lo que fue necesario realizar las actividadesmencionadas en la implementación.

Como conclusión, este procesador se integra a la familia de procesadores softcore sintetizables sobre FPGAs de Xilinx, junto con el Microblaze y el Picoblaze, ofreciendo la ventaja deser migrable a otras arquitecturas de FPGA (Actel, Altera).Como línea de trabajo futura se propone crear una



63




implementación de bus AMBA-Lite y periféricos compatiblescon este bus, a fin de aumentar sus capacidades y convertirloen una opción a tener en cuenta en la creación de sistemasembebidos sobre FPGAs de Xilinx. Una vez realizado esto se

buscará desarrollar un sistema con capacidad de ejecutar variantes de embedded Linux, a fin de aplicarlo en el área

educativa en el Curso de Sistemas Embebidos dictado por laFI-UBA.

IV. R EFERENCIAS

[1] CAST T8051 Core Product Brochure (www.cast-inc.com)

[2] IPextreme M8051EW+ Core – Product Characteristics (www.ip-extreme.com)

[3] ARM Ltd, “ARM DDI 0419C ARMv6-M Architecture ReferenceManual”, Septiembre de 2010.

[4] ARM Ltd, “ARM IHI 0033A AMBA 3 AHB-Lite Protocol V.1.0Specification”, Junio de 2006.

[5] ARM Ltd, “AT510-DC-80001-r0p0-00-rel0 ARM Cortex-M0DesignStart Release Note”, Agosto de 2010.

[6] ARM Ltd, “ARM DDI 0432C Cortex-M0 Revision r0p0 TechnicalReference Manual”, Noviembre de 2009.

[7] ARM Ltd, “ARM DUI 0497A Cortex-M0 Devices Generic User Guide”, Octubre de 2009.

[8] Xilinx, “DS312 Spartan-3E FPGA Family: Datasheet”, Agosto de 2009.

[9] Digilent, “Digilent Nexys2 Board Reference Manual”, Junio de 2008.

V. AGRADECIMIENTOS

A la gente del programa universitario de ARM, en particular a William Hohl yJoe Bungo; a Fiona Cole de Digilent Inc.; y la gente del programauniversitario de Xilinx (XUP) por su ayuda y cooperación.

VI. MARCAS REGISTRADAS

La información acerca de las familias de procesadores de ARM fue extraida principalmente del sitio web de ARM Ltd. (www.arm.com) publicada enoctubre de 2010.

ARM, Cortex, Cortex-M, AMBA, AMBA-Lite, y otras marcas mencionadas

son marcas registradas de ARM Limited.

Xilinx, Spartan, ISE, y otras marcas mencionadas son marcas registradas de

Xilinx Inc.

Digilent, Nexys2, Adept, y otras marcas mencionadas son marcas registradas

de Digilent Inc.

Todas las otras marcas registradas mencionadas son propiedad de sus

respectivos propietarios.

Las Figuras 1 a 6 y la Figura 8 son copyright ARM Ltd. Reproducidas con

permiso.

La Figura 7 es copyright Digilent Inc. Reproducida con permiso.



64




Sistemas en Chip acelerados por hardware:

comparación de performance en aplicaciones

criptográficas

Marcos J. Oviedo

Facultad de Ingeniería


Córdoba, AR

[email protected]

Pablo A. Ferreyra

Facultad de Matemática, Astronomía y

Física


Posgrado en Sistemas Embebidos


Córdoba, AR

[email protected]

Carlos A. Marqués

Facultad de Matemática, Astronomía y

Física


Córdoba, AR

[email protected]

Abstract — El procesamiento de datos de alta performance se haconvertido en un desafío para la tecnología de los sistemas

embebidos actuales. Una alternativa para suplir los

requerimientos de performance es la utilización de aceleradores

de hardware implementados en lógica programable. En el

presente trabajo se muestran los resultados obtenidos de dos

implementaciones del algoritmo criptográfico TripleDES a través

del uso de aceleradores de hardware.

Keywords; Computación de Alta Performance, Sistema en Chip,

Encriptación de datos Standard, Optimizaciones de Hardware,

Aceleradores de Hardware.

I. I NTRODUCCION

Avances en la industria de los semiconductores han permitido que utilizando componentes de lógica programablesea posible implementar sistemas digitales complejos. Unsistema en chip programable (SoC) es un sistema digital que enuna sola pastilla de silicio, implementa un sistema embebido,dispositivos de aplicación específica y software de aplicación ycontrol.

Uno de los conceptos más poderosos atrás del diseño SoCes que la funcionalidad del sistema puede ser especificada yasignada no sólo al software que corre sobre el procesador, sinotambién a los componentes de hardware que lo constituyen.Permitiendo así, que para efectos de aceleración de

procesamiento, sea posible implementar unidades de

procesamiento de alta performance encargadas de realizar ciertos tipos de operaciones computacionales de forma óptimay por lo tanto a mayor velocidad que el procesador del sistemaembebido, ayudando así a incrementar la performance delsistema.

Debido a la creciente demanda de tecnológica de lasociedad moderna, los sistemas embebidos que componen losequipos electrónicos actuales debe ser capaces de evolucionar constantemente a modo de soportar la creciente demanda decapacidad de procesamiento a los que están sometidos. A modode resolver esto existen alternativas a los sistemas embebidos

tradicionales, como el desarrollo de sistemas embebidos en unSoC de alta performance (HPSoC).

En un HPSoC la arquitectura de hardware esta optimizada para que la plataforma de cómputo que lo compone trabajecooperativamente con aceleradores de hardware. En el curso dedesarrollo de un HPSoC, las funcionalidades que componen almismo son definidas primero en software, para que luego partede las mismas sea trasladada a hardware. La implementaciónen hardware a través de lógica programable es una alternativaválida que se puede utilizar para lograr sustancialesincrementos en performance, teniendo en cuenta el alto nivelde paralelismo que se puede conseguir con la utilización de una

plataforma de lógica programable.

En el presente trabajo se mostrará en forma teórica unametodología de desarrollo de un HPSoC para luego finalizar con una comparación de performance entre los resultadosobtenidos de dos alternativas de implementación del algoritmode encriptación simétrico TripleDES en un HPSoC. Laimplementación se realizo sobre una plataforma de lógica

programable que contiene una FPGA Xilinx Virtex 4.

Este paper está organizado de la siguiente forma: Lasección II presenta información teórica sobre las limitacionesde los sistemas basados en procesador que motivan el presentetrabajo. La sección III presenta la metodología de trabajo

propuesta para desarrollar este tipo de sistemas digitales. Lasección IV presenta un enfoque en distintos niveles sobre lastécnicas y mecanismos disponibles para incrementar la

performance de un HPSoC. La sección V presenta dosimplementaciones de HPSoC que proveen aceleradorescriptográficos desarrollados siguiendo la metodología

propuesta. La sección VI muestra y compara los resultadosobtenidos. Por último, en la sección VII se muestran losresultados obtenidos y se presentan las conclusiones del

presente trabajo.



65




II. LIMITACIONES DE LOS SISTEMAS BASADOS E N

PROCESADOR

Los procesadores fueron concebidos para realizar computación de propósito general. Esta decisión de diseño

produjo que los procesadores no sean eficientes a la hora derealizar tareas de cómputo específicas y por lo tanto, que no

puedan satisfacer la performance de procesamiento quedemandan algunos sistemas embebidos actuales. Persiguiendola ley de Moore, a lo largo de los años se ha buscadoalternativas para mejorar la performance de las plataformas decómputo basadas en procesador. Sin embargo estas alternativasno han sido eficientes ni aplicables en muchos escenarios endonde la performance era un requerimiento. Como se enunciaen [1], esto se debe principalmente a que existen limitacionesfísicas inherentes a los procesadores que en muchos casos ydada la tecnología actual, impiden que estas alternativas seapliquen arbitrariamente:

• El hecho de aumentar la cantidad de transistores y lafrecuencia a la que estos trabajan, introduce serios

problemas de disipación de calor (barrera de potencia).

• La frecuencia no puede ser incrementadaarbitrariamente, no solo por la barrera de potencia, sino también debido a una inherente limitación física enlos tiempos de conmutación de los transistoresutilizados en el diseño del microprocesador (barrera defrecuencia).

• En un sistema de cómputo actual, el ancho de bandadel microprocesador es generalmente 70 veces superior al de la memoria externa, convirtiendo el acceso a lamisma en un cuello de botella. El uso de complejas

jerarquías de memorias locales al microprocesador (caches) disminuye considerablemente el tiempo deacceso a los datos, pero debido a la imposibilidad

tecnológica de incrementar el tamaño del cachearbitrariamente, el acceso a memoria sigue siendo un

problema real (barrera de memoria).

• Finalmente los procesadores en si tienen una limitaciónfundamental: Un diseño basado en ejecución serial,que hace extremadamente difícil extraer niveles de

paralelismo de un flujo de ejecución de instrucciones.Como se menciona en [2] existen complejos diseños ytécnicas en las arquitecturas de los procesadoresactuales que intentan extraer el paralelismo en lasinstrucciones y mitigar esta limitación.

La utilización de lógica programable y la realización de un

HPSoC es una valida alternativa para lograr sustancialesincrementos en performance en sistemas donde la performancees el principal requerimiento. En el presente trabajo sedemostrara la implementación de un HPSoC que permitirácrear una plataforma de computo especifica y orientada a laaplicación, a modo de optimizar el camino de ejecución dedatos (a través de extraer e implementar paralelismo),optimizar el uso de la memoria (aumento la localidad y elacceso), disminuir la disipación de potencia (hardwareespecifico requiere menor número de transistores) y disminuir la frecuencia de trabajo (posible debido a que en cada ciclo dereloj se realizan múltiples operaciones).

III. METODOLOGIA DE DESARROLLO DE U N HPSOC

En la metodología propuesta, el diseño de un HPSoCconsistirá en dos áreas separadas pero que requiereninteracción entre ellas. Una de esas áreas es la creación delsoporte necesario para implementar un sistema embebido en laFPGA basado en microprocesador y la otra es la optimizaciónde la aplicación en vistas de una posterior implementación

basada en un codiseño hardware-software. En este codiseño el

componente de hardware se implementara como uncomponente acelerador que se comunicara con el componentede software a través del diseño embebido.

En primera instancia, el desarrollo de sistemas embebidosse realiza utilizando herramientas EDA que permiteninterconectar, a través de una jerarquía de buses deinterconexión, un microprocesador (que puede ser un softcore,o un hardcore como se menciona en [3]), con un conjunto dedispositivos que vuelven al sistema embebido una plataformade computo funcional. El desarrollo de sistemas embebidos noes estandarizado y varía dependiendo del fabricante de FPGAsque se utilice. En el presente trabajo se utilizó FPGAs de lafirma Xilinx, por lo cual se trabajo con el ecosistema de

desarrollo de Xilinx para implementar el sistema embebido.Esto consistió en utilizar las herramientas EDK, ISE y laslibrerías de componentes de hardware XilinxProcessorIPLib.

En segunda instancia, se deberá trabajar sobre la aplicaciónque se busca optimizar. Para esto se debe realizar un prototipo

por software de la aplicación o algoritmo a implementar en elHPSoC. Este prototipo será luego caracterizado y evaluadomediante herramientas como profilers y analizadores decódigo, a modo de poder detectar cuales son los segmentos oáreas de la misma en donde más procesamiento se realiza(secciones críticas en términos de performance). Con estainformación y a través de un enfoque top-down, se procederá aestudiar el algoritmo que define la aplicación, a modo de

refactorizar la misma y que las secciones críticas puedan ser optimizadas y aisladas para ser implementadas en hardware. Laimplementación en hardware de las secciones críticas de laaplicación permiten que las operaciones computacionales

puedan ser representadas en lenguajes de descripción dehardware y que a través de una estrategia de optimización por niveles, se puedan implementar componentes aceleradores dehardware, es decir hardware de procesamiento especifico que

permita realizar computo altamente performante y eficiente.

Para el desarrollo del componente acelerador se puedeutilizar un lenguaje de descripción de hardware como VHDL outilizar una herramienta ESL como ImpulseC [4]. Elcomponente acelerador además, deberá integrarse dentro del

diseño embebido del HPSoC, por lo que un canal decomunicación de alta velocidad entre hardware y softwaredeberá también ser desarrollado.

Por otro lado, cabe mencionar que el componente desoftware del codiseño HW/SW puede correr directamentesobre el procesador o bajo el control y soporte de un sistemaoperativo (como una aplicación más de espacio de usuario).Dado los beneficios que provee un sistema operativo, ennuestra metodología se brinda soporte de un sistema operativo

para el componente de software.



66




Una vez que estas dos instancias del HPSoC esténcompletas, el diseño de hardware tiene que ser trasladado ymapeado en el fabric de una FPGA, y las imágenes binarias delsoftware correspondiente tienen que ser almacenadas en lasmemorias correspondientes para su posterior evaluación.

IV. OPTIMIZACION DE PERFORMANCE E N UN DISEÑO

HPSOC

Existen diversos factores que pueden ser modificados ytécnicas que pueden ser aplicadas en la arquitectura de unHPSoC a modo de incrementar la performance general delmismo. Estos factores pueden ser agrupados en tres áreas a lasque llamaremos niveles de optimización.

A. Optimizaciones a nivel de Sistema

Describimos como sistema a la plataforma física en dondese implementa la aplicación. Las optimizaciones a nivel desistema están ligadas a la forma en que se pueden implementar las aplicaciones en esta plataforma, y las modificaciones que

pueden ser realizadas en la misma para que estas se ejecutenmás rápido y para que el throughput sea más elevado.

La optimización trivial es modificar el diseño de hardwareque compone la plataforma de cómputo para que los diversoscomponentes de esta funcionen a la máxima velocidadadmisible. Además, es óptimo establecer canales decomunicaciones de alta velocidad entre los componentes de usofrecuente por el procesador, por ejemplo los bancos dememorias o la comunicación con el fabric de la FPGA. El usode caches de memorias (preferentemente memoria RAM en

bloque) puede aumentar la localidad de datos y así mejorar la performance.

Así mismo, las herramientas de síntesis que sintetizan eldiseño de hardware permiten configurar restricciones de

tiempo y aumentar el nivel esfuerzo, a modo de mejorar elrendimiento disminuyendo el tiempo de propagación de datos através del hardware.

Por otra parte, a nivel de sistema se puede paralelizar el procesamiento de datos a nivel de componente acelerador.Siempre que el algoritmo a procesar lo permita, es decir que elalgoritmo de procesamiento trabaje con un conjunto de datosindependiente unos de otros, y que además existadisponibilidad de recursos en la FPGA utilizada, se puedeimplementar más de un componente acelerador y procesar asívarios conjuntos de datos en paralelo.

B. Optimizaciones a nivel de aplicación

Describimos como aplicación al algoritmo computacionalque cumple un cierto número de requerimientos con el fin deimplementar por software o hardware la funcionalidad

principal del HPSoC.

El objetivo de las optimizaciones a nivel de aplicación esestudiar el algoritmo que define las operaciones críticas en

performance de la aplicación, a modo detectar el paralelismoinherente en el mismo y optimizar el procesamiento.

Cabe aclarar que las optimizaciones sobre el algoritmo seharán sobre los detalles de alto nivel del mismo, y no sobre los

detalles de bajo nivel que definen la implementación delmismo. Entonces, si posibles paralelizaciones son detectadas, ysiempre cumpliendo con los requerimientos funcionalesiniciales, se buscara implementar las modificaciones necesariasen el código del algoritmo, de modo de que este deje de lado suflujo de ejecución serial y adopte un modelo de funcionamientoen paralelo.

Además de detectar niveles de paralelización yoptimizaciones en el flujo de ejecución del algoritmo, otrainteresante técnica que se puede utilizar para optimizar la

performance a nivel de aplicación es el uso de precomputo dedatos. Esto consiste básicamente en acotar el rango de accióndel algoritmo, tomando asumpciones sobre el espacio detrabajo del algoritmo, a modo de precomputar y simplificar susoperaciones y de ese modo acelerar la ejecución del mismo.

C. Optimizaciones a nivel de micro arquitectura

Describimos como micro arquitectura a los componentes delógica programable que implementan los detalles de bajo niveldel algoritmo que define la aplicación que se ejecutara sobre elHPSoC. Algunas técnicas para mejorar la performance de la

micro arquitectura del componente acelerador son lassiguientes.

1) Replicar los arrays o bancos de memoria que contienen

los datos: Una de las ventajas más importantes que nos ofrecela programación en hardware es la posibilidad de acceder amúltiples bancos de memoria en un solo ciclo de reloj. Adiferencia de una implementación de software, en la que unCPU esta conectado a uno o mas dispositivos de memoriafísica siempre a través de un solo bus, una implementación enhardware permite la flexibilidad de generar una topología deconexionado arbitraria, en la que un conjunto de operacionesal ser ejecutadas puedan acceder a datos distribuidos en varios

bancos de memoria en una sola operación de reloj. Es por estoque un factor importante a tener en cuenta, es que para lograr resultados óptimos debemos replicar nuestro set de datos endiferentes bancos de memoria. Con esto lograremos tener

bancos de memoria separados, cada uno con su puerto delectura/escritura, lo que permitirá acceder a los mismos enforma paralela para su posterior operación/procesamiento.

2) Operaciones sobre bucles: En un algoritmo, los buclesson una de las construcciones que contienen un alto grado de

paralelismo inherente, y por lo tanto, son una de lasconstrucciones que se apunta a optimizar. Los bucles

generalmente realizan operaciones repetitivas sobre un set dedatos. Si cada de las operaciones del bucle no depende dedatos calculados en interacciones anteriores, es decir si encada iteración se puede operar sobre set de datosindependientes, el grado de paralelismo que se puede obtener es elevado. Existen dos técnicas para optimizar lasoperaciones sobre bucles, estas son el desenrollado del bucle yla generación de “líneas de ensamblado”, o mas conocido por su término en ingles, pipelines. El desenrrollado de buclesconsiste en expandir el conjunto de iteraciones consideradas

por el bucle y reacomodar el algoritmo para que estas puedan



67




ser realizadas en paralelo y en una sola iteración del bucle. El

desarrollo de pipelines consiste en dividir el trabajo a procesar

en subtareas, a modo de que a medida que van entrando los

datos a procesar, cada subtarea pueda ir procesando en forma

concurrente un diferente set de datos. Entonces, si cada

iteración del bucle requiere ejecutar N subtareas, en una

implementación sin pipeline, el bucle realizara una cantidad

(N * cantidad_elementos_de_datos) de iteraciones paracompletar su trabajo. En cambio en una implementación con

pipeline, la totalidad de datos serán procesados en una

cantidad (N + 1) de iteraciones. La teoría de pipelines y

desenrollado de bucles ha sido extensamente desarrollada en

[5] y [6].

V. DESARROLLO DE U N HPSOC CRIPTOGRAFICO

A modo de evaluar las mejoras obtenidas a través de laimplementación de un HPSoC acelerado por hardware, sedesarrollo un SoC prototipo sin aceleración (implementaciónsolo por software), y dos versiones de un HPSoC con

aceleración por hardware. En estos dos últimos casos, elcomponente acelerador fue desarrollado en VHDL y con laherramienta de síntesis de alto nivel ImpulseC respectivamente.

La aplicación criptográfica consistió en obtener un set dedatos de memoria y cifrarlos a través del algoritmo de cifradosimétrico TripleDES. El algoritmo de cifrado simétricoTripleDES se utilizó en modo ECB, siguiendo los lineamientosmencionados en [7] y [8]. Siguiendo la metodología propuestaen el presente trabajo, después de diseñar e implementar elsistema embebido en el SoC, se desarrollo en software un

prototipo no optimizado del algoritmo a utilizar. Este prototiposirvió para estudiar el algoritmo y caracterizarlo. Con los datosobtenidos y evaluando las técnicas de optimización

enumeradas en [9], se procedió a desarrollar los componentesaceleradores y aplicar los niveles de optimizaciónanteriormente descritos.

Cabe aquí citar que para la implementación de los prototipos se utilizó el kit de desarrollo FX12 Minimodule, provisto por la firma Avnet y que cuenta con una FPGAVirtex4 FX12 y diversos componentes externos descritos en la

página del fabricante. El diagrama en bloque del HPSoCdesarrollado puede verse en la figura 1.

A. Desarrollo del sistema embebido del SoC

Durante el desarrollo del diseño embebido se dio soporte atodos los dispositivos físicos de hardware del kit de desarrollo,

utilizando los IP Cores de Hardware necesarios para elfuncionamiento del sistema embebido.

Para implementar el diseño embebido se utilizó laherramienta EDK de Xilinx descrita en [10]. El procesador elegido para el diseño embebido fue un recurso de hardwareque posee la FPGA elegida, es decir el hardcore de unPowerPC 405 (PPC). Mediante esta herramienta se desarrolloun sistema embebido que permitió comunicar el procesador PPC con los dispositivos externos del kit de desarrollo, talescomo la Memoria RAM, la memoria FLASH, el puerto UART,la PHY de Gigabit Ethernet así como también implementar

componentes necesarios para volver al sistema embebido y su procesador una plataforma de computo funcional. Además laherramienta permitió, desarrollar un canal de comunicación dealta velocidad entre el componente acelerador implementadoen la lógica programable y el microprocesador del sistemaembebido.

Se genero el soporte necesario para que el PPC puedacomunicarse a través de los buses PLB, OPB, FCB, OCM yDCR a los distintos dispositivo. Estos buses pertenecen a lafamilia de buses CrossConnect y están descriptos en [10]. Cabeaclarar que este procesador solo soporta conexión directa a los

buses PLB, OCM, DCR y FCB, por lo que los dispositivosatrás del bus OPB se alcanzaran a través de un bridgePLB2OPB.

Una vez definida la arquitectura de buses, sus tamaños yfrecuencias de trabajo, así como también los elementosadicionales necesarios para su correcto funcionamiento, seescogió a los dispositivos del kit de desarrollo a los cuales seles dará soporte y como estarán conectados estos a la jerarquíade buses, a modo de que estos sean visibles al procesador PPC.La configuración de los mismos, es particular de cada caso ydependiente del diseño adoptado, aunque por lo general estaconfiguración especifica incluye aspectos como el tipo deDMA que utilizara, velocidad de funcionamiento, tipo de clock al que estará conectado, pines y redes al que estará conectado,cantidad, tipo de interrupciones que generara y áreas dememoria que estarán reservadas en el mapa de memoria delsistema para los registros del mismo. Cada IPCore de la libreríade hardware XilinxProcessorIPLib posee un datasheet quedetalla sus parámetros de configuración posibles.

El canal de comunicaciones de alta velocidad utilizado seimplemento por medio del controlador APU, una funcionalidaddel procesador PPC descripta en [11]. El controlador APU

provee una interfase de comunicación flexible y de alta

velocidad entre el fabric de la FPGA y el procesador PPC. Estainterfase de comunicación conecta directamente el pipeline deinstrucciones del PPC a uno o más componentes aceleradoresde hardware.

B. Desarrollo del soporte del software de control del HPSoC

El componente de software de la aplicación del HPSoC seejecutara con soporte de un sistema operativo. Se eligió Linuxcomo sistema operativo de soporte. Para esto se preparo elsistema operativo Linux a modo que controle los distintoscomponentes de hardware del sistema embebido. Se generoademás un root filesystem con las aplicaciones necesarias paravolver funcional al sistema. Se desarrollo además un

mecanismo para que el kernel pueda ser cargado en memoriade ejecución mediante el uso de XMD, un debugger provisto

por EDK y que a través de JTAG puede bajar y ejecutar binarios ELF compilados para el procesador PPC. Esto permitió que el kernel se pueda ejecutar sobre el sistemaembebido, inicializarse, detectar el hardware sobre el que seejecuta, configurar las interfaces de red, autoconfigurar sudirección de red a través de DHCP y bootear un root filesystemremoto a través de NFS. En la figura 2 se puede observar laiteración de protocolos durante el booteo del kernel.



68




ControladorPHY

ControladorDDR

ControladorUART

ControladorGPIO

ControladorHWICAP

D cacheI cache

A r b i t r o

RAM debloque

OPBPLB

Bus FCB

Bus

Bridge

A r b i t r o

ComponenteAcelerador de HW

Power PC

405

HPSoC

Servidor de pruebas con:- Servicio DHCP server- Servicio NFS server- Entorno de Desarrollo

- Buildroot- Crosscompiladores

Flujo de consultas<- Consulta DHCP-> Respuesta DHCP con información de

red y información de servidor NFS<- Petición de montaje a traves de NFS-> Informacion de punto de Montaje

Ethernet

La versión de Linux utilizada es la 2.6.20. Se realizaronmodificaciones masivas sobre el código del kernel, utilizandocódigo provisto por el fabricante y modificaciones ad-hoc.

Además, para poder soportar el canal de comunicaciones

APU, hubo que habilitar el bit 6 del registro MSR, Machine-

State Register del procesador PPC. Este registro define elestado de funcionamiento del procesador, y debe ser configurado en tiempo de inicialización del sistema operativo.

En este modo de funcionamiento, el procesador puede utilizar

instrucciones vectoriales para transmitir datos a través del

canal de comunicación de alta performance entre el hardware

y el software.

C. Desarrollo de la aplicación del HPSoC

Como se mencionó, se desarrollaron tres versiones de laaplicación. Una desarrollada enteramente en software quesirvió como punto de estudio del algoritmo de encriptación. A

partir de este prototipo, se desarrollaron dos versiones de

componentes aceleradores. Una versión utilizando laherramienta ImpulseC y otra versión desarrollada en VHDL. Aambas versiones se les aplicaron las mismas optimizacionesdescritas a continuación.

1) Optimizaciones a nivel de sistema: Las optimizaciones

a nivel de sistema realizadas sobre la plataforma serán listadas

a continuación.

a) Se incremento la frecuencia del clock del procesador

embebido a 200 Mhz.

b) Se incrementaron la frecuencia de los buses PLB y

OPB.

c)

Se incremento la frecuencia de trabajo delcomponente acelerador.

d) Se utilizó el máximo nivel de esfuerzo en la síntesis.

Esto se logro editando el archivo etc/fast_runtime.opt. Este

archivo contiene las opciones de ejecución de las utilidades de

mapeo y ruteo de componentes. Ambas utilidades (map y

place) fueron seteadas con la opción –ol a high (lo que indica

máximo esfuerzo en la síntesis necesario para obtener un

diseño optimizado).

e) Se incremento la transferencia de datos para utilizar

el máximo ancho de banda provisto por el canal APU. Esto es

64 bits de datos.

2) Optimizaciones a nivel de aplicación: A nivel de

aplicación se realizaron optimizaciones sobre el algoritmo

TripleDES en si mismo. Como se describe en [9], se pueden

realizar cambios en distintos puntos del algoritmo que

mejoraran drásticamente la performance del mismo a través

del precomputo de datos y de la optimización de las

operaciones lógicas de permutación y tablas de búsqueda

(operaciones sobre las cajas S).

a) Precomputo de datos de las subllaves: Se realizo el

precomputo de las subllaves necesarias para operar elalgoritmo TripleDES. Esto permitio que las subllaves puedan

ser accesibles de forma inmediata. Ademas, el hecho de

precomputarlas de antemano permitio que los valores de las

mismas puedan ser replicados espacialmente de modo que

puedan ser utilizados de forma eficiente en las operaciones del

algoritmo TripleDES. El precomputo se puede realizar debidoa que se asume que el valor de la llave no será cambiado por el

usuario en el futuro. La generación y precomputo de lassubllaves se realiza en forma externa y el código se embebe en

la descripción del hardware.

b) Precomputo y combinación de la tabla de

permutación P con las cajas S: El algoritmo DES provee un

mecanismo de expansión de información a través de un

conjunto predefinido de bits conocido como cajas S. El

algoritmo incluye además tablas de permutación bits,

conocidas como tabla P, que a fines de performance y

teniendo en cuenta ciertas modificaciones en la

implementación del mismo, pueden ser combinadas con tablas

S para precomputar futuro procesamiento. Estas cajascombinadas se llaman cajas SP.

c) Tabla de expansión E embebida: La tabla de

expansión E se utiliza en DES para llevar un bloque de datos

de 32 bits a un formato de 48 bits, necesario para poder

XORear las subllaves con este valor expandido. Con fines de

performance, se embebió el proceso de expansión de la tabla E

en las operaciones de translación de las cajas SP.

3) Optimizaciones a nivel de microarquitectura: A nivel

de microarquitectura no se realizaron optimizaciones sobre el

algoritmo TripleDES en si mismo, si no que se busco

Figura 1. Diagrama en bloques de la arquitectura HPSoC desarrollada

Figura 2. Flujo de consultas para booteo del sistema operativo



69




optimizar las formas en que las operaciones se realizan, así

como también la implementación de pipelines, desenrollado

de bucles y replicación de datos para favorecer la

paralelización de operaciones.

a) Implementación de la técnica de secuencias de permutación: A modo de implementar las permutaciones

inicial y final de bits de forma optimizada, se utilizó la técnica

"secuencias de permutación" descrita también en [9]. Estatécnica es ampliamente utilizada en diversos algoritmos de

cifrado de datos, así como también en algoritmos de

corrección de errores en la industria.

b) Replicación de datos: Se genero código replicado de

entidades de memoria que almacenan los datos de las 8cajasSP. Esto permitió realizar operaciones de búsqueda en las

tablas de forma paralela. El código de estas entidades de

memoria fue desarrollado para que durante la sintesis las

construcciones infieran en recursos de RAM en bloque.

c) Pipelines: A modo de aumentar el throughput de

procesamiento de datos, se subdividió el procesamiento del

algoritmo en diferentes etapas que pueden funcionar en forma

aislada. Estas etapas se encargan en la gran mayoría de realizar el proceso de combinar las cajas SP con los datos de entrada. El

pipeline permitió que se procesen varios datos al mismo

tiempo.

VI. R ESULTADOS OBTENIDOS

Las métricas obtenidas de la ejecución del los componentesaceleradores de hardware desarrollados, así como también de laversión en software de la aplicación pueden verse en la tabla I.

En esta tabla se muestra que la aceleración obtenida alimplementar parte del algoritmo de la aplicación en un HPSoCcon un componente acelerador es de alrededor de 400X en

ambos casos. El throughput expuesto corresponde a lamedición del tiempo de ejecución de la función de SW queenvía los datos al componente acelerador.

Se muestra además en la tabla II un extracto del reporte dela síntesis del componente acelerador más significativo(desarrollado en ImpulseC) que muestra el porcentaje derecursos usados en la FPGA.

VII. CONCLUSIONES

En el presente trabajo se presentaron los beneficios, entérminos de performance, obtenidos a través de laimplementación de aceleradores criptográficos utilizando

HPSoCs.Las implementaciones realizadas muestran cómo es posible

incrementar la performance de una aplicación de softwarecorriendo en un sistema embebido en varios órdenes demagnitud. Los resultados comparativos mostraron que luego deaplicar la metodología propuesta se obtuvo una ganancia dealrededor de 400X en ambos casos.

En el presente trabajo se utilizaron además herramientas delestado del arte en el desarrollo de lógica programable paraimplementar el sistema embebido y los componentesaceleradores.

TABLA I. RESULTADOS DE IMPLEMENTACION HPSOC

CRIPTOGRAFICO

TABLA II. RESULTADOS DE SINTESIS HPSOC CRIPTOGRAFICO

Este trabajo concluye que la utilización de un HPSoC esuna alternativa técnicamente viable para mejorar la

performance de los sistemas digitales embebidos del mundoactual.

R EFERENCIAS

[1] [1] Wohlmuth, Otto, “High performance computing based on FPGAS”IEEE Field Programmable Logic and Applications, FPL, 2008.

[2] Ramakrishna, Rau and Fisher, Joseph, "Instruction-level parallel processing: History, overview, and perspective", The Journal of Supercomputing, Volume 7, Numbers 1-2.

[3] Meyer-Baese, Uwe, "Digital signal processing with field programmablegate arrays", Third Edition, Springer, pagina 589.

[4] D. Pellerin and S. Thibault, “Practical FPGA Programming in C”.Prentice Hall Professional Technical Reference, 2005.

[5] Pai, Vijay and Adve, Sarita, "Code transformations to improve memory parallelism", Proceedings of the 32nd annual ACM/IEEE international

symposium on Microarchitecture, Pages: 147 - 155, 1999.[6] Wolf, M.E, Chen, Ding-Kai, "Combining loop transformations

considering caches and scheduling", 29th Annual IEEE/ACMInternational Symposium on Microarchitecture, 1996.

[7] Bruce Schneier, “Applied Cryptography Second Edition”. John Wiley,2004.

[8] Federal Information Processing Standars Publication, “DATAENCRYPTION STANDARD (DES)”. FIPS PUB 46-3.

[9] PK Yuen, “Practical Cryptology and Web Security”. Pearson EducationLimited, Chap 4, 2006.

[10] Xilinx Documentation files, “EDK Concepts, Tools, and Techniques”.

[11] Shenoy, "Accelerating Software Applications Using the APU Controller and C-to-HDL Tools", Xilinx Application note XAPP 901.

Implementación

HPSoC TripleDES

Frecuencia

de operación

Throughput

(aplicación

userspace)

Ganancia

Software 300 Mhz 42.096 Kbps 1X

Hardware

ImpulseC

50 Mhz 17.929 Mbps 415X

Hardware

VHDL50 Mhz 19.280 Mbps 458X

HPSoC con componente desarrollado en ImpulseC

Recurso Utilización Porcentaje

de uso

BUFGs 11 out of 32 34%

DCM_ADVs 2 out of 4 50%

ILOGICs 29 out of 320 9%

External IOBs 73 out of 240 30%

LOCed IOBs 73 out of 73 100%

OLOGICs 54 out of 320 16%

RAMB16s 26 out of 36 72%

SLICES 5470 out of 5472 99%

SLICEMs 355 out of 2736 12%



70






71




Linux Embebido



72






73




El papel del Hardware copyleft en la Ensenanza deSistemas Embebidos

Carlos I. Camargo Bareno

Universidad Nacional de Colombia,Email: [email protected]

Abstract—El gran avance de las tecnicas de fabricacion deCircuitos Integrados ha permitido que los sistemas embebidossean parte fundamental de nuestras vidas, aun sin darnos cuentadiariamente interactuamos con decenas de ellos. Esto unido a ladisponibilidad de herramientas software de desarrollo gratuitasabre grandes posibilidades comerciales para paises en vıa dedesarrollo ya que no son necesarias grandes inversiones de capitalpara la concepcion, dise ˜ no, y fabricacion de estos sistemas. Sinembargo, en la actualidad muy pocas universidades ofrecencursos que permitan crear las habilidades necesarias para la

realizacion de un producto comercializable, lo que se traduceen un abandono de la produccion local y el aumento de ladependencia con la industria manufacturera asiatica. por otrolado, las herramientas utilizadas en la actualidad (tanto SW comoHW) proporcionan un nivel de abstraccion relativamente altoimpidiendo que el estudiante entienda el funcionamiento globalde un sistema digital, lo que le impide generar habilidades (especi-ficamente las relacionadas con la concepcion e implementacion)necesarias para realizar el proceso completo. En este artıculo sepresenta una metodologıa para la ense ˜ nanza de dise ˜ no de sistemasembebidos utilizando herramientas hardware y software abiertasque ayuda a resolver los problemas mencionados anteriormente.

Index Terms—Sistemas Embebidos, educacion en ingenierıa,hardware copyleft.

I. INTRODUCCION

El mercado de los sistemas embebidos continua en aumento

y su campo de accion se ha extendido en casi todas las

actividades humanas. Segun BBC, inc. el mercado para el

software embebido crecio de $1.6 billones a $3.5 billones en

2009, con una tasa de crecimiento anual (AAGR) del 16%,

mientras la tasa de crecimiento para las tarjetas embebidas

es del 10%; segun Venture Development Corporation (VDC)

mas de un billon de dispositivos embebidos fueron vendidos

en el 2004,. De acuerdo con VDC el porcentaje de dispositivos

basados en sistemas operativos comerciales tiende a disminuir

del 43.1% en 2001 a 37.1% en 2004, esta tendencia se debe a

la utilizacion de herramientas de libre distribucion GNU/Linux

[1].

En la actualidad estamos presenciando una tendencia global

a delegar las tareas de manufactura de sistemas digitales a

paises asiaticos, donde la mano de obra calificada es abundante

y barata; se presentan casos donde los creadores de una deter-

minada tecnologıa no la desarrollan y dejan que estos paises

se beneficien de sus descubrimientos [2] reduciendo de forma

considerable la produccion. Esta situacion se agrava a me-

dida que las grandes empresas manufactureras asiaticas como

Foxconn capturan la produccion de los grandes disenadores

como Apple, Nokia, DELL, HP y Microsoft, lo que genera el

cierre de empresas manufactureras a lo largo del mundo, con

la consecuencia de perdida de empleo masivo. En la actualidad

segun Bureau of Labor Statistics y Thomson Financial Extel

Company Report Foxconn emplea a mas personas que Apple,

Dell, Micorsoft, HP, Intel y Sony combinados; esta situacion

es mas grave en paises en vıa de desarrollo, donde no existe

la plataforma tecnologica para disenar dispositivos digitales,

y son importadores de tecnologıa sin la capacidad de generar

productos que satisfagan necesidades locales. Lo anterior lleva

a preguntarse por la funcion y la situacion de un profesional

en areas afines a la ingenierıa electronica en paıses donde no

existe la capacidad de concepcion y diseno.

La tendencia moderna en los programas academicos a la

utilizacion de herramientas de alto nivel para la ensenanza

en areas afines al desarrollo de dispositivos digitales [3]

ocasiona que los profesionales no adquieran las habilidades

necesarias para completar la cadena concepcion - diseno -

implementacion y operacion, en la mayorıa de los casos se

generan habilidades para la concepcion y el diseno a alto

nivel y dejan los otros pasos en manos de herramientas

especializadas y/o a empresas asiaticas. Esta situacion resultala mas atractiva desde el punto de vista economico, ya que no

es necesario adquirir maquinaria costosa ni contratar personal

calificado para operarlas; sin embargo, limita la generacion

de empleo local a personas con un nivel de formacion alto

[2] generando desempleo en las personas menos capacitadas.

Segun John Hall presidente y CEO de Linux International “

algunas facultades preparan a la gente en el uso de productos

en vez de tecnologıas de nivel basico” [3]. Esta situacion unida

al abandono de la implementacion hace que la dependencia

con las empresas manufactureras asiaticas aumente cada vez

mas.

Segun el ex-director ejecutivo de Intel Andy Grove [2] la

solucion esta en hacer de la creacion de empleo la polıtica

economica gubernamental mas importante y hacer que las

demas giren en torno a ella. Ademas, es necesario volver a

la produccion interna con el fın de generar nuevos empleos,

y volver a adoptar medidas que protejan la produccion in-

terna de los productos asiaticos. Sin embargo, para lograrlo

es necesario crear en los profesionales las habilidades para

implementar productos comercializables.

En este artıculo presentamos un programa academico

basado en la utilizacion de software y hardware libre para el

area de electronica digital que desarrolla las habilidades nece-



74




sarias para Concebir, Disenar Implementar y operar sistemas

digitales.

A. Flujo de dise˜ no de sistemas embebidos

Los Sistemas Embebidos son sistemas heterogeneos que

contienen componentes Software (microcontroladore, micro-

procesadores y DSPs) y Hardware (funciones implementadas

en Dispositivos logicos programables PLDs); por este motivo,es necesario adquirir habilidades en la utilizacion de lenguajes

de programacion como C o C++ para implementar las fun-

ciones software y Verilog o VHDL para la implementacion

de las tareas hardware; adicionalmente, deben conocer las

diferentes formas de comunicacion entre estos dos tipos de

funciones. Aunque en el mercado existen herramientas que

permiten la entrada de diseno utilizando lenguajes de alto

nivel como SystemC o SpecC y proporcionan el codigo para

implementar las tareas software, hardware y su interfaz de

comunicacion; no es recomendable utilizarlas en el ciclo de

formacion basico ya que impide que se conozca el flujo de

diseno completo, suministrando un nivel de abstraccion en el

cual no es necesario conocer la arquitectura de la plataforma

utilizada para la implementacion.

En la figura 1 se muestran los conceptos que deben dominar

los disenadores de sistemas embebidos, y las tareas que

deben realizarse para la concepcion, diseno e implementacion

de un sistema embebido. En gran parte de los programas

academicos se estudian unicamente los temas relacionados con

la concepcion y diseno centrandose en las especificaciones

funcionales del sistema, utilizando herramientas comerciales

o COTS (Commercial off-the-shelf) para su implementacion.

Esta combinacion genera dependencia e impide la generacion

de habilidades necesarias para implementar un sistema dig-

ital teniendo en cuenta restricciones economicas, fısicas,electricas, ergonomicas, comerciales, etc. Nuestra propuesta se

basa en la utilizacion de herramientas abiertas tanto hardware

como software que permiten recorrer todo el proceso de con-

cepcion, diseno e implementacion y obtener un entendimiento

integral del proceso sin generar dependencia a productos

comerciales.

1) Dominios de Dise˜ no y Niveles de abstracci ´ on: Existen

tres dominios en los que se puede describir un sistema

digital [5] Funcional: Describe el comportamiento funcional y

temporal del sistema Estructural: Describe su composicion a

partir de bloques basicos y F ısico relacionado con la estructura

f ısica del sistema a nivel de circuito integrado o placa de

circuito impreso [6]. Cada uno de estos dominios puede ser

descrito utilizando diferentes niveles de abstraccion; un nivel

de abstraccion alto permite el uso de lenguajes de alto nivel

facilitando la entrada de diseno al extraer la funcionalidad de

la parte f ısica; por otro lado, los niveles de abstraccion bajo

utilizan bloques constructores elementales.

En el mercado existen herramientas que permiten entradas

de diseno a nivel funcional utilizando especificaciones y

algorıtmos y de forma automatica y optimizada generan repre-

sentaciones en diferentes niveles de abstraccion en los domin-

ios estructural y fısico. Es decir, a partir de las especificaciones

Fig. 1. Educacion de sistemas embebidos. Tomada de: [4] y modificada

y algoritmos que indican el funcionamiento del sistema pueden

generar archivos para la fabricacion de un circuito integrado

o archivos de configuracion/programacion que pueden ser

utilizados en dispositivos comerciales. Desde el punto de vista

comercial esto es muy util ya que permite reducir el tiempo

de diseno y los costos asociados. Sin embargo, presentan los

inconvenientes mencionados anteriormente y por lo general

son muy costosas.

II . METODO PARA LA ENSE NANZA DE SISTEMAS

EMBEBIDOS

Basandose en la metodologıa de diseno para sistemas embe-bidos [7], en los dominios de diseno y niveles de abstraccion

de Gajski-Kuhn, se realizo una division de temas que busca

crear habilidades de forma gradual e incremental. En la Figura

4 podemos observar esta division y las herramientas que

se utilizaran en cada curso, como herramienta de desarrollo

hardware se utilizara una plataforma que proporcione los

archivos y documentos necesarios para replicarla, modificarla

y pueda ser utilizada como base de desarrollos comerciales.

A. SIE: Plataforma abierta para el desarrollo de sistemas

embebidos

En el mercado existe una gran variedad de plataformas que

pueden ser utilizadas en el estudio de sistemas embebidos,

sin embargo, no todas son adecuadas para la implementacion

del metodo que proponemos ya que se requiere: acceso a los

esquematicos y a los archivos de fabricacion del PCB con posi-

bilidad de modificacion; acceso a la documentacion completa

del proceso de fabricacion; acceso a la cadena de produccion;

utilizacion de herramientas abiertas para su programacion; un

PLD para la implementacion de tareas HW; un procesador para

la implementacion de tareas SW; un canal de comunicacion

entre el procesador y el PLD; y una comunidad que desarrolle

aplicaciones para dicha plataforma y que proporcione medios



75




para el intercambio de informacion a traves de listas de correo

y wikis.

Despues de una busqueda minuciosa no se encontraron

plataformas que cumplieran con estas condiciones, en especial

con las relacionadas con el proceso de diseno y de produccion,

esto es normal, ya que la mayorıa de las empresas no quieren

que se fabriquen sus plataformas y los proyectos individuales

no poseen la infraestructura necesaria para la produccionmasiva. Por este motivo, se decidio crear una plataforma que

cumpliera con los requerimientos (plataforma SIE ), para ello

se buscaron proyectos similares que permitieran su creacion y

que el producto creado sea una extension de dicho proyecto.

El proyecto Qi-Hardware [8] busca definir el concepto copyleft

hardware basandose en el movimiento de software libre y

codigo abierto (FOSS [9]) y proporciona un enlace con la

industria manufacturera asiatica.

1) Hardware copyleft: El proyecto SIE [10] fue creado

para satisfacer las necesidades de los desarrolladores de hard-

ware permitiendo la creacion de aplicaciones comerciales

bajo la licencia Creative Commons BY - SA [11] la que

permite la distribucion y modificacion del diseno (incluso para

aplicaciones comerciales), con el unico requisito de que los

productos derivados deben tener la misma licencia y deben

dar credito al autor del trabajo original. Lo que constituye la

base de los productos hardware copyleft .

Al ser inspirado en el movimiento FOSS, los dispositivos

hardware copyleft comparten la misma filosofıa [9], y son

el complemento perfecto del software libre. Para que un

dispositivo HW sea reproducible y modificable es necesario:

suministrar los archivos necesarios para la fabricacion, es

decir, los esquematicos y los archivos de la placa de circuito

impreso (preferiblemente para herramientas abiertas como

Kicad o geda); la cadena de herramientas de compilaci on ydepuracion para desarrollo de aplicaciones; el codigo fuente

de: el programa que inicializa la plataforma (bootloader ),

la herramienta que carga dicho programa en la memoria

no volatil (usbboot ), el sistema de archivos y aplicaciones

(openwrt ); documentacion completa que indique como fue

disenada, construida, como utilizarla, desarrollar aplicaciones

y tutoriales que expliquen el funcionamiento de los diferentes

componentes. (esto puede ser descargado de [12] y [13]). Adi-

cionalmente, se debe contar con la posibilidad de fabricacion

y montaje, lo que constituye la principal diferencia entre el

software y el hardware libre.

2) Arquitectura: La Figura 2 muestra el diagrama de blo-

ques de la plataforma SIE, en ella encontramos un proce-

sador que posee perifericos para comunicacion serial (UART),

memorias micro-SD, un puerto I2C, controlar un LCD a

color de 3 pulgadas, 2 entradas y salidas de audio stereo,

2 entradas analogas; una FPGA que proporciona 25 senales

de entrada/salida digitales de proposito general (GPIOs) y

controla un conversor analogo digital de 8 canales. Existen tres

canales de comunicacion entre la FPGA y el procesador: uno

para controlar el puerto JTAG, lo que permite la configuracion

de la FPGA desde el procesador (eliminando la necesidad

de cables de programacion); otro que proporciona el bus de

datos, direccion y control para comunicarse con las tareas HW

o perifericos implementadas en la FPGA y un puerto serial

utilizado para depuracion de softcores implementados en la

FPGA. El procesador utilizado es un Ingenic JZ4725 (MIPS)

corriendo a 400MHz, se dispone de una memoria NAND de

2GB para almacenamiento de datos y programas, ası como de

una memoria SDRAM de 32 MB, lo que permite la ejecucion

de una gran variedad de aplicaciones Linux.

Fig. 2. Estructura de la plataforma de desarrollo SIE

3) Comunicaciones: SIE proporciona un canal de comu-

nicacion y alimentacion a traves del puerto USB-device, y

es configurado para ser utilizado como una interfaz de red

(usb0), permitiendo la transferencia de archivos y ejecucion de

una consola remota utilizando el protocolo ssh; este canal de

comunicacion tambien se utiliza para programar la memoria

NAND no volatil, por lo que para realizar la programacion

completa de los componentes de la plataforma solo es nece-sario un cable USB.

4) Especificaciones f ısicas: Las dimensiones de SIE son

8cm de largo, 8 cm de ancho, 1cm de altura; su placa de

circuito impreso es de dos capas, utiliza lıneas de 8 mils, vıas

de 12 mils de diametro, los componentes se encuentran en una

sola capa y son TQFP o SMD, no posee componentes BGA

o QFN lo que facilita el montaje manual. Todo esto hace que

sea posible la reproduccion y modificacion de esta plataforma

a un precio muy bajo. El costo de fabricacion de esta tarjeta

se estima en 70 usd para 50 unidades. La figura 3 muestra la

apariencia de la plataforma de desarrollo SIE.

B. Curso b´ asico

Para el curso basico se trabajara la mayor parte de los

niveles de abstraccion del dominio funcional; partiendo de

unas especificaciones funcionales se generara un modelo

del sistema utilizando algoritmos que describan el compor-

tamiento de las diferentes tareas que implementan el sistema

(bloques funcionales). Estos bloques seran implementados, en

dispositivos logicos programables como FPGAs o CPLDs.

A partir de estos algoritmos se identifican las operaciones

basicas aritmeticas y logicas que modifican los datos asociados

a cada funcion para generar el camino de datos (datapath;



76




Fig. 3. Plataforma de desarrollo SIE

el datapath proporciona senales que controlan el instante en

el que se ejecutan la operaciones soportadas, dichas senales

deben ser generadas por un modulo disenado para implementar

el algoritmo deseado; estos dos modulos se implementaran

con bloques logicos basicos y maquinas de estados finitos

utilizando lenguaje de descripcion de hardware (VHDl, verilog

estandard). Estas descripciones son la entrada a herramientas

que realizaran la transicion al dominio estructural generando

las compuertas logicas, flip-Flops y las interconexiones que

implementen la funcionalidad requerida. Durante el proceso

es necesario realizar simulaciones (utilizando icarus verilog

y ghdl) que permitan comprobar el cumplimiento de las

especificaciones iniciales, si no se cumple alguna de ellas se

debe volver a repetir el proceso.

Durante el desarrollo del primer curso se estudiaran los

conceptos basicos de los sistemas digitales como sistemasnumericos, operaciones aritmeticas y logicas, logica combi-

natoria y secuencial. Se utilizaran lenguajes de descripcion de

hardware como VHDL y verilog como entrada de diseno a

herramientas que realizan la sıntesis digital. Para evitar crear

dependencia, se ensenara la forma de adecuada de implementar

codigo re-utilizable que no utilice componentes especıficos de

un determinado fabricante.

1) Dise˜ no de aplicaciones utilizando HDL y PLDs: Para

generar las habilidades necesarias para concebir, disenar, im-

plementar y operar sistemas digitales, se realizaran practicas

sencillas que ayuden al estudiante a entender los mecanismos

de implementacion de tareas HW en un dispositivo logico

programable utilizando la plataforma de desarrollo SIE; como

puede verse en la figura 2 la FPGA solo controla un conversor

analogo digital serial de 8 canales, y proporciona 25 GPIOs,

esto se hizo de forma intencional para que los estudiantes

se vean forzados a realizar las conexiones electricas de

los dispositivos externos a sus aplicaciones; las plataformas

comerciales proporcionan una gran variedad de dispositivos

conectados a los PLDs, lo que no es muy recomendable ya

que el estudiante no aprende a leer la hoja de especificaciones

del fabricante de un determinado dispositivo para determinar

su forma de conexion, y/o las condiciones que se deben

tener en cuenta para su correcto funcionamiento; afectando

la generacion de habilidades necesarias para la eleccion de

componentes, realizacion y lectura de esquematicos y diseno

de layouts.

El procesador de la plataforma SIE sera utilizado como

camino de configuracion de la FPGA; el archivo de configu-

racion sera descargado al sistema de archivos de la plataforma

SIE utilizando el protocolo ssh y la interfaz de red USB; unprograma en espacio de usuario se encarga de configurar la

FPGA con el archivo deseado. Adicionalmente, existe una

aplicacion basada en el proyecto urjtag ejecutandose en el

procesador que permite la generacion de vectores de prueba

y recoleccion de resultados utilizando el puerto JTAG [14], lo

que permite que el estudiante pueda probar su circuito a baja

frecuencia sin instrumentos de medicion adicionales.

C. Arquitectura de Computadores

En este curso se trabajara en el dominio estructural comen-

zando desde los componentes basicos de una CPU hasta llegar

a la arquitectura de un sistema sobre silicio (SoC), esto con

el fın de conocer y entender la arquitectura y funcionamiento

de los dispositivos en los que se ejecutan las tareas software.

Se utililizaran perifericos conectados a traves de buses a la

CPU para implementar tareas hardware. Se realizara la im-

plementacion de un Sistema sobre silicio (SoC) y se trabajara

con herramientas de libre distribucion (cadena de herramientas

GNU [1]) para programar aplicaciones que involucren el uso

de tareas HW y SW.

1) Arquitectura de una CPU y tareas SW: Utilizando

procesadores softcore se estudiaran los componentes basicos

de la CPU, el camino de datos: banco de registros, bloques ar-

itmeticos, logicos y buses internos, se analizaran las diferentes

instrucciones que proporciona la arquitectura bajo estudio y seanalizara el funcionamiento de la maquina de control, iden-

tificando los componentes que permiten el almacenamiento y

ejecucion secuencial de instrucciones definidas por el usuario.

En este punto se introduciran los conceptos de llamado a fun-

ciones, atencion de interrupciones, direccionamiento directo e

indirecto y acceso a memoria externa.

Para este estudio, se utilizaran procesadores implementados

en lenguajes de descripcion de hardware que cuenten con

herramientas de programacion de bajo (assembler) y alto nivel

(C, C++), con el fin de realizar simulaciones, aplicaciones

y modificaciones. Al finalizar el curso se pretende que el

estudiante entendienda las diferencias entre tareas software y

tareas hardware y podra realizar experimentos que le permitan

comparar las caracterısticas de ambas implementaciones. En

la actualidad se esta trabajando con los SoC plasma basado

en un procesador MIPS, MICO 32 de lattice, y openrisc de

OpenCores, implementados en VHDL o Verilog.

Se utilizaran los perifericos para la implementacion de tar-

eas HW y se estudiaran las diferentes formas que existen para

comunicarse con las tareas SW (buses, interrupciones, polling)

presentando los criterios de seleccion para la implementacion

de tareas SW y HW. Se introducira el concepto de mapa

de memoria, decodificador de direcciones, memorias volatiles



77




(ejecucion de programas y de uso general) y memorias no

volatiles (almacenamiento de programas). Se introducira el

concepto de bootloader y su uso en la carga de aplicaciones

a las memorias volatiles internas y externas del SoC. Y

finalmente se mostraran los diferentes metodos existentes para

programar las memorias no volatiles.

Utilizando la cadena de herramientas GNU, se realizara

el flujo de desarrollo para tareas SW desde la entrada dediseno utilizando el lenguaje C, hasta la generacion del archivo

binario que contiene las instrucciones (para la CPU en estudio)

que implementan dicha tarea. Utilizando herramientas propias

se generaran los archivos para inicializar la memoria de

programa (implementada en la FPGA) con estas instrucciones.

2) Dise˜ no de aplicaciones que involucren co-dise˜ no HW-

SW: Tanto la CPU, los perifericos, la memoria ram y la

memoria de programa estaran implementados en la FPGA

de SIE. Durante todo el periodo academico se desarrollara

un proyecto de complejidad media que involucre el uso de

tareas HW y SW, (en la pagina de la plataforma [13] se

pueden observar los proyectos realizados hasta el momento);para esto se formaran equipos de trabajo de 3 personas

que deben hacer una propuesta inicial (concepcion y es-

pecificaciones), realizar la descripcion funcional del sistema

utilizando algoritmos (diseno y modelo del sistema), realizar

el particionamiento en funciones HW y SW, implementar estas

funciones y disenar una placa de circuito impreso (utilizando

kicad ) con lo necesario para implementar la funcionalidad

requerida (implementacion). Se realizaran entregas periodicas

para verificar el cumplimiento del cronograma propuesto por el

equipo de trabajo y el proceso de diseno debe ser documentado

en la pagina wiki del curso. Esta actividad generara habilidades

de trabajo en equipo, elaboracion de esquematicos, fabricacion

de PCBs, escritura de documentos tecnicos e implementacionde sistemas digitales.

SIE permite conectar de forma f acil (usando dos jumpers)

dos GPIOs de la FPGA a las senales de transmision y re-

cepcion del procesador, lo que permite la comunicacion serial

entre el procesador implementado en la FPGA y el procesador

MIPS, creando de esta forma un canal de depuracion para

las aplicaciones implementadas en la FPGA, eliminando la

necesidad de equipo adicional.

D. Sistemas Embebidos

El tercer y ultimo curso de la lınea integra los conocimientos

adquiridos en los cursos anteriores e introduce un elemento

nuevo un SoC comercial, SIE posee un SoC basado en

un procesador MIPS equipado con los recursos necesarios

para ejecutar programas Linux; en este curso se estudiara la

arquitectura de los SoC comerciales, las herramientas de pro-

gramacion abiertas disponibles (cadena de herramientas GNU,

librerıas GNU como libQT), cargadores de Linux (u-boot), el

sistema operativo Linux, drivers de perifericos, distribuciones

para sistemas embebidos (openwrt, openembedded, debian).

Con esto el estudiante estara en capacidad de crear aplica-

ciones que utilizan la gran variedad de librerıas disponibles en

Fig. 4. Metodologıa de Diseno para el area de Sistemas Digitales

el proyecto FOSS, las mismas que utilizan Nokia, Motorola,

Dell, Sony.

1) Creaci´ on de perif ericos y drivers : Ademas de cubrir

el tema de programacion de SoC utilizando GNU/Linux, esnecesario que se entienda no solo el funcionamiento del

sistema operativo Linux, sino como este se comunica y con-

trola los perif ericos (tareas HW); para esto, se implementaran

perif ericos en la FPGA y se estudiara la forma de acceder a

ellos utilizando el protocolo establecido por el kernel.

2) Concepci´ on, Dise˜ no, Implementaci´ on y Operaci´ on de

Sistemas Embebidos: Durante el periodo academico los es-

tudiantes deben disenar, implementar y operar un sistema

embebido concebido por un equipo de trabajo de tres per-

sonas, utilizando como base la plataforma SIE, disenaran una

tarjeta hija (utilizando kicad) que implemente la funcionalidad

deseada, todos los proyectos deben integrar tareas HW en la

FPGA con modulos del kernel para su control. Los proyectos

realizados hasta el momento pueden encontrarse en la pagina

del proyecto.

E. Comunidad hardware copyleft

Una parte importante de este metodo de ensenanza es la

filosofıa del proyecto hardware copyleft, por esta razon, cada

grupo debe hacer un aporte, suministrando la informacion

completa del proceso de desarrollo, los archivos necesarios

para replicar y/o modificarlo, esto es una consecuencia de la

licencia CC-BY-SA.



78




La experiencia del proyecto FOSS indica muchos miem-

bros de estas comunidades ingresan para suplir necesidades,

pero muchos de ellos continuan creando codigo y prestando

servicios a la comunidad porque disfrutan programar. Estos

aficionados realizan un papel muy importante dentro de la co-

munidad encargandose de tareas como mejora de la plataforma

tecnologica, re-escribiendo secciones de codigo, documentan-

dolo, respondiendo preguntas, preservando o mejorando laarquitectura [15]. Las actividades de documentacion ademas

de contribuir a mejorar las habilidades de escritura de reportes

tecnicos ayudan a formar una comunidad que contribuye

al crecimiento del proyecto copylef harware, los estudiantes

ingresan a las listas de desarrolladores aprendiendo a utilizar

una herramienta muy poderosa en la que pueden compartir

sus inquietudes con miembros mas experimentados y mientras

participan ayudan a crear un banco de preguntas que pueden

ser utiles para futuros miembros. Adicionalmente se obliga a

expresarse en un idioma diferente.

Crear estos habitos ayuda a que los jovenes sean conscientes

de su papel dentro de la comunidad y piensen que sus acciones

pueden ayudarla o perjudicarla, los proyectos realizados por

ellos podran ser parte de los recursos de la comunidad (si la

calidad del trabajo lo amerita) y pueden ser la continuaci on

de un esfuerzo prolongado o el punto de partida de un nuevo

conocimiento; la licencia CC-BY-SA garantiza que todos los

trabajos derivados de este recurso seran parte del mismo, lo

que garantiza su crecimiento, la labor de los estudiantes es vi-

tal para el uso del recurso comun y puede crear miembros que

en un futuro formularan polıticas y reglas de uso del recurso.

Por otro lado, participar en este tipo de proyectos permite crear

reputacion, la cual puede ser util para establecer relaciones

profesionales, de negocios o personales. El entorno academico

es ideal para atraer nuevos miembros a la comunidad hardwarecopyleft, ya que se trabaja con jovenes con deseos de ser parte

de un grupo y de adquirir conocimientos. Desde el punto de

vista comercial este recurso es muy atractivo ya que permite

ahorrar mucho tiempo, esfuerzo y dinero para la creacion de

nuevos productos. Por otro lado, el concepto de hardware

copyleft es una herramienta poderosa para transferir tecnologıa

y conocimientos a los paıses en vıa de desarrollo donde la

plataforma tecnologica no se lo suficientemente desarrollada.

III. CONCLUSIONES

El hardware copyleft es una herramienta poderosa para

la creacion de habilidades necesarias para concebir, disenar,

implementar y operar sistemas digitales, ya que proporciona

la informacion necesaria para entender el ciclo completo de

diseno, (lo cual no es posible obtener cuando se trabaja

con plataformas de desarrollo comerciales); proporcionando

informacion detallada sobre el proceso de diseno de platafor-

mas abiertas, que pueden ser utilizadas como referencia para

generar nuevos productos comerciales; el acceso a aplicaciones

software que permiten la creacion de aplicaciones; un canal de

comunicacion que permite utilizar a la industria manufacturera

asiatica para la produccion en masa; conocimiento de los

procesos de fabricacion y produccion.

Las actividades propuestas en las tres asignaturas del area

tienen como objetivo generar en el estudiante las habilidades

necesarias que le permitan disenar sistemas digitales con

grado de complejidad creciente, hasta llegar a un sistema que

puede ser comercializable y satisface una necesidad de una

determinada comunidad, con esto, se evita que el ultimo paso

en el proceso de ensenanza sea la simulacion; se ilustra el

proceso que debe seguirse para que un prototipo se conviertaen un producto comercial, lo que contribuira con la creacion

de nuevos productos y la generacion de empleo.

La utilizacion de herramientas de bajo nivel permite que

el estudiante conozca y controle los diferentes pasos de la

metodologıa de diseno y sea capaz de ajustarlas para diferentes

situaciones, esto hace que se adquiera un conocimiento sobre

la tecnologıa sin crear dependencia hacia las herramientas

comerciales que realizan la mayorıa de los pasos de la

metodologıa de forma automatica.

REFERENCES

[1] R. M. Stallman. The GNU Operating System and the Free Software

Movement Voices from the Open Source Revolution. O’Reilly andAssociates, 1999.

[2] A. Grove. How America Can Create Jobs.http://www.businessweek.com/magazine/content/10 28/b418604835 8596.htm,May 2010.

[3] Jon Hall. POR GRANDES QUE SEAN...: ASEGURE EL FUTURODE SU NEGOCIO. Linux magazine,, ISSN 1576-4079(58):92, 2009.

[4] H. Mitsui, H. Kambe, and H. Koizumi. Use of Student Experimentsfor Teaching Embedded Software Development Including HW/SW Co-Design. IEEE TRANSACTIONS ON EDUCATION,, 52(3), August 2009.

[5] A. Gerstlauer, D. Gajski., . Technical Report CECS-02-17, and 2002.CECS, UC Irvine. System-level abstraction semantics, Technical ReportCECS-02-17. Technical report, CECS, UC Irvine, 2002.

[6] Gajski D.D., Abdi S., Gerstlauer A., and Schirner G. Embedded System

Design: Modeling, Synthesis, Verification. Springer, 2009.[7] Luis Alejandro Cortes. Verification and Scheduling Techniques for Real-

Time Embedded Systems. PhD thesis, Link opings universitet Institute of Technology, 2005.

[8] Qi Hardware. Qi Hardware Copyleft Hardware Project. URL:http://en.qi-hardware.com/.

[9] R. Stallman. Philosophy of the GNU project. URL:http://www.gnu.org/philosophy/, 2007.

[10] W. Spraul, C. Camargo, and A. Wang. Proyecto SAKC.URL:http://en.qi-hardware.com/wiki/SAKC .

[11] Creative Commons. Licencias Creative Commons. URL:http://creativecommons.org/licenses., 2004.

[12] C. Camargo. Proyecto SIE: Descargas. http://projects.qi-hardware.com/index.php/p/nn-usb-fpga/source/tree/master/, 2010.

[13] C. Camargo. Proyecto SIE: Documentacion. http://en.qi-hardware.com/wiki/SAKC, 2010.

[14] Texas Instruments. IEEE Std 1149.1 (JTAG) Testability. 1997 Semi-

conductor Group, 1996.[15] S. Shah. Motivation, Governance, and the Viality of Hybrid Forms in

Open Source Software Development. Management Science, July 2006.



79




Desarrollo de un equipo para grabar los sonidos

de los bovinos a la intemperie

S. Reyes, V. Olivera, M. C. San Román y J. P. OliverFacultad de Ingeniería, Universidad de la República

Montevideo, [email protected], [email protected], [email protected], [email protected]

Resumen—En este trabajo se presenta un dispositivo capaz degrabar y almacenar el sonido que emiten los bovinos durantela masticación e ingesta de forraje. Este dispositivo, junto conun software capaz de detectar las actividades realizadas porel animal (pastoreo, rumia y descanso) a partir de las señalesde audio obtenidas, forma parte del prototipo Monitoreo delSonido Bovino (MOSOBO). A partir de estos datos es posible

determinar en qué momento del día y durante cuánto tiempoel animal realizó alguna actividad, lo que permite estudiar elcomportamiento ingestivo de los rumiantes.

El dispositivo tiene una autonomía energética de más de 24horas, graba y almacena audio de alta calidad, no afecta elcomportamiento del animal, es de fácil colocación, bajo costo,estable y robusto.

Debido a la buena calidad del audio adquirido y al proce-samiento realizado a la señales de audio se lograron excelentesresultados al reconocer las diferentes actividades que el animalrealiza (pastoreo, rumia y descanso).

Index Terms—SBC, Linux embebido

I. INTRODUCCIÓN

El objetivo de este trabajo fue desarrollar a nivel de pro-totipo un dispositivo capaz de grabar el sonido que realizanlos bovinos durante la masticación e ingesta de forraje, juntocon un paquete de software que corre en un PC, capazde determinar y desplegar qué actividades realizó el animal(pastoreo, rumia o descanso), en qué orden y la duración delas mismas.

El comportamiento animal en pastoreo es resultado defactores abióticos (distancia al agua, la temperatura, la luz,el pH, el suelo, nutrientes, pendiente) y factores bióticos(cantidad y calidad del forraje por animal, estado fisiológicoy metabólico del animal)[1]. Justamente la cantidad de forrajeconsumida por el animal depende del tiempo de pastoreo y su

tasa de consumo[2].Existen situaciones en las que el consumo de energía del

animal no se modifica pero su productividad se ve modifi-cada como consecuencia de tener diferente comportamientoingestivo. La medición del comportamiento y del consumo deenergía contribuiría a explicar gran parte de los resultados enproductividad animal a nivel experimental y comercial.

Los requisitos principales del dispositivo consistieron en queel sistema fuera robusto (ya que se utiliza a la intemperie juntocon el animal), que tuviera autonomía energética por más de24 horas, fuera económico, de fácil colocación y bajo peso,y que fuera inofensivo y no modificara el comportamiento delos animales.

Con respecto al software el requisito principal fue el de sercapaz de identificar 3 actividades bien diferenciadas (pastoreo,rumia y descanso), en qué momento son realizadas y laduración de las mismas.

Este trabajo se basó en las conclusiones de algunas inves-tigaciones sobre el comportamiento de los rumiantes y los

sonidos que los mismos emiten en las distintas etapas de ladigestión[3].En las siguientes secciones se describen los componentes se-

leccionados para realizar el dispositivo y como se implementóel software del sistema embebido. Finalmente se mencionanlas conclusiones y perspectivas de este trabajo.

II. HARDWARE

Para poder determinar los requerimientos de frecuenciade muestreo y cantidad de bits del dispositivo de grabaciónfue necesario conocer qué características tenían los sonidosemitidos por los bovinos. De la buena elección de estosrequerimientos dependía el éxito del software de análisis y

reconocimiento.Por está razón, primero se realizaron varios ensayos para

obtener señales de audio de los sonidos emitidos por losbovinos. Luego de procesar dichas señales, se determinaronlos requerimientos del dispositivo y se seleccionaron loscomponentes.

Ensayos preliminares

Para obtener las señales de audio, se seleccionaron varioscomponentes con distintas características y se realizaron variosensayos en 2 vacas distintas (Ver Figura 1).

Procesamiento digital de las señales

Para analizar las señales obtenidas a partir de los ensayos,se utilizó el software Wavesurfer . Con el mismo se observarony obtuvieron los segmentos de las señales que aportaroninformación útil.

En la Figura 2(a) y en la Figura 2(b) se pueden observaralgunas secuencias representativas de las actividades de rumiay pastoreo respectivamente.

La Figura 2(a) no brinda información sobre la frecuenciamínima de muestreo, pues se obtuvo con un reproductormp3 el cual muestrea a 8 kHz. Sin embargo, se puede notarfácilmente que la señal presenta un patrón rítmico.

En la Figura 2(b) se pueden identificar componentes deseñal de interés de hasta 6 kHz. Esta señal a diferencia de



80




(a) (b) (c)

Figura 1. Ensayos realizados para adquirir las señales a analizar

(a) Señal de audio emitida por un bovino durante larumia.

(b) Señal de audio emitida por un bovino durante elpastoreo.

Figura 2. Señlaes obtenidas a partir de los ensayos.

la anterior, fue obtenida con un micrófono de PC y una

computadora.

Determinación de los requerimientos

El artículo “Computational method for segmentation and

classification of ingestive sounds in sheep”[4] propone un

método novedoso para análizar y reconocer automaticamente

señales sonoras emitidas por ovinos al realizar pastoreo y

rumia1.

En base a este artículo y a las características presentes en

las señales observadas durante el procesamiento digital de

las mismas se decidió que el dispositivo de grabación debía

muestrear al menos a 22 kHz y tener una resolución de al

menos 12 bits.

Teniendo en cuenta que el dispositivo debía ser capaz de

grabar el sonido emitido por los rumiantes durante 24 horas,

al obtener las señales a 22 kHz, 12 bits, fue necesario contar

con una memoria no volátil de al menos 3,5 GB.

Era indispensable que el dispositivo permaneciera en el

animal durante 1 día sin interrupción, por lo que la batería

debía ser capaz de alimentar el dispositivo durante este tiempo.

Además debe tener un factor de forma aceptable y ser liviana.

Teniendo en cuenta el presupuesto con el que contaba el

proyecto y la relación entre la capacidad de las baterías y

su peso, concluimos que la placa debía consumir menos de

1,5 W.

Uno de los objetivos del proyecto fue determinar en qué

momento del día el animal realizó cada actividad, por lo queera necesario incluir un reloj de tiempo real.

Una de las características deseables del dispositivo era la

capacidad de interactuar con el usuario, para lo cual se decidió

utilizar LEDs y botones.

Del análisis de los distintos requerimientos del sistema se

llegó a la siguiente especificación:

Muestreo a 22 kHz, al menos 12 bits.

Memoria no volátil de 3,5 GB.

Bajo consumo, menor a 1,5 W.

Real Time Clock o posibilidad de conectar uno.

Botones para la interfaz con el usuario (2 o 3).

2 LEDs.

Elección de los componentes

Se analizaron varias opciones para desarrollar el dispositivo.

La primera opción fue la de basar nuestro desarrollo uti-

lizando grabadoras digitales de audio, reproductores de mp3,

mp4 o celulares capaces de adquirir audio; pero se descartó

dado que ninguno cumplía los requerimientos mínimos en

frecuencia de grabación y/o cantidad de bits, y costo.

Luego se consideró la opción de desarrollar a medida placas

con microcontroladores y ADCs o tarjetas de audio (o utilizar

1El método propuesto puede ser utilizado indistintamente en bovinos yovinos ya que desde el punto de vista del comportamiento ingestivo sonconsiderados iguales.



81




algún kit de desarrollo existente). Esta opción si bien presenta

ventajas en cuanto a consumo y costos, implicaba un riesgo

para cumplir los plazos del proyecto y debido a que había que

tomar la definición en una etapa temprana del mismo en la

cual todavía no se tenían claros todos los requerimientos se

decidió utilizar un sistema con mayores recursos y flexibilidad.

Por las razones antes mencionadas finalmente se decidió

utilizar una Single Board Computers que incluyera un sistema

operativo para acortar tiempos de desarrollo y una tarjeta de

sonido o ADC externo que cumpliera los requerimientos. Esta

solución permitiría tener mayor flexibilidad y velocidad de

desarrollo de las aplicaciones, y soportar futuras ampliaciones

del equipo como son transmitir los datos mediante Wi-Fi

facilitando la descarga de datos del dispositivo o añadir un

GPS que permitiría relacionar las actividades realizadas por el

animal y la ubicacion geográfica del mismo.

SBC, tarjeta de sonido y unidades de almacenamiento:

Luego de evaluar las placas de la Tabla I y comprobarsi cumplían los requerimientos estipulados (con pequeños

agregados), concluimos que la placa TS-7260 de Technologic

System era la mejor opción. Además se decidió utilizar la

tarjeta de sonido USB 3D Sound modelo HY554 por cumplir

con los requerimientos de frecuencia de grabación y cantidad

de bits y ser de bajo costo.

TS-7260: Tiene instalado de fábrica el núcleo 2.4.26 de

GNU/Linux, y está optimizado para la arquitectura de la

misma y su consumo máximo se encuentra en el orden de

1 W (sin el uso de periféricos y a máxima frecuencia).

Por defecto la TS-7260 trae instalada la aplicación

BusyBox[9]; pero la utilización de la misma fue descartada

debido a distintas limitaciones 2. Se decidió instalar unadistribución GNU/Linux Debian Sarge 3.1 debido a su compa-

tibilidad con nuestra arquitectura y ser un sistema sumamente

estable.

USB 3D Sound modelo HY554: Inicialmente se había

decidido grabar a 22 kHz pero la tarjeta de sonido seleccionada

muestrea únicamente a 48 kHz; por lo que finalmente la

grabación de audio se realiza con frecuencia de muestreo de

48 kHz.

Unidades de almacenamiento: Para poder almacenar 24 hs

a 48 kHz, 16 bits, se necesita una unidad de almacenamiento

de al menos 7 GB. Se intentó grabar audio y decimar los

archivos ya grabados, simultáneamente en la placa pero los

mismos resultaban corruptos. Tampoco fue posible utilizaralgoritmos de compresión de audio con pérdida de información

porque no cumplíamos con los requsitos mínimos de 22 kHz,

12 bits.

La distribución GNU/Linux Debian Sarge 3.1 ocupa alrede-

dor de 512 MB por lo que se necesita una unidad externa de

almacenamiento dado que la memoria interna de la TS-7260

no es suficiente.

Finalmente se decidió almacenar los datos en un pendrive

de 8 GB e iniciar el sistema desde una memoria SD card de

2 GB.

2Con la aplicación BusyBox no es posible manejar módulos de audio,interfaz de red y almacenamiento.

Batería: Para determinar la capacidad de la batería a utilizar

se relevó el consumo de la placa en las posibles situaciones

de funcionamiento (ver Tabla II): inicio del sistema operativo,

estado de espera3 o grabando y almacenando.

Tabla IICONSUMO DEL SISTEMA EMBEBIDO AL SER ALIMENTADO POR UNA

FUENTE DE 5 V.

Actividad Consumo (mA) Pote ncia (W)

Inicio del sistema 300 máx 1,5

Estado de espera 220 1,1

Grabando y almacenando 240 1,2

Eligiendo el peor caso (inicio del sistema), el consumo fue

de 1,5 W, lo cual nos llevó a consumir 36 Wh en un día.

Teniendo en cuenta la potencia que debía suministrar, el

rango de alimentación de la SBC4, factor de forma aceptable,

el costo y la relación entre su peso y la capacidad; se decidióutilizar en el primer prototipo 2 baterías de gel (modelo

RB632C) de 6 V y 3200 mAh. Usando ambas baterías se llegó

a una capacidad de 38,4 Wh, cumpliendo los requerimientos

planteados anteriormente. Las baterías seleccionadas pesan

1200 g y tienen un factor de forma aceptable: 32 x 96 x 60 mm.

Para el diseño final se utilizará un pack de 5 baterías de

litio-ion de 2800 mAh y 3.7 V (modelo GTL), con lo cual

el peso de las baterías bajaría significativamente quedando en

aproximadamente 200 g.

Micrófono: Se decidió utilizar el micrófono Ht-101 de la

marca Xtreme que se encontraba en el mercado local a un

precio accesible, ancho de banda: 100-16000 Hz, impedancia:

2.2 kΩ, sensibilidad: -55db ± 3db y era omni direccional.Placa de interfaz de usuario y control de energía: Para

poder mantener una comunicación con el usuario se diseñó

una placa interfaz de usuario y control de energía. La misma

cuenta con tres botones con las siguientes funcionalidades:

encendido, apagado y grabación.

Uno de los problemas que se presentó al apagar la placa es

que la misma sigue tomando corriente luego de que el sistema

operativo es apagado. Para evitar este problema se

Como se puede observar en la Figura 3, uno de los botones

mecánicos se encuentra en paralelo a un botón lógico. El botón

lógico se realizó mediante un opto acoplador y un transistor

los cuales se disponen en una configuración Darlington. Al

presionar el botón de encendido la placa se prende y ejecuta

su secuencia de arranque. Unos segundos después el sistema

toma el control de los puertos de entrada-salida, se polariza

el transistor Q1 poniendo en "1"lógico el pin 7 del DIO,

activando así al opto acoplador.

El transistor que realiza la salida del opto acoplador fun-

ciona como un interruptor ya que queda en estado de sa-

turación. Esto a su vez produce la saturación del transistor

Q2 permitiendo así el pasaje de la corriente. El proceso de

encendido tiene una duración aproximada de 4 segundos y

3Sistema luego del arranque a la espera de una orden del usuario.4La TS-7260 debe ser alimentada entre 4,5 y 20 V.



82




Tabla ICOMPARACIÓN DE POSIBLES PLACAS

Sinlge board computers seleccionadas

Gumstix Overo Earth[5] PPM-LX800[6] EPX-GX500[7] ARM TS-7260[8]Procesador ARM Cortex-A8 CPU 600

MHzAMD 500 MHz Geode LX800 AMD GeodeTM GX500 200MHz ARM9 CPU

Memoria 256 MB RAM 256 MB Flash Up to 128 MB SDRAM Upto 64 MB of AMD MirrorBitFlash

Up to 512 MB SDRAM 32MB SDRAM 32MB NANDFlash

RTC SiADC 10 bits 12-bit 2 12-bitSD 2GB micro SD Si Si SiUSB USB HS Host 2 x 2.0 ports 2 X Two USB 1.1 ports 2 USB 2.0(12 Mbit/s max)Tamaño(mm x mm x mm)

17 x 58 x 4.2 90 x 96 95 x 120

Consumo 1W 0.9W 1.0W 0.25W a la frecuencia mínimaSist. Operativosque soporta

Windows XP, XP Embedded,Linux, DOS, x86 RTOS

Windows XP, XP Embedded,Linux, Windows CE, DOS,x86 RTOS

Linux out-of-the-box

cuando finaliza enciende el led verde, indicando al usuarioque el sistema está encendido y que puede soltar el pulsador.La última acción que toma el sistema opertivo de la placa

TS−7260 es bajar el pin 7 a "0", esto hace que la SBC sequede sin alimentación, por lo que con esta solución la placaefectivamente no consumirá cuando esté apagada.

Figura 3. Esquema de la placa interfaz usuario y control de energía.

III. DISEÑO INDUSTRIAL

La caja seleccionada para contener la TS-7260, tarjeta deaudio, baterías y placa interfaz es una Pelican 1060 Micro

Case[10] es a prueba de polvo, agua y golpes (ip67); y susdimensiones son 20.9 x 10.8 x 5.7 cm.

Figura 4. Bozal, caja con el dispositivo y micrófono.

En la Figura 4, se puede observar el bozal diseñado, endonde se colocan el micrófono y la caja con el dispositivo. Parapoder conectar el micrófono a la placa de audio se colocó unpasacables estanco para mantener las propiedades de la caja.

IV. ESPECIFICACIÓN DEL SOFTWARE DEL SISTEMA

EMBEBIDO

Introdución

El diseño del sistema embebido se divide en los siguientes

bloques:Inicialización del sistema.Adquisición y almacenamiendo de audio.Apagar el sistema.

Varias de las acciones que debe realizar el sistema embebidoson realizadas por programas y/o librerías de código abiertoya implementadas y testeadas por varias comunidades dedesarrolladores.

A continuación se detalla el funcionamiento de los bloques.

Inicialización del sistema

Luego de presionar el pulsador de encendido se ejecuta TS-SDBOOT e inicia el sistema operativo.



83




Figura 5. Interacción de los programas del software del sisem.

Ejecutar TS-SDBOOT: El TS-SDBOOT es un bootloader

para las placas TS-7260, TS-7300 y TS-7400. Al ejecutarlose levanta la imagen del kernel que se encuentra en la primerapartición de la SD card para luego descomprimirla en RAM.

Luego se ejecuta linuxrc, el cual es un archivo realizadoen shell scripting que se encarga de configurar el sistema dearchivos del GNU/Linux.

Después que todas estas acciones han finalizado, se levantael sistema operativo Debian Sarge 3.1, el cual se encuentra enla tercer partición de la SD card.

Programa linuxrc: Se ejecuta para poder configurar ytrabajar desde la SD card como se diseñó, modificar laconfiguración del sistema de archivos de la tercera particiónde la SD card y realizar el control de LEDs y pulsador paraencender la placa.

Inicio del sistema operativo: Para que el sistema arranqueautomáticamente con nuestro software se modificó la autenti-cación de los usuarios y los demonios que se levantan al iniciodel sistema.

Adquisición y almacenamiendo de audio

La adquisición del audio se realiza mediante el uso delsoftware Bplay, el cual cuenta con una interfaz de grabaciónllamada brec. Se debe configurar el software para grabar a lafrecuencia de muestreo y cantidad de bits deseados.

Apagar el sistemaCuando se presiona el pulsador de apagado el sistema

operativo se apaga correctamente y se le quita la alimentacióna la TS-7260.

En la Figura 5 se muestra un diagrama que explica comointeractúan algunos programas del software del sistema embe-bido.

V. IMPLEMENTACIÓN DEL SOFTWARE DEL SISTEMA

EMBEBIDO

Para tener la seguridad de que la SBC funcionara correcta-mente, se verificó el puerto serie, el puerto ethernet y algunoscomandos básicos de GNU/Linux.

Luego se intentó bootear Debian Sarge 3.1 desde una tarjetaSD. Como el RedBoot que trae originalmente la placa TS-7260 no soportaba el booteo desde la tarjeta SD fue necesariocambiarlo por el TS-SDBOOT5[11].

El kit de desarrollo de Technologic System incluía el códigofuente de Debian Sarge 3.1, para el kernel 2.4.26-ts10 quese cross-compiló para crear la imagen comprimida zImage.Para implementarlo exitosamente fue necesario modificar elcódigo fuente proporcionado por Technologic System paraobtener módulos de audio y tarjeta de almacenamiento, direc-cionamientos de memoria correctos y comando de ejecuciónde inicio del kernel; solucionar errores de dependencia ycódigo mal implementado. Para poder solucionar estos in-convenientes fue necesario modificar archivos del fuente delkernel desrrollados en C.

Para obtener los errores del sistema operativo se utilizóla herramienta strace que muestra las llamadas al sistema

operativo. Analizando los distintos errores que se obtuvieronal utilizar dicha herramienta se depuro el código6.Posteriormente se cross compilaron los módulos y bibliote-

cas necesarias para controlar las distintas interfaces de la SBCque traía incluído el kit de desarrollo. También fue necesariomodificar los códigos fuentes de los cuales dependía el módulode audio porque contenían diversos errores, como por ejemplono se podía grabar correctamente.

Además de utilizar el TS-SDBOOT fue necesario parti-cionar en 3 la tarjeta SD y realizar los siguientes procedimien-tos:

1ra partición.: Instalar el zImage del kernel deGNU/Linux deseado.

2da partición.: Instalar linuxrc y modificar algunos delos parámetros de dicho programa.

3ra partición.: Instalar Debian Sarge 3.1, nuevos módu-los crosscompilados y archivos creados durante la realizacióndel proyecto encargados de manejar la placa interfaz y grabar.

Para poder bootear Debian Sarge 3.1 desde una SD card fuenecesario cambiar el RedBoot original de la TS-7260 por elTS-SDBOOT [11].

El kit de desarrollo de Technologic System incluía el códigofuente de Debian Sarge 3.1, para el kernel 2.4.26−ts10 quese cross-compiló para crear la imagen comprimida zImage.Para implementarlo exitosamente fue necesario modificar elcódigo fuente proporcionado por Technologic System paraobtener módulos de audio y tarjeta SD, direccionamientosde memoria correctos y comando de ejecución de iniciodel kernel; solucionar errores de dependencia y código malimplementado.

Posteriormente se cross compilaron los módulos y biblio-tecas necesarias para controlar las distintas interfaces de laTS-7260 que traía incluído el kit de desarrollo. También fue

5Una vez realizada esta acción no es posible volver a bootear desde laSDRAM, a menos que se la envíe a la fábrica de origen; sin embargo,decidimos realizarla.

6Los archivos correctos se encuentran en:mosobo.it.com.uy/mosobo_2.4.26-ts10.tar.gz. Las herramientas para crosscompilar el kernel se encuentran en: mosobo.it.com.uy/toolchain.tar.gz.



84




necesario modificar los códigos fuentes de los cuales dependíael módulo de audio ya que contenían diversos errores.

VI. TRATAMIENTO DE SEÑALES

Para realizar el reconocimiento de actividades se utilizó unarepresentación apropiada de las señales acústicas y modeladoestadístico que tiene su base en los Modelos Ocultos deMarkov (HMMs)[12]. Cabe destacar que todo el análisis delas señales se realiza en un PC.

Antes de generar y entrenar los modelos las señales deaudio debieron ser remuestreadas y filtradas por la presenciade ruido blanco en altas y bajas frecuencias. Para implementarel software de reconocimiento de actividades se utilizó elsoftware Hidden Markov Model Toolkit (HTK)[13].

Con el fin de evaluar cualitativamente el resultado de grabara los rumiantes con el dispositivo desarrollado y realizar elreconociemiento de eventos y actividades con el software

implementado, definimos la probabilidad de acierto de laactividad A (simbolizando pastoreo, rumia o descanso) como:

PaA =100

tA

K Ai=1

N ij=1

tAij

donde KA es la cantidad de intervalos de la actividad A en laseñal a evaluar, tA es el tiempo total etiquetado de la actividada evaluar A, Ni es la cantidad de intervalos de la actividad A

en tAi detectados en el reconocimiento y tAij es el intervalode tiempo j de la actividad A en tAi en el reconocimiento.

Los resultados obtenidos de los porcentajes de acierto apartir de una señal de 1 hora de duración fueron: PaP =100 %,

PaR=100% y PaD=52 %. Tanto la rumia como el pastoreose detectaron correctamente mientras que el descanso solo sedetectó un poco más de la mitad del tiempo. Esto se debe aque cualquier ruido del ambiente puede ser considerado para elmodelo, como un evento de rumia o arranque, por lo que partedel descanso puede confundirse con la rumia o el pastoreo.

VII. CONCLUSIONES Y PERSPECTIVAS

Utilizando la placa TS-7260 con Linux embebido se desa-rrolló un dispositivo capaz de grabar y almacenar correctamen-te los sonidos emitidos por bovinos y que puede permanecera la intemperie junto con los mismos sin presentar problemasde funcionamiento. El dispositivo es de fácil colocación, nointerfiere con el comportamiento de los animales, no les generalesiones y además su costo, que ronda los 375 USD enmateriales7, es relativamente bajo en comparación con otrosdispositivos que se utilizan para este fin.

Se logró una independencia energética de 24 horas, re-sultando en un peso del dispositivo de 1700 g sin bozal.Utilizando las baterías de litio-ion mencionadas el peso totaldel dispositivo baja a 800 g sin bozal.

A pesar de haber tenido varios inconvenientes con las he-rramientas de desarrollo brindadas por el fabricante de la SBC(código fuente mal implementado, errores de direccionamiento

7No incluye gastos de aduanas ni envíos.

de memoria, dependencias, etc), se logró implementar exitosa-mente el software y sistema operativo del sistema embebido,cumpliendo con todos los objetivos planteados.

Utilizando la herramienta de desarrollo HTK se implementóun sistema de reconocimiento de eventos de las actividadesque realizan los rumiantes; a partir del cual se implementó unsistema de reconocimiento de actividades (pastoreo, rumia ydescanso).

Se lograron buenos resultados en el reconocimiento de lasactividades de pastoreo y rumia (porcentajes de acierto del100 %) mientras que el resultado de la actividad descanso nofue tan satisfactorio (porcentaje de acierto del 52 %).

En un futuro se le puede incorporar un GPS con el cualse podría relacionar la ubicación del animal al realizar cadaactividad. Además, mediante el uso de mapas se podríadeterminar el tipo de pastura que ingirió el animal y estimar lamateria seca consumida lo cual brinda información adicional

del comportamiento ingestivo animal.REFERENCIAS

[1] P. Chilibroste, P. Soca, D. Mattiauda, O. Bentancur, and P. Robinson.,“Short term fasting as a tool to design effective grazing strategies forlactating dairy cattle: a review.” Australian Journal of Experimental

Agriculture, 2007.[2] J. Hodgson, “The control of herbage intake in the grazing ruminant.”

Hill Farming Reasearch Organization, 1985.[3] E. Sazonov, S. Schuckers, P. Lopez-Meyer, O. Makeyev, N. Sazonova,

E. L. Melanson, and M.Ñeuman., “Non-invasive monitoring of chewingand swallowing for objective quantification of ingestive behavior.”

Electronic Journals from Institute of Physics Publishing., 2008.[4] D. Milone, H. Rufiner, J. Galli, E. L. f, and C. Cangiano, “Computational

method for segmentation and classification of ingestive sounds in sheep,”Science Direct , 2009.

[5] Gumstix, “Gumstix developer site - gumstix overo - feature overview.”agosto 2009. [Online]. Available: http://www.gumstix.net/Hardware/ view/Hardware-Specifications/Overo-Specifications/112.html

[6] WinSystem, “Winsystem,” agosto 2009. [Online]. Available: http: //www.pc104plus.com/products/PPM-LX800- G.cfm

[7] Winsystem, “Winsystem,” agosto 2009. [Online]. Available: http: //sbc.winsystems.com/products/EPX-GX500.cfm

[8] T. Systems,http://www.embeddedarm.com/products/board−detail.php?product=TS−7260,agosto 2009.

[9] BusyBox, “Busybox,” junio 2010. [Online]. Available: http://www.busybox.net/

[10] “Pelican products 1060 micro case,” setiembre 2009. [Online].Available: http://www.pelican.com/cases_detail.php?Case=1060

[11] T. System, “Ts−boot,” noviembre 2009. [Online]. Available: http: //www.embeddedarm.com/software/arm-linux-fastboot- ts7300.php

[12] “Hidden markov models,” setiembre 2009. [Online]. Available:http://jedlik.phy.bme.hu/$\sim$gerjanos/HMM/node2.html

[13] U. de Cambridge, “htk3,” noviembre 2009. [Online]. Available:http://htk.eng.cam.ac.uk/



85




Dispositivo de rehabilitación visual basado ensistemas embebidos del tipo ARM.

Marcelo M. RaponiCentro de Investigaciones en Láseres y Aplicaciones

CITEFA-CONICETBuenos Aires, [email protected]

Rodolfo O. BonninBusiness Vision S.A.

Hipólito Yrigoyen 1530, Piso 7Ciudad Autónoma de Buenos Aires, Argentina

[email protected]

Resumen- En el trabajo se describe el diseño y desarrollo de un

sistema embebido basado en tecnología ARM® Cortex™ A8

(placa BeagleBoard), para adquirir y procesar en tiempo real

señales de video provenientes de una mini-cámara portátil, y

generar un patrón de estimulación visual que brinde un cierto

grado de rehabilitación a personas con baja visión. Para la

implementación de la plataforma se utilizó el IDE Qt-creator ylibrerías open-source (Qt, Highgui y OpenCV). El framework

permite adquirir señales de video, aplicar filtros espaciales,

modificar brillo y contraste, hacer zoom, invertir colores, entre

otras operaciones. El patrón visual final es enviado a un módulo

de visualización compuesto por dos mini-display LCD TFT

gráficos montados en las lentes de unos anteojos.

Palabras claves- BeagleBoard; sistemas embebidos; baja visión;

OpenCV.

I. I NTRODUCCIÓN

El sentido de la visión es fundamental para realizar lasmúltiples tareas que cotidianamente llevamos a cabo los sereshumanos. Actividades tan habituales como cruzar una calle,tomar un colectivo, mirar televisión, leer el diario, entre otrastantas, se ven seriamente afectadas por lesiones y patologíasoculares que producen ceguera parcial o completa en millonesde seres humanos. Existe un gran número de personas que

presentan diferentes grados de deterioro visual sin llegar a ser completamente ciegos, a los cuales se los clasifica como

pacientes con baja visión o visión subnormal . Para definir eltérmino baja visión de una forma amplia, es necesario tener encuenta no sólo el déficit visual sino también la calidad visual.Una patología ocular permanente debe ser valorada en cuantoafecta al estado psíquico, fisiológico y social del individuorespecto a una vida de relación. La Organización Mundial de la

Salud (OMS) define la baja visión como: "Pérdida de agudezavisual y/o campo visual, que incapacita para la realización detareas de la vida diaria, incluso tras un tratamiento y/ocorrección refractiva convencional. La agudeza visual debe ser igual o inferior a 0.3 (30% de visión) y el campo visual menor o igual a 20º. La pérdida afecta a los dos ojos, pero aún quedaresto visual útil”. Una persona es legalmente ciega cuando suagudeza visual es menor o igual a 0.1 (10% de visión) y sucampo visual inferior a 10º, en el mejor de los ojos. Segúnestadísticas mundiales existirían alrededor de 161 millones de

personas con deficiencia visual, de los cuales 124 millonestendrían baja visión y 37 millones serían ciegos, incluyendo 1,4

millones menores de 15 años. Las cataratas son la principalcausa de ceguera (47,8%), seguida por la degeneración macular asociada a la edad (8,7%) y la retinopatía diabética (4,8%).

En el área de la rehabilitación visual generalmente setrabaja en monocularidad , es decir, se utiliza el mejor ojo del

paciente que siempre ve menos de 3/10. Si ambos ojos ven másde 1/10 (y menos de 3/10) se emplea una corrección de +8 o+10 dioptrías con prismas, con el fin de compensar la granconvergencia que se necesitaría para enfocar un objeto ubicadoa una distancia de 10 o 12.5 cm. En la mayoría de los casos, elojo más deteriorado afecta - por ser el ojo director - la

percepción del mundo exterior, y el cerebro debe aprender adesechar dicha información. Una manera de colaborar con elcerebro es colocar un vidrio oscuro o esmerilado frente a dichoojo, impidiendo que reciba estímulos de luz. Por otro lado, noexisten indicaciones de ayudas ópticas/electrónicas para

patologías especificas. Un persona con baja visión tienedisminuida la sensibilidad de percepción (capacidad dedistinguir detalles) debido a diversas causas, por lo cual,

cualquier dispositivo de rehabilitación, deberá sencillamentemagnificar el estimulo visual (ver Fig. 1).

Figura 1. Dispositivos electrónicos empleados por pacientes con baja visión.

Actualmente, mediante el empleo de elementos ópticos(lentes especiales, lupas, telelupas) y sistemas electrónicos



86




(magnificadores de imágenes, circuito cerrado de TV, etc.) es posible brindar a dichos pacientes, un cierto gradorehabilitación visual. En el mercado nacional e internacionalexisten ayudas para visión cercana (ej. leer o escribir) y visiónlejana (ver TV, mirar una pizarra, observar carteles en la vía

pública, etc.), aunque el acceso a estos dispositivos esgeneralmente restrictivo debido a su alto costo y no siempre

brindan un beneficio sustancial al paciente. Los precios de las

ayudas electrónicas pueden variar desde unos U$S 300 hastamás de U$S 3000. El dispositivo que presentamos en estetrabajo (aún en etapa de desarrollo) tiene un costo defabricación de aproximadamente U$S 500 (incluye anteojoscon display y mini-cámara, unidad de control, batería, cables ycomponentes varios). Estimamos que el precio final de ventadel sistema será de unos U$S 1000 (la tercera parte del costo denuestro principal competidor: www.vuzix.com).

A continuación se presenta el diseño y desarrollo de undispositivo biomédico de rehabilitación visual, basado entecnología embebida de última generación y algoritmos de

procesamiento de imágenes digitales, capaz de mejorar lacalidad de vida de personas con disfunciones visuales severas.

El sistema - reconfigurable, portátil y de bajo costo - permiteadquirir y procesar imágenes en tiempo real, efectuar un realceselectivo de la información visual y mapear dicha informaciónen un patrón de estimulación apropiado. El software se basa en

plataformas open-source lo que garantiza su portabilidad einteroperabilidad con otros sistemas y hardware subyacente, yes lo suficientemente modularizado como para permitir unarápida adaptación a nuevos dispositivos embebidos o

bibliotecas, como así también un adecuado mantenimiento enel caso que se requieran rediseños y/o adicionar nuevasfuncionalidades.

II. IMPLEMENTACIÓN DEL HARDWARE

La implementación física del dispositivo consta de trescomponentes: un módulo de adquisición de señales de video(con un subsistema de captura de imágenes incorporado ysalida USB), un módulo de visualización de señal de video

procesada, y un módulo de procesamiento basado en tecnologíaARM (Advanced RISC Machines) Cortex™ A8 (placaBeagleBoard) [1,2].

A. Módulos de adquisición y visualización de imágenes

El módulo encargado de la adquisición de las imágenesconsiste en un soporte (anteojos) que posee un dispositivo decaptura integrado (ver Fig. 2). El sensor y su controlador seencuentran montados en la estructura de los lentes y se

vinculan con la unidad de control vía un puerto USB 2.0. Elcontrolador de video (Sunplus SPCA1528A) soporta sensoresde 5 Mega píxeles, grabación de audio y video, y salida de TV.Por medio del driver de Linux es posible seleccionar diferentesresoluciones de video: 640x480, 320x240 y 176x144 píxeles.La mini-cámara incorporada en los lentes permite adquirir imágenes de buena calidad aún en ambientes con bajailuminación. La duración de su batería es de aproximadamente4 -5 hs. La señal de video luego de ser procesada por laBeagleBoard, es enviada a un módulo de visualizacióncompuesto por dos display LCD TFT gráficos, con unaresolución de 320x240 píxeles (QVGA), un tamaño de 0.24”

(sobre la diagonal), distancia interpupilar de 63.5 mm y tamañode imagen virtual de aproximadamente 35” a 2 metros dedistancia. El consumo de energía del módulo visualizador esmenor a 450 mW y puede procesar señales de video tipo NTSCo PAL estándar de manera automática.

Figura 2. Modulo de adquisición (superior) y de visualización (inferior) del prototipo desarrollado.

B. Módulo de procesamiento basado en BeagleBoard

Para la implementación del prototipo hemos seleccionadola placa de desarrollo BeagleBoard, la cual es un pequeño y

potente ordenador equipado con un procesador OMAP 3 paraaplicaciones multimedia, basado en la arquitectura dual coreoptimizada para sistemas operativos eficientes, como Linux.Posee un núcleo de procesamiento ARM Cortex™ A8 dearquitectura ARMv7, con frecuencia de trabajo de 600 MHz,256 Mb de memoria RAM, un DSP C64x+ y un acelerador gráfico. La placa tiene conectividad con diversos periféricos:webcam, LCD, memorias SD, etc. (ver Fig. 3).

Figura 3. Sistema embebido (placa BeagleBoard) y su conexión con elmódulo de adquisición de video.



87




Se optó por la tecnología ARM principalmente por surápida puesta en marcha, la posibilidad de utilizar las libreríasOpenCV (Open Source Computer Vision Library), el altogrado de conectividad, su portabilidad, la capacidad de cálculodel DSP y la aceleradora de gráficos, entre otras característicassobresalientes

III. ARQUITECTURA DE LA SOLUCIÓN DE SOFTWARE

La solución consiste básicamente en una aplicacióndesarrollada en C y C++, empleando como backend laestructura de datos y los algoritmos de procesamiento propiosde OpenCV [3-4], y como frontend una GUI (Graphical User Interface) diseñada en base a librerías Qt [5]. El backendrealiza las tareas preliminares de adquisición y adaptación delas señales a las restricciones impuestas por el transductor. Estáconformado por un stack de software cuyos componentes

principales son el kernel de Linux, la librería OpenCV y V4L para la captura de vídeo. OpenCV es una librería de programación especialmente diseñada para tratamiento deimágenes, captura, procesamiento y visualización de señales devideo en tiempo real, segmentación y reconocimiento de

objetos y gestos, seguimiento de objetos, robótica, biométrica,seguridad, entre otras aplicaciones. Es de código abierto,multiplataforma, de fácil uso y en continua evolución. Fuedesarrollada originalmente por Intel para abordar problemas enel área de la visión por computador. Actualmente es un

proyecto libre publicado bajo licencia BSD (Berkeley SoftwareDistribution), lo que permite su uso tanto para aplicacionescomerciales como no comerciales.

V4L es una interfaz de kernel para video captura y driversde salida, incluyendo sintonizadores de radio y sistemas RDS(Radio Data System). Está integrado al kernel en la versión 2.6,y tiene un árbol de desarrollo adaptado a versiones anterioresdel kernel. Para el soporte del dispositivo de captura de

entrada, una versión actual de los drivers (gspca_spca1548)tuvo que ser modificada para ser soportada por la distribuciónde Linux (Angström). A continuación se explicará cada uno delos bloques constitutivo de la plataforma.

A. Sistema Operativo

La distribución seleccionada (Angström) [6] está diseñadaespecíficamente para sistemas embebidos, y el kernel Linux esel oficial de la distribución 2.6.32, con parches desarrollados

para el soporte de diversos sistemas embebidos. El kernel debióser compilado utilizando el toolchain OpenEmbedded paraincluir el soporte de la cámara del módulo de adquisición,debido a que el soporte oficial fue lanzado a posteriori de la

fecha de release del kernel oficial. Para esto se tuvo que hacer un backport de una variable para el módulo genérico gspca(soporte de un número de webcams de bajo costo), y se adaptóel driver gspca_1528 para el uso de una función legacy dedriver genérico. Dicho driver fue compilado directamente en elnuevo kernel, que será utilizado en las pruebas finales.

B. Esquema general de la aplicación de software

En la Fig. 4 se presenta un esquema general de laorganización funcional del software implementado. Se puedenobservar las funciones principales de adquisición,

procesamiento y visualización de resultados, y la interacción delos mismos.

Figura 4. Diagrama en bloques del procesamiento realizado por la plataforma

embebida

C. Adquisición de datos

La adquisición de imágenes se realiza por medio de lalibrería auxiliar de OpenCV, highgui [7], que consiste en untoolkit gráfico portable, capaz de trabajar con dispositivos decaptura, salida y archivos de video, y provee de herramientassencillas de GUI (las cuales no son utilizadas en el prototipo,siendo cubiertas por la librería Qt). A continuacióntranscribiremos algunas líneas del código, donde se puedenapreciar las estructuras de datos y funciones esencialesempleadas para la adquisición de imágenes:

capture = new cv::VideoCapture ( int source ) ;

// Crea un objeto de clase VideoCapture que contendrá losframes y metadata de la imagen a capturar.

if ( !capture->isOpened ( ) ) return;

// Comprueba la correcta inicialización del dispositivo decaptura;

capture->grab( );

capture->retrieve ( *firstImage , 0 ) ;

//Captura un frame y coloca valores y metadatos en la matriz

D. Procesamiento de los datos

El procesamiento de las imágenes se realiza mediante lassiguientes rutinas:

Ajuste de brillo/contraste: se realiza por medio de lafunción convertScaleAbs, la cual posee una variable alpha quemodifica la relación de escala de los valores, y beta, que generaun bias para los valores de la imagen.

Detección de bordes: se utiliza el algoritmo de Canny [8],incluido en OpenCV, con un primer umbral del procedimientode histéresis de 50, un segundo umbral de 300, una apertura de3 y sin gradiente L2.



88




Inversión de colores: se aplica la función bitwise_not acada elemento del miembro data del objeto de clase Mat.

E. Interfaz gráfica

Mediante una interfaz visual amigable, el usuario puedeseleccionar diferentes operaciones a realizar sobre la señal devideo capturada, entre los cuales podemos mencionar: zoom,detección de bordes, modificación de brillo y contraste, imagen complementaria, entre otras que se incorporarán en un futuro.La interfaz fue diseñada teniendo en cuenta la maximizacióndel espacio visible debido a que la imagen será destinadafinalmente a los displays, y una disrupción excesiva de loscontroles no es aconsejable. Consiste en un módulo devisualización de resultados/modificación de parámetros por medio de la librería Qt. En el mismo se puede elegir el origende los datos, los algoritmos a aplicar y el nivel de zoom. En laFig. 5 se presenta el diseño de la interfaz implementada, pudiendo observarse sus comandos localizados en una barradesplegable.

Figura 5. Prototipo de interfaz visual. Se observa un texto original y elresultante de aplicar zoom e inversión de colores.

En la figura anterior se puede observar el control de brillo, basado en un spinbox con botones adicionales que modificanlos valores, adaptados a la operación de un touchscreen.Similar comportamiento posee el control de contraste. Tambiénse visualizan los controles de zoom (in y out) que operan sobreel widget por medio de método GraphicsView::scale (razón deaspecto horizontal, razón de aspecto vertical) . Los botones C yV, permiten elegir la fuente de los frames, el primero identificala cámara, y el segundo un archivo de video, que se elegirá por medio de un diálogo de selección de archivo.

Adaptación de estructuras de datos: para posibilitar laadaptación entre las clase cv::Mat y QImage de Qt, fuenecesario realizar un mapeado entre las estructuras de datosraw de OpenCV y de QtImage, con una llamada del tipo:

Qim_dest = QImage ( ( const uchar* ) im_ini -> data , im_ini -> cols , im_ini -> rows , QImage::Format_RGB888 ) ;

Donde Qim_dest es el objeto QImage destino, y im_ini es

un objeto del tipo cv::Mat, del que se copiaran los valores RGB byte a byte.

IV. CONCLUSIONES

El prototipo desarrollado permite la adquisición de señalesde video en tiempo real y efectuar un realce selectivo de lainformación visual. Mediante una sencilla interfazespecialmente diseñada, es posible seleccionar diferentes procesamientos digitales que se aplicarán a los respectivoscuadros de la señal entrante. La plataforma implementada es portátil, de bajo consumo y puede utilizarse para mejorar diversas tareas de la vida cotidiana que realizan los pacientescon baja visión.

AGRADECIMIENTOS

Los autores agradecen a todos aquellos que hicieron posiblela concreción del diseño del primer prototipo de baja visión.

R EFERENCIAS

[1] ARM, descripción del procesador Cortex A8 [online]http://www.arm.com/products/processors/cortex-a/cortex-a8.php Fechade acceso: 24 de septiembre de 2010.

[2] Gerald Coley. “BeagleBoard System Reference Manual Rev C4, Revision 0.0” [online]. http://beagleboard.org/static/BBSRM_latest.pdf,December 15, 2009.

[3] Gary Bradski y Adrian Kaebler. “Learning OpenCV”, Ed. O'Reilly

Media Inc., ISBN 978-0-596-51613-0, 2008.[4] http://opencv.willowgarage.com/wiki OpenCV Wiki Welcome. Fecha

de acceso: 26 de Agosto de 2010.

[5] http://qt.nokia.com/downloads/sdk-windows-cpp. Nokia Corporation.Fecha de acceso: 26 de septiembre de 2010.

[6] http://www.angstrom-distribution.org/ The Ångström DistributionEmbedded power. Fecha de acceso: 28 de Agosto de 2010.

[7] http://opencv.willowgarage.com/documentation/cpp/highgui._high-level_gui_and_media_io.html Opencv v2.1 documentation. Fecha deacceso: 15 de Septiembre de 2010.

[8] J. Canny. A Computational Approach to Edge Detection. IEEETransactions on Pattern Analysis and Machine Intelligence, PAMI-8(6):679 – 698, November 1986.



89




Protocolos

y

Comunicaciones



90






91




Analisis del Desempeno de un Algoritmo de

Localizacion para Redes de SensoresSilvana Romina Sanudo. Departamento de Ingenierıa Electrica y Computadoras, Universidad Nacional del Sur,

Bahıa Blanca. Email: [email protected]

Favio Roman Masson. Departamento de Ingenierıa Electrica y Computadoras, Universidad Nacional del Sur,

Bahıa Blanca. Email: [email protected]

Pedro Julian. Departamento de Ingenierıa Electrica y Computadoras, Universidad Nacional del Sur, Bahıa Blanca.


Resumen—Se presenta el analisis del fucionamiento de unestimador para localizacion y seguimiento de fuentes o eventosen Redes de Sensores denominado Filtro de Partıculas Acotado

(BPF, Bounded Particle Filter). El algoritmo cumple con las res-tricciones de redes de sensores, a saber: mınimo procesamiento,mınimo almacenamiento y mınima comunicacion de datos. Seanaliza su desempe ˜ no en una aplicacion de localizacion en unespacio de estados bidimensional utilizando sensores de rango.La solucion presentada puede extenderse a cualquier tipo desensores en cualquier aplicacion de localizacion o seguimiento.

I. INTRODUCCION

Los avances en Sistemas Micro Electro Mecanicos (MEMs)

y redes inalambricas han hecho posible la creacion de

pequenos nodos sensores multifuncionales de comunicacion

inalambrica; de bajo costo, poca cobertura de sensado y

comunicacion limitada; poca capacidad de procesamiento yalmacenamiento, bajo ancho de banda y bajo consumo de

energıa [1]. Las redes conformadas por dichos nodos, de-

nominadas Redes de Sensores Inal´ ambricas (WSN, por su

nombre en ingles, Wireless Sensor Networks) ( [2], [3]), son

un paradigma de la medicion distribuida; los nodos colectan

informacion f ısica del ambiente y la comunican. La red en

conjunto trabaja con un fin determinado; uno de los objetivos

mas comunes es la localizacion de una fuente o evento y

su seguimiento ( [4], [5]). Los nodos en aplicaciones de

localizacion y seguimiento requieren, en algunos casos, tratar

con eventos de corta duracion y para ello deben ser capaces

de procesar y comunicar la informacion en forma rapida

para lograr el procesamiento colectivo. Un ejemplo es ladeteccion de disparos [6]. Las limitaciones fısicas de los

nodos hacen que su capacidad de procesamiento, memoria

y comunicacion sean muy restringidas, es por ello que en

general los nodos realizan tareas simples sin llegar a un

resultado, solo a un preprocesamiento de la informacion; la

mayor parte del procesamiento se realiza en una computadora.

La localizacion presenta modelos no lineales con ruidos de

distribucion aleatoria. El Filtro de Partıculas presenta una

forma simple y efectiva de representar modelos de procesos es-

tocasticos y modelos de propagacion arbitrarios con funciones

de distribucion de probabilidad arbitrarias; lo que lo hace la

herramienta adecuada para la tarea que se desea abordar. El

Filtro de Partıculas Acotado es una modificacion del Filtro

de Partıculas de modo de poder implementarlo sobre un nodo

comercial, cumpliendo con las restricciones que el nodo y la

red de sensores presentan; y presentando una solucion a los

problemas que un PF conlleva, como ser el empobrecimientode muestras y la convergencia. El presente trabajo provee

el analisis de un algoritmo para redes de sensores adaptado

especialmente para su implementacion sobre los nodos de la

red. Permite llegar a resultados de localizacion cumpliendo

con las restricciones que el sistema (nodo/red) presenta. El

algoritmo permite realizar una estimacion conjunta, totalmente

descentralizada, de un objeto o evento. Se han explicado

la motivacion y las caracterısticas de la aplicacion que se

presentara en el trabajo. En la siguiente seccion se expone

la nocion de fusion de datos. En el Capıtulo 3 se presenta un

paneo de filtros no lineales y en el Capıtulo 4 se resume el

algoritmo de Filtro de Partıculas Acotado, las contribuciones

que presenta. En el Capıtulo 5 se muestran las aplicacionesimplementadas del Filtro de Partıculas Acotado; un estudio

estadıstico para la variacion de parametros de diseno del

algoritmo y se extraen conclusiones respecto a los resultados

obtenidos.

I I . FUS ION DE DATOS

La fusion de datos pretende, mediante la combinacion de

observaciones de diferentes sensores, potenciar las virtudes de

cada uno de ellos y minimizar sus posibles desventajas, con

el fin de realizar inferencias sobre el mundo exterior; pretende

obtener un mejor resultado a partir de multiples sensores

realizando inferencias que pueden no ser posibles a partir deuno solo. Existen diversas maneras de realizar la fusion de

datos, dependiendo de la aplicacion y la distribucion de la red.

En casos donde se cuenta con un gran numero de sensores o

se requiere llegar al resultado en forma rapida es adecuado

realizar la fusion de manera descentralizada ( [7], [8], [9]),

fusionar entre nodos vecinos o bien realizar un procesamiento

previo de la informacion adquirida dentro del nodo y luego

transmitir los resultados a un nodo de mayor jerarquıa o

bien a un nodo central de procesamiento [10]. En general

en localizacion y seguimiento el procesamiento se realiza en

lınea (online), al instante, sobre todo en aplicaciones militares

y de seguridad; y requieren algoritmos rapidos y convergentes.

En el presente trabajo se presenta un algoritmo de fusion de

datos rapido y convergente con bajo requerimiento de calculo,



92




comunicacion y almacenamiento; aplicado en problemas que

requieren una fusion online sobre un esquema distribuido;

es decir, la fusion se realiza nodo a nodo y se comunica

directamente un resultado.

III. INTRODUCCION A LOS FILTROS DE ESTIMACION

En redes descentralizadas los nodos tienen mayor comple-

jidad debido a que deben procesar la informacion y calcular

la estimacion del estado de interes, pero ello hace a la red

resultante escalable y modular [11]. En aplicaciones reales,

las fuentes de ruido tienen distribuciones no Gaussianas, y

asumir que lo son lleva a resultados de estimacion incorrectos

( [12], [13]). Una manera de resolver el problema es acu-

mular informacion [14] para obtener una estimacion general

casi Gaussiana (mientras la informacion de cada nodo no

lo es) y luego utilizar un Filtro de Kalman estandar. Otro

problema importante viene relacionado con los modelos nolineales y filtros basados en la linealizacion, como el Filtro de

Kalman Extendido (EKF); dichos filtros producen resultados

catastroficos si no se linealiza cerca del punto de operacion

[13]. Los Filtros de Partıculas (PF) son herramientas que

realizan una estimacion Bayesiana y evitan los problemas

detallados anteriormente; permiten representar modelos de

procesos estocasticos y modelos de propagacion arbitrarios

con funciones de distribucion de probabilidad (pdf) arbitrarias

en una manera simple y efectiva. Para lograrlo se utilizan

los Metodos Secuenciales de Monte Carlo ( [15], [12]). La

densidad de probabilidad es representada por puntos pesados

(partıculas) que son posibles estados del proceso, distribuidas

en todo el espacio de estados. La base de los PF [12] mas uti-lizados se denomina Remuestreo por Importancia de Muestras

(SIR, Sample Importance Resampling). El filtro realiza tres

operaciones basicas; generacion de partıculas, calculo del peso

de cada partıcula y remuestreo. Las partıculas y su peso se

propagan utilizando el Teorema de Bayes y el concepto de SIR.

Para lograr buenas aproximaciones son necesarias muchas

partıculas, lo que implica gran capacidad de computo y

almacenamiento; y en una red de sensores la transmisi on entre

nodos de dicha informacion implicarıa un costo inaceptable en

el canal inalambrico. Se han propuesto muchas modificaciones

del PF para adaptarlo a tareas especıficas [15]. El PF Gaus-

siano (GPF) [16] aproxima las densidades a posteriori con

Gaussianas simples ; es un algoritmo util cuando se requieretransmitir mensajes de poca longitud y frecuencia. Cuando una

distribucion Gaussiana no es representativa del estimado, se

puede utilizar una suma de Gaussianas para aproximarlo [17]

aumentando los requerimientos de procesamiento. Tambien

se han utilizado cajas en lugar de partıculas discretas para

representar la estimacion ( [18]), como resultado se debe

comunicar menos informacion pero se desperdicia mucha

informacion de los sensores debido a que para la generacion

de cada caja se considera la maxima incertidumbre del es-

tado. En el presente trabajo el Filtro Acotado de Part ıculas

(BPF, Bounded Particle Filter) ( [19], [20]) puede representar

funciones de probabilidad no Gaussianas (pdf), el algoritmo

encierra la region de partıculas con alta probabilidad, son las

partıculas previamente seleccionadas debido a que su peso

excede una cota de peso. El desempeno del algoritmo se

evalua en aplicaciones de localizacion de objetos en un espacio

bidimensional, utilizando sensores de rango. La aproximacion

de la estimacion es delimitada por cotas de rango y angulo

(coordenadas polares) y se propagan de nodo a nodo. El

BPF cumple potencialmente con el requerimiento de poca

comunicacion, bajo procesamiento de datos y el hecho de que

no es necesaria una caracterıstica de pdf a priori.

IV. FILTRO DE PARTICULAS ACOTADO

El Filtro de Partıculas Acotado (BPF, por su sigla en

ingles Bounded Particle Filter) presentado en [20] comienza

en un nodo l ıder con una distribucion de partıculas inicial

que se extiende sobre todo el espacio de estados de inter es.

Luego de una medicion y una actualizacion consistente de la

estimacion, se realiza la seleccion de partıculas y se envıan al

siguiente nodo propiedades importantes de las partıculas se-

leccionadas. En la version de mınima informacion transmitida,se comunican las cotas del espacio estimado que encierran

las partıculas seleccionadas. La seleccion del nodo excede el

alcance del trabajo [5]. Cada nodo recibe las cotas y genera

una distribucion de partıculas en el area delimitada por las

mismas, donde se realiza la prediccion y la actualizacion.

V. ENSAYOS DEL ALGORITMO IMPLEMENTADO SOBRE

NODOS

A. Funcionamiento del Algoritmo en el Nodo.

Se implementa el algoritmo sobre un nodo Mica2 ( [21],

[22], [23]). La informacion inicial llega al nodo desde un

nodo inicial o previo y consiste en la posicion del nodo ycotas de angulo y rango (solo 6 parametros de doble precision

a ser transmitidos entre los nodos en un unico paquete de

RF). Una vez que la informacion llega, el nodo comienza su

propio procedimiento de estimacion y luego lo comunica al

nodo siguiente o a la PC. El procedimiento de estimacion

comienza con una lectura del sensor (observacion, medicion);

las partıculas son generadas dentro de las cotas recibidas en

coordenadas polares. Cuando una observacion es efectuada, la

estimacion de la observacion es calculada sobre cada partıcula;

y con ello su peso. Se compara el angulo y rango de las

partıculas cuyos pesos exceden la Cota de Peso (CotaW )

con las cotas de rango y angulo iniciales o previas para

actualizarlas de ser necesario. Existe un problema con la gen-eracion aleatoria de partıculas, especialmente debido a las di-

ficultades de implementar un generador de numeros aleatorios

en un nodo de capacidad de procesamiento y almacenamiento

limitadas. Se implementa un generador de numeros aleatorios

llamado Ran [24] que debio ser modificado en dos formas

para obtener distribuciones totalmente aleatorias. Primero se

lee el contador del reloj del nodo y se rota para obtener un

numero que no sea monotonamente creciente, dicho numero se

suma a la semilla. En segundo lugar, cada numero generado se

utiliza como semilla para la proxima generacion. Para generar

una partıcula se genera un numero aleatorio y se opera para

obtener un numero entre las cotas de rango. Luego para dicho

rango se genera un nuevo numero aleatorio que es operado

para que caiga dentro de las cotas de angulo. En la Fig. 1 se



93




Fig. 1. Comportamiento del nodo.

muestra la implementacion del algoritmo sobre el nodo; loscuadrados grises son los procedimientos que no son propios

del algoritmo. En la Fig. 2 se especifica mas detalladamente

el procedimiento realizado dentro de cada nodo. Ahora una

breve explicacion:

• Inicializacion de parametros: Las cotas iniciales (Amin,

Amax, Rmin, Rmax) son inicializadas de manera que la

primer partıcula seleccionada ya las modifique. Como

ejemplo podemos citar un Rango Maximo de 0 y un

Rango Mınimo de 20 metros; para un sensor cuyo alcance

es de 10 metros.

• Medicion del sensor: Se simula la lectura de un sensor de

rango; en otras palabras, se define una posicion fija del

sensor y se calcula previamente una observacion de rangocon un ruido gaussiano especıfico; en nuestro caso es de

5 cm. la varianza del sensor. Se calculan 1000 valores

dentro de una normal de un rango medio y dicha varianza,

y se elije aleatoreamente un valor que sera la lectura del

sensor.

• Calculo de la Cota de Peso (CotaW ): Se genera un

numero inicial de partıculas, solo con el objetivo de

guardar el peso maximo (W max) entre ellas, y se calcula

con (1). CotaW se calcula como un porcentaje de dicho

W max. No debe confundirse este numero con el numero

de partıculas generadas al inicio del algoritmo BPF.

CotaW =Porcentaje

100W max (1)

• Seleccion de partıculas y extraccion de cotas de angulo

y rango: Se genera una partıcula, se compara su peso

con CotaW y en caso de superarla, se incrementa un

contador de partıculas seleccionadas (k) y se compara

el rango y angulo de dicha partıcula con las cotas de

rango y angulo para actualizarlas. Se descarta la part ıcula

y se repite el procedimiento en forma serial hasta que el

mınimo numero de partıculas sobrevivientes (NroPart) se

cumple.

B. Ensayos de Simulaci´ on de Red con MICAs.

Los nodos sensores realizaron el procesamiento en el orden

y la ubicacion especificada en la Tabla I. Se realizaron los

Fig. 2. Detalle del algoritmo dentro de los nodos.

ensayos manteniendo la configuracion de la red, el orden

de procesamiento y el valor medido. Para cada ensayo se

realizaron 20 corridas del algoritmo BPF sobre las cuales

se evaluo el valor medio de la media y la varianza de las

partıculas seleccionadas en la estimacion resultante (en XY), el

area resultante y la media del numero de partıculas generadas

hasta lograr las 15 partıculas que superen CotaW en cadaestimacion de cada corrida. La idea es variar el numero de

partıculas generadas con el fin de almacenar el W max; y de ahı

se elige la cota de peso como un porcentaje del maximo peso.

Siempre se almacenan mınimo 15 partıculas. Se realizaron

ensayos:

• Variando las partıculas iniciales: 10, 20, 40, 60, 80 y 100

partıculas sobre las cuales elijo la de peso maximo para

luego calcular CotaW .

• Variando el porcentaje de W max que se adopta por cota:

40, 60 y 80

Es importante recordar que se denomina “area” al producto

entre la diferencia entre las cotas de rango por la diferencia

entre las cotas de angulo de la estimacion resultante; y la

unidad es metro por radian. El numero mınimo de part ıculas



94




Nodo X (m.) Y (m.) z (m.)

1 0 0 -

2 1 1 1.998

3 4 -1 4.121

4 -1 3 3.1699

Tabla IUBICACION Y ORDEN DE ESTIMACION DE LOS SENSORES CON EL Nodo1

COMO ORIGEN DE COORDENADAS.

40 60 800

2

4

6

8

10

Á r e a

40 60 800

2

4

6

8

10

40 60 800

2

4

6

8

10

Á r e a

40 60 800

2

4

6

8

10

40 60 800

2

4

6

8

10

%

Á r e a

40 60 800

2

4

6

8

10

%

Área resultante en fcn. del % de la CotaW

20 Part10 Part

40 Part

80 Part 100 Part

60 Part

Fig. 3. Area de la estimacion resultante para 40, 60 y 80 %.

10 20 40 60 80 1000

2

4

6

8

10

40 % Á r e a

Área resultante en fcn. del Nro. Mín. Part.

10 20 40 60 80 1000

2

4

6

8

10

60 % Á r e a

10 20 40 60 80 1000

2

4

6

8

10

Número mínimo de part. a conservar

Á r e a

80 %

Fig. 4. Area de la estimacion resultante para los diferentes numeros departıculas iniciales.

a conservar es de 15; una vez que se encuentran 15 part ıculas

cuyo peso supere la cota, se da por terminada la estimacion.

Una corrida consta de tres estimaciones consecutivas, en el

orden mostrado de los nodos (2-3-4), una estimacion por nodo

sensor y se transmite. La tercer estimacion consecutiva es la

que se denomina “estimacion resultante”. En la Fig. 3 se ve el

area de la estimacion resultante como funcion del porcentaje

del W max que se toma como CotaW ; como era de esperar,

el area se reduce a medida que se aumenta la precisi on que se

le exige al filtro al aumentar CotaW . Arriba sobre la derecha

se indica el numero de partıculas iniciales. En la Fig. 4 se

muestran en forma diferente los mismos resultados que en la

Fig. 3.

40 60 800

40

80

120

160

200

N r o .

P a r t .

Media del número de partículas generadas en cada corrida

40 60 800

40

80

120

160

200

40 60 800

40

80

120

160

200

N r o .

P a r t .

40 60 800

40

80

120

160

200

40 60 800

40

80

120

160

200

%

N r o .

P a r t .

40 60 800

40

80

120

160

200

%

100 Part

10 Part 20 Part

40 Part 60 Part

80 Part

Fi g. 5. Numero medio de partıculas generadas en cada corrida para 40, 60y 80 %.

0 20 40 60 80 100 1200

40

80

120

160200

N r o .

P a r t .

Nro. medio de part. generadas para una corrida

10 20 40 60 80 1000

40

80

120

160

200

N r o .

P a r t .

10 20 40 60 80 1000

40

80

120

160

200

Nro. mínimo de part. iniciales

N r o .

P a r t .

40%

60%

80%

Fig. 6. Media del numero de partıculas generadas en una corrida en funcionde las partıculas iniciales.

En las Fig. 5 y Fig. 6 se muestra el numero medio de

partıculas generadas por corrida en funcion de los porcentajes

y del numero de partıculas iniciales. Se puede observar que a

medida que aumenta el porcentaje en el calculo de CotaW se

reduce el area mas probable, haciendo necesaria la generacion

de un mayor numero de partıculas para lograr cumplir con las

15 mınimas (dentro de dicha area) requeridas para terminar la

estimacion.

En la Fig. 7 se muestra la varianza sobre el eje Y. Se puedeobservar que se reduce notablemente al aumentar el porcentaje

en el calculo de la cota de peso. En las Fig. 8 se pueden ver

las estimaciones resultantes de las 20 corridas del algoritmo

para 80 partıculas iniciales de donde se selecciona el mayor

peso. En el grafico de la izquierda se utiliza una cota de peso

del 40% de W max, mientras que en el grafico de la derecha

se utiliza una cota del 80 % de W max. Se ve claramente la

forma en que se reduce el area mas probable.

C. Casos Especiales

1) Caso 1: Se realiza una configuracion de red poco

aconsejable, ya que por la ubicacion de los sensores los

cırculos estimados no se cortan perpendicularmente en ningun

momento, por estar los sensores alineados. Para este caso se



95




10 20 40 60 80 1000

0.2

0.4

0.6

0.8

1

V a r i a n z a ( m . )

Varianza del eje Y en fcn. del Nro. Mín. Part.

10 20 40 60 80 1000

0.2

0.4

0.6

0.81

V a r i a n z a ( m . )

10 20 40 60 80 1000

0.2

0.4

0.6

0.8

1

Nro Mín. Part. a conservar

V a r i a n z a ( m . )

60 %

80 %

40 %

Fig. 7. Varianza en el eje Y en funcion de las partıculas iniciales.

−0.5 0 0.5 1 1.5 2 2.5

−0.5

0

0.5

1

1.5

2

2.5

Eje X (m.)

E j e Y ( m . )

Estimaciones resultantes para 40% y 80 partículas iniciales

−0.3 − 0.2 −0.1 0 0.1 0.2 0.3 0.4

−0.6

−0.4

−0.2

0

0.2

0.4

Eje X (m.)

E j e Y ( m . )

Estimaciones resultantes para 80% y 80 partículas iniciales

Fig. 8. Varianza en el eje Y en funcion de las partıculas iniciales.

seleccionan las partıculas cuya cota supere el 60 % de W max

entre los pesos de 80 partıculas inicialmente generadas. Una

vez que se encuentran 15 partıculas que superan dicha cota,

se extraen las cotas de rango y angulo que las encierran. En

la Tabla II se detalla la ubicacion de los sensores. En la Fig. 9

se pueden apreciar las sucesivas estimaciones hasta llegar a la

estimacion resultante. Se simbolizan con cırculos los sensores

y con una estrella la fuente, que esta en el origen. Para ver

como actua cada nodo, en la Fig. 10 se ve m as en detalle.

En cada cuadro se muestran las particulas generadas dentro

de las cotas que pasa el sensor anterior, y en linea llena las

nuevas cotas que encierran las partıculas mas pesadas, las

seleccionadas por tener un peso superior a la cota de peso.

2) Caso 2: En este caso los nodos se encuentran alineados

en una lınea diferente a la de la fuente, a tres metros de

distancia. Es una configuracion mala de la red, ya se veraa continuacion porque. La Fig. 11 muestra una corrida de

estimaciones de la red; en cada caso se muestran las partıculas

generadas dentro de las cotas que se reciben del nodo sensor

anterior y el area determinada por la nueva estimacion (lınea

Node X (m.) Y (m.) z (m.)

1 0 0 -

2 -4 0 4.0499

3 -6 0 6.0311

4 -2 0 1.9474

Tabla II

UBICACIÓN Y ORDEN DE ESTIMACI

ÓN DE LOS SENSORES CON EL NODO 1COMO ORIGEN DE COORDENADAS.

−8 −6 −4 −2 0 2 4 6 8−8

−6

−4

−2

0

2

4

6

8

X (m.)

Y ( m . )

Estimaciones en cada paso de una corrida

Fig. 9. Estimaciones para un caso especial.

−5 0 5

−5

0

5

Y ( m . )

Estimaciones en una corrida

−5 0 5

−5

0

5

X (m.)

−5 0 5

−5

0

5

−5 0 5

−5

0

5

X (m.)

Y ( m . )

Fig. 10. Pasos en una corrida.

completa) que encierra las partıculas mas pesadas; el ultimo

grafico muestra las areas de las estimaciones resultantes. La

Fig. 12 muestra en detalle las areas de las estimaciones

resultantes de una corrida del algoritmo en la red. Los cırculos

negros corresponden a los sensores y la estrella negra a

la fuente. La primer estimacion se representa en rojo, la

segunda en azul y la final en verde. Como se puede observar,

las areas estimadas no se reducen y no lo haran, debido a

la configuracion de la red. En casos como este se pueden

implementar otros metodos para rescatar mas informacion.

Como estrategia se podrıa cortar la cota de angulo a la

mitad y evaluar las partıculas de cada mitad por separado.

Otra forma es seleccionar las partıculas mas pesadas en cada

mitad, comparando su peso con una cota que es porcentaje del

maximo peso de cada mitad. Luego de ello se extraen las cotas

de angulo y rango dando como resultado lo que se muestra en

Fig. 13.

VI . CONCLUSIONES Y L INEAS FUTURAS

El BPF cumple con las restricciones de procesamiento,

almacenamiento y comunicacion que presentan los nodos,

soluciona el problema de empobrecimiento de muestras y de

convergencia; tambien evita el procesamiento que implica el

remuestreo y aporta una forma de resumir la informacion de la

estimacion de modo de transmitir la menor cantidad de datos

posible. Se prueba que el algoritmo converge a un estimado

representativo del estado con muy poco procesamiento y sin



96




−5 0 5

−5

0

5

Y

( m . )

−5 0 5

−5

0

5

X (m.)

−5 0 5

−5

0

5

−5 0 5

−5

0

5

X (m.)

Y

( m . )

Fig. 11. Corrida de estimaciones.

−8 −6 −4 −2 0 2 4 6 8−8

−6

−4

−2

0

2

4

6

8

X (m.)

Y

( m . )

Fig. 12. Areas estimadas.

−4

−2

0

2

−5

0

5

100

0.5

1

1.5

2

X (m.)

W e i g h t

−5 − 4 −3 −2 −1 0 1 2 3−1

0

1

2

3

4

5

6

7

X (m.)

Y ( m . )

Fig. 13. Pasos en una corrida.

necesidad de almacenar ni transmitir partıculas. En el trabajo

se muestran resultados de la implementacion del filtro sobre

nodos comerciales, por software, pero debido a la necesidad

de reducir la energıa al mınimo, serıa muy interesante laimplementacion del algoritmo en un chip. Se demuestra que

las funciones empleadas son basicas y el almacenamiento

necesario mınimo, de modo que no se esta muy lejos de la

posible implementacion. Se debe complementar el algoritmo

con algoritmos de sincronizacion de la red, de localizacion

de los nodos dentro de la misma y de seleccion del nodo

vecino mas informativo. Es importante estudiar el calculo de

la cota de peso basado en las incertidumbres de proceso y

observacion. Tambien se deben analizar las diferentes formas

de transmitir mayor informacion del estimado, ademas de las

cotas, de modo que la generacion de partıculas iniciales no

sea una uniforme, sino que aproxime mejor la curva real de

probabilidad a priori. Se puede extender el algoritmo para

deteccion de multiples fuentes.

REFERENCIAS

[1] B. Sadler, “Fundamentals of energy constrained sensor network sys-tems,” IEEE Aerospace and Electronic Systems Magazine Part.2 Tuto-rials, vol. 20, no. 8, pp. 17–35, 2005.

[2] I. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci, “Wireless

sensor networks: a survey,” Computer Networks, vol. 38, no. 4, pp. 393–422, 2002.[3] J. Yick, B. Mukherjee, and D. Ghosal, “Wireless sensor network survey,”

Computer Networks, vol. 12, no. 52, pp. 2292–2330, 2008.[4] M. Terwilliger, A. Gupta, V. Bhuse, Z. H. Kamal, and M. Salahuddin,

“A localization system using wireless network sensors: A comparison of two techniques,” in Proceedings of the First Workshop on Positioning,

Navigation and Communication, Hannover, Germany, March 2004, pp.95–100.

[5] L. M. Kaplan, “Global node selection for localization in a distributedsensor network,” Aerospace and Electronic Systems, IEEE Transactionson, vol. 42, no. 1, pp. 113–135, 2006. [Online]. Available:http://dx.doi.org/10.1109/TAES.2006.1603409

[6] A. C. Rodriguez, “Circuitos integrados de bajo consumo para deteccion ylocalizacion de disparos de armas de fuego,” Ph.D. dissertation, Facultadde Ingenierıa, Universidad Nacional de Mar del Plata, Mar del Plata,Argentina, Mayo 2009.

[7] M. Coates, “Data fusion in decentralized sensing networks,” 4th Inter-national Conference on Information Fusion, Montreal, Canada, 2001.[8] H. Durrant-Whyte, M. Stevens, and E. Nettleton, “Data fusion in decen-

tralized sensing networks,” in Proceedings 4th International Conferenceon Information Fusion, 2001, pp. 302–307.

[9] I. F. Akyldiz, T. Melodia, and K. R. Chowdhury, “Wireless multimediasensor networks: Applications and testbeds,” Proceedings of the IEEE ,vol. 96, no. 10, pp. 1588–1605, 2008.

[10] D. Blatt and A. D. H. III, “Energy-based sensor network sourse local-ization via projection onto convex sets,” IEEE Transaction on SignalProcessing, vol. 54, p. 3614, 2006.

[11] A. Makarenko and H. Durrant-Whyte, “Decentralized data fusion andcontrol in active sensor networks,” in Proceedings of the Seventh

International Conference on Information Fusion, 2004.[12] M. S. Arulampalan, S. Maskell, N. Gordon, and T. Clapp, “A tutorial

on particle filters for online nonlinear/non-gaussian bayesian tracking,” IEEE Transactions on Signal Processing, Special Issue, vol. 50, no. 2,

pp. 174–188, 2002.[13] F. Daum, “Nonlinear filters: Beyond the kalman filter,” IEEE Aerospaceand Electronic Systems Magazine, vol. 20, no. 8, pp. 57–69, 2005.

[14] T. Bailey, “Constrained initialisation for bearing-only slam,” in Proceed-ings IEEE International Conference on Robotics Automation, Taipei,Taiwan, Sept 2003, pp. 1966–1971.

[15] J. Carpenter, P. Clifford, and P. Feamhead, “Improved particle filterfor nonlinear problems, radar, sonar and navigation,” IEE Proceedings

Radar, Sonar and Navigation, vol. 146, no. 1, pp. 2–7, 1999.[16] J. Kotecha and P. Djuric, “Gaussian particle filtering,” IEEE Transactions

On Signal Processing, vol. 51, no. 10, pp. 2592–2601, 2003.[17] ——, “Gaussian sum particle filtering for dynamic state space models,”

in Proceedings International Conference in Acoustics, Speech, SignalProcessing, Salt Lake City, UT, May 2001, pp. 3465–3468.

[18] A. Gning, F. Abdallah, and P. Bonnifait, “A new estimation method formultisensor fusion by using interval analysis and particle filtering,” inProceedings IEEE International Conference on Robotics Automation,

Roma, Italy, April 2007, pp. 3844–3849.[19] S. R. Sanudo and F. Masson, “Filtro de partıculas acotado para fusion dedatos en redes de sensores,” in Proceedings of the Jornadas Argentinasde Rob´ otica, Cordoba, Argentina, 2006.

[20] S. R. Sanudo, F. Masson, and P. Julian, “Bounded state space particlefilter for network sensors,” IEEE International Symposium on Circuitsand Systems, Sensory Systems I Lecture session C4L-M , pp. 3570–3573,2007.

[21] C. T. Inc.2004. Wireless sensor networks. [Online]. Available:http://www.xbow.com

[22] TinyOS. (2004) Open sourse operating system for sensor networks.[Online]. Available: http://www.tinyos.net/,//webs.cs.berkeley.edu/tos/

[23] P. Levis, S. Madden, J. Polastre, R. Szewczyk, K. Whitehouse, A. Woo,D. Gay, J. Hill, M. Welsh, E. Brewer, and D. Culler, “Tinyos: Anoperating system for sensor networks,” Ambient Intelligence, 2005.

[24] M. Matsumoto and Y. Kurita, “Twisted gfsr generators ii,” ACM Transac-tions on Modelling and Computer Simulation, vol. 4, no. 3, pp. 254–266,

1994.



97




Tecnología inalámbrica Near Field Communication ysus aplicaciones en sistemas embebidos

Esp. Ing. María Fernanda CarignanoEspecialidad en Sistemas EmbebidosInstituto Universitario Aeronáutico

Av. Fuerza Aérea 6500 - (5010) Có[email protected]

Dr. Pablo FerreyraPosgrado Sistemas Embebidos IUAUniversidad Nacional de Córdoba

[email protected]

Abstract — El estándar internacional NFC define una nueva

tecnología inalámbrica basada en radiofrecuencia que funciona

en un radio de cobertura pequeño. El presente trabajo analiza la

tecnología NFC y su aplicación real usando el lenguaje Java

desde el punto de vista de la Ingeniería de Software.

NFC, RFID, sistemas embebidos, tecnología inalámbrica

I. I NTRODUCCIÓN

La tecnología NFC se basa en RFID (Radio-frequencyidentification), una tecnología inalámbrica que está endesarrollo desde hace casi cuatro décadas. NFC es unatecnología estandarizada que tiene como propósito ser usada

para facilitar la interconexión de dispositivos y el intercambiode datos en un entorno acotado. En conjunto con la creacióndel estándar NFC, en 2004 surge el NFC Forum que,

basándose en dicho estándar, ha creado una serie de protocolosque normalizan la forma en que NFC debe usarse paragarantizar la interoperabilidad de dispositivos de distintosfabricantes. Este trabajo presenta un panorama general de

diversos aspectos de la tecnología NFC. Se realiza unacomparación entre NFC y otras tecnologías inalámbricas,destacando las aplicaciones para las que NFC representa unaventaja. Como último aporte ofrece nociones acerca deldesarrollo de aplicaciones Java para dispositivos NFC a nivelsoftware, pero sin involucrarse con las cuestiones relacionadascon la electrónica y el hardware.

La sección Tecnología NFC describe los orígenes de NFC,sus características técnicas, los estándares que la especifican yestablece una comparación con otras tecnologías relacionadas.

La sección NFC en el mercado de consumo masivo ofreceejemplos de aplicaciones NFC, dispositivos NFC disponiblescomercialmente y un resumen de pruebas piloto que se handesarrollado hasta la actualidad.

La sección Desarrollo de aplicaciones Java paradispositivos NFC describe una aplicación NFC real usando elSDK (Software Development Kit) provisto por Nokia para suteléfono Nokia 6131 NFC.

II. TECNOLOGÍA NFC

A. Orígenes

La tecnología RFID comenzó a esbozarse durante laSegunda Guerra Mundial [1][2]. RFID permite el uso de unobjeto (normalmente llamado tag RFID) que se adosa a un

producto, animal o persona con el propósito de identificación yseguimiento usando ondas de radio. Un tag RFID consta de dos

partes principales: a) un circuito integrado para almacenar y procesar información, modular y demodular la señal de RF yotras funciones especializadas; b) una antena para recibir ytransmitir la señal. Los tags RFID se pueden clasificar en tresgrandes grupos [3]: activos, pasivos y pasivos asistidos porbatería.

Una de las tecnologías que se derivan de RFID es NFC,cuya característica principal es el hecho de combinar ambasfunciones de tag y reader/writer RFID en un único dispositivo.Dado que NFC es una extensión de RFID, es compatible contoda la infraestructura RFID existente.

B. Características técnicas

NFC es una tecnología de comunicaciones inalámbrica decorto alcance y alta frecuencia que permite el intercambio dedatos entre dos dispositivos cercanos. Estos dispositivosreciben el nombre de Iniciator (el que origina la transmisión) yTarget (el receptor). NFC funciona en la banda frecuencia nolicenciada de 13,56 MHz en una distancia de hasta 20 cm.

NFC está basada en el principio de inducciónelectromagnética por el cual dos circuitos inductivos cercanoscomparten energía con lo cual pueden transmitir datos adistancias de pocos centímetros.

En forma similar a RFID, NFC define dos modos deoperación: activo y pasivo.

Dado que NFC es una tecnología derivada de RFID la cualse ha estado usando en múltiples aplicaciones en entornosreales, NFC soporta tasas variables de transferencia paraasegurar la interoperabilidad con la infraestructura preexistente.Actualmente ofrece tasas de transferencia de datos de 106, 212y 424 Kbps, pero se esperan valores más altos en el futuro.



98




C. Seguridad

NFC provee de una seguridad intrínseca dada por ellimitado radio de comunicación de unos pocos centímetros.Pero si bien esto dificulta la tarea de "robar" información deningún modo garantiza que una comunicación NFC no puedaser vulnerada [4]. Algunas de las amenazas a la seguridad delas comunicaciones NFC son: escuchas secretas(eavesdropping), corrupción de datos, modificación de

datos, inserción de datos, ataque del "Hombre en el medio"(Man-in-the-middle).

D. Estandarización

La tecnología NFC ha sido estandarizada por ISO/IEC(International Organization for Standardization/ InternationalElectrotechnical Comision), ETSI (EuropeanTelecommunications Standards Institute) y ECMA (EuropeanComputer Manufacturers Association) [5]. Los estándares[6][7][8] especifican los esquemas de modulación,codificación, velocidad de transferencia y formato de la tramade la interfaz de RF para dispositivos NFC, así como tambiénlos esquemas de inicialización y condiciones requeridas para

control de colisiones durante la inicialización. También definenel protocolo de transporte, incluyendo métodos de activacióndel protocolo e intercambio de datos.

Además un conjunto de empresas internacionales líderes ensus rubros consituyó en 2004 el NFC Forum [9], unaorganización sin fines de lucro cuya misión es fomentar el usode la tecnología NFC desarrollando especificaciones[10][11][12][13], asegurando la interoperabilidad entredispositivos y servicios [14][15] y educando al mercado acercade esta tecnología.

E. Tecnologías relacionadas

La posibilidad de comunicación inalámbrica basada enondas de RF dio lugar al desarrollo de numerosas tecnologías

basadas en el mismo principio físico. En la Tabla 1 se detallany comparan las tecnologías inalámbricas de comunicacionesque complementan o tienen un ámbito de aplicaciónequivalente a NFC [10]. La Fig. 1 muestra esta comparaciónentre tecnologías en forma gráfica dando una vista simplificadade las diferencias entre ellas en cuanto a alcance y velocidad detransmisión.

TABLA I. COMPARACIÓN ENTRE TECNOLOGÍAS INALÁMBRICAS

NFC RFID WiFi Bluetooth ZigBee IrDA

Estándar ISO/IEC18092

ISO/IEC14443

IEEE 802.11 IEEE802.15.1

IEEE802.15.4

IrDA

Tasa detransferencia

106-424Kbps

106-424Kbps

11-200 Mbps 1-480 Mbps 20-250 kbps 1 Kbps – 100Mbps

Frecuenciadefuncionamiento

13,56 MHz 13,56 MHz 2.4, 5.25,5.6, 5.8 GHz

2.4 GHz 868/915MHz2.4 GHz

Cantidadmáxima dedispositivosque puedeninteractuar

2 2 Indefinida 8 Indefinida 2

Tiempo deinicialización

< 0,1 ms < 0,1 ms < 0,1 ms 6 s < 0,1 ms 0,5 ms

NFC RFID WiFi Bluetooth ZigBee IrDA

Alcance < 20 cm < 3 m < 100 m < 30 m < 500 m < 5 m

Seguridad Dada por lacercaníaentredispositivos

Dada por lacercaníaentredispositivos

Determinada por losmecanismosdeencriptaciónque se usen



Dada por elrequerimiento de ambosdispositivosestén en lalínea devista.

Consumo de

energía

Mínimo o

inexistente

Mínimo o

inexistente

Alto para

dispositivosalimentadoscon baterías

Alto para

dispositivosalimentadoscon baterías

Muy bajo Bajo

Objetivo Simplificar lainteracciónentredispositivoselectrónicos

Realizar seguimientode objetos ycontrol deacceso

Reemplazar cables enredesextensas,fundamentalmente detipo LANs

Reemplazar cables paraconectar dispositivoselectrónicoscercanos

Control ymonitoreoinalámbrico

Reemplazar cables paraconectar dispositivoselectrónicoscercanos

Ejemplo deaplicación

Intercambiode tarjetas personaleselectrónicasacercandodos teléfonoscelulares

Control deinventario ensupermercados.

Conexiónentredispositivosde unaoficina (PCs,notebooks,impresoras,etc.) dentro

de un mismoedificio oentreedificioscercanos

Conexión de periféricos(teclado,mouse, etc.)a unanotebook enla mismahabitación

Manejo desistema deriego yfertilizaciónensembradosusandosensores que

de acuerdo alos valoresde ciertasvariablesaccionan losmecanismoscorrespondientes

Transferencia de archivosentre unteléfonocelular y unanotebook

Figura 1. Alcance y velocidad de transmisión de las tecnologías inalámbricas

III. NFC EN EL MERCADO DE CONSUMO MASIVO

La evolución de la tecnología RFID en el área de NFC hadado origen a un completo conjunto de aplicaciones reales queson no sólo técnicamente factibles sino comercialmenteviables. NFC ofrece una relación costo-beneficio apropiada

para el mercado masivo y cumple con estándares acordadosinternacionalmente.

El principal atractivo de la tecnología NFC es el permitir variadas formas de comunicación y transacciones de un modomuy cómodo y amigable para el usuario.

En relación a esta simplicidad de uso, se puede establecer una analogía con otros dispositivos de uso cotidiano como unsimple interruptor para iluminar una habitación o un picaporte

para abrir una puerta. Su uso es casi intuitivo para la mayoríade la gente y no es necesario conocer los principios físicos que

permiten que funcionen, ni leer un extenso manual de uso. Lo



99




mismo ocurre con NFC, la idea es que con una acción simplecomo "tocar" o acercar un dispositivo NFC a otro, se inicie elservicio deseado, permitiendo que el uso de cualquier "servicio" electrónico y otras interacciones sean accesibles amás gente sin importar su edad o capacidades [16].

A. Ejemplos de aplicaciones NFC

Existen numerosas aplicaciones de NFC que aquí se van a

agrupar en las tres categorías propuestas por InnovisionResearch & Technology plc [14]:

• Service initiation: este tipo de aplicaciones consistenen que el usuario toque con su dispositivo NFC (por ejemplo un teléfono) un tag NFC dispuesto a tal efectoen lugares definidos. De esta forma el tag NFCtransfiere al dispositivo NFC una pequeña cantidad dedatos (texto, URL, número telefónico o cualquier otrodato breve) que le permitirán al usuario realizar algunaacción. Algunos ejemplos de este tipo de aplicaciones:

o Carteles inteligentes (smart posters) en la vía pública promocionando un producto,

servicio, evento, etc. que proporcionan unaURL al usuario donde puede obtener másinformación acerca del producto o servicio

publicitado, o bien reservar las entradas parael evento.

o Información adicional sobre productos en uncomercio cuando el usuario toca dicho

producto con su dispositivo NFC.

o Control de temperatura o iluminación de unahabitación sin tener que moverse del lugar donde la persona está sentada (con tagsubicados en muebles que la persona puedetocar con su dispositivo NFC).

o Registro de visitas efectuadas por personalde guardia de un edificio a medida que haceel recorrido de rutina por todas las zonasdefinidas en el lugar.

o Etiquetas adhesivas con tags NFC decomercialización masiva en las que elusuario puede especificar un dato que seráusado por un dispositivo NFC para realizar una acción. Por ejemplo, se pueden adherir etiquetas con números telefónicos a fotos defamiliares para que una persona concapacidades visuales o de movimiento

reducidas pueda llamar a un familiar consólo acercar su teléfono NFC a la fotocorrespondiente

1. Otro uso de estas etiquetas

permitiría que cuando un niño llega a suhogar desde la escuela, toque con su teléfonocelular NFC un tag NFC ubicado en la puertade la casa y se envíe un SMS a sus padres.

1 Corresponde al caso de uso descrito en la aplicación de prueba de

concepto.

• Peer-to-peer: este tipo de aplicaciones usan NFCcomo mecanismo para establecer la comunicaciónentre dos dispositivos que necesitan intercambiar datos. Luego el intercambio de datos real puederealizarse usando NFC u otra tecnología inalámbricaque resulte apropiada de acuerdo con el volumen dedatos transmitidos. Algunos ejemplos dentro de estegrupo de aplicaciones:

o Transmisión de fotos desde una cámaradigital a una impresora: mediante NFC seestablece una conexión Bluetooth que es laque se usa para transmitir las fotos.

o Intercambio de tarjetas personales a través deuna conexión Bluetooth establecida por

NFC.

o Configuración automática de una conexiónWi-Fi en lugares públicos: el usuario tocacon su teléfono móvil un tag ubicado en lamesa que le transmite la configuración de lared y luego toca su computadora portátil con

el teléfono para configurar la red e iniciar laconexión.

• Payment & ticketing: este tipo de aplicaciones es elque principalmente dio origen a los estándares NFC.Dado que desde hace tiempo se usan contactless cards

para ciertas transacciones comerciales y compra de pasajes en medios de transporte, la nueva tecnología NFC tuvo que ser definida para mantener compatibilidad con las aplicaciones existentes.Algunos ejemplos de aplicaciones:

o Pagos en expendedoras automáticas y parquímetros.

o Consulta de saldo en tarjetas para transportesin necesidad de concurrir a un lugar específico para obtener este dato.

o “Billetera electrónica”: la tendencia final esevitar la necesidad de usar tarjetas plásticas

para cada uno de los sistemas de fidelizaciónde clientes con puntos, acceso a cobertura desalud, tarjetas de débito y crédito, etc. y

poder realizar todas la transaccionescomerciales usando el teléfono móvil. Deesta forma hasta los pagos mínimosquedarían registrados en un resumen decuenta facilitando el control de gastos. Un

estudio desarrollado por Visa Internacionaldeterminó que el 89% de las personas quehan usado teléfonos móviles para realizar transacciones comerciales, prefieren estemétodo sobre otras alternativas de pago.

B. Desarrollo de un caso de uso de NFC: Un día en la vidade un usuario de NFC

Alicia, usuaria de un teléfono NFC, tiene una entrevista yse traslada desde su casa hasta el lugar en su auto que deja enuna playa de estacionamiento. Al ingresar a la playa acerca su



100




teléfono al lector NFC y registra el horario de ingreso. Luegomientras camina hasta el lugar de la reunión ve una publicidaden la calle sobre calzado de la nueva temporada. El cartelincluye el logo de NFC, entonces Alicia se acerca al cartel ycon su teléfono obtiene un cupón de descuento para compra delcalzado publicitado. Cuando termina la entrevista, va a retirar su coche del estacionamiento, acerca su teléfono al lector nuevamente y, previa confirmación en el teléfono, se debita de

su cuenta bancaria el monto del estacionamiento.Antes de regresar a su hogar, Alicia decide aprovechar su

descuento en calzados y viaja en su auto a la zona comercialdonde lo deja estacionado en un parquímetro. En este caso,también acerca su teléfono al parquímetro, el cual registra losdatos de Alicia y la hora de inicio del estacionamiento.

Alicia llega a la zapatería. Allí la mercadería está dispuestaen la vidriera de modo que cualquier cliente con su teléfono

NFC pueda leer la información contenida en las etiquetas NFCadheridas al calzado exhibido. Entonces Alicia, sin necesidadde ingresar al local y esperar a un vendedor, averigua loscolores, precio y numeración disponible de los modelos que leinteresan, acercando su teléfono a la vidriera. En base a estainformación decide cuál es el modelo a adquirir, ingresa allocal, se lo solicita al vendedor para medirlo y finalmenteconcreta la compra. Paga usando una tarjeta de crédito de su"billetera electrónica": acerca el teléfono NFC al lector en lacaja, elige la tarjeta de crédito y presenta el cupón dedescuento, concluyendo la compra. Luego regresa a buscar suauto, acerca su teléfono al parquímetro y se debita de su cuenta

bancaria el monto correspondiente al estacionamiento.

Por su parte, en el circuito de fabricación de calzados, cadaunidad de producto, incluye en la suela una etiqueta NFC que

permite identificar a cada componente del par de zapatosunívocamente. Luego los zapatos se ponen en sucorrespondiente caja equipada con un lector NFC mediante el

cual, si los zapatos colocados dentro de la caja no son loscorrectos, se genera una señal audible y luminosa ayudando enel guardado de la mercadería en su correspondiente caja.

Las cajas así etiquetadas también facilitan la realización decontroles de inventario periódicos en el local comercialmediante el uso de un teléfono NFC que registra la mercaderíaexistente en el depósito y luego la compara con la mercaderíaefectivamente consignada en el sistema informático.

Si bien toda la tecnología necesaria para implementar estecaso de uso está disponible, en un país como Argentina haycuestiones de carácter socio-económico a resolver antes de

poder implementarlo:

• Los dispositivos NFC aún no son de consumo masivo.

• El acceso a Internet en celulares es lento y tiene un precio relativamente elevado para la población engeneral.

• Mucha gente cuando sale de compras no lo hace comouna tarea más que tiene que ser rápida y eficiente, sinocomo un modo de estar en contacto con otra gente ydialogar con los vendedores.

• En las grandes urbes es necesario volver a concientizar a la ciudadanía acerca de la responsabilidad en elcuidado de los bienes públicos.

C. Dispositivos NFC

En la actualidad los principales fabricantes de celulares handesarrollado modelos con soporte para NFC [17] que estándisponibles principalmente en Europa y América del Norte.

D. Pruebas piloto

Desde hace unos años se desarrollan pruebas piloto endiversos lugares del mundo con el fin de obtener información

para desarrollar servicios basados en NFC acordes a lasexpectativas de la gente [18]. La mayor parte de las pruebasestán relacionadas con aplicaciones de pago en comerciosminoristas o compras en expendedoras automáticas. Otro gran

porcentaje de pruebas es acerca del uso de smart posters paraofrecer información a los usuarios, publicidad o promociones ydescuentos para usar en sus compras en comercios. También serealizaron numerosas pruebas de aplicaciones para compra de

pasajes en los medios de transporte público (ómnibus,

subterráneos, trenes) y en menor medida aplicaciones paracompra de entradas a espectáculos, estacionamiento y otras.

IV. DESARROLLO DE APLICACIONES JAVA PARA

DISPOSITIVOS NFC

A. Descripción de la API para desarrollo de aplicaciones

NFC (JSR-257)

Los dispositivos móviles con hardware NFC, para permitir el desarrollo de aplicaciones Java que hagan uso de dichohardware deben implementar la JSR-257 [19] cuya estructurade clases, paquetes e interfaces se detalla en la Fig. 2 y permitea las aplicaciones acceder a información en contactless targets

tales como smart cards, tags NFC y tags visuales (códigos de barras) [20].

Un dispositivo con soporte para JSR-257 debe incluir todaslas clases e interfaces definidas en esta especificación pero noes requerida la implementación de la funcionalidad de todos lostargets, aunque si se implementa un target, es requerido queexista el dispositivo físico correspondiente.

La JSR-257 es una especificación de referencia, luego cadafabricante puede implementar los componentes que desee y/oextenderla con soporte para contactless targets adicionales [21].

B. Aplicación de prueba de concepto usando Nokia 6131

NFC En esta sección se describe una aplicación de prueba de

concepto desarrollada para el teléfono Nokia 6131 NFC, unode los dispositivos disponibles comercialmente [22] que proveesoporte para NFC mediante la implementación de laespecificación JSR-257.

1) Entorno de desarrollo Nokia provee a los desarrolladores un conjunto de

herramientas denominado Nokia 6131 NFC SDK 1.1 queincluye un emulador del teléfono y de las tarjetas y tags NFC.



101




El teléfono Nokia 6131 NFC implementa un subconjuntode la JSR-257, la Tabla 2 detalla el soporte para contactlesstargets ofrecido por este dispositivo indicando, cuando esténdisponibles, los componentes Java que permiten la interaccióncon estos targets.

Figura 2. Componentes de la JSR-257

2) Caso de usoPermitir al usuario doméstico, usando su teléfono celular

NFC, la creación de tags NFC2

adhesivos con información útil para adjuntar a objetos de uso cotidiano. Estos tags podrán ser leídos luego usando también teléfonos como el Nokia 6131

NFC que proveen soporte nativo para le lectura de algunos

tipos de datos almacenados en tags NFC (tarjetas personales(business cards), números telefónicos, direcciones web).

TABLA II. TAGS IMPLEMENTADOS EN NOKIA 6131 NFC

Tipo de

tag

Denominación Componente Java relacionado

Visual (No implementado) avax.microedition.contactless.visual(incluye solamente clases stub paracumplir con la JSR-257)

NFCForum

Tipo 1 (Innovision Topaz)Tipo 2 (Mifare Ultralight)Tipo 3 (Sony FeliCa)Tipo 4 (Mifare DESFire)

-com.nokia.nfc.nxp.mfstd.*com.sony.felica.Type3TagConnectioncom.nokia.nfc.nxp.desfire.*

Otros Innovision Jewel

Mifare Standard 1K Mifare Standard 4K

com.innovision.rf.JewelTagConnection

com.nokia.nfc.nxp.mfstd.*com.nokia.nfc.nxp.mfstd.*

3) Arquitectura de la aplicaciónLa aplicación de prueba de concepto permite crear tags y

leer su contenido. Está basada en los principios de orientación aobjetos [23] y en su arquitectura se aplican tres patrones dediseño principales: MVC (Model View Controller), Singleton y Observer/Listener.

2 Una etiqueta de bajo costo para este uso es la Mifare Ultralight [23]($6 a $10 por unidad, de acuerdo a la cantidad).

La Fig. 3 muestra una vista estática de la aplicacióndistinguiendo con dos colores las clases propias de laaplicación (gris) y las clases que forman parte de la API

provista por el teléfono (blanco).

Figura 3. Diagrama de clases

La Fig. 4 es una vista dinámica de la aplicación quedescribe la interacción entre las instancias de las clases(objetos) durante la ejecución de la aplicación.

4) ImplementaciónEl uso de la JSR-257 se puede resumir en los dos pasos

detallados a continuación que luego tendrán mayor o menor complejidad dependiendo de la necesidad de la aplicación. Los

pasos se ilustran con fragmentos de código tomados de laaplicación de prueba de concepto.

1. Registrar un contactless target para que en el momentoen que el teléfono detecte la presencia de un tag(NDEF en este caso), notifique a la aplicación a travésdel método targetDetected():

DiscoveryManager.getInstance().addTargetListener(this,

TargetType.NDEF_TAG);

2. Implementar el listener correspondiente al tipo deeventos que se quieren recibir (TargetListener en estecaso). La implementación consiste en abrir unaconexión con el target y realizar las operaciones delectura/escritura necesarias.

public void targetDetected(TargetProperties[] tp)

...

_ndefTagConnection = (NDEFTagConnection) Connector

.open(tp[0].getUrl(connections[i]));

NDEFRecord[] records = new NDEFRecord[1];

NDEFRecord phoneNumber = new NDEFRecord(new

NDEFRecordType( NDEFRecordType.URI, "tel:"+

DataController.getInstance().getPhoneNumber()), null,

null);

records[0] = phoneNumber;

NDEFMessage message = new NDEFMessage(records);



102




_ndefTagConnection.writeNDEF(message);

_ndefTagConnection.close();

...

Figura 4. Diagrama de secuencia

V. CONCLUSIONES

NFC es una forma de darle valor agregado a una tecnologíaque existe desde hace más de tres décadas y que ya se haimpuesto en el mercado: RFID. La ventaja principal de NFC esno ser "una tecnología más" sino generar todo un nuevomodelo de negocio basado en infraestructura existente yampliamente difundida (lectores de tarjetas en transportes,telefonía pública, etc.) y haciendo uso del dispositivo con másmercado masivo en la última década, el teléfono celular (si biencualquier otro dispositivo electrónico puede incorporar NFC)[10]. También se la puede ver como una tecnología que traenuevos usos para artefactos que desde hace tiempo no tieneninnovación por ejemplo, carteles, mobiliario, etc. [14].

Goza de cierta difusión en los países más avanzados deEuropa, Asia y América del Norte y todas las pruebas que sehan realizado en los últimos tres años demuestran el interés dela gente por la tecnología si bien ponen ciertos reparos en lascuestiones de seguridad, fundamentalmente cuando se trata deaplicaciones de pago o consulta de cuentas bancarias.

A pesar de ser una tecnología nueva, ha llegado a un gradode estandarización que la hace aplicable sin mayores cambios.Por lo tanto basados en los resultados de las experiencias piloto[18], el punto que tal vez requiera análisis y trabajo adicionales el relacionado a la seguridad en las transacciones. Este es elaspecto más sensible para el usuario final y de él prácticamentedepende la adopción masiva en cuestiones relacionadas a pagos[25]. Pero será solamente cuestión de tiempo y"evangelización", algo similar a lo ocurrido en su momento conlas tarjetas de crédito y débito, y luego la banca electrónicaonline.

En países en vías de desarrollo como la Argentina, las posibilidades de esta tecnología en el corto plazo son un tantomás acotadas ya que salvo en las principales ciudades, no estágeneralizado el uso de tarjetas con RFID para pago deservicios, y menos aún, de productos. Por otro lado, lasempresas de telefonía locales aún no comercializan productoscon NFC. Pero dado el elevado número de celulares de gamamedia que existen en la población, se puede esperar que en el

momento en que la tecnología surja en el país, rápidamenteencuentre adeptos como en el resto del mundo. Por lo tanto esun buen nicho de negocio explorar soluciones en este sentido yestar preparados para el momento en que la tecnologíacomience su incursión en el país.

R EFERENCIAS

[1] http://en.wikipedia.org/wiki/RFID

[2] United States Patent 3.713.148 - Cardullo, et al. (23-Enero-1973)

[3] http://www.telecomspace.com/wirelessnw-rfid.html

[4] http://mulliner.org/collin/academic/publications/vulnanalysisattacksnfcmobilephones_mulliner_2009.pdf

[5] ECMA-340

[6] ECMA-352[7] ISO/IEC 14443

[8] ISO/IEC 15693

[9] http://www.nfc-forum.org/home

[10] http://www.nfc-forum.org/resources/member_videos/NFC_Forum_14Feb07_Press_and_ Analyst_Briefing_Slides.pdf

[11] http://www.nfc-forum.org/resources/presentations/NFC_Forum_Webcast-7Oct08- NFC_For_Developers.pdf

[12] http://www.nfc-forum.org/resources/faqs/

[13] http://www.nfc-forum.org/specs/spec_list/

[14] http://www.nfc-forum.org/resources/N-Mark

[15] http://www.nfc-

forum.org/resources/white_papers/nfc_forum_marketing_white_paper.pdf

[16] http://www.nfc-forum.org/resources/white_papers/NFC_Forum_Mobile_NFC_Ecosystem_White_Paper.pdf

[17] http://www.nfc-research.at/index.php?id=45

[18] http://www.nfcnews.com/2009/07/14/nfc-pilots-and-implementations

[19] JSR-000257

[20] http://www.forum.nokia.com/info/sw.nokia.com/id/8a11d3f9-3061-40dd-afb9-8ad417293ef3/Nokia_6131_NFC_Technical_Product_Description_v1_0 _en.pdf.html

[21] http://developers.sun.com/learning/javaoneonline/2008/pdf/TS-5635.pdf

[22] http://java.sun.com/developer/technicalArticles/javame/nfc/

[23]

http://www.smartcardfocus.com/shop/ilp/id~227/p/index.shtml[24] Apuntes del módulo de la ESE: "Algoritmos y Patrones"

[25] http://www.forum.nokia.com/piazza/wiki/images/6/6b/Nokia_NFC_white_paper.pdf



103




Cost Effective Cross-layer Protocol

Testing: A Case Study

Marcelo Odin Guirado∗, Jose Pablo Escobedo†, Ana Cavalli†, Stephane Maag† and Ariel Sabiguero Yawelak ∗

∗Instituto de Computacion, Facultad de Ingenierıa

Universidad de la Republica, Montevideo, Uruguay

e-mail: modin|[email protected]† Departement Logiciels-Reseaux

TELECOM SudParis (ex INT), Evry, France

email: jose.escobedo|ana.cavalli|[email protected]

Abstract—Model-based testing has been successfully applied

to conformance testing of reactive systems such as networkprotocols, both on general purpose and embedded systems.However, doubts persist about the overhead on time and humanresources required. This work addresses the empirical quantifi-cation of model-based validation costs for medium and small-sized projects. In particular, it asseses the cost of model-basedtesting for cross-layer protocols. This paper presents how, inspite of some initial constraints in budget, human resources, timeframe and available tools, it was possible to produce a formalspecification or model, implement a fully functional prototypeand test it for conformance with test cases derived from themodel.

I. INTRODUCTION

Mobile devices support for wireless technologies and

TCP/IP connectivity allows the access to services through avariety of networking infrastructures. However, TCP/IP was

developed for wired networks and devices with sufficient

resources (bandwidth, energy, etc) such as servers or desktop

computers. A popular approach to improve the performance

of TCP/IP over wireless mediums are cross-layer protocol

optimizations.

As a part of the SCAN [1] project a system was required

to add cross-layer protocol optimizations to devices with con-

strained resources, such as embedded devices, while requiring

minimum or no modification to the network protocol stack.

Due to the intricacy of network protocols and the particular

challenges of cross-layer design (high coupling, interaction

among optimizations, etc), cost effective validation techniquesand tools were required.

Model-based testing [2], [3] has been successfully applied

to conformance testing of reactive systems such as network

protocols. However, time and human resources required may

turn this approach inefficient. In this paper is described how

model-based testing was applied to cross-layer protocol op-

timization in order to determine if it is a suitable and cost

effective methodology for the problem domain.

A prototype with a simple optimization protocol [4] was

implemented. To address modularity and non intrusiveness

The work presented in this paper is the result of a French-Uruguayancooperation, which was partially funded by the SCAN Project.

the ECLAIR [5] architecture was followed. Simulations and

testing techniques were conducted to validate the system. Itsspecification was modeled in SDL [6] and test cases were

semi-automatically derived from the model. An ad-hoc testing

automation tool was built to run the test suite against the

prototype.

A full iteration -from concept phase to execution and

validation- was accomplished within a tight schedule and with

scarce resources. The time devoted to this iteration comprised

the time to study tools and modeling language, to model the

specification of the system, to build an implementation and to

test it.

The rest of this paper is organized as follows: in section II

the methodology is presented. Cross-layer design and archi-

tectures were studied, as well as suitable means for validationsuch as verification and testing. In part III the cross-layer

optimization protocol and its implementation are presented and

discussed. In part IV the model of the system specification is

briefly described, an explanation on how it was used to validate

and test the prototype is given, and the results in terms of cost

are summarized. In part V conclusions are presented.

I I . METHODOLOGY

Layered architecture, such the ISO OSI [7] model, divides

networking software in layers which are collections of pro-

tocols with a specific function (such as binary transmission,

physical addressing, logical addressing, and so on). Each layer

provides services to the layer above and consumes servicesfrom the layer below through well defined interfaces. The

layered architecture promotes the isolation among layers, and

this modularity makes possible to replace implementations at

each layer while maintaining the interfaces. TCP/IP protocol

stack follows a similar layered architecture.

However, for embedded devices and wireless communica-

tions resources such as bandwidth, energy, etc. become scarce.

In order to optimize the utilization of these resources, higher

layers may benefit from information from lower layers and

vice versa.

Methodological grounds for this work are sketched in the

rest of this section. Cross-layer design and architectures were



104




studied, as well as suitable means for validation like verifica-

tion and testing.

A. Cross-layer design and architecture

Cross-layer design consists in violating layer isolation inorder to offer feedback between a layer with information and

another layer that can use this information to operate more

efficiently. An example of cross-layer optimization is flow

control among MAC and transport layers [8].

Although cross-layer design have proven a popular approach

to improve performance on wireless networks, there is a trade

off between modular architecture and optimizations. There are

various cross-layer architectures proposed in the literature that

could help alleviate these problems, such as PMI [9], ICMP

based [10], CLASS [11], CrossTalk [12], MobileMan [13],

ECLAIR [5]. Each architecture proposes a different approach

for signaling among layers, such as adding extra information

at PDU, direct interaction among layers through function calls,a common network parameters repository, etc.

The ECLAIR [5] architecture was chosen because it al-

lowed non intrusive introduction of cross-layer optimizations

(namely, it does not require modifications on the network

protocol stack), minimum stack overhead, extensibility, re-

versibility, portability and efficiency. Furthermore, details were

publicly available. ECLAIR separates the protocol implemen-

tation, residing in an optimization subsystem, from the inter-

action with the protocol stack, residing in a tuning subsystem.

This allows any changes taking effect in the protocol stack to

be isolated from the actual protocol.

Inter layer feedback is achieved through notifications of

changes in protocol stack data structures. The optimization of

the protocol stack behavior is achieved through changes of the

network parameters through an API presented by the tuning

subsystem, plus the algorithms in the optimization modules.

There are some limitations to the scope of this architecture.

Only asynchronous event detection is addressed through either

notifier chains or by polling the desired data structure with a

pre-established frequency. Explicit synchronization of the net-

work protocol stack and the optimizations protocols behavior

is not addressed, which can lead to loops. Integrity of the data

structures when concurrently accessed by the protocol stack

and the optimization protocol is not addressed.

B. Validation and Model-Based Testing

As the terminology on validation, verification and testing

is not always consistent in the literature, the meaning of

these concepts in the context of this paper are presented

here. To validate a system is to provide information that

increases the confidence in the hypothesis that the system was

built correctly. The most popular approaches for validation

are verification and testing. Verification is to interact with

the model of a system (using the model for simulations or

mathematically prove properties of the model), and testing is

to perform experiments on an implementation of the system

trying to find defects.

It has been stated [14] that 50% of the defects are introduced

in the coding phase of a software developing process, and only

15% are detected in design phase. Most defects are found

during testing. The cost of correcting a defect is higher the

later it is found. A consequence of this is that while it is

important to use techniques to detect defects as early as pos-

sible (such as model checking or any verification techniques),

it is on the testing phase of the actual implementations that

most defects are found so both approaches are convenient and

complementary.

For this reason model-based testing paradigm was chosen.

The goal of model-based testing is to reduce costs while

developing quality software by automating the testing process

as much as possible, in particular automating the test case

generation. In order to do so, a formal model of the system

specification is built and used to derive the test cases. This

formal model is developed in parallel to the implementation

of the system, thus the model could be verified and test casesgenerated while the system is still being implemented.

The ioco [15] (input output conformance testing) theory is

behind well known automated test case generation tools such

as TGV [16], [17] and TorX [18]. The theory states that it is

possible to establish the existence of a mathematical relation

(namely, ioco) between a formal model (the model of the

specification) and an implicit model corresponding to an actual

implementation by probing the implementation. In practice, to

prove conformance that way is not possible because any non

trivial system would require a test suite too huge to make

testing impractical. A compromise is achieved by restricting

test case generation to certain parts/behaviors of the model

specified as test purposes.The formal model is built in any of multiple formal spec-

ification languages such as SDL, LOTOS, IF, IOLTS, etc. In

general the model used for test case generation differs from

the model used for designing the system in that the first is

used to capture the behavior of the system while the later is

used to capture the structure of the system. It also differs in

the abstraction level, since the model used for test generation

can ommit many details. Therefore, the model and the system

can be built independently and simultaneously, and test cases

can be obtained even before the system had been finished,

shortening the time required for testing.

Maturity in modeling for design is not required, actually the

implementation could be developed from an informal speci-

fication of the requirements. However, it makes more sense

to use model-based testing when the software development

process has already automated the test execution.

SDL [6] was chosen as the modeling language for the model

of the system specification. SDL is known for its success in

the telecommunications and protocol design domain [19] [20],

as well as for the availability of tools to build models in that

language.

III. PROTOTYPE

In this section the cross-layer optimization protocol and its

implementation are presented and discussed.



105




A. Use Case

The optimization protocol that was chosen to be imple-

mented [4] was presented along with the ECLAIR architecture

proposal. Although a detailed description is beyond the scope

of this work, a brief explanation follows.The selected use case consists in setting priorities for TCP

connections that in turn determine the size of the receiver

announced window in each connection, thus accelerating

or slowing the sender, redistributing the throughput accord-

ing to the priorities. It is based on the following relation:

Throughput = RCV Window

RT T . The receiver window is a

parameter included in the TCP header which is adjusted

depending the use of the receptor buffer to prevent the loss of

packets.

While in theory this approach may seem valid, in practice

there are some flaws. The size of the receiver announced

windows represents the memory available for that connection,

but memory is not taken into account when setting the size of the new announced window.

When the size of the received segments is too small (for

instance, interactive sessions) it is not a good idea to rise the

size of the announced window because it would be filling the

buffers mainly with control information.

If the size of the receiver window is raised but the applica-

tion cannot consume the received packets, the buffers will be

filled for that connection and further packets will be discarded.

This may even be seen from the sender as a congestion,

furthering slowing the transmission rate (congestion control).

The model Throughput= RCV Window

RT T does not contem-

plate the probability of packets loss, which is not negligible

in wireless networks, in particular for video transmissions orreal time traffic.

It could be argued that cross-layer feedback is not present,

since the priority of the connections are set by a user. However,

in the architecture the user is modeled as part of a user layer

and its feedback is valuable as context information. While

in this case priorities are set by a person, they could also

be set automatically according to access policies for each

user and/or application. The user layer and the interaction

with the transport layer simplifies the complexity of proper

synchronization and monitoring of the network protocol data

structures.

B. ImplementationAn implementation of this use case is reported to exist

for Linux 2.4.x, however it was not available and was not

used in this work. Furthermore, there are many differences

from GNU/Linux Kernels 2.4.x to 2.6.30 which was the latest

Kernel available at the time of the implementation.

The system was implemented in two parts. On the one hand,

there is a program running in user space (a command line

tool) to set the priorities for the connections. On the other

hand, there is a Kernel module (implemented as a device

driver), which can directly access and modify the Kernel

data structure. It allows real time, user driven recalculation

of the window size and modification the rcv ssthresh and

window clamp parameters for the connections. Note that per

flow optimization did not allowed the use of /proc/net without

modifying the Kernel, and such modifications would affect the

overall performance of the system.

The prototype was implemented on archlinux over Vir-tualBox, with GNU/Linux Kernel 2.6.30, and was compiled

with GCC 4.4.5. Cscope was used to analyze the Kernel

code. The implementation is generic enough so that it can be

reused and expanded with other optimizations, and can easily

be ported to embedded systems.

In the network protocol stack of the GNU/Linux Kernel

there is a hash table accessible through the inet lookup

function. inet lookup receives local and remote IP and port

and returns a pointer to a sock, which is used to access

the aforementioned parameters. This data structure and the

functions in Kernel 2.4 (the Kernel version for which the

use case was originally implemented) differs from the ones

in GNU/Linux Kernel 2.6 (the Kernel version for which wedeveloped our prototype). In Figure 1 is shown how the

inet lookup is used. While future releases of the operating

system might result in modifications to the tunning layer, the

optimization subsystem and the optimization protocol itself

will remain unchanged. This is a strong point of the ECLAIR

architecture.

static int set_receiver_window(u32 size,

struct rwc_info_struct *conn_id)

struct sock *sk;

struct net *red;

struct tcp_sock *tp;

int tama;sk = inet_lookup (red, &tcp_hashinfo,

conn_id->ip_local,

conn_id->puerto_local,

conn_id->ip_remoto,

conn_id->puerto_remoto,

tama);

if (sk!=0)

tp=tcp_sk(sk);

lock_sock(sk);

tp->rcv_ssthresh=size;

tp->window_clamp=size;

release_sock(sk);

return(0);

else

return(1);

Fig. 1. Setting the new receiver windows

While some experiments were conducted with the prototype,

further experimentation is needed to establish its behavior in

various real world scenarios. Since the use case was shown to

have some flaws, other more realistic cross-layer optimization

protocols should be implemented and tested.

Future work will include porting the system to other

plaftorms such as OpenWRT and Android, and developing a

SNMP interface to explore the possibilities of global cross-

layer optimizations.



106




IV. TESTING

In this section the model of the system specification is

briefly described, an explanation on how it was used to validate

and test the prototype is given, and the results in terms of cost

are summarized.

A. Model of the system specification

The model of the use case was built with RTDS [21]

by PragmaDev [22], following the ECLAIR architecture. It

syntactically conforms the SDL-92 standard. A diagram in

SDL can be seen in Figure 2

After the model was obtained, simulations were done in

order to gain confidence in the model. Further simulations

were conducted for the test purposes in order to generate test

cases.

The system is composed of two blocks, a TL or Tuning

Layer block for interacting with the protocol stack, and a OSS

or Optimizing Subsystem that encompasses the PO or protocoloptimizers. Inside the TL there are two process corresponding

to the UTL or User Tuning Layer, and to the TCPTL or

TCP Tuning Layer. Inside the OSS there is the RCWPO

process, the receiver window protocol optimizer; here resides

the optimization logic.

The UTL receives signals indicating priority change in

connections and notifies the RCWPO. The RCWPO process

receives signals that indicate a priority change has occurred,

end emits signals for the TCPTL indicating that the window

size must be changed and its new value. The TCPTL receives

signals from the RCWPO and emits signals to the Kernel to

change the appropriate data structures.

The nomenclature for the components was taken directlyfrom the ECLAIR architecture papers.

B. Test case generation

The RTDS tool provided an environment for simulations.

From the simulations, MSC [23] corresponding to the test

cases were generated.

The MSC test cases were used as input to the tester and as

part of the oracle to establish verdict of the tests. An example

is shown in Figure 3

The input and outputs of the systems were modeled as

signals as usual in SDL, and mapped to concrete inputs and

outputs such as function invocations.This mapping was used

to convert the MSC to input files to the tester.

C. Testing architecture

Testing architecture consists in the components to test,

components of the tester, interaction points which are the

interfaces of the IUT with the tester, which can be PO (Point

of Observation, not to be confused with Protocol Optimizers

from ECLAIR) or PCOs (Point of Control and Observation).

In the SDL model, the tester ’exists’ at the environment.

The tester has two parts: the Kernel (Kernel facilities are

employed for registering the outputs) and the MTC which runs

in user space, runs the test suites and emits the verdict. The

IUT has two parts also, a Kernel module running the TCPTL

set_receiver_window

set_app_pty

tcp_hash_fn

trap_pty_chg

IUT

Tester

KernelRCWPOUTLMTC TCPTL

Fig. 3. Fragment of MSC test purpose

Kernel

MTC UTL

RCWPO &

TCPTL

Tester IUT

PCO

PO

Fig. 4. Testing Architecture

and the RCWPO, and the UTL in user space. The IUT includes

the Kernel module (comprising the RCWPO and TCPTL) andthe user space application for setting priorities (namely, the

UTL).

set_app_pty FROM MTC, TO UTL

(request the UTL to change the priority

of a connection)

app_pty_ok FROM UTL TO MTC

(returns the result of the priority change)

app_pty_err FROM UTL TO MTC

Fig. 5. Signals exchanged at the PCO

tcp_hash_fn FROM TCP_TL TO Kernel

(request the sock corresponding to a connection)tcp_hash_fn_value FROM Kernel TO TCP_TL

(returns sock for the connection required)

read_rcv_wnd FROM TCP_TL TO Kernel

(request parameters of a sock for an

established connection)

read_rcv_wnd_value FROM Kernel TO TCP_TL

lock_socket FROM TCP_TL TO Kernel

set_wnd_clamp FROM TCP_TL TO Kernel

set_rcv_wnd FROM TCP_TL TO Kernel

release_socket FROM TCP_TL TO Kernel

Fig. 6. Signals exchanged at the PO

There are two interfaces between the tester and the IUT, one

PCO used by the MTC to interact feed the input to the UTL,



107




TCP_TCPTL

[tcp_hash_fn,

set_rcv_wnd,read_cnv_wnd,release_socket]

[get_receiver_window,

[register_pty_chg,

unregister_pty_chg,chg_pty_ok]

pty_chg_unreg_ok]pty_chg_reg_ok,[trap_pty_chg,

RCW_TCPTL

[set_app_pty]RCW_UTL

set_receiver_window_err,get_receiver_window_errreceiver_window_val]

[set_receiver_window_ok,

TL OSS

UTL

USER_UTL

[app_pty_ok,app_pty_err]

read_rcv_wnd_value][tcp_hash_fn_value,

RCWPO

lock_socket,set_wnd_clamp,

set_receiver_window]

TCPTL

Fig. 2. System diagram in SDL

and one PO to capture the output of the Kernel module in

Kernel space when values of rcv ssthresh and window clamp

are set.The signals exchanged at the PCO are listed in Figure 5,

while the signals exchanged at the PO are presented in

Figure 6.

These signals are used at the abstraction level of the model.

For running the test suite, the signals are mapped to concrete

operations, such as can be seen in the following examples:

The signal set app pty is mapped to

./userTL host_local port_local

host_remote port_remote 2 2

userTL is a comand line utility to pass information to the

UTL. The first numeric value identifies an operation (namely,

set the pty) and the second the priority.For tcp hash fn, the actual operation performed is an in-

vocation of inet lookup, a Kernel function. The most relevant

parameters it receives are the local and remote IP and port,

represented in network byte order by unsigned integers of 32

and 16 bits respectively, and a pointer to the ’hash info’ Kernel

data structure

sock sk = inet_lookup(net, &hash_info,

__be32 daddr, __be16 dest, __be32 saddr,

__be16 source, int tama);

D. Test execution

An ad-hoc testing automation tool was built and used as

the Main Test Component. It is a bash shell script that parsesan input file and executes the input. When there are no more

inputs to process, it parses an output file where the system

traces were recorded in order to establish a verdict. At the

time of the test, only the type of the signals and the data

types (not values) were considered for verdict.

Note that the Kernel is part of the tester, for it receives

the output of the system. This presents some challenges for

capturing and logging the output.

Since the receiver window is included in the TCP header, a

simple solution would have been to capture the TCP packets

by means of Wireshark or a similar tool. However, this solution

does not account for the window clamp parameter. And,

formally, the TCP packets are not the output of the modeled

system.

In spite of the black box testing approach, the IUT wascoded in a way that it wrote the outputs in the system log

by means of the printk() function. A more appropriate

solution would have been to intercept system calls and add

a tracing facility before executing the actual code of the

function.

Intercepting system calls would be an incomplete solution,

since the prototype changes the value of variables explicitly,

not by means of a system call but by an assignment statement.

Therefore it might require memory inspection for the addresses

where the data structure are stored.

These approaches have considerable potential but to keep

on schedule were left for future work.

Something lacking in this work was the automatic conver-

sion of MSC into input file for the tester, the fully automatic

generation of test cases and a general framework for test

execution.

For the general framework for test execution, TTCN-3 is

the standard of the industry. TTCN-3[24][25] is the test-

ing language promoted by the European Telecommunications

Standards Institute (ETSI) which was designed for any kind

of testing activity.

There are commercial tools that generate test cases from

models in SDL and MSC which can be converted to ATS in

TTCN-3. These tools can be used to fully automate the test

case generation and execution process. We note that Telel-

ogic [26] and Verilog [27] were the major SDL tool vendors.

Telelogic complemented its TAU tool suite with Autolink for

test case generation. Verilog extended OBJECTGeode with

TestComposer. Verilog was acquired by Telelogic, which in

turn was acquired by IBM [28].

E. Results

A two people team was assembled for the project, with no

prior knowledge of modeling tools nor the modeling language

and only minor knowledge on the problem domain. Thus the

time devoted to learning is included in the cost of the project.

An iterative incremental software development process was

followed. In week 1, the specification of the system was



108




given. In weeks 2 and 3 the modeling language (SDL) for

the formal specification was studied and the model of the

system specification in SDL was produced. In week 3 the test

cases were obtained from the model. In weeks 3 and 4 the

prototype was implemented. In week 5 a test automation tool

was implemented, and the prototype was tested. The project

was evaluated.

The hours/person were approximately 320.

The UserTL module has 80 source lines of code and its

compiled size was 2KB. The RWCPO plus the TCPTL module

has 550 lines approximately and its compiled size was 9KB.

V. CONCLUSION

A cross-layer architecture was selected and studied thor-

oughly. As a result, a fully functional prototype that introduced

cross-layer optimizations in devices with constrained resources

was implemented. The chosen architecture was validated, as

well as the model-based testing methodology, a formal modelwas obtained and used to derive test cases. The work started

with the model, followed with the implementation and finished

with an operational prototype that was tested.

Model-based testing approach, even without the fully au-

tomation of the test case generation proved a cost effective

testing methodology even in a scarce resources situation,

consisting of a two people team and a reduced time frame.

The applied methodology does not require sophisticated

software developing processes, even though it can benefit from

them in larger projects.

The need for an appropriate framework for test execution

became evident. Even though the test automation tool devel-

oped was adequate, it lacked flexibility and portability andcould not be used for a different project without some effort.

The prototype followed the use case specification, was built

according to the ECLAIR architecture and was successfully

tested and validated. Therefore, the methodology, tools and

modeling techniques were appropriate to the problem domain.

To our knowledge the prototype was the first use of the use

case and architecture for recent versions of the GNU/Linux

Kernel. The work took place on a virtualized environment

for practical reasons. Despite of that, is directly applicable to

hardware implementations of corresponding embedded devices

implementing GNU/Linux.

The model itself can be reused to include further optimiza-

tions or required refinements to the current, and to derive more

test cases.

ACKNOWLEDGMENT

The authors would like to thank Eduardo Grampın who

made this project possible. We would also like to thank Patrick

Senac for the inspiration taken from his work.

REFERENCES

[1] (2010) SCAN website. [Online]. Available: https://www.niclabs.cl/scan[2] Manfred Broy and Bengt Jonsson and Joost-Pieter Katoen and Martin

Leucker and Alexander Pretschner (Eds.), Model-Based Testing of Reac-tive Systems, ser. Lecture Notes in Computer Science. Berlin, Germany:Springer, 2005, no. 3472.

[3] Mark Utting and Bruno Legeard, Model-Based Testing: A Tools Ap- proach. San Francisco, USA: Morgan Kaufmann, 2006.

[4] V. T. Raisinghani, A. K. Singh, and S. Iyer, “Improving TCP perfor-mance over mobile wireless environments using cross layer feedback,”in IEEE International Conference on Personal Wireless Communications(ICPWC-2002), Delhi, India, Dec. 2002, pp. 81–85.

[5] V. T. Raisinghani and S. Iyer, “Cross-layer feedback architecture formobile device protocol stacks,” IEEE Commun. Mag., vol. 44, pp. 85–92, Jan. 2006.

[6] Specification and Description Language (SDL), ITU-T RecommendationZ.100.

[7] Information technology - OSI - Basic Reference Model, ITU Recom-mendation X.200.

[8] L. Zhang, P. Senac, E. Lochin, and M. Diaz, “Mobile TFRC: acongestion control for WLANs,” in The IEEE International Symposiumon a World of Wireless, Mobile and Multimedia Networks (WOWMOM

2008), Newport Beach CA, USA, Jun. 2008, pp. 23–26.[9] J. Inouye, J. Binkley, and J. Walpole, “Dynamic network reconfiguration

support for mobile computers,” in Proceedings of the 3rd annual ACM/IEEE international conference on Mobile computing and network-ing, Budapest, Hungary, 1997, pp. 13–22.

[10] P. Sudame and B. R. Badrinath, “On providing support for protocoladaptation in mobile networks,” ACM Mobile Networks and Applica-

tions, vol. 6, pp. 43–55, Jan. 2001.[11] QiWang and M. Abu-Rgheff, “Cross-layer signalling for next-generation

wireless systems,” in Wireless Communications and Networking(WCNC), New Orleans, USA, Mar. 2003, pp. 1084–1089.

[12] R. Winter, J. Schiller, N. Nikaein, and C. Bonnet, “Crosstalk: cross-layerdecision support based on global knowledge,” IEEE Commun. Mag.,vol. 44, pp. 93–99, Jan. 2006.

[13] M. Conti, G. Maselli, G. Turi, and S. Giordano, “Cross-layering inmobile ad hoc network design,” IEEE Computer , vol. 37, pp. 48–51,Feb. 2004.

[14] Christel Baier and Joost-Pieter Katoen, Principles of Model Checking,ser. Lecture Notes in Computer Science. Cambridge, USA: The MITPress, 2008, no. 3472.

[15] J. Tretmans, “Test generation with inputs, outputs and repetitive quies-cence,” Software-Concepts and Tools, vol. 17, pp. 103–120, Mar. 1996.

[16] J. Fernandez, C. Jard, T. Jeeron, and C. Viho, “An experiment inautomatic generation of test suites for protocols with verification tech-

nology,” Science of Computer Programming Special Issue on COST247,Verification and Validation Methods for Formal Descriptions, vol. 29,pp. 123–146, Jul. 1997.

[17] C. Jard and T. Jeron, “TGV: theory, principles and algorithms, Atool for the automatic synthesis of conformance test cases for non-deterministic reactive systems,” International Journal on Software Tools

for Technology Transfer , vol. 7, pp. 297–315, Oct. 2004.[18] J. Tretmans and H. Brinksma, “TorX: Automated model-based testing,”

in First European Conference on Model-Driven Software Engineering,Nuremberg, Germany, 2003, pp. 31–43.

[19] Ana Cavalli and Amardeo Sarma (Eds.), SDL ’97: Time for Testing.Amsterdam, Netherlands: Elsevier, 1997.

[20] Laurent Doldi, Validation of Communications Systems with SDL: The Art of SDL Simulation and Reachability Analysis. Wiltshire, GreatBritain: Wiley, 2003.

[21] (2010) Pragmadev RTDS. [Online]. Available:http://www.pragmadev.com/product/RTDSV4.pdf

[22] (2010) Pragmadev website. [Online]. Available :http://www.pragmadev.com/

[23] Message Sequence Chart (MSC), ITU-T Recommendation Z.120.[24] Methods for Testing and Specification (MTS); The Testing and Test

Control Notation version 3; Part 1: TTCN-3 Core Language, ETSI ETSIStandard 201 873-1 v2.2.1.

[25] Colin Willcock and Thomas Deiss and Stephan Tobies and Stefan Keiland Federico Engler and Stephan Schulz, An Introduction to TTCN-3.Wiltshire, Great Britain: Wiley, 2005.

[26] (2010) Telelogic AB. [Online]. Available:http://en.wikipedia.org/wiki/Telelogic

[27] (2010) Telelogic acquires VERILOG. [Online]. Available:http://www.highbeam.com/doc/1G1-58356443.html

[28] (2010) IBM acquires Telelogic. [Online]. Available: http://www-01.ibm.com/software/rational/welcome/telelogic/



109




Robótica



110






111




Butiá: Plataforma robótica genérica para laenseñanza de la informática

Gonzalo Tejera, Andrés Aguirre, Federico Andrade, Pablo Gindel, Santiago Margni y Jorge Viscagtejera|aaguirre|fandrade|pablod|smargni|[email protected]

Instituto de Computación, Facultad de Ingeniería, Universidad de la República J. Herrera y Reissig 565,Montevideo, Uruguay

Resumen—El aprendizaje de la robótica en los niveles inicialesde la educación es una herramienta poderosa para trasmitir a losprofesores, estudiantes y sus familias conocimientos básicos sobrelas nuevas tecnología y sus aplicaciones. Existen muchos mitossobre las computadoras y los robots, desconocimientos básicos

tanto sobre lo que pueden como lo que no pueden hacer, en ambossentidos, y que generan por un lado miedos infundados y por otroexpectativas desmedidas. La incorporación de los robots y de lainteligencia computacional se está dando de manera progresiva ennuestra sociedad, y es importante entonces contribuir a mejorarel conocimiento sobre estas tecnologías. Este artículo presenta unaplataforma simple y económica que permite a los alumnos de losliceos públicos del Uruguay interiorizarse con la programaciónde robots.

Index Terms—Educación inicial, enseñanza de informática yrobótica.

I. INTRODUCCIÓN

LOS robots pueden ser una herramienta pedagógicapoderosa y flexible. Permite a los estudiantes realizar

elaboraciones mentales de orden superior, reflexionar sobreel por qué de las cosas, experimentar e identificar las reper-cusiones de las decisiones que se toman y comprenderlas.

El proyecto Butiá[1] desarrollado con fondos de la AgenciaNacional de Investigación e Innovación[2] crea una plataformaque permite a alumnos de liceos públicos, en coordinacióncon docentes e inspectores del Consejo de Enseñanza Se-cundaria (CES)[3], interiorizarse con la programación delcomportamiento de robots.

El proyecto provee a los liceos seleccionados por el CESuna plataforma simple y económica que permite a los alumnos

definir el comportamiento de un robot, que proporciona am-biente lúdico e idóneo para que los estudiantes se interioricencon la programación y la robótica.

Es importante señalar que, en cuanto a la robótica, existeactualmente una profunda asimetría entre liceos públicos yprivados, extendiéndose de manera creciente la robótica enla currícula de muchas instituciones privadas. Esta propuestapretende contribuir a disminuir esta brecha acercando estesistema robótico a instituciones públicas de nivel secundarioen las que hasta el momento, este tipo de sistemas no ha sidoampliamente incorporado.

II. LA ROBÓTICA Y LA EDUCACIÓN

Dada la creciente importancia que tiene la tecnología hoyen día y el amplio terreno que viene ganando la robótica

y la mecatrónica en la vida de las personas en el mundodesarrollado, resulta conveniente comenzar a incorporar estosconceptos en las primeras etapas de la formación educativade nuestros jóvenes. En este sentido, es interesante ofrecer a

alumnos de educación secundaria la posibilidad de acercarse anuevas tecnologías a través del manejo de robots y lenguajesde programación simples que les permitan controlarlos. Seespera con esta experiencia que los alumnos dispongan deun elemento más para definir su vocación hacia orientacionesCientífico – Tecnológicas.

Programar los comportamientos de un robot móvil generamucho interés para los adolescentes. Además, les permitealcanzar resultados visuales inmediatos de sus programas,estimula su creatividad, así como al mismo tiempo se lesenseñan conceptos básicos de programación. Se entiende queel trabajo con robots, desde una perspectiva de la robóticapedagógica potencia el desarrollo del aprendizaje inductivo y

por descubrimiento guiado; posibilita el diseño de situacionesdidácticas que permiten a los estudiantes construir su propioconocimiento. [4]

Esta propuesta busca generar entornos de aprendizaje cen-trados en la actividad de los propios estudiantes. Uno de losfactores a destacar es la posibilidad de integración de lasdiferentes áreas, como matemáticas, ciencias experimentales,comunicación, filosofía, entre otras, que amplían la propuestade trabajo a nivel de los centros educativos, posibilitandoque se desarrollen proyectos de fin de año integrando variasasignaturas al trabajo con los robots, como se propone en elplan de estudios vigente de bachillerato.

Los alumnos de estos liceos podrán presentar los trabajos realizados sobre el sistema robótico en el marco delevento de robótica organizado por la Facultad de Ingenieríade la Universidad de la República[5], simultáneamente contrabajos realizados por alumnos y docentes universitarios,generando un rico ambiente de intercambio de experienciasy conocimientos.

El proyecto Butiá se apoya, en todo sentido, sobre las com-putadoras OLPC (One Laptop per Child)[6] proporcionadasal sistema de educación público del Uruguay a través delPlan Ceibal[7], llevado adelante por el gobierno nacional delUruguay a partir del año 2007. En la Figura 1 podemosapreciar una de las computadoras del mencionado plan sobre

la plataforma Butiá.



112




Figura 1. La computadora OLPC sobre la plataforma Butiá.

III. ARQUITECTURA DEL LA PLATAFORMA BUTIÁ

Al momento de diseñar la arquitectura del sistema se tuvocomo principal objetivo la portabilidad del mismo, ponderandoplataformas con pocas prestaciones de hardware. Otro puntoen el que se tuvo especial cuidado es en brindar una interfazclara y simple que permita integrar la arquitectura del robotcon diferentes lenguajes de programación.

Una vista simplificada de los principales componentes dela solución puede visualizarse en la Figura 2. La arqui-tectura Butiá consta de tres capas. Tomando en cuenta unenfoque botton-up, podemos identificar el nivel más cercanoal hardware, la primer capa (capa 1), encargada de interactuar

con los sensores y actuadores. En esta capa se especificanlos servicios que el firmware brinda, además estos serviciosson agrupados de forma lógica en componentes de softwarellamados módulos de usuario, los cuales son una abstraccióndel sensor o actuador que se desea controlar en el robot. Estoscomponentes de software residen en el firmware de la placade entrada/salida (E/S). La separación entre esta capa y lasiguiente está bien definida por un stack de protocolos, lo cualpermite obtener un gran nivel de independencia del hardwaresubyacente. El prototipo construido es funcional con la placade E/S Arduino y actualmente se presenta un gran nivel deavance con la placa USB4all [8]; además se espera portar aotro tipo de plataformas como Handy Cricket, PicoBoard o

GoGoBoard. Existe una segunda capa (DSI - descubrimiento einvocación de servicios) que se encarga de descubrir de formadinámica los módulos presentes en la placa de E/S junto conlos servicios o funcionalidades que estos brindan y una vezdescubiertos son expuestos para poder ser consumidos por unaaplicación. Para permitir un uso más versátil al momento deintegrarse con diferentes lenguajes de programación se realizóuna tercer capa (capa 3), que ofrece estos servicios a un nivelmayor de abstracción lo que posibilita que sean invocadosen la red. Esta última capa permite interactuar con el robotdesde cualquier lenguaje de programación que tenga soportede sockets.

La arquitectura construida es genérica, permitiendo una

Figura 2. Componentes de la arquitectura Butiá.

fácil extensión de sus funcionalidades independientementedel hardware de bajo nivel subyacente, así como portable adiferentes plataformas de bajos recursos de hardware.

A diferencia de otras plataformas donde la lógica de controlse desarrolla completamente en una placa de E/S microcontro-lada, la arquitectura Butiá fomenta un diseño híbrido, dondesolo se implementa en la placa de E/S la interacción directacon el hardware encapsulándolo en los módulos de usuario,luego la lógica de control es desarrollada en un lenguaje de alto

nivel en base a los servicios que estos módulos exponen. Estopermite utilizar herramientas de mayor nivel de abstracción,generando código con un alto nivel de mantenibilidad yentendimiento, facilitando la comprensión por alumnos que seinician en las ciencias de la computación. En la Figura 3 unniño de 9 años trabaja en el comportamiento del robot Butiá.

Figura 3. Niño trabajando con la plataforma durante el sumo.uy.

La distribución del sistema operativo instalado en las com-putadoras OLPC incluye diversos entornos y lenguajes deprogramación. Entre ellos se encuentra el entorno de progra-mación gráfico Tortugarte[9] basado en el lenguaje LOGO[10].



113




En el marco del proyecto se extendió el lenguaje agregandouna paleta para interactuar con la plataforma Butiá. En la partesuperior de la Figura 4 se muestra la paleta Butiá integrada alentorno Tortugarte que permite controlar los motores y accedera la lectura de los sensores. En la parte inferior de la misma sepresenta un comportamiento para evitar obstáculos utilizandoel sensor Botón.

Además de esta extensión se desarrollaron APIs para loslenguajes de programación Python, C y Lua.

Figura 4. Evitando obstáculos con Tortugarte.

IV. IMPLEMENTACIÓN DEL PROTOTIPO

Con el objetivo de cumplir con los requerimientos de porta-bilidad, los componentes de software que tienen interaccióndirecta con el hardware fueron implementados utilizando ellenguaje de programación ANSI C, esto permite lograr tenermayor control sobre el hardware y minimizar las latencias

vinculadas con los tiempos de comunicación. La lógica demayor nivel de abstracción y más propensa a cambios, serealizó utilizando el lenguaje interpretado Lua[11]. Lua es unlenguaje de gran nivel de abstracción, su máquina virtual esmuy pequeña y esta desarrollada en ANSI C lo que permiteportarlo fácilmente a diferentes arquitecturas, particularmenteen aquellas con bajas prestaciones de hardware. Dado que esun lenguaje interpretado el software desarrollado utilizandosu maquina virtual es sumamente versátil, evitando generarbinarios para las distintas arquitecturas como es usual enotros lenguajes, lo cual es un gran beneficio al momento deldesarrollo, simplificando el testing y puesta en producciónsobre la plataforma objetivo. También existe una versión de

Lua, llamada eLua pensada para sistemas con aún menosrecursos como microcontroladores.

Se espera que Butiá soporte al menos las siguientes platafor-mas:

1. OLPC. Esta es la plataforma del Plan Ceibal. El hard-ware contiene un procesador AMD Geode, con arquitec-tura x86. Los primeros modelos poseían 256MB RAMactualmente ya disponen de 512MB. El disco duro es deestado sólido de 1GB. El software consiste en un kernel Linux con Sugar como interfaz de usuario.

2. Intel Classmate. Es la plataforma para enseñanza de In-tel, y es un nombre genérico para una línea de productosde distintos fabricantes. El hardware es típico para unnetbook de bajo costo: procesador Intel Atom (x86), apartir de 512MB de RAM, disco duro magnético.

3. Router Inalámbrico. Plataforma de costo y poder decómputo mínimo prevista. Un ejemplo típico es unrouter Asus 520GU . Consiste en un sistema embebidocon un procesador Broadcomm, con 16MB de RAM y8MB de almacenamiento Flash. En el marco del proyec-to se realizaron pruebas con OpenWRT , una distribuciónde Linux para sistemas embebidos.

4. Smartphones. Hay una gran cantidad de fabricantes yde plataformas de software. Usualmente contienen unprocesador ARM , más de 64MB de RAM y almace-namiento flash. El sistema operativo puede estar basadoen Linux, Windows CE , u otros sistemas dedicados.

5. Sistemas basados en Single Board Computers (SBC), seespera que la arquitectura funcione en la placa Beagle-

Board y Foxboard , para esta última tenemos actualmenteun prototipo funcional.

Se plantea la necesidad de disponer de un componente que

pueda ser desplegado con mínimas modificaciones en todaslas plataformas de interés, y que implemente las siguientesfuncionalidades:

Acceda a la placa de E/S implementando el protocoloUSB4all sobre el tipo de conexión asociado (USB oSerial).Ofrezca una API que permita acceder las funcionalidadesprovistas por Butiá desde las aplicaciones de usuario.

Este componente se implementó en Lua como dos compo-nentes: una biblioteca que implementa la comunicación conla placa (bobot), y una aplicación que usa esta biblioteca yexporta su funcionalidad mediante un socket (bobot-server).

Esta arquitectura es la solución de referencia y de máximaportabilidad.El bobot accede la placa microcontroladora mediante USB

o Serial. Para la primer opción, se enlaza con libusb, unabiblioteca portable de espacio de usuario para manipulardispositivos USB. Este enlace se realiza mediante un bindingdesarrollado, llamado lualibusb[12]. Para acceder medianteserial se utiliza una pequeña librería en C que implementauna comunicación orientada a mensajes, llamada serialcomm.Bobot es fácilmente extensible para agregar soporte a nuevosmódulos de la placa controladora (USB4all/Arduino). Esto selogra mediante drivers cargados dinámicamente de acuerdo alos módulos declarados por la placa controladora.

En las plataformas robóticas comercialmente más difundi-das, el usuario debe llevar nota de qué dispositivo conectó encada puerto de comunicación y declararlo en algún punto dela estructura del software. Esto difiere radicalmente respectoa la capacidad de auto-configuración o plug&play (PnP)

de la plataforma Butiá. La idea es exponer al usuario lascapacidades sensoriales y de actuación del robot Butiá, deuna forma ordenada que facilite su aprovechamiento evitandoetapas de configuración. Siguiendo estos principios se diseñoun conector PnP flexible, en el cual se puedan conectar tantosensores como actuadores, analógicos como digitales, PWM eincluso I2C. Dicho conector dispone entre otros de pines deidentificación los cuales se cablean a vcc o gnd directamente



114




Figura 5. Interacción entre el sistema Butiá y la placa de E/S.

o a través de resistencias, logrando diferenciar el tipo dedispositivo conectado.

Ventajas del uso de los conectores PnP Butiá:

Constituye una potente herramienta de diagnóstico.Simplifica el acceso al hardware.Permite que el firmware seleccione automáticamente elmódulo adecuado para manejar cada tipo de dispositivo.

Se diseño una placa adaptadora a la controladora de E/S quedispone de ocho conectores PnP Butiá, y en forma separadael conector para el bus Dynamixel (que también cuenta conauto-detección) y un conector de potencia para dos motoresde continua o un motor de paso. Un ejemplo concreto de

implementación es el que podemos ver en el Cuadro I

Cuadro IESPECIFICACIONES DEL ROBOT BUTIÁ.

Elemento Instancia

Motores Dynamixel AX12Control de bajo nivel Arduino MegaControl de alto nivel Computadora OLPC

Chasis Acrílico 5mmAmortiguación Placa acero alto carbono 0.5mm

Sensores Kit DFRobot para Arduino y sensores Sharp

Utilizando la información de PnP es posible desde la inter-faz de Tortugarte colorear los elementos de la plataforma Butiáde diferentes colores dependiendo si se encuentra o no conec-tados al robot. Esta característica permite que los usuariospuedan detectar rápidamente errores de hardware, reduciendolas frustraciones generadas por este tipo de situaciones.

V. TRABAJO A FUTURO

Actualmente se están logrando grandes avances con laintegración de la cámara web de la XO como un sensor más, sehan realizado pruebas de factibilidad que permiten identificarcolores y retornar sus coordenadas. También se está trabajandoen agregar el micrófono de la XO al universo de sensores. Eneste sentido se están realizando pruebas para poder procesarel lenguaje natural y permitir programar el robot medianteel uso de la voz. Otro aspecto interesante en el cual se está

investigando es en permitir compartir un robot entre variasmáquinas brindando los mecanismos necesarios para arbitrarel acceso al mismo. Por último se están consiguiendo grandesavances en portar la arquitectura a plataformas embebidas tipoARM como son FoxBoard y BeagleBoard .

VI. CONCLUSIONES

Se diseñó una arquitectura que brinda un enfoque genéricoe independiente del hardware de control. Esta arquitectura per-mite desarrollar el comportamiento del robot Butiá mediantelenguajes de programación de fácil acceso y comprensión paraestudiantes liceales como es Tortugarte. De todas formas alestar modularizado y bien definido el alcance de cada capa,así como el API para acceder a cada una de ellas, existendiferentes niveles en los cuales el alumno puede desarrollar elcomportamiento, dependiendo de su nivel de conocimientos,llevando esto a la programación de nuevos módulos de usuario

en el firmware, así como programación en otros lenguajescomo Lua, Python, Java. Actualmente se ha logrado un nivelsuficiente de madurez en el sistema, se dispone de 30 robotsen producción distribuidos en todo el país.

Desde el punto de vista social, a través de este proyecto selogra acortar la brecha para los que por razones económicas nopueden alcanzar dichas tecnologías. En este sentido se lograun proyecto con un fin democratizador.

REFERENCIAS

[1] Butiá, “Proyecto butiá,” Agosto 2010,http://www.fing.edu.uy/inco/proyectos/butia/.

[2] ANII, “Agencia nacional de investigación e innovación,” Febrero 2011,

http://www.anii.org.uy/web/.[3] CES, “Centro de educación secundaria,” Febrero 2010,http://www.ces.edu.uy/ces/.

[4] S. Colorado, M. María, and A. Gauthier, “Ambientes de aprendizaje conrobótica pedagógica,” Ingeniería Eléctrica y Electrónica - Universidadde los Andes, Memo de Investigación IEL 2003-001, 2005.

[5] sumo.uy, “Campeonato de sumo robótico,” Agosto 2010,http://www.fing.edu.uy/inco/eventos/sumo.uy/.

[6] OLPC, “One laptop per child,” Agosto 2010, http://laptop.org/.[7] Ceibal, “Portal del plan ceibal,” Agosto 2010, http://www.ceibal.edu.uy/.[8] A. Aguirre, P. Fernández, and C. Grossy, “Interfaz usb genérica para

comunicación con dispositivos electrónicos,” Dciembre 2007.[9] S. Labs, “Turtleart activity,” Agosto 2010,

http://wiki.sugarlabs.org/go/Activities/TurtleArt.[10] (2011, Febrero) Web site of logo foundation. [Online]. Available:

http://el.media.mit.edu/logo-foundation/index.html[11] L. H. d. F. Roberto Ierusalimschy, Waldemar Celes, “The programming

language lua,” Diciembre 1993, http://www.lua.org/.[12] J. Visca and A. Aguirre, “Libusb binding for lua,” Agosto 2010,http://luaforge.net/projects/lualibusb.



115




Librerıas embebidas para microcontroladores

LPC2000 de aplicacion en robotica

Gonzalo F. Perez Paina, David A. Gaydou, Nestor L. Palomeque, Lucas A. Martini

Centro de Investigacion en Informatica para la Ingenierıa, C.I.I.I.

Universidad Tecnologica Nacional, Facultad Regional Cordoba, UTN-FRC


Abstract—En el presente trabajo se describe el desarrollo delibrerıas embebidas para microcontroladores NXP con nucleoARM7. Las mismas se dividen en Modulos de perif ericos yModulos de software que implementan algoritmos especıficos. LosModulos perif ericos permiten la abstraccion del modelo particu-lar de microcontrolador para acceder mediante funciones de alto

nivel a los diferentes perifericos como GPIO, Timers, UART, etc.Los Modulos de software implementan algoritmos de utilidadpara aplicaciones del area de robotica, sensorıstica y control,como por ejemplo, la comunicacion serial punto a punto mediantepaquetes, medicion de se ˜ nales de encoders opticos incrementales,controladores PID, etc. Ademas, se presenta un caso de aplicacionen el que fueron utilizadas las librerıas, mas precisamente en unrobot movil de traccion diferencial de construccion propia. Suutilizacion muestra ser lo suficientemente flexibles para agilizarel dise ˜ no, desarrollo y prueba de aplicaciones embebidas.

I. INTRODUCTION

Para el desarrollo de software de sistemas embebidos es

de principal importancia contar con herramientas flexibles,

que brinden la posibilidad de realizar modificaciones a laaplicacion con un mınimo esfuerzo. Esto permite elegir la

mejor implementacion en sistemas donde se requiere maxima

confiabilidad y desempeno. Una de las necesidades fundamen-

tales para el desarrollo de software embebido es poder contar

con librerıas tanto para los perifericos particulares de la familia

de microcontroladores utilizada, ası como de algoritmos de uso

comun en algun area en particular.

En el laboratorio de electronica del Centro de Investi-

gacion en Informatica para la Ingenierıa (C.I.I.I.), se lle-

van a cabo desarrollos de sistemas embebidos en el marco

de diferentes proyectos de investigacion, principalmente en

el area de robotica, sensorıstica y control. Una evolucion

natural en el desarrollo de dichos sistemas fue comenzar autilizar microcontroladores de 32 bits, que permitan desarrollar

programas capaces de realizar cierta cantidad de calculos

en tiempos razonables para dichas aplicaciones. Una de las

primeras incursiones en este tipo microcontroladores se realiza

utilizando arquitectura de nucleo ARM7, mas precisamente los

de la familia LPC21XX [1] de la marca NXP.

En el presente trabajo se describe el desarrollo de librerıas

para sistemas embebidos, las cuales han sido pensadas prin-

cipalmente para cubrir los requerimientos del laboratorio del

C.I.I.I., en areas de aplicacion particular. Estas librerıas, como

se comentara mas adelante, se dividen en una parte para el

manejo de hardware y otra de algoritmos particulares de gran

utilidad en los proyectos del Centro. Como principal objetivo

en su desarrollo se tiene la abstraccion del hardware y se ha

prestado principal atencion en el modo que se articulan los

diferentes Modulos (de hardware y algoritmos) para que resul-

ten flexibles, facil de mantener y modificar, lo que promuevan

la reutilizacion de software.La seccion II presenta una descripcion general de los

diferentes Modulos de software de las librerıas ciiiemblibs y

su relacion. La seccion III presenta los modulos perif ericos

o de manejo de hardware en detalle, y la IV los modulos en

desarrollo. La seccion V describe los modulos especiales o de

algoritmos, junto con su relacion con los Modulos perif ericos.

En la seccion VI se muestra un caso de aplicacion en la

utilizacion de las librerıas. Y por ultimo en la seccion VII

se presentan las conclusiones del trabajo.

II. DESCRIPCION GENERAL

Las librerıas embebidas denominadas ciiiemblibs por su

desarrollo dentro del Centro de Investigacion en Informaticapara la Ingenierıa, se encuentran divididas en dos grupos

principales: por un lado los modulos para perif ericos, cuyo

Fig. 1. Organizacion y relacion de los diferentes modulos de las librerıas



116




objetivo es controlar los dispositivos particulares de los mi-

crocontroladores LPC21XX y por otro lado los modulos

especiales, que cumplen funcionalidades particulares e inde-

pendiente del modelo de microcontrolador utilizado, pudiendo

ser compilados para otras arquitecturas. Una representacion

esquematica de esta division se puede apreciar en la Fig. 1.

Dentro de los Modulos perifericos podemos nombrar:

• Modulo para entrada-salida o simplemente GPIO, es el

encargado de comandar los puertos de salidas y entradas

digitales.

• Modulo para temporizadores o TIMER, maneja los tem-

porizadores y la funcionalidad capture.

• Modulo para comunicacion serial o UART, trabaja con el

puerto serial del microcontrolador.

• Modulo para el manejo de interrupciones o IRQ, se

encarga de comandar las interrupciones vectorizadas.

• Modulo para el manejo del modulador de ancho de pulso

o PWM, manipula el modulador de ancho de pulso delmicrocontrolador.

• Modulo para la conversion analogico-digital o ADC,

trabaja con el conversor del microcontrolador.

• Modulo In-Application Programming o IAP, se encarga

de la escritura de datos en memoria no volatil.

En cuanto a los Modulos especiales o de algoritmos ten-

emos:

• Modulo de comunicacion mediante datos empaquetados

o COMMUNICATION, es un protocolo de comunicacion

entre dos dispositivos.

• Modulo para el manejo de encoders o ENCODER, para

la decodificacion de encoders opticos incrementales.• Modulo Controladores, realiza el calculo de un contro-

lador proporcional-integral-derivativo.

Las librerıas fueron desarrolladas en lenguaje ANSI-C sep-

aradas en diferentes modulos (archivos .h y .c) para cada uno

de los Modulos perif ericos o especiales indicados anterior-

mente. Cada una de las funciones de los diferentes modulos

comienza con el nombre del Modulo para poder identificar

a que modulo pertenece la funcion, por ej. las funciones de

inicializacion de algunos de los Modulos son: para el Modulo

GPIO gpio_init(), para el Modulo PWM pwm_init(),

para el Modulo de comunicacion com_init(). Ademas, las

librerıas incluyen ejemplos de utilizacion de cada uno de los

Modulos que soporta.

III. MODULOS PARA PERIFERICOS

Estos modulos se desarrollaron para un manejo sim-

ple y transparente de los perif ericos del microcontrolador

LPC21XX. En las subsecciones siguientes se describen los

modulos perif ericos aplicados especıficamente al microcon-

trolador modelo LPC2114/24.

A. M odulo para entrada-salida

El microcontrolador NXP LPC2114/24 posee dos puertos

de proposito general: Port0 y Port1, de los cuales el primero

dispone de 30 pines y el segundo de 16, siendo un total 46

pines de entrada/salida, todos estos pines se encuentran multi-

plexados con diferentes funciones de otros modulos perif ericos

del microcontrolador.

El Modulo software para entrada y salida contiene fun-

ciones que inicializan los pines del microcontrolador comoentrada/salida de proposito general (o GPIO como sus siglas

en ingles), se configura si el pin se va a utilizar como una

entrada o como una salida digital; en el caso de un pin de

entrada digital el Modulo permite leer su estado, y en el caso

de un pin de salida el Modulo permite establecer un estado

logico (alto o bajo) a la salida del pin.

Algunas de las funciones del modulo son gpio_init(),

gpio_set() y gpio_toggle().

B. M odulo para temporizadores

El microcontrolador NXP LPC2114/24 posee dos tempo-

rizadores o Timers. Estos temporizadores son independientes

e identicos, ademas cada Timer dispone de hasta 4 canalesde captura que permiten almacenar, en un registro dedicado

a esto, el valor del Timer Counter cuando se produce una

transicion en la senal de entrada de estos canales. Tanto el

Prescaler, como el Timer Counter y los Registros de Captura

son de 32 bits.

Este Modulo software permite configurar y controlar ambos

Timers del microcontrolador. La codificacion de la misma se

centra principalmente en el modo de cuenta de intervalos de

tiempo entre eventos. En esta librerıa tambien se encuentra

codificado el modo particular Capture.

Algunas de las funciones del modulo son timer_init(),

timer_get(), timer_enable_interrupt(),

timer_disable_interrupt().

C. M odulo para comunicaci ´ on serial

El microcontrolador NXP LPC2114/24 posee dos UART

(Universal Asynchronous Receiver-Transmitter). La UART0

permite una configuracion interna unica en “Null Modem”,

por ende no realiza control por hardware de la trans-

mision/recepcion de sus datos. En cambio, la UART1 sı

dispone de un control de flujo de datos por hardware, del cual

se puede hacer uso.

El Modulo software correspondiente permite configurar la

UART0 y UART1 del microcontrolador, no obstante, en esta

instancia solo esta desarrollado el empleo en configuracion“Null Modem” para ambas UARTs.

Este Modulo posee un conjuntos de funciones que permiten

configurar la frecuencia (Baud Rate) de la comunicacion, la

cantidad de bytes a transmitir, el tipo de paridad, la cantidad

de bits de stop y el tamano de memorias intermedias (FIFO).

Tambien implementa rutinas que permiten la trasmision y la

recepcion de datos, ademas de controlar las distintas fuentes

de interrupciones, haciendo uso del Modulo de software IRQ

para el manejo de interrupciones para la configuracion de

las mismas. Posee una implementacion por callbacks para

la atencion de las posibles fuentes de interrupciones, lo que

facilita la tarea del programador.



117




Fig. 2. Modos de funcionamiento del PWM

Algunas de las funciones del modulo son uart_init(),

uart_set_baudrate(), uart_send_byte(),

uart_receive_byte().

D. M´ odulo para el manejo de interrupciones

El Controlador Vectorizado de Interrupciones (o VIC por

sus siglas en ingles) del microcontrolador LPC2114/24, posee

treinta y dos entradas y solicitud de interrupcion programable

en tres categorıas nombradas a continuacion en orden deprioridad: FIQ (Fast Interrupt reQuest), IRQ vectorizada, y

IRQ no vectorizada.

La librerıa desarrollada configura las interrupciones IRQ

vectorizadas. Actualmente no opera sobre las interrupciones

FIQ e interrupciones IRQ no vectorizadas. Las interrupciones

vectorizadas IRQ son basicamente un “vector” de 16 ele-

mentos, donde cada elemento constituye una “funcion inter-

rupcion” que atiende el servicio de cualquiera de las posibles

fuentes de interrupcion. La mayor prioridad de este vector

comienza con el primer elemento.

Algunas de las funciones del modulo son

irq_vect_init(), irq_vect_enable(),

irq_vect_disable().

E. M odulo para el manejo del modulador de ancho de pulsos

El Modulo perif erico PWM del microcontrolador

LPC2114/24 posee dos modos de funcionamiento: simple

flanco, en el cual solo se puede controlar el flanco de bajada

y doble flanco, que permite controlar tanto el flanco de

subida como el de bajada, como se indica en la la Fig. 2.

Las funcionalidades del microcontrolador permiten hasta seis

salidas de simple flanco, tres salidas de doble flanco, o una

combinacion de ambos tipos.

Este Modulo actualmente se centra en el modo de fun-

cionamiento de simple flanco de los seis PWM disponibles en

el microcontrolador. Las funciones de este Modulo permiten

configurar la frecuencia de la senal de PWM, y en cualquier

instante poder modificar el “ciclo de trabajo” o conocer el

valor del “ciclo de trabajo” actual.

Algunas de las funciones del modulo son pwm_set_on(),

pwm_set_off(), pwm_set_value().

IV. MODULOS PARA PERIFERICOS EN DESARROLLO

Estos Modulos se encuentran en etapa de desarrollo por lo

que se presentan aquı, a modo explicativo, la funcionalidad

que tendran una vez finalizados.

A. M´ odulo In-Application Programming (IAP)

Esta librerıa se desarrolla con la intencion de poder al-

macenar datos sobre la memoria flash del microcontrolador

LPC2114/24. En la actualidad se encuentran completamente

codificadas y se encuentra en etapa de evaluacion para seragregadas a la librerıa.

B. M odulo para la conversi´ on anal´ ogico-digital

Este Modulo permite realizar la conversion de senales

analogica a digital para aplicaciones de adquisicion de datos.

Actualmente las funciones en desarrollo permiten obtener

valores del conversor a requerimiento de la aplicacion. Se

planea agregar las funciones necesarias para los diferentes

modos de funcionamiento del Modulo periferico ADC.

V. MODULOS ESPECIALES

Los Modulos especiales implementan algoritmos de utilidad

en diversas aplicaciones de sistemas embebidos. Algunos de

estos Modulos hacen uso de los Modulos perif ericos pero son

independientes de los mismos.

A. M odulo de comunicaci´ on mediante datos empaquetados

Permite la transferencia de datos entre dos dispositivos

cuyas velocidades de procesamiento son muy diferentes,

como ser una aplicacion en una PC y la aplicacion embebida.

La implementacion provee rutinas para lectura y escritura

de datos en forma de paquetes, por parte de la aplicacion

principal. Tambien hace uso de callbacks correspondientes al

dispositivo f ısico o logico utilizado en el otro extremo de la

conexion de la librerıa. A los datos enviados a la interfaz de

salida, el Modulo agrega caracteres de inicio y tamano del

paquete como parte del protocolo. En la Fig. 3 se puede vercomo se conforma un paquete.

La operacion de la transmision y recepcion emplea la

mecanica de productor-consumidor, actuando sobre un buffer

circular intermedio implementado en el Modulo y coordinado

a traves de una variable protegida incrementada por el produc-

tor y decrementada por el consumidor. En terminos generales

la rutina del productor carga los caracteres secuencialmente en

el buffer interno, arma los paquetes, chequea los desbordes,

controla la circularidad e incrementa la cuenta de paquetes

(variable compartida). La rutina del consumidor extrae los

caracteres secuencialmente, liberando el espacio en el buffer,

controla la circularidad y decrementa la cuenta de paquetes

(variable compartida).

Fig. 3. Paquete de datos de la librerıa COMMUNICATION

Algunas de las funciones del modulo son com_init(),

com_send_packet(), com_receive_packet().



118




Fig. 4. Robot Movil de Arquitectura Abierta, RoMAA

B. M odulo para el manejo de encoders

Un encoder optico incremental es un sensor que permite

detectar el movimiento de rotacion de un eje a traves de sus

salidas correspondientes a dos senales llamadas Fase A y Fase

B, las cuales son trenes de pulsos desfasadas 90o.

El objetivo de esta librerıa consiste en crear un modulo

funcional para la lectura de este tipo de sensores. Este Modulo

permite decodificar las senales del encoder [2] y ası poder

determinar el sentido de avance y la cantidad absoluta de

pulsos del eje del cual se quiere controlar la rotacion.

Algunas de las funciones del modulo son

encoder_init(), encoder_update().

C. M´ odulo software CONTROLADORES

Actualmente este Modulo implementa un controlador PID

[3] (Proporcional Integrativo Derivativo) que permite ajustar

los valores de desempeno de un sistema de lazo cerrado a las

necesidades de la aplicacion. Este Modulo realiza los calculos

en base a la implementacion en tiempo discreto de la ec. (1):

Rn = Rn−1 + K P (en − en−1)

+ K I

en + en−1

2

(1)

+ K D(en − 2en−1 + en−2)

donde K P , K I y K D son las constantes proporcional, integral

y derivativa respectivamente, Rn es la salida actual, Rn−1 es

la salida anterior y en es el error actual.

Algunas de las funciones del modulo son pid_init(),

pid_update().

VI . EJEMPLO DE APLICACION

La totalidad de los Modulos explicados anteriormente estan

siendo utilizados en diferentes proyectos dentro del Centro

de Investigacion en Informatica para la Ingenierıa, pero cabe

mencionar uno de los mas importantes, el Robot Movil de

Fig. 5. Controlador embebido del robot RoMAA con µC ARM LPC2124

Arquitectura Abierta o RoMAA [4], el cual puede verse en la

Fig. 4. El sistema de control embebido, mostrado en la Fig.

5, del robot movil RoMAA se basa en un microcontrolador

LPC2124, para cuyo desarrollo se utilizaron en su totalidad

las librerıas del presente trabajo.

El sistema de traccion se basa en motores de corriente

continua alimentados mediantes drivers de potencia de llave H,

comandados desde senales de PWM utilizado con el Modulo

correspondiente. Para el control de velocidad de dichos mo-

tores se utiliza un lazo de control a partir de mediciones de

encoders opticos incrementales acoplados mecanicamente a

los motores; la medicion de velocidad se realiza mediante la

funcion de Capture del Timer del microcontrolador, con el

modulo adecuado, ademas de la librerıa de encoders, para

tener un registro de los pulsos y sentido de giro de los

motores. Esta informacion se integra luego en lo que se

conoce como odometrıa [5]. El sistema de control incluye

tambien un lazo externo en configuracion cross-coupling para

obtener trayectorias en lınea recta o arcos, y poder comandar al

vehıculo con velocidad lineal y angular. Los comandos hacia el

controlador e informacion del mismo se obtienen desde la PC

a bordo del robot, mediante la comunicacion serie utilizandola librerıa UART y COMMUNICATION, la cual se encarga

del protocolo de comunicacion.

Ademas, se hace uso del resto de las librerıas, como GPIO

para el control de los puertos utilizados, TIMER para gen-

eracion de bases de tiempo e implementacion de la funcional-

idad capture e IRQ para la manipulacion de interrupciones.

La necesidad de poder medir la carga de la baterıa de la que

se abastece el robot RoMAA y poder ası tener un control

del posible estado inoperante del mismo, surge el desarrollo

actual, de la librerıa ADC. De manera similar surge la librerıa

IAP, para poder almacenar datos, como las constantes del PID,

en memoria no volatil.



119




VII. CONCLUSIONES

Las librerıas embebidas ciiiemblibs estan siendo uti-

lizadas actualmente en diferentes proyectos del laboratorio de

electronica del C.I.I.I., relacionados a robotica, sensorıstica y

control. La utilizacion de las mismas muestra que cumplencon el objetivo planteado al inicio del proyecto.

Por un lado la utilizacion de los Modulos perif ericos facilita

la implementacion de nuevas aplicaciones mediante la ab-

straccion del hardware, lo que reduce la necesidad de consultar

constantemente el manual del microcontrolador, para el caso

de los modulos perif ericos. Y por otro lado, los Modulos de

software o algoritmos permiten flexibilidad en las etapas de

pruebas al inicio de los proyectos, como por ejemplo la librerıa

de comunicacion que es de gran utilidad en la depuracion

de aplicaciones. Ademas, las librerıas de Modulo software

pueden ser utilizadas en diferentes arquitecturas de microcon-

troladores, debido a que son independientes del hardware.

La utilizacion de las librerıas ciiiemblibs permiten granflexibilidad en las etapas iniciales de diseno y evaluacion

necesarias en el desarrollo de nuevos proyectos.

REFERENCES

[1] NXP Semiconductors. UM10114. LPC21xx and 22xx User Manual, April2007.

[2] Stare Z. Mijat N. Stojkovic, N. Dual-mode digital revolution counter.volume 2, pages 950 –954 vol.2, 2001.

[3] Thomas Brunl. Embedded Robotics: Mobile Robot Design and Applica-tions with Embedded Systems. Springer Publishing Company, Incorpo-rated, 2008.

[4] D. A. Gaydou, G. F. Perez Paina, G. M. Steiner, and J. Salomone.Plataforma movil de arquitectura abierta. In Proceedings of the V

Argentine Symposium of Robotics 2008 . Ediuns, 2008, November 2008.[5] E. Olson. A primer on odometry and motor control. Technical report,

Massachusetts Institute of Technology, 2007.



120




Filtro complementario para estimacion de actitud

aplicado al controlador embebido de un cuatrirrotor

David Gaydou, Javier Redolfi y Agustın HenzeCentro de Investigacion en Informatica para la Ingenierıa

Universidad Tecnologica Nacional - Facultad Regional Cordoba

[email protected]

Resumen—Se presentan los resultados del dise ˜ no e imple-mentacion de un sistema de estimacion de actitud para unrobot autonomo volador de cuatro rotores utilizando para dichaestimacion, primero en forma independiente un acelerometroy un giroscopo de tecnologıa MEMS, y luego fusionando lasmediciones de ambos sensores mediante un filtro complementario.

Index Terms—Cuadricoptero, Giroscopo, Acelerometro, Filtrocomplementario.

I. INTRODUCCION

A continuacion se presenta un sistema para estimacion de

actitud de un robot volador autonomo (UAV, Unmanned Aerial

Vehicle) de cuatro rotores capaz de despegar verticalmente y

realizar vuelos estacionarios que esta siendo desarrollado en

el Centro de Investigaciones en Informatica para la Ingenierıa

(C.I.I.I.) en la Facultad Regional Cordoba de la Universidad

Tecnologica Nacional. Este robot esta disenado para ambi-

entes interiores como ası tambien exteriores con condiciones

atmosf ericas limitadas. Se preve una carga util de 1 Kg. Elsistema de control de estabilidad esta implementado en un

microcontrolador LPC2114 de NXP. Este controlador consta

de dos lazos anidados, el lazo interno controla la actitud

de la aeronave y el externo genera referencias para el lazo

interno a fin de controlar la posicion. El lazo interno consta de

tres compensadores proporcional, integral y derivativo (PID)

digitales, dos para controlar los angulos de cabeceo (ϕ) y

rolido (θ) y el tercero para la orientacion (ψ). Estos 3 angulos

son conocidos como angulos de navegacion. El sistema de

lazo cerrado para ϕ y θ tiene un ancho de banda teorico de

15 Hz. El mecanismo de medicion de estos angulos debe

poseer una frecuencia de corte por encima de este lımite

para no comprometer la estabilidad ni degradar el desempenodinamico.

Para determinar la inclinacion se utilizan acelerometros tipo

MEMS, que poseen numerosas ventajas para esta aplicacion,

como ser buen ancho de banda, suficiente resolucion, peso

reducido, robustez y bajo costo. Mediante estos sensores es

posible determinar la direccion y el sentido del vector de acel-

eracion de la gravedad respecto a un marco de referencia fijo

en la aeronave. La desventaja fundamental de estos sensores

radica en que las mediciones son fuertemente afectadas por las

vibraciones en la estructura donde se encuentran montados.

Otra alternativa para medir la inclinacion es computar la

rotacion integrando la senal de sensores giroscopicos. Por

las mismas razones que el caso anterior, los dispositivos

de tecnologıa MEMS resultan los mas apropiados para esta

aplicacion, aunque si bien son mas inmunes a las vibraciones

presentan derivas sostenidas en el tiempo debido a la inte-

gracion de los errores de offset.

En adelante, el contenido se organiza de la siguiente manera.En la seccion 2 se evaluan un acelerometro y un giroscopo

como sensores de medicion de inclinacion. Se muestran los

inconvenientes que producen las vibraciones y las derivas.

En la seccion 3 se propone combinar las mediciones de

los sensores mediante un filtro complementario que permita

reconstruir una estimacion de las mediciones a partir de las

partes de los espectros de las senales adquiridas con cada

sensor, cuya informacion se encuentre menos corrompida.

En la seccion 4 se presentan los resultados de los ensayos

utilizando el filtro complementario. En la seccion 5 se discuten

las conclusiones.

Figura 1: Montaje experimental usado para realizar los ensayos

(balancın).

II. ENSAYO INDIVIDUAL DE LOS SENSORES

Para los ensayos que se describen a continuacion se con-

struyo un montaje experimental que consta de un balancın

con un propulsor en cada extremo, un potenciometro en el

pivot y el sensor con el sistema de control montado en el

centro. Este montaje con un grado de libertad permite simular

el comportamiento dinamico aproximado del sistema respecto



121




2 3 4 5 6 7 8tiempo [s]

30

20

10

0

10

[ g r a d o

s ]

9

(a) Angulo de rolido en funcion del tiempo.

0 20 40 60 80

frecuencia [Hz]

0

10

20

30

40

50

60

70

80

90

M a g n i t u d

(b) Espectro de frecuencias.

Figura 2: Angulo medido con el acelerometro, con el montaje

en equilibrio formando un angulo de 10o y los propulsores

apagados.

al rolido o el cabeceo.(Fig. 1). Aparte del sistema mecanico, el

montaje cuenta con un controlador PID digital implementado

en el microcontrolador, el cual cierra el lazo del sistema a

traves del control de la velocidad de los motores. Para lograr

una notacion consistente supondremos que el angulo a medir

es el de rolido (θ).

II-A. Aceler ometro

En el desarrollo experimental se utilizo el acelerometro

ADXL345 de tres ejes dispuesto de manera que los ejes de

medicion del mismo coincidan con los ejes del sistema de

referencia del UAV. De esta manera el angulo se obtiene como

ϕ = a rc co sax

g, donde la aceleracion ax se mide con una

resolucion de 10 bits, y un ancho de banda ajustable por

software desde 0.05 Hz. hasta 1600 Hz.

Las Fig. 2a,2b y las Fig. 3a, 3b muestran comparativamente las

senales adquiridas del sistema a lazo abierto en estado de equi-

librio con una inclinacion de 10o con los propulsores apagados

y con los propulsores encendidos (50 %) respectivamente.

2 3 4 5 6 7 8tiempo [s]

30

20

10

0

10

[ g r a d o s ]

¡


0 20 40 60 80

frecuencia [Hz]

0

2000

4000

6000

8000

10000

12000

M a g n i t u d


Figura 3: Angulo medido con el acelerometro, con el montaje

en equilibrio formando un angulo de 10o y los propulsores

encendidos al 50 % de su potencia.

Si bien el sistema en lazo cerrado formado por el balancın

mas el controlador PID presenta un buen rechazo a las

componentes ruidosas de alta frecuencia de las vibraciones,

esto se aprecia en la curva de bode simulada para un sistema

ideal de la Fig. 4 y en las curvas de respuesta en el tiempo del

mismo sistema que se ven en la Fig. 5, las variaciones bruscasde la senal de referencia producen acciones de control, debidas

a la rama del derivador del compensador, que llevan a los

motores a zonas no lineales (saturacion o corte), provocando

la inestabilidad del sistema real. Esto se puede comprobar

calculando la componente derivativa del compensador PID

usando como entrada de error la senal de la Fig. 3a.

El filtrado de la senal ruidosa mediante un filtro pasa-bajos

introduce otras desventajas: si bien se pueden mantener aco-

tadas las derivadas en la senal, la atenuacion y el corrimiento

de fase degradan la respuesta dinamica e incluso provocan

inestabilidad cuando las frecuencias de corte son demasiado

bajas. La Fig. 6a muestra la respuesta temporal del sistema



122




[ d B ]

[ g

r a d o s ]

0

-10

-20

0.1 1 10 100

0

-20

-40

-60

-80

-100

frecuencia [Hz]

Figura 4: Respuesta en frecuencia del sistema completo a lazo

cerrado.

[ g r a d o s ]

10

8

6

4

2

0

-2

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1tiempo [s]

(a) Frecuencia de la perturacion de 5Hz .

[ g r a d o s ]

10

8

6

4

2

0

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1tiempo [s]

(b) Frecuencia de la perturacion de 50Hz .

Figura 5: Respuesta temporal del sistema de lazo cerrado detipo regulador con una perturbacion sumada a la medicion

ideal de 0,1o de amplitud para frecuencias de 5Hz y 50Hz.

para una medicion no ruidosa y no filtrada, en la Fig. 6b

la misma senal se pasa por un filtro pasa-bajos de 5 Hz de

frecuencia de corte, finalmente si se disminuye la frecuencia

de corte del mismo a 2 Hz el sistema se desestabiliza, tal como

lo muestra la grafica de simulacion de la Fig. 6c.

Como consecuencia de las caracterısticas ruidosas de las

mediciones adquiridas con el acelerometro no serıa posible

utilizarlo como inclinometro en el sistema de estabilizacion.

[

g r a d o s ]

10

5

0

0 0.5 1 1.5 2

tiempo [s]

(a) Sin filtrar.

[ g r a d o s ]

10

0

-6

0 0.5 1 1.5 2tiempo [s]

(b) f c = 5Hz

[ g

r a d o s ]

200

0

-200

0 0.5 1 1.5 2tiempo [s]

(c) f c = 2Hz

Figura 6: Respuestas temporales del sistema a lazo cerrado de

θ para senales no ruidosas, pero previamente pasadas por un

filtro pasa bajos.

A raız de esto se evalua la posibilidad de utilizar un giroscopo.

II-B. Gir oscopo

Para realizar los siguientes experimentos se utilizo un

giroscopo de 3 ejes ITG3200 de la firma InvenSense. Este

se dispuso de manera que sus ejes esten alineados con los

del sistema de referencia de abordo. Este dispositivo posee

un rango dinamico de +/ − 2000[o/s] y una sensibilidad de

14o/s. En las Fig. 7a, 7b, 8a,8b se observan comparativamente

las senales en el tiempo y el espectro para el caso que los

propulsores estan apagados y encendidos con la misma

configuracion que la descripta para el caso de la medicion

con el acelerometro. Haciendo una comparacion de la Fig. 3a



123




2 3 4 5 6 7 8 90.01

0.00

0.01

0.02

0.03

0.04

0.05

0.06

0.07¡

tiempo [s]

[ g r a d o s ]


0 20 40 60 80 1000

5

10

15

20

25

m a g n i t u d

frecuencia [Hz](b) Espectro de frecuencias.

Figura 7: Angulo medido con el giroscopio, con el montaje

en equilibrio y los propulsores apagados.

con la Fig. 8a se puede ver que la influencia de las vibraciones

en las mediciones del giroscopo son sensiblemente menores

que en el caso del acelerometro. Sin embargo se han observado

intervalos de tiempo relativamente cortos, la Fig. 9 muestra

que para tiempos mayores la medida de este sensor comienza

a derivar.

III. FILTRO COMPLEMENTARIO

En forma intuitiva surge la idea de usar la medicion obtenida

por el giroscopo para tiempos cortos y realizar la correccion

de la deriva con la medicion realizada por el acelerometro

en tiempos largos, debido a que esta ultima medicion tiende

a ser la aceleracion de la gravedad para perıodos largos.

Los filtros complementarios son muy usados en sistemas de

navegacion inercial. Aplicaciones tıpicas son la combinacion

de las medidas de aceleracion vertical y velocidad barometrica

vertical para obtener una estimacion de la velocidad vertical

o mediciones de unidades inerciales y sistemas de vision. [1]

Un filtro complementario es en sı un filtro de Kalman de

estado estacionario para una cierta clase de problemas de

2 3 4 5 6 7 8 9.

.5

.

.5

.

.5

tiempo [s]

[ g r a d o s ]


0 20 40 60 80 1000

0

100

10

200

20

300

30

400

f recuencia [Hz]

m a g n i t u d


Figura 8: Angulo medido con el giroscopio, con el montaje

en equilibrio y los propulsores encendidos al 50 % de su

potencia..

filtrado [2], este no considera ninguna descripcion estadıstica

del ruido que corrompe a las senales y es obtenido solamente

por un analisis en el dominio de la frecuencia. El filtro

complementario resulta sencillo de tratar matematicamente y

en razon de su baja complejidad de implementacion consume

pocos recursos computacionales. La idea basica del filtro

complementario es combinar la salida del acelerometro y

del giroscopo para obtener una buena estimacion del angulo

de orientacion de la plataforma, compensando la deriva del

giroscopo con la dinamica lenta del inclinometro [3].

El filtro complementario propuesto es el que se muestra en

la figura 10. Donde θa es el angulo medido por el acelerometro

cuya senal esta corrompida por ruidos de alta frecuencia

proveniente de las vibraciones, θg es el angulo medido por

el giroscopo, afectado por la deriva y θ es el angulo estimado.

Las funciones de transferencia del filtro deben ser elegidas

de acuerdo a la ecuacion 1:



124




0 5 10 15 20 25 30 35 40 Tiempo (s)

20

15

10

5

0

5

10

15

Giró¡ scopo

Potenció¡ metro

[ g r a d o s ]

Figura 9: Deriva del angulo medido por el giroscopo

Figura 10: Diagrama en bloques del filtro complementario

utilizado.

H a(s)

G(s) +

H g(s)(1

−G(s)) = 1 (1)

en donde H a(s) y H g(s) representan las funciones de trans-

ferencia del acelerometro y el giroscopo respectivamente.

Suponemos que las funciones de transferencia de los sen-

sores son iguales a 1. Esto es H a(s) = H g(s) = 1.

La funcion de transferencia elegida para G(s) es un filtro

pasa bajos de primer orden, lo cual hace que la estimaci on en

baja frecuencia dependa de la medicion del acelerometro.

G(s) =α

s + α(2)

En tanto que la funcion de transferencia elegida para 1 −G

(s

) es un filtro pasa altos de un polo:

1−G(s) =s

s + α(3)

este filtro nos permite hacer que las componentes de alta

frecuencia de la medicion estimada esten dominadas por el

aporte de las mediciones provenientes del giroscopo.

Como podemos ver en la figura 10, si ambas mediciones

son ideales, la funcion de transferencia total del filtro resulta:

θ(s)

θ(s)= G(s) + (1−G(s)) = 1 (4)

Y esto hace que:

θ(s) = θ(s) (5)

III-A. Discretizaci´ on de los filtros

Para la implementacion de los filtros digitales en el micro-

controlador se parte discretizando las funciones de transferen-

cia de los mismos usando la transformada z y suponiendo un

retenedor de orden cero a la entrada. Con esto se obtiene una

expresion compacta para el filtro completo.

Si definimos: G1(s) = G(s) y G2(s) = 1−G(s), entonces:

G1(z) =(1− e

−T

τ )z−1

1− e−T

τ z−1(6)

G2(z) =1− z

−1

1− e−T

τ z−1(7)

En donde a = 1τ

y τ representa la constante de ambos

filtros.

III-B. Algoritmo del microcontrolador

El algoritmo del microcontrolador surge del paso a ecua-

ciones en diferencias de las funciones de transferencia de cada

filtro.

θ[k] = θa[k] + θg[k] (8)

θa[k] = e−T

τ θa[k−1] + (1− e−T

τ )θa[k−1] (9)

θg[k] = e−T

τ θg[k−1] + θg[k] − θg[k−1] (10)

ω[k]T = θg[k] − θg[k−1] (11)

θg[k] = e−T

τ θg[k−1] + ω[k]T (12)

IV. RESULTADOS DE LA I MPLEMENTACION

Se ensayo el sistema utilizando el filtrado complementario

verificandose una buena estimacion del angulo que resulto en

la correcta estabilizacion y una buena respuesta dinamica.

En la figura 11 se muestran las mediciones individuales del

acelerometro y el giroscopo; y la estimacion del filtro com-

plementario; mientras se sometio al sistema a perturbaciones

forzandolo a salir de la posicion de equilibrio y permitiendoleque se restituya en forma autonoma. Como se observa en

la grafica se calibro debilmente el offset del giroscopo para

permitir una deriva exagerada a fin de mostrar el rechazo

del filtro. En la Figura 12 se observa la medida del angulo

estimada por el filtro contrastada contra la medicion del po-

tenciometro durante la evolucion del sistema desde un angulo

inicial de -10 grados hasta el equilibrio en cero grado. En este

ensayo se utilizo la medida del filtro para la realimentacion del

lazo de control y se ajustaron las constantes del controlador

PID. Este ajuste se realizo segun los analisis de estabilidad

hechos del sistema a lazo cerrado para obtener la respuesta

subamortiguada que se observa, aunque hubo que realizar



125




algunos retoques empıricos los cuales se pueden deber a que

se idealizaron algunas partes del sistema y tambien a falta de

una buena calibracion de los sensores y propulsores.

0 5 10 15 20 25 30

Tiempo (s)

40

20

0

20

40

60

Aceleró¡

metroGiró¡ scopo

Filtro Complementario

[ g r a d o s ]

Figura 11: Mediciones y estimacion durante ensayo del sis-

tema.

22 23 24 25 26 27 28 Tiempo (s)

15

10

5

0

5

10

15

Filtro Complementario

Potenció¡ metro

[ g r a d o s ]

Figura 12: Respuesta dinamica del sistema ante una pertur-

bacion

V. CONCLUSIONES

Se ensayaron tres metodos de medicion de inclinacion

de una plataforma experimental que se comporta como el

UAV con cinco grados de libertad restringido, permitiendose

rotaciones que corresponderıan al cabeceo o el rolido de

la aeronave. Los dos primeros metodos ensayados utilizaron

acelerometro por un lado y giroscopo por otro de manera

individual. En el primer caso la influencia de las vibraciones

impide el correcto funcionamiento del lazo de control, en

tanto que si se filtra la senal de la medicion se degrada la

respuesta dinamica o incluso se llega a la inestabilidad del

sistema de lazo cerrado para frecuencias de corte demasiado

bajas. Por el lado del giroscopo se obtuvo mejores resultados

en el comportamiento del lazo de control, no obstante esto la

deriva producida por el offset del sensor hace que el error de

inclinacion se incremente de manera constante en el tiempo.

Ninguno de los dos metodos resulta viable para el control de

actitud del UAV.

Finalmente se aplico un filtro complementario para combinar

la medicion de ambos sensores tomando de cada uno la parte

del espectro de la senal de medicion menos corrompida y

atenuando la otra a fin de que la suma permita una estimaci on

aproximada de la variable de interes. El comportamiento

dinamico del sistema realimentado con la medicion estimada

por el filtro resulta satisfactorio para ser aplicado al prototipo

real.

AGRADECIMIENTOS

El primer autor se financia bajo el programa de Becas de

Formacion de Doctores en Areas Tecnologicas Prioritarias.

Ministerio de Ciencia, Tecnologıa e Innovacion Productiva,Agencia Nacional de Promocion Cientıfica y Tecnologica -

FONCyT IP-PRH 2007 - Resolucion C.S. No 649/08.

REFERENCIAS

[1] G. Buskey, J. Roberts, P. Corke, and G. Wyeth, “Helicopter automationusing a low-cost sensing system,” Computing & Control Engineering

Journal, vol. 15, no. 2, pp. 8–9, 2004.[2] W. Higgins, “A comparison of complementary and Kalman filtering,”

Aerospace and Electronic Systems, IEEE Transactions on, no. 3, pp. 321–325, 2007.

[3] A. Baerveldt and R. Klang, “A low-cost and low-weight attitude esti-mation system for an autonomous helicopter,” in Intelligent EngineeringSystems, 1997. INES’97. Proceedings., 1997 IEEE International Confer-ence on. IEEE, 2002, pp. 391–395.



126






127




Software Embebido



128






129




Aplicación Web embebida para el control de payload de un satélite

Ing. Gabriel Rodrigo [email protected]

Dr. Pedro E. [email protected]

Instituto Universitario Aeronáutico, Especialidad en Sistemas Embebidos

Av. Fuerza Aérea 6500 (5010) Córdoba, Córdoba, Argentina

Abstract — Este trabajo presenta una solución real de diseño e

implementación de una aplicación de control del payload de unsatélite geoestacionario construida como un ambiente webembebido operando en una plataforma de microcontroladoresRabbit. La misma permite enviar comandos y leer telemetría de lacarga útil durante la integración al modelo de ingeniería y vuelo.Se plantea en primer lugar el diseño del hardware que provee alsistema de las interfaces adecuadas para llevar a cabo laconectividad entre el payload y el módulo. El resultado final es undispositivo capaz de realizar el monitoreo y control, a través de

una red Ethernet, de distintas variables de estado, proveyendo alusuario de una interfaz gráfica que puede ser ejecutada encualquier terminal remota con conexión a Internet.

Keywords: Carga útil, satélite, web, sistemas

embebidos, telecomandos, telemetría,

geoestacionario.

I. INTRODUCCIÓN

En el proceso de construcción de un satélite uno de losprincipales objetivos es lograr comandar y conocer elestado de distintas variables de la carga útil (payload)durante la integración con los modelos de ingeniería yvuelo. En el proyecto referido en este trabajo surgió la

necesidad de explorar las diversas alternativas quepermitirían implementar conectividad TCP/IP(Transmission Control Protocol/Internet Protocol),proveer el acceso a los subsistemas mediante un servicioWeb y gestionar, en una capa más baja del stack delprotocolo, el hardware subyacente de la plataforma pormedio de interfaces estrictamente definidas de la cargaútil. El módulo encargado de comandar el payload es launidad de interfaz de distribución de carga útil (PIDUpor su nombre en inglés Payload Interface Distribution

Unit ), en este diseño se busca sustituir el PIDU de vueloen la etapa de integración del payload al modelo deingeniería del satélite.En tecnología satelital se crea con éste propósito unequipo eléctrico de soporte en tierra (EGSE por sussiglas en inglés Electrical Ground Support Equipment )el cual sirve de apoyo durante la fase de integración yensayo de cada uno de los subsistemas del satélite, tantoen el modelo de ingeniería, como en el modelo de vuelo.En este trabajo se describe el diseño de un equipo deésta índole que sirve de apoyo en la fase de integracióndel payload de un satélite geoestacionario el que ha sidoespecificado para trabajar en banda Ku con canales de36MHz y 72MHz de ancho de banda, como así también

con un cierto número de entradas/salidas digitales yanalógicas. Uno de los desafíos que debe resolverexitosamente el diseño propuesto es la implementaciónde la solución mediante herramientas estandar y quepermita entregar desde una plataforma embebida unaGUI (GUI por las siglas en inglés Graphical UserInterface) flexible para su operación. Los alcances delproyecto requieren que este deba ser realizado bajoestrictos y restrictivos requerimientos de costo,calendarios y calidad claramente especificados.

II. DESARROLLO DEL MÓDULO Y APLICACIÓNEMBEBIDA

En base a las interfaces del PIDU y a las necesidades delos usuarios en la fase de integración, es que sedesprenden los requerimientos de la plataformaembebida, principalmente en lo que respecta al hardwarede la misma. Para el desarrollo se eligió una plataformaRCM3365 [R01] basada en microprocesadores Rabbit[R03],la que cumple con los requisitos de cantidad deentradas/salidas, conectividad Ethernet, stack TCP/IPintegrado y prestaciones de espacio en memoriaadecuadas para este desarrollo.Una vez seleccionada la plataforma, se desarrollaron losrestantes componentes de hardware y software,actividades que involucraron:

• Diseño del la plataforma de hardware de acuerdo conlos requerimientos de interfaces del fabricante del

payload .• Diseño y fabricación del circuito impreso, listados demateriales y documentación del desarrollo.• Poblado de la placa (630 componentes) y soldadurapor olas y horno de termo-fusión.• Diseño e implementación de la aplicación embebidaen la plataforma seleccionada (RCM3365) mediante

Dynamic C para el envío de telecomandos y recepciónde telemetría a través de la plataforma de hardware conel payload.• Implementación de un servicio Web donde lainformación a desplegar se genere utilizando el formatoHTML y se despliegue utilizando RabbitWeb[R02].• Definición del protocolo de comunicación para unaaplicación remota, usando TCP/IP.



130




A. Definición de interfaces y requerimientos de

diseño

De acuerdo con las especificaciones de la misión seránnecesarios los siguientes tipos de interfaces:

• Low Level Commands (LLC) – Envío de comandos

digitales

• Digital Relay (DR) – Lectura de Telemetría digital

• Analog Ouput (AN) – Lectura de Telemetría

analógica

• Temperature Sensing (PT) – Lectura de telemetría

analógica

B. Estrategia de diseño

En la Tabla 1 se especifican las interfaces LLC, para el

caso de DR se corresponden entradas digitales TTL y el

rango de las lecturas analógicas es de 0 a 5V.

Tabla 1 Especificaciones de interfaces LLC

Teniendo en cuenta los requerimientos de diseño y las

especificaciones del payload la plataforma de hardware

debe contar con 16 salidas LLC, 6 entradas DR, 2 AN y

2 PT. El envío de comandos es vía interfaces LLC y la

lectura de telemetría discreta mediante interfaces DR,

por lo tanto asociamos telecomandos (TC) con LLC ytelemetría (TM) con DR.

Figura 1 Arquitectura general de interfaces del

PIDU

La arquitectura de interfaces es la descripta en la Figura

1 donde se puede apreciar un diagrama del PIDU, para

el cual, la plataforma embebida debe conectarse como

un usuario del payload.

A partir del diseño de alto nivel del satélite se define el

entorno de integración así la configuración base de los

EGSE. La arquitectura seleccionada utiliza armarios de

20” resistentes a las vibraciones conteniendo una PC

industrial, una pantalla de 17” y de la electrónica

adicional involucrada en cada subsistema a ser

integrado. El software que corre en la PC tiene como

propósito controlar la electrónica del EGSE para que sevincule con cada subsistema. Surge entonces la

necesidad de contar con una GUI con la que puedan

configurarse parámetros establecidos durante la etapa de

integración y ensayo.

El enfoque convencional es implementar este diseño

mediante una FPGA, pero para satisfacer losrequerimientos de conectividad con la plataforma de

simulación (SIMPLAT por sus siglas en inglés

Simulation Platform) es mandatorio disponer de un

stack Ethernet en 10Mbps.

Como estrategia de diseño todos los módulos EGSE se

comunicarán con el SIMPLAT por medio de TCP/IP,

con lo cual es evidente la importancia de seleccionar una

plataforma que cuente con soporte para este protocolo.

Una posible solución explorada en el diseño explicado

en este trabajo es recurrir a una interfaz basada en Web

donde la información se codifique en HTML. Se aprecia

la flexibilidad de configuración de la misma y por la

facilidad de acceso remoto desde cualquier PC

conectada al ambiente de desarrollo del satélite.

En este marco, considerando restricciones en los

tiempos del proyecto, disponibilidad de herramientas de

desarrollo y costos, la elección de un microprocesador

de la familia Rabbit proporciona la flexibilidad necesaria

puesto que esta provee capacidad de conexión TCP/IP,

programación en una versión propietaria de C ( Dynamic

C ) y abundantes recursos de desarrollo.

El diseño de interfaces con el payload, LLC, DR, AN y

PT es, por tratarse de un satélite geoestacionario,

propietario de la empresa proveedora de la carga útil.

Está implementado con interfaces muy robustas y

resistentes a fallas. Esos mismos atributos por otra parte

hacen que sea imposible encontrar en el mercado

hardware de control que se adapte para los

requerimientos de la misión. Fue necesario entoncesdiseñar un hardware de interfaces a nivel electrónico

específico que contemplara al mismo tiempo

conectividad con el usuario y con el SIMPLAT.

C. Selección de la plataforma embebida

RCM3365

De acuerdo con las prestaciones de diseño de hardware,

y la posibilidad de que el módulo a ser desarrollado

fuera usado en la integración de otros subsistemas del

satélite como potencia, control de actitud, navegación yotros, se tuvieron en cuenta la disponibilidad de un

número importante de entradas/salidas LLC, DR

adicionales para expansión futura.

En el otro extremo las características de comunicación

TCP/IP servicio web y la posibilidad de acceso vía

Telnet, requieren cantidades de memoria significativas

lo que resulta clave al momento de elección de la

plataforma de desarrollo. Conjugando espacio en



131




memoria (512K programa, 512K datos), capacidad dealmacenamiento masivo y la cantidad de E/S provistapor 52 líneas, se seleccionó para el diseño elmicroprocesador RCM3365 de la familia Rabbit.La plataforma seleccionada soluciona varios problemasde diseño de hardware al proveer una capa físicaEthernet, tolerancia al régimen de alimentación ymemoria incorporada en dispositivo [R03].

Al seleccionar una plataforma embebida basada enRCM3365 se facilita, además, la solución derestricciones de implementación puesto que el módulode desarrollo se monta en un zócalo de interfaz. De estaforma se puede trabajar de manera simultánea a lapuesta en marcha del hardware para posteriormente serintegrado en la plataforma final.Otro problema resuelto con la elección, es solucionar lacapa física de Ethernet, puesto que el módulo cuenta conun conector RJ45 y el hardware asociado para operarcon este protocolo.

III. DISEÑO DEL HARDWARE DE INTERFAZ

Una vez finalizada la etapa de definición derequerimientos de diseño se pudo avanzar con laelaboración de los planos esquemáticos-eléctricos, delhardware de interfaz que hace de nexo entre laplataforma embebida RCM3365 y las interfaces de lacarga útil.El diseño fue sometido a dos procesos de revisión porestar involucrado directamente con un subsistema de unsatélite y de manera de realizar la detección de defectoslo más temprano posible en el ciclo de vida del proyecto.Los procesos de revisión típicos son la revisiónpreliminar de diseño (PDR por Preliminary Design

Review) y revisión crítica de diseño (CDR por Critical

Design Review). Una vez establecida la línea de base delos requerimientos de diseño, se realiza la PDR con elobjetivo de saber si se han comprendido esosrequerimientos y se está en condiciones de avanzar conla fase de diseño de detalle. En este análisis, se presentael sistema como un diagrama en bloques.Finalizada la PDR comienza la etapa de desarrollo yantes de fabricar la placa se realiza la CDR donde seestudia a nivel de circuitos y en detalle cada una de lasinterfaces involucradas y los posibles modos de fallo. Eneste análisis se presentan planos esquemáticos muydetallados de cada circuito.

Por último se realiza un análisis independiente de modosde falla (FMEA Failure mode and effects analysis). Encaso de detectar riesgos de que el fallo de uncomponente se propague y dañe el hardware de vuelo, seidentifica la mitigación a realizar mediante estrategias deprotección como interfaces opto-acopladas o deaislamiento galvánico.Se utilizan en la implementación, prácticas de Ingenieríade Software [C04,P01] consistentes con la complejidad deldesarrollo realizado, la criticidad de los entregables y la

necesidad de alcanzar estrictos requerimientos decalidad.Diseñado el esquemático se desarrolla el diseño delcircuito impreso (PCB) teniendo en cuenta aspectos deInterferencia y compatibilidad electromagnética(EMI/EMC) e integridad de las señales entre otros.

A. Diseño de la aplicación embebidaPara la programación embebida se utilizaron losrecursos de desarrollo provistos por el lenguaje DynamicC propietaria de la plataforma RCM3365. Este lenguajees un derivado de C adecuado y mejorado para losrequerimientos de los microprocesadores de la familiaRabbit. El fabricante de los módulos entrega junto con elkit de desarrollo de la plataforma, el software paraprogramación [R05] y el cable de conexión con la PCutilizada como ambiente de desarrollo.Una vez finalizada la puesta en marcha a nivelelectrónico de la plataforma de interfaz de hardware secomienza a trabajar en el componente de software. En

primera medida se validan todas las entradas/salidasdigitales, LLC y DR, comprobando que el software seacapaz de comandar y leer todos los puertos delmicroprocesador que habían sido asignados a lasdistintas interfaces del PIDU. Este proceso se simplificanotablemente aplicando una técnica de “stubs” [C04] (funciones simuladas no operativas) donde pequeñossegmentos de código son aplicados a verificar unaspecto en particular.A continuación se presenta en el Ejemplo 1, laprogramación que muestra como se escribe y lee unpuerto en Dynamic C [C01] para un módulo RCM3365.

Los canales de entrada analógicos AN y PT provienende un conversor analógico-digital (ADC Analog To

Digital Converter ) de Analog Devices AD7993AR [C03] que posee una interfaz serial I2C [I01].El lenguaje de programación Dynamic C incluye unainterfaz de desarrollo API [D01] llamada I2C.LIB [R04],que maneja los aspectos genéricos de la interfaz I2C yproporciona funciones simplificadas [C02] para que eldiseñador utilice el módulo RCM3365 como un Masterdel BUS según lo mostrado en la Figura 2.

Ejemplo 1 Lectura de puerto en Dynamic C

main()BitWrPortI(PDDDR, &PDDDRShadow,0,1); // switch, inputBitWrPortI(PDDDR, &PDDDRShadow,1,0); // LED, outputBitWrPortI(PDDR, &PDDRShadow,1,0); // apaga LEDwhile(1)

if(!BitRdPortI(PDDR,1))BitWrPortI(PDDR,&PDDRShadow,0,0); /* Prende el LED DS1 */

elseBitWrPortI(PDDR,&PDDRShadow,1,0); /* Apaga el LED DS1 */



132




Figura 2 Arquitectura Rabbit como master de BusI2C

Los principales elementos del API proporcionado por la

librería pueden ser vistos en la Tabla 2. Una vez

corroborado el correcto funcionamiento de todas las

entradas/salidas del la plataforma embebida, LLC, DR,

AN y PT, se pone el énfasis en la interfaz con el usuario.

El software Dynamic C provee un entorno de trabajo,

para el cual, una de sus principales ventajas es poder

realizar una depuración del programa paso a paso, esto

constituye una herramienta muy importante a la hora de

realizar cualquier implementación en una plataforma

embebida de este tipo.

Tabla 2 Elementos del API de gestión de busI2C

B. Implementación Web utilizando Rabbit Web

El servidor HTTP es el encargado de resolver las

solicitudes GET y POST direccionada a la dirección IP ypuerto donde está escuchando el servidor [H01]; lasmismas son respondidas mediante páginas HTML

generadas dinámicamente. De esta forma un usuario

puede entre otras facilidades:

• Configurar distintos parámetros de funcionamiento

como dirección IP y usuario del dispositivo

• Obtener registros parciales de las muestras de

temperatura y valores analógicos de tensión propiciados

ambos por el ADC.

• Obtener valores de telemetría DR del payload.

• Enviar comandos LLC al payload.

En el Ejemplo 2 se presenta de manera simplificada la

estructura del software en Dynamic C implementada

para montar un servicio web en un módulo RCM3365.Para el desarrollo de la página HTML se utilizó el

software Macromedia DreamWeaver 8; en realidad

cualquier editor puede ser utilizado con éste propósito

puesto que el diseño de las páginas es relativamente

sencillo y el volumen de información desplegada bajo.

El principal uso de este servicio es proveer una interfazde usuario que se capaz vincular las variables leídas

desde el bus I2C del ADC provenientes de los canales

AN y PT, y procesar las mismas para que puedan ser

mostradas al usuario en formato de página HTML.

1) Incorporación de RabbitWeb

RabbitWeb es una facilidad que ofrece Dynamic C, con

la cual se puede crear una interfaz web para los

dispositivos de la familia Rabbit. La principal ventaja

respecto a servidores HTTP convencionales consiste en

la eliminación de la necesidad de utilizar programaciónCGI [G01]. El resultado obtenido es una página Web que

puede ser accedida desde cualquier PC visible mediante

ruteos TCP/IP de manera que permita al usuario enviarcomandos LLC y leer telemetría DR y analógica. Una

página web relaciona al usuario con la electrónica del

payload en la etapa de integración del modelo de

ingeniería. Como fuere mencionado anteriormente, la

recolección de telemetría y el envío de telecomandos

debe ser llevado a cabo por el SIMPLAT que emula la

aviónica del satélite y no su carga útil. Al realizarlo es

necesario implementar un protocolo de comunicación

entre éste y la plataforma embebida que replique la que

tendrá luego en la plataforma de ingeniería y de vuelo.

• Inicialización de los pines de I2Ci2c_init() // Configura SCL y SDA como salidas de OC y constantes de retardo.

• Envío de la condición de Comienzoi2c_start_tx() // Inicializa la transmisión mediante el envío de un comienzo (start)

i2c_startw_tx() // Inicializa la t ransmisión mediante el envío de un Start (S)

// Inserta un delay después del pulso S

• Envío de un Byte de datosi2c_write_char() // Envía 8 bits al dispositivo esclavo

i2c_wr_wait() // Reintenta escribir una variable char hasta que el esclavoresponde

• Escucha de un ACKi2c_check_ack() // Chequea si un dispositivo esclavo pone un bajo en SCL

• Recepción de un Byte de datos

i2c_read_char() //Lee 8 bits de datos de un dispositivo esclavo• Envío de un ACKi2c_send_ack() // Envía una secuencia ACK al esclavo.

i2c_send_nak() // Envía una secuencia NAK

• Envío de una condición de paradai2c_stop_tx() // Envío de P (STOP) al esclavo

#define TCPCONFIG 0#define USE_ETHERNET 1

#define MY_IP_ADDRESS "192.168.1.54"

#define MY_NETMASK "255.255.255.0"#define MY_GATEWAY "192.168.1.1"

#ximport "index.html" index_html

#ximport "rabbit1.gif" rabbit1_gif

#memmap xmem#use "dcrtcp.lib"

#use "http.lib"const HttpType http_types[] =

".html", "text/html", NULL, // html

".gif", "image/gif", NULL ;

const static HttpSpec http_flashspec[] =

HTTPSPEC_FILE, "/", index_html, NULL, 0, NULL, NULL,

HTTPSPEC_FILE, "/index.html", index_html, NULL, 0, NULL, NULL, HTTPSPEC_FILE, "/rabbit1.gif", rabbit1_gif, NULL, 0, NULL, NULL ;

main()

sock_init();http_init();

while(1)

htt handler

Ejemplo 2 Implementación de HTML en RCM3365



133




2) Comunicación con aplicación vía TCP/IP.

El protocolo de comunicación entre la aplicaciónembebida y el simulador de plataforma se implementasobre un socket TCP/IP, en el campo de datos delsegmento, donde la plataforma RCM3365 operará comocliente. El control de flujo propio de TCP/IP garantizauna entrega de paquetes en orden y libres de errores, locual constituye una ventaja para la integridad de lacomunicación. El SIMPLAT inicia la conexión con laplataforma embebida enviando un paquete “ Request ”(TM o TC) formado por 4 Bytes (32bits), que incluye:número de secuencia, un identificador de unidad(Payload Nominal o Redundante) y un campo de datos,donde se especifica el comando “TC Variable” que elSIMPLAT desea enviar o el valor de telemetría “TM

Variable “que se pretende leer. Para una solicitud detelemetría “TM Request”, la plataforma embebidadevuelve un paquete “TM Response” con el mismonúmero de secuencia con el cual se originó la petición yel campo “TM Value” con un valor de TM DR, AN oPT según lo requerido, de tratarse de una solicitud detelecomandos “TC Request”, la plataforma, retorna unpaquete “TC Response” (eco), tras haber ejecutado elcomando indicado en los campos “ LLC Status” y “TC

Variable”. En caso de que la conexión no pueda serestablecida dentro de 10 intentos se asumirá unacondición de error en el SIMPLAT. Las principalesventajas del protocolo bidireccional implementado sonsimplicidad y robustez. La estructura de los paquetes dedatos del protocolo de comunicación puede serobservada en la Tabla 3.

Tabla 3 Estructura de los paquetes de datos delprotocolo de comunicación Implementado

Cada 500 mSeg el SIMPLAT establecerá unacomunicación con la plataforma embebida realizando elenvío de telecomandos (TC Resquest ) y/o pedidos detelemetría (TM Request ) que estén determinados en eseciclo. Se ha implementado en la memoria de programa

del módulo RCM3365 una tabla de asignación detelecomandos y variables de telemetría, que vincula TCy TM con valores hexadecimales.Estos valores son enviados en el campo “TM Variable” o “TC Variable” de los paquetes “TM Request” y “TC

Request” implementados para este protocolo decomunicación En la figura 4 se puede observar elfuncionamiento del protocolo. Si la plataformaembebida encuentra un error en el sub-campo “TM

Variable” o “TC Variable” del campo de datos de unpaquete “ Request ”, devolverá un paquete “retry” con

número de secuencia 0x00 y el campo de datos con unvalor 0x000000, lo cual indicará al SIMPLAT un pedidode retransmisión. Si la plataforma no devuelve unnúmero de secuencia esperado por el SIMPLAT, segenerará automáticamente desde el SIMPLAT unreenvío de la solicitud TM o TC según corresponda.

Figura 4 Funcionamiento del Protocolo deComunicación Simplat-Plataforma

Una vez finalizado el período de comunicación con laplataforma, la misma estará esperando hasta quecomience un nuevo ciclo de Telecomandos y pedidos deTelemetría que esté determinado por parte delSIMPLAT.

IV. VALIDACIÓN Y VERIFICACIÓN

La validación y verificación (V&V) del diseño requiereconsideraciones especiales. A nivel de verificación se

procede a revisar unitariamente cada interfaz enparticular, los niveles de tensión, corrientes, tiempos detransitorios, flancos y tolerancias requeridas por elfabricante del payload las que son estrictas.Para los ensayos a nivel unitario de recepción decomandos y emisión de telemetría mediante “stubs” quesimularon el payload a ser controlado de acuerdo a laespecificación de su fabricante. Posteriormente serealizó la integración con el payload de manera deverificar la recolección de telemetría DR. Se probaron100 casos de estados de cambios de variablescontroladas por un operador y su correcto reflejo en lainformación HTML proporcionada por la interfaz Web.

Una estrategia similar se utilizó para verificarunitariamente los comandos LLC controlando coninstrumental apropiado que los parámetros eléctricos yde tiempo estuvieran dentro de especificación al mismotiempo que se verifica que las lecturas soncorrectamente reflejadas en la GUI. Los resultados deltest fueron documentados e incluidos en ladocumentación del sistema.La integración con la PC industrial se resuelve tambiéncon un criterio de verificación unitaria primero paraluego ser validado con mediante ciclos extendidos de



134




mediciones del SIMPLAT, verificando la conectividad

integrada entre la plataforma embebida bajo desarrollo y

el simulador de la plataforma.La integración final del EGSE con el subsistema ha

quedado para una etapa posterior del proyecto y no se ha

completado al momento de formular esta publicación.

V. RESUMEN DEL PROYECTO

La duración total del proyecto implicó aproximadamente

un año de trabajo desde la definición de requerimientosa nivel sistema, hasta la concepción de un entregable

como el descripto en este trabajo.

El enfoque utilizado cumple con todas las etapas de un

ciclo de vida de tipo iterativo incluyendo

requerimientos, diseño, construcción, etapas de testing,

integración de hardware y software y validación del

EGSE. El esfuerzo total de desarrollo es del orden de 3

personas-año donde algunas etapas fueron tercerizadas

tales como la fabricación de PCB, poblado de la placa,

soldadura por horno y por olas, este diseño constituye

una pieza de relevante importancia en la cadena de tests

de integración y ensayo de un satélite geoestacionario.

VI. CONCLUSIONES

Este trabajo refleja la creación de una plataforma

embebida como parte del proyecto de desarrollo de un

satélite geoestacionario. Este tipo de desarrollo apela a

la sencillez de un entorno HTML/Web para implementar

la interfaz de usuario. El proceso de desarrollo se

sostiene en prácticas de ingeniería de software

establecidas tales como ciclo de requerimientos, diseño

por etapas, establecimiento de línea de base de

configuración e inspecciones confirmando la utilidad de

estas técnicas en el desarrollo de sistemas embebidos de

esta complejidad. Queda confirmada la hipótesis de las

ventajas relativas de la plataforma elegida respecto a un

desarrollo funcionalmente equivalente basado en

arquitecturas FPGA. Estas ventajas se ven en aspectos

tales como capacidad de integración de hardware y

software como una solución integrada así la posibilidadde actualización flexible del firmware, lo cual

transforma al módulo desarrollado en una estructura

tolerante al cambio de requerimientos de diseño. Las

aplicaciones de este módulo en las etapas de integración

y ensayo del satélite geoestacionario son diversas, de

acuerdo con los requerimientos de cada subsistema a ser

integrado, razón por la cual, para cada uno de ellos elsoftware embebido en el módulo RCM3365 deberá ser

actualizado y modificado. Este desarrollo se extenderá

entonces hasta fines del 2011, fecha estipulada para

finalizar con la integración del modelo de ingeniería delsatélite.

Una ventaja del diseño utilizado fue desarrollar en un

entorno de programación amigable, basado en las

estructuras del lenguaje C, lo cual permitió abordar la

tecnología con una curva de aprendizaje modesta

comparada a la que hubiera sido necesaria para adquirir

los conocimientos de VHDL para haber podido utilizar

una implementación en FPGA.

La disponibilidad de gran cantidad de ejemplos, notas deaplicación y manuales del fabricante sirvieron de guía en

este desarrollo y una importante cantidad de

aplicaciones similares en el mundo de los entornos

embebidos indicaban que la alternativa elegida fuera la

correcta.

Como aprendizaje se puede mencionar que elcompilador de Dynamic C 9.62 no es totalmente

compatible con ANSI C y si bien puede ser portado

entre diferentes microprocesadores de la familia Rabbit,

se requiere un trabajo extra para implementarlo. Usos

específicos como RabbitWeb con Z Server son

propietarios y no son reutilizables en otros

microprocesadores o plataformas embebidas.

Quedará como trabajo a futuro culminar con la

integración del payload al modelo de ingeniería y

actualizar el software embebido de cada módulo de

acuerdo a los requerimientos de cada subsistema a ser

integrado.

La integración final del EGSE con el subsistema será

realizada a fines de Julio del corriente año y se prevé

hacer en primera medida una recepción e inspección

visual del subsistema montaje en el modelo de

ingeniería del satélite y posterior encendido, apagado del

transmisor, receptor. Se busca en primera instancia

verificar las funcionalidades vitales. El plan de

integración y ensayo tiene estipulado en la segunda

etapa conectar un simulador de canal, y realizar pruebas

específicas, para lo cual la plataforma aquí desarrollada

es de vital importancia para el control de la carga útil.

REFERENCIAS

[C01] Caprile S.R.: Desarrollo con procesadores y módulos Rabbit 2ª

Ed. (2005) ISBN: 987-21834-2-2

[C02] Caprile S.R.: EL camino del conejo. 2ª Ed. ISBN: 978-987-1301-28-7

[C03] Conversor Analógico Digital AD7993AR-

http://www.analog.com [C04] Colofello J. S.”Introduction to Software V&V” SEI Curriculum

Module SEI-CM-13-1.1 1988

[D01] Daughtry J.M.,Farooq U et al “API Usability:Report on specialgroup interest at CIDH” SIGSoft V34N4 pp 27-29 2009

[G01] Gundavaram, S “Common Gateway Interface” O’Reilly Open

Book Project

[H01] Hyder K,Perrin B “Embedded Systems Design using the Rabbit

3000 Microprocessor” ISBN: 0-7506-7872-0[I01] I2C: Inter-Integrated Circuit

(http://www.nxp.com/acrobat_download/literature/9398/39340011.pdf

)[P01] Pressman, R. “Software Engineering: A Practit ioner's

Approach”,7th Ed McGraw-Hill ISBN 0071267824

[R01] Rabbit RCM3365 Data sheet-http://www.rabbit.com/products/rcm3365/rcm3365.pdf

[R02] RabbitWeb -

http://www.rabbit.com/documentation/docs/modules/RabbitWeb/RabbitWeb.pdf

[R03] Rabbit Technical Notes and white Papers http://www.rabbit.com

[R04] Rabbit Referencia manual librería I2C.lib-http://www.rabbit.com/documentation

[R05] Rabbit Software Dynamic C version 9.6

http://www.rabbit.com/support



135




Wireless Ethernet

Bridge

Router Wireless

I2C

Mod5270

Módulo deSensores

PuertoEthernet

Estación Meteorológica Web

Router Ethernet

Ethernet

LAN

Enfoque embebido para una Estación Meteorológicacon Interfaz Web

Esp. Ing. Martín Federico PellizaEspecialidad en Sistemas EmbebidosInstituto Universitario Aeronáutico

Córdoba, [email protected]

Mg. Héctor RisoEspecialidad en Sistemas EmbebidosInstituto Universitario Aeronáutico


Abstract —Este trabajo tiene como objetivo realizar unaexploración y evaluación de posibilidades para el desarrollo deaplicaciones embebidas que ofrezcan conectividad de red. En esemarco se eligió como ejercicio el desarrollo de un prototipo deuna estación meteorológica web, implementando una aplicaciónembebida en un módulo de desarrollo del fabricante Netburneral cuál se integró el hardware necesario para medición de

temperatura y movimientos sísmicos. Como resultado se obtuvoun dispositivo totalmente autónomo que permite a través de unared ethernet el monitoreo de diferentes condiciones ambientalesen tiempo real, el acceso a los registros de los datos almacenados

internamente en el dispositivo, y la configuración remota dedistintos parámetros de su funcionamiento.

I. INTRODUCCIÓN

Con el objetivo de explorar las posibilidades actuales a lahora de desarrollar dispositivos con capacidades de red, seeligió como ejercicio el desarrollo de un prototipo para laadquisición y registro de diversas condiciones ambientales, quepermita el acceso a los mismos en tiempo real a través de unared ethernet.

Para la implementación preliminar de una solución, lasalternativas que se presentaban eran el desarrollo de unhardware dedicado basado en microprocesador y softwareembebido que implemente tanto los protocolos de red y lainterfaz con los sensores, o bien la utilización de unaplataforma que ya integre la solución de red y acote el trabajode desarrollo. Se seleccionó esta última opción, ya que seestimó que el esfuerzo de desarrollo requerido para la primeraopción sería considerablemente mayor y excedería los límitesde tiempo propuestos para este trabajo, y se eligió comoplataforma de desarrollo un módulo Mod5270 de Netburner [1]

Luego de la selección de la plataforma, se desarrollaron loscomponentes de Hardware y de Software, actividades queinvolucraron:

• El diseño y fabricación de un módulo de sensores parala adquisición de datos de aceleración y temperatura,extensible para la incorporación de sensores depresión, humedad, velocidad y dirección de viento, etc.

• El diseño y la implementación en C++ de la aplicaciónembebida en el Mod5270 para la adquisición y registrode datos del módulo de sensores, y su acceso remoto

• La definición de un protocolo para la comunicación dedatos vía UDP.

• La implementación de un servicio web para el acceso alos datos y configuración del Mod5270, utilizandoHTML y JavaScript para el desarrollo de las páginasweb. Esta actividad incluyó también la implementaciónen JAVA de un applet para la visualización en tiemporeal y en forma gráfica de los datos de temperatura ymovimientos sísmicos.

La descripción de las estas tareas y los resultados obtenidosen cada una de ellas se desarrollan en las siguientes secciones.

En Fig. 1 se muestra el dispositivo desarrollado dentro deun contexto de aplicación.

Figure 1. Contexto de Aplicación

II. DESARROLLO DEL HARDWARE

A. Plataforma

El seleccionó el módulo Mod5270 de Netburner comoplataforma de desarrollo. El módulo incluye entre suscaracterísticas principales

• Procesador de 32-bits ColdFire MFC5270

• Sistema operativo C/OS-II

• Puerto 10/100 Ethernet

• Interfaz RS-232

• 2Mb de SDRAM, 512K de memoria flash



136




El sistema operativo C/OS-II es un sistema operativo entiempo real multitarea basado en prioridades, ideal para serutilizado en aplicaciones embebidas. El C/OS-II estáintegrado con el sistema de I/O del Mod5270 y ofrece (ademásde las funciones y rutinas básicas para la creación yadministración de tareas) librerías de soporte para diversos

protocolos de comunicación de red (entre otros DHCP, TCP,UDP, HTTP) y de interfaz con otros dispositivos (tales comoI2C y SPI) [2]. Estas librerías son utilizadas por la aplicación

para la adquisición y registro de datos, como así también parala exposición del servicio web.

B. Módulo de sensores

Se desarrolló un módulo básico de hardware de adquisiciónde datos, cuyo diseño se enfocó en la facilidad para laintegración de distintos tipos de sensores. Con este criterio seadoptó el bus I

2C

TMpara la comunicación entre los sensores del

módulo y la plataforma Mod5270. El bus I2C es un bus de bi-

direccional, que provee un mecanismo sencillo y eficiente parael intercambio de datos entre dispositivos, con una

interconexión mínima entre ellos, ya que es un bus de doscables.

La flexibilidad del bus permite la incorporación de sensoresal módulo de manera directa, con la sola condición de que estossoporten una interfaz I

2C. De esta forma el módulo de sensores

es extensible y permite la medición variadas condicionesambientales, además de las ofrecidas por el prototipo, comopor ejemplo presión, humedad, velocidad viento, etc.

El módulo de adquisición de datos desarrollado para esteprototipo cuenta con dos sensores para la medición detemperatura, y un sensor para la medición de movimientossísmicos.

Para la medición de temperatura se escogieron los sensoresdigitales de temperatura TMP101 de Texas Instruments [3] ySTTS75 de STMicroelectronics [4], mientras que para lamedición de movimientos sísmicos se utilizó el acelerómetrodigital de 3 ejes LIS3LV02DL STMicroelectronics [5]. Todoslos sensores están interconectados al bus I

2C y se utilizan en

modo esclavo, mientras que el Mod5270 es utilizado comomaestro.

Los sensores de temperatura utilizados poseencaracterísticas similares en cuanto a su rango de medición (de –55°C a +125°C), pero se configuraron con resolucionesdiferentes, el primero con una resolución de 9 bits (0.5°C ) y elsegundo con una resolución de 12 bits (0.0625°C), con el finde evaluar el desempeño de cada uno en distintos rangos.

Por otro lado se utilizó el sensor LIS3LV02DL para la

medición de aceleraciones. Este dispositivo permite rangos deaceleración a fondo de escala de +/-2.0g y +/-6.0g, con unancho de banda de la conversión variable entre 10Hz y 640Hz,ambos seleccionables por software durante el funcionamiento.Como la aceleración en la mayoría de los terremotosmoderados está comprendida entre 0,05 g y 0,35 g (llegando enalgunos casos a alcanzar aceleraciones de 0,5 g cuando elmovimiento del suelo es medido sobre suelo firme o roca muycerca de la fuente de ondas), y su frecuencia típica se encuentraentre 0,5Hz y 2Hz (llegando a 4Hz en casos excepcionales) [6]

y [7], este dispositivo es apropiado para la medición demovimientos sísmicos.

III. DESARROLLO DEL SOFTWARE

Se desarrolló una aplicación embebida en el Mod5270,

encargada de obtener los datos del módulo de sensores,mantener un registro de los mismos y permitir el acceso a estosdatos en forma remota a través de HTTP, FTP o UDP.

El Mod5270 opera bajo un sistema operativo multitareapreemptivo, basado en prioridades. La aplicación ejecuta lasrutinas de acceso a la red (inicialización del stack TCP yadquisición de IP dinámica) y luego crea, configura e inicia lastareas que ejecutan las actividades mencionadas en el párrafoanterior en forma independiente.

Las principales tareas ejecutadas por la aplicación puedendividirse en:

A. Adquisición de datos a través del módulo de sensores

Existen dos tareas encargadas de obtener cíclicamente losdatos de temperatura y aceleración, realizando el muestreo dedatos con la frecuencia configurada a través de la página deconfiguración del sistema. El período de muestreo paratemperatura puede variar entre 1 y 3600 segundos, mientrasque para aceleración el período de muestreo puede variar entre200 y 1000 milisegundos (en saltos de 50 milisegundos).

La aplicación permite registrar hasta un máximo de 3600muestras de temperatura y 18000 muestras de aceleración. Estenúmero máximo de muestras se determinó asumiendo una horade almacenaje, con el período de muestreo de temperatura de 1segundo y de movimiento de 200mS. Las muestras sealmacenan en un buffer circular, por lo que las muestras másantiguas son reemplazadas por nuevas muestras una vez que ellímite máximo de cada tipo de muestra es alcanzado.

La adquisición de los datos de temperatura y movimientodel módulo de sensores se realiza a través del bus de dos líneasI2C. Cada dispositivo conectado al bus posee una direcciónúnica de 7 bits, y puede actuar como transmisor o receptor dedatos. El Mod5270 es utilizado como maestro (el dispositivoque inicia la comunicación), mientras que los dispositivos delmódulo de sensores son configurados en modo esclavo. Laespecificación del protocolo I

2C [8] describe el proceso de

transmisión de datos entre dispositivos.

Inicialmente la tarea de adquisición de temperaturasconfigura los sensores de temperatura para una resolución de12 bits el TMP100 y 9 bits el STTS75, en modo de muestreocontinuo (una muestra cada 340ms). Luego, de acuerdo alperíodo configurado, solicita muestras de temperatura al sensoractivo. La tabla de conversión de bits a °C es similar paraambos sensores, y puede encontrarse en la Tabla 4 de [4]

La tarea de adquisición de aceleraciones configura al sensorde aceleración para una escala de medición de de +/-2.0g conuna resolución de 12 bits (~0,001 g), con una frecuencia demuestreo de 40Hz (25mS). Luego, la tarea solicita muestras deaceleración de acuerdo al período de muestreo configurado. Latabla de conversión de bits a G se muestra en Table 1.



137




TABLE I. TABLA DE CONVERSIÓN

Tabla de Conversión de Aceleración

Aceleración (G) Salida Digital HEX

2.0000 0111 1111 1111 7FF1.5625 0110 0100 0000 6401.0000 0100 0000 0000 400

0.2930 0001 0010 1100 12C0.0039 0000 0000 0100 004-0.0039 1111 1111 1100 FFC-0.2930 1110 1101 0100 ED4-1.5625 1001 1100 0000 9C0-2.0000 1000 0000 0000 800

B. Servicio FTP

Permite obtener archivos con los registros de las últimasmuestras de temperatura y movimientos sísmicos, como así también un registro completo de los eventos del sistema. Enesta versión de la aplicación en el servidor sólo seimplementaron los siguientes comandos definidos por el

protocolo FTP: “ls” para obtener los nombres de los archivosdisponibles, “get” para descargar archivos, y “bye” parafinalizar la conexión.

Los clientes FTP pueden descargar archivos con losdiferentes registros (aceleración, temperatura y eventos delsistema) en formato de texto. Estos archivos son generadosbajo demanda, ya que el Mod5270 no posee un sistema dearchivos, y contienen una lista de todas las muestrasdisponibles.

Cada entrada del archivo contiene la hora, un índicerepresentando la secuencia y un valor entero decimal querepresenta el valor la medición, de acuerdo a la conversión detemperatura y aceleración de las tablas descriptas en la secciónanterior de este documento.

C. Servicio UDP

Esta tarea implementa un protocolo de comunicación parala transmisión datos de mediciones a aplicaciones externas viaUDP. El servidor recibe mensajes solicitando distintos tipos demuestras (UDP Sample Requests), respondiendo a los mismoscon las muestras requeridas en un mensaje de respuesta (UDPSample Response). El puerto del servidor es configurable através de la página de configuración.

a) Sample Request El campo Tipo de Muestra contiene un código de 8 bits

cuyo valor identifica solicitudes de muestras de temperatura oaceleración.

El campo Cantidad de Muestras (16 bits) es utilizado parasolicitar el envío una cantidad fija de muestras.

El campo Ultima Muestra Recibida (16 bits) es utilizadopara solicitar el envío de una cantidad variable de muestras.

La Fig. 2 muestra el formato de un UDP Sample Request

Figure 2. UDP Sample Request

b) Sample ResponseUn mensaje UDP Sample Response puede contener una o

mas muestras, cada una con un formato como el que se detallaen Fig. 3. El encabezado de una muestra indica, en su MSB, siesa muestra es la última muestra disponible o si existen otrasmuestras más actuales disponibles, y en sus 7 bits restantes elcódigo del tipo de muestra (aceleración o temperatura). Loscampos Índice y TimeStamp son comunes a cualquier tipo demuestra, mientras que los restantes campos se diferencian paralas muestras de temperatura y aceleración.

El campo Índice (16 bits) indica el número de secuencia dela muestra. Su valor máximo depende del tipo de muestra,siendo 3600 para muestras de temperatura y 18000 paramuestras de aceleración.

El campo TimeStamp (entero sin signo de 32 bits) contienela fecha y hora de la muestra expresada en Tiempo UniversalCoordinado (UTC)

El campo mS (16 bits) está presente sólo en muestras deaceleración y contiene los milisegundos del TimeStamp

Los campos de Temperatura (16 bits) y Aceleración X-Y-Z(cada una un valor de 16 bits) contienen el valor de la medicióncorrespondiente, según la conversión de aceleración ytemperatura descripta en secciones anteriores (los bits 15-14-14-12 son siempre 0).

Se permite incluir hasta 50 muestras en un mensaje UDPSample Response (para limitar el tamaño del paquete UDP a750 bytes).

Figure 3. UDP Sample Response

Cuando un UDP Sample Request contiene en el campo

Ultima Muestra Recibida el número de secuencia de unamuestra, el servidor enviará un mensaje UDP Sample Responsecon todas las muestras desde el índice indicado, hasta lamuestra más actual disponible. El campo Cantidad de Muestras es considerado sólo si el campo Ultima Muestra Disponible contiene un número negativo.

En Fig. 4 se ejemplifica el uso de de este protocolo. ElApplet desarrollado para la visualización de datos en tiemporeal desde la página web hace uso de este protocolo para laadquisición de las muestras de temperatura y aceleración.



138




Cliente Servidor

Muestra actual‘t’: 34‘a’: 123

UDPSampleRequest (‘a’,20,-1)

El cliente solicita las últimas20 muestras de aceleración

UDPSampleResponse

El servidor responde con unmensaje con las muestras deaceleración 103 a 123

UDPSampleRequest (‘a’,0 , 123)

El cliente solicita las muestrasde aceleración desde la últimarecibida, 123


UDPSampleResponseEl servidor responde con unmensaje con las muestras deaceleración 124 a 131

UDPSampleRequest (‘t’,-1 ,-1)

El cliente solicita la últimamuestra de temperaturadisponible


El servidor responde unmensaje con la muestrastemperartura 82

UDPSampleResponse

Figure 4. Funcionamiento del protocolo para la solicitud de muestras

D. Servicio HTTP

Esta tarea es la encargada de procesar solicitudes HTTP. Elservidor soporta solicitudes GET y POST, respondiendo a lasmismas mediante paginas HTML generadas dinámicamente.Accediendo a este servicio un usuario puede:

Configurar distintos parámetros de funcionamientodel Mod5270

Obtener registros parciales de las muestras detemperatura y movimientos sísmicos

Obtener registros de eventos del sistema

Mostrar en tiempo real las muestras temperatura ymovimientos sísmicos

a) Pagina de configuración

Los parámetros configurables a través la página deconfiguración son el período de muestreo de temperatura ymovimientos sísmicos (aceleración), la dirección IP delservidor NTP con el cual la aplicación se sincroniza, el puertodonde el servicio UDP está disponible, el tipo de filtro aplicadoa las muestras de aceleración y la selección del sensor de

temperatura activo.En este prototipo la implementación de HTTP soporta

autenticación “BASIC”, y este esquema es utilizado para elacceso a la página de configuración de los parámetros defuncionamiento, para la cuál la provisión de credenciales esobligatoria. Este esquema es utilizado sólo con fines deidentificación, ya que no constituye un método seguro deautenticación (los datos son transmitidos como texto claro).

Cada cambio en la configuración de los parámetros defuncionamiento del Mod5270, es registrado como un evento desistema.

Figure 5. Pagina de configuración

b) Registros

Los registros parciales de las últimas muestras detemperatura y movimientos sísmicos, como así también de loseventos del sistema se obtienen en la pestaña Registros de lapágina web.

Los eventos del sistema también son registrados y puedenser accedidos a través de la página esta misma página.

Es todos los casos, es posible seleccionar la visualizaciónde los entre 10 y 100 últimos registros. Los registros completospueden obtenerse vía FTP.

Figure 6. Registros de Aceleración

c) Mediciones en tiempo real

Para la visualización en tiempo real de los datos, el servidordescarga en el navegador del cliente un applet encargado deobtener (vía UDP y adhiriendo al protocolo descrito ensecciones anteriores) y procesar los datos, desplegándolos enforma gráfica. El applet solicita muestras cada 750mS yactualiza los gráficos con las muestras del último paquete UDP



139




recibido. Se despliegan las últimas 50 muestras de temperaturay 300 muestras de aceleración.

Figure 7. Mediciones en tiempo real

E. Sincronización de la hora del sistema

Esta tarea se ocupa de sincronizar el reloj interno delMod5270 a través de un cliente NTP. La aplicacióninicialmente sincroniza el reloj interno del sistema medianteuna solicitud a un servidor NTP, y a partir de ese momento sere-sincroniza cada 4 horas.

De existir algún error durante la sincronización, laaplicación intenta nuevamente restablecer el contacto con elservidor NTP cada 10 minutos, hasta lograr la re-sincronización (inicialmente 00:00:00 GMT 1 Ene 1970 encaso de no poder sincronizarse).

Los errores durante la sincronización de la hora son

almacenados en el registro de eventos del sistema.

IV. CONCLUSIONES

Durante el ejercicio se realizaron actividades deinvestigación sobre las diferentes alternativas existentes a lahora de diseñar una sistema embebido, que involucraron elestudio de microprocesadores, plataformas, sensores, einterfaces, la aplicación de diferentes protocolos de red, eldiseño y fabricación de un módulo de hardware y laprogramación, en C++, JAVA, JavaScript, HTML y sobre unaplataforma basada en un sistema operativo en tiempo real, deuna aplicación embebida completa.

El resultado demostró que existen en el mercado actualopciones para el desarrollo de sistemas embebidos con

conectividad de red que involucran un esfuerzo de desarrollorelativamente acotado; la alternativa que se evaluó no sóloincorpora la solución de red, sino que además ofreceherramientas (en la forma de paquete de librerías, entorno dedesarrollo integrado, hardware de base para la prototipación)que facilitan tanto el desarrollo de las aplicaciones embebidas,

como así también la integración de los diferentes componentesde hardware necesarios para implementar un sistematotalmente autónomo con capacidades de red.

Si bien el desarrollo de un producto aplicado supone ladefinición de requerimientos más específicos basados ennecesidades concretas, el presente trabajo puede constituir unpunto de partida para el monitoreo de diferentes entornos endonde el uso de conectividad Ethernet es extendido. Laintegración de nuevos sensores y la utilización de esquemas decaptura inalámbricos tales como ZigBee o Bluetooth permitiríapor ejemplo la comprobación de condiciones de presión,humedad y temperatura en laboratorios, vibraciones en salas deensayos, etc.

Futuras evoluciones del prototipo podrían centrarsetambién en la definición de una estrategia para el registro pordisparo en lugar del registro continuo para las mediciones demovimientos sísmicos, la medición de determinadas variablessólo bajo demanda, la implementación de estrategias para lagestión de fallos o la incorporación de capacidades deseguridad (por ejemplo el uso de SSL para el cifrado de datosintercambiados entre servidor y cliente).

REFERENCIAS

[1] Netburner Mod5270 Data Sheet -http://www.netburner.com/downloads/mod5270/mod5270_datasheet_pinout_diagram.pdf

[2] Netburner Mod5270 Hardware User’s Manual -http://csserver.evansville.edu/~richardson/courseware/resources/EE458/ nburn/docs/platform/Mod5270.pdf

[3] Texas Instruments TMP100 Data Sheet -http://www.datasheetcatalog.org/datasheet/texasinstruments/tmp101.pdf

[4] STMicroelectronics STTS75 Data Sheet -http://www.stmicroelectronics.fr/stonline/products/literature/ds/13298/stts75.pdf

[5] STMicroelectronics LIS3LV02DL Data Sheet -http://www.stm32circle.com/projects/file/DataSheet/lis3lv02dl.pdf

[6] Terremotos – Bruce A Bolt – Ed. Reverte -http://books.google.com.ar/books?id=KmHP0lGeQWQC&lpg=PP1&pg=PP1#v=onepage&q=&f=false

[7] Registro y tratamiento de acelerogramas – Carreño, Suárez, Bravo yTordesillas - Física de la tierra, ISSN 0214-4557, Nº 11, 1999 (Ejemplardedicado a: Ingeniería sísmica), pags. 81-111 -http://revistas.ucm.es/fis/02144557/articulos/FITE9999110081A.PDF

[8] Philips Semiconductors: The i2c (Inter-Integrated Circuit) busspecification. -

(http://www.nxp.com/acrobat_download/literature/9398/39340011.pdf )



140




Diseño de un sistema de actualización de firmwarepara un sistema embebido

Esp. Ing. Diego Gustavo RocaEspecialidad en Sistemas EmbebidosInstituto Universitario Aeronáutico


Dr. Pablo FerreyraEspecialidad en Sistemas EmbebidosInstituto Universitario Aeronáutico


Resumen— En este trabajo se analiza la problemática que se

observa al momento de tener que actualizar el firmware de unsistema embebido, cuando éste ya se encuentra en manos del

usuario final. Se proponen soluciones efectivas a dicha

problemática y una secuencia de pasos para llevar adelante enforma segura la actualización.

I. INTRODUCCION

Los sistemas embebidos tienden, fruto del avancetecnológico, a ser cada vez más potentes, integrados ycomplejos. Esto hace que puedan realizar tareas cada vez máscomplicadas y que sean tan flexibles como para adaptarse adistintas situaciones. Esas mismas razones, sumadas anecesidades de mercado, traen aparejada la necesidad constantede corregir, mejorar o modificar el software que los controla;aun cuando el sistema embebido esté en manos del usuariofinal.

El presente trabajo está basado en un caso real. Se analiza ydescribe la problemática encontrada al momento de tener que

actualizar el software de un sistema embebido. En todomomento la problemática es confrontada con losrequerimientos del sistema y restricciones propias del caso real.Finalmente se describe el diseño de la solución propuesta.

De aquí en adelante en el presente trabajo se denominará al“Sistema embebido” como el “Equipo”, por razones desimplicidad.

II. REQUERIMIENTOS DEL SISTEMA DE ACTUALIZACIÓN

Se describen a continuación los requerimientos recibidos almomento de iniciar el trabajo:

1 - Desarrollar un sistema que permita actualizar el

firmware del Equipo sin necesidad de cambios de hardware.Entiéndase como cambio de hardware a cualquier componenteo parte que haya que reemplazar para efectivizar laactualización, por ej.: Memorias pregrabadas, tarjetas SD,placas, etc.

2 - Del punto 1 se desprende que, para llevar adelante laactualización, se deberá enviar al lugar en que se encuentra elEquipo alguna forma de archivo conteniendo el nuevofirmware. A dicho archivo lo denominaremos de aquí enadelante como: “Archivo de actualización”.

3 - Se deberán suministrar medios que permitan controlar orestringir la aplicación del Archivo de actualización sobre losEquipos. Esto implica que el Archivo de actualización puedausarse para actualizar sin restricciones el firmware de cualquierEquipo (que tenga los medios para ello), o que dicho Archivode actualización sea aplicable únicamente a un grupodeterminado de Equipos, o, más restrictivo aún, que dicho

Archivo de actualización sea aplicable a un único Equipo enparticular. Al momento de generar ese Archivo deactualización deberá poder seleccionarse el grado de restriccióna aplicar.

4 - El Equipo dispone como interfaz de comunicacionessolamente de un puerto serie RS-232C.

5 - La empresa fabricante del Equipo no posee un servidorde acceso público desde el cual se podría descargar el Archivode actualización.

III. MODELO DEL SISTEMA DE ACTUALIZACIÓN

En esta sección se hará un análisis de los requerimientos delsistema de actualización y se planteará un modelo donde sedescribirán las partes involucradas. Se esbozarán también loslineamientos básicos de funcionamiento.

Visto desde el lado del Equipo, el requerimiento 4 imponela necesidad de una computadora que se conecte al Equipo yque permita descargar el Archivo de actualización al mismo.Será necesario también contar con un operador que lleveadelante acciones básicas.

El requerimiento 5 lleva a proponer el envío del Archivo deactualización al lugar donde se vaya a hacer la actualizaciónvía e-mail.

El requerimiento 3 impone la necesidad de hacer algún tipode procesamiento al archivo de imagen de memoria, como así también la necesidad de algún control de integridad del mismo.Por ello, será necesario desarrollar una aplicación de PC queprocese el archivo de imagen de memoria y genere el Archivode actualización.



141




Fig. 1. Modelo del sistema de actualización remota.

En la Fig. 1 se observa el modelo propuesto para el sistemade actualización. La secuencia lógica de pasos para recorrer elmodelo sería la siguiente: El fabricante lanza la nueva versiónde firmware, que en nuestro caso es básicamente la imagen dememoria. Ese archivo es procesado por una aplicación de PCque lleva el nombre de “Packer”, se obtiene así el Archivo deactualización. El Archivo de actualización es enviado al lugaren que se encuentre el Equipo vía e-mail. Para llevar adelantela actualización, el operador del sistema necesita otraaplicación de PC que lleva el nombre de “Updater”. Laaplicación “Updater” se encarga de descargar el Archivo de

actualización al Equipo y actúa como interfaz entre el operadory el Equipo durante el proceso de actualización.

A. Análisis de la problemática involucrada en el modelo del

sistema de actualización

Una vez obtenido el modelo del sistema, se hace un análisisde los posibles problemas y riesgos que se podrían encontrar alo largo del circuito de actualización, con el fin de plantearsoluciones a los mismos.

Básicamente, el principal riesgo que se encuentra en todosistema de actualización de firmware es que ante un fallo oerror en el mismo, el equipo que recibe la actualización quedeimposibilitado de operar. Ese es el principal factor a tener en

cuenta en todo momento durante el diseño del sistema.En el modelo planteado se pueden distinguir tres puntos

problemáticos: El primero aparece durante el envío del Archivode actualización al usuario del Equipo, ya que se emplea unmedio no seguro como lo es el e-mail. Es así que el Archivo deactualización puede caer en manos inapropiadas y que le seaaplicado un proceso de ingeniería inversa, con el fin dedespejar el código fuente del mismo o introducirlemodificaciones que alteren su funcionamiento. De igual modo,el Archivo de actualización puede corromperse en el caminosin necesariamente la participación de terceros. Se deberíatambién, suministrar algún mecanismo que permita al Equipoautenticar que el Archivo de actualización es válido.

El segundo punto problemático, aparece durante la descargadel Archivo de actualización al Equipo, a través del enlace RS-232C. Aquí se encuentra que la conexión se puede interrumpir,lo que haría que el Archivo de actualización quede truncado, ouna interrupción momentánea haría que se pierda parte delArchivo de actualización, quedando este incompleto. Por otraparte, el ruido en el canal podría hacer que se corrompa elArchivo de actualización.

El tercer punto problemático está en el proceso degrabación del nuevo firmware en la memoria FLASH del

Equipo. Un corte de energía durante la grabación de lamemoria FLASH sería fatal, como así también un apagado delequipo, ya sea intencional o no, ya que podría dejarloinoperante. Otro problema, es que se grabe una versión defirmware válida, pero equivocada (como sería, por ejemplo,grabar por error una versión más antigua).

IV. DISEÑO DEL SISTEMA DE ACTUALIZACIÓN

En este punto se deben conjugar los requerimientosiniciales, el modelo propuesto y el análisis de problemas yriesgos del modelo, con el fin de obtener una solución quesatisfaga los requerimientos y elimine o al menos mitigue losriesgos asociados.

A. Solución a los riesgos asociados al envío vía e-mail del

Archivo de actualización

El envío del Archivo de actualización al usuario a través dee-mail, es el punto de mayor exposición pública de lainformación. Se deben asegurar aquí tres principios básicos deseguridad de la información: Privacidad, Integridad yAutenticidad.

La Privacidad de la información se obtendrá encriptandotoda la información transportada que es útil al sistema. Elalgoritmo de encriptación seleccionado para el caso es el TEA(Tiny Encryption Algorithm) [1]. Como su nombre lo indica,TEA es un algoritmo compacto y de implementación muysimple, especial para sistemas embebidos ya que consumepocos recursos. Como contrapartida, existen varios estudios decriptoanálisis [2] del algoritmo, que lo hacen relativamentedébil, pero para el caso en estudio la relación costo/beneficioque enfrenta un tercero en el caso de realizar un ataque contrael Archivo de actualización es lo suficientemente elevada comopara disuadirlo de hacerlo. TEA es un algoritmo de cifrado porbloques, que emplea una estructura de tipo Feistel con 64rondas, opera sobre bloques de 64 bits y emplea una clave de128 bits. En el modelo se prevé que el Archivo de actualizaciónsaldrá encriptado y solo podrá ser desencriptado por el Equipo,el cual tendrá la clave de desencriptación previamenteembebida. El modo de operación seleccionado para procesarlos bloques es el CBC [3] (Cipher Block Chaining),empleándose un Vector de Inicialización aleatorio, que formaráparte del Archivo de actualización.

El control de Integridad se obtendrá al aplicar una funciónde Hash SHA-1 al Archivo de actualización, cuyo resultado seanexará al final del mismo y será comprobado por la aplicación“Updater” al momento de recibir el Archivo de actualización ycomo paso previo a enviarlo al Equipo a través del enlace RS-232C.

La Autenticidad del Archivo de actualización se verificaráen base a un método muy simple, que consiste en agregar alArchivo de actualización un “Magic Number” de 8 bytes, cuyovalor será fijo y conocido por el Equipo, quien al momento dedesencriptar el Archivo de actualización controlará que en laposición esperada se encuentre dicho valor.

Todo lo mencionado hasta aquí, delinea la estructura quetomará el Archivo de actualización, y a medida que se avanceen el análisis, la estructura final quedará configurada.



142




B. Solución a los riesgos durante la descarga del Archivo de

actualización a través del enlace RS-232

Los problemas asociados a la descarga del Archivo deactualización desde la aplicación Updater al Equipo, secontrolan empleando un protocolo de comunicacionesadecuado a las necesidades del caso en estudio. El protocoloserá propietario y se implementará en base a capas, brindandoal conjunto la funcionalidad esperada.

El protocolo deberá poseer la capacidad de segmentar elArchivo de actualización y enviarlo al Equipo en forma depaquetes. Se decidió segmentar al Archivo de actualización ensegmentos de 1024 bytes, cada uno de los cuales se enviarádentro de un paquete.

Cada paquete tendrá un campo que será el CRC32 delsegmento, lo que permitirá al Equipo detectar un paquete condatos corruptos al momento de recibirlo. El mecanismo dedetección es bien simple: el Equipo al recibir el paquetecalculará el CRC32 del segmento y luego lo contrastará con elCRC32 recibido con el paquete, si ambos difieren el segmentoestá corrupto.

Cada segmento tendrá un número de secuencia asociado(SEQ), lo que permitirá detectar si un paquete se perdió en elcamino, o si llegaron segmentos en orden alterado. Se deberecordar que segmentar implica tener que reconstruir luego elArchivo de actualización y la pérdida o llegada fuera desecuencia de algún segmento conlleva a que el Archivo deactualización quede inutilizable.

Finalmente, a cada paquete se le agregará una cabeceraconteniendo códigos de Comando y SubComando quepermitirán identificar el paquete. La estructura general delpaquete será la indicada en la Fig. 2:

Fig. 2. Estructura general del paquete para descarga de Archivo de

actualización.

Cada paquete de datos que reciba el Equipo será reconocidopor el Equipo con un paquete de ACK, con la estructuramostrada en la Fig. 3. Dentro del paquete ACK vendráindicado el número de secuencia (SEQ) del siguiente paqueteque espera recibir el Equipo. Cuando el número de secuenciadel paquete de ACK se corresponde con el número desecuencia del paquete anterior más uno (SEQ + 1) será esto unaindicación implícita de que el paquete anterior se recibió

correctamente. Por el contrario, si el paquete anterior se recibiócon errores se enviará un paquete ACK con el mismo númerode secuencia del paquete fallido, siendo esto una indicaciónimplícita de que se espera una retransmisión.

Fig. 3. Estructura general de un paquete ACK para descarga de Archivode actualización.

La secuencia normal de funcionamiento, tal como lomuestra la Fig. 4, sería la siguiente: la aplicación “Updater”iniciará el proceso y enviará un Paquete de Inicialización condos fines, primero detectar que el Equipo esté disponible parauna actualización y segundo enviar información acerca deltamaño total del Archivo de actualización que se va a transferiry la cantidad de paquetes que se van a emplear para dicho fin.Este paquete lleva número de secuencia 0.

Fig. 4. Diagrama de secuencia de una transferencia normal de descarga de

Archivo de actualización.

El Equipo responderá que está listo para la transferenciaenviando un ACK con número de secuencia 1, indicando así que espera recibir el Segmento 1 del Archivo de actualización.

La aplicación “Updater” enviará el Segmento 1 y alrecibirlo el Equipo responderá con un ACK con número desecuencia 2. Así sucesivamente se continuará hasta completarel envío del Archivo de actualización completo.

Se deben considerar también condiciones anormales defuncionamiento, como por ejemplo: el Segmento solicitado nose recibe o se recibe con errores. En este caso el Equiporeenviará hasta tres veces el ACK solicitando el reenvío del

paquete solicitado. Si el paquete esperado continúa sin recibirsecomo se espera, el Equipo abortará el proceso. Si el paquete serecibe bien, el proceso continuará normalmente. Del mismomodo, puede que la aplicación “Updater” no reciba nunca elACK esperado o que este llegue erróneo, en este caso laaplicación “Updater” se limitará a esperar por un lapso detiempo determinado la llegada del ACK, y una vez vencido eltiempo de espera será la aplicación “Updater” quien abortará elproceso.

CMD SCMD SEQ SEGMENTO CRC32

CMD SCMD SEQ



143




Como puede verse, el protocolo es simple pero funcional ala aplicación y brinda medios de seguridad y control paralograr una transferencia segura.

C. Solución a los riesgos asociados al proceso de grabación

en memoria FLASH

El proceso de grabación de la nueva imagen de memoria enFLASH es la parte más crítica del sistema de actualización.Cualquier falla en el proceso de grabación dejaría al equipoinutilizado para funcionar.

Ante una falla en el proceso de grabación, debida a casosfortuitos como puede ser un apagado no intencional o un cortede energía, es deseable poder repetir el proceso cuando lascondiciones estén dadas nuevamente. Esto lleva a la necesidadde tener una porción de código que siempre esté funcional yque no forme parte del área de memoria que se actualiza. Aesta porción de código se la llamará “Bootloader”, y será unprograma independiente, que se ubicará en una parte de lamemoria FLASH que nunca se graba o modifica, ver Fig.8. El“Bootloader” será el programa encargado de llevar adelante elproceso de actualización. Entre las funcionalidades del“Bootloader” se tendrán: Recibir y reconstruir el Archivo deactualización, desencriptarlo, verificar la autenticidad delmismo y realizar el proceso de grabación en FLASH del nuevofirmware.

Otro riesgo oportunamente encontrado en el análisis delmodelo, implicaba el caso en que se graba una versión defirmware válida para el sistema, pero incorrecta para el equipo,ya sea porque es antigua o con funcionalidades no soportadaspor ese modelo. Sería interesante aquí, poder volver a laversión de firmware anterior del Equipo, para restituirlo a suestado inicial. En el caso en estudio, debido a que el Equipocuenta con recursos de memoria suficiente, se destinó una parte

libre de la memoria FLASH, para realizar una copia de laimagen del firmware actual, a modo de BackUp, previo agrabar la nueva imagen de memoria. Esto da la posibilidad, encaso que sea necesario, de que el “Bootloader” restituya laimagen de memoria original, retornando al Equipo a su estadoinicial.

En base a estos recaudos, los riesgos asociados al procesode grabación de memoria FLASH quedan mitigados.

D. Solución al requerimiento Nº3 – Restricción de uso del


El requerimiento Nº3 plantea la necesidad de poder

restringir la aplicabilidad del Archivo de actualización a losEquipos. Esto implica que el fabricante tenga la posibilidad dedecidir si un determinado Archivo de actualización puede serutilizado para actualizar cualquier Equipo, un grupodeterminado de ellos o un único Equipo en particular. Lasrazones para esta funcionalidad son varias, pudiendo citarrazones comerciales: Solo el fabricante decide que Equiposserán actualizados y no terceros (distribuidores y serviciotécnico), pudiendo generar versiones “a medida” especiales oexclusivas para un determinado cliente. Razones técnicas: lainstalación temporaria de una aplicación de testeo y puesta apunto del Equipo. Otra razón sería el poder evitar

actualizaciones equivocadas de Equipos, con versiones nosoportadas por determinado modelo, etc.

Aparecen aquí dos problemas. Primero, como identificarunívocamente a un Equipo en particular, y segundo, comolograr la restricción gradual de uso, desde un Archivo deactualización “universal” que aplica a cualquier Equipo, hastauno exclusivo para un Equipo específico.

En el caso en estudio, la única información disponible en elEquipo que lo identifica unívocamente es el número de serie.Este se graba en un área especial de memoria Flash, la cual unavez bloqueada, no puede ser modificada nunca más.

El número de serie consta de cinco bytes, que especifican alEquipo por: Modelo, Año y Mes de fabricación, Lote eidentificador (ID) dentro del lote, información suficiente parasolucionar los problemas planteados al inicio de esta sección.

Se propone emplear una analogía a lo que se hace alenmascarar una dirección IP para formar subredes. Para estecometido, en el Archivo de actualización se incluirá el númerode serie del Equipo destino de la actualización. También seagregará al Archivo de actualización una “Máscara” de cincobytes, en la que cada byte puede tomar el valor 255 (0xFF) ó 0(0x00). El Equipo al recibir el Archivo de actualización,aplicará la Máscara al Número de serie incluido en el Archivode Actualización y también al Número de serie propio, grabadoen FLASH en origen. En este contexto, “aplicar la máscara”implica realizar la operación AND bit a bit entre la máscara yel número de serie. Los resultados obtenidos luego de lasoperaciones de enmascarado serán comparados. Si coinciden,el Archivo de actualización es aplicable a ese Equipo y secontinúa con el proceso de actualización. Caso contrario, elproceso se aborta ya que ese Archivo de actualización no estádestinado al Equipo que se está intentando actualizar.

Número de serie

MODELO AÑO MES LOTE ID

0 0 1 1 1

… … … … …

10 99 12 255 255

Tabla de Máscaras

255 255 255 255 255

255 255 255 255 0

255 255 255 0 0

255 255 0 0 0

255 0 0 0 0

0 0 0 0 0

Fig. 5. Estructura del número de serie del Equipo y tabla de Máscaras de

restricción.

En la Fig. 5 se observan los valores posibles que puedetomar el Número de serie y también la Tabla de Máscarasaplicables al caso en estudio. Dentro de la Tabla de Máscaras,la primera comenzando desde arriba, corresponde al caso másrestrictivo, ya que el número de serie del Equipo y el que vieneen el Archivo de Actualización deben coincidir completamente.La segunda permite actualizar cualquier Equipo de un Modelo,Año, Mes y Lote en particular. La quinta, por ejemplo, permiteactualizar cualquier Equipo de un modelo en particular, y lasexta permite actualizar cualquier Equipo sin restricciones.



144




V. ESTRUCTURA FINAL DEL ARCHIVO DE ACTUALIZACIÓN

En la Fig.6 se observa el ensamblado paso a paso partiendode la imagen de memoria en claro (Firmware) hasta llegar a laestructura final que tendrá el Archivo de actualización, que seenviará al cliente. Al Firmware se le agregará una cabecera dedatos, a ese conjunto se lo rellenará (PAD) para llevarlo a untamaño múltiplo del tamaño de bloque que usa el algoritmo deencriptación TEA. A los Datos encriptados se les agregará el

vector de inicialización. Ese conjunto es el que recibirá elEquipo a través del enlace RS232C. A dicho conjuntofinalmente, se le agregará una cabecera de Información y elSHA-1 para comprobación de integridad, datos que seránextraídos y utilizados por la aplicación “Updater” al momentode recibir el Archivo de actualización.

Fig. 6. Estructura final del Archivo de actualización. Ensamble de partes.

VI. REESTRUCTURACIÓN DEL MAPA DE MEMORIA DEL

EQUIPO

Inicialmente el Equipo dispone de una distribución básicade la memoria. Toda la memoria FLASH está destinada alFirmware. Lo mismo ocurre con la memoria RAM.

El sistema de actualización necesita de una nuevadistribución de memoria, como puede verse en la Fig. 7.

Se observa que luego de la restructuración la memoriaFLASH queda dividida en 4 aéreas separadas. Cada unacumple una misión diferente.

El BOOT SWITCHER es el punto de arranque del sistema,

ya que aquí apunta el vector de RESET. En este área habrá unapequeña porción de código encargado de inicializar el sistema(configurar vectores de interrupción y excepciones, arranque dereloj, etc.) y de detectar la condición de trigger, para determinarel modo de arranque del Equipo, esto es, en modo Normal o enmodo Actualización. La condición de trigger se configura porhardware, mediante un Dip-Switch, que es la forma más simpley segura para ello.

Fig. 7. Reestructuración del mapa de memoria del Equipo, para satisfacernecesidades del sistema.

Si se detecta un arranque en modo Actualización, el controldel sistema se pasa al Bootloader, mediante un salto a ladirección de inicio del mismo. El Bootloader es la aplicaciónencargada de controlar y llevar adelante el proceso de

actualización. El Bootloader es una aplicación independienteque implementa el protocolo antes descripto y se comunica conla aplicación “Updater” vía enlace RS232C.

Si se detecta un arranque en modo Normal, el control delsistema se pasa al Firmware, que es la aplicación que realiza lafuncionalidad normal para la que fue diseñado el Equipo.

VII. FUNCIONAMIENTO DEL PROCESO DE ACTUALIZACIÓN

DENTRO DEL EQUIPO.

Básicamente el proceso de actualización conlleva los pasosque se describen a continuación:

Una vez que el Equipo se inició en modo Actualización y elBootloader tomó control del sistema, se procede a recibir elArchivo de actualización, segmento a segmento, los cuales sevan depositando en el Buffer Temporal en RAM (ver Fig. 8),para ir reconstruyendo el Archivo de actualización.

Cuando el Archivo de actualización se recibió porcompleto, se procede a procesarlo. Esto implica desencriptarlo,verificar el Magic Number para autenticar el Archivo deactualización, controlar la Restricción de uso en base a Númerode serie y Máscara y finalmente chequear el CRC32 general del

Firmware

8 8 4 4 8

Serial Máscara Size CRC Magic # Firmware

Firmware + Cabecera de datos PAD

Datos encriptados8

IV Datos Encriptados

Conjunto de datos que recibirá el Equipo

20

Info Conjunto de datos que recibirá el Equipo SHA-1




145




firmware recibido. Si todos estos pasos se verificancorrectamente, se puede continuar con el proceso. Casocontrario el proceso se aborta y se vuelve a la condición dedesocupado.

Recibido el nuevo Firmware, se procede a realizar un Back-Up del firmware actual en memoria FLASH, en el Área deBack-Up (ver Fig. 8), para permitir en caso de ser necesario,restaurar el sistema a su estado inicial.

Completado el proceso de Back-Up, se procede a grabar elnuevo firmware en el Área de FLASH destinado al arranqueNormal del Equipo.

Finalizado ese proceso, el Equipo queda listo para serencendido en modo Normal y correr la versión actualizada deFirmware.

VIII. CONCLUSIONES

Se planteó como eje central para este trabajo laactualización del firmware de un sistema embebido. Al caso

general se le aplicaron las restricciones y necesidades propiasde un caso real particular.

Se propusieron una serie de pasos lógicos para enfrentar elcaso, como son, iniciar con un relevamiento y estudio derequerimientos, en base a los cuales se planteó un modelo parala solución del problema. Una vez verificada la validez delmodelo, se procedió a analizar los riesgos emergentes delmodelo que pudieran malograr el proceso. Una vez detectadoslos riesgos se procedió a plantear soluciones a los mismos deforma de eliminarlos o mitigarlos. Con toda esa información,se dió paso al diseño del sistema y planteamiento final de lasolución. Esa serie de pasos lógicos posibilitaron un diseñosólido y aseguraron que al momento de la implementación no

se debieran pagar costos innecesarios debidos a problemas noconsiderados tempranamente.

Se tuvieron en cuenta para el presente trabajo conceptosbásicos de seguridad de la información, buscándose elequilibrio entre el costo de implementarlos y el costo queenfrentaría un atacante real al sistema.

Se planteó un modelo de protocolo de comunicacionessimple, pero eficiente y seguro para el caso real propuesto.

Finalmente, se propuso una forma de implementar yestructurar las distintas áreas de memoria y la forma en quedebería llevarse adelante la actualización, incluyéndose laposibilidad de restaurar el estado anterior del Equipo, en caso

de ser necesario.Como cosas pendientes, que escapan a la extensión y

profundidad de este trabajo, quedarían el diseño de lasaplicaciones de PC, auxiliares al sistema.

IX. REFERENCIAS

[1] Wheeler, David J.; Needham, Roger M. (1994-12-16). “TEA, a

tiny encryption algorithm” Lecture Notes in Computer Science

(Leuven, Belgium: Fast Software Encryption: Second

International Workshop) 1008: 363–366 .[2] Kelsey, John; Schneier, Bruce; Wagner, David (1997). " Related-

key cryptanalysis of 3-WAY, Biham-DES, CAST, DES-XNewDES, RC2, and TEA". Lecture Notes in Computer Science

1334: 233–246. [3] NIST Special Publication 800-38. “Recommendation forBlockCipher Modes of Operation - Methods and Techniques”2001 Edition

X. BIBLIOGRAFÍA

- Sloss, Andrew; Symes Dominic; Wright, Chris (2004).“ARM System Developer’s Guide – Designing andOptimizing System Software” ISBN: 1-55860-874-5

- SPANSION - FlashOverview_AN_A0 (November 10, 2005)– “Flash Memory: An Overview”

- Tanenbaum, Andrew S. (1997) “Computer Networks” ISBN:968-880-958-6

- A. Menezes, P.; van Oorschot, and S. Vanstone, (1996)

“Handbook of Applied Cryptography” CRC Press.- Williams, Ross N. (1993) “A Painless Guide to CRC ErrorDetection Algorithms”

- W. Richard Stevens, (1993) “TCP/IP Illustrated, TheProtocols”



146




Actualización parcial de software embebido entiempo de ejecución en sistemas sin RTOS

Santiago Martínez, Matías Bakalián, Leonardo Steinfeld, Francisco LanzariInstituto de Ingeniería EléctricaFacultad de Ingeniería, UdelaR

Montevideo, [email protected], [email protected], [email protected], [email protected]

Resumen —La actualización de software embebido permite alterar

o modificar la funcionalidad de un sistema. En algunos casos

puede llegar a ser un procedimiento engorroso si el equipo es de

difícil acceso o con un alto costo operativo si se trata de gran

cantidad de dispositivos. En este contexto, la opción de realizarlo

de manera remota mediante comunicación inalámbrica resultauna alternativa muy atractiva. Además puede ser importante

minimizar el volumen de información a transmitir para

disminuir la energía de reprogramación. Siguiendo esta línea se

han propuesto mecanismos para realizar una programación

parcial. En el presente trabajo, a partir de la observación de que

en muchos de estos sistemas el código correspondiente a la

aplicación es sensiblemente menor en tamaño que las bibliotecas

utilizadas, se propone un mecanismo para realizar la

actualización de la aplicación manteniendo las bibiliotecas.

Esta solución simple logra una implementación que reduce el

costo de reprogramación, ocupa poca cantidad de memoria y

tiene despreciable overhead de ejecución. Además sirve como

primer acercamiento a alternativas de programación parcial máscomplejas.

Palabras Clave; reprogramación; comunicación inalámbrica ;

software embebido

I. I NTRODUCCIÓN

En el contexto de los sistemas embebidos, con frecuenciaes necesario y/o deseable actualizar cierta sección de código,

por ejemplo para la corrección de bugs o modificación dealgoritmos (por ejemplo: encriptación de datos, codificación odecodificación, etc). También puede desearse modificar solamente la aplicación manteniendo los servicios que

bibliotecas existentes ya proveen. Debido a esto, sería deseable

y de gran aplicabilidad poseer una herramienta para laactualización parcial de código sin necesidad de reprogramar completamente el sistema.

Se han propuesto e implementado varios mecanismos paramodificar el código dentro de un sistema embebido. La técnicamás adecuada a cada caso depende de las funcionalidadesrequeridas y también de las limitaciones en términos derecursos, ya sean de potencia de cómputo, memoria o inclusoenergía en casos de sistemas portátiles alimentados a pilas.

La primera opción, trivial, para actualizar el software es lareprogramación total del código, donde una nueva imagen

binaria del software remplaza el programa antiguo, por ejemplovía JTAG o BSL (Bootstrap Loader). Éste es el mecanismomás sencillo y ampliamente utilizado, normalmente no serealiza en campo y es llevado a cabo por un usuario utilizandoun PC.

Cuando se cuenta con una cantidad importante de equiposinstalados, el método anterior tiene un alto costo y es de difícilimplementación logística. Entonces resulta atractivo realizar lareprogramación en campo, transmitiendo el nuevo código alequipo que necesita su actualización de manera inalámbrica.En diversas ocasiones, solamente es necesario realizar

pequeñas modificaciones al código, como en la corrección de bugs, por lo que el código binario final sólo sufre pequeñasmodificaciones. En estos casos es posible, en lugar de realizar un reemplazo total de la imagen del programa, cargar tan sololas diferencias entre el binario original y el modificado. Estatécnica está motivada por la necesidad de minimizar el costoenergético de la reprogramación y tiene sentido en sistemasdonde el costo asociado a la transmisión es varios órdenes demagnitud mayor al costo de procesamiento. De esta manera seminimiza el volumen de datos transferidos al sistema embebidoa costas de un incremento en el procesado local para laobtención de la imagen combinada [1]. Otra alternativa es usar sistemas con máquinas virtuales, ya que por más que se

programe totalmente el sistema, el código interpretado o bytecode generalmente es sensiblemente menor que el códigodirectamente ejecutable[2].

Una alternativa a los mecanismos mencionadosanteriormente es la utilización de módulos cargables ensistemas que cuentan con un kernel o sistemas operativosdiseñados especialmente para contemplar esta funcionalidad.Algunos ejemplos son Contiki [3] y SOS [4], ambos de código

abierto. Cuando un nuevo módulo es cargado, esto es, seincorpora a un sistema ya corriendo, contiene referencias avariables y funciones externas al propio módulo. Estas puedenser resueltas en tiempo de compilación en el host, procesollamado pre-enlazado, o en el propio sistema embebido entiempo de ejecución, llamado enlazado dinámico. Los módulosdinámicamente enlazados contienen referencias sin resolver,mientras que en los módulos pre-enlazados éstas ya fueronsustituidas por direcciones físicas absolutas. En el primer caso,la utilización de tablas es una técnica comúnmente utilizada

para la resolución de etiquetas, donde el proceso de enlazado escompletado en el sistema embebido a través de tablas donde los



147




nombres simbólicos se traducen en direcciones absolutas. Elsistema operativo SenSpireOS [5] contempla la funcionalidadde enlazado dinámico de módulos SELF (basados en elformato estándar ELF) mediante una tabla de direcciones, conla finalidad de realizar la reprogramación parcial de los nodosde una red de sensores inalámbricos. [6]

La utilización de kernels o sistemas operativos con estasfuncionalidades normalmente trae aparejado un incremento

significativo en la complejidad del software embebido, unincremento en el total de código y un overhead de tiempo deejecución asociado a la búsqueda en tablas [1].

El presente trabajo plantea dar una solución simple al problema de la programación parcial remota en arquitecturasde software donde no se cuenta con un kernel confuncionalidades especiales donde se realiza la actualización dela aplicación manteniendo las bibliotecas. El objetivo esminimizar el costo de reprogramación a través de unaimplementación con baja cantidad de memoria y despreciableoverhead, y que sirva como primer acercamiento a alternativasmás complejas.

II. PROPUESTA

En base a las consideraciones realizadas, se propone el usode módulos pre-enlazados para permitir, en tiempo deejecución, la modificación parcial del software del sistema. Elobjetivo es actualizar la aplicación manteniendo las bibliotecasutilizadas por la misma. Para ello es necesario que el sistema aactualizar reciba a través de una interfaz de comunicación elcódigo binario de la nueva aplicación, guardar el mismo en lamemoria, típicamente no-volátil (FLASH), para finalmentecomenzar a ejecutar la nueva versión. Para la generación dedicho código binario es necesario contar con herramientasadecuadas.

Es conveniente aclarar que debe tenerse en consideración el

contenido existente en la memoria del sistema que se encuentraya instalado en campo. Una opción sería diseñar un esquema,de cierta complejidad, que a partir de los archivos ejecutablesdel sistema existente y de la nueva aplicación, identifique yextraiga la porción de ejecutable a actualizar. Esto podríarealizarse mediante la edición de los archivos ELF (Executableand Linkable Format) asociados. Sin embargo se optó por unasolución más sencilla mediante la utilización de opcionesavanzadas del linker . La idea es usar una tabla dedireccionamiento indirecto, al igual que en solucionesanteriormente mencionadas, para permitir hacer uso de las bibliotecas sin necesidad de disponer de ellas al momento decompilar y enlazar la nueva aplicación. Para permitir laactualización de la aplicación sin sobrescribir las bibliotecas, esnecesario organizar las memorias de manera de poder guardar en áreas diferentes aplicación y bibliotecas. Esta solución, adiferencia de la edición de los archivos ELF, requierereprogramar la aplicación en forma completa. En principio puede considerarse un costo aceptable debido a la sencillez delmétodo en comparación con otros, más si se considera que eltamaño de la aplicación, en general, es mucho menor que eltamaño de las bibliotecas.

A. Tabla de direccionamiento indirecto

Durante el desarrollo de una nueva aplicación basada en bibliotecas, ya sea para corregir bugs o cambiar completamente

la funcionalidad, es necesario que el linker resuelva lasllamadas desde la aplicación a funciones y los accesos avariables de dichas bibliotecas precargadas en el sistema.

Para realizar lo anterior se utilizó una tabla dedireccionamiento indirecto, con el fin de realizar la interacciónentre las bibliotecas y la aplicación.

Como paso inicial, compilan las bibliotecas junto con una

aplicación de inicialización y con la tabla con el fin de cargar en la misma las direcciones donde se encuentran alojadas lasfunciones públicas pertenecientes a las bibliotecas. De estemodo, la llamada a una función de las bibliotecas desde unanueva aplicación puede realizarse mediante una llamada a ladirección de memoria almacenada en el lugar correspondientede la tabla, permitiendo el acceso a la función en formaindirecta.

En la figura 1 se muestra el mapa de memoria en el primer paso cuando las bibliotecas y la tabla han sido cargadas enmemoria. Luego se muestra el mapa de memoria resultantedespués de la actualización, donde se puede apreciar el flujo deinvocación para una función desde la aplicación hasta la biblioteca correspondiente.

En principio se podría asumir que es posible crear el nuevosoftware y simplemente enviar al sistema la porción de códigorelativa a la aplicación. Sin embargo, nada garantiza que ellocator ubique las funciones de las bibliotecas en las mismasdirecciones de memoria que lo hizo anteriormente y enconsecuencia las llamadas desde la aplicación a las funcionesse realizarían a una dirección de memoria diferente a dondeestas se encuentran. Mediante el uso de la tabla, es decir, lanueva aplicación realizando las llamadas a la biblioteca através de ésta, se evitan este tipo de inconvenientes ya que lamisma contiene siempre las direcciones reales donde lasfunciones se encuentran alojadas.

Otro beneficio de la utilización de la tabla es que no es

necesario disponer de las bibliotecas a la hora de generar lanueva aplicación.

Figura 1. Mapeo en memoria: (A) primer paso: bibliotecas y

tabla cargadas en memoria, (B): nueva aplicación y

flujo de invocación para una función.



148




B. Organización de las memorias

Para que sea posible sustituir la aplicación y a la vez dejar inalteradas las bibliotecas existentes en la memoria del sistema,es necesario conservar código, constantes y variables de lasfunciones pre-cargadas. Por ello éstas últimas deben estar separadas en memoria del resto, para así tener la seguridad deque no sean sobrescritas. Para conseguirlo, una opción deorganización es disponer de regiones disjuntas en las distintas

memorias (FLASH y RAM) para las bibliotecas, la aplicación presente y la nueva aplicación. En este esquema se lograguardar completamente la nueva aplicación sin sobrescribir laaplicación actual antes de conmutarlas. También es posiblesobrescribir la aplicación corriente con la nueva, ya que todaslas rutinas necesarias para realizar la conmutación (recepción yescritura en memoria) residirían en la región destinadas a las

bibliotecas. El código, las constantes y los valores deinicialización residen en FLASH mientras que las variablesresiden en RAM, por lo que la organización de la memoriadebe contemplar ambas. En la Figura 2 se muestra un posiblemapeo de memorias, en donde se distinguen los segmentos“Tabla” y “Aplicación” en FLASH y en RAM los segmentos“Aplicación”, ”Tabla” y “código para escritura en FLASH”

Figura 2. Mapa de memoria RAM y FLASH con los segmentosinvolucrados

C. Recepción de datos y puesta en marcha de la nueva

aplicación

Tal como fuera dicho anteriormente, en el proceso deactualización, primero debe establecerse una comunicaciónentre el sistema embebido (mediante una interfaz decomunicación) y el sistema que posea el código de la nuevaaplicación ya compilada. Este sistema puede ser, en principio,de muy diversos tipos, tanto un PC como otro sistemaembebido.

Posteriormente, los datos correspondientes a la nuevaaplicación son recibidos por el sistema embebido yalmacenados en memoria volátil, para luego ser grabados en

memoria persistente para finalmente poder ser ejecutados. Elgrabado en memoria persistente puede sobrescribir el códigoanterior, minimizando así la cantidad de memoria requerida, o

puede ser alojado en un lugar diferente, pudiendo retornar a laaplicación anterior en caso de problemas tanto con el grabadocomo en el funcionamiento de la nueva aplicación.

Finalmente, antes de que la nueva aplicación puedaejecutarse, es necesario llevar al sistema a un estado inicial, de

modo de asegurar el buen funcionamiento de los servicios delsistema embebido y de las bibliotecas (configuración de

periféricos, reinicialización de variables de las bibliotecas,inicialización de variables de la aplicación, etc.).

III. ESTUDIO DE CASO

Para verificar la metodología propuesta se utilizó el kit dedesarrollo ez430-RF2500 [7], compuesto por dos dispositivosque cuentan con un microcontrolador MSP430F2274 y untransmisor/receptor de radio CC2500, permitiendo establecer una comunicación punto a punto entre ellos. Para el desarrollode las aplicaciones, se cuenta con bibliotecas provistas por elfabricante, en particular con un stack de comunicación,

SimpliciTI [8], que proporciona un protocolo de comunicaciónsimple que permite cumplir con el objetivo. Se utilizó elentorno de desarrollo IAR Embedded Workbench 6.0 [9],aunque también soporta el Code Composer Studio [10]. De lasdiferentes aplicaciones ejemplos provistas se eligió "Simple peer to peer" , en la cual se configuran dos dispositivos, uno para enviar y el otro para recibir mensajes a través de la radio.Inicialmente se estudió el código del stack para determinar lasfunciones públicas utilizadas por la aplicación, siendo éstas lasque necesariamente deberán ser incluidas en la tabla dedireccionamiento indirecto.

IV. IMPLEMENTACIÓN

A continuación se describen algunas consideracionesimportantes a la hora de la instrumentación de la propuesta, enespecial, las relativas a la implementación particular a este casode estudio y del conjunto de herramientas (compilador, linker ,etc.) utilizado.

A. Primeras consideraciones

Al momento de guardar la nueva aplicación en memoria novolátil, puede ser necesario realizar un borrado total elsegmento involucrado. Esto depende de las limitaciones que

presente el microcontrolador utilizado a la hora de escribir eneste tipo de memorias. Por ejemplo, en algunosmicrocontroladores se permite el borrado de bits pero nosetearlos. En este caso, para poder guardar la nueva aplicación,

es necesario inicializar el segmento guardando en todos sus bytes el valor 0xFF.

Hay casos en los cuales la rutina encargada de escribir enFLASH debe ejecutarse desde RAM. Para esto existen dosalternativas, guardar dicha rutina en RAM, o crear una copia enRAM justo antes de utilizarla. En ambos casos será necesariauna rutina auxiliar que se encargue de alojarla en RAM. Lasegunda opción es interesante cuando el sistema cuenta conmuy poca RAM y se desea optimizar su utilización, perogenera overhead a la hora de requerirla (al actualizar). Semencionaron dos alternativas a la hora de guardar la nuevaaplicación en memoria. Para el caso en el que la nueva



149




// FLASH

-Z(CONST)DATA16_C,DATA16_ID,DIFUNCT, CHECKSUM=8000-80B5-Z(CODE)CSTART,ISR_CODE=8086-80B5-P(CODE)CODE=80B6-9BF5-P(CODE)SEG_MAIN_FLASH=9BF6-BFFF

// RAM

-Z(DATA)DATA16_I,DATA16_Z,DATA16_N, DATA16_HEAP +_DATA16_HEAP_SIZE=0200-047F-Z(DATA)CODE_I-Z(DATA)CSTACK+_STACK_SIZE#-Z(DATA)SEG_MAIN_RAM=04F0-05FF

__no_init ptr_BSP_Init* pBSP_Init @ "SEG_MAIN_RAM"; __no_init ptr_SMPL_Init* pSMPL_Init @ "SEG_MAIN_RAM";

void BSP_Init(void ) @ "SEG_MAIN_FLASH" pBSP_Init = (ptr_BSP_Init*) 0xFFC0;(*pBSP_Init)();

smplStatus_t SMPL_Init_(funptr f)@ "SEG_MAIN_FLASH"

pSMPL_Init = (ptr_SMPL_Init*) 0xFFC2;return (*pSMPL_Init)(f);

void BSP_Init(void );

smplStatus_t SMPL_Init(funptr);// siguen más prototipos

typedef uint8_t (*funptr)(linkID_t);typedef void (*ptr_BSP_Init)(void );typedef smplStatus_t (*ptr_SMPL_Init)(funptr);typedef struct dirfunctions

ptr_BSP_Init_ d1;ptr_SMPL_Init_ d2;// siguen más miembros

dirfunctions;

__no_init dirfunctions dfunctions @ 0xFFC0; void table_init(void )

dfunctions.d1 = BSP_Init;dfunctions.d2 = SMPL_Init;// siguen más miembros

aplicación sobrescribe a la anterior, es necesario que la rutinade actualización conserve el control del sistema hasta que lanueva aplicación esté completamente cargada en memoria y sehaya llevado el sistema al estado inicial, para finalmente ceder el control a la nueva aplicación. El otro caso presenta másflexibilidad, en el sentido de que la actualización podríarealizarse en varios pasos y la aplicación original podría seguir ejecutándose durante la misma, esto si se puede asegurar el

correcto funcionamiento de la aplicación.Una vez cargada la nueva aplicación en memoria, como se

mencionó anteriormente, es necesario inicializar el sistema. Lainicialización asociada a la configuración de periféricos,dispositivos conectados al microcontrolador (como por ejemplola radio) que es realizada a través de llamadas a funciones, no presenta problemas. Sin embargo durante el start-up, antes deejecutar la primera línea del “main”, se asigna el valor inicial alas variables estáticas inicializadas (segmento data) y seresetean aquellas no inicializadas (segmento bss). Este paso puede realizarse de manera transparente para el usuario,agregando el código de start-up de la aplicación al realizar laactualización, y también el de las bibliotecas precargadas, o enforma manual, agregando explícitamente al inicio del código

de aplicación el llamado a las funciones correspondientes paracopiar los valores iniciales desde memoria no volátil a RAM para el caso de variables inicializadas y para el borrado, paralas variables no inicializadas.

B. Tabla de direccionamiento indirecto

Una vez reconocidas las funciones del stack utilizadas por la aplicación, se generó la estructura de la tabla en un lugar adecuado de memoria y se almacenaron los punteros a lasfunciones. También fue necesario definir los tipos punteros adichas funciones.

En el archivo de encabezado, tabla.h, se definen los tipos autilizar, los punteros y la estructura de la tabla. En el archivo

tabla.c se define la tabla, donde se especifica explícitamente suubicación en memoria y la función de inicialización. En lasFiguras 3 y 4 se muestra una sección de cada archivo, donde se puede apreciar el código relativo a dos funciones de las bibliotecas: BSP_Init() y SMLP_Init(linkID_t).

Figura 3. Archivos encabezado tabla.h.

Figura 4. Archivo tabla.c

De esta manera, se crea una tabla en la dirección 0xFFC0 yal ejecutarse la función table_init() quedan guardadas en lamisma las direcciones donde se encuentran las funciones.

Para usar los servicios de las bibliotecas, la nuevaaplicación es compilada utilizando un archivo de encabezadodonde se declaran todas las funciones públicas de las bibliotecas y un archivo donde se definen dichas funciones demanera de acceder al código respectivo a través de la tabla, talcomo se muestra en las Figuras 5 y 6.

Figura 5. Archivos de encabezado con todas las funciones

publicas de las bibliotecas.

Figura 6. Archivo con las definiciones de las funciones.

Se puede observar el "cast" al tipo puntero correspondiente y lautilización de segmentos de memoria creados específicamente

para la aplicación, con el fin de independizar en memoria elcódigo perteneciente a la aplicación del perteneciente al stack

de comunicación.Para lograr ubicar los diferentes segmentos según la

organización de memoria elegida se utilizan opcionesespecíficas del linker [11]. Ello es posible modificando unarchivo de configuración que el linker utiliza. En IAR, este puede encontrarse dentro de las propiedades del proyecto. El

fragmento modificado del mismo se muestra en la Figura 7,donde se puede apreciar los rangos de direcciones asignadas acada área.

Figura 7. Definición de segmentos.

Una vez creados los segmentos deseados desaparecen los problemas asociados a la sobrescritura de datos y se tienecampo fértil para intentar recibir una nueva aplicación. Larecepción de la nueva aplicación se realiza a través de laUART del microcontrolador.

C. Escritura en FLASH de la nueva aplicación

Para escribir la nueva aplicación en memoria FLASH,debido al microcontrolador utilizado, fue necesario utilizar una



150




rutina que resida en RAM. Esta rutina de escritura,FlashWrite(), debe tener en cuenta consideraciones respecto ala cantidad de datos a escribir para no dañar la memoria.FlashWrite() es cargada en FLASH junto con las bibliotecas, por lo tanto es necesaria la existencia de otra rutina,CopyRoutine(), encargada de crear una copia de la misma enRAM para su ejecución. Las rutinas mencionadasanteriormente, específicas para el microcontrolador MSP430,

forman parte de los códigos ejemplo suministrados por TexasInstruments [12]. Debido a la escasa memoria RAM que presenta el microcontrolador utilizado (1 kB), el hecho de tener que copiar FlashWrite() a RAM hace que el espacio disponible para recibir la nueva aplicación se reduzca a unos 150 bytesaproximadamente. Por lo tanto, en caso de que la misma superedicho límite, deberá ser enviada de a fragmentos. En este caso,como fue comentado, puede resultar necesario pasarle elcontrol a otra rutina, que espere hasta que se termine dichatransferencia para evitar problemas de datos corruptos.

V. R ESULTADOS

El sistema se fue probando y verificando con cada paso dela implementación. La metodología fue básicamente la misma

para todos los casos, “debbugear” la aplicación, prestandoatención al flujo del programa y los cambios producidos en lamemoria y registros del microcontrolador.

La primer prueba consistió en verificar en memoria que latabla se generaba correctamente, es decir, que se encontrara enla ubicación correcta y se guardaran en ella las direccionesdonde efectivamente se encontraban las funciones en cuestión.Para esto se tuvieron que superar varios inconvenientes, comola ubicación en memoria y la inicialización de estructuras "a posteriori", con el uso de directivas como “@” y "__no_init"respectivamente para este compilador.

Luego de esto se probó la técnica de direccionamientoindirecto propuesta. Para esto se cargó en memoria el código

perteneciente al stack de comunicación y se generó la tabla, seconfiguraron opciones de la plataforma de desarrollo para quese mantenga la información en la memoria y se cargó laaplicación utilizando el direccionamiento indirecto. Es decir, secompiló únicamente la aplicación con los archivos dedireccionamiento indirecto y se cargó en memoria. Ejecutando paso a paso la aplicación se verificó que las llamadas a lasfunciones efectivamente pasaban por la tabla, llamandocorrectamente a las funciones que debía, como era esperado.

La rutina de recepción de datos se probó enviando datoshacia la UART del sistema, utilizando para la comunicación el programa Hércules (freeware) [13]. Se verificó la llamada a larutina de atención a la interrupción de la UART y la correctarecepción de los datos enviados, almacenados en RAM.

Respecto a la escritura en FLASH, se verificó el correctofuncionamiento de las funciones CopyRoutine() y FlashWrite()mencionadas anteriormente. Para el caso de CopyRoutine(), seobservó la memoria ocupada por FlashWrite() y se comparó byte a byte con lo que se había copiado en RAM, verificandoque no hubieran errores. Para FlashWrite(), se optó por mover a FLASH un arreglo conocido hacia una zona no inicializadade memoria y se constató su correcto funcionamiento.

Para la prueba del sistema completo se compiló y cargó elstack junto con una primera aplicación y la tabla en dos

dispositivos, un receptor y un transmisor. La informacióncorrespondiente a la salida del linker se presenta en la figura 8.Luego se compiló una nueva aplicación junto con los archivosde acceso indirecto y se cargó en el transmisor, como seobserva en la figura 9. Se constató el correcto funcionamientodel sistema con la nueva aplicación según los cambios defuncionalidad introducidos.

Figura 8. Disposición de segmentos en memoria y tamaño decódigo, caso directo.

Figura 9. Disposición de segmentos en memoria y tamaño decódigo, caso indirecto.



151




Se observó que el código de la aplicación corresponde al8% (576 bytes de código más 236 bytes de datos) del total de laaplicación incluyendo las bibliotecas (como se observa en elresumen de memoria de la Figura 9). En tiempo de ejecución,cuando se realiza una llamada a una función, se posee unoverhead de ejecución de 2 instrucciones “jump” respecto alcaso original. A continuación, en la Tabla 1, se presentan paradiferentes aplicaciones ejemplo incluidas en el stack

SimplicitTI: el tamaño total de la aplicación incluyendo las bibliotecas, la cantidad de bytes a transmitir correspondiente ala aplicación y finalmente el porcentaje que representa laaplicación respecto al total. Estas valores fueron obtenidos a partir del análisis del mapa de memoria al crear las distintasaplicaciones y sumando el espacio de memoria requerido por latabla de direccionamiento indirecto. Puede observarse que laaplicación más el overhead asociado a la técnica representaentre el 3% y el 7% del total del software embebido deaplicaciones últimas analizadas, siendo la aplicación “Simple peer to peer”, implementada y probada, la que resulta en elmayor peso relativo, 8%. Esto significaría un ahorroenergético en costo de reprogramación de más de 90% en todoslos casos en comparación con la reprogramación total.

Aplicación Cantidad de bytes totales

Cantidad de bytes a retransmitir

Porcentaje deretransmisión

Polling whit Acces Point

(Sender)

7548 544 7.2%


(Receiver)

7756 544 7.0%


(Acces Point)

6794 260 3.8%

Cascading end Devices 6924 399 5.8%

Acces Point as Data

Hub(End Device)

8767 409 4.7%

Acces Point as Data

Hub(Acces Point)

9885 705 6.1%

Acces Point as DataHub(Chanel Sniffer)

6897 384 5.6%

Acces Point as Data

Hub(Range Extender)

6854 216 3.2%

Tabla 1. Tamaño relativo de diferentes aplicaciones incluidas en SimpliciTI.

VI. CONCLUSIONES

Se propuso una solución simple al problema de lareprogramación parcial que permite la actualización de la

aplicación de manera remota utilizando comunicacióninalámbrica. Se logró una implementación que ocupa pocacantidad de memoria y tiene despreciable overhead deejecución.

Se diseñó e implementó un sistema basado en lametodología propuesta, pudiendo verificar la confiabilidad dela misma.

Se han contrastado los resultados obtenidos contra los delsistema sin direccionamiento indirecto obteniéndose para estecaso particular un costo en memoria del 8% del total de espacioocupado por el código original. Es decir que para realizar laactualización sólo es necesario transmitir el 8% del código que

se debería transmitir si se cargaran nuevamente las bibliotecas junto con la aplicación.

Se ha estimado para otras implementaciones un costo deretransmisión que oscila entre el 3% y 7% del código totalembebido.

R EFERENCIAS

[1] Dunkels, A., Finne, N., Eriksson, J., and Voigt, T. 2006. Run-timedynamic linking for reprogramming wireless sensor networks. InProceedings of the 4th international Conference on Embedded Networked Sensor Systems (Boulder, Colorado, USA, October 31 - November 03, 2006). SenSys '06. ACM, New York, NY, 15-28.

[2] Nanthanavoot P. and Chongstitvatana, P., "Code-Size Reduction for

Embedded Systems using Bytecode Translation Unit", Conf. of Electrical/Electronics, Computer, Telecommunications, and InformationTechnology (ECTI), Thailand, 13-14 May 2004.

[3] A. Dunkels, B. Grönvall, and T. Voigt. Contiki—a Lightweight andFlexible Operating System for Tiny Networked Sensors. In EmNets,Tampa, Florida, USA, November 2004.

[4] C.-C. Han, R. Kumar, R. Shea, E. Kohler, and M. Srivastava. ADynamic Operating System for Sensor Nodes. In ACM MobiSys,Seattle, Washington, USA, June 2005.

[5] W. Dong, C Chen, X Liu, J Bu, Y Liu, K Zheng. “SenSpire OS: APredictable, Flexible, and Efficient OS for Wireless Sensor Networks.”,2007.

[6] W. Dong, C. Chen, X. Liu, J. Bu, and Y. Liu, “Dynamic Linking andLoading in Networked Embedded Systems.” in Proceedings of IEEE MASS , 2009

[7] Texas Instruments, MSP430 Wireless Development Tool, EZ430-RF2500, disponible: http://focus.ti.com/docs/toolsw/folders/print/ez430-rf2500.html; consulta: octubre de 2010.

[8] Texas Instruments; SimpliciTI Compliant Protocol Stack, disponiblehttp://focus.ti.com/docs/toolsw/folders/print/simpliciti.html; consulta:octubre de 2010.

[9] IAR Systems, IAR Embedded Workbench 6.0; disponible:http://www.iar.com/; consulta: octubre de 2010.

[10] Texas Instruments, Code Composer Studio (CCStudio) IntegratedDevelopment Environment (IDE) v4.x; disponible:http://focus.ti.com/docs/toolsw/folders/print/ccstudio.html; consulta:octubre de 2010.

[11] IAR Systems, IAR Linker and Library Reference Guide. disponible:http://ftp.iar.se/WWWfiles/guides/xlink.pdf ; consulta: octubre de 2010.

[12] Texas Instruments, MSP430 16-bit Microcontroller Code Examples andFunction Library; disponible: http://www.ti.com/lit/zip/slac123;consulta: octubre de 2010.

[13] HW Group, Hercules Utilities; disponible: http://www.hw-group.com/products/hercules/index_es.html; consulta: ocutubre de 2010.



152




Muestreo y Adquisición Inteligente de SeñalesSensoriales en Sistemas Embebidos

Gustavo Monte, Kector Kessel, Norberto Scarone, Cesar Almendra

Universidad Tecnológica Nacional - Facultad Regional del Neuquén – Plaza Huincul - [email protected]

Resumen- Hoy en día es muy común encontrar el prefijointeligente en los sistemas que el hombre desarrolla.Encontramos desde fusibles inteligentes hasta autopistasinteligentes. La razón de esta “inteligencia” es que dada lacomplejidad de los sistemas actuales, los diseñadores la hantrasladado a los dispositivos con el objetivo de simplificar laoperación al usuario final. Un ejemplo típico es la filosofía Plugand Play. Aprovechando la capacidad actual de los sistemasembebidos, este trabajo presenta técnicas y algoritmos con elobjetivo de sumar inteligencia al proceso de muestreo de unaseñal analógica. Empleando técnicas de sobremuestreo einterpolación adaptiva se logra analizar la señal, inferir estados,predecir comportamientos y validar la señal digitalizada. Laseñal a digitalizar es un proceso aleatorio, lo único que se conocede antemano es su limitación en ancho de banda que le impidetomar valores totalmente arbitrarios entre muestras. Alaumentar la frecuencia de muestreo se restringe la aleatoriedadhasta quedar reducida a un espacio de escasas dimensiones quepermite realizar un análisis certero sobre la señal. Se presentanresultados experimentales desarrollados en microcontroladorespara validar los algoritmos propuestos.

Palabras Clave Sensores Inteligentes, sobremuestreo,muestreo inteligente.

I. I NTRODUCCIÓN

Los sistemas embebidos realizan sus decisiones en base alas señales de los sensores incluidos en él. Las señales provenientes de los sensores es la fuente de informacióndisponible para cumplir el objetivo de diseño de un sistemade instrumentación y/o control. Estas señales proporcionanla abstracción del mundo real. Una señal es una entidadcuantificable de alguna forma de información. Más valiosa esla señal cuanto más información se encuentra embebida enella. El concepto clave es la “información” que recibe el

sistema. La Fig. 1 representa este concepto en forma gráfica.Esta información se encuentra inmersa en la señal, por lotanto generalmente es necesario procesarla.

Aún en señales analógicas, no es necesario conocer el valor de la señal todo el tiempo. La máxima velocidad de cambiode una señal determina el intervalo de tiempo mínimo que senecesita conocer a la señal para poder inferir sucomportamiento dentro él.

Figura 1. La información que transporta una señal generalmente seencuentra oculta. Procesar una señal implica extraer la informaciónembebida en el núcleo de ella.

Si la señal en el mundo real es analógica, debe ser convertida en una representación digital que pueda ser entendida por el sistema embebido. La conversión de unaseñal en digital es realizada por el conversor analógico – digital que es el elemento principal de interfase entre elmundo real y el “mundo digital” como se observa en la Fig. 2.La forma más simple, pero no la única, de conversión es el

muestreo uniforme. Otros tipos de muestreo incluyenmuestreo por cruce de nivel [1] y muestreo no uniforme [2].

Figura 2. El conversor analógico digital es el elemento interfase que permite la representación de las señales reales en el mundo digital. Eneste caso,, muestreo uniforme, que transforma la señal en una secuencia

ordenada de números.

t

X(t)

t

ConversorA/D

Mundo real

t

001011100011001000110001010001000100000000110010

0011000100010111Xn

Mundo digital

INFORMACIÓN

CAPA OBSERVABLESEÑAL

Procesar una señal implicaextraer la información embebida en ella



153




En el caso de muestreo uniforme, a intervalos regulares

t , se toman muestras de la señal y se convierten en un

código correspondiente a un alfabeto finito, es decir una

cantidad limitada de representaciones posibles. También el

esquema más simple es el de dividir el rango dinámico del

sensor en M divisiones de igual longitud, proceso que se

conoce como cuantificación uniforme. Otros tipos de

cuantificación se adaptan a la función densidad de probabilidad de la señal esperada. Es decir, para los valores

más probables de la señal se disminuye la amplitud de la

cuantificación.

El pasaje del mundo real al digital tiene dos

particularidades importantes. Primero, la señal que existe para

todo tiempo, es considerada solamente cada t segundos.

Segundo la señal analógica, que es libre de tomar cualquier

valor de amplitud, es forzada a una representación finita en el

mundo digital, transformándose en una secuencia ordenada de

números. El primer aspecto fue abordado por H. Nyquist y se

conoce ampliamente como el teorema de muestreo. El

teorema establece que no es necesario conocer la señal todo eltiempo para obtener una representación digital fidedigna

siempre y cuando la señal posea un limite máximo de

contenido espectral. El teorema determina que debemos

tomar muestras a una frecuencia de por lo menos el doble de

la máxima frecuencia presente en la señal. Es un límite

teórico que necesita filtros reconstructores ideales para

obtener sin error el valor de la señal entre las muestras. Si la

señal se encuentra limitada en frecuencia hasta una fmax, las

muestras, en un muestreo uniforme se deben realizar como

mínimo a 2fmax. Como resultado del proceso de muestreo

uniforme se obtiene una secuencia ordenada de números que

representan la señal, siempre y cuando se haya respetado elteorema de muestreo para evitar el “aliasing”. Hasta aquí se

ha descripto un proceso convencional de digitalización. La

secuencia ordenada de números es la señal en el mundo

digital a partir de la cual se deberán tomar todas las

decisiones en el sistema.

Un sensor inteligente con capacidad de procesamiento

embebida debería procesar el vector de muestras digitales

con el fin de tomar conciencia de la señal que obtuvo.

Figura 3. El muestreo inteligente debe “ver” a la señal completa, no solo

una muestra a digitalizar.

Recordemos que el proceso de muestreo es el punto de

conexión a través del cual se infiere el mundo real. En un

sistema de control, todas las acciones estarán basadas en esta

información. En la Fig. 3 se observa una señal típica

proveniente de un sensor. Un proceso de muestreo

inteligente implica ver a la señal en su conjunto, no solo

una muestra. Si un ser humano observa la Fig. 3 podría sacar

conclusiones tales como: la señal es ascendente, hay unaforma tipo impulsiva que provoca un pico positivo y uno

negativo. La señal proveniente del sensor es un proceso

aleatorio. Los parámetros que se conocen previamente son la

limitación en ancho de banda, impuesta por un filtro

antialiasing, y su rango dinámico. En general, no se conoce la

función densidad de probabilidad de la señal. La presencia de

ruido, malfuncionamiento del elemento sensor o errores en la

conversión deberían ser detectados. Las características

deseables de un sensor inteligente con respecto a la señal que

adquiere serían:

Determinar la frecuencia de muestreo óptimo.

Reconocer la forma de la señal.

Predecir valores.

Validar la señal.

Marcar particularidades.

Almacenar valores pasados en forma comprimida.

Detectar patrones en forma automática y/o predeterminada.

En las secciones siguientes se desarrollan los algoritmos

propuestos en busca de las anteriores características. Se

mantiene el muestreo uniforme pero la señal se sobremuestrea

con respecto a la frecuencia de Nyquist. Se obtiene un vector

redundante a partir del cual se disparan todos los algoritmos.

El primero es una segmentación en tiempo real basada en

interpolación lineal adaptiva. Luego los segmentos son

etiquetados reflejando el comportamiento dentro de él. Con

esta información se detectan secuencias de segmentos que

identifican comportamientos globales. Estos tres procesos

conforman la base para el análisis de la señal muestreada.

II. DESCRIPCIÓN DE LOS ALGORITMOS

De acuerdo al teorema de muestreo, debemos tomar dos

muestras, como mínimo, en el tiempo correspondiente al

periodo de la componente de frecuencia máxima de la señal.

Si comenzamos a aumentar la frecuencia de muestreo, surgen

dos preguntas: ¿Hasta que valor tiene sentido aumentarla? y

t

X (t)



154




max max

2[ (2 ( ) (2 )]

2 N

A A sen f t t sen f t

max max( ) ( ) [ (2 ( ) (2 )] x t t x t A sen f t t sen f t

1

max2 (2 ) N sen f t

max

2 N s f

f

¿Que beneficios otorga este incremento? Las respuestas a

estos interrogantes surgen del siguiente análisis.

Sea x(t) la señal a ser muestreada, limitada en banda a

fmax Hertz. Consideremos el caso particular que x(t) es una

señal sinusoidal de máxima amplitud y frecuencia.

(1)

Donde A es la mitad de rango dinámico del conversor. Si

transcurren t segundos tenemos:

(2)

Por lo tanto:

(3)

El lado izquierdo de (3) corresponde al cambio de la señalentre dos instantes de muestreo. Si fijamos este cambio a 1 bit

menos significativo, un LSB, obtenemos:

(4)

Donde N es la cantidad de bits del conversor A/D. La

máxima velocidad de cambio de la sinusoidal ocurre en los

cruce por cero. Tomando t=0 para simplificar obtenemos de

(4):

(5)

Dado que 1/ t es la frecuencia de muestreo fs, el

argumento del seno es mucho menor que uno y teniendo en

cuenta que ( )sen x x para x pequeños obtenemos:

(6)

Por ejemplo, empleando (6), para N=8 bits obtenemos una

frecuencia de muestreo de aproximadamente 400 veces la de

Nyquist. Dada una resolución del conversor, (6) determina la

máxima frecuencia de muestreo que tiene sentido aplicar ya

que valores mayores darían como resultado la misma

muestra. La ecuación (6) se determinó para una señal

sinusoidal pura de máxima amplitud y frecuencia.

Considerando una señal real y que el contenido espectral es

en general decreciente con la frecuencia, un factor de 10% del

máximo obtenido es razonable.

Entre los beneficios que brinda el sobremuestreo se

encuentra una reducción efectiva del ruido de cuantificación,

[3]. Es importante resaltar que la señal que podía tomar

infinitos valores entre dos puntos en el mundo analógico, es

forzada a un alfabeto finito. Más aun empleando la restricción

del cambio de a solo un LSB, el espacio queda reducido a tres

dimensiones, el mismo valor o mas menos un LSB.

Bajo condiciones de sobremuestreo se reduce la

aleatoriedad de la señal. Visto de otra manera se genera

redundancia entre muestras vecinas. Los algoritmos que

describen el muestreo inteligente parten de los siguientes

conceptos:

a) No todas las muestras poseen la misma cantidad de

información [4].

b) En condiciones de sobremuestreo, las muestras

pierden valor relativo si su valor puede ser obtenido

mediante interpolación de sus muestras vecinas.

Las muestras que no pueden obtenidas mediante unacombinación lineal de sus vecinas, transportan en algún

sentido más información y las llamaremos muestras

esenciales. Las muestras esenciales marcan límites naturales

de segmentos de la señal con un comportamiento uniforme.

En [5] se describen ampliamente los algoritmos propuestos

y aquí presentaremos solamente un resumen. El algoritmo de

segmentación comienza interpolando la muestra 2 de 1 y 3.

Se calcula el error como la diferencia entre la muestra 2

interpolada y la real. Si el error es menor que una cota de

error, la muestra 2 no transporta información ya que su valor

puede ser calculado mediante interpolación lineal de susmuestras vecinas. El próximo paso es interpolar la muestra 3

mediante las muestras 1 y 5 y así siguiendo. Cuando se supera

el error de interpolación o un error acumulativo, se culmina

un segmento determinado en sus extremos por dos muestras

esenciales. Si la cota de error no se supera por un número

determinado de muestras se culmina el segmento a ese

máximo de muestras. De esta segmentación, que se ejecuta en

tiempo real, se obtienen dos vectores que denominamos

mark(n) y timepos(n) que contienen los valores de las

muestras esenciales y los instantes de ocurrencia

respectivamente.

En la Fig. 4 se observa el esquema del proceso completo de

tratamiento de la señal sobremuestreada. Un tercer vector

clases(n) determina el comportamiento de la señal dentro del

segmento, estableciendo ocho clases de comportamiento

denominadas: a,b,c,d,e,f,g,h. Se basa en la diferencia entre las

muestras interpoladas y las muestras reales. Por ejemplo si

dentro de un segmento las muestras interpoladas exceden las

reales, es un indicador de la forma de la señal dentro del

segmento, como es el caso de los segmentos tipo “f” o “d”.

En la Fig. 5. se observan las ocho clases. Los segmentos

“a”,”b” y ”c” son consecuencia de no haber alcanzado la cota

max( ) (2 ( )) x t t Asen f t t

ma x( ) (2 ) x t Asen f t



155




de error y el segmento se termina por alcanzar el límite

máximo de segmento.

Figura 4. Esquema del proceso de análisis de la señal sobremuestreada.

Figura 5. Clasificación de segmentos en ocho clases.

A. Análisis inter-segmento

La información proporcionada por los tres vectores

mark(n), timepos(n) y clases(n) proporciona una plataformade análisis para inferir comportamientos de la señal

muestreada. Es importante recalcar que los tres vectores, enuna estructura de de buffer circular, se obtienen en tiemporeal a medida que ingresan las muestras. El patrón de

secuencia de clases de segmentos especifica un

comportamiento determinado de la señal muestreada. En laFig. 6 se observa una señal ejemplo. Considerando solamenteel vector clases obtenido podemos inferir el comportamiento

de la señal a través de los siguientes patrones:

En la primera porción de la señal hay uncrecimiento exponencial dado por la secuencia de

segmentos “g” .

Se alcanza un máximo que ocurre en la unión de

segmentos “g” y “e” .

A partir del máximo, la señal comienza a caer dada

la ocurrencia de los segmentos “e” .

Hay un cambio de tendencia dada la ocurrencia de

un segmento “h”, luego del cual la señal decae en

forma exponencial para alcanzar un mínimo que

será localizado con precisión en la unión de los

segmentos “f” y “d” .

Figura 6. Vector clases sobre una señal testigo.

Mediante estas simples observaciones, el sistema embebidoes conciente de la señal que esta digitalizando, prácticamenteen tiempo real.

Es importante remarcar que si el error de interpolación tiendea un LSB, la probabilidad de ocurrencia de los segmentos

“a”,”b”,”c” y ”h” tienden a cero. Bajo esta condición, y con laseñal suficientemente sobremuestreada, el comportamiento de

la señal queda especificado solamente por los cuatrosegmentos “d”, “e”,”f” y ”g”.

El análisis del comportamiento macroscópico de la señales posible mediante las secuencias de patrones de clases desegmentos. Por ejemplo, la ocurrencia consecutiva de

segmentos tipo “g” indica que la señal se esta estabilizando aun valor de estado estacionario que podría incluso predecirse.

Esta predicción es analizada en la siguiente sección.

Mediante el análisis de la cantidad de muestras de los

segmentos obtenidos, el sistema embebido podría ajustar élmismo la frecuencia de muestreo. La frecuencia de muestreoóptima para una porción de señal es la frecuencia de

sobremuestreo dividida por la cantidad de muestras delsegmento más corto en dicha porción de la señal. La longitud de los segmentos es un parámetro importante ya quedetermina como se aparta la señal de un comportamientolineal. La Fig 7. Detalla la detección de algunos

comportamientos macroscópicos.

señalsensorial

X t)

fs sobremuestreo

Segmentacióntiempo real

Resultado:Ve ctor de muestras esenciales y

vector de posicion temporal

A nálisisintrasegmento

R esultado:Ve ctor de clases a,b,c,d,e,f,g,h

A nálisisintersegmento

R esultado:De tección de pa trones:E xponencial, sinusoidal,ruidoso, frecuencia demuestreo optima, ruidoimpulsivo, predicción,

compresión….

Resultado:vector de se ñal con redundancia

a

b

h

g

f

e

d

c

c o n s t a n t e

lin e a l +

lin e a l ( - )

+ e x p +

( - ) e x p +

r u i d o s o

c - e x p ( - )

c + e x p ( - )



156




Figura 7. Detección de comportamiento macroscopico mediante analisis

inter segmento.


Los algoritmos de segmentación y clasificación fueron

implementados sobre microcontroladores. Se realizó unsensor de temperatura inteligente de bajo costo cuyo circuito

se observa en la Fig 8. El microcontrolador es un 12F683 deMicrochip que posee conversor A/D de 10 bits. La sonda detemperatura esta formada por tres diodos 1N4148 y posee

interfase serie RS232 optoacoplada. El costo del sensor esinferior a los 4 USD.

Figura 8 Implementación de un sensor inteligente de temperatura de bajo

costo.

El sensor reconoce la forma que obtiene en el muestreo y

cuando detecta tres segmentos consecutivos tipo “g” o tres

segmentos consecutivos tipo “f” realiza el análisis de

predicción empleando las muestras esenciales y la pendiente

en esos instantes. Este tipo de predicción es importante en

sistemas de control [6].

La expresión general de exponencial en la Fig. 9 es:

/( ) ( ) t T x t Xss Xss Xi e

(7)

Donde Xss es el valor en estado estacionario y Xi el valor

inicial. La derivada de x(t) respecto de en t=0 es:

0(8)

t

dx Xss Xi

dt T

La pendiente de los segmentos puede emplearse como laaproximación de la derivada en (8) aplicada en los puntos a y

b. Si consideramos la derivada en el punto a y empleandoeste punto como valor inicial obtenemos:

(9) Xss Xia MaT

Donde Ya Ma Xa

es la aproximación de la pendiente en

el punto a. Repitiendo el análisis ahora en el punto b, y

empleando este punto como valor inicial obtenemos:

(10) Xss Xib

MbT

Donde Yb Mb Xb

es ahora la aproximación de la pendiente

en el punto b. Resolviendo (9) y (10) obtenemos (11).

(11)

Ma Xib - Mb Xia

Xss Ma-Mb

Figura 9 Predicción del valor estacionario de la señal basada en los

cambios de pedndiente en los segmentos tipo “g”.

En la Fig. 10 se observa el algoritmo de segmentación yclasificación de segmento implementado en lenguaje “C” deCCS inc sobre el 12F683. Se diseño siguiendo la filosofía de programación Estado-Cooperativa. Por limitaciones de

memoria RAM, 128 bytes, se limitó la longitud del segmentoa 48 muestras.

Un microcontrolador adecuado para estas técnicas es eldsPIC33FJ12GP de Microchip, el cual fue diseñado paraaplicaciones de sensores inteligentes, permitiendo digitalizar

a 1.1 millones de muestras por segundo.

Comportamiento exponencial estable: S ecuenciaconsecutiva de segmentos tipo “g” de longitudes

crecientes.

Co mportamiento exponencial intestable: S ecuenciaconsecutiva de s egmentos tipo “d” de longitudesdecrecientes.

Comp ortamiento oscilatorio: Secuencia deseg mentos tipo “g”, “e”,”f”,”d”. Los máximos ocurrenen la unión de “g”,”e” y los mínimos en la unión de“f” y”d”. Analizando los valores de los máximos y

mínimos se determina si la osc ilación es crecienteo de creciente

Ruido impulsivo: Determinado por la abruptareducción de las longitudes de los segmentos.

Detección de patrones especificos: En este caso elpatrón QRS T



157




Figura 10 Algoritmo de segmentación y clasificación de segmento

implementado en el microcontrolador 12F683.

IV CONCLUSIONES

La potencia de los sistemas embebidos actuales hacambiado no solo la topología de nuestros diseños, sinoademás la forma de concebirlos. Algo que en el pasado era

inviable pasa a ser factible para luego transformase ennatural.

Naturalmente los sistemas embebidos deben muestrear enforma inteligente. Una propuesta de normalización de estos

algoritmos fue presentada en [7]. El intercambio deinformación mediante un lenguaje común entre sensores deun sistema permite el aumento de confiabilidad, la predicción

anticipada de estados anormales, la detección de patronesnormales y anormales y el aprendizaje de patrones en formaautomática.

Los algoritmos presentados son simples pero muy efectivos.Capturan la esencia de la señal muestreada, y representan lainformación presente en ella. Si el error de interpolacióntiende a un LSB los cuatro segmentos “d”,“e”,”f” y “g”

codifican la señal como si fuera el código genético de ella.

R EFERENCIAS

[1] N. Sayiner, H.V. Sorensen and T.R. Viswanathan, “A Level-Crossing Sampling Scheme for A/D Conversion”, IEEE

Transactions on Circuits and Systems II, vol. 43, pp. 335-339, April1996.

[2] R. Haddad, T Parsons.“ Digital Signal Processing, Theory,Applications and Hardware”.Computer Science Press 1991., pp 32-36.

[3] J Murthy Madapura “Achieving Higher ADC Resolution Using

Oversampling” AN1152, Microchip Technology Inc. 2008.

[4] Marten D. van der Laan. “Signal sampling techniques for data

acquisition in process Control”. Thesis Rijksuniversiteit Groningen. -1995. ISBN 90-367-0502-9.

[5] Monte, G. “Sensor Signal Preprocessing Techniques for Analysis and Prediction” Industrial Electronics, 2008. IECON 2008. 34th Annual

Conference of IEEE. pp 1788-1793. ISBN 978-114244-1766-7.

[6] F. Bertling, S. Soter, “Real-time prediction of the steady state

temperature of circuit components as a tool for power electronic circuittesting”. PCIM Europe 2007 Conference, Nuremberg, Germany.

[7] Monte, G. “A proposal of a New Standard For Sensor Signal Analysis”.

Industrial Technology (ICIT), 2010.Chile. IEEE InternationalConference . pp 1617-1622. ISBN 978-1-4244-5697-0/10.

.



158




Controlador de carga para un sistema fotovoltaicoaislado

Daniel Hoyos, Maiver Villena, Víctor Hugo Serrano,Federico Farfán, Carlos Cadena

Universidad Nacional de SaltaINENCO Instituto de Energías Renovables

Salta, [email protected]

Telmo MoyaUniversidad Nacional de Salta

Salta, [email protected]

Resumen — El siguiente trabajo tiene por objeto analizar los

componentes más importantes que influyen en el diseño de unainstalación fotovoltaica aislada que incluye un controlador

fotovoltaico y un inversor de 12V a 220V, proponer uncontrolador de carga que maximice las prestaciones del sistema,

proteja y aumente la vida útil de cada uno de los componentes. Elsistema se desarrollará utilizando un microcontrolador.

batería, controlador de carga,inversor, microcontrolador, panel

fotovoltaico

I. I NTRODUCCIÓN

Un sistema fotovoltaico como se muestra en la Fig. 1 estácompuesto por: panel fotovoltaico, batería, controlador decarga, inversor, que transforma corriente continua a corrientealterna en 220 V y la carga del sistema.

Figura 1. Esquema general de un controlador fotovoltaico

El panel fotovoltaico tiene una curva de funcionamientocomo la de la Fig. 2 y es el resultado de asociar un conjunto de

células fotovoltaicas en serie y en paralelo. La descripcióneléctrica de la célula [2] responde a la siguiente ecuación:

I = Il - I0 [exp ((V + I R s ) / n Vt) -1] - (V + I R s ) / R p (1)

Il: Corriente fotogenerada,

I0: Corriente de saturación inversa del diodo,

Vt = kT/e: voltaje térmico,

T: temperatura en grados Kelvin,

Figura 2. Panel fotovoltaico

R s: resistencia serie,

R p: resistencia paralelo,

n: factor de idealidad del diodo.

La corriente fotogenerada se determina en función de lasdimensiones de la célula, su área A en cm2, la densidad decorriente de cortocircuito Jsc en A/cm2, la temperatura detrabajo T en ºC y el factor de temperatura αJsc en A/ºC cm2.

El valor de I1 lo determinamos con la siguiente ecuación:

I1 = A (Jsc G/1000 + αJsc (T – 27)) (2)

Lo que implica que al aumentar la radiación aumenta lacorriente de cortocircuito y la gráfica se desplaza hacia arriba.

Si se supone que el sistema a controlar es aislado y seutiliza fundamentalmente para dar iluminación nocturna, lasituación habitual en nuestro país, el diagrama de consumoeléctrico es el mostrado con trazo discontinuo en la Fig. 3,mientras que la radiación solar tiene su pico alrededor de las 13horas [1], por lo tanto la corriente que puede suministrar el panel responde a una distribución del tipo mostrado en lamisma Fig. 3. Se utilizó un modelo de radiación de día claro



159




modificado, el cual responde en forma aproximada a la regiónmontañosa de Argentina [1]. De la observación de los gráficosse puede inferir que el ciclo de carga y descarga de lainstalación es de 24 horas en el cual la batería se descargadurante la noche y el atardecer para cargarse durante el díasegún la radiación incidente. El ciclo de descarga no puedecontrolarse porque es función de las necesidades del usuario, pero la carga se puede controlar en alguna medida, lo que

permite optimizar las perfomance del sistema.El algoritmo de control que proponemos en este trabajo

consiste en medir la energía consumida por la carga el díaanterior y devolverla si se puede en el día siguiente. Estealgoritmo no busca obtener la máxima energía del panel,debido a que basa su funcionamiento en optimizar el ciclo decarga de la batería el cual es el elemento más débil de unsistema fotovoltaico aislado. Para que el sistema funcioneóptimamente no se puede superar la tensión de gaseo de la batería.

Figura 3. Curva aproximada de la distribución de la corriente recibida yentregada por el sistema.

II. ACUMULADORES

Las baterías utilizadas en este caso son del tipo de Pb-ácido. Para el análisis del sistema se utiliza el modelo deCoppeti [2], el cual es muy sencillo y funciona aceptablementesobre un número muy grande de baterías presentes en elmercado local. La elección de la misma se realiza en funcióndel parámetro capacidad en Amper-hora que sería la máximaenergía que puede entregar la batería hasta descargarsecompletamente. La energía útil es un valor que se encuentraafectado de un coeficiente que para las baterías analizadas eneste trabajo es de 0,3. Lo que significa que si se dispone de una batería de 150 Ah. la profundidad de descarga máxima que se

puede realizar es de 50-60 Ah. El acumulador cuando se cargainvierte energía para su propio funcionamiento lo que implicauna pérdida de carga, por ello se define un coeficientedenominado eficiencia; el cual puede ser del orden de 0,9 enlos acumuladores que se están utilizando. La evaporación delelectrolito es función de la temperatura ambiente y de latensión de la batería. Una aproximación de primer orden deeste fenómeno responde a la ecuación:

V = 0,05 t + 12,5 (3)

En donde V es la tensión a partir de la cual la bateríaempieza a gasear y t es la temperatura ambiente. Se debe tener en cuenta que no es conveniente para la batería una cargarápida y tampoco es conveniente para el panel tener largos períodos de tiempo, a circuito abierto, o en cortocircuito (comoes el caso de los controladores convencionales) por lo tanto esconveniente suministrar carga a la batería durante la mayor parte del día.

III. HARDWARE DEL CONTROLADOR DE CARGA

El controlador está compuesto por tres bloques: medición, potencia y control. El bloque de medición se encarga de medir la corriente suministrada por el panel fotovoltaico y la corrienteentregada a la carga, la tensión de batería y la temperaturaambiente. El bloque de potencia es el encargado de suministrar corriente a la batería utilizando modulación por ancho de pulsoy transistores HEXFET IRFZ44N. Para controlar la cargasolamente se desconecta cuando la tensión de la batería es

menor que 11,3 V o la corriente es mayor que un determinadovalor.

A. Medición

Un esquema del circuito de medición de corrientes ytensiones del controlador es el mostrado en la Fig. 4, en elmismo se puede observar que se mide la corriente usando ladiferencia entre dos tensiones.

Figura 4. Esquema del circuito de medida de corriente

El valor de las resistencias de shunt depende de la corrientemáxima del controlador de carga y de la potencia máxima quese desea disipar en las baterías. . Los valores de R1 y R2 soncríticos ya que un valor de resistencia elevado disminuye el

rendimiento del sistema y un valor muy pequeño disminuye lasensibilidad de la medida de corriente. El sistema de controlestá alimentado por una tensión de 3.3V, siendo esa la máximatensión que puede medir. Por lo tanto se debe atenuar la tensión para que pueda ser medida a costa de disminuir la mínimacorriente que se puede medir. Para no perder resolución seutiliza un amplificador diferencial, con ganancia unitaria deforma que ninguna tensión sea superior a 7 V para evitar que elamplificador se sature. La ganancia de tensión del amplificador diferencial será 1 y la ganancia del amplificador no inversor será de 3,3.



160




Figura 5. Circuito de medición

El circuito utilizado para la medición puede verse en la Fig.5.

La expresión del número de cuentas en función de losdistintos parámetros del circuito es [1]

Nc=k 2(k 1.R 1I+V1).2n/Vref (4)

En donde:

Nc= número de cuentas

k 1= ganancia del amplificador diferencial

k 2=Ganancia del amplificador inversor

R 1= resistencia de shunt

n= número de bits

Vref =Tensión de referencia

V1= Tensión para evitar la saturación de losamplificadores operacionales.

B. Control de potencia

El circuito de control de potencia que se muestra en la Fig.6 es el de un controlador serie en el cual se usan comoelementos de control dos MOSFET de potencia. El transistor T1 se encarga de controlar la carga de la batería mientras queT2 se utiliza sólo para desconectar la carga en caso de sobrecorriente o que la batería se encuentre muy descargada.

Figura 6. Circuito de control de potencia

Este circuito fue modificado y se probaron nuevasconfiguraciones con MOSFET tipo P y tipo N siendo lamostrada en la Fig. 6 la más práctica cuando se requierencorrientes mayores.

C. Control

El bloque de control está compuesto básicamente por unmicrocontrolador 16f877 y el circuito puede verse en la Fig. 7.La medición de la temperatura se realiza utilizando un circuitointegrado especialmente diseñado para este fin, el LM35 quetiene una sensibilidad de 10 mV/ºC.

Figura 7. Circuito de control

El microcontrolador tiene por entradas las tensiones:“Vcap” encargada de medir la tensión del capacitor que polariza las compuertas de los MOSFET de potencia en elcanal 0 del microcontrolador, “Vcp” que es la tensión querepresenta la corriente del panel en el canal 1, “Vcc” que es latensión que representa la corriente de la carga en el canal 2,“Vtb” que es la tensión de la batería en el canal 3 y latemperatura es sensada por el canal 4. Las señales de salidaserán las tensiones: T1 encargada de controlar la corriente decarga de la batería, utilizándose para esta salida el módulo 1 demodulación por ancho de pulso y T2 que controla la descargade la batería y sólo se utiliza para desconectar la batería en casode sobrecarga, cortocircuito o batería muy descargada. Elsistema tiene dos leds que informan si la batería está cargada ono.

IV. CONTROL DEL SISTEMA

El control de este sistema debe tener en cuenta que:



161




• La batería no comience a evaporar electrolito.

• El ciclo de carga debe ser tal que en el transcurso de 24horas la carga consumida por el usuario debe ser restituida al 100 %. De esta forma el sistema entregacorriente durante todo el día a la batería.

A. Control de la evaporación del electrolito

La temperatura se mide con un LM35, que tiene unasensibilidad de 10 mV/ºC, el cual nos indica la tensión a partir de la que se debe detener la carga.

B. Ciclo de carga

Con en este sistema se busca que el panel entregue a la batería una cantidad de carga igual a la consumida durante eldía anterior. En la Fig. 8 se puede observar la distribución de lacorriente del panel a lo largo de un día típico sin nubosidad,

para realizar el control se supuso que la cantidad de corrienteque puede entregar el panel es una función triangular, como seobserva en la figura, siendo ésta una aproximación de primer orden con respecto a la distribución real. El valor máximo deesta distribución es el correspondiente a la hora de máximaradiación, el mediodía solar. Por lo tanto la carga que puedeentregar este sistema será igual a la máxima corriente que puede suministrar el panel multiplicado por la duración del díadividido 2, integral de la función triangular

Figura 8. Distribución diaria de las corrientes del sistema

Este valor en general es mayor que el consumo de la carga

de la instalación, como se muestra en la Fig. 8. Por lo tanto sise desea reponer la carga a lo largo del día, se debe entregar encada intervalo de tiempo la relación entre la carga consumidaen el día anterior y la carga máxima posible. Se utiliza con estefin modulación por ancho de pulso (PWM), la cantidad decorriente entregada en PWM es proporcional a la relaciónentre el periodo de la función y el tiempo de alto.

Se mide la corriente de carga de la batería y la corriente dedescarga, se integran estos valores a lo largo de un ciclo de unel día anterior se determina el periodo y el tiempo de alto de lamodulación por ancho de pulso.

Figura 9. Secuenacias del ciclo de carga y descarga del controlador día, con

el valor máximo teórico y con la carga consumida

En la Fig. 9 se puede observar una simulación de cuatrodías de operación del controlador de carga, CDA significacarga consumida el día anterior por el sistema en Amper hora,PWM modulación por ancho de pulso, CNR carga no restituidaa la batería al final del día por el sistema y CG energíaconsumida por la carga durante el día. Las funciones mostradasen la grafica son: “Ifoto” que es la corriente que puede



162




suministrar el panel, “cargar” que es la energía en Amper horaque el panel está enviando a la batería, “Carga” es la corrienteen Amper que esta consumiendo la instalación y “amperc” es laemergía consumida por la instalación a lo largo del día.

El controlador de carga mide la energía consumida por lainstalación durante la tarde y la noche restituyendo este valor durante el día siguiente, Fig. 9a. Cuando la energía consumidasupera la carga que puede restituir en un día, Fig. 9b, elcontrolador restituye la carga en los días subsiguientes, Fig. 9cy Fig. 9d. Si se observa en la Fig. 9c el controlador aprovechatoda la energía disponible siendo la relación PWM = 1 en casoque la energía requerida sea mayor que la que puede aportar, enFig. 9d se encuentra en régimen normal.

Este algoritmo de control es muy sencillo, sólo necesita queal comenzar a operar el sistema se reinicie temprano a lamañana del primer día, cuando la radiación es casi cero y no secomenzó a consumir energía de los acumuladores.

Pero tiene algunos problemas, por ejemplo si una nubedisminuye notablemente la radiación solar el sistema no puedeacomodarse para reponer en el día la energía consumida. El

algoritmo de control no distingue en qué momento del día seencuentra el controlador. Por lo tanto se realizó unamodificación, se define como “noche” al estado en el que el panel fotovoltaico entrega una corriente menor a 0,1 A, duranteese tiempo pwm = 1, “amanecer” cuando la corriente superacon pendiente positiva 0,1 A, “atardecer” cuando la corriente esmenor a 0,1 A con pendiente negativa, la “duración del día” esla diferencia entre amanecer y atardecer y la “mañana” la primera mitad del día. Tarde la segunda mitad del día. Secalcula la relación de modulación por ancho de pulso para lamañana y la tarde de forma que cada una debe restablecer lamitad de la carga del día.

V. PROGRAMA DE CONTROL

El microcontrolador PIC16F877 se programa en lenguajede maquina, se utilizó la interrupción del contador TMR0 paraimplementar un reloj. TMR0 es un contador que una vezconfigurado está continuamente contando y cada vez quedesborda hace un llamado a una interrupción, esta subrutinaincrementa un conjunto de contadores en cascada: fracción demilisegundos, milisegundos, minutos, 15 minutos, horas y días.Así, cuando el contador “segundos” llega a 60 se borra yaumenta “minutos”, cuando “minutos” se pone a uno serealiza la medición de los distintos parámetros, corriente de

panel, corriente de carga, tensión de batería, temperatura y laintegración de las corrientes. En la hora 0 se realiza el cálculode la relación de modulación de pulso y duración del díaanterior en cantidad de periodos de 15 minutos. Cuando lacorriente de panel supera los 0,1 A y la corriente anterior esmenor a ese valor se determina el amanecer y se inicia lacuenta del día siguiente, durante este tiempo la relación de

modulación es cero. Cuando la corriente de panel baja de 0,1A, o sea la corriente medida es menor de 0,1 y la anterior mayor de 0,1 A se determina el fin del día. Con estos valores sedetermina el mediodía, donde se recalcula la relación demodulación PWM.

Por ejemplo un día de 10 horas tendrá 40 períodos de 15minutos y la energía será proporcional a 151*40/2=3020cuentas, un día de 14 horas tendrá como máximo teórico 8456.La energía consumida por la carga también es proporcional ala cuenta obtenida de sumar todas las cuentas obtenidas almedir la corriente en la carga. Por esta razón se divide elmáximo teórico de energía suministrada por el panel en cuentas por 32 que da como resultado 149, que es un número de 8 bitsy se lo utiliza como período de PWM, mientras que el tiempode alto es la cuenta de la energía consumida por la cargadividido por 32. Este valor se reajusta al mediodía.

VI. CONCLUSIONES

El algoritmo de control analizado es muy sencillo deimplementar y no requiere microcontroladores demasiadoscomplicados. Fue probado sobre una plataforma con unmicrocontrolador PIC 16F873 funcionando aceptablemente.También se desarrollo una versión en C paramicrocontroladores de la familia 18f4550. El algoritmo decontrol de este sistema fue simulado y probado como semuestra en la Fig. 9. El sistema fue probado en laboratoriosimulando cargas y conectando paneles fotovoltaicos. La lógicade control del controlador fue desarrollada para un panel, perocambiando la resistencia de shunt, de modo apropiado se probóel sistema con una corriente máxima de 20 A, o sea 6 paneles.Las resistencias de shunt son la mayor causa de disipación deenergía del controlador. El rendimiento del sistema es de 0,93con HEXFET. Se probaron distintos transistores, el 2N3055controla hasta 2 paneles, MJ15004 controla hasta 3 paneles. Alutilizar transistores bipolares el rendimiento disminuye hasta0,9; pero el costo del controlador disminuye sensiblemente. Elsistema presenta dificultades de control en la situación en queel máximo de energía disponible en el fotovoltaico no sea almediodía. Esta situación se puede dar en una región donde laslluvias ocurren al mediodía.

R EFERENCIAS

[1] Duffie J. A. y Beckman W. A. (1991). Solar Engineering of ThermalProcesses, 2ª edición, pp. 54-59. Wiley Interscience,

[2] Farfan Federico Hoyos Daniel (2008), Sistema de simulación yevaluación de logicas de control basados en algoritmos borrosos parasistemas fotovoltaicos Avances en Energías Renovables y Medio

Ambiente Vol. 12, 2008. Impreso en la Argentina. ISSN 0329-5184

[3] J. B. Copetti, E. Lorenzo, F. Chenlo A general battery model for PVsystem simulationProgress in Photovoltaics: Research and ApplicationsVolume 1, Issue 4, pages 283–292, October 1993.



163




Sistema de Emergencia Remoto Basado en GSM

Daniel A. Mancuso, Juan L. CastagnolaFacultad de Ingeniería

Universidad Católica de Córdoba


Resumen — En este trabajo se reporta el desarrollo de un sistema

de emergencia de propósitos múltiples, portátil, basado en la

tecnología GSM, capaz de enviar mensajes SMS y realizar

llamadas de voz disparadas por eventos de alarma provenientes

de distintas fuentes. El núcleo del sistema es un microcontrolador

de 16 bits de la serie PIC24 en el cual se ejecuta un sistema

operativo de tiempo real, que realiza el control de un módulo

GSM y la interfaz de usuario compuesta por un display LCD

alfanumérico, un teclado de membrana, una interfaz de audio y

demás periféricos necesarios.

Palabras clave - Sistema de Emergencia; Seguridad doméstica;

Sistemas Embebidos; GSM; SMS; Microcontroladores; RTOS;

I. I NTRODUCCIÓN

En la actualidad, un gran porcentaje de la población se preocupa por la seguridad doméstica. Con el amplio desarrollode las tecnologías de comunicaciones, se ve simplificado eldiseño de un sistema de monitoreo y alarma remoto. Tanto pararesponder a posibles robos o intrusiones a la propiedad,accidentes o situaciones de peligro hogareñas como puede ser una perdida de gas, como también la integridad física de las

personas que habitan el hogar [1, 2]. En consecuencia, se

desarrolla un sistema capaz de solicitar auxilio a un tercero o auna empresa de servicios de emergencia, mediante el envío deuna alerta acerca de la ocurrencia de una situación de este tipo.

La red de comunicaciones “Groupe Special Mobile”(GSM), es actualmente una tecnología madura. Provee unaamplia cobertura en las ciudades y zonas rurales, comunicacióna largas distancias [3], un fácil acceso al usuario (ya que se

puede utilizar con un simple chip mediante un sistema pre- pago). A través de esta red se pueden realizar llamadas de voz,datos y entrega de “Short Message Service” (SMS). Debido aestas ventajas, se seleccionó la red GSM como medio deentrega del mensaje de alarma.

Un gran porcentaje de los sistemas embebidos pequeños

están basados en microcontroladores, y el mayor desafío en eldiseño de estos sistemas es el desarrollo del firmware [4]. Elenfoque tradicional en la programación de los sistemas, es deltipo programa principal / interrupciones (foreground/ background), donde el flujo normal del programa consiste enun loop infinito que realiza llamadas a los módulos deaplicación para realizar las operaciones deseadas. Además, seutilizan rutinas de interrupción (ISRs, Interrupt Service Routines) disparadas por eventos tales como temporizadores ocambios de estado en las entradas. Pero a medida que lacomplejidad del sistema aumenta, se hace mas dificultoso eldesarrollo y la depuración del firmware, ya que se deben

realizar varias tareas en simultáneo compartiendo un mismoflujo de programa principal. Es decir, las tareas se debenrealizar en forma secuencial sin perder el control de latemporización de cada operación, lo cual resulta cada vez masdificultoso, y en consecuencia, mas propenso a fallas difícilesde detectar [5].

Un mejor enfoque en estos casos, es la utilización desistemas operativos de tiempo real (RTOS, Real TimeOperating System). Estos aportan un cambio de paradigma

entre la programación lineal o secuencial, y la programaciónmulti-tarea o multi-hilo, donde varias tareas se realizanaparentemente en simultáneo compartiendo los recursos delmicrocontrolador. En realidad, las tareas se siguen ejecutandode forma secuencial ya que el CPU es único y solo se puedeejecutar una instrucción por ciclo, pero el núcleo del sistemaoperativo (kernel) es el encargado de ceder el control de laejecución a cada tarea a una velocidad lo suficientemente altacomo para que, en apariencia, se ejecuten en paralelo [6].

Por lo tanto, el principal aporte de este trabajo respecto deotros sistemas con características similares es la utilización deun RTOS para el diseño del sistema de emergencia, lo cualimplica tanto una simplificación en la implementación delfirmware, como un aumento en la confiabilidad del mismo.

II. DESCRIPCIÓN DEL SISTEMA

En la figura 1 puede observarse un esquema del sistema propuesto.

Este está compuesto por una estación basada en unmicrocontrolador de 16 bits que ejecuta un RTOS (encargadodel control de todos los bloques del sistema), un modulo GSMcon su correspondiente tarjeta SIM (la compañía a utilizar debeseleccionarse según la cobertura, confiabilidad del servicio ycostos), una interfaz de usuario compuesta por un display LCDy un teclado de membrana, un parlante y un micrófono. Laalimentación se realiza mediante un adaptador AC/DC y una

batería de Li-Ion de respaldo. La misma tiene una doblefunción: tanto como energía de respaldo para cortes delsuministro eléctrico, como para un posible uso portátil delaparato. Por ejemplo, un paciente con discapacidad motriz

podría utilizarlo para solicitar asistencia remota desde una sillade ruedas.

El sistema también consta con varias entradas digitalesmediante las cuales se realiza el disparo de la alarma. Lasmismas pueden provenir de distintos tipos de fuente como por ejemplo: sensores de humo para detectar incendios, sensores degas natural para la detección de pérdidas, sensores de



164




movimiento, detectores de apertura de puertas y ventanas paradetectar posibles intrusos.

Figure 1. Diagrama de bloques del sistema de emergencia.

Otras fuentes de disparo pueden ser dispositivos de controlde variables biomédicas como electrocardiógrafos o sensoresde saturación de oxígeno. Los cuales eventualmente pueden proveer salidas de alarma al detectar que los parámetros salende un rango prefijado de seguridad [9, 10].

Mediante la interfaz de usuario se realizan variasconfiguraciones como los tipos de alarma conectados a cadaentrada, el SMS prefijado que debe enviarse en cada caso, losnúmeros de teléfono a los que se debe enviar la alarma, etc.

También se utiliza el display LCD para indicar el estado de laconexión a la red, el nivel de la señal GSM, el nivel de la batería o el disparo de una alarma.

III. DISEÑO DE LA PLATAFORMA

A. Microcontrolador

La selección del microcontrolador a utilizar se basa en trescriterios:

• Los periféricos necesarios: una interfaz UART para lacomunicación con el módulo GSM y la cantidadmínima de puertos digitales que proporcionen lasconexiones con los distintos elementos del sistema.

• Que el RTOS a utilizar provea la implementación para el microcontrolador a seleccionar (porting). Estoimplica un tamaño mínimo de memorias RAM yFLASH, ademas de STACK dinámica en lugar de ser de tamaño fijo.

• El fácil acceso a las herramientas de desarrollo (IDE, programador y debugger).

El dispositivo seleccionado a partir de los criteriosanteriores es el PIC24FJ64GA004 de Microchip TechnologyInc., es un microcontrolador de 16 bits con una arquitectura

Harvard modificada, posee una memoria Flash de 64 kbyte,una RAM de 8 kbyte, y una interfaz propietaria para la programación y depuración llamada ICSP.

Si bien hay muchos microcontroladores que cumplen losrequisitos anteriores, el seleccionado está disponible en elmercado local, y es aceptado por su robustez en comparacióncon uC de otros fabricantes. Por otro lado, las herramientas dedesarrollo son fácilmente accesibles.

B. Modulo GSM

Se seleccionó el módulo GSM/GPRS SIM340C, de la firmaSIMCOM. La figura 2 muestra un diagrama interno delmódulo. El mismo provee toda la interfaz de RF para laconexión a la red GSM, comunicación mediante un puertoUART para el control del mismo, interfaz para la conexión conuna tarjeta SIM, 2 canales de audio y un convertidor A/Dinterno para el control del nivel de batería. El control delmódulo se puede realizar mediante comandos AT standard, ycomandos adicionales propios del fabricante. También proveeel protocolo TCP/IP que puede ser utilizado para latransferencia de datos desde y hacia Internet mediantecomandos AT extendidos [7].

Figure 2. Diagrama interno del módulo GSM.

C. Circuito grabador - reproductor de voz

Para el almacenamiento de mensajes de voz (y su posterior reproducción durante una llamada de emergencia), se utiliza uncircuito de grabación de voz. El IC seleccionado es elAPR9600 de la compañía Aplus Integrated Circuits Inc. Poseeuna memoria Flash capaz de almacenar hasta 60 segundos deaudio a una calidad aceptable para la grabación de voz. La

memoria puede subdividirse hasta en 8 segmentos, dando la posibilidad de grabar varios mensajes de menor duración. Parala interconexión de este IC con el parlante, el micrófono y lainterfaz de audio del modulo GSM, se utiliza el circuitoCD4053, que posee 3 llaves analógicas de dos vías, las cualesson controladas por el uC. Un circuito amplificador de audio(LM386), amplifica la señal de audio a un nivel suficiente paraque sea claramente audible en el parlante. Esta interfaz ilustraen la figura 3.

La interfaz de audio se implementa tanto como para grabar y reproducir los mensajes prefijados de alarma, como para lautilización en modo “manos libres”.



165




Figure 3. Diagrama en bloques de la interfaz de audio

D. Interfaz de usuario

Como fue indicado anteriormente, la interacción con elusuario se realiza mediante un teclado de membrana de 4 filas por 3 columnas con el cual se puede navegar por los diferentesmenús e ingresar datos como el número de teléfono al que sedebe realizar la llamada de emergencia. Se dispone un móduloLCD alfanumérico de 4x20 caracteres para la visualización de

los menús y estados del sistema.

IV. DESARROLLO DEL FIRMWARE

Como se comentó anteriormente, el mayor desafío en eldiseño de un sistema embebido es el desarrollo del firmware, por lo que en este trabajo se intenta sacar provecho de lasvirtudes de los RTOS debido a la complejidad del sistema, justificando la mayor utilización de recursos del uC.

A. Sistema Operativo

El sistema operativo seleccionado para el presente trabajoes el “uC/OS-II” de Micrium Technologies. Este es un RTOSmulti-tarea (puede manejar hasta 56 tareas), preemptivo (es de-cir, que ejecuta siempre la tarea de mayor prioridad), y deter-minista, de manera que siempre se puede conocer el tiempo deejecución de una tarea. Se puede escalar según las necesidadesde la aplicación y es portable hacia una amplia gama de microprocesadores y microcontroladores presentes en el mercado(mas de 100 modelos de distintos fabricantes). La selección deeste RTOS se basó en la gran aceptación que tiene el mismo enla industria y en ámbitos académicos, y que los autores tienenexperiencia previa en el uso del mismo.

El proceso de desarrollo del firmware debe comenzar por ladivisión de la aplicación en distintas tareas que deben ejecutar-se en paralelo. A cada tarea se le debe asignar una prioridad,dependiendo de la importancia de que una tarea se comience a

ejecutar antes que otra tarea disponible para ejecución.La figura 4 muestra el flujo de ejecución de un sistema pre-

emptivo. Al comienzo se observa una tarea de baja prioridad enestado de ejecución (1). Luego, un evento asíncrono interrumpeel microcontrolador (2) para ser atendido por el servicio de in-terrupción (3). Al completarse la rutina de ISR, se invoca alkernel, el cual se encarga de ejecutar la tarea de mayor priori-dad (4). Esta tarea finaliza su ejecución al no ser interrumpida por una ISR (5), con lo que el kernel devuelve la ejecución a latarea de menor prioridad (6). De esta manera, el kernel aseguraque las tareas con temporizaciones criticas sean ejecutadas pri-mero.

Figure 4. Flujo de ejecución de un RTOS preemptivo

En uC/OS-II, las tareas pueden crearse y eliminarse demanera dinámica (con el fin de liberar recursos). Cada tareadebe tener su propio stack, con un tamaño suficiente paraalmacenar los datos de la tarea en el peor caso de ejecución,mas espacio extra para salvar los registros de estado del uC.

Como es difícil calcular a priori la cantidad de memoria quenecesitará cada tarea, el kernel provee un servicio para conocer la cantidad de stack que la tarea utiliza en tiempo de ejecución.Una vez obtenido este parámetro, se puede reservar el tamañoóptimo para cada tarea.

Para la comunicación entre tareas, uC/OS-II provee 3servicios: Semaphores, que pueden utilizarse como banderas ocomo llaves para reservar o bloquear algún recurso. Mailboxes, para enviar mensajes entre tareas. Y Queues, las cuales soncolas FIFO que pueden utilizarse para el envío de variosmensajes o manejarse como buffers [6].

B. División de las tareas

A partir de los bloques descriptos en la sección II, los procesos se dividen en 4 tareas, las cuales son:

• TaskLCD: encargada de visualizar la informacióncorrespondiente al estado del sistema en el display,refrescando periódicamente la pantalla.

• TaskTeclado: se encarga de responder a las teclas pulsadas, ejecutando acciones de acuerdo al estado dela aplicación (navegación por los distintos menús,configuraciones, estado de alarma, etc.).

• TaskAlarma: verifica el estado de las entradascorrespondientes a las fuentes de alarma y activa elenvío de la alerta en caso de detectarse una situación

de emergencia.

• TaskGSM: es la encargada del control del moduloGSM; envío y recepción de los comandos AT por medio de la interfaz UART, encendido / apagado delmodulo, control de la interfaz de audio hacia elmodulo, etc.

En la figura 5 puede observarse la organización del firmware.



166




Figure 5. Organización del firmware

Por otro lado, se crea una estructura llamada “Status” paraalmacenar distintas variables y flags para el control del sistema.Los elementos de la misma son enumerados en la tabla 1.

TABLE I. ELEMENTOS DE LA ESTRUCTURA “STATUS”

Variable: Descripción:

Alarma Estado de la alarma (ON/OFF)

Aviso Estado del aviso

Bateria Porcentaje de carga de la batería

Señal Nivel de señal de recepción de la red GSM

Call_ready Listo para realizar llamadas y enviar SMS

Iniciando_GSM Inicializando módulo y conectando a la red

Sim_not_present No se detectó tarjeta SIM

Mens_nuevo Nuevo SMS entrante detectado

Llam_en_progreso Realizando una llamada

Llam_entranteSe detectó una llamada para almacenar el

número

Num_config Número configurado para las llamadas

Menu Estado del menú

Timeout Tiempo restante para la grabación/reproducción

del mensaje de voz

C. Módulos adicionales

El kernel se configura de modo que solo se compilen losservicios que se van a utilizar con el fin de ocupar el menor espacio posible en memoria. Se deben adicionar módulos [8] para realizar la interfaz con los distintos periféricos:

• Para el escaneo del teclado se utiliza el módulo “KEY” provisto por uC/OS-II, el cual ejecuta una tarea de forma periódica almacenando en un buffer el historial de lasteclas pulsadas.

• La escritura en el display se realiza a través del módulo“LCD” que fue modificado para funcionar con 4 bits dedatos.

• Para la comunicación serial, se desarrolló un móduloUART. El mismo utiliza queues para el envío y recepciónde caracteres hacia el modulo GSM.

• Para el envío de los comandos AT y la interpretación de

las respuestas se escribió el módulo GSM, el cual proveeservicios tales como escribir un SMS, iniciar una llamadade voz, consultar el estado de la batería, etc. Este módulose comunica con la aplicación por medio de semaphores yqueues.

D. Funciones implementadas

Como se intenta maximizar la flexibilidad de utilización delsistema, se implementan varias funciones, a las cuales seaccede desde la interfaz de usuario:

• Configuración manual del número de teléfono deemergencia (ingresándolo por teclado).

•

Almacenamiento automático del número (con unallamada entrante desde el teléfono celular).

• Grabación o reproducción del mensaje de alerta.

• Configuración del SMS que se debe enviar ante lasdistintas situaciones de emergencia.

• Prueba de las distintas alarmas sin realizar ningunallamada.

• Consulta del crédito restante en el caso de que el chiputilizado corresponda a una linea de modalidad prepaga (esto puede realizarse mediante una llamadade voz o un SMS).

• En estado de espera, el display muestra el estado de laconexión a la red (activo/inactivo), el nivel de bateríay el nivel de señal que recibe el modulo GSM, como puede observarse en la figura 6.

Figure 6. Visualización del estado de espera.

Para la etapa de desarrollo del sistema, se diseño una PCB

(la cual se puede observar en la figura 7). La misma estácompuesta del uC, la interfaz de programación, y unconvertidor UART-USB para la visualización de lacomunicación del uC con el modulo GSM en un terminal dePC. A esta placa se fueron adicionando los distintos módulos(GSM, tarjeta SIM, teclado, LCD, interfaz de audio,alimentación y entradas).



167




Figure 7. Primer prototipo del sistema de emergencia

V. CONCLUSIÓN

Este trabajo describe el diseño de un sistema de emergenciaque utiliza la red GSM como medio de comunicación. Suinnovación radica en el uso de un RTOS para la programacióndel firmware. Durante el desarrollo del firmware ha resultadoevidente la gran diferencia entre programar este sistema

basándose en RTOS y realizarlo de la forma tradicional(foreground/background). Se simplifica mucho el control de lastemporizaciónes (gracias a los servicios que provee el kernel yla propiedad determinista del mismo). También se logra unafácil abstracción entre los distintos módulos y tareas,simplificando en gran forma la adición de nuevos elementos alsistema. De esta manera, se puede inferir que la dificultad de la

programación de este tipo de sistemas embebidos avanza deuna forma mas lineal con la complejidad del sistema que

realizando la programación de la forma tradicional.Luego de finalizado el desarrollo y depuración del

firmware, se realizaron varias pruebas respecto a la fiabilidaddel sistema, tanto alimentado desde la red eléctrica como desdela batería de soporte. Se lograron excelentes resultadosrespecto a la conexión del modulo a la red GSM, incluso enubicaciones de baja señal y con pocos cuidados en laadaptación de la antena conectada al módulo, con lo que elmódulo seleccionado cumplió las expectativas. Por otro lado, lacalidad del audio obtenido es satisfactoria en el modo “manoslibres”.

La configuración y utilización del dispositivo ha resultado bastante simple para personas ajenas el desarrollo, ya que la

navegación por el menú y las distintas configuraciones resultan bastante intuitivas y explícitas.

Debido a los resultados obtenidos, se puede inferir que elsistema desarrollado puede ser de gran ayuda en una amplia

variedad de situaciones de riesgo hogareño así como para personas con algún grado de discapacidad física ya que esfácilmente controlable por cualquier tipo de pulsador, y es degran ayuda en estos casos la funcionalidad de tipo “manoslibres”. Estos elementos lo hacen extremadamente flexible enuna gran variedad de aplicaciones, ya que el único elementoque se debe intercambiar en cada caso es el dispositivo dedisparo de la alarma.

AGRADECIMIENTOS

Se agradece la colaboración del Ing. Agustín Laprovita, elIng. Walter Lancioni, el Sr. Matias Díaz, el Ing. CarlosCenteno y a las Cátedras de “Sistemas Embebidos” y“Proyecto y Diseño” de la Facultad de Ingeniería - UniversidadCatólica de Córdoba, por los múltiples aportes que realizaronen el desarrollo de este trabajo.

R EFERENCIAS

[1] Huiping Huang, Shide Xiao, Xiangyin Meng, Ying Xiong, "A RemoteHome Security System Based on Wireless Sensor Network and GSM

Technology," nswctc, vol. 1, pp.535-538, 2010 Second InternationalConference on Networks Security, Wireless Communications andTrusted Computing, 2010.

[2] Kyriacou Efthyvoulos, Pavlopoulos Sotiris, Dimitris Koutsouris,Andreas Andreou A, Pattichis Costas and Schizas Christos,“Multipurpose Health Care Telemedicine System”, Proceedings of the23rd Annual International Conference of the IEEE/EMBS, Istanbul,Turkey 2001, 8.1:2-3.

[3] HaitaoJia, LiCao, “A remote data acquisition system based on SMS”,Proceedings of Systems, Man and Cybernetics, IEEE InternationalConference on San Antonio, TX, USA, 11-14 October 2009.

[4] David Andrews, Iain Bate, Thomas Nolte, Clara Otero-Perez and StefanM.Petters, “Impact of embedded systems evolution on RTOS use anddesign”, Proceedings of the 1st Workshop on Operating SystemPlatforms for Embedded Real-Time Applications, Palma, Mallorca,Spain, July, 2005.

[5] Labrosse, Jean J., “Designing with Real-Time Kernels”, Lawrence,Kansas, CMP Books, 2002 ISBN 0-87930-604-1.

[6] Labrosse, Jean J. “μC/OS-II, The Real-Time Kernel”, Lawrence, KansasR&D Technical Books, 1998 ISBN 0-87930-543-6.

[7] SimCOM, “SIM340 Hardware Design ”, SIMCom Wireless SolutionsLtd., 2009.

[8] Labrosse, Jean J, “Embedded Systems Building Blocks, Complete andReady-to-Use modules in C”, Lawrence, Kansas, R&D TechnicalBooks, 1995 ISBN 0-87930-440-5.

[9] Pattichis CS, Kyriacou E, Voskarides S, Pattichis MS, Istepanian R andSchizas CN , “Wireless Telemedicine Systems: An Overview”, IEEEAntennas & Propagation Magazine 2002, 44(2):143-153.

[10] Lombardi, P.; Giaconia, C.G.;Di Dio, V.;. “An embedded diagnosticsystem for wheelchairs brushless drives monitoring”. Paper presented atInternational Symposium on Power Electronics, Electrical Drives,

Automation and Motion (SPEEDAM 2006), Taormina.



168




Ventricular Fibrillation Detection Algorithm

Implemented in a Cell-Phone Platform

Michał Rospierski, Marcelo Segura, Martín Guzzo, Eduardo Zavalla , Cristian Sisterna and Eric Laciar

Laboratorio de Electrónica Digital (LED)Universidad Nacional de San Juan (UNSJ)

San Juan, Argentina

[email protected], [email protected] , [email protected] , [email protected] ,

[email protected] , [email protected]

Abstract — Due to their portability, computer capabilities and

widespread use in the society, current cell-phones can be used for

processing of other signals different than voice, like the

electrocardiogram (ECG) signals. In this work, it has been

implemented and evaluated an algorithm in a cell-phone in order

to detect a Ventricular Fibrillation (VF) in the ECG. It identifies

QRS complexes in the ECG and detects possible VF episodes by

the measurement of instantaneous cardiac rate. In case of

detecting VF, the cell phone will automatically send a Short

Message Service to pre-saved phone numbers asking for

immediate help. The developed algorithm could be used to create

an inexpensive and portable system based on a cell-phone that

can save lives. This work belongs to a global project which

includes sensors, signal acquisition, transmission to cell-phones

and alarm messages. The signal acquisition and transmission will

be implemented with low cost, low power current commercial

Systems in Package devices. These devices allow long lifeoperation, portability and wireless connectivity.

Keywords: Telemedicine, Ventricular Fibrillation, ECG, cell-

phone, on-l ine processing.

I. I NTRODUCTION

Nowadays cell-phones have become one of the mostcommon electronic devices which are owned by almosteveryone in our world. As a consequence of their portabilityand growing computer capabilities, they are used not only for communication purposes, but also for entertainment, socialnetworks, positioning systems, and many other applications.This paper explains the development of one particular application that takes advantage of these mobile devices tocreate a system that can save lives.

One of the most common causes of sudden death in patients

with cardiac diseases is Ventricular Fibrillation (VF). It is amalignant arrythmia characterized by a rapid heart rate and anuncoordinated contraction of the cardiac muscle of theventricles in the heart [1]. VF is usually diagnosed on the basisof electrocardiogram (ECG), which is the non-invasive register of the electrical activity of the heart.

In a VF episode, the ECG has the form of an irregular sinusoid with irregular shape and variable amplitude pulses, asit can be seen in Fig. 1. Heart rate in such situation can go from240 up to 600 beats per minute (bpm). In the case of a VF onlydoctor help could save the life of a patient. Using the current

mobile phone computer capabilities and network access, it is possible to design a powerful system to save people indangerous situations.

Figure 1 – VF in a recorded ECG

The aim of this work is to implement in a cell – phonemathematical algorithms which can detect VF in a recorded

ECG and in case of detecting VF automatically send a ShortMessage Service (SMS) to a pre-saved phone number asking

for immediate help. One of the most critical points to face and

resolve is the computing time to solve the mathematicalalgorithms to detect VF with the cell-phone computing

capabilities.

This paper is structured as follows. Section II describes the

selected VF detection algorithm. Section III details theimplementation and simulation of the VF detection algorithmdone in the MatLab environment. Section IV describes the

conversion from MatLab language code to Java PlatformMicro Edition (J2ME) language and checks the program

operation in an actual cell phone focusing on the processingtime of the ECG signal to detect VF. Section V details thevirtual machine environment used as a simulator. Section VI

goes through the tests in an actual cell-phone implementation.Finally, in Section VII, results and conclusions are described.

II. VENTRICULAR FIBRILATION DETECTION ALGORITHM

One of most simple criterion of VF recognition is based on

the measurement of cardiac rate [2]. Normal resting heart ratevaries between 60 to 100 bpm. However, heart rate during VFcan reach values from about 240 up to 600 bpm and even

higher [2].



169




The algorithm used in this work is based on a modified

version of QRS detector proposed by Pan and Tompkins [3]. Itdetects the QRS complexes in ECG signals using bandwidth,slope and pulse duration criteria. Fig. 2 is a graphical

representation of the basic steps of the algorithm.

Figure 2 - Block diagram of Pan and Tompkins algorithm

In the first step of the algorithm the ECG signal goes

through a band-pass filter to attenuate the P and T lowfrequency components of the ECG, remove baseline slowchanges or drifts and reduce 50/60 Hz line interference and

electromyographic high frequency noise. After filtering, thesignal is differentiated to amplify the QRS edges which aremuch steeper than the edges of the other ECG components.

Since after differentiation the signal has positive and negative points, it is then squared, getting a signal that has only positive

data points. Consequently, the steeper parts, which weredetected in differentiator filter, are amplified. However, theoutput of the squaring function will exhibit multiple peakswithin the duration of a single QRS complex. To smooth theresulting signal, the Pan and Tompkins algorithm uses a

moving window integration filter. After all these steps, thesignal is compared with a threshold value, set by the doctor. If the sample value is bigger than the threshold, its value is

assigned a “1”, on the contrary if the value is smaller than thethreshold a “0” is assigned to this sample. Meanwhile the QRSis being detected, ECG time intervals between two pulses

(named usually as RR interval) are measured and the cardiacfrequency is then calculated. If the cardiac rate is over a

specific limit, set by the doctor, it means that a possible VFepisode is detected.

III. MATLAB PROCESSING

A. Basic QRS complexes detection

A previous recorded ECG file extracted from MIT-BIHMalignant Ventricular Arrhythmia Database [4] was taken asan input, to detect the QRS complexes and then plot the results

of applying the Pan and Tompkins algorithm [2]. A .m file(MatLab file) takes in the file name and the samples numbers,

which are from the file to be processed. Sampling frequencywas set at 250 Hz, and a Butterworth band – pass filter secondorder with cut-off frequencies of 5 Hz and 70 Hz was

implemented by using (1).

(1)

Then, the filtered signal goes through differentiator filter

with following equation (2).

(2) Following the Pan and Tompkins algorithm, the next step

was to square the signal and then to apply the moving window

integration filter using (3) and (4):

(3)

(4)

Finally, the developed MatLab program carries out thenormalization and finds the pulses, which have bigger valuethan a threshold value. The resultant output vector contains the

same amount of samples that the input vector, but it only has“1” and ”0” values. A “1” means that a QRS complex has been detected, otherwise is “0”.

Fig. 3 depicts the different stages in the Pan and Tompkinsalgorithm implemented in MatLab and their respective

resultant waveforms. In the plot of the bottom it can be seenthe QRS marks after processing the ECG in MatLab.

B. VF Detection Sample Buffers

Once the QRS complexes were correctly detected, the

next step was to calculate the cardiac frequency. For this purpose the output vector of QRS was converted to a vector of sample numbers, for which QRS has been detected, and then,

the number of samples, which are beginnings of pulses, arefound. Subsequently, the program counts the difference

between two beginnings of pulses and puts the result into avector named RR (time intervals between pulses).

Figure 3 – Different stages in the Pan and Tompkins algorithm implemented

in MatLab. From top to bottom: original ECG, filtered signal, differentiated

waveform, squared signal, moving integrated signal and QRS marks



170




Dividing values from RR by sample frequency gives the

difference in seconds. Finally, the output vector computes theinstantaneous cardiac frequency (beats/min) accordingly to(5).

(5) After calculating the cardiac frequency ( F

c), the decision

of VF detection is taken after than the F c exceeding the

threshold frequency. In this work, a VF episode is consideredif at least 3 consecutive cardiac cycles have F c values over 240

bpm [2]. However, the number of cardiac cycles and thethreshold frequency for VF detection are programmable by thecardiologist according to the medical history of the patient.

In order to optimize the signal processing, the ECG record

is divided into 3 second windows moving in 1 second steps.The program seeks for a VF episode in a 3 second window in

which it is looking for a bad cardiac frequency to then startanalyzing every second of the ECG. Every second a newsearch starts. It can give enough time to be sure that a VF is

happening (because of the 3 seconds window) and it also candetect it quickly enough (because of 1 second move).The other

advantage of this method, illustrated in Fig. 4, is that the firsttwo seconds of any next window has been already analyzed,so it is possible to use buffers to process and analyze only the

unprocessed one second. It has to be pointed out that thewritten program always analyzes last 50 samples from the preceding second to avoid processing problems related tostarting filters.

C. Results of MatLab implementation

As it was mentioned before, a previous recorded ECG file

extracted from MIT-BIH Malignant Ventricular ArrhythmiaDatabase [4] was taken as an input (3000 samples, 12seconds). This was used to be analyzed by the algorithmsimplemented in MatLab. Fig. 5 details the different

waveforms obtained after passing the ECG input through thedifferent stages of the implemented algorithm.

Figure 4 - Representation of the signal segmentation process

Figure 5 - Example of a 3 second window of ECG signal with the transition of

normal heart rhythm and the beginning of a VF episode At the bottom of Fig. 5, the plot “QRS pulses” shows the

detection of the QRS complex, red dotted line. At the end of

the plot, the detection of an increase of the cardiac frequencycan be clearly seen, successfully detecting a VF episode. Table1 shows the instantaneous cardiac frequency results using (5).

Table 1 - Instantaneous cardiac frequency

computed by the algorithm

Fc [beats / minute]

77.7

58.6

312.5

394.7

500.0

300.0

333.3

IV. J2ME I NTERPRETATION

As a previous step to run the application on the cell-phoneit was necessary to use J2SE to translate the algorithms

developed in MatLab to a language closer to the cell-phonelanguage.

Java Platform Micro Edition is a specification thatdescribes a simplified version of the Java platform. Java ME

Platform is designed for devices with very limited resources,such as mobile phones or PDAs. Due to technical limitations

of such devices, i.e., slower processors, less memory, Java MEhas its own reduced in relation to a set of Java classes calledthe Standard Edition (SE) configuration. Configurations arecomplemented by profiles that add to the existing classes of their own class to ensure the execution of specific tasks for

specific devices. Profiles can therefore be enhanced withoptional packages. Such as a variety of ApplicationProgramming Interfaces (APIs) allows designers and



171




developers great flexibility in creating software for devices

with different hardware configurations [5].

The cell-phone used for this project is a Sony Ericsson

W300i. Fig. 6 shows the Java features and functionalities of this phone.

Figure 6 - Java features on the Sony Ericsson W300i

It is equipped with internal memory up to 20 MB with possibility of adding external memory as a Memory Stick

Micro; it also has Bluetooth wireless technology. Some of thementioned functionalities of this phone were not used in the present work; however, they will be very useful for the next

development continuing the current one.

A. Declared Methods

To be able to carry out all the mathematical calculation inJ2ME, one class and several methods were written in the J2SE

platform, which are later invoked within the Java programwritten in J2ME [5].

Fig. 7 is a flow diagram of the Java algorithm of the VFdetection implemented in the cell phone.

Buffer with samplesK=0

K<Number of

WndowsStop

K=0

Copy of 350Samples

Copy of 750Samples

FilteringK>0Copy from

Window Buffer

Copy to

Window Buffer

Finding Pulses and CFCalculation

Recognition and Decision

Display ResultsIncrease Buffer Index

K= K+1

Start

Class ObjectNumber of Windows

Parameters Transfer

No

Si

No

Figure 7 - Flow diagram of the Java VF detection algorithm

B. VF Detection Application

The application that runs in the cell phone begins

reading a configuration file, previously recorded, whichcontains the parameters used for the VF detection and thetelephone number to send the SMS for help. Then, an option

for starting detecting or go to administrative tasks is displayed.

Selecting “Detect” will start the VF detection algorithm,

displaying on the cell-phone display the average cardiacfrequency and whether a VF has been detected. In case of detecting a VF the program automatically sends an SMS to the phone number in the configuration file and with the message

saved in the msg.txt file adding the hour and date of detection.

After sending the SMS, the program goes back to continuedetection. Fig. 8 shows graphically what was explained above.

Selecting the option Admin, the administrative options areshown. Among them are change the password, check configuration, and data directories. Of course all of these

options can be changed to fit different needs.

Figure 8 – VF detection application flow in the cell-phone V. VIRTUAL MACHINE SIMULATION R ESULTS

For the virtual machine simulation the Sony EricssonW300 simulator was used [7]. A configuration file was createdwith the values shown in Table 2.

Table 2 - Values of the different variables in the configuration file

Variable Value

Cardiac frequency threshold 250

QRS signal level threshold 0.55

Threshold of high cardiac frequencies in

window3

Threshold of windows with high cardiac

frequencies for sms3

Telephone number 5550001

The values used for the configuration file shown in Table2 are the same values used in J2SE and MatLab tests. Two

virtual cell-phones were used in the virtual machine simulator,one carries out the VF detection algorithm, and sends the SMS



172




in case of a VF detection, and the other cell-phone is the

receiver cell-phone, which will receive the SMS. Hence, the phone number used in this case, Table 2, is a number thatallows communicating two virtual cell-phones.

Fig. 9 shows the msg.txt template file used in this test, 78

characters have been used to write the most importantinformation about the patient, cell-phone owner, to be sent by

SMS to the destination number.

Figure 9 - msg.txt template with the data to be sent by SMS

Fig. 10 is a screen capture of the two Sony Ericsson cell- phones in the virtual machine simulation environment. Theone on the left is running the VF detection algorithm, showing

a VF detection alert message as well as sending SMS message.The cell-phone on the right is the destination cell-phone,doctor’s cell-phone for instance, that displays the received

SMS due to the detection of a VF in the patient’s cell -phone(the one on the left). The testing results were the same results

obtained in the J2SE and MatLab environments.

I. R EAL CELL-PHONE IMPLEMENTATION

Having succeeded in the previous simulation, the next step

was to implement the VF detection algorithm in a real cell- phone. The main challenge in this step is the time invested to

process the VF detection algorithm. Therefore, careful tests

Figure 10 - Virtual machine simulation

were developed to have a precise idea of the time processing

the algorithm. The results of the test for the time needed to runthe VF detection algorithm is shown in Table 3.

Table 3 - Calculation time per window in real cell-phone

Window Number Time for Window [ms]

1 183

2 77

3 77

4 77

5 79

6 81

7 SMS

8 86

9 77

10 83

The other factor that is very time consuming during thecalculation process is presenting the calculation results on thecell-phone display. Adding this time, the time results shown in

Table 3 increase in approximately 50% with regards the timeobtained without displaying the results. Even though this high

percentage of increasing the time per window when displayingthe results, they are still short enough to conduct efficient VFrecognition with the proposed algorithm.

II. CONCLUSIONS

In this work, it has been implemented and evaluated analgorithm to detect a Ventricular Fibrillation (VF) in a cell-

phone. The application in the cell-phone was able to open anECG digitized text file, process the samples, make the rightdecision about ventricular fibrillation and in case of

emergency send SMS to a hospital or a cardiologist for help.Moreover cell-phone was able to display current cardiacfrequency of every window. The configuration file offers an

easy way to change recognition parameters, very useful inadjusting analysis to specified patient and ECG detection

conditions, and to change SMS contents, the SMS can containup to 129 characters.

Analyzing the obtained results it is possible to say that acell-phone, in this particular case the Sony Ericson W300i,

has enough computational power to perform efficientventricular fibrillation recognition with the proposed

algorithm. Average time for window calculation, without thefirst window, is 79.65 ms, 127 ms with displaying results;what is much faster than it was expected.

The flow followed with the different programming

environments was a real success. At the beginning it washelpful to use built in signal processing MatLab libraries.Translating code from MatLab to J2SE was simple. Finally



173




translation to J2ME brought a lot of effort to create manually

methods which are not available for this type of Java. It was beneficial to use J2SE before J2ME.

Future works are based first on using a more reliableconnection to send the request for help, like a General Packet

Radio Service (GPRS) or High-Speed Downlink PacketAccess (HSDPA) for Global System for Mobile

Communications (GSM) or Universal MobileTelecommunications System (UMTS) respectively; second onusing a cell phone device with Global Positioning System

(GPS) to send the localization of the patient to rescue service,third on adding portability to the code, so it can be used byany cell-phone. Another feature to add is to offer different

options for detecting other heart anomalies besides the VF.

R EFERENCES

[1] A. J. Bayés de Luna. “Arritmias, concepto, mecanismos y clasificación,”in Electrocardiografía Clínica. Ediciones Espaxs, Barcelona, 1999.

[2] E. Laciar Leber and M. E. Valentinuzzi. “Chapter 4: Ventricular fibrillation detection,” in Cardiac Fibrillation-Defibrillation. Clinical and

Engineering Aspects by Max E Valentinuzzi, World ScientificPublishing Co, 2010.

[3] J. Pan, W.J. Tompkins. “A real-time QRS detection algorithm”, IEEE

Trans. Biomed. Eng., 32: 230-236.

[4] MIT-BIH Malignant Arrhythmia Database, freely available inhttp://www.physionet.rg/physiobank/database/vfdb/

[5] Sing Li and Jonathan Knudsen, Beginning J2ME: From Novice to

Professional. Third Edition, APRESS, Srpinger-Verlag New York, 2005.

[6] B. Eckel, Thinking in JAVA. Third Edition. Prentice Hall, 2002

[7] Sony Ericsson Developers Platform: http://developer.sonyericsson.com



174






175




POSTERS



176






177




Arquitecturas

de

Microcontroladores



178






179




“Comparación del desempeño de microcontroladores AVR de 4tageneración”

David M. Caruso; Salvador E. TropeaInstituto Nacional de Tecnología Industrial - Electrónica e Informática

Avenida General Paz 5445 entre Albarellos y Constituyentes, Edificio 42,CC157 (CP 1650) San Martín, Bs. As., Argentina

david,[email protected]

Nuestro equipo de trabajo desarrolló un microcontrolador ciclo a ciclo compatible con los microcon-

troladores AVR de 4 generación. El mismo fue ampliamente validado con varias aplicaciones usando

FPGAs. A los fines de comparar su desempeño con el de otros microcontroladores se decidió correr

un benchmark en el mismo.

Para esto se utilizó el benchmark Dhrystone versión 2.1. A pesar de que existen otros benchmarks

más representativos este es el más utilizado por los fabricantes, aún hoy en día.

La originalidad de este trabajo, radica en el hecho de que no puede implementarse el Dhrystone en

microcontroladores AVR de 4

generación, dado que no poseen la suficiente memoria RAM. Si bienes probable que dicho benchmark pueda ejecutarse en AVRs de 5 generación (ej. ATXMega256), los

resultados serían menos representativos. Por otro lado no se pudieron encontrar resultados publicados

del Dhrystone para ningún AVR (no confundir con AVR32).

Debido a que los bloques de memoria son un recurso escaso en FPGAs de bajo costo, sólo algunos

cientos de kilobits, es deseable utilizar memorias externas para el programa a ejecutar. El uso de

memorias flash externas, trae aparejada una latencia dada por el cambio de página de la memoria, que

limita la frecuencia de operación máxima. Para aliviar esta situación se agregó un core intermedio

entre el AVR y la memoria, que le permite leer, a la máxima velocidad por página, optimizando los

tiempos de cambios de página. El conjunto del core con la memoria, se puede entender, en una forma

muy simplificada, como un sistema de "memoria caché".

Se obtuvieron distintos resultados de desempeño, para el microcontrolador con memoria interna, ex-

terna y con el sistema de memoria caché. Dichos resultados indican que el AVR tiene un desempeño

que es comparable o superior a una CPU 80286 (PC AT 286).



180




"Anemómetro Ultrasónico 3D empleando ArquitecturasAnalógica-Digital Reconfigurables"

Montoya Walter*; Rogel Fernando*; De Marziani C. *#;

Alcoleas, R. *; Colombo, A*.

*Dto. de Electrónica, Facultad de Ingeniería, Univ. Nacional de laPatagonia San Juan Bosco

#CONICET, Consejo Nacional de Investigaciones Científicas y Técnicas.

Diversas actividades del hombre están vinculadas con la meteorología: transporte aéreo y

terrestre, medicina, energía eólica, agricultura, turismo, pronósticos de alertas, etc. La

meteorología implica la medición de parámetros físicos básicos tales como: presión

atmosférica, temperatura, humedad, dirección y velocidad del viento, visibilidad y

precipitaciones.

Para determinar la velocidad y dirección del viento habitualmente se emplean sistemas

mecánicos que necesitan un mantenimiento continuo y son muy sensibles a daños, particularmente en la zona Patagónica donde los vientos son característicos por su

agresividad.

En los últimos años han surgido anemómetros que emplean sensores ultrasónicos que, al no

tener partes móviles, requieren de un mantenimiento menor. El principio de funcionamiento

consiste en determinar el tiempo de propagación de la señal ultrasónica en el aire y analizar

la velocidad del mismo relativa a la velocidad del sonido, conociendo la distancia entre

sensores. El principal inconveniente de este tipo de anemómetros es su elevado costo

comercial.

En este trabajo se presenta el desarrollo de un anemómetro ultrasónico 3D de bajo costo a

partir del empleo de arquitecturas analógico-digitales reconfigurables PSoC de Cypress®.

Así, es posible realizar el acondicionamiento y procesamiento de señales con un mismo

circuito integrado sin necesidad de incrementar excesivamente el hardware a implementar

reduciendo los tiempos de diseño. Al tratarse de sistemas reconfigurables es posible

introducir mejoras sin necesidad de modificar el hardware implementado. Las pruebas

experimentales realizadas en laboratorio demuestran que la arquitectura propuesta permite

obtener una adecuada precisión en la medición de la velocidad y dirección del viento.



181




ASICs



182






183




“Detector Activo de Corrientes de Fuga”

Matias Bulacio; Tomás González; Ramiro Alonso; Guido Marinelli; Dr. Hernán Tacca; Dr.Ariel Lutenberg; Dr. José Lipovetsky

LABCATyPDepartamento de Electrónica

Facultad de Ingeniería

Universidad de Buenos Aires

En instalaciones eléctricas industriales y hogareñas se utilizan dispositivos que detectan corrientes

de fuga a tierra, llamados disyuntores. Estos equipos cortan la alimentación de la red en caso de

producirse una falla protegiendo equipos y vidas humanas. Su funcionamiento se basa en la medición

de un desbalance de corriente entre las líneas de alimentación de los equipos por lo que el sistema a

proteger tiene que estar en funcionamiento para poder detectar la fuga. Estos dispositivos son lentos,

no son capaces de detectar fugas pulsantes y debido a su tiempo de respuesta son ineficaces para

proteger dispositivos electrónicos, como por ejemplo los transistores de potencia en variadores de

velocidad de motores.

Dadas las deficiencias de los disyuntores, se desarrolló un dispositivo capaz de detectar corrientes defuga antes y durante la puesta en marcha de los equipos e instalaciones eléctricas, con un tiempo de

respuesta que permite resguardar los dispositivos electrónicos.

La solución desarrollada consiste de dos partes, un circuito que inyecta una señal pulsante de alta

frecuencia en la línea de alimentación de un equipo y un circuito detector de la misma en caso de

fuga. Ambos circuitos, inyector y detector, se integran en un único chip de silicio con la tecnología

XC06 de XFAB (se enviará a fabricar a mediados de diciembre). La inyección y sensado en la línea

de potencia se realiza mediante aislación galvánica externa al circuito integrado (transformadores

de pulsos). Esto provee seguridad y cubre las necesidades del producto propuestas anteriormente.

Este dispositivo posee umbrales de sensibilidad ajustables para permitir su portabilidad a distintas

aplicaciones.



184




Fabricación de un circuito integrado digital conversor Serie-Paralelo y Paralelo-Serie en un

proceso CMOS de 0.5 μm

Barbeito, P.; Carrá M.; García Inza M.Seminario de diseño y fabricación de circuitos integrados en tecnología CMOS.

Departamento de electrónica, Facultad de ingeniería, Universidad de Buenos Aires

Con el avance de la tecnología y de la capacidad de procesamiento la cantidad de bits por

palabra continúa creciendo. Hoy es común trabajar en 32 o hasta 64 bits e intentar acceder a

estos bits en paralelo presenta una serie de inconvenientes. Por ejemplo al aumentar la

cantidad de pines del encapsulado aumenta el costo de este, aparecen inconvenientes en el

ruteo y la velocidad de transferencia se ve limitada debido al efecto de crosstalk.

El transmitir la información en forma serial a través de un solo pin resuelve o mejora

substancialmente estos problemas, permite reducir la cantidad de pines necesarios en el

encapsulado y aumenta la flexibilidad en cuanto a cantidad de bits por palabra.

El objetivo de este trabajo es presentar el diseño, fabricación y posterior validación de las

mediciones realizadas en los circuitos fabricados de dos módulos de conversión, serie-paralelo

y paralelo-serie, que permiten transmitir ó recibir una serie de bits y presentarlos

internamente en un circuito integrado en forma paralela.

Los bloques fueron fabricados en el proceso CMOS AMI C5 de 0,5um de longitud de canal al

que se accede a través del consorcio MOSIS.

Cada bloque posee una serie de pines de control (como ser reset, clock y enable de salida) que

permiten trabajar con estos de manera simple desde el interior del circuito integrado y desde

el exterior para poder usarlo de interfaz con otros integrados.

Estos bloques de circuito integrado forman parte de una librería que está disponible para

futuros proyectos del seminario y laboratorios de investigación de la facultad de ingeniería de

la universidad de Buenos Aires.



185




FPGA, Verilog,

VHDL y HDLs



186






187




“Control Automático de Ganancia sobre un CPLD”

Guillermo M. Gancio.Instituto Argentino de Radioastronomía I.A.R. CONICET.

[email protected]

El I.A.R. cuenta con dos antenas parabólicas de 30mts de diámetro para uso radioastronomico. Una de

ellas utiliza un receptor criogénico refrigerado a 15oK (-258oC) operando en una frecuencia centralde 1420Mhz(HI). Estas pequeñas señales de radio, deben ser acondicionadas a niveles de potencia

predeterminados por la configuración utilizada por el receptor, es por ello necesario que uno de los

módulos sea responsable del control automático de ganancia del sistema.

Este módulo debe controlar una serie de atenuadores digitales, tener la capacidad de recibir una señal

de referencia externa que utilizará para el ajuste de nivel y además, la capacidad de poder operarse

de forma manual o remota mediante una PC. Al evaluar las opciones se decidió realizar este control

utilizando un CPLD implementando la solución en lenguaje VHDL. El hardware se dividió en 3

secciones principales: a)Etapa de atenuación; b)Etapa analógica; c)Etapa digital.

Parte fundamental de la etapa digital es el código VHDL, el mismo se dividió en funciones reducidaspara realizar los testbenchs de forma más eficiente; estas tareas se dividen en: a)Interfase usuario;

b)Control externo; c)Control atenuadores digitales. Cada módulo en VHDL fue simulado utilizando

las herramientas de desarrollo de la firma Xilinx. Luego de verificar las simulaciones se procedió con

la implementación de un módulo completo logrando mediciones que permitieron validar comparati-

vamente el funcionamiento esperado del módulo. También se presentan las medidas realizadas con el

control automático de ganancia integrado a la cadena del radiotelescopio.



188




“Aplicaciones de FPGA de tecnología flash al control de

motores eléctricos de corriente alterna” Bulacio Matías F.; Arias Ricardo; Tacca Hernán E.

LABCATyP

Departamento de ElectrónicaFacultad de Ingeniería de la Universidad de Buenos Aires

En la industria, los motores asincrónicos trifásicos son alimentados y controlados porvariadores de velocidad. Estos últimos reciben información de control y diagnóstico, talescomo puesta en marcha, parada, cambio de set-point desde la estación de supervisión o,tales como el estado de falla, velocidad angular, temperatura desde el motor.

Ésta realimentación de información se realiza convencionalmente mediante cableadoadicional que no solo puede ser costoso, sino que muchas veces puede ser complicado ohasta imposible de realizar debido al difícil acceso al lugar donde debe ser instalado.

Es por esto último que este trabajo se enfoca en la utilización de la línea de potencia comocanal de comunicación (PLC, Power Line Communication), evitando el cableado adicionalpara la supervisión y comando.

Con el fin de lograr el objetivo de aprovechar los cables de la línea de potencia para lasupervisión y comando de los motores de inducción se realizará mediante la FPGA unsistema de inserción y detección de señales en la línea trifásica.

Además se deben aprovechar los transformadores y sensores incluidos, para implementarlas funciones de protección habituales en variadores de velocidad (sobrecarga, detección de

cortocircuitos, fallas de aislación, circulación de corrientes parásitas a tierra, etc.). En estepunto el uso de la FPGA permitiría actuar más rápidamente ante la presencia de una falla,protegiendo no solo a la máquina eléctrica sino también a los dispositivos de potencia(IGBT’s).



189




“Montaje de Experimentación para Óptica AdaptativaAstronómica con FPGA”

Rodríguez Brizuela F.1; Verasay J.P.1; Recabarren P.1,2 (1) Facultad de Ciencias Exactas, Físicas y Naturales, UNCba

(2)Instituto de Astronomía Teórica y Experimental (CONICET),Có[email protected], [email protected]

Las variaciones de densidad de los gases de la atmósfera terrestre afectan el frente de ondade luz originado en un objeto celeste a ser observado desde la Tierra. Esto produce erroresen la fase del frente de onda, imponiendo una limitación a la calidad de las imágenes quelos telescopios pueden obtener.

Las Ópticas Adaptivas son sistemas de Control a Lazo Cerrado, de Tiempo Real, que a partir del sensado de las aberraciones que sufre un frente de onda, actúan modificando lageometría de la óptica del telescopio, compensando así las deformaciones que la atmósfera

produce en las imágenes, a una frecuencia del orden del KHz.

En este trabajo se presenta un montaje experimental destinado al ensayo de software paraÓpticas Adaptivas astronómicas, basadas en tecnología FPGA, que consiste en el sensado

por imagen, del error de posición de un haz láser proyectado sobre una pantalla,realimentado al sistema de control basado en una FPGA Xilinx Spartan 3E, el cual actúasobre un espejo móvil, corrigiendo la trayectoria del haz, manteniéndolo en la misma

posición. La posición del haz es obtenida a partir del digitalizado de la señal de video deuna cámara CCTV.

El montaje realizado permitirá ensayar diferentes algoritmos de control, presentándose unaversión inicial en VHDL, para pruebas de funcionamiento del conjunto.



190




Implementación de MODBUS en FPGA mediante VHDL

– Capa de Enlace – Olmedo Sergio 1, Guanuco Luis 1, Panozzo Zénere Jonatán 1, Rubio Agustín 1

1-Centro Universitario de Desarrollo en Automación y Robótica “CUDAR” Universidad Tecnológica Nacional - FRC

Córdoba, Argentina

La descripción de hardware, mediante la programación en VHDL, permite una amplia

versatilidad en el diseño de circuitos digitales. Se presenta una descripción sobre la

realización de una comunicación entre dispositivos lógicos programables, según el

protocolo MODBUS. Este estándar de comunicación, de amplia aceptación, define

protocolos para las capas de “Aplicación”, “Enlace” y “Física”. En esta presentación se

aborda el desarrollo del mismo la “Capa de Enlace”, y de manera resumida la forma en que

esta interactúa con las otras capas

El desarrollo de un protocolo estándar de comunicación se basa en una jerarquía con

diferentes niveles de abstracción para el tratado de la información, lo que implica variadasformas de implementación tanto hardware como software. El modelo OSI es un marco de

referencia para la definición de arquitecturas de interconexión de sistemas de

comunicaciones.

El protocolo MODBUS define la comunicación serie entre un único dispositivo Maestro y

entre uno a 247 Esclavos. En el caso de haber un único Esclavo, la comunicación se

denomina “punto a punto” y si existe más de un Esclavo, la comunicación es “multipunto”.

La generación de una trama MODBUS comienza con el envío de un caracter que define el

principio de la misma. En forma consecutiva se transmiten los campos de dirección, función,

datos, chequeo de error LRC y para terminar los caracteres de fin de trama

Con las especificaciones de MODBUS y modelado de hardware en VHDL se logradiferenciar componentes que trabajan en forma concurrentes y procesan los datos para la

utilización en una capa superior o inferior como lo define el modelo OSI. La

implementación se realiza en una FPGA Xilinx Spartan 2E XC2S200E, donde el banco de

pruebas se adaptó una línea serie mediante RS232 conectando entre sí dos FPGA. Uno de

ellos implementados como Maestro y el otro como Esclavo.

La implementación de MODBUS en sistemas embebidos, presenta una preferencia en la

utilización de microcontroladores para llevar adelante su desarrollo. Sin embargo, la

descripción de hardware permite la flexibilidad en el diseño de sistemas de comunicación

digital, dado que el mismo se realiza independientemente del dispositivo a utilizar, por lo

que se logra portabilidad en la implementación sobre PLDs. La concurrencia otorga unmejor aprovechamiento del tiempo, que se traduce en mayor velocidad de operación, en

desmedro de una utilización de recursos también mayor.



191




“Implementación en FPGA de Ruido Gaussiano para simulaciones enHardware”

L. De Micco; H. A. LarrondoDepartamentos de Física y de Ingeniería Electrónica,

Facultad de Ingeniería, Universidad Nacional de Mar del Plata,Av. J. B. Justo 4302, 7600 Mar del Plata, Argentina.

CONICET

El canal con ruido gaussiano es un estandard en la evaluación de todo sistema de comunicaciones ya

que constituye una buena aproximación a muchos canales reales. Los generadores de ruido gaussiano

constituyen entonces un equipamiento básico para la medición de los actuales sistemas digitales.

La mayoría de los métodos de generación propuestos parten de una serie temporal con histograma

constante (PDF uniforme). Aplicando luego el algoritmo de Box-Muller se obtiene la serie temporal

con PDF gaussiana. Un inconveniente para la implementación en hardware del algoritmo de Box-

Muller es que requiere la implementación de las funciones sinusoidal y logarítmica. En este trabajo

se propone una metodología que permite la implementación en FPGA de un generador de ruido con

una PDF deseada, a partir de un mapa caótico sintetizado. La PDF es aproximada por tramos. Da-da la importancia de los generadores de ruido gaussiano apuntada arriba, en este trabajo se aplica la

metodología propuesta para la obtención de una primera aproximación a la PDF Gaussiana. La imple-

mentación en hardware se realizó utilizado una FPGA Cyclone III EP3C120F780C7 de ALTERA c,

el diseño ocupa sólo 6% de los elementos lógicos del dispositivo y utiliza 26% de memoria RAM.

Para la representación numérica se emplea arquitectura de punto flotante IEEE754 no sólo para con-

seguir una mejor precisión sino también para facilitar la utilización en sistemas digitales que utilizan

esta representación.



192






193




Implementación

de

Sistemas Embebidos



194






195




Sistema para medición optoelectrónica del secado de pinturas

Ezequiel Rubinsztain1; Ariel Lutenberg

1; Fernando Perez Quintián

2, 3

1GLOmAe, Departamento de Física, Facultad de Ingeniería, Universidad de

Buenos Aires (Argentina)2Departamento de Física, Facultad de Ingeniería, Universidad del Comahue

(Argentina)3CONICET (Argentina)

En este trabajo se presenta un sistema opto-electrónico para la medición del secado de

pinturas. El diseño propuesto está compuesto por un diodo láser, un sensor de luz CCD

lineal y un microcontrolador dsPIC30F4011, que realiza el control y el procesamiento de

datos.

La evolución temporal del patrón de speckle producido por la dispersión del haz láser en la

pintura se captura mediante a una cámara CCD lineal, se procesa y se transmite vía RS232 a

la PC. Mediante la aplicación de algoritmos de procesamiento de señales se puede extraer información de las imágenes vinculadas al estado de secado y así analizar las características

de la pintura o proveer información en tiempo real sobre el proceso de secado de la pintura.

El microcontrolador dsPIC30F4011 se utiliza como C.P.U. del sistema y se aprovechan las

ventajas que ofrece: Instrucciones de tipo DSP, velocidad de 30 MIPS y un conversor A/D

de 1Msample. El sistema fue probado con éxito para el estudio de esmalte, látex, líquido

corrector, etc. y se desarrollaron nuevos algoritmos para procesamiento en tiempo real de la

información.



196




“Kit Educativo Basado en Microprocesador de 32 Bits”

Salituri Juan I.; Juárez José M.Facultad de Ingeniería de la UNLP

Facultad de Ingeniería de la UNLP – Facultad de Ingeniería de la UNQ [email protected]

El presente proyecto forma parte de un trabajo final de carrera y tiene como

objetivo principal diseñar e implementar una placa de desarrollo basada en un

microcontrolador de 32 bits orientada al ambiente educativo. La motivación del

mismo surge de la necesidad de disponer de una plataforma flexible para exponer

de forma práctica algunos de los conceptos teóricos desarrollados durante la

formación académica de los alumnos, en particular aquellos que incluyen lossistemas embebidos.

Tras una búsqueda y estudio de diversos microcontroladores se decidió utilizar el

LPC2368 de la firma NXP debido a su disponibilidad en el mercado nacional y a

las prestaciones del mismo. Este microcontrolador se basa en un procesador

ARM7TDMI-S de 32 bits capaz de trabajar hasta una frecuencia de 72MHz.

La etapa de diseño se concentr ó en tratar de lograr una disposición de periféricos

capaz de conseguir la mayor funcionalidad y flexibilidad posible al mismo tiempo.

Fue necesario considerar que el kit será de uso educativo por lo que se debiótomar los recaudos necesarios de forma de evitar daños del mismo ocasionados

por errores de los alumnos durante la etapa de aprendizaje.

La etapa de implementación incluyó tanto el desarrollo del PCB en cuatro capas,

como el montaje de los componentes, en su mayoría SMD, y el desarrollo de

firmware para testeo de la plataforma.

La potencialidad del microprocesador seleccionado y la amplia gama de

periféricos que este dispone permitirán al usuario implementar una cantidad

importante de aplicaciones e incursionar en los sistemas operativos de tiempo

real.



197




“Sistema de adquisición de datos para estudios

interferométricos”

Antón L.1, Terán G.

1, Lutenberg A.

1, Perez Quintián F.

23

1GLOmAe, Facultad de Ingeniería, Universidad de Buenos Aires

2Departamento de Física, Facultad de Ingeniería, Universidad del Comahue

3CONICET

Un interferómetro heterodino es un sistema óptico que permite la caracterización

de materiales mediante ensayos no destructivos. Esta técnica se utiliza, por ejemplo, enlas industrias petrolera y de la construcción, para medir porosidad de rocas, vibraciones

en estructuras, características de hormigones, entre otras aplicaciones.

La salida del interferómetro es una señal modulada en fase. El objetivo de este proyecto es diseñar y construir un equipo capaz de demodular esta señal, digitalizarla y

transmitir el resultado a una PC para su tratamiento.

El sistema consta de una etapa de adaptación de entrada, una de demodulación dePM, una de digitalización y almacenamiento y una etapa de salida de datos. La

demodulación se lleva a cabo mediante un PLL de frecuencia central de 70MHz y anchode banda tal que permita demodular una señal de frecuencia máxima de 10MHz. La

digitalización se realiza mediante un conversor A/D de 8 bits a una tasa de muestreo de

50Msps para asegurar una buena calidad de salida. El sistema posee una memoria que permite almacenar los datos correspondientes a un ensayo de 10 milisegundos de duración.Finalmente, los datos son transmitidos a un ordenador mediante un microcontrolador coninterfaz USB. Este proyecto incluye, también, el desarrollo de un software para el control de

las mediciones y recepción de los datos producidos por las mismas.

El prototipo del proyecto se encuentra en etapa de prueba. Se presentarán resultados de

las mediciones realizadas para la verificación del funcionamiento del mismo.



198




ANOTADOR BRAILLE ELECTRÓNICO PARLANTE Cayuela P.; Monardez G.

Centro Universitario de Desarrollo en Automación y Robótica (CUDAR)

Universidad Tecnológica Nacional, Facultad Regional Córdoba

Córdoba, Argentina

[email protected]

Se planteó la realización de un prototipo de anotador braille electrónico, de bajo costo de

producción, que en caso de no ser gratuito para ciegos, por falta de financiación de

organizaciones gubernamentales o similares, sea accesible su compra, dado que en el

mercado internacional su adquisición se hace prohibitiva por su alto costo, única fuente

actual para los ciegos de Argentina.

A partir de este problema, se planteó y desarrolló con éxito un anotador electrónico braille

portátil. Este permite el ingreso de texto mediante un teclado braille, que luego debe

descargarse en una PC para ser reproducido por un software especial de síntesis de voz.

Esto se logró con creces, dado que empleamos tecnología electrónica de fácil acceso y bajo

precio para Argentina, permitiendo la construcción de un anotador completo por un costo de

alrededor del 10% del valor de un aparato de importación.

Este aparato fue sometido a pruebas de rigor en instituciones educativas para ciegos. El

resultado mostró que los usuarios requieren de un retorno o método de revisión directo de

los textos ingresados al equipo.

Por ello se planteó la incorporación de tecnología de síntesis de voz al anotador braille

electrónico previamente desarrollado. El nuevo anotador servirá de verdadera alternativa

ante los aparatos importados y permitirá a la persona ciega tomar notas a través de un

teclado con disposición braille, almacenarlas y recuperarlas mediante síntesis de voz donde

sea que lo necesiten.

En este momento estamos probando los primeros prototipos con sintetizador de voz por

hardware incorporado al anotador braille electrónico, con lo cual, el aparato será también

parlante.



199




“Esquema de control de un microdisplay LCD”

Burman A.1, Garea M.T.1, Lutenberg A.1, Perez Quintian F.231GLOmAe, Facultad de Ingenierıa, Universidad de Buenos Aires

2Departamento de Fısica, Facultad de Ingenierıa, Universidad del Comahue3CONICET

Los moduladores espaciales de luz (SLMs) son sistemas opticos que permiten modificar en tiempo

real, la amplitud y la fase de la luz que los atraviesa. Habitualmente, el elemento central de estos

sistemas es un microdisplay. Los microdisplays son displays de cristal lıquido donde el tamano de los

pıxeles es del orden de 10 a 40µm.

Generalmente, el alto costo de los SLMs, del orden de decenas de miles de dolares, resulta prohibitivo

para los laboratorios de optica. Frecuentemente se suelen armar SLMs precarios a partir del desguace

de proyectores de video. Esto presenta dos inconvenientes: por un lado, la dificultad de disponer de

varios SLMs de caracterısticas similares. Por otro lado, la necesidad de utilizar una PC para generar las

senales que emplea el SLM, debido a que los circuitos de control de los proyectores est an disenados

para trabajar con senales de video.

En este trabajo se presenta el desarrollo de un prototipo de un SLM a partir de un microdisplay de

venta comercial. El esquema propuesto consiste principalmente en una CPLD que genera las senales

de sincronismo del microdisplay, una memoria para almacenar distintas imagenes, un conversor DAC

para cargar la imagen en el microdisplay y un microcontrolador que realiza el control general del

sistema. De esta forma se logra utilizar el microdisplay sin la necesidad de trabajar con senales de

video.

El prototipo resulta significativamente mas economico que los SLMs comerciales y, por ende, ofrece

una alternativa en dispositivos para la investigacion en optica en el paıs.



200






201




Linux Embebido



202






203




“Single Board Computer Basada en ARM9 y FPGA paraProcesamiento de Imágenes Digitales”

Diego Gonzalez Dondo; Leandro N. Alem; Guillermo SteinerUniversidad Tecnológica Nacional-Facultad Regional Córdoba

[email protected]

El en el presente trabajo se muestra el desarrollo de una computadora simple o SBC (Por sus siglas en

ingles), ya que se trata de una configuración que posee los mismos elementos constituyentes básicos

de un computadora, como son: microprocesador, memoria (RAM y ROM), bus de datos, periféricos

de entrada y salida, fuente de alimentación, comunicación vía ethernet, etc. El microcontrolador uti-

lizado es el EP9302 de arquitectura ARM9 de 32 bit. Al mismo se le conecta una FPGA de Xilinx

Spartan XSA3SE500 directamente al bus de datos y un sensor de imágenes 0V7620 con su óptica co-

rrespondiente. Con esto se logra un sistema completo para el procesamiento de imágenes, condición

muy deseada para aplicaciones embebidas.

La utilización de una FPGA en el desarrollo de las SBC implica la posibilidad de que los algoritmos

de procesamiento de imágenes se pueden implementar en la misma, esto quiere decir que se puedencrear estructuras de hardware dedicado para llevar a cabo el proceso. Esto manifiesta una gran ventaja

con respecto a las implementaciones efectuadas en software de una PC de escritorio, debido a que lo

que se programa en una FPGA es hardware, que es totalmente concurrente, traduciéndose en una alta

velocidad de cálculo.

Al ser la SBC de arquitectura abierta permite una versatilidad en la utilización de la misma, como en

la implementación de los algoritmos, ya que, o bien se llevan a cabo por el potente microcontrolador

ARM9, por la FPGA o una combinación de ambos.

El sistema esta conformada por 3 PCBs, los cuales fueron realizados en dos capas, con agujeros meta-

lizados, mascara antisoldante y con encapsulados de montaje superficial. El montaje de los componen-

tes se realizó en forma manual. Se implemento un mecanismo de testeo por pasos del funcionamientode los componentes principales, como el microprocesador, memorias, etc, basado en un software de

booteo del microcontrolador.

El sistema cuenta actualmente con un kernel de Linux embebido y la distribución GNU Debian para

ARM, para aumentar la versatilidad del sistema y abstraerse del hardware a la hora de desarrollar y

ejecutar aplicaciones.



204




“Diseño de un reloj sidereo sobre una plataforma uClinux y FPGA”

Guillermo M. Gancio.Instituto Argentino de Radioastronomía I.A.R. CONICET.

[email protected]

Parte del instrumental que tiene el I.A.R. está dedicado al sistema de apuntamiento de una antena de

30mts de diámetro con la cual realiza observaciones radioastronomicas en la banda de 1420Mhz(HI).

Uno de los módulos está encargado de proveer una señal de referencia de tiempo y frecuencia que está

sincronizada con el movimiento de los astros, este reloj se denomina de tiempo sidéreo. Para obtener

el tiempo sidéreo es necesario poder obtener y mantener la hora local de forma precisa.

Esto se puede lograr mediante el protocolo SNTP por lo cual es requisito contar con una conexión

ethernet, también es necesario poder controlar un hardware asociado que permita proveer una comu-

nicación serial con otros dispositivos. Al evaluar las posibles plataformas para el desarrollo de este

módulo y teniendo en cuenta que debe ser integrado junto a otros sistemas, se optó por una plataforma

del tipo SBC (Single Borad Computer) la cual fue desarrollada en el I.A.R; a modo de evaluación se

utilizó un kit de la firma Digilentinc (Spartan 3E Starter Kit).

Esta plataforma debe presentar cierta flexibilidad con respecto al hardware asociado, por esto se deci-

dió utilizar una FPGA SPARTAN3E-500 de la firma Xilinx en la cual se implementó el softprocessor

MicroBlaze de la misma firma. Se decidió utilizar un sistema operativo un uClinux como elemento de

abstracción entre el desarrollo de las aplicaciones y el hardware asociado. Mediante este mecanismo

se busca estandarizar el desarrollo de aplicaciones de software independientemente de la evolución

de la plataforma de hardware.



205




Protocolos

y

Comunicaciones



206






207




“Herramienta para depuración de redes de sensores

inalámbricos”Mazzara P., Steinfeld L., Silveira F., Villaverde J.

Instituto de Ingeniería Eléctrica, Fac. de Ingeniería, Universidad de la República

mazzara, leo, silveira, [email protected]

La implementación de una red de sensores inalámbricos presenta grandes desafíos. La

depuración de una aplicación tiene la dificultad propia de depurar un sistema distribuido

además de un sistema embebido en tiempo real. En estas redes es fundamental minimizar el

consumo de los nodos, siendo la comunicación responsable de la mayor parte y por ello se

busca disminuir los tiempos en que la radio está activa. Contar con una herramienta para

realizar un profiling de energía en tiempo real es fundamental. La verificación de una

correcta transición de estados de la radio, así como también medir el tiempo en cada uno

permite detectar bugs de diseño o implementación.

Para encarar este problema se siguió una metodología no intrusiva en dos etapas. Primero secaracteriza en laboratorio el consumo de un mote en los diferentes estados. Luego, la

actividad de un nodo en campo es registrada por un dispositivo, MoteSpy. Para ello es

necesario modificar el software del nodo a testear para que el módulo de comunicación

maneje un puerto de salida digital. Este es conectado a un puerto de entrada del MoteSpy

para registrar el instante de tiempo de los eventos señalados por el nodo. Estos son

guardados adecuadamente (hasta 1MB de datos en Flash) para luego ser recuperados y

analizados.

Esta metodología se utilizó una red en operación, permitiendo medir el ciclo de trabajo

efectivo de un nodo y calcular su tiempo de vida y detectar desincronizaciones ocurridas

entre nodos, evaluando el impacto que esto tiene en el consumo.



208




The Wireless E mbedded Inter netMercado G., Aguir re M. y Diedr ichs A.

gust avo.mer cad o, ma tia s.aguir re,

an a.diedr ichs @gridt ics.frm .ut n.edu .ar

Gru po UTN Gr idTICSFacultad Regional Mendoza

Un iversidad Tecnológica Na ciona l

La visión detrás de la Internet de las Cosas es que los dispositivos embebidos,

ta mbién llamados “sma rt objetcs”, están cada vez ma s un iversa lment e

conectados a In tern et y que son un a par te integral de la misma.

La In ter net de las cosas, a veces denominada “inter net embebida orillera”,

es un cam bio ma yúsculo y el ma yor desa fío a la In ter net a ctu al. La misma está

“hecha” con dispositivos embebidos conectados a Internet , lo que incluyesensores, maquinas, lectores de RFID y equipamiento de automatización de

edificios, solo para nombrar unas pocas aplicaciones. El exacto tamaño de la

Internet de las cosas es difícil de estimar pero se asume que pronto su tamaño

excederá en de la Intern et actua l.

El wireles embedded internet es un subconjunto de la Internet de las cosas y

son aquellos dispositivos embebidos de recursos limitados, a menudo operados

por ba ter ía s y conect ados a Inter net a t ravés de red es in alá mbr ica s de ba ja

poten cia y bajo a ncho de ba nda.

6LowPAN fue desarrollado para hacer posible Wireless Embedded Internet

simplificando las funcionalidades de protocolo de internet IPv6, definiendo un

encabezam iento muy compa cto y toma ndo en cuen ta la na tu ra leza de las r edesinalámbricas.

En el presente trabajo se muestra la funcionalidad de 6LowPAN (Red de área

per sona l de ba ja s pres tacion es habilitado para IPv6), defin iendo los concep tos

de la norm a del IETF, sus alcan ces y sus aplicaciones h abitua les.



209




Robótica



210






211




“Implementación de rutinas de Control optimo en micros de

8/32 bits”Hugo Ryckeboer, Andrés Angelópulo, Ignacio J. Zaradnik

Departamento de Ingeniería e Investigaciones Tecnológicas, UNLaM

El presente trabajo se centra en la especialidad de control optimo, mas precisamente en el

principio de Pontryagin. La ventaja de esta especialidad es que nos permite encontrar un

control para nuestra planta y a la vez optimizar alguna de las características del sistema.

Como ejemplos podemos nombrar el de un vehículo que tiene que llegar de un punto X a un

punto Y en el menor tiempo posible, o consumiendo la menor cantidad de energía. Este

trabajo tuvo como objetivo presentar a los alumnos algo más que simples formulas

matemáticas, y de esta forma hacer más didáctico el tema.

El primer ejemplo nombrado es el más utilizado académicamente a raíz de su fácil

visualización, por este motivo es que se lo ha seleccionado para implementar.

La parte mecánica del proyecto es una base con cuatro ruedas sobre la cual se monta unaplaca controladora, un motor de continua, una placa auxiliar, que es utilizada de interfaz

entre el motor y la placa controladora, y una batería.

La plataforma utilizada para el controlador es un microcontrolador de la línea Flexis, línea

que tiene micros de 8 y 32 bits pin a pin compatibles, de Freescale. Como placa

controladora se utiliza la DEMOQE128, la cual es una placa de desarrollo de bajo costo de

Freescale para la línea de microcontroladores MC9S08QE128/MCF51QE28. La

programación es realizada en ANSI C a través de IDE CodeWarrior.



212




“Sensado basado en visión para el control de un sistema Ball & Beam”

Ezequiel Pecker Marcosig; Aníbal ZaniniFacultad de Ingeniería FIUBA

[email protected]@fi.uba.ar

El objetivo de este trabajo es controlar la posición de una bola que rueda sobre una guía con un

grado de libertad. Se utiliza visión artificial como método de sensado de la posición. Esta herramienta

es muy utilizada porque no necesita contácto con el elemento a sensar. La cámara utilizada es una

webcam. El medio en el cual se realiza la captura de la imagen debe controlarse adecuadamente

para tener alto contraste entre la bola y los demás componentes del sistema. La posición obtenida

de la imagen es convertida, mediante transformaciones lineales, de un sistema de coordenadas 2D

expresado en pixeles a un sistema de coordenadas 3D solidario con la barra y expresado en mm.

El sistema mecánico a controlar es inherentemente inestable y tiene una dinámica no lineal, por esta

razón, es una planta utilizada frecuentemente para evaluar diversas estrategias de control.

El sistema es estabilizado con un controlador PID que se ejecuta en una PC y determina el valor dela fuerza de control a enviar a un microcontrolador para que éste la convierta en una señal adecuada

para manejar el servo unido al eje de la guía. Este actuador tiene embebido un controlador propor-

cional originalmente diseñado para obtener una determinada dinámica en la respuesta del servo. Para

este lazo de control el movimiento de la guía acoplada y el desplazamiento de la bola constituyen

perturbaciones. Ambos controladores se hallan conectados en cascada.

Referencias

1. “Machine Vision Based Control on the Ball and Beam”, I. Petrovic, M. Brezac y R. Cupec, 7thInternational Workshop on Advanced Motion Control AMC’02, pp573-577, 2002.

2. “Vision Guided Ball-Beam Balancing System Using Fuzzy Logic”, E. Dadios, R. Baylon,

R.D.G. Andre Florentino y Z. Zulueta. 26th Annual Conference of the IEEE Industrial Elec-

tronics Society IECON 2000, pp.1973-1978, 2000.

3. “A Ball and Beam Testbed for Fuzzy Identification and Control Design”, E.Laukonen y S.Yurkovich,

American Control Conference ACC’93, pp.665-669, 1993.

4. “Control System Design”, 1er. Ed., K.J.Astrom, Department of Automatic Control Lund Insti-

tute of Technology, Suecia, 2002.

5. “Digital Image Proccessing”, 2da. Ed., R.C. Gonzalez y R.E. Woods, Prentice Hall, USA, 2001.

6. “Learning OpenCV Computer Vision with the OpenCV Library”, 1er. Ed., G. Bradski y A.

Kaehler, O’Reilly Media, USA, 2008.



213




RTOS



214






215




Sistema portátil para adquisición, monitorización y

registro de señales de ECG en tiempo real

Azcueta Mario Martín1, Kharsansky Alan1

1 Laboratorio de Sistemas Embebidos, Facultad de Ingeniería, Universidad de Buenos Aires

Este trabajo comprende el desarrollo de un sistema portátil de adquisición, monitorización

y registro de señales electrocardiográficas (ECG) con interfaz de usuario a través de pantalla gráfica táctil y/o PC, utilizando la reciente plataforma de NXP LPC1768. A esta

clase de dispositivo se lo denomina comúnmente Holter cardíaco, y es frecuentemente

utilizado por médicos para diagnosticar patologías cardíacas en pacientes.

El funcionamiento del dispositivo está basado en el sistema operativo de tiempo realFreeRTOS, el cual coordina las operaciones de adquisición, análisis y registro de la señal y

la interfaz con el usuario. La señal de ECG es acondicionada analógica y digitalmente para

amplificarla y remover el ruido de línea, tras lo cual es digitalizada y almacenada en una

tarjeta de memoria SD utilizando el sistema de archivos FAT32, por un períodoseleccionable de 24 a 48 horas. También se monitorea en tiempo real la cantidad de latidos

por minuto del paciente, utilizando un algoritmo de detección de QRS.

El equipo permite verificar la correcta recepción de la señal al momento de su colocación

en el paciente, mostrándola en pantalla. Las condiciones de grabación se configuran a

través de un menú gráfico user-friendly y pantalla táctil. Una vez iniciada la grabación, la pantalla puede ser removida dejando al paciente solo con la unidad de adquisición,

minimizando así el peso y tamaño de la unidad que debe ser portada. No conocemos a la

fecha dispositivos comerciales que posean esta última característica, la cual consideramosun aporte útil y novedoso.



216




Estación de Control para Red de Sensores Inalámbricos

Implementada con RTOS Laprovitta A.; Sahade D.; Sanchez R.; Vélez Ibarra D.Laboratorio de Comunicaciones, Facultad de Ingeniería

Universidad Católica de CórdobaCórdoba, [email protected]

En el presente trabajo se reporta exclusivamente el diseño de una Estación de Control parauna red de sensores inalámbricos (WSN) aplicada al monitoreo de cultivos en invernaderos.Este desarrollo se abordó mediante la implementación de un sistema embebido controlado

por un sistema operativo de tiempo real.

Los parámetros a capturar (temperatura, humedad y radiación solar) en diferentes puntos delinvernadero se obtienen de sensores conectados a los nodos de la WSN. Éstos son

interrogados y configurados a través del vínculo inalámbrico local (2.4GHz) por la Estaciónde Control, la cual funciona no sólo como punto de acceso de esta red con topología enestrella, sino que además brinda canales de interacción con el sistema a usuarios localesdesde su propia interfaz humana (Pantalla Táctil) o por medio del software de gestión enuna computadora portátil.

Mediante la utilización de un RTOS sobre un sistema embebido hemos logrado no sóloreaccionar continuamente a los cambios en el entorno del sistema y computar resultadoscerteros en tiempo real, sino también una excelente solución de compromiso en el diseño dehardware y software, disminuyendo la complejidad de este último sin aumentar los recursoscircuitales necesarios. Esta simplificación en la implementación de un sistema con lascaracterísticas antes descriptas, es uno de los principales aportes de este trabajo.



217




Notas:



Notas:



CASE 2011www.sase.com.ar

2 al 4 de Marzo de 2011

UTN-FRBA, Buenos

Aires, Argentina

Documents

CASE2011_Libro_de_Trabajos.pdf