CASE2011 Libro de Trabajos

CASE 2011www.sase.com.ar2 al 4 de Marzo de 2011UTN-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

CASE 2011CASE 2011

Libro de Trabajos

Congreso Argentino de

Sistemas Embebidos

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

i

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, siempre que 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 que incluyen el procesamiento de datos, pero que a diferencia de una computa-dora personal, están diseñados para satisfacer una función específica, como ser 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, un microprocesador 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 Simposio Argentino de Sistemas Embebidos, SASE 2010. Del evento participaron 500 personas (58% Academia, 42% Industria), contando con el auspicio de 32 uni-versidades, 13 empresas y 10 instituciones, y se ofrecieron 34 tutoriales, 6 plenarias, 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 y participaron cerca de 1000 personas de la industria y la academia, contando con el auspicio de 50 universidades, 30 empresas y 15 instituciones, en el marco 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, Arquitecturas de 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 y corrección. De este modo fueron seleccionados 28 artículos y 22 pósters. Estos 50 trabajos se publican en esta memoria y también están disponibles en forma online en la página www.sase.com.ar/2011

Esperamos que los trabajos recopilados en esta memoria sean de su interés y contamos 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 Microprocessor Architecture 15

DSPs 21

Desarrollo e Implementacion de un Controlador Activo de Ruido de Banda Angosta Adaptativo 23

Prototipado rápido para sistemas embebidos en FPGA - Desarrollo de la trasformada 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 de Residuos, Implementación en FPGA 42

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

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

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

Sistemas en Chip acelerados por hardware: comparación de performance en 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 la intemperie 79

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

Protocolos y Comunicaciones 89

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

Tecnología inalámbrica Near Field Communication y sus aplicaciones en sistemas 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 en robótica 115

Filtro complementario para estimación de actitud aplicado al controlador embebido 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 sistema embebido 140

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

Muestreo y Adquisición Inteligente de Señales Sensoriales en Sistemas Embebidos 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-Phone Platform 168

POSTERS 175

Arquitecturas de Microcontroladores 177

Comparación del desempeño de microcontroladores AVR de 4ta generación 179

Anemómetro Ultrasónico 3D empleando Arquitecturas Analógica-Digital Reconfigurables 180

ASICs 181

Detector Activo de Corrientes de Fuga 183

Fabricación de un circuito integrado digital conversor Serie-Paralelo y Paralelo-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 de corriente 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 en Hardware 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 de Imá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 de ECG en tiempo real 215

Estación de Control para Red de Sensores Inalámbricos Implementada con RTOS 216

xii

1

www.sase.com.arwww.sase.com.ar2 al 4 de marzo de 20112 al 4 de marzo de 2011UTNFRBA, Buenos Aires, ArgentinaUTNFRBA, Buenos Aires, Argentina

ARTÍCULOS

2


3


ASICs

4


5


Sistema de Medicion Remoto Basado enDispositivos FPGA

Pablo D. Pareja Obregon, Alfredo Falcon, Martın Di FedericoPablo S. Mandolesi, Pedro M. Julian

Dpto de Ing. Electrica y de ComputadorasUniversidad Nacional del Sur

Bahıa Blanca, [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 distintosdispositivos de medida, cambiando las variables a controlar ypudiendo utilizarse en aplicaciones remotas.

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

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

I. INTRODUCCION

Las redes de datos son una de las areas tecnologicas conmayor desarrollo en la actualidad. Sus aplicaciones van desdelas 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 paracontrolar diversos dispositivos de la vida cotidiana[3]. Acordecon dicha tendencia, muchos modulos de sistemas embebidosya vienen con soluciones y herramientas para redes Ethernetincorporadas. Esto facilita su incorporacion en sistemas demedicion remotos, ası como acelera el tiempo de desarrollode aplicaciones controlables a distancia.

Otra tecnologıa que esta ganando terreno, debido a suflexibilidad y potencia son los arreglos logicos programablesen campo (FPGA)[4]. La posibilidad de programar las FPGAen tiempo de ejecucion, sin moverlas del lugar de aplicacion,es un factor clave a la hora de definir la arquitectura a utilizaren el diseno[5]. Actualmente los desarrollos con FPGAs,pueden aprovechar modulos de Ethernet y microprocesadoresque 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 unaestacion de trabajo, sin la necesidad de encontrarse fısicamenteen el lugar donde se esta realizando la medida. Esto resultaparticularmente util cuando la variable a medir se encuentraen lugares de difıcil acceso, como es el caso de variablesambientales en zonas geograficas protegidas.

Este paradigma de sistemas de medida descentralizados,viene con problematicas de sincronizacion asociadas. Definirel nodo maestro y los nodos esclavos en estas comunicaciones,es uno de los puntos clave a la hora de comenzar el desarrollode cualquier sistema. La sincronizacion de los mismos debera,a su vez, tener en cuenta como se almacenaran los datosrecibidos y discriminar las fuentes de datos en el caso decontar con mas de un nodo. Al mismo tiempo, la informaciontemporal de los datos es un parametro clave en transmisionessujetas al ruido con posible perdida de informacion en elcamino.

Una red de sensores consiste en un conjunto de nodos concapacidad 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 utilizacionde redes de sensores nos permite disponer de diversos tiposde informacion, al instante y desde cualquier sitio. En elpresente trabajo, se desarrolla un sistema de medicion remotoutilizando un dispositivo FPGA como nodo de mediciony una computadora como nodo maestro de recoleccion dedatos[6][7].

El dispositivo a medir consiste en un conversor de corrientea corriente, utilizado en la medicion de los tiempos de respues-ta de un fototransistor. El objetivo del trabajo es obtener lasmınimas corrientes necesarias en el emisor, para cada valor detiempo de encendido del mismo. De esta manera, contando contodos los pares de valores de corrientes de emisor y tiemposde encendido, se puede obtener el punto optimo de trabajopara cualquier aplicacion en particular.

El presente trabajo se divide de la siguiente manera: en laseccion II se describe la arquitectura del sistema de medicionpropuesto, para luego desarrollar con mayor profundidad cadauno de los bloques implementados. En la seccion III semuestran los resultados experimentales obtenidos, durante laetapa de evaluacion del sistema, ası como un analisis de los

6


tiempos de medida resultantes en relacion con la resolucionde los datos. En la seccion IV se describen futuras mejoras enel sistema de medida y finalmente en la seccion V se detallanlas conclusiones del trabajo.

II. DESARROLLO

El sistema propuesto ha sido disenado de forma de asegurarmaxima flexibilidad y facilidad de uso. Dado que en nues-tra aplicacion en particular, se requieren variar los diversosparametros de la medicion, es necesario que los algoritmossean genericos y de facil extension. Ası se logran modificarlos tiempos y resoluciones de la medicion de manera sencillay en tiempo de ejecucion.

Aun cuando el uso de redes de sensores es muy venta-joso en muchas aplicaciones, se deben tener en cuenta suslimitaciones[8][9]. Cuando las redes utilizadas estan compues-tas por nodos inalambricos, para evitar el cambio periodico delas fuentes de alimentacion, un bajo consumo de energıa es unrequerimiento fundamental en el diseno. En nuestra aplicacionen particular, debido a que todos los nodos utilizados por elmomento cuentan con conexion directa a la red de energıa,el bajo consumo no es un parametro de peso en el diseno delsistema. Por otra parte, tambien existe un lımite en cuanto a lamemoria que disponen los nodos (FPGA) y su capacidad deprocesamiento. En el sistema desarrollado, para evitar trabajaren el lımite de la memoria de nuestra FPGA los datos sonenviados de manera asincronica en el momento en que sonadquiridos, utilizando el protocolo estandar de comunicacionesRS232.

La aplicacion de un sistema de medicion descentralizado esun proceso que comprende diversas etapas a mencionar, nodode control maestro, nodos de medicion esclavos, relevamientode datos, transmision de paquetes obtenidos, y finalmenteanalisis 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, cuyosparametros a modificar son la corriente de entrada (Ie) y eltiempo de encendido (tduty)[10]. Para cada par de valorestiempo-corriente, obtenemos una tension de salida Vout =f(Ie, tduty). Dicha salida es una senal digital que puede valer0 o 1, es decir tiene un bit de ancho de palabra. Por otra parte,tambien existe una senal de reset que nos permite efectuar unanueva medicion. El objetivo de nuestro ensayo, consiste enlevantar la curva de corrientes Ie mınimas necesarias para quetransicione la salida, en funcion del tiempo tduty de encendido.

El sistema de medida disenado consiste en una FPGA, quees la encargada de manejar las senales digitales del bancode pruebas, una computadora que actua como nodo maestro,y una fuente de corriente de precision Agilent E5270B. Elensayo, que se muestra en la Fig. 2, consiste en ir tomandosucesivos valores de corriente Ie, los cuales son controladosentre 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 AgilentE5270B para fijar los valores propiamente dichos. Por otraparte, para cada valor de corriente, se envıa una senal decontrol a la FPGA para que comience las mediciones. Dichasenal de control se transmite mediante una comunicacion serieRS232[11]. Para cada medicion, la FPGA reiniciara el circuitomediante un pulso digital de reset. A su vez, controlara la senaltduty a traves de la llave S1 que permite que la corriente Ie

llegue a un diodo emisor de luz. Durante los tiempos de apa-gado de la llave S1, la corriente Ie es derivada a tierra. La luzemitida llegara a la base de un fototransistor, que producira lacorriente de entrada al circuito de pruebas. Dicha corrientese integrara sobre una capacidad que finalmente producira latension de salida Vout. Al variar el tiempo de encendido tduty

se puede controlar la cantidad de tiempo que se integra luz,y en consecuencia obtener el mınimo tiempo necesario paradetectar una corriente determinada. A su vez, la tension digitalde salida es muestreada por la FPGA. La misma transmitira eldato resultante a la computadora, mediante una comunicacionserie. El script en Matlab recibira los datos, los almacenara enuna variable y comenzara el proceso nuevamente para unacorriente mayor.

En este esquema, donde la computadora corriendo Matlabrepresenta el nodo maestro, y tanto la fuente de corrien-te Agilent E5270B como la FPGA los nodos esclavos, laprincipal problematica a abordar es la sincronizacion entreel 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 seriede comunicacion RS232. Para la fuente de corriente AgilentE5270B, sin embargo, se decidio establecer la comunicacionutilizando el protocolo GPIB, debido a la disponibilidad delas librerıas necesarias.

7


Figura 2. Ensayo realizado

II-B. Nodo de Control Maestro

El control del nodo maestro se realiza mediante un scriptde Matlab. Un esquema del mismo se muestra en la Fig.3. Basicamente consiste en ir fijando sucesivos valores decorriente en la fuente Agilent E5270B, dar la orden a la FPGAde comenzar una nueva corrida de mediciones, y esperar losresultados de la misma. La comunicacion entre Matlab y lafuente de corriente Agilent E5270B se realiza por medio deuna comunicacion GPIB. Es importante tener en cuenta, que lafuente de corriente Agilent no permite manejar con presicionel tiempo en que se fija una variable o se toma una muestra.Debido a esto, la variacion de los pulsos de corriente de emisorse realiza mediante llaves controladas por la FPGA, y nodirectamente mediante la fuente de corriente.

Por otra parte, los comandos a la FPGA se implementaronmediante una comunicacion serie. Para los mismos se utili-zaron librerıas estandar provistas por Matlab. Para simplificarel 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 eltiempo total de medida de la FPGA, mas un agregado detiempo extra para tener en cuenta las variaciones debidas a queel planificador de tareas del sistema operativo no es de tiemporeal. Los datos se reciben de manera asincronica, por bloques.Cada bloque contiene la totalidad de las medidas realizadas enesa corrida de datos. La configuracion de comunicacion serieRS232 es 115200 baudios, 8 bits de datos, sin bit paridad, 2bits de stop. Luego de este proceso, se varıa nuevamente lacorriente y se comienza una nueva medicion. Al finalizar lamedicion de todas las corrientes requeridas, se almacenan losdatos en un archivo para su posterior analisis.

II-C. Nodo de Medicion Esclavo

Como se menciono anteriormente, la FPGA es la encargadade generar las senales digitales que controlan nuestro circuitode pruebas. Estas senales controlan por un lado la tension dereset (Vreset), y en segundo lugar manejan la llave CMOS(S1) conectada en paralelo con la fuente de corriente AgilentE5270B. 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 decontrol, 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 S1, permi-tiendo el paso de la corriente Ie al diodo emisor. Estas ventanasdeben variar entre dos valores conocidos, que seran el tiempomınimo y maximo de la medicion. Una vez finalizado cadapulso de corriente, se realiza la medida de la tension de saliday se envıa el resultado al nodo maestro.

El algoritmo fue implementado en Verilog, utilizando unkit de desarrollo Spartan 3 para la FPGA. El sistema consisteen una maquina de estados y dos contadores. La maquinade estados es la encargada de esperar la recepcion de uncomando RS232, el cual reiniciara los contadores. La maquinade estados a su vez, es la encargada de tomar muestras de lasalida y envıar los datos mediante el protocolo serie RS232.

Los contadores son los encargados de generar un barridoen las ventanas de tiempo. El primer contador almacena eltamano de la ventana de tiempo actual. Por otra parte, elsegundo contador genera la ventana de tiempo propiamentedicha, manteniendo abierta la llave S1 mientras su cuentasea menor que el tamano indicado por el primer contador.Al finalizar la cuenta del segundo contador, se emite la senalfinBarrido a la maquina de estados, indicando que se debeenviar un dato nuevo. A continuacion se incrementa el primercontador, y se repite el proceso hasta llegar al maximo tamanode ventana que se desea medir.

Para recibir y transmitir los datos mediante el protocoloserie, se necesito desarrollar un modulo encargado de dichatarea. El esquema utilizado se desarrolla en la seccion siguien-te.

II-D. Trasmision de Paquetes

El sistema encargado de trasmitir y recibir datos serie fuedesarrollado en Verilog. El mismo se divide en 3 partes, ungenerador de baudios, un transmisor y un receptor. Como secomento anteriormente, la velocidad de transmision utilizadaes 115200 baudios. Las FPGAs, sin embargo usualmenteutilizan velocidades mucho mayores a 115200 Hz. En nuestrocaso 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 vecespor segundo como nos sea posible. Al contar con un relojde 50 MHz, para generar 115200 Hz se debe dividir por unnumero que no es entero. La solucion es dividir por el numeropotencia de 2 mas cercano a la velocidad que queremosgenerar. Esto tendra como consecuencia que en ocasiones seutilice un perıodo menor y en ocasiones un perıodo mayor. Enpromedio, la velocidad generada sera la que estamos buscandoy al contar con un reloj mucho mayor que la tasa de baudios, elerror estara dentro de la variacion aceptable por el protocolo.

Cuando se recibe la senal TxD start, que es emitida porla maquina de estados de la seccion II-C, se toma un datode 8 bits y se lo serializa utilizando un multiplexor. En esemomento la senal busy es emitida y se mantiene durante todala transmision. La senal TxD start es ignorada durante esetiempo.

El receptor, por otra parte, va ensamblando los datos de lalınea de entrada (RxD) a medida que arriban. Esta lınea sera laque reciba los datos entrantes del protocolo RS232. Con cadabyte recibido, se emite la senal data ready durante un perıodode reloj. Para determinar cuando arriba un nuevo dato o bit deinicio, sobremuestreamos la senal a un multiplo de la tasa debaudios. Una vez que detectamos el bit de inicio, muestreamosla lınea a la tasa de baudios conocida, para adquirir los bits dedatos. En nuestro caso utilizamos un sobremuestreo de 8 veces.Al ser asincronica, la senal RxD de entrada no tiene ningunarelacion con nuestro reloj. Para solucionar esto, se utilizan dosflip flops tipo D, logrando ası la sincronizacion con nuestroreloj. Los datos son a su vez filtrados, para evitar que picos detension en la lınea RxD sean confundidos con bits de inicio.Para esto, se utiliza un algoritmo de decision que muestrea3 veces la senal. Finalmente, un registro de desplazamientorecolecta 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, sesimulo el codigo desarrollado inyectando valores de entradamediante una transmision RS232 emulada. Por otra parte, paracomprobar el correcto funcionamiento del sistema completo,se inyectaron datos conocidos y se comprobo que llegarancorrectamente a la estacion central. Debido a que la matriz amedir es amplia, es conveniente realizar pruebas intermediascon pocos datos, para acortar los tiempos de prueba delsistema de medida. El numero total de muestras a tomar esn(Ie) ∗ n(tduty), donde n es el numero de puntos. Entre laspruebas llevadas a cabo, se realizaron comunicaciones entreterminales serie y Matlab, y por ultimo entre Matlab y laFPGA.

Finalmente se relevaron multiples datos de manera continua,contrastandolos con los datos obtenidos a partir de resultadosteoricos. En la figura 5 se muestran los resultados experimen-tales obtenidos durante una de las pruebas de laboratorio.

9


Ie [m

A]

Tduty [ms]

Corriente minima de transicion en funcion del tiempo 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 decontrol embebido, que permita recibir los datos recolectadospor la FPGA y almacenarlos en una memoria interna. Esimportante mencionar, que se deberıa ademas disenar unafuente de corriente programable de alta precision. De estamanera, se podrıa reemplazar la fuente Agilent E5270B. Entrelas ventajas de este metodo, se encuentra la mayor portabilidaddel sistema, pudiendo incluir los modulos de medida en elmismo circuito que conforma el dispositivo a medir.

Es importante mencionar que en cuanto a la sincronizacionde 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 sincronizaciones un punto crıtico para tener en cuenta en mediciones de masalta frecuencia y multiples nodos.

Para poder realizar y controlar las mediciones de variosdispositivos en paralelo, se propone ademas transmitir losdatos mediante una red Ethernet[12]. De esta manera, larecepcion se realiza en una computadora conectada a la red,que sera la encargada de procesar la informacion de todos losnodos y almacenarla para su posterior analisis[3]. Para accedera la comunicacion a traves de la red Ethernet, se realizo unainterfaz grafica desarrollada con las librerıas graficas Qt[13],que vuelca los datos obtenidos a un archivo de texto. Sinembargo, como en un principio se requerıa medir los datosde un unico dispositivo, dicha interfaz luego no fue utilizada.

Finalmente como alternativa al uso de una FPGA en losnodos de sensado, se podrıa utilizar un CPLD de bajo con-sumo. Esto permite disminuir el consumo, para su posteriorinclusion en un nodo funcionando a baterıas. Sin embargo,como en nuestro caso se propone utilizar redes Ethernet enfuturas versiones, el uso de nodos con FPGA permite mayorflexibilidad en el diseno.

V. CONCLUSIONES

En el presente trabajo se trato la implementacion de unsistema automatico de medicion y validacion, implementado

con dispositivos FPGA. Esta aplicacion resulta particularmentepractica para sistemas de medicion con bajas constantes detiempo, donde se debe iterar sobre distintos parametros y cadamedicion lleva grandes cantidades de tiempo. De esta manera,dichos parametros son configurables en el servidor, quien seencarga de supervisar las mediciones de manera automatica ya su vez almacenando los datos resultantes.

Todo proyecto consta de varias etapas a mencionar, concep-cion, diseno e implementacion, y testeo. Todas ellas han sidodesarrolladas a lo largo del trabajo, mostrando la metodologıacon la que se ataco el problema que se pretendıa resolver.En particular, el sistema fue probado satisfactoriamente enlaboratorio. Se proponen algunas mejoras al sistema, las cualesseran implementadas una vez que se evalue la eficacia delmetodo 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 IEEEInstrumentation 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 CurrentConveyors, 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 ofFPGA-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 dePresion Endotraqueal

Pablo D. Pareja Obregon, Alfredo Falcon, Martın Di FedericoPablo S. Mandolesi, Pedro M. Julian

Dpto de Ing. Electrica y de ComputadorasUniversidad Nacional del Sur

Bahıa Blanca, [email protected]

Resumen—En el presente trabajo se desarrolla la concepcion,diseno 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 Investigacionen Sistemas Electronicos y Electromecatronicos (GISEE) de laUniversidad Nacional del Sur.1

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

I. INTRODUCCION

La microelectronica y las redes de sensores se encuentranentre las areas tecnologicas con mayor diversidad de cam-pos de aplicacion[1]. En particular, la medicina es una delas disciplinas afectadas con mayor impacto asociado[2][3].Muchas de las aplicaciones electronicas en medicina tienencomo objetivo mejorar la calidad de los procedimientos, elcontrol y la supervision del paciente antes, durante o despuesde una determinada intervencion[4][5][6].

Como resultado de un proyecto de colaboracion entre unhospital local y la Universidad Nacional del Sur, se detecto lanecesidad de llevar a cabo algun tipo de control sobre lapresion endotraqueal en pacientes intubados. En la actualidadno existe ningun sistema de sensado de dicha presion, que-dando la tarea relevada por las enfermeras de turno. Esto traecomo consecuencia una apreciacion subjetiva y poco confiablede las medidas realizadas. Por otra parte, por el hecho quela supervision no es permanente, la deteccion de cualquierproblema se puede realizar con una demora tal que el danosea 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 nodoscon capacidad de sensado y calculo limitadas, que puedencoordinarse a traves de comunicaciones inalambricas con elproposito de llevar adelante alguna tarea. La utilizacion deredes de sensores nos permite disponer de diversos tipos deinformacion, al instante y desde cualquier sitio[10][11].

La motivacion del presente trabajo es realizar una red desensores hospitalarias, que incluya un sistema de medicion dela presion del tubo endotraqueal en pacientes intubados. Estesistema debe realizar mediciones periodicas de la presion, ytransmitirlas de manera inalambrica a un nodo de procesa-miento central. El nodo central sera el encargado de almacenarlos datos resultantes de la medicion, y mostrar la informaciona traves de una computadora al personal medico adecuado.

El presente trabajo se divide de la siguiente manera: en laseccion II se describe la arquitectura del sistema de medicionpropuesto, para luego desarrollar con mayor profundidad cadauno de los bloques implementados. En la seccion III semuestran los resultados experimentales obtenidos, durante laetapa de evaluacion del sistema, ası como pruebas realizadassobre pacientes en una sala de terapia intensiva. En la seccionIV se describen futuras mejoras en el sistema de medida yfinalmente en la seccion V se detallan las conclusiones deltrabajo.

II. DESARROLLO

El sistema propuesto ha sido disenado teniendo en cuentala facilidad de su uso, ası como el mınimo consumo y mayorprecision posibles en la medida. Otro factor de peso en eldiseno es la robustez del producto terminado, debido a quesera transportado continuamente de lugar y por personal noespecializado.

Si bien la utilizacion de redes de sensores tiene diversasventajas en muchas aplicaciones, se deben tener en cuentasus limitaciones[11]. En particular, cuando las redes utilizadastienen como medio de comunicacion nodos inalambricos, unbajo consumo de energıa es un requerimiento fundamental enel diseno. Esto es debido principalmente a que se debe evitarel cambio periodico de las fuentes de alimentacion. Es por elloque en este tipo de redes se debe minimizar la comunicacion,que es la tarea que mayor consumo de energıa requiere. Paraabordar esta problematica, se busco realizar comunicaciones

11


periodicas de datos, en lugar de transmitir continuamentevariables del paciente. Esta metodologıa utilizada se desarrollaen la seccion II-A.

La aplicacion de una red de sensores para medicion devariables hospitalarios es un proceso que comprende diver-sas etapas a mencionar, sistema de medicion, transmision yrecepcion de los paquetes de informacion, analisis de losdatos, y finalmente visualizacion de los mismos. Cada una deestas etapas sera explicada con mayor detalle en las seccionessiguientes.

II-A. Sistema

Un esquema del sistema completo se muestra en la Fig. 1.El sistema se puede dividir en dos bloques, nodo sensor ybase central. El nodo sensor es el encargado de adquirir lasenal resultante de la medicion y transmitirla a la base porradiofrecuencia. La base recibe la senal y luego de su proce-samiento, la muestra en una interfaz realizada especıficamentepara dichos fines.

Figura 1. Diagrama en bloques del sistema completo

Como el nodo sensor es alimentado por una baterıa, esnecesario que el consumo de energıa sea lo mas eficiente po-sible. Por otra parte, como la presion cambia muy lentamentecon el tiempo, no es necesario medirla de manera continua.Es por esto, que para disminuir el consumo de energıa, sedecidio colocar un reloj de tiempo real encargado de prenderel sistema periodicamente para realizar la medicion. De estamanera, el reloj genera una senal que habilita el reguladorprincipal, encendiendo a su vez un microcontrolador CC1010.Durante la medicion de la presion, el microcontrolador prendeotro regulador que alimenta el puente sensor de presion y suamplificador asociado.

Este esquema de manejo de energıa, es utilizado para reducirnotablemente el consumo. Esto se logra realizando medicio-nes durante 10 segundos, cada 15 minutos. La medicion serealiza durante 10 segundos con el fin de obtener parametrosadicionales del paciente y detectar cualquier anomalıa. Entrelos parametros adicionales medidos se encuentran la presioncapilar y el pulso del paciente, entre otros.

Para poder prender y apagar periodicamente el sistema,se necesita un circuito con una muy buena precision encuanto 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 sueleccion, podemos encontrar el bajo consumo que presenta.Es importante mencionar, que dicho consumo es uno de losfactores de mayor peso sobre el consumo total, ya que es elunico componente del sistema que nunca sera apagado.

Otra de las caracterısticas importantes del circuito integradoPCF8593, es la posibilidad de contar desde centesimas desegundo, hasta dıas e incluso meses. El mismo posee 16registros de 8 bits, los cuales cumplen distintas funciones.Entre ellas se encuentra configurar su comportamiento. Esto esimportante, ya que dichos registros deberan ser configuradosde 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 detension en base a capacitores conmutados MCP1253. El mo-tivo de dicha eleccion, es fundamentalmente su bajo consumode energıa mientras se encuentra en modo de apagado. Dichoconsumo es de 0, 1µA. Sin embargo, el problema de este re-gulador es que al presentar conmutaciones, se introduce ruidoal alimentar el puente del sensor MPX2010. Al introducirruido en la etapa de sensado, el mismo es amplificado porlas sucesivas etapas, obteniendo una medicion poco confiable.Para disminuir este ruido, la solucion fue agregar un segundoamplificador de mayor consumo y menor ruido, pero quefuera prendido unicamente mientras se realiza la medicion. Elregulador 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 deconmutacion asociado a los reguladores basados en circuitosconmutados.

II-B. Sistema de Medicion

El sistema de medicion y acondicionamiento de senal debeser capaz de medir presiones entre 0 y 50mmHg. Estosvalores de presion se deben convertir de manera lineal, enuna tension entre 0 y 3, 3V , con una precision de 1mmHga fondo de escala. Este valor de tension sera la entrada delconversor A/D del transmisor.

La topologıa del sistema de medicion utilizado se muestraen la Fig. 2. Se decidio utilizar el sensor MPX2010 debidoa que posee compensacion en temperatura y sus valores deresistencia estan ajustados por laser, obteniendo una lecturafinal muy precisa. Este sensor posee una sensibilidad ksensor

de 110µV/mmHg cuando se lo polariza con 3, 3V . Con estevalor y los rangos de presion de entrada y tension se salida sepuede calcular la ganancia del amplificador como se muestraen la Ec. 1.

Av =Spamentrada A/D

ksensor ∗ Spam Presion= 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 cualse utilizo un ancho de banda maximo de 100Hz. Como elsensor es resistivo se puede calcular el ruido del mismo comose indica en la Ec. 2

Vnsensor =

√∫ 100

f=0

r2(f)df = 380nV (2)

A continuacion, podemos calcular el valor de presion deruido como se indica en la Ec. 3. El ruido del sensor se puededespreciar, ya que el mismo deberıa dividirse por el modulo dela ganancia al cuadrado. En consecuencia basta con elegir unamplificador de bajo ruido, por lo que se eligio el amplificadorde instrumentacion INA333 que posee una densidad espectralde ruido de 50nV/

√Hz.

Pnsensor =Vnsensor

ksensor= 3, 45e−3mmHg (3)

Otra fuente de error es la variacion de la ganancia. Dichavariacion se puede controlar con la precision de la resistenciaRG. Se decidio que la variacion maxima de ganancia admisiblees de 1/3mmHg a fondo de escala. Para comenzar esteanalisis calculamos el valor de tension correspondiente a1/3mmHg, como se muestra en la Ec. 4.

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

Por otra parte tenemos que la variacion en la ganancia afondo de escala es

∆VinA/D = ∆Av ksensor Pmax (5)

Igualando 4 y 5 tenemos

∆Av =Av 1/3Pmax

= 4 (6)

De la ecuacion de ganancia del amplificador, tenemos queRG 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 sensibilidaddel sensor de presion, como la referencia del conversor A/D.Es decir, se produce una variacion de la presion medida apesar de que su entrada se mantenga constante. Luego de teneren cuenta los distintos parametros que afectan esta variacion,se llego a la conclusion que la maxima variacion de tensionadmisible es 16, 5mV para un error maximo en la medicionde 1/3mmHg a fondo de escala. Este valor pone restriccionessobre el ripple de salida de los reguladores. Los mismosdeberan poseer un ripple maximo de 0, 5% para una tensionnominal de salida de 3, 3V .

Es importante mencionar que el amplificador seleccionadoposee bajo offset de entrada, y por lo tanto no influye en eldesempeno del sistema.

II-C. Transmision y Recepcion

Para implementar la transmision y recepcion de los datos, seutilizan las facilidades del microcontrolador CC1010 utilizado.El mismo posee una entrada analogica, en la cual se conectala salida del amplificador. Esta entrada es convertida en unapalabra digital mediante un conversor analogico-digital de 10bits de resolucion. Una vez convertida la senal en un valordigital, es transmitida por radiofrecuencia a un nodo receptorimplementado utilizando el mismo microcontrolador. La bandafrecuencia utilizada es 433MHz.

Durante la etapa de transmision de datos, el consumo decorriente es de 14mA. Es por esto que en el transmisor sedeben limitar los tiempos de uso del canal de radiofrecuenciaal mınimo. Para esto, el microcontrolador utilizado cuenta conla posibilidad de apagar el modulo de transmision de datosmientras no se necesite. Para nuestra aplicacion, se realizala conversion analogica-digital en primer lugar, se procesanlos datos y se prende el modulo de radiofrecuencia recien

13


cuando se vaya a enviar el resultado. Por otra parte, en elreceptor no existen problemas de consumo, debido a que sepuede extraer energıa de la red electrica, o incluso del puertocon que este conectado el nodo a la computadora.

II-D. Presentacion de datos

Una vez que el receptor obtiene los datos de una medicion,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 unprograma 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 mostrarla forma de los valores obtenidos y su variacion a lo largo deltiempo, incluir condiciones de alarma. Para asegurar que lasalarmas sean atendidas, su condicion de apagado no puede sertemporal, sino que debe requerir la intervencion del personalde turno.

Figura 3. Programa desarrollado para el historial de presiones


Durante el proceso de validacion del sistema, se realizarontanto pruebas de calibrado en laboratorio, como pruebas defuncionamiento 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 enparalelo con nuestro sensor. En la figura 4 se muestra elresultado de variar la presion de entrada entre 0 y 50 mmHg,que seran las condiciones normales de funcionamiento. Comose puede observar, los resultados obtenidos concuerdan conlos valores indicados por la columna de presion de referencia.

Por otra parte, es necesario caracterizar la variacion dela medida entre distintos sensores. Para esto, se realizaronmediciones de ganancia y offset sobre una poblacion de 10sensores de presion. Los resultados concuerdan con el 1 %de variacion en la ganancia de los sensores, y una variaciondebida al offset de entrada menor a 1/3mmHg. Estos valorespermiten utilizar nuestro sistema sin necesidad de calibrado,caracterıstica fundamental a la hora de producir un dispositivoen grandes cantidades.

Por otra parte, el consumo del sensor es relativamentegrande, debido a que presenta una impedancia de entradade 3kΩ. Sin embargo, el sensor sera conectado unicamentedurante un instante de tiempo, mientras se esta realizando lamedicion. Como luego el sensor sera apagado en el resto del

Figura 4. Caracterizacion del sistema

proceso, dicho consumo no sera significativo en el consumototal del sistema.

Por ultimo se realizaron mediciones en la sala de terapiaintensiva en un hospital local. El motivo de dichas medidasfue obtener senales reales de presion endotraqueal, y ası poderoptimizar el calculo de los filtros y demas parametros delsistema. Para corroborar la validez de los valores obtenidos, seconecto ademas una placa adquisidora en paralelo con la salidade nuestro amplificador. Dicha placa adquisidora se conectapor un puerto USB con una computadora portatil donde seregistran los datos. La tension de alimentacion de la placaadquisidora se obtiene de la misma computadora. Esto esnecesario, ya que en todo equipamiento medico se requiere queno haya un camino de alimentacion directo entre el pacientey la red electrica. Los resultados obtenidos se muestran en laFig. 5. En la misma se puede observar la presion de salida delsensor amplificado y su correspondiente valor en mmHg. Seincluye 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 mayorcantidad de sensores, que realicen el relevamiento de otrasvariables medicas como podrıan ser el ritmo cardıaco y presionsanguınea, entre otras[13].

Para poder realizar y controlar las mediciones de variospacientes en paralelo, se propone ademas realizar una interfazque se conecte a internet. De esta manera, se pueden relevardatos de distintas habitaciones distribuidas a lo largo delhospital, o incluso entre distintos hospitales que compartanel sistema. Esto es particularmente util ya que la recepcionse puede realizar en cualquier computadora conectada a lared[14]. Por otra parte, el medico a cargo podrıa acceder a losdatos 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 presionendotraqueal en pacientes intubados. Dicha red es implementa-da con circuitos de aplicacion especıfica y microprocesadoresde proposito general. Esta aplicacion resulta particularmenteutil, ya que se obtienen variables de pacientes internadosque en la actualidad no se miden con regularidad. Esto a suvez podrıa disminuir enormemente los gastos en que incurrenlos hospitales locales, debidos a tratamientos posteriores a lainternacion, 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 sidodesarrolladas a lo largo del trabajo, mostrando la metodologıacon la que se ataco el problema que se pretendıa resolver. Enparticular, el sistema fue probado satisfactoriamente en labo-ratorio y en un hospital local. Se proponen algunas mejoras alsistema, las cuales seran implementadas una vez que se evaluela eficacia del sistema y determinen las condiciones optimasde 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 InternationalConference 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 andBiology 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 ofmedicine, 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,” Sao Paulo medicaljournal, 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 ofthe 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 ASICMicroprocessor Architecture

O. Lifschitz, J. A. Rodrıguez,P. Julian, O. Agamennoni

Instituto de Investigaciones en Ingenierıa Electrica - IIIE(UNS-CONICET)

Departamento de Ingenierıa Electrica y de ComputadorasUniversidad Nacional del Sur

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 abstractionwidely used in circuit theory, computer graphics, and systemidentification [1]. The evaluation of this type of functionshas been approached in different ways by diverse algorithmssuch as: simplicial paths [2], comparator architecture [3], andmore recently neural networks [4]. A dedicated microprocessornamed PWLR6 was designed using a full EDA flow usingstandard AMI 05 OSU standard cells library [5]. The µPwas 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 SetArchitecture). Absolute and relative jumps, ALU (ArithmeticLogic Unit), memory read and write, and register accessinstructions, provide a rich environment to exploit the PWLR6µP functionalities. In this paper, we present a set of debugfeatures and methodologies to proceed with a Post-siliconvalidation and testing environment requirements to deal withthe complexity of the PWL µP.

Specific Design For Testability (DFT) and observabilityfeatures were introduced in the early ASIC design stage. TheseDFT 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 simulationdata within a clock period resolution was achieved. Randomtests procedure were used to ensure a better test coverage inorder to guarantee the correct chip functionality. Morevoer,a Well known pre-silicon tests scenarios were prepared toconsistently evaluate each of the PWLs blocks separately incase of a bug or a missfunctionality occurs. Methodologiesfor power measurements and maximun operational frequencywere developed and are shown in the paper, together withexperimental results.

II. BRIEF DESCRIPTION OF THE PWLR6 ARCHITECTURE

In this section, a brief description of a digital architecturethat implements an R6 PWL is presented. The idea is toexplain the complextity level of the ASIC to evalute. Theproposed architecture is based on a microprocessor [7] schemethat includes an ALU (Arithmetic Logic Unit), a register fileand 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

XY Bus

MPC

MIR

SR-PM

Program Memory

Program Bus

Decode Logic

Bypass Logic

DFT

Control Unit Datapath

Fetch

Logic

Control Bits

Test Bits

Test MUX

Scan chain

DFT Bus

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-slaveconfiguration where the PWL is in the role of slave andthe master is implemented on a Xilinx Test board with aVirtex5 FPGA. The PWL uses a DDR2 Device where thecontrolller and the memory transfer hub (MTH) are realizedon the Virtex5. The MTH is responsable for adapted thememory controller with the PWL chip memory protocol,also allows the functionality of the systems at differentfrequencies between the memory controller and the PWLchip. The systems frequencies are: Master@100MHz, Memorycontroller@160MHz and the PWL@[6,25Mhz - 50MHz]. Themaster interconnects with a PC, through RS232, with theMatlab interface. The PWL chip is placed on a two layer PCB.This PCB includes some pin connectors for the logic analyzerand 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, eachof them running on a different part of the HW environment.PWL Assembler.- This assembler activates the PWL for theN-dimensional input data X from the master, calculates andsends 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 atmaximun load. The PWL has 256 by 20 bits wide instructionROM space. The master programs the PWL ROM whilethe PWL is in programming mode. The assembler code ishardcoded in the FPGA. The programming and executionmodes are set by the master.Master SW.- The master SW has four state machines andthe PicoBlaze micro-controller. The PicoBlaze is an eigth bitVHDL micro-processor and operates the RS232 interactingbetween 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: dataand 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 machineputs the PWL to work by sending the start signal and seriesXi inputs (Xi ! R6) to the PWL and then wait for the PWLto transfers the result back. This machine will send the finalresults to the Human Interface.DFT block.- Generates the debug features activation: Scan,Bypass-Scan and Bypass. (See DFT part). The selection willbe set by the picoblaze based on the human interface decision.This state machine performs the first data format before reachthe PC interface.PC SW.- Its a Matlab interface dealing with the instructioncommands to the PicoBlaze and formatting the data for thehuman interface. Also, creates the random cases and comparesthe chip results with the PWL implemented in a Matlab privatetoolbox.

IV. DESIGN FOR TESTABILITY

The main idea of the following structures is to help thedesigner during the validation process. This DFT strategydevelopment started in the design stage together with the chipdevelopment and its functionality was checked on simulationsat pre-silicon stage. Six DFT were created:Stop Clk.- Some events, internally or externally, could enablethe PWL chip clk freezing the execution. These events couldbe completely synchronized with the simulation tool in thecase the user needs a time correlation for simulator compari-son. This synchronization allowed an easy verification registerby register for clock by clock operation. The syncronizationwas achived by a counter that has the number of clocks,this ensures the correlation between the simulation and thechip. The option for an external Stop Clk signal assertion isavailable but this is asynchronous and no time correlation canbe guaranteed.Do 1 Clk.- Triggers a one PWL clock pulse allowing theexecution of the PWL routines step by step. This signalactivation can be external or internal. In the internal casewill be when other DFT are using it. In the external casethe 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. Thesesignals are selected from the data and control flow path.Mux.- This is an externally activated multiplexer that takesdifferent internal signals out to I/O pins. The mux out is inparallel format. The relation between the number of bits andthe number of observable registers is a trade-off and dependson design considerations. This DFT has ”on the fly” activation,meaning that it is capable of taking out signals while the chipis running. Of course, this is an expensive DFT due to theamount of I/O pins but, on the other hand, is the simplest oneto build. Also, this mux allows the creation of a ”signature”

17


signals on the logic analizer creating an easy scenario tocompare with the simulator.Scan.- This takes out a number of different bits coming fromdifferent internal PWL block. The scan out is serial on a daisychain format. As opposite to the Mux, the scan has to beactivated when the PWL is stopped by the Stop Clk signal. Interms of out pins, this feature is cheaper because used only toout pins: data and clock.Bypass-Scan.- It is similar to the Scan but acts only on theControl-Register. Due to its complexity and importance thecontrol register has a dedicated DFT. The Control-Registerhas the ASM instructions that are 20 bits.Bypass.- The Bypass DFT allows writing the control registerfrom the outside world putting aside the ROM interface. ThisDFT should be perfectly synchronized with the PWL clockto allow the correct work. The Bypass-scan and Bypass DFTwere introduced in the PWL silicon to replace the internalROM device in case of design or manufacturing failure. Theidea was to allow the ”onion peeling” procedure, means thatif ROM failure was detected, the chip debug would continueusing the Bypass DFT and validation process would not stop.

V. POST-SILICON

A. Block functional verification

The block functional verification requires to test every blockindependently. Asserting the functionality of each block allowsto build a step by step process and isolate problems when theyappear. This verification was done using a friendly and flexiblePWL assembler compiler. Six main blocks were included inthis verification process:Design for testability.- Much of these features were testedin pre-silicon using a logic analyzer but due to fact that thePWL 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 isinherited from design to design.FPGA State Machines.- The state machines were checkedwith a logic analyzer before PWL silicon arrival. Signalprotocol and timing were checked with the simulation resultscomparison.ROM Memory.- It was verified using a observavility DFTthat allowed to check the correct data was being written. Thiswas 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 toverify all the signals to ensure the correctness of the Xi data.Sorting.- Due its strong dependency with the n-dimensionalvalue, different set of inputs were used and the correct orderafter sorting routine were check with an obserbavility DFT.Changing different data sets and comparing with simulationresults allowed to verified the correct sorting routine.External Memory Access.- A bi-directional I/O was involvedhere so a particular PWL assembler was used to read and writeto different memory addresses. The data was verified using aDFT and a logic analyzer. Moreover, the whole system: PWL,

MTH and memory controller had a special attention duringvalidation 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 theaddress 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 andcorrelations test with the simulator. Random cases were com-pared with matlab toolbox using a ”Linear-Function” spaceinstead of no-linear to get a direct error calculation. The maindifference between these cases is the run speed. Means, thesimulations are some reduced set of Xi values running on thesimulations and all the DFT (Scan and Mux) values are gen-erated and used for comparison between Modelsim simulatorand the chip. In this case, the memory size used was verysmall and the values were hardcode on the simulated VHDLcode. On the other hand, the random cases are generated bymatlab and the whole 16MB memory map was used. Matlabcreated a random Xi input, send it to the PWL and the resultwas compared with the matlab calculation. The correct resultsof all these cases were the base for the maximum frequencytest on next section.

Figure 4 shows some of the random test results. The errorbetween PWL-chip and Matlab should be 0 as expected.

0 500 1000 1500 20000

20

40

60

80

Nº of running

F(x1

,...x

6)

PWL−chip Vs Matlab

MatlabChip 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 operationalattainable frequency for this design and technology. The I/Oand core power planes in the PWL are unified. This unificationlimited the highest voltage applied to the PWL due the I/Oclamping connection with the FPGA.In order to overcome to this voltage limitation the procedurewas to define a test that allowed extrapolation of the maximumPWL frequency, without changing the PWL core-I/O voltagebeyond the FPGA I/O limits. This test exercises the critical

18


path obtained from simulations. This critical was the partrelated with the ALU execution and was verified in thelaboratory by exercising different parts inside the PWL circuittill we have a functional failure. The failure or success of thistest was our fail/pass criteria in the Frequency Vs PWL Vcccore graph. The test consisted on reducing Vcc, maintaining afix PWL frequency, until a failure result occurred. A fail resultwas the one that gave a different number comparing with thesimulation results but the chip was still functional. The idea offunctionality was that only the numerical result was the errorand not the PWL protocol behaviour. The PWL frequencychange 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 frequencyfor 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 ]

Freq

[ M

Hz ]

Weak coverageStrong coverage

Fig. 6. Freq. Vs Vcc.

The difference in coverage is related with the simulationand random cases mentioned before. Although boths kind oftest point to the ALU execution, the random test were morethan twenty thousand cases and simulations cases are nine.Thats why the difference in the frequency results observedon picture Frequency Vs Vcc results.

VII. POWER MEASUREMENTS

The power consumption has three main components: staticconsumption, clk tree and the dynamic consumption. The

procedure to measured each components was done followingthe next table:

Power Item CLK Reset RunningStatic off on off

Clock Tree on on offDynamic on off on

The running condition means that the PWL is executing theassembler instructions.

Power consumption was measured using a series resistoron the PWL Vcc connection. The value of this resistor iscalculated to keep the voltage on the resistor at working rangebetween 600mV and 1500mV. The idea was to maintain thesame resistor value for all the measurments. The resistor was100!. The measurements were done with two devices: digitalscope (Agilent DSO3062A) and a multimeter Hewlett Packard(HP34401A). The idea of using both elements was to correlatethe results.

A. Consumption time picture

To get an idea of the PWL power consumption, a scopepicture was captured showing the consumption while a test ison execution.Figure 7 shows the power consumption Vs time during a testexecution.

−20 0 20 40 60 80−4

−2

0

2

4

6

8

10

Time [ us ]

Powe

r [ m

W ]

Power PWL (Freq: 6,25MHz)

Stand byGetting XiSortingCalculation & mem accessSending resultsWait for a new XiReq

Fig. 7. Power Activity.

In the Figure 7 the Req signal belongs to the asynchronyprotocol and is shown here just as an activity reference. (Thissignal does not have the correct voltage scale.)The consumption time picture was a base for the creationof a ”Power Virus”. The worst power consumption occurredduring ”calculation and memory access”, based on these factsa PWL assembler which fully activates the ALU and the I/Owas done. This assembler is called Power Virus because isthe 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. Inthis power virus an I/O out instruction was added, this givesthe power virus with pad activity. The power virus assemblerwas used to calculate the consumption for different Vcc coresand operation frequencies. Also, gives the worst case powerenvelope 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 thePWL reset was asserted. Using the power virus assembler, theprocedure was to measure the power consumption for differentoperation frequencies. As expected, the maximum power quotewas for the power virus with full I/O activity. Table I shows thepower measurements results for the: clock tree, power viruswith and without I/O activity.

TABLE IPOWER @3,3V

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

25 22,70 34,91 49,6812,5 11,42 17,60 24,876,25 5,69 8,75 12,40

VIII. CONCLUSIONS

In this paper we have presented a post-silicon validation andtesting methodology. Three important conclusions were: theproactive work done with the environment preparations, like:DFT features, different assembler codes, assembler compiler,etc.Defined methodologies setups for power consumption, blocksvalidation and the attainable maximum frequency for this kindof silicon.Studied the importance of defining a correct coverage duringsilicon validation specially when the pre-silicon could notcover all the cases due to the complexity of the testbenchscenarios.

IX. ACKNOWLEDGMENT

We would like to thanks to Ing. Ariel Arelovich for the PWLassembler 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”, inProc. 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. Parlanti Laboratorio de Procesamiento Digital de Señales

Universidad Nacional de Córdoba Có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 activas como la presentada, se logran atenuaciones apropiadas y eficientes para el uso comercial.

Palabras claves: CAR, Controlador Adaptativo, FxLMS

I. INTRODUCCION En ambientes industriales, receptáculos cercanos a motores

(como en la cabina de un avión o automóvil) o en entornos ruidosos en general, los auriculares utilizados para la cancelación acústica pasiva de ruido suelen ser efectivos solamente a frecuencias superiores a los 500 Hz. Como complemento de los auriculares pasivos, los sistemas de Control Activo de Ruido (CAR), apuntan a cancelar componentes de ruido de baja frecuencia. Cuando esta cancelación se produce en un espacio reducido, como dentro de un auricular, el sistema CAR se lo denomina “unimodal” y su objetivo es producir una señal de igual amplitud y fase contraria al ruido remanente dentro de la cavidad del auricular, comúnmente llamado “antiruido”[1].

El ruido dentro de la cavidad del auricular puede variar en el tiempo, ya sea porque la fuente de ruido ha variado, o porque la 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 en consecuencia la señal antiruido producida. A tal fin utiliza la diferencia entre la señal producida y la deseada (el ruido a cancelar) para modificar su propia función de transferencia mediante algún algoritmo apropiado, “aprendiendo” entonces de 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 los filtros de respuesta al impulso infinita (IIR, Infinite Impulse Response). La modificación de la función de transferencia requerida se realiza entonces modificando en forma automática los 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 Signal Processors), de gran capacidad de procesamiento, tanto la adaptación de los coeficientes como el proceso de la señal de entrada 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 DSP comercial, aplicado a la cancelación de ruido dentro de la cavidad de un auricular comercial.

II. CARACTERÍSTICAS DE DISEÑO

A. Arquitectura general de un sistema adaptativo En general, un sistema adaptativo modifica su propia

transferencia partiendo de cuán diferente sea su salida respecto de la salida ideal o deseada. Este principio puede aplicarse a diferentes fines, en un variado campo de las ciencias. El esquema de la Fig. 1, muestra el caso de un sistema adaptativo diseñ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 la salida del mismo, d(n), representa la señal que se desea cancelar. La señal de referencia se introduce al sistema adaptativo, compuesto por un controlador con transferencia H(z) que produce la salida y(n) y el algoritmo de adaptación del controlador.

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)

+ _

Sistema Adaptativo

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 respuestas al impulso de P(z) y H(z) respectivamente. Se dice que el sistema ha convergido cuando e(n) ≈ 0 y H(z) ≈ P(z), deteniéndose la adaptación. Esto sucede siempre que x(n) tenga suficiente contenido espectral para excitar todos los coeficientes del filtro FIR en el proceso de aprendizaje. El algoritmo 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 del filtro FIR, y µ el paso o velocidad de adaptación entre la iteración n y la n+1. Un valor de µ pequeño hará el aprendizaje lento, 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 convergencia hacia el valor ideal, normalmente llamada solución de Wiener.

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

µ(n)= α/LPx(n) (3)

donde α es una constante y Px(n) es la potencia de la señal de referencia x(n) en el instante n. De esta forma el paso µ(n) utilizado con señales de baja potencia será mayor, acelerando el proceso de convergencia, mientras que con señales de mayor potencia µ(n) será menor, asegurando la estabilidad del sistema.

B. Arquitectura de un CAR en un auricular En el caso del sistema CAR aplicado a la cavidad de un

auricular, P(z) representa la transferencia acústica entre el exterior 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 el ruido a cancelar, remanente en el interior de la cavidad. En este caso, la señal de error se encuentra en el entorno acústico y no en el eléctrico. Esta situación se muestra en la Fig. 2.

En este caso, el controlador H(z) no podrá gobernar la señal antiruido directamente, sino a través de elementos físicos como un conversor Digital/Analógico y un parlante. Del mismo modo, el error acústico y la señal de referencia deberán ser captados por micrófonos y ser convertidas a digital por un conversor Analógico/Digital, para transformarse en la señal discreta 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 una sola función de transferencia llamada “camino secundario” S(z).

Para compensar el efecto de S(z) y aplicar los mismos criterios de aprendizaje de (2), la señal de referencia x(n) debe afectarse 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 de referencia filtrada o FxLMS (por sus siglas en ingles de Filtered x Least Mean Squares) [4].

C. Estimación del camino secundario La Fig. 2 supone que la transferencia S(z) se conoce, ya que

debe usársela para filtrar la señal de referencia x(n). En general esto no será así. Además la función de transferencia puede variar en el tiempo, producto del envejecimiento de los materiales utilizados, etc. Es por eso que la presencia del camino secundario desconocido o variante en el tiempo, obliga a introducir un segundo sistema adaptativo para estimar su función de transferencia. El esquema se muestra en la Fig. 3. Una vez convergido este segundo sistema adaptativo, su función de transferencia Sp(z), será una buena aproximación a S(z), y se utilizará una copia de la misma, cSp(z), para filtrar la señal de referencia x(n), produciendo la señal de referencia filtrada x’(n).

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

f(n) = e(n) – v(n)*sp(n) = x(n)*p(n) – x(n)*h(n)*s(n) + v(n)*s(n) – v(n)*sp(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 camino secundario, 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. Si ambos procesos adaptativos se realizan simultáneamente, se dice que el camino secundario se modela “on-line”.

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

P(z)

H(z)

LMS

ruido deseada

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 el tiempo de proceso del sistema adaptativo más el retraso del camino secundario S(z) debe ser menor al retraso de la transferencia P(z).

D. Alcance del CAR Al diseñar un sistema CAR, lo primero que debe definirse

es el tipo de ruido que se desea cancelar, dependiendo éste del ambiente donde se deba desempeñar. En ambientes con motores, turbinas, aire acondicionado, sirenas, etc, el ruido a cancelar será principalmente de banda angosta, es decir su espectro estará concentrado alrededor de frecuencias bastante definidas y su aspecto temporal será repetitivo. En cambio en ambientes donde el ruido represente música, conversaciones entre personas, ruido blanco gausseano, etc, el ruido a cancelar será de banda ancha, encontrándose un contenido espectral más distribuido. Este trabajo se concentra en el primer caso, la cancelación de ruido de banda angosta.

La Fig. 3 muestra una arquitectura que puede cancelar tanto ruido de banda ancha como de banda angosta, ya que se dispone de la señal de referencia x(n), y cualquiera sea su espectro 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, denominado micrófono de referencia. Si se desea que el CAR sólo actúe sobre ruidos de banda angosta, como en nuestro caso, el esquema de la Fig. 3 puede simplificarse, prescindiendo del micrófono de referencia. En ese caso la señal x(n) podrá estimarse dentro del mismo proceso, según se muestra en la Fig. 4.

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

x(n) = y(n)*csp(n) + f(n) = y(n)*csp(n) + d(n) – y(n)*s(n) + v(n)*s(n) – v(n)*sp(n). (6)

Una vez convergidos ambos sistemas cSp(z)=Sp(z)≈S(z) y entonces x(n)≈d(n), por lo que el esquema de la Fig. 4, puede asimilarse 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 el esquema 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 de referencia.

Figura 4. CAR para ruidos de banda angosta

En contrapartida, el esquema de la Fig. 4 solamente funcionará 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, se

realizó sobre el DSP StarCore MSC7116 de alto rendimiento de la empresa Freescale Semiconductor Inc. El StarCore MSC7116 es un DSP de punto fijo de 16 bits de ancho de palabra, de bajo costo, con un núcleo de cuatro ALUs, capaz de realizar 1000 MMACS a 266MHz. La capacidad de procesamiento del DSP es suficiente para realizar el cálculo computacional complejo que requiere la realización de los filtros 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), que corre sobre el DSP. Dicho sistema operativo es el SmartDSP de la empresa Freescale Semiconductor Inc, diseñado especialmente para los DSP de la familia StarCore. La interface de programación de aplicación o API (por sus siglas en inglés Application Program Interface) del SmartDSP [6], esta formada por funciones desarrolladas en lenguaje C, que permiten una fácil configuración y utilización de los periféricos del 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 del controlador se empleó el driver del periférico TDM (del inglés Time Division Multiplexing) para la entrada y salida de datos de ambos canales de audio (derecho e izquierdo) en el DSP. La velocidad de entrada y salida de datos es la frecuencia de muestreo del sistema, fijada en 8KHz. Este valor de frecuencia de muestreo es suficiente para la aplicación, ya que el rango de frecuencias de interés de un sistema CAR corresponde a frecuencias por debajo de los 500Hz.

El programa de aplicación fue desarrollado íntegramente en lenguaje C, empleando funciones denominadas “intrínsecas” a la hora de realizar y optimizar el procesamiento de los filtros adaptativos. Estas funciones intrínsecas son funciones en C que no pertenecen a la API del RTOS, sino que son funciones propias del compilador [7], especialmente diseñadas para realizar 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

Sp(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 intercalan directamente en el código en lenguaje C, permitiendo al programador aproximarse a la eficiencia propia del lenguaje ensamblador del DSP.

La precisión de la mayoría de los datos se fijó en una longitud de palabra de 16 bits en el formato de punto fijo. Para los coeficientes de H(z) se experimentó con 16 y 32 bits. Para mejorar 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 la señal de error f(n), implicando esto la realización de multiplicaciones de 32 x 16 bits en la actualización de los coeficientes de H(z) en el segundo sumando de (5). Esto llevó a una mejora importante en el desempeño de todo el sistema.

El modelo experimental implementado para evaluar el desempeño del CAR aplicado a un auricular, se basó en aplicar para cada canal de audio en forma independiente, un esquema como el presentado en la Fig. 4, utilizando el algoritmo FxLMS en su versión normalizada. El diagrama en bloques para cada canal del sistema CAR, se muestra en la Fig. 5. A continuación se 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 desarrollo

de software para aplicaciones que utilizan los DSP StarCore MSC711x. El uso de la misma permitió y facilitó la descarga y evaluación del software del controlador sobre el DSP, vía puerto paralelo con una PC portátil. Además por medio del CODEC integrado en la misma, ingresan y salen al DSP las señ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/D y 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éreo

SHP1900 de Philips, de una relación calidad-precio conveniente. Dada la característica de ser un auricular circumaural, las orejas de quien escucha son cubiertas totalmente 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ófonos omnidireccionales ECM-30, los cuales son micrófonos del tipo Electret. Este tipo de micrófonos tienen características que son más que suficientes para aplicaciones de CAR (en lo que respecta a sus anchos de banda, sensibilidades y relaciones señ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 del auricular determina la zona de quietud, y fue sugerida por los autores 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ímpano del oído, además de demostrarse experimentalmente que esta configuración presenta la respuesta en frecuencia de la magnitud del camino secundario, más plana que otras configuraciones [9, 10].

C. Placa amplificadora Se desarrolló un preamplificador para cada micrófono y el

amplificador de potencia del auricular. Cada preamplificador es del tipo transistorizado y tiene como función el acondicionar el nivel bajo de la señal de cada micrófono hasta un nivel de señal adecuado para cada conversor A/D. El amplificador de potencia basado en el integrado LM386, entrega la potencia necesaria para excitar los parlantes del auricular.

IV. RESULTADOS Para poder analizar y graficar los resultados obtenidos de

las mediciones del sistema CAR se empleo el programa computacional 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 para estimar la señal de referencia x(n). Además, se la utiliza para la actualización de los coeficientes del controlador H(z) con el algoritmo FxLMS, según (5). En la presente implementación se realizó una identificación del camino secundario S(z) de manera off-line.

Para realizar la identificación off-line de S(z), Sp(z) se implementó con un filtro adaptativo FIR de longitud Ls = 128 coeficientes de tal manera de cubrir la mayor parte de su respuesta al impulso. Los coeficientes de Sp(z) fueron adaptados con el algoritmo LMS, según (2). Como señal de aprendizaje v(n) se empleó ruido blanco de media cero y varianza 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 donde se observa un retardo de aproximadamente 40 coeficientes, o 5ms para una frecuencia de muestreo de 8kHz. La hoja de datos del CODEC indica que él mismo introduce un retardo fijo de 36 muestras, que representa casi todo el retardo presente en 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. La Fig. 7 muestra la magnitud de la respuesta en frecuencia de la estimación de S(z).

Para observar la evolución temporal del proceso aprendizaje de Sp(z), se utilizó una ventana temporal de 16.000 muestras, es decir 2 segundos. El proceso de aprendizaje se muestra en la Fig. 8. En la misma la señal de ruido blanco filtrada por S(z) esta graficada en azul (en este caso la única componente de e(n) en la Fig. 4), el ruido blanco filtrado por el filtro adaptativo Sp(z) en verde y el error de identificación en rojo (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 en

MATLAB diferentes ruidos de prueba. Luego se los emitió con los parlantes de una PC portátil. Una persona portando los auriculares 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 la estimación de S(z) obtenida previamente de manera off-line. Para la adaptación de los coeficientes del controlador H(z) se utilizó la versión normalizada de FxLMS, el algoritmo FxNLMS, que combina (5) y (3). Para H(z) se empleó un filtro adaptativo FIR de longitud Lh = 160 coeficientes. En (3) se utilizó α = 0,016 y para calcular de manera eficiente una aproximación P’x de la potencia Px se utilizó una ventana exponencial 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)) entre iteraciones, y utilizar un factor β que determina la rapidez en que los cambios de x(n) se reflejarán en P’x(n). Para ello se eligió β = 0,002 como compromiso entre una aproximación buena y estable de Px 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 un valor mínimo P’xMIN(n) = 0,01.

El primer ruido de prueba generado en MATLAB fue un tono de 200Hz, con una amplitud tal que distorsione la salida de los parlantes de la PC portátil, generando así suficiente contenido 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) con coeficientes de 16 bits y en rojo con coeficientes de 32 bits. Dicha medición se obtuvo luego de 3 segundos (24.000 muestras) 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 el circuito. La atenuación que se logró para el tono de 200Hz, sus armónicas y el tono de 50Hz se muestran en la Tabla I, para ambas precisiones de los coeficientes de H(z). Para armónicas siguientes a 600Hz prácticamente no se percibe atenuación.

El desempeño del controlador también fue probado con un tí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últiplos de 60Hz de distinta amplitud, con la mayor potencia concentrada en las componentes de 240, 300, 360, 420 y 480Hz. La medición también fue hecha luego de haber transcurrido 3 segundos (24.000 muestras) de comenzado a actuar el aprendizaje del controlador H(z).

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

Am

plitu

d

Cantidad de Coeficientes del Filtro

Mag

nitu

d (d

B)

Frecuencia (kHz)

Am

plitu

d

Muestras

28


Figura 9. Espectro de potencia de ruido de 200 Hz distorsionado (línea azul), 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)


(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ñal error 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)


(dB)


(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 este

trabajo se resumen las siguientes conclusiones:

• El sistema CAR diseñado e implementado atenúa en forma 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 utilizado fue suficiente para realizar el procesamiento de ambos canales independientes de audio en tiempo real en forma simultánea.

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

• Para las señales de prueba utilizadas el usuario manifestó que el ruido remanente en la cavidad del auricular resultó en niveles confortables, y fue sensiblemente menor al percibido sin la activación del CAR.

Las direcciones futuras se orientarán al análisis, diseño e implementación de un CAR aplicado a la cancelación de ruido de banda ancha en un auricular. Asimismo, se investigarán y analizarán otros algoritmos de adaptación, implementándolos en condiciones reales y con componentes disponibles comercialmente.

AGRADECIMIENTOS A la Secretaria de Ciencia y Tecnología de la Universidad

Nacional de Córdoba, a la empresa Freescale Semiconductor, Inc.

REFERENCIAS [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 Sustems

Theory, R. E. Kalman and N. DeClaris, Eds. New York: Holt, Rinehart and Wiston, 1970, pp. 563–587.

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

[5] M. T. Akhtar, M. Abe and M. Kawamata “Noise power scheduling in active noise control systems with online secondary path modeling” in IEICE 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: C Compiler 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 Control

Headset: 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 Headphone Applications”, IEEE Transaction on Control Systems Technology, vol. 14, no. 2, pp. 331-335, Mar. 2006.

[11] MathWorks. Filter design toolbox. Active Noise Control Using a Filtered-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 FPGA Desarrollo de la trasformada Wavewlet en 2-D

Melo Hugo Maximiliano; Gutierrez Guillermo; Perez Alejandro; Cavallero Rodolfo

Centro Universitario de Desarrollo en Automación y Robótica

Universidad Tecnológica Nacional

Facultad Regional Córdoba

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

prototipos funcionales incorporables a sistemas embebidos

basados en tecnología FPGA. Se describen las herramientas de

alto nivel utilizadas y se desarrolla, paso a paso, un módulo IP

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

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

I. INTRODUCCIÓN

Uno de los proyectos desarrollados en el CUDAR de la

Universidad Tecnológica Nacional Facultad Regional Córdoba es la Compresión de Video con Wavelet en Lógica Programable. Como plataforma de Hardware se ha utilizado la FPGA VirtexII Pro de la empresa XILINX, la cual cuenta con dos procesadores embebidos en silicio tipo PowerPC. El sistema 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 los cuales son implementados directamente como hardware. Durante el proceso de desarrollo se investigaron y probaron distintos métodos disponibles para prototipado rápido de funciones. El método descripto en el presente trabajo hace uso de uno de los programas más difundidos en el área matemática: MatLab perteneciente a la empresa MathWorks y su módulo asociado Simulink, que es una plataforma versátil de diseño y simulación de sistemas dinámicos, lo que permitió que integrantes del proyecto con poca experiencia en la metodologí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 crecimiento que está mostrando la tecnología de las FPGAs, las cuales incluyen con mas frecuencia procesadores embebidos en silicio, la posibilidad de portar todos los conocimientos matemáticos a hardware programable de manera simple disminuye de forma importante el número de horas hombres y tiempo de depuración, lo cual tiene un marcado impacto en los costos y el tiempo de prototipado necesario para el desarrollo de nuevos productos. Los costos asociados con la adquisición de las distintas herramientas utilizadas son amortizados rápidamente con los frutos de su aplicación.

Las empresas fabricantes de FPGA han invertido mucho esfuerzo en el desarrollo de herramientas de alto nivel que faciliten la implementación de sistemas complejos en sus dispositivos. Un ejemplo de este tipo de software es el System Generator de la empresa XILINX. Este programa contiene un conjunto de bloques para utilizar con el SimuLink. Emplea el concepto de “cajas negras” y de abstracción de hardware, con el objetivo de poder llevar a cabo un diseño en bloques funcionales y así obtener una concepción de alto nivel que pueda ser simulada utilizando recursos ya disponibles en SimuLink. El System Generator puede ser también utilizado como 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 empresa XILINX propone como herramienta de alto nivel para desarrollo de sistemas embebidos el EDK (Embedded Development Kit). Esta plataforma de software se compone del XPS (Xilinx Plataform Studio) para el desarrollo del hardware y el SDK (Software Development Kit) para el desarrollo de software. Estas herramientas están pensadas para acortar 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 System Generator. Cada bloque funcional es un dispositivo de hardware 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 disponibles en la plataforma.

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

II. WAVELET

Las Wavelets son familias de funciones que se encuentran

en el espacio y se emplean para el análisis, examinan a la señal de interés para obtener determinadas características de espacio tamaño y dirección. La familia está definida por:

30


0,,

abaa

a

bxh

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 la mejor concentración en información de tiempo y frecuencia [1].

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

A. Tipos de Wavelets

Segun la aplicación se selecciona la Wavelet madre de la cual 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 bajos y pasa altos seguido de etapas de down sampling que generan la descomposición, como se aprecia en la Figura 2. De la misma forma la recontrucción es realizada por bancos de filtros y 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 una

muestra o intercalando un cero entre ellas [3].

Figura 2. Descomposición Simple

Una imagen es una matriz de datos en donde cada elemento representa un pixel, en caso de ser imagen color la misma puede representarse por sus componentes RGB o YCrCb, para aplicar la transformada Wavelet en dos dimensiones utilizando el metodo de filtros separables, es necesario recorrer la matriz de 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:

kj

ni kjniNE bbD

,

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 de frecuencia 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 el incremento de las frecuencias. Estas propiedades quedan reflejadas en la Transformada Wavelet Discreta de la imagen [4].

31


En compresión y en algunas otras aplicaciones de la transformada 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 en la Figura 4.

Figura 4. 3 Niveles de Wavelet en 2-D

III. IMPLEMENTACIÓN

Para la implementación de la transformada Wavelet en 2-D es 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 la transformada.

Cada una de las etapas se presenta con un módulo independiente y la unión entre ambos se realiza con un código de 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étodo empleado y los resultados obtenidos.

A. Implementación del prototipado rápido

1) Filtro FIR Filtro FIR en su forma directa

Figura 5. Estructura filtro FIR.

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

Se destaca que el parámetro M-1 es el orden del polinomio y orden del filtro, mientras que la cantidad de coeficientes del filtro 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 de MatLab 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 Wavelet madre es una Daubechies 3. Los filtros resultantes para esta Wavelet son de orden 5 con un total 6 coeficientes.

A continuación se realiza el esquemático de la Figura 6 en entorno SimuLink, utilizando bloques propios de SimuLink y System 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ón simple, 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:

enteraparteTruncación

filtrodelOrdenentradadeDatosN

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 en hardware 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 matriz de datos, se utiliza programación directa en MatLab, y se aplica la 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 son extremadamente simples de realizar, la mayoría de ellas se reducen a operadores, como la que devuelve un vector, a partir de recorrer la matriz por columnas. Para obtener el barrido horizontal y vertical se utiliza la misma función pero aplicada a la matriz original o a su transpuesta. Para poder hacer uso de este método es necesario que la matriz sea cuadrada y además debe 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 se obtienen 5002 datos, lo cual no es compatible con una matriz rectangular. A los efectos de lograr una matriz rectangular se ensayaron las siguientes soluciones: a) se agregaron 98 ceros para hacer compatible el número de datos con una matriz rectangular necesaria para la siguiente etapa, lo que dio como resultado una alteración de la imagen reconstruida ya que los ceros quedaban embebidos en el análisis. b) se optó por truncar el número de datos, considerando válidos 5000 datos. Durante los 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 datos de la descomposición, el valor de M se obtiene truncando la parte entera de la siguiente relación:


filtrodelOrdenM

2

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

2

EntradadeDatosN

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

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

Figura 7. Recomposición Simple

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

2)(' entradadeDatosN

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

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

La teoría de banco de filtros utilizada para la implementación de la transformada Wavelet, está planteada y funciona adecuadamente para señales infinitas, pero se producen distorsiones en los límites de las señales finitas, como es 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 alguna manera. La bibliografía consultada propone entre otros el método de convolución circular y la reflexión simétrica, que se obtienen mediante la reflexión y la repetición simétrica de las muestras en la frontera. MatLab también plantea la posibilidad de relleno con ceros.

Estas ampliaciones no son arbitrarias y dependen exclusivamente del orden del filtro. Pese a la extensión, la salida continúa generando distorsión en los bordes, sin embargo es bastante fácil ver la reflexión simétrica también a la 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, db3 corresponde al tipo de onda utilizado para el cálculo de coeficientes y las salidas son Ap y De corresponden a la Aproximación y Detalle respectivamente.

5) Resultado de la implementación propuesta

Al comparar la imagen reconstruida con la imagen original utilizando el método implementado, se hallaron errores en el margen superior izquierdo de la imagen, de manera más específica en una submatriz de n x n donde n es la cantidad de coeficientes del filtro implementado para Daubechies 3.

Como solución a este problema se agregaron marcos a la imagen original. En esta experiencia para prototipado rápido se utilizó un marco cuyo valor numérico era el uno, esto permitió apreciar el comienzo de la imagen al finalizar el marco, y pese a que no se empleó ninguna extensión de frontera se logró una reconstrucción perfecta. Esto se debe a que los errores de los procesos de truncación de información para la formación de matrices 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 y Robótica (CUDAR) actualmente está incorporando estos métodos a las etapas de transformación para la compresión de video.

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ódulo desarrollado en un sistema real.

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

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

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

Del trabajo realizado con System Generator resulta un módulo que tendrá por puertos en la entidad principal dos registros de entrada/salida de 8 bits, una entrada para el reloj del sistema y una entrada de chip enable. Para embeber el mismo se ejecuta el asistente “Create or import Peripheral” del entorno XPS [6].

Los pasos para implementar un sistema embebido utilizando 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 propiedad intelectual (IPIF). La existencia de los dos registros accesibles por software que serán los mismos que necesita el módulo generado por System Generator.

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

Una vez verificada la incorporación, mediante la síntesis de las fuentes, se agrega el IP desde el repositorio en el entorno EDK, 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 filtro datos enviados por el puerto serie de una PC conectada al sistema. Los datos procesados se leen del registro de salida y se envian a una PC por el puerto serie, los mismos son almacenados y posterirmente contrastados con los resultados de las simulaciones realizadas en SimuLink.

34


IV. CONCLUSIÓN Y FUTUROS TRABAJOS

Las pruebas realizadas con la metodología utilizada demostró ser efectiva para la implementación de módulos IP, la interacción entre las herramientas de alto nivel demostró ser robusta y confiable. La posibilidad de utilizar la potencia de MatLab 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ón y desarrollo. La evolución de las herramientas de desarrollo de sistemas embebidos en plataformas FPGA muestran un crecimiento importante y sostenido de este campo en este tipo de tecnologías.

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

REFERENCIAS

[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 to Wavelets and Wavelets Transforms”. Electrical and computer

engenieering departament. Rice University. Houston, Texas.

[4] Borja José García Menéndez; Eva Mancilla Ambrona; Ruth Montes

Fraile. “Optimizacion de la transformada Wavelet Discreta” Universidad complutense de Madrid – Facultad de informática 2004 – 2005.

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

[6] Perez, Alejandro; Gutierrez, Francisco, Rodolfo Cavallero, Nicolas

Ravotti “Desarrollo de sistemas embebidos en FPGAs. Diseño e incorporación de periféricos”.

35


FPGA, Verilog, VHDL y HDLs

36


37


Implementacion en FPGA de decodificadores LDPCde baja complejidad

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

Universidad Nacional de Mar del PlataEmail: [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 (incluidaslas 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 senal a ruido dela senal recibida del canal.

I. INTRODUCCION

Los codigos de paridad de baja densidad (LDPC) estan reci-biendo mucha atencion debido a su funcionamiento cercanoal 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ınimacuadrada, tiene la ventaja de no requerir el conocimiento de laproporcion de senal a ruido de la senal recibida. El desempenode este algoritmo es similar al del algoritmo de suma-producto.

Los cocientes y productos involucrados en estos algoritmoshacen que sean difıcil su implementacion en forma sencilla enlogica programable.

En este trabajo se muestra como es posible implementarambos decodificadores LDPC (suma-producto y distancia-suave) en FPGA [5] utilizando solo operaciones de suma-restay tablas de busqueda. Estos decodificador pueden trabajar concualquier tamano y tipo de matriz de paridad H (incluidas lasgeneradas aleatoriamente, las generadas con una determinadaregla de construccion, como las quasi-cıclicas [6],[7], sean detipo sistematico, o no sistematico) y su arquitectura puede serfacilmente configurada para diferentes tasas de codigo.

Los resultados obtenidos muestran que no hay una grandiferencia en el desempeno de decodificacion al utilizar losdecodificadores propuestos con respecto a decodificar usandolos 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.

II. DECODIFICADOR LDPC

En los codigos LDPC [1] existe una matriz de paridad H,la cual cumple con la condicion H r = 0 para todo vectorr del codigo. La esencia del algoritmo de decodificacion [1]es encontrar el vector r, (el cual es una estimacion del vectorr ), 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ımbolosdel vector r), y los nodos de paridad, (representativos de lasecuaciones de paridad que se vinculan con los sımbolos de r).

Este proceso de intercambio de informacion entre nodos esiterativo. El proceso se detiene si se cumple la condicion dadapor (1), con lo cual se obtiene un mensaje valido, o bien, siel numero de iteraciones establecido es alcanzado sin que secumpla 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 estabasado en el algoritmo de decodificacion de suma- productointroducido por D. J. C. MacKay y R. M. Neal [1]. Acontinuacion se detalla brevemente su funcionamiento.

Si yj es el sımbolo obtenido a la salida del canal en eltiempo j, la probabilidad a priori F x

j de que el j−esimosımbolo sea x, con x = 0, 1 esta dada por:

F 1j = e−f1

j =1

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

F 0j = e−f0

j = 1− F 1j (3)

se pueden hallar |f1j | y |f0

j | como:

|f1j | = ln

(1 + e−2yj/σ2

)= f+(2yj/σ

2, 0)

|f0j | = 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 conjuntode columnas que tienen elementos no nulos para la fila i, yM(j) al conjunto de filas con elementos no nulos para lacolumna j. Igualmente f−(a, b) es una tabla de busqueda conentrada |a− b| (Ver apendice A).

38


TABLA IRESUMEN DEL ALGORITMO SR

Inicializacion

q0ij = f0

j q1ij = f1

j

Paso horizontal 1

δqij = max(−q0ij ,−q1

ij) + f−(q0ij , q1

ij)

sij = 0 si −q0ij ≥ −q1

ij sino sij = 0

Paso horizontal 2

δrij =∑

N(i)

δqij − δqij

sδrij =∑

N(i)

sij − sij

Paso horizontal 3

si sδrij es parr0ij = lg(2)− f+(δrij , 0)

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

si sδrij es imparr0ij = lg(2) + f−(δrij , 0)

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

Paso vertical

cxij = −fx

j +∑

M(j)

rxij − rx

ij

q0ij = −c0ij −max(c0ij , c1ij) + f−(c0ij , c1ij)

q1ij = −c1ij −max(c0ij , c1ij) + f−(c0ij , c1ij)

Estimacion del sımbolo decodificado r(j)

cxj = −fx

j −∑

M(j)

rxij

rj = 0 si c0j ≥ c1j sino rj = 1

IV. ARQUITECTURA DEL DECODIFICADOR DESUMA-RESTA (SR)

En la Fig. 1 se observa el decodificador implementado. Lamemoria ROM H solo almacena la ubicacion de cada “uno”en la matriz H, su tamano depende del numero de columnascon “unos” en cada fila y del numero de filas que posee. Porejemplo, para una matriz H1 generada aleatoriamente, de 60×30, el tamano de ROM H es de 256 palabras de 6 bits, y parauna matriz H2 generada aleatoriamente, de 1008× 504, es de4096 palabras de 10 bits. La ROM num unos fil almacenael numero de columnas con “unos” que tiene cada fila. Estamemoria se utiliza para poder indexar y poder ası recuperarjunto con la ROM H, la posicion de cada “uno” en la matrizH. Las memorias ROM ftabla+ y ROM ftabla- contienen lastablas de busquedas f+(a, b) y f−(a, b). Ambas tablas son de256 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 f0 y f1 cada vez que ingresa una nuevapalabra al decodificador. Su tamano depende de la longitud depalabra utilizada.

Las memorias RAM q0 y RAM q1, poseen igual cantidadde palabras que la memoria ROM H, pero son de 16 bits. LasRAM q0 y RAM q1 realizan varias funciones: En la inicializa-cion almacenan los valores de q0ij y q1ij . En el paso horizontal1, RAM q0 guarda los valores de δqij y RAM q1 guarda losvalores de sij . En el paso horizontal 2 se almacenan los valoresde δrij y sδrij . En el paso horizontal 3 se almacenan losvalores de r0ij y r1ij . Finalmente en el paso vertical se vuelvena almacenar los valores de q0ij y q1ij . Esto le da un alto gradode reutilizacion a estas memorias.

V. ALGORITMO DE DECODIFICACION DE DISTANCIASUAVE 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 tiempoj, suponiendo que la informacion es transmitida con formatopolar normalizado con amplitud ±1; la probabilidad a prioriF x

j de que el j−esimo sımbolo sea x, con x = 0, 1 estadada por (2) y (3).

En el algoritmo de decodificacion de distancia suave (DS) elcalculo de probabilidades [3][4] es reemplazado por el calculode 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 tambiense 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 observarsolo se realizan comparaciones, sumas, restas y busquedas entablas.

VI. ARQUITECTURA DEL DECODIFICADOR DSS

En la Fig.2 se observa el decodificador implementado. Lamemoria ROM H solo almacena la ubicacion de cada ”uno”en la matriz H, su tamano depende del numero de columnascon ”unos” en cada fila y del numero de filas que posee. Porejemplo, 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 = d0

j (j) q1ij = d1

j (j)

Paso horizontal 1

σqij = +f+(q0ij , q1

ij)

δqij = −f−(q0ij , q1

ij)

sij = 0 si −q0ij ≥ −q1

ij sino 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 parr0ij = −f+(σrij , δrij)

r1ij = +f−(σrij , δrij)

si sδrij es imparr0ij = +f−(σrij , δrij)

r1ij = −f+(σrij , δrij)

Paso vertical

q0ij = d2

0(j) +∑

M(j)

r0ij − r0

ij

q1ij = d2

1(j) +∑

M(j)

r1ij − r1

ij

Estimacion del sımbolo decodificado r(j)

r20(j) = q0

ij + r0ij

r21(j) = q1

ij + r1ij

rj = 1 si r21(j) < r2

0(j) sino rj = 0

una matriz H2 generada aleatoriamente, de 1008× 504, es de4096 palabras de 10 bits. La ROM num unos fil almacenael numero de columnas con ”unos” que tiene cada fila. Estamemoria se utiliza para poder indexar y poder ası recuperarjunto con la ROM H, la posicion de cada ”uno” en la matrizH. Las memorias ROM ftabla+ y ROM ftabla- contienen lastablas de busquedas f+(a, b) y f−(a, b). Ambas tablas son de256 palabras 16 bits tanto para H1 y H2.

Las RAM d20 y RAM d21 almacenan a d20 y d2

1 cada vezque ingresa una nueva palabra al decodificador. Su tamanodepende 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. LasRAM 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 d2

1. En el paso horizontal1, RAM q0 guarda los valores de σqij y RAM q1 guarda losvalores de δqij . En el paso horizontal 2 se almacenan losvalores de σrij y δrij . En el paso horizontal 3 se almacenanlos valores de r0ij y r1ij .

Finalmente en el paso vertical se vuelven a almacenar losvalores de q0ij y q1ij , esto le da un alto grado de reutilizaciona estas memorias. La RAM signo almacena sij en el pasohorizontal 1 y sδrij en el paso horizontal 2.

VII. COMPLEJIDAD

El analisis del numero de operaciones involucradas en losalgoritmos presentados permite tener una idea del costo enterminos de hardware que supone su implementacion.

Dada una matriz H, con N columnas y M filas, se definea t = M(j)prom como el numero promedio de unos porcolumna, 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 losalgoritmos tratados (utilizando t = 3 y v = 6)

SP (Mackay and Neal)productos: 2(v + 2t− 6)Nt = 36Nsumas y restas: 5Nt = 15Ncocientes: 2Nt = 6N

SRsumas y restas (paso horizontal): (3 + 2(v− 2))Nt = 33Ncomparaciones (paso horizontal): 3Nt = 9Nbusquedas en tablas (paso horizontal): 3Nt = 9Nsumas y restas (paso vertical): (11+ (t− 2)+ t)Nt = 45Ncomparaciones (paso vertical): 5Nt = 15Nbusquedas en tablas (paso vertical): 4Nt = 12N

DSSsumas y restas (paso horizontal): (6 + 3(v− 2))Nt = 54Ncomparaciones (paso horizontal): 6Nt = 18Nbusquedas 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 72Ncomparaciones – 24N 21N

busquedas en tabla – 21N 12N

TABLA IVRESULTADOS OBTENIDOS EN LA IMPLEMENTACION 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 = 18Ncomparaciones (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 DSSposee menos operaciones que el SR [8]. Si bien los algoritmosDSS y SR requieren mas operaciones de sumas y restas queel algoritmo de decodificacion tradicional de Mackay-Neal, lacomplejidad del DSS y SR se ven notablemente reducidas porel 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 QUARTUSII [13] de ALTERA. En la Tabla IV se pueden ver losresultados obtenidos en la implementacion del decodificadorLDPC (60× 30) y en la Tabla V los resultados para eldecodificador (1008× 504). En ambos casos se observa queel decodificador DSS es mas veloz que el SR, y utiliza menoselementos logicos y registros.

En la Fig. 3 se muestra los resultados obtenidos haciendouna simulacion del codigo LDPC (60×30) en una transmisionde 10000 bloques de 30 bits de mensajes, y en la Fig.4 los resultados del codigo LDPC (1008 × 504) en unatransmision de 10000 bloques de 504 bits de mensajes. Enambos decodificadores se utilizaron 16 iteraciones y factoresde 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]

Pro

babi

lidad

bin

aria

de

erro

r

Sin codificarDS idealSP Mackay−NealSR tabla de 256 entradasDSS 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 Eb/N0 ∼ 5dB (σ = 0.56) yen la Fig. 4 el BER es cero cuando Eb/N0 ∼ 3dB (σ = 0.7).Se puede apreciar que el desempeno al usar tablas de 256entradas no muestra diferencias apreciables con respecto aluso 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 tasade error, usando tablas de busqueda de tamano razonable.

IX. CONCLUSIONES

Se han disenado e implementado en FPGA dos decodifi-cadores LDPC. Ambos pueden trabajar con cualquier tamanoy 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, ono sistematico), y se adaptan en forma parametrica cualquierasea la tasa del codigo k/n. El decodificador DSS presentala 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]

Pro

babi

lidad

bin

aria

de

erro

r

Sin codificarDS idealSP Mackay−NealSR tabla de 256 entradasDSS tabla de 256 entradas

Fig. 4. Desempeno de un decodificador LDPC 1008× 504 para diferentesalgoritmos de decodificacion

canal.Ambas implementaciones muestran una gran versatilidad de

aplicacion y no presentan diferencias apreciables en el de-sempeno de tasa de error con respecto al uso del decodificadorde suma-producto ideal introducido por D. J. C. MacKay y R.M. Neal.

APENDICE AALGEBRA LOGARITMICA

En caso de tener C = ec, A = ea y B = eb, para C = A+Bse 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) puedenser 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 oflow 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 IEEEDSP2000,(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 andApplications. ISCTA’ 09, vol 1, pp 1-5 (2009).

[12] L. Teres, Y. Torroja, S. Olcoz, E. Villar VHDL. Lenguaje Estandarde Diseno Electronico, McGraw Hill/Interamericana de Espana, Madrid(1997).

[13] www.altera.com, “Quartus II Software,” Available: On Line.

42


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

FPGA

Carlos Arturo Gayoso, Claudio Marcelo González, Leonardo Arnone y Miguel Rabini Laboratorio de Componentes Electrónicos, Departamento de Electrónica

Universidad Nacional de Mar del Plata Mar 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. INTRODUCCIÓN

A. Determinismo y aleatoriedad

Los sistemas, desde el punto de vista de su comportamiento, 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 sus variables ni en las relaciones entre ellas. Por el contrario en los sistemas 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ón ilimitada su salida actual y las anteriores, no se puede encontrar ningún tipo de patrón o regularidad. Existen diversos circuitos o algoritmos que tienen la particularidad de generar secuencias de números aleatorios. En este caso, a diferencia de procesos naturales, las series generadas tienen un período, que si bien puede ser muy grande, es finito. Por esta razón a estos sistemas se los denomina pseudoaleatorios.

B. Tests de aleatoriedad

Los test de aleatoriedad se emplean para analizar una secuencia de números, provenientes de una fuente natural o artificial, 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 en evidencia un patrón de comportamiento fácilmente predecible que descarte un comportamiento aleatorio. Sin embargo, en otros casos, con las herramientas estadísticas tradicionales no se puede detectar una estructura determinista. Es por ello que se han ideado distintos tipos de test a los que es sometida la secuencia numérica bajo estudio en busca de concluir sobre su carácter deterministico o aleatorio.

Entre los test más utilizados para medir la calidad de una secuencia de números supuestos aleatorios se encuentra die hard [3], [4]. En realidad es un conjunto de 17 tests desarrollados por George Marsaglia de manera progresiva desde 1985 y publicados por primera vez juntos en 1995.

El generador propuesto en este trabajo se sometió al test die hard pues es uno de los más díficiles de superar. El paquete die hard tiene como entrada un archivo de al menos 11 Mbytes con la secuencia de números cuya aleatoriadad se desea determinar y entrega una serie de 229 valores denominados p, cada uno de los cuales debe cumplir 0,025 < p < 0,975 para que la serie se considere aleatoria. Finalmente calcula el p de los 229 ps calculados previamente, que debe cumplir con la misma desigualdad.

C. El Sistema Numérico de Residuos

Los circuitos aritméticos, por ejemplo sumadores, basados en la notación de complemento a 2, deben propagar la información de acarreo desde el bit menos significativo al más significativo, de manera que a medida que el número de éstos aumenta el rendimiento se degrada. El RNS [5], [6], [7] es una técnica eficiente para superar este problema, dado que se trabaja sobre canales independientes sin necesidad de intercambio de información entre ellos. De esta manera los sistemas basados en el RNS están compuestos de una serie de canales 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 conjunto

de enteros relativamente primos entre si m1, m2..., mL, llamados módulos. Su rango dinámico, el número de cantidades 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, ..., xL], 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ódyxzMmódYXZ 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, puesto que 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 demostrado en 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 su diná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:

( ) Mmódbxax 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 trabaja con hj 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 gj y mj son la raíz primitiva y el módulo de trabajo de cada uno de los canales y residuoj, i es el residuo del canal j para la iteración i.

( ) jijijjij mmódbresiduogresiduo ,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

kikij residuob (4)

en tanto que para los Tipo II (RNS-LCG-II), siendo Θ la operación or exclusiva bit a bit, será:

1,

1

0, −

−=

≠=

Θ= ik

nk

jkk

ij 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 potencia exacta 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 lo serán. Este problema se ejemplifica en la TABLA I, para tener M = 11 se necesita t = 4. Como se puede observar se tiene:

unosycerosb

unosycerosb

unosycerosb

unosycerosb

posiciónlaPara

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, 37 con lo que se obtiene M = 8.154.657.291 > 232 = 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 < 2t+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 porcentaje m0 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 ingresan al 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 del valor 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 f31 a f0 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álisis

espectral y uniformidad y se compararon los resultados de las series generadas por los GNPAs propuestos con los de contraste. En todos los casos los resultados obtenidos son indistinguibles de aquellos tomados como referencia.

TABLA III. Valores de p calculados por Diehard para 10 series para los

generadores RNS-LCG-I y RNS-LCG-II tipo A.

RNS-LCG-I RNS-LCG-II Simulación

p p

0 0,407911 0,607689 1 0,269137 0,071269 2 0,407911 0,143974 3 0,176487 0,789647 4 0,872657 0,510381 5 0,181225 0,110432 6 0,452626 0,292616 7 0,429352 0,312498 8 0,305565 0,119320 9 0,048907 0,619312

TABLA IV. Valores de p calculados por Diehard para 10 series para los generadores RNS-LCG-I y RNS-LCG-II, tipo B.


p p

0 0,800747 0,316036 1 0,907225 0,263429 2 0,326950 0,473377 3 0,930700 0,649256 4 0,087136 0,541925 5 0,401577 0,972650 6 0,949964 0,027664 7 0,207195 0,141259 8 0,038877 0,885084 9 0,053990 0,855836

TABLA V. Valores de p calculados por Diehard para 10 series para los generadores RNS-LCG-I y RNS-LCG-II tipo C.


p p

0 0,101530 0,084441 1 0,134149 0,455188 2 0,676679 0,974504 3 0,205915 0,554348 4 0,361947 0,917724 5 0,544443 0,623239 6 0,148867 0,031028 7 0,052875 0,201848 8 0,658070 0,320512 9 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.000 de puntos, de 32 bits, para cada GNPA. En los generadores Clase A los archivos no tienen el mismo tamaño, puesto que en este caso se descartan aquellos valores superiores 232, el tamaño de estos archivos está comprendido entre los 11 y los 12 Mbytes. En los generadores Clase B el tamaño es en todos los casos de 12 Mbytes. Y finalmente para los Clase C son todos de 11.999.992 de bytes puesto que los primeros valores deben descartarse por el empleo del circuito de corrección. Los resultados obtenidos para las 300 series son los que se muestran en las siguientes tablas.

Como puede apreciarse las series pasan satisfactoriamente este test. Se puede aseverar entonces que todos los generadores propuestos, en sus distintas variantes, pasan exitosamente una de las baterías de test más exigentes para la determinación de aleatoriedad sobre una serie de números.

IV. IMPLEMENTACIÓN EN LÓGICA PROGRAMABLE

Debido a que los circuitos sumadores y multiplicadores son el núcleo de la mayor parte del hardware RNS, se realizó un amplio estudio sobre este tipo de operaciones en el sistema numérico de residuos [18] y [19]. Esta investigación incluyó distintos tipos de sumadores y multiplicadores presentados en distintos trabajos [20], [21], [22], [23] y [24]. De los resultados obtenidos en [18] y [19] se puede determinar que la frecuencia de operación es de 93,4 MHz cuando se emplea una FLEX10K20RC240-4 y trabajando con 32 bits.

V. CONCLUSIONES

En el presente trabajo se presentaron una serie de generadores de números pseudoaleatorios basados en el sistema numérico de residuos que pasan exitosamente, además de las estadísticas básicas, uno de los test de aleatoriedad más exigentes como es el die hard.

REFERENCIAS

[1] M. Naito, N. Tanaka, H. Okamoto, “Distinguishing chaos from random fractal sequences by the comparison of forward predictions: utilization of the difference in time reversal symetry of time series,” IEEE Proc. Of First International Conference on Knokledge-Based Intelligent Electronic System, 21-23 de mayo de1997, pp. 101-107.

[2] K. Ozdemir, S. Kilinc. S Ozoguz, “Random Number Generator Design Using 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 the suitability of digital maps for integrated pseudo-RNGs,” Proc. ECCTD Cracow, 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 Residue Adders,” 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,” IEEE Transactions 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, IEEE Transactions 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 on Computers, 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 and A. Lloris, Design of Index-based RNS-DWT Architectures for Custom IC Designs, Proc. of 2001 IEEE Workshop on Signal Processing Systems SiPS’2001, pp. 70-79, Sep. 2001.

[12] W. A. Chren, “RNS-Based Enhancements for Direct Digital Frequency Synthesis,” 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 Applications to 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 Digital Signal Processing,” IEEE Press, 1986.

[16] U. Meyer-Bäse, A. Garcia and F. J. Taylor, “Implementation of a Communications Channelizer using FPGAs and RNS Arithmetic Journal of 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 residuos en lógica programable “, II Jornadas sobre Computación Reconfigurable y 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 de multiplicadores en aritmética de residuos empleando lógica programable”, Décimo Tercera Reunión de Trabajo en Procesamiento de la Informació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 Residue Adders”, 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 Binary Adders”, IEEE Transactions on Circuits and Systems II: Analog and Digital 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”, IEEE Transactions on Computers, vol. C-29, no. 10, pp. 899-905, Oct. 1980.

[23] J. C. Smith and F. J. Taylor, “A fault-tolerant GEQRNS processing element for linear systolic array DSP application”, IEEE Transactions on Computers, 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 and A. Lloris, “Design of Index-based RNS-DWT Architectures for Custom IC Designs”, Proc. of 2001 IEEE Workshop on Signal Processing Systems 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 Desarrollo Centro de Desarrollo de la Electrónica y la Automática, CDEA

Pinar del Río, Cuba Email: [email protected]

Abstract—En este artículo se describe una de las tantas aplicaciones de los algoritmos de filtrado adaptativo, en este caso la reducción o cancelación de ruido en particular usando el algoritmo QRD-RLS, llevando a cabo su implementación sobre FPGA y tomando como eje fundamental del trabajo, la flexibilidad de estos dispositivos y las ventajas de la aceleración de algoritmos por hardware en determinadas 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, de manera 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 de cancelar 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 su mayor 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 en un 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 funcionamiento de un sistema adaptativo [1].

)(*)()( twtuty = (1) )()()( tytdte −= (2)

Donde u(t) es la señal de entrada, y(t) es la señal de

salida ya filtrada, d(t) es la señal deseada a la salida y e(t) es el error entre d(t) e y(t). En este caso, la señal de entrada u(n) pasa a la Planta que contiene los coeficientes w(n) (un filtro FIR) y devuelve una señal y(t) cuyo resultado se muestra en (1). En el momento que la planta entrega el resultado y(t), esta resta a una señal d(t) y produce una señal de error e(t) cuyo resultado 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 una respuesta similar a la señal deseada d(t). Conjuntamente con la señal u(t) se calculan los nuevos coeficientes w(t ) para la planta usando un Mecanismo Adaptativo de Control de Coeficientes [1].

A. Algoritmo QRD-RLS

Dentro de los algoritmos adaptativos existentes el RLS (Recursive Least Square), es generalmente preferido por su rápida convergencia. El método basado en 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 coeficientes involucra la inversión de matrices, lo cual es generalmente indeseado en las implementaciones de hardware debido al alto consumo de recursos. La descomposición de matrices basada en esquemas de mínimos cuadrados tales como, SVD (Singular Value Descomposition) y QR evitan explícitamente la inversión de matrices, son más robustas y más asequible su implementación en hardware [5].

El método de descomposición QR comienza desde la matriz de datos usando transformación unitaria. Para una matriz Q(n) unitaria dada, la función de coste puede ser expresada como:

22/12/1

22/1

||)()()()()()()(||)(||)()()(||)(

nwnnnQndnnQnEnennQnE

ΑΑ−Α=

Α=

(3)

Para el problema de minimización definido por la función de coste, la matriz unitaria Q(n) es elegida para triangular la matriz de datos de manera exponencial ponderada tal que:

⎥⎦

⎤⎢⎣

⎡=ΑΑ

0)(

)()()( 2/1 nRnnnQ (4)

Donde R(n) es una matriz triangular superior de dimensió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

nvnp

ndnnQ (5)

Donde p(n) es un vector de Kx1 elementos y v(n) es un vector de (n-K) x1 elementos, luego se puede reescribir la función de coste de la siguiente manera:

2||)(0

)()()(

||)( nwnR

nvnp

nE ⎥⎦

⎤⎢⎣

⎡−⎥

⎦

⎤⎢⎣

⎡=

2||)(

)()()(|| ⎥

⎦

⎤⎢⎣

⎡ −=

nvnwnRnp

(6)

Es obvio que la estimación de mínimos cuadrados para el vector de pesos debe satisfacer que:

)()()(

10)()()(1'

'

npnRnw

xnwnRnp K−=

=− (7)

La matriz unitaria Q(n), la matriz triangular superior R(n), y el vector p(n) , pueden ser calculados recursivamente usando:

⎢⎢⎢

⎣

⎡−−

xKxKKn

nR

10)1(0

)(

⎥⎥⎥

⎦

⎤−−

)(1)1(0

)(

nxKn

np

α

50


⎢⎢⎢

⎣

⎡

−−−

=

)()1(0)1(

)(

2/1

'

nuxKKn

nRnQ

T

λ

⎥⎥⎥

⎦

⎤

−−−

)(1)1(0

)1(2/1

ndxKn

npλ

⎢⎣

⎡ −=

0)1(

)()( ' nQnQnQ ⎥

⎦

⎤10 (8)

Por lo tanto el vector de coeficientes óptimos puede

ser obtenido. Pero en algunas aplicaciones tales como reducción de ruido y predicción linear e(n), es la señal de salida. Desarrollando la ecuación anterior podemos obtener e(n) directamente sin extraer el vector de pesos explícitamente. Este resultado puede resumirse en la siguiente ecuación:

⎢⎣

⎡

xK

nR

10)(

)()(

nnp

α

⎥⎥⎦

⎤−

*))(()()(

2/1

1

nnunR

γ (9)

)('' nQ=⎢⎢⎣

⎡ −

)()1(2/1

nunR

T

λ

)()1(2/1

ndnp −λ

⎥⎦

⎤10 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ñal interferente ruido blanco gaussiano de valor medio cero y varianza constante, y como señal útil de prueba, un tono sinusoidal 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 a

continuación en la figura 3 donde se puede apreciar la forma clásica de un sistema adaptativo utilizado para cancelar ruido, donde en este caso, se toma como referencia 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 una réplica del ruido contaminante de la señal útil , lo que al efectuar la diferencia entre estas dos señales , se obtiene como salida la señal útil inicial, correspondiente al error entre la referencia y la salida del filtro. La diferencia de este sistema con respecto a las demás arquitecturas de sistemas adaptativos es que la salida del mismo es la señal de error [2].

Figura 3 Filtro Adaptativo como reductor de ruido

La elección de la estructura de cancelación adaptativa mostrada en la figura 3 y usada para la verificación del algoritmo QRD-RLS pudiera no ser la mas óptima en cuanto a la cantidad de información que necesita el sistema para adaptarse, pudiendo usarse otro tipo de estructura de cancelación de ruido, como la predictiva, la cual no requiere el conocimiento previo de la naturaleza del ruido aditivo a la señal, ni tampoco que el mismo deba estar correlacionado. Sin embargo, esto puede implicar un aumento en el consumo de recursos hardware del algoritmo QRD-RLS imposibilitando la fiabilidad de su sinterización sobre una arquitectura reconfigurable. Que el ruido que se toma como muestra de entrada al filtro, este correlacionado con el incidente en la señal útil, implica mejores resultados y un menor número de operaciones para la convergencia del algoritmo, lo cual se traduce en un ahorro de recursos computacionales, siendo este último punto, y la síntesis del algoritmo QRD-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 de AccelDSP 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-RLS a través de la herramienta de síntesis AccelDSP y exportado a System Generator, se adiciona este a un sistema diseñado para comprobar su funcionamiento. El sistema de comprobación del algoritmo se diseñó en System Generator, mediante el cual se generan, tanto la señ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 y comparada con los resultados obtenidos en la simulación.

Todo el sistema fue implementado sobre la arquitectura FPGA SPARTAN-3AN, la cual posee 700K compuertas y 20 multiplicadores embebidos, de los cuales solo se usa el 60 % de los mismo. Teniendo en cuenta que este es un punto crítico a la hora de implementar el algoritmo, es este un buen resultado con respecto al consumo de recursos del sistema. La figura 5 muestra el diagrama completo del sistema.

Figura 5 Arquitectura del Sistema en System

Generator

IV. RESULTADOS En orden de comparar los resultados obtenidos en la

simulación del sistema cancelador de ruido, con los mostrados 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 la eficiencia del algoritmo en tareas de reducción o cancelación de ruido, utilizando como secuencia de adaptación, una señal de referencia.

Figura 6 Salida del sistema y comportamiento de

frecuencias Como se puede apreciar en la figura anterior la salida

del sistema generada en el modelo de punto flotante

52


descrito en Matlab y la salida del modelo punto fijo generado por la herramienta coinciden, así mismo el comportamiento de frecuencias, lo cual demuestra la convergencia de los coeficientes del filtro a la atenuación de las frecuencias fuera del rango dinámico de señal útil.

A continuación se puede ver la comparación entre la señal de entrada contaminada y salida del sistema, con lo cual se muestra la coincidencia del modelo de simulación en Matlab con el modelo real implementado sobre el FPGA.

Figura 7 Entrada contaminada y señal a la salida del

sistema en System Generator En cuanto a los recursos utilizados en la

implementación del algoritmo QRD-RLS, la tabla 1 muestra el consumo que originó la implementación del mismo. Cabe destacar que el procesamiento de los datos mediante el algoritmo QRD-RLS se hizo tomando como longitud máxima, 24 bits, forzando el diseño del mismo a esta longitud de datos, teniendo en cuenta los recursos del dispositivo 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 sobre una arquitectura paralela y reconfigurable lo que posibilita su reutilización en posteriores diseños.

REFERENCIAS [1] Jorge Benavides Aspiazu, Walter Calienes Bartra

and Carlos Silva Cárdenas,”Diseño de una arquitectura para la implementacion de un filtro adaptativo rls sobre un fpga”, XV Workshop Iberchip, Buenos Aires - Argentina,Marzo 2009.

[2] Saeed V. Vaseghi, Advanced Digital Signal Processing 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-RLS

Algorithm 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 RLS algorithms: 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 Posicionde un Motor DC Basado en FPGA

Luis F. Castano Londono, Gustavo A. Osorio LondonoGrupo en Percepcion y Control Inteligente

Departamento de Ingenierıa Electrica, Electronica y ComputacionUniversidad Nacional de Colombia - Sede Manizales

Resumen—En este artıculo se presenta el diseno 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 generacion de la trayectoriade arranque, la lectura de la senal del encoder, el controlador PIy el generador de la senal 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 IIde Altera Corporation. Se presentan simulaciones realizadas conSimulink y resultados experimentales del sistema desarrollado.

Palabras Clave—Servocontrol, PID, VHDL, FPGA

I. INTRODUCCION

Actualmente existen varias aplicaciones y herramientas parala implementacion de servocontroladores digitales ya sea conel uso de microcontroladores como en [2] [11], DSP como en[1] [5] [10] [12] y FPGA como en [4] [7]. Este tipo de sistemaspueden ser empleados para control de posicion en impresoras,plotters y escaners, ofreciendo multiples ventajas con relaciona los sistemas que emplean motores de paso[11]. Tambien seemplean en aplicaciones de robotica [8] y automatizacion[1].La mayorıa de estos sistemas son implementados con eluso de microcontroladores estandar, microcontroladores de16 bits de gama alta o DSP cuando se desea incrementarel desempeno[11]. La seleccion del tipo de dispositivo parala implementacion del servocontrolador depende de los re-querimientos del sistema y las caracterısticas de la aplicaciondeseada. Generalmente los criterios de seleccion se basan enla relacion costo-rendimiento y llevan a una decision entremicrocontroladores estandar y DSP [10].

Fig. 1. Esquema basico del sistema de control de posicion del motor DC

Los microcontroladores estandar son los mas adecuadospara aplicaciones con requerimientos relativamente bajos decontrol en tiempo real y que ademas requieren desarrollarotras tareas como el control de interfaces de usuario. LosDSP son empleados cuando los requerimientos del algoritmode control en tiempo real son mayores [10]. Tanto paraaplicaciones con microcontroladores como con DSP seemplean circuitos externos para el manejo de algunas tareasde la aplicacion. Particularmente en el caso de aplicacionescon 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 consumode potencia y mayor estabilidad en el desempeno [6] [7].Al no depender de una arquitectura especıfica los FPGApermiten el diseno de sistemas flexibles que funcionan conuna mayor velocidad de procesamiento debido a su capacidadde concurrencia. Por otra parte hoy en dıa las herramientasde diseno, simulacion y sıntesis sobre FPGA ofrecen variadasprestaciones para el diseno e implementacion de todo tipo desistemas embebidos de bajo costo. En este artıculo se presentala implementacion de un servocontrolador para un motor DCbasado en FPGA. En la seccion II se describen cada unode los componentes del sistema que fueron desarrollados enVHDL y con diagramas de bloques bajo el entorno QuartusII e implementados en la tarjeta DE3. En la seccion IIIse presentan simulaciones y resultados experimentales delsistema desarrollado. Finalmente se presentan las conclusionesen la seccion IV.

54


II. IMPLEMENTACION DEL SISTEMA DE CONTROL

El esquema basico del servocontrol desarrollado se muestraen Fig. 1. El sistema a controlar es un motor DC de imanpermanente instrumentado con un encoder incremental de 400PPR (pulsos por revolucion). La etapa de potencia consisteen un circuito inversor que permite el manejo de la corrientey el control del sentido de giro del motor. En la FPGA sonimplementados los modulos que se encargan de la generacionde la trayectoria para el arranque, la lectura de la senal delencoder, el controlador PI y el generador de la senal de controlPWM. El diagrama de bloques del sistema de control realizadoen Quartus II se muestra en Fig. 2.

A. Generacion de la funcion de arranque del motor

Para el arranque del motor se debe tener en cuenta losefectos de la resistencia por friccion seca y el transitorio de lacorriente de armadura. El voltaje aplicado en el devanado debeser suficiente para que el torque del motor supere el torqueresistivo debido a la friccion seca. Por otra parte cuando seaplica una referencia de tipo escalon la corriente de arranque esmuy alta debido a la inductancia de armadura. Esta situacionpuede ocasionar desgaste en los componentes mecanicos yelectricos del motor debido a los movimientos abruptos y ladisipacion de potencia. Un metodo para evitar la sobrecorrienteen el transitorio es el arranque progresivo por medio de unacurva de tension. La generacion de esta curva se realiza a partirde una funcion de velocidad de forma trapezoidal como la quese muestra en la parte superior de Fig. 3. La implementacionde esta funcion se realiza con base en la expresion que semuestra 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 estan determinadas porla velocidad maxima (ωmax) y la posicion final (θf ) que sealcanza 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 unafuncion de referencia de posicion como la que se muestra enla parte inferior de Fig. 3. El esquema para la implementaciondel 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 posicion

La medida de la posicion es realizada con un encodermagnetico incremental de 400 PPR acoplado al rotor delmotor. Este encoder entrega dos senales en cuadratura comose muestra en Fig. 5. Estas senales permiten detectar eldesplazamiento y el sentido de giro del rotor. Cuando el rotorgira en el sentido de las agujas del reloj la fase A se encuentraadelantada 90 a la fase B como se muestra en Fig. 5(a).Cuando el rotor gira en el sentido contrario a las agujas delreloj la fase B se encuentra adelantada 90 a la fase A comose 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 delencoder se realiza a traves de un circuito secuencial cuyodiagrama de transicion de estados se muestra en Fig. 6. Elanillo interno es la secuencia para la deteccion de la direcciondel giro en el sentido de las agujas del reloj, siendo la salida 0.

El anillo externo es la secuencia para la deteccion la direcciondel giro en el sentido contrario a las agujas del reloj, siendo lasalida 1. Las transiciones entre los estados del anillo internoal externo o del anillo externo al interno permiten la detecciondel cambio de sentido de giro. El circuito planteado de estaforma se puede implementar de manera sencilla a traves deuna 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 depulsos ascendente/descendente de n bits. La senal de relojpara este contador se obtiene de la xor entre las dos fases delencoder dando lugar a una medida de 800 ppr. Este contadorse incrementa o decrementa en funcion del desplazamiento yel sentido de giro del rotor. El contador esta disenado para daruna medida tanto positiva como negativa del desplazamientodel rotor con relacion a su posicion inicial cuando se enciendeel circuito. Para garantizar una lectura correcta de las senalesdel encoder tanto para la deteccion del sentido de giro comopara determinar la posicion, se implementa un circuito antire-bote como parte de este modulo, ya que la duracion de unpulso para cada una de estas senales es de 500µs cuando elmotor trabaja a 2000 rpm.

C. Controlador proporcional integral

El control basado en el esquema PID convencional esampliamente usado debido a su simplicidad y desempeno [6][8]. Algunos sistemas de servocontrol poseen tres lazos decontrol (posicion, velocidad y corriente) permitiendo un mejorcomportamiento de las caracterısticas estaticas y dinamicas delsistema [3] [4] [9]. El lazo de posicion es el principal para elservocontrol. El lazo de velocidad limita las fluctuaciones develocidad para mejorar la respuesta en el transitorio y frentea perturbaciones en la carga. El lazo de corriente limita lainterferencia de la corriente de armadura y la corriente maximapara proteger el motor [4] [9]. Tambien se pueden encontrar

56


sistemas basados en lazos de posicion y velocidad comoen [2]. El sistema implementado posee unicamente un lazode posicion con un controlador PI, siendo los controladoresproporcional e integral los mas comunes para los lazos deposicion, velocidad y corriente en este tipo de sistemas decontrol. La salida del controlador PI se calcula como semuestra en (2) y determina el valor del porcentaje de ciclo utilde la senal de control PWM tal como se muestra en Fig. 8.

u(t) = sat(Kp e(t) +Ki sat

(∫e(t) dt

))(2)

El control proporcional es elaborado con un circuito mul-tiplicador generado con la herramienta MegaWizard Plug-InManager del Quartus II. El control integral es implementadocon base en (3) y el diagrama de bloques mostrado en Fig. 7.El valor de la constante h esta determinado por la frecuenciade reloj del circuito de integracion (e.g. h = 50µs parafclk = 20KHz). Los valores de Kp y Ki son definidos atraves 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 senal de control PWMEl generador de la senal PWM se basa en el diagrama

de bloques mostrado en Fig. 8. Este modulo consta de uncontador, un circuito aritmetico, un comparador y un demulti-plexor. El contador permite generar una senal diente de sierrade 20 KHz. El circuito aritmetico se emplea para el calculodel valor de referencia que es comparado con la senal dientede sierra para generar la senal PWM. El circuito demultiplexorse encarga de llevar la senal de control PWM a las entradasdel puente inversor segun el signo de la senal de control paradeterminar el sentido de giro del motor.

Fig. 8. Diagrama de bloques para la implementacion del generador de lasenal de control PWM

E. Descripcion del sistema fısico

El modelo de un motor DC de iman permanente puede serrepresentado por las expresiones mostradas en (4a)-(4d). Estasecuaciones son obtenidas de los sistemas electrico y mecanicomostrados en el circuito equivalente de Fig. 9.

Ea = Ra ia + Ladiadt

+ ea (4a)

τm = Jd2θ

dt+B

dθ

dt(4b)

τm = Kt ia (4c)

ea = Ke ω (4d)

Fig. 9. Circuito equivalente del motor DC de iman permanente

La representacion en el espacio de estados del modelo delmotor se muestra en (5).

x =

x1

x2

x3

=

0 1 00 a b0 c d

x1

x2

x3

+

00f

u(5)

y =[

1 0 0] x1

x2

x3

donde a = −B/J, b = Kt/J, c = −Ke/La, d = −Ra/La

y f = 1/La, estan definidos por los parametros del motor. Losvalores de los parametros obtenidos con la identificacion delmotor son: B = 1.2e−6Nms/rad, Kt = 14.5e−6Nm/A,J = 0.5e−6Nms2/rad, Ke = 0.35V s/rad, Ra = 3.3 Ω yLa = 36 µ H .

III. SIMULACION Y RESULTADOS EXPERIMENTALES

Las simulaciones del sistema implementado son realizadasen MATLAB usando Simulink con base en el modelo desarrol-lado en la seccion II-E. Para obtener los datos experimentalesse emplea el Signal Tap II Logic Analyzer del Quartus II. Conel uso de esta herramienta para cada experimento se toman65536 muestras de cada una de las variables que se deseamedir.

57


A. Experimento A: respuesta en lazo abierto

Las pruebas para observar la respuesta del motor en lazoabierto se realizaron para valores de Ea entre 0.5V y 24V. EnFig. 10 se muestra la respuesta del sistema en lazo abierto parauna valor de ea de 4V. La lınea continua muestra la respuestade la simulacion y la lınea punteada corresponde a los valoresexperimentales 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 simulacionpara la respuesta del sistema en lazo cerrado con Kp = 20,Ki = 4 y una alimentacion para circuito de potencia de 15 V.La lınea solida corresponde a la referencia y la lınea punteadacorresponde a la respuesta del motor. En la parte inferiorde Fig. 11 se muestra la respuesta experimental del sistemaen lazo cerrado para los mismos valores de Kp y Ki. Lalınea continua corresponde a la referencia y la lınea punteadacorresponde a la respuesta del motor. En Fig. 12 se muestranlas senales de error. La lınea continua corresponde a losresultados de la simulacion y la lınea discontinua correspondea los datos experimentales. Los valores de Kp y Ki seescogieron experimentalmente de tal forma que la respuestadel sistema fuera estable.

IV. CONCLUSIONES

En este artıculo se presenta el diseno e implementaciondel control de posicion para un motor DC basado en FPGA.El diseno es realizado con el uso de VHDL y diagramas debloques e implementado en la FPGA. Debido a la modularidaddel diseno y la independencia de una arquitectura especıficaes posible implementar diferentes topologıas basadas en elesquema convencional PID. En este artıculo se realiza ladescripcion y se presentan los resultados del sistema con uncontrolador PI aplicado a un lazo de posicion.

La comparacion entre los resultados de la simulacion ylos datos experimentales permiten validar el funcionamientodel sistema desarrollado tanto en lazo abierto como en lazo

Fig. 11. Respuesta del sistema en lazo cerrado con controlador PI. Kp =20, Ki = 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 delmotor.

Fig. 12. Senal de error del sistema en lazo cerrado con controlador PI.Kp = 20, Kp = 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 deerror para los resultados de la simulacion y los resultadosexperimentales se relaciona principalmente con el modeladodel motor. Sin embargo se puede observar un comportamientobastante aproximado del sistema tanto en el transitorio comoen estado estacionario.

Las caracterısticas del sistema desarrollado y las herramien-tas empleadas permitiran realizar el estudio de la dinamicadel sistema aplicando otras topologıas y esquemas de control.Existe principal interes en la implementacion de controladoresbasados en esquemas diferentes al PID (ie. controladoresbasados en la estrategia zero average dynamics (ZAD)), enlos cuales resulta fundamental la capacidad de concurrencia yvelocidad 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 EmbeddedDSP, 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 ofInternational 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 CurrentMotor 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-DOFmanipulator 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 Controllerwith 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 - UBA Buenos 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 y dispositivos mixtos (mixed signal) de bajo costo y bajo consumo; tanto como dispositivos en silicio como softcores o hardblocks en FPGA. Actualmente hay soluciones de Cortex-M en FPGA de Altera (Cortex-M1 como softcore) y de Actel (Cortex-M1 como softcore y Cortex-M3 como hardblock); mientras que Xilinx no ofrece soluciones de Cortex-M para su línea de FPGA. Por otra parte, 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 presente trabajo se muestran los resultados de la implementación de dicho procesador en una FPGA de rango bajo de Xilinx, lográndose de esta manera ampliar el rango de implementaciones de los procesadores Cortex-M en FPGA.

Keywords- Cortex-M0, FPGA

I. INTRODUCCION

A. Descripción de las familias de procesadores de ARM En la línea de procesadores de ARM, la familia Cortex

consiste en cores que van desde soluciones orientadas a microcontroladores de bajo costo hasta procesadores de alta perfomance con capacidad de ejecutar sistemas operativos complejos. Las lineas clásicas incluyen a las familias ARM7, ARM9 y ARM11 y las series especializadas SecurCore™ para aplicaciones de seguridad y criptografía. En la Fig. 1 se puede apreciar la ubicación relativa de cada familia en relación a su capacidad 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 rango dentro de la familia Cortex-M de procesadores de ARM. Esta familia permite realizar distintos tipos de compromisos entre costo, 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 bits mientras 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/MHz y ocupa un área equivalente de 12.000 compuertas. Como referencia, un procesador clásico como el i8051 ocupa típicamente alrededor de 8.000 compuertas [1][2]. En la Fig. 2 vemos la ubicación relativa de cada miembro de la familia Cortex-M en función de su performance y plataforma de implementació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 un Dhrystone de 0,9 DMIPS/MHz; implementa hasta 32 interrupciones enmascarables más una no enmascarable a través de un controlador de interrupciones integrado (NVIC-Nested Vectored Interrupt Controller) con una latencia fija de 16 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ón reducida del bus Advanced Microcontroller Bus Architecture (AMBA®), denominada AMBA AHB–Lite. Este bus fue diseñado como un bus de alta performance para transferencias rápidas entre el procesador y periféricos que requieran gran ancho de banda y/o altas tasas de transferencia de datos. Generalmente se lo implementa con un único dispositivo que actúa como maestro y el resto como esclavos, aunque la especificación del bus permite la implementación de múltiples maestros. Sus principales características son que permite transferencias en ráfaga, sus operaciones se realizan en un ciclo de reloj (sincronizado con su flanco), no implementa tri-state y es configurable el ancho del bus (32, 64, 128, 256, 512 y 1024 bits) [4]. La Fig. 4 muestra una implementación del bus y las Figs. 5 y 6 muestran las señales de un dispositivo maestro y un dispositivo 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ón reducida del procesador Cortex-M0 standard (M0S) y fue lanzado al mercado el 4 de agosto de 2010. Sus principales diferencias con el procesador M0S son: El procesador M0S posee interfaces del bus AMBA-Lite como maestro y como esclavo, mientras que el M0DS sólo posee la interfase como maestro; 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 M0DS implementa 16 interrupciones fijas. El M0S opcionalmente puede incluir un controlador de interrupción para bajo consumo (WakeUp Interrupt Controller), control selectivo de reloj interno (arquitectural clock gating), hardware e interfaces de debugging (hasta 4 breakpoints por hardware y comunicación serial o JTAG) y un timer de referencia de 24 bits; el M0DS no incluye 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 bajo

de Xilinx: S3E500-4; sus principales características son: 500K compuertas, 10500 celdas lógicas (equivalentes a 1100 bloques lógicos configurables (CLB) o 4600 slices), 20 multiplicadores por hardware, 360Kbits de bloques dedicados de ram, 73kbits de ram distribuida, 4 controladores de reloj y una frecuencia máxima de trabajo de 300MHz [8].

La placa utilizada es una placa básica (starter board) de la firma Digilent, modelo Nexys2. Cuenta con una FPGA S3E500, 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 de 50MHz, 8 LEDS, 4 displays de 7 segmentos, 4 pulsadores y 8 interruptores. 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 un software 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.), lo que permite programarla y ver su estado interno fácilmente.

61


Como herramientas de software se utilizó el entorno de desarrollo para FPGA de Xilinx ISE versión 12.2; para la generació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 un documento en formato PDF correspondiente a las notas de lanzamiento (Release Notes) [5].

El test bench se compone de un módulo no sintetizable en verilog que implementa al procesador conectado a una memoria preinicializada con un programa simple. Completan el test bench el código fuente en C del programa; la imagen en formato binario del programa y un makefile que permite obtener la imagen en formato binario a partir del código fuente en 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 que

el procesador sea sintetizable en la FPGA seleccionada. 2) crear un proyecto en la herramienta ISE de Xilinx que implemente el test bench y verificar su correcto funcionamiento 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 binario generado sea correcto mediante simulación. 5) crear un proyecto en la herramienta ISE de Xilinx que implemente con componentes sintetizables el sistema de test bench. 6) generar un programa que permita interactuar con los recursos de hardware de la placa, a fin de verificar la correcta implementación del procesador. Verificar el mismo mediante simulació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 correcto funcionamiento mediante simulación funcional en el entorno ISE. 8) Sintetizar el proyecto con el programa integrado e implementarlo en la placa de desarrollos. Verificar el correcto acceso a los recursos de hardware de la placa.

D. Secuencia de implementación realizada El ítem 1) se realizó sin mayor inconveniente, resultando en

un uso aproximado del 50% de los Slices de la FPGA, lo que

determinó la viabilidad de realizar la implementación. Durante la 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 de encontrar la razón de ello, se continuó con el ítem 3), para obtener una simulación de la ejecución del software en el entorno de desarrollo del mismo. Para ello se utilizó el entorno de desarrollo ARM MDK de la firma Keil Gmbh, ya que era la herramienta que se indicaba en las notas de lanzamiento.

Al analizar en detalle el makefile para utilizarlo con el MDK se encontró que el mismo no era consistente: si bien las herramientas de compilación y enlazado eran del MDK (Armcc y Armlink), los parámetros pasados no correspondían a dichas herramientas. Buscando en la documentación de otros proveedores de herramientas de software para procesadores ARM se llegó a la conclusión que los parámetros correspondían a las herramientas del IAR Embedded Workbench de la firma IAR (Iccarm e Ilinkarm); por lo que el makefile provisto era en realidad compuesto por distintos makefiles 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 se repetía el problema del procesador bloqueado. Una vez realizado esto, nuevamente se obtuvo un estado de procesador bloqueado, pero al disponer del proyecto en MDK, era posible comparar la simulación de software en MDK con la simulación funcional del test bench en ISIM de Xilinx. Al realizar dicha comparación, se encontró que la simulación del software en MDK funcionaba correctamente, mientras que la simulación funcional en el ISIM mostraba valores que no correspondían en los 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 realizaba una 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 la implementació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 de que se realice correctamente la inicialización de la memoria; y de 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 antes mencionados, se paso a los ítems 5) Sistema Sintetizable y 6) Programa que utilice el hardware de la placa de desarrollos. Se decidió empezar por el programa. A fin de no implementar un dispositivo 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 una variable con un cierto retardo entre cada carga. Esto generaría un programa que buscara dichos valores constantes en memoria, 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 acceso a memoria en busca de los valores constantes antes mencionados. En la Fig. 9 se observa una captura de la pantalla del simulador de software. Una vez realizada esta verificación,

62


se cargo el programa en el test bench y se verifico en la simulación funcional con ISIM que los valores elegidos aparecían sobre el bus de datos. En la Fig. 10 se ve una captura de 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 sistema sintetizable. El mismo consta de las siguientes partes: “Procesador”, con el código verilog del procesador Cortex- M0DS; “Sincronizador de reset”, implementado con un contador que fija una señal en nivel alto al llegar al final del conteo, a fin de generar una señal de reset sincrónica con el reloj 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, a través de un DCM de la FPGA fijado a 10MHz a partir del oscilador de 50MHz que provee la placa de desarrollos. Y finalmente “Detector de Bus”, que detecta sobre el bus de datos los 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 que convirtiera el formato binario del archivo de programa al formato COE necesario para inicializar la memoria. Se verificó mediante simulación funcional en el ISIM el correcto funcionamiento del sistema completo, en particular del detector de bus, el cual reaccionó correctamente frente a los datos que aparecían sucesivamente sobre el bus de datos.

Finalmente se implemento completamente el sistema y se programó la placa con el mismo, realizándose las siguientes verificaciones: con la herramienta ChipScope Pro, que permite

ver señales internas de la FPGA, se verificó la aparición de los valores constantes programados; y visualmente se verificó que a los intervalos programados para los accesos a memoria, un led de la placa de desarrollos cambiaba de estado de encendido a apagado, dándose así por validada la implementación del procesador en la FPGA.

III. RESULTADOS Y CONCLUSIONES El resultado más destacable es que es posible implementar

este procesador en una FPGA de rango bajo, lo que permite su aplicació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 implementarlo sobre los tres principales proveedores de tecnologias de FPGA (Xilinx, Altera y Actel), lo que lo convierte en una plataforma a considerar en situaciones en las que la portabilidad entre distintos fabricantes de FPGA es un requisito.

Como estadísticas de implementación, en la Fig. 11 se muestran 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 de síntesis y los resultados Post Place and Route indicaron una frecuencia máxima de trabajo de alrededor de 40MHz. Cabe aclarar que no se realizaron ningún tipo de restricciones de temporización o ubicación de componentes en el sistema.

Otra particularidad de este procesador es que es posible acceder directamente a los registros internos del mismo, lo que lo hace útil en aplicaciones educativas, ya que es posible observar la total concordancia entre la simulación de software, la simulación funcional en ISIM, y la verificación de la implementación a través de ChipScope Pro a nivel de registros internos 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 actividades mencionadas 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 de ser 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 compatibles con este bus, a fin de aumentar sus capacidades y convertirlo en una opción a tener en cuenta en la creación de sistemas embebidos 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 la FI-UBA.

IV. REFERENCIAS

[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 Reference

Manual”, Septiembre de 2010. [4] ARM Ltd, “ARM IHI 0033A AMBA 3 AHB-Lite Protocol V.1.0

Specification”, Junio de 2006. [5] ARM Ltd, “AT510-DC-80001-r0p0-00-rel0 ARM Cortex-M0

DesignStart Release Note”, Agosto de 2010. [6] ARM Ltd, “ARM DDI 0432C Cortex-M0 Revision r0p0 Technical

Reference 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 y Joe Bungo; a Fiona Cole de Digilent Inc.; y la gente del programa universitario 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 en octubre 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

Instituto Universitario Aeronáutico Córdoba, AR

[email protected]

Pablo A. Ferreyra Facultad de Matemática, Astronomía y

Física Universidad Nacional de Córdoba Posgrado en Sistemas Embebidos

Instituto Universitario Aeronáutico Córdoba, AR

[email protected]

Carlos A. Marqués Facultad de Matemática, Astronomía y

Física Universidad Nacional de Córdoba

Córdoba, AR [email protected]

Abstract— El procesamiento de datos de alta performance se ha

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

Avances en la industria de los semiconductores han permitido que utilizando componentes de lógica programable sea posible implementar sistemas digitales complejos. Un sistema en chip programable (SoC) es un sistema digital que en una sola pastilla de silicio, implementa un sistema embebido, dispositivos de aplicación específica y software de aplicación y control.

Uno de los conceptos más poderosos atrás del diseño SoC es que la funcionalidad del sistema puede ser especificada y asignada no sólo al software que corre sobre el procesador, sino tambié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 óptima y por lo tanto a mayor velocidad que el procesador del sistema embebido, ayudando así a incrementar la performance del sistema.

Debido a la creciente demanda de tecnológica de la sociedad moderna, los sistemas embebidos que componen los equipos electrónicos actuales debe ser capaces de evolucionar constantemente a modo de soportar la creciente demanda de capacidad de procesamiento a los que están sometidos. A modo de resolver esto existen alternativas a los sistemas embebidos

tradicionales, como el desarrollo de sistemas embebidos en un SoC de alta performance (HPSoC).

En un HPSoC la arquitectura de hardware esta optimizada para que la plataforma de cómputo que lo compone trabaje cooperativamente con aceleradores de hardware. En el curso de desarrollo de un HPSoC, las funcionalidades que componen al mismo son definidas primero en software, para que luego parte de las mismas sea trasladada a hardware. La implementación en hardware a través de lógica programable es una alternativa válida que se puede utilizar para lograr sustanciales incrementos en performance, teniendo en cuenta el alto nivel de 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 una metodología de desarrollo de un HPSoC para luego finalizar con una comparación de performance entre los resultados obtenidos de dos alternativas de implementación del algoritmo de encriptación simétrico TripleDES en un HPSoC. La implementació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: La sección II presenta información teórica sobre las limitaciones de los sistemas basados en procesador que motivan el presente trabajo. La sección III presenta la metodología de trabajo propuesta para desarrollar este tipo de sistemas digitales. La sección IV presenta un enfoque en distintos niveles sobre las técnicas y mecanismos disponibles para incrementar la performance de un HPSoC. La sección V presenta dos implementaciones de HPSoC que proveen aceleradores criptográficos desarrollados siguiendo la metodología propuesta. La sección VI muestra y compara los resultados obtenidos. Por último, en la sección VII se muestran los resultados obtenidos y se presentan las conclusiones del presente trabajo.

65


II. LIMITACIONES DE LOS SISTEMAS BASADOS EN

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 de realizar tareas de cómputo específicas y por lo tanto, que no puedan satisfacer la performance de procesamiento que demandan algunos sistemas embebidos actuales. Persiguiendo la ley de Moore, a lo largo de los años se ha buscado alternativas para mejorar la performance de las plataformas de cómputo basadas en procesador. Sin embargo estas alternativas no han sido eficientes ni aplicables en muchos escenarios en donde la performance era un requerimiento. Como se enuncia en [1], esto se debe principalmente a que existen limitaciones físicas inherentes a los procesadores que en muchos casos y dada la tecnología actual, impiden que estas alternativas se apliquen arbitrariamente:

• El hecho de aumentar la cantidad de transistores y la frecuencia a la que estos trabajan, introduce serios problemas de disipación de calor (barrera de potencia).

• La frecuencia no puede ser incrementada arbitrariamente, no solo por la barrera de potencia, si no también debido a una inherente limitación física en los tiempos de conmutación de los transistores utilizados en el diseño del microprocesador (barrera de frecuencia).

• En un sistema de cómputo actual, el ancho de banda del microprocesador es generalmente 70 veces superior al de la memoria externa, convirtiendo el acceso a la misma en un cuello de botella. El uso de complejas jerarquías de memorias locales al microprocesador (caches) disminuye considerablemente el tiempo de acceso a los datos, pero debido a la imposibilidad tecnológica de incrementar el tamaño del cache arbitrariamente, el acceso a memoria sigue siendo un problema real (barrera de memoria).

• Finalmente los procesadores en si tienen una limitación fundamental: 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 y técnicas en las arquitecturas de los procesadores actuales que intentan extraer el paralelismo en las instrucciones 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 sustanciales incrementos en performance en sistemas donde la performance es el principal requerimiento. En el presente trabajo se demostrara la implementación de un HPSoC que permitirá crear una plataforma de computo especifica y orientada a la aplicación, a modo de optimizar el camino de ejecución de datos (a través de extraer e implementar paralelismo), optimizar el uso de la memoria (aumento la localidad y el acceso), disminuir la disipación de potencia (hardware especifico requiere menor número de transistores) y disminuir la frecuencia de trabajo (posible debido a que en cada ciclo de reloj se realizan múltiples operaciones).

III. METODOLOGIA DE DESARROLLO DE UN HPSOC

En la metodología propuesta, el diseño de un HPSoC consistirá en dos áreas separadas pero que requieren interacción entre ellas. Una de esas áreas es la creación del soporte necesario para implementar un sistema embebido en la FPGA basado en microprocesador y la otra es la optimización de 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 un componente acelerador que se comunicara con el componente de software a través del diseño embebido.

En primera instancia, el desarrollo de sistemas embebidos se realiza utilizando herramientas EDA que permiten interconectar, a través de una jerarquía de buses de interconexión, un microprocesador (que puede ser un softcore, o un hardcore como se menciona en [3]), con un conjunto de dispositivos que vuelven al sistema embebido una plataforma de computo funcional. El desarrollo de sistemas embebidos no es estandarizado y varía dependiendo del fabricante de FPGAs que se utilice. En el presente trabajo se utilizó FPGAs de la firma 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 las librerías de componentes de hardware XilinxProcessorIPLib.

En segunda instancia, se deberá trabajar sobre la aplicación que se busca optimizar. Para esto se debe realizar un prototipo por software de la aplicación o algoritmo a implementar en el HPSoC. Este prototipo será luego caracterizado y evaluado mediante herramientas como profilers y analizadores de có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 esta información y a través de un enfoque top-down, se procederá a estudiar 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. La implementación en hardware de las secciones críticas de la aplicación permiten que las operaciones computacionales puedan ser representadas en lenguajes de descripción de hardware y que a través de una estrategia de optimización por niveles, se puedan implementar componentes aceleradores de hardware, es decir hardware de procesamiento especifico que permita realizar computo altamente performante y eficiente.

Para el desarrollo del componente acelerador se puede utilizar un lenguaje de descripción de hardware como VHDL o utilizar una herramienta ESL como ImpulseC [4]. El componente acelerador además, deberá integrarse dentro del diseño embebido del HPSoC, por lo que un canal de comunicación de alta velocidad entre hardware y software deberá también ser desarrollado.

Por otro lado, cabe mencionar que el componente de software del codiseño HW/SW puede correr directamente sobre el procesador o bajo el control y soporte de un sistema operativo (como una aplicación más de espacio de usuario). Dado los beneficios que provee un sistema operativo, en nuestra metodología se brinda soporte de un sistema operativo para el componente de software.

66


Una vez que estas dos instancias del HPSoC estén completas, el diseño de hardware tiene que ser trasladado y mapeado en el fabric de una FPGA, y las imágenes binarias del software correspondiente tienen que ser almacenadas en las memorias correspondientes para su posterior evaluación.

IV. OPTIMIZACION DE PERFORMANCE EN UN DISEÑO

HPSOC

Existen diversos factores que pueden ser modificados y técnicas que pueden ser aplicadas en la arquitectura de un HPSoC a modo de incrementar la performance general del mismo. Estos factores pueden ser agrupados en tres áreas a las que llamaremos niveles de optimización.

A. Optimizaciones a nivel de Sistema

Describimos como sistema a la plataforma física en donde se implementa la aplicación. Las optimizaciones a nivel de sistema 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 ejecuten más rápido y para que el throughput sea más elevado.

La optimización trivial es modificar el diseño de hardware que compone la plataforma de cómputo para que los diversos componentes de esta funcionen a la máxima velocidad admisible. Además, es óptimo establecer canales de comunicaciones de alta velocidad entre los componentes de uso frecuente por el procesador, por ejemplo los bancos de memorias o la comunicación con el fabric de la FPGA. El uso de 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 el diseño de hardware permiten configurar restricciones de tiempo y aumentar el nivel esfuerzo, a modo de mejorar el rendimiento disminuyendo el tiempo de propagación de datos a travé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 el algoritmo de procesamiento trabaje con un conjunto de datos independiente unos de otros, y que además exista disponibilidad de recursos en la FPGA utilizada, se puede implementar 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 computacional que cumple un cierto número de requerimientos con el fin de implementar por software o hardware la funcionalidad principal del HPSoC.

El objetivo de las optimizaciones a nivel de aplicación es estudiar el algoritmo que define las operaciones críticas en performance de la aplicación, a modo detectar el paralelismo inherente en el mismo y optimizar el procesamiento.

Cabe aclarar que las optimizaciones sobre el algoritmo se harán sobre los detalles de alto nivel del mismo, y no sobre los

detalles de bajo nivel que definen la implementación del mismo. Entonces, si posibles paralelizaciones son detectadas, y siempre cumpliendo con los requerimientos funcionales iniciales, se buscara implementar las modificaciones necesarias en el código del algoritmo, de modo de que este deje de lado su flujo de ejecución serial y adopte un modelo de funcionamiento en paralelo.

Además de detectar niveles de paralelización y optimizaciones en el flujo de ejecución del algoritmo, otra interesante técnica que se puede utilizar para optimizar la performance a nivel de aplicación es el uso de precomputo de datos. Esto consiste básicamente en acotar el rango de acción del algoritmo, tomando asumpciones sobre el espacio de trabajo del algoritmo, a modo de precomputar y simplificar sus operaciones y de ese modo acelerar la ejecución del mismo.

C. Optimizaciones a nivel de micro arquitectura

Describimos como micro arquitectura a los componentes de lógica programable que implementan los detalles de bajo nivel del algoritmo que define la aplicación que se ejecutara sobre el HPSoC. Algunas técnicas para mejorar la performance de la micro arquitectura del componente acelerador son las siguientes.

1) Replicar los arrays o bancos de memoria que contienen

los datos: Una de las ventajas más importantes que nos ofrece la programación en hardware es la posibilidad de acceder a múltiples bancos de memoria en un solo ciclo de reloj. A diferencia de una implementación de software, en la que un CPU esta conectado a uno o mas dispositivos de memoria física siempre a través de un solo bus, una implementación en hardware permite la flexibilidad de generar una topología de conexionado arbitraria, en la que un conjunto de operaciones al ser ejecutadas puedan acceder a datos distribuidos en varios bancos de memoria en una sola operación de reloj. Es por esto que un factor importante a tener en cuenta, es que para lograr resultados óptimos debemos replicar nuestro set de datos en diferentes bancos de memoria. Con esto lograremos tener bancos de memoria separados, cada uno con su puerto de lectura/escritura, lo que permitirá acceder a los mismos en forma paralela para su posterior operación/procesamiento.

2) Operaciones sobre bucles: En un algoritmo, los bucles son una de las construcciones que contienen un alto grado de paralelismo inherente, y por lo tanto, son una de las construcciones que se apunta a optimizar. Los bucles generalmente realizan operaciones repetitivas sobre un set de datos. Si cada de las operaciones del bucle no depende de datos calculados en interacciones anteriores, es decir si en cada iteración se puede operar sobre set de datos independientes, el grado de paralelismo que se puede obtener es elevado. Existen dos técnicas para optimizar las operaciones sobre bucles, estas son el desenrollado del bucle y la generación de “líneas de ensamblado”, o mas conocido por su término en ingles, pipelines. El desenrrollado de bucles consiste 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 para completar 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 UN HPSOC CRIPTOGRAFICO

A modo de evaluar las mejoras obtenidas a través de la implementación de un HPSoC acelerado por hardware, se desarrollo un SoC prototipo sin aceleración (implementación solo por software), y dos versiones de un HPSoC con aceleración por hardware. En estos dos últimos casos, el componente acelerador fue desarrollado en VHDL y con la herramienta de síntesis de alto nivel ImpulseC respectivamente.

La aplicación criptográfica consistió en obtener un set de datos de memoria y cifrarlos a través del algoritmo de cifrado simétrico TripleDES. El algoritmo de cifrado simétrico TripleDES se utilizó en modo ECB, siguiendo los lineamientos mencionados en [7] y [8]. Siguiendo la metodología propuesta en el presente trabajo, después de diseñar e implementar el sistema embebido en el SoC, se desarrollo en software un prototipo no optimizado del algoritmo a utilizar. Este prototipo sirvió para estudiar el algoritmo y caracterizarlo. Con los datos obtenidos y evaluando las técnicas de optimización enumeradas en [9], se procedió a desarrollar los componentes aceleradores y aplicar los niveles de optimización anteriormente 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 FPGA Virtex4 FX12 y diversos componentes externos descritos en la página del fabricante. El diagrama en bloque del HPSoC desarrollado puede verse en la figura 1.

A. Desarrollo del sistema embebido del SoC

Durante el desarrollo del diseño embebido se dio soporte a todos los dispositivos físicos de hardware del kit de desarrollo, utilizando los IP Cores de Hardware necesarios para el funcionamiento del sistema embebido.

Para implementar el diseño embebido se utilizó la herramienta EDK de Xilinx descrita en [10]. El procesador elegido para el diseño embebido fue un recurso de hardware que posee la FPGA elegida, es decir el hardcore de un PowerPC 405 (PPC). Mediante esta herramienta se desarrollo un sistema embebido que permitió comunicar el procesador PPC con los dispositivos externos del kit de desarrollo, tales como 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 la herramienta permitió, desarrollar un canal de comunicación de alta velocidad entre el componente acelerador implementado en la lógica programable y el microprocesador del sistema embebido.

Se genero el soporte necesario para que el PPC pueda comunicarse a través de los buses PLB, OPB, FCB, OCM y DCR a los distintos dispositivo. Estos buses pertenecen a la familia de buses CrossConnect y están descriptos en [10]. Cabe aclarar que este procesador solo soporta conexión directa a los buses PLB, OCM, DCR y FCB, por lo que los dispositivos atrás del bus OPB se alcanzaran a través de un bridge PLB2OPB.

Una vez definida la arquitectura de buses, sus tamaños y frecuencias de trabajo, así como también los elementos adicionales necesarios para su correcto funcionamiento, se escogió a los dispositivos del kit de desarrollo a los cuales se les dará soporte y como estarán conectados estos a la jerarquía de buses, a modo de que estos sean visibles al procesador PPC. La configuración de los mismos, es particular de cada caso y dependiente del diseño adoptado, aunque por lo general esta configuración especifica incluye aspectos como el tipo de DMA 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 de memoria que estarán reservadas en el mapa de memoria del sistema para los registros del mismo. Cada IPCore de la librería de hardware XilinxProcessorIPLib posee un datasheet que detalla sus parámetros de configuración posibles.

El canal de comunicaciones de alta velocidad utilizado se implemento por medio del controlador APU, una funcionalidad del 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. Esta interfase de comunicación conecta directamente el pipeline de instrucciones del PPC a uno o más componentes aceleradores de hardware.

B. Desarrollo del soporte del software de control del HPSoC

El componente de software de la aplicación del HPSoC se ejecutara con soporte de un sistema operativo. Se eligió Linux como sistema operativo de soporte. Para esto se preparo el sistema operativo Linux a modo que controle los distintos componentes de hardware del sistema embebido. Se genero además un root filesystem con las aplicaciones necesarias para volver funcional al sistema. Se desarrollo además un mecanismo para que el kernel pueda ser cargado en memoria de 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 sistema embebido, inicializarse, detectar el hardware sobre el que se ejecuta, configurar las interfaces de red, autoconfigurar su dirección de red a través de DHCP y bootear un root filesystem remoto a través de NFS. En la figura 2 se puede observar la iteración de protocolos durante el booteo del kernel.

68


Controlador PHY

Controlador DDR

Controlador UART

ControladorGPIO

ControladorHWICAP

D cacheI cache

Arbitro

RAM de bloque

OPBPLB

Bus FCB

BusBridge

Arbitro

Componente Acelerador de HW

Power PC405

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 realizaron modificaciones masivas sobre el código del kernel, utilizando có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 el estado 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 la aplicación. Una desarrollada enteramente en software que sirvió 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 la herramienta ImpulseC y otra versión desarrollada en VHDL. A ambas versiones se les aplicaron las mismas optimizaciones descritas 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 del componente 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 el algoritmo 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 debido a que se asume que el valor de la llave no será cambiado por el usuario en el futuro. La generación y precomputo de las subllaves 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 cajas combinadas 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]. Esta té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 8 cajasSP. 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. RESULTADOS OBTENIDOS

Las métricas obtenidas de la ejecución del los componentes aceleradores de hardware desarrollados, así como también de la versión en software de la aplicación pueden verse en la tabla I.

En esta tabla se muestra que la aceleración obtenida al implementar parte del algoritmo de la aplicación en un HPSoC con un componente acelerador es de alrededor de 400X en ambos casos. El throughput expuesto corresponde a la medición del tiempo de ejecución de la función de SW que envía los datos al componente acelerador.

Se muestra además en la tabla II un extracto del reporte de la síntesis del componente acelerador más significativo (desarrollado en ImpulseC) que muestra el porcentaje de recursos usados en la FPGA.

VII. CONCLUSIONES

En el presente trabajo se presentaron los beneficios, en términos de performance, obtenidos a través de la implementación de aceleradores criptográficos utilizando HPSoCs.

Las implementaciones realizadas muestran cómo es posible incrementar la performance de una aplicación de software corriendo en un sistema embebido en varios órdenes de magnitud. Los resultados comparativos mostraron que luego de aplicar la metodología propuesta se obtuvo una ganancia de alrededor de 400X en ambos casos.

En el presente trabajo se utilizaron además herramientas del estado del arte en el desarrollo de lógica programable para implementar el sistema embebido y los componentes aceleradores.

TABLA I. RESULTADOS DE IMPLEMENTACION HPSOC CRIPTOGRAFICO

TABLA II. RESULTADOS DE SINTESIS HPSOC CRIPTOGRAFICO

Este trabajo concluye que la utilización de un HPSoC es una alternativa técnicamente viable para mejorar la performance de los sistemas digitales embebidos del mundo actual.

REFERENCIAS

[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 programmable gate 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/ACM International Symposium on Microarchitecture, 1996.

[7] Bruce Schneier, “Applied Cryptography Second Edition”. John Wiley, 2004.

[8] Federal Information Processing Standars Publication, “DATA ENCRYPTION STANDARD (DES)”. FIPS PUB 46-3.

[9] PK Yuen, “Practical Cryptology and Web Security”. Pearson Education Limited, 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 VHDL

50 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 BarenoUniversidad 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, diseno, y fabricacion de estos sistemas. Sinembargo, en la actualidad muy pocas universidades ofrecencursos que permitan crear las habilidades necesarias para larealizacion 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 ensenanza de diseno 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 aumentoy su campo de accion se ha extendido en casi todas lasactividades humanas. Segun BBC, inc. el mercado para elsoftware embebido crecio de $1.6 billones a $3.5 billones en2009, con una tasa de crecimiento anual (AAGR) del 16%,mientras la tasa de crecimiento para las tarjetas embebidases del 10%; segun Venture Development Corporation (VDC)mas de un billon de dispositivos embebidos fueron vendidosen el 2004,. De acuerdo con VDC el porcentaje de dispositivosbasados en sistemas operativos comerciales tiende a disminuirdel 43.1% en 2001 a 37.1% en 2004, esta tendencia se debe ala utilizacion de herramientas de libre distribucion GNU/Linux[1].

En la actualidad estamos presenciando una tendencia globala delegar las tareas de manufactura de sistemas digitales apaises asiaticos, donde la mano de obra calificada es abundantey barata; se presentan casos donde los creadores de una deter-minada tecnologıa no la desarrollan y dejan que estos paisesse beneficien de sus descubrimientos [2] reduciendo de formaconsiderable la produccion. Esta situacion se agrava a me-dida que las grandes empresas manufactureras asiaticas comoFoxconn capturan la produccion de los grandes disenadores

como Apple, Nokia, DELL, HP y Microsoft, lo que genera elcierre de empresas manufactureras a lo largo del mundo, conla consecuencia de perdida de empleo masivo. En la actualidadsegun Bureau of Labor Statistics y Thomson Financial ExtelCompany Report Foxconn emplea a mas personas que Apple,Dell, Micorsoft, HP, Intel y Sony combinados; esta situaciones mas grave en paises en vıa de desarrollo, donde no existela plataforma tecnologica para disenar dispositivos digitales,y son importadores de tecnologıa sin la capacidad de generarproductos que satisfagan necesidades locales. Lo anterior llevaa preguntarse por la funcion y la situacion de un profesionalen areas afines a la ingenierıa electronica en paıses donde noexiste la capacidad de concepcion y diseno.

La tendencia moderna en los programas academicos a lautilizacion de herramientas de alto nivel para la ensenanzaen areas afines al desarrollo de dispositivos digitales [3]ocasiona que los profesionales no adquieran las habilidadesnecesarias para completar la cadena concepcion - diseno -implementacion y operacion, en la mayorıa de los casos segeneran habilidades para la concepcion y el diseno a altonivel y dejan los otros pasos en manos de herramientasespecializadas y/o a empresas asiaticas. Esta situacion resultala mas atractiva desde el punto de vista economico, ya que noes necesario adquirir maquinaria costosa ni contratar personalcalificado para operarlas; sin embargo, limita la generacionde 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 productosen vez de tecnologıas de nivel basico” [3]. Esta situacion unidaal abandono de la implementacion hace que la dependenciacon las empresas manufactureras asiaticas aumente cada vezmas.

Segun el ex-director ejecutivo de Intel Andy Grove [2] lasolucion esta en hacer de la creacion de empleo la polıticaeconomica gubernamental mas importante y hacer que lasdemas giren en torno a ella. Ademas, es necesario volver ala 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 lograrloes necesario crear en los profesionales las habilidades paraimplementar productos comercializables.

En este artıculo presentamos un programa academicobasado en la utilizacion de software y hardware libre para elarea de electronica digital que desarrolla las habilidades nece-

74


sarias para Concebir, Disenar Implementar y operar sistemasdigitales.

A. Flujo de diseno de sistemas embebidos

Los Sistemas Embebidos son sistemas heterogeneos quecontienen componentes Software (microcontroladore, micro-procesadores y DSPs) y Hardware (funciones implementadasen Dispositivos logicos programables PLDs); por este motivo,es necesario adquirir habilidades en la utilizacion de lenguajesde programacion como C o C++ para implementar las fun-ciones software y Verilog o VHDL para la implementacionde las tareas hardware; adicionalmente, deben conocer lasdiferentes formas de comunicacion entre estos dos tipos defunciones. Aunque en el mercado existen herramientas quepermiten la entrada de diseno utilizando lenguajes de altonivel como SystemC o SpecC y proporcionan el codigo paraimplementar las tareas software, hardware y su interfaz decomunicacion; no es recomendable utilizarlas en el ciclo deformacion basico ya que impide que se conozca el flujo dediseno completo, suministrando un nivel de abstraccion en elcual no es necesario conocer la arquitectura de la plataformautilizada para la implementacion.

En la figura 1 se muestran los conceptos que deben dominarlos disenadores de sistemas embebidos, y las tareas quedeben realizarse para la concepcion, diseno e implementacionde un sistema embebido. En gran parte de los programasacademicos se estudian unicamente los temas relacionados conla concepcion y diseno centrandose en las especificacionesfuncionales del sistema, utilizando herramientas comercialeso COTS (Commercial off-the-shelf) para su implementacion.Esta combinacion genera dependencia e impide la generacionde habilidades necesarias para implementar un sistema dig-ital teniendo en cuenta restricciones economicas, fısicas,electricas, ergonomicas, comerciales, etc. Nuestra propuesta sebasa en la utilizacion de herramientas abiertas tanto hardwarecomo software que permiten recorrer todo el proceso de con-cepcion, diseno e implementacion y obtener un entendimientointegral del proceso sin generar dependencia a productoscomerciales.

1) Dominios de Diseno y Niveles de abstraccion: Existentres dominios en los que se puede describir un sistemadigital [5] Funcional: Describe el comportamiento funcional ytemporal del sistema Estructural: Describe su composicion apartir de bloques basicos y Fısico relacionado con la estructurafısica del sistema a nivel de circuito integrado o placa decircuito impreso [6]. Cada uno de estos dominios puede serdescrito utilizando diferentes niveles de abstraccion; un nivelde abstraccion alto permite el uso de lenguajes de alto nivelfacilitando la entrada de diseno al extraer la funcionalidad dela parte fısica; por otro lado, los niveles de abstraccion bajoutilizan bloques constructores elementales.

En el mercado existen herramientas que permiten entradasde diseno a nivel funcional utilizando especificaciones yalgorı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 puedengenerar archivos para la fabricacion de un circuito integradoo archivos de configuracion/programacion que pueden serutilizados en dispositivos comerciales. Desde el punto de vistacomercial esto es muy util ya que permite reducir el tiempode diseno y los costos asociados. Sin embargo, presentan losinconvenientes mencionados anteriormente y por lo generalson muy costosas.

II. METODO PARA LA ENSENANZA DE SISTEMASEMBEBIDOS

Basandose en la metodologıa de diseno para sistemas embe-bidos [7], en los dominios de diseno y niveles de abstraccionde Gajski-Kuhn, se realizo una division de temas que buscacrear habilidades de forma gradual e incremental. En la Figura4 podemos observar esta division y las herramientas quese utilizaran en cada curso, como herramienta de desarrollohardware se utilizara una plataforma que proporcione losarchivos y documentos necesarios para replicarla, modificarlay pueda ser utilizada como base de desarrollos comerciales.

A. SIE: Plataforma abierta para el desarrollo de sistemasembebidos

En el mercado existe una gran variedad de plataformas quepueden ser utilizadas en el estudio de sistemas embebidos,sin embargo, no todas son adecuadas para la implementaciondel metodo que proponemos ya que se requiere: acceso a losesquematicos y a los archivos de fabricacion del PCB con posi-bilidad de modificacion; acceso a la documentacion completadel proceso de fabricacion; acceso a la cadena de produccion;utilizacion de herramientas abiertas para su programacion; unPLD para la implementacion de tareas HW; un procesador parala implementacion de tareas SW; un canal de comunicacionentre el procesador y el PLD; y una comunidad que desarrolleaplicaciones para dicha plataforma y que proporcione medios

75


para el intercambio de informacion a traves de listas de correoy wikis.

Despues de una busqueda minuciosa no se encontraronplataformas que cumplieran con estas condiciones, en especialcon las relacionadas con el proceso de diseno y de produccion,esto es normal, ya que la mayorıa de las empresas no quierenque se fabriquen sus plataformas y los proyectos individualesno poseen la infraestructura necesaria para la produccionmasiva. Por este motivo, se decidio crear una plataforma quecumpliera con los requerimientos (plataforma SIE), para ellose buscaron proyectos similares que permitieran su creacion yque el producto creado sea una extension de dicho proyecto.El proyecto Qi-Hardware [8] busca definir el concepto copylefthardware basandose en el movimiento de software libre ycodigo abierto (FOSS [9]) y proporciona un enlace con laindustria manufacturera asiatica.

1) Hardware copyleft: El proyecto SIE [10] fue creadopara satisfacer las necesidades de los desarrolladores de hard-ware permitiendo la creacion de aplicaciones comercialesbajo la licencia Creative Commons BY - SA [11] la quepermite la distribucion y modificacion del diseno (incluso paraaplicaciones comerciales), con el unico requisito de que losproductos derivados deben tener la misma licencia y debendar credito al autor del trabajo original. Lo que constituye labase de los productos hardware copyleft.

Al ser inspirado en el movimiento FOSS, los dispositivoshardware copyleft comparten la misma filosofıa [9], y sonel complemento perfecto del software libre. Para que undispositivo HW sea reproducible y modificable es necesario:suministrar los archivos necesarios para la fabricacion, esdecir, los esquematicos y los archivos de la placa de circuitoimpreso (preferiblemente para herramientas abiertas comoKicad o geda); la cadena de herramientas de compilacion ydepuracion para desarrollo de aplicaciones; el codigo fuentede: el programa que inicializa la plataforma (bootloader),la herramienta que carga dicho programa en la memoriano volatil (usbboot), el sistema de archivos y aplicaciones(openwrt); documentacion completa que indique como fuedisenada, construida, como utilizarla, desarrollar aplicacionesy tutoriales que expliquen el funcionamiento de los diferentescomponentes. (esto puede ser descargado de [12] y [13]). Adi-cionalmente, se debe contar con la posibilidad de fabricaciony montaje, lo que constituye la principal diferencia entre elsoftware 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 acolor de 3 pulgadas, 2 entradas y salidas de audio stereo,2 entradas analogas; una FPGA que proporciona 25 senalesde entrada/salida digitales de proposito general (GPIOs) ycontrola un conversor analogo digital de 8 canales. Existen trescanales de comunicacion entre la FPGA y el procesador: unopara controlar el puerto JTAG, lo que permite la configuracionde la FPGA desde el procesador (eliminando la necesidadde cables de programacion); otro que proporciona el bus de

datos, direccion y control para comunicarse con las tareas HWo perifericos implementadas en la FPGA y un puerto serialutilizado para depuracion de softcores implementados en laFPGA. El procesador utilizado es un Ingenic JZ4725 (MIPS)corriendo a 400MHz, se dispone de una memoria NAND de2GB para almacenamiento de datos y programas, ası como deuna memoria SDRAM de 32 MB, lo que permite la ejecucionde 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, yes configurado para ser utilizado como una interfaz de red(usb0), permitiendo la transferencia de archivos y ejecucion deuna consola remota utilizando el protocolo ssh; este canal decomunicacion tambien se utiliza para programar la memoriaNAND no volatil, por lo que para realizar la programacioncompleta de los componentes de la plataforma solo es nece-sario un cable USB.

4) Especificaciones fısicas: Las dimensiones de SIE son8cm de largo, 8 cm de ancho, 1cm de altura; su placa decircuito impreso es de dos capas, utiliza lıneas de 8 mils, vıasde 12 mils de diametro, los componentes se encuentran en unasola capa y son TQFP o SMD, no posee componentes BGAo QFN lo que facilita el montaje manual. Todo esto hace quesea posible la reproduccion y modificacion de esta plataformaa un precio muy bajo. El costo de fabricacion de esta tarjetase estima en 70 usd para 50 unidades. La figura 3 muestra laapariencia de la plataforma de desarrollo SIE.

B. Curso basico

Para el curso basico se trabajara la mayor parte de losniveles de abstraccion del dominio funcional; partiendo deunas especificaciones funcionales se generara un modelodel sistema utilizando algoritmos que describan el compor-tamiento de las diferentes tareas que implementan el sistema(bloques funcionales). Estos bloques seran implementados, endispositivos logicos programables como FPGAs o CPLDs.A partir de estos algoritmos se identifican las operacionesbasicas aritmeticas y logicas que modifican los datos asociadosa cada funcion para generar el camino de datos (datapath;

76


Fig. 3. Plataforma de desarrollo SIE

el datapath proporciona senales que controlan el instante enel que se ejecutan la operaciones soportadas, dichas senalesdeben ser generadas por un modulo disenado para implementarel algoritmo deseado; estos dos modulos se implementarancon bloques logicos basicos y maquinas de estados finitosutilizando lenguaje de descripcion de hardware (VHDl, verilogestandard). Estas descripciones son la entrada a herramientasque realizaran la transicion al dominio estructural generandolas compuertas logicas, flip-Flops y las interconexiones queimplementen la funcionalidad requerida. Durante el procesoes necesario realizar simulaciones (utilizando icarus verilogy ghdl) que permitan comprobar el cumplimiento de lasespecificaciones iniciales, si no se cumple alguna de ellas sedebe volver a repetir el proceso.

Durante el desarrollo del primer curso se estudiaran losconceptos basicos de los sistemas digitales como sistemasnumericos, operaciones aritmeticas y logicas, logica combi-natoria y secuencial. Se utilizaran lenguajes de descripcion dehardware como VHDL y verilog como entrada de diseno aherramientas que realizan la sıntesis digital. Para evitar creardependencia, se ensenara la forma de adecuada de implementarcodigo re-utilizable que no utilice componentes especıficos deun determinado fabricante.

1) Diseno de aplicaciones utilizando HDL y PLDs: Paragenerar las habilidades necesarias para concebir, disenar, im-plementar y operar sistemas digitales, se realizaran practicassencillas que ayuden al estudiante a entender los mecanismosde implementacion de tareas HW en un dispositivo logicoprogramable utilizando la plataforma de desarrollo SIE; comopuede verse en la figura 2 la FPGA solo controla un conversoranalogo digital serial de 8 canales, y proporciona 25 GPIOs,esto se hizo de forma intencional para que los estudiantesse vean forzados a realizar las conexiones electricas delos dispositivos externos a sus aplicaciones; las plataformascomerciales proporcionan una gran variedad de dispositivosconectados a los PLDs, lo que no es muy recomendable yaque el estudiante no aprende a leer la hoja de especificacionesdel fabricante de un determinado dispositivo para determinarsu forma de conexion, y/o las condiciones que se deben

tener en cuenta para su correcto funcionamiento; afectandola generacion de habilidades necesarias para la eleccion decomponentes, realizacion y lectura de esquematicos y disenode layouts.

El procesador de la plataforma SIE sera utilizado comocamino de configuracion de la FPGA; el archivo de configu-racion sera descargado al sistema de archivos de la plataformaSIE utilizando el protocolo ssh y la interfaz de red USB; unprograma en espacio de usuario se encarga de configurar laFPGA con el archivo deseado. Adicionalmente, existe unaaplicacion basada en el proyecto urjtag ejecutandose en elprocesador que permite la generacion de vectores de pruebay recoleccion de resultados utilizando el puerto JTAG [14], loque permite que el estudiante pueda probar su circuito a bajafrecuencia 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 llegara la arquitectura de un sistema sobre silicio (SoC), esto conel fın de conocer y entender la arquitectura y funcionamientode los dispositivos en los que se ejecutan las tareas software.Se utililizaran perifericos conectados a traves de buses a laCPU para implementar tareas hardware. Se realizara la im-plementacion de un Sistema sobre silicio (SoC) y se trabajaracon herramientas de libre distribucion (cadena de herramientasGNU [1]) para programar aplicaciones que involucren el usode tareas HW y SW.

1) Arquitectura de una CPU y tareas SW: Utilizandoprocesadores softcore se estudiaran los componentes basicosde la CPU, el camino de datos: banco de registros, bloques ar-itmeticos, logicos y buses internos, se analizaran las diferentesinstrucciones que proporciona la arquitectura bajo estudio y seanalizara el funcionamiento de la maquina de control, iden-tificando los componentes que permiten el almacenamiento yejecucion secuencial de instrucciones definidas por el usuario.En este punto se introduciran los conceptos de llamado a fun-ciones, atencion de interrupciones, direccionamiento directo eindirecto y acceso a memoria externa.

Para este estudio, se utilizaran procesadores implementadosen lenguajes de descripcion de hardware que cuenten conherramientas de programacion de bajo (assembler) y alto nivel(C, C++), con el fin de realizar simulaciones, aplicacionesy modificaciones. Al finalizar el curso se pretende que elestudiante entendienda las diferencias entre tareas software ytareas hardware y podra realizar experimentos que le permitancomparar las caracterısticas de ambas implementaciones. Enla actualidad se esta trabajando con los SoC plasma basadoen un procesador MIPS, MICO 32 de lattice, y openrisc deOpenCores, implementados en VHDL o Verilog.

Se utilizaran los perifericos para la implementacion de tar-eas HW y se estudiaran las diferentes formas que existen paracomunicarse con las tareas SW (buses, interrupciones, polling)presentando los criterios de seleccion para la implementacionde tareas SW y HW. Se introducira el concepto de mapade memoria, decodificador de direcciones, memorias volatiles

77


(ejecucion de programas y de uso general) y memorias novolatiles (almacenamiento de programas). Se introducira elconcepto de bootloader y su uso en la carga de aplicacionesa las memorias volatiles internas y externas del SoC. Yfinalmente se mostraran los diferentes metodos existentes paraprogramar las memorias no volatiles.

Utilizando la cadena de herramientas GNU, se realizarael flujo de desarrollo para tareas SW desde la entrada dediseno utilizando el lenguaje C, hasta la generacion del archivobinario que contiene las instrucciones (para la CPU en estudio)que implementan dicha tarea. Utilizando herramientas propiasse generaran los archivos para inicializar la memoria deprograma (implementada en la FPGA) con estas instrucciones.

2) Diseno de aplicaciones que involucren co-diseno HW-SW: Tanto la CPU, los perifericos, la memoria ram y lamemoria de programa estaran implementados en la FPGAde SIE. Durante todo el periodo academico se desarrollaraun proyecto de complejidad media que involucre el uso detareas HW y SW, (en la pagina de la plataforma [13] sepueden observar los proyectos realizados hasta el momento);para esto se formaran equipos de trabajo de 3 personasque deben hacer una propuesta inicial (concepcion y es-pecificaciones), realizar la descripcion funcional del sistemautilizando algoritmos (diseno y modelo del sistema), realizarel particionamiento en funciones HW y SW, implementar estasfunciones y disenar una placa de circuito impreso (utilizandokicad) con lo necesario para implementar la funcionalidadrequerida (implementacion). Se realizaran entregas periodicaspara verificar el cumplimiento del cronograma propuesto por elequipo de trabajo y el proceso de diseno debe ser documentadoen la pagina wiki del curso. Esta actividad generara habilidadesde trabajo en equipo, elaboracion de esquematicos, fabricacionde PCBs, escritura de documentos tecnicos e implementacionde sistemas digitales.

SIE permite conectar de forma facil (usando dos jumpers)dos GPIOs de la FPGA a las senales de transmision y re-cepcion del procesador, lo que permite la comunicacion serialentre el procesador implementado en la FPGA y el procesadorMIPS, creando de esta forma un canal de depuracion paralas aplicaciones implementadas en la FPGA, eliminando lanecesidad de equipo adicional.

D. Sistemas Embebidos

El tercer y ultimo curso de la lınea integra los conocimientosadquiridos en los cursos anteriores e introduce un elementonuevo un SoC comercial, SIE posee un SoC basado enun procesador MIPS equipado con los recursos necesariospara ejecutar programas Linux; en este curso se estudiara laarquitectura 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), elsistema operativo Linux, drivers de perifericos, distribucionespara 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) Creacion de perifericos y drivers : Ademas de cubrirel tema de programacion de SoC utilizando GNU/Linux, esnecesario que se entienda no solo el funcionamiento delsistema operativo Linux, sino como este se comunica y con-trola los perifericos (tareas HW); para esto, se implementaranperifericos en la FPGA y se estudiara la forma de acceder aellos utilizando el protocolo establecido por el kernel.

2) Concepcion, Diseno, Implementacion y Operacion deSistemas Embebidos: Durante el periodo academico los es-tudiantes deben disenar, implementar y operar un sistemaembebido concebido por un equipo de trabajo de tres per-sonas, utilizando como base la plataforma SIE, disenaran unatarjeta hija (utilizando kicad) que implemente la funcionalidaddeseada, todos los proyectos deben integrar tareas HW en laFPGA con modulos del kernel para su control. Los proyectosrealizados hasta el momento pueden encontrarse en la paginadel proyecto.

E. Comunidad hardware copyleft

Una parte importante de este metodo de ensenanza es lafilosofıa del proyecto hardware copyleft, por esta razon, cadagrupo debe hacer un aporte, suministrando la informacioncompleta del proceso de desarrollo, los archivos necesariospara replicar y/o modificarlo, esto es una consecuencia de lalicencia 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 prestandoservicios a la comunidad porque disfrutan programar. Estosaficionados realizan un papel muy importante dentro de la co-munidad encargandose de tareas como mejora de la plataformatecnologica, re-escribiendo secciones de codigo, documentan-dolo, respondiendo preguntas, preservando o mejorando laarquitectura [15]. Las actividades de documentacion ademasde contribuir a mejorar las habilidades de escritura de reportestecnicos ayudan a formar una comunidad que contribuyeal crecimiento del proyecto copylef harware, los estudiantesingresan a las listas de desarrolladores aprendiendo a utilizaruna herramienta muy poderosa en la que pueden compartirsus inquietudes con miembros mas experimentados y mientrasparticipan ayudan a crear un banco de preguntas que puedenser utiles para futuros miembros. Adicionalmente se obliga aexpresarse en un idioma diferente.

Crear estos habitos ayuda a que los jovenes sean conscientesde su papel dentro de la comunidad y piensen que sus accionespueden ayudarla o perjudicarla, los proyectos realizados porellos podran ser parte de los recursos de la comunidad (si lacalidad del trabajo lo amerita) y pueden ser la continuacionde un esfuerzo prolongado o el punto de partida de un nuevoconocimiento; la licencia CC-BY-SA garantiza que todos lostrabajos derivados de este recurso seran parte del mismo, loque garantiza su crecimiento, la labor de los estudiantes es vi-tal para el uso del recurso comun y puede crear miembros queen un futuro formularan polıticas y reglas de uso del recurso.Por otro lado, participar en este tipo de proyectos permite crearreputacion, la cual puede ser util para establecer relacionesprofesionales, de negocios o personales. El entorno academicoes ideal para atraer nuevos miembros a la comunidad hardwarecopyleft, ya que se trabaja con jovenes con deseos de ser partede un grupo y de adquirir conocimientos. Desde el punto devista comercial este recurso es muy atractivo ya que permiteahorrar mucho tiempo, esfuerzo y dinero para la creacion denuevos productos. Por otro lado, el concepto de hardwarecopyleft es una herramienta poderosa para transferir tecnologıay conocimientos a los paıses en vıa de desarrollo donde laplataforma tecnologica no se lo suficientemente desarrollada.

III. CONCLUSIONES

El hardware copyleft es una herramienta poderosa parala creacion de habilidades necesarias para concebir, disenar,implementar y operar sistemas digitales, ya que proporcionala informacion necesaria para entender el ciclo completo dediseno, (lo cual no es posible obtener cuando se trabajacon plataformas de desarrollo comerciales); proporcionandoinformacion detallada sobre el proceso de diseno de platafor-mas abiertas, que pueden ser utilizadas como referencia paragenerar nuevos productos comerciales; el acceso a aplicacionessoftware que permiten la creacion de aplicaciones; un canal decomunicacion que permite utilizar a la industria manufactureraasiatica para la produccion en masa; conocimiento de losprocesos de fabricacion y produccion.

Las actividades propuestas en las tres asignaturas del areatienen como objetivo generar en el estudiante las habilidadesnecesarias que le permitan disenar sistemas digitales congrado de complejidad creciente, hasta llegar a un sistema quepuede ser comercializable y satisface una necesidad de unadeterminada comunidad, con esto, se evita que el ultimo pasoen el proceso de ensenanza sea la simulacion; se ilustra elproceso que debe seguirse para que un prototipo se conviertaen un producto comercial, lo que contribuira con la creacionde nuevos productos y la generacion de empleo.

La utilizacion de herramientas de bajo nivel permite queel estudiante conozca y controle los diferentes pasos de lametodologıa de diseno y sea capaz de ajustarlas para diferentessituaciones, esto hace que se adquiera un conocimiento sobrela tecnologıa sin crear dependencia hacia las herramientascomerciales que realizan la mayorıa de los pasos de lametodologıa de forma automatica.

REFERENCES

[1] R. M. Stallman. The GNU Operating System and the Free SoftwareMovement 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/b4186048358596.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 SystemDesign: Modeling, Synthesis, Verification. Springer, 2009.

[7] Luis Alejandro Cortes. Verification and Scheduling Techniques for Real-Time Embedded Systems. PhD thesis, Linkopings universitet Institute ofTechnology, 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 inOpen Source Software Development. Management Science, July 2006.

79


Desarrollo de un equipo para grabar los sonidosde 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 posibledeterminar 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 sutasa de consumo[2].

Existen situaciones en las que el consumo de energía delanimal 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 lossonidos 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 yreconocimiento.

Por está razón, primero se realizaron varios ensayos paraobtener 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 unacomputadora.

Determinación de los requerimientos

El artículo “Computational method for segmentation andclassification of ingestive sounds in sheep”[4] propone unmétodo novedoso para análizar y reconocer automaticamenteseñ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 delas mismas se decidió que el dispositivo de grabación debíamuestrear al menos a 22 kHz y tener una resolución de almenos 12 bits.

Teniendo en cuenta que el dispositivo debía ser capaz degrabar el sonido emitido por los rumiantes durante 24 horas,al obtener las señales a 22 kHz, 12 bits, fue necesario contarcon una memoria no volátil de al menos 3,5 GB.

Era indispensable que el dispositivo permaneciera en elanimal durante 1 día sin interrupción, por lo que la bateríadebí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 elproyecto y la relación entre la capacidad de las baterías ysu peso, concluimos que la placa debía consumir menos de1,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 lacapacidad de interactuar con el usuario, para lo cual se decidióutilizar LEDs y botones.

Del análisis de los distintos requerimientos del sistema sellegó 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 enfrecuencia de grabación y/o cantidad de bits, y costo.

Luego se consideró la opción de desarrollar a medida placascon 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 presentaventajas en cuanto a consumo y costos, implicaba un riesgopara cumplir los plazos del proyecto y debido a que había quetomar la definición en una etapa temprana del mismo en lacual todavía no se tenían claros todos los requerimientos sedecidió utilizar un sistema con mayores recursos y flexibilidad.

Por las razones antes mencionadas finalmente se decidióutilizar una Single Board Computers que incluyera un sistemaoperativo para acortar tiempos de desarrollo y una tarjeta desonido o ADC externo que cumpliera los requerimientos. Estasolución permitiría tener mayor flexibilidad y velocidad dedesarrollo de las aplicaciones, y soportar futuras ampliacionesdel equipo como son transmitir los datos mediante Wi-Fifacilitando la descarga de datos del dispositivo o añadir unGPS que permitiría relacionar las actividades realizadas por elanimal 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ñosagregados), concluimos que la placa TS-7260 de TechnologicSystem era la mejor opción. Además se decidió utilizar latarjeta de sonido USB 3D Sound modelo HY554 por cumplircon los requerimientos de frecuencia de grabación y cantidadde bits y ser de bajo costo.

TS-7260: Tiene instalado de fábrica el núcleo 2.4.26 deGNU/Linux, y está optimizado para la arquitectura de lamisma y su consumo máximo se encuentra en el orden de1 W (sin el uso de periféricos y a máxima frecuencia).

Por defecto la TS-7260 trae instalada la aplicaciónBusyBox[9]; pero la utilización de la misma fue descartadadebido 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 sumamenteestable.

USB 3D Sound modelo HY554: Inicialmente se habíadecidido grabar a 22 kHz pero la tarjeta de sonido seleccionadamuestrea únicamente a 48 kHz; por lo que finalmente lagrabación de audio se realiza con frecuencia de muestreo de48 kHz.

Unidades de almacenamiento: Para poder almacenar 24 hsa 48 kHz, 16 bits, se necesita una unidad de almacenamientode al menos 7 GB. Se intentó grabar audio y decimar losarchivos ya grabados, simultáneamente en la placa pero losmismos resultaban corruptos. Tampoco fue posible utilizaralgoritmos de compresión de audio con pérdida de informaciónporque 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 dealmacenamiento dado que la memoria interna de la TS-7260no es suficiente.

Finalmente se decidió almacenar los datos en un pendrivede 8 GB e iniciar el sistema desde una memoria SD card de2 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 utilizarse relevó el consumo de la placa en las posibles situacionesde 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) Potencia (W)Inicio del sistema 300 máx 1,5Estado de espera 220 1,1

Grabando y almacenando 240 1,2

Eligiendo el peor caso (inicio del sistema), el consumo fuede 1,5 W, lo cual nos llevó a consumir 36 Wh en un día.

Teniendo en cuenta la potencia que debía suministrar, elrango 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 (modeloRB632C) de 6 V y 3200 mAh. Usando ambas baterías se llegóa una capacidad de 38,4 Wh, cumpliendo los requerimientosplanteados anteriormente. Las baterías seleccionadas pesan1200 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 delitio-ion de 2800 mAh y 3.7 V (modelo GTL), con lo cualel peso de las baterías bajaría significativamente quedando enaproximadamente 200 g.

Micrófono: Se decidió utilizar el micrófono Ht-101 de lamarca Xtreme que se encontraba en el mercado local a unprecio 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: Parapoder mantener una comunicación con el usuario se diseñóuna placa interfaz de usuario y control de energía. La mismacuenta con tres botones con las siguientes funcionalidades:encendido, apagado y grabación.

Uno de los problemas que se presentó al apagar la placa esque la misma sigue tomando corriente luego de que el sistemaoperativo es apagado. Para evitar este problema se

Como se puede observar en la Figura 3, uno de los botonesmecánicos se encuentra en paralelo a un botón lógico. El botónlógico se realizó mediante un opto acoplador y un transistorlos cuales se disponen en una configuración Darlington. Alpresionar el botón de encendido la placa se prende y ejecutasu secuencia de arranque. Unos segundos después el sistematoma el control de los puertos de entrada-salida, se polarizael 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 transistorQ2 permitiendo así el pasaje de la corriente. El proceso deencendido 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 seleccionadasGumstix Overo Earth[5] PPM-LX800[6] EPX-GX500[7] ARM TS-7260[8]

Procesador ARM Cortex-A8 CPU 600MHz

AMD 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 placaTS−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 MicroCase[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 SISTEMAEMBEBIDO

Introdución

El diseño del sistema embebido se divide en los siguientesbloques:

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 bootloaderpara 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 sistema

Cuando se presiona el pulsador de apagado el sistemaoperativo 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 SISTEMAEMBEBIDO

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 sistemaoperativo. 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 softwareimplementado, definimos la probabilidad de acierto de laactividad A (simbolizando pastoreo, rumia o descanso) como:

PaA =100tA

KA∑i=1

Ni∑j=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 Aen 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 adicionaldel 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 ExperimentalAgriculture, 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, “Computationalmethod 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 en

sistemas embebidos del tipo ARM.

Marcelo M. Raponi

Centro de Investigaciones en Láseres y Aplicaciones

CITEFA-CONICET

Buenos Aires, Argentina

[email protected]

Rodolfo O. Bonnin

Business Vision S.A.

Hipólito Yrigoyen 1530, Piso 7

Ciudad 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 y

librerí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. INTRODUCCIÓN

El sentido de la visión es fundamental para realizar las múltiples tareas que cotidianamente llevamos a cabo los seres humanos. Actividades tan habituales como cruzar una calle, tomar un colectivo, mirar televisión, leer el diario, entre otras tantas, se ven seriamente afectadas por lesiones y patologías oculares que producen ceguera parcial o completa en millones de 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 el término baja visión de una forma amplia, es necesario tener en cuenta no sólo el déficit visual sino también la calidad visual. Una patología ocular permanente debe ser valorada en cuanto afecta al estado psíquico, fisiológico y social del individuo respecto a una vida de relación. La Organización Mundial de la Salud (OMS) define la baja visión como: "Pérdida de agudeza visual y/o campo visual, que incapacita para la realización de tareas de la vida diaria, incluso tras un tratamiento y/o correcció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 queda resto visual útil”. Una persona es legalmente ciega cuando su agudeza visual es menor o igual a 0.1 (10% de visión) y su campo visual inferior a 10º, en el mejor de los ojos. Según estadísticas mundiales existirían alrededor de 161 millones de personas con deficiencia visual, de los cuales 124 millones tendrían baja visión y 37 millones serían ciegos, incluyendo 1,4

millones menores de 15 años. Las cataratas son la principal causa 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 se trabaja en monocularidad, es decir, se utiliza el mejor ojo del paciente que siempre ve menos de 3/10. Si ambos ojos ven más de 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 gran convergencia que se necesitaría para enfocar un objeto ubicado a una distancia de 10 o 12.5 cm. En la mayoría de los casos, el ojo más deteriorado afecta - por ser el ojo director - la percepción del mundo exterior, y el cerebro debe aprender a desechar dicha información. Una manera de colaborar con el cerebro es colocar un vidrio oscuro o esmerilado frente a dicho ojo, impidiendo que reciba estímulos de luz. Por otro lado, no existen indicaciones de ayudas ópticas/electrónicas para patologías especificas. Un persona con baja visión tiene disminuida la sensibilidad de percepción (capacidad de distinguir detalles) debido a diversas causas, por lo cual, cualquier dispositivo de rehabilitación, deberá sencillamente magnificar 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 grado rehabilitación visual. En el mercado nacional e internacional existen ayudas para visión cercana (ej. leer o escribir) y visión lejana (ver TV, mirar una pizarra, observar carteles en la vía pública, etc.), aunque el acceso a estos dispositivos es generalmente 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 hasta más de U$S 3000. El dispositivo que presentamos en este trabajo (aún en etapa de desarrollo) tiene un costo de fabricación de aproximadamente U$S 500 (incluye anteojos con display y mini-cámara, unidad de control, batería, cables y componentes varios). Estimamos que el precio final de venta del sistema será de unos U$S 1000 (la tercera parte del costo de nuestro principal competidor: www.vuzix.com).

A continuación se presenta el diseño y desarrollo de un dispositivo biomédico de rehabilitación visual, basado en tecnología embebida de última generación y algoritmos de procesamiento de imágenes digitales, capaz de mejorar la calidad de vida de personas con disfunciones visuales severas. El sistema - reconfigurable, portátil y de bajo costo - permite adquirir y procesar imágenes en tiempo real, efectuar un realce selectivo de la información visual y mapear dicha información en un patrón de estimulación apropiado. El software se basa en plataformas open-source lo que garantiza su portabilidad e interoperabilidad con otros sistemas y hardware subyacente, y es lo suficientemente modularizado como para permitir una rápida adaptación a nuevos dispositivos embebidos o bibliotecas, como así también un adecuado mantenimiento en el caso que se requieran rediseños y/o adicionar nuevas funcionalidades.

II. IMPLEMENTACIÓN DEL HARDWARE

La implementación física del dispositivo consta de tres componentes: un módulo de adquisición de señales de video (con un subsistema de captura de imágenes incorporado y salida USB), un módulo de visualización de señal de video procesada, y un módulo de procesamiento basado en tecnología ARM (Advanced RISC Machines) Cortex™ A8 (placa BeagleBoard) [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ágenes consiste en un soporte (anteojos) que posee un dispositivo de captura integrado (ver Fig. 2). El sensor y su controlador se encuentran montados en la estructura de los lentes y se vinculan con la unidad de control vía un puerto USB 2.0. El controlador de video (Sunplus SPCA1528A) soporta sensores de 5 Mega píxeles, grabación de audio y video, y salida de TV. Por medio del driver de Linux es posible seleccionar diferentes resoluciones 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 baja iluminación. La duración de su batería es de aproximadamente 4 -5 hs. La señal de video luego de ser procesada por la BeagleBoard, es enviada a un módulo de visualización compuesto por dos display LCD TFT gráficos, con una resolución de 320x240 píxeles (QVGA), un tamaño de 0.24”

(sobre la diagonal), distancia interpupilar de 63.5 mm y tamaño de imagen virtual de aproximadamente 35” a 2 metros de distancia. El consumo de energía del módulo visualizador es menor a 450 mW y puede procesar señales de video tipo NTSC o 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 seleccionado la placa de desarrollo BeagleBoard, la cual es un pequeño y potente ordenador equipado con un procesador OMAP 3 para aplicaciones multimedia, basado en la arquitectura dual core optimizada para sistemas operativos eficientes, como Linux. Posee un núcleo de procesamiento ARM Cortex™ A8 de arquitectura 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 el

módulo de adquisición de video.

87


Se optó por la tecnología ARM principalmente por su rápida puesta en marcha, la posibilidad de utilizar las librerías OpenCV (Open Source Computer Vision Library), el alto grado de conectividad, su portabilidad, la capacidad de cálculo del DSP y la aceleradora de gráficos, entre otras características sobresalientes

III. ARQUITECTURA DE LA SOLUCIÓN DE SOFTWARE

La solución consiste básicamente en una aplicación desarrollada en C y C++, empleando como backend la estructura de datos y los algoritmos de procesamiento propios de OpenCV [3-4], y como frontend una GUI (Graphical User Interface) diseñada en base a librerías Qt [5]. El backend realiza las tareas preliminares de adquisición y adaptación de las 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 de imágenes, captura, procesamiento y visualización de señales de video 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. Fue desarrollada originalmente por Intel para abordar problemas en el área de la visión por computador. Actualmente es un proyecto libre publicado bajo licencia BSD (Berkeley Software Distribution), lo que permite su uso tanto para aplicaciones comerciales como no comerciales.

V4L es una interfaz de kernel para video captura y drivers de 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 anteriores del 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ón de Linux (Angström). A continuación se explicará cada uno de los bloques constitutivo de la plataforma.

A. Sistema Operativo

La distribución seleccionada (Angström) [6] está diseñada específicamente para sistemas embebidos, y el kernel Linux es el 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 para incluir 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 de driver genérico. Dicho driver fue compilado directamente en el nuevo 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 la organización funcional del software implementado. Se pueden observar las funciones principales de adquisición,

procesamiento y visualización de resultados, y la interacción de los 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 la librería auxiliar de OpenCV, highgui [7], que consiste en un toolkit gráfico portable, capaz de trabajar con dispositivos de captura, salida y archivos de video, y provee de herramientas sencillas de GUI (las cuales no son utilizadas en el prototipo, siendo cubiertas por la librería Qt). A continuación transcribiremos algunas líneas del código, donde se pueden apreciar las estructuras de datos y funciones esenciales empleadas para la adquisición de imágenes:

capture = new cv::VideoCapture ( int source ) ;

// Crea un objeto de clase VideoCapture que contendrá los frames y metadata de la imagen a capturar.

if ( !capture->isOpened ( ) ) return;

// Comprueba la correcta inicialización del dispositivo de captura;

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 las siguientes rutinas:

Ajuste de brillo/contraste: se realiza por medio de la función convertScaleAbs, la cual posee una variable alpha que modifica la relación de escala de los valores, y beta, que genera un 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 procedimiento de histéresis de 50, un segundo umbral de 300, una apertura de 3 y sin gradiente L2.

88


Inversión de colores: se aplica la función bitwise_not a cada elemento del miembro data del objeto de clase Mat.

E. Interfaz gráfica

Mediante una interfaz visual amigable, el usuario puede seleccionar diferentes operaciones a realizar sobre la señal de video 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ón del espacio visible debido a que la imagen será destinada finalmente a los displays, y una disrupción excesiva de los controles no es aconsejable. Consiste en un módulo de visualización de resultados/modificación de parámetros por medio de la librería Qt. En el mismo se puede elegir el origen de los datos, los algoritmos a aplicar y el nivel de zoom. En la Fig. 5 se presenta el diseño de la interfaz implementada, pudiendo observarse sus comandos localizados en una barra desplegable.

Figura 5. Prototipo de interfaz visual. Se observa un texto original y el

resultante 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 modifican los valores, adaptados a la operación de un touchscreen. Similar comportamiento posee el control de contraste. También se visualizan los controles de zoom (in y out) que operan sobre el widget por medio de método GraphicsView::scale (razón de aspecto horizontal, razón de aspecto vertical) . Los botones C y V, permiten elegir la fuente de los frames, el primero identifica la 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 la adaptación entre las clase cv::Mat y QImage de Qt, fue necesario realizar un mapeado entre las estructuras de datos raw 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ñales de video en tiempo real y efectuar un realce selectivo de la información visual. Mediante una sencilla interfaz especialmente diseñada, es posible seleccionar diferentes procesamientos digitales que se aplicarán a los respectivos cuadros 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 pacientes con baja visión.

AGRADECIMIENTOS

Los autores agradecen a todos aquellos que hicieron posible la concreción del diseño del primer prototipo de baja visión.

REFERENCIAS

[1] ARM, descripción del procesador Cortex A8 [online] http://www.arm.com/products/processors/cortex-a/cortex-a8.php Fecha de 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 Distribution Embedded 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 de acceso: 15 de Septiembre de 2010.

[8] J. Canny. A Computational Approach to Edge Detection. IEEE Transactions on Pattern Analysis and Machine Intelligence, PAMI-8(6):679–698, November 1986.

89


Protocolosy

Comunicaciones

90


91


Analisis del Desempeno de un Algoritmo deLocalizacion para Redes de Sensores

Silvana 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.Email: [email protected]

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 desempeno 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 depequenos nodos sensores multifuncionales de comunicacioninalambrica; de bajo costo, poca cobertura de sensado ycomunicacion limitada; poca capacidad de procesamiento yalmacenamiento, bajo ancho de banda y bajo consumo deenergıa [1]. Las redes conformadas por dichos nodos, de-nominadas Redes de Sensores Inalambricas (WSN, por sunombre en ingles, Wireless Sensor Networks) ( [2], [3]), sonun paradigma de la medicion distribuida; los nodos colectaninformacion fısica del ambiente y la comunican. La red enconjunto trabaja con un fin determinado; uno de los objetivosmas comunes es la localizacion de una fuente o evento ysu seguimiento ( [4], [5]). Los nodos en aplicaciones delocalizacion y seguimiento requieren, en algunos casos, tratarcon eventos de corta duracion y para ello deben ser capacesde procesar y comunicar la informacion en forma rapidapara lograr el procesamiento colectivo. Un ejemplo es ladeteccion de disparos [6]. Las limitaciones fısicas de losnodos hacen que su capacidad de procesamiento, memoriay comunicacion sean muy restringidas, es por ello que engeneral los nodos realizan tareas simples sin llegar a unresultado, solo a un preprocesamiento de la informacion; lamayor parte del procesamiento se realiza en una computadora.La localizacion presenta modelos no lineales con ruidos dedistribucion aleatoria. El Filtro de Partıculas presenta unaforma simple y efectiva de representar modelos de procesos es-tocasticos y modelos de propagacion arbitrarios con funcionesde distribucion de probabilidad arbitrarias; lo que lo hace laherramienta adecuada para la tarea que se desea abordar. ElFiltro de Partıculas Acotado es una modificacion del Filtrode Partıculas de modo de poder implementarlo sobre un nodo

comercial, cumpliendo con las restricciones que el nodo y lared de sensores presentan; y presentando una solucion a losproblemas que un PF conlleva, como ser el empobrecimientode muestras y la convergencia. El presente trabajo proveeel analisis de un algoritmo para redes de sensores adaptadoespecialmente para su implementacion sobre los nodos de lared. Permite llegar a resultados de localizacion cumpliendocon las restricciones que el sistema (nodo/red) presenta. Elalgoritmo permite realizar una estimacion conjunta, totalmentedescentralizada, de un objeto o evento. Se han explicadola motivacion y las caracterısticas de la aplicacion que sepresentara en el trabajo. En la siguiente seccion se exponela nocion de fusion de datos. En el Capıtulo 3 se presenta unpaneo de filtros no lineales y en el Capıtulo 4 se resume elalgoritmo de Filtro de Partıculas Acotado, las contribucionesque presenta. En el Capıtulo 5 se muestran las aplicacionesimplementadas del Filtro de Partıculas Acotado; un estudioestadıstico para la variacion de parametros de diseno delalgoritmo y se extraen conclusiones respecto a los resultadosobtenidos.

II. FUSION DE DATOS

La fusion de datos pretende, mediante la combinacion deobservaciones de diferentes sensores, potenciar las virtudes decada uno de ellos y minimizar sus posibles desventajas, conel fin de realizar inferencias sobre el mundo exterior; pretendeobtener un mejor resultado a partir de multiples sensoresrealizando inferencias que pueden no ser posibles a partir deuno solo. Existen diversas maneras de realizar la fusion dedatos, dependiendo de la aplicacion y la distribucion de la red.En casos donde se cuenta con un gran numero de sensores ose requiere llegar al resultado en forma rapida es adecuadorealizar la fusion de manera descentralizada ( [7], [8], [9]),fusionar entre nodos vecinos o bien realizar un procesamientoprevio de la informacion adquirida dentro del nodo y luegotransmitir los resultados a un nodo de mayor jerarquıa obien a un nodo central de procesamiento [10]. En generalen localizacion y seguimiento el procesamiento se realiza enlınea (online), al instante, sobre todo en aplicaciones militaresy de seguridad; y requieren algoritmos rapidos y convergentes.En el presente trabajo se presenta un algoritmo de fusion dedatos rapido y convergente con bajo requerimiento de calculo,

92


comunicacion y almacenamiento; aplicado en problemas querequieren una fusion online sobre un esquema distribuido;es decir, la fusion se realiza nodo a nodo y se comunicadirectamente 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 calcularla estimacion del estado de interes, pero ello hace a la redresultante escalable y modular [11]. En aplicaciones reales,las fuentes de ruido tienen distribuciones no Gaussianas, yasumir 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 generalcasi Gaussiana (mientras la informacion de cada nodo nolo es) y luego utilizar un Filtro de Kalman estandar. Otroproblema importante viene relacionado con los modelos nolineales y filtros basados en la linealizacion, como el Filtro deKalman Extendido (EKF); dichos filtros producen resultadoscatastroficos si no se linealiza cerca del punto de operacion[13]. Los Filtros de Partıculas (PF) son herramientas querealizan una estimacion Bayesiana y evitan los problemasdetallados anteriormente; permiten representar modelos deprocesos estocasticos y modelos de propagacion arbitrarioscon funciones de distribucion de probabilidad (pdf) arbitrariasen una manera simple y efectiva. Para lograrlo se utilizanlos Metodos Secuenciales de Monte Carlo ( [15], [12]). Ladensidad de probabilidad es representada por puntos pesados(partıculas) que son posibles estados del proceso, distribuidasen 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 tresoperaciones basicas; generacion de partıculas, calculo del pesode cada partıcula y remuestreo. Las partıculas y su peso sepropagan utilizando el Teorema de Bayes y el concepto de SIR.Para lograr buenas aproximaciones son necesarias muchaspartıculas, lo que implica gran capacidad de computo yalmacenamiento; y en una red de sensores la transmision entrenodos de dicha informacion implicarıa un costo inaceptable enel canal inalambrico. Se han propuesto muchas modificacionesdel PF para adaptarlo a tareas especıficas [15]. El PF Gaus-siano (GPF) [16] aproxima las densidades a posteriori conGaussianas simples ; es un algoritmo util cuando se requieretransmitir mensajes de poca longitud y frecuencia. Cuando unadistribucion Gaussiana no es representativa del estimado, sepuede utilizar una suma de Gaussianas para aproximarlo [17]aumentando los requerimientos de procesamiento. Tambiense han utilizado cajas en lugar de partıculas discretas pararepresentar la estimacion ( [18]), como resultado se debecomunicar menos informacion pero se desperdicia muchainformacion de los sensores debido a que para la generacionde 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 representarfunciones de probabilidad no Gaussianas (pdf), el algoritmoencierra la region de partıculas con alta probabilidad, son laspartıculas previamente seleccionadas debido a que su peso

excede una cota de peso. El desempeno del algoritmo seevalua en aplicaciones de localizacion de objetos en un espaciobidimensional, utilizando sensores de rango. La aproximacionde la estimacion es delimitada por cotas de rango y angulo(coordenadas polares) y se propagan de nodo a nodo. ElBPF cumple potencialmente con el requerimiento de pocacomunicacion, bajo procesamiento de datos y el hecho de queno es necesaria una caracterıstica de pdf a priori.

IV. FILTRO DE PARTICULAS ACOTADO

El Filtro de Partıculas Acotado (BPF, por su sigla eningles Bounded Particle Filter) presentado en [20] comienzaen un nodo lıder con una distribucion de partıculas inicialque se extiende sobre todo el espacio de estados de interes.Luego de una medicion y una actualizacion consistente de laestimacion, se realiza la seleccion de partıculas y se envıan alsiguiente 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 encierranlas partıculas seleccionadas. La seleccion del nodo excede elalcance del trabajo [5]. Cada nodo recibe las cotas y generauna distribucion de partıculas en el area delimitada por lasmismas, donde se realiza la prediccion y la actualizacion.

V. ENSAYOS DEL ALGORITMO IMPLEMENTADO SOBRENODOS

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 unnodo inicial o previo y consiste en la posicion del nodo ycotas de angulo y rango (solo 6 parametros de doble precisiona ser transmitidos entre los nodos en un unico paquete deRF). Una vez que la informacion llega, el nodo comienza supropio procedimiento de estimacion y luego lo comunica alnodo siguiente o a la PC. El procedimiento de estimacioncomienza con una lectura del sensor (observacion, medicion);las partıculas son generadas dentro de las cotas recibidas encoordenadas polares. Cuando una observacion es efectuada, laestimacion de la observacion es calculada sobre cada partıcula;y con ello su peso. Se compara el angulo y rango de laspartıculas cuyos pesos exceden la Cota de Peso (CotaW )con las cotas de rango y angulo iniciales o previas paraactualizarlas 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 aleatoriosen un nodo de capacidad de procesamiento y almacenamientolimitadas. Se implementa un generador de numeros aleatoriosllamado Ran [24] que debio ser modificado en dos formaspara obtener distribuciones totalmente aleatorias. Primero selee el contador del reloj del nodo y se rota para obtener unnumero que no sea monotonamente creciente, dicho numero sesuma a la semilla. En segundo lugar, cada numero generado seutiliza como semilla para la proxima generacion. Para generaruna partıcula se genera un numero aleatorio y se opera paraobtener un numero entre las cotas de rango. Luego para dichorango se genera un nuevo numero aleatorio que es operadopara 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 propiosdel algoritmo. En la Fig. 2 se especifica mas detalladamenteel procedimiento realizado dentro de cada nodo. Ahora unabreve explicacion:• Inicializacion de parametros: Las cotas iniciales (Amin,

Amax, Rmin, Rmax) son inicializadas de manera que laprimer partıcula seleccionada ya las modifique. Comoejemplo podemos citar un Rango Maximo de 0 y unRango Mınimo de 20 metros; para un sensor cuyo alcancees de 10 metros.

• Medicion del sensor: Se simula la lectura de un sensor derango; en otras palabras, se define una posicion fija delsensor y se calcula previamente una observacion de rangocon un ruido gaussiano especıfico; en nuestro caso es de5 cm. la varianza del sensor. Se calculan 1000 valoresdentro de una normal de un rango medio y dicha varianza,y se elije aleatoreamente un valor que sera la lectura delsensor.

• Calculo de la Cota de Peso (CotaW ): Se genera unnumero inicial de partıculas, solo con el objetivo deguardar el peso maximo (Wmax) entre ellas, y se calculacon (1). CotaW se calcula como un porcentaje de dichoWmax. No debe confundirse este numero con el numerode partıculas generadas al inicio del algoritmo BPF.

CotaW =Porcentaje

100Wmax (1)

• Seleccion de partıculas y extraccion de cotas de anguloy rango: Se genera una partıcula, se compara su pesocon CotaW y en caso de superarla, se incrementa uncontador de partıculas seleccionadas (k) y se comparael rango y angulo de dicha partıcula con las cotas derango y angulo para actualizarlas. Se descarta la partıculay se repite el procedimiento en forma serial hasta que elmınimo numero de partıculas sobrevivientes (NroPart) secumple.

B. Ensayos de Simulacion de Red con MICAs.

Los nodos sensores realizaron el procesamiento en el ordeny 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 ordende procesamiento y el valor medido. Para cada ensayo serealizaron 20 corridas del algoritmo BPF sobre las cualesse evaluo el valor medio de la media y la varianza de laspartıculas seleccionadas en la estimacion resultante (en XY), elarea resultante y la media del numero de partıculas generadashasta lograr las 15 partıculas que superen CotaW en cadaestimacion de cada corrida. La idea es variar el numero departıculas generadas con el fin de almacenar el Wmax; y de ahıse elige la cota de peso como un porcentaje del maximo peso.Siempre se almacenan mınimo 15 partıculas. Se realizaronensayos:• Variando las partıculas iniciales: 10, 20, 40, 60, 80 y 100

partıculas sobre las cuales elijo la de peso maximo paraluego calcular CotaW .

• Variando el porcentaje de Wmax que se adopta por cota:40, 60 y 80

Es importante recordar que se denomina “area” al productoentre la diferencia entre las cotas de rango por la diferenciaentre las cotas de angulo de la estimacion resultante; y launidad 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.9983 4 -1 4.1214 -1 3 3.1699

Tabla IUBICACION Y ORDEN DE ESTIMACION DE LOS SENSORES CON EL Nodo1

COMO ORIGEN DE COORDENADAS.

40 60 8002468

10

Áre

a

40 60 8002468

10

40 60 8002468

10

Áre

a

40 60 8002468

10

40 60 8002468

10

%

Áre

a

40 60 8002468

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 10002468

10

40 %

Áre

a

Área resultante en fcn. del Nro. Mín. Part.

10 20 40 60 80 10002468

10

60 %Áre

a

10 20 40 60 80 10002468

10

Número mínimo de part. a conservar

Áre

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ıculascuyo peso supere la cota, se da por terminada la estimacion.Una corrida consta de tres estimaciones consecutivas, en elorden mostrado de los nodos (2-3-4), una estimacion por nodosensor y se transmite. La tercer estimacion consecutiva es laque se denomina “estimacion resultante”. En la Fig. 3 se ve elarea de la estimacion resultante como funcion del porcentajedel Wmax que se toma como CotaW ; como era de esperar,el area se reduce a medida que se aumenta la precision que sele exige al filtro al aumentar CotaW . Arriba sobre la derechase indica el numero de partıculas iniciales. En la Fig. 4 semuestran en forma diferente los mismos resultados que en laFig. 3.

40 60 800

4080

120160200

Nro

. Par

t.

Media del número de partículas generadas en cada corrida

40 60 800

4080

120160200

40 60 800

4080

120160200

Nro

. Par

t.

40 60 800

4080

120160200

40 60 800

4080

120160200

%

Nro

. Par

t.

40 60 800

4080

120160200

%

100 Part

10 Part 20 Part

40 Part 60 Part

80 Part

Fig. 5. Numero medio de partıculas generadas en cada corrida para 40, 60y 80 %.

0 20 40 60 80 100 1200

4080

120160200

Nro

. Par

t.

Nro. medio de part. generadas para una corrida

10 20 40 60 80 1000

4080

120160200

Nro

. Par

t.

10 20 40 60 80 1000

4080

120160200

Nro. mínimo de part. iniciales

Nro

. Par

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 departıculas generadas por corrida en funcion de los porcentajesy del numero de partıculas iniciales. Se puede observar que amedida que aumenta el porcentaje en el calculo de CotaW sereduce el area mas probable, haciendo necesaria la generacionde un mayor numero de partıculas para lograr cumplir con las15 mınimas (dentro de dicha area) requeridas para terminar laestimacion.

En la Fig. 7 se muestra la varianza sobre el eje Y. Se puedeobservar que se reduce notablemente al aumentar el porcentajeen el calculo de la cota de peso. En las Fig. 8 se pueden verlas estimaciones resultantes de las 20 corridas del algoritmopara 80 partıculas iniciales de donde se selecciona el mayorpeso. En el grafico de la izquierda se utiliza una cota de pesodel 40% de Wmax, mientras que en el grafico de la derechase utiliza una cota del 80 % de Wmax. Se ve claramente laforma en que se reduce el area mas probable.

C. Casos Especiales

1) Caso 1: Se realiza una configuracion de red pocoaconsejable, ya que por la ubicacion de los sensores loscırculos estimados no se cortan perpendicularmente en ningunmomento, por estar los sensores alineados. Para este caso se

95


10 20 40 60 80 1000

0.20.40.60.8

1

Var

ianz

a (m

.)

Varianza del eje Y en fcn. del Nro. Mín. Part.

10 20 40 60 80 1000

0.20.40.60.8

1

Var

ianz

a (m

.)

10 20 40 60 80 1000

0.20.40.60.8

1

Nro Mín. Part. a conservar

Var

ianz

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

Eje

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

Eje

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 Wmax

entre los pesos de 80 partıculas inicialmente generadas. Unavez que se encuentran 15 partıculas que superan dicha cota,se extraen las cotas de rango y angulo que las encierran. Enla Tabla II se detalla la ubicacion de los sensores. En la Fig. 9se pueden apreciar las sucesivas estimaciones hasta llegar a laestimacion resultante. Se simbolizan con cırculos los sensoresy con una estrella la fuente, que esta en el origen. Para vercomo actua cada nodo, en la Fig. 10 se ve mas en detalle.En cada cuadro se muestran las particulas generadas dentrode las cotas que pasa el sensor anterior, y en linea llena lasnuevas cotas que encierran las partıculas mas pesadas, lasseleccionadas por tener un peso superior a la cota de peso.

2) Caso 2: En este caso los nodos se encuentran alineadosen una lınea diferente a la de la fuente, a tres metros dedistancia. Es una configuracion mala de la red, ya se veraa continuacion porque. La Fig. 11 muestra una corrida deestimaciones de la red; en cada caso se muestran las partıculasgeneradas dentro de las cotas que se reciben del nodo sensoranterior y el area determinada por la nueva estimacion (lınea

Node X (m.) Y (m.) z (m.)

1 0 0 -2 -4 0 4.04993 -6 0 6.03114 -2 0 1.9474

Tabla IIUBICACION Y ORDEN DE ESTIMACION DE LOS SENSORES CON EL NODO 1

COMO 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 ultimografico muestra las areas de las estimaciones resultantes. LaFig. 12 muestra en detalle las areas de las estimacionesresultantes de una corrida del algoritmo en la red. Los cırculosnegros corresponden a los sensores y la estrella negra ala fuente. La primer estimacion se representa en rojo, lasegunda en azul y la final en verde. Como se puede observar,las areas estimadas no se reducen y no lo haran, debido ala configuracion de la red. En casos como este se puedenimplementar otros metodos para rescatar mas informacion.Como estrategia se podrıa cortar la cota de angulo a lamitad y evaluar las partıculas de cada mitad por separado.Otra forma es seleccionar las partıculas mas pesadas en cadamitad, comparando su peso con una cota que es porcentaje delmaximo peso de cada mitad. Luego de ello se extraen las cotasde angulo y rango dando como resultado lo que se muestra enFig. 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 deconvergencia; tambien evita el procesamiento que implica elremuestreo y aporta una forma de resumir la informacion de laestimacion de modo de transmitir la menor cantidad de datosposible. Se prueba que el algoritmo converge a un estimadorepresentativo 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.)

Wei

ght

−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 trabajose muestran resultados de la implementacion del filtro sobrenodos comerciales, por software, pero debido a la necesidadde reducir la energıa al mınimo, serıa muy interesante laimplementacion del algoritmo en un chip. Se demuestra quelas funciones empleadas son basicas y el almacenamientonecesario mınimo, de modo que no se esta muy lejos de laposible implementacion. Se debe complementar el algoritmocon algoritmos de sincronizacion de la red, de localizacionde los nodos dentro de la misma y de seleccion del nodovecino mas informativo. Es importante estudiar el calculo dela cota de peso basado en las incertidumbres de proceso yobservacion. Tambien se deben analizar las diferentes formasde transmitir mayor informacion del estimado, ademas de lascotas, de modo que la generacion de partıculas iniciales nosea una uniforme, sino que aproxime mejor la curva real deprobabilidad a priori. Se puede extender el algoritmo paradeteccion 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, “Wirelesssensor 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 oftwo 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 SeventhInternational Conference on Information Fusion, 2004.

[12] M. S. Arulampalan, S. Maskell, N. Gordon, and T. Clapp, “A tutorialon 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 ProceedingsRadar, Sonar and Navigation, vol. 146, no. 1, pp. 2–7, 1999.

[16] J. Kotecha and P. Djuric, “Gaussian particle filtering,” IEEE TransactionsOn 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 Robotica, 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 y sus aplicaciones en sistemas embebidos

Esp. Ing. María Fernanda Carignano Especialidad en Sistemas Embebidos Instituto Universitario Aeronáutico

Av. Fuerza Aérea 6500 - (5010) Córdoba [email protected]

Dr. Pablo Ferreyra Posgrado Sistemas Embebidos IUA Universidad 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. INTRODUCCIÓN

La tecnología NFC se basa en RFID (Radio-frequency identification), una tecnología inalámbrica que está en desarrollo desde hace casi cuatro décadas. NFC es una tecnología estandarizada que tiene como propósito ser usada para facilitar la interconexión de dispositivos y el intercambio de datos en un entorno acotado. En conjunto con la creación del estándar NFC, en 2004 surge el NFC Forum que, basándose en dicho estándar, ha creado una serie de protocolos que normalizan la forma en que NFC debe usarse para garantizar la interoperabilidad de dispositivos de distintos fabricantes. Este trabajo presenta un panorama general de diversos aspectos de la tecnología NFC. Se realiza una comparación entre NFC y otras tecnologías inalámbricas, destacando las aplicaciones para las que NFC representa una ventaja. Como último aporte ofrece nociones acerca del desarrollo de aplicaciones Java para dispositivos NFC a nivel software, pero sin involucrarse con las cuestiones relacionadas con 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 y establece una comparación con otras tecnologías relacionadas.

La sección NFC en el mercado de consumo masivo ofrece ejemplos de aplicaciones NFC, dispositivos NFC disponibles comercialmente y un resumen de pruebas piloto que se han desarrollado hasta la actualidad.

La sección Desarrollo de aplicaciones Java para dispositivos NFC describe una aplicación NFC real usando el SDK (Software Development Kit) provisto por Nokia para su teléfono Nokia 6131 NFC.

II. TECNOLOGÍA NFC

A. Orígenes

La tecnología RFID comenzó a esbozarse durante la Segunda Guerra Mundial [1][2]. RFID permite el uso de un objeto (normalmente llamado tag RFID) que se adosa a un producto, animal o persona con el propósito de identificación y seguimiento 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 y otras funciones especializadas; b) una antena para recibir y transmitir la señal. Los tags RFID se pueden clasificar en tres grandes grupos [3]: activos, pasivos y pasivos asistidos por batería.

Una de las tecnologías que se derivan de RFID es NFC, cuya característica principal es el hecho de combinar ambas funciones de tag y reader/writer RFID en un único dispositivo. Dado que NFC es una extensión de RFID, es compatible con toda la infraestructura RFID existente.

B. Características técnicas

NFC es una tecnología de comunicaciones inalámbrica de corto alcance y alta frecuencia que permite el intercambio de datos entre dos dispositivos cercanos. Estos dispositivos reciben el nombre de Iniciator (el que origina la transmisión) y Target (el receptor). NFC funciona en la banda frecuencia no licenciada de 13,56 MHz en una distancia de hasta 20 cm.

NFC está basada en el principio de inducción electromagnética por el cual dos circuitos inductivos cercanos comparten energía con lo cual pueden transmitir datos a distancias de pocos centímetros.

En forma similar a RFID, NFC define dos modos de operación: activo y pasivo.

Dado que NFC es una tecnología derivada de RFID la cual se ha estado usando en múltiples aplicaciones en entornos reales, NFC soporta tasas variables de transferencia para asegurar la interoperabilidad con la infraestructura preexistente. Actualmente ofrece tasas de transferencia de datos de 106, 212 y 424 Kbps, pero se esperan valores más altos en el futuro.

98


C. Seguridad

NFC provee de una seguridad intrínseca dada por el limitado radio de comunicación de unos pocos centímetros. Pero si bien esto dificulta la tarea de "robar" información de ningún modo garantiza que una comunicación NFC no pueda ser vulnerada [4]. Algunas de las amenazas a la seguridad de las 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/ International Electrotechnical Comision), ETSI (European Telecommunications Standards Institute) y ECMA (European Computer Manufacturers Association) [5]. Los estándares [6][7][8] especifican los esquemas de modulación, codificación, velocidad de transferencia y formato de la trama de la interfaz de RF para dispositivos NFC, así como también los esquemas de inicialización y condiciones requeridas para control de colisiones durante la inicialización. También definen el protocolo de transporte, incluyendo métodos de activación del protocolo e intercambio de datos.

Además un conjunto de empresas internacionales líderes en sus rubros consituyó en 2004 el NFC Forum [9], una organización sin fines de lucro cuya misión es fomentar el uso de la tecnología NFC desarrollando especificaciones [10][11][12][13], asegurando la interoperabilidad entre dispositivos y servicios [14][15] y educando al mercado acerca de esta tecnología.

E. Tecnologías relacionadas

La posibilidad de comunicación inalámbrica basada en ondas de RF dio lugar al desarrollo de numerosas tecnologías basadas en el mismo principio físico. En la Tabla 1 se detallan y comparan las tecnologías inalámbricas de comunicaciones que complementan o tienen un ámbito de aplicación equivalente a NFC [10]. La Fig. 1 muestra esta comparación entre tecnologías en forma gráfica dando una vista simplificada de las diferencias entre ellas en cuanto a alcance y velocidad de transmisión.

TABLA I. COMPARACIÓN ENTRE TECNOLOGÍAS INALÁMBRICAS

NFC RFID WiFi Bluetooth ZigBee IrDA

Estándar ISO/IEC 18092

ISO/IEC 14443

IEEE 802.11 IEEE 802.15.1

IEEE 802.15.4

IrDA

Tasa de transferencia

106-424 Kbps

106-424 Kbps

11-200 Mbps 1-480 Mbps 20-250 kbps 1 Kbps – 100 Mbps

Frecuencia de funcionamiento

13,56 MHz 13,56 MHz 2.4, 5.25, 5.6, 5.8 GHz

2.4 GHz 868/915 MHz 2.4 GHz

Cantidad máxima de dispositivos que pueden interactuar

2 2 Indefinida 8 Indefinida 2

Tiempo de inicializació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 la cercanía entre dispositivos

Dada por la cercanía entre dispositivos

Determinada por los mecanismos de encriptación que se usen



Dada por el requerimiento de ambos dispositivos estén en la línea de vista.

Consumo de energía

Mínimo o inexistente

Mínimo o inexistente

Alto para dispositivos alimentados con baterías

Alto para dispositivos alimentados con baterías

Muy bajo Bajo

Objetivo Simplificar la interacción entre dispositivos electrónicos

Realizar seguimiento de objetos y control de acceso

Reemplazar cables en redes extensas, fundamentalmente de tipo LANs

Reemplazar cables para conectar dispositivos electrónicos cercanos

Control y monitoreo inalámbrico

Reemplazar cables para conectar dispositivos electrónicos cercanos

Ejemplo de aplicación

Intercambio de tarjetas personales electrónicas acercando dos teléfonos celulares

Control de inventario en supermercados.

Conexión entre dispositivos de una oficina (PCs, notebooks, impresoras, etc.) dentro de un mismo edificio o entre edificios cercanos

Conexión de periféricos (teclado, mouse, etc.) a una notebook en la misma habitación

Manejo de sistema de riego y fertilización en sembrados usando sensores que de acuerdo a los valores de ciertas variables accionan los mecanismos correspondientes

Transferencia de archivos entre un teléfono celular y una notebook

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 ha dado origen a un completo conjunto de aplicaciones reales que son no sólo técnicamente factibles sino comercialmente viables. NFC ofrece una relación costo-beneficio apropiada para el mercado masivo y cumple con estándares acordados internacionalmente.

El principal atractivo de la tecnología NFC es el permitir variadas formas de comunicación y transacciones de un modo muy 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 un simple interruptor para iluminar una habitación o un picaporte para abrir una puerta. Su uso es casi intuitivo para la mayoría de 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 simple como "tocar" o acercar un dispositivo NFC a otro, se inicie el servicio deseado, permitiendo que el uso de cualquier "servicio" electrónico y otras interacciones sean accesibles a má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 Innovision Research & Technology plc [14]:

• Service initiation: este tipo de aplicaciones consisten en que el usuario toque con su dispositivo NFC (por ejemplo un teléfono) un tag NFC dispuesto a tal efecto en lugares definidos. De esta forma el tag NFC transfiere al dispositivo NFC una pequeña cantidad de datos (texto, URL, número telefónico o cualquier otro dato breve) que le permitirán al usuario realizar alguna acció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 una URL al usuario donde puede obtener más información acerca del producto o servicio publicitado, o bien reservar las entradas para el evento.

o Información adicional sobre productos en un comercio cuando el usuario toca dicho producto con su dispositivo NFC.

o Control de temperatura o iluminación de una habitación sin tener que moverse del lugar donde la persona está sentada (con tags ubicados en muebles que la persona puede tocar con su dispositivo NFC).

o Registro de visitas efectuadas por personal de guardia de un edificio a medida que hace el recorrido de rutina por todas las zonas definidas en el lugar.

o Etiquetas adhesivas con tags NFC de comercialización masiva en las que el usuario 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 de familiares para que una persona con capacidades visuales o de movimiento reducidas pueda llamar a un familiar con sólo acercar su teléfono NFC a la foto correspondiente1. Otro uso de estas etiquetas permitiría que cuando un niño llega a su hogar desde la escuela, toque con su teléfono celular NFC un tag NFC ubicado en la puerta de 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 NFC como mecanismo para establecer la comunicación entre dos dispositivos que necesitan intercambiar datos. Luego el intercambio de datos real puede realizarse usando NFC u otra tecnología inalámbrica que resulte apropiada de acuerdo con el volumen de datos transmitidos. Algunos ejemplos dentro de este grupo de aplicaciones:

o Transmisión de fotos desde una cámara digital a una impresora: mediante NFC se establece una conexión Bluetooth que es la que se usa para transmitir las fotos.

o Intercambio de tarjetas personales a través de una conexión Bluetooth establecida por NFC.

o Configuración automática de una conexión Wi-Fi en lugares públicos: el usuario toca con su teléfono móvil un tag ubicado en la mesa que le transmite la configuración de la red y luego toca su computadora portátil con el teléfono para configurar la red e iniciar la conexión.

• Payment & ticketing: este tipo de aplicaciones es el que 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 transporte sin necesidad de concurrir a un lugar específico para obtener este dato.

o “Billetera electrónica”: la tendencia final es evitar la necesidad de usar tarjetas plásticas para cada uno de los sistemas de fidelización de clientes con puntos, acceso a cobertura de salud, tarjetas de débito y crédito, etc. y poder realizar todas la transacciones comerciales usando el teléfono móvil. De esta forma hasta los pagos mínimos quedarían registrados en un resumen de cuenta facilitando el control de gastos. Un estudio desarrollado por Visa Internacional determinó que el 89% de las personas que han usado teléfonos móviles para realizar transacciones comerciales, prefieren este método sobre otras alternativas de pago.

B. Desarrollo de un caso de uso de NFC: Un día en la vida

de un usuario de NFC

Alicia, usuaria de un teléfono NFC, tiene una entrevista y se traslada desde su casa hasta el lugar en su auto que deja en una playa de estacionamiento. Al ingresar a la playa acerca su

100


teléfono al lector NFC y registra el horario de ingreso. Luego mientras camina hasta el lugar de la reunión ve una publicidad en la calle sobre calzado de la nueva temporada. El cartel incluye el logo de NFC, entonces Alicia se acerca al cartel y con su teléfono obtiene un cupón de descuento para compra del calzado 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 comercial donde lo deja estacionado en un parquímetro. En este caso, también acerca su teléfono al parquímetro, el cual registra los datos de Alicia y la hora de inicio del estacionamiento.

Alicia llega a la zapatería. Allí la mercadería está dispuesta en la vidriera de modo que cualquier cliente con su teléfono NFC pueda leer la información contenida en las etiquetas NFC adheridas al calzado exhibido. Entonces Alicia, sin necesidad de ingresar al local y esperar a un vendedor, averigua los colores, precio y numeración disponible de los modelos que le interesan, acercando su teléfono a la vidriera. En base a esta información decide cuál es el modelo a adquirir, ingresa al local, se lo solicita al vendedor para medirlo y finalmente concreta la compra. Paga usando una tarjeta de crédito de su "billetera electrónica": acerca el teléfono NFC al lector en la caja, elige la tarjeta de crédito y presenta el cupón de descuento, concluyendo la compra. Luego regresa a buscar su auto, 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, cada unidad de producto, incluye en la suela una etiqueta NFC que permite identificar a cada componente del par de zapatos unívocamente. Luego los zapatos se ponen en su correspondiente caja equipada con un lector NFC mediante el cual, si los zapatos colocados dentro de la caja no son los correctos, se genera una señal audible y luminosa ayudando en el guardado de la mercadería en su correspondiente caja.

Las cajas así etiquetadas también facilitan la realización de controles de inventario periódicos en el local comercial mediante el uso de un teléfono NFC que registra la mercadería existente en el depósito y luego la compara con la mercadería efectivamente consignada en el sistema informático.

Si bien toda la tecnología necesaria para implementar este caso de uso está disponible, en un país como Argentina hay cuestiones 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 en general.

• Mucha gente cuando sale de compras no lo hace como una tarea más que tiene que ser rápida y eficiente, sino como un modo de estar en contacto con otra gente y dialogar con los vendedores.

• En las grandes urbes es necesario volver a concientizar a la ciudadanía acerca de la responsabilidad en el cuidado de los bienes públicos.

C. Dispositivos NFC

En la actualidad los principales fabricantes de celulares han desarrollado modelos con soporte para NFC [17] que están disponibles principalmente en Europa y América del Norte.

D. Pruebas piloto

Desde hace unos años se desarrollan pruebas piloto en diversos lugares del mundo con el fin de obtener información para desarrollar servicios basados en NFC acordes a las expectativas de la gente [18]. La mayor parte de las pruebas están relacionadas con aplicaciones de pago en comercios minoristas o compras en expendedoras automáticas. Otro gran porcentaje de pruebas es acerca del uso de smart posters para ofrecer información a los usuarios, publicidad o promociones y descuentos para usar en sus compras en comercios. También se realizaron numerosas pruebas de aplicaciones para compra de pasajes en los medios de transporte público (ómnibus, subterráneos, trenes) y en menor medida aplicaciones para compra 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 dicho hardware deben implementar la JSR-257 [19] cuya estructura de clases, paquetes e interfaces se detalla en la Fig. 2 y permite a 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 todas las clases e interfaces definidas en esta especificación pero no es requerida la implementación de la funcionalidad de todos los targets, aunque si se implementa un target, es requerido que exista el dispositivo físico correspondiente.

La JSR-257 es una especificación de referencia, luego cada fabricante puede implementar los componentes que desee y/o extenderla 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, uno de los dispositivos disponibles comercialmente [22] que provee soporte para NFC mediante la implementación de la especificación JSR-257.

1) Entorno de desarrollo Nokia provee a los desarrolladores un conjunto de

herramientas denominado Nokia 6131 NFC SDK 1.1 que incluye un emulador del teléfono y de las tarjetas y tags NFC.

101


El teléfono Nokia 6131 NFC implementa un subconjunto de la JSR-257, la Tabla 2 detalla el soporte para contactless targets ofrecido por este dispositivo indicando, cuando estén disponibles, los componentes Java que permiten la interacción con estos targets.

Figura 2. Componentes de la JSR-257

2) Caso de uso Permitir 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) javax.microedition.contactless.visual (incluye solamente clases stub para cumplir con la JSR-257)

NFC Forum

Tipo 1 (Innovision Topaz) Tipo 2 (Mifare Ultralight) Tipo 3 (Sony FeliCa) Tipo 4 (Mifare DESFire)

- com.nokia.nfc.nxp.mfstd.* com.sony.felica.Type3TagConnection com.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ón La aplicación de prueba de concepto permite crear tags y

leer su contenido. Está basada en los principios de orientación a objetos [23] y en su arquitectura se aplican tres patrones de diseñ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ón distinguiendo con dos colores las clases propias de la aplicació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 que describe la interacción entre las instancias de las clases (objetos) durante la ejecución de la aplicación.

4) Implementación El 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 la aplicación de prueba de concepto.

1. Registrar un contactless target para que en el momento en que el teléfono detecte la presencia de un tag (NDEF en este caso), notifique a la aplicación a través del método targetDetected():

DiscoveryManager.getInstance().addTargetListener(this,

TargetType.NDEF_TAG);

2. Implementar el listener correspondiente al tipo de eventos que se quieren recibir (TargetListener en este caso). La implementación consiste en abrir una conexión con el target y realizar las operaciones de lectura/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ía que existe desde hace más de tres décadas y que ya se ha impuesto en el mercado: RFID. La ventaja principal de NFC es no ser "una tecnología más" sino generar todo un nuevo modelo de negocio basado en infraestructura existente y ampliamente difundida (lectores de tarjetas en transportes, telefonía pública, etc.) y haciendo uso del dispositivo con más mercado masivo en la última década, el teléfono celular (si bien cualquier otro dispositivo electrónico puede incorporar NFC) [10]. También se la puede ver como una tecnología que trae nuevos usos para artefactos que desde hace tiempo no tienen innovación por ejemplo, carteles, mobiliario, etc. [14].

Goza de cierta difusión en los países más avanzados de Europa, Asia y América del Norte y todas las pruebas que se han realizado en los últimos tres años demuestran el interés de la gente por la tecnología si bien ponen ciertos reparos en las cuestiones de seguridad, fundamentalmente cuando se trata de aplicaciones de pago o consulta de cuentas bancarias.

A pesar de ser una tecnología nueva, ha llegado a un grado de 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 adicional es el relacionado a la seguridad en las transacciones. Este es el aspecto más sensible para el usuario final y de él prácticamente depende 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 con las tarjetas de crédito y débito, y luego la banca electrónica online.

En países en vías de desarrollo como la Argentina, las posibilidades de esta tecnología en el corto plazo son un tanto más acotadas ya que salvo en las principales ciudades, no está generalizado el uso de tarjetas con RFID para pago de servicios, y menos aún, de productos. Por otro lado, las empresas de telefonía locales aún no comercializan productos con NFC. Pero dado el elevado número de celulares de gama media que existen en la población, se puede esperar que en el momento en que la tecnología surja en el país, rápidamente encuentre adeptos como en el resto del mundo. Por lo tanto es un buen nicho de negocio explorar soluciones en este sentido y estar preparados para el momento en que la tecnología comience su incursión en el país.

REFERENCIAS [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 ProtocolTesting: 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, Uruguaye-mail: modin|[email protected]

† Departement Logiciels-ReseauxTELECOM SudParis (ex INT), Evry, France

email: jose.escobedo|ana.cavalli|[email protected]

Abstract—Model-based testing has been successfully appliedto 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 andTCP/IP connectivity allows the access to services through avariety of networking infrastructures. However, TCP/IP wasdeveloped for wired networks and devices with sufficientresources (bandwidth, energy, etc) such as servers or desktopcomputers. A popular approach to improve the performanceof TCP/IP over wireless mediums are cross-layer protocoloptimizations.

As a part of the SCAN [1] project a system was requiredto add cross-layer protocol optimizations to devices with con-strained resources, such as embedded devices, while requiringminimum or no modification to the network protocol stack.Due to the intricacy of network protocols and the particularchallenges of cross-layer design (high coupling, interactionamong optimizations, etc), cost effective validation techniquesand tools were required.

Model-based testing [2], [3] has been successfully appliedto conformance testing of reactive systems such as networkprotocols. However, time and human resources required mayturn this approach inefficient. In this paper is described howmodel-based testing was applied to cross-layer protocol op-timization in order to determine if it is a suitable and costeffective methodology for the problem domain.

A prototype with a simple optimization protocol [4] wasimplemented. 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 andtesting techniques were conducted to validate the system. Itsspecification was modeled in SDL [6] and test cases weresemi-automatically derived from the model. An ad-hoc testingautomation tool was built to run the test suite against theprototype.

A full iteration -from concept phase to execution andvalidation- was accomplished within a tight schedule and withscarce resources. The time devoted to this iteration comprisedthe time to study tools and modeling language, to model thespecification of the system, to build an implementation and totest it.

The rest of this paper is organized as follows: in section IIthe 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-layeroptimization protocol and its implementation are presented anddiscussed. In part IV the model of the system specification isbriefly described, an explanation on how it was used to validateand test the prototype is given, and the results in terms of costare summarized. In part V conclusions are presented.

II. METHODOLOGY

Layered architecture, such the ISO OSI [7] model, dividesnetworking 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 layerprovides services to the layer above and consumes servicesfrom the layer below through well defined interfaces. Thelayered architecture promotes the isolation among layers, andthis modularity makes possible to replace implementations ateach layer while maintaining the interfaces. TCP/IP protocolstack 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, higherlayers may benefit from information from lower layers andvice versa.

Methodological grounds for this work are sketched in therest 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 andanother layer that can use this information to operate moreefficiently. An example of cross-layer optimization is flowcontrol among MAC and transport layers [8].

Although cross-layer design have proven a popular approachto improve performance on wireless networks, there is a tradeoff between modular architecture and optimizations. There arevarious cross-layer architectures proposed in the literature thatcould help alleviate these problems, such as PMI [9], ICMPbased [10], CLASS [11], CrossTalk [12], MobileMan [13],ECLAIR [5]. Each architecture proposes a different approachfor signaling among layers, such as adding extra informationat 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 networkprotocol stack), minimum stack overhead, extensibility, re-versibility, portability and efficiency. Furthermore, details werepublicly 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 tobe isolated from the actual protocol.

Inter layer feedback is achieved through notifications ofchanges in protocol stack data structures. The optimization ofthe protocol stack behavior is achieved through changes of thenetwork parameters through an API presented by the tuningsubsystem, plus the algorithms in the optimization modules.

There are some limitations to the scope of this architecture.Only asynchronous event detection is addressed through eithernotifier chains or by polling the desired data structure with apre-established frequency. Explicit synchronization of the net-work protocol stack and the optimizations protocols behavioris not addressed, which can lead to loops. Integrity of the datastructures when concurrently accessed by the protocol stackand the optimization protocol is not addressed.

B. Validation and Model-Based Testing

As the terminology on validation, verification and testingis not always consistent in the literature, the meaning ofthese concepts in the context of this paper are presentedhere. To validate a system is to provide information thatincreases the confidence in the hypothesis that the system wasbuilt correctly. The most popular approaches for validationare verification and testing. Verification is to interact withthe model of a system (using the model for simulations ormathematically prove properties of the model), and testing isto perform experiments on an implementation of the systemtrying to find defects.

It has been stated [14] that 50% of the defects are introducedin the coding phase of a software developing process, and only15% are detected in design phase. Most defects are foundduring testing. The cost of correcting a defect is higher thelater it is found. A consequence of this is that while it isimportant 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 thatmost defects are found so both approaches are convenient andcomplementary.

For this reason model-based testing paradigm was chosen.The goal of model-based testing is to reduce costs whiledeveloping quality software by automating the testing processas much as possible, in particular automating the test casegeneration. In order to do so, a formal model of the systemspecification is built and used to derive the test cases. Thisformal model is developed in parallel to the implementationof 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 isbehind well known automated test case generation tools suchas TGV [16], [17] and TorX [18]. The theory states that it ispossible to establish the existence of a mathematical relation(namely, ioco) between a formal model (the model of thespecification) and an implicit model corresponding to an actualimplementation by probing the implementation. In practice, toprove conformance that way is not possible because any nontrivial system would require a test suite too huge to maketesting impractical. A compromise is achieved by restrictingtest case generation to certain parts/behaviors of the modelspecified as test purposes.

The formal model is built in any of multiple formal spec-ification languages such as SDL, LOTOS, IF, IOLTS, etc. Ingeneral the model used for test case generation differs fromthe model used for designing the system in that the first isused to capture the behavior of the system while the later isused to capture the structure of the system. It also differs inthe abstraction level, since the model used for test generationcan ommit many details. Therefore, the model and the systemcan be built independently and simultaneously, and test casescan be obtained even before the system had been finished,shortening the time required for testing.

Maturity in modeling for design is not required, actually theimplementation could be developed from an informal speci-fication of the requirements. However, it makes more senseto use model-based testing when the software developmentprocess has already automated the test execution.

SDL [6] was chosen as the modeling language for the modelof the system specification. SDL is known for its success inthe telecommunications and protocol design domain [19] [20],as well as for the availability of tools to build models in thatlanguage.

III. PROTOTYPE

In this section the cross-layer optimization protocol and itsimplementation 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 architectureproposal. Although a detailed description is beyond the scopeof this work, a brief explanation follows.

The selected use case consists in setting priorities for TCPconnections that in turn determine the size of the receiverannounced window in each connection, thus acceleratingor slowing the sender, redistributing the throughput accord-ing to the priorities. It is based on the following relation:Throughput = RCV Window

RTT . The receiver window is aparameter included in the TCP header which is adjusteddepending the use of the receptor buffer to prevent the loss ofpackets.

While in theory this approach may seem valid, in practicethere are some flaws. The size of the receiver announcedwindows represents the memory available for that connection,but memory is not taken into account when setting the size ofthe new announced window.

When the size of the received segments is too small (forinstance, interactive sessions) it is not a good idea to rise thesize of the announced window because it would be filling thebuffers 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 befilled 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 WindowRTT does not contem-

plate the probability of packets loss, which is not negligiblein 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 layerand its feedback is valuable as context information. Whilein this case priorities are set by a person, they could alsobe set automatically according to access policies for eachuser and/or application. The user layer and the interactionwith the transport layer simplifies the complexity of propersynchronization and monitoring of the network protocol datastructures.

B. Implementation

An implementation of this use case is reported to existfor Linux 2.4.x, however it was not available and was notused in this work. Furthermore, there are many differencesfrom GNU/Linux Kernels 2.4.x to 2.6.30 which was the latestKernel 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 linetool) to set the priorities for the connections. On the otherhand, there is a Kernel module (implemented as a devicedriver), which can directly access and modify the Kerneldata structure. It allows real time, user driven recalculationof the window size and modification the rcv ssthresh and

window clamp parameters for the connections. Note that perflow optimization did not allowed the use of /proc/net withoutmodifying the Kernel, and such modifications would affect theoverall performance of the system.

The prototype was implemented on archlinux over Vir-tualBox, with GNU/Linux Kernel 2.6.30, and was compiledwith GCC 4.4.5. Cscope was used to analyze the Kernelcode. The implementation is generic enough so that it can bereused and expanded with other optimizations, and can easilybe ported to embedded systems.

In the network protocol stack of the GNU/Linux Kernelthere is a hash table accessible through the inet lookupfunction. inet lookup receives local and remote IP and portand returns a pointer to a sock, which is used to accessthe aforementioned parameters. This data structure and thefunctions in Kernel 2.4 (the Kernel version for which theuse case was originally implemented) differs from the onesin GNU/Linux Kernel 2.6 (the Kernel version for which wedeveloped our prototype). In Figure 1 is shown how theinet lookup is used. While future releases of the operatingsystem might result in modifications to the tunning layer, theoptimization subsystem and the optimization protocol itselfwill remain unchanged. This is a strong point of the ECLAIRarchitecture.

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

elsereturn(1);

Fig. 1. Setting the new receiver windows

While some experiments were conducted with the prototype,further experimentation is needed to establish its behavior invarious real world scenarios. Since the use case was shown tohave some flaws, other more realistic cross-layer optimizationprotocols should be implemented and tested.

Future work will include porting the system to otherplaftorms such as OpenWRT and Android, and developing aSNMP interface to explore the possibilities of global cross-layer optimizations.

106


IV. TESTING

In this section the model of the system specification isbriefly described, an explanation on how it was used to validateand test the prototype is given, and the results in terms of costare 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. Itsyntactically conforms the SDL-92 standard. A diagram inSDL can be seen in Figure 2

After the model was obtained, simulations were done inorder to gain confidence in the model. Further simulationswere conducted for the test purposes in order to generate testcases.

The system is composed of two blocks, a TL or TuningLayer block for interacting with the protocol stack, and a OSSor Optimizing Subsystem that encompasses the PO or protocoloptimizers. Inside the TL there are two process correspondingto the UTL or User Tuning Layer, and to the TCPTL orTCP Tuning Layer. Inside the OSS there is the RCWPOprocess, the receiver window protocol optimizer; here residesthe optimization logic.

The UTL receives signals indicating priority change inconnections and notifies the RCWPO. The RCWPO processreceives signals that indicate a priority change has occurred,end emits signals for the TCPTL indicating that the windowsize must be changed and its new value. The TCPTL receivessignals from the RCWPO and emits signals to the Kernel tochange 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 testcases were generated.

The MSC test cases were used as input to the tester and aspart of the oracle to establish verdict of the tests. An exampleis shown in Figure 3

The input and outputs of the systems were modeled assignals as usual in SDL, and mapped to concrete inputs andoutputs such as function invocations.This mapping was usedto 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 theinterfaces of the IUT with the tester, which can be PO (Pointof Observation, not to be confused with Protocol Optimizersfrom 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 areemployed for registering the outputs) and the MTC which runsin user space, runs the test suites and emits the verdict. TheIUT 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 includesthe Kernel module (comprising the RCWPO and TCPTL) andthe user space application for setting priorities (namely, theUTL).

set_app_pty FROM MTC, TO UTL(request the UTL to change the priorityof 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 anestablished connection)

read_rcv_wnd_value FROM Kernel TO TCP_TLlock_socket FROM TCP_TL TO Kernelset_wnd_clamp FROM TCP_TL TO Kernelset_rcv_wnd FROM TCP_TL TO Kernelrelease_socket FROM TCP_TL TO Kernel

Fig. 6. Signals exchanged at the PO

There are two interfaces between the tester and the IUT, onePCO 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 inKernel space when values of rcv ssthresh and window clampare set.

The signals exchanged at the PCO are listed in Figure 5,while the signals exchanged at the PO are presented inFigure 6.

These signals are used at the abstraction level of the model.For running the test suite, the signals are mapped to concreteoperations, such as can be seen in the following examples:

The signal set app pty is mapped to

./userTL host_local port_localhost_remote port_remote 2 2

userTL is a comand line utility to pass information to theUTL. 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 relevantparameters it receives are the local and remote IP and port,represented in network byte order by unsigned integers of 32and 16 bits respectively, and a pointer to the ’hash info’ Kerneldata 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 asthe Main Test Component. It is a bash shell script that parsesan input file and executes the input. When there are no moreinputs to process, it parses an output file where the systemtraces were recorded in order to establish a verdict. At thetime of the test, only the type of the signals and the datatypes (not values) were considered for verdict.

Note that the Kernel is part of the tester, for it receivesthe output of the system. This presents some challenges forcapturing and logging the output.

Since the receiver window is included in the TCP header, asimple solution would have been to capture the TCP packetsby means of Wireshark or a similar tool. However, this solutiondoes not account for the window clamp parameter. And,

formally, the TCP packets are not the output of the modeledsystem.

In spite of the black box testing approach, the IUT wascoded in a way that it wrote the outputs in the system logby means of the printk() function. A more appropriatesolution would have been to intercept system calls and adda tracing facility before executing the actual code of thefunction.

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 addresseswhere the data structure are stored.

These approaches have considerable potential but to keepon 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 automaticgeneration of test cases and a general framework for testexecution.

For the general framework for test execution, TTCN-3 isthe standard of the industry. TTCN-3[24][25] is the test-ing language promoted by the European TelecommunicationsStandards Institute (ETSI) which was designed for any kindof testing activity.

There are commercial tools that generate test cases frommodels in SDL and MSC which can be converted to ATS inTTCN-3. These tools can be used to fully automate the testcase 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 fortest case generation. Verilog extended OBJECTGeode withTestComposer. Verilog was acquired by Telelogic, which inturn was acquired by IBM [28].

E. Results

A two people team was assembled for the project, with noprior knowledge of modeling tools nor the modeling languageand only minor knowledge on the problem domain. Thus thetime devoted to learning is included in the cost of the project.

An iterative incremental software development process wasfollowed. In week 1, the specification of the system was

108


given. In weeks 2 and 3 the modeling language (SDL) forthe formal specification was studied and the model of thesystem specification in SDL was produced. In week 3 the testcases were obtained from the model. In weeks 3 and 4 theprototype was implemented. In week 5 a test automation toolwas implemented, and the prototype was tested. The projectwas 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 modulehas 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 introducedcross-layer optimizations in devices with constrained resourceswas implemented. The chosen architecture was validated, aswell as the model-based testing methodology, a formal modelwas obtained and used to derive test cases. The work startedwith the model, followed with the implementation and finishedwith an operational prototype that was tested.

Model-based testing approach, even without the fully au-tomation of the test case generation proved a cost effectivetesting methodology even in a scarce resources situation,consisting of a two people team and a reduced time frame.

The applied methodology does not require sophisticatedsoftware developing processes, even though it can benefit fromthem in larger projects.

The need for an appropriate framework for test executionbecame 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 builtaccording to the ECLAIR architecture and was successfullytested and validated. Therefore, the methodology, tools andmodeling techniques were appropriate to the problem domain.

To our knowledge the prototype was the first use of the usecase and architecture for recent versions of the GNU/LinuxKernel. The work took place on a virtualized environmentfor practical reasons. Despite of that, is directly applicable tohardware implementations of corresponding embedded devicesimplementing GNU/Linux.

The model itself can be reused to include further optimiza-tions or required refinements to the current, and to derive moretest cases.

ACKNOWLEDGMENT

The authors would like to thank Eduardo Grampın whomade this project possible. We would also like to thank PatrickSenac 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 (WOWMOM2008), Newport Beach CA, USA, Jun. 2008, pp. 23–26.

[9] J. Inouye, J. Binkley, and J. Walpole, “Dynamic network reconfigurationsupport for mobile computers,” in Proceedings of the 3rd annualACM/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-generationwireless 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 Toolsfor 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: TheArt 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ásicostanto 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 alumnosdefinir 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 aalumnos 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 ypor 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 traba-jos 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 sobrela 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 interactuarcon 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 oGoGoBoard. 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 altonivel 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 latenciasvinculadas 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 deLua, 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 kernelLinux 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 quepueda 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 USBo 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 deimplementación es el que podemos ver en el Cuadro I

Cuadro IESPECIFICACIONES DEL ROBOT BUTIÁ.

Elemento InstanciaMotores Dynamixel AX12

Control 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 usuarioen 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 microcontroladoresLPC2000 de aplicacion en robotica

Gonzalo F. Perez Paina, David A. Gaydou, Nestor L. Palomeque, Lucas A. MartiniCentro de Investigacion en Informatica para la Ingenierıa, C.I.I.I.

Universidad Tecnologica Nacional, Facultad Regional Cordoba, UTN-FRCEmail: [email protected]

Abstract—En el presente trabajo se describe el desarrollo delibrer ıas embebidas para microcontroladores NXP con nucleoARM7. Las mismas se dividen en Modulos de perifericos yModulos de software que implementan algoritmos especıficos. LosModulos perifericos permiten la abstraccion del modelo particu-lar de microcontrolador para acceder mediante funciones de altonivel 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 senales de encodersopticos 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. Suutilizaci on muestra ser lo suficientemente flexibles para agilizarel diseno, desarrollo y prueba de aplicaciones embebidas.

I. I NTRODUCTION

Para el desarrollo de software de sistemas embebidos esde principal importancia contar con herramientas flexibles,que brinden la posibilidad de realizar modificaciones a laaplicacion con un mınimo esfuerzo. Esto permite elegir lamejor implementacion en sistemas donde se requiere maximaconfiabilidad y desempeno. Una de las necesidades fundamen-tales para el desarrollo de software embebido es poder contarcon librerıas tanto para los perifericos particulares de la familiade microcontroladores utilizada, ası como de algoritmos de usocomun 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 marcode diferentes proyectos de investigacion, principalmente enel area de robotica, sensorıstica y control. Una evolucionnatural en el desarrollo de dichos sistemas fue comenzar autilizar microcontroladores de 32 bits, que permitan desarrollarprogramas capaces de realizar cierta cantidad de calculosen tiempos razonables para dichas aplicaciones. Una de lasprimeras incursiones en este tipo microcontroladores se realizautilizando arquitectura de nucleo ARM7, mas precisamente losde la familia LPC21XX [1] de la marca NXP.

En el presente trabajo se describe el desarrollo de librerıaspara sistemas embebidos, las cuales han sido pensadas prin-cipalmente para cubrir los requerimientos del laboratoriodelC.I.I.I., enareas de aplicacion particular. Estas librerıas, comose comentara mas adelante, se dividen en una parte para elmanejo de hardware y otra de algoritmos particulares de gran

utilidad en los proyectos del Centro. Como principal objetivoen su desarrollo se tiene la abstraccion del hardware y se haprestado principal atencion en el modo que se articulan losdiferentes Modulos (de hardware y algoritmos) para que resul-ten flexibles, facil de mantener y modificar, lo que promuevanla reutilizacion de software.

La seccion II presenta una descripcion general de losdiferentes Modulos de software de las librerıas ciiiemblibs ysu relacion. La seccion III presenta los modulos perifericoso de manejo de hardware en detalle, y la IV los modulos endesarrollo. La seccion V describe los modulos especiales o dealgoritmos, junto con su relacion con los Modulos perifericos.En la seccion VI se muestra un caso de aplicacion en lautilizacion de las librerıas. Y por ultimo en la seccion VIIse presentan las conclusiones del trabajo.

II. D ESCRIPCION GENERAL

Las librerıas embebidas denominadasciiiemblibs por sudesarrollo dentro del Centro de Investigacion en Informaticapara la Ingenierıa, se encuentran divididas en dos gruposprincipales: por un lado los modulos para perifericos, cuyo

Fig. 1. Organizacion y relacion de los diferentes modulos de las librerıas

116


objetivo es controlar los dispositivos particulares de losmi-crocontroladores LPC21XX y por otro lado los modulosespeciales, que cumplen funcionalidades particulares e inde-pendiente del modelo de microcontrolador utilizado, pudiendoser compilados para otras arquitecturas. Una representacionesquematica 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 elencargado de comandar los puertos de salidas y entradasdigitales.

• Modulo para temporizadores o TIMER, maneja los tem-porizadores y la funcionalidad capture.

• Modulo para comunicacion serial o UART, trabaja con elpuerto serial del microcontrolador.

• Modulo para el manejo de interrupciones o IRQ, seencarga de comandar las interrupciones vectorizadas.

• Modulo para el manejo del modulador de ancho de pulsoo 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 encargade la escritura de datos en memoria no volatil.

En cuanto a los Modulos especiales o de algoritmos ten-emos:

• Modulo de comunicacion mediante datos empaquetadoso COMMUNICATION, es un protocolo de comunicacionentre dos dispositivos.

• Modulo para el manejo de encoders o ENCODER, parala decodificacion de encodersopticos 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 unode los Modulos perifericos o especiales indicados anterior-mente. Cada una de las funciones de los diferentes moduloscomienza con el nombre del Modulo para poder identificara que modulo pertenece la funcion, por ej. las funciones deinicializacion de algunos de los Modulos son: para el ModuloGPIOgpio_init(), para el Modulo PWMpwm_init(),para el Modulo de comunicacion com_init(). Ademas, laslibrerıas incluyen ejemplos de utilizacion de cada uno de losModulos que soporta.

III. M ODULOS PARA PERIFERICOS

Estos modulos se desarrollaron para un manejo sim-ple y transparente de los perifericos del microcontroladorLPC21XX. En las subsecciones siguientes se describen losmodulos perifericos aplicados especıficamente al microcon-trolador modelo LPC2114/24.

A. Modulo para entrada-salida

El microcontrolador NXP LPC2114/24 posee dos puertosde proposito general: Port0 y Port1, de los cuales el primerodispone 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 perifericosdel 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 siglasen ingles), se configura si el pin se va a utilizar como unaentrada o como una salida digital; en el caso de un pin deentrada digital el Modulo permite leer su estado, y en el casode un pin de salida el Modulo permite establecer un estadologico (alto o bajo) a la salida del pin.

Algunas de las funciones del modulo songpio_init(),gpio_set() y gpio_toggle().

B. Modulo para temporizadores

El microcontrolador NXP LPC2114/24 posee dos tempo-rizadores o Timers. Estos temporizadores son independientese identicos, ademas cada Timer dispone de hasta 4 canalesde captura que permiten almacenar, en un registro dedicadoa esto, el valor del Timer Counter cuando se produce unatransicion en la senal de entrada de estos canales. Tanto elPrescaler, como el Timer Counter y los Registros de Capturason de 32 bits.

Este Modulo software permite configurar y controlar ambosTimers del microcontrolador. La codificacion de la misma secentra principalmente en el modo de cuenta de intervalos detiempo entre eventos. En esta librerıa tambien se encuentracodificado el modo particular Capture.

Algunas de las funciones del modulo sontimer_init(),timer_get(), timer_enable_interrupt(),timer_disable_interrupt().

C. Modulo para comunicacion serial

El microcontrolador NXP LPC2114/24 posee dos UART(Universal Asynchronous Receiver-Transmitter). La UART0permite una configuracion internaunica 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 cualse puede hacer uso.

El Modulo software correspondiente permite configurar laUART0 y UART1 del microcontrolador, no obstante, en estainstancia solo esta desarrollado el empleo en configuracion“Null Modem” para ambas UARTs.

Este Modulo posee un conjuntos de funciones que permitenconfigurar la frecuencia (Baud Rate) de la comunicacion, lacantidad de bytes a transmitir, el tipo de paridad, la cantidadde bits de stop y el tamano de memorias intermedias (FIFO).Tambien implementa rutinas que permiten la trasmision y larecepcion de datos, ademas de controlar las distintas fuentesde interrupciones, haciendo uso del Modulo de software IRQpara el manejo de interrupciones para la configuracion delas mismas. Posee una implementacion por callbacks parala atencion de las posibles fuentes de interrupciones, lo quefacilita la tarea del programador.

117


Fig. 2. Modos de funcionamiento del PWM

Algunas de las funciones del modulo sonuart_init(),uart_set_baudrate(), uart_send_byte(),uart_receive_byte().

D. Modulo para el manejo de interrupciones

El Controlador Vectorizado de Interrupciones (o VIC porsus siglas en ingles) del microcontrolador LPC2114/24, poseetreinta y dos entradas y solicitud de interrupcion programableen tres categorıas nombradas a continuacion en orden deprioridad: FIQ (Fast Interrupt reQuest), IRQ vectorizada,yIRQ no vectorizada.

La librerıa desarrollada configura las interrupciones IRQvectorizadas. Actualmente no opera sobre las interrupcionesFIQ e interrupciones IRQ no vectorizadas. Las interrupcionesvectorizadas 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 posiblesfuentes de interrupcion. La mayor prioridad de este vectorcomienza con el primer elemento.

Algunas de las funciones del modulo sonirq_vect_init(), irq_vect_enable(),irq_vect_disable().

E. Modulo para el manejo del modulador de ancho de pulsos

El Modulo periferico PWM del microcontroladorLPC2114/24 posee dos modos de funcionamiento: simpleflanco, en el cual solo se puede controlar el flanco de bajaday doble flanco, que permite controlar tanto el flanco desubida como el de bajada, como se indica en la la Fig. 2.Las funcionalidades del microcontrolador permiten hasta seissalidas de simple flanco, tres salidas de doble flanco, o unacombinacion de ambos tipos.

Este Modulo actualmente se centra en el modo de fun-cionamiento de simple flanco de los seis PWM disponibles enel microcontrolador. Las funciones de este Modulo permitenconfigurar la frecuencia de la senal de PWM, y en cualquierinstante poder modificar el “ciclo de trabajo” o conocer elvalor del “ciclo de trabajo” actual.

Algunas de las funciones del modulo sonpwm_set_on(),pwm_set_off(), pwm_set_value().

IV. M ODULOS PARA PERIFERICOS EN DESARROLLO

Estos Modulos se encuentran en etapa de desarrollo por loque se presentan aquı, a modo explicativo, la funcionalidadque tendran una vez finalizados.

A. Modulo In-Application Programming (IAP)

Esta librerıa se desarrolla con la intencion de poder al-macenar datos sobre la memoria flash del microcontroladorLPC2114/24. En la actualidad se encuentran completamentecodificadas y se encuentra en etapa de evaluacion para seragregadas a la librerıa.

B. Modulo para la conversion analogico-digital

Este Modulo permite realizar la conversion de senalesanalogica a digital para aplicaciones de adquisicion de datos.Actualmente las funciones en desarrollo permiten obtenervalores del conversor a requerimiento de la aplicacion. Seplanea agregar las funciones necesarias para los diferentesmodos de funcionamiento del Modulo periferico ADC.

V. M ODULOS ESPECIALES

Los Modulos especiales implementan algoritmos de utilidaden diversas aplicaciones de sistemas embebidos. Algunos deestos Modulos hacen uso de los Modulos perifericos pero sonindependientes de los mismos.

A. Modulo de comunicacion mediante datos empaquetados

Permite la transferencia de datos entre dos dispositivoscuyas velocidades de procesamiento son muy diferentes,como ser una aplicacion en una PC y la aplicacion embebida.La implementacion provee rutinas para lectura y escriturade datos en forma de paquetes, por parte de la aplicacionprincipal. Tambien hace uso de callbacks correspondientes aldispositivo fısico o logico utilizado en el otro extremo de laconexion de la librerıa. A los datos enviados a la interfaz desalida, el Modulo agrega caracteres de inicio y tamano delpaquete como parte del protocolo. En la Fig. 3 se puede vercomo se conforma un paquete.

La operacion de la transmision y recepcion emplea lamecanica de productor-consumidor, actuando sobre un buffercircular intermedio implementado en el Modulo y coordinadoa traves de una variable protegida incrementada por el produc-tor y decrementada por el consumidor. En terminos generalesla rutina del productor carga los caracteres secuencialmente enel buffer interno, arma los paquetes, chequea los desbordes,controla la circularidad e incrementa la cuenta de paquetes(variable compartida). La rutina del consumidor extrae loscaracteres 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 soncom_init(),com_send_packet(), com_receive_packet().

118


Fig. 4. Robot Movil de Arquitectura Abierta, RoMAA

B. Modulo para el manejo de encoders

Un encoderoptico incremental es un sensor que permitedetectar el movimiento de rotacion de un eje a traves de sussalidas correspondientes a dos senales llamadas Fase A y FaseB, las cuales son trenes de pulsos desfasadas 90o.

El objetivo de esta librerıa consiste en crear un modulofuncional para la lectura de este tipo de sensores. Este Modulopermite decodificar las senales del encoder [2] y ası poderdeterminar el sentido de avance y la cantidad absoluta depulsos del eje del cual se quiere controlar la rotacion.

Algunas de las funciones del modulo sonencoder_init(), encoder_update().

C. Modulo software CONTROLADORES

Actualmente este Modulo implementa un controlador PID[3] (Proporcional Integrativo Derivativo) que permite ajustarlos valores de desempeno de un sistema de lazo cerrado a lasnecesidades de la aplicacion. Este Modulo realiza los calculosen base a la implementacion en tiempo discreto de la ec. (1):

Rn = Rn−1 + KP (en − en−1)

+ KI

(en + en−1

2

)(1)

+ KD(en − 2en−1 + en−2)

dondeKP , KI y KD son las constantes proporcional, integraly derivativa respectivamente,Rn es la salida actual,Rn−1 esla salida anterior yen es el error actual.

Algunas de las funciones del modulo sonpid_init(),pid_update().

VI. EJEMPLO DE APLICACION

La totalidad de los Modulos explicados anteriormente estansiendo utilizados en diferentes proyectos dentro del Centrode Investigacion en Informatica para la Ingenierıa, pero cabemencionar 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 laFig. 4. El sistema de control embebido, mostrado en la Fig.5, del robot movil RoMAA se basa en un microcontroladorLPC2124, para cuyo desarrollo se utilizaron en su totalidadlas librerıas del presente trabajo.

El sistema de traccion se basa en motores de corrientecontinua alimentados mediantes drivers de potencia de llave H,comandados desde senales de PWM utilizado con el Modulocorrespondiente. Para el control de velocidad de dichos mo-tores se utiliza un lazo de control a partir de mediciones deencodersopticos incrementales acoplados mecanicamente alos motores; la medicion de velocidad se realiza mediante lafuncion de Capture del Timer del microcontrolador, con elmodulo adecuado, ademas de la librerıa de encoders, paratener un registro de los pulsos y sentido de giro de losmotores. Esta informacion se integra luego en lo que seconoce como odometrıa [5]. El sistema de control incluyetambien un lazo externo en configuracion cross-coupling paraobtener trayectorias en lınea recta o arcos, y poder comandar alvehıculo con velocidad lineal y angular. Los comandos hacia elcontrolador e informacion del mismo se obtienen desde la PCa bordo del robot, mediante la comunicacion serie utilizandola librerıa UART y COMMUNICATION, la cual se encargadel protocolo de comunicacion.

Ademas, se hace uso del resto de las librerıas, como GPIOpara 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 quese abastece el robot RoMAA y poder ası tener un controldel posible estado inoperante del mismo, surge el desarrolloactual, de la librerıa ADC. De manera similar surge la librerıaIAP, para poder almacenar datos, como las constantes del PID,en memoria no volatil.

119


VII. C ONCLUSIONES

Las librerıas embebidasciiiemblibs estan siendo uti-lizadas actualmente en diferentes proyectos del laboratorio deelectronica del C.I.I.I., relacionados a robotica, sensorıstica ycontrol. La utilizacion de las mismas muestra que cumplencon el objetivo planteado al inicio del proyecto.

Por un lado la utilizacion de los Modulos perifericos facilitala implementacion de nuevas aplicaciones mediante la ab-straccion del hardware, lo que reduce la necesidad de consultarconstantemente el manual del microcontrolador, para el casode los modulos perifericos. Y por otro lado, los Modulos desoftware o algoritmos permiten flexibilidad en las etapas depruebas al inicio de los proyectos, como por ejemplo la librerıade comunicacion que es de gran utilidad en la depuracionde aplicaciones. Ademas, las librerıas de Modulo softwarepueden 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 evaluacionnecesarias 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. InProceedings of the VArgentine 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 actitudaplicado 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 [email protected]

Resumen—Se presentan los resultados del diseno 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 gir oscopo de tecnologıa MEMS, y luego fusionando lasmediciones de ambos sensores mediante un filtro complementario.

Index Terms—Cuadricoptero, Giroscopo, Acelerometro, Filtrocomplementario.

I. I NTRODUCCION

A continuacion se presenta un sistema para estimacion deactitud de un robot volador autonomo (UAV, Unmanned AerialVehicle) de cuatro rotores capaz de despegar verticalmenteyrealizar vuelos estacionarios que esta siendo desarrollado enel Centro de Investigaciones en Informatica para la Ingenierıa(C.I.I.I.) en la Facultad Regional Cordoba de la UniversidadTecnologica Nacional. Este robot esta disenado para ambi-entes interiores como ası tambien exteriores con condicionesatmosfericas limitadas. Se preve una cargautil de 1 Kg. Elsistema de control de estabilidad esta implementado en unmicrocontrolador LPC2114 de NXP. Este controlador constade dos lazos anidados, el lazo interno controla la actitudde la aeronave y el externo genera referencias para el lazointerno a fin de controlar la posicion. El lazo interno consta detres compensadores proporcional, integral y derivativo (PID)digitales, dos para controlar losangulos de cabeceo (ϕ) yrolido (θ) y el tercero para la orientacion (ψ). Estos 3angulosson conocidos comoangulos de navegacion. El sistema delazo cerrado paraϕ y θ tiene un ancho de banda teorico de15 Hz. El mecanismo de medicion de estosangulos debeposeer una frecuencia de corte por encima de este lımitepara no comprometer la estabilidad ni degradar el desempenodinamico.Para determinar la inclinacion se utilizan acelerometros tipoMEMS, que poseen numerosas ventajas para esta aplicacion,como ser buen ancho de banda, suficiente resolucion, pesoreducido, robustez y bajo costo. Mediante estos sensores esposible determinar la direccion y el sentido del vector de acel-eracion de la gravedad respecto a un marco de referencia fijoen la aeronave. La desventaja fundamental de estos sensoresradica en que las mediciones son fuertemente afectadas por lasvibraciones en la estructura donde se encuentran montados.Otra alternativa para medir la inclinacion es computar larotacion integrando la senal de sensores giroscopicos. Por

las mismas razones que el caso anterior, los dispositivosde tecnologıa MEMS resultan los mas apropiados para estaaplicacion, aunque si bien son mas inmunes a las vibracionespresentan 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 giroscopocomo sensores de medicion de inclinacion. Se muestran losinconvenientes que producen las vibraciones y las derivas.En la seccion 3 se propone combinar las mediciones delos sensores mediante un filtro complementario que permitareconstruir una estimacion de las mediciones a partir de laspartes de los espectros de las senales adquiridas con cadasensor, cuya informacion se encuentre menos corrompida.En la seccion 4 se presentan los resultados de los ensayosutilizando el filtro complementario. En la seccion 5 se discutenlas 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ıncon un propulsor en cada extremo, un potenciometro en elpivot y el sensor con el sistema de control montado en elcentro. Este montaje con un grado de libertad permite simularel comportamiento dinamico aproximado del sistema respecto

121


2 3 4 5 6 7 8tiempo [s]

30

20

10

0

10

[gra

dos]

9

(a) Angulo de rolido en funcion del tiempo.

0 20 40 60 80frecuencia [Hz]

0

10

20

30

40

50

60

70

80

90

Mag

nitud

(b) Espectro de frecuencias.

Figura 2:Angulo medido con el acelerometro, con el montajeen equilibrio formando unangulo de 10o y los propulsoresapagados.

al rolido o el cabeceo.(Fig. 1). Aparte del sistema mecanico, elmontaje cuenta con un controlador PID digital implementadoen el microcontrolador, el cual cierra el lazo del sistema atraves del control de la velocidad de los motores. Para lograruna notacion consistente supondremos que elangulo a medires el de rolido (θ).

II-A. Acelerometro

En el desarrollo experimental se utilizo el acelerometroADXL345 de tres ejes dispuesto de manera que los ejes demedicion del mismo coincidan con los ejes del sistema dereferencia del UAV. De esta manera elangulo se obtiene comoϕ = arc cos ax

g , donde la aceleracion ax se mide con unaresolucion de 10 bits, y un ancho de banda ajustable porsoftware desde 0.05 Hz. hasta 1600 Hz.Las Fig. 2a,2b y las Fig. 3a, 3b muestran comparativamente lassenales adquiridas del sistema a lazo abierto en estado de equi-librio con una inclinacion de 10o con los propulsores apagadosy con los propulsores encendidos (50 %) respectivamente.

2 3 4 5 6 7 8tiempo [s]

30

20

10

0

10

[gra

dos]

¡


0 20 40 60 80frecuencia [Hz]

0

2000

4000

6000

8000

10000

12000

Magnitud


Figura 3:Angulo medido con el acelerometro, con el montajeen equilibrio formando unangulo de 10o y los propulsoresencendidos al 50 % de su potencia.

Si bien el sistema en lazo cerrado formado por el balancınmas el controlador PID presenta un buen rechazo a lascomponentes ruidosas de alta frecuencia de las vibraciones,esto se aprecia en la curva de bode simulada para un sistemaideal de la Fig. 4 y en las curvas de respuesta en el tiempo delmismo sistema que se ven en la Fig. 5, las variaciones bruscasde la senal de referencia producen acciones de control, debidasa la rama del derivador del compensador, que llevan a losmotores a zonas no lineales (saturacion o corte), provocandola inestabilidad del sistema real. Esto se puede comprobarcalculando la componente derivativa del compensador PIDusando como entrada de error la senal de la Fig. 3a.El filtrado de la senal ruidosa mediante un filtro pasa-bajosintroduce otras desventajas: si bien se pueden mantener aco-tadas las derivadas en la senal, la atenuacion y el corrimientode fase degradan la respuesta dinamica e incluso provocaninestabilidad cuando las frecuencias de corte son demasiadobajas. La Fig. 6a muestra la respuesta temporal del sistema

122


[dB]

[grados]

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

[gra

dos]

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

[gra

dos]

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

Figura 5: Respuesta temporal del sistema de lazo cerrado detipo regulador con una perturbacion sumada a la medicionideal de0,1o de amplitud para frecuencias de 5Hz y 50Hz.

para una medicion no ruidosa y no filtrada, en la Fig. 6bla misma senal se pasa por un filtro pasa-bajos de 5 Hz defrecuencia de corte, finalmente si se disminuye la frecuenciade corte del mismo a 2 Hz el sistema se desestabiliza, tal comolo muestra la grafica de simulacion de la Fig. 6c.Como consecuencia de las caracterısticas ruidosas de lasmediciones adquiridas con el acelerometro no serıa posibleutilizarlo como inclinometro en el sistema de estabilizacion.

[gra

dos]

10

5

0

0 0.5 1 1.5 2

tiempo [s]

(a) Sin filtrar.

[gra

dos]

10

0

-6

0 0.5 1 1.5 2tiempo [s]

(b) fc = 5Hz

[gra

dos]

200

0

-200

0 0.5 1 1.5 2tiempo [s]

(c) fc = 2Hz

Figura 6: Respuestas temporales del sistema a lazo cerrado deθ para senales no ruidosas, pero previamente pasadas por unfiltro pasa bajos.

A raız de esto se evalua la posibilidad de utilizar un giroscopo.

II-B. Giroscopo

Para realizar los siguientes experimentos se utilizo ungiroscopo de 3 ejes ITG3200 de la firma InvenSense.Estese dispuso de manera que sus ejes esten alineados con losdel sistema de referencia de abordo. Este dispositivo poseeun rango dinamico de+/ − 2000[o/s] y una sensibilidad de14o/s. En las Fig. 7a, 7b, 8a,8b se observan comparativamentelas senales en el tiempo y el espectro para el caso que lospropulsores estan apagados y encendidos con la misma

configuracion que la descripta para el caso de la medicioncon 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]

[gra

dos]


0 20 40 60 80 1000

5

10

15

20

25

magn

itud

frecuencia [Hz]


Figura 7: Angulo medido con el giroscopio, con el montajeen equilibrio y los propulsores apagados.

con la Fig. 8a se puede ver que la influencia de las vibracionesen las mediciones del giroscopo son sensiblemente menoresque en el caso del acelerometro. Sin embargo se han observadointervalos de tiempo relativamente cortos, la Fig. 9 muestraque para tiempos mayores la medida de este sensor comienzaa derivar.

III. F ILTRO COMPLEMENTARIO

En forma intuitiva surge la idea de usar la medicion obtenidapor el giroscopo para tiempos cortos y realizar la correccionde la deriva con la medicion realizada por el acelerometroen tiempos largos, debido a que estaultima medicion tiendea ser la aceleracion de la gravedad para perıodos largos.Los filtros complementarios son muy usados en sistemas denavegacion inercial. Aplicaciones tıpicas son la combinacionde las medidas de aceleracion vertical y velocidad barometricavertical para obtener una estimacion de la velocidad verticalo mediciones de unidades inerciales y sistemas de vision. [1]

Un filtro complementario es en sı un filtro de Kalman deestado estacionario para una cierta clase de problemas de

2 3 4 5 6 7 8 91.0

0.5

0.0

0.5

1.0

1.5

tiempo [s]

[gra

dos]


0 20 40 60 80 1000

50

100

150

200

250

300

350

400

frecuencia [Hz]

magn

itud


Figura 8: Angulo medido con el giroscopio, con el montajeen equilibrio y los propulsores encendidos al 50 % de supotencia..

filtrado [2], este no considera ninguna descripcion estadısticadel ruido que corrompe a las senales y es obtenido solamentepor un analisis en el dominio de la frecuencia. El filtrocomplementario resulta sencillo de tratar matematicamente yen razon de su baja complejidad de implementacion consumepocos recursos computacionales. La idea basica del filtrocomplementario es combinar la salida del acelerometro ydel giroscopo para obtener una buena estimacion del angulode orientacion de la plataforma, compensando la deriva delgiroscopo con la dinamica lenta del inclinometro [3].

El filtro complementario propuesto es el que se muestra enla figura 10. Dondeθa es elangulo medido por el acelerometrocuya senal esta corrompida por ruidos de alta frecuenciaproveniente de las vibraciones,θg es el angulo medido porel giroscopo, afectado por la deriva yθ es elangulo estimado.

Las funciones de transferencia del filtro deben ser elegidasde acuerdo a la ecuacion 1:

124


0 5 10 15 20 25 30 35 40Tiempo (s)

20

15

10

5

0

5

10

15

Giró¡ scopo

Potenció¡ metro

[gra

dos]

Figura 9: Deriva delangulo medido por el giroscopo

Figura 10: Diagrama en bloques del filtro complementarioutilizado.

Ha(s)G(s) +Hg(s)(1−G(s)) = 1 (1)

en dondeHa(s) y Hg(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 esHa(s) = Hg(s) = 1.

La funcion de transferencia elegida paraG(s) es un filtropasa bajos de primer orden, lo cual hace que la estimacion enbaja frecuencia dependa de la medicion del acelerometro.

G(s) =α

s+ α(2)

En tanto que la funcion de transferencia elegida para1 −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 altafrecuencia de la medicion estimada esten dominadas por elaporte de las mediciones provenientes del giroscopo.

Como podemos ver en la figura 10, si ambas medicionesson 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. Discretizacion 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 unretenedor de orden cero a la entrada. Con esto se obtiene unaexpresion 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 dondea = 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 cadafiltro.

θ[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 IMPLEMENTACION

Se ensayo el sistema utilizando el filtrado complementarioverificandose una buena estimacion del angulo que resulto enla correcta estabilizacion y una buena respuesta dinamica.En la figura 11 se muestran las mediciones individuales delacelerometro y el giroscopo; y la estimacion del filtro com-plementario; mientras se sometio al sistema a perturbacionesforzandolo a salir de la posicion de equilibrio y permitiendoleque se restituya en forma autonoma. Como se observa enla grafica se calibro debilmente el offset del giroscopo parapermitir una deriva exagerada a fin de mostrar el rechazodel filtro. En la Figura 12 se observa la medida delanguloestimada por el filtro contrastada contra la medicion del po-tenciometro durante la evolucion del sistema desde unanguloinicial de -10 grados hasta el equilibrio en cero grado. En esteensayo se utilizo la medida del filtro para la realimentacion dellazo de control y se ajustaron las constantes del controladorPID. Este ajuste se realizo segun los analisis de estabilidadhechos del sistema a lazo cerrado para obtener la respuestasubamortiguada que se observa, aunque hubo que realizar

125


algunos retoques empıricos los cuales se pueden deber a quese idealizaron algunas partes del sistema y tambien a falta deuna buena calibracion de los sensores y propulsores.

0 5 10 15 20 25 30Tiempo (s)

40

20

0

20

40

60

Aceleró¡ metro

Giró¡ scopo

Filtro Complementario

[gra

dos]

Figura 11: Mediciones y estimacion durante ensayo del sis-tema.

22 23 24 25 26 27 28Tiempo (s)

15

10

5

0

5

10

15

Filtro Complementario

Potenció¡ metro

[gra

dos]

Figura 12: Respuesta dinamica del sistema ante una pertur-bacion

V. CONCLUSIONES

Se ensayaron tres metodos de medicion de inclinacionde una plataforma experimental que se comporta como elUAV con cinco grados de libertad restringido, permitiendoserotaciones que corresponderıan al cabeceo o el rolido dela aeronave. Los dos primeros metodos ensayados utilizaronacelerometro por un lado y giroscopo por otro de maneraindividual. En el primer caso la influencia de las vibracionesimpide el correcto funcionamiento del lazo de control, entanto que si se filtra la senal de la medicion se degrada larespuesta dinamica o incluso se llega a la inestabilidad delsistema de lazo cerrado para frecuencias de corte demasiadobajas. Por el lado del giroscopo se obtuvo mejores resultados

en el comportamiento del lazo de control, no obstante esto laderiva producida por el offset del sensor hace que el error deinclinacion se incremente de manera constante en el tiempo.Ninguno de los dos metodos resulta viable para el control deactitud del UAV.Finalmente se aplico un filtro complementario para combinarla medicion de ambos sensores tomando de cada uno la partedel espectro de la senal de medicion menos corrompida yatenuando la otra a fin de que la suma permita una estimacionaproximada de la variable de interes. El comportamientodinamico del sistema realimentado con la medicion estimadapor el filtro resulta satisfactorio para ser aplicado al prototiporeal.

AGRADECIMIENTOS

El primer autor se financia bajo el programa de Becas deFormacion de Doctores enAreas 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 EngineeringJournal, 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,” inIntelligent 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 Caballero [email protected]

Dr. Pedro E. Colla [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 un satélite geoestacionario construida como un ambiente web embebido operando en una plataforma de microcontroladores Rabbit. La misma permite enviar comandos y leer telemetría de la carga útil durante la integración al modelo de ingeniería y vuelo. Se plantea en primer lugar el diseño del hardware que provee al sistema de las interfaces adecuadas para llevar a cabo la conectividad entre el payload y el módulo. El resultado final es un dispositivo capaz de realizar el monitoreo y control, a través de una red Ethernet, de distintas variables de estado, proveyendo al usuario de una interfaz gráfica que puede ser ejecutada en cualquier 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 los principales objetivos es lograr comandar y conocer el estado de distintas variables de la carga útil (payload) durante la integración con los modelos de ingeniería y vuelo. En el proyecto referido en este trabajo surgió la necesidad de explorar las diversas alternativas que permitirían implementar conectividad TCP/IP (Transmission Control Protocol/Internet Protocol), proveer el acceso a los subsistemas mediante un servicio Web y gestionar, en una capa más baja del stack del protocolo, el hardware subyacente de la plataforma por medio de interfaces estrictamente definidas de la carga útil. El módulo encargado de comandar el payload es la unidad de interfaz de distribución de carga útil (PIDU por su nombre en inglés Payload Interface Distribution Unit), en este diseño se busca sustituir el PIDU de vuelo en la etapa de integración del payload al modelo de ingeniería del satélite. En tecnología satelital se crea con éste propósito un equipo eléctrico de soporte en tierra (EGSE por sus siglas en inglés Electrical Ground Support Equipment) el cual sirve de apoyo durante la fase de integración y ensayo de cada uno de los subsistemas del satélite, tanto en 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ón del payload de un satélite geoestacionario el que ha sido especificado para trabajar en banda Ku con canales de 36MHz y 72MHz de ancho de banda, como así también

con un cierto número de entradas/salidas digitales y analógicas. Uno de los desafíos que debe resolver exitosamente el diseño propuesto es la implementación de la solución mediante herramientas estandar y que permita entregar desde una plataforma embebida una GUI (GUI por las siglas en inglés Graphical User Interface) flexible para su operación. Los alcances del proyecto requieren que este deba ser realizado bajo estrictos y restrictivos requerimientos de costo, calendarios y calidad claramente especificados.

II. DESARROLLO DEL MÓDULO Y APLICACIÓN

EMBEBIDA

En base a las interfaces del PIDU y a las necesidades de los usuarios en la fase de integración, es que se desprenden los requerimientos de la plataforma embebida, principalmente en lo que respecta al hardware de la misma. Para el desarrollo se eligió una plataforma RCM3365 [R01] basada en microprocesadores Rabbit[R03], la que cumple con los requisitos de cantidad de entradas/salidas, conectividad Ethernet, stack TCP/IP integrado y prestaciones de espacio en memoria adecuadas para este desarrollo. Una vez seleccionada la plataforma, se desarrollaron los restantes componentes de hardware y software, actividades que involucraron:

• Diseño del la plataforma de hardware de acuerdo con los requerimientos de interfaces del fabricante del payload. • Diseño y fabricación del circuito impreso, listados de materiales y documentación del desarrollo. • Poblado de la placa (630 componentes) y soldadura por olas y horno de termo-fusión. • Diseño e implementación de la aplicación embebida en la plataforma seleccionada (RCM3365) mediante Dynamic C para el envío de telecomandos y recepción de telemetría a través de la plataforma de hardware con el payload. • Implementación de un servicio Web donde la información a desplegar se genere utilizando el formato HTML y se despliegue utilizando RabbitWeb[R02]. • Definición del protocolo de comunicación para una aplicació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án necesarios 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 y telemetrí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 se vincule 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 los requerimientos 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 entonces diseñ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 y otros, 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 de almacenamiento masivo y la cantidad de E/S provista por 52 líneas, se seleccionó para el diseño el microprocesador RCM3365 de la familia Rabbit. La plataforma seleccionada soluciona varios problemas de diseño de hardware al proveer una capa física Ethernet, tolerancia al régimen de alimentación y memoria incorporada en dispositivo [R03]. Al seleccionar una plataforma embebida basada en RCM3365 se facilita, además, la solución de restricciones de implementación puesto que el módulo de desarrollo se monta en un zócalo de interfaz. De esta forma se puede trabajar de manera simultánea a la puesta en marcha del hardware para posteriormente ser integrado en la plataforma final. Otro problema resuelto con la elección, es solucionar la capa física de Ethernet, puesto que el módulo cuenta con un conector RJ45 y el hardware asociado para operar con este protocolo.

III. DISEÑO DEL HARDWARE DE INTERFAZ

Una vez finalizada la etapa de definición de requerimientos de diseño se pudo avanzar con la elaboración de los planos esquemáticos-eléctricos, del hardware de interfaz que hace de nexo entre la plataforma embebida RCM3365 y las interfaces de la carga útil. El diseño fue sometido a dos procesos de revisión por estar involucrado directamente con un subsistema de un satélite y de manera de realizar la detección de defectos lo más temprano posible en el ciclo de vida del proyecto. Los procesos de revisión típicos son la revisión preliminar 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 de los requerimientos de diseño, se realiza la PDR con el objetivo de saber si se han comprendido esos requerimientos y se está en condiciones de avanzar con la fase de diseño de detalle. En este análisis, se presenta el sistema como un diagrama en bloques. Finalizada la PDR comienza la etapa de desarrollo y antes de fabricar la placa se realiza la CDR donde se estudia a nivel de circuitos y en detalle cada una de las interfaces involucradas y los posibles modos de fallo. En este análisis se presentan planos esquemáticos muy detallados de cada circuito. Por último se realiza un análisis independiente de modos de falla (FMEA Failure mode and effects analysis). En caso de detectar riesgos de que el fallo de un componente se propague y dañe el hardware de vuelo, se identifica la mitigación a realizar mediante estrategias de protección como interfaces opto-acopladas o de aislamiento galvánico. Se utilizan en la implementación, prácticas de Ingeniería de Software [C04,P01] consistentes con la complejidad del desarrollo realizado, la criticidad de los entregables y la

necesidad de alcanzar estrictos requerimientos de calidad. Diseñado el esquemático se desarrolla el diseño del circuito impreso (PCB) teniendo en cuenta aspectos de Interferencia y compatibilidad electromagnética (EMI/EMC) e integridad de las señales entre otros.

A. Diseño de la aplicación embebida

Para la programación embebida se utilizaron los recursos de desarrollo provistos por el lenguaje Dynamic C propietaria de la plataforma RCM3365. Este lenguaje es un derivado de C adecuado y mejorado para los requerimientos de los microprocesadores de la familia Rabbit. El fabricante de los módulos entrega junto con el kit de desarrollo de la plataforma, el software para programación [R05] y el cable de conexión con la PC utilizada como ambiente de desarrollo. Una vez finalizada la puesta en marcha a nivel electrónico de la plataforma de interfaz de hardware se comienza a trabajar en el componente de software. En primera medida se validan todas las entradas/salidas digitales, LLC y DR, comprobando que el software sea capaz de comandar y leer todos los puertos del microprocesador que habían sido asignados a las distintas interfaces del PIDU. Este proceso se simplifica notablemente aplicando una técnica de “stubs” [C04] (funciones simuladas no operativas) donde pequeños segmentos de código son aplicados a verificar un aspecto en particular. A continuación se presenta en el Ejemplo 1, la programación que muestra como se escribe y lee un puerto en Dynamic C [C01] para un módulo RCM3365.

Los canales de entrada analógicos AN y PT provienen de 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 una interfaz de desarrollo API [D01] llamada I2C.LIB [R04], que maneja los aspectos genéricos de la interfaz I2C y proporciona funciones simplificadas [C02] para que el diseñador utilice el módulo RCM3365 como un Master del BUS según lo mostrado en la Figura 2.

Ejemplo 1 Lectura de puerto en Dynamic C

main() BitWrPortI(PDDDR, &PDDDRShadow,0,1); // switch, input BitWrPortI(PDDDR, &PDDDRShadow,1,0); // LED, output BitWrPortI(PDDR, &PDDRShadow,1,0); // apaga LED while(1) if(!BitRdPortI(PDDR,1)) BitWrPortI(PDDR,&PDDRShadow,0,0); /* Prende el LED DS1 */ else BitWrPortI(PDDR,&PDDRShadow,1,0); /* Apaga el LED DS1 */

132


Figura 2 Arquitectura Rabbit como master de Bus I2C

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 bus I2C

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 y puerto donde está escuchando el servidor [H01]; las mismas 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 interfaz de 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ón CGI [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 enviar comandos 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 I2C i2c_init() // Configura SCL y SDA como salidas de OC y constantes de retardo. • Envío de la condición de Comienzo i2c_start_tx() // Inicializa la transmisión mediante el envío de un comienzo (start) i2c_startw_tx() // Inicializa la transmisión mediante el envío de un Start (S) // Inserta un delay después del pulso S • Envío de un Byte de datos i2c_write_char() // Envía 8 bits al dispositivo esclavo i2c_wr_wait() // Reintenta escribir una variable char hasta que el esclavo responde • Escucha de un ACK i2c_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 ACK i2c_send_ack() // Envía una secuencia ACK al esclavo. i2c_send_nak() // Envía una secuencia NAK • Envío de una condición de parada i2c_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) http_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ón embebida y el simulador de plataforma se implementa sobre un socket TCP/IP, en el campo de datos del segmento, donde la plataforma RCM3365 operará como cliente. El control de flujo propio de TCP/IP garantiza una entrega de paquetes en orden y libres de errores, lo cual constituye una ventaja para la integridad de la comunicación. El SIMPLAT inicia la conexión con la plataforma 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 el SIMPLAT desea enviar o el valor de telemetría “TM Variable “que se pretende leer. Para una solicitud de telemetría “TM Request”, la plataforma embebida devuelve un paquete “TM Response” con el mismo número de secuencia con el cual se originó la petición y el campo “TM Value” con un valor de TM DR, AN o PT según lo requerido, de tratarse de una solicitud de telecomandos “TC Request”, la plataforma, retorna un paquete “TC Response” (eco), tras haber ejecutado el comando indicado en los campos “LLC Status” y “ TC Variable”. En caso de que la conexión no pueda ser establecida dentro de 10 intentos se asumirá una condición de error en el SIMPLAT. Las principales ventajas del protocolo bidireccional implementado son simplicidad y robustez. La estructura de los paquetes de datos del protocolo de comunicación puede ser observada en la Tabla 3.

Tabla 3 Estructura de los paquetes de datos del protocolo de comunicación Implementado

Cada 500 mSeg el SIMPLAT establecerá una comunicación con la plataforma embebida realizando el envío de telecomandos (TC Resquest) y/o pedidos de telemetría (TM Request) que estén determinados en ese ciclo. Se ha implementado en la memoria de programa del módulo RCM3365 una tabla de asignación de telecomandos y variables de telemetría, que vincula TC y 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 de comunicación En la figura 4 se puede observar el funcionamiento del protocolo. Si la plataforma embebida encuentra un error en el sub-campo “TM Variable” o “TC Variable” del campo de datos de un paquete “Request”, devolverá un paquete “retry” con

número de secuencia 0x00 y el campo de datos con un valor 0x000000, lo cual indicará al SIMPLAT un pedido de retransmisión. Si la plataforma no devuelve un número de secuencia esperado por el SIMPLAT, se generará automáticamente desde el SIMPLAT un reenvío de la solicitud TM o TC según corresponda.

Figura 4 Funcionamiento del Protocolo de

Comunicación Simplat-Plataforma Una vez finalizado el período de comunicación con la plataforma, la misma estará esperando hasta que comience un nuevo ciclo de Telecomandos y pedidos de Telemetría que esté determinado por parte del SIMPLAT.

IV. VALIDACIÓN Y VERIFICACIÓN

La validación y verificación (V&V) del diseño requiere consideraciones especiales. A nivel de verificación se procede a revisar unitariamente cada interfaz en particular, los niveles de tensión, corrientes, tiempos de transitorios, flancos y tolerancias requeridas por el fabricante del payload las que son estrictas. Para los ensayos a nivel unitario de recepción de comandos y emisión de telemetría mediante “stubs” que simularon el payload a ser controlado de acuerdo a la especificación de su fabricante. Posteriormente se realizó la integración con el payload de manera de verificar la recolección de telemetría DR. Se probaron 100 casos de estados de cambios de variables controladas por un operador y su correcto reflejo en la información HTML proporcionada por la interfaz Web. Una estrategia similar se utilizó para verificar unitariamente los comandos LLC controlando con instrumental apropiado que los parámetros eléctricos y de tiempo estuvieran dentro de especificación al mismo tiempo que se verifica que las lecturas son correctamente reflejadas en la GUI. Los resultados del test fueron documentados e incluidos en la documentación del sistema. La integración con la PC industrial se resuelve también con un criterio de verificación unitaria primero para luego 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 requerimientos a 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 posibilidad de 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 el software 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 del saté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 de aplicació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 el compilador 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 special group 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 Practitioner'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 de Sensores

Puerto Ethernet

Estación Meteorológica Web

Router Ethernet

Ethernet LAN

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

Esp. Ing. Martín Federico Pelliza Especialidad en Sistemas Embebidos Instituto Universitario Aeronáutico

Córdoba, Argentina [email protected]

Mg. Héctor Riso Especialidad en Sistemas Embebidos Instituto Universitario Aeronáutico


Abstract—Este trabajo tiene como objetivo realizar una exploración y evaluación de posibilidades para el desarrollo de aplicaciones embebidas que ofrezcan conectividad de red. En ese marco se eligió como ejercicio el desarrollo de un prototipo de una estación meteorológica web, implementando una aplicación embebida en un módulo de desarrollo del fabricante Netburner al cuál se integró el hardware necesario para medición de temperatura y movimientos sísmicos. Como resultado se obtuvo un dispositivo totalmente autónomo que permite a través de una red ethernet el monitoreo de diferentes condiciones ambientales en tiempo real, el acceso a los registros de los datos almacenados internamente en el dispositivo, y la configuración remota de distintos parámetros de su funcionamiento.

I. INTRODUCCIÓN

Con el objetivo de explorar las posibilidades actuales a la hora de desarrollar dispositivos con capacidades de red, se eligió como ejercicio el desarrollo de un prototipo para la adquisición y registro de diversas condiciones ambientales, que permita el acceso a los mismos en tiempo real a través de una red ethernet.

Para la implementación preliminar de una solución, las alternativas que se presentaban eran el desarrollo de un hardware dedicado basado en microprocesador y software embebido que implemente tanto los protocolos de red y la interfaz con los sensores, o bien la utilización de una plataforma que ya integre la solución de red y acote el trabajo de desarrollo. Se seleccionó esta última opción, ya que se estimó que el esfuerzo de desarrollo requerido para la primera opción sería considerablemente mayor y excedería los límites de tiempo propuestos para este trabajo, y se eligió como plataforma de desarrollo un módulo Mod5270 de Netburner [1]

Luego de la selección de la plataforma, se desarrollaron los componentes de Hardware y de Software, actividades que involucraron:

• El diseño y fabricación de un módulo de sensores para la adquisición de datos de aceleración y temperatura, extensible para la incorporación de sensores de presión, humedad, velocidad y dirección de viento, etc.

• El diseño y la implementación en C++ de la aplicación embebida en el Mod5270 para la adquisición y registro de datos del módulo de sensores, y su acceso remoto

• La definición de un protocolo para la comunicación de datos vía UDP.

• La implementación de un servicio web para el acceso a los datos y configuración del Mod5270, utilizando HTML y JavaScript para el desarrollo de las páginas web. Esta actividad incluyó también la implementación en JAVA de un applet para la visualización en tiempo real y en forma gráfica de los datos de temperatura y movimientos sísmicos.

La descripción de las estas tareas y los resultados obtenidos en cada una de ellas se desarrollan en las siguientes secciones.

En Fig. 1 se muestra el dispositivo desarrollado dentro de un contexto de aplicación.

Figure 1. Contexto de Aplicación

II. DESARROLLO DEL HARDWARE

A. Plataforma El seleccionó el módulo Mod5270 de Netburner como

plataforma de desarrollo. El módulo incluye entre sus caracterí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 en tiempo real multitarea basado en prioridades, ideal para ser utilizado en aplicaciones embebidas. El C/OS-II está integrado con el sistema de I/O del Mod5270 y ofrece (además de las funciones y rutinas básicas para la creación y administració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 como I2C y SPI) [2]. Estas librerías son utilizadas por la aplicación para la adquisición y registro de datos, como así también para la exposición del servicio web.

B. Módulo de sensores Se desarrolló un módulo básico de hardware de adquisición

de datos, cuyo diseño se enfocó en la facilidad para la integración de distintos tipos de sensores. Con este criterio se adoptó el bus I2CTM para 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 para el intercambio de datos entre dispositivos, con una interconexión mínima entre ellos, ya que es un bus de dos cables.

La flexibilidad del bus permite la incorporación de sensores al módulo de manera directa, con la sola condición de que estos soporten una interfaz I2C. De esta forma el módulo de sensores es extensible y permite la medición variadas condiciones ambientales, además de las ofrecidas por el prototipo, como por ejemplo presión, humedad, velocidad viento, etc.

El módulo de adquisición de datos desarrollado para este prototipo cuenta con dos sensores para la medición de temperatura, y un sensor para la medición de movimientos sísmicos.

Para la medición de temperatura se escogieron los sensores digitales de temperatura TMP101 de Texas Instruments [3] y STTS75 de STMicroelectronics [4], mientras que para la medición de movimientos sísmicos se utilizó el acelerómetro digital de 3 ejes LIS3LV02DL STMicroelectronics [5]. Todos los sensores están interconectados al bus I2C y se utilizan en modo esclavo, mientras que el Mod5270 es utilizado como maestro.

Los sensores de temperatura utilizados poseen características similares en cuanto a su rango de medición (de –55°C a +125°C), pero se configuraron con resoluciones diferentes, el primero con una resolución de 9 bits (0.5°C ) y el segundo con una resolución de 12 bits (0.0625°C), con el fin de 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 de aceleración a fondo de escala de +/-2.0g y +/-6.0g, con un ancho 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 terremotos moderados está comprendida entre 0,05 g y 0,35 g (llegando en algunos casos a alcanzar aceleraciones de 0,5 g cuando el movimiento del suelo es medido sobre suelo firme o roca muy cerca de la fuente de ondas), y su frecuencia típica se encuentra entre 0,5Hz y 2Hz (llegando a 4Hz en casos excepcionales) [6]

y [7], este dispositivo es apropiado para la medición de movimientos 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 estos datos en forma remota a través de HTTP, FTP o UDP.

El Mod5270 opera bajo un sistema operativo multitarea preemptivo, basado en prioridades. La aplicación ejecuta las rutinas de acceso a la red (inicialización del stack TCP y adquisición de IP dinámica) y luego crea, configura e inicia las tareas que ejecutan las actividades mencionadas en el párrafo anterior en forma independiente.

Las principales tareas ejecutadas por la aplicación pueden dividirse en:

A. Adquisición de datos a través del módulo de sensores Existen dos tareas encargadas de obtener cíclicamente los

datos de temperatura y aceleración, realizando el muestreo de datos con la frecuencia configurada a través de la página de configuración del sistema. El período de muestreo para temperatura puede variar entre 1 y 3600 segundos, mientras que para aceleración el período de muestreo puede variar entre 200 y 1000 milisegundos (en saltos de 50 milisegundos).

La aplicación permite registrar hasta un máximo de 3600 muestras de temperatura y 18000 muestras de aceleración. Este número máximo de muestras se determinó asumiendo una hora de almacenaje, con el período de muestreo de temperatura de 1 segundo y de movimiento de 200mS. Las muestras se almacenan en un buffer circular, por lo que las muestras más antiguas son reemplazadas por nuevas muestras una vez que el límite máximo de cada tipo de muestra es alcanzado.

La adquisición de los datos de temperatura y movimiento del módulo de sensores se realiza a través del bus de dos líneas I2C. Cada dispositivo conectado al bus posee una dirección única de 7 bits, y puede actuar como transmisor o receptor de datos. El Mod5270 es utilizado como maestro (el dispositivo que inicia la comunicación), mientras que los dispositivos del módulo de sensores son configurados en modo esclavo. La especificación del protocolo I2C [8] describe el proceso de transmisión de datos entre dispositivos.

Inicialmente la tarea de adquisición de temperaturas configura los sensores de temperatura para una resolución de 12 bits el TMP100 y 9 bits el STTS75, en modo de muestreo continuo (una muestra cada 340ms). Luego, de acuerdo al período configurado, solicita muestras de temperatura al sensor activo. La tabla de conversión de bits a °C es similar para ambos sensores, y puede encontrarse en la Tabla 4 de [4]

La tarea de adquisición de aceleraciones configura al sensor de aceleración para una escala de medición de de +/-2.0g con una resolución de 12 bits (~0,001 g), con una frecuencia de muestreo de 40Hz (25mS). Luego, la tarea solicita muestras de aceleración de acuerdo al período de muestreo configurado. La tabla 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 7FF 1.5625 0110 0100 0000 640 1.0000 0100 0000 0000 400 0.2930 0001 0010 1100 12C 0.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 últimas

muestras de temperatura y movimientos sísmicos, como así también un registro completo de los eventos del sistema. En esta versión de la aplicación en el servidor sólo se implementaron los siguientes comandos definidos por el protocolo FTP: “ls” para obtener los nombres de los archivos disponibles, “get” para descargar archivos, y “bye” para finalizar la conexión.

Los clientes FTP pueden descargar archivos con los diferentes registros (aceleración, temperatura y eventos del sistema) en formato de texto. Estos archivos son generados bajo demanda, ya que el Mod5270 no posee un sistema de archivos, y contienen una lista de todas las muestras disponibles.

Cada entrada del archivo contiene la hora, un índice representando la secuencia y un valor entero decimal que representa el valor la medición, de acuerdo a la conversión de temperatura y aceleración de las tablas descriptas en la sección anterior de este documento.

C. Servicio UDP Esta tarea implementa un protocolo de comunicación para

la transmisión datos de mediciones a aplicaciones externas via UDP. El servidor recibe mensajes solicitando distintos tipos de muestras (UDP Sample Requests), respondiendo a los mismos con las muestras requeridas en un mensaje de respuesta (UDP Sample Response). El puerto del servidor es configurable a travé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 o aceleración.

El campo Cantidad de Muestras (16 bits) es utilizado para solicitar el envío una cantidad fija de muestras.

El campo Ultima Muestra Recibida (16 bits) es utilizado para 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 Response Un mensaje UDP Sample Response puede contener una o

mas muestras, cada una con un formato como el que se detalla en Fig. 3. El encabezado de una muestra indica, en su MSB, si esa muestra es la última muestra disponible o si existen otras muestras más actuales disponibles, y en sus 7 bits restantes el código del tipo de muestra (aceleración o temperatura). Los campos Índice y TimeStamp son comunes a cualquier tipo de muestra, mientras que los restantes campos se diferencian para las muestras de temperatura y aceleración.

El campo Índice (16 bits) indica el número de secuencia de la muestra. Su valor máximo depende del tipo de muestra, siendo 3600 para muestras de temperatura y 18000 para muestras de aceleración.

El campo TimeStamp (entero sin signo de 32 bits) contiene la fecha y hora de la muestra expresada en Tiempo Universal Coordinado (UTC)

El campo mS (16 bits) está presente sólo en muestras de aceleració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ón correspondiente, según la conversión de aceleración y temperatura descripta en secciones anteriores (los bits 15-14-14-12 son siempre 0).

Se permite incluir hasta 50 muestras en un mensaje UDP Sample Response (para limitar el tamaño del paquete UDP a 750 bytes).

Figure 3. UDP Sample Response

Cuando un UDP Sample Request contiene en el campo Ultima Muestra Recibida el número de secuencia de una muestra, el servidor enviará un mensaje UDP Sample Response con todas las muestras desde el índice indicado, hasta la muestra 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. El Applet desarrollado para la visualización de datos en tiempo real desde la página web hace uso de este protocolo para la adquisició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

UDPSampleResponseEl servidor responde con un mensaje con las muestras deaceleración 103 a 123

UDPSampleRequest (‘a’,0 , 123)

El cliente solicita las muestras de aceleración desde la últimarecibida, 123


UDPSampleResponseEl servidor responde con un mensaje con las muestras deaceleración 124 a 131

UDPSampleRequest (‘t’,-1 ,-1)

El cliente solicita la última muestra de temperatura disponible


El servidor responde un mensaje 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. El

servidor soporta solicitudes GET y POST, respondiendo a las mismas mediante paginas HTML generadas dinámicamente. Accediendo a este servicio un usuario puede:

Configurar distintos parámetros de funcionamiento del Mod5270

Obtener registros parciales de las muestras de temperatura y movimientos sísmicos

Obtener registros de eventos del sistema

Mostrar en tiempo real las muestras temperatura y movimientos sísmicos

a) Pagina de configuración Los parámetros configurables a través la página de

configuración son el período de muestreo de temperatura y movimientos sísmicos (aceleración), la dirección IP del servidor NTP con el cual la aplicación se sincroniza, el puerto donde el servicio UDP está disponible, el tipo de filtro aplicado a 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 el acceso a la página de configuración de los parámetros de funcionamiento, para la cuál la provisión de credenciales es obligatoria. Este esquema es utilizado sólo con fines de identificación, ya que no constituye un método seguro de autenticación (los datos son transmitidos como texto claro).

Cada cambio en la configuración de los parámetros de funcionamiento del Mod5270, es registrado como un evento de sistema.

Figure 5. Pagina de configuración

b) Registros Los registros parciales de las últimas muestras de

temperatura y movimientos sísmicos, como así también de los eventos del sistema se obtienen en la pestaña Registros de la página web.

Los eventos del sistema también son registrados y pueden ser accedidos a través de la página esta misma página.

Es todos los casos, es posible seleccionar la visualización de los entre 10 y 100 últimos registros. Los registros completos pueden 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 servidor

descarga en el navegador del cliente un applet encargado de obtener (vía UDP y adhiriendo al protocolo descrito en secciones anteriores) y procesar los datos, desplegándolos en forma gráfica. El applet solicita muestras cada 750mS y actualiza los gráficos con las muestras del último paquete UDP

139


recibido. Se despliegan las últimas 50 muestras de temperatura y 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 del

Mod5270 a través de un cliente NTP. La aplicación inicialmente sincroniza el reloj interno del sistema mediante una solicitud a un servidor NTP, y a partir de ese momento se re-sincroniza cada 4 horas.

De existir algún error durante la sincronización, la aplicación intenta nuevamente restablecer el contacto con el servidor NTP cada 10 minutos, hasta lograr la re-sincronización (inicialmente 00:00:00 GMT 1 Ene 1970 en caso 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 de

investigación sobre las diferentes alternativas existentes a la hora de diseñar una sistema embebido, que involucraron el estudio de microprocesadores, plataformas, sensores, e interfaces, la aplicación de diferentes protocolos de red, el diseño y fabricación de un módulo de hardware y la programación, en C++, JAVA, JavaScript, HTML y sobre una plataforma basada en un sistema operativo en tiempo real, de una aplicación embebida completa.

El resultado demostró que existen en el mercado actual opciones para el desarrollo de sistemas embebidos con

conectividad de red que involucran un esfuerzo de desarrollo relativamente acotado; la alternativa que se evaluó no sólo incorpora la solución de red, sino que además ofrece herramientas (en la forma de paquete de librerías, entorno de desarrollo 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 componentes de hardware necesarios para implementar un sistema totalmente autónomo con capacidades de red.

Si bien el desarrollo de un producto aplicado supone la definición de requerimientos más específicos basados en necesidades concretas, el presente trabajo puede constituir un punto de partida para el monitoreo de diferentes entornos en donde el uso de conectividad Ethernet es extendido. La integración de nuevos sensores y la utilización de esquemas de captura inalámbricos tales como ZigBee o Bluetooth permitiría por ejemplo la comprobación de condiciones de presión, humedad y temperatura en laboratorios, vibraciones en salas de ensayos, etc.

Futuras evoluciones del prototipo podrían centrarse también en la definición de una estrategia para el registro por disparo en lugar del registro continuo para las mediciones de movimientos sísmicos, la medición de determinadas variables sólo bajo demanda, la implementación de estrategias para la gestión de fallos o la incorporación de capacidades de seguridad (por ejemplo el uso de SSL para el cifrado de datos intercambiados 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 y Tordesillas - Física de la tierra, ISSN 0214-4557, Nº 11, 1999 (Ejemplar dedicado 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) bus specification. - (http://www.nxp.com/acrobat_download/literature/9398/39340011.pdf)

140


Diseño de un sistema de actualización de firmware para un sistema embebido

Esp. Ing. Diego Gustavo Roca Especialidad en Sistemas Embebidos Instituto Universitario Aeronáutico


Dr. Pablo Ferreyra Especialidad en Sistemas Embebidos Instituto Universitario Aeronáutico


Resumen— En este trabajo se analiza la problemática que se observa al momento de tener que actualizar el firmware de un sistema 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 en forma segura la actualización.

I. INTRODUCCION

Los sistemas embebidos tienden, fruto del avance tecnológico, a ser cada vez más potentes, integrados y complejos. Esto hace que puedan realizar tareas cada vez más complicadas y que sean tan flexibles como para adaptarse a distintas situaciones. Esas mismas razones, sumadas a necesidades de mercado, traen aparejada la necesidad constante de corregir, mejorar o modificar el software que los controla; aun cuando el sistema embebido esté en manos del usuario final.

El presente trabajo está basado en un caso real. Se analiza y describe la problemática encontrada al momento de tener que actualizar el software de un sistema embebido. En todo momento la problemática es confrontada con los requerimientos 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 de simplicidad.

II. REQUERIMIENTOS DEL SISTEMA DE ACTUALIZACIÓN

Se describen a continuación los requerimientos recibidos al momento 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 componente o parte que haya que reemplazar para efectivizar la actualización, por ej.: Memorias pregrabadas, tarjetas SD, placas, etc.

2 - Del punto 1 se desprende que, para llevar adelante la actualización, se deberá enviar al lugar en que se encuentra el Equipo alguna forma de archivo conteniendo el nuevo firmware. A dicho archivo lo denominaremos de aquí en adelante como: “Archivo de actualización”.

3 - Se deberán suministrar medios que permitan controlar o restringir la aplicación del Archivo de actualización sobre los Equipos. Esto implica que el Archivo de actualización pueda usarse para actualizar sin restricciones el firmware de cualquier Equipo (que tenga los medios para ello), o que dicho Archivo de actualización sea aplicable únicamente a un grupo determinado de Equipos, o, más restrictivo aún, que dicho Archivo de actualización sea aplicable a un único Equipo en particular. Al momento de generar ese Archivo de actualización deberá poder seleccionarse el grado de restricción a aplicar.

4 - El Equipo dispone como interfaz de comunicaciones solamente de un puerto serie RS-232C.

5 - La empresa fabricante del Equipo no posee un servidor de acceso público desde el cual se podría descargar el Archivo de actualización.

III. MODELO DEL SISTEMA DE ACTUALIZACIÓN

En esta sección se hará un análisis de los requerimientos del sistema de actualización y se planteará un modelo donde se describirán las partes involucradas. Se esbozarán también los lineamientos básicos de funcionamiento.

Visto desde el lado del Equipo, el requerimiento 4 impone la necesidad de una computadora que se conecte al Equipo y que permita descargar el Archivo de actualización al mismo. Será necesario también contar con un operador que lleve adelante acciones básicas.

El requerimiento 5 lleva a proponer el envío del Archivo de actualización al lugar donde se vaya a hacer la actualización vía e-mail.

El requerimiento 3 impone la necesidad de hacer algún tipo de 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 que procese el archivo de imagen de memoria y genere el Archivo de actualización.

141


Fig. 1. Modelo del sistema de actualización remota.

En la Fig. 1 se observa el modelo propuesto para el sistema de actualización. La secuencia lógica de pasos para recorrer el modelo sería la siguiente: El fabricante lanza la nueva versión de firmware, que en nuestro caso es básicamente la imagen de memoria. Ese archivo es procesado por una aplicación de PC que lleva el nombre de “Packer”, se obtiene así el Archivo de actualización. El Archivo de actualización es enviado al lugar en que se encuentre el Equipo vía e-mail. Para llevar adelante la actualización, el operador del sistema necesita otra aplicación de PC que lleva el nombre de “Updater”. La aplicación “Updater” se encarga de descargar el Archivo de actualización al Equipo y actúa como interfaz entre el operador y 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álisis de los posibles problemas y riesgos que se podrían encontrar a lo largo del circuito de actualización, con el fin de plantear soluciones a los mismos.

Básicamente, el principal riesgo que se encuentra en todo sistema de actualización de firmware es que ante un fallo o error en el mismo, el equipo que recibe la actualización quede imposibilitado 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 Archivo de actualización al usuario del Equipo, ya que se emplea un medio no seguro como lo es el e-mail. Es así que el Archivo de actualización puede caer en manos inapropiadas y que le sea aplicado un proceso de ingeniería inversa, con el fin de despejar el código fuente del mismo o introducirle modificaciones que alteren su funcionamiento. De igual modo, el Archivo de actualización puede corromperse en el camino sin necesariamente la participación de terceros. Se debería también, suministrar algún mecanismo que permita al Equipo autenticar que el Archivo de actualización es válido.

El segundo punto problemático, aparece durante la descarga del 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, o una interrupción momentánea haría que se pierda parte del Archivo de actualización, quedando este incompleto. Por otra parte, el ruido en el canal podría hacer que se corrompa el Archivo de actualización.

El tercer punto problemático está en el proceso de grabación del nuevo firmware en la memoria FLASH del

Equipo. Un corte de energía durante la grabación de la memoria FLASH sería fatal, como así también un apagado del equipo, ya sea intencional o no, ya que podría dejarlo inoperante. Otro problema, es que se grabe una versión de firmware 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 requerimientos iniciales, el modelo propuesto y el análisis de problemas y riesgos del modelo, con el fin de obtener una solución que satisfaga los requerimientos y elimine o al menos mitigue los riesgos 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 de e-mail, es el punto de mayor exposición pública de la información. Se deben asegurar aquí tres principios básicos de seguridad de la información: Privacidad, Integridad y Autenticidad.

La Privacidad de la información se obtendrá encriptando toda la información transportada que es útil al sistema. El algoritmo 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 muy simple, especial para sistemas embebidos ya que consume pocos recursos. Como contrapartida, existen varios estudios de criptoanálisis [2] del algoritmo, que lo hacen relativamente débil, pero para el caso en estudio la relación costo/beneficio que enfrenta un tercero en el caso de realizar un ataque contra el Archivo de actualización es lo suficientemente elevada como para disuadirlo de hacerlo. TEA es un algoritmo de cifrado por bloques, que emplea una estructura de tipo Feistel con 64 rondas, opera sobre bloques de 64 bits y emplea una clave de 128 bits. En el modelo se prevé que el Archivo de actualización saldrá encriptado y solo podrá ser desencriptado por el Equipo, el cual tendrá la clave de desencriptación previamente embebida. El modo de operación seleccionado para procesar los 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ón de Hash SHA-1 al Archivo de actualización, cuyo resultado se anexará al final del mismo y será comprobado por la aplicación “Updater” al momento de recibir el Archivo de actualización y como 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 al Archivo de actualización un “Magic Number” de 8 bytes, cuyo valor será fijo y conocido por el Equipo, quien al momento de desencriptar el Archivo de actualización controlará que en la posición esperada se encuentre dicho valor.

Todo lo mencionado hasta aquí, delinea la estructura que tomará el Archivo de actualización, y a medida que se avance en 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 de actualización desde la aplicación Updater al Equipo, se controlan empleando un protocolo de comunicaciones adecuado a las necesidades del caso en estudio. El protocolo será propietario y se implementará en base a capas, brindando al conjunto la funcionalidad esperada.

El protocolo deberá poseer la capacidad de segmentar el Archivo de actualización y enviarlo al Equipo en forma de paquetes. Se decidió segmentar al Archivo de actualización en segmentos de 1024 bytes, cada uno de los cuales se enviará dentro de un paquete.

Cada paquete tendrá un campo que será el CRC32 del segmento, lo que permitirá al Equipo detectar un paquete con datos corruptos al momento de recibirlo. El mecanismo de detección es bien simple: el Equipo al recibir el paquete calculará el CRC32 del segmento y luego lo contrastará con el CRC32 recibido con el paquete, si ambos difieren el segmento está corrupto.

Cada segmento tendrá un número de secuencia asociado (SEQ), lo que permitirá detectar si un paquete se perdió en el camino, o si llegaron segmentos en orden alterado. Se debe recordar que segmentar implica tener que reconstruir luego el Archivo de actualización y la pérdida o llegada fuera de secuencia de algún segmento conlleva a que el Archivo de actualización quede inutilizable.

Finalmente, a cada paquete se le agregará una cabecera conteniendo códigos de Comando y SubComando que permitirán identificar el paquete. La estructura general del paquete 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á reconocido por el Equipo con un paquete de ACK, con la estructura mostrada en la Fig. 3. Dentro del paquete ACK vendrá indicado el número de secuencia (SEQ) del siguiente paquete que espera recibir el Equipo. Cuando el número de secuencia del paquete de ACK se corresponde con el número de secuencia del paquete anterior más uno (SEQ + 1) será esto una indicació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úmero de secuencia del paquete fallido, siendo esto una indicación implícita de que se espera una retransmisión.

Fig. 3. Estructura general de un paquete ACK para descarga de Archivo de actualización.

La secuencia normal de funcionamiento, tal como lo muestra la Fig. 4, sería la siguiente: la aplicación “Updater” iniciará el proceso y enviará un Paquete de Inicialización con dos fines, primero detectar que el Equipo esté disponible para una actualización y segundo enviar información acerca del tamaño total del Archivo de actualización que se va a transferir y 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 transferencia enviando 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 al recibirlo el Equipo responderá con un ACK con número de secuencia 2. Así sucesivamente se continuará hasta completar el envío del Archivo de actualización completo.

Se deben considerar también condiciones anormales de funcionamiento, como por ejemplo: el Segmento solicitado no se recibe o se recibe con errores. En este caso el Equipo reenviará hasta tres veces el ACK solicitando el reenvío del paquete solicitado. Si el paquete esperado continúa sin recibirse como se espera, el Equipo abortará el proceso. Si el paquete se recibe bien, el proceso continuará normalmente. Del mismo modo, puede que la aplicación “Updater” no reciba nunca el ACK esperado o que este llegue erróneo, en este caso la aplicación “Updater” se limitará a esperar por un lapso de tiempo determinado la llegada del ACK, y una vez vencido el tiempo de espera será la aplicación “Updater” quien abortará el proceso.

CMD SCMD SEQ SEGMENTO CRC32

CMD SCMD SEQ

143


Como puede verse, el protocolo es simple pero funcional a la aplicación y brinda medios de seguridad y control para lograr 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 en

FLASH es la parte más crítica del sistema de actualización. Cualquier falla en el proceso de grabación dejaría al equipo inutilizado para funcionar.

Ante una falla en el proceso de grabación, debida a casos fortuitos como puede ser un apagado no intencional o un corte de energía, es deseable poder repetir el proceso cuando las condiciones estén dadas nuevamente. Esto lleva a la necesidad de tener una porción de código que siempre esté funcional y que no forme parte del área de memoria que se actualiza. A esta porción de código se la llamará “Bootloader”, y será un programa independiente, que se ubicará en una parte de la memoria FLASH que nunca se graba o modifica, ver Fig.8. El “Bootloader” será el programa encargado de llevar adelante el proceso de actualización. Entre las funcionalidades del “Bootloader” se tendrán: Recibir y reconstruir el Archivo de actualización, desencriptarlo, verificar la autenticidad del mismo y realizar el proceso de grabación en FLASH del nuevo firmware.

Otro riesgo oportunamente encontrado en el análisis del modelo, implicaba el caso en que se graba una versión de firmware válida para el sistema, pero incorrecta para el equipo, ya sea porque es antigua o con funcionalidades no soportadas por ese modelo. Sería interesante aquí, poder volver a la versión de firmware anterior del Equipo, para restituirlo a su estado inicial. En el caso en estudio, debido a que el Equipo cuenta con recursos de memoria suficiente, se destinó una parte libre de la memoria FLASH, para realizar una copia de la imagen del firmware actual, a modo de BackUp, previo a grabar la nueva imagen de memoria. Esto da la posibilidad, en caso que sea necesario, de que el “Bootloader” restituya la imagen de memoria original, retornando al Equipo a su estado inicial.

En base a estos recaudos, los riesgos asociados al proceso de grabación de memoria FLASH quedan mitigados.

D. Solución al requerimiento Nº3 – Restricción de uso del Archivo de actualización

El requerimiento Nº3 plantea la necesidad de poder restringir la aplicabilidad del Archivo de actualización a los Equipos. Esto implica que el fabricante tenga la posibilidad de decidir si un determinado Archivo de actualización puede ser utilizado para actualizar cualquier Equipo, un grupo determinado de ellos o un único Equipo en particular. Las razones para esta funcionalidad son varias, pudiendo citar razones comerciales: Solo el fabricante decide que Equipos serán actualizados y no terceros (distribuidores y servicio técnico), pudiendo generar versiones “a medida” especiales o exclusivas para un determinado cliente. Razones técnicas: la instalación temporaria de una aplicación de testeo y puesta a punto del Equipo. Otra razón sería el poder evitar

actualizaciones equivocadas de Equipos, con versiones no soportadas por determinado modelo, etc.

Aparecen aquí dos problemas. Primero, como identificar unívocamente a un Equipo en particular, y segundo, como lograr la restricción gradual de uso, desde un Archivo de actualización “universal” que aplica a cualquier Equipo, hasta uno exclusivo para un Equipo específico.

En el caso en estudio, la única información disponible en el Equipo que lo identifica unívocamente es el número de serie. Este se graba en un área especial de memoria Flash, la cual una vez bloqueada, no puede ser modificada nunca más.

El número de serie consta de cinco bytes, que especifican al Equipo por: Modelo, Año y Mes de fabricación, Lote e identificador (ID) dentro del lote, información suficiente para solucionar los problemas planteados al inicio de esta sección.

Se propone emplear una analogía a lo que se hace al enmascarar una dirección IP para formar subredes. Para este cometido, en el Archivo de actualización se incluirá el número de serie del Equipo destino de la actualización. También se agregará al Archivo de actualización una “Máscara” de cinco bytes, 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 Archivo de Actualización y también al Número de serie propio, grabado en FLASH en origen. En este contexto, “aplicar la máscara” implica realizar la operación AND bit a bit entre la máscara y el número de serie. Los resultados obtenidos luego de las operaciones de enmascarado serán comparados. Si coinciden, el Archivo de actualización es aplicable a ese Equipo y se continúa con el proceso de actualización. Caso contrario, el proceso 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 puede tomar el Número de serie y también la Tabla de Máscaras aplicables al caso en estudio. Dentro de la Tabla de Máscaras, la primera comenzando desde arriba, corresponde al caso más restrictivo, ya que el número de serie del Equipo y el que viene en 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, permite actualizar cualquier Equipo de un modelo en particular, y la sexta 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 partiendo de la imagen de memoria en claro (Firmware) hasta llegar a la estructura final que tendrá el Archivo de actualización, que se enviará al cliente. Al Firmware se le agregará una cabecera de datos, a ese conjunto se lo rellenará (PAD) para llevarlo a un tamaño múltiplo del tamaño de bloque que usa el algoritmo de encriptación TEA. A los Datos encriptados se les agregará el vector de inicialización. Ese conjunto es el que recibirá el Equipo a través del enlace RS232C. A dicho conjunto finalmente, se le agregará una cabecera de Información y el SHA-1 para comprobación de integridad, datos que serán extraídos y utilizados por la aplicación “Updater” al momento de 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ásica de la memoria. Toda la memoria FLASH está destinada al Firmware. Lo mismo ocurre con la memoria RAM.

El sistema de actualización necesita de una nueva distribución de memoria, como puede verse en la Fig. 7.

Se observa que luego de la restructuración la memoria FLASH queda dividida en 4 aéreas separadas. Cada una cumple 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á una pequeña porción de código encargado de inicializar el sistema (configurar vectores de interrupción y excepciones, arranque de reloj, etc.) y de detectar la condición de trigger, para determinar el modo de arranque del Equipo, esto es, en modo Normal o en modo Actualización. La condición de trigger se configura por hardware, mediante un Dip-Switch, que es la forma más simple y segura para ello.

Fig. 7. Reestructuración del mapa de memoria del Equipo, para satisfacer

necesidades del sistema.

Si se detecta un arranque en modo Actualización, el control del sistema se pasa al Bootloader, mediante un salto a la dirección de inicio del mismo. El Bootloader es la aplicación encargada de controlar y llevar adelante el proceso de actualización. El Bootloader es una aplicación independiente que implementa el protocolo antes descripto y se comunica con la aplicación “Updater” vía enlace RS232C.

Si se detecta un arranque en modo Normal, el control del sistema se pasa al Firmware, que es la aplicación que realiza la funcionalidad 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 pasos que se describen a continuación:

Una vez que el Equipo se inició en modo Actualización y el Bootloader tomó control del sistema, se procede a recibir el Archivo de actualización, segmento a segmento, los cuales se van 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ó por completo, se procede a procesarlo. Esto implica desencriptarlo, verificar el Magic Number para autenticar el Archivo de actualización, controlar la Restricción de uso en base a Número de 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 encriptados

8

IV Datos Encriptados

Conjunto de datos que recibirá el Equipo

20

Info Conjunto de datos que recibirá el Equipo SHA-1

Archivo de actualización

145


firmware recibido. Si todos estos pasos se verifican correctamente, se puede continuar con el proceso. Caso contrario el proceso se aborta y se vuelve a la condición de desocupado.

Recibido el nuevo Firmware, se procede a realizar un Back-Up del firmware actual en memoria FLASH, en el Área de Back-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 el nuevo firmware en el Área de FLASH destinado al arranque Normal del Equipo.

Finalizado ese proceso, el Equipo queda listo para ser encendido en modo Normal y correr la versión actualizada de Firmware.

VIII. CONCLUSIONES

Se planteó como eje central para este trabajo la actualización del firmware de un sistema embebido. Al caso general se le aplicaron las restricciones y necesidades propias de un caso real particular.

Se propusieron una serie de pasos lógicos para enfrentar el caso, como son, iniciar con un relevamiento y estudio de requerimientos, en base a los cuales se planteó un modelo para la solución del problema. Una vez verificada la validez del modelo, se procedió a analizar los riesgos emergentes del modelo que pudieran malograr el proceso. Una vez detectados los riesgos se procedió a plantear soluciones a los mismos de forma de eliminarlos o mitigarlos. Con toda esa información, se dió paso al diseño del sistema y planteamiento final de la solución. Esa serie de pasos lógicos posibilitaron un diseño sólido y aseguraron que al momento de la implementación no se debieran pagar costos innecesarios debidos a problemas no considerados tempranamente.

Se tuvieron en cuenta para el presente trabajo conceptos básicos de seguridad de la información, buscándose el equilibrio entre el costo de implementarlos y el costo que enfrentaría un atacante real al sistema.

Se planteó un modelo de protocolo de comunicaciones simple, pero eficiente y seguro para el caso real propuesto.

Finalmente, se propuso una forma de implementar y estructurar las distintas áreas de memoria y la forma en que debería llevarse adelante la actualización, incluyéndose la posibilidad 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 las aplicaciones 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-X NewDES, RC2, and TEA". Lecture Notes in Computer Science 1334: 233–246.

[3] NIST Special Publication 800-38. “Recommendation for BlockCipher Modes of Operation - Methods and Techniques” 2001 Edition

X. BIBLIOGRAFÍA

- Sloss, Andrew; Symes Dominic; Wright, Chris (2004). “ARM System Developer’s Guide – Designing and Optimizing 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 Error Detection Algorithms”

- W. Richard Stevens, (1993) “TCP/IP Illustrated, The Protocols”

146


Actualización parcial de software embebido en tiempo 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 resulta una 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ás complejas.

Palabras Clave; reprogramación; comunicación inalámbrica ; software embebido

I. INTRODUCCIÓN

En el contexto de los sistemas embebidos, con frecuencia es necesario y/o deseable actualizar cierta sección de código, por ejemplo para la corrección de bugs o modificación de algoritmos (por ejemplo: encriptación de datos, codificación o decodificació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 la actualización parcial de código sin necesidad de reprogramar completamente el sistema.

Se han propuesto e implementado varios mecanismos para modificar el código dentro de un sistema embebido. La técnica más adecuada a cada caso depende de las funcionalidades requeridas y también de las limitaciones en términos de recursos, ya sean de potencia de cómputo, memoria o incluso energía en casos de sistemas portátiles alimentados a pilas.

La primera opción, trivial, para actualizar el software es la reprogramación total del código, donde una nueva imagen

binaria del software remplaza el programa antiguo, por ejemplo vía JTAG o BSL (Bootstrap Loader). Éste es el mecanismo más sencillo y ampliamente utilizado, normalmente no se realiza en campo y es llevado a cabo por un usuario utilizando un PC.

Cuando se cuenta con una cantidad importante de equipos instalados, el método anterior tiene un alto costo y es de difícil implementación logística. Entonces resulta atractivo realizar la reprogramación en campo, transmitiendo el nuevo código al equipo 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ñas modificaciones. En estos casos es posible, en lugar de realizar un reemplazo total de la imagen del programa, cargar tan solo las diferencias entre el binario original y el modificado. Esta técnica está motivada por la necesidad de minimizar el costo energético de la reprogramación y tiene sentido en sistemas donde el costo asociado a la transmisión es varios órdenes de magnitud mayor al costo de procesamiento. De esta manera se minimiza el volumen de datos transferidos al sistema embebido a costas de un incremento en el procesado local para la obtenció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ódigo directamente ejecutable[2].

Una alternativa a los mecanismos mencionados anteriormente es la utilización de módulos cargables en sistemas que cuentan con un kernel o sistemas operativos diseñ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, se incorpora a un sistema ya corriendo, contiene referencias a variables y funciones externas al propio módulo. Estas pueden ser resueltas en tiempo de compilación en el host, proceso llamado pre-enlazado, o en el propio sistema embebido en tiempo de ejecución, llamado enlazado dinámico. Los módulos dinámicamente enlazados contienen referencias sin resolver, mientras que en los módulos pre-enlazados éstas ya fueron sustituidas 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 es completado en el sistema embebido a través de tablas donde los

147


nombres simbólicos se traducen en direcciones absolutas. El sistema operativo SenSpireOS [5] contempla la funcionalidad de enlazado dinámico de módulos SELF (basados en el formato estándar ELF) mediante una tabla de direcciones, con la finalidad de realizar la reprogramación parcial de los nodos de una red de sensores inalámbricos. [6]

La utilización de kernels o sistemas operativos con estas funcionalidades normalmente trae aparejado un incremento significativo en la complejidad del software embebido, un incremento en el total de código y un overhead de tiempo de ejecució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 arquitecturas de software donde no se cuenta con un kernel con funcionalidades especiales donde se realiza la actualización de la aplicación manteniendo las bibliotecas. El objetivo es minimizar el costo de reprogramación a través de una implementación con baja cantidad de memoria y despreciable overhead, y que sirva como primer acercamiento a alternativas más complejas.

II. PROPUESTA

En base a las consideraciones realizadas, se propone el uso de módulos pre-enlazados para permitir, en tiempo de ejecución, la modificación parcial del software del sistema. El objetivo es actualizar la aplicación manteniendo las bibliotecas utilizadas por la misma. Para ello es necesario que el sistema a actualizar reciba a través de una interfaz de comunicación el código binario de la nueva aplicación, guardar el mismo en la memoria, típicamente no-volátil (FLASH), para finalmente comenzar a ejecutar la nueva versión. Para la generación de dicho código binario es necesario contar con herramientas adecuadas.

Es conveniente aclarar que debe tenerse en consideración el contenido existente en la memoria del sistema que se encuentra ya instalado en campo. Una opción sería diseñar un esquema, de cierta complejidad, que a partir de los archivos ejecutables del sistema existente y de la nueva aplicación, identifique y extraiga la porción de ejecutable a actualizar. Esto podría realizarse mediante la edición de los archivos ELF (Executable and Linkable Format) asociados. Sin embargo se optó por una solución más sencilla mediante la utilización de opciones avanzadas del linker. La idea es usar una tabla de direccionamiento indirecto, al igual que en soluciones anteriormente mencionadas, para permitir hacer uso de las bibliotecas sin necesidad de disponer de ellas al momento de compilar y enlazar la nueva aplicación. Para permitir la actualización de la aplicación sin sobrescribir las bibliotecas, es necesario organizar las memorias de manera de poder guardar en áreas diferentes aplicación y bibliotecas. Esta solución, a diferencia de la edición de los archivos ELF, requiere reprogramar la aplicación en forma completa. En principio puede considerarse un costo aceptable debido a la sencillez del método en comparación con otros, más si se considera que el tamaño de la aplicación, en general, es mucho menor que el tamañ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 las llamadas desde la aplicación a funciones y los accesos a variables de dichas bibliotecas precargadas en el sistema.

Para realizar lo anterior se utilizó una tabla de direccionamiento indirecto, con el fin de realizar la interacción entre 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 las funciones públicas pertenecientes a las bibliotecas. De este modo, la llamada a una función de las bibliotecas desde una nueva aplicación puede realizarse mediante una llamada a la dirección de memoria almacenada en el lugar correspondiente de la tabla, permitiendo el acceso a la función en forma indirecta.

En la figura 1 se muestra el mapa de memoria en el primer paso cuando las bibliotecas y la tabla han sido cargadas en memoria. Luego se muestra el mapa de memoria resultante después de la actualización, donde se puede apreciar el flujo de invocación para una función desde la aplicación hasta la biblioteca correspondiente.

En principio se podría asumir que es posible crear el nuevo software y simplemente enviar al sistema la porción de código relativa a la aplicación. Sin embargo, nada garantiza que el locator ubique las funciones de las bibliotecas en las mismas direcciones de memoria que lo hizo anteriormente y en consecuencia las llamadas desde la aplicación a las funciones se realizarían a una dirección de memoria diferente a donde estas se encuentran. Mediante el uso de la tabla, es decir, la nueva aplicación realizando las llamadas a la biblioteca a través de ésta, se evitan este tipo de inconvenientes ya que la misma contiene siempre las direcciones reales donde las funciones 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 la nueva 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 las funciones pre-cargadas. Por ello éstas últimas deben estar separadas en memoria del resto, para así tener la seguridad de que no sean sobrescritas. Para conseguirlo, una opción de organizació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 logra guardar completamente la nueva aplicación sin sobrescribir la aplicación actual antes de conmutarlas. También es posible sobrescribir la aplicación corriente con la nueva, ya que todas las rutinas necesarias para realizar la conmutación (recepción y escritura en memoria) residirían en la región destinadas a las bibliotecas. El código, las constantes y los valores de inicialización residen en FLASH mientras que las variables residen en RAM, por lo que la organización de la memoria debe contemplar ambas. En la Figura 2 se muestra un posible mapeo 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 segmentos involucrados

C. Recepción de datos y puesta en marcha de la nueva aplicación

Tal como fuera dicho anteriormente, en el proceso de actualización, primero debe establecerse una comunicación entre el sistema embebido (mediante una interfaz de comunicación) y el sistema que posea el código de la nueva aplicación ya compilada. Este sistema puede ser, en principio, de muy diversos tipos, tanto un PC como otro sistema embebido.

Posteriormente, los datos correspondientes a la nueva aplicación son recibidos por el sistema embebido y almacenados en memoria volátil, para luego ser grabados en

memoria persistente para finalmente poder ser ejecutados. El grabado en memoria persistente puede sobrescribir el código anterior, minimizando así la cantidad de memoria requerida, o puede ser alojado en un lugar diferente, pudiendo retornar a la aplicación anterior en caso de problemas tanto con el grabado como en el funcionamiento de la nueva aplicación.

Finalmente, antes de que la nueva aplicación pueda ejecutarse, es necesario llevar al sistema a un estado inicial, de modo de asegurar el buen funcionamiento de los servicios del sistema 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 de desarrollo ez430-RF2500 [7], compuesto por dos dispositivos que cuentan con un microcontrolador MSP430F2274 y un transmisor/receptor de radio CC2500, permitiendo establecer una comunicación punto a punto entre ellos. Para el desarrollo de las aplicaciones, se cuenta con bibliotecas provistas por el fabricante, en particular con un stack de comunicación, SimpliciTI [8], que proporciona un protocolo de comunicación simple que permite cumplir con el objetivo. Se utilizó el entorno de desarrollo IAR Embedded Workbench 6.0 [9], aunque también soporta el Code Composer Studio [10]. De las diferentes 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 las funciones públicas utilizadas por la aplicación, siendo éstas las que necesariamente deberán ser incluidas en la tabla de direccionamiento indirecto.

IV. IMPLEMENTACIÓN

A continuación se describen algunas consideraciones importantes a la hora de la instrumentación de la propuesta, en especial, las relativas a la implementación particular a este caso de estudio y del conjunto de herramientas (compilador, linker, etc.) utilizado.

A. Primeras consideraciones

Al momento de guardar la nueva aplicación en memoria no volátil, puede ser necesario realizar un borrado total el segmento involucrado. Esto depende de las limitaciones que presente el microcontrolador utilizado a la hora de escribir en este tipo de memorias. Por ejemplo, en algunos microcontroladores se permite el borrado de bits pero no setearlos. 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 en FLASH debe ejecutarse desde RAM. Para esto existen dos alternativas, guardar dicha rutina en RAM, o crear una copia en RAM justo antes de utilizarla. En ambos casos será necesaria una rutina auxiliar que se encargue de alojarla en RAM. La segunda opción es interesante cuando el sistema cuenta con muy poca RAM y se desea optimizar su utilización, pero genera overhead a la hora de requerirla (al actualizar). Se mencionaron dos alternativas a la hora de guardar la nueva aplicació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 miembrosdirfunctions;

__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 rutina de actualización conserve el control del sistema hasta que la nueva aplicación esté completamente cargada en memoria y se haya llevado el sistema al estado inicial, para finalmente ceder el control a la nueva aplicación. El otro caso presenta más flexibilidad, en el sentido de que la actualización podría realizarse 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. La inicialización asociada a la configuración de periféricos, dispositivos conectados al microcontrolador (como por ejemplo la radio) que es realizada a través de llamadas a funciones, no presenta problemas. Sin embargo durante el start-up, antes de ejecutar la primera línea del “main”, se asigna el valor inicial a las variables estáticas inicializadas (segmento data) y se resetean 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 la actualización, y también el de las bibliotecas precargadas, o en forma manual, agregando explícitamente al inicio del código de aplicación el llamado a las funciones correspondientes para copiar los valores iniciales desde memoria no volátil a RAM para el caso de variables inicializadas y para el borrado, para las 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 las funciones. También fue necesario definir los tipos punteros a dichas funciones.

En el archivo de encabezado, tabla.h, se definen los tipos a utilizar, los punteros y la estructura de la tabla. En el archivo tabla.c se define la tabla, donde se especifica explícitamente su ubicación en memoria y la función de inicialización. En las Figuras 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 y al ejecutarse la función table_init() quedan guardadas en la misma las direcciones donde se encuentran las funciones.

Para usar los servicios de las bibliotecas, la nueva aplicación es compilada utilizando un archivo de encabezado donde se declaran todas las funciones públicas de las bibliotecas y un archivo donde se definen dichas funciones de manera de acceder al código respectivo a través de la tabla, tal como 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 la utilización de segmentos de memoria creados específicamente para la aplicación, con el fin de independizar en memoria el có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 opciones específicas del linker [11]. Ello es posible modificando un archivo 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 a cada área.

Figura 7. Definición de segmentos.

Una vez creados los segmentos deseados desaparecen los problemas asociados a la sobrescritura de datos y se tiene campo fértil para intentar recibir una nueva aplicación. La recepción de la nueva aplicación se realiza a través de la UART 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 a la 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 en RAM para su ejecución. Las rutinas mencionadas anteriormente, específicas para el microcontrolador MSP430, forman parte de los códigos ejemplo suministrados por Texas Instruments [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 bytes aproximadamente. Por lo tanto, en caso de que la misma supere dicho límite, deberá ser enviada de a fragmentos. En este caso, como fue comentado, puede resultar necesario pasarle el control a otra rutina, que espere hasta que se termine dicha transferencia para evitar problemas de datos corruptos.

V. RESULTADOS

El sistema se fue probando y verificando con cada paso de la implementación. La metodología fue básicamente la misma para todos los casos, “debbugear” la aplicación, prestando atención al flujo del programa y los cambios producidos en la memoria y registros del microcontrolador.

La primer prueba consistió en verificar en memoria que la tabla se generaba correctamente, es decir, que se encontrara en la ubicación correcta y se guardaran en ella las direcciones donde efectivamente se encontraban las funciones en cuestión. Para esto se tuvieron que superar varios inconvenientes, como la 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 direccionamiento indirecto propuesta. Para esto se cargó en memoria el código perteneciente al stack de comunicación y se generó la tabla, se configuraron opciones de la plataforma de desarrollo para que se mantenga la información en la memoria y se cargó la aplicación utilizando el direccionamiento indirecto. Es decir, se compiló únicamente la aplicación con los archivos de direccionamiento indirecto y se cargó en memoria. Ejecutando paso a paso la aplicación se verificó que las llamadas a las funciones efectivamente pasaban por la tabla, llamando correctamente a las funciones que debía, como era esperado.

La rutina de recepción de datos se probó enviando datos hacia la UART del sistema, utilizando para la comunicación el programa Hércules (freeware) [13]. Se verificó la llamada a la rutina de atención a la interrupción de la UART y la correcta recepción de los datos enviados, almacenados en RAM.

Respecto a la escritura en FLASH, se verificó el correcto funcionamiento de las funciones CopyRoutine() y FlashWrite() mencionadas anteriormente. Para el caso de CopyRoutine(), se observó la memoria ocupada por FlashWrite() y se comparó byte a byte con lo que se había copiado en RAM, verificando que no hubieran errores. Para FlashWrite(), se optó por mover a FLASH un arreglo conocido hacia una zona no inicializada de memoria y se constató su correcto funcionamiento.

Para la prueba del sistema completo se compiló y cargó el stack junto con una primera aplicación y la tabla en dos

dispositivos, un receptor y un transmisor. La información correspondiente a la salida del linker se presenta en la figura 8. Luego se compiló una nueva aplicación junto con los archivos de acceso indirecto y se cargó en el transmisor, como se observa en la figura 9. Se constató el correcto funcionamiento del sistema con la nueva aplicación según los cambios de funcionalidad introducidos.

Figura 8. Disposición de segmentos en memoria y tamaño de código, caso directo.

Figura 9. Disposición de segmentos en memoria y tamaño de código, caso indirecto.

151


Se observó que el código de la aplicación corresponde al 8% (576 bytes de código más 236 bytes de datos) del total de la aplicación incluyendo las bibliotecas (como se observa en el resumen de memoria de la Figura 9). En tiempo de ejecución, cuando se realiza una llamada a una función, se posee un overhead de ejecución de 2 instrucciones “jump” respecto al caso original. A continuación, en la Tabla 1, se presentan para diferentes 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 a la aplicación y finalmente el porcentaje que representa la aplicación respecto al total. Estas valores fueron obtenidos a partir del análisis del mapa de memoria al crear las distintas aplicaciones y sumando el espacio de memoria requerido por la tabla de direccionamiento indirecto. Puede observarse que la aplicación más el overhead asociado a la técnica representa entre el 3% y el 7% del total del software embebido de aplicaciones últimas analizadas, siendo la aplicación “Simple peer to peer”, implementada y probada, la que resulta en el mayor peso relativo, 8%. Esto significaría un ahorro energético en costo de reprogramación de más de 90% en todos los 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%

Polling whit Acces Point (Receiver)

7756 544 7.0%

Polling whit Acces Point (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 Data Hub(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 la reprogramación parcial que permite la actualización de la aplicación de manera remota utilizando comunicación inalámbrica. Se logró una implementación que ocupa poca cantidad de memoria y tiene despreciable overhead de ejecución.

Se diseñó e implementó un sistema basado en la metodología propuesta, pudiendo verificar la confiabilidad de la misma.

Se han contrastado los resultados obtenidos contra los del sistema sin direccionamiento indirecto obteniéndose para este caso particular un costo en memoria del 8% del total de espacio ocupado por el código original. Es decir que para realizar la actualizació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 de retransmisión que oscila entre el 3% y 7% del código total embebido.

REFERENCIAS

[1] Dunkels, A., Finne, N., Eriksson, J., and Voigt, T. 2006. Run-time dynamic linking for reprogramming wireless sensor networks. In Proceedings 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 Information Technology (ECTI), Thailand, 13-14 May 2004.

[3] A. Dunkels, B. Grönvall, and T. Voigt. Contiki—a Lightweight and Flexible 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. A Dynamic 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: A Predictable, Flexible, and Efficient OS for Wireless Sensor Networks.”, 2007.

[6] W. Dong, C. Chen, X. Liu, J. Bu, and Y. Liu, “Dynamic Linking and Loading 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, disponible http://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) Integrated Development 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 and Function 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ñales Sensoriales en Sistemas Embebidos

Gustavo Monte, Kector Kessel, Norberto Scarone, Cesar Almendra

Universidad Tecnológica Nacional - Facultad Regional del Neuquén – Plaza Huincul - Argentina

[email protected]

Resumen- Hoy en día es muy común encontrar el prefijo inteligente en los sistemas que el hombre desarrolla. Encontramos desde fusibles inteligentes hasta autopistas inteligentes. La razón de esta “inteligencia” es que dada la complejidad de los sistemas actuales, los diseñadores la han trasladado a los dispositivos con el objetivo de simplificar la operación al usuario final. Un ejemplo típico es la filosofía Plug and Play. Aprovechando la capacidad actual de los sistemas embebidos, este trabajo presenta técnicas y algoritmos con el objetivo de sumar inteligencia al proceso de muestreo de una señal analógica. Empleando técnicas de sobremuestreo e interpolación adaptiva se logra analizar la señal, inferir estados, predecir comportamientos y validar la señal digitalizada. La señal a digitalizar es un proceso aleatorio, lo único que se conoce de antemano es su limitación en ancho de banda que le impide tomar valores totalmente arbitrarios entre muestras. Al aumentar la frecuencia de muestreo se restringe la aleatoriedad hasta quedar reducida a un espacio de escasas dimensiones que permite realizar un análisis certero sobre la señal. Se presentan resultados experimentales desarrollados en microcontroladores para validar los algoritmos propuestos.

Palabras Clave Sensores Inteligentes, sobremuestreo, muestreo inteligente.

I. INTRODUCCIÓN

Los sistemas embebidos realizan sus decisiones en base a las señales de los sensores incluidos en él. Las señales provenientes de los sensores es la fuente de información disponible para cumplir el objetivo de diseño de un sistema de instrumentación y/o control. Estas señales proporcionan la abstracción del mundo real. Una señal es una entidad cuantificable de alguna forma de información. Más valiosa es la señal cuanto más información se encuentra embebida en ella. 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 lo tanto 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 cambio de una señal determina el intervalo de tiempo mínimo que se necesita conocer a la señal para poder inferir su comportamiento dentro él.

Figura 1. La información que transporta una señal generalmente se encuentra oculta. Procesar una señal implica extraer la información embebida 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 una señal en digital es realizada por el conversor analógico – digital que es el elemento principal de interfase entre el mundo 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 incluyen muestreo 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. En este caso,, muestreo uniforme, que transforma la señal en una secuencia ordenada de números.

t

X(t)

t

Conversor A/D

Mundo real

t

0010111000110010001100010100010001000000001100100011000100010111

Xn

Mundo digital

INFORMACIÓN

CAPA OBSERVABLESEÑAL

Procesar una señal implica extraer 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 el tiempo 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 el teorema 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 una forma 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 max2 [ (2 ( ) (2 )]2N

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

1max2 (2 )N sen f t

max

2Nsff

¿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ñal entre 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 una

combinació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 sus muestras 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

max( ) (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 plataforma de análisis para inferir comportamientos de la señal muestreada. Es importante recalcar que los tres vectores, en una estructura de de buffer circular, se obtienen en tiempo real 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 la Fig. 6 se observa una señal ejemplo. Considerando solamente el 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 un crecimiento 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 embebido es conciente de la señal que esta digitalizando, prácticamente en tiempo real. Es importante remarcar que si el error de interpolación tiende a un LSB, la probabilidad de ocurrencia de los segmentos “a”,”b”,”c” y ”h” tienden a cero. Bajo esta condición, y con la señal suficientemente sobremuestreada, el comportamiento de la señal queda especificado solamente por los cuatro segmentos “d”, “e”,”f” y ”g”.

El análisis del comportamiento macroscópico de la señal es posible mediante las secuencias de patrones de clases de segmentos. Por ejemplo, la ocurrencia consecutiva de segmentos tipo “g” indica que la señal se esta estabilizando a un 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 él mismo 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 del segmento más corto en dicha porción de la señal. La longitud de los segmentos es un parámetro importante ya que determina como se aparta la señal de un comportamiento lineal. La Fig 7. Detalla la detección de algunos comportamientos macroscópicos.

s e ñ a ls e n s o r ia l

X t)

fs s o b re m u es treo

S e g m e n ta c ió n t ie m p o rea l

R es u ltad o :V e c to r d e m u es tra s es e n c ia le s y

v e c to r d e p o s ic ion tem po ra l

A ná lis is in tras e g m e n to

R e s u l ta d o :V e c to r d e c las e s a ,b ,c ,d ,e ,f,g ,h

A ná lis is in te rs e g m e n to

R es u ltad o :D e tec c ió n d e p a tro ne s :

E x p on e nc ia l, s inu s o id a l, ru ido s o , fre c ue n c ia d e m ue s tre o o p tim a , ru ido im p u ls iv o , p re d ic c ió n ,

c o m p re s ió n… .

R es u ltad o : v e c to r d e s e ñ a l c o n red u nd a nc ia

a

b

h

g

f

e

d

c

c o n s t a n t e

l i n e a l +

l i n 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ó un sensor de temperatura inteligente de bajo costo cuyo circuito se observa en la Fig 8. El microcontrolador es un 12F683 de Microchip que posee conversor A/D de 10 bits. La sonda de temperatura esta formada por tres diodos 1N4148 y posee interfase serie RS232 optoacoplada. El costo del sensor es inferior 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 Tx 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)tdx Xss Xi dt T

La pendiente de los segmentos puede emplearse como la aproximación de la derivada en (8) aplicada en los puntos a y b. Si consideramos la derivada en el punto a y empleando este punto como valor inicial obtenemos:

(9) Xss Xia Ma T

Donde YaMa 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 Mb T

Donde YbMb 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 y

clasificación de segmento implementado en lenguaje “C” de CCS 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 segmento a 48 muestras.

Un microcontrolador adecuado para estas técnicas es el dsPIC33FJ12GP de Microchip, el cual fue diseñado para aplicaciones de sensores inteligentes, permitiendo digitalizar a 1.1 millones de muestras por segundo.

C o m p orta m ie n to e x p o n en c ia l es ta b le : S e cu e n c ia c on s e cu t iv a d e s eg m e nto s tip o “g ” d e lo n g itu d es

cre cien te s.

C o m p o rta m ie n to e xp o n e n cia l in te s ta b le : S e cu e n cia c o n se c u tiv a d e s e g m e n to s t ip o “d ” de lo n g itu d e s

d e c re c ie n te s .

C o m p orta m ie n to o s ci la to r io : S e c u e nc ia d e s e g m e n to s tip o “g ” , “e ”, ” f” ,”d ” . L o s m á x im o s o c u rre n e n la un ión d e “g” ,”e ” y los m ín im os e n la u n ió n d e “ f” y”d ” . A n a liz a n d o lo s v alo re s d e los m á xim o s y

m ín im o s s e d e te rm in a s i la o sc ila c ió n e s c re c ie n te o d e c re c ie n te

R u ido im p u ls iv o: D e te rm in a d o p o r la a bru p ta re d u cc ió n d e la s lo ng i tu d e s d e lo s se g m en to s.

D ete cc ió n d e pa tro n e s e s pe c ifico s : E n es te ca s o e l p a tró n Q R S 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 ha cambiado no solo la topología de nuestros diseños, sino además la forma de concebirlos. Algo que en el pasado era inviable pasa a ser factible para luego transformase en natural.

Naturalmente los sistemas embebidos deben muestrear en

forma inteligente. Una propuesta de normalización de estos algoritmos fue presentada en [7]. El intercambio de información mediante un lenguaje común entre sensores de un sistema permite el aumento de confiabilidad, la predicción anticipada de estados anormales, la detección de patrones normales y anormales y el aprendizaje de patrones en forma automática.

Los algoritmos presentados son simples pero muy efectivos.

Capturan la esencia de la señal muestreada, y representan la información presente en ella. Si el error de interpolación tiende 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.

REFERENCIAS

[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, April 1996.

[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 circuit testing”. 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 International Conference . pp 1617-1622. ISBN 978-1-4244-5697-0/10.

.

158


Controlador de carga para un sistema fotovoltaico aislado

Daniel Hoyos, Maiver Villena, Víctor Hugo Serrano, Federico Farfán, Carlos Cadena

Universidad Nacional de Salta INENCO Instituto de Energías Renovables

Salta, Argentina [email protected]

Telmo Moya Universidad Nacional de Salta

Salta, Argentina [email protected]

Resumen — El siguiente trabajo tiene por objeto analizar los componentes más importantes que influyen en el diseño de una instalación fotovoltaica aislada que incluye un controlador fotovoltaico y un inversor de 12V a 220V, proponer un controlador de carga que maximice las prestaciones del sistema, proteja y aumente la vida útil de cada uno de los componentes. El sistema se desarrollará utilizando un microcontrolador.

batería, controlador de carga,inversor, microcontrolador, panel fotovoltaico

I. INTRODUCCIÓN Un sistema fotovoltaico como se muestra en la Fig. 1 está

compuesto por: panel fotovoltaico, batería, controlador de carga, inversor, que transforma corriente continua a corriente alterna en 220 V y la carga del sistema.

Figura 1. Esquema general de un controlador fotovoltaico

El panel fotovoltaico tiene una curva de funcionamiento como la de la Fig. 2 y es el resultado de asociar un conjunto de células fotovoltaicas en serie y en paralelo. La descripción eléctrica de la célula [2] responde a la siguiente ecuación:

I = Il - I0 [exp ((V + I Rs ) / n Vt) -1] - (V + I Rs ) / Rp (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

Rs: resistencia serie,

Rp: resistencia paralelo,

n: factor de idealidad del diodo.

La corriente fotogenerada se determina en función de las dimensiones de la célula, su área A en cm2, la densidad de corriente de cortocircuito Jsc en A/cm2, la temperatura de trabajo 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 la corriente de cortocircuito y la gráfica se desplaza hacia arriba.

Si se supone que el sistema a controlar es aislado y se utiliza fundamentalmente para dar iluminación nocturna, la situación habitual en nuestro país, el diagrama de consumo eléctrico es el mostrado con trazo discontinuo en la Fig. 3, mientras que la radiación solar tiene su pico alrededor de las 13 horas [1], por lo tanto la corriente que puede suministrar el panel responde a una distribución del tipo mostrado en la misma Fig. 3. Se utilizó un modelo de radiación de día claro

159


modificado, el cual responde en forma aproximada a la región montañosa de Argentina [1]. De la observación de los gráficos se puede inferir que el ciclo de carga y descarga de la instalación es de 24 horas en el cual la batería se descarga durante la noche y el atardecer para cargarse durante el día según la radiación incidente. El ciclo de descarga no puede controlarse 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ía anterior y devolverla si se puede en el día siguiente. Este algoritmo no busca obtener la máxima energía del panel, debido a que basa su funcionamiento en optimizar el ciclo de carga de la batería el cual es el elemento más débil de un sistema 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 y entregada 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 de Coppeti [2], el cual es muy sencillo y funciona aceptablemente sobre un número muy grande de baterías presentes en el mercado local. La elección de la misma se realiza en función del parámetro capacidad en Amper-hora que sería la máxima energía que puede entregar la batería hasta descargarse completamente. La energía útil es un valor que se encuentra afectado de un coeficiente que para las baterías analizadas en este 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 carga invierte energía para su propio funcionamiento lo que implica una pérdida de carga, por ello se define un coeficiente denominado eficiencia; el cual puede ser del orden de 0,9 en los acumuladores que se están utilizando. La evaporación del electrolito es función de la temperatura ambiente y de la tensión de la batería. Una aproximación de primer orden de este 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ía empieza a gasear y t es la temperatura ambiente. Se debe tener en cuenta que no es conveniente para la batería una carga rápida y tampoco es conveniente para el panel tener largos períodos de tiempo, a circuito abierto, o en cortocircuito (como es el caso de los controladores convencionales) por lo tanto es conveniente 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 corriente entregada a la carga, la tensión de batería y la temperatura ambiente. El bloque de potencia es el encargado de suministrar corriente a la batería utilizando modulación por ancho de pulso y transistores HEXFET IRFZ44N. Para controlar la carga solamente se desconecta cuando la tensión de la batería es menor que 11,3 V o la corriente es mayor que un determinado valor.

A. Medición

Un esquema del circuito de medición de corrientes y tensiones del controlador es el mostrado en la Fig. 4, en el mismo se puede observar que se mide la corriente usando la diferencia entre dos tensiones.

Figura 4. Esquema del circuito de medida de corriente

El valor de las resistencias de shunt depende de la corriente máxima del controlador de carga y de la potencia máxima que se desea disipar en las baterías. . Los valores de R1 y R2 son críticos ya que un valor de resistencia elevado disminuye el rendimiento del sistema y un valor muy pequeño disminuye la sensibilidad de la medida de corriente. El sistema de control está alimentado por una tensión de 3.3V, siendo esa la máxima tensión que puede medir. Por lo tanto se debe atenuar la tensión para que pueda ser medida a costa de disminuir la mínima corriente que se puede medir. Para no perder resolución se utiliza un amplificador diferencial, con ganancia unitaria de forma que ninguna tensión sea superior a 7 V para evitar que el amplificador 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 los distintos parámetros del circuito es [1]

Nc=k2(k1.R1I+V1).2n/Vref (4)

En donde:

Nc= número de cuentas

k1= ganancia del amplificador diferencial

k2=Ganancia del amplificador inversor

R1= resistencia de shunt

n= número de bits

Vref=Tensión de referencia

V1= Tensión para evitar la saturación de los amplificadores 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 como elementos de control dos MOSFET de potencia. El transistor T1 se encarga de controlar la carga de la batería mientras que T2 se utiliza sólo para desconectar la carga en caso de sobre corriente o que la batería se encuentre muy descargada.

Figura 6. Circuito de control de potencia

Este circuito fue modificado y se probaron nuevas configuraciones con MOSFET tipo P y tipo N siendo la mostrada en la Fig. 6 la más práctica cuando se requieren corrientes mayores.

C. Control

El bloque de control está compuesto básicamente por un microcontrolador 16f877 y el circuito puede verse en la Fig. 7. La medición de la temperatura se realiza utilizando un circuito integrado especialmente diseñado para este fin, el LM35 que tiene 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 el canal 0 del microcontrolador, “Vcp” que es la tensión que representa la corriente del panel en el canal 1, “Vcc” que es la tensió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 la temperatura es sensada por el canal 4. Las señales de salida serán las tensiones: T1 encargada de controlar la corriente de carga de la batería, utilizándose para esta salida el módulo 1 de modulación por ancho de pulso y T2 que controla la descarga de la batería y sólo se utiliza para desconectar la batería en caso de sobrecarga, cortocircuito o batería muy descargada. El sistema tiene dos leds que informan si la batería está cargada o no.

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 24 horas la carga consumida por el usuario debe ser restituida al 100 %. De esta forma el sistema entrega corriente 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 una sensibilidad 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 el día anterior. En la Fig. 8 se puede observar la distribución de la corriente del panel a lo largo de un día típico sin nubosidad, para realizar el control se supuso que la cantidad de corriente que puede entregar el panel es una función triangular, como se observa en la figura, siendo ésta una aproximación de primer orden con respecto a la distribución real. El valor máximo de esta distribución es el correspondiente a la hora de máxima radiación, el mediodía solar. Por lo tanto la carga que puede entregar este sistema será igual a la máxima corriente que puede suministrar el panel multiplicado por la duración del día dividido 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 si se desea reponer la carga a lo largo del día, se debe entregar en cada intervalo de tiempo la relación entre la carga consumida en el día anterior y la carga máxima posible. Se utiliza con este fin modulación por ancho de pulso (PWM), la cantidad de corriente entregada en PWM es proporcional a la relación entre el periodo de la función y el tiempo de alto.

Se mide la corriente de carga de la batería y la corriente de descarga, se integran estos valores a lo largo de un ciclo de un el día anterior se determina el periodo y el tiempo de alto de la modulació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 cuatro días de operación del controlador de carga, CDA significa carga consumida el día anterior por el sistema en Amper hora, PWM modulación por ancho de pulso, CNR carga no restituida a la batería al final del día por el sistema y CG energía consumida por la carga durante el día. Las funciones mostradas en la grafica son: “Ifoto” que es la corriente que puede

162


suministrar el panel, “cargar” que es la energía en Amper hora que el panel está enviando a la batería, “Carga” es la corriente en Amper que esta consumiendo la instalación y “amperc” es la emergía consumida por la instalación a lo largo del día.

El controlador de carga mide la energía consumida por la instalación durante la tarde y la noche restituyendo este valor durante el día siguiente, Fig. 9a. Cuando la energía consumida supera la carga que puede restituir en un día, Fig. 9b, el controlador restituye la carga en los días subsiguientes, Fig. 9c y Fig. 9d. Si se observa en la Fig. 9c el controlador aprovecha toda la energía disponible siendo la relación PWM = 1 en caso que la energía requerida sea mayor que la que puede aportar, en Fig. 9d se encuentra en régimen normal.

Este algoritmo de control es muy sencillo, sólo necesita que al comenzar a operar el sistema se reinicie temprano a la mañana del primer día, cuando la radiación es casi cero y no se comenzó a consumir energía de los acumuladores.

Pero tiene algunos problemas, por ejemplo si una nube disminuye notablemente la radiación solar el sistema no puede acomodarse para reponer en el día la energía consumida. El algoritmo de control no distingue en qué momento del día se encuentra el controlador. Por lo tanto se realizó una modificación, se define como “noche” al estado en el que el panel fotovoltaico entrega una corriente menor a 0,1 A, durante ese tiempo pwm = 1, “amanecer” cuando la corriente supera con pendiente positiva 0,1 A, “atardecer” cuando la corriente es menor a 0,1 A con pendiente negativa, la “duración del día” es la diferencia entre amanecer y atardecer y la “mañana” la primera mitad del día. Tarde la segunda mitad del día. Se calcula la relación de modulación por ancho de pulso para la mañana y la tarde de forma que cada una debe restablecer la mitad de la carga del día.

V. PROGRAMA DE CONTROL

El microcontrolador PIC16F877 se programa en lenguaje de maquina, se utilizó la interrupción del contador TMR0 para implementar un reloj. TMR0 es un contador que una vez configurado está continuamente contando y cada vez que desborda hace un llamado a una interrupción, esta subrutina incrementa un conjunto de contadores en cascada: fracción de milisegundos, milisegundos, minutos, 15 minutos, horas y días. Así, cuando el contador “segundos” llega a 60 se borra y aumenta “minutos”, cuando “minutos” se pone a uno se realiza la medición de los distintos parámetros, corriente de panel, corriente de carga, tensión de batería, temperatura y la integración de las corrientes. En la hora 0 se realiza el cálculo de la relación de modulación de pulso y duración del día anterior en cantidad de periodos de 15 minutos. Cuando la corriente de panel supera los 0,1 A y la corriente anterior es menor a ese valor se determina el amanecer y se inicia la cuenta del día siguiente, durante este tiempo la relación de

modulación es cero. Cuando la corriente de panel baja de 0,1 A, 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 se determina el mediodía, donde se recalcula la relación de modulación PWM.

Por ejemplo un día de 10 horas tendrá 40 períodos de 15 minutos y la energía será proporcional a 151*40/2=3020 cuentas, un día de 14 horas tendrá como máximo teórico 8456. La energía consumida por la carga también es proporcional a la cuenta obtenida de sumar todas las cuentas obtenidas al medir la corriente en la carga. Por esta razón se divide el má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 bits y se lo utiliza como período de PWM, mientras que el tiempo de alto es la cuenta de la energía consumida por la carga dividido por 32. Este valor se reajusta al mediodía.

VI. CONCLUSIONES

El algoritmo de control analizado es muy sencillo de implementar y no requiere microcontroladores demasiados complicados. Fue probado sobre una plataforma con un microcontrolador PIC 16F873 funcionando aceptablemente. También se desarrollo una versión en C para microcontroladores de la familia 18f4550. El algoritmo de control de este sistema fue simulado y probado como se muestra en la Fig. 9. El sistema fue probado en laboratorio simulando cargas y conectando paneles fotovoltaicos. La lógica de control del controlador fue desarrollada para un panel, pero cambiando 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 de energía del controlador. El rendimiento del sistema es de 0,93 con HEXFET. Se probaron distintos transistores, el 2N3055 controla hasta 2 paneles, MJ15004 controla hasta 3 paneles. Al utilizar transistores bipolares el rendimiento disminuye hasta 0,9; pero el costo del controlador disminuye sensiblemente. El sistema presenta dificultades de control en la situación en que el máximo de energía disponible en el fotovoltaico no sea al mediodía. Esta situación se puede dar en una región donde las lluvias ocurren al mediodía.

REFERENCIAS

[1] Duffie J. A. y Beckman W. A. (1991). Solar Engineering of Thermal Processes, 2ª edición, pp. 54-59. Wiley Interscience,

[2] Farfan Federico Hoyos Daniel (2008), Sistema de simulación y evaluación de logicas de control basados en algoritmos borrosos para sistemas 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 PV system simulationProgress in Photovoltaics: Research and Applications Volume 1, Issue 4, pages 283–292, October 1993.

163


Sistema de Emergencia Remoto Basado en GSM

Daniel A. Mancuso, Juan L. Castagnola Facultad de Ingeniería

Universidad Católica de CórdobaCórdoba, Argentina

[email protected]

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. INTRODUCCIÓN

En la actualidad, un gran porcentaje de la población se preocupa por la seguridad doméstica. Con el amplio desarrollo de las tecnologías de comunicaciones, se ve simplificado el diseño de un sistema de monitoreo y alarma remoto. Tanto para responder 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 a una empresa de servicios de emergencia, mediante el envío de una 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 una amplia cobertura en las ciudades y zonas rurales, comunicación a 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 a estas ventajas, se seleccionó la red GSM como medio de entrega del mensaje de alarma.

Un gran porcentaje de los sistemas embebidos pequeños están basados en microcontroladores, y el mayor desafío en el diseño de estos sistemas es el desarrollo del firmware [4]. El enfoque tradicional en la programación de los sistemas, es del tipo programa principal / interrupciones (foreground/ background), donde el flujo normal del programa consiste en un loop infinito que realiza llamadas a los módulos de aplicación para realizar las operaciones deseadas. Además, se utilizan rutinas de interrupción (ISRs, Interrupt Service Routines) disparadas por eventos tales como temporizadores o cambios de estado en las entradas. Pero a medida que la complejidad del sistema aumenta, se hace mas dificultoso el desarrollo y la depuración del firmware, ya que se deben

realizar varias tareas en simultáneo compartiendo un mismo flujo de programa principal. Es decir, las tareas se deben realizar en forma secuencial sin perder el control de la temporización de cada operación, lo cual resulta cada vez mas dificultoso, y en consecuencia, mas propenso a fallas difíciles de detectar [5].

Un mejor enfoque en estos casos, es la utilización de sistemas operativos de tiempo real (RTOS, Real Time Operating System). Estos aportan un cambio de paradigma entre la programación lineal o secuencial, y la programación multi-tarea o multi-hilo, donde varias tareas se realizan aparentemente en simultáneo compartiendo los recursos del microcontrolador. En realidad, las tareas se siguen ejecutando de forma secuencial ya que el CPU es único y solo se puede ejecutar una instrucción por ciclo, pero el núcleo del sistema operativo (kernel) es el encargado de ceder el control de la ejecución a cada tarea a una velocidad lo suficientemente alta como para que, en apariencia, se ejecuten en paralelo [6].

Por lo tanto, el principal aporte de este trabajo respecto de otros sistemas con características similares es la utilización de un RTOS para el diseño del sistema de emergencia, lo cual implica tanto una simplificación en la implementación del firmware, 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 un microcontrolador de 16 bits que ejecuta un RTOS (encargado del control de todos los bloques del sistema), un modulo GSM con su correspondiente tarjeta SIM (la compañía a utilizar debe seleccionarse según la cobertura, confiabilidad del servicio y costos), una interfaz de usuario compuesta por un display LCD y un teclado de membrana, un parlante y un micrófono. La alimentación se realiza mediante un adaptador AC/DC y una batería de Li-Ion de respaldo. La misma tiene una doble función: tanto como energía de respaldo para cortes del suministro eléctrico, como para un posible uso portátil del aparato. Por ejemplo, un paciente con discapacidad motriz podría utilizarlo para solicitar asistencia remota desde una silla de ruedas.

El sistema también consta con varias entradas digitales mediante las cuales se realiza el disparo de la alarma. Las mismas pueden provenir de distintos tipos de fuente como por ejemplo: sensores de humo para detectar incendios, sensores de gas natural para la detección de pérdidas, sensores de

164


movimiento, detectores de apertura de puertas y ventanas para detectar posibles intrusos.

Figure 1. Diagrama de bloques del sistema de emergencia.

Otras fuentes de disparo pueden ser dispositivos de control de variables biomédicas como electrocardiógrafos o sensores de saturación de oxígeno. Los cuales eventualmente pueden proveer salidas de alarma al detectar que los parámetros salen de un rango prefijado de seguridad [9, 10].

Mediante la interfaz de usuario se realizan varias configuraciones como los tipos de alarma conectados a cada entrada, el SMS prefijado que debe enviarse en cada caso, los nú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 la conexió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 tres criterios:

• Los periféricos necesarios: una interfaz UART para la comunicación con el módulo GSM y la cantidad mínima de puertos digitales que proporcionen las conexiones con los distintos elementos del sistema.

• Que el RTOS a utilizar provea la implementación para el microcontrolador a seleccionar (porting). Esto implica un tamaño mínimo de memorias RAM y FLASH, 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 criterios anteriores es el PIC24FJ64GA004 de Microchip Technology Inc., 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 los requisitos anteriores, el seleccionado está disponible en el mercado local, y es aceptado por su robustez en comparación con uC de otros fabricantes. Por otro lado, las herramientas de desarrollo son fácilmente accesibles.

B. Modulo GSM

Se seleccionó el módulo GSM/GPRS SIM340C, de la firma SIMCOM. La figura 2 muestra un diagrama interno del módulo. El mismo provee toda la interfaz de RF para la conexión a la red GSM, comunicación mediante un puerto UART para el control del mismo, interfaz para la conexión con una tarjeta SIM, 2 canales de audio y un convertidor A/D interno para el control del nivel de batería. El control del módulo se puede realizar mediante comandos AT standard, y comandos adicionales propios del fabricante. También provee el protocolo TCP/IP que puede ser utilizado para la transferencia de datos desde y hacia Internet mediante comandos 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 un circuito de grabación de voz. El IC seleccionado es el APR9600 de la compañía Aplus Integrated Circuits Inc. Posee una memoria Flash capaz de almacenar hasta 60 segundos de audio 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. Para la interconexión de este IC con el parlante, el micrófono y la interfaz de audio del modulo GSM, se utiliza el circuito CD4053, que posee 3 llaves analógicas de dos vías, las cuales son controladas por el uC. Un circuito amplificador de audio (LM386), amplifica la señal de audio a un nivel suficiente para que sea claramente audible en el parlante. Esta interfaz ilustra en la figura 3.

La interfaz de audio se implementa tanto como para grabar y reproducir los mensajes prefijados de alarma, como para la utilizació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 el usuario se realiza mediante un teclado de membrana de 4 filas por 3 columnas con el cual se puede navegar por los diferentes menús e ingresar datos como el número de teléfono al que se debe realizar la llamada de emergencia. Se dispone un módulo LCD 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 el diseño de un sistema embebido es el desarrollo del firmware, por lo que en este trabajo se intenta sacar provecho de las virtudes 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 trabajo es el “uC/OS-II” de Micrium Technologies. Este es un RTOS multi-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 de ejecución de una tarea. Se puede escalar según las necesidades de la aplicación y es portable hacia una amplia gama de micro-procesadores y microcontroladores presentes en el mercado (mas de 100 modelos de distintos fabricantes). La selección de este RTOS se basó en la gran aceptación que tiene el mismo en la industria y en ámbitos académicos, y que los autores tienen experiencia previa en el uso del mismo.

El proceso de desarrollo del firmware debe comenzar por la divisió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 en estado de ejecución (1). Luego, un evento asíncrono interrumpe el microcontrolador (2) para ser atendido por el servicio de in-terrupción (3). Al completarse la rutina de ISR, se invoca al kernel, 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 la tarea de menor prioridad (6). De esta manera, el kernel asegura que 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 de manera dinámica (con el fin de liberar recursos). Cada tarea debe tener su propio stack, con un tamaño suficiente para almacenar 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 que necesitará 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 3 servicios: Semaphores, que pueden utilizarse como banderas o como llaves para reservar o bloquear algún recurso. Mailboxes, para enviar mensajes entre tareas. Y Queues, las cuales son colas FIFO que pueden utilizarse para el envío de varios mensajes 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ón correspondiente 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 de la aplicación (navegación por los distintos menús, configuraciones, estado de alarma, etc.).

• TaskAlarma: verifica el estado de las entradas correspondientes a las fuentes de alarma y activa el envío de la alerta en caso de detectarse una situación de emergencia.

• TaskGSM: es la encargada del control del modulo GSM; envío y recepción de los comandos AT por medio de la interfaz UART, encendido / apagado del modulo, control de la interfaz de audio hacia el modulo, 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” para almacenar 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ú

TimeoutTiempo 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 los servicios 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 las teclas pulsadas.

• La escritura en el display se realiza a través del módulo “LCD” que fue modificado para funcionar con 4 bits de datos.

• Para la comunicación serial, se desarrolló un módulo UART. El mismo utiliza queues para el envío y recepción de 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 provee servicios tales como escribir un SMS, iniciar una llamada de voz, consultar el estado de la batería, etc. Este módulo se comunica con la aplicación por medio de semaphores y queues.

D. Funciones implementadas

Como se intenta maximizar la flexibilidad de utilización del sistema, se implementan varias funciones, a las cuales se accede desde la interfaz de usuario:

• Configuración manual del número de teléfono de emergencia (ingresándolo por teclado).

• Almacenamiento automático del número (con una llamada entrante desde el teléfono celular).

• Grabación o reproducción del mensaje de alerta.

• Configuración del SMS que se debe enviar ante las distintas situaciones de emergencia.

• Prueba de las distintas alarmas sin realizar ninguna llamada.

• Consulta del crédito restante en el caso de que el chip utilizado corresponda a una linea de modalidad prepaga (esto puede realizarse mediante una llamada de voz o un SMS).

• En estado de espera, el display muestra el estado de la conexión a la red (activo/inactivo), el nivel de batería y 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 un convertidor UART-USB para la visualización de la comunicación del uC con el modulo GSM en un terminal de PC. 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 emergencia que utiliza la red GSM como medio de comunicación. Su innovación radica en el uso de un RTOS para la programación del firmware. Durante el desarrollo del firmware ha resultado evidente 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 las temporizaciónes (gracias a los servicios que provee el kernel y la propiedad determinista del mismo). También se logra una fácil abstracción entre los distintos módulos y tareas, simplificando en gran forma la adición de nuevos elementos al sistema. De esta manera, se puede inferir que la dificultad de la programación de este tipo de sistemas embebidos avanza de una 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 fiabilidad del sistema, tanto alimentado desde la red eléctrica como desde la batería de soporte. Se lograron excelentes resultados respecto a la conexión del modulo a la red GSM, incluso en ubicaciones de baja señal y con pocos cuidados en la adaptación de la antena conectada al módulo, con lo que el módulo seleccionado cumplió las expectativas. Por otro lado, la calidad del audio obtenido es satisfactoria en el modo “manos libres”.

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 el sistema 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 es fácilmente controlable por cualquier tipo de pulsador, y es de gran ayuda en estos casos la funcionalidad de tipo “manos libres”. Estos elementos lo hacen extremadamente flexible en una gran variedad de aplicaciones, ya que el único elemento que se debe intercambiar en cada caso es el dispositivo de disparo de la alarma.

AGRADECIMIENTOS

Se agradece la colaboración del Ing. Agustín Laprovita, el Ing. Walter Lancioni, el Sr. Matias Díaz, el Ing. Carlos Centeno y a las Cátedras de “Sistemas Embebidos” y “Proyecto y Diseño” de la Facultad de Ingeniería - Universidad Católica de Córdoba, por los múltiples aportes que realizaron en el desarrollo de este trabajo.

REFERENCIAS

[1] Huiping Huang, Shide Xiao, Xiangyin Meng, Ying Xiong, "A Remote Home Security System Based on Wireless Sensor Network and GSM Technology," nswctc, vol. 1, pp.535-538, 2010 Second International Conference on Networks Security, Wireless Communications and Trusted Computing, 2010.

[2] Kyriacou Efthyvoulos, Pavlopoulos Sotiris, Dimitris Koutsouris, Andreas Andreou A, Pattichis Costas and Schizas Christos, “Multipurpose Health Care Telemedicine System”, Proceedings of the 23rd 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 International Conference on San Antonio, TX, USA, 11-14 October 2009.

[4] David Andrews, Iain Bate, Thomas Nolte, Clara Otero-Perez and Stefan M.Petters, “Impact of embedded systems evolution on RTOS use and design”, Proceedings of the 1st Workshop on Operating System Platforms 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, Kansas R&D Technical Books, 1998 ISBN 0-87930-543-6.

[7] SimCOM, “SIM340 Hardware Design ”, SIMCom Wireless Solutions Ltd., 2009.

[8] Labrosse, Jean J, “Embedded Systems Building Blocks, Complete and Ready-to-Use modules in C”, Lawrence, Kansas, R&D Technical Books, 1995 ISBN 0-87930-440-5.

[9] Pattichis CS, Kyriacou E, Voskarides S, Pattichis MS, Istepanian R and Schizas CN , “Wireless Telemedicine Systems: An Overview”, IEEE Antennas & Propagation Magazine 2002, 44(2):143-153.

[10] Lombardi, P.; Giaconia, C.G.;Di Dio, V.;. “An embedded diagnostic system for wheelchairs brushless drives monitoring”. Paper presented at International 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 life operation, portability and wireless connectivity.

Keywords: Telemedicine, Ventricular Fibrillation, ECG, cell-

phone, on-line processing.

I. INTRODUCTION

Nowadays cell-phones have become one of the most common electronic devices which are owned by almost everyone in our world. As a consequence of their portability and growing computer capabilities, they are used not only for communication purposes, but also for entertainment, social networks, positioning systems, and many other applications. This paper explains the development of one particular application that takes advantage of these mobile devices to create 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 a malignant arrythmia characterized by a rapid heart rate and an uncoordinated contraction of the cardiac muscle of the ventricles in the heart [1]. VF is usually diagnosed on the basis of 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, as it can be seen in Fig. 1. Heart rate in such situation can go from 240 up to 600 beats per minute (bpm). In the case of a VF only doctor 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 in dangerous situations.

Figure 1 – VF in a recorded ECG

The aim of this work is to implement in a cell–phone

mathematical algorithms which can detect VF in a recorded

ECG and in case of detecting VF automatically send a Short

Message 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 mathematical

algorithms 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 the

implementation and simulation of the VF detection algorithm

done in the MatLab environment. Section IV describes the

conversion from MatLab language code to Java Platform

Micro Edition (J2ME) language and checks the program

operation in an actual cell phone focusing on the processing

time of the ECG signal to detect VF. Section V details the

virtual 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 rate

varies between 60 to 100 bpm. However, heart rate during VF

can 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]. It

detects 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 low

frequency components of the ECG, remove baseline slow

changes or drifts and reduce 50/60 Hz line interference and

electromyographic high frequency noise. After filtering, the

signal is differentiated to amplify the QRS edges which are

much 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 were

detected in differentiator filter, are amplified. However, the

output of the squaring function will exhibit multiple peaks within the duration of a single QRS complex. To smooth the

resulting signal, the Pan and Tompkins algorithm uses a

moving window integration filter. After all these steps, the

signal 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 the

threshold a “0” is assigned to this sample. Meanwhile the QRS

is being detected, ECG time intervals between two pulses

(named usually as RR interval) are measured and the cardiac

frequency is then calculated. If the cardiac rate is over a

specific limit, set by the doctor, it means that a possible VF episode is detected.

III. MATLAB PROCESSING

A. Basic QRS complexes detection

A previous recorded ECG file extracted from MIT-BIH

Malignant Ventricular Arrhythmia Database [4] was taken as

an 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 frequency

was set at 250 Hz, and a Butterworth band–pass filter second order 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 the

normalization and finds the pulses, which have bigger value than 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 Tompkins

algorithm implemented in MatLab and their respective

resultant waveforms. In the plot of the bottom it can be seen

the 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, are

found. Subsequently, the program counts the difference

between two beginnings of pulses and puts the result into a

vector 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 the

instantaneous cardiac frequency (beats/min) accordingly to

(5).

(5)

After calculating the cardiac frequency (Fc), the decision

of VF detection is taken after than the Fc exceeding the

threshold frequency. In this work, a VF episode is considered

if at least 3 consecutive cardiac cycles have Fc values over 240

bpm [2]. However, the number of cardiac cycles and the

threshold frequency for VF detection are programmable by the

cardiologist 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 start

analyzing every second of the ECG. Every second a new

search starts. It can give enough time to be sure that a VF is

happening (because of the 3 seconds window) and it also can

detect it quickly enough (because of 1 second move).The other

advantage of this method, illustrated in Fig. 4, is that the first

two 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 the

written program always analyzes last 50 samples from the preceding second to avoid processing problems related to

starting filters.

C. Results of MatLab implementation

As it was mentioned before, a previous recorded ECG file

extracted from MIT-BIH Malignant Ventricular Arrhythmia

Database [4] was taken as an input (3000 samples, 12 seconds). This was used to be analyzed by the algorithms

implemented in MatLab. Fig. 5 details the different

waveforms obtained after passing the ECG input through the

different 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 frequency

can be clearly seen, successfully detecting a VF episode. Table

1 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 INTERPRETATION

As a previous step to run the application on the cell-phone

it was necessary to use J2SE to translate the algorithms

developed in MatLab to a language closer to the cell-phone

language.

Java Platform Micro Edition is a specification that

describes 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 ME

has its own reduced in relation to a set of Java classes called

the Standard Edition (SE) configuration. Configurations are complemented 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 with

optional packages. Such as a variety of Application

Programming 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 the

mentioned 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 in

J2ME, one class and several methods were written in the J2SE

platform, which are later invoked within the Java program

written in J2ME [5].

Fig. 7 is a flow diagram of the Java algorithm of the VF

detection implemented in the cell phone.

Buffer with samples

K=0

K<Number of

WndowsStop

K=0

Copy of 350

SamplesCopy of 750

Samples

FilteringK>0Copy from

Window Buffer

Copy to

Window Buffer

Finding Pulses and CF

Calculation

Recognition and Decision

Display Results

Increase Buffer Index

K= K+1

Start

Class Object

Number 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, which

contains the parameters used for the VF detection and the

telephone 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 cardiac

frequency 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 continue

detection. Fig. 8 shows graphically what was explained above.

Selecting the option Admin, the administrative options are

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

For the virtual machine simulation the Sony Ericsson

W300 simulator was used [7]. A configuration file was created

with 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 window

3

Threshold of windows with high cardiac frequencies for sms

3

Telephone number 5550001

The values used for the configuration file shown in Table

2 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 that

allows 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 important information 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. The

one 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. REAL 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 run

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

calculation process is presenting the calculation results on the

cell-phone display. Adding this time, the time results shown in

Table 3 increase in approximately 50% with regards the time

obtained without displaying the results. Even though this high

percentage of increasing the time per window when displaying

the results, they are still short enough to conduct efficient VF

recognition with the proposed algorithm.

II. CONCLUSIONS

In this work, it has been implemented and evaluated an

algorithm to detect a Ventricular Fibrillation (VF) in a cell-

phone. The application in the cell-phone was able to open an

ECG digitized text file, process the samples, make the right

decision 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 cardiac

frequency of every window. The configuration file offers an

easy way to change recognition parameters, very useful in

adjusting analysis to specified patient and ECG detection

conditions, and to change SMS contents, the SMS can contain up to 129 characters.

Analyzing the obtained results it is possible to say that a

cell-phone, in this particular case the Sony Ericson W300i,

has enough computational power to perform efficient

ventricular fibrillation recognition with the proposed

algorithm. Average time for window calculation, without the

first 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 was

helpful 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 reliable

connection to send the request for help, like a General Packet

Radio Service (GPRS) or High-Speed Downlink Packet Access (HSDPA) for Global System for Mobile

Communications (GSM) or Universal Mobile

Telecommunications System (UMTS) respectively; second on

using 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 by

any cell-phone. Another feature to add is to offer different

options for detecting other heart anomalies besides the VF.

REFERENCES

[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 Scientific Publishing 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 in http://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 bien

es 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 Arquitecturas Analó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 la Patagonia 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é LipovetskyLABCATyP

Departamento de ElectrónicaFacultad de Ingeniería

Universidad de Buenos Aires

En instalaciones eléctricas industriales y hogareñas se utilizan dispositivos que detectan corrientesde fuga a tierra, llamados disyuntores. Estos equipos cortan la alimentación de la red en caso deproducirse una falla protegiendo equipos y vidas humanas. Su funcionamiento se basa en la mediciónde un desbalance de corriente entre las líneas de alimentación de los equipos por lo que el sistema aproteger 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 paraproteger dispositivos electrónicos, como por ejemplo los transistores de potencia en variadores develocidad 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 derespuesta que permite resguardar los dispositivos electrónicos.

La solución desarrollada consiste de dos partes, un circuito que inyecta una señal pulsante de altafrecuencia en la línea de alimentación de un equipo y un circuito detector de la misma en caso defuga. Ambos circuitos, inyector y detector, se integran en un único chip de silicio con la tecnologíaXC06 de XFAB (se enviará a fabricar a mediados de diciembre). La inyección y sensado en la líneade potencia se realiza mediante aislación galvánica externa al circuito integrado (transformadoresde pulsos). Esto provee seguridad y cubre las necesidades del producto propuestas anteriormente.Este dispositivo posee umbrales de sensibilidad ajustables para permitir su portabilidad a distintasaplicaciones.

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. [email protected]

El I.A.R. cuenta con dos antenas parabólicas de 30mts de diámetro para uso radioastronomico. Una deellas 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 potenciapredeterminados por la configuración utilizada por el receptor, es por ello necesario que uno de losmó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ñalde referencia externa que utilizará para el ajuste de nivel y además, la capacidad de poder operarsede forma manual o remota mediante una PC. Al evaluar las opciones se decidió realizar este controlutilizando un CPLD implementando la solución en lenguaje VHDL. El hardware se dividió en 3secciones 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 utilizandolas herramientas de desarrollo de la firma Xilinx. Luego de verificar las simulaciones se procedió conla 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 elcontrol 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ónica

Facultad de Ingeniería de la Universidad de Buenos Aires

En la industria, los motores asincrónicos trifásicos son alimentados y controlados por variadores de velocidad. Estos últimos reciben información de control y diagnóstico, tales como 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 cableado adicional que no solo puede ser costoso, sino que muchas veces puede ser complicado o hasta 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 como canal de comunicación (PLC, Power Line Communication), evitando el cableado adicional para la supervisión y comando. Con el fin de lograr el objetivo de aprovechar los cables de la línea de potencia para la supervisión y comando de los motores de inducción se realizará mediante la FPGA un sistema 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 implementar las 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 este punto 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 Adaptativa Astronó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órdoba [email protected], [email protected]

Las variaciones de densidad de los gases de la atmósfera terrestre afectan el frente de onda de luz originado en un objeto celeste a ser observado desde la Tierra. Esto produce errores en la fase del frente de onda, imponiendo una limitación a la calidad de las imágenes que los 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 la geometrí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úa sobre 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 de una cámara CCTV. El montaje realizado permitirá ensayar diferentes algoritmos de control, presentándose una versió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 variadas

formas 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 logra

diferenciar 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 un

mejor 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 yaque constituye una buena aproximación a muchos canales reales. Los generadores de ruido gaussianoconstituyen 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 histogramaconstante (PDF uniforme). Aplicando luego el algoritmo de Box-Muller se obtiene la serie temporalcon 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 trabajose propone una metodología que permite la implementación en FPGA de un generador de ruido conuna 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 lametodologí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 utilizanesta representación.

192


193


Implementación de

Sistemas Embebidos

194


195


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

Ezequiel Rubinsztain1; Ariel Lutenberg1; Fernando Perez Quintián2, 3 1GLOmAe, Departamento de Física, Facultad de Ingeniería, Universidad de

Buenos Aires (Argentina) 2 Departamento 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 los

sistemas 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, en las 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 de

PM, 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 ancho de 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 con interfaz 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.23

1GLOmAe, Facultad de Ingenierıa, Universidad de Buenos Aires2Departamento de Fısica, Facultad de Ingenierıa, Universidad del Comahue

3CONICET

Los moduladores espaciales de luz (SLMs) son sistemas opticos que permiten modificar en tiemporeal, la amplitud y la fase de la luz que los atraviesa. Habitualmente, el elemento central de estossistemas es un microdisplay. Los microdisplays son displays de cristal lıquido donde el tamano de lospı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 prohibitivopara los laboratorios de optica. Frecuentemente se suelen armar SLMs precarios a partir del desguacede proyectores de video. Esto presenta dos inconvenientes: por un lado, la dificultad de disponer devarios SLMs de caracterısticas similares. Por otro lado, la necesidad de utilizar una PC para generar lassenales que emplea el SLM, debido a que los circuitos de control de los proyectores estan disenadospara trabajar con senales de video.

En este trabajo se presenta el desarrollo de un prototipo de un SLM a partir de un microdisplay deventa comercial. El esquema propuesto consiste principalmente en una CPLD que genera las senalesde sincronismo del microdisplay, una memoria para almacenar distintas imagenes, un conversor DACpara cargar la imagen en el microdisplay y un microcontrolador que realiza el control general delsistema. De esta forma se logra utilizar el microdisplay sin la necesidad de trabajar con senales devideo.

El prototipo resulta significativamente mas economico que los SLMs comerciales y, por ende, ofreceuna 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 eningles), ya que se trata de una configuración que posee los mismos elementos constituyentes básicosde un computadora, como son: microprocesador, memoria (RAM y ROM), bus de datos, periféricosde 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 XilinxSpartan 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ónmuy deseada para aplicaciones embebidas.

La utilización de una FPGA en el desarrollo de las SBC implica la posibilidad de que los algoritmosde 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 ventajacon respecto a las implementaciones efectuadas en software de una PC de escritorio, debido a que loque se programa en una FPGA es hardware, que es totalmente concurrente, traduciéndose en una altavelocidad de cálculo.

Al ser la SBC de arquitectura abierta permite una versatilidad en la utilización de la misma, como enla implementación de los algoritmos, ya que, o bien se llevan a cabo por el potente microcontroladorARM9, 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 debooteo del microcontrolador.

El sistema cuenta actualmente con un kernel de Linux embebido y la distribución GNU Debian paraARM, para aumentar la versatilidad del sistema y abstraerse del hardware a la hora de desarrollar yejecutar 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. [email protected]

Parte del instrumental que tiene el I.A.R. está dedicado al sistema de apuntamiento de una antena de30mts 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 obtenerel 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ónethernet, 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 estemódulo y teniendo en cuenta que debe ser integrado junto a otros sistemas, se optó por una plataformadel tipo SBC (Single Borad Computer) la cual fue desarrollada en el I.A.R; a modo de evaluación seutilizó 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 softprocessorMicroBlaze de la misma firma. Se decidió utilizar un sistema operativo un uClinux como elemento deabstracción entre el desarrollo de las aplicaciones y el hardware asociado. Mediante este mecanismose busca estandarizar el desarrollo de aplicaciones de software independientemente de la evoluciónde la plataforma de hardware.

205


Protocolosy

Comunicaciones

206


207


“Herramienta para depuración de redes de sensoresinalá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 se caracteriza 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 Embedded In ternet Mercado G., Aguir re M. y Diedr ichs A.

gustavo.mercado, mat ias.aguir re,

ana .diedr ichs@gridt ics.frm.u tn .edu .a r

Grupo UTN Gr idTICS

Facultad Regiona l Mendoza

Universidad Tecnológica Naciona l

La visión det rás de la In ternet de las Cosas es que los disposit ivos embebidos,

también llamados “smar t objetcs”, están cada vez mas universa lmente

conectados a In ternet y que son una par te in tegra l de la misma.

La In ternet de las cosas, a veces denominada “in ternet embebida or illera”,

es un cambio mayúscu lo y el mayor desafío a la In ternet actua l. La misma está

“hecha” con disposit ivos embebidos conectados a In ternet , lo que incluye

sensores, maquinas, lectores de RFID y equ ipamien to de au tomat ización de

edificios, solo para nombrar unas pocas aplicaciones. El exacto tamaño de la

In ternet de las cosas es difícil de est imar pero se asume que pron to su tamaño

excederá en de la In ternet actua l.

E l wireles embedded in ternet es un subconjun to de la In ternet de las cosas y

son aquellos disposit ivos embebidos de recursos limitados, a menudo operados

por ba ter ías y conectados a In ternet a t r avés de redes ina lámbr icas de ba ja

potencia y ba jo ancho de banda.

6LowPAN fue desar rolla do para hacer posible Wireless Embedded In ternet

simplificando la s funcionalidades de protocolo de in ternet IPv6, defin iendo un

encabezamien to muy compacto y tomando en cuen ta la na tu ra leza de las redes

ina lámbr icas.

En el presen te t rabajo se muest ra la fu ncionalidad de 6LowPAN (Red de área

personal de ba jas prestaciones habilitado pa ra IPv6), defin iendo los conceptos

de la norma del IETF, sus a lcances y sus aplicaciones habitua 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 una

placa 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 Zanini

Facultad de Ingeniería [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 ungrado de libertad. Se utiliza visión artificial como método de sensado de la posición. Esta herramientaes muy utilizada porque no necesita contácto con el elemento a sensar. La cámara utilizada es unawebcam. El medio en el cual se realiza la captura de la imagen debe controlarse adecuadamentepara tener alto contraste entre la bola y los demás componentes del sistema. La posición obtenidade la imagen es convertida, mediante transformaciones lineales, de un sistema de coordenadas 2Dexpresado 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 estarazó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 adecuadapara 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. Paraeste lazo de control el movimiento de la guía acoplada y el desplazamiento de la bola constituyenperturbaciones. 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 real

FreeRTOS, 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íodo

seleccionable 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 consideramos

un 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órdoba

Córdoba, Argentina.

[email protected]

En el presente trabajo se reporta exclusivamente el diseño de una Estación de Control para

una 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 del invernadero 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ón de Control, la cual funciona no sólo como punto de acceso de esta red con topología en estrella, sino que además brinda canales de interacción con el sistema a usuarios locales desde su propia interfaz humana (Pantalla Táctil) o por medio del software de gestión en una computadora portátil.

Mediante la utilización de un RTOS sobre un sistema embebido hemos logrado no sólo

reaccionar continuamente a los cambios en el entorno del sistema y computar resultados

certeros en tiempo real, sino también una excelente solución de compromiso en el diseño de

hardware y software, disminuyendo la complejidad de este último sin aumentar los recursos

circuitales necesarios. Esta simplificación en la implementación de un sistema con las

caracterí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 2011UTN-FRBA, Buenos

Aires, Argentina

CASE2011 Libro de Trabajos

Documents

Transcript of CASE2011 Libro de Trabajos