CASE2011 Libro de Trabajos PDF

CASE 2011
www.sase.com.ar 2 al 4 de Marzo de 2011 UTN-FRBA, Buenos Aires, Argentina
LibrodeTrabajos
Publicacin realizada con el apoyo de:

Agencia Nacional de Promocin Cientfica y Tecnolgica CONICET - Consejo Nacional de Investigaciones Cientficas y Tcnicas TWAS - The Academy of Sciences for the Developing World
CASE 2011
Libro de Trabajos
Congreso Argentino de Sistemas Embebidos
2 al 4 de Marzo de 2011 UTN-FRBA, Buenos Aires, Argentina
ISBN 978-987-9374-69-6
Libro de Trabajos CASE-Congreso Argentino de Sistemas Embebidos 2011
Edicin de contenido: Diego J. Brengi y Ariel Lutenberg

Copyright 2011. FIUBA- Facultad de Ingeniera - Universidad de Buenos Aires. Copyright 2011. UTN-FRBA - Universidad Tecnolgica Nacional - Facultad Regional Buenos Aires. Copyright 2011. INTI- Instituto Nacional de Tecnologa Industrial.
Se otorga permiso para copiar y redistribuir este libro de trabajos, siempre que se mantengan los mensajes de copyright y autora de la obra y sus partes.
ii
Prefacio
Sistema embebido es el nombre que reciben los equipos electrnicos que incluyen el procesamiento de datos, pero que a diferencia de una computadora personal, estn diseados para satisfacer una funcin especfica, como ser un reloj, un reproductor de MP3, un telfono celular, un router o el control de un automvil (ECU). El cerebro de un sistema embebido (S.E.) es tpicamente un microcontrolador, aunque los datos tambin pueden ser procesados por un DSP, una FPGA, un microprocesador o un ASIC, y su diseo est optimizado para reducir su tamao, su costo y/o su consumo, aumentar su confiabilidad y mejorar su desempeo. El diseo de sistemas embebidos es un motor clave de la industria y del desarrollo cientfico y tecnolgico, y es un campo que en los ltimos aos ha crecido 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 universidades, 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 latinoamericana, y abierto a todos los interesados en participar. Como parte del SASE 2011 se realizaron las siguientes actividades:

CASE - Congreso Argentino de Sistemas Embebidos, presentacin trabajos cientficos. Workshops: 15 talleres prcticos en la modalidad hands-on. Tutoriales: 120 charlas de capacitacin. Plenarias: 6 conferencias y debates abiertos. Concurso de proyectos estudiantiles: sobre trabajos finales de graduacin. Concurso de emprendimientos tecnolgicos: destinado a promover emprendimientos electrnicos con viabilidad econmica. Programa de equipamiento para universidades: para transferir a las universidades las donaciones de los auspiciantes. Becas de viaje y alojamiento: se entregaron 116 ayudas econmicas para estudiantes de grado, estudiantes de doctorado, docentes e investigadores, de Argentina y Latinoamrica. 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 pas, fomentando la colaboracin. Difundir en el medio acadmico los adelantos cientficos y tecnolgicos producidos a nivel mundial. Propiciar la presentacin y discusin de trabajos de investigacin desarrollados en Argentina. Estimular en los estudiantes universitarios avanzados el inters por la investigacin en el rea de los S.E. Difundir los proyectos de investigacin mediante el desarrollo de un sitio web. Coordinar y actualizar los contenidos de S.E. de los programas de grado y posgrado de las universidades argentinas.
Entre los temas de inters del CASE pueden mencionarse ASICs, Arquitecturas de microcontroladores, DSPs, Electrnica espacial, FPGAs, Linux embebido, Low-power, Robtica, RTOS, Softcores, Software embebido, Verilog y VHDL, entre otras. Los trabajos presentados al CASE fueron sometidos a un proceso de revisin y correccin. De este modo fueron seleccionados 28 artculos y 22 psters. Estos 50 trabajos se publican en esta memoria y tambin estn disponibles en forma online en la pgina www.sase.com.ar/2011 Esperamos que los trabajos recopilados en esta memoria sean de su inters y contamos con su participacin en futuras ediciones del evento. Atentamente, Dr. Ariel Lutenberg Comit Organizador CASE 2011
iv
Empresas Auspiciantes

Electrocomponentes S.A. (Argentina) Cika S.R.L. (Argentina) ELKO/Arrow Argentina (Argentina) Electrnica 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 Mquinarias y consumibles S.R.L. (Argentina) Sequoia Space (Colombia) Revista Mercado Electrnico (Argentina) INVAP S.E. (Argentina) Miteco S.R.L. (Argentina) Clariphy Argentina S.A. (Argentina) Semak S.A. (Argentina) HT S.A. (Argentina) Tecnonerga (Argentina)
Instituciones Auspiciantes

MinCyT ANPCyT (Agencia) CONICET CONAE CONEA CITEDEF INTI CADIEEL IEEE Argentina AADECA PAE-37079 TWAS
Universidades Auspiciantes

Instituto Tecnolgico de Buenos Aires Instituto Universitario Aeronutico Universidad Blas Pascal Crdoba Universidad CAECE de Mar del Plata Universidad Catlica de Crdoba Universidad Catlica de Santiago del Estero Universidad Catlica del Uruguay (Uruguay) Universidad de Buenos Aires Universidad de la Repblica (Uruguay) Universidad de Mendoza Universidad Nacional de Catamarca Universidad Nacional del Centro Universidad Nacional del Comahue Universidad Nacional de Crdoba Universidad Nacional de Cuyo Universidad Nacional de Entre Ros 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 Ro Cuarto Universidad Nacional de Rosario Universidad Nacional de Salta Universidad Nacional de San Juan Universidad Nacional de San Luis Universidad Nacional de San Martn Universidad Nacional del Sur Universidad Nacional de Tres de Febrero Universidad Nacional de Tucumn UTN-FRA (Avellaneda) UTN-FRBA (Buenos Aires) UTN-FRBB (Baha Blanca) UTN-FRC (Crdoba) UTN-FRD (Delta) UTN-FRH (Haedo) UTN-FRLR (La Rioja) UTN-FRM (Mendoza) UTN-FRN (Neuqun) UTN-FRP (Paran) UTN-FRRG (Ro Grande) UTN-FRSF (San Francisco) UTN-FRSN (San Nicols) UTN-FRVT (Venado Tuerto) UTN-FRVM (Villa Mara) UTN-FRT (Tucumn)
vii
Comit Organizador

Dra. Patricia Borensztejn (FCEN-UBA) Ing. Diego Brengi (INTI/UNLaM) Ing. Julin 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 Julin (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. Anbal Romandetta (UNTreF) Dr. Ricardo Snchez Pea (ITBA) Ing. Gerardo Sager (UNLP) Msc. Cristian Sisterna (UNSJ) Dr. Elas Todorovich (UNICEN) Ing. Salvador Tropea (INTI) Ing. Ignacio Zaradnik (UNLaM)
Coordinacin General

Dr. Ariel Lutenberg (FI-UBA) Ing. Diego Brengi (INTI/UNLaM)
viii
Revisores
Jorge Alberto Ricardo Arias German Bassi Patricia Borenzstejn Diego Brengi Daniel Cabbibo Lucas Chiesa Claudio Delrieux Carlos Demarziani Luciana Demicco Francisco Ditaranto Andrs Djordjalian Fabiana Ferreira Alejandro Furfaro Mariano Andrs Garca Inza Carlos Arturo Gayoso Juan Carlos Gmez Pedro Julian Mauro Koenig Hilda Angela Larrondo Jose Lipovetzky Ariel Lutenberg Pedro Martos Gustavo Mercado Rafael Oliva Franco Pessana Leonardo Rey Vega Gaston Rodriguez Cristian Sisterna Hernn E. Tacca Elas Todorovich Salvador Tropea Claudio Verrastro Gustavo Zabaleta Ignacio Zaradnik
ix
NDICE
ARTCULOS ASICs
Sistema de Medicin Remoto Basado en Dispositivos FPGA Red de Sensores Hospitalaria para la Medicin de Presin Endotraqueal Post-silicon Validation Procedure for a PWL ASIC Microprocessor Architecture
1 3
5 10 15
DSPs
Desarrollo e Implementacion de un Controlador Activo de Ruido de Banda Angosta Adaptativo Prototipado rpido para sistemas embebidos en FPGA - Desarrollo de la trasformada Wavewlet en 2-D
21
23 29
FPGA, Verilog, VHDL y HDLs

Implementacin en FPGA de decodificadores LDPC de baja complejidad Generador de Nmeros Pseudoaleatorios Mediante el Sistema Numrico de Residuos, Implementacin en FPGA Implementacin del algoritmo QRD-RLS sobre FPGA,Aplicacin a un Sistema Cancelador de Ruido Diseo de un Sistema para el Control de Posicin de un Motor DC Basado en FPGA Implementacin del procesador CortexM0 DesignStart en una fpga de rango bajo Sistemas en Chip acelerados por hardware: comparacin de performance en aplicaciones criptogrficas
35 37 42 48 53 59 64 71 73 79 85 89 91 97 103 109 111 x
Linux Embebido
El papel del Hardware copyleft en la Enseanza de Sistemas Embebidos Desarrollo de un equipo para grabar los sonidos de los bovinos a la intemperie Dispositivo de rehabilitacin visual basado en sistemas embebidos del tipo ARM
Protocolos y Comunicaciones
Anlisis del Desempeo de un Algoritmo de Localizacin para Redes de Sensores Tecnologa inalmbrica Near Field Communication y sus aplicaciones en sistemas embebidos Cost Effective Cross-layer Protocol Testing: A Case Study
Robtica
Buti: Plataforma robtica genrica para la enseanza de la informtica
Libreras embebidas para microcontroladores LPC2000 de aplicacin en robtica Filtro complementario para estimacin de actitud aplicado al controlador embebido de un cuatrirrotor
115 120 127 129 135 140 146 152 158 163 168
Software Embebido
Aplicacin Web embebida para el control de payload de un satlite Enfoque embebido para una Estacin Meteorolgica con Interfaz Web Diseo de un sistema de actualizacin de firmware para un sistema embebido Actualizacin parcial de software embebido en tiempo de ejecucin en sistemas sin RTOS Muestreo y Adquisicin Inteligente de Seales Sensoriales en Sistemas Embebidos Controlador de carga para un sistema fotovoltaico aislado Sistema de Emergencia Remoto Basado en GSM Ventricular Fibrillation Detection Algorithm Implemented in a Cell-Phone Platform
POSTERS Arquitecturas de Microcontroladores

Comparacin del desempeo de microcontroladores AVR de 4ta generacin Anemmetro Ultrasnico 3D empleando Arquitecturas Analgica-Digital Reconfigurables
175 177
179 180
ASICs
Detector Activo de Corrientes de Fuga Fabricacin de un circuito integrado digital conversor Serie-Paralelo y Paralelo-Serie en un proceso CMOS de 0.5 m
181
183 184

Control Automtico de Ganancia sobre un CPLD Aplicaciones de FPGA de tecnologa flash al control de motores elctricos de corriente alterna Montaje de Experimentacin para ptica Adaptativa Astronmica con FPGA Implementacin de MODBUS en FPGA mediante VHDL, Capa de Enlace Implementacin en FPGA de Ruido Gaussiano para simulaciones en Hardware
185
187 188 189 190 191
Implementacin de Sistemas Embebidos

Sistema para medicin optoelectrnica del secado de pinturas Kit Educativo basado en microprocesador de 32 bits Sistema de adquisicin de datos para estudios interferomtricos
193
195 196 197
xi
Anotador Braille Electrnico Parlante Esquema de control de un microdisplay LCD
198 199
Linux Embebido
Single Board Computer Basada en ARM9 y FPGA para Procesamiento de Imgenes Digitales Diseo de un reloj sidereo sobre una plataforma uClinux y FPGA
201
203 204
Herramienta para depuracin de redes de sensores inalmbricos The Wireless Embedded Internet
205
207 208
Robtica
Implementacin de rutinas de Control ptimo en micros de 8/32 bits Sensado basado en visin para el control de un sistema Ball & Beam
209
211 212
RTOS
Sistema porttil para adquisicin, monitorizacin y registro de seales de ECG en tiempo real Estacin de Control para Red de Sensores Inalmbricos Implementada con RTOS
213
215 216
xii
www.sase.com.ar 2al4demarzode2011 UTNFRBA,BuenosAires,Argentina
ARTCULOS
ASICs
Sistema de Medici on Remoto Basado en Dispositivos FPGA

Pablo D. Pareja Obreg on, Alfredo Falc on, Mart n Di Federico Pablo S. Mandolesi, Pedro M. Juli an
Dpto de Ing. El ectrica y de Computadoras Universidad Nacional del Sur Bah a Blanca, Argentina pablopareja@ieee.org
ResumenEn el presente trabajo, se desarrolla un sistema de medici on automatizado utilizando un dispositivo FPGA como nodo de medici on y una computadora como nodo maestro de recolecci on de datos. La arquitectura es extendible a distintos dispositivos de medida, cambiando las variables a controlar y pudiendo utilizarse en aplicaciones remotas. Este sistema fue desarrollado por el Grupo de Investigaci on en Sistemas Electr onicos y Electromecatr onicos (GISEE) de la Universidad Nacional del Sur.1 y el desarrollo En el trabajo se trata la concepci on, el diseno, del sistema hasta llegar al sistema terminado.
I.
I NTRODUCCI ON
reas tecnol Las redes de datos son una de las a ogicas con mayor desarrollo en la actualidad. Sus aplicaciones van desde las telecomunicaciones, sistemas de seguridad, sistemas multimedia, hasta redes de sensores y sistemas embebidos[1][2]. Esto trae como consecuencia la tendencia actual a utilizar redes LAN o incluso conexiones directas a internet para controlar diversos dispositivos de la vida cotidiana[3]. Acorde con dicha tendencia, muchos m odulos de sistemas embebidos ya vienen con soluciones y herramientas para redes Ethernet incorporadas. Esto facilita su incorporaci on en sistemas de medici on remotos, as como acelera el tiempo de desarrollo de aplicaciones controlables a distancia. Otra tecnolog a que est a ganando terreno, debido a su exibilidad y potencia son los arreglos l ogicos programables en campo (FPGA)[4]. La posibilidad de programar las FPGA en tiempo de ejecuci on, sin moverlas del lugar de aplicaci on, es un factor clave a la hora de denir la arquitectura a utilizar en el dise no[5]. Actualmente los desarrollos con FPGAs, pueden aprovechar m odulos de Ethernet y microprocesadores que ya vienen embebidos en las mismas.
1 El presente trabajo fue sustentado parcialmente por la Agencia Nacional de Promoci on Cient ca y Tecnol ogica (ANPCyT), Proyecto PICT 14628, y por la UNS, Proyecto PGI 24/ZK12. P. Juli an es miembro del Consejo Nacional de Investigaciones Cient cas y T ecnicas CONICET, Av. Rivadavia 1517, Buenos Aires, Argentina. P. Mandolesi es miembro de CIC (Comisi on de Investigaciones Cient cas), Pcia. Bs. As, La Plata, Argentina. P. Pareja Obreg on es becario del Consejo Nacional de Investigaciones Cient cas y T ecnicas CONICET, Av. Rivadavia 1517, Buenos Aires, Argentina. A. Falc on es becario PRH de la Universidad Nacional del Sur, Av. Col on 80, Bah a Blanca, Argentina.
Como ventaja adicional de los sistemas de medida remotos, se encuentra la posibilidad de enviar comandos desde una estaci on de trabajo, sin la necesidad de encontrarse f sicamente en el lugar donde se est a realizando la medida. Esto resulta til cuando la variable a medir se encuentra particularmente u en lugares de dif cil acceso, como es el caso de variables ambientales en zonas geogr acas protegidas. Este paradigma de sistemas de medida descentralizados, viene con problem aticas de sincronizaci on asociadas. Denir el nodo maestro y los nodos esclavos en estas comunicaciones, es uno de los puntos clave a la hora de comenzar el desarrollo de cualquier sistema. La sincronizaci on de los mismos deber a, a su vez, tener en cuenta c omo se almacenaran los datos recibidos y discriminar las fuentes de datos en el caso de contar con m as de un nodo. Al mismo tiempo, la informaci on temporal de los datos es un par ametro clave en transmisiones sujetas al ruido con posible p erdida de informaci on en el camino. Una red de sensores consiste en un conjunto de nodos con capacidad de sensado y c alculo limitadas, que pueden coordinarse a trav es de comunicaciones inal ambricas o cableadas, con el prop osito de llevar adelante alguna tarea. La utilizaci on de redes de sensores nos permite disponer de diversos tipos de informaci on, al instante y desde cualquier sitio. En el presente trabajo, se desarrolla un sistema de medici on remoto utilizando un dispositivo FPGA como nodo de medici on y una computadora como nodo maestro de recolecci on de datos[6][7]. El dispositivo a medir consiste en un conversor de corriente a corriente, utilizado en la medici on de los tiempos de respuesta de un fototransistor. El objetivo del trabajo es obtener las m nimas corrientes necesarias en el emisor, para cada valor de tiempo de encendido del mismo. De esta manera, contando con todos los pares de valores de corrientes de emisor y tiempos ptimo de trabajo de encendido, se puede obtener el punto o para cualquier aplicaci on en particular. El presente trabajo se divide de la siguiente manera: en la secci on II se describe la arquitectura del sistema de medici on propuesto, para luego desarrollar con mayor profundidad cada uno de los bloques implementados. En la secci on III se muestran los resultados experimentales obtenidos, durante la etapa de evaluaci on del sistema, as como un an alisis de los
tiempos de medida resultantes en relaci on con la resoluci on de los datos. En la secci on IV se describen futuras mejoras en el sistema de medida y nalmente en la secci on V se detallan las conclusiones del trabajo. II. D ESARROLLO El sistema propuesto ha sido dise nado de forma de asegurar m axima exibilidad y facilidad de uso. Dado que en nuestra aplicaci on en particular, se requieren variar los diversos par ametros de la medici on, es necesario que los algoritmos sean gen ericos y de f acil extensi on. As se logran modicar los tiempos y resoluciones de la medici on de manera sencilla y en tiempo de ejecuci on. A un cuando el uso de redes de sensores es muy ventajoso en muchas aplicaciones, se deben tener en cuenta sus limitaciones[8][9]. Cuando las redes utilizadas est an compuestas por nodos inal ambricos, para evitar el cambio peri odico de las fuentes de alimentaci on, un bajo consumo de energ a es un requerimiento fundamental en el dise no. En nuestra aplicaci on en particular, debido a que todos los nodos utilizados por el momento cuentan con conexi on directa a la red de energ a, el bajo consumo no es un par ametro de peso en el dise no del sistema. Por otra parte, tambi en existe un l mite en cuanto a la memoria que disponen los nodos (FPGA) y su capacidad de procesamiento. En el sistema desarrollado, para evitar trabajar en el l mite de la memoria de nuestra FPGA los datos son enviados de manera asincr onica en el momento en que son adquiridos, utilizando el protocolo est andar de comunicaciones RS232. La aplicaci on de un sistema de medici on descentralizado es un proceso que comprende diversas etapas a mencionar, nodo de control maestro, nodos de medici on esclavos, relevamiento de datos, transmisi on de paquetes obtenidos, y nalmente an alisis de datos relevados. Cada una de estas etapas ser a explicada con mayor detalle en las secciones siguientes. II-A. Sistema Un esquema del sistema completo se muestra en la Fig. 1. Nuestro dispositivo a medir consiste en un circuito, cuyos par ametros a modicar son la corriente de entrada (Ie ) y el tiempo de encendido (tduty )[10]. Para cada par de valores tiempo-corriente, obtenemos una tensi on de salida Vout = f (Ie , tduty ). Dicha salida es una se nal digital que puede valer 0 o 1, es decir tiene un bit de ancho de palabra. Por otra parte, tambi en existe una se nal de reset que nos permite efectuar una nueva medici on. El objetivo de nuestro ensayo, consiste en levantar la curva de corrientes Ie m nimas necesarias para que transicione la salida, en funci on del tiempo tduty de encendido. El sistema de medida dise nado consiste en una FPGA, que es la encargada de manejar las se nales digitales del banco de pruebas, una computadora que act ua como nodo maestro, y una fuente de corriente de precisi on Agilent E5270B. El ensayo, que se muestra en la Fig. 2, consiste en ir tomando sucesivos valores de corriente Ie , los cuales son controlados entre un valor m nimo de 5 A y un valor m aximo de 15 mA. Estos valores son ajustados mediante un script en Matlab,
Figura 1. Sistema total
que a su vez se comunica con la fuente de corriente Agilent E5270B para jar los valores propiamente dichos. Por otra parte, para cada valor de corriente, se env a una se nal de control a la FPGA para que comience las mediciones. Dicha se nal de control se transmite mediante una comunicaci on serie RS232[11]. Para cada medici on, la FPGA reiniciar a el circuito mediante un pulso digital de reset. A su vez, controlar a la se nal tduty a trav es de la llave S1 que permite que la corriente Ie llegue a un diodo emisor de luz. Durante los tiempos de apagado de la llave S1 , la corriente Ie es derivada a tierra. La luz emitida llegar a a la base de un fototransistor, que producir a la corriente de entrada al circuito de pruebas. Dicha corriente se integrar a sobre una capacidad que nalmente producir a la tensi on 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 para detectar una corriente determinada. A su vez, la tensi on digital de salida es muestreada por la FPGA. La misma transmitir a el dato resultante a la computadora, mediante una comunicaci on serie. El script en Matlab recibir a los datos, los almacenar a en una variable y comenzar a el proceso nuevamente para una corriente mayor. En este esquema, donde la computadora corriendo Matlab representa el nodo maestro, y tanto la fuente de corriente Agilent E5270B como la FPGA los nodos esclavos, la principal problem atica a abordar es la sincronizaci on entre el nodo maestro y los nodos esclavos. Para simplicar dicha sincronizaci on, se decidi o utilizar un protocolo est andar, robusto y ampliamente probado, como es el protocolo serie de comunicaci on RS232. Para la fuente de corriente Agilent E5270B, sin embargo, se decidi o establecer la comunicaci on utilizando el protocolo GPIB, debido a la disponibilidad de las librer as necesarias.
Figura 2. Ensayo realizado
II-B. Nodo de Control Maestro
II-C.
Nodo de Medici on Esclavo
El control del nodo maestro se realiza mediante un script de Matlab. Un esquema del mismo se muestra en la Fig. 3. B asicamente consiste en ir jando sucesivos valores de corriente en la fuente Agilent E5270B, dar la orden a la FPGA de comenzar una nueva corrida de mediciones, y esperar los resultados de la misma. La comunicaci on entre Matlab y la fuente de corriente Agilent E5270B se realiza por medio de una comunicaci on GPIB. Es importante tener en cuenta, que la fuente de corriente Agilent no permite manejar con presici on el tiempo en que se ja una variable o se toma una muestra. Debido a esto, la variaci on de los pulsos de corriente de emisor se realiza mediante llaves controladas por la FPGA, y no directamente mediante la fuente de corriente. Por otra parte, los comandos a la FPGA se implementaron mediante una comunicaci on serie. Para los mismos se utilizaron librer as est andar provistas por Matlab. Para simplicar el sistema, se realiz o una recepci on asincr onica de los datos. Luego de enviado el comando de inicio a la FPGA, se espera un tiempo determinado. Este tiempo se corresponde con el tiempo total de medida de la FPGA, m as un agregado de tiempo extra para tener en cuenta las variaciones debidas a que el planicador de tareas del sistema operativo no es de tiempo real. Los datos se reciben de manera asincr onica, por bloques. Cada bloque contiene la totalidad de las medidas realizadas en esa corrida de datos. La conguraci on de comunicaci on serie RS232 es 115200 baudios, 8 bits de datos, sin bit paridad, 2 bits de stop. Luego de este proceso, se var a nuevamente la corriente y se comienza una nueva medici on. Al nalizar la medici on de todas las corrientes requeridas, se almacenan los datos en un archivo para su posterior an alisis.
Como se mencion o anteriormente, la FPGA es la encargada de generar las se nales digitales que controlan nuestro circuito de pruebas. Estas se nales controlan por un lado la tensi on de reset (Vreset ), y en segundo lugar manejan la llave CMOS (S1 ) conectada en paralelo con la fuente de corriente Agilent E5270B. Uno de los motivos principales para utilizar llaves
Figura 3. Algoritmo implementado en el nodo maestro
Figura 4. Algoritmo implementado en el nodo esclavo
CMOS es su consumo pr acticamente nulo en la entrada de control, que debe ser manejada por la FPGA. Un esquema del algoritmo utilizado se muestra en la Fig. 4. Dicho algoritmo maneja las llamadas ventanas de tiempo, durante las cuales se mantiene encendida la llave S1 , permitiendo el paso de la corriente Ie al diodo emisor. Estas ventanas deben variar entre dos valores conocidos, que ser an el tiempo m nimo y m aximo de la medici on. Una vez nalizado cada pulso de corriente, se realiza la medida de la tensi on de salida y se env a el resultado al nodo maestro. El algoritmo fue implementado en Verilog, utilizando un kit de desarrollo Spartan 3 para la FPGA. El sistema consiste en una m aquina de estados y dos contadores. La m aquina de estados es la encargada de esperar la recepci on de un comando RS232, el cual reiniciar a los contadores. La m aquina de estados a su vez, es la encargada de tomar muestras de la salida y env ar los datos mediante el protocolo serie RS232. Los contadores son los encargados de generar un barrido en las ventanas de tiempo. El primer contador almacena el tama no de la ventana de tiempo actual. Por otra parte, el segundo contador genera la ventana de tiempo propiamente dicha, manteniendo abierta la llave S1 mientras su cuenta sea menor que el tama no indicado por el primer contador. Al nalizar la cuenta del segundo contador, se emite la se nal nBarrido a la m aquina de estados, indicando que se debe enviar un dato nuevo. A continuaci on se incrementa el primer contador, y se repite el proceso hasta llegar al m aximo tama no de ventana que se desea medir. Para recibir y transmitir los datos mediante el protocolo serie, se necesit o desarrollar un m odulo encargado de dicha tarea. El esquema utilizado se desarrolla en la secci on siguiente. II-D. Trasmisi on de Paquetes El sistema encargado de trasmitir y recibir datos serie fue desarrollado en Verilog. El mismo se divide en 3 partes, un generador de baudios, un transmisor y un receptor. Como se coment o anteriormente, la velocidad de transmisi on utilizada es 115200 baudios. Las FPGAs, sin embargo usualmente utilizan velocidades mucho mayores a 115200 Hz. En nuestro caso en particular, el reloj con que contamos es de 50 MHz. Eso signica que utilizaremos un reloj de alta velocidad, que
dividiremos para obtener un per odo tan cerca a 115200 veces por segundo como nos sea posible. Al contar con un reloj de 50 MHz, para generar 115200 Hz se debe dividir por un n umero que no es entero. La soluci on es dividir por el n umero potencia de 2 m as cercano a la velocidad que queremos generar. Esto tendr a como consecuencia que en ocasiones se utilice un per odo menor y en ocasiones un per odo mayor. En promedio, la velocidad generada ser a la que estamos buscando y al contar con un reloj mucho mayor que la tasa de baudios, el error estar a dentro de la variaci on aceptable por el protocolo. Cuando se recibe la se nal TxD start, que es emitida por la m aquina de estados de la secci on II-C, se toma un dato de 8 bits y se lo serializa utilizando un multiplexor. En ese momento la se nal busy es emitida y se mantiene durante toda la transmisi on. La se nal TxD start es ignorada durante ese tiempo. El receptor, por otra parte, va ensamblando los datos de la l nea de entrada (RxD) a medida que arriban. Esta l nea ser a la que reciba los datos entrantes del protocolo RS232. Con cada byte recibido, se emite la se nal data ready durante un per odo de reloj. Para determinar cuando arriba un nuevo dato o bit de inicio, sobremuestreamos la se nal a un m ultiplo de la tasa de baudios. Una vez que detectamos el bit de inicio, muestreamos la l nea a la tasa de baudios conocida, para adquirir los bits de datos. En nuestro caso utilizamos un sobremuestreo de 8 veces. Al ser asincr onica, la se nal RxD de entrada no tiene ninguna relaci on con nuestro reloj. Para solucionar esto, se utilizan dos ip ops tipo D, logrando as la sincronizaci on con nuestro reloj. Los datos son a su vez ltrados, para evitar que picos de tensi on en la l nea RxD sean confundidos con bits de inicio. Para esto, se utiliza un algoritmo de decisi on que muestrea 3 veces la se nal. Finalmente, un registro de desplazamiento recolecta los bits de datos a medida que son recibidos. III. R ESULTADOS E XPERIMENTALES
El sistema fue probado en laboratorio y funcion o correctamente. Para la validaci on de los algoritmos de Verilog, se simul o el c odigo desarrollado inyectando valores de entrada mediante una transmisi on RS232 emulada. Por otra parte, para comprobar el correcto funcionamiento del sistema completo, se inyectaron datos conocidos y se comprob o que llegaran correctamente a la estaci on central. Debido a que la matriz a medir es amplia, es conveniente realizar pruebas intermedias con pocos datos, para acortar los tiempos de prueba del sistema de medida. El n umero total de muestras a tomar es n(Ie ) n(tduty ), donde n es el n umero de puntos. Entre las pruebas llevadas a cabo, se realizaron comunicaciones entre ltimo entre Matlab y la terminales serie y Matlab, y por u FPGA. Finalmente se relevaron m ultiples datos de manera continua, contrast andolos con los datos obtenidos a partir de resultados te oricos. En la gura 5 se muestran los resultados experimentales obtenidos durante una de las pruebas de laboratorio.

Corriente minima de transicion en funcion del tiempo de encendido 14 12 10 Ie [mA] 8 6 4 2 00
0.2
0.4
0.6 0.8 Tduty [ms]
1.2
con dispositivos FPGA. Esta aplicaci on resulta particularmente pr actica para sistemas de medici on con bajas constantes de tiempo, donde se debe iterar sobre distintos par ametros y cada medici on lleva grandes cantidades de tiempo. De esta manera, dichos par ametros son congurables en el servidor, quien se encarga de supervisar las mediciones de manera autom atica y a su vez almacenando los datos resultantes. Todo proyecto consta de varias etapas a mencionar, concepci on, dise no e implementaci on, y testeo. Todas ellas han sido desarrolladas a lo largo del trabajo, mostrando la metodolog a con la que se atac o el problema que se pretend a resolver. En particular, el sistema fue probado satisfactoriamente en laboratorio. Se proponen algunas mejoras al sistema, las cuales ser an implementadas una vez que se eval ue la ecacia del ptimas de trabajo. m etodo y determinen las condiciones o R EFERENCIAS
[1] G. J. Pottie and W. J. Kaiser, Wireless integrated network sensors, Communications of the ACM, vol. 43, no. 5, pp. 5158, May 2000. [2] C. Chong and S. Kumar, Sensor networks: evolution, opportunities, and challenges, Proceedings of the IEEE, vol. 91, no. 8, pp. 12471256, Aug. 2003. [3] H. E. Williams and D. Lane, Web database applications with PHP & MySQL. OReilly & Associates, 2004. [4] C. D. Araujo, M. D. Santos, and E. Barros, A FPGA-based implementation of an intravenous infusion controller system, IEEE International Conference on Application-Specic Systems, Architectures and Processors, pp. 402411, Jul. 1997. [5] W. Wolf, FPGA-based system design. Prentice Hall PTR Upper Saddle River, NJ, USA, 2004. [6] Y. Bai and C. Hsu, Design and Implementation of an Embedded Remote Electronic Measurement System, Proceedings of the IEEE Instrumentation and Measurement Technology Conference, pp. 1311 1316, Apr. 2007. [7] F. Yu, X. Shen, X. Song, and J. Chen, Implementation and evaluation of object-oriented exible measurement system, 9th International Conference on Electronic Measurement & Instruments, pp. 310314, Aug. 2009. [8] B. Sadler, Fundamentals of energy-constrained sensor network systems, Aerospace and Electronic Systems Magazine, IEEE, vol. 20, no. 8, pp. 1735, Aug. 2005. [9] P. Bustamante, U. Bilbao, N. Guarretxena, and G. Solas, Wireless sensor for intravenous dripping detection, 14th IEEE International Conference on Electronics, Circuits and Systems, pp. 399402, Dec. 2007. [10] G. Ferri and N. C. Guerrini, Low Voltage, Low Power CMOS Current Conveyors, 1st ed. Springer, Nov. 2010. [11] J. Campbell, C Programmers Guide to Serial Communications, 2nd ed. Sams, Sep. 1993. [12] A. Lofgren, L. Lodesten, S. Sjoholm, and H. Hansson, An analysis of FPGA-based UDP/IP stack parallelism for embedded Ethernet connectivity, 23rd NORCHIP Conference, pp. 9497, Nov. 2005. [13] M. K. Dalheimer, Programming with Qt. OReilly, 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.
Figura 5. Resultados experimentales obtenidos
IV.
F UTURAS M EJORAS
Como futura mejora se propone desarrollar un sistema de control embebido, que permita recibir los datos recolectados por la FPGA y almacenarlos en una memoria interna. Es importante mencionar, que se deber a adem as dise nar una fuente de corriente programable de alta precisi on. De esta manera, se podr a reemplazar la fuente Agilent E5270B. Entre las ventajas de este m etodo, se encuentra la mayor portabilidad del sistema, pudiendo incluir los m odulos de medida en el mismo circuito que conforma el dispositivo a medir. Es importante mencionar que en cuanto a la sincronizaci on de la medici on, en el presente trabajo no se encuentran mayores dicultades dado que las mediciones son relativamente lentas, y en un solo nodo. Sin embargo, dicha sincronizaci on es un punto cr tico para tener en cuenta en mediciones de m as alta frecuencia y m ultiples nodos. Para poder realizar y controlar las mediciones de varios dispositivos en paralelo, se propone adem as transmitir los datos mediante una red Ethernet[12]. De esta manera, la recepci on se realiza en una computadora conectada a la red, que ser a la encargada de procesar la informaci on de todos los nodos y almacenarla para su posterior an alisis[3]. Para acceder a la comunicaci on a trav es de la red Ethernet, se realiz o una interfaz gr aca desarrollada con las librer as gr acas Qt[13], que vuelca los datos obtenidos a un archivo de texto. Sin embargo, como en un principio se requer a medir los datos nico dispositivo, dicha interfaz luego no fue utilizada. de un u Finalmente como alternativa al uso de una FPGA en los nodos de sensado, se podr a utilizar un CPLD de bajo consumo. Esto permite disminuir el consumo, para su posterior inclusi on en un nodo funcionando a bater as. Sin embargo, como en nuestro caso se propone utilizar redes Ethernet en futuras versiones, el uso de nodos con FPGA permite mayor exibilidad en el dise no. V. C ONCLUSIONES En el presente trabajo se trat o la implementaci on de un sistema autom atico de medici on y validaci on, implementado
Red de Sensores Hospitalaria para la Medici on de Presi on Endotraqueal

Pablo D. Pareja Obreg on, Alfredo Falc on, Mart n Di Federico Pablo S. Mandolesi, Pedro M. Juli an
Dpto de Ing. El ectrica y de Computadoras Universidad Nacional del Sur Bah a Blanca, Argentina pablopareja@ieee.org
ResumenEn el presente trabajo se desarrolla la concepci on, e implementaci diseno on de un sistema de medici on de presi on endotraqueal para pacientes intubados. El mismo fue probado tanto en laboratorio, como en condiciones normales de funcionamiento. Los bloques de sensado forman a su vez parte de una red de sensores hospitalaria, cuyo objetivo es adquirir tantas variables sobre los pacientes como sean requeridas por el personal m edico. Este sistema fue desarrollado por el Grupo de Investigaci on en Sistemas Electr onicos y Electromecatr onicos (GISEE) de la Universidad Nacional del Sur.1 y el desarrollo En el trabajo se trata la concepci on, el diseno, del sistema hasta llegar al producto terminado.
I.
I NTRODUCCI ON
La microelectr onica y las redes de sensores se encuentran reas tecnol entre las a ogicas con mayor diversidad de campos de aplicaci on[1]. En particular, la medicina es una de las disciplinas afectadas con mayor impacto asociado[2][3]. Muchas de las aplicaciones electr onicas en medicina tienen como objetivo mejorar la calidad de los procedimientos, el control y la supervisi on del paciente antes, durante o despu es de una determinada intervenci on[4][5][6]. Como resultado de un proyecto de colaboraci on entre un hospital local y la Universidad Nacional del Sur, se detect o la necesidad de llevar a cabo alg un tipo de control sobre la presi on endotraqueal en pacientes intubados. En la actualidad no existe ning un sistema de sensado de dicha presi on, quedando la tarea relevada por las enfermeras de turno. Esto trae como consecuencia una apreciaci on subjetiva y poco conable de las medidas realizadas. Por otra parte, por el hecho que la supervisi on no es permanente, la detecci on de cualquier problema se puede realizar con una demora tal que el da no sea irreversible[7][8][9].
1 El presente trabajo fue sustentado parcialmente por la Agencia Nacional de Promoci on Cient ca y Tecnol ogica (ANPCyT), Proyecto PICT 14628, y por la UNS, Proyecto PGI 24/ZK12. P. Juli an es miembro del Consejo Nacional de Investigaciones Cient cas y T ecnicas CONICET, Av. Rivadavia 1517, Buenos Aires, Argentina. P. Mandolesi es miembro de CIC (Comisi on de Investigaciones Cient cas), Pcia. Bs. As, La Plata, Argentina. P. Pareja Obreg on es becario del Consejo Nacional de Investigaciones Cient cas y T ecnicas CONICET, Av. Rivadavia 1517, Buenos Aires, Argentina. A. Falc on es becario PRH de la Universidad Nacional del Sur, Av. Col on 80, Bah a Blanca, Argentina.
Una red de sensores consiste en un conjunto de nodos con capacidad de sensado y c alculo limitadas, que pueden coordinarse a trav es de comunicaciones inal ambricas con el prop osito de llevar adelante alguna tarea. La utilizaci on de redes de sensores nos permite disponer de diversos tipos de informaci on, al instante y desde cualquier sitio[10][11]. La motivaci on del presente trabajo es realizar una red de sensores hospitalarias, que incluya un sistema de medici on de la presi on del tubo endotraqueal en pacientes intubados. Este sistema debe realizar mediciones peri odicas de la presi on, y transmitirlas de manera inal ambrica a un nodo de procesamiento central. El nodo central ser a el encargado de almacenar los datos resultantes de la medici on, y mostrar la informaci on a trav es de una computadora al personal m edico adecuado. El presente trabajo se divide de la siguiente manera: en la secci on II se describe la arquitectura del sistema de medici on propuesto, para luego desarrollar con mayor profundidad cada uno de los bloques implementados. En la secci on III se muestran los resultados experimentales obtenidos, durante la etapa de evaluaci on del sistema, as como pruebas realizadas sobre pacientes en una sala de terapia intensiva. En la secci on IV se describen futuras mejoras en el sistema de medida y nalmente en la secci on V se detallan las conclusiones del trabajo. II. D ESARROLLO El sistema propuesto ha sido dise nado teniendo en cuenta la facilidad de su uso, as como el m nimo consumo y mayor precisi on posibles en la medida. Otro factor de peso en el dise no es la robustez del producto terminado, debido a que ser a transportado continuamente de lugar y por personal no especializado. Si bien la utilizaci on de redes de sensores tiene diversas ventajas en muchas aplicaciones, se deben tener en cuenta sus limitaciones[11]. En particular, cuando las redes utilizadas tienen como medio de comunicaci on nodos inal ambricos, un bajo consumo de energ a es un requerimiento fundamental en el dise no. Esto es debido principalmente a que se debe evitar el cambio peri odico de las fuentes de alimentaci on. Es por ello que en este tipo de redes se debe minimizar la comunicaci on, que es la tarea que mayor consumo de energ a requiere. Para abordar esta problem atica, se busc o realizar comunicaciones
10
peri odicas de datos, en lugar de transmitir continuamente variables del paciente. Esta metodolog a utilizada se desarrolla en la secci on II-A. La aplicaci on de una red de sensores para medici on de variables hospitalarios es un proceso que comprende diversas etapas a mencionar, sistema de medici on, transmisi on y recepci on de los paquetes de informaci on, an alisis de los datos, y nalmente visualizaci on de los mismos. Cada una de estas etapas ser a explicada con mayor detalle en las secciones siguientes. II-A. Sistema Un esquema del sistema completo se muestra en la Fig. 1. El sistema se puede dividir en dos bloques, nodo sensor y base central. El nodo sensor es el encargado de adquirir la se nal resultante de la medici on y transmitirla a la base por radiofrecuencia. La base recibe la se nal y luego de su procesamiento, la muestra en una interfaz realizada espec camente para dichos nes.
Figura 1. Diagrama en bloques del sistema completo
Para poder prender y apagar peri odicamente el sistema, se necesita un circuito con una muy buena precisi on en cuanto a su base de tiempos. El circuito integrado utilizado, que implementa el reloj de tiempo real, es el PCF8593. Entre las caracter sticas principales que inuyeron sobre su elecci on, podemos encontrar el bajo consumo que presenta. Es importante mencionar, que dicho consumo es uno de los factores de mayor peso sobre el consumo total, ya que es el nico componente del sistema que nunca ser u a apagado. Otra de las caracter sticas importantes del circuito integrado PCF8593, es la posibilidad de contar desde cent esimas de segundo, hasta d as e incluso meses. El mismo posee 16 registros de 8 bits, los cuales cumplen distintas funciones. Entre ellas se encuentra congurar su comportamiento. Esto es importante, ya que dichos registros deber an ser congurados de manera previa al ser conectados al circuito, que ser a apagado y prendido de manera peri odica. Para suministrar energ a al circuito, se utilizaron dos tipos de reguladores. El regulador principal es un convertidor de tensi on en base a capacitores conmutados MCP1253. El motivo de dicha elecci on, es fundamentalmente su bajo consumo de energ a mientras se encuentra en modo de apagado. Dicho consumo es de 0, 1A. Sin embargo, el problema de este regulador es que al presentar conmutaciones, se introduce ruido al alimentar el puente del sensor MPX2010. Al introducir ruido en la etapa de sensado, el mismo es amplicado por las sucesivas etapas, obteniendo una medici on poco conable. Para disminuir este ruido, la soluci on fue agregar un segundo amplicador de mayor consumo y menor ruido, pero que nicamente mientras se realiza la medici fuera prendido u on. El regulador utilizado para esta segunda tarea fue un regulador lineal LDO2980. Si bien estos reguladores son menos ecientes en cuanto al uso de la energ a, no introducen el ruido de conmutaci on asociado a los reguladores basados en circuitos conmutados. II-B. Sistema de Medici on
Como el nodo sensor es alimentado por una bater a, es necesario que el consumo de energ a sea lo m as eciente posible. Por otra parte, como la presi on cambia muy lentamente con el tiempo, no es necesario medirla de manera continua. Es por esto, que para disminuir el consumo de energ a, se decidi o colocar un reloj de tiempo real encargado de prender el sistema peri odicamente para realizar la medici on. De esta manera, el reloj genera una se nal que habilita el regulador principal, encendiendo a su vez un microcontrolador CC1010. Durante la medici on de la presi on, el microcontrolador prende otro regulador que alimenta el puente sensor de presi on y su amplicador asociado. Este esquema de manejo de energ a, es utilizado para reducir notablemente el consumo. Esto se logra realizando mediciones durante 10 segundos, cada 15 minutos. La medici on se realiza durante 10 segundos con el n de obtener par ametros adicionales del paciente y detectar cualquier anomal a. Entre los par ametros adicionales medidos se encuentran la presi on capilar y el pulso del paciente, entre otros.
El sistema de medici on y acondicionamiento de se nal debe ser capaz de medir presiones entre 0 y 50mmHg . Estos valores de presi on se deben convertir de manera lineal, en una tensi on entre 0 y 3, 3V , con una precisi on de 1mmHg a fondo de escala. Este valor de tensi on ser a la entrada del conversor A/D del transmisor. La topolog a del sistema de medici on utilizado se muestra en la Fig. 2. Se decidi o utilizar el sensor MPX2010 debido a que posee compensaci on en temperatura y sus valores de resistencia est an ajustados por l aser, obteniendo una lectura nal muy precisa. Este sensor posee una sensibilidad ksensor de 110V /mmHg cuando se lo polariza con 3, 3V . Con este valor y los rangos de presi on de entrada y tensi on se salida se puede calcular la ganancia del amplicador como se muestra en la Ec. 1. Av = Spam entrada A/D = 600 ksensor Spam P resio n (1)
11
Figura 2. Sensado y acondicionamiento de la se nal
La topolog a utilizada posee tres fuentes posibles de error. La primer fuente de error analizada es el ruido, para el cual se utiliz o un ancho de banda m aximo de 100Hz . Como el sensor es resistivo se puede calcular el ruido del mismo como se indica en la Ec. 2 Vnsensor =
100 f =0
r2 (f )df = 380nV
(2)
A continuaci on, podemos calcular el valor de presi on de ruido como se indica en la Ec. 3. El ruido del sensor se puede despreciar, ya que el mismo deber a dividirse por el m odulo de la ganancia al cuadrado. En consecuencia basta con elegir un amplicador de bajo ruido, por lo que se eligi o el amplicador de instrumentaci on INA333 que posee una densidad espectral de ruido de 50nV / Hz . Pnsensor = Vnsensor = 3, 45e3 mmHg ksensor (3)
De la ecuaci on de ganancia del amplicador, tenemos que RG debe ser 166, 94. Asumiendo que la ganancia es 600 2 tenemos que la resistencia RG debe ser 166, 94 0, 1 % ltimo, analizamos la variaci Por u on de la tensi on de alimentaci on. Dichas variaciones cambian tanto la sensibilidad del sensor de presi on, como la referencia del conversor A/D. Es decir, se produce una variaci on de la presi on medida a pesar de que su entrada se mantenga constante. Luego de tener en cuenta los distintos par ametros que afectan esta variaci on, se lleg o a la conclusi on que la m axima variaci on de tensi on admisible es 16, 5mV para un error m aximo en la medici on de 1/3mmHg a fondo de escala. Este valor pone restricciones sobre el ripple de salida de los reguladores. Los mismos deber an poseer un ripple m aximo de 0, 5 % para una tensi on nominal de salida de 3, 3V . Es importante mencionar que el amplicador seleccionado posee bajo offset de entrada, y por lo tanto no inuye en el desempe no del sistema. II-C. Transmisi on y Recepci on Para implementar la transmisi on y recepci on de los datos, se utilizan las facilidades del microcontrolador CC1010 utilizado. El mismo posee una entrada anal ogica, en la cual se conecta la salida del amplicador. Esta entrada es convertida en una palabra digital mediante un conversor anal ogico-digital de 10 bits de resoluci on. Una vez convertida la se nal en un valor digital, es transmitida por radiofrecuencia a un nodo receptor implementado utilizando el mismo microcontrolador. La banda frecuencia utilizada es 433M Hz . Durante la etapa de transmisi on de datos, el consumo de corriente es de 14mA. Es por esto que en el transmisor se deben limitar los tiempos de uso del canal de radiofrecuencia al m nimo. Para esto, el microcontrolador utilizado cuenta con la posibilidad de apagar el m odulo de transmisi on de datos mientras no se necesite. Para nuestra aplicaci on, se realiza la conversi on anal ogica-digital en primer lugar, se procesan los datos y se prende el m odulo de radiofrecuencia reci en
Otra fuente de error es la variaci on de la ganancia. Dicha variaci on se puede controlar con la precisi on de la resistencia RG . Se decidi o que la variaci on m axima de ganancia admisible es de 1/3mmHg a fondo de escala. Para comenzar este an alisis calculamos el valor de tensi on correspondiente a 1/3mmHg , como se muestra en la Ec. 4. V1/3mmHg = Av ksensor 1/3 (4)
Por otra parte tenemos que la variaci on en la ganancia a fondo de escala es VinA/D = Av ksensor P max Igualando 4 y 5 tenemos Av = Av 1/3 =4 P max (6) (5)
12
cuando se vaya a enviar el resultado. Por otra parte, en el receptor no existen problemas de consumo, debido a que se puede extraer energ a de la red el ectrica, o incluso del puerto con que est e conectado el nodo a la computadora. II-D. Presentaci on de datos Una vez que el receptor obtiene los datos de una medici on, la se nal adquirida es almacenada para su posterior uso. Sin embargo, es conveniente mostrar los resultados obtenidos, a medida que se realizan las mediciones. Para ello se desarroll o un programa de computadora utilizando librer as gr acas Qt[12]. En la gura 3 se muestra una captura de pantalla del mismo. Es importante en este tipo de interfaces, adem as de mostrar la forma de los valores obtenidos y su variaci on a lo largo del tiempo, incluir condiciones de alarma. Para asegurar que las alarmas sean atendidas, su condici on de apagado no puede ser temporal, sino que debe requerir la intervenci on del personal de turno.
Figura 4. Caracterizaci on del sistema
Figura 3. Programa desarrollado para el historial de presiones
III.
R ESULTADOS EXPERIMENTALES
Durante el proceso de validaci on del sistema, se realizaron tanto pruebas de calibrado en laboratorio, como pruebas de funcionamiento bajo condiciones normales de uso. Para contrastar los datos obtenidos con los valores de presi on reales, se utiliz o una columna de mercurio est andar conectada en paralelo con nuestro sensor. En la gura 4 se muestra el resultado de variar la presi on de entrada entre 0 y 50 mmHg, que ser an las condiciones normales de funcionamiento. Como se puede observar, los resultados obtenidos concuerdan con los valores indicados por la columna de presi on de referencia. Por otra parte, es necesario caracterizar la variaci on de la medida entre distintos sensores. Para esto, se realizaron mediciones de ganancia y offset sobre una poblaci on de 10 sensores de presi on. Los resultados concuerdan con el 1 % de variaci on en la ganancia de los sensores, y una variaci on debida al offset de entrada menor a 1/3mmHg . Estos valores permiten utilizar nuestro sistema sin necesidad de calibrado, caracter stica fundamental a la hora de producir un dispositivo en grandes cantidades. Por otra parte, el consumo del sensor es relativamente grande, debido a que presenta una impedancia de entrada nicamente de 3k . Sin embargo, el sensor ser a conectado u durante un instante de tiempo, mientras se est a realizando la medici on. Como luego el sensor ser a apagado en el resto del
proceso, dicho consumo no ser a signicativo en el consumo total del sistema. ltimo se realizaron mediciones en la sala de terapia Por u intensiva en un hospital local. El motivo de dichas medidas fue obtener se nales reales de presi on endotraqueal, y as poder optimizar el c alculo de los ltros y dem as par ametros del sistema. Para corroborar la validez de los valores obtenidos, se conect o adem as una placa adquisidora en paralelo con la salida de nuestro amplicador. Dicha placa adquisidora se conecta por un puerto USB con una computadora port atil donde se registran los datos. La tensi on de alimentaci on de la placa adquisidora se obtiene de la misma computadora. Esto es necesario, ya que en todo equipamiento m edico se requiere que no haya un camino de alimentaci on directo entre el paciente y la red el ectrica. Los resultados obtenidos se muestran en la Fig. 5. En la misma se puede observar la presi on de salida del sensor amplicado y su correspondiente valor en mmHg . Se incluye adem as la informaci on espectral de la se nal.
Figura 5. Medidas del sistema realizadas en un hospital local
13
IV.
F UTURAS MEJORAS
Como futura mejora se propone incluir en el sistema mayor cantidad de sensores, que realicen el relevamiento de otras variables m edicas como podr an ser el ritmo card aco y presi on sangu nea, entre otras[13]. Para poder realizar y controlar las mediciones de varios pacientes en paralelo, se propone adem as realizar una interfaz que se conecte a internet. De esta manera, se pueden relevar datos de distintas habitaciones distribuidas a lo largo del hospital, o incluso entre distintos hospitales que compartan til ya que la recepci el sistema. Esto es particularmente u on se puede realizar en cualquier computadora conectada a la red[14]. Por otra parte, el m edico a cargo podr a acceder a los datos desde cualquier computadora con acceso a dicha red. V. C ONCLUSIONES
En el presente trabajo se trat o la implementaci on de una red de sensores hospitalaria para la medici on de la presi on endotraqueal en pacientes intubados. Dicha red es implementada con circuitos de aplicaci on espec ca y microprocesadores de prop osito general. Esta aplicaci on resulta particularmente til, ya que se obtienen variables de pacientes internados u que en la actualidad no se miden con regularidad. Esto a su vez podr a disminuir enormemente los gastos en que incurren los hospitales locales, debidos a tratamientos posteriores a la internaci on, y causados por lesiones del tubo endotraqueal. Todo proyecto consta de varias etapas a mencionar, concepci on, dise no e implementaci on, y testeo. Todas ellas han sido desarrolladas a lo largo del trabajo, mostrando la metodolog a con la que se atac o el problema que se pretend a resolver. En particular, el sistema fue probado satisfactoriamente en laboratorio y en un hospital local. Se proponen algunas mejoras al sistema, las cuales ser an implementadas una vez que se eval ue ptimas la ecacia del sistema y determinen las condiciones o de trabajo. R EFERENCIAS
[1] C. Chong and S. Kumar, Sensor networks: evolution, opportunities, and challenges, Proceedings of the IEEE, vol. 91, no. 8, pp. 12471256, Aug. 2003. [2] P. Bustamante, U. Bilbao, N. Guarretxena, and G. Solas, Wireless sensor for intravenous dripping detection, 14th IEEE International Conference on Electronics, Circuits and Systems, pp. 399402, Dec. 2007. [3] T. Fulford-Jones, G. Wei, and M. Welsh, A portable, low-power, wireless two-lead EKG system, 26th Annual International Conference of the Engineering in Medicine and Biology Society of the IEEE, vol. 1, pp. 21412144, Sep. 2004. [4] S. Young and K. Hsiao, A pharmacokinetic model to study administration of intravenous anaesthetic agents, Engineering in Medicine and Biology Magazine, IEEE, vol. 13, no. 2, pp. 263268, May 1994. [5] C. D. Araujo, M. D. Santos, and E. Barros, A FPGA-based implementation of an intravenous infusion controller system, Proceedings of the IEEE International Conference on Application-Specic Systems, Architectures and Processors, pp. 402411, Jul. 1997. [6] G. Dullerud, M. Csete, and J. Doyle, Application of multivariable feedback methods to intravenous anesthetic pharmacodynamics, Proceedings of the American Control Conference, vol. 1, pp. 791795, Jun. 1995.
[7] J. L. Stauffer, D. E. Olson, and T. L. Petty, Complications and consequences of endotracheal intubation and tracheotomy. a prospective study of 150 critically ill adult patients, The American journal of medicine, vol. 70, no. 1, pp. 6576, Jan. 1981. [8] J. R. Braz, L. H. Navarro, I. H. Takata, and P. N. J unior, Endotracheal tube cuff pressure: need for precise measurement, S ao Paulo medical journal, vol. 117, no. 6, pp. 2437, Nov. 1999. [9] C. Ganner, The accurate measurement of endotracheal tube cuff pressures, British journal of nursing, vol. 10, no. 17, pp. 112734, Sep. 2001. [10] G. J. Pottie and W. J. Kaiser, Wireless integrated network sensors, Communications of the ACM, vol. 43, no. 5, pp. 5158, May 2000. [11] B. Sadler, Fundamentals of energy-constrained sensor network systems, Aerospace and Electronic Systems Magazine, IEEE, vol. 20, no. 8, pp. 1735, Aug. 2005. [12] M. K. Dalheimer, Programming with Qt. OReilly, 2002. [13] R. Weber, Transtracheal doppler: a new method of cardiac output measurement, Proceedings of the Annual International Conference of the IEEE Engineering in Engineering in Medicine and Biology Society, vol. 5, pp. 15711572, Nov. 1989. [14] H. E. Williams and D. Lane, Web database applications with PHP & MySQL. OReilly & 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.
14
Post-silicon Validation Procedure for a PWL ASIC Microprocessor Architecture

Instituto de Investigaciones en Ingenier a El ectrica - IIIE (UNS-CONICET) Departamento de Ingenier a El ectrica y de Computadoras Universidad Nacional del Sur Av. Alem 1253, (8000) Bah a Blanca
O. Lifschitz, J. A. Rodr guez, P. Juli an, O. Agamennoni
Abstract In this paper, we present the environment set for validation and testing a particular ASIC that implements a piecewise linear (PWL) architecture. Description for a package debug propose is included. Methodologies for power consumption and envelope and maximum operation frequency estimation, based on laboratory measurements, are described.
II. B RIEF D ESCRIPTION OF THE PWLR6 ARCHITECTURE In this section, a brief description of a digital architecture that implements an R6 PWL is presented. The idea is to explain the complextity level of the ASIC to evalute. The proposed architecture is based on a microprocessor [7] scheme that includes an ALU (Arithmetic Logic Unit), a register le and a control unit [8]. Figure 1 illustrates the block diagram of the PWL chip.
Control Unit
Program Bus
I. I NTRODUCTION Piecewise linear functions are a mathematical abstraction widely used in circuit theory, computer graphics, and system identication [1]. The evaluation of this type of functions has been approached in different ways by diverse algorithms such as: simplicial paths [2], comparator architecture [3], and more recently neural networks [4]. A dedicated microprocessor named PWLR6 was designed using a full EDA ow using standard AMI 05 OSU standard cells library [5]. The P was designed in order to execute the calculation of a sixinput PWL function with a high degree of exibility [6]. A micro-programmed control unit enables the setup of different congurations using the PWLR6 ISA (Instruction Set Architecture). Absolute and relative jumps, ALU (Arithmetic Logic Unit), memory read and write, and register access instructions, provide a rich environment to exploit the PWLR6 P functionalities. In this paper, we present a set of debug features and methodologies to proceed with a Post-silicon validation and testing environment requirements to deal with the complexity of the PWL P. Specic Design For Testability (DFT) and observability features were introduced in the early ASIC design stage. These DFT features run the whole verication ow together with the PWL silicon. In order to create an efcient testing environment, a synchronization between silicon results and simulation data within a clock period resolution was achieved. Random tests procedure were used to ensure a better test coverage in order to guarantee the correct chip functionality. Morevoer, a Well known pre-silicon tests scenarios were prepared to consistently evaluate each of the PWLs blocks separately in case of a bug or a missfunctionality occurs. Methodologies for power measurements and maximun operational frequency were developed and are shown in the paper, together with experimental results.
Datapath
XY Bus
SR-PM
SR38 VRT CNT
MPC
Reg.1 Reg.2 Reg.3 Reg.4 Reg.5 Reg.6
Fetch Logic
Program Memory
Tag1 Tag2 Tag3 Tag4 Tag5 Tag6 Reg.B Reg.A
MIR
Decode Logic
Acc
RSX
MUX
MUX
DFT
Bypass Logic
DFT Bus
Control Bits
ALU
Rout Test MUX

Test Bits
Scan chain
MADR
Data Memory Bus
Fig. 1.
PWL blocks.
Figure 2 ilustrates PWL Chip.
Fig. 2.
PWL chip.
15
III. T ESTING E NVIRONMENT A. Hardware environment In this section, a brief description of the hardware (HW) environment is presented. The HW consists of a master-slave conguration where the PWL is in the role of slave and the master is implemented on a Xilinx Test board with a Virtex5 FPGA. The PWL uses a DDR2 Device where the controlller and the memory transfer hub (MTH) are realized on the Virtex5. The MTH is responsable for adapted the memory controller with the PWL chip memory protocol, also allows the functionality of the systems at different frequencies between the memory controller and the PWL chip. The systems frequencies are: Master@100MHz, Memory controller@160MHz and the PWL@[6,25Mhz - 50MHz]. The master interconnects with a PC, through RS232, with the Matlab interface. The PWL chip is placed on a two layer PCB. This PCB includes some pin connectors for the logic analyzer and for an easy power measurement. Figure 3 ilustrates system hardware scheme.
functionality. The state machines are: ASM Load.- Programs the PWL ROM with the assembler. This was done using two asynchrony signals: data and clock. Both signals are generated by the master. Chip clk gen.- Generated the PWL clock. This machine implements the Stop clock and Do 1 clk features. (See DFT part) Exe calc func.- Executes the PWL activation. This machine puts the PWL to work by sending the start signal and series Xi inputs (Xi R6 ) to the PWL and then wait for the PWL to transfers the result back. This machine will send the nal results to the Human Interface. DFT block.- Generates the debug features activation: Scan, Bypass-Scan and Bypass. (See DFT part). The selection will be set by the picoblaze based on the human interface decision. This state machine performs the rst data format before reach the PC interface. PC SW.- Its a Matlab interface dealing with the instruction commands to the PicoBlaze and formatting the data for the human interface. Also, creates the random cases and compares the chip results with the PWL implemented in a Matlab private toolbox. IV. D ESIGN FOR TESTABILITY The main idea of the following structures is to help the designer during the validation process. This DFT strategy development started in the design stage together with the chip development and its functionality was checked on simulations at pre-silicon stage. Six DFT were created: Stop Clk.- Some events, internally or externally, could enable the PWL chip clk freezing the execution. These events could be completely synchronized with the simulation tool in the case the user needs a time correlation for simulator comparison. This synchronization allowed an easy verication register by register for clock by clock operation. The syncronization was achived by a counter that has the number of clocks, this ensures the correlation between the simulation and the chip. The option for an external Stop Clk signal assertion is available but this is asynchronous and no time correlation can be guaranteed. Do 1 Clk.- Triggers a one PWL clock pulse allowing the execution of the PWL routines step by step. This signal activation can be external or internal. In the internal case will be when other DFT are using it. In the external case the activation is from the human interface command. The following two DFT: Mux and Scan are related to the observability. The idea was to carry internal signals out. These signals are selected from the data and control ow path. Mux.- This is an externally activated multiplexer that takes different internal signals out to I/O pins. The mux out is in parallel format. The relation between the number of bits and the number of observable registers is a trade-off and depends on design considerations. This DFT has on the y activation, meaning that it is capable of taking out signals while the chip is running. Of course, this is an expensive DFT due to the amount of I/O pins but, on the other hand, is the simplest one to build. Also, this mux allows the creation of a signature
Fig. 3.
System view.
B. Software environment There are several software (SW) levels in the system, each of them running on a different part of the HW environment. PWL Assembler.- This assembler activates the PWL for the N-dimensional input data X from the master, calculates and sends the results back to the master. Besides that, other assembler codes were development based on the debug necessity. These assembles allow to activate different parts inside the PWL chip or, in the case of power, to activate the ALU at maximun load. The PWL has 256 by 20 bits wide instruction ROM space. The master programs the PWL ROM while the PWL is in programming mode. The assembler code is hardcoded in the FPGA. The programming and execution modes are set by the master. Master SW.- The master SW has four state machines and the PicoBlaze micro-controller. The PicoBlaze is an eigth bit VHDL micro-processor and operates the RS232 interacting between the state machines and the Matlab command instruction sets. The state machines control the PWL activation and
16
signals on the logic analizer creating an easy scenario to compare with the simulator. Scan.- This takes out a number of different bits coming from different internal PWL block. The scan out is serial on a daisy chain format. As opposite to the Mux, the scan has to be activated when the PWL is stopped by the Stop Clk signal. In terms of out pins, this feature is cheaper because used only to out pins: data and clock. Bypass-Scan.- It is similar to the Scan but acts only on the Control-Register. Due to its complexity and importance the control register has a dedicated DFT. The Control-Register has the ASM instructions that are 20 bits. Bypass.- The Bypass DFT allows writing the control register from the outside world putting aside the ROM interface. This DFT should be perfectly synchronized with the PWL clock to allow the correct work. The Bypass-scan and Bypass DFT were introduced in the PWL silicon to replace the internal ROM device in case of design or manufacturing failure. The idea was to allow the onion peeling procedure, means that if ROM failure was detected, the chip debug would continue using the Bypass DFT and validation process would not stop. V. P OST-S ILICON A. Block functional verication The block functional verication requires to test every block independently. Asserting the functionality of each block allows to build a step by step process and isolate problems when they appear. This verication was done using a friendly and exible PWL assembler compiler. Six main blocks were included in this verication process: Design for testability.- Much of these features were tested in pre-silicon using a logic analyzer but due to fact that the PWL was the rst silicion including these kind of validation hardware, a validation slot for these blocks was included (These blocks are not part of the PWL evaluation). Ideally, these blocks should be a legacy well know HW design that is inherited from design to design. FPGA State Machines.- The state machines were checked with a logic analyzer before PWL silicon arrival. Signal protocol and timing were checked with the simulation results comparison. ROM Memory.- It was veried using a observavility DFT that allowed to check the correct data was being written. This was a big concern because no pre-silicon test could be done. Xi Protocol.- Includes all the asynchronous protocol between master and slave. A DFT and a logic analyzer were used to verify all the signals to ensure the correctness of the Xi data. Sorting.- Due its strong dependency with the n-dimensional value, different set of inputs were used and the correct order after sorting routine were check with an obserbavility DFT. Changing different data sets and comparing with simulation results allowed to veried the correct sorting routine. External Memory Access.- A bi-directional I/O was involved here so a particular PWL assembler was used to read and write to different memory addresses. The data was veried using a DFT and a logic analyzer. Moreover, the whole system: PWL,
MTH and memory controller had a special attention during validation due to the different frequencies operations. ALU.- Besides the PWL calculations, a set of different mathematical operations were test and the results checked using the address I/O pins. B. Functional verication Two set of cases where used in this stage: from simulations and random cases. The simulation cases used for DFT and correlations test with the simulator. Random cases were compared with matlab toolbox using a Linear-Function space instead of no-linear to get a direct error calculation. The main difference between these cases is the run speed. Means, the simulations are some reduced set of Xi values running on the simulations and all the DFT (Scan and Mux) values are generated and used for comparison between Modelsim simulator and the chip. In this case, the memory size used was very small and the values were hardcode on the simulated VHDL code. On the other hand, the random cases are generated by matlab and the whole 16MB memory map was used. Matlab created a random Xi input, send it to the PWL and the result was compared with the matlab calculation. The correct results of all these cases were the base for the maximum frequency test on next section. Figure 4 shows some of the random test results. The error between PWL-chip and Matlab should be 0 as expected.
PWLchip Vs Matlab 80 F(x1,...x6) 60 40 20 0 0 1000 1500 N of running Percentage Relative Error PWLchip Vs Matlab 500 2000 Matlab Chip PWL
1 0.5 0 0.5 1 0 500 1000 N of running 1500 2000
Fig. 4.
Matlab Vs Chip comparison .
VI. F REQUENCY MEASUREMENTS The idea was to verify the maximum PWL operational attainable frequency for this design and technology. The I/O and core power planes in the PWL are unied. This unication limited the highest voltage applied to the PWL due the I/O clamping connection with the FPGA. In order to overcome to this voltage limitation the procedure was to dene a test that allowed extrapolation of the maximum PWL frequency, without changing the PWL core-I/O voltage beyond the FPGA I/O limits. This test exercises the critical
17
path obtained from simulations. This critical was the part related with the ALU execution and was veried in the laboratory by exercising different parts inside the PWL circuit till we have a functional failure. The failure or success of this test was our fail/pass criteria in the Frequency Vs PWL Vcc core graph. The test consisted on reducing Vcc, maintaining a x PWL frequency, until a failure result occurred. A fail result was the one that gave a different number comparing with the simulation results but the chip was still functional. The idea of functionality was that only the numerical result was the error and not the PWL protocol behaviour. The PWL frequency change was done using the DCM block in the FPGA. Figure 5 exemplies the DCM connection.
procedure to measured each components was done following the next table:
Power Item Static Clock Tree Dynamic CLK off on on Reset on on off Running off off on
The running condition means that the PWL is executing the assembler instructions. Power consumption was measured using a series resistor on the PWL Vcc connection. The value of this resistor is calculated to keep the voltage on the resistor at working range between 600mV and 1500mV. The idea was to maintain the same resistor value for all the measurments. The resistor was 100. The measurements were done with two devices: digital scope (Agilent DSO3062A) and a multimeter Hewlett Packard (HP34401A). The idea of using both elements was to correlate the results. A. Consumption time picture To get an idea of the PWL power consumption, a scope picture was captured showing the consumption while a test is on execution. Figure 7 shows the power consumption Vs time during a test execution.
Power PWL (Freq: 6,25MHz) 10
Fig. 5.
Frequency shmoo .
Figure 6 ilustrate the maximum PWL operational frequency for each Vcc value with a different coverage level.
60
55
6
Freq [ MHz ]
Power [ mW ]
50
45
0
40 Weak coverage Strong coverage 35 3 3.1 3.2 3.3 3.4 Vcc [ V ] 3.5 3.6 3.7 3.8
Stand by Getting Xi Sorting Calculation & mem access Sending results Wait for a new Xi Req
4 20
20 Time [ us ]
40
60
80
Fig. 6.
Freq. Vs Vcc.
Fig. 7.
Power Activity.
The difference in coverage is related with the simulation and random cases mentioned before. Although boths kind of test point to the ALU execution, the random test were more than twenty thousand cases and simulations cases are nine. Thats why the difference in the frequency results observed on picture Frequency Vs Vcc results. VII. P OWER MEASUREMENTS The power consumption has three main components: static consumption, clk tree and the dynamic consumption. The
In the Figure 7 the Req signal belongs to the asynchrony protocol and is shown here just as an activity reference. (This signal does not have the correct voltage scale.) The consumption time picture was a base for the creation of a Power Virus. The worst power consumption occurred during calculation and memory access, based on these facts a PWL assembler which fully activates the ALU and the I/O was done. This assembler is called Power Virus because is the maximum power that the PWL can dissipate. The ALU, which is the highest consuming block, was running at the
18
maximum execution velocity on an innite assembler loop. In this power virus an I/O out instruction was added, this gives the power virus with pad activity. The power virus assembler was used to calculate the consumption for different Vcc cores and operation frequencies. Also, gives the worst case power envelope for disipations considerations. B. Power measurements The static power was around 160nW. As mentioned before, this static power was when the PWL clk tree was off and the PWL reset was asserted. Using the power virus assembler, the procedure was to measure the power consumption for different operation frequencies. As expected, the maximum power quote was for the power virus with full I/O activity. Table I shows the power measurements results for the: clock tree, power virus with and without I/O activity.
TABLE I P OWER @3,3V PWL Freq. [ MHz ] 25 12,5 6,25 Clock Tree 22,70 11,42 5,69 Power [ mW ] P. Virus P. Virus + I/O 34,91 49,68 17,60 24,87 8,75 12,40
[6] V. M. Jimenez, J. A. Rodriguez, P. M. Julian, O. Agamennoni, O. Lifschitz, VLSI Microprocessor Architecture for a Simplicial PWL Function Evaluation Core, in Proc. Arg. School of Micro Nanoelectronics, pp. 1-6, 2008. [7] Intel Co., Microprocessor and Peripheral Handbook, Volume 1Microprocessors, Intel, 1987. [8] V. M. Jimenez, J. A. Rodriguez, P. M. Julian, O. Agamennoni, M. Di Federico, Digital architecture for R6 PWL function computation, in Proc. Arg. School of Micro Nanoelectronics, pp. 1-6, 2007.
VIII. C ONCLUSIONS In this paper we have presented a post-silicon validation and testing methodology. Three important conclusions were: the proactive work done with the environment preparations, like: DFT features, different assembler codes, assembler compiler, etc. Dened methodologies setups for power consumption, blocks validation and the attainable maximum frequency for this kind of silicon. Studied the importance of dening a correct coverage during silicon validation specially when the pre-silicon could not cover all the cases due to the complexity of the testbench scenarios. IX. ACKNOWLEDGMENT We would like to thanks to Ing. Ariel Arelovich for the PWL assembler compiler that fruitful helped us during validation. R EFERENCES
[1] L. Castro, J. Figueroa, O. Agamennoni, BIBO stability for NOE model structure using HL CPWL functions, in Proc. of Modelling, Identication, and Control, 2005. [2] M. Chien and E.Kuh, Solving nonlinear resistive networks using piecewise-linear analysis and simplicial subdivision, IEEE Transactions on Circuits and Systems, Vol.24, pp. 305-317, 1977. [3] P. Mandolesi, P. Juli an, and A. Andreou, A scalable and programmable simplicial CNN digital pixel processor architecture, IEEE Transactions on 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 Systemon-Chip Designs,, International Conference on Microelectronic Systems Education, IEEE Computer Society, pp. 11-12, 2005.
19
20
DSPs
21
22
Desarrollo e Implementacin de un Controlador Activo de Ruido de Banda Angosta Adaptativo

F. A. Gonzlez, R. Rossi, G. R. Molina y G. Parlanti
Laboratorio de Procesamiento Digital de Seales Universidad Nacional de Crdoba Crdoba, Argentina rrossi@efn.uncor.edu rmolina@efn.uncor.edu
ResumenSe presenta en este trabajo el diseo y construccin de un sistema Controlador Activo de Ruido (CAR) adaptativo, basado en un Procesador Digital de Seales 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 difcil de cancelar por medios pasivos de cancelacin acstica, pero utilizando tcnicas activas como la presentada, se logran atenuaciones apropiadas y eficientes para el uso comercial. Palabras claves: CAR, Controlador Adaptativo, FxLMS
de Procesadores Digitales de Seales (DSP, Digital Signal Processors), de gran capacidad de procesamiento, tanto la adaptacin de los coeficientes como el proceso de la seal de entrada del CAR pueden realizarse en tiempo real. En este trabajo se presentan detalles del diseo y de la implementacin de un sistema CAR en un dispositivo DSP comercial, aplicado a la cancelacin de ruido dentro de la cavidad de un auricular comercial. II. CARACTERSTICAS DE DISEO
I.
INTRODUCCION
En ambientes industriales, receptculos cercanos a motores (como en la cabina de un avin o automvil) o en entornos ruidosos en general, los auriculares utilizados para la cancelacin acstica 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 cancelacin se produce en un espacio reducido, como dentro de un auricular, el sistema CAR se lo denomina unimodal y su objetivo es producir una seal de igual amplitud y fase contraria al ruido remanente dentro de la cavidad del auricular, comnmente 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 acstica del auricular ha cambiado, por ejemplo por diferencias anatmicas de quien lo usa. El sistema CAR debe ser capaz de adaptarse a estas variaciones, modificando en consecuencia la seal antiruido producida. A tal fin utiliza la diferencia entre la seal producida y la deseada (el ruido a cancelar) para modificar su propia funcin de transferencia mediante algn 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 ms sencillos de realizar y por ser incondicionalmente estables, en contrapartida con los filtros de respuesta al impulso infinita (IIR, Infinite Impulse Response). La modificacin de la funcin de transferencia requerida se realiza entonces modificando en forma automtica los coeficientes del filtro. Los filtros FIR requieren de mayor cantidad de coeficientes que los IIR, pero con el advenimiento
A. Arquitectura general de un sistema adaptativo En general, un sistema adaptativo modifica su propia transferencia partiendo de cun 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 diseado para identificar un sistema desconocido. La seal de entrada, tambin llamada referencia, se representa por la seal x(n), la transferencia del sistema desconocido por P(z) y la salida del mismo, d(n), representa la seal que se desea cancelar. La seal 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 adaptacin del controlador. De lo expuesto, se define a la seal de error como: e(n) = d(n) y(n) = x(n)*p(n) x(n)* h(n). (1)
x(n)
d(n) P(z) _ y(n) H(z)
e(n)
Alg. Sistema Adaptativo
Figura 1. Sistema Adaptativo
23
La seal e(n) es quien gobierna el proceso de aprendizaje. En (1), * denota convolucin, 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), detenindose la adaptacin. 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 adaptacin ms utilizado por su sencillez y robustez es el llamado Least Mean Squares, LMS, [3] que produce la adaptacin iterativa de los coeficientes del FIR H(z) segn: hk(n+1) = hk(n) + e(n)x(n) (2)
Entorno Acstico ruido P(z) deseada _
error
antiruido S(z) x(n) H(z) LMS y(n) e(n)
S(z)
Figura 2. CAR en un auricular
El algoritmo de adaptacin en este caso se llama LMS de referencia filtrada o FxLMS (por sus siglas en ingles de Filtered x Least Mean Squares) [4]. C. Estimacin del camino secundario La Fig. 2 supone que la transferencia S(z) se conoce, ya que debe usrsela para filtrar la seal de referencia x(n). En general esto no ser as. Adems la funcin 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 funcin de transferencia. El esquema se muestra en la Fig. 3. Una vez convergido este segundo sistema adaptativo, su funcin de transferencia Sp(z), ser una buena aproximacin a S(z), y se utilizar una copia de la misma, cSp(z), para filtrar la seal de referencia x(n), produciendo la seal de referencia filtrada x(n). En la Fig. 3, la seal v(n) es una seal de aprendizaje estadsticamente independiente de x(n) para que los procesos de aprendizaje no interfieran entre s. La seal 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)
donde k = 1, 2, L, siendo L la cantidad de coeficientes del filtro FIR, y el paso o velocidad de adaptacin entre la iteracin n y la n+1. Un valor de pequeo har el aprendizaje lento, pero lograr un error e(n) remanente pequeo. Un valor de alto har el aprendizaje rpido, a expensas de un e(n) remanente ms alto adems de poner en riesgo la convergencia hacia el valor ideal, normalmente llamada solucin 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 seal de entrada segn: (n)= /LPx(n) (3)
donde es una constante y Px(n) es la potencia de la seal de referencia x(n) en el instante n. De esta forma el paso (n) utilizado con seales de baja potencia ser mayor, acelerando el proceso de convergencia, mientras que con seales 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 acstica entre el exterior y el interior del auricular, y la seal de referencia x(n) el ruido fuera del auricular. La seal deseada d(n) representa el ruido a cancelar, remanente en el interior de la cavidad. En este caso, la seal de error se encuentra en el entorno acstico y no en el elctrico. Esta situacin se muestra en la Fig. 2. En este caso, el controlador H(z) no podr gobernar la seal antiruido directamente, sino a travs de elementos fsicos como un conversor Digital/Analgico y un parlante. Del mismo modo, el error acstico y la seal de referencia debern ser captados por micrfonos y ser convertidas a digital por un conversor Analgico/Digital, para transformarse en la seal discreta e(n) y x(n) respectivamente. Adems de estos bloques, normalmente son necesarios amplificadores y atenuadores. Todos estos bloques adicionales, se suelen representar por una sola funcin de transferencia llamada camino secundario S(z). Para compensar el efecto de S(z) y aplicar los mismos criterios de aprendizaje de (2), la seal de referencia x(n) debe afectarse o filtrarse por la misma funcin de transferencia S(z).
La seal 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)], detenindose ambas adaptaciones. Si ambos procesos adaptativos se realizan simultneamente, se dice que el camino secundario se modela on-line. La seal v(n), requerida en una estimacin on-line, siempre est presente en el error e(n), siendo esta ltima la seal que el usuario escucha. Por ello, es conveniente disminuir o anular v(n) una vez que el proceso adaptativo de estimacin del camino secundario ha convergido [5]. En la prctica, tambin es comn realizar una estimacin 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 algn motivo, el sistema adaptativo Sp(z) vuelve a activarse para emular esos cambios.
24

x(n) d(n) P(z) _
e(n) q(n)
d(n) _
e(n) q(n)
S(z) y(n) _ Sp(z) _
S(z) y(n) _ _ Sp(z) v(n)
H(z)
+
v(n)
-+
f(n) x(n) cSp(z)
H(z)
+
f(n)
cSp(z) LMS
LMS
LMS
cSp(z)
x(n)
LMS
Figura 3. Sistema CAR con estimacin del camino secundario
+ Figura 4. CAR para ruidos de banda angosta
Es importante notar que para que el filtro H(z) sea causal el tiempo de proceso del sistema adaptativo ms el retraso del camino secundario S(z) debe ser menor al retraso de la transferencia P(z). D. Alcance del CAR Al disear un sistema CAR, lo primero que debe definirse es el tipo de ruido que se desea cancelar, dependiendo ste del ambiente donde se deba desempear. 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 msica, conversaciones entre personas, ruido blanco gausseano, etc, el ruido a cancelar ser de banda ancha, encontrndose un contenido espectral ms distribuido. Este trabajo se concentra en el primer caso, la cancelacin 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 seal de referencia x(n), y cualquiera sea su espectro el sistema podr aprender partiendo de ella. La seal de referencia debe tomarse desde el exterior del auricular, mediante un micrfono adicional al del error, denominado micrfono de referencia. Si se desea que el CAR slo acte sobre ruidos de banda angosta, como en nuestro caso, el esquema de la Fig. 3 puede simplificarse, prescindiendo del micrfono de referencia. En ese caso la seal x(n) podr estimarse dentro del mismo proceso, segn se muestra en la Fig. 4. La seal 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)
En contrapartida, el esquema de la Fig. 4 solamente funcionar para cancelar ruidos de banda angosta (peridicos) pues si no el retraso del conjunto H(z)S(z) debera ser cero. III. IMPLEMENTACIN DEL SISTEMA
La implementacin 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 ncleo de cuatro ALUs, capaz de realizar 1000 MMACS a 266MHz. La capacidad de procesamiento del DSP es suficiente para realizar el clculo computacional complejo que requiere la realizacin de los filtros adaptativos para ambos canales dentro del tiempo de un perodo de muestreo (procesamiento en tiempo real por muestras simples). El software del controlador o programa de aplicacin est montado sobre un sistema operativo de tiempo real o RTOS (por sus siglas en ingls Real Time Operating System), que corre sobre el DSP. Dicho sistema operativo es el SmartDSP de la empresa Freescale Semiconductor Inc, diseado especialmente para los DSP de la familia StarCore. La interface de programacin de aplicacin o API (por sus siglas en ingls Application Program Interface) del SmartDSP [6], esta formada por funciones desarrolladas en lenguaje C, que permiten una fcil configuracin y utilizacin de los perifricos del DSP. Para cada tipo de estos perifricos, existe un driver del sistema operativo, que permite la comunicacin del programa de aplicacin con los mismos. En el software del controlador se emple el driver del perifrico TDM (del ingls 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 aplicacin, ya que el rango de frecuencias de inters de un sistema CAR corresponde a frecuencias por debajo de los 500Hz. El programa de aplicacin fue desarrollado ntegramente en lenguaje C, empleando funciones denominadas intrnsecas a la hora de realizar y optimizar el procesamiento de los filtros adaptativos. Estas funciones intrnsecas son funciones en C que no pertenecen a la API del RTOS, sino que son funciones propias del compilador [7], especialmente diseadas para realizar operaciones fraccionarias y optimizar el programa de
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 seal peridica 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 micrfono de referencia.
25
aplicacin, aprovechando las caractersticas de procesamiento paralelo del DSP. Las funciones intrnsecas se intercalan directamente en el cdigo en lenguaje C, permitiendo al programador aproximarse a la eficiencia propia del lenguaje ensamblador del DSP. La precisin de la mayora 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 actualizacin de los coeficientes de los filtros en el proceso adaptativo y evitar que la adaptacin se detuviera prematuramente por falta de precisin, se utilizaron 32 bits para el resultado del producto entre el paso de adaptacin y la seal de error f(n), implicando esto la realizacin de multiplicaciones de 32 x 16 bits en la actualizacin de los coeficientes de H(z) en el segundo sumando de (5). Esto llev a una mejora importante en el desempeo de todo el sistema. El modelo experimental implementado para evaluar el desempeo 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 versin normalizada. El diagrama en bloques para cada canal del sistema CAR, se muestra en la Fig. 5. A continuacin se explican cada una de las partes de este modelo. A. Placa de evaluacin del Procesador Digital de Seales El mdulo 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 evaluacin del software del controlador sobre el DSP, va puerto paralelo con una PC porttil. Adems por medio del CODEC integrado en la misma, ingresan y salen al DSP las seales analgicas de los transductores electroacsticos. El CODEC es el AK4554 de 16 bits estreo de la empresa AKM Semiconductor Inc., el cual realiza las conversiones A/D y D/A para ambos canales, adems de efectuar los filtrados antialiasing y de reconstruccin (filtros pasa bajos) correspondientes. La entrada y salida de datos dentro del DSP para ambos canales del controlador, es realizada a travs de su perifrico TDM, el cual se comunica con el CODEC. B. Sistema acstico El auricular utilizado es el auricular circumaural estreo SHP1900 de Philips, de una relacin calidad-precio conveniente. Dada la caracterstica de ser un auricular circumaural, las orejas de quien escucha son cubiertas totalmente por las almohadillas del auricular, crendose pequeas cavidades acsticas en torno a cada uno de los odos. Como sensores de error se usaron los micrfonos omnidireccionales ECM-30, los cuales son micrfonos del tipo Electret. Este tipo de micrfonos tienen caractersticas que son ms que suficientes para aplicaciones de CAR (en lo que respecta a sus anchos de banda, sensibilidades y relaciones seal-ruido), adems de ser de tamao fsico muy reducido, por lo que son ideales para nuestra aplicacin. La ubicacin de los micrfonos de error dentro del auricular determina la zona de quietud, y fue sugerida por los autores de [9] y [10] como la ubicacin ideal.
Figura 5. Diagrama en bloques de un canal del modelo experimental.
Dicha ubicacin corresponde a la ms cercana al tmpano del odo, adems de demostrarse experimentalmente que esta configuracin presenta la respuesta en frecuencia de la magnitud del camino secundario, ms plana que otras configuraciones [9, 10]. C. Placa amplificadora Se desarroll un preamplificador para cada micrfono y el amplificador de potencia del auricular. Cada preamplificador es del tipo transistorizado y tiene como funcin el acondicionar el nivel bajo de la seal de cada micrfono hasta un nivel de seal 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. Identificacin del camino secundario S(z) Como hemos visto anteriormente, y se mostr en la Fig. 4, la estimacin de S(z), que llamamos Sp(z), es necesaria para estimar la seal de referencia x(n). Adems, se la utiliza para la actualizacin de los coeficientes del controlador H(z) con el algoritmo FxLMS, segn (5). En la presente implementacin se realiz una identificacin del camino secundario S(z) de manera off-line. Para realizar la identificacin 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, segn (2). Como seal 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 adaptacin = 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).
26
Amplitud
Cantidad de Coeficientes del Filtro
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 estimacin de S(z). Para observar la evolucin 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 seal 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 identificacin en rojo (en este caso la nica componente de f(n) en la Fig. 4). B. Desempeo del controlador H(z) Para evaluar el desempeo del controlador, se generaron en MATLAB diferentes ruidos de prueba. Luego se los emiti con los parlantes de una PC porttil. Una persona portando los auriculares se ubic de frente a los parlantes de la PC, recibiendo el ruido generado de manera uniforme en cada odo. Durante el proceso de las mediciones se empleo la estimacin de S(z) obtenida previamente de manera off-line. Para la adaptacin de los coeficientes del controlador H(z) se utiliz la versin 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 aproximacin Px de la potencia Px se utiliz una ventana exponencial de la forma:
Amplitud
Muestras
Figura 8. Evolucin temporal de la identificacin de S(z).
Px(n) = (1-)Px(n-1) + x2(n)
(7)
lo que requiere almacenar un solo valor (Px(n-1)) entre iteraciones, y utilizar un factor que determina la rapidez en que los cambios de x(n) se reflejarn en Px(n). Para ello se eligi = 0,002 como compromiso entre una aproximacin buena y estable de Px y el seguimiento rpido 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 mnimo PxMIN(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 porttil, generando as suficiente contenido armnico. 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 medicin 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 armnicas, casi de la misma amplitud, y un tono de 50Hz, presente en el circuito. La atenuacin que se logr para el tono de 200Hz, sus armnicas y el tono de 50Hz se muestran en la Tabla I, para ambas precisiones de los coeficientes de H(z). Para armnicas siguientes a 600Hz prcticamente no se percibe atenuacin. El desempeo del controlador tambin fue probado con un tpico ruido de maquina [11], tambin generado en MATLAB, y reproducido sin distorsin por los parlantes de una PC porttil. El mismo est formado por 12 componentes mltiplos de 60Hz de distinta amplitud, con la mayor potencia concentrada en las componentes de 240, 300, 360, 420 y 480Hz. La medicin tambin 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 seal error para coeficientes de H(z) de 16 bits y en rojo para coeficientes de 32 bits. La atenuacin de las componentes ms significativas del ruido de maquina se detalla en la Tabla II para ambas precisiones de coeficientes.
Magnitud (dB)
Frecuencia (kHz)
Figura 7. Magnitud de la respuesta en frecuencia de Sp(z).
27
V.
CONCLUSIONES Y DIRECCIONES FUTURAS
A partir del anlisis y los resultados presentados en este trabajo se resumen las siguientes conclusiones: El sistema CAR diseado e implementado atena en forma aceptable diferentes ruidos peridicos (o de banda angosta) en la banda de frecuencia de inters. La precisin y capacidad de cmputo del DSP utilizado fue suficiente para realizar el procesamiento de ambos canales independientes de audio en tiempo real en forma simultnea. Es apreciable la mejora al utilizar coeficientes de 32 bits para H(z). Para las seales 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 activacin del CAR.

Figura 9. Espectro de potencia de ruido de 200 Hz distorsionado (lnea azul), seal error con coeficientes de 16 bits (lnea verde) y 32 bits (lnea roja).
TABLA I. ATENUACIN DEL TONO Y SUS ARMNICAS Frecuencia (Hz) 50 200 400 600 Atenuacin coeficientes 16 bits (dB) 33,5 51 44 35,5 Atenuacin coeficientes 32 bits (dB) 29,5 85,3 67,4 59,5
Las direcciones futuras se orientarn al anlisis, diseo e implementacin de un CAR aplicado a la cancelacin de ruido de banda ancha en un auricular. Asimismo, se investigarn y analizarn otros algoritmos de adaptacin, implementndolos en condiciones reales y con componentes disponibles comercialmente. AGRADECIMIENTOS A la Secretaria de Ciencia y Tecnologa de la Universidad Nacional de Crdoba, 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.115. [2] B. Widrow and S. Stearns, Adaptive Signal Processing, 1st ed., Englewood Cliffs,NJ:Prentice-Hall, 1985, pp.396. [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. 563587. [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 Users 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=/prod ucts/demos/shipping/filterdesign/adaptfxlmsdemo.html
Figura 10. Espectro de potencia del ruido de maquina (lnea azul), seal error con coeficientes de 16 bits (lnea verde) y 32 bits (lnea roja).
TABLA II. ATENUACIN DEL RUIDO DE MQUINA Frecuencia (Hz) 240 300 360 420 480 Atenuacin coeficientes 16 bits (dB) 31,3 46,7 35,2 38,7 25,6 Atenuacin coeficientes 32 bits (dB) 56,1 64,6 63,1 64,5 45,2
28
Prototipado rpido 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 Automacin y Robtica Universidad Tecnolgica Nacional Facultad Regional Crdoba
Abstract Se presenta la metodologa de implementacin de prototipos funcionales incorporables a sistemas embebidos basados en tecnologa FPGA. Se describen las herramientas de alto nivel utilizadas y se desarrolla, paso a paso, un mdulo 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 rpido, Filtros FIR, XPS, EDK, SDK.
I.
INTRODUCCIN
Uno de los proyectos desarrollados en el CUDAR de la Universidad Tecnolgica Nacional Facultad Regional Crdoba es la Compresin de Video con Wavelet en Lgica 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 perifricos son incorporados como IP utilizando como soporte de desarrollo el sistema XPS de la empresa XILINX. Para la compresin de video es necesaria la implementacin de varias operaciones y algoritmos matemticos, mucho de los cuales son implementados directamente como hardware. Durante el proceso de desarrollo se investigaron y probaron distintos mtodos disponibles para prototipado rpido de funciones. El mtodo descripto en el presente trabajo hace uso de uno de los programas ms difundidos en el rea matemtica: MatLab perteneciente a la empresa MathWorks y su mdulo asociado Simulink, que es una plataforma verstil de diseo y simulacin de sistemas dinmicos, lo que permiti que integrantes del proyecto con poca experiencia en la metodologa de desarrollo en lgica programable, pudiesen probar ideas y realizar simulaciones que con poco esfuerzo pueden ser llevadas al hardware. Con el importante crecimiento que est mostrando la tecnologa de las FPGAs, las cuales incluyen con mas frecuencia procesadores embebidos en silicio, la posibilidad de portar todos los conocimientos matemticos a hardware programable de manera simple disminuye de forma importante el nmero de horas hombres y tiempo de depuracin, 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 adquisicin de las distintas herramientas utilizadas son amortizados rpidamente con los frutos de su aplicacin.
Las empresas fabricantes de FPGA han invertido mucho esfuerzo en el desarrollo de herramientas de alto nivel que faciliten la implementacin 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 abstraccin de hardware, con el objetivo de poder llevar a cabo un diseo en bloques funcionales y as obtener una concepcin de alto nivel que pueda ser simulada utilizando recursos ya disponibles en SimuLink. El System Generator puede ser tambin utilizado como herramienta de integracin, ya que es posible definir nuevos bloques con cdigos 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 estn pensadas para acortar el tiempo de desarrollo. El EDK permite disear sistemas mediante grficos, 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 fsico. Los cdigos de MatLab auxiliares sern reemplazados por cdigo 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 anlisis, examinan a la seal de inters para obtener determinadas caractersticas de espacio tamao y direccin. La familia est definida por:
29
a ,b
x b a a
a, b
La familia Wavelet se genera desde una funcin 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 concentracin en informacin de tiempo y frecuencia [1]. Las transformadas Wavelet se clasifican en Transformadas Wavelet Discretas (DWT) y Transformadas Wavelet Continuas (CWT) [2].
Figura 2. Descomposicin Simple
A.
Tipos de Wavelets
Segun la aplicacin se selecciona la Wavelet madre de la cual se derivan las familias de seales por dilatacin, contraccin y desplazamiento temporal.
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 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 metodologa de bancos de filtros, pasa bajos y pasa altos seguido de etapas de down sampling que generan la descomposicin, como se aprecia en la Figura 2. De la misma forma la recontruccin es realizada por bancos de filtros y up sampling de la seal. El decimado (Down Sampling) y undecimado (Up Sampling) indican decremento o incremento, respectivamente, de nmeros de muestras, lo cual se logra eliminando una muestra o intercalando un cero entre ellas [3].
La energa normalizada de una sub-imagen formada por N coeficientes de Wavelet se define como:
Eni
1 N
j ,k
[Dni (b j ,bk )]
La caracterstica de energa Wavelet {Eni} n=1...d, i= H, V, D refleja la distribucin de energa a lo largo del eje de frecuencia sobre una escala y en una orientacin determinada. La energa de las imgenes 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].
30
En compresin y en algunas otras aplicaciones de la transformada se hace necesario aplicar una tcnica multinivel. Esta se obtiene aplicando sucesivamente las transformadas a la parte de aproximacin de la etapa anterior como puede verse en la Figura 4.
Se destaca que el parmetro M-1 es el orden del polinomio y orden del filtro, mientras que la cantidad de coeficientes del filtro es M. 2) Caractersticas. Los filtros FIR a implementar son los que permiten realizar la transformada Wavelet por el mtodo de bancos de filtros. Estos coeficientes se obtienen desde la ventana de comando de MatLab con la siguiente expresin: [LO_D,HI_D,LO_R,HI_R]= WFILTERS('db3') 'db3' le indica a la funcin 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 continuacin se realiza el esquemtico de la Figura 6 en entorno SimuLink, utilizando bloques propios de SimuLink y System Generator.
Figura 4. 3 Niveles de Wavelet en 2-D
III. IMPLEMENTACIN Para la implementacin 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 mdulo independiente y la unin entre ambos se realiza con un cdigo de MatLab que posteriormente ser reemplazado en la FPGA por rutinas de manipulacin de datos ejecutadas en los procesadores embebidos. A continuacin se describe el mtodo empleado y los resultados obtenidos.
Figura 6. Primera Descomposicin Simple
A. 1)
Implementacin del prototipado rpido Filtro FIR Filtro FIR en su forma directa Se toma como entrada la componente de Crominancia roja (Cr) de una imagen de 100 x 100 pxeles. Luego de la decimacin de la primera descomposicin simple, los filtros arrojan N+2 coeficientes con valor numrico, donde N es el nmero que se espera luego de una decimacin. Estos dos valores podran ser interpretados como extras, producto de:
N
Figura 5. Estructura filtro FIR.
Datos de entrada 2
Orden del filtro 2 Truncacin parte entera
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.
Ejemplo: Cantidad de datos a la entrada= 10000
31
Orden del filtro = 5
De esta forma se obtienen los datos para formar la matriz rectangular necesaria para los siguientes pasos.
10000 2
5 2 Truncacin parte entera
5002
Este mtodo se utiliz tanto en la etapa de descomposicin como en la de reconstruccin.
Cantidad de coeficientes a la salida = 5002.
3)
Propuesta de implementacin
El presente trabajo propone implementar rpidamente en hardware un prototipo funcional del sistema que permita hacer una evaluacin conceptual y funcional del diseo, sin atacar an el problema de optimizacin del mismo. Para realizar los distintos barridos necesarios de la matriz de datos, se utiliza programacin directa en MatLab, y se aplica la seal a SimuLink directamente en forma de vector, lo cual hace transparente el recorrido de la matriz para este ltimo. MatLab esta diseado para trabajar con matrices, por lo que las operaciones con este tipo de arreglo de datos son extremadamente simples de realizar, la mayora 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 funcin pero aplicada a la matriz original o a su transpuesta. Para poder hacer uso de este mtodo es necesario que la matriz sea cuadrada y adems debe respetar la apariencia de la imagen original. Como mtodo de prueba se trabaj sobre la siguiente proposicin: a la salida de la primera descomposicin 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 nmero de datos con una matriz rectangular necesaria para la siguiente etapa, lo que dio como resultado una alteracin de la imagen reconstruida ya que los ceros quedaban embebidos en el anlisis. b) se opt por truncar el nmero de datos, considerando vlidos 5000 datos. Durante los ensayos se determin que no se puede descartar cualquier dato, ya que esto repercute en los resultados de la posterior reconstruccin. Para cada descomposicin simple, se opt por tomar como validos los N primeros datos, eliminando M datos de la descomposicin, el valor de M se obtiene truncando la parte entera de la siguiente relacin:
Figura 7. Recomposicin Simple
Se debe tener en cuenta que para una reconstruccin correcta, utilizando el presente mtodo, se debe aplicar el recorte de datos de manera invertida. Es decir si en la etapa de descomposicin se utilizaron los primeros N datos, en las etapas de reconstruccin se deben utilizar los ltimos N datos.
N ' ( Datos de entrada) 2

Dejando de tener en cuenta una cantidad M de coeficientes de salida. 4) Distorsin en los bordes de una imagen.
La teora de banco de filtros utilizada para la implementacin de la transformada Wavelet, est planteada y funciona adecuadamente para seales infinitas, pero se producen distorsiones en los lmites de las seales finitas, como es en el caso de una imagen [5]. Se han propuesto varios mtodos para solucionar este problema. Todos ellos proponen extender la seal de alguna manera. La bibliografa consultada propone entre otros el mtodo de convolucin circular y la reflexin simtrica, que se obtienen mediante la reflexin y la repeticin simtrica de las muestras en la frontera. MatLab tambin plantea la posibilidad de relleno con ceros. Estas ampliaciones no son arbitrarias y dependen exclusivamente del orden del filtro. Pese a la extensin, la salida contina generando distorsin en los bordes, sin embargo es bastante fcil ver la reflexin simtrica tambin a la salida de los filtros. Eliminando dicha distorsin simtrica, se obtiene la salida recuperada perfecta, que puede ser verificada con MatLab a travs de: [Ap De]= dwt (entrada, db3);
Orden del filtro 2 Truncacin parte entera
La cantidad N de datos tiles se calcula con la siguiente frmula:
Datos de Entrada 2
32
Donde entrada es un vector de valores finitos, db3 corresponde al tipo de onda utilizado para el clculo de coeficientes y las salidas son Ap y De corresponden a la Aproximacin y Detalle respectivamente.
EDK. Una vez generado el Hardware se utilizar el SDK para generar y depurar el software. Del trabajo realizado con System Generator resulta un mdulo 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 grficamente la plataforma base, Micro, bus, controladores de memorias, perifricos de IO genricos 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 generacin de la interfaz funcional para propiedad intelectual (IPIF). La existencia de los dos registros accesibles por software que sern los mismos que necesita el mdulo 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 incorporacin, mediante la sntesis 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 .
5)
Resultado de la implementacin propuesta
Al comparar la imagen reconstruida con la imagen original utilizando el mtodo implementado, se hallaron errores en el margen superior izquierdo de la imagen, de manera ms especfica en una submatriz de n x n donde n es la cantidad de coeficientes del filtro implementado para Daubechies 3. Como solucin a este problema se agregaron marcos a la imagen original. En esta experiencia para prototipado rpido se utiliz un marco cuyo valor numrico era el uno, esto permiti apreciar el comienzo de la imagen al finalizar el marco, y pese a que no se emple ninguna extensin de frontera se logr una reconstruccin perfecta. Esto se debe a que los errores de los procesos de truncacin de informacin para la formacin de matrices auxiliares de recorrido, descriptos anteriormente, se sitan dentro del permetro del marco, figura 8, que posteriormente es eliminado.
Figura 8. Marcos agregados a la imagen original.
El Centro Universitario de Desarrollo en Automacin y Robtica (CUDAR) actualmente est incorporando estos mtodos a las etapas de transformacin para la compresin de video.
Figura 9. Esquema del mdulo encapsulado en el IPIF.
B. Incorporacin del mdulo Wavelet a un sistema embebido en FPGA con XPS La etapa final del desarrollo es la incorporacin del mdulo 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 ms fcil e intuitiva de implementar sistemas embebidos en esta plataforma es con el XPS utilizando el
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.
33
IV. CONCLUSIN Y FUTUROS TRABAJOS Las pruebas realizadas con la metodologa utilizada demostr ser efectiva para la implementacin de mdulos IP, la interaccin 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 implementacin de hiptesis de manera rpida para validacin o refutacin, acortando los tiempos de investigacin y desarrollo. La evolucin de las herramientas de desarrollo de sistemas embebidos en plataformas FPGA muestran un crecimiento importante y sostenido de este campo en este tipo de tecnologas. En el CUDAR se continuar con la exploracin de este tipo de alternativas en todos los proyectos que involucren algoritmos matemticos. REFERENCIAS
[1] [2] [3] Jalali, Payman. Wavelets and aplication. Energy Tecnology Department. Lappeenranta University of Tecnology. Kobayashi, Mei. Wavelets Analisys: Application in Industry Tokyo Research Laboratory. Burrus, Sidney; Gopinath, Ramesh; Guo Haitao. Introduction to Wavelets and Wavelets Transforms. Electrical and computer engenieering departament. Rice University. Houston, Texas. Borja Jos Garca Menndez; Eva Mancilla Ambrona; Ruth Montes Fraile. Optimizacion de la transformada Wavelet Discreta Universidad complutense de Madrid Facultad de informtica 2004 2005. Strang ,Gilbert; Nguyen, Truong. Wavelets and Filter Banks . Perez, Alejandro; Gutierrez, Francisco, Rodolfo Cavallero, Nicolas Ravotti Desarr ollo de sistemas embebidos en FPGAs. Diseo e incorporacin de perifricos.
[4]
[5] [6]
34
35
36
Implementaci on en FPGA de decodicadores LDPC de baja complejidad

L. Arnone C. Gayoso
Facultad de Ingenier a Universidad Nacional de Mar del Plata Email: leoarn@.mdp.edu.ar
C. Gonz alez
M. Rabini
J. Casti neira Moreira
AbstractLos c odigos con matriz de paridad de baja densidad LDPC son considerados ampliamente como uno de los c odigos correctores de errores a ser usados en sistemas de comunicaciones de la pr oxima generaci on. En este trabajo se presenta la implementaci on de dos decodicadores LDPC en FPGA, que permiten trabajar con cualquier tipo de matriz paridad (incluidas las generadas aleatoriamente, las generadas con una determinada regla de construcci on, como las quasi-c clicas, sean de tipo sistem atico, o no sistem atico), y se adapta en forma param etrica cualquiera sea la tasa del c odigo k/n. Ambas implementaciones son de baja complejidad, debido a que s olo utilizan operaciones de suma-resta y busqueda en tablas. El segundo decodicador implementado tiene la ventaja que a ruido de no requiere el conocimiento de la proporci on de senal recibida del canal. la senal
II. D ECODIFICADOR LDPC En los c odigos LDPC [1] existe una matriz de paridad H, la cual cumple con la condici on H r = 0 para todo vector r del c odigo. La esencia del algoritmo de decodicaci on [1] es encontrar el vector r, (el cual es una estimaci on del vector r ), que cumpla con la condici on: H r=0 (1)
I. I NTRODUCCI ON Los c odigos de paridad de baja densidad (LDPC) est an recibiendo mucha atenci on debido a su funcionamiento cercano al l mite de Shannon [1]. Un m etodo que permite decodicar r apidamente c odigos 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 m etrica la distancia Euclidiana m nima cuadrada, tiene la ventaja de no requerir el conocimiento de la proporci on de se nal a ruido de la se nal recibida. El desempe no de este algoritmo es similar al del algoritmo de suma-producto. Los cocientes y productos involucrados en estos algoritmos hacen que sean dif cil su implementaci on en forma sencilla en l ogica programable. En este trabajo se muestra como es posible implementar ambos decodicadores LDPC (suma-producto y distanciasuave) en FPGA [5] utilizando s olo operaciones de suma-resta y tablas de b usqueda. Estos decodicador pueden trabajar con cualquier tama no y tipo de matriz de paridad H (incluidas las generadas aleatoriamente, las generadas con una determinada regla de construcci on, como las quasi-c clicas [6],[7], sean de tipo sistem atico, o no sistem atico) y su arquitectura puede ser f acilmente congurada para diferentes tasas de c odigo. Los resultados obtenidos muestran que no hay una gran diferencia en el desempe no de decodicaci on al utilizar los decodicadores propuestos con respecto a decodicar usando los algoritmos de suma-productos (SP) y distancia-suave (DS). Esto permite, implementar decodicadores en l ogica programable de muy baja complejidad con muy buen desempe no.
En este algoritmo se produce un intercambio de informaci on [2] entre cada nodo s mbolo (representativo de los s mbolos del vector r), y los nodos de paridad, (representativos de las ecuaciones de paridad que se vinculan con los s mbolos de r). Este proceso de intercambio de informaci on entre nodos es iterativo. El proceso se detiene si se cumple la condici on dada por (1), con lo cual se obtiene un mensaje v alido, o bien, si el n umero de iteraciones establecido es alcanzado sin que se cumpla la condici on anterior, se habr a producido un error. DE SUMA - RESTA III. A LGORITMO DE DECODIFICACI ON El algoritmo de suma-resta, es descripto en [8] y est a basado en el algoritmo de decodicaci on de suma- producto introducido por D. J. C. MacKay y R. M. Neal [1]. A continuaci on se detalla brevemente su funcionamiento. Si yj es el s mbolo obtenido a la salida del canal en el simo tiempo j , la probabilidad a priori Fjx de que el j e s mbolo sea x, con x = {0, 1} est a dada por: Fj1 = efj =
0 1
1 2 1 + e2yj /
(2) (3)
Fj0 = efj = 1 Fj1

1 0 se pueden hallar |fj | y |fj | como: 1 |fj | = 0 |fj | =
ln 1 + e2yj /
= f+ (2yj / 2 , 0) (4)
2yj / 2 + f+ (2yj / 2 , 0)
donde f+ (a, b) es una tabla de b usqueda con entrada |a b| [9], [10]. La Tabla I resume los pasos del algoritmo utilizado. Dada una matriz de paridad H, se denomina N (i) al conjunto de columnas que tienen elementos no nulos para la la i, y M (j ) al conjunto de las con elementos no nulos para la columna j . Igualmente f (a, b) es una tabla de b usqueda con entrada |a b| (Ver apendice A).
37

TABLA I R ESUMEN DEL ALGORITMO SR Inicializaci on
0 qij 0 = fj 1 = f1 qij j
ROM_num_unos_fil
ROM_H
ROM_ftabla+
ROM_ftabla-
y(j) Salida del canal
CONTROL
r(j) Salida estimada
Paso horizontal 1
0 , q 1 ) + f (q 0 , q 1 ) qij = ma x(qij ij ij ij 0 q 1 sino s = 0 sij = 0 si qij ij ij
RAM_f0
RAM_f1
RAM_q0
RAM_q1
Paso horizontal 2 rij = srij =

N (i) N (i)
qij qij sij sij
Fig. 1. Arquitectura del decodicador SR implementado en FPGA de ALTERA [5]
Paso horizontal 3 si srij es par 0 = lg(2) f (r , 0) rij + ij

1 = lg(2) + f (r , 0) rij ij
si srij es impar 0 = lg(2) + f (r , 0) rij ij

1 = lg(2) f (r , 0) rij + ij
Paso vertical
x cx ij = fj + 0 qij M (j ) x rx rij ij
RAM f 1 almacenan a f0 y f1 cada vez que ingresa una nueva palabra al decodicador. Su tama no depende de la longitud de palabra utilizada. Las memorias RAM q0 y RAM q1 , poseen igual cantidad de palabras que la memoria ROM H, pero son de 16 bits. Las RAM q0 y RAM q1 realizan varias funciones: En la inicializa0 1 ci on almacenan los valores de qij y qij . En el paso horizontal 1, RAM q0 guarda los valores de qij y RAM q1 guarda los valores de sij . En el paso horizontal 2 se almacenan los valores de rij y srij . En el paso horizontal 3 se almacenan los 1 0 . Finalmente en el paso vertical se vuelven y rij valores de rij 0 1 a almacenar los valores de qij y qij . Esto le da un alto grado de reutilizaci on a estas memorias. DE DISTANCIA V. A LGORITMO DE DECODIFICACI ON SUAVE SIMPLIFICADO (DSS) En el algoritmo de decodicaci on cl asico de suma-producto, si yj es el s mbolo obtenido a la salida del canal en el tiempo j , suponiendo que la informaci on es transmitida con formato polar normalizado con amplitud 1; la probabilidad a priori simo s Fjx de que el j e mbolo sea x, con x = {0, 1} est a dada por (2) y (3). En el algoritmo de decodicaci on de distancia suave (DS) el c alculo de probabilidades [3][4] es reemplazado por el c alculo de la distancia Euclidiana cuadrada: d2 1 (j ) = d2 0 (j ) = (yj 1)2 (yj + 1)2 (5)
c0 ij
1 ma x(c0 ij , cij )
1 f (c0 ij , cij )
1 = c1 ma 1 0 1 qij x(c0 ij ij , cij ) + f (cij , cij )
Estimaci on del s mbolo decodicado r (j )

x cx j = fj 0 r j = 0 si cj M (j ) c1 j sino x rij
r j =1
IV. A RQUITECTURA DEL DECODIFICADOR DE SUMA - RESTA (SR) En la Fig. 1 se observa el decodicador implementado. La memoria ROM H s olo almacena la ubicaci on de cada uno en la matriz H, su tama no depende del n umero de columnas con unos en cada la y del n umero de las que posee. Por ejemplo, para una matriz H1 generada aleatoriamente, de 60 30, el tama no de ROM H es de 256 palabras de 6 bits, y para una matriz H2 generada aleatoriamente, de 1008 504, es de 4096 palabras de 10 bits. La ROM num unos l almacena el n umero de columnas con unos que tiene cada la. Esta memoria se utiliza para poder indexar y poder as recuperar on de cada uno en la matriz junto con la ROM H, la posici H. Las memorias ROM ftabla+ y ROM ftabla- contienen las tablas de b usquedas f+ (a, b) y f (a, b). Ambas tablas son de 256 palabras de 16 bits, tanto para H1 y H2 . Las RAM f 0 y
De forma similar a lo propuesto en [8], en este caso tambi en se realiza un desarrollo logar tmico [11] para obtener el algoritmo de decodicaci on de distancia suave simplicado (DSS). La Tabla II resume el algoritmo DSS. Como se puede observar s olo se realizan comparaciones, sumas, restas y b usquedas en tablas. VI. A RQUITECTURA DEL DECODIFICADOR DSS En la Fig.2 se observa el decodicador implementado. La memoria ROM H s olo almacena la ubicaci on de cada uno en la matriz H, su tama no depende del n umero de columnas con unos en cada la y del n umero de las que posee. Por ejemplo, para una matriz H1 generada aleatoriamente, de 60 30, el tama no de ROM H es de 256 palabras de 6 bits, y para
38

TABLA II R ESUMEN DEL ALGORITMO DSS Inicializaci on
0 qij
ROM_num_unos_fil
ROM_H
ROM_ftabla+
ROM_ftabla-
d0 j (j )
1 = d1 (j ) qij j
y(j) Salida del canal
CONTROL
r(j) Salida estimada
Paso horizontal 1
0 , q1 ) qij = +f+ (qij ij 0 , q1 ) qij = f (qij ij 0 q 1 sino s = 1 sij = 0 si qij ij ij
RAM_d20
RAM_d21
RAM_q0
RAM_q1
RAM_signo
Paso horizontal 2 rij = rij =

N (i) N (i) N (i)
Fig. 2. Arquitectura del decodicador DSS implementado en FPGA de ALTERA [5]
qij qij qij qij sij sij
srij =
Paso horizontal 3 si srij es par 0 = f (r , r ) rij + ij ij

1 = +f (r , r ) rij ij ij
2 ci on almacenan los valores de d2 0 y d1 . En el paso horizontal 1, RAM q0 guarda los valores de qij y RAM q1 guarda los valores de qij . En el paso horizontal 2 se almacenan los valores de rij y rij . En el paso horizontal 3 se almacenan 0 1 los valores de rij y rij . Finalmente en el paso vertical se vuelven a almacenar los 0 1 valores de qij y qij , esto le da un alto grado de reutilizaci on a estas memorias. La RAM signo almacena sij en el paso horizontal 1 y srij en el paso horizontal 2.
si srij es impar 0 = +f (r , r ) rij ij ij

1 = f (r , r ) rij + ij ij
VII. C OMPLEJIDAD El an alisis del n umero de operaciones involucradas en los algoritmos presentados permite tener una idea del costo en t erminos de hardware que supone su implementaci on. Dada una matriz H, con N columnas y M las, se dene a t = M (j )prom como el n umero promedio de unos por columna, y v = N (i)prom al n umero promedio de unos por la. T picamente se tiene: v = N t/M (6) Para un c odigo LDPC de velocidad 1/2, M = N/2, entonces: v =2t (7) A continuaci on se se eval ua el grado de complejidad para los algoritmos tratados (utilizando t = 3 y v = 6) SP (Mackay and Neal) productos: 2(v + 2t 6)N t = 36N sumas y restas: 5N t = 15N cocientes: 2N t = 6N SR sumas y restas (paso horizontal): (3 + 2(v 2))N t = 33N comparaciones (paso horizontal): 3N t = 9N b usquedas en tablas (paso horizontal): 3N t = 9N sumas y restas (paso vertical): (11 + (t 2) + t)N t = 45N comparaciones (paso vertical): 5N t = 15N b usquedas en tablas (paso vertical): 4N t = 12N DSS sumas y restas (paso horizontal): (6 + 3(v 2))N t = 54N comparaciones (paso horizontal): 6N t = 18N b usquedas en tablas (paso horizontal): 4N t = 12N
Paso vertical
0 = d2 (j ) + qij 0 1 = d2 (j ) + qij 1 M (j ) 0 r0 rij ij 1 r1 rij ij
M (j )
Estimaci on del s mbolo decodicado r (j )

2 (j ) = q 0 + r 0 r0 ij ij 2 (j ) = q 1 + r 1 r1 ij ij 2 2 r j = 1 si r1 (j ) < r0 (j ) sino r j =0
una matriz H2 generada aleatoriamente, de 1008 504, es de 4096 palabras de 10 bits. La ROM num unos l almacena el n umero de columnas con unos que tiene cada la. Esta memoria se utiliza para poder indexar y poder as recuperar on de cada uno en la matriz junto con la ROM H, la posici H. Las memorias ROM ftabla+ y ROM ftabla- contienen las tablas de b usquedas f+ (a, b) y f (a, b). Ambas tablas son de 256 palabras 16 bits tanto para H1 y H2 . 2 Las RAM d20 y RAM d21 almacenan a d2 0 y d1 cada vez que ingresa una nueva palabra al decodicador. Su tama no depende de la longitud de palabra utilizada. Las memorias RAM q0 y RAM q1 , poseen igual cantidad de palabras que la memoria ROM H, pero son de 16 bits. Las RAM q0 y RAM q1 realizan varias funciones: En la inicializa-
39

TABLA III DEL A N ALISIS DE LA COMPLEJIDAD DE LA IMPLEMENTACI ON USANDO t = 3. ALGORITMO DE DECODIFICACI ON operaciones productos cocientes sumas y restas comparaciones b usquedas en tabla SP (Mackay-Neal) 36N 6N 15N SR [8] 78N 24N 21N DSS 72N 21N 12N TABLA V DE UN R ESULTADOS OBTENIDOS EN LA IMPLEMENTACI ON (1008 504) DECODIFICADOR SR Y DSS DE TAMA NO Hardware utilizado Dispositivo Familia Elementos l ogicos Registros Bits de memoria Frecuencia del reloj SR EP2C35F672C6 Cyclone II 1109 435 210944 94, 43M Hz DSS EP2C35F672C6 Cyclone II 951 428 219136 118, 11M Hz
TABLA IV DE UN R ESULTADOS OBTENIDOS EN LA IMPLEMENTACI ON (60 30) DECODIFICADOR SR Y DSS DE TAMA NO Hardware utilizado Dispositivo Familia Elementos l ogicos Registros Bits de memoria Frecuencia del reloj SR EP2C35F672C6 Cyclone II 1036 394 15968 101, 67M Hz DSS EP2C35F672C6 Cyclone II 882 387
10 Probabilidad binaria de error
20320 112, 38M Hz
10
10
sumas y restas (paso vertical): (2(t 2) + 4)N t = 18N comparaciones (paso vertical): N t = 3N En la Tabla III, se resume el grado de complejidad de los algoritmos tratados. Como se puede observar, el algoritmo DSS posee menos operaciones que el SR [8]. Si bien los algoritmos DSS y SR requieren m as operaciones de sumas y restas que el algoritmo de decodicaci on tradicional de Mackay-Neal, la complejidad del DSS y SR se ven notablemente reducidas por el hecho que no utilizar productos ni cocientes. VIII. R ESULTADOS OBTENIDOS Ambos decodicadores LDPC (60 30) y LDPC (1008 504) se implementaron usando lenguaje VHDL [12] y la herramientas de s ntesis del programa QUARTUS II [13] de ALTERA. En la Tabla IV se pueden ver los resultados obtenidos en la implementaci on del decodicador LDPC (60 30) y en la Tabla V los resultados para el decodicador (1008 504). En ambos casos se observa que el decodicador DSS es m as veloz que el SR, y utiliza menos elementos l ogicos y registros. En la Fig. 3 se muestra los resultados obtenidos haciendo una simulaci on del c odigo LDPC (60 30) en una transmisi on de 10000 bloques de 30 bits de mensajes, y en la Fig. 4 los resultados del c odigo LDPC (1008 504) en una transmisi on de 10000 bloques de 504 bits de mensajes. En ambos decodicadores se utilizaron 16 iteraciones y factores de correcci on tabulados en tablas de 256 elementos.
10
Sin codificar DS ideal SP MackayNeal SR tabla de 256 entradas DSS tabla de 256 entradas 0 1 2 Eb/No [dB] 3 4 5
Fig. 3. Desempe no de un decodicador LDPC 60 30 para diferentes algoritmos de decodicaci on
En la Fig. 3 el BER (Bit Error Rate) es cero para ambos decodicadores (SR y DSS) cuando Eb /N0 5dB ( = 0.56) y en la Fig. 4 el BER es cero cuando Eb /N0 3dB ( = 0.7). Se puede apreciar que el desempe no al usar tablas de 256 entradas no muestra diferencias apreciables con respecto al uso de la funci on ideal (SP Mackay-Neal y DS). Por tanto se ve que es posible implementar decodicadores de baja complejidad sin tener una p erdida apreciable en la tasa de error, usando tablas de b usqueda de tama no razonable. IX. C ONCLUSIONES Se han dise nado e implementado en FPGA dos decodicadores LDPC. Ambos pueden trabajar con cualquier tama no y tipo de matriz de paridad H (incluidas las generadas aleatoriamente, las generadas con una determinada regla de construcci on, como las quasi-c clicas, sean de tipo sistem atico, o no sistem atico), y se adaptan en forma param etrica cualquiera sea la tasa del c odigo k/n. El decodicador DSS presenta la ventaja de no requerir informaci on del nivel del ruido del
40
10
El c alculo de los logaritmos involucrados en (8) y (9) pueden ser evitados usando tablas de b usqueda f+ (a, b) y f (a, b) con entradas |a b|. R EFERENCIAS
[1] D.J.C. MacKay and R.M. Neal, Near Shannon limit performance of low density parity check codes, Electronics Letters, vol. 33, pp 457-458 (1997). [2] R.G. Gallager, Low Density Parity Check Codes, IRE Trans. Information Theory, IT-8, 21-28 (1962). [3] P. G. Farrell,Decoding Error-Control Codes with Soft Distance as the Metric, in Proc. Workshop on Mathematical Techniques in Coding Theory, Edinburgh, UK, (2008). [4] P. G. Farrell and J. Casti neira Moreira, Soft-Input Soft-Output Euclidean Distance Metric Iterative Decoder for LDPC Codes, in Proc. Argentine Symposium 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 Efcient FPGA Implementation of Quasi-Cyclic LDPC Decoder, Proc. 5th WSEAS Int. Conf. on Instrumentation, Measurement, Circuits and Systems,, vol 1, pp 218-223 (2006). [7] M.K. Ku, H.S. Li and Y.H.. Chien, Code Design And Decoder Implementation of Low Density Parity Check Code, Emerging Information Technology Conference, (2005). [8] L. Arnone, C. Gayoso, C. Gonz alez and J. Casti neira, Sum-Subtract Fixed Point LDPC Decoder, Latin American Applied Research, vol 37, pp 17-20 (2007). [9] J.P. Woodard and L. Hanzo, Comparative Study of Turbo Decoding Techniques, IEEE Transaction on Vehicular Technology, vol. 49, (2000). [10] T. Bhatt, K. Narayanan and N. Kehtarnavaz, Fixed point DSP implementation of Low-Density Parity Check Codes, Proc IEEE DSP2000,(2000). [11] P. G. Farrell L. Arnone and J. Casti neira Moreira, FPGA implementation of a Euclidean distance metric SISO Decoder, Proceedings of the Tenth International Symposium in Communications Theory and Applications. ISCTA 09, vol 1, pp 1-5 (2009). [12] L. Ter es, Y. Torroja, S. Olcoz, E. Villar VHDL. Lenguaje Est andar de Dise no Electr onico, McGraw Hill/Interamericana de Espa na, Madrid (1997). [13] www.altera.com, Quartus II Software, Available: On Line.
Probabilidad binaria de error
10
10
10
Sin codificar DS ideal SP MackayNeal SR tabla de 256 entradas DSS tabla de 256 entradas 1 1.5 2 Eb/No [dB] 2.5 3
Fig. 4. Desempe no de un decodicador LDPC 1008 504 para diferentes algoritmos de decodicaci on
canal. Ambas implementaciones muestran una gran versatilidad de aplicaci on y no presentan diferencias apreciables en el desempe no de tasa de error con respecto al uso del decodicador de suma-producto ideal introducido por D. J. C. MacKay y R. M. Neal. NDICE A APE LGEBRA LOGAR A I TMICA c a En caso de tener C = e , A = e y B = eb , para C = A+B se tiene: c = ma x(a, b) + ln(1 + e|ab| ) (8) C = (1)z ec = (1)z |C | con |C | = Para C = A B o |A B | y z = 0 si A > B sino z = 1, entonces: c = = ma x(a, b) + ln(1 e|ab| ) ma x(a, b) | ln(1 e|ab| )| (9)
41
Generador de Nmeros Pseudoaleatorios Mediante el Sistema Numrico de Residuos, Implementacin en FPGA

Carlos Arturo Gayoso, Claudio Marcelo Gonzlez, Leonardo Arnone y Miguel Rabini
Laboratorio de Componentes Electrnicos, Departamento de Electrnica Universidad Nacional de Mar del Plata Mar del Plata, Repblica Argentina cgayoso@fi.mdp.edu.ar
Resumen Este trabajo estudia la implementacin en hardware de generadores de nmeros pseudo aleatorios (Pseudo Random Number Generators, PRNGs o Generadores de Nmeros Pseudoaleatorios, GNPA), en lgica programable (Field Programmable Gate Arrays o FPGA). Se investiga el empleo del sistema numrico de residuos (Residue Number System o RNS) para incrementar la velocidad a la que los generadores producen los nmeros aleatorios y para que posea una dinmica distinta a los generadores conocidos. El circuito propuesto se evalu desde el punto de vista estadstico mediante tests bsicos 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 definicin de sistemas determinsticos y aleatorios junto con la presentacin del test die hard y su empleo. Se describe el generador de nmeros pseudo aleatorios propuesto junto la explicacin de cada uno de los bloques que lo constituyen. Se finaliza presentando los aportes y conclusiones del trabajo realizado. Palabras clave; Sistema Numrico de Residuos; Aritmtica de residuos; Nmeros pseudoaleatorios; Lgica Programable.
I.
INTRODUCCIN
A. Determinismo y aleatoriedad Los sistemas, desde el punto de vista de su comportamiento, se puede clasificar como deterministas, aleatorios o caticos. En los sistemas deterministas se puede precisar cualquiera de sus futuros estados conociendo su estado presente, no hay participacin 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 evolucin del mismo, ni siquiera su prximo estado, conociendo con una precisin ilimitada su salida actual y las anteriores, no se puede encontrar ningn tipo de patrn o regularidad. Existen diversos circuitos o algoritmos que tienen la particularidad de generar secuencias de nmeros aleatorios. En este caso, a diferencia de procesos naturales, las series generadas tienen un perodo, que si bien puede ser muy grande, es finito. Por esta razn a estos sistemas se los denomina pseudoaleatorios.
B. Tests de aleatoriedad Los test de aleatoriedad se emplean para analizar una secuencia de nmeros, provenientes de una fuente natural o artificial, para determinar si se trata de un proceso estocstico [1], [2]. Un estudio preliminar de la secuencia de datos, por ejemplo uniformidad, o autocorrelacin, puede poner en evidencia un patrn de comportamiento fcilmente predecible que descarte un comportamiento aleatorio. Sin embargo, en otros casos, con las herramientas estadsticas 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 numrica bajo estudio en busca de concluir sobre su carcter deterministico o aleatorio. Entre los test ms utilizados para medir la calidad de una secuencia de nmeros 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 ms dficiles de superar. El paquete die hard tiene como entrada un archivo de al menos 11 Mbytes con la secuencia de nmeros 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 Numrico de Residuos Los circuitos aritmticos, por ejemplo sumadores, basados en la notacin de complemento a 2, deben propagar la informacin de acarreo desde el bit menos significativo al ms significativo, de manera que a medida que el nmero de stos aumenta el rendimiento se degrada. El RNS [5], [6], [7] es una tcnica eficiente para superar este problema, dado que se trabaja sobre canales independientes sin necesidad de intercambio de informacin entre ellos. De esta manera los sistemas basados en el RNS estn compuestos de una serie de canales pero, cada uno de ellos, con un nmero reducido de bits. Los circuitos aritmticos de n bits se pueden transformar,
42
mediante el empleo del RNS, en O(n/log2(n)) canales de log2(n) bits cada uno [8], Fig. 1. Esta caracterstica lo hace apropiado para la realizacin de un nmero importante de aplicaciones en procesamiento digital de seales [9], [10], [11].
razn el circuito propuesto se ha implementado sobre una FPGA FLEX10K20RC240-4 [17] de Atera Corporation. II. GENERADOR PSEUDOALEATORIO PROPUESTO (RNSLCG)
El generador propuesto, denominado RNS-LCG (Residue Number System-Linear Congruential Generator) se basa en el Linear Congruential Generator (LCG). Sin embargo su dinmica es distinta. En efecto, no se trata de realizar un LCG mediante RNS sino en usar el RNS para obtrener un generador de nmeros pseudoaleatorios con una dinminca completamente distinta. Un LCG comn responde a la siguiente ecuacin:
xi = (a xi 1 + b ) md M
Figura 1. Esquema general de un circuito RNS.
(2)
Un sistema basado en RNS se define mediante un conjunto de enteros relativamente primos entre si {m1, m2..., mL}, llamados mdulos. Su rango dinmico, el nmero 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 aritmtica de residuos se define sobre un anillo de enteros mdulo M tal que:
Z = ( XY ) md M zi = (xi yi ) md mi
con a y b constantes y M el mdulo que determina el rango dinmico del sistema. La implementacin circuital para los generadores RNSLCG 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 pequeo generador lineal congruente que realiza el clculo de la Ec. 3. En esta gj y mj son la raz primitiva y el mdulo de trabajo de cada uno de los canales y residuoj, i es el residuo del canal j para la iteracin i.
residuo j , i = (g j residuo j , i 2 + b j , i )md m j
(3)
(i = 1,...,L) (1)
donde significa suma, resta o multiplicacin en mdulo. En la ecuacin (1) se puede apreciar el potencial del RNS, puesto que las operaciones en mdulo 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 mdulo mi. Aunque operaciones tales como divisin o comparacin son muy difciles de realizar, esto no limita la aplicacin del RNS, de hecho el procesamiento digital de seales se ha transformado en su campo de aplicacin preferido. De esta manera los algoritmos de multiplicacin y suma, muy comunes en DSP (procesamiento digital de seales), pueden incrementar su velocidad de funcionamiento mediante su implementacin en RNS, como se ha demostrado en aplicaciones tales como transformadas discretas, filtrado digital o procesamiento de imgenes [12], [13]. Por otro lado los fabricantes de dispositivos lgicos programables (Field Programmable Logic) proveen circuitos integrados programables en campo para casi todas las aplicaciones de la electrnica digital. Para la implementacin de circuitos aritmticos en el RNS los FPLs [14], [15] se han convertido en una seria alternativa al empleo de circuitos implementados con aritmtica convencional [16]. Por esta
Figura 2 Generadores RNS-LCG-I y RNS-LCG-II. Diagrama en bloques para un canal genrico j, arriba. Esquemtico total, abajo.
43
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 nmero de mdulos, para el canal j en la iteracin i se tiene:
b j,i =
k = n 1 k =0 k j
residuo
(4)
k , i 1
en tanto que para los Tipo II (RNS-LCG-II), siendo la operacin or exclusiva bit a bit, ser:
k = n 1
b j,i =
residuos
k =0 k j
k , i 1
(5)
Ahora bien, si se desea generar nmeros de t bits se presenta la siguiente dificultad. Para trabajar en el RNS se debe elegir un conjunto m de mdulos relativamente primos con lo que se obtiene un rango dinmico M igual al producto de los mdulos, 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. An cuando los nmeros ledos en decimal sean equiprobables, los 0s y 1s en cada posicin no lo sern. Este problema se ejemplifica en la TABLA I, para tener M = 11 se necesita t = 4. Como se puede observar se tiene:
b0 6 ceros y 5 unos b 6 ceros y 5 unos Para la posicin 1 b2 7 ceros y 4 unos b3 8 ceros y 3 unos
A. Estratega 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 slo aquellos valores que sean menores que 232 y descartar el resto. Por ejemplo, si el GNPA tiene distribucin uniforme entre 0 y M 1, la serie obtenida tendr distribucin uniforme entre 0 y 232 1. Trabajar de esta manera trae dos consecuencias, una intuitiva y otra prctica. La intuitiva dice que si existiera alguna estructura en la secuencia generada, al quitar algunos de sus elementos, en este caso un nmero importante, casi uno de cada dos, en la nueva serie esa estructura se desvanecer o atenuar. En el caso prctico se tiene el problema de que no se entregar, debido al descarte, un nmero en cada iteracin. 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 mnima, y puesto que el nmero de bits es 33 simplemente se descarta el ms significativo. En el caso ejemplificado en la TABLA I se obtendrn nmeros comprendidos entre 0 y 10 en la que al descartar el bit de mayor peso se reducir a una cadena de dgitos entre 0 y 7. Las consecuencias son las siguientes. Se mejora el throughput, puesto que en cada iteracin se obtiene un dato. Se empeora su funcin distribucin puesto que la combinacin 000 es ms probable que la 111, dado que la primera puede ocurrir si el nmero presentado por el generador fue 0000 o 1000 en tanto que la segunda de dar slo cuando su salida sea 0111. Cuanto menor sea la diferencia entre M y 2t menor ser la perturbacin en la funcin distribucin, supuesta uniforme. Como ventaja tiene la caracterstica de su sencillez, puesto que ni siquiera es necesario un comparador, en efecto, de las tres clases de circuitos desarrollados es el ms sencillo en su hardware. Para identificar los conjuntos de mdulos que mejor se adaptan a esta estrategia se realiz un estudio exhaustivo con mdulos 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 mdulos que superaran a 232 en no ms de un 0,01%. Es decir combinaciones de los 30 mdulos tomados de a 4, 5, 6, 7 y 8. Con 4 mdulos 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 funcin distribucin de probabilidad uniforme se ver alterada, habr nmeros ms probable que otros, pero sern
Los 0s y 1s no son equiprobables en cada posicin, algo indeseado en un buen GNPAs. Esto ocurre a pesar de que los nmeros del 0 al 10 tengan una distribucin uniforme perfecta. Para salvar esta situacin se implementaron tres estrategias, denominadas A, B y C.
TABLA I. Ejemplo para M = 11 y t = 4. 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 b3 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 b2 0 0 0 0 1 1 1 1 0 0 0 0 1 1 1 1 b1 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 b0 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
44
slo el 0,000171% del total. De manera que se puede afirmar que para la mayora de los fines prcticos los 0s y 1s sern prcticamente equiprobables en cada posicin y que la funcin densidad de probabilidad es uniforme.
TABLA II. Conjuntos de mdulos que ms se aproximan a 232 en exceso. Exceso de 232 en porcentaje 0,000171% 0,000329% 0,001602% 0,001765% 0,001930% 0,002493% 0,002979% 0,003663% 0,003954% 0,004044% 0,004114% 0,005759% 0,005835% 0,006079% 0,006208% 0,006232% 0,006623% 0,006680% 0,007078% 0,008061% 0,008383% 0,009021% 0,009294% 0,009370% 0,009494% 0,009509% m0 3 5 3 5 11 5 3 7 3 13 13 3 3 3 3 11 5 7 3 13 17 3 11 3 3 5 m1 43 11 7 11 23 11 11 31 7 17 19 7 7 5 17 17 37 17 7 23 19 19 23 5 7 13 m2 47 13 13 17 53 13 13 41 13 37 53 13 11 7 23 31 47 37 19 47 41 59 43 7 19 19 m3 67 17 37 23 59 19 23 37 61 59 19 13 53 31 79 67 89 31 53 47 67 13 29 23 m4 m5 m6 m7
97 109 53 47 29 61 61 67 53 67 29 73 41 59 113 83 109 71 89 71 73 73 89 97
43 103 109 71 113 83 31 43 37 67 43 79 109 71 107 109 97 109
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 seran siempre los mismos. La idea es que cuando el conversor RNS a binario entregue un nmero tal que a32 = 1 los bits a31 a0 sean reemplazados por alguna operacin entre stos y el valor de Registro e, que se almacen en algn momento en el pasado. Estadsticamente tanto ms alejados del valor actual cuanto mayor sea el nmero de bits tomados de Registro c para cargar al Registro e. La operacin entre Registro e y a31 a0 debe ser una relacin sencilla en la que, adems, para cada bit del resultado los 0s y 1s sean equiprobables. El elemento que cumple con esta condicin es la or exclusiva realizada bit a bit. Con este circuito de correccin se logran dos cosas. Primero, en cada iteracin se obtiene un nmero de la serie pseudoaleatoria. Segundo, no se altera la distribucin 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.
83 113 73 101 97 113 67 73 71 79 73
67 103 71 23 43 37 83 41 89 61 47 97 67 Figura 3 Esquema de correccin para los circuitos tipo C. 71
89 113 127
C. Estrategia C Este enfoque elimina las limitaciones que tienen las estrategias A y B. Puesto que entrega un nmero en cada iteracin y la distribucin es uniforme en toda su extensin. 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 nmeros que requieren para su representacin en binario 33 bits. Los nmeros entregados por el GNPA ingresan al bloque que se ilustra en Fig. 3, denominado circuito de correccin. Como se puede apreciar, si el bit ms significativo entregado por el conversor RNS a binario es cero (a32 = 0), el nmero entregado por el GNPA sigue sin cambios su camino hasta la salida, Registro d. El Registro e peridicamente actualiza su valor de la siguiente manera. Si un determinado nmero 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 estadsticamente su valor se modifica, en caso de tomar los
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 races 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 bsico A fin de poder comparar los generadores propuestos con otros ya testeados y conocidos se generaron series de 32 bits con:
45
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 combinacin de los generadores Subtract With Borrow y Multiply With Carry, del paquete Diehard
Se realizaron los tests bsicos de autocorrelacin, anlisis 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. Simulacin 0 1 2 3 4 5 6 7 8 9 RNS-LCG-I
p
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 tamao, puesto que en este caso se descartan aquellos valores superiores 232, el tamao de estos archivos est comprendido entre los 11 y los 12 Mbytes. En los generadores Clase B el tamao 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 correccin. 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 bateras de test ms exigentes para la determinacin de aleatoriedad sobre una serie de nmeros. IV. IMPLEMENTACIN EN LGICA PROGRAMABLE
RNS-LCG-II
p
0,407911 0,269137 0,407911 0,176487 0,872657 0,181225 0,452626 0,429352 0,305565 0,048907
0,607689 0,071269 0,143974 0,789647 0,510381 0,110432 0,292616 0,312498 0,119320 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. Simulacin 0 1 2 3 4 5 6 7 8 9 RNS-LCG-I p 0,800747 0,907225 0,326950 0,930700 0,087136 0,401577 0,949964 0,207195 0,038877 0,053990 RNS-LCG-II p 0,316036 0,263429 0,473377 0,649256 0,541925 0,972650 0,027664 0,141259 0,885084 0,855836
Debido a que los circuitos sumadores y multiplicadores son el ncleo de la mayor parte del hardware RNS, se realiz un amplio estudio sobre este tipo de operaciones en el sistema numrico de residuos [18] y [19]. Esta investigacin 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 operacin 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 nmeros pseudoaleatorios basados en el sistema numrico de residuos que pasan exitosamente, adems de las estadsticas bsicas, uno de los test de aleatoriedad ms 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. 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. 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. J. Savir A new empirical test for the quality of random integer generators, IEEE Trans. Comput., vol. C-32, pp. 960, Oct. 1983. Fred J. Taylor. Residue arithmetic: A tutorial with examples, Computer Magazine, IEEE Mayo. 1984. pp. 59-62. 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.
TABLA V. Valores de p calculados por Diehard para 10 series para los generadores RNS-LCG-I y RNS-LCG-II tipo C. Simulacin 0 1 2 3 4 5 6 7 8 9 RNS-LCG-I p 0,101530 0,134149 0,676679 0,205915 0,361947 0,544443 0,148867 0,052875 0,658070 0,114893 RNS-LCG-II p 0,084441 0,455188 0,974504 0,554348 0,917724 0,623239 0,031028 0,201848 0,320512 0,457464 [2]
[3]
[4] [5] [6]
Copyright 1984-2004, The MathWorks Inc.
46

[7] Fred J. Taylor. Large moduli multipliers for signal procesing, IEEE Transactions on circuits and systems, Volumen CAS-28, Nmero 7, Julio 1981. Chin-Liang Wang. IEEE Transactions on Circuits and Systems II: Analog and Digital Signal Processing, Noviembre 1994, pp. 768-772. 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. 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. J. Ramrez, P. G. Fernndez, U. Meyer-Bse, F. J. Taylor, A. Garca and A. Lloris, Design of Index-based RNS-DWT Architectures for Custom IC Designs, Proc. of 2001 IEEE Workshop on Signal Processing Systems SiPS2001, pp. 70-79, Sep. 2001. 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. J. Ramrez, A. Garca, P. G. Fernndez, L., Parrilla and A. Lloris, RNSFPL Merged Architectures for Orthogonal DWT, Electronics Letters, vol. 36, no. 14, pp. 1198-1199, Jul. 2000. N. S. Szabo and R. I. Tanaka, Residue Arithmetic and Its Applications to Computer Technology, McGraw-Hill, NY, 1967. 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. U. Meyer-Bse, 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. Garca, C. M. Gonzlez, L. Arnone, J. C. Garca, E. Boemo, Estudio sobre el diseo de sumadores en aritmtica de residuos en lgica programable , II Jornadas sobre Computacin Reconfigurable y Aplicaciones. 10 al 20 de septiembre de 2002, Almuecar, Granada, Espaa. Anales pg 203. ISBN: 84-600-9928-8. [19] C. A. Gayoso, C. Gonzlez, M. Rabini, L. Arnone, Estudio de multiplicadores en aritmtica de residuos empleando lgica programable, Dcimo Tercera Reunin de Trabajo en Procesamiento de la Informacin y Control RPIC 2009, 16 al 18 de septiembre de 2009. Rosario, Argentina. Pg. 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. Ramrez, P. G. Fernndez, U. Meyer-Bse, F. J. Taylor, A. Garca and A. Lloris, Design of Index-based RNS-DWT Architectures for Custom IC Designs, Proc. of 2001 IEEE Workshop on Signal Processing Systems SiPS2001, pp. 70-79, Sep. 2001.
[8] [9]
[10]
[11]
[12]
[13]
[14] [15]
[16]
47
Implementacin del algoritmo QRD-RLS sobre FPGA Aplicacin a un Sistema Cancelador de Ruido
Miguel Enrique Iglesias Martnez Departamento de Investigacin y Desarrollo Centro de Desarrollo de la Electrnica y la Automtica, CDEA Pinar del Ro, Cuba Email: mgi@cdea.co.cu
AbstractEn este artculo se describe una de las tantas aplicaciones de los algoritmos de filtrado adaptativo, en este caso la reduccin o cancelacin de ruido en particular usando el algoritmo QRD-RLS, llevando a cabo su implementacin sobre FPGA y tomando como eje fundamental del trabajo, la flexibilidad de estos dispositivos y las ventajas de la aceleracin de algoritmos por hardware en determinadas aplicaciones. Keywords- FPGA,QRD-RLS, algoritmos I.
INTRODUCCION
En algunos casos cuando se utilizan filtros digitales, las seales 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 disear un filtro que pueda aprender del proceso mismo, de manera que se pueda adaptar para manejar la situacin. Para resolver muchos de estos problemas se propone el uso de filtros adaptativos, cuya caracterstica principal es que estos pueden modificar sus parmetros durante la operacin 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 clculo de los coeficientes en un sistema dado, los cuales varan en complejidad. Entre los ms sencillos se encuentra el algoritmo Least Mean Square (LMS). Este algoritmo es muy usado debido a su facilidad de implementacin y baja utilizacin de recursos computacionales. Cuando el medio es altamente dinmico se requiere de algoritmos que se adapten rpidamente a los cambios,
para estos casos el algoritmo LMS no brinda un buen desempeo. Con esos propsitos se crearon algoritmos de rpida respuesta, tales como el algoritmo RLS [2]. El cual su caracterstica fundamental es que actualiza los coeficientes del filtro en cada iteracin, basado en el lema de inversin 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 mayora 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 implementacin del algoritmo RLS en su variante QRD-RLS sobre una arquitectura reconfigurable para lo cual se lleva a cabo primeramente el diseo del algoritmo en la herramientas de simulacin de sistemas Matlab, para luego obtener su sintetizacin en cdigo HDL mediante la plataforma de trabajo de Xilinx, AccelDSP, y su posterior inclusin en un sistema para la reduccin de ruido. El trabajo se ha organizado de la siguiente manera: La seccin 2 explicar los conceptos bsicos sobre algoritmos adaptivos en general, adems del algoritmo QRD-RLS en particular. La seccin 3 muestra la arquitectura y la plataforma de diseo. La seccin 4 muestra los resultados obtenidos a partir del diseo planteado y su comparacin con los obtenidos en simulacin, 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 segn lo mostrado en la figura 1. Como se puede apreciar se tiene una planta con caractersticas definidas, cuya salida es ingresada al mecanismo adaptativo luego de ser restada de una seal deseada, con lo que dicho mecanismo puede calcular los coeficientes nuevos necesarios para adaptar la respuesta de la planta a la seal deseada.
48
El mtodo de descomposicin QR comienza desde la matriz de datos usando transformacin unitaria. Para una matriz Q(n) unitaria dada, la funcin de coste puede ser expresada como:
E(n) =|| Q(n)1/ 2 (n)e(n) ||2 E(n) =|| Q(n)1/ 2 (n)d (n) Q(n)1/ 2 (n)(n)w(n) ||2 (3)
Para el problema de minimizacin definido por la funcin de coste, la matriz unitaria Q(n) es elegida para triangular la matriz de datos de manera exponencial ponderada tal que:
Figura 1 Diagrama de un sistema adaptativo Las ecuaciones mostradas modelan el funcionamiento de un sistema adaptativo [1].
R(n) Q(n) 1 / 2 (n)(n) = 0
(4)
y (t ) = u (t ) * w(t ) e(t ) = d (t ) y (t )
(1) (2)
Donde u(t) es la seal de entrada, y(t) es la seal de salida ya filtrada, d(t) es la seal deseada a la salida y e(t) es el error entre d(t) e y(t). En este caso, la seal de entrada u(n) pasa a la Planta que contiene los coeficientes w(n) (un filtro FIR) y devuelve una seal y(t) cuyo resultado se muestra en (1). En el momento que la planta entrega el resultado y(t), esta resta a una seal d(t) y produce una seal de error e(t) cuyo resultado se muestra en la ecuacin (2), la cual es el parmetro que le permite saber al mecanismo adaptivo que tan lejos se encuentra la planta de tener una respuesta similar a la seal deseada d(t). Conjuntamente con la seal 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
Donde R(n) es una matriz triangular superior de dimensin KxK y 0 es una matriz nula de dimensin (nK)xK. El vector de seal deseado, despus de estar transformado, esta definido por:
p(n) Q(n)1 / 2 (n)d (n) = v(n)
(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 funcin de coste de la siguiente manera:
p (n) R (n) E ( n ) =|| w( n ) || 2 v ( n) 0
p (n) R(n) w(n) 2 =|| || v ( n )
(6)
Dentro de los algoritmos adaptativos existentes el RLS (Recursive Least Square), es generalmente preferido por su rpida convergencia. El mtodo basado en mnimos cuadrados intenta encontrar un juego de coeficientes que minimicen la suma del error cuadrtico. El clculo directo del nuevo vector de coeficientes involucra la inversin de matrices, lo cual es generalmente indeseado en las implementaciones de hardware debido al alto consumo de recursos. La descomposicin de matrices basada en esquemas de mnimos cuadrados tales como, SVD (Singular Value Descomposition) y QR evitan explcitamente la inversin de matrices, son ms robustas y ms asequible su implementacin en hardware [5].
Es obvio que la estimacin de mnimos cuadrados para el vector de pesos debe satisfacer que:
p (n) R (n) w ' (n) = 0 K x1 w ' (n) = R 1 (n) p (n)
(7)
La matriz unitaria Q(n), la matriz triangular superior R(n), y el vector p(n) , pueden ser calculados recursivamente usando: p (n) R (n) 0 ( n K 1) xK 0 ( n K 1) x1 xK ( n ) 0 1
49
1 / 2 R ( n 1) = Q ' ( n ) 0 ( n K 1) xK u T ( n )
0 ( n K 1) x1 d (n) Q n ( 1 ) 0 (8) Q (n) = Q ' (n) 1 0
1 / 2 p ( n 1)
Por lo tanto el vector de coeficientes ptimos puede ser obtenido. Pero en algunas aplicaciones tales como reduccin de ruido y prediccin linear e(n), es la seal de salida. Desarrollando la ecuacin anterior podemos obtener e(n) directamente sin extraer el vector de pesos explcitamente. Este resultado puede resumirse en la siguiente ecuacin:
R ( n) 0 1xK
p ( n)
( n)
R 1 (n)u (n) ( 1 / 2 (n)) *
El diagrama de la arquitectura propuesta se observa a continuacin en la figura 3 donde se puede apreciar la forma clsica de un sistema adaptativo utilizado para cancelar ruido, donde en este caso, se toma como referencia del sistema ,la seal contaminada(d(n)+N(n)), y como seal de entrada al filtro, una muestra de ruido correlacionado(N(n)) con el presente en la seal, obteniendo como resultado a la salida del filtro una rplica del ruido contaminante de la seal til , lo que al efectuar la diferencia entre estas dos seales , se obtiene como salida la seal til inicial, correspondiente al error entre la referencia y la salida del filtro. La diferencia de este sistema con respecto a las dems arquitecturas de sistemas adaptativos es que la salida del mismo es la seal de error [2].
(9)
1 / 2 R (n 1) 1 / 2 p(n 1) 0 Kx1 = Q ' ' ( n) T (10) 1 d ( n ) u n ( )

La descomposicin QR se puede realizar mediante la utilizacin 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 DISEO
Figura 3 Filtro Adaptativo como reductor de ruido
A partir de lo mencionado anteriormente se inicia el diseo y simulacin del algoritmo QRD-RLS segn los parmetros de seal para los cuales el sistema deber responder de acuerdo a la caractersticas de ruido presente en la seal til, para lo cual se utiliza como seal interferente ruido blanco gaussiano de valor medio cero y varianza constante, y como seal til de prueba, un tono sinusoidal de frecuencia 1KHz muestreado a 16 KHz. Como se muestra en la figura 2.
La eleccin de la estructura de cancelacin adaptativa mostrada en la figura 3 y usada para la verificacin del algoritmo QRD-RLS pudiera no ser la mas ptima en cuanto a la cantidad de informacin que necesita el sistema para adaptarse, pudiendo usarse otro tipo de estructura de cancelacin de ruido, como la predictiva, la cual no requiere el conocimiento previo de la naturaleza del ruido aditivo a la seal, 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 sinterizacin sobre una arquitectura reconfigurable. Que el ruido que se toma como muestra de entrada al filtro, este correlacionado con el incidente en la seal til, implica mejores resultados y un menor nmero de operaciones para la convergencia del algoritmo, lo cual se traduce en un ahorro de recursos computacionales, siendo este ltimo punto, y la sntesis del algoritmo QRD-RLS, los objetivos fundamentales del trabajo.
A. AccelDSP
Figura 2 Seales utilizadas en la Aplicacin
AccelDSP es una herramienta de sntesis proporcionada por Xilinx, la cual permite transformar un diseo en punto flotante desarrollado en Matlab, en un mdulo hardware, que puede ser implementado en un FPGA.
50
Posee una interfaz de usuario fcil de usar que controla un ambiente integrado con otras herramientas de diseo, tales como: Matlab, Xilinx ISE, System Generator y otras como simuladores de cdigo HDL y sintetizadores lgicos [4].
B. Capacidades de AccelDSP
ruido blanco gaussiano. Posteriormente la seal obtenida pasa a travs de un conversor DAC para ser visualizada y comparada con los resultados obtenidos en la simulacin. 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 crtico 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.
AccelDSP proporciona las siguientes capacidades: Lee y analiza un diseo en punto flotante desarrollado en Matlab. Crea automticamente el diseo equivalente en punto fijo. Invoca a Matlab para simular y verificar el diseo tanto en punto fijo como en punto flotante. Crea un modelo HDL sintetizable con su fichero de simulacin correspondiente (Testbench) [4].
C. Flujo de diseo AccelDSP
En la figura 4 se puede observar el flujo de diseo de AccelDSP cuando se utiliza Xilinx System Generator como herramienta de diseo, para adicionar el sistema generado como una librera ms y reutilizar esta en posteriores diseos, aunque se puede emplear tambin Xilinx ISE .
Figura 5 Arquitectura del Sistema en System Generator

IV.
RESULTADOS
En orden de comparar los resultados obtenidos en la simulacin del sistema cancelador de ruido, con los mostrados en la implementacin del algoritmo QRDRLS, se presentan a continuacin una serie de grficas para la comparacin de los mismos, la cuales detallan la eficiencia del algoritmo en tareas de reduccin o cancelacin de ruido, utilizando como secuencia de adaptacin, una seal de referencia.
Figura 4 Flujo de Diseo AccelDSP-XSG [4].
Una vez generado el bloque del algoritmo QRD-RLS a travs de la herramienta de sntesis AccelDSP y exportado a System Generator, se adiciona este a un sistema diseado para comprobar su funcionamiento. El sistema de comprobacin del algoritmo se dise en System Generator, mediante el cual se generan, tanto la seal til correspondiente al tono sinusoidal, como el
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
51
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 atenuacin de las frecuencias fuera del rango dinmico de seal til. A continuacin se puede ver la comparacin entre la seal de entrada contaminada y salida del sistema, con lo cual se muestra la coincidencia del modelo de simulacin en Matlab con el modelo real implementado sobre el FPGA.
CONCLUSIONES
El algoritmo QRD-RLS es una excelente manera de filtrar una seal cualquiera usando una seal de referencia d(t) como modelo, pero, lamentablemente, su implementacin se traduce en un costo computacional elevado, aunque se pueden llegar a diseos 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 implementacin, ya que los mayores problemas de este algoritmo, son los clculos de la matriz de autocorrelacin inversa de la seal 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 crtico en el diseo. No obstante se logr sintetizar el algoritmo QRD-RLS sobre una arquitectura paralela y reconfigurable lo que posibilita su reutilizacin en posteriores diseos.
REFERENCIAS
[1]
Figura 7 Entrada contaminada y seal a la salida del sistema en System Generator
En cuanto a los recursos utilizados en la implementacin del algoritmo QRD-RLS, la tabla 1 muestra el consumo que origin la implementacin del mismo. Cabe destacar que el procesamiento de los datos mediante el algoritmo QRD-RLS se hizo tomando como longitud mxima, 24 bits, forzando el diseo del mismo a esta longitud de datos, teniendo en cuenta los recursos del dispositivo con el cual se llev a cabo la implementacin, y sin comprometer la eficiencia del algoritmo en cuanto a presentar a su salida, un resultado ptimo.
Jorge Benavides Aspiazu, Walter Calienes Bartra and Carlos Silva Crdenas,Diseo de una arquitectura para la implementacion de un filtro adaptativo rls sobre un fpga, XV Workshop Iberchip, Buenos Aires - Argentina,Marzo 2009. Saeed V. Vaseghi, Advanced Digital Signal Processing and Noise Reduction, Third Edition, 2006, John Wiley & Sons Ltd. S. Haykin,Adaptive Filter Theory, 3rd ed. Upper Saddle River, NJ:Prentice-Hall, 1994. AccelDSP Synthesis Tool User Guide obtenido de: http://www.xilinx.com/acceldsp_user.pdf. 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 B. Yang and J. F. Bohme, Rotation-based RLS algorithms: Unified derivations, numerical properties, and parallel implementations, IEEE Trans. Signal Processing, vol. 40, pp. 11511167, May 1992.
[2]
[3] [4]
[5]
[6]
Tabla 1 Consumo de Recursos del Algoritmo QRD-RLS
52
Dise no de un Sistema para el Control de Posici on de un Motor DC Basado en FPGA

Luis F. Casta no Londo no, Gustavo A. Osorio Londo no Grupo en Percepci on y Control Inteligente Departamento de Ingenier a El ectrica, Electr onica y Computaci on Universidad Nacional de Colombia - Sede Manizales
e impleResumenEn este art culo se presenta el diseno mentaci on de un sistema para el control de posici on de un motor DC basado en FPGA. Se describen los m odulos implementados en la FPGA que se encargan de la generaci on de la trayectoria del encoder, el controlador PI de arranque, la lectura de la senal de control PWM. El sistema de control y el generador de la senal es implementado en la tarjeta DE3 de Terasic Technologies Inc. usando VHDL y diagramas de bloques bajo el entorno Quartus II de Altera Corporation. Se presentan simulaciones realizadas con Simulink y resultados experimentales del sistema desarrollado. Palabras ClaveServocontrol, PID, VHDL, FPGA
Los microcontroladores est andar son los m as adecuados para aplicaciones con requerimientos relativamente bajos de control en tiempo real y que adem as requieren desarrollar otras tareas como el control de interfaces de usuario. Los DSP son empleados cuando los requerimientos del algoritmo de control en tiempo real son mayores [10]. Tanto para aplicaciones con microcontroladores como con DSP se emplean circuitos externos para el manejo de algunas tareas de la aplicaci on. Particularmente en el caso de aplicaciones con DSP se emplean CPLD o FPGA como en [1] y [5]. ltima d En la u ecada la implementaci on sistemas de servocontrol sobre FPGA se ha convertido en la soluci on alternativa, dado que este tipo de circuitos proporcionan bajo consumo de potencia y mayor estabilidad en el desempe no [6] [7]. Al no depender de una arquitectura espec ca los FPGA permiten el dise no de sistemas exibles que funcionan con una mayor velocidad de procesamiento debido a su capacidad de concurrencia. Por otra parte hoy en d a las herramientas de dise no, simulaci on y s ntesis sobre FPGA ofrecen variadas prestaciones para el dise no e implementaci on de todo tipo de sistemas embebidos de bajo costo. En este art culo se presenta la implementaci on de un servocontrolador para un motor DC basado en FPGA. En la secci on II se describen cada uno de los componentes del sistema que fueron desarrollados en VHDL y con diagramas de bloques bajo el entorno Quartus II e implementados en la tarjeta DE3. En la secci on III se presentan simulaciones y resultados experimentales del sistema desarrollado. Finalmente se presentan las conclusiones en la secci on IV.
I. I NTRODUCCI ON Actualmente existen varias aplicaciones y herramientas para la implementaci on de servocontroladores digitales ya sea con el uso de microcontroladores como en [2] [11], DSP como en [1] [5] [10] [12] y FPGA como en [4] [7]. Este tipo de sistemas pueden ser empleados para control de posici on en impresoras, plotters y escaners, ofreciendo m ultiples ventajas con relaci on a los sistemas que emplean motores de paso[11]. Tambi en se emplean en aplicaciones de rob otica [8] y automatizaci on[1]. La mayor a de estos sistemas son implementados con el uso de microcontroladores est andar, microcontroladores de 16 bits de gama alta o DSP cuando se desea incrementar el desempe no[11]. La selecci on del tipo de dispositivo para la implementaci on del servocontrolador depende de los requerimientos del sistema y las caracter sticas de la aplicaci on deseada. Generalmente los criterios de selecci on se basan en la relaci on costo-rendimiento y llevan a una decisi on entre microcontroladores est andar y DSP [10].
Fig. 1.
Esquema b asico del sistema de control de posici on del motor DC
53
DEL SISTEMA DE CONTROL II. I MPLEMENTACI ON El esquema b asico del servocontrol desarrollado se muestra en Fig. 1. El sistema a controlar es un motor DC de im an permanente instrumentado con un encoder incremental de 400 PPR (pulsos por revoluci on). La etapa de potencia consiste en un circuito inversor que permite el manejo de la corriente y el control del sentido de giro del motor. En la FPGA son implementados los m odulos que se encargan de la generaci on de la trayectoria para el arranque, la lectura de la se nal del encoder, el controlador PI y el generador de la se nal de control PWM. El diagrama de bloques del sistema de control realizado en Quartus II se muestra en Fig. 2. A. Generaci on de la funci on de arranque del motor Para el arranque del motor se debe tener en cuenta los efectos de la resistencia por fricci on seca y el transitorio de la corriente de armadura. El voltaje aplicado en el devanado debe ser suciente para que el torque del motor supere el torque resistivo debido a la fricci on seca. Por otra parte cuando se aplica una referencia de tipo escal on la corriente de arranque es muy alta debido a la inductancia de armadura. Esta situaci on puede ocasionar desgaste en los componentes mec anicos y el ectricos del motor debido a los movimientos abruptos y la disipaci on de potencia. Un m etodo para evitar la sobrecorriente en el transitorio es el arranque progresivo por medio de una curva de tensi on. La generaci on de esta curva se realiza a partir de una funci on de velocidad de forma trapezoidal como la que se muestra en la parte superior de Fig. 3. La implementaci on de esta funci on se realiza con base en la expresi on que se muestra en (1). ref
si t /4 4max t/, = max , si /4 t 3 /4 4max t/ + 4max , si t 3 /4
(1)
Las caracter sticas de este trapecio est an determinadas por la velocidad m axima (max ) y la posici on nal (f ) que se alcanza en el tiempo ( ). El valor de se dene como tf ti y es calculado como f /max .
Fig. 3. Funciones de velocidad y posici on para el arranque del motor. El valor de tf ti determina el tiempo para el cual se desea que el motor alcance la posici on nal f .
Fig. 2.
Diagrama de bloques del sistema de control de posici on
54
Esta funci on de velocidad se integra para obtener una funci on de referencia de posici on como la que se muestra en la parte inferior de Fig. 3. El esquema para la implementaci on del generador de la funci on de arranque se muestra en Fig. 4.
El anillo externo es la secuencia para la detecci on la direcci on del giro en el sentido contrario a las agujas del reloj, siendo la salida 1. Las transiciones entre los estados del anillo interno al externo o del anillo externo al interno permiten la detecci on del cambio de sentido de giro. El circuito planteado de esta forma se puede implementar de manera sencilla a trav es de una descripci on comportamental algor tmica en VHDL.
Fig. 4. Esquema del generador de funciones de las trayectorias de velocidad y posici on para el arranque del motor
on B. Medida de la posici La medida de la posici on es realizada con un encoder magn etico incremental de 400 PPR acoplado al rotor del motor. Este encoder entrega dos se nales en cuadratura como se muestra en Fig. 5. Estas se nales permiten detectar el desplazamiento y el sentido de giro del rotor. Cuando el rotor gira en el sentido de las agujas del reloj la fase A se encuentra adelantada 90 a la fase B como se muestra en Fig. 5(a). Cuando el rotor gira en el sentido contrario a las agujas del reloj la fase B se encuentra adelantada 90 a la fase A como se muestra en Fig. 5(b).
Fig. 6. Diagrama de transici on de estados del circuito de detecci on de sentido de giro del motor
(a) Fase A adenlatada 90 a la fase B
La medida de la posici on se realiza con un contador de pulsos ascendente/descendente de n bits. La se nal de reloj para este contador se obtiene de la xor entre las dos fases del encoder dando lugar a una medida de 800 ppr. Este contador se incrementa o decrementa en funci on del desplazamiento y el sentido de giro del rotor. El contador esta dise nado para dar una medida tanto positiva como negativa del desplazamiento del rotor con relaci on a su posici on inicial cuando se enciende el circuito. Para garantizar una lectura correcta de las se nales del encoder tanto para la detecci on del sentido de giro como para determinar la posici on, se implementa un circuito antirebote como parte de este m odulo, ya que la duraci on de un pulso para cada una de estas se nales es de 500s cuando el motor trabaja a 2000 rpm. C. Controlador proporcional integral El control basado en el esquema PID convencional es ampliamente usado debido a su simplicidad y desempe no [6] [8]. Algunos sistemas de servocontrol poseen tres lazos de control (posici on, velocidad y corriente) permitiendo un mejor comportamiento de las caracter sticas est aticas y din amicas del sistema [3] [4] [9]. El lazo de posici on es el principal para el servocontrol. El lazo de velocidad limita las uctuaciones de velocidad para mejorar la respuesta en el transitorio y frente a perturbaciones en la carga. El lazo de corriente limita la interferencia de la corriente de armadura y la corriente m axima para proteger el motor [4] [9]. Tambi en se pueden encontrar
(b) Fase B adenlatada 90 a la fase A Fig. 5. Se nales del encoder
La detecci on del sentido de giro a partir de las se nales del encoder se realiza a trav es de un circuito secuencial cuyo diagrama de transici on de estados se muestra en Fig. 6. El anillo interno es la secuencia para la detecci on de la direcci on del giro en el sentido de las agujas del reloj, siendo la salida 0.
55
sistemas basados en lazos de posici on y velocidad como nicamente un lazo en [2]. El sistema implementado posee u de posici on con un controlador PI, siendo los controladores proporcional e integral los m as comunes para los lazos de posici on, velocidad y corriente en este tipo de sistemas de control. La salida del controlador PI se calcula como se til muestra en (2) y determina el valor del porcentaje de ciclo u de la se nal de control PWM tal como se muestra en Fig. 8. u(t) = sat Kp e(t) + Ki sat e(t) dt (2)
E. Descripci on del sistema f sico El modelo de un motor DC de im an permanente puede ser representado por las expresiones mostradas en (4a)-(4d). Estas ecuaciones son obtenidas de los sistemas el ectrico y mec anico mostrados en el circuito equivalente de Fig. 9. Ea = Ra ia + La dia + ea dt (4a)
El control proporcional es elaborado con un circuito multiplicador generado con la herramienta MegaWizard Plug-In Manager del Quartus II. El control integral es implementado con base en (3) y el diagrama de bloques mostrado en Fig. 7. El valor de la constante h est a determinado por la frecuencia de reloj del circuito de integraci on (e.g. h = 50s para fclk = 20KHz ). Los valores de Kp y Ki son denidos a trav es de entradas externas. e(t) dt = h 2 (e(k ) + e(k 1)) (3)
m = J
d2 d +B dt dt
(4b) (4c) (4d)
m = Kt ia ea = Ke
Fig. 9.
Circuito equivalente del motor DC de im an permanente
Fig. 7.
Diagrama de bloques para la implementaci on del control integral
La representaci on en el espacio de estados del modelo del motor se muestra en (5). x 1 0 2 = 0 x = x 0 x 3 1 a c x1 0 0 b x2 + 0 u f d x3 x1 x2 x3 y = 1 0 0
D. Generador de la se nal de control PWM El generador de la se nal PWM se basa en el diagrama de bloques mostrado en Fig. 8. Este m odulo consta de un contador, un circuito aritm etico, un comparador y un demultiplexor. El contador permite generar una se nal diente de sierra de 20 KHz. El circuito aritm etico se emplea para el c alculo del valor de referencia que es comparado con la se nal diente de sierra para generar la se nal PWM. El circuito demultiplexor se encarga de llevar la se nal de control PWM a las entradas del puente inversor seg un el signo de la se nal de control para determinar el sentido de giro del motor.
(5)
donde a = B/J, b = Kt /J, c = Ke /La , d = Ra /La y f = 1/La , est an denidos por los par ametros del motor. Los valores de los par ametros obtenidos con la identicaci on del motor son: B = 1.2e6 N ms/rad, Kt = 14.5e6 N m/A, J = 0.5e6 N ms2 /rad, Ke = 0.35V s/rad, Ra = 3.3 y La = 36 H . Y RESULTADOS EXPERIMENTALES III. S IMULACI ON Las simulaciones del sistema implementado son realizadas en MATLAB usando Simulink con base en el modelo desarrollado en la secci on II-E. Para obtener los datos experimentales se emplea el Signal Tap II Logic Analyzer del Quartus II. Con el uso de esta herramienta para cada experimento se toman 65536 muestras de cada una de las variables que se desea medir.
Fig. 8. Diagrama de bloques para la implementaci on del generador de la se nal de control PWM
56
A. Experimento A: respuesta en lazo abierto Las pruebas para observar la respuesta del motor en lazo abierto se realizaron para valores de Ea entre 0.5V y 24V. En Fig. 10 se muestra la respuesta del sistema en lazo abierto para una valor de ea de 4V. La l nea continua muestra la respuesta de la simulaci on y la l nea punteada corresponde a los valores experimentales medidos con el encoder.
Fig. 11. Respuesta del sistema en lazo cerrado con controlador PI. Kp = 20, Ki = 4. El gr aco superior muestra los resultados de la simulaci on y el gr aco inferior muestra los resultados experimentales. La l nea s olida corresponde a la referencia y la l nea punteada corresponde a la respuesta del motor. Fig. 10. Respuesta del sistema en lazo abierto a un escal on de 4V. La l nea continua muestra la respuesta de la simulaci on y la l nea punteada corresponde a los valores experimentales medidos con el encoder.
B. Experimento B: respuesta en lazo cerrado En la parte superior de Fig. 11 se muestra la simulaci on para la respuesta del sistema en lazo cerrado con Kp = 20, Ki = 4 y una alimentaci on para circuito de potencia de 15 V. La l nea s olida corresponde a la referencia y la l nea punteada corresponde a la respuesta del motor. En la parte inferior de Fig. 11 se muestra la respuesta experimental del sistema en lazo cerrado para los mismos valores de Kp y Ki . La l nea continua corresponde a la referencia y la l nea punteada corresponde a la respuesta del motor. En Fig. 12 se muestran las se nales de error. La l nea continua corresponde a los resultados de la simulaci on y la l nea discontinua corresponde a los datos experimentales. Los valores de Kp y Ki se escogieron experimentalmente de tal forma que la respuesta del sistema fuera estable. IV. C ONCLUSIONES En este art culo se presenta el dise no e implementaci on del control de posici on para un motor DC basado en FPGA. El dise no es realizado con el uso de VHDL y diagramas de bloques e implementado en la FPGA. Debido a la modularidad del dise no y la independencia de una arquitectura espec ca es posible implementar diferentes topolog as basadas en el esquema convencional PID. En este art culo se realiza la descripci on y se presentan los resultados del sistema con un controlador PI aplicado a un lazo de posici on. La comparaci on entre los resultados de la simulaci on y los datos experimentales permiten validar el funcionamiento del sistema desarrollado tanto en lazo abierto como en lazo
Fig. 12. Se nal de error del sistema en lazo cerrado con controlador PI. Kp = 20, Kp = 4. La l nea continua corresponde a los resultados de la simulaci on y la l nea discontinua corresponde a los datos experimentales.
cerrado. La diferencia en el comportamiento de la se nal de error para los resultados de la simulaci on y los resultados experimentales se relaciona principalmente con el modelado del motor. Sin embargo se puede observar un comportamiento bastante aproximado del sistema tanto en el transitorio como en estado estacionario. Las caracter sticas del sistema desarrollado y las herramientas empleadas permitir an realizar el estudio de la din amica del sistema aplicando otras topolog as y esquemas de control. Existe principal inter es en la implementaci on de controladores basados en esquemas diferentes al PID (ie. controladores basados en la estrategia zero average dynamics (ZAD)), en los cuales resulta fundamental la capacidad de concurrencia y velocidad que brindan los FPGA.
57
R EFERENCIAS
[1] X. Zhou, L. Sundong, W. Li, Implementation of a High Performance Stand-Alone Motion Controller, in Proceedings of International Conference on Advanced Intelligent Mechatronics, 2009. IEEE/ASME 2009., pp.269-273, 14-17 July. 2009 [2] H. Zhou, DC Servo Motor PID Control in Mobile Robots with Embedded DSP, in Proceedings of the International Conference on Intelligent Computation 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-system of BLDCM based on frequency domain method, in Proceedings of International Conference on Electrical Machines and Systems, 2008. ICEMS 2008., pp.1612-1617, 17-20 Oct. 2008 [4] T. Ya, Z. Runjing, H. Xiaoxia, Application of FPGA in Direct Current Motor Servo System, in Proceedings of the 27 Chinese Control Conference. CCC 2008., pp.261-265, 16-18 July 2008 [5] J. Xu, B. You, L. Ma, Research and development of DSP based servo motion controller, in Proceedings of the 7th World Congress on Intelligent Control and Automation, 2008. WCICA 2008., pp.7720-7725, 25-27 June 2008 [6] J. Kim, H. Jeon, S. Jung, Hardware implementation of nonlinear PID controller with FPGA based on oating point operation for 6-DOF manipulator robot arm, in Proceedings of the International Conference on 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 Modular FPGA-Based PID Controllers, in IEEE Transactions on Industrial Electronics, vol.54, no.4, pp.1898-1906, Aug. 2007 [8] J. Lima, R. Menotti, J. M. P.Cardoso, E. Marques, A Methodology to Design FPGA-based PID Controllers, in Proceedings of the IEEE International Conference on Systems, Man and Cybernetics, 2006. SMC 06., vol.3, pp.2577-2583, 8-11 Oct. 2006 [9] Z. Runjing, D. Yu, Y. Weiting, Application of Fuzzy-PI Controller with Feedforward Control in Direct Current Motor Servo System, in Proceedings of the International Conference on Neural Networks and Brain, 2005. ICN N &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/les/microcontrollers/doc/app note/AN1213.pdf [11] Microchip Technology Inc., T. Bucella, Aplication Note 532: 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 servo system based on new self-tuning PID algorithm and DSP, in Proceedings of The IEEE International Conference on Industrial Technology, 1996. ICIT 96, pp.71-75, 2-6 Dec. 1996
58
Implementacin del procesador Cortex-M0 DesignStart en una FPGA de rango bajo

Pedro Ignacio Martos y Fabricio Baglivo
Laboratorio de Sistemas Embebidos Facultad de Ingeniera - UBA Buenos Aires, Argentina pmartos@fi.uba.ar / baglivofabricio@gmail.com
AbstractLos procesadores de la lnea CortexTM-M de ARM ltd. estn orientados a la implementacin 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 lnea de FPGA. Por otra parte, ARM ha lanzado recientemente una versin 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 implementacin de dicho procesador en una FPGA de rango bajo de Xilinx, logrndose de esta manera ampliar el rango de implementaciones de los procesadores Cortex-M en FPGA. Keywords- Cortex-M0, FPGA
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 diseo, 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 cdigo con procesadores ms potentes de la familia como el Cortex-M3. La menor implementacin de Cortex-M0 consume 85W/MHz y ocupa un rea equivalente de 12.000 compuertas. Como referencia, un procesador clsico como el i8051 ocupa tpicamente alrededor de 8.000 compuertas [1][2]. En la Fig. 2 vemos la ubicacin relativa de cada miembro de la familia Cortex-M en funcin de su performance y plataforma de implementacin.
I.
INTRODUCCION
A. Descripcin de las familias de procesadores de ARM En la lnea 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 clsicas incluyen a las familias ARM7, ARM9 y ARM11 y las series especializadas SecurCore para aplicaciones de seguridad y criptografa. En la Fig. 1 se puede apreciar la ubicacin relativa de cada familia en relacin a su capacidad y funcionalidad.
Figura 2. Comparacin 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 ms una no enmascarable a travs de un controlador de interrupciones integrado (NVICNested Vectored Interrupt Controller) con una latencia fija de 16 ciclos de mquina [3]. La Fig. 3 muestra un diagrama en bloques del procesador Cortex-M0
Figura 1. Relacin performance-capacidades de las distintas familias de procesadores de ARM
59
Figura 3. Diagrama en bloques de un procesador Cortex-M0
Su interfase con otros perifricos es a travs de una versin reducida del bus Advanced Microcontroller Bus Architecture (AMBA), denominada AMBA AHBLite. Este bus fue diseado como un bus de alta performance para transferencias rpidas entre el procesador y perifricos que requieran gran ancho de banda y/o altas tasas de transferencia de datos. Generalmente se lo implementa con un nico dispositivo que acta como maestro y el resto como esclavos, aunque la especificacin del bus permite la implementacin de mltiples maestros. Sus principales caractersticas son que permite transferencias en rfaga, 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 implementacin del bus y las Figs. 5 y 6 muestran las seales de un dispositivo maestro y un dispositivo esclavo respectivamente.
C. Procesador Cortex-M0 DesignStart El procesador Cortex-M0 DesignStart (M0DS) es una versin 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 slo posee la interfase como maestro; el M0S puede implementarse con un multiplicador rpido de 1 ciclo de reloj o con uno lento de 32 ciclos de reloj, mientras que el M0DS slo 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 interrupcin 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 comunicacin 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. IMPLEMENTACIN
A. Hardware y software utilizado La FPGA empleada es de una lnea madura y de rango bajo de Xilinx: S3E500-4; sus principales caractersticas son: 500K compuertas, 10500 celdas lgicas (equivalentes a 1100 bloques lgicos 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 mxima de trabajo de 300MHz [8]. La placa utilizada es una placa bsica (starter board) de la firma Digilent, modelo Nexys2. Cuenta con una FPGA S3E500, una interfase de programacin y comunicaciones por USB, 16 Mbytes de PSDRAM y 16 Mbytes de Flash ROM, ms una PROM de configuracin; 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 4. Ejemplo de un sistema con bus AMBA-Lite
Figura 5. Seales de un dispositivo AMBA-Lite maestro
Figura 7. Diagrama en bloques de la placa de desarrollos utilizada
Figura 6. Seales de un dispositivo AMBA-Lite esclavo
Una de las ventajas de esta placa es que, mediante un software que se obtiene de la pgina web del fabricante (Adept), es posible utilizar directamente las herramientas de programacin de Xilinx (Impact, Chipscope Pro, Xmd, etc.), lo que permite programarla y ver su estado interno fcilmente.
60
Como herramientas de software se utiliz el entorno de desarrollo para FPGA de Xilinx ISE versin 12.2; para la generacin 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 bsicas. 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 mdulo no sintetizable en verilog que implementa al procesador conectado a una memoria preinicializada con un programa simple. Completan el test bench el cdigo 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 cdigo fuente en C. En la Fig. 8 se v el diagrama en bloques del test bench.
determin la viabilidad de realizar la implementacin. Durante la ejecucin del tem 2), en la simulacin 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 razn de ello, se continu con el tem 3), para obtener una simulacin de la ejecucin 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 compilacin y enlazado eran del MDK (Armcc y Armlink), los parmetros pasados no correspondan a dichas herramientas. Buscando en la documentacin de otros proveedores de herramientas de software para procesadores ARM se lleg a la conclusin que los parmetros correspondan 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 serva para generar el archivo binario a partir del archivo fuente. Ante esta situacin, se decidi implementar un proyecto en MDK con el archivo fuente provisto, obtener un archivo binario, y utilizar este en la simulacin para verificar si se repeta 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 simulacin de software en MDK con la simulacin funcional del test bench en ISIM de Xilinx. Al realizar dicha comparacin, se encontr que la simulacin del software en MDK funcionaba correctamente, mientras que la simulacin funcional en el ISIM mostraba valores que no correspondan en los buses de datos. Un anlisis 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 funcin de verilog $fread asumiendo que la misma realizaba una lectura de 4 bytes simultneamente (32bits), cuando la misma en la implementacin 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 inicializacin de la memoria; y de esa manera la simulacin de software del MDK coincidi con la simulacin funcional de ISIM para el cdigo 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 agregara 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 generara un programa que buscara dichos valores constantes en memoria, lo que obligara a aparecer a dichos valores sobre el bus de datos del procesador, permitiendo su deteccin. 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 verificacin,
Figura 8. Diagrama en bloques del test bench
C. Plan de trabajo de la implementacin 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 simulacin. 3) generar el archivo binario a partir del cdigo fuente utilizando el makefile provisto. 4) verificar en el test bench que el archivo binario generado sea correcto mediante simulacin. 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 implementacin del procesador. Verificar el mismo mediante simulacin 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 simulacin 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 implementacin realizada El tem 1) se realiz sin mayor inconveniente, resultando en un uso aproximado del 50% de los Slices de la FPGA, lo que
61
se cargo el programa en el test bench y se verifico en la simulacin funcional con ISIM que los valores elegidos aparecan sobre el bus de datos. En la Fig. 10 se ve una captura de la simulacin funcional en ISIM.
ver seales internas de la FPGA, se verific la aparicin 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, dndose as por validada la implementacin del procesador en la FPGA. III. RESULTADOS Y CONCLUSIONES
El resultado ms destacable es que es posible implementar este procesador en una FPGA de rango bajo, lo que permite su aplicacin en sistemas embebidos sobre FPGA de bajo costo. Asimismo se ampli el espectro de implementacin 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.
Figura 9. Simulacin de software mostrando el acceso a memoria
Como estadsticas de implementacin, en la Fig. 11 se muestran los resultados de uso de la FPGA:
Figura 10. Simulacin funcional mostrando el acceso a memoria
Figura 11. Estadisticas de uso de la FPGA una vez realizada la implementacin del sistema
Siendo exitosas las simulaciones, se implemento el sistema sintetizable. El mismo consta de las siguientes partes: Procesador, con el cdigo verilog del procesador CortexM0DS; Sincronizador de reset, implementado con un contador que fija una seal en nivel alto al llegar al final del conteo, a fin de generar una seal de reset sincrnica con el reloj del sistema. Memoria, implementado como una RAM preinicializada con el archivo binario generado en MDK. Reloj, que implementa la seal de reloj de referencia, a travs 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 simulacin 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 aparecan sucesivamente sobre el bus de datos. Finalmente se implemento completamente el sistema y se program la placa con el mismo, realizndose las siguientes verificaciones: con la herramienta ChipScope Pro, que permite
Como resultados de temporizacin, la herramienta de sntesis y los resultados Post Place and Route indicaron una frecuencia mxima de trabajo de alrededor de 40MHz. Cabe aclarar que no se realizaron ningn tipo de restricciones de temporizacin o ubicacin 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 simulacin de software, la simulacin funcional en ISIM, y la verificacin de la implementacin a travs de ChipScope Pro a nivel de registros internos del procesador. Como aspecto a considerar sera las mejoras al test bench provisto; acortara 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 implementacin. Como conclusin, 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 lnea de trabajo futura se propone crear una
62
implementacin de bus AMBA-Lite y perifricos compatibles con este bus, a fin de aumentar sus capacidades y convertirlo en una opcin a tener en cuenta en la creacin 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.
[1] [2] [3] [4] [5] [6] [7] [8] [9]
REFERENCIAS
CAST T8051 Core Product Brochure (www.cast-inc.com) IPextreme M8051EW+ Core Product Characteristics (www.ipextreme.com) ARM Ltd, ARM DDI 0419C ARMv6-M Architecture Reference Manual, Septiembre de 2010. ARM Ltd, ARM IHI 0033A AMBA 3 AHB-Lite Protocol V.1.0 Specification, Junio de 2006. ARM Ltd, AT510-DC-80001-r0p0-00-rel0 ARM Cortex-M0 DesignStart Release Note, Agosto de 2010. ARM Ltd, ARM DDI 0432C Cortex-M0 Revision r0p0 Technical Reference Manual, Noviembre de 2009. ARM Ltd, ARM DUI 0497A Cortex-M0 Devices Generic User Guide, Octubre de 2009. Xilinx, DS312 Spartan-3E FPGA Family: Datasheet, Agosto de 2009. 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 cooperacin.
VI.
MARCAS REGISTRADAS
La informacin 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.
63
Sistemas en Chip acelerados por hardware: comparacin de performance en aplicaciones criptogrficas

Marcos J. Oviedo
Facultad de Ingeniera Instituto Universitario Aeronutico Crdoba, AR moviedo@gmail.com
Pablo A. Ferreyra
Facultad de Matemtica, Astronoma y Fsica Universidad Nacional de Crdoba Posgrado en Sistemas Embebidos Instituto Universitario Aeronutico Crdoba, AR ferreyra@famaf.unc.edu.ar
Carlos A. Marqus
Facultad de Matemtica, Astronoma y Fsica Universidad Nacional de Crdoba Crdoba, AR marques@famaf.unc.edu.ar
Abstract El procesamiento de datos de alta performance se ha convertido en un desafo para la tecnologa de los sistemas embebidos actuales. Una alternativa para suplir los requerimientos de performance es la utilizacin de aceleradores de hardware implementados en lgica programable. En el presente trabajo se muestran los resultados obtenidos de dos implementaciones del algoritmo criptogrfico TripleDES a travs del uso de aceleradores de hardware. Keywords; Computacin de Alta Performance, Sistema en Chip, Encriptacin de datos Standard, Optimizaciones de Hardware, Aceleradores de Hardware.
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 cmputo 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 implementacin en hardware a travs de lgica programable es una alternativa vlida que se puede utilizar para lograr sustanciales incrementos en performance, teniendo en cuenta el alto nivel de paralelismo que se puede conseguir con la utilizacin de una plataforma de lgica programable. En el presente trabajo se mostrar en forma terica una metodologa de desarrollo de un HPSoC para luego finalizar con una comparacin de performance entre los resultados obtenidos de dos alternativas de implementacin del algoritmo de encriptacin simtrico TripleDES en un HPSoC. La implementacin se realizo sobre una plataforma de lgica programable que contiene una FPGA Xilinx Virtex 4. Este paper est organizado de la siguiente forma: La seccin II presenta informacin terica sobre las limitaciones de los sistemas basados en procesador que motivan el presente trabajo. La seccin III presenta la metodologa de trabajo propuesta para desarrollar este tipo de sistemas digitales. La seccin IV presenta un enfoque en distintos niveles sobre las tcnicas y mecanismos disponibles para incrementar la performance de un HPSoC. La seccin V presenta dos implementaciones de HPSoC que proveen aceleradores criptogrficos desarrollados siguiendo la metodologa propuesta. La seccin VI muestra y compara los resultados obtenidos. Por ltimo, en la seccin VII se muestran los resultados obtenidos y se presentan las conclusiones del presente trabajo.
I.
INTRODUCCION
Avances en la industria de los semiconductores han permitido que utilizando componentes de lgica 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 aplicacin especfica y software de aplicacin y control. Uno de los conceptos ms poderosos atrs del diseo SoC es que la funcionalidad del sistema puede ser especificada y asignada no slo al software que corre sobre el procesador, sino tambin a los componentes de hardware que lo constituyen. Permitiendo as, que para efectos de aceleracin 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 tecnolgica de la sociedad moderna, los sistemas embebidos que componen los equipos electrnicos actuales debe ser capaces de evolucionar constantemente a modo de soportar la creciente demanda de capacidad de procesamiento a los que estn sometidos. A modo de resolver esto existen alternativas a los sistemas embebidos
64
II.
LIMITACIONES DE LOS SISTEMAS BASADOS EN PROCESADOR
III.
METODOLOGIA DE DESARROLLO DE UN HPSOC
Los procesadores fueron concebidos para realizar computacin de propsito general. Esta decisin de diseo produjo que los procesadores no sean eficientes a la hora de realizar tareas de cmputo especficas 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 aos se ha buscado alternativas para mejorar la performance de las plataformas de cmputo 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 fsicas inherentes a los procesadores que en muchos casos y dada la tecnologa 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 disipacin de calor (barrera de potencia). La frecuencia no puede ser incrementada arbitrariamente, no solo por la barrera de potencia, si no tambin debido a una inherente limitacin fsica en los tiempos de conmutacin de los transistores utilizados en el diseo del microprocesador (barrera de frecuencia). En un sistema de cmputo 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 jerarquas de memorias locales al microprocesador (caches) disminuye considerablemente el tiempo de acceso a los datos, pero debido a la imposibilidad tecnolgica de incrementar el tamao del cache arbitrariamente, el acceso a memoria sigue siendo un problema real (barrera de memoria). Finalmente los procesadores en si tienen una limitacin fundamental: Un diseo basado en ejecucin serial, que hace extremadamente difcil extraer niveles de paralelismo de un flujo de ejecucin de instrucciones. Como se menciona en [2] existen complejos diseos y tcnicas en las arquitecturas de los procesadores actuales que intentan extraer el paralelismo en las instrucciones y mitigar esta limitacin.
En la metodologa propuesta, el diseo de un HPSoC consistir en dos reas separadas pero que requieren interaccin entre ellas. Una de esas reas es la creacin del soporte necesario para implementar un sistema embebido en la FPGA basado en microprocesador y la otra es la optimizacin de la aplicacin en vistas de una posterior implementacin basada en un codiseo hardware-software. En este codiseo el componente de hardware se implementara como un componente acelerador que se comunicara con el componente de software a travs del diseo embebido. En primera instancia, el desarrollo de sistemas embebidos se realiza utilizando herramientas EDA que permiten interconectar, a travs de una jerarqua de buses de interconexin, 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 vara 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 libreras de componentes de hardware XilinxProcessorIPLib. En segunda instancia, se deber trabajar sobre la aplicacin que se busca optimizar. Para esto se debe realizar un prototipo por software de la aplicacin o algoritmo a implementar en el HPSoC. Este prototipo ser luego caracterizado y evaluado mediante herramientas como profilers y analizadores de cdigo, a modo de poder detectar cuales son los segmentos o reas de la misma en donde ms procesamiento se realiza (secciones crticas en trminos de performance). Con esta informacin y a travs de un enfoque top-down, se proceder a estudiar el algoritmo que define la aplicacin, a modo de refactorizar la misma y que las secciones crticas puedan ser optimizadas y aisladas para ser implementadas en hardware. La implementacin en hardware de las secciones crticas de la aplicacin permiten que las operaciones computacionales puedan ser representadas en lenguajes de descripcin de hardware y que a travs de una estrategia de optimizacin 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 descripcin de hardware como VHDL o utilizar una herramienta ESL como ImpulseC [4]. El componente acelerador adems, deber integrarse dentro del diseo embebido del HPSoC, por lo que un canal de comunicacin de alta velocidad entre hardware y software deber tambin ser desarrollado. Por otro lado, cabe mencionar que el componente de software del codiseo HW/SW puede correr directamente sobre el procesador o bajo el control y soporte de un sistema operativo (como una aplicacin ms de espacio de usuario). Dado los beneficios que provee un sistema operativo, en nuestra metodologa se brinda soporte de un sistema operativo para el componente de software.
La utilizacin de lgica programable y la realizacin 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 implementacin de un HPSoC que permitir crear una plataforma de computo especifica y orientada a la aplicacin, a modo de optimizar el camino de ejecucin de datos (a travs de extraer e implementar paralelismo), optimizar el uso de la memoria (aumento la localidad y el acceso), disminuir la disipacin de potencia (hardware especifico requiere menor nmero de transistores) y disminuir la frecuencia de trabajo (posible debido a que en cada ciclo de reloj se realizan mltiples operaciones).
65
Una vez que estas dos instancias del HPSoC estn completas, el diseo de hardware tiene que ser trasladado y mapeado en el fabric de una FPGA, y las imgenes binarias del software correspondiente tienen que ser almacenadas en las memorias correspondientes para su posterior evaluacin. IV. OPTIMIZACION DE PERFORMANCE EN UN DISEO HPSOC
detalles de bajo nivel que definen la implementacin del mismo. Entonces, si posibles paralelizaciones son detectadas, y siempre cumpliendo con los requerimientos funcionales iniciales, se buscara implementar las modificaciones necesarias en el cdigo del algoritmo, de modo de que este deje de lado su flujo de ejecucin serial y adopte un modelo de funcionamiento en paralelo. Adems de detectar niveles de paralelizacin y optimizaciones en el flujo de ejecucin del algoritmo, otra interesante tcnica que se puede utilizar para optimizar la performance a nivel de aplicacin es el uso de precomputo de datos. Esto consiste bsicamente en acotar el rango de accin 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 ejecucin del mismo. C. Optimizaciones a nivel de micro arquitectura Describimos como micro arquitectura a los componentes de lgica programable que implementan los detalles de bajo nivel del algoritmo que define la aplicacin que se ejecutara sobre el HPSoC. Algunas tcnicas 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 ms importantes que nos ofrece la programacin en hardware es la posibilidad de acceder a mltiples bancos de memoria en un solo ciclo de reloj. A diferencia de una implementacin de software, en la que un CPU esta conectado a uno o mas dispositivos de memoria fsica siempre a travs de un solo bus, una implementacin en hardware permite la flexibilidad de generar una topologa 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 operacin 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 operacin/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 iteracin se puede operar sobre set de datos independientes, el grado de paralelismo que se puede obtener es elevado. Existen dos tcnicas para optimizar las operaciones sobre bucles, estas son el desenrollado del bucle y la generacin de lneas de ensamblado, o mas conocido por su trmino 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
Existen diversos factores que pueden ser modificados y tcnicas 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 optimizacin. A. Optimizaciones a nivel de Sistema Describimos como sistema a la plataforma fsica en donde se implementa la aplicacin. Las optimizaciones a nivel de sistema estn 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 ms rpido y para que el throughput sea ms elevado. La optimizacin trivial es modificar el diseo de hardware que compone la plataforma de cmputo para que los diversos componentes de esta funcionen a la mxima velocidad admisible. Adems, 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 comunicacin 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 sntesis que sintetizan el diseo de hardware permiten configurar restricciones de tiempo y aumentar el nivel esfuerzo, a modo de mejorar el rendimiento disminuyendo el tiempo de propagacin de datos a travs 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 adems exista disponibilidad de recursos en la FPGA utilizada, se puede implementar ms de un componente acelerador y procesar as varios conjuntos de datos en paralelo. B. Optimizaciones a nivel de aplicacin Describimos como aplicacin al algoritmo computacional que cumple un cierto nmero de requerimientos con el fin de implementar por software o hardware la funcionalidad principal del HPSoC. El objetivo de las optimizaciones a nivel de aplicacin es estudiar el algoritmo que define las operaciones crticas en performance de la aplicacin, a modo detectar el paralelismo inherente en el mismo y optimizar el procesamiento. Cabe aclarar que las optimizaciones sobre el algoritmo se harn sobre los detalles de alto nivel del mismo, y no sobre los
66
ser realizadas en paralelo y en una sola iteracin 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 iteracin del bucle requiere ejecutar N subtareas, en una implementacin sin pipeline, el bucle realizara una cantidad (N * cantidad_elementos_de_datos) de iteraciones para completar su trabajo. En cambio en una implementacin con pipeline, la totalidad de datos sern procesados en una cantidad (N + 1) de iteraciones. La teora de pipelines y desenrollado de bucles ha sido extensamente desarrollada en [5] y [6]. V. DESARROLLO DE UN HPSOC CRIPTOGRAFICO
componentes necesarios para volver al sistema embebido y su procesador una plataforma de computo funcional. Adems la herramienta permiti, desarrollar un canal de comunicacin de alta velocidad entre el componente acelerador implementado en la lgica programable y el microprocesador del sistema embebido. Se genero el soporte necesario para que el PPC pueda comunicarse a travs de los buses PLB, OPB, FCB, OCM y DCR a los distintos dispositivo. Estos buses pertenecen a la familia de buses CrossConnect y estn descriptos en [10]. Cabe aclarar que este procesador solo soporta conexin directa a los buses PLB, OCM, DCR y FCB, por lo que los dispositivos atrs del bus OPB se alcanzaran a travs de un bridge PLB2OPB. Una vez definida la arquitectura de buses, sus tamaos y frecuencias de trabajo, as como tambin 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 estarn conectados estos a la jerarqua de buses, a modo de que estos sean visibles al procesador PPC. La configuracin de los mismos, es particular de cada caso y dependiente del diseo adoptado, aunque por lo general esta configuracin 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 estarn reservadas en el mapa de memoria del sistema para los registros del mismo. Cada IPCore de la librera de hardware XilinxProcessorIPLib posee un datasheet que detalla sus parmetros de configuracin 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 comunicacin flexible y de alta velocidad entre el fabric de la FPGA y el procesador PPC. Esta interfase de comunicacin conecta directamente el pipeline de instrucciones del PPC a uno o ms componentes aceleradores de hardware. B. Desarrollo del soporte del software de control del HPSoC El componente de software de la aplicacin 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 adems un root filesystem con las aplicaciones necesarias para volver funcional al sistema. Se desarrollo adems un mecanismo para que el kernel pueda ser cargado en memoria de ejecucin mediante el uso de XMD, un debugger provisto por EDK y que a travs 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 direccin de red a travs de DHCP y bootear un root filesystem remoto a travs de NFS. En la figura 2 se puede observar la iteracin de protocolos durante el booteo del kernel.
A modo de evaluar las mejoras obtenidas a travs de la implementacin de un HPSoC acelerado por hardware, se desarrollo un SoC prototipo sin aceleracin (implementacin solo por software), y dos versiones de un HPSoC con aceleracin por hardware. En estos dos ltimos casos, el componente acelerador fue desarrollado en VHDL y con la herramienta de sntesis de alto nivel ImpulseC respectivamente. La aplicacin criptogrfica consisti en obtener un set de datos de memoria y cifrarlos a travs del algoritmo de cifrado simtrico TripleDES. El algoritmo de cifrado simtrico TripleDES se utiliz en modo ECB, siguiendo los lineamientos mencionados en [7] y [8]. Siguiendo la metodologa propuesta en el presente trabajo, despus de disear 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 tcnicas de optimizacin enumeradas en [9], se procedi a desarrollar los componentes aceleradores y aplicar los niveles de optimizacin anteriormente descritos. Cabe aqu citar que para la implementacin 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 pgina 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 diseo embebido se dio soporte a todos los dispositivos fsicos de hardware del kit de desarrollo, utilizando los IP Cores de Hardware necesarios para el funcionamiento del sistema embebido. Para implementar el diseo embebido se utiliz la herramienta EDK de Xilinx descrita en [10]. El procesador elegido para el diseo 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 tambin implementar
67

Ethernet
RAM de bloque
Power PC 405
I cache D cache
Bus FCB
Componente Acelerador de HW
Servidor de pruebas con: - Servicio DHCP server - Servicio NFS server - Entorno de Desarrollo - Buildroot - Crosscompiladores
HPSoC
PLB
Bus Bridge
OPB
Flujo de consultas <- Consulta DHCP -> Respuesta DHCP con informacin de red y informacin de servidor NFS <- Peticin de montaje a traves de NFS -> Informacion de punto de Montaje
Figura 1. Diagrama en bloques de la arquitectura HPSoC desarrollada
La versin de Linux utilizada es la 2.6.20. Se realizaron modificaciones masivas sobre el cdigo del kernel, utilizando cdigo provisto por el fabricante y modificaciones ad-hoc. Adems, para poder soportar el canal de comunicaciones APU, hubo que habilitar el bit 6 del registro MSR, MachineState Register del procesador PPC. Este registro define el estado de funcionamiento del procesador, y debe ser configurado en tiempo de inicializacin del sistema operativo. En este modo de funcionamiento, el procesador puede utilizar instrucciones vectoriales para transmitir datos a travs del canal de comunicacin de alta performance entre el hardware y el software. C. Desarrollo de la aplicacin del HPSoC Como se mencion, se desarrollaron tres versiones de la aplicacin. Una desarrollada enteramente en software que sirvi como punto de estudio del algoritmo de encriptacin. A partir de este prototipo, se desarrollaron dos versiones de componentes aceleradores. Una versin utilizando la herramienta ImpulseC y otra versin desarrollada en VHDL. A ambas versiones se les aplicaron las mismas optimizaciones descritas a continuacin. 1) Optimizaciones a nivel de sistema: Las optimizaciones a nivel de sistema realizadas sobre la plataforma sern listadas a continuacin. 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 componente acelerador. la frecuencia de trabajo del
d) Se utiliz el mximo nivel de esfuerzo en la sntesis. Esto se logro editando el archivo etc/fast_runtime.opt. Este archivo contiene las opciones de ejecucin de las utilidades de mapeo y ruteo de componentes. Ambas utilidades (map y place) fueron seteadas con la opcin ol a high (lo que indica mximo esfuerzo en la sntesis necesario para obtener un diseo optimizado).
Arbitro
Arbitro
Controlador PHY
Controlador DDR
Controlador UART
Controlador GPIO
Controlador HWICAP
Figura 2. Flujo de consultas para booteo del sistema operativo
e) Se incremento la transferencia de datos para utilizar el mximo ancho de banda provisto por el canal APU. Esto es 64 bits de datos. 2) Optimizaciones a nivel de aplicacin: A nivel de aplicacin 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 drsticamente la performance del mismo a travs del precomputo de datos y de la optimizacin de las operaciones lgicas de permutacin y tablas de bsqueda (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 generacin y precomputo de las subllaves se realiza en forma externa y el cdigo se embebe en la descripcin del hardware. b) Precomputo y combinacin de la tabla de permutacin P con las cajas S: El algoritmo DES provee un mecanismo de expansin de informacin a travs de un conjunto predefinido de bits conocido como cajas S. El algoritmo incluye adems tablas de permutacin bits, conocidas como tabla P, que a fines de performance y teniendo en cuenta ciertas modificaciones en la implementacin del mismo, pueden ser combinadas con tablas S para precomputar futuro procesamiento. Estas cajas combinadas se llaman cajas SP. c) Tabla de expansin E embebida: La tabla de expansin 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 expansin de la tabla E en las operaciones de translacin 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
68
optimizar las formas en que las operaciones se realizan, as como tambin la implementacin de pipelines, desenrollado de bucles y replicacin de datos para favorecer la paralelizacin de operaciones. a) Implementacin de la tcnica de secuencias de permutacin: A modo de implementar las permutaciones inicial y final de bits de forma optimizada, se utiliz la tcnica "secuencias de permutacin" descrita tambin en [9]. Esta tcnica es ampliamente utilizada en diversos algoritmos de cifrado de datos, as como tambin en algoritmos de correccin de errores en la industria. b) Replicacin de datos: Se genero cdigo replicado de entidades de memoria que almacenan los datos de las 8 cajasSP. Esto permiti realizar operaciones de bsqueda en las tablas de forma paralela. El cdigo 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 mayora 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
TABLA I.
RESULTADOS DE IMPLEMENTACION HPSOC CRIPTOGRAFICO HPSoC TripleDES
Implementacin Software Hardware ImpulseC Hardware VHDL
Frecuencia de operacin
Throughput (aplicacin userspace)
Ganancia
300 Mhz 50 Mhz 50 Mhz
42.096 Kbps 17.929 Mbps 19.280 Mbps
1X 415X 458X
TABLA II.
RESULTADOS DE SINTESIS HPSOC CRIPTOGRAFICO HPSoC con componente desarrollado en ImpulseC

Recurso Utilizacin Porcentaje de uso
BUFGs DCM_ADVs ILOGICs External IOBs LOCed IOBs OLOGICs RAMB16s SLICES SLICEMs
11 out of 32 2 out of 4 29 out of 320 73 out of 240 73 out of 73 54 out of 320 26 out of 36 5470 out of 5472 355 out of 2736
34% 50% 9% 30% 100% 16% 72% 99% 12%
Las mtricas obtenidas de la ejecucin del los componentes aceleradores de hardware desarrollados, as como tambin de la versin en software de la aplicacin pueden verse en la tabla I. En esta tabla se muestra que la aceleracin obtenida al implementar parte del algoritmo de la aplicacin en un HPSoC con un componente acelerador es de alrededor de 400X en ambos casos. El throughput expuesto corresponde a la medicin del tiempo de ejecucin de la funcin de SW que enva los datos al componente acelerador. Se muestra adems en la tabla II un extracto del reporte de la sntesis del componente acelerador ms 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 trminos de performance, obtenidos a travs de la implementacin de aceleradores criptogrficos utilizando HPSoCs. Las implementaciones realizadas muestran cmo es posible incrementar la performance de una aplicacin de software corriendo en un sistema embebido en varios rdenes de magnitud. Los resultados comparativos mostraron que luego de aplicar la metodologa propuesta se obtuvo una ganancia de alrededor de 400X en ambos casos. En el presente trabajo se utilizaron adems herramientas del estado del arte en el desarrollo de lgica programable para implementar el sistema embebido y los componentes aceleradores.
Este trabajo concluye que la utilizacin de un HPSoC es una alternativa tcnicamente viable para mejorar la performance de los sistemas digitales embebidos del mundo actual. REFERENCIAS
[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. [1]
69
70
Linux Embebido
71
72
El papel del Hardware copyleft en la Ense nanza de Sistemas Embebidos

Universidad Nacional de Colombia, Email: cicamargoba@unal.edu.co
AbstractEl gran avance de las t ecnicas de fabricaci on de Circuitos Integrados ha permitido que los sistemas embebidos sin darnos cuenta sean parte fundamental de nuestras vidas, aun diariamente interactuamos con decenas de ellos. Esto unido a la disponibilidad de herramientas software de desarrollo gratuitas abre grandes posibilidades comerciales para paises en v a de desarrollo ya que no son necesarias grandes inversiones de capital y fabricaci para la concepci on, diseno, on de estos sistemas. Sin embargo, en la actualidad muy pocas universidades ofrecen cursos que permitan crear las habilidades necesarias para la realizaci on de un producto comercializable, lo que se traduce en un abandono de la producci on local y el aumento de la dependencia con la industria manufacturera asi atica. por otro lado, las herramientas utilizadas en la actualidad (tanto SW como HW) proporcionan un nivel de abstracci on relativamente alto impidiendo que el estudiante entienda el funcionamiento global de un sistema digital, lo que le impide generar habilidades (especicamente las relacionadas con la concepci on e implementaci on) necesarias para realizar el proceso completo. En este art culo se de sistemas presenta una metodolog a para la ensenanza de diseno embebidos utilizando herramientas hardware y software abiertas que ayuda a resolver los problemas mencionados anteriormente. Index TermsSistemas Embebidos, educaci on en ingenier a, hardware copyleft.
Carlos I. Camargo Bare no
I. I NTRODUCCI ON El mercado de los sistemas embebidos contin ua en aumento y su campo de acci on se ha extendido en casi todas las actividades humanas. Seg un BBC, inc. el mercado para el software embebido creci o de $1.6 billones a $3.5 billones en 2009, con una tasa de crecimiento anual (AAGR) del 16%, mientras la tasa de crecimiento para las tarjetas embebidas es del 10%; seg un Venture Development Corporation (VDC) m as de un bill on de dispositivos embebidos fueron vendidos en el 2004,. De acuerdo con VDC el porcentaje de dispositivos basados en sistemas operativos comerciales tiende a disminuir del 43.1% en 2001 a 37.1% en 2004, esta tendencia se debe a la utilizaci on de herramientas de libre distribuci on GNU/Linux [1]. En la actualidad estamos presenciando una tendencia global a delegar las tareas de manufactura de sistemas digitales a paises asi aticos, donde la mano de obra calicada es abundante y barata; se presentan casos donde los creadores de una determinada tecnolog a no la desarrollan y dejan que estos paises se benecien de sus descubrimientos [2] reduciendo de forma considerable la producci on. Esta situaci on se agrava a medida que las grandes empresas manufactureras asi aticas como Foxconn capturan la producci on de los grandes dise nadores
como Apple, Nokia, DELL, HP y Microsoft, lo que genera el cierre de empresas manufactureras a lo largo del mundo, con la consecuencia de p erdida de empleo masivo. En la actualidad seg un Bureau of Labor Statistics y Thomson Financial Extel Company Report Foxconn emplea a m as personas que Apple, Dell, Micorsoft, HP, Intel y Sony combinados; esta situaci on es m as grave en paises en v a de desarrollo, donde no existe la plataforma tecnol ogica para dise nar dispositivos digitales, y son importadores de tecnolog a sin la capacidad de generar productos que satisfagan necesidades locales. Lo anterior lleva a preguntarse por la funci on y la situaci on de un profesional reas anes a la ingenier en a a electr onica en pa ses donde no existe la capacidad de concepci on y dise no. La tendencia moderna en los programas acad emicos a la utilizaci on de herramientas de alto nivel para la ense nanza en areas anes al desarrollo de dispositivos digitales [3] ocasiona que los profesionales no adquieran las habilidades necesarias para completar la cadena concepci on - dise no implementaci on y operaci on, en la mayor a de los casos se generan habilidades para la concepci on y el dise no a alto nivel y dejan los otros pasos en manos de herramientas especializadas y/o a empresas asi aticas. Esta situaci on resulta la m as atractiva desde el punto de vista econ omico, ya que no es necesario adquirir maquinaria costosa ni contratar personal calicado para operarlas; sin embargo, limita la generaci on de empleo local a personas con un nivel de formaci on alto [2] generando desempleo en las personas menos capacitadas. Seg un John Hall presidente y CEO de Linux International algunas facultades preparan a la gente en el uso de productos en vez de tecnolog as de nivel b asico [3]. Esta situaci on unida al abandono de la implementaci on hace que la dependencia con las empresas manufactureras asi aticas aumente cada vez m as. Seg un el ex-director ejecutivo de Intel Andy Grove [2] la soluci on est a en hacer de la creaci on de empleo la pol tica econ omica gubernamental m as importante y hacer que las dem as giren en torno a ella. Adem as, es necesario volver a la producci on interna con el f n de generar nuevos empleos, y volver a adoptar medidas que protejan la producci on interna de los productos asi aticos. Sin embargo, para lograrlo es necesario crear en los profesionales las habilidades para implementar productos comercializables. En este art culo presentamos un programa acad emico basado en la utilizaci on de software y hardware libre para el rea de electr a onica digital que desarrolla las habilidades nece-
73
sarias para Concebir, Dise nar Implementar y operar sistemas digitales. A. Flujo de dise no de sistemas embebidos Los Sistemas Embebidos son sistemas heterog eneos que contienen componentes Software (microcontroladore, microprocesadores y DSPs) y Hardware (funciones implementadas en Dispositivos l ogicos programables PLDs); por este motivo, es necesario adquirir habilidades en la utilizaci on de lenguajes de programaci on como C o C++ para implementar las funciones software y Verilog o VHDL para la implementaci on de las tareas hardware; adicionalmente, deben conocer las diferentes formas de comunicaci on entre estos dos tipos de funciones. Aunque en el mercado existen herramientas que permiten la entrada de dise no utilizando lenguajes de alto nivel como SystemC o SpecC y proporcionan el c odigo para implementar las tareas software, hardware y su interfaz de comunicaci on; no es recomendable utilizarlas en el ciclo de formaci on b asico ya que impide que se conozca el ujo de dise no completo, suministrando un nivel de abstracci on en el cual no es necesario conocer la arquitectura de la plataforma utilizada para la implementaci on. En la gura 1 se muestran los conceptos que deben dominar los dise nadores de sistemas embebidos, y las tareas que deben realizarse para la concepci on, dise no e implementaci on de un sistema embebido. En gran parte de los programas nicamente los temas relacionados con acad emicos se estudian u la concepci on y dise no centr andose en las especicaciones funcionales del sistema, utilizando herramientas comerciales o COTS (Commercial off-the-shelf) para su implementaci on. Esta combinaci on genera dependencia e impide la generaci on de habilidades necesarias para implementar un sistema digital teniendo en cuenta restricciones econ omicas, f sicas, el ectricas, ergon omicas, comerciales, etc. Nuestra propuesta se basa en la utilizaci on de herramientas abiertas tanto hardware como software que permiten recorrer todo el proceso de concepci on, dise no e implementaci on y obtener un entendimiento integral del proceso sin generar dependencia a productos comerciales. 1) Dominios de Dise no y Niveles de abstracci on: Existen tres dominios en los que se puede describir un sistema digital [5] Funcional: Describe el comportamiento funcional y temporal del sistema Estructural: Describe su composici on a partir de bloques b asicos y F sico relacionado con la estructura f sica del sistema a nivel de circuito integrado o placa de circuito impreso [6]. Cada uno de estos dominios puede ser descrito utilizando diferentes niveles de abstracci on; un nivel de abstracci on alto permite el uso de lenguajes de alto nivel facilitando la entrada de dise no al extraer la funcionalidad de la parte f sica; por otro lado, los niveles de abstracci on bajo utilizan bloques constructores elementales. En el mercado existen herramientas que permiten entradas de dise no a nivel funcional utilizando especicaciones y algor tmos y de forma autom atica y optimizada generan representaciones en diferentes niveles de abstracci on en los dominios estructural y f sico. Es decir, a partir de las especicaciones
Fig. 1.
Educaci on de sistemas embebidos. Tomada de: [4] y modicada
y algoritmos que indican el funcionamiento del sistema pueden generar archivos para la fabricaci on de un circuito integrado o archivos de conguraci on/programaci on que pueden ser utilizados en dispositivos comerciales. Desde el punto de vista til ya que permite reducir el tiempo comercial esto es muy u de dise no y los costos asociados. Sin embargo, presentan los inconvenientes mencionados anteriormente y por lo general son muy costosas. TODO PARA LA ENSE NANZA II. M E DE S ISTEMAS E MBEBIDOS Bas andose en la metodolog a de dise no para sistemas embebidos [7], en los dominios de dise no y niveles de abstracci on de Gajski-Kuhn, se realiz o una divisi on de temas que busca crear habilidades de forma gradual e incremental. En la Figura 4 podemos observar esta divisi on y las herramientas que se utilizar an en cada curso, como herramienta de desarrollo hardware se utilizar a una plataforma que proporcione los archivos y documentos necesarios para replicarla, modicarla y pueda ser utilizada como base de desarrollos comerciales. A. SIE: Plataforma abierta para el desarrollo de sistemas embebidos En el mercado existe una gran variedad de plataformas que pueden ser utilizadas en el estudio de sistemas embebidos, sin embargo, no todas son adecuadas para la implementaci on del m etodo que proponemos ya que se requiere: acceso a los esquem aticos y a los archivos de fabricaci on del PCB con posibilidad de modicaci on; acceso a la documentaci on completa del proceso de fabricaci on; acceso a la cadena de producci on; utilizaci on de herramientas abiertas para su programaci on; un PLD para la implementaci on de tareas HW; un procesador para la implementaci on de tareas SW; un canal de comunicaci on entre el procesador y el PLD; y una comunidad que desarrolle aplicaciones para dicha plataforma y que proporcione medios
74
para el intercambio de informaci on a trav es de listas de correo y wikis. Despu es de una b usqueda minuciosa no se encontraron plataformas que cumplieran con estas condiciones, en especial con las relacionadas con el proceso de dise no y de producci on, esto es normal, ya que la mayor a de las empresas no quieren que se fabriquen sus plataformas y los proyectos individuales no poseen la infraestructura necesaria para la producci on masiva. Por este motivo, se decidi o crear una plataforma que cumpliera con los requerimientos (plataforma SIE), para ello se buscaron proyectos similares que permitieran su creaci on y que el producto creado sea una extensi on de dicho proyecto. El proyecto Qi-Hardware [8] busca denir el concepto copyleft hardware bas andose en el movimiento de software libre y c odigo abierto (FOSS [9]) y proporciona un enlace con la industria manufacturera asi atica. 1) Hardware copyleft: El proyecto SIE [10] fu e creado para satisfacer las necesidades de los desarrolladores de hardware permitiendo la creaci on de aplicaciones comerciales bajo la licencia Creative Commons BY - SA [11] la que permite la distribuci on y modicaci on del dise no (incluso para nico requisito de que los aplicaciones comerciales), con el u productos derivados deben tener la misma licencia y deben dar cr edito al autor del trabajo original. Lo que constituye la base de los productos hardware copyleft. Al ser inspirado en el movimiento FOSS, los dispositivos hardware copyleft comparten la misma losof a [9], y son el complemento perfecto del software libre. Para que un dispositivo HW sea reproducible y modicable es necesario: suministrar los archivos necesarios para la fabricaci on, es decir, los esquem aticos y los archivos de la placa de circuito impreso (preferiblemente para herramientas abiertas como Kicad o geda); la cadena de herramientas de compilaci on y depuraci on para desarrollo de aplicaciones; el c odigo fuente de: el programa que inicializa la plataforma (bootloader), la herramienta que carga dicho programa en la memoria no vol atil (usbboot), el sistema de archivos y aplicaciones (openwrt); documentaci on completa que indique como fu e dise nada, construida, como utilizarla, desarrollar aplicaciones y tutoriales que expliquen el funcionamiento de los diferentes componentes. (esto puede ser descargado de [12] y [13]). Adicionalmente, se debe contar con la posibilidad de fabricaci on y montaje, lo que constituye la principal diferencia entre el software y el hardware libre. 2) Arquitectura: La Figura 2 muestra el diagrama de bloques de la plataforma SIE, en ella encontramos un procesador que posee perif ericos para comunicaci on serial (UART), memorias micro-SD, un puerto I2C, controlar un LCD a color de 3 pulgadas, 2 entradas y salidas de audio stereo, 2 entradas an alogas; una FPGA que proporciona 25 se nales de entrada/salida digitales de prop osito general (GPIOs) y controla un conversor an alogo digital de 8 canales. Existen tres canales de comunicaci on entre la FPGA y el procesador: uno para controlar el puerto JTAG, lo que permite la conguraci on de la FPGA desde el procesador (eliminando la necesidad de cables de programaci on); otro que proporciona el bus de
datos, direcci on y control para comunicarse con las tareas HW o perif ericos implementadas en la FPGA y un puerto serial utilizado para depuraci on de softcores implementados en la FPGA. El procesador utilizado es un Ingenic JZ4725 (MIPS) corriendo a 400MHz, se dispone de una memoria NAND de 2GB para almacenamiento de datos y programas, as como de una memoria SDRAM de 32 MB, lo que permite la ejecuci on de una gran variedad de aplicaciones Linux.
Fig. 2.
Estructura de la plataforma de desarrollo SIE
3) Comunicaciones: SIE proporciona un canal de comunicaci on y alimentaci on a trav es del puerto USB-device, y es congurado para ser utilizado como una interfaz de red (usb0), permitiendo la transferencia de archivos y ejecuci on de una consola remota utilizando el protocolo ssh; este canal de comunicaci on tambi en se utiliza para programar la memoria NAND no vol atil, por lo que para realizar la programaci on completa de los componentes de la plataforma solo es necesario un cable USB. 4) Especicaciones f sicas: Las dimensiones de SIE son 8cm de largo, 8 cm de ancho, 1cm de altura; su placa de circuito impreso es de dos capas, utiliza l neas de 8 mils, v as de 12 mils de di ametro, los componentes se encuentran en una sola capa y son TQFP o SMD, no posee componentes BGA o QFN lo que facilita el montaje manual. Todo esto hace que sea posible la reproducci on y modicaci on de esta plataforma a un precio muy bajo. El costo de fabricaci on de esta tarjeta se estima en 70 usd para 50 unidades. La gura 3 muestra la apariencia de la plataforma de desarrollo SIE. B. Curso b asico Para el curso b asico se trabajar a la mayor parte de los niveles de abstracci on del dominio funcional; partiendo de unas especicaciones funcionales se generar a un modelo del sistema utilizando algoritmos que describan el comportamiento de las diferentes tareas que implementan el sistema (bloques funcionales). Estos bloques ser an implementados, en dispositivos l ogicos programables como FPGAs o CPLDs. A partir de estos algoritmos se identican las operaciones b asicas aritm eticas y l ogicas que modican los datos asociados a cada funci on para generar el camino de datos (datapath;
75
Fig. 3.
Plataforma de desarrollo SIE
tener en cuenta para su correcto funcionamiento; afectando la generaci on de habilidades necesarias para la elecci on de componentes, realizaci on y lectura de esquem aticos y dise no de layouts. El procesador de la plataforma SIE ser a utilizado como camino de conguraci on de la FPGA; el archivo de conguraci on ser a descargado al sistema de archivos de la plataforma SIE utilizando el protocolo ssh y la interfaz de red USB; un programa en espacio de usuario se encarga de congurar la FPGA con el archivo deseado. Adicionalmente, existe una aplicaci on basada en el proyecto urjtag ejecut andose en el procesador que permite la generaci on de vectores de prueba y recolecci on de resultados utilizando el puerto JTAG [14], lo que permite que el estudiante pueda probar su circuito a baja frecuencia sin instrumentos de medici on adicionales. C. Arquitectura de Computadores En este curso se trabajar a en el dominio estructural comenzando desde los componentes b asicos de una CPU hasta llegar a la arquitectura de un sistema sobre silicio (SoC), esto con el f n de conocer y entender la arquitectura y funcionamiento de los dispositivos en los que se ejecutan las tareas software. Se utililizar an perif ericos conectados a trav es de buses a la CPU para implementar tareas hardware. Se realizar a la implementaci on de un Sistema sobre silicio (SoC) y se trabajar a con herramientas de libre distribuci on (cadena de herramientas GNU [1]) para programar aplicaciones que involucren el uso de tareas HW y SW. 1) Arquitectura de una CPU y tareas SW: Utilizando procesadores softcore se estudiar an los componentes b asicos de la CPU, el camino de datos: banco de registros, bloques aritm eticos, l ogicos y buses internos, se analizar an las diferentes instrucciones que proporciona la arquitectura bajo estudio y se analizar a el funcionamiento de la m aquina de control, identicando los componentes que permiten el almacenamiento y ejecuci on secuencial de instrucciones denidas por el usuario. En este punto se introducir an los conceptos de llamado a funciones, atenci on de interrupciones, direccionamiento directo e indirecto y acceso a memoria externa. Para este estudio, se utilizar an procesadores implementados en lenguajes de descripci on de hardware que cuenten con herramientas de programaci on de bajo (assembler) y alto nivel (C, C++), con el n de realizar simulaciones, aplicaciones y modicaciones. Al nalizar el curso se pretende que el estudiante entendienda las diferencias entre tareas software y tareas hardware y podr a realizar experimentos que le permitan comparar las caracter sticas de ambas implementaciones. En la actualidad se est a trabajando con los SoC plasma basado en un procesador MIPS, MICO 32 de lattice, y openrisc de OpenCores, implementados en VHDL o Verilog. Se utilizar an los perif ericos para la implementaci on de tareas HW y se estudiaran las diferentes formas que existen para comunicarse con las tareas SW (buses, interrupciones, polling) presentando los criterios de selecci on para la implementaci on de tareas SW y HW. Se introducir a el concepto de mapa de memoria, decodicador de direcciones, memorias vol atiles
el datapath proporciona se nales que controlan el instante en el que se ejecutan la operaci ones soportadas, dichas se nales deben ser generadas por un m odulo dise nado para implementar el algoritmo deseado; estos dos m odulos se implementaran con bloques l ogicos b asicos y m aquinas de estados nitos utilizando lenguaje de descripci on de hardware (VHDl, verilog est andard). Estas descripciones son la entrada a herramientas que realizar an la transici on al dominio estructural generando las compuertas l ogicas, ip-Flops y las interconexiones que implementen la funcionalidad requerida. Durante el proceso es necesario realizar simulaciones (utilizando icarus verilog y ghdl) que permitan comprobar el cumplimiento de las especicaciones iniciales, si no se cumple alguna de ellas se debe volver a repetir el proceso. Durante el desarrollo del primer curso se estudiaran los conceptos b asicos de los sistemas digitales como sistemas num ericos, operaciones aritm eticas y l ogicas, l ogica combinatoria y secuencial. Se utilizaran lenguajes de descripci on de hardware como VHDL y verilog como entrada de dise no a herramientas que realizan la s ntesis digital. Para evitar crear dependencia, se ense nar a la forma de adecuada de implementar c odigo re-utilizable que no utilice componentes espec cos de un determinado fabricante. 1) Dise no de aplicaciones utilizando HDL y PLDs: Para generar las habilidades necesarias para concebir, dise nar, implementar y operar sistemas digitales, se realizar an pr acticas sencillas que ayuden al estudiante a entender los mecanismos de implementaci on de tareas HW en un dispositivo l ogico programable utilizando la plataforma de desarrollo SIE; como puede verse en la gura 2 la FPGA solo controla un conversor an alogo digital serial de 8 canales, y proporciona 25 GPIOs, esto se hizo de forma intencional para que los estudiantes se vean forzados a realizar las conexiones el ectricas de los dispositivos externos a sus aplicaciones; las plataformas comerciales proporcionan una gran variedad de dispositivos conectados a los PLDs, lo que no es muy recomendable ya que el estudiante no aprende a leer la hoja de especicaciones del fabricante de un determinado dispositivo para determinar su forma de conexi on, y/o las condiciones que se deben
76
(ejecuci on de programas y de uso general) y memorias no vol atiles (almacenamiento de programas). Se introducir a el concepto de bootloader y su uso en la carga de aplicaciones a las memorias vol atiles internas y externas del SoC. Y nalmente se mostraran los diferentes m etodos existentes para programar las memorias no vol atiles. Utilizando la cadena de herramientas GNU, se realizar a el ujo de desarrollo para tareas SW desde la entrada de dise no utilizando el lenguaje C, hasta la generaci on del archivo binario que contiene las instrucciones (para la CPU en estudio) que implementan dicha tarea. Utilizando herramientas propias se generar an los archivos para inicializar la memoria de programa (implementada en la FPGA) con estas instrucciones. 2) Dise no de aplicaciones que involucren co-dise no HWSW: Tanto la CPU, los perif ericos, la memoria ram y la memoria de programa estar an implementados en la FPGA de SIE. Durante todo el periodo acad emico se desarrollar a un proyecto de complejidad media que involucre el uso de tareas HW y SW, (en la p agina de la plataforma [13] se pueden observar los proyectos realizados hasta el momento); para esto se formar an equipos de trabajo de 3 personas que deben hacer una propuesta inicial (concepci on y especicaciones), realizar la descripci on funcional del sistema utilizando algoritmos (dise no y modelo del sistema), realizar el particionamiento en funciones HW y SW, implementar estas funciones y dise nar una placa de circuito impreso (utilizando kicad) con lo necesario para implementar la funcionalidad requerida (implementaci on). Se realizar an entregas peri odicas para vericar el cumplimiento del cronograma propuesto por el equipo de trabajo y el proceso de dise no debe ser documentado en la p agina wiki del curso. Esta actividad generar a habilidades de trabajo en equipo, elaboraci on de esquem aticos, fabricaci on de PCBs, escritura de documentos t ecnicos e implementaci on de sistemas digitales. SIE permite conectar de forma f acil (usando dos jumpers) dos GPIOs de la FPGA a las se nales de transmisi on y recepci on del procesador, lo que permite la comunicaci on serial entre el procesador implementado en la FPGA y el procesador MIPS, creando de esta forma un canal de depuraci on para las aplicaciones implementadas en la FPGA, eliminando la necesidad de equipo adicional. D. Sistemas Embebidos ltimo curso de la l El tercer y u nea integra los conocimientos adquiridos en los cursos anteriores e introduce un elemento nuevo un SoC comercial, SIE posee un SoC basado en un procesador MIPS equipado con los recursos necesarios para ejecutar programas Linux; en este curso se estudiar a la arquitectura de los SoC comerciales, las herramientas de programaci on abiertas disponibles (cadena de herramientas GNU, librer as GNU como libQT), cargadores de Linux (u-boot), el sistema operativo Linux, drivers de perif ericos, distribuci ones para sistemas embebidos (openwrt, openembedded, debian). Con esto el estudiante estar a en capacidad de crear aplicaciones que utilizan la gran variedad de librer as disponibles en
Fig. 4.
rea de Sistemas Digitales Metodolog a de Dise no para el a
el proyecto FOSS, las mismas que utilizan Nokia, Motorola, Dell, Sony. 1) Creaci on de perif ericos y drivers : Adem as de cubrir el tema de programaci on de SoC utilizando GNU/Linux, es necesario que se entienda no solo el funcionamiento del sistema operativo Linux, sino como este se comunica y controla los perif ericos (tareas HW); para esto, se implementar an perif ericos en la FPGA y se estudiar a la forma de acceder a ellos utilizando el protocolo establecido por el kernel. 2) Concepci on, Dise no, Implementaci on y Operaci on de Sistemas Embebidos: Durante el periodo acad emico los estudiantes deben dise nar, implementar y operar un sistema embebido concebido por un equipo de trabajo de tres personas, utilizando como base la plataforma SIE, dise nar an una tarjeta hija (utilizando kicad) que implemente la funcionalidad deseada, todos los proyectos deben integrar tareas HW en la FPGA con m odulos del kernel para su control. Los proyectos realizados hasta el momento pueden encontrarse en la p agina del proyecto. E. Comunidad hardware copyleft Una parte importante de este m etodo de ense nanza es la losof a del proyecto hardware copyleft, por esta raz on, cada grupo debe hacer un aporte, suministrando la informaci on completa del proceso de desarrollo, los archivos necesarios para replicar y/o modicarlo, esto es una consecuencia de la licencia CC-BY-SA.
77
La experiencia del proyecto FOSS indica muchos miembros de estas comunidades ingresan para suplir necesidades, pero muchos de ellos continuan creando c odigo y prestando servicios a la comunidad porque disfrutan programar. Estos acionados realizan un papel muy importante dentro de la comunidad encarg andose de tareas como mejora de la plataforma tecnol ogica, re-escribiendo secciones de c odigo, documentandolo, respondiendo preguntas, preservando o mejorando la arquitectura [15]. Las actividades de documentaci on adem as de contribuir a mejorar las habilidades de escritura de reportes t ecnicos ayudan a formar una comunidad que contribuye al crecimiento del proyecto copylef harware, los estudiantes ingresan a las listas de desarrolladores aprendiendo a utilizar una herramienta muy poderosa en la que pueden compartir sus inquietudes con miembros m as experimentados y mientras participan ayudan a crear un banco de preguntas que pueden tiles para futuros miembros. Adicionalmente se obliga a ser u expresarse en un idioma diferente. Crear estos h abitos ayuda a que los j ovenes sean conscientes de su papel dentro de la comunidad y piensen que sus acciones pueden ayudarla o perjudicarla, los proyectos realizados por ellos podr an ser parte de los recursos de la comunidad (si la calidad del trabajo lo amerita) y pueden ser la continuaci on de un esfuerzo prolongado o el punto de partida de un nuevo conocimiento; la licencia CC-BY-SA garantiza que todos los trabajos derivados de este recurso ser an parte del mismo, lo que garantiza su crecimiento, la labor de los estudiantes es vital para el uso del recurso com un y puede crear miembros que en un futuro formular an pol ticas y reglas de uso del recurso. Por otro lado, participar en este tipo de proyectos permite crear til para establecer relaciones reputaci on, la cual puede ser u profesionales, de negocios o personales. El entorno acad emico es ideal para atraer nuevos miembros a la comunidad hardware copyleft, ya que se trabaja con j ovenes con deseos de ser parte de un grupo y de adquirir conocimientos. Desde el punto de vista comercial este recurso es muy atractivo ya que permite ahorrar mucho tiempo, esfuerzo y dinero para la creaci on de nuevos productos. Por otro lado, el concepto de hardware copyleft es una herramienta poderosa para transferir tecnolog a y conocimientos a los pa ses en v a de desarrollo donde la plataforma tecnol ogica no se lo sucientemente desarrollada. III. C ONCLUSIONES El hardware copyleft es una herramienta poderosa para la creaci on de habilidades necesarias para concebir, dise nar, implementar y operar sistemas digitales, ya que proporciona la informaci on necesaria para entender el ciclo completo de dise no, (lo cual no es posible obtener cuando se trabaja con plataformas de desarrollo comerciales); proporcionando informaci on detallada sobre el proceso de dise no de plataformas abiertas, que pueden ser utilizadas como referencia para generar nuevos productos comerciales; el acceso a aplicaciones software que permiten la creaci on de aplicaciones; un canal de comunicaci on que permite utilizar a la industria manufacturera asi atica para la producci on en masa; conocimiento de los procesos de fabricaci on y producci on.
rea Las actividades propuestas en las tres asignaturas del a tienen como objetivo generar en el estudiante las habilidades necesarias que le permitan dise nar sistemas digitales con grado de complejidad creciente, hasta llegar a un sistema que puede ser comercializable y satisface una necesidad de una ltimo paso determinada comunidad, con esto, se evita que el u en el proceso de ense nanza sea la simulaci on; se ilustra el proceso que debe seguirse para que un prototipo se convierta en un producto comercial, lo que contribuir a con la creaci on de nuevos productos y la generaci on de empleo. La utilizaci on de herramientas de bajo nivel permite que el estudiante conozca y controle los diferentes pasos de la metodolog a de dise no y sea capaz de ajustarlas para diferentes situaciones, esto hace que se adquiera un conocimiento sobre la tecnolog a sin crear dependencia hacia las herramientas comerciales que realizan la mayor a de los pasos de la metodolog a de forma autom atica. R EFERENCES
[1] R. M. Stallman. The GNU Operating System and the Free Software Movement Voices from the Open Source Revolution. OReilly and Associates, 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 FUTURO DE SU NEGOCIO. Linux magazine,, ISSN 1576-4079(58):92, 2009. [4] H. Mitsui, H. Kambe, and H. Koizumi. Use of Student Experiments for Teaching Embedded Software Development Including HW/SW CoDesign. 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 Report CECS-02-17. Technical report, CECS, UC Irvine, 2002. [6] Gajski D.D., Abdi S., Gerstlauer A., and Schirner G. Embedded System Design: Modeling, Synthesis, Verication. Springer, 2009. [7] Luis Alejandro Cort es. Verication and Scheduling Techniques for RealTime Embedded Systems. PhD thesis, Link opings universitet Institute of Technology, 2005. [8] Qi Hardware. Qi Hardware Copyleft Hardware Project. URL: http://en.qi-hardware.com/. [9] R. Stallman. Philosophy of the GNU project. URL: http://www.gnu.org/philosophy/, 2007. [10] W. Spraul, C. Camargo, and A. Wang. Proyecto SAKC. URL:http://en.qi-hardware.com/wiki/SAKC. [11] Creative Commons. Licencias Creative Commons. URL: http://creativecommons.org/licenses., 2004. [12] C. Camargo. Proyecto SIE: Descargas. http://projects.qihardware.com/index.php/p/nn-usb-fpga/source/tree/master/, 2010. [13] C. Camargo. Proyecto SIE: Documentaci on. http://en.qihardware.com/wiki/SAKC, 2010. [14] Texas Instruments. IEEE Std 1149.1 (JTAG) Testability. 1997 Semiconductor Group, 1996. [15] S. Shah. Motivation, Governance, and the Viality of Hybrid Forms in Open Source Software Development. Management Science, July 2006.
78
Desarrollo de un equipo para grabar los sonidos de los bovinos a la intemperie

Facultad de Ingeniera, Universidad de la Repblica Montevideo, Uruguay santiagoreyesgonzalez@gmail.com, valeoli@gmail.com, cecisr@gmail.com, jpo@ng.edu.uy
ResumenEn este trabajo se presenta un dispositivo capaz de grabar y almacenar el sonido que emiten los bovinos durante la masticacin e ingesta de forraje. Este dispositivo, junto con un software capaz de detectar las actividades realizadas por el animal (pastoreo, rumia y descanso) a partir de las seales de audio obtenidas, forma parte del prototipo Monitoreo del Sonido Bovino (MOSOBO). A partir de estos datos es posible determinar en qu momento del da y durante cunto tiempo el animal realiz alguna actividad, lo que permite estudiar el comportamiento ingestivo de los rumiantes. El dispositivo tiene una autonoma energtica de ms de 24 horas, graba y almacena audio de alta calidad, no afecta el comportamiento del animal, es de fcil colocacin, bajo costo, estable y robusto. Debido a la buena calidad del audio adquirido y al procesamiento realizado a la seales de audio se lograron excelentes resultados al reconocer las diferentes actividades que el animal realiza (pastoreo, rumia y descanso). Index TermsSBC, Linux embebido
S. Reyes, V. Olivera, M. C. San Romn y J. P. Oliver
Con respecto al software el requisito principal fue el de ser capaz de identicar 3 actividades bien diferenciadas (pastoreo, rumia y descanso), en qu momento son realizadas y la duracin de las mismas. Este trabajo se bas en las conclusiones de algunas investigaciones sobre el comportamiento de los rumiantes y los sonidos que los mismos emiten en las distintas etapas de la digestin[3]. En las siguientes secciones se describen los componentes seleccionados para realizar el dispositivo y como se implement el software del sistema embebido. Finalmente se mencionan las conclusiones y perspectivas de este trabajo. II. H ARDWARE Para poder determinar los requerimientos de frecuencia de muestreo y cantidad de bits del dispositivo de grabacin fue necesario conocer qu caractersticas tenan los sonidos emitidos por los bovinos. De la buena eleccin de estos requerimientos dependa el xito del software de anlisis y reconocimiento. Por est razn, primero se realizaron varios ensayos para obtener seales de audio de los sonidos emitidos por los bovinos. Luego de procesar dichas seales, se determinaron los requerimientos del dispositivo y se seleccionaron los componentes. Ensayos preliminares Para obtener las seales de audio, se seleccionaron varios componentes con distintas caractersticas y se realizaron varios ensayos en 2 vacas distintas (Ver Figura 1). Procesamiento digital de las seales Para analizar las seales obtenidas a partir de los ensayos, se utiliz el software Wavesurfer. Con el mismo se observaron y obtuvieron los segmentos de las seales que aportaron informacin til. En la Figura 2(a) y en la Figura 2(b) se pueden observar algunas secuencias representativas de las actividades de rumia y pastoreo respectivamente. La Figura 2(a) no brinda informacin sobre la frecuencia mnima de muestreo, pues se obtuvo con un reproductor mp3 el cual muestrea a 8 kHz. Sin embargo, se puede notar fcilmente que la seal presenta un patrn rtmico. En la Figura 2(b) se pueden identicar componentes de seal de inters de hasta 6 kHz. Esta seal a diferencia de
I.
I NTRODUCCIN
El objetivo de este trabajo fue desarrollar a nivel de prototipo un dispositivo capaz de grabar el sonido que realizan los bovinos durante la masticacin e ingesta de forraje, junto con un paquete de software que corre en un PC, capaz de determinar y desplegar qu actividades realiz el animal (pastoreo, rumia o descanso), en qu orden y la duracin de las mismas. El comportamiento animal en pastoreo es resultado de factores abiticos (distancia al agua, la temperatura, la luz, el pH, el suelo, nutrientes, pendiente) y factores biticos (cantidad y calidad del forraje por animal, estado siolgico y metablico del animal)[1]. Justamente la cantidad de forraje consumida por el animal depende del tiempo de pastoreo y su tasa de consumo[2]. Existen situaciones en las que el consumo de energa del animal no se modica pero su productividad se ve modicada como consecuencia de tener diferente comportamiento ingestivo. La medicin del comportamiento y del consumo de energa contribuira a explicar gran parte de los resultados en productividad animal a nivel experimental y comercial. Los requisitos principales del dispositivo consistieron en que el sistema fuera robusto (ya que se utiliza a la intemperie junto con el animal), que tuviera autonoma energtica por ms de 24 horas, fuera econmico, de fcil colocacin y bajo peso, y que fuera inofensivo y no modicara el comportamiento de los animales.
79
(a)
(b)
(c)
Figura 1. Ensayos realizados para adquirir las seales a analizar
(a) Seal de audio emitida por un bovino durante la rumia.
(b) Seal de audio emitida por un bovino durante el pastoreo. Figura 2. Selaes obtenidas a partir de los ensayos.
rumia1 . En base a este artculo y a las caractersticas presentes en las seales observadas durante el procesamiento digital de las mismas se decidi que el dispositivo de grabacin deba muestrear al menos a 22 kHz y tener una resolucin de al menos 12 bits. Teniendo en cuenta que el dispositivo deba ser capaz de grabar el sonido emitido por los rumiantes durante 24 horas, al obtener las seales a 22 kHz, 12 bits, fue necesario contar con una memoria no voltil de al menos 3,5 GB. Era indispensable que el dispositivo permaneciera en el animal durante 1 da sin interrupcin, por lo que la batera deba ser capaz de alimentar el dispositivo durante este tiempo. Adems debe tener un factor de forma aceptable y ser liviana. Teniendo en cuenta el presupuesto con el que contaba el proyecto y la relacin entre la capacidad de las bateras y su peso, concluimos que la placa deba consumir menos de 1,5 W. Uno de los objetivos del proyecto fue determinar en qu momento del da el animal realiz cada actividad, por lo que era necesario incluir un reloj de tiempo real. Una de las caractersticas deseables del dispositivo era la capacidad de interactuar con el usuario, para lo cual se decidi utilizar LEDs y botones. Del anlisis de los distintos requerimientos del sistema se lleg a la siguiente especicacin: Muestreo a 22 kHz, al menos 12 bits. Memoria no voltil 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. Eleccin de los componentes Se analizaron varias opciones para desarrollar el dispositivo. La primera opcin fue la de basar nuestro desarrollo utilizando grabadoras digitales de audio, reproductores de mp3, mp4 o celulares capaces de adquirir audio; pero se descart dado que ninguno cumpla los requerimientos mnimos en frecuencia de grabacin y/o cantidad de bits, y costo. Luego se consider la opcin de desarrollar a medida placas con microcontroladores y ADCs o tarjetas de audio (o utilizar
1 El mtodo propuesto puede ser utilizado indistintamente en bovinos y ovinos ya que desde el punto de vista del comportamiento ingestivo son considerados iguales.
la anterior, fue obtenida con un micrfono de PC y una computadora.
Determinacin de los requerimientos El artculo Computational method for segmentation and classication of ingestive sounds in sheep[4] propone un mtodo novedoso para anlizar y reconocer automaticamente seales sonoras emitidas por ovinos al realizar pastoreo y
80
algn kit de desarrollo existente). Esta opcin si bien presenta ventajas en cuanto a consumo y costos, implicaba un riesgo para cumplir los plazos del proyecto y debido a que haba que tomar la denicin en una etapa temprana del mismo en la cual todava no se tenan claros todos los requerimientos se decidi utilizar un sistema con mayores recursos y exibilidad. Por las razones antes mencionadas nalmente se decidi utilizar una Single Board Computers que incluyera un sistema operativo para acortar tiempos de desarrollo y una tarjeta de sonido o ADC externo que cumpliera los requerimientos. Esta solucin permitira tener mayor exibilidad y velocidad de desarrollo de las aplicaciones, y soportar futuras ampliaciones del equipo como son transmitir los datos mediante Wi-Fi facilitando la descarga de datos del dispositivo o aadir un GPS que permitira relacionar las actividades realizadas por el animal y la ubicacion geogrca del mismo. SBC, tarjeta de sonido y unidades de almacenamiento: Luego de evaluar las placas de la Tabla I y comprobar si cumplan los requerimientos estipulados (con pequeos agregados), concluimos que la placa TS-7260 de Technologic System era la mejor opcin. Adems se decidi utilizar la tarjeta de sonido USB 3D Sound modelo HY554 por cumplir con los requerimientos de frecuencia de grabacin y cantidad de bits y ser de bajo costo. TS-7260: Tiene instalado de fbrica el ncleo 2.4.26 de GNU/Linux, y est optimizado para la arquitectura de la misma y su consumo mximo se encuentra en el orden de 1 W (sin el uso de perifricos y a mxima frecuencia). Por defecto la TS-7260 trae instalada la aplicacin BusyBox[9]; pero la utilizacin de la misma fue descartada debido a distintas limitaciones 2 . Se decidi instalar una distribucin GNU/Linux Debian Sarge 3.1 debido a su compatibilidad con nuestra arquitectura y ser un sistema sumamente estable. USB 3D Sound modelo HY554: Inicialmente se haba decidido grabar a 22 kHz pero la tarjeta de sonido seleccionada muestrea nicamente a 48 kHz; por lo que nalmente la grabacin de audio se realiza con frecuencia de muestreo de 48 kHz. Unidades de almacenamiento: Para poder almacenar 24 hs a 48 kHz, 16 bits, se necesita una unidad de almacenamiento de al menos 7 GB. Se intent grabar audio y decimar los archivos ya grabados, simultneamente en la placa pero los mismos resultaban corruptos. Tampoco fue posible utilizar algoritmos de compresin de audio con prdida de informacin porque no cumplamos con los requsitos mnimos de 22 kHz, 12 bits. La distribucin GNU/Linux Debian Sarge 3.1 ocupa alrededor de 512 MB por lo que se necesita una unidad externa de almacenamiento dado que la memoria interna de la TS-7260 no es suciente. Finalmente se decidi almacenar los datos en un pendrive de 8 GB e iniciar el sistema desde una memoria SD card de 2 GB.
2 Con la aplicacin BusyBox no es posible manejar mdulos de audio, interfaz de red y almacenamiento.
Batera: Para determinar la capacidad de la batera a utilizar se relev el consumo de la placa en las posibles situaciones de funcionamiento (ver Tabla II): inicio del sistema operativo, estado de espera3 o grabando y almacenando.
Tabla II C ONSUMO DEL SISTEMA EMBEBIDO AL SER ALIMENTADO POR UNA FUENTE DE 5 V. Actividad Inicio del sistema Estado de espera Grabando y almacenando Consumo (mA) 300 mx 220 240 Potencia (W) 1,5 1,1 1,2
Eligiendo el peor caso (inicio del sistema), el consumo fue de 1,5 W, lo cual nos llev a consumir 36 Wh en un da. Teniendo en cuenta la potencia que deba suministrar, el rango de alimentacin de la SBC4 , factor de forma aceptable, el costo y la relacin entre su peso y la capacidad; se decidi utilizar en el primer prototipo 2 bateras de gel (modelo RB632C) de 6 V y 3200 mAh. Usando ambas bateras se lleg a una capacidad de 38,4 Wh, cumpliendo los requerimientos planteados anteriormente. Las bateras seleccionadas pesan 1200 g y tienen un factor de forma aceptable: 32 x 96 x 60 mm. Para el diseo nal se utilizar un pack de 5 bateras de litio-ion de 2800 mAh y 3.7 V (modelo GTL), con lo cual el peso de las bateras bajara signicativamente quedando en aproximadamente 200 g. Micrfono: Se decidi utilizar el micrfono Ht-101 de la marca Xtreme que se encontraba en el mercado local a un precio accesible, ancho de banda: 100-16000 Hz, impedancia: 2.2 k , sensibilidad: -55db 3db y era omni direccional. Placa de interfaz de usuario y control de energa: Para poder mantener una comunicacin con el usuario se dise una placa interfaz de usuario y control de energa. La misma cuenta con tres botones con las siguientes funcionalidades: encendido, apagado y grabacin. Uno de los problemas que se present al apagar la placa es que la misma sigue tomando corriente luego de que el sistema operativo es apagado. Para evitar este problema se Como se puede observar en la Figura 3, uno de los botones mecnicos se encuentra en paralelo a un botn lgico. El botn lgico se realiz mediante un opto acoplador y un transistor los cuales se disponen en una conguracin Darlington. Al presionar el botn de encendido la placa se prende y ejecuta su secuencia de arranque. Unos segundos despus el sistema toma el control de los puertos de entrada-salida, se polariza el transistor Q1 poniendo en "1"lgico el pin 7 del DIO, activando as al opto acoplador. El transistor que realiza la salida del opto acoplador funciona como un interruptor ya que queda en estado de saturacin. Esto a su vez produce la saturacin del transistor Q2 permitiendo as el pasaje de la corriente. El proceso de encendido tiene una duracin aproximada de 4 segundos y
3 Sistema 4 La
luego del arranque a la espera de una orden del usuario. TS-7260 debe ser alimentada entre 4,5 y 20 V.
81

Tabla I C OMPARACIN DE POSIBLES PLACAS
Gumstix Overo Earth[5] ARM Cortex-A8 CPU 600 MHz 256 MB RAM 256 MB Flash Sinlge board computers seleccionadas PPM-LX800[6] EPX-GX500[7] AMD 500 MHz Geode LX800 AMD GeodeTM GX500 Up to 128 MB SDRAM Up to 64 MB of AMD MirrorBit Flash Si 2 x 2.0 ports 90 x 96 0.9W Windows XP, XP Embedded, Linux, DOS, x86 RTOS Up to 512 MB SDRAM ARM TS-7260[8] 200MHz ARM9 CPU 32MB SDRAM 32MB NAND Flash Si 2 12-bit Si 2 USB 2.0(12 Mbit/s max) 95 x 120 0.25W a la frecuencia mnima Linux out-of-the-box
Procesador Memoria RTC ADC SD USB Tamao (mm x mm x mm) Consumo Sist. Operativos que soporta
10 bits 2GB micro SD USB HS Host 17 x 58 x 4.2 1W
12-bit Si 2 X Two USB 1.1 ports 1.0W Windows XP, XP Embedded, Linux, Windows CE, DOS, x86 RTOS
cuando naliza enciende el led verde, indicando al usuario que el sistema est encendido y que puede soltar el pulsador. La ltima accin que toma el sistema opertivo de la placa TS7260 es bajar el pin 7 a "0", esto hace que la SBC se quede sin alimentacin, por lo que con esta solucin la placa efectivamente no consumir cuando est apagada.
Figura 4. Bozal, caja con el dispositivo y micrfono.
En la Figura 4, se puede observar el bozal diseado, en donde se colocan el micrfono y la caja con el dispositivo. Para poder conectar el micrfono a la placa de audio se coloc un pasacables estanco para mantener las propiedades de la caja. IV. E SPECIFICACIN DEL SOFTWARE DEL SISTEMA
EMBEBIDO
Introducin El diseo del sistema embebido se divide en los siguientes bloques: Inicializacin del sistema. Adquisicin y almacenamiendo de audio. Apagar el sistema. Varias de las acciones que debe realizar el sistema embebido son realizadas por programas y/o libreras de cdigo abierto ya implementadas y testeadas por varias comunidades de desarrolladores. A continuacin se detalla el funcionamiento de los bloques. Inicializacin del sistema Luego de presionar el pulsador de encendido se ejecuta TSSDBOOT e inicia el sistema operativo.
Figura 3. Esquema de la placa interfaz usuario y control de energa.
III.
D ISEO INDUSTRIAL
La caja seleccionada para contener la TS-7260, tarjeta de audio, bateras y placa interfaz es una Pelican 1060 Micro Case[10] es a prueba de polvo, agua y golpes (ip67); y sus dimensiones son 20.9 x 10.8 x 5.7 cm.
82
Figura 5. Interaccin de los programas del software del sisem.
Ejecutar TS-SDBOOT: El TS-SDBOOT es un bootloader para las placas TS-7260, TS-7300 y TS-7400. Al ejecutarlo se levanta la imagen del kernel que se encuentra en la primera particin de la SD card para luego descomprimirla en RAM. Luego se ejecuta linuxrc, el cual es un archivo realizado en shell scripting que se encarga de congurar el sistema de archivos del GNU/Linux. Despus que todas estas acciones han nalizado, se levanta el sistema operativo Debian Sarge 3.1, el cual se encuentra en la tercer particin de la SD card. Programa linuxrc: Se ejecuta para poder congurar y trabajar desde la SD card como se dise, modicar la conguracin del sistema de archivos de la tercera particin de la SD card y realizar el control de LEDs y pulsador para encender la placa. Inicio del sistema operativo: Para que el sistema arranque automticamente con nuestro software se modic la autenticacin de los usuarios y los demonios que se levantan al inicio del sistema. Adquisicin y almacenamiendo de audio La adquisicin del audio se realiza mediante el uso del software Bplay, el cual cuenta con una interfaz de grabacin llamada brec. Se debe congurar el software para grabar a la frecuencia de muestreo y cantidad de bits deseados. Apagar el sistema Cuando se presiona el pulsador de apagado el sistema operativo se apaga correctamente y se le quita la alimentacin a la TS-7260. En la Figura 5 se muestra un diagrama que explica como interactan algunos programas del software del sistema embebido. V. I MPLEMENTACIN DEL SOFTWARE DEL SISTEMA
EMBEBIDO
Luego se intent bootear Debian Sarge 3.1 desde una tarjeta SD. Como el RedBoot que trae originalmente la placa TS7260 no soportaba el booteo desde la tarjeta SD fue necesario cambiarlo por el TS-SDBOOT5 [11]. El kit de desarrollo de Technologic System inclua el cdigo fuente de Debian Sarge 3.1, para el kernel 2.4.26-ts10 que se cross-compil para crear la imagen comprimida zImage. Para implementarlo exitosamente fue necesario modicar el cdigo fuente proporcionado por Technologic System para obtener mdulos de audio y tarjeta de almacenamiento, direccionamientos de memoria correctos y comando de ejecucin de inicio del kernel; solucionar errores de dependencia y cdigo mal implementado. Para poder solucionar estos inconvenientes fue necesario modicar archivos del fuente del kernel desrrollados en C. Para obtener los errores del sistema operativo se utiliz la herramienta strace que muestra las llamadas al sistema operativo. Analizando los distintos errores que se obtuvieron al utilizar dicha herramienta se depuro el cdigo6 . Posteriormente se cross compilaron los mdulos y bibliotecas necesarias para controlar las distintas interfaces de la SBC que traa includo el kit de desarrollo. Tambin fue necesario modicar los cdigos fuentes de los cuales dependa el mdulo de audio porque contenan diversos errores, como por ejemplo no se poda grabar correctamente. Adems de utilizar el TS-SDBOOT fue necesario particionar en 3 la tarjeta SD y realizar los siguientes procedimientos: 1ra particin.: Instalar el zImage del kernel de GNU/Linux deseado. 2da particin.: Instalar linuxrc y modicar algunos de los parmetros de dicho programa. 3ra particin.: Instalar Debian Sarge 3.1, nuevos mdulos crosscompilados y archivos creados durante la realizacin del proyecto encargados de manejar la placa interfaz y grabar. Para poder bootear Debian Sarge 3.1 desde una SD card fue necesario cambiar el RedBoot original de la TS-7260 por el TS-SDBOOT [11]. El kit de desarrollo de Technologic System inclua el cdigo fuente de Debian Sarge 3.1, para el kernel 2.4.26ts10 que se cross-compil para crear la imagen comprimida zImage. Para implementarlo exitosamente fue necesario modicar el cdigo fuente proporcionado por Technologic System para obtener mdulos de audio y tarjeta SD, direccionamientos de memoria correctos y comando de ejecucin de inicio del kernel; solucionar errores de dependencia y cdigo mal implementado. Posteriormente se cross compilaron los mdulos y bibliotecas necesarias para controlar las distintas interfaces de la TS-7260 que traa includo el kit de desarrollo. Tambin fue
5 Una vez realizada esta accin no es posible volver a bootear desde la SDRAM, a menos que se la enve a la fbrica de origen; sin embargo, decidimos realizarla. 6 Los archivos correctos se encuentran en: mosobo.it.com.uy/mosobo_2.4.26-ts10.tar.gz. Las herramientas para cross compilar el kernel se encuentran en: mosobo.it.com.uy/toolchain.tar.gz.
Para tener la seguridad de que la SBC funcionara correctamente, se veric el puerto serie, el puerto ethernet y algunos comandos bsicos de GNU/Linux.
83
necesario modicar los cdigos fuentes de los cuales dependa el mdulo de audio ya que contenan diversos errores. VI. T RATAMIENTO DE SEALES Para realizar el reconocimiento de actividades se utiliz una representacin apropiada de las seales acsticas y modelado estadstico que tiene su base en los Modelos Ocultos de Markov (HMMs)[12]. Cabe destacar que todo el anlisis de las seales se realiza en un PC. Antes de generar y entrenar los modelos las seales de audio debieron ser remuestreadas y ltradas por la presencia de ruido blanco en altas y bajas frecuencias. Para implementar el software de reconocimiento de actividades se utiliz el software Hidden Markov Model Toolkit (HTK)[13]. Con el n de evaluar cualitativamente el resultado de grabar a los rumiantes con el dispositivo desarrollado y realizar el reconociemiento de eventos y actividades con el software implementado, denimos la probabilidad de acierto de la actividad A (simbolizando pastoreo, rumia o descanso) como: K N 100 A i tAij P aA = tA i=1 j =1 donde KA es la cantidad de intervalos de la actividad A en la seal a evaluar, tA es el tiempo total etiquetado de la actividad a evaluar A, Ni es la cantidad de intervalos de la actividad A en tAi detectados en el reconocimiento y tAij es el intervalo de tiempo j de la actividad A en tAi en el reconocimiento. Los resultados obtenidos de los porcentajes de acierto a partir de una seal de 1 hora de duracin fueron: PaP =100 %, PaR =100 % y PaD =52 %. Tanto la rumia como el pastoreo se detectaron correctamente mientras que el descanso solo se detect un poco ms de la mitad del tiempo. Esto se debe a que cualquier ruido del ambiente puede ser considerado para el modelo, como un evento de rumia o arranque, por lo que parte del descanso puede confundirse con la rumia o el pastoreo. VII. C ONCLUSIONES Y PERSPECTIVAS Utilizando la placa TS-7260 con Linux embebido se desarroll un dispositivo capaz de grabar y almacenar correctamente los sonidos emitidos por bovinos y que puede permanecer a la intemperie junto con los mismos sin presentar problemas de funcionamiento. El dispositivo es de fcil colocacin, no interere con el comportamiento de los animales, no les genera lesiones y adems su costo, que ronda los 375 USD en materiales7 , es relativamente bajo en comparacin con otros dispositivos que se utilizan para este n. Se logr una independencia energtica de 24 horas, resultando en un peso del dispositivo de 1700 g sin bozal. Utilizando las bateras de litio-ion mencionadas el peso total del dispositivo baja a 800 g sin bozal. A pesar de haber tenido varios inconvenientes con las herramientas de desarrollo brindadas por el fabricante de la SBC (cdigo fuente mal implementado, errores de direccionamiento
7 No
de memoria, dependencias, etc), se logr implementar exitosamente 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 actividades que realizan los rumiantes; a partir del cual se implement un sistema de reconocimiento de actividades (pastoreo, rumia y descanso). Se lograron buenos resultados en el reconocimiento de las actividades de pastoreo y rumia (porcentajes de acierto del 100 %) mientras que el resultado de la actividad descanso no fue tan satisfactorio (porcentaje de acierto del 52 %). En un futuro se le puede incorporar un GPS con el cual se podra relacionar la ubicacin del animal al realizar cada actividad. Adems, mediante el uso de mapas se podra determinar el tipo de pastura que ingiri el animal y estimar la materia seca consumida lo cual brinda informacin adicional del comportamiento ingestivo animal. R EFERENCIAS
[1] P. Chilibroste, P. Soca, D. Mattiauda, O. Bentancur, and P. Robinson., Short term fasting as a tool to design effective grazing strategies for lactating dairy cattle: a review. Australian Journal of Experimental Agriculture, 2007. [2] J. Hodgson, The control of herbage intake in the grazing ruminant. Hill Farming Reasearch Organization, 1985. [3] E. Sazonov, S. Schuckers, P. Lopez-Meyer, O. Makeyev, N. Sazonova, E. L. Melanson, and M.euman., Non-invasive monitoring of chewing and swallowing for objective quantication of ingestive behavior. Electronic Journals from Institute of Physics Publishing., 2008. [4] D. Milone, H. Runer, J. Galli, E. L. f, and C. Cangiano, Computational method for segmentation and classication 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-Specications/Overo-Specications/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/boarddetail.php?product=TS7260, 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, Tsboot, 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/
incluye gastos de aduanas ni envos.
84
Dispositivo de rehabilitacin visual basado en sistemas embebidos del tipo ARM.

Marcelo M. Raponi
Centro de Investigaciones en Lseres y Aplicaciones CITEFA-CONICET Buenos Aires, Argentina mraponi@citefa.gov.ar
Rodolfo O. Bonnin
Business Vision S.A. Hiplito Yrigoyen 1530, Piso 7 Ciudad Autnoma de Buenos Aires, Argentina rbonnin@b-vision.com
Resumen- En el trabajo se describe el diseo y desarrollo de un sistema embebido basado en tecnologa ARM Cortex A8 (placa BeagleBoard), para adquirir y procesar en tiempo real seales de video provenientes de una mini-cmara porttil, y generar un patrn de estimulacin visual que brinde un cierto grado de rehabilitacin a personas con baja visin. Para la implementacin de la plataforma se utiliz el IDE Qt-creator y libreras open-source (Qt, Highgui y OpenCV). El framework permite adquirir seales de video, aplicar filtros espaciales, modificar brillo y contraste, hacer zoom, invertir colores, entre otras operaciones. El patrn visual final es enviado a un mdulo de visualizacin compuesto por dos mini-display LCD TFT grficos montados en las lentes de unos anteojos. Palabras claves- BeagleBoard; sistemas embebidos; baja visin; OpenCV.
millones menores de 15 aos. Las cataratas son la principal causa de ceguera (47,8%), seguida por la degeneracin macular asociada a la edad (8,7%) y la retinopata diabtica (4,8%). En el rea de la rehabilitacin 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 ms de 1/10 (y menos de 3/10) se emplea una correccin de +8 o +10 dioptras con prismas, con el fin de compensar la gran convergencia que se necesitara para enfocar un objeto ubicado a una distancia de 10 o 12.5 cm. En la mayora de los casos, el ojo ms deteriorado afecta - por ser el ojo director - la percepcin del mundo exterior, y el cerebro debe aprender a desechar dicha informacin. Una manera de colaborar con el cerebro es colocar un vidrio oscuro o esmerilado frente a dicho ojo, impidiendo que reciba estmulos de luz. Por otro lado, no existen indicaciones de ayudas pticas/electrnicas para patologas especificas. Un persona con baja visin tiene disminuida la sensibilidad de percepcin (capacidad de distinguir detalles) debido a diversas causas, por lo cual, cualquier dispositivo de rehabilitacin, deber sencillamente magnificar el estimulo visual (ver Fig. 1).
I.
INTRODUCCIN
El sentido de la visin es fundamental para realizar las mltiples tareas que cotidianamente llevamos a cabo los seres humanos. Actividades tan habituales como cruzar una calle, tomar un colectivo, mirar televisin, leer el diario, entre otras tantas, se ven seriamente afectadas por lesiones y patologas oculares que producen ceguera parcial o completa en millones de seres humanos. Existe un gran nmero 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 visin o visin subnormal. Para definir el trmino baja visin de una forma amplia, es necesario tener en cuenta no slo el dficit visual sino tambin la calidad visual. Una patologa ocular permanente debe ser valorada en cuanto afecta al estado psquico, fisiolgico y social del individuo respecto a una vida de relacin. La Organizacin Mundial de la Salud (OMS) define la baja visin como: "Prdida de agudeza visual y/o campo visual, que incapacita para la realizacin de tareas de la vida diaria, incluso tras un tratamiento y/o correccin refractiva convencional. La agudeza visual debe ser igual o inferior a 0.3 (30% de visin) y el campo visual menor o igual a 20. La prdida afecta a los dos ojos, pero an queda resto visual til. Una persona es legalmente ciega cuando su agudeza visual es menor o igual a 0.1 (10% de visin) y su campo visual inferior a 10, en el mejor de los ojos. Segn estadsticas mundiales existiran alrededor de 161 millones de personas con deficiencia visual, de los cuales 124 millones tendran baja visin y 37 millones seran ciegos, incluyendo 1,4
Figura 1. Dispositivos electrnicos empleados por pacientes con baja visin.
Actualmente, mediante el empleo de elementos pticos (lentes especiales, lupas, telelupas) y sistemas electrnicos
85
(magnificadores de imgenes, circuito cerrado de TV, etc.) es posible brindar a dichos pacientes, un cierto grado rehabilitacin visual. En el mercado nacional e internacional existen ayudas para visin cercana (ej. leer o escribir) y visin lejana (ver TV, mirar una pizarra, observar carteles en la va pblica, 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 electrnicas pueden variar desde unos U$S 300 hasta ms de U$S 3000. El dispositivo que presentamos en este trabajo (an en etapa de desarrollo) tiene un costo de fabricacin de aproximadamente U$S 500 (incluye anteojos con display y mini-cmara, unidad de control, batera, 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 continuacin se presenta el diseo y desarrollo de un dispositivo biomdico de rehabilitacin visual, basado en tecnologa embebida de ltima generacin y algoritmos de procesamiento de imgenes digitales, capaz de mejorar la calidad de vida de personas con disfunciones visuales severas. El sistema - reconfigurable, porttil y de bajo costo - permite adquirir y procesar imgenes en tiempo real, efectuar un realce selectivo de la informacin visual y mapear dicha informacin en un patrn de estimulacin 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 rpida adaptacin a nuevos dispositivos embebidos o bibliotecas, como as tambin un adecuado mantenimiento en el caso que se requieran rediseos y/o adicionar nuevas funcionalidades. II.
IMPLEMENTACIN DEL HARDWARE
(sobre la diagonal), distancia interpupilar de 63.5 mm y tamao de imagen virtual de aproximadamente 35 a 2 metros de distancia. El consumo de energa del mdulo visualizador es menor a 450 mW y puede procesar seales de video tipo NTSC o PAL estndar de manera automtica.
Figura 2. Modulo de adquisicin (superior) y de visualizacin (inferior) del prototipo desarrollado.
La implementacin fsica del dispositivo consta de tres componentes: un mdulo de adquisicin de seales de video (con un subsistema de captura de imgenes incorporado y salida USB), un mdulo de visualizacin de seal de video procesada, y un mdulo de procesamiento basado en tecnologa ARM (Advanced RISC Machines) Cortex A8 (placa BeagleBoard) [1,2]. A. Mdulos de adquisicin y visualizacin de imgenes El mdulo encargado de la adquisicin de las imgenes 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 va un puerto USB 2.0. El controlador de video (Sunplus SPCA1528A) soporta sensores de 5 Mega pxeles, grabacin 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 pxeles. La mini-cmara incorporada en los lentes permite adquirir imgenes de buena calidad an en ambientes con baja iluminacin. La duracin de su batera es de aproximadamente 4 -5 hs. La seal de video luego de ser procesada por la BeagleBoard, es enviada a un mdulo de visualizacin compuesto por dos display LCD TFT grficos, con una resolucin de 320x240 pxeles (QVGA), un tamao de 0.24
B. Mdulo de procesamiento basado en BeagleBoard Para la implementacin del prototipo hemos seleccionado la placa de desarrollo BeagleBoard, la cual es un pequeo 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 ncleo 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 grfico. La placa tiene conectividad con diversos perifricos: webcam, LCD, memorias SD, etc. (ver Fig. 3).
Figura 3. Sistema embebido (placa BeagleBoard) y su conexin con el mdulo de adquisicin de video.
86
Se opt por la tecnologa ARM principalmente por su rpida puesta en marcha, la posibilidad de utilizar las libreras OpenCV (Open Source Computer Vision Library), el alto grado de conectividad, su portabilidad, la capacidad de clculo del DSP y la aceleradora de grficos, entre otras caractersticas sobresalientes III. ARQUITECTURA DE LA SOLUCIN DE SOFTWARE
procesamiento y visualizacin de resultados, y la interaccin de los mismos.
La solucin consiste bsicamente en una aplicacin 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) diseada en base a libreras Qt [5]. El backend realiza las tareas preliminares de adquisicin y adaptacin de las seales a las restricciones impuestas por el transductor. Est conformado por un stack de software cuyos componentes principales son el kernel de Linux, la librera OpenCV y V4L para la captura de vdeo. OpenCV es una librera de programacin especialmente diseada para tratamiento de imgenes, captura, procesamiento y visualizacin de seales de video en tiempo real, segmentacin y reconocimiento de objetos y gestos, seguimiento de objetos, robtica, biomtrica, seguridad, entre otras aplicaciones. Es de cdigo abierto, multiplataforma, de fcil uso y en continua evolucin. Fue desarrollada originalmente por Intel para abordar problemas en el rea de la visin 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 versin 2.6, y tiene un rbol de desarrollo adaptado a versiones anteriores del kernel. Para el soporte del dispositivo de captura de entrada, una versin actual de los drivers (gspca_spca1548) tuvo que ser modificada para ser soportada por la distribucin de Linux (Angstrm). A continuacin se explicar cada uno de los bloques constitutivo de la plataforma. A. Sistema Operativo La distribucin seleccionada (Angstrm) [6] est diseada especficamente para sistemas embebidos, y el kernel Linux es el oficial de la distribucin 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 cmara del mdulo de adquisicin, 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 mdulo genrico gspca (soporte de un nmero de webcams de bajo costo), y se adapt el driver gspca_1528 para el uso de una funcin legacy de driver genrico. Dicho driver fue compilado directamente en el nuevo kernel, que ser utilizado en las pruebas finales. B. Esquema general de la aplicacin de software En la Fig. 4 se presenta un esquema general de la organizacin funcional del software implementado. Se pueden observar las funciones principales de adquisicin,
Figura 4. Diagrama en bloques del procesamiento realizado por la plataforma embebida
C. Adquisicin de datos La adquisicin de imgenes se realiza por medio de la librera auxiliar de OpenCV, highgui [7], que consiste en un toolkit grfico 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 librera Qt). A continuacin transcribiremos algunas lneas del cdigo, donde se pueden apreciar las estructuras de datos y funciones esenciales empleadas para la adquisicin de imgenes: 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 inicializacin 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 imgenes se realiza mediante las siguientes rutinas: Ajuste de brillo/contraste: se realiza por medio de la funcin convertScaleAbs, la cual posee una variable alpha que modifica la relacin de escala de los valores, y beta, que genera un bias para los valores de la imagen. Deteccin de bordes: se utiliza el algoritmo de Canny [8], incluido en OpenCV, con un primer umbral del procedimiento de histresis de 50, un segundo umbral de 300, una apertura de 3 y sin gradiente L2.
87
Inversin de colores: se aplica la funcin bitwise_not a cada elemento del miembro data del objeto de clase Mat. E. Interfaz grfica Mediante una interfaz visual amigable, el usuario puede seleccionar diferentes operaciones a realizar sobre la seal de video capturada, entre los cuales podemos mencionar: zoom, deteccin de bordes, modificacin de brillo y contraste, imagen complementaria, entre otras que se incorporarn en un futuro. La interfaz fue diseada teniendo en cuenta la maximizacin del espacio visible debido a que la imagen ser destinada finalmente a los displays, y una disrupcin excesiva de los controles no es aconsejable. Consiste en un mdulo de visualizacin de resultados/modificacin de parmetros por medio de la librera 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 diseo de la interfaz implementada, pudiendo observarse sus comandos localizados en una barra desplegable.
Adaptacin de estructuras de datos: para posibilitar la adaptacin 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 adquisicin de seales de video en tiempo real y efectuar un realce selectivo de la informacin visual. Mediante una sencilla interfaz especialmente diseada, es posible seleccionar diferentes procesamientos digitales que se aplicarn a los respectivos cuadros de la seal entrante. La plataforma implementada es porttil, de bajo consumo y puede utilizarse para mejorar diversas tareas de la vida cotidiana que realizan los pacientes con baja visin. AGRADECIMIENTOS Los autores agradecen a todos aquellos que hicieron posible la concrecin del diseo del primer prototipo de baja visin. REFERENCIAS
[1] ARM, descripcin del procesador Cortex A8 [online] http://www.arm.com/products/processors/cortex-a/cortex-a8.php Fecha de acceso: 24 de septiembre de 2010. Gerald Coley. BeagleBoard System Reference Manual Rev C4, Revision 0.0 [online]. http://beagleboard.org/static/BBSRM_latest.pdf, December 15, 2009. Gary Bradski y Adrian Kaebler. Learning OpenCV, Ed. O'Reilly Media Inc., ISBN 978-0-596-51613-0, 2008. http://opencv.willowgarage.com/wiki OpenCV Wiki Welcome. Fecha de acceso: 26 de Agosto de 2010. http://qt.nokia.com/downloads/sdk-windows-cpp. Nokia Corporation. Fecha de acceso: 26 de septiembre de 2010. http://www.angstrom-distribution.org/ The ngstrm Distribution Embedded power. Fecha de acceso: 28 de Agosto de 2010. http://opencv.willowgarage.com/documentation/cpp/highgui._highlevel_gui_and_media_io.html Opencv v2.1 documentation. Fecha de acceso: 15 de Septiembre de 2010. J. Canny. A Computational Approach to Edge Detection. IEEE Transactions on Pattern Analysis and Machine Intelligence, PAMI8(6):679698, November 1986.
[2]
[3] [4] [5] [6] [7]
[8] Figura 5. Prototipo de interfaz visual. Se observa un texto original y el resultante de aplicar zoom e inversin 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 operacin de un touchscreen. Similar comportamiento posee el control de contraste. Tambin se visualizan los controles de zoom (in y out) que operan sobre el widget por medio de mtodo GraphicsView::scale (razn de aspecto horizontal, razn de aspecto vertical) . Los botones C y V, permiten elegir la fuente de los frames, el primero identifica la cmara, y el segundo un archivo de video, que se elegir por medio de un dilogo de seleccin de archivo.
88
89
90
An alisis del Desempe no de un Algoritmo de Localizaci on para Redes de Sensores

Silvana Romina Sa nudo. Departamento de Ingenier a El ectrica y Computadoras, Universidad Nacional del Sur, Bah a Blanca. Email: ssanudo@uns.edu.ar Favio Rom an Masson. Departamento de Ingenier a El ectrica y Computadoras, Universidad Nacional del Sur, Bah a Blanca. Email: fmasson@uns.edu.ar Pedro Juli an. Departamento de Ingenier a El ectrica y Computadoras, Universidad Nacional del Sur, Bah a Blanca. Email: pjulian@uns.edu.ar
ResumenSe presenta el an alisis del fucionamiento de un eventos estimador para localizaci on y seguimiento de fuentes o en Redes de Sensores denominado Filtro de Part culas Acotado (BPF, Bounded Particle Filter). El algoritmo cumple con las restricciones de redes de sensores, a saber: m nimo procesamiento, m nimo almacenamiento y m nima comunicaci on de datos. Se en una aplicaci analiza su desempeno on de localizaci on en un espacio de estados bidimensional utilizando sensores de rango. La soluci on presentada puede extenderse a cualquier tipo de seguimiento. sensores en cualquier aplicaci on de localizaci on o
I. I NTRODUCCI ON Los avances en Sistemas Micro Electro Mec anicos (MEMs) y redes inal ambricas han hecho posible la creaci on de peque nos nodos sensores multifuncionales de comunicaci on inal ambrica; de bajo costo, poca cobertura de sensado y comunicaci on limitada; poca capacidad de procesamiento y almacenamiento, bajo ancho de banda y bajo consumo de energ a [1]. Las redes conformadas por dichos nodos, denominadas Redes de Sensores Inal ambricas (WSN, por su nombre en ingl es, Wireless Sensor Networks) ( [2], [3]), son un paradigma de la medici on distribuida; los nodos colectan informaci on f sica del ambiente y la comunican. La red en conjunto trabaja con un n determinado; uno de los objetivos evento y mas comunes es la localizaci on de una fuente o su seguimiento ( [4], [5]). Los nodos en aplicaciones de localizaci on y seguimiento requieren, en algunos casos, tratar con eventos de corta duraci on y para ello deben ser capaces de procesar y comunicar la informaci on en forma r apida para lograr el procesamiento colectivo. Un ejemplo es la detecci on de disparos [6]. Las limitaciones f sicas de los nodos hacen que su capacidad de procesamiento, memoria y comunicaci on sean muy restringidas, es por ello que en general los nodos realizan tareas simples sin llegar a un resultado, solo a un preprocesamiento de la informaci on; la mayor parte del procesamiento se realiza en una computadora. La localizaci on presenta modelos no lineales con ruidos de distribuci on aleatoria. El Filtro de Part culas presenta una forma simple y efectiva de representar modelos de procesos estoc asticos y modelos de propagaci on arbitrarios con funciones de distribuci on de probabilidad arbitrarias; lo que lo hace la herramienta adecuada para la tarea que se desea abordar. El Filtro de Part culas Acotado es una modicaci on del Filtro de Part culas de modo de poder implementarlo sobre un nodo
comercial, cumpliendo con las restricciones que el nodo y la red de sensores presentan; y presentando una soluci on a los problemas que un PF conlleva, como ser el empobrecimiento de muestras y la convergencia. El presente trabajo provee el an alisis de un algoritmo para redes de sensores adaptado especialmente para su implementaci on sobre los nodos de la red. Permite llegar a resultados de localizaci on cumpliendo con las restricciones que el sistema (nodo/red) presenta. El algoritmo permite realizar una estimaci on conjunta, totalmente evento. Se han explicado descentralizada, de un objeto o la motivaci on y las caracter sticas de la aplicaci on que se presentar a en el trabajo. En la siguiente secci on se expone la noci on de fusi on de datos. En el Cap tulo 3 se presenta un paneo de ltros no lineales y en el Cap tulo 4 se resume el algoritmo de Filtro de Part culas Acotado, las contribuciones que presenta. En el Cap tulo 5 se muestran las aplicaciones implementadas del Filtro de Part culas Acotado; un estudio estad stico para la variaci on de par ametros de dise no del algoritmo y se extraen conclusiones respecto a los resultados obtenidos. DE DATOS II. F USI ON La fusi on de datos pretende, mediante la combinaci on de observaciones de diferentes sensores, potenciar las virtudes de cada uno de ellos y minimizar sus posibles desventajas, con el n de realizar inferencias sobre el mundo exterior; pretende obtener un mejor resultado a partir de m ultiples sensores realizando inferencias que pueden no ser posibles a partir de uno solo. Existen diversas maneras de realizar la fusi on de datos, dependiendo de la aplicaci on y la distribuci on de la red. En casos donde se cuenta con un gran n umero de sensores o se requiere llegar al resultado en forma r apida es adecuado realizar la fusi on de manera descentralizada ( [7], [8], [9]), fusionar entre nodos vecinos o bien realizar un procesamiento previo de la informaci on adquirida dentro del nodo y luego transmitir los resultados a un nodo de mayor jerarqu a o bien a un nodo central de procesamiento [10]. En general en localizaci on y seguimiento el procesamiento se realiza en l nea (online), al instante, sobre todo en aplicaciones militares y de seguridad; y requieren algoritmos r apidos y convergentes. En el presente trabajo se presenta un algoritmo de fusi on de datos r apido y convergente con bajo requerimiento de c alculo,
91
comunicaci on y almacenamiento; aplicado en problemas que requieren una fusi on online sobre un esquema distribuido; es decir, la fusi on se realiza nodo a nodo y se comunica directamente un resultado. A LOS F ILTROS DE E STIMACI ON III. I NTRODUCCI ON En redes descentralizadas los nodos tienen mayor complejidad debido a que deben procesar la informaci on y calcular la estimaci on del estado de inter es, pero ello hace a la red resultante escalable y modular [11]. En aplicaciones reales, las fuentes de ruido tienen distribuciones no Gaussianas, y asumir que lo son lleva a resultados de estimaci on incorrectos ( [12], [13]). Una manera de resolver el problema es acumular informaci on [14] para obtener una estimaci on general casi Gaussiana (mientras la informaci on de cada nodo no lo es) y luego utilizar un Filtro de Kalman est andar. Otro problema importante viene relacionado con los modelos no lineales y ltros basados en la linealizaci on, como el Filtro de Kalman Extendido (EKF); dichos ltros producen resultados catastr ocos si no se linealiza cerca del punto de operaci on [13]. Los Filtros de Part culas (PF) son herramientas que realizan una estimaci on Bayesiana y evitan los problemas detallados anteriormente; permiten representar modelos de procesos estoc asticos y modelos de propagaci on arbitrarios con funciones de distribuci on de probabilidad (pdf) arbitrarias en una manera simple y efectiva. Para lograrlo se utilizan los M etodos Secuenciales de Monte Carlo ( [15], [12]). La densidad de probabilidad es representada por puntos pesados (part culas) que son posibles estados del proceso, distribuidas en todo el espacio de estados. La base de los PF [12] mas utilizados se denomina Remuestreo por Importancia de Muestras (SIR, Sample Importance Resampling). El ltro realiza tres operaciones b asicas; generaci on de part culas, c alculo del peso de cada part cula y remuestreo. Las part culas y su peso se propagan utilizando el Teorema de Bayes y el concepto de SIR. Para lograr buenas aproximaciones son necesarias muchas part culas, lo que implica gran capacidad de c omputo y almacenamiento; y en una red de sensores la transmisi on entre nodos de dicha informaci on implicar a un costo inaceptable en el canal inal ambrico. Se han propuesto muchas modicaciones del PF para adaptarlo a tareas espec cas [15]. El PF Gaussiano (GPF) [16] aproxima las densidades a posteriori con til cuando se requiere Gaussianas simples ; es un algoritmo u transmitir mensajes de poca longitud y frecuencia. Cuando una distribuci on Gaussiana no es representativa del estimado, se puede utilizar una suma de Gaussianas para aproximarlo [17] aumentando los requerimientos de procesamiento. Tambi en se han utilizado cajas en lugar de part culas discretas para representar la estimaci on ( [18]), como resultado se debe comunicar menos informaci on pero se desperdicia mucha informaci on de los sensores debido a que para la generaci on de cada caja se considera la m axima incertidumbre del estado. En el presente trabajo el Filtro Acotado de Part culas (BPF, Bounded Particle Filter) ( [19], [20]) puede representar funciones de probabilidad no Gaussianas (pdf), el algoritmo encierra la regi on de part culas con alta probabilidad, son las part culas previamente seleccionadas debido a que su peso
excede una cota de peso. El desempe no del algoritmo se eval ua en aplicaciones de localizaci on de objetos en un espacio bidimensional, utilizando sensores de rango. La aproximaci on ngulo de la estimaci on es delimitada por cotas de rango y a (coordenadas polares) y se propagan de nodo a nodo. El BPF cumple potencialmente con el requerimiento de poca comunicaci on, bajo procesamiento de datos y el hecho de que no es necesaria una caracter stica de pdf a priori. IV. F ILTRO DE PART I CULAS ACOTADO El Filtro de Part culas Acotado (BPF, por su sigla en ingl es Bounded Particle Filter) presentado en [20] comienza en un nodo l der con una distribuci on de part culas inicial que se extiende sobre todo el espacio de estados de inter es. Luego de una medici on y una actualizaci on consistente de la estimaci on, se realiza la selecci on de part culas y se env an al siguiente nodo propiedades importantes de las part culas seleccionadas. En la versi on de m nima informaci on transmitida, se comunican las cotas del espacio estimado que encierran las part culas seleccionadas. La selecci on del nodo excede el alcance del trabajo [5]. Cada nodo recibe las cotas y genera rea delimitada por las una distribuci on de part culas en el a mismas, donde se realiza la predicci on y la actualizaci on. V. E NSAYOS DEL A LGORITMO I MPLEMENTADO SOBRE N ODOS A. Funcionamiento del Algoritmo en el Nodo. Se implementa el algoritmo sobre un nodo Mica2 ( [21], [22], [23]). La informaci on inicial llega al nodo desde un nodo inicial o previo y consiste en la posici on del nodo y ngulo y rango (solo 6 par cotas de a ametros de doble precisi on nico paquete de a ser transmitidos entre los nodos en un u RF). Una vez que la informaci on llega, el nodo comienza su propio procedimiento de estimaci on y luego lo comunica al nodo siguiente o a la PC. El procedimiento de estimaci on comienza con una lectura del sensor (observaci on, medici on); las part culas son generadas dentro de las cotas recibidas en coordenadas polares. Cuando una observaci on es efectuada, la estimaci on de la observaci on es calculada sobre cada part cula; ngulo y rango de las y con ello su peso. Se compara el a part culas cuyos pesos exceden la Cota de Peso (CotaW ) ngulo iniciales o previas para con las cotas de rango y a actualizarlas de ser necesario. Existe un problema con la generaci on aleatoria de part culas, especialmente debido a las dicultades de implementar un generador de n umeros aleatorios en un nodo de capacidad de procesamiento y almacenamiento limitadas. Se implementa un generador de n umeros aleatorios llamado Ran [24] que debi o ser modicado en dos formas para obtener distribuciones totalmente aleatorias. Primero se lee el contador del reloj del nodo y se rota para obtener un n umero que no sea mon otonamente creciente, dicho n umero se suma a la semilla. En segundo lugar, cada n umero generado se utiliza como semilla para la pr oxima generaci on. Para generar una part cula se genera un n umero aleatorio y se opera para obtener un n umero entre las cotas de rango. Luego para dicho rango se genera un nuevo n umero aleatorio que es operado ngulo. En la Fig. 1 se para que caiga dentro de las cotas de a
92
Fig. 1.
Comportamiento del nodo.
muestra la implementaci on del algoritmo sobre el nodo; los cuadrados grises son los procedimientos que no son propios del algoritmo. En la Fig. 2 se especica mas detalladamente el procedimiento realizado dentro de cada nodo. Ahora una breve explicaci on: Inicializaci on de par ametros: Las cotas iniciales (Amin, Amax, Rmin, Rmax) son inicializadas de manera que la primer part cula seleccionada ya las modique. Como ejemplo podemos citar un Rango M aximo de 0 y un Rango M nimo de 20 metros; para un sensor cuyo alcance es de 10 metros. Medici on del sensor: Se simula la lectura de un sensor de rango; en otras palabras, se dene una posici on ja del sensor y se calcula previamente una observaci on de rango con un ruido gaussiano espec co; en nuestro caso es de 5 cm. la varianza del sensor. Se calculan 1000 valores dentro de una normal de un rango medio y dicha varianza, y se elije aleat oreamente un valor que ser a la lectura del sensor. C alculo de la Cota de Peso (CotaW ): Se genera un n umero inicial de part culas, solo con el objetivo de guardar el peso m aximo (Wmax ) entre ellas, y se calcula con (1). CotaW se calcula como un porcentaje de dicho Wmax . No debe confundirse este n umero con el n umero de part culas generadas al inicio del algoritmo BPF. P orcentaje Wmax (1) CotaW = 100 ngulo Selecci on de part culas y extracci on de cotas de a y rango: Se genera una part cula, se compara su peso con CotaW y en caso de superarla, se incrementa un contador de part culas seleccionadas (k ) y se compara ngulo de dicha part el rango y a cula con las cotas de ngulo para actualizarlas. Se descarta la part rango y a cula y se repite el procedimiento en forma serial hasta que el m nimo n umero de part culas sobrevivientes (NroPart) se cumple. B. Ensayos de Simulaci on de Red con MICAs. Los nodos sensores realizaron el procesamiento en el orden y la ubicaci on especicada en la Tabla I. Se realizaron los
Fig. 2.
Detalle del algoritmo dentro de los nodos.
ensayos manteniendo la conguraci on de la red, el orden de procesamiento y el valor medido. Para cada ensayo se realizaron 20 corridas del algoritmo BPF sobre las cuales se evalu o el valor medio de la media y la varianza de las part culas seleccionadas en la estimaci on resultante (en XY), el rea resultante y la media del n a umero de part culas generadas hasta lograr las 15 part culas que superen CotaW en cada estimaci on de cada corrida. La idea es variar el n umero de part culas generadas con el n de almacenar el Wmax ; y de ah se elige la cota de peso como un porcentaje del m aximo peso. Siempre se almacenan m nimo 15 part culas. Se realizaron ensayos: Variando las part culas iniciales: 10, 20, 40, 60, 80 y 100 part culas sobre las cuales elijo la de peso m aximo para luego calcular CotaW . Variando el porcentaje de Wmax que se adopta por cota: 40, 60 y 80 Es importante recordar que se denomina area al producto entre la diferencia entre las cotas de rango por la diferencia ngulo de la estimaci entre las cotas de a on resultante; y la unidad es metro por radian. El n umero m nimo de part culas
93

Nodo 1 2 3 4 X (m.) 0 1 4 -1 Y (m.) 0 1 -1 3 z (m.) 1.998 4.121 3.1699
Nro. Part. 200 160 120 80 40 0 Media del nmero de partculas generadas en cada corrida 200 20 Part 10 Part 160 120 80 40 0 200 160 120 80 40 0 200 160 120 80 40 0
40
60
80
40
60
80 60 Part
Tabla I Y ORDEN DE ESTIMACI ON DE LOS SENSORES CON EL N odo1 U BICACI ON COMO ORIGEN DE COORDENADAS .
200 40 Part 160 120 80 40 0 40 200 160 120 80 40 0
Nro. Part.
60
80 80 Part
40
60
80 100 Part
10 8 6 4 2 0 10 8 6 4 2 0 10 8 6 4 2 0
40
rea resultante en fcn. del % de la CotaW 10 10 Part 8 6 4 2 0 60 80 40 60 40 Part 10 8 6 4 2 0 10 8 6 4 2 0
20 Part
rea
Nro. Part.
40
60 %
80
40
60 %
80
80 60 Part
Fig. 5. N umero medio de part culas generadas en cada corrida para 40, 60 y 80 %.
Nro. medio de part. generadas para una corrida Nro. Part.
rea
40
60
80 80 Part
40
60
80 100 Part
rea
200 160 120 80 40 0 200 160 120 80 40 0 200 160 120 80 40 0
40 %
20
40
60
80
100
120
Nro. Part.
40
60 %
80
40
60 %
80
60 %
Fig. 3.
Area de la estimaci on resultante para 40, 60 y 80 %.
10
20
40
60
80
100
Nro. Part.
rea resultante en fcn. del Nro. Mn. Part. 10 8 6 4 2 0 10 8 6 4 2 0 10 8 6 4 2 0
80 %
rea
40 %
10
20
40 60 80 Nro. mnimo de part. iniciales
100
10
20
40
60
80
100
rea
Fig. 6. Media del n umero de part culas generadas en una corrida en funci on de las part culas iniciales.
60 %
10
20
40
60
80
100
80 %
10
20
40 60 80 Nmero mnimo de part. a conservar
100
Fig. 4. Area de la estimaci on resultante para los diferentes n umeros de part culas iniciales.
a conservar es de 15; una vez que se encuentran 15 part culas cuyo peso supere la cota, se da por terminada la estimaci on. Una corrida consta de tres estimaciones consecutivas, en el orden mostrado de los nodos (2-3-4), una estimaci on por nodo sensor y se transmite. La tercer estimaci on consecutiva es la que se denomina estimaci on resultante. En la Fig. 3 se ve el rea de la estimaci a on resultante como funci on del porcentaje del Wmax que se toma como CotaW ; como era de esperar, rea se reduce a medida que se aumenta la precisi el a on que se le exige al ltro al aumentar CotaW . Arriba sobre la derecha se indica el n umero de part culas iniciales. En la Fig. 4 se muestran en forma diferente los mismos resultados que en la Fig. 3.
En las Fig. 5 y Fig. 6 se muestra el n umero medio de part culas generadas por corrida en funci on de los porcentajes y del n umero de part culas iniciales. Se puede observar que a medida que aumenta el porcentaje en el c alculo de CotaW se rea m reduce el a as probable, haciendo necesaria la generaci on de un mayor n umero de part culas para lograr cumplir con las rea) requeridas para terminar la 15 m nimas (dentro de dicha a estimaci on. En la Fig. 7 se muestra la varianza sobre el eje Y. Se puede observar que se reduce notablemente al aumentar el porcentaje en el c alculo de la cota de peso. En las Fig. 8 se pueden ver las estimaciones resultantes de las 20 corridas del algoritmo para 80 part culas iniciales de donde se selecciona el mayor peso. En el gr aco de la izquierda se utiliza una cota de peso del 40% de Wmax , mientras que en el gr aco de la derecha se utiliza una cota del 80 % de Wmax . Se ve claramente la rea m forma en que se reduce el a as probable. C. Casos Especiales on de red poco 1) Caso 1: Se realiza una conguraci aconsejable, ya que por la ubicaci on de los sensores los c rculos estimados no se cortan perpendicularmente en ning un momento, por estar los sensores alineados. Para este caso se
rea
94

Varianza del eje Y en fcn. del Nro. Mn. Part. 1 0.8 0.6 0.4 0.2 0 1 0.8 0.6 0.4 0.2 0 1 0.8 0.6 0.4 0.2 0 Varianza (m.) 40 %
Estimaciones en cada paso de una corrida 8 6 4
10
20
40
60
80
100
Y (m.)
2 0 2 4
Varianza (m.)
60 %
10
20
40
60
80
100
6
Varianza (m.)
80 %
8 8
0 X (m.)
10
20
40 60 80 Nro Mn. Part. a conservar
100
Fig. 9.
Estimaciones para un caso especial.

Estimaciones en una corrida 5 Y (m.) 5 0 5 5 0 5 5 0 5
Fig. 7.
Varianza en el eje Y en funci on de las part culas iniciales.

Estimaciones resultantes para 40% y 80 partculas iniciales Estimaciones resultantes para 80% y 80 partculas iniciales
2.5
0 5
0.4
2 0.2 1.5 Eje Y (m.) Eje Y (m.) 0
0.2 0.5 0.4
5 Y (m.) 0 5 5 0 X (m.) 5
5 0 5 5 0 X (m.) 5
0.5 0.5 0 0.5 1 Eje X (m.) 1.5 2 2.5
0.6 0.3 0.2 0.1 0 0.1 Eje X (m.) 0.2 0.3 0.4
Fig. 8.
Varianza en el eje Y en funci on 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. Una vez que se encuentran 15 part culas que superan dicha cota, ngulo que las encierran. En se extraen las cotas de rango y a la Tabla II se detalla la ubicaci on de los sensores. En la Fig. 9 se pueden apreciar las sucesivas estimaciones hasta llegar a la estimaci on resultante. Se simbolizan con c rculos los sensores y con una estrella la fuente, que est a en el origen. Para ver como actua cada nodo, en la Fig. 10 se ve m as en detalle. En cada cuadro se muestran las particulas generadas dentro de las cotas que pasa el sensor anterior, y en linea llena las nuevas cotas que encierran las part culas m as pesadas, las seleccionadas por tener un peso superior a la cota de peso. 2) Caso 2: En este caso los nodos se encuentran alineados en una l nea diferente a la de la fuente, a tres metros de distancia. Es una conguraci on mala de la red, ya se ver a a continuaci on porque. La Fig. 11 muestra una corrida de estimaciones de la red; en cada caso se muestran las part culas generadas dentro de las cotas que se reciben del nodo sensor rea determinada por la nueva estimaci anterior y el a on (l nea
Node 1 2 3 4 X (m.) 0 -4 -6 -2 Y (m.) 0 0 0 0 z (m.) 4.0499 6.0311 1.9474
Fig. 10.
Pasos en una corrida.
ltimo completa) que encierra las part culas mas pesadas; el u reas de las estimaciones resultantes. La gr aco muestra las a reas de las estimaciones Fig. 12 muestra en detalle las a resultantes de una corrida del algoritmo en la red. Los c rculos negros corresponden a los sensores y la estrella negra a la fuente. La primer estimaci on se representa en rojo, la segunda en azul y la nal en verde. Como se puede observar, reas estimadas no se reducen y no lo har las a an, debido a la conguraci on de la red. En casos como este se pueden implementar otros m etodos para rescatar mas informaci on. ngulo a la Como estrategia se podr a cortar la cota de a mitad y evaluar las part culas de cada mitad por separado. Otra forma es seleccionar las part culas mas pesadas en cada mitad, comparando su peso con una cota que es porcentaje del m aximo peso de cada mitad. Luego de ello se extraen las cotas ngulo y rango dando como resultado lo que se muestra en de a Fig. 13. VI. C ONCLUSIONES Y L I NEAS FUTURAS El BPF cumple con las restricciones de procesamiento, almacenamiento y comunicaci on que presentan los nodos, soluciona el problema de empobrecimiento de muestras y de convergencia; tambi en evita el procesamiento que implica el remuestreo y aporta una forma de resumir la informaci on de la estimaci on de modo de transmitir la menor cantidad de datos posible. Se prueba que el algoritmo converge a un estimado representativo del estado con muy poco procesamiento y sin
Tabla II Y ORDEN DE ESTIMACI ON DE LOS SENSORES CON EL N ODO 1 U BICACI ON COMO ORIGEN DE COORDENADAS .
95
R EFERENCIAS
5 Y (m.) 0 5 5 0 5 5 0 5 5 0 5
5 Y (m.) 0 5 5 0 X (m.) 5
5 0 5 5 0 X (m.) 5
Fig. 11.
Corrida de estimaciones.
8 6 4 2 Y (m.) 0 2 4 6 8 8
0 X (m.)
Fig. 12.
Areas estimadas.
7 6 2 5 1.5 4 Weight Y (m.) 1 3 2 1 5 0 0 5 4 2 X (m.) 2 0 1 5
0.5
0 10
1 X (m.)
Fig. 13.
Pasos en una corrida.
necesidad de almacenar ni transmitir part culas. En el trabajo se muestran resultados de la implementaci on del ltro sobre nodos comerciales, por software, pero debido a la necesidad de reducir la energ a al m nimo, ser a muy interesante la implementaci on del algoritmo en un chip. Se demuestra que las funciones empleadas son b asicas y el almacenamiento necesario m nimo, de modo que no se est a muy lejos de la posible implementaci on. Se debe complementar el algoritmo con algoritmos de sincronizaci on de la red, de localizaci on de los nodos dentro de la misma y de selecci on del nodo vecino mas informativo. Es importante estudiar el c alculo de la cota de peso basado en las incertidumbres de proceso y observaci on. Tambi en se deben analizar las diferentes formas de transmitir mayor informaci on del estimado, adem as de las cotas, de modo que la generaci on de part culas iniciales no sea una uniforme, sino que aproxime mejor la curva real de probabilidad a priori. Se puede extender el algoritmo para detecci on de m ultiples fuentes.
[1] B. Sadler, Fundamentals of energy constrained sensor network systems, IEEE Aerospace and Electronic Systems Magazine Part.2 Tutorials, vol. 20, no. 8, pp. 1735, 2005. [2] I. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci, Wireless sensor networks: a survey, Computer Networks, vol. 38, no. 4, pp. 393 422, 2002. [3] J. Yick, B. Mukherjee, and D. Ghosal, Wireless sensor network survey, Computer Networks, vol. 12, no. 52, pp. 22922330, 2008. [4] M. Terwilliger, A. Gupta, V. Bhuse, Z. H. Kamal, and M. Salahuddin, A localization system using wireless network sensors: A comparison of two techniques, in Proceedings of the First Workshop on Positioning, Navigation and Communication, Hannover, Germany, March 2004, pp. 95100. [5] L. M. Kaplan, Global node selection for localization in a distributed sensor network, Aerospace and Electronic Systems, IEEE Transactions on, vol. 42, no. 1, pp. 113135, 2006. [Online]. Available: http://dx.doi.org/10.1109/TAES.2006.1603409 [6] A. C. Rodriguez, Circuitos integrados de bajo consumo para detecci on y localizaci on de disparos de armas de fuego, Ph.D. dissertation, Facultad de Ingenier a, Universidad Nacional de Mar del Plata, Mar del Plata, Argentina, Mayo 2009. [7] M. Coates, Data fusion in decentralized sensing networks, 4th International Conference on Information Fusion, Montreal, Canada, 2001. [8] H. Durrant-Whyte, M. Stevens, and E. Nettleton, Data fusion in decentralized sensing networks, in Proceedings 4th International Conference on Information Fusion, 2001, pp. 302307. [9] I. F. Akyldiz, T. Melodia, and K. R. Chowdhury, Wireless multimedia sensor networks: Applications and testbeds, Proceedings of the IEEE, vol. 96, no. 10, pp. 15881605, 2008. [10] D. Blatt and A. D. H. III, Energy-based sensor network sourse localization via projection onto convex sets, IEEE Transaction on Signal Processing, vol. 54, p. 3614, 2006. [11] A. Makarenko and H. Durrant-Whyte, Decentralized data fusion and control in active sensor networks, in Proceedings of the Seventh International Conference on Information Fusion, 2004. [12] M. S. Arulampalan, S. Maskell, N. Gordon, and T. Clapp, A tutorial on particle lters for online nonlinear/non-gaussian bayesian tracking, IEEE Transactions on Signal Processing, Special Issue, vol. 50, no. 2, pp. 174188, 2002. [13] F. Daum, Nonlinear lters: Beyond the kalman lter, IEEE Aerospace and Electronic Systems Magazine, vol. 20, no. 8, pp. 5769, 2005. [14] T. Bailey, Constrained initialisation for bearing-only slam, in Proceedings IEEE International Conference on Robotics Automation, Taipei, Taiwan, Sept 2003, pp. 19661971. [15] J. Carpenter, P. Clifford, and P. Feamhead, Improved particle lter for nonlinear problems, radar, sonar and navigation, IEE Proceedings Radar, Sonar and Navigation, vol. 146, no. 1, pp. 27, 1999. [16] J. Kotecha and P. Djuric, Gaussian particle ltering, IEEE Transactions On Signal Processing, vol. 51, no. 10, pp. 25922601, 2003. [17] , Gaussian sum particle ltering for dynamic state space models, in Proceedings International Conference in Acoustics, Speech, Signal Processing, Salt Lake City, UT, May 2001, pp. 34653468. [18] A. Gning, F. Abdallah, and P. Bonnifait, A new estimation method for multisensor fusion by using interval analysis and particle ltering, in Proceedings IEEE International Conference on Robotics Automation, Roma, Italy, April 2007, pp. 38443849. [19] S. R. Sa nudo and F. Masson, Filtro de part culas acotado para fusi on de datos en redes de sensores, in Proceedings of the Jornadas Argentinas de Rob otica, C ordoba, Argentina, 2006. nudo, F. Masson, and P. Julian, Bounded state space particle [20] S. R. Sa lter for network sensors, IEEE International Symposium on Circuits and Systems, Sensory Systems I Lecture session C4L-M, pp. 35703573, 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: An operating system for sensor networks, Ambient Intelligence, 2005. [24] M. Matsumoto and Y. Kurita, Twisted gfsr generators ii, ACM Transactions on Modelling and Computer Simulation, vol. 4, no. 3, pp. 254266, 1994.
96
Tecnologa inalmbrica Near Field Communication y sus aplicaciones en sistemas embebidos

Esp. Ing. Mara Fernanda Carignano
Especialidad en Sistemas Embebidos Instituto Universitario Aeronutico Av. Fuerza Area 6500 - (5010) Crdoba mfcarignano@gmail.com
Dr. Pablo Ferreyra

Posgrado Sistemas Embebidos IUA Universidad Nacional de Crdoba ferreyra@famaf.unc.edu.ar
Abstract El estndar internacional NFC define una nueva tecnologa inalmbrica basada en radiofrecuencia que funciona en un radio de cobertura pequeo. El presente trabajo analiza la tecnologa NFC y su aplicacin real usando el lenguaje Java desde el punto de vista de la Ingeniera de Software. NFC, RFID, sistemas embebidos, tecnologa inalmbrica
II.
TECNOLOGA NFC
I.
INTRODUCCIN
La tecnologa NFC se basa en RFID (Radio-frequency identification), una tecnologa inalmbrica que est en desarrollo desde hace casi cuatro dcadas. NFC es una tecnologa estandarizada que tiene como propsito ser usada para facilitar la interconexin de dispositivos y el intercambio de datos en un entorno acotado. En conjunto con la creacin del estndar NFC, en 2004 surge el NFC Forum que, basndose en dicho estndar, 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 tecnologa NFC. Se realiza una comparacin entre NFC y otras tecnologas inalmbricas, 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 electrnica y el hardware. La seccin Tecnologa NFC describe los orgenes de NFC, sus caractersticas tcnicas, los estndares que la especifican y establece una comparacin con otras tecnologas relacionadas. La seccin 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 seccin Desarrollo de aplicaciones Java para dispositivos NFC describe una aplicacin NFC real usando el SDK (Software Development Kit) provisto por Nokia para su telfono Nokia 6131 NFC.
A. Orgenes La tecnologa 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 propsito de identificacin y seguimiento usando ondas de radio. Un tag RFID consta de dos partes principales: a) un circuito integrado para almacenar y procesar informacin, modular y demodular la seal de RF y otras funciones especializadas; b) una antena para recibir y transmitir la seal. Los tags RFID se pueden clasificar en tres grandes grupos [3]: activos, pasivos y pasivos asistidos por batera. Una de las tecnologas que se derivan de RFID es NFC, cuya caracterstica principal es el hecho de combinar ambas funciones de tag y reader/writer RFID en un nico dispositivo. Dado que NFC es una extensin de RFID, es compatible con toda la infraestructura RFID existente. B. Caractersticas tcnicas NFC es una tecnologa de comunicaciones inalmbrica 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 transmisin) 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 induccin electromagntica por el cual dos circuitos inductivos cercanos comparten energa con lo cual pueden transmitir datos a distancias de pocos centmetros. En forma similar a RFID, NFC define dos modos de operacin: activo y pasivo. Dado que NFC es una tecnologa derivada de RFID la cual se ha estado usando en mltiples 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 ms altos en el futuro.
97
C. Seguridad NFC provee de una seguridad intrnseca dada por el limitado radio de comunicacin de unos pocos centmetros. Pero si bien esto dificulta la tarea de "robar" informacin de ningn modo garantiza que una comunicacin NFC no pueda ser vulnerada [4]. Algunas de las amenazas a la seguridad de las comunicaciones NFC son: escuchas secretas (eavesdropping), corrupcin de datos, modificacin de datos, insercin de datos, ataque del "Hombre en el medio" (Man-in-the-middle). D. Estandarizacin La tecnologa 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 estndares [6][7][8] especifican los esquemas de modulacin, codificacin, velocidad de transferencia y formato de la trama de la interfaz de RF para dispositivos NFC, as como tambin los esquemas de inicializacin y condiciones requeridas para control de colisiones durante la inicializacin. Tambin definen el protocolo de transporte, incluyendo mtodos de activacin del protocolo e intercambio de datos. Adems un conjunto de empresas internacionales lderes en sus rubros consituy en 2004 el NFC Forum [9], una organizacin sin fines de lucro cuya misin es fomentar el uso de la tecnologa NFC desarrollando especificaciones [10][11][12][13], asegurando la interoperabilidad entre dispositivos y servicios [14][15] y educando al mercado acerca de esta tecnologa. E. Tecnologas relacionadas La posibilidad de comunicacin inalmbrica basada en ondas de RF dio lugar al desarrollo de numerosas tecnologas basadas en el mismo principio fsico. En la Tabla 1 se detallan y comparan las tecnologas inalmbricas de comunicaciones que complementan o tienen un mbito de aplicacin equivalente a NFC [10]. La Fig. 1 muestra esta comparacin entre tecnologas en forma grfica dando una vista simplificada de las diferencias entre ellas en cuanto a alcance y velocidad de transmisin.
TABLA I. NFC
Estndar ISO/IEC 18092 Tasa de 106-424 transferencia Kbps Frecuencia 13,56 MHz de funcionamie nto Cantidad 2 mxima de dispositivos que pueden interactuar Tiempo de < 0,1 ms inicializaci n
NFC
Alcance Seguridad < 20 cm Dada por la cercana entre dispositivos
RFID
<3m Dada por la cercana entre dispositivos
WiFi
< 100 m Determinada por los mecanismos de encriptacin que se usen
Bluetooth
< 30 m Determinada por los mecanismos de encriptacin que se usen Alto para dispositivos alimentados con bateras Reemplazar cables para conectar dispositivos electrnicos cercanos Conexin de perifricos (teclado, mouse, etc.) a una notebook en la misma habitacin
ZigBee
< 500 m Determinada por los mecanismos de encriptacin que se usen Muy bajo
IrDA
<5m Dada por el requerimient o de ambos dispositivos estn en la lnea de vista. Bajo
Consumo de Mnimo o energa inexistente
Alto para dispositivos alimentados con bateras Objetivo Simplificar Realizar Reemplazar la seguimiento cables en interaccin de objetos y redes entre control de extensas, dispositivos acceso fundamental mente de electrnicos tipo LANs Ejemplo de Intercambio Control de Conexin aplicacin de tarjetas inventario en entre personales supermercad dispositivos de una electrnicas os. oficina (PCs, acercando notebooks, dos telfonos impresoras, celulares etc.) dentro de un mismo edificio o entre edificios cercanos
Mnimo o inexistente
Control y Reemplazar monitoreo cables para inalmbrico conectar dispositivos electrnicos cercanos Manejo de sistema de riego y fertilizacin en sembrados usando sensores que de acuerdo a los valores de ciertas variables accionan los mecanismos correspondie ntes Transferenci a de archivos entre un telfono celular y una notebook
Figura 1. Alcance y velocidad de transmisin de las tecnologas inalmbricas
III.
NFC EN EL MERCADO DE CONSUMO MASIVO
COMPARACIN ENTRE TECNOLOGAS INALMBRICAS RFID

ISO/IEC 14443 106-424 Kbps 13,56 MHz
La evolucin de la tecnologa RFID en el rea de NFC ha dado origen a un completo conjunto de aplicaciones reales que son no slo tcnicamente factibles sino comercialmente WiFi Bluetooth ZigBee IrDA viables. NFC ofrece una relacin costo-beneficio apropiada IEEE 802.11 IEEE IEEE IrDA para el mercado masivo y cumple con estndares acordados 802.15.1 802.15.4 11-200 Mbps 1-480 Mbps 20-250 kbps 1 Kbps 100internacionalmente.
Mbps 868/915 MHz 2.4 GHz Indefinida 2
2.4 GHz 2.4, 5.25, 5.6, 5.8 GHz
El principal atractivo de la tecnologa NFC es el permitir variadas formas de comunicacin y transacciones de un modo muy cmodo y amigable para el usuario. En relacin a esta simplicidad de uso, se puede establecer una analoga con otros dispositivos de uso cotidiano como un simple interruptor para iluminar una habitacin o un picaporte para abrir una puerta. Su uso es casi intuitivo para la mayora de la gente y no es necesario conocer los principios fsicos que permiten que funcionen, ni leer un extenso manual de uso. Lo
Indefinida
< 0,1 ms
< 0,1 ms
6s
< 0,1 ms
0,5 ms
98
mismo ocurre con NFC, la idea es que con una accin simple como "tocar" o acercar un dispositivo NFC a otro, se inicie el servicio deseado, permitiendo que el uso de cualquier "servicio" electrnico y otras interacciones sean accesibles a ms 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 categoras 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 telfono) un tag NFC dispuesto a tal efecto en lugares definidos. De esta forma el tag NFC transfiere al dispositivo NFC una pequea cantidad de datos (texto, URL, nmero telefnico o cualquier otro dato breve) que le permitirn al usuario realizar alguna accin. Algunos ejemplos de este tipo de aplicaciones: o Carteles inteligentes (smart posters) en la va pblica promocionando un producto, servicio, evento, etc. que proporcionan una URL al usuario donde puede obtener ms informacin acerca del producto o servicio publicitado, o bien reservar las entradas para el evento. Informacin adicional sobre productos en un comercio cuando el usuario toca dicho producto con su dispositivo NFC. Control de temperatura o iluminacin de una habitacin 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). 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. Etiquetas adhesivas con tags NFC de comercializacin masiva en las que el usuario puede especificar un dato que ser usado por un dispositivo NFC para realizar una accin. Por ejemplo, se pueden adherir etiquetas con nmeros telefnicos a fotos de familiares para que una persona con capacidades visuales o de movimiento reducidas pueda llamar a un familiar con slo acercar su telfono NFC a la foto correspondiente1. Otro uso de estas etiquetas permitira que cuando un nio llega a su hogar desde la escuela, toque con su telfono celular NFC un tag NFC ubicado en la puerta de la casa y se enve un SMS a sus padres.
Peer-to-peer: este tipo de aplicaciones usan NFC como mecanismo para establecer la comunicacin entre dos dispositivos que necesitan intercambiar datos. Luego el intercambio de datos real puede realizarse usando NFC u otra tecnologa inalmbrica que resulte apropiada de acuerdo con el volumen de datos transmitidos. Algunos ejemplos dentro de este grupo de aplicaciones: o Transmisin de fotos desde una cmara digital a una impresora: mediante NFC se establece una conexin Bluetooth que es la que se usa para transmitir las fotos. Intercambio de tarjetas personales a travs de una conexin Bluetooth establecida por NFC. Configuracin automtica de una conexin Wi-Fi en lugares pblicos: el usuario toca con su telfono mvil un tag ubicado en la mesa que le transmite la configuracin de la red y luego toca su computadora porttil con el telfono para configurar la red e iniciar la conexin.
Payment & ticketing: este tipo de aplicaciones es el que principalmente dio origen a los estndares NFC. Dado que desde hace tiempo se usan contactless cards para ciertas transacciones comerciales y compra de pasajes en medios de transporte, la nueva tecnologa NFC tuvo que ser definida para mantener compatibilidad con las aplicaciones existentes. Algunos ejemplos de aplicaciones: o o Pagos en expendedoras parqumetros. automticas y
Consulta de saldo en tarjetas para transporte sin necesidad de concurrir a un lugar especfico para obtener este dato. Billetera electrnica: la tendencia final es evitar la necesidad de usar tarjetas plsticas para cada uno de los sistemas de fidelizacin de clientes con puntos, acceso a cobertura de salud, tarjetas de dbito y crdito, etc. y poder realizar todas la transacciones comerciales usando el telfono mvil. De esta forma hasta los pagos mnimos quedaran 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 telfonos mviles para realizar transacciones comerciales, prefieren este mtodo sobre otras alternativas de pago.
Corresponde al caso de uso descrito en la aplicacin de prueba de
concepto.
B. Desarrollo de un caso de uso de NFC: Un da en la vida de un usuario de NFC Alicia, usuaria de un telfono 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
99
telfono al lector NFC y registra el horario de ingreso. Luego mientras camina hasta el lugar de la reunin 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 telfono obtiene un cupn de descuento para compra del calzado publicitado. Cuando termina la entrevista, va a retirar su coche del estacionamiento, acerca su telfono al lector nuevamente y, previa confirmacin en el telfono, 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 parqumetro. En este caso, tambin acerca su telfono al parqumetro, el cual registra los datos de Alicia y la hora de inicio del estacionamiento. Alicia llega a la zapatera. All la mercadera est dispuesta en la vidriera de modo que cualquier cliente con su telfono NFC pueda leer la informacin 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 numeracin disponible de los modelos que le interesan, acercando su telfono a la vidriera. En base a esta informacin decide cul 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 crdito de su "billetera electrnica": acerca el telfono NFC al lector en la caja, elige la tarjeta de crdito y presenta el cupn de descuento, concluyendo la compra. Luego regresa a buscar su auto, acerca su telfono al parqumetro y se debita de su cuenta bancaria el monto correspondiente al estacionamiento. Por su parte, en el circuito de fabricacin de calzados, cada unidad de producto, incluye en la suela una etiqueta NFC que permite identificar a cada componente del par de zapatos unvocamente. 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 seal audible y luminosa ayudando en el guardado de la mercadera en su correspondiente caja. Las cajas as etiquetadas tambin facilitan la realizacin de controles de inventario peridicos en el local comercial mediante el uso de un telfono NFC que registra la mercadera existente en el depsito y luego la compara con la mercadera efectivamente consignada en el sistema informtico. Si bien toda la tecnologa necesaria para implementar este caso de uso est disponible, en un pas como Argentina hay cuestiones de carcter socio-econmico a resolver antes de poder implementarlo: Los dispositivos NFC an no son de consumo masivo. El acceso a Internet en celulares es lento y tiene un precio relativamente elevado para la poblacin en general. Mucha gente cuando sale de compras no lo hace como una tarea ms que tiene que ser rpida 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 ciudadana acerca de la responsabilidad en el cuidado de los bienes pblicos.
C. Dispositivos NFC En la actualidad los principales fabricantes de celulares han desarrollado modelos con soporte para NFC [17] que estn disponibles principalmente en Europa y Amrica del Norte. D. Pruebas piloto Desde hace unos aos se desarrollan pruebas piloto en diversos lugares del mundo con el fin de obtener informacin para desarrollar servicios basados en NFC acordes a las expectativas de la gente [18]. La mayor parte de las pruebas estn relacionadas con aplicaciones de pago en comercios minoristas o compras en expendedoras automticas. Otro gran porcentaje de pruebas es acerca del uso de smart posters para ofrecer informacin a los usuarios, publicidad o promociones y descuentos para usar en sus compras en comercios. Tambin se realizaron numerosas pruebas de aplicaciones para compra de pasajes en los medios de transporte pblico (mnibus, subterrneos, trenes) y en menor medida aplicaciones para compra de entradas a espectculos, estacionamiento y otras. IV. DESARROLLO DE APLICACIONES JAVA PARA DISPOSITIVOS NFC
A. Descripcin de la API para desarrollo de aplicaciones NFC (JSR-257) Los dispositivos mviles 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 informacin en contactless targets tales como smart cards, tags NFC y tags visuales (cdigos de barras) [20]. Un dispositivo con soporte para JSR-257 debe incluir todas las clases e interfaces definidas en esta especificacin pero no es requerida la implementacin de la funcionalidad de todos los targets, aunque si se implementa un target, es requerido que exista el dispositivo fsico correspondiente. La JSR-257 es una especificacin de referencia, luego cada fabricante puede implementar los componentes que desee y/o extenderla con soporte para contactless targets adicionales [21]. B. Aplicacin de prueba de concepto usando Nokia 6131 NFC En esta seccin se describe una aplicacin de prueba de concepto desarrollada para el telfono Nokia 6131 NFC, uno de los dispositivos disponibles comercialmente [22] que provee soporte para NFC mediante la implementacin de la especificacin 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 telfono y de las tarjetas y tags NFC.
100
El telfono 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 estn disponibles, los componentes Java que permiten la interaccin con estos targets.
La Fig. 3 muestra una vista esttica de la aplicacin distinguiendo con dos colores las clases propias de la aplicacin (gris) y las clases que forman parte de la API provista por el telfono (blanco).
Figura 3. Diagrama de clases Figura 2. Componentes de la JSR-257
2) Caso de uso Permitir al usuario domstico, usando su telfono celular NFC, la creacin de tags NFC2 adhesivos con informacin til para adjuntar a objetos de uso cotidiano. Estos tags podrn ser ledos luego usando tambin telfonos 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), nmeros telefnicos, direcciones web).
TABLA II. TAGS IMPLEMENTADOS EN NOKIA 6131 NFC Componente Java relacionado javax.microedition.contactless.visual (incluye solamente clases stub para cumplir con la JSR-257) com.nokia.nfc.nxp.mfstd.* com.sony.felica.Type3TagConnection com.nokia.nfc.nxp.desfire.* com.innovision.rf.JewelTagConnection com.nokia.nfc.nxp.mfstd.* com.nokia.nfc.nxp.mfstd.*
La Fig. 4 es una vista dinmica de la aplicacin que describe la interaccin entre las instancias de las clases (objetos) durante la ejecucin de la aplicacin. 4) Implementacin El uso de la JSR-257 se puede resumir en los dos pasos detallados a continuacin que luego tendrn mayor o menor complejidad dependiendo de la necesidad de la aplicacin. Los pasos se ilustran con fragmentos de cdigo tomados de la aplicacin de prueba de concepto. 1. Registrar un contactless target para que en el momento en que el telfono detecte la presencia de un tag (NDEF en este caso), notifique a la aplicacin a travs del mtodo targetDetected():
Tipo de Denominacin tag Visual (No implementado)
DiscoveryManager.getInstance().addTargetListener(this, TargetType.NDEF_TAG);
NFC Forum
Otros
Tipo 1 (Innovision Topaz) Tipo 2 (Mifare Ultralight) Tipo 3 (Sony FeliCa) Tipo 4 (Mifare DESFire) Innovision Jewel Mifare Standard 1K Mifare Standard 4K
2.
Implementar el listener correspondiente al tipo de eventos que se quieren recibir (TargetListener en este caso). La implementacin consiste en abrir una conexin con el target y realizar las operaciones de lectura/escritura necesarias.
public void targetDetected(TargetProperties[] tp) { ...
3) Arquitectura de la aplicacin La aplicacin de prueba de concepto permite crear tags y leer su contenido. Est basada en los principios de orientacin a objetos [23] y en su arquitectura se aplican tres patrones de diseo principales: MVC (Model View Controller), Singleton y Observer/Listener.
Una etiqueta de bajo costo para este uso es la Mifare Ultralight [23] ($6 a $10 por unidad, de acuerdo a la cantidad).
2
_ndefTagConnection = (NDEFTagConnection) .open(tp[0].getUrl(connections[i])); NDEFRecord[] records = new NDEFRecord[1];
Connector
NDEFRecord phoneNumber = new NDEFRecord(new NDEFRecordType( NDEFRecordType.URI, "tel:"+ DataController.getInstance().getPhoneNumber()), null, null); records[0] = phoneNumber; NDEFMessage message = new NDEFMessage(records);
101

_ndefTagConnection.writeNDEF(message); _ndefTagConnection.close(); ... }
En pases en vas de desarrollo como la Argentina, las posibilidades de esta tecnologa en el corto plazo son un tanto ms acotadas ya que salvo en las principales ciudades, no est generalizado el uso de tarjetas con RFID para pago de servicios, y menos an, de productos. Por otro lado, las empresas de telefona locales an no comercializan productos con NFC. Pero dado el elevado nmero de celulares de gama media que existen en la poblacin, se puede esperar que en el momento en que la tecnologa surja en el pas, rpidamente 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 tecnologa comience su incursin en el pas. REFERENCIAS
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] http://en.wikipedia.org/wiki/RFID United States Patent 3.713.148 - Cardullo, et al. (23-Enero-1973) http://www.telecomspace.com/wirelessnw-rfid.html http://mulliner.org/collin/academic/publications/vulnanalysisattacksnfcm obilephones_mulliner_2009.pdf ECMA-340 ECMA-352 ISO/IEC 14443 ISO/IEC 15693 http://www.nfc-forum.org/home http://www.nfcforum.org/resources/member_videos/NFC_Forum_14Feb07_Press_and_ Analyst_Briefing_Slides.pdf http://www.nfcforum.org/resources/presentations/NFC_Forum_Webcast-7Oct08NFC_For_Developers.pdf http://www.nfc-forum.org/resources/faqs/ http://www.nfc-forum.org/specs/spec_list/ http://www.nfc-forum.org/resources/N-Mark http://www.nfcforum.org/resources/white_papers/nfc_forum_marketing_white_paper.p df http://www.nfcforum.org/resources/white_papers/NFC_Forum_Mobile_NFC_Ecosyste m_White_Paper.pdf http://www.nfc-research.at/index.php?id=45 http://www.nfcnews.com/2009/07/14/nfc-pilots-and-implementations JSR-000257 http://www.forum.nokia.com/info/sw.nokia.com/id/8a11d3f9-306140dd-afb98ad417293ef3/Nokia_6131_NFC_Technical_Product_Description_v1_0 _en.pdf.html http://developers.sun.com/learning/javaoneonline/2008/pdf/TS-5635.pdf http://java.sun.com/developer/technicalArticles/javame/nfc/ http://www.smartcardfocus.com/shop/ilp/id~227/p/index.shtml Apuntes del mdulo de la ESE: "Algoritmos y Patrones" http://www.forum.nokia.com/piazza/wiki/images/6/6b/Nokia_NFC_whit e_paper.pdf
Figura 4. Diagrama de secuencia
V.
CONCLUSIONES
NFC es una forma de darle valor agregado a una tecnologa que existe desde hace ms de tres dcadas y que ya se ha impuesto en el mercado: RFID. La ventaja principal de NFC es no ser "una tecnologa ms" sino generar todo un nuevo modelo de negocio basado en infraestructura existente y ampliamente difundida (lectores de tarjetas en transportes, telefona pblica, etc.) y haciendo uso del dispositivo con ms mercado masivo en la ltima dcada, el telfono celular (si bien cualquier otro dispositivo electrnico puede incorporar NFC) [10]. Tambin se la puede ver como una tecnologa que trae nuevos usos para artefactos que desde hace tiempo no tienen innovacin por ejemplo, carteles, mobiliario, etc. [14]. Goza de cierta difusin en los pases ms avanzados de Europa, Asia y Amrica del Norte y todas las pruebas que se han realizado en los ltimos tres aos demuestran el inters de la gente por la tecnologa 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 tecnologa nueva, ha llegado a un grado de estandarizacin 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 anlisis y trabajo adicional es el relacionado a la seguridad en las transacciones. Este es el aspecto ms sensible para el usuario final y de l prcticamente depende la adopcin masiva en cuestiones relacionadas a pagos [25]. Pero ser solamente cuestin de tiempo y "evangelizacin", algo similar a lo ocurrido en su momento con las tarjetas de crdito y dbito, y luego la banca electrnica online.
[11]
[12] [13] [14] [15]
[16]
[17] [18] [19] [20]
[21] [22] [23] [24] [25]
102
Cost Effective Cross-layer Protocol Testing: A Case Study

Marcelo Odin Guirado , Jos e Pablo Escobedo , Ana Cavalli , St ephane Maag and Ariel Sabiguero Yawelak
de Computaci on, Facultad de Ingenier a Universidad de la Rep ublica, Montevideo, Uruguay e-mail: {modin|asabigue}@fing.edu.uy D epartement Logiciels-R eseaux TELECOM SudParis (ex INT), Evry, France email: {jose.escobedo|ana.cavalli|stephane.maag}@it-sudparis.eu
Instituto
AbstractModel-based testing has been successfully applied to conformance testing of reactive systems such as network protocols, both on general purpose and embedded systems. However, doubts persist about the overhead on time and human resources required. This work addresses the empirical quantication of model-based validation costs for medium and smallsized projects. In particular, it asseses the cost of model-based testing for cross-layer protocols. This paper presents how, in spite of some initial constraints in budget, human resources, time frame and available tools, it was possible to produce a formal specication or model, implement a fully functional prototype and test it for conformance with test cases derived from the model.
I. I NTRODUCTION Mobile devices support for wireless technologies and TCP/IP connectivity allows the access to services through a variety of networking infrastructures. However, TCP/IP was developed for wired networks and devices with sufcient resources (bandwidth, energy, etc) such as servers or desktop computers. A popular approach to improve the performance of TCP/IP over wireless mediums are cross-layer protocol optimizations. As a part of the SCAN [1] project a system was required to add cross-layer protocol optimizations to devices with constrained resources, such as embedded devices, while requiring minimum or no modication to the network protocol stack. Due to the intricacy of network protocols and the particular challenges of cross-layer design (high coupling, interaction among optimizations, etc), cost effective validation techniques and tools were required. Model-based testing [2], [3] has been successfully applied to conformance testing of reactive systems such as network protocols. However, time and human resources required may turn this approach inefcient. In this paper is described how model-based testing was applied to cross-layer protocol optimization in order to determine if it is a suitable and cost effective methodology for the problem domain. A prototype with a simple optimization protocol [4] was implemented. To address modularity and non intrusiveness
The work presented in this paper is the result of a French-Uruguayan cooperation, which was partially funded by the SCAN Project.
the ECLAIR [5] architecture was followed. Simulations and testing techniques were conducted to validate the system. Its specication was modeled in SDL [6] and test cases were semi-automatically derived from the model. An ad-hoc testing automation tool was built to run the test suite against the prototype. A full iteration -from concept phase to execution and validation- was accomplished within a tight schedule and with scarce resources. The time devoted to this iteration comprised the time to study tools and modeling language, to model the specication of the system, to build an implementation and to test it. The rest of this paper is organized as follows: in section II the methodology is presented. Cross-layer design and architectures were studied, as well as suitable means for validation such as verication and testing. In part III the cross-layer optimization protocol and its implementation are presented and discussed. In part IV the model of the system specication is briey described, an explanation on how it was used to validate and test the prototype is given, and the results in terms of cost are summarized. In part V conclusions are presented. II. M ETHODOLOGY Layered architecture, such the ISO OSI [7] model, divides networking software in layers which are collections of protocols with a specic function (such as binary transmission, physical addressing, logical addressing, and so on). Each layer provides services to the layer above and consumes services from the layer below through well dened interfaces. The layered architecture promotes the isolation among layers, and this modularity makes possible to replace implementations at each layer while maintaining the interfaces. TCP/IP protocol stack follows a similar layered architecture. However, for embedded devices and wireless communications resources such as bandwidth, energy, etc. become scarce. In order to optimize the utilization of these resources, higher layers may benet from information from lower layers and vice versa. Methodological grounds for this work are sketched in the rest of this section. Cross-layer design and architectures were
103
studied, as well as suitable means for validation like verication and testing. A. Cross-layer design and architecture Cross-layer design consists in violating layer isolation in order to offer feedback between a layer with information and another layer that can use this information to operate more efciently. An example of cross-layer optimization is ow control among MAC and transport layers [8]. Although cross-layer design have proven a popular approach to improve performance on wireless networks, there is a trade off between modular architecture and optimizations. There are various cross-layer architectures proposed in the literature that could help alleviate these problems, such as PMI [9], ICMP based [10], CLASS [11], CrossTalk [12], MobileMan [13], ECLAIR [5]. Each architecture proposes a different approach for signaling among layers, such as adding extra information at PDU, direct interaction among layers through function calls, a common network parameters repository, etc. The ECLAIR [5] architecture was chosen because it allowed non intrusive introduction of cross-layer optimizations (namely, it does not require modications on the network protocol stack), minimum stack overhead, extensibility, reversibility, portability and efciency. Furthermore, details were publicly available. ECLAIR separates the protocol implementation, residing in an optimization subsystem, from the interaction with the protocol stack, residing in a tuning subsystem. This allows any changes taking effect in the protocol stack to be isolated from the actual protocol. Inter layer feedback is achieved through notications of changes in protocol stack data structures. The optimization of the protocol stack behavior is achieved through changes of the network parameters through an API presented by the tuning subsystem, plus the algorithms in the optimization modules. There are some limitations to the scope of this architecture. Only asynchronous event detection is addressed through either notier chains or by polling the desired data structure with a pre-established frequency. Explicit synchronization of the network protocol stack and the optimizations protocols behavior is not addressed, which can lead to loops. Integrity of the data structures when concurrently accessed by the protocol stack and the optimization protocol is not addressed. B. Validation and Model-Based Testing As the terminology on validation, verication and testing is not always consistent in the literature, the meaning of these concepts in the context of this paper are presented here. To validate a system is to provide information that increases the condence in the hypothesis that the system was built correctly. The most popular approaches for validation are verication and testing. Verication is to interact with the model of a system (using the model for simulations or mathematically prove properties of the model), and testing is to perform experiments on an implementation of the system trying to nd defects.
It has been stated [14] that 50% of the defects are introduced in the coding phase of a software developing process, and only 15% are detected in design phase. Most defects are found during testing. The cost of correcting a defect is higher the later it is found. A consequence of this is that while it is important to use techniques to detect defects as early as possible (such as model checking or any verication techniques), it is on the testing phase of the actual implementations that most defects are found so both approaches are convenient and complementary. For this reason model-based testing paradigm was chosen. The goal of model-based testing is to reduce costs while developing quality software by automating the testing process as much as possible, in particular automating the test case generation. In order to do so, a formal model of the system specication is built and used to derive the test cases. This formal model is developed in parallel to the implementation of the system, thus the model could be veried and test cases generated while the system is still being implemented. The ioco [15] (input output conformance testing) theory is behind well known automated test case generation tools such as TGV [16], [17] and TorX [18]. The theory states that it is possible to establish the existence of a mathematical relation (namely, ioco) between a formal model (the model of the specication) and an implicit model corresponding to an actual implementation by probing the implementation. In practice, to prove conformance that way is not possible because any non trivial system would require a test suite too huge to make testing impractical. A compromise is achieved by restricting test case generation to certain parts/behaviors of the model specied as test purposes. The formal model is built in any of multiple formal specication languages such as SDL, LOTOS, IF, IOLTS, etc. In general the model used for test case generation differs from the model used for designing the system in that the rst is used to capture the behavior of the system while the later is used to capture the structure of the system. It also differs in the abstraction level, since the model used for test generation can ommit many details. Therefore, the model and the system can be built independently and simultaneously, and test cases can be obtained even before the system had been nished, shortening the time required for testing. Maturity in modeling for design is not required, actually the implementation could be developed from an informal specication of the requirements. However, it makes more sense to use model-based testing when the software development process has already automated the test execution. SDL [6] was chosen as the modeling language for the model of the system specication. SDL is known for its success in the telecommunications and protocol design domain [19] [20], as well as for the availability of tools to build models in that language. III. P ROTOTYPE In this section the cross-layer optimization protocol and its implementation are presented and discussed.
104
A. Use Case The optimization protocol that was chosen to be implemented [4] was presented along with the ECLAIR architecture proposal. Although a detailed description is beyond the scope of this work, a brief explanation follows. The selected use case consists in setting priorities for TCP connections that in turn determine the size of the receiver announced window in each connection, thus accelerating or slowing the sender, redistributing the throughput according to the priorities. It is based on the following relation: W indow . The receiver window is a T hroughput = RCV RT T parameter included in the TCP header which is adjusted depending the use of the receptor buffer to prevent the loss of packets. While in theory this approach may seem valid, in practice there are some aws. The size of the receiver announced windows represents the memory available for that connection, but memory is not taken into account when setting the size of the new announced window. When the size of the received segments is too small (for instance, interactive sessions) it is not a good idea to rise the size of the announced window because it would be lling the buffers mainly with control information. If the size of the receiver window is raised but the application cannot consume the received packets, the buffers will be lled 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). W indow does not contemThe model T hroughput = RCV RT T plate the probability of packets loss, which is not negligible in wireless networks, in particular for video transmissions or real time trafc. It could be argued that cross-layer feedback is not present, since the priority of the connections are set by a user. However, in the architecture the user is modeled as part of a user layer and its feedback is valuable as context information. While in this case priorities are set by a person, they could also be set automatically according to access policies for each user and/or application. The user layer and the interaction with the transport layer simplies the complexity of proper synchronization and monitoring of the network protocol data structures. B. Implementation An implementation of this use case is reported to exist for Linux 2.4.x, however it was not available and was not used in this work. Furthermore, there are many differences from GNU/Linux Kernels 2.4.x to 2.6.30 which was the latest Kernel available at the time of the implementation. The system was implemented in two parts. On the one hand, there is a program running in user space (a command line tool) to set the priorities for the connections. On the other hand, there is a Kernel module (implemented as a device driver), which can directly access and modify the Kernel data structure. It allows real time, user driven recalculation of the window size and modication the rcv ssthresh and
window clamp parameters for the connections. Note that per ow optimization did not allowed the use of /proc/net without modifying the Kernel, and such modications would affect the overall performance of the system. The prototype was implemented on archlinux over VirtualBox, with GNU/Linux Kernel 2.6.30, and was compiled with GCC 4.4.5. Cscope was used to analyze the Kernel code. The implementation is generic enough so that it can be reused and expanded with other optimizations, and can easily be ported to embedded systems. In the network protocol stack of the GNU/Linux Kernel there is a hash table accessible through the inet lookup function. inet lookup receives local and remote IP and port and returns a pointer to a sock, which is used to access the aforementioned parameters. This data structure and the functions in Kernel 2.4 (the Kernel version for which the use case was originally implemented) differs from the ones in GNU/Linux Kernel 2.6 (the Kernel version for which we developed our prototype). In Figure 1 is shown how the inet lookup is used. While future releases of the operating system might result in modications to the tunning layer, the optimization subsystem and the optimization protocol itself will remain unchanged. This is a strong point of the ECLAIR architecture.
static int set_receiver_window(u32 size, struct rwc_info_struct *conn_id) { struct sock *sk; struct net *red; struct tcp_sock *tp; int tama; sk = inet_lookup (red, &tcp_hashinfo, conn_id->ip_local, conn_id->puerto_local, conn_id->ip_remoto, conn_id->puerto_remoto, tama); if (sk!=0) { tp=tcp_sk(sk); lock_sock(sk); tp->rcv_ssthresh=size; tp->window_clamp=size; release_sock(sk); return(0);} else return(1); } Fig. 1. Setting the new receiver windows
While some experiments were conducted with the prototype, further experimentation is needed to establish its behavior in various real world scenarios. Since the use case was shown to have some aws, other more realistic cross-layer optimization protocols should be implemented and tested. Future work will include porting the system to other plaftorms such as OpenWRT and Android, and developing a SNMP interface to explore the possibilities of global crosslayer optimizations.
105
IV. T ESTING In this section the model of the system specication is briey described, an explanation on how it was used to validate and test the prototype is given, and the results in terms of cost are summarized. A. Model of the system specication The model of the use case was built with RTDS [21] by PragmaDev [22], following the ECLAIR architecture. It syntactically conforms the SDL-92 standard. A diagram in SDL can be seen in Figure 2 After the model was obtained, simulations were done in order to gain condence in the model. Further simulations were conducted for the test purposes in order to generate test cases. The system is composed of two blocks, a TL or Tuning Layer block for interacting with the protocol stack, and a OSS or Optimizing Subsystem that encompasses the PO or protocol optimizers. Inside the TL there are two process corresponding to the UTL or User Tuning Layer, and to the TCPTL or TCP Tuning Layer. Inside the OSS there is the RCWPO process, the receiver window protocol optimizer; here resides the optimization logic. The UTL receives signals indicating priority change in connections and noties the RCWPO. The RCWPO process receives signals that indicate a priority change has occurred, end emits signals for the TCPTL indicating that the window size must be changed and its new value. The TCPTL receives signals from the RCWPO and emits signals to the Kernel to change the appropriate data structures. The nomenclature for the components was taken directly from the ECLAIR architecture papers. B. Test case generation The RTDS tool provided an environment for simulations. From the simulations, MSC [23] corresponding to the test cases were generated. The MSC test cases were used as input to the tester and as part of the oracle to establish verdict of the tests. An example is shown in Figure 3 The input and outputs of the systems were modeled as signals as usual in SDL, and mapped to concrete inputs and outputs such as function invocations.This mapping was used to convert the MSC to input les to the tester. C. Testing architecture Testing architecture consists in the components to test, components of the tester, interaction points which are the interfaces of the IUT with the tester, which can be PO (Point of Observation, not to be confused with Protocol Optimizers from ECLAIR) or PCOs (Point of Control and Observation). In the SDL model, the tester exists at the environment. The tester has two parts: the Kernel (Kernel facilities are employed for registering the outputs) and the MTC which runs in user space, runs the test suites and emits the verdict. The IUT has two parts also, a Kernel module running the TCPTL
MTC UTL
IUT
RCWPO TCPTL Kernel
set_app_pty trap_pty_chg set_receiver_window tcp_hash_fn
Tester
Fig. 3. Fragment of MSC test purpose
MTC PCO
UTL
RCWPO & Kernel PO TCPTL
Tester
Fig. 4.
IUT
Testing Architecture
and the RCWPO, and the UTL in user space. The IUT includes the Kernel module (comprising the RCWPO and TCPTL) and the user space application for setting priorities (namely, the UTL).
set_app_pty FROM MTC, TO UTL (request the UTL to change the priority of a connection) app_pty_ok FROM UTL TO MTC (returns the result of the priority change) app_pty_err FROM UTL TO MTC Fig. 5. Signals exchanged at the PCO
tcp_hash_fn FROM TCP_TL TO Kernel (request the sock corresponding to a connection) tcp_hash_fn_value FROM Kernel TO TCP_TL (returns sock for the connection required) read_rcv_wnd FROM TCP_TL TO Kernel (request parameters of a sock for an established connection) read_rcv_wnd_value FROM Kernel TO TCP_TL lock_socket FROM TCP_TL TO Kernel set_wnd_clamp FROM TCP_TL TO Kernel set_rcv_wnd FROM TCP_TL TO Kernel release_socket FROM TCP_TL TO Kernel Fig. 6. Signals exchanged at the PO
There are two interfaces between the tester and the IUT, one PCO used by the MTC to interact feed the input to the UTL,
106
TL
USER_UTL
[app_pty_ok, app_pty_err] [set_app_pty]
OSS
RCW_UTL
[register_pty_chg, unregister_pty_chg, chg_pty_ok] [trap_pty_chg, pty_chg_reg_ok, pty_chg_unreg_ok]
UTL
RCWPO
TCP_TCPTL
[tcp_hash_fn, lock_socket, set_wnd_clamp, set_rcv_wnd, read_cnv_wnd, release_socket]
TCPTL
[tcp_hash_fn_value, read_rcv_wnd_value]
RCW_TCPTL
[get_receiver_window, set_receiver_window]
[set_receiver_window_ok, set_receiver_window_err, get_receiver_window_err receiver_window_val]
Fig. 2.
System diagram in SDL
and one PO to capture the output of the Kernel module in Kernel space when values of rcv ssthresh and window clamp are set. The signals exchanged at the PCO are listed in Figure 5, while the signals exchanged at the PO are presented in Figure 6. These signals are used at the abstraction level of the model. For running the test suite, the signals are mapped to concrete operations, such as can be seen in the following examples: The signal set app pty is mapped to
./userTL host_local port_local host_remote port_remote 2 2
userTL is a comand line utility to pass information to the UTL. The rst numeric value identies an operation (namely, set the pty) and the second the priority. For tcp hash fn, the actual operation performed is an invocation of inet lookup, a Kernel function. The most relevant parameters it receives are the local and remote IP and port, represented in network byte order by unsigned integers of 32 and 16 bits respectively, and a pointer to the hash info Kernel data structure
sock sk = inet_lookup(net, &hash_info, __be32 daddr, __be16 dest, __be32 saddr, __be16 source, int tama);
D. Test execution An ad-hoc testing automation tool was built and used as the Main Test Component. It is a bash shell script that parses an input le and executes the input. When there are no more inputs to process, it parses an output le where the system traces were recorded in order to establish a verdict. At the time of the test, only the type of the signals and the data types (not values) were considered for verdict. Note that the Kernel is part of the tester, for it receives the output of the system. This presents some challenges for capturing and logging the output. Since the receiver window is included in the TCP header, a simple solution would have been to capture the TCP packets by means of Wireshark or a similar tool. However, this solution does not account for the window clamp parameter. And,
formally, the TCP packets are not the output of the modeled system. In spite of the black box testing approach, the IUT was coded in a way that it wrote the outputs in the system log by means of the printk() function. A more appropriate solution would have been to intercept system calls and add a tracing facility before executing the actual code of the function. Intercepting system calls would be an incomplete solution, since the prototype changes the value of variables explicitly, not by means of a system call but by an assignment statement. Therefore it might require memory inspection for the addresses where the data structure are stored. These approaches have considerable potential but to keep on schedule were left for future work. Something lacking in this work was the automatic conversion of MSC into input le for the tester, the fully automatic generation of test cases and a general framework for test execution. For the general framework for test execution, TTCN-3 is the standard of the industry. TTCN-3[24][25] is the testing language promoted by the European Telecommunications Standards Institute (ETSI) which was designed for any kind of testing activity. There are commercial tools that generate test cases from models in SDL and MSC which can be converted to ATS in TTCN-3. These tools can be used to fully automate the test case generation and execution process. We note that Telelogic [26] and Verilog [27] were the major SDL tool vendors. Telelogic complemented its TAU tool suite with Autolink for test case generation. Verilog extended OBJECTGeode with TestComposer. Verilog was acquired by Telelogic, which in turn was acquired by IBM [28]. E. Results A two people team was assembled for the project, with no prior knowledge of modeling tools nor the modeling language and only minor knowledge on the problem domain. Thus the time devoted to learning is included in the cost of the project. An iterative incremental software development process was followed. In week 1, the specication of the system was
107
given. In weeks 2 and 3 the modeling language (SDL) for the formal specication was studied and the model of the system specication in SDL was produced. In week 3 the test cases were obtained from the model. In weeks 3 and 4 the prototype was implemented. In week 5 a test automation tool was implemented, and the prototype was tested. The project was evaluated. The hours/person were approximately 320. The UserTL module has 80 source lines of code and its compiled size was 2KB. The RWCPO plus the TCPTL module has 550 lines approximately and its compiled size was 9KB. V. C ONCLUSION A cross-layer architecture was selected and studied thoroughly. As a result, a fully functional prototype that introduced cross-layer optimizations in devices with constrained resources was implemented. The chosen architecture was validated, as well as the model-based testing methodology, a formal model was obtained and used to derive test cases. The work started with the model, followed with the implementation and nished with an operational prototype that was tested. Model-based testing approach, even without the fully automation of the test case generation proved a cost effective testing methodology even in a scarce resources situation, consisting of a two people team and a reduced time frame. The applied methodology does not require sophisticated software developing processes, even though it can benet from them in larger projects. The need for an appropriate framework for test execution became evident. Even though the test automation tool developed was adequate, it lacked exibility and portability and could not be used for a different project without some effort. The prototype followed the use case specication, was built according to the ECLAIR architecture and was successfully tested and validated. Therefore, the methodology, tools and modeling techniques were appropriate to the problem domain. To our knowledge the prototype was the rst use of the use case and architecture for recent versions of the GNU/Linux Kernel. The work took place on a virtualized environment for practical reasons. Despite of that, is directly applicable to hardware implementations of corresponding embedded devices implementing GNU/Linux. The model itself can be reused to include further optimizations or required renements to the current, and to derive more test cases. ACKNOWLEDGMENT The authors would like to thank Eduardo Gramp n who made this project possible. We would also like to thank Patrick S enac for the inspiration taken from his work. R EFERENCES
[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 Reactive Systems, ser. Lecture Notes in Computer Science. Berlin, Germany: Springer, 2005, no. 3472.
[3] Mark Utting and Bruno Legeard, Model-Based Testing: A Tools Approach. San Francisco, USA: Morgan Kaufmann, 2006. [4] V. T. Raisinghani, A. K. Singh, and S. Iyer, Improving TCP performance over mobile wireless environments using cross layer feedback, in IEEE International Conference on Personal Wireless Communications (ICPWC-2002), Delhi, India, Dec. 2002, pp. 8185. [5] V. T. Raisinghani and S. Iyer, Cross-layer feedback architecture for mobile device protocol stacks, IEEE Commun. Mag., vol. 44, pp. 85 92, Jan. 2006. [6] Specication and Description Language (SDL), ITU-T Recommendation Z.100. [7] Information technology - OSI - Basic Reference Model, ITU Recommendation X.200. [8] L. Zhang, P. S enac, E. Lochin, and M. Diaz, Mobile TFRC: a congestion control for WLANs, in The IEEE International Symposium on a World of Wireless, Mobile and Multimedia Networks (WOWMOM 2008), Newport Beach CA, USA, Jun. 2008, pp. 2326. [9] J. Inouye, J. Binkley, and J. Walpole, Dynamic network reconguration support for mobile computers, in Proceedings of the 3rd annual ACM/IEEE international conference on Mobile computing and networking, Budapest, Hungary, 1997, pp. 1322. [10] P. Sudame and B. R. Badrinath, On providing support for protocol adaptation in mobile networks, ACM Mobile Networks and Applications, vol. 6, pp. 4355, Jan. 2001. [11] QiWang and M. Abu-Rgheff, Cross-layer signalling for next-generation wireless systems, in Wireless Communications and Networking (WCNC), New Orleans, USA, Mar. 2003, pp. 10841089. [12] R. Winter, J. Schiller, N. Nikaein, and C. Bonnet, Crosstalk: cross-layer decision support based on global knowledge, IEEE Commun. Mag., vol. 44, pp. 9399, Jan. 2006. [13] M. Conti, G. Maselli, G. Turi, and S. Giordano, Cross-layering in mobile ad hoc network design, IEEE Computer, vol. 37, pp. 4851, Feb. 2004. [14] Christel Baier and Joost-Pieter Katoen, Principles of Model Checking, ser. Lecture Notes in Computer Science. Cambridge, USA: The MIT Press, 2008, no. 3472. [15] J. Tretmans, Test generation with inputs, outputs and repetitive quiescence, Software-Concepts and Tools, vol. 17, pp. 103120, Mar. 1996. [16] J. Fernandez, C. Jard, T. J eeron, and C. Viho, An experiment in automatic generation of test suites for protocols with verication technology, Science of Computer Programming Special Issue on COST247, Verication and Validation Methods for Formal Descriptions, vol. 29, pp. 123146, Jul. 1997. [17] C. Jard and T. J eron, TGV: theory, principles and algorithms, A tool for the automatic synthesis of conformance test cases for nondeterministic reactive systems, International Journal on Software Tools for Technology Transfer, vol. 7, pp. 297315, 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. 3143. [19] Ana Cavalli and Amardeo Sarma (Eds.), SDL 97: Time for Testing. Amsterdam, Netherlands: Elsevier, 1997. [20] Laurent Doldi, Validation of Communications Systems with SDL: The Art of SDL Simulation and Reachability Analysis. Wiltshire, Great Britain: 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 Specication (MTS); The Testing and Test Control Notation version 3; Part 1: TTCN-3 Core Language, ETSI ETSI Standard 201 873-1 v2.2.1. [25] Colin Willcock and Thomas Deiss and Stephan Tobies and Stefan Keil and 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://www01.ibm.com/software/rational/welcome/telelogic/
108
Robtica
109
110
Buti: Plataforma robtica genrica para la enseanza de la informtica

Gonzalo Tejera, Andrs Aguirre, Federico Andrade, Pablo Gindel, Santiago Margni y Jorge Visca {gtejera|aaguirre|fandrade|pablod|smargni|jvisca}@ng.edu.uy Instituto de Computacin, Facultad de Ingeniera, Universidad de la Repblica J. Herrera y Reissig 565, Montevideo, Uruguay
ResumenEl aprendizaje de la robtica en los niveles iniciales de la educacin es una herramienta poderosa para trasmitir a los profesores, estudiantes y sus familias conocimientos bsicos sobre las nuevas tecnologa y sus aplicaciones. Existen muchos mitos sobre las computadoras y los robots, desconocimientos bsicos tanto sobre lo que pueden como lo que no pueden hacer, en ambos sentidos, y que generan por un lado miedos infundados y por otro expectativas desmedidas. La incorporacin de los robots y de la inteligencia computacional se est dando de manera progresiva en nuestra sociedad, y es importante entonces contribuir a mejorar el conocimiento sobre estas tecnologas. Este artculo presenta una plataforma simple y econmica que permite a los alumnos de los liceos pblicos del Uruguay interiorizarse con la programacin de robots. Index TermsEducacin inicial, enseanza de informtica y robtica.
I.
I NTRODUCCIN
OS robots pueden ser una herramienta pedaggica poderosa y exible. Permite a los estudiantes realizar elaboraciones mentales de orden superior, reexionar sobre el por qu de las cosas, experimentar e identicar las repercusiones de las decisiones que se toman y comprenderlas. El proyecto Buti[1] desarrollado con fondos de la Agencia Nacional de Investigacin e Innovacin[2] crea una plataforma que permite a alumnos de liceos pblicos, en coordinacin con docentes e inspectores del Consejo de Enseanza Secundaria (CES)[3], interiorizarse con la programacin del comportamiento de robots. El proyecto provee a los liceos seleccionados por el CES una plataforma simple y econmica que permite a los alumnos denir el comportamiento de un robot, que proporciona ambiente ldico e idneo para que los estudiantes se interioricen con la programacin y la robtica. Es importante sealar que, en cuanto a la robtica, existe actualmente una profunda asimetra entre liceos pblicos y privados, extendindose de manera creciente la robtica en la currcula de muchas instituciones privadas. Esta propuesta pretende contribuir a disminuir esta brecha acercando este sistema robtico a instituciones pblicas de nivel secundario en las que hasta el momento, este tipo de sistemas no ha sido ampliamente incorporado. II. L A ROBTICA Y LA EDUCACIN
Dada la creciente importancia que tiene la tecnologa hoy en da y el amplio terreno que viene ganando la robtica
y la mecatrnica en la vida de las personas en el mundo desarrollado, resulta conveniente comenzar a incorporar estos conceptos en las primeras etapas de la formacin educativa de nuestros jvenes. En este sentido, es interesante ofrecer a alumnos de educacin secundaria la posibilidad de acercarse a nuevas tecnologas a travs del manejo de robots y lenguajes de programacin simples que les permitan controlarlos. Se espera con esta experiencia que los alumnos dispongan de un elemento ms para denir su vocacin hacia orientaciones Cientco Tecnolgicas. Programar los comportamientos de un robot mvil genera mucho inters para los adolescentes. Adems, les permite alcanzar resultados visuales inmediatos de sus programas, estimula su creatividad, as como al mismo tiempo se les ensean conceptos bsicos de programacin. Se entiende que el trabajo con robots, desde una perspectiva de la robtica pedaggica potencia el desarrollo del aprendizaje inductivo y por descubrimiento guiado; posibilita el diseo de situaciones didcticas que permiten a los estudiantes construir su propio conocimiento. [4] Esta propuesta busca generar entornos de aprendizaje centrados en la actividad de los propios estudiantes. Uno de los factores a destacar es la posibilidad de integracin de las diferentes reas, como matemticas, ciencias experimentales, comunicacin, losofa, entre otras, que amplan la propuesta de trabajo a nivel de los centros educativos, posibilitando que se desarrollen proyectos de n de ao integrando varias asignaturas al trabajo con los robots, como se propone en el plan de estudios vigente de bachillerato. Los alumnos de estos liceos podrn presentar los trabajos realizados sobre el sistema robtico en el marco del evento de robtica organizado por la Facultad de Ingeniera de la Universidad de la Repblica[5], simultneamente con trabajos realizados por alumnos y docentes universitarios, generando un rico ambiente de intercambio de experiencias y conocimientos. El proyecto Buti se apoya, en todo sentido, sobre las computadoras OLPC (One Laptop per Child)[6] proporcionadas al sistema de educacin pblico del Uruguay a travs del Plan Ceibal[7], llevado adelante por el gobierno nacional del Uruguay a partir del ao 2007. En la Figura 1 podemos apreciar una de las computadoras del mencionado plan sobre la plataforma Buti.
111
Figura 1.
La computadora OLPC sobre la plataforma Buti.
III.
A RQUITECTURA DEL LA PLATAFORMA B UTI
Figura 2.
Componentes de la arquitectura Buti.
Al momento de disear la arquitectura del sistema se tuvo como principal objetivo la portabilidad del mismo, ponderando plataformas con pocas prestaciones de hardware. Otro punto en el que se tuvo especial cuidado es en brindar una interfaz clara y simple que permita integrar la arquitectura del robot con diferentes lenguajes de programacin. Una vista simplicada de los principales componentes de la solucin puede visualizarse en la Figura 2. La arquitectura Buti consta de tres capas. Tomando en cuenta un enfoque botton-up, podemos identicar el nivel ms cercano al hardware, la primer capa (capa 1), encargada de interactuar con los sensores y actuadores. En esta capa se especican los servicios que el rmware brinda, adems estos servicios son agrupados de forma lgica en componentes de software llamados mdulos de usuario, los cuales son una abstraccin del sensor o actuador que se desea controlar en el robot. Estos componentes de software residen en el rmware de la placa de entrada/salida (E/S). La separacin entre esta capa y la siguiente est bien denida por un stack de protocolos, lo cual permite obtener un gran nivel de independencia del hardware subyacente. El prototipo construido es funcional con la placa de E/S Arduino y actualmente se presenta un gran nivel de avance con la placa USB4all [8]; adems se espera portar a otro tipo de plataformas como Handy Cricket, PicoBoard o GoGoBoard. Existe una segunda capa (DSI - descubrimiento e invocacin de servicios) que se encarga de descubrir de forma dinmica los mdulos presentes en la placa de E/S junto con los servicios o funcionalidades que estos brindan y una vez descubiertos son expuestos para poder ser consumidos por una aplicacin. Para permitir un uso ms verstil al momento de integrarse con diferentes lenguajes de programacin se realiz una tercer capa (capa 3), que ofrece estos servicios a un nivel mayor de abstraccin lo que posibilita que sean invocados en la red. Esta ltima capa permite interactuar con el robot desde cualquier lenguaje de programacin que tenga soporte de sockets. La arquitectura construida es genrica, permitiendo una
fcil extensin de sus funcionalidades independientemente del hardware de bajo nivel subyacente, as como portable a diferentes plataformas de bajos recursos de hardware. A diferencia de otras plataformas donde la lgica de control se desarrolla completamente en una placa de E/S microcontrolada, la arquitectura Buti fomenta un diseo hbrido, donde solo se implementa en la placa de E/S la interaccin directa con el hardware encapsulndolo en los mdulos de usuario, luego la lgica de control es desarrollada en un lenguaje de alto nivel en base a los servicios que estos mdulos exponen. Esto permite utilizar herramientas de mayor nivel de abstraccin, generando cdigo con un alto nivel de mantenibilidad y entendimiento, facilitando la comprensin por alumnos que se inician en las ciencias de la computacin. En la Figura 3 un nio de 9 aos trabaja en el comportamiento del robot Buti.
Figura 3.
Nio trabajando con la plataforma durante el sumo.uy.
La distribucin del sistema operativo instalado en las computadoras OLPC incluye diversos entornos y lenguajes de programacin. Entre ellos se encuentra el entorno de programacin grco Tortugarte[9] basado en el lenguaje LOGO[10].
112
En el marco del proyecto se extendi el lenguaje agregando una paleta para interactuar con la plataforma Buti. En la parte superior de la Figura 4 se muestra la paleta Buti integrada al entorno Tortugarte que permite controlar los motores y acceder a la lectura de los sensores. En la parte inferior de la misma se presenta un comportamiento para evitar obstculos utilizando el sensor Botn. Adems de esta extensin se desarrollaron APIs para los lenguajes de programacin Python, C y Lua.
3. Router Inalmbrico. Plataforma de costo y poder de cmputo mnimo prevista. Un ejemplo tpico es un router Asus 520GU. Consiste en un sistema embebido con un procesador Broadcomm, con 16MB de RAM y 8MB de almacenamiento Flash. En el marco del proyecto se realizaron pruebas con OpenWRT, una distribucin de Linux para sistemas embebidos. 4. Smartphones. Hay una gran cantidad de fabricantes y de plataformas de software. Usualmente contienen un procesador ARM, ms de 64MB de RAM y almacenamiento ash. El sistema operativo puede estar basado en Linux, Windows CE, u otros sistemas dedicados. 5. Sistemas basados en Single Board Computers (SBC), se espera que la arquitectura funcione en la placa BeagleBoard y Foxboard, para esta ltima tenemos actualmente un prototipo funcional. Se plantea la necesidad de disponer de un componente que pueda ser desplegado con mnimas modicaciones en todas las plataformas de inters, y que implemente las siguientes funcionalidades: Acceda a la placa de E/S implementando el protocolo USB4all sobre el tipo de conexin asociado (USB o Serial). Ofrezca una API que permita acceder las funcionalidades provistas por Buti desde las aplicaciones de usuario. Este componente se implement en Lua como dos componentes: una biblioteca que implementa la comunicacin con la placa (bobot), y una aplicacin que usa esta biblioteca y exporta su funcionalidad mediante un socket (bobot-server). Esta arquitectura es la solucin de referencia y de mxima portabilidad. El bobot accede la placa microcontroladora mediante USB o Serial. Para la primer opcin, se enlaza con libusb, una biblioteca portable de espacio de usuario para manipular dispositivos USB. Este enlace se realiza mediante un binding desarrollado, llamado lualibusb[12]. Para acceder mediante serial se utiliza una pequea librera en C que implementa una comunicacin orientada a mensajes, llamada serialcomm. Bobot es fcilmente extensible para agregar soporte a nuevos mdulos de la placa controladora (USB4all/Arduino). Esto se logra mediante drivers cargados dinmicamente de acuerdo a los mdulos declarados por la placa controladora. En las plataformas robticas comercialmente ms difundidas, el usuario debe llevar nota de qu dispositivo conect en cada puerto de comunicacin y declararlo en algn punto de la estructura del software. Esto diere radicalmente respecto a la capacidad de auto-conguracin o plug&play (PnP) de la plataforma Buti. La idea es exponer al usuario las capacidades sensoriales y de actuacin del robot Buti, de una forma ordenada que facilite su aprovechamiento evitando etapas de conguracin. Siguiendo estos principios se diseo un conector PnP exible, en el cual se puedan conectar tanto sensores como actuadores, analgicos como digitales, PWM e incluso I2C. Dicho conector dispone entre otros de pines de identicacin los cuales se cablean a vcc o gnd directamente
Figura 4.
Evitando obstculos con Tortugarte.
IV. I MPLEMENTACIN DEL PROTOTIPO Con el objetivo de cumplir con los requerimientos de portabilidad, los componentes de software que tienen interaccin directa con el hardware fueron implementados utilizando el lenguaje de programacin ANSI C, esto permite lograr tener mayor control sobre el hardware y minimizar las latencias vinculadas con los tiempos de comunicacin. La lgica de mayor nivel de abstraccin y ms propensa a cambios, se realiz utilizando el lenguaje interpretado Lua[11]. Lua es un lenguaje de gran nivel de abstraccin, su mquina virtual es muy pequea y esta desarrollada en ANSI C lo que permite portarlo fcilmente a diferentes arquitecturas, particularmente en aquellas con bajas prestaciones de hardware. Dado que es un lenguaje interpretado el software desarrollado utilizando su maquina virtual es sumamente verstil, evitando generar binarios para las distintas arquitecturas como es usual en otros lenguajes, lo cual es un gran benecio al momento del desarrollo, simplicando el testing y puesta en produccin sobre la plataforma objetivo. Tambin existe una versin de Lua, llamada eLua pensada para sistemas con an menos recursos como microcontroladores. Se espera que Buti soporte al menos las siguientes plataformas: 1. OLPC. Esta es la plataforma del Plan Ceibal. El hardware contiene un procesador AMD Geode, con arquitectura x86. Los primeros modelos posean 256MB RAM actualmente ya disponen de 512MB. El disco duro es de estado slido de 1GB. El software consiste en un kernel Linux con Sugar como interfaz de usuario. 2. Intel Classmate. Es la plataforma para enseanza de Intel, y es un nombre genrico para una lnea de productos de distintos fabricantes. El hardware es tpico para un netbook de bajo costo: procesador Intel Atom (x86), a partir de 512MB de RAM, disco duro magntico.
113
investigando es en permitir compartir un robot entre varias mquinas brindando los mecanismos necesarios para arbitrar el acceso al mismo. Por ltimo se estn consiguiendo grandes avances en portar la arquitectura a plataformas embebidas tipo ARM como son FoxBoard y BeagleBoard. VI. C ONCLUSIONES
Figura 5.
Interaccin entre el sistema Buti y la placa de E/S.
o a travs de resistencias, logrando diferenciar el tipo de dispositivo conectado. Ventajas del uso de los conectores PnP Buti: Constituye una potente herramienta de diagnstico. Simplica el acceso al hardware. Permite que el rmware seleccione automticamente el mdulo adecuado para manejar cada tipo de dispositivo. Se diseo una placa adaptadora a la controladora de E/S que dispone de ocho conectores PnP Buti, y en forma separada el conector para el bus Dynamixel (que tambin cuenta con auto-deteccin) y un conector de potencia para dos motores de continua o un motor de paso. Un ejemplo concreto de implementacin es el que podemos ver en el Cuadro I
Cuadro I E SPECIFICACIONES DEL ROBOT B UTI . Elemento Motores Control de bajo nivel Control de alto nivel Chasis Amortiguacin Sensores Instancia Dynamixel AX12 Arduino Mega Computadora OLPC Acrlico 5mm Placa acero alto carbono 0.5mm Kit DFRobot para Arduino y sensores Sharp
Se dise una arquitectura que brinda un enfoque genrico e independiente del hardware de control. Esta arquitectura permite desarrollar el comportamiento del robot Buti mediante lenguajes de programacin de fcil acceso y comprensin para estudiantes liceales como es Tortugarte. De todas formas al estar modularizado y bien denido el alcance de cada capa, as como el API para acceder a cada una de ellas, existen diferentes niveles en los cuales el alumno puede desarrollar el comportamiento, dependiendo de su nivel de conocimientos, llevando esto a la programacin de nuevos mdulos de usuario en el rmware, as como programacin en otros lenguajes como Lua, Python, Java. Actualmente se ha logrado un nivel suciente de madurez en el sistema, se dispone de 30 robots en produccin distribuidos en todo el pas. Desde el punto de vista social, a travs de este proyecto se logra acortar la brecha para los que por razones econmicas no pueden alcanzar dichas tecnologas. En este sentido se logra un proyecto con un n democratizador. R EFERENCIAS
[1] Buti, Proyecto buti, Agosto 2010, http://www.ng.edu.uy/inco/proyectos/butia/. [2] ANII, Agencia nacional de investigacin e innovacin, Febrero 2011, http://www.anii.org.uy/web/. [3] CES, Centro de educacin secundaria, Febrero 2010, http://www.ces.edu.uy/ces/. [4] S. Colorado, M. Mara, and A. Gauthier, Ambientes de aprendizaje con robtica pedaggica, Ingeniera Elctrica y Electrnica - Universidad de los Andes, Memo de Investigacin IEL 2003-001, 2005. [5] sumo.uy, Campeonato de sumo robtico, Agosto 2010, http://www.ng.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. Fernndez, and C. Grossy, Interfaz usb genrica para comunicacin con dispositivos electrnicos, 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.
Utilizando la informacin de PnP es posible desde la interfaz de Tortugarte colorear los elementos de la plataforma Buti de diferentes colores dependiendo si se encuentra o no conectados al robot. Esta caracterstica permite que los usuarios puedan detectar rpidamente errores de hardware, reduciendo las frustraciones generadas por este tipo de situaciones. V. T RABAJO A F UTURO
Actualmente se estn logrando grandes avances con la integracin de la cmara web de la XO como un sensor ms, se han realizado pruebas de factibilidad que permiten identicar colores y retornar sus coordenadas. Tambin se est trabajando en agregar el micrfono de la XO al universo de sensores. En este sentido se estn realizando pruebas para poder procesar el lenguaje natural y permitir programar el robot mediante el uso de la voz. Otro aspecto interesante en el cual se est
114
Librer as embebidas para microcontroladores LPC2000 de aplicaci on en rob otica

Gonzalo F. Perez Paina, David A. Gaydou, N estor L. Palomeque, Lucas A. Martini
Centro de Investigaci on en Inform atica para la Ingenier a, C.I.I.I. Universidad Tecnol ogica Nacional, Facultad Regional C ordoba, UTN-FRC Email: gperez@scdt.frc.utn.edu.ar
AbstractEn el presente trabajo se describe el desarrollo de librer as embebidas para microcontroladores NXP con nucleo ARM7. Las mismas se dividen en M odulos de perif ericos y M odulos de software que implementan algoritmos espec cos. Los M odulos perif ericos permiten la abstracci on del modelo particular de microcontrolador para acceder mediante funciones de alto nivel a los diferentes perif ericos como GPIO, Timers, UART, etc. Los M odulos de software implementan algoritmos de utilidad rea de rob para aplicaciones del a otica, sensor stica y control, como por ejemplo, la comunicaci on serial punto a punto mediante pticos incrementales, paquetes, medici on de senales de encoders o controladores PID, etc. Adem as, se presenta un caso de aplicaci on en el que fueron utilizadas las librer as, m as precisamente en un robot m ovil de tracci on diferencial de construcci on propia. Su utilizaci on muestra ser lo sucientemente exibles para agilizar desarrollo y prueba de aplicaciones embebidas. el diseno,
I. I NTRODUCTION Para el desarrollo de software de sistemas embebidos es de principal importancia contar con herramientas exibles, que brinden la posibilidad de realizar modicaciones a la aplicaci on con un m nimo esfuerzo. Esto permite elegir la mejor implementaci on en sistemas donde se requiere m axima conabilidad y desempe no. Una de las necesidades fundamentales para el desarrollo de software embebido es poder contar con librer as tanto para los perif ericos particulares de la familia de microcontroladores utilizada, as como de algoritmos de uso rea en particular. com un en alg un a En el laboratorio de electr onica del Centro de Investigaci on en Inform atica para la Ingenier a (C.I.I.I.), se llevan a cabo desarrollos de sistemas embebidos en el marco de diferentes proyectos de investigaci on, principalmente en rea de rob el a otica, sensor stica y control. Una evoluci on natural en el desarrollo de dichos sistemas fue comenzar a utilizar microcontroladores de 32 bits, que permitan desarrollar programas capaces de realizar cierta cantidad de c alculos en tiempos razonables para dichas aplicaciones. Una de las primeras incursiones en este tipo microcontroladores se realiza utilizando arquitectura de n ucleo ARM7, m as precisamente los de la familia LPC21XX [1] de la marca NXP. En el presente trabajo se describe el desarrollo de librer as para sistemas embebidos, las cuales han sido pensadas principalmente para cubrir los requerimientos del laboratorio del reas de aplicaci C.I.I.I., en a on particular. Estas librer as, como se comentar a m as adelante, se dividen en una parte para el manejo de hardware y otra de algoritmos particulares de gran
utilidad en los proyectos del Centro. Como principal objetivo en su desarrollo se tiene la abstracci on del hardware y se ha prestado principal atenci on en el modo que se articulan los diferentes M odulos (de hardware y algoritmos) para que resulten exibles, f acil de mantener y modicar, lo que promuevan la reutilizaci on de software. La secci on II presenta una descripci on general de los diferentes M odulos de software de las librer as ciiiemblibs y su relaci on. La secci on III presenta los m odulos perif ericos o de manejo de hardware en detalle, y la IV los m odulos en desarrollo. La secci on V describe los m odulos especiales o de algoritmos, junto con su relaci on con los M odulos perif ericos. En la secci on VI se muestra un caso de aplicaci on en la ltimo en la secci utilizaci on de las librer as. Y por u on VII se presentan las conclusiones del trabajo. GENERAL II. D ESCRIPCI ON Las librer as embebidas denominadas ciiiemblibs por su desarrollo dentro del Centro de Investigaci on en Inform atica para la Ingenier a, se encuentran divididas en dos grupos principales: por un lado los m odulos para perif ericos, cuyo
Fig. 1.
Organizaci on y relaci on de los diferentes m odulos de las librer as
115
objetivo es controlar los dispositivos particulares de los microcontroladores LPC21XX y por otro lado los m odulos especiales, que cumplen funcionalidades particulares e independiente del modelo de microcontrolador utilizado, pudiendo ser compilados para otras arquitecturas. Una representaci on esquem atica de esta divisi on se puede apreciar en la Fig. 1. Dentro de los M odulos perif ericos podemos nombrar: M odulo para entrada-salida o simplemente GPIO, es el encargado de comandar los puertos de salidas y entradas digitales. M odulo para temporizadores o TIMER, maneja los temporizadores y la funcionalidad capture. M odulo para comunicaci on serial o UART, trabaja con el puerto serial del microcontrolador. M odulo para el manejo de interrupciones o IRQ, se encarga de comandar las interrupciones vectorizadas. M odulo para el manejo del modulador de ancho de pulso o PWM, manipula el modulador de ancho de pulso del microcontrolador. M odulo para la conversi on anal ogico-digital o ADC, trabaja con el conversor del microcontrolador. M odulo In-Application Programming o IAP, se encarga de la escritura de datos en memoria no vol atil. En cuanto a los M odulos especiales o de algoritmos tenemos: M odulo de comunicaci on mediante datos empaquetados o COMMUNICATION, es un protocolo de comunicaci on entre dos dispositivos. M odulo para el manejo de encoders o ENCODER, para pticos incrementales. la decodicaci on de encoders o M odulo Controladores, realiza el c alculo de un controlador proporcional-integral-derivativo. Las librer as fueron desarrolladas en lenguaje ANSI-C separadas en diferentes m odulos (archivos .h y .c) para cada uno de los M odulos perif ericos o especiales indicados anteriormente. Cada una de las funciones de los diferentes m odulos comienza con el nombre del M odulo para poder identicar a qu e m odulo pertenece la funci on, por ej. las funciones de inicializaci on de algunos de los M odulos son: para el M odulo GPIO gpio_init(), para el M odulo PWM pwm_init(), para el M odulo de comunicaci on com_init(). Adem as, las librer as incluyen ejemplos de utilizaci on de cada uno de los M odulos que soporta. RICOS III. M ODULOS PARA PERIF E Estos m odulos se desarrollaron para un manejo simple y transparente de los perif ericos del microcontrolador LPC21XX. En las subsecciones siguientes se describen los m odulos perif ericos aplicados espec camente al microcontrolador modelo LPC2114/24. A. M odulo para entrada-salida El microcontrolador NXP LPC2114/24 posee dos puertos de prop osito general: Port0 y Port1, de los cuales el primero dispone de 30 pines y el segundo de 16, siendo un total 46
pines de entrada/salida, todos estos pines se encuentran multiplexados con diferentes funciones de otros m odulos perif ericos del microcontrolador. El M odulo software para entrada y salida contiene funciones que inicializan los pines del microcontrolador como entrada/salida de prop osito general ( o GPIO como sus siglas en ingl es), se congura si el pin se va a utilizar como una entrada o como una salida digital; en el caso de un pin de entrada digital el M odulo permite leer su estado, y en el caso de un pin de salida el M odulo permite establecer un estado l ogico (alto o bajo) a la salida del pin. Algunas de las funciones del m odulo son gpio_init(), gpio_set() y gpio_toggle(). B. M odulo para temporizadores El microcontrolador NXP LPC2114/24 posee dos temporizadores o Timers. Estos temporizadores son independientes e id enticos, adem as cada Timer dispone de hasta 4 canales de captura que permiten almacenar, en un registro dedicado a esto, el valor del Timer Counter cuando se produce una transici on en la se nal de entrada de estos canales. Tanto el Prescaler, como el Timer Counter y los Registros de Captura son de 32 bits. Este M odulo software permite congurar y controlar ambos Timers del microcontrolador. La codicaci on de la misma se centra principalmente en el modo de cuenta de intervalos de tiempo entre eventos. En esta librer a tambi en se encuentra codicado el modo particular Capture. Algunas de las funciones del m odulo son timer_init(), timer_get(), timer_enable_interrupt(), timer_disable_interrupt(). C. M odulo para comunicaci on serial El microcontrolador NXP LPC2114/24 posee dos UART (Universal Asynchronous Receiver-Transmitter). La UART0 nica en Null Modem, permite una conguraci on interna u por ende no realiza control por hardware de la transmisi on/recepci on de sus datos. En cambio, la UART1 s dispone de un control de ujo de datos por hardware, del cual se puede hacer uso. El M odulo software correspondiente permite congurar la UART0 y UART1 del microcontrolador, no obstante, en esta instancia solo est a desarrollado el empleo en conguraci on Null Modem para ambas UARTs. Este M odulo posee un conjuntos de funciones que permiten congurar la frecuencia (Baud Rate) de la comunicaci on, la cantidad de bytes a transmitir, el tipo de paridad, la cantidad de bits de stop y el tama no de memorias intermedias (FIFO). Tambi en implementa rutinas que permiten la trasmisi on y la recepci on de datos, adem as de controlar las distintas fuentes de interrupciones, haciendo uso del M odulo de software IRQ para el manejo de interrupciones para la conguraci on de las mismas. Posee una implementaci on por callbacks para la atenci on de las posibles fuentes de interrupciones, lo que facilita la tarea del programador.
116
Fig. 2.
Modos de funcionamiento del PWM
A. M odulo In-Application Programming (IAP) Esta librer a se desarrolla con la intenci on de poder almacenar datos sobre la memoria ash del microcontrolador LPC2114/24. En la actualidad se encuentran completamente codicadas y se encuentra en etapa de evaluaci on para ser agregadas a la librer a. B. M odulo para la conversi on anal ogico-digital Este M odulo permite realizar la conversi on de se nales anal ogica a digital para aplicaciones de adquisici on de datos. Actualmente las funciones en desarrollo permiten obtener valores del conversor a requerimiento de la aplicaci on. Se planea agregar las funciones necesarias para los diferentes modos de funcionamiento del M odulo perif erico ADC. V. M ODULOS E SPECIALES Los M odulos especiales implementan algoritmos de utilidad en diversas aplicaciones de sistemas embebidos. Algunos de estos M odulos hacen uso de los M odulos perif ericos pero son independientes de los mismos. A. M odulo de comunicaci on mediante datos empaquetados Permite la transferencia de datos entre dos dispositivos cuyas velocidades de procesamiento son muy diferentes, como ser una aplicaci on en una PC y la aplicaci on embebida. La implementaci on provee rutinas para lectura y escritura de datos en forma de paquetes, por parte de la aplicaci on principal. Tambi en hace uso de callbacks correspondientes al dispositivo f sico o l ogico utilizado en el otro extremo de la conexi on de la librer a. A los datos enviados a la interfaz de salida, el M odulo agrega caracteres de inicio y tama no del paquete como parte del protocolo. En la Fig. 3 se puede ver c omo se conforma un paquete. La operaci on de la transmisi on y recepci on emplea la mec anica de productor-consumidor, actuando sobre un buffer circular intermedio implementado en el M odulo y coordinado a trav es de una variable protegida incrementada por el productor y decrementada por el consumidor. En t erminos generales la rutina del productor carga los caracteres secuencialmente en el buffer interno, arma los paquetes, chequea los desbordes, controla la circularidad e incrementa la cuenta de paquetes (variable compartida). La rutina del consumidor extrae los caracteres secuencialmente, liberando el espacio en el buffer, controla la circularidad y decrementa la cuenta de paquetes (variable compartida).
Algunas de las funciones del m odulo son uart_init(), uart_set_baudrate(), uart_send_byte(), uart_receive_byte(). D. M odulo para el manejo de interrupciones El Controlador Vectorizado de Interrupciones ( o VIC por sus siglas en ingl es) del microcontrolador LPC2114/24, posee treinta y dos entradas y solicitud de interrupci on programable en tres categor as nombradas a continuaci on en orden de prioridad: FIQ (Fast Interrupt reQuest), IRQ vectorizada, y IRQ no vectorizada. La librer a desarrollada congura las interrupciones IRQ vectorizadas. Actualmente no opera sobre las interrupciones FIQ e interrupciones IRQ no vectorizadas. Las interrupciones vectorizadas IRQ son b asicamente un vector de 16 elementos, donde cada elemento constituye una funci on interrupci on que atiende el servicio de cualquiera de las posibles fuentes de interrupci on. La mayor prioridad de este vector comienza con el primer elemento. Algunas de las funciones del m odulo son irq_vect_init(), irq_vect_enable(), irq_vect_disable(). E. M odulo para el manejo del modulador de ancho de pulsos El M odulo perif erico PWM del microcontrolador LPC2114/24 posee dos modos de funcionamiento: simple anco, en el cual solo se puede controlar el anco de bajada y doble anco, que permite controlar tanto el anco de subida como el de bajada, como se indica en la la Fig. 2. Las funcionalidades del microcontrolador permiten hasta seis salidas de simple anco, tres salidas de doble anco, o una combinaci on de ambos tipos. Este M odulo actualmente se centra en el modo de funcionamiento de simple anco de los seis PWM disponibles en el microcontrolador. Las funciones de este M odulo permiten congurar la frecuencia de la se nal de PWM, y en cualquier instante poder modicar el ciclo de trabajo o conocer el valor del ciclo de trabajo actual. Algunas de las funciones del m odulo son pwm_set_on(), pwm_set_off(), pwm_set_value(). RICOS EN DESARROLLO IV. M ODULOS PARA PERIF E
Fig. 3.
Paquete de datos de la librer a COMMUNICATION
Estos M odulos se encuentran en etapa de desarrollo por lo que se presentan aqu , a modo explicativo, la funcionalidad que tendr an una vez nalizados.
Algunas de las funciones del m odulo son com_init(), com_send_packet(), com_receive_packet().
117
Fig. 4.
Robot M ovil de Arquitectura Abierta, RoMAA
Fig. 5.
Controlador embebido del robot RoMAA con C ARM LPC2124
B. M odulo para el manejo de encoders ptico incremental es un sensor que permite Un encoder o detectar el movimiento de rotaci on de un eje a trav es de sus salidas correspondientes a dos se nales llamadas Fase A y Fase B, las cuales son trenes de pulsos desfasadas 90o . El objetivo de esta librer a consiste en crear un m odulo funcional para la lectura de este tipo de sensores. Este M odulo permite decodicar las se nales del encoder [2] y as poder determinar el sentido de avance y la cantidad absoluta de pulsos del eje del cual se quiere controlar la rotaci on. Algunas de las funciones del m odulo son encoder_init(), encoder_update(). C. M odulo software CONTROLADORES Actualmente este M odulo implementa un controlador PID [3] (Proporcional Integrativo Derivativo) que permite ajustar los valores de desempe no de un sistema de lazo cerrado a las necesidades de la aplicaci on. Este M odulo realiza los c alculos en base a la implementaci on en tiempo discreto de la ec. (1): Rn = Rn1 + + + KP (en en1 ) en + en1 KI 2 KD (en 2en1 + en2 ) Arquitectura Abierta o RoMAA [4], el cual puede verse en la Fig. 4. El sistema de control embebido, mostrado en la Fig. 5, del robot m ovil RoMAA se basa en un microcontrolador LPC2124, para cuyo desarrollo se utilizaron en su totalidad las librer as del presente trabajo. El sistema de tracci on se basa en motores de corriente continua alimentados mediantes drivers de potencia de llave H, comandados desde se nales de PWM utilizado con el M odulo correspondiente. Para el control de velocidad de dichos motores se utiliza un lazo de control a partir de mediciones de pticos incrementales acoplados mec encoders o anicamente a los motores; la medici on de velocidad se realiza mediante la funci on de Capture del Timer del microcontrolador, con el m odulo adecuado, adem as de la librer a de encoders, para tener un registro de los pulsos y sentido de giro de los motores. Esta informaci on se integra luego en lo que se conoce como odometr a [5]. El sistema de control incluye tambi en un lazo externo en conguraci on cross-coupling para obtener trayectorias en l nea recta o arcos, y poder comandar al veh culo con velocidad lineal y angular. Los comandos hacia el controlador e informaci on del mismo se obtienen desde la PC a bordo del robot, mediante la comunicaci on serie utilizando la librer a UART y COMMUNICATION, la cual se encarga del protocolo de comunicaci on. Adem as, se hace uso del resto de las librer as, como GPIO para el control de los puertos utilizados, TIMER para generaci on de bases de tiempo e implementaci on de la funcionalidad capture e IRQ para la manipulaci on de interrupciones. La necesidad de poder medir la carga de la bater a de la que se abastece el robot RoMAA y poder as tener un control del posible estado inoperante del mismo, surge el desarrollo actual, de la librer a ADC. De manera similar surge la librer a IAP, para poder almacenar datos, como las constantes del PID, en memoria no vol atil.
(1)
donde KP , KI y KD son las constantes proporcional, integral y derivativa respectivamente, Rn es la salida actual, Rn1 es la salida anterior y en es el error actual. Algunas de las funciones del m odulo son pid_init(), pid_update(). VI. E JEMPLO DE APLICACI ON La totalidad de los M odulos explicados anteriormente est an siendo utilizados en diferentes proyectos dentro del Centro de Investigaci on en Inform atica para la Ingenier a, pero cabe mencionar uno de los m as importantes, el Robot M ovil de
118
VII. C ONCLUSIONES Las librer as embebidas ciiiemblibs est an siendo utilizadas actualmente en diferentes proyectos del laboratorio de electr onica del C.I.I.I., relacionados a rob otica, sensor stica y control. La utilizaci on de las mismas muestra que cumplen con el objetivo planteado al inicio del proyecto. Por un lado la utilizaci on de los M odulos perif ericos facilita la implementaci on de nuevas aplicaciones mediante la abstracci on del hardware, lo que reduce la necesidad de consultar constantemente el manual del microcontrolador, para el caso de los m odulos perif ericos. Y por otro lado, los M odulos de software o algoritmos permiten exibilidad en las etapas de pruebas al inicio de los proyectos, como por ejemplo la librer a de comunicaci on que es de gran utilidad en la depuraci on de aplicaciones. Adem as, las librer as de M odulo software pueden ser utilizadas en diferentes arquitecturas de microcontroladores, debido a que son independientes del hardware. La utilizaci on de las librer as ciiiemblibs permiten gran exibilidad en las etapas iniciales de dise no y evaluaci on necesarias en el desarrollo de nuevos proyectos. R EFERENCES
[1] NXP Semiconductors. UM10114. LPC21xx and 22xx User Manual, April 2007. [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 Applications with Embedded Systems. Springer Publishing Company, Incorporated, 2008. [4] D. A. Gaydou, G. F. P erez Paina, G. M. Steiner, and J. Salomone. Plataforma m ovil de arquitectura abierta. In Proceedings of the V Argentine Symposium of Robotics 2008. Ediuns, 2008, November 2008. [5] E. Olson. A primer on odometry and motor control. Technical report, Massachusetts Institute of Technology, 2007.
119
Filtro complementario para estimaci on de actitud aplicado al controlador embebido de un cuatrirrotor

David Gaydou, Javier Redol y Agust n Henze
Centro de Investigaci on en Inform atica para la Ingenier a Universidad Tecnol ogica Nacional - Facultad Regional C ordoba dgaydou@scdt.frc.utn.edu.ar
e impleResumenSe presentan los resultados del diseno mentaci on de un sistema de estimaci on de actitud para un robot aut onomo volador de cuatro rotores utilizando para dicha estimaci on, primero en forma independiente un aceler ometro y un gir oscopo de tecnolog a MEMS, y luego fusionando las mediciones de ambos sensores mediante un ltro complementario. Index TermsCuadric optero, Gir oscopo, Aceler ometro, Filtro complementario.
I.
I NTRODUCCI ON
A continuaci on se presenta un sistema para estimaci on de actitud de un robot volador aut onomo (UAV, Unmanned Aerial Vehicle) de cuatro rotores capaz de despegar verticalmente y realizar vuelos estacionarios que est a siendo desarrollado en el Centro de Investigaciones en Inform atica para la Ingenier a (C.I.I.I.) en la Facultad Regional C ordoba de la Universidad Tecnol ogica Nacional. Este robot est a dise nado para ambientes interiores como as tambi en exteriores con condiciones til de 1 Kg. El atmosf ericas limitadas. Se prev e una carga u sistema de control de estabilidad est a implementado en un microcontrolador LPC2114 de NXP. Este controlador consta de dos lazos anidados, el lazo interno controla la actitud de la aeronave y el externo genera referencias para el lazo interno a n de controlar la posici on. El lazo interno consta de tres compensadores proporcional, integral y derivativo (PID) ngulos de cabeceo () y digitales, dos para controlar los a ngulos rolido () y el tercero para la orientaci on ( ). Estos 3 a ngulos de navegaci son conocidos como a on. El sistema de lazo cerrado para y tiene un ancho de banda te orico de ngulos debe 15 Hz. El mecanismo de medici on de estos a poseer una frecuencia de corte por encima de este l mite para no comprometer la estabilidad ni degradar el desempe no din amico. Para determinar la inclinaci on se utilizan aceler ometros tipo MEMS, que poseen numerosas ventajas para esta aplicaci on, como ser buen ancho de banda, suciente resoluci on, peso reducido, robustez y bajo costo. Mediante estos sensores es posible determinar la direcci on y el sentido del vector de aceleraci on de la gravedad respecto a un marco de referencia jo en la aeronave. La desventaja fundamental de estos sensores radica en que las mediciones son fuertemente afectadas por las vibraciones en la estructura donde se encuentran montados. Otra alternativa para medir la inclinaci on es computar la rotaci on integrando la se nal de sensores girosc opicos. Por
las mismas razones que el caso anterior, los dispositivos de tecnolog a MEMS resultan los m as apropiados para esta aplicaci on, aunque si bien son m as inmunes a las vibraciones presentan derivas sostenidas en el tiempo debido a la integraci on de los errores de offset. En adelante, el contenido se organiza de la siguiente manera. En la secci on 2 se eval uan un aceler ometro y un gir oscopo como sensores de medici on de inclinaci on. Se muestran los inconvenientes que producen las vibraciones y las derivas. En la secci on 3 se propone combinar las mediciones de los sensores mediante un ltro complementario que permita reconstruir una estimaci on de las mediciones a partir de las partes de los espectros de las se nales adquiridas con cada sensor, cuya informaci on se encuentre menos corrompida. En la secci on 4 se presentan los resultados de los ensayos utilizando el ltro complementario. En la secci on 5 se discuten las conclusiones.
Figura 1: Montaje experimental usado para realizar los ensayos (balanc n).
II.
E NSAYO INDIVIDUAL DE LOS SENSORES
Para los ensayos que se describen a continuaci on se construy o un montaje experimental que consta de un balanc n con un propulsor en cada extremo, un potenci ometro en el pivot y el sensor con el sistema de control montado en el centro. Este montaje con un grado de libertad permite simular el comportamiento din amico aproximado del sistema respecto
120
10
10
[grados]
10
[grados]
10
20
20
30 2 3 4 6 5 tiempo [s] 7 8 9
30 2 3 4 6 5 tiempo [s] 7 8
(a) Angulo de rolido en funci on del tiempo.

90

12000
80 70 60
10000
Magnitud
20 40 60 frecuencia [Hz] (b) Espectro de frecuencias. 80
Magnitud
8000 6000 4000 2000 0
50
40 30 20 10 0 0
20
40 60 frecuencia [Hz] (b) Espectro de frecuencias.
80
Figura 2: Angulo medido con el aceler ometro, con el montaje ngulo de 10o y los propulsores en equilibrio formando un a apagados.
Figura 3: Angulo medido con el aceler ometro, con el montaje ngulo de 10o y los propulsores en equilibrio formando un a encendidos al 50 % de su potencia.
al rolido o el cabeceo.(Fig. 1). Aparte del sistema mec anico, el montaje cuenta con un controlador PID digital implementado en el microcontrolador, el cual cierra el lazo del sistema a trav es del control de la velocidad de los motores. Para lograr ngulo a medir una notaci on consistente supondremos que el a es el de rolido (). II-A. Aceler ometro En el desarrollo experimental se utiliz o el aceler ometro ADXL345 de tres ejes dispuesto de manera que los ejes de medici on del mismo coincidan con los ejes del sistema de ngulo se obtiene como referencia del UAV. De esta manera el a x , donde la aceleraci o n ax se mide con una = arc cos a g resoluci on de 10 bits, y un ancho de banda ajustable por software desde 0.05 Hz. hasta 1600 Hz. Las Fig. 2a,2b y las Fig. 3a, 3b muestran comparativamente las se nales adquiridas del sistema a lazo abierto en estado de equilibrio con una inclinaci on de 10o con los propulsores apagados y con los propulsores encendidos (50 %) respectivamente.
Si bien el sistema en lazo cerrado formado por el balanc n m as el controlador PID presenta un buen rechazo a las componentes ruidosas de alta frecuencia de las vibraciones, esto se aprecia en la curva de bode simulada para un sistema ideal de la Fig. 4 y en las curvas de respuesta en el tiempo del mismo sistema que se ven en la Fig. 5, las variaciones bruscas de la se nal de referencia producen acciones de control, debidas a la rama del derivador del compensador, que llevan a los motores a zonas no lineales (saturaci on o corte), provocando la inestabilidad del sistema real. Esto se puede comprobar calculando la componente derivativa del compensador PID usando como entrada de error la se nal de la Fig. 3a. El ltrado de la se nal ruidosa mediante un ltro pasa-bajos introduce otras desventajas: si bien se pueden mantener acotadas las derivadas en la se nal, la atenuaci on y el corrimiento de fase degradan la respuesta din amica e incluso provocan inestabilidad cuando las frecuencias de corte son demasiado bajas. La Fig. 6a muestra la respuesta temporal del sistema
121

0 0 -20 -40 -60 -80 -20 -100 0.1 1 10 frecuencia [Hz] 100 0 0.5 1 tiempo [s] 1.5 2 0 [grados] [dB] 5 10
-10
Figura 4: Respuesta en frecuencia del sistema completo a lazo cerrado.

10 8 [grados] 6 4 2 0 -2 0 0.1 0.2 0.3 0.4 0.5 0.6 tiempo [s] 0.7 0.8 0.9 1
[grados]
[grados]
(a) Sin ltrar.

10
-6 0 0.5 1 tiempo [s] 1.5 2
(b) fc = 5Hz
200
(a) Frecuencia de la perturaci on de 5Hz .

10 8 [grados] 6 4 2 0 0 0.1 0.2 0.3 0.4 0.5 0.6 tiempo [s] 0.7 0.8 0.9 1 -200 0 0.5 1 tiempo [s] 1.5 2 [grados]
(c) fc = 2Hz
(b) Frecuencia de la perturaci on de 50Hz .
Figura 6: Respuestas temporales del sistema a lazo cerrado de para se nales no ruidosas, pero previamente pasadas por un ltro pasa bajos.
Figura 5: Respuesta temporal del sistema de lazo cerrado de tipo regulador con una perturbaci on sumada a la medici on ideal de 0,1o de amplitud para frecuencias de 5Hz y 50Hz.
A ra z de esto se eval ua la posibilidad de utilizar un gir oscopo. II-B. Gir oscopo
para una medici on no ruidosa y no ltrada, en la Fig. 6b la misma se nal se pasa por un ltro pasa-bajos de 5 Hz de frecuencia de corte, nalmente si se disminuye la frecuencia de corte del mismo a 2 Hz el sistema se desestabiliza, tal como lo muestra la gr aca de simulaci on de la Fig. 6c. Como consecuencia de las caracter sticas ruidosas de las mediciones adquiridas con el aceler ometro no ser a posible utilizarlo como inclin ometro en el sistema de estabilizaci on.
Para realizar los siguientes experimentos se utiliz o un gir oscopo de 3 ejes ITG3200 de la rma InvenSense. Este se dispuso de manera que sus ejes est en alineados con los del sistema de referencia de abordo. Este dispositivo posee un rango din amico de +/ 2000[o /s] y una sensibilidad de o 14 /s. En las Fig. 7a, 7b, 8a,8b se observan comparativamente las se nales en el tiempo y el espectro para el caso que los propulsores est an apagados y encendidos con la misma conguraci on que la descripta para el caso de la medici on con el aceler ometro. Haciendo una comparaci on de la Fig. 3a
122
0.07
1.5
0.06
1.0
0.05
[grados]
0.04
[grados]
3 4 5 6 7 8 9
0.5
0.03
0.02
0.0
0.01
0.5
0.00
0.01 2
1.0 2
tiempo [s]
tiempo [s]

25
400
350
20
300
magnitud
20 40 60 80 100
magnitud
15
250
200
10
150
100
5
50
0 0
0 0
20
40
60
80
100
frecuencia [Hz] (b) Espectro de frecuencias.
frecuencia [Hz] (b) Espectro de frecuencias.
Figura 7: Angulo medido con el giroscopio, con el montaje en equilibrio y los propulsores apagados.
Figura 8: Angulo medido con el giroscopio, con el montaje en equilibrio y los propulsores encendidos al 50 % de su potencia..
con la Fig. 8a se puede ver que la inuencia de las vibraciones en las mediciones del gir oscopo son sensiblemente menores que en el caso del aceler ometro. Sin embargo se han observado int ervalos de tiempo relativamente cortos, la Fig. 9 muestra que para tiempos mayores la medida de este sensor comienza a derivar. III. F ILTRO C OMPLEMENTARIO En forma intuitiva surge la idea de usar la medici on obtenida por el gir oscopo para tiempos cortos y realizar la correcci on de la deriva con la medici on realizada por el aceler ometro ltima medici en tiempos largos, debido a que esta u on tiende a ser la aceleraci on de la gravedad para per odos largos. Los ltros complementarios son muy usados en sistemas de navegaci on inercial. Aplicaciones t picas son la combinaci on de las medidas de aceleraci on vertical y velocidad barom etrica vertical para obtener una estimaci on de la velocidad vertical o mediciones de unidades inerciales y sistemas de visi on. [1] Un ltro complementario es en s un ltro de Kalman de estado estacionario para una cierta clase de problemas de
ltrado [2], este no considera ninguna descripci on estad stica del ruido que corrompe a las se nales y es obtenido solamente por un an alisis en el dominio de la frecuencia. El ltro complementario resulta sencillo de tratar matem aticamente y en raz on de su baja complejidad de implementaci on consume pocos recursos computacionales. La idea b asica del ltro complementario es combinar la salida del aceler ometro y ngulo del gir oscopo para obtener una buena estimaci on del a de orientaci on de la plataforma, compensando la deriva del gir oscopo con la din amica lenta del inclin ometro [3]. El ltro complementario propuesto es el que se muestra en ngulo medido por el aceler la gura 10. Donde a es el a ometro cuya se nal est a corrompida por ruidos de alta frecuencia ngulo medido por proveniente de las vibraciones, g es el a es el a ngulo estimado. el gir oscopo, afectado por la deriva y Las funciones de transferencia del ltro deben ser elegidas de acuerdo a la ecuaci on 1:
123

15
10
Girscopo Potencimetro

(s) = (s) III-A. Discretizaci on de los ltros
(5)
5
[grados]
10
Para la implementaci on de los ltros digitales en el microcontrolador se parte discretizando las funciones de transferencia de los mismos usando la transformada z y suponiendo un retenedor de orden cero a la entrada. Con esto se obtiene una expresi on compacta para el ltro completo. Si denimos: G1 (s) = G(s) y G2 (s) = 1 G(s), entonces: G1 (z ) =
5 10 15 20 Tiempo (s) 25 30 35 40
15
(1 e 1e 1e
T T
)z 1 z 1 z 1
(6) (7)
20 0
ngulo medido por el gir Figura 9: Deriva del a oscopo En donde a = ltros. III-B.
G2 (z ) =
1
1 z 1
T
y representa la constante de ambos
Algoritmo del microcontrolador
El algoritmo del microcontrolador surge del paso a ecuaciones en diferencias de las funciones de transferencia de cada ltro. Figura 10: Diagrama en bloques del ltro complementario utilizado. [k] = a[k] + g[k]
T T a[k1] + (1 e a[k] = e ) a[k1]
(8) (9) (10) (11) (12)
Ha(s) G(s) + Hg(s) (1 G(s) ) = 1
(1)
T g[k1] + g[k] g[k1] g[k] = e
en donde Ha(s) y Hg(s) representan las funciones de transferencia del aceler ometro y el gir oscopo respectivamente. Suponemos que las funciones de transferencia de los sensores son iguales a 1. Esto es Ha(s) = Hg(s) = 1. La funci on de transferencia elegida para G(s) es un ltro pasa bajos de primer orden, lo cual hace que la estimaci on en baja frecuencia dependa de la medici on del aceler ometro. G(s) = s+ (2)
[k] T = g[k] g[k1]

T g[k] = e g[k1] + [k] T
IV.
R ESULTADOS DE LA IMPLEMENTACI ON
En tanto que la funci on de transferencia elegida para 1 G(s) es un ltro pasa altos de un polo: 1 G(s) = s s+ (3)
este ltro nos permite hacer que las componentes de alta frecuencia de la medici on estimada est en dominadas por el aporte de las mediciones provenientes del gir oscopo. Como podemos ver en la gura 10, si ambas mediciones son ideales, la funci on de transferencia total del ltro resulta: (s) = G(s) + (1 G(s) ) = 1 (s) Y esto hace que: (4)
Se ensay o el sistema utilizando el ltrado complementario ngulo que result veric andose una buena estimaci on del a o en la correcta estabilizaci on y una buena respuesta din amica. En la gura 11 se muestran las mediciones individuales del aceler ometro y el gir oscopo; y la estimaci on del ltro complementario; mientras se someti o al sistema a perturbaciones forz andolo a salir de la posici on de equilibrio y permiti endole que se restituya en forma aut onoma. Como se observa en la gr aca se calibr o d ebilmente el offset del gir oscopo para permitir una deriva exagerada a n de mostrar el rechazo ngulo del ltro. En la Figura 12 se observa la medida del a estimada por el ltro contrastada contra la medici on del po ngulo tenci ometro durante la evoluci on del sistema desde un a inicial de -10 grados hasta el equilibrio en cero grado. En este ensayo se utiliz o la medida del ltro para la realimentaci on del lazo de control y se ajustaron las constantes del controlador PID. Este ajuste se realiz o seg un los an alisis de estabilidad hechos del sistema a lazo cerrado para obtener la respuesta subamortiguada que se observa, aunque hubo que realizar
124
algunos retoques emp ricos los cuales se pueden deber a que se idealizaron algunas partes del sistema y tambi en a falta de una buena calibraci on de los sensores y propulsores.
60
40
Acelermetro Girscopo Filtro Complementario

20
[grados]
en el comportamiento del lazo de control, no obstante esto la deriva producida por el offset del sensor hace que el error de inclinaci on se incremente de manera constante en el tiempo. Ninguno de los dos m etodos resulta viable para el control de actitud del UAV. Finalmente se aplic o un ltro complementario para combinar la medici on de ambos sensores tomando de cada uno la parte del espectro de la se nal de medici on menos corrompida y atenuando la otra a n de que la suma permita una estimaci on aproximada de la variable de inter es. El comportamiento din amico del sistema realimentado con la medici on estimada por el ltro resulta satisfactorio para ser aplicado al prototipo real. AGRADECIMIENTOS El primer autor se nancia bajo el programa de Becas de Formaci on de Doctores en Areas Tecnol ogicas Prioritarias. Ministerio de Ciencia, Tecnolog a e Innovaci on Productiva, Agencia Nacional de Promoci on Cient ca y Tecnol ogica FONCyT IP-PRH 2007 - Resoluci on C.S. No 649/08. R EFERENCIAS
[1] G. Buskey, J. Roberts, P. Corke, and G. Wyeth, Helicopter automation using a low-cost sensing system, Computing & Control Engineering Journal, vol. 15, no. 2, pp. 89, 2004. [2] W. Higgins, A comparison of complementary and Kalman ltering, 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 estimation system for an autonomous helicopter, in Intelligent Engineering Systems, 1997. INES97. Proceedings., 1997 IEEE International Conference on. IEEE, 2002, pp. 391395.
20
40 0
10
15 Tiempo (s)
20
25
30
Figura 11: Mediciones y estimaci on durante ensayo del sistema.

15
Filtro Complementario Potencimetro
10
5
[grados]
10
15 22
23
24
25 Tiempo (s)
26
27
28
Figura 12: Respuesta din amica del sistema ante una perturbaci on V. C ONCLUSIONES
Se ensayaron tres m etodos de medici on de inclinaci on de una plataforma experimental que se comporta como el UAV con cinco grados de libertad restringido, permitiendose rotaciones que corresponder an al cabeceo o el rolido de la aeronave. Los dos primeros m etodos ensayados utilizaron aceler ometro por un lado y gir oscopo por otro de manera individual. En el primer caso la inuencia de las vibraciones impide el correcto funcionamiento del lazo de control, en tanto que si se ltra la se nal de la medici on se degrada la respuesta din amica o incluso se llega a la inestabilidad del sistema de lazo cerrado para frecuencias de corte demasiado bajas. Por el lado del gir oscopo se obtuvo mejores resultados
125
126
Software Embebido
127
128
Aplicacin Web embebida para el control de payload de un satlite

Ing. Gabriel Rodrigo Caballero gcaballero@iua.edu.ar Dr. Pedro E. Colla pcolla@iua.edu.ar Instituto Universitario Aeronutico, Especialidad en Sistemas Embebidos Av. Fuerza Area 6500 (5010) Crdoba, Crdoba, Argentina
Abstract Este trabajo presenta una solucin real de diseo e implementacin de una aplicacin de control del payload de un satlite geoestacionario construida como un ambiente web embebido operando en una plataforma de microcontroladores Rabbit. La misma permite enviar comandos y leer telemetra de la carga til durante la integracin al modelo de ingeniera y vuelo. Se plantea en primer lugar el diseo del hardware que provee al sistema de las interfaces adecuadas para llevar a cabo la conectividad entre el payload y el mdulo. El resultado final es un dispositivo capaz de realizar el monitoreo y control, a travs de una red Ethernet, de distintas variables de estado, proveyendo al usuario de una interfaz grfica que puede ser ejecutada en cualquier terminal remota con conexin a Internet. Keywords: Carga til, satlite, embebidos, telecomandos, geoestacionario. web, sistemas telemetra,
con un cierto nmero de entradas/salidas digitales y analgicas. Uno de los desafos que debe resolver exitosamente el diseo propuesto es la implementacin de la solucin mediante herramientas estandar y que permita entregar desde una plataforma embebida una GUI (GUI por las siglas en ingls Graphical User Interface) flexible para su operacin. 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 MDULO Y APLICACIN
EMBEBIDA
I.
INTRODUCCIN
En el proceso de construccin de un satlite uno de los principales objetivos es lograr comandar y conocer el estado de distintas variables de la carga til (payload) durante la integracin con los modelos de ingeniera y vuelo. En el proyecto referido en este trabajo surgi la necesidad de explorar las diversas alternativas que permitiran implementar conectividad TCP/IP (Transmission Control Protocol/Internet Protocol), proveer el acceso a los subsistemas mediante un servicio Web y gestionar, en una capa ms baja del stack del protocolo, el hardware subyacente de la plataforma por medio de interfaces estrictamente definidas de la carga til. El mdulo encargado de comandar el payload es la unidad de interfaz de distribucin de carga til (PIDU por su nombre en ingls Payload Interface Distribution Unit), en este diseo se busca sustituir el PIDU de vuelo en la etapa de integracin del payload al modelo de ingeniera del satlite. En tecnologa satelital se crea con ste propsito un equipo elctrico de soporte en tierra (EGSE por sus siglas en ingls Electrical Ground Support Equipment) el cual sirve de apoyo durante la fase de integracin y ensayo de cada uno de los subsistemas del satlite, tanto en el modelo de ingeniera, como en el modelo de vuelo. En este trabajo se describe el diseo de un equipo de sta ndole que sirve de apoyo en la fase de integracin del payload de un satlite geoestacionario el que ha sido especificado para trabajar en banda Ku con canales de 36MHz y 72MHz de ancho de banda, como as tambin
En base a las interfaces del PIDU y a las necesidades de los usuarios en la fase de integracin, 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: Diseo del la plataforma de hardware de acuerdo con los requerimientos de interfaces del fabricante del payload. Diseo y fabricacin del circuito impreso, listados de materiales y documentacin del desarrollo. Poblado de la placa (630 componentes) y soldadura por olas y horno de termo-fusin. Diseo e implementacin de la aplicacin embebida en la plataforma seleccionada (RCM3365) mediante Dynamic C para el envo de telecomandos y recepcin de telemetra a travs de la plataforma de hardware con el payload. Implementacin de un servicio Web donde la informacin a desplegar se genere utilizando el formato HTML y se despliegue utilizando RabbitWeb[R02]. Definicin del protocolo de comunicacin para una aplicacin remota, usando TCP/IP.
129
A. Definicin de interfaces y requerimientos de diseo De acuerdo con las especificaciones de la misin sern necesarios los siguientes tipos de interfaces: Low Level Commands (LLC) Envo de comandos digitales Digital Relay (DR) Lectura de Telemetra digital Analog Ouput (AN) Lectura de Telemetra analgica Temperature Sensing (PT) Lectura de telemetra analgica B. Estrategia de diseo 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 analgicas es de 0 a 5V.
Tabla 1 Especificaciones de interfaces LLC Teniendo en cuenta los requerimientos de diseo y las especificaciones del payload la plataforma de hardware debe contar con 16 salidas LLC, 6 entradas DR, 2 AN y 2 PT. El envo de comandos es va interfaces LLC y la lectura de telemetra discreta mediante interfaces DR, por lo tanto asociamos telecomandos (TC) con LLC y telemetra (TM) con DR.
adicional involucrada en cada subsistema a ser integrado. El software que corre en la PC tiene como propsito controlar la electrnica del EGSE para que se vincule con cada subsistema. Surge entonces la necesidad de contar con una GUI con la que puedan configurarse parmetros establecidos durante la etapa de integracin y ensayo. El enfoque convencional es implementar este diseo mediante una FPGA, pero para satisfacer los requerimientos de conectividad con la plataforma de simulacin (SIMPLAT por sus siglas en ingls Simulation Platform) es mandatorio disponer de un stack Ethernet en 10Mbps. Como estrategia de diseo todos los mdulos EGSE se comunicarn 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 solucin explorada en el diseo explicado en este trabajo es recurrir a una interfaz basada en Web donde la informacin se codifique en HTML. Se aprecia la flexibilidad de configuracin de la misma y por la facilidad de acceso remoto desde cualquier PC conectada al ambiente de desarrollo del satlite. En este marco, considerando restricciones en los tiempos del proyecto, disponibilidad de herramientas de desarrollo y costos, la eleccin de un microprocesador de la familia Rabbit proporciona la flexibilidad necesaria puesto que esta provee capacidad de conexin TCP/IP, programacin en una versin propietaria de C (Dynamic C) y abundantes recursos de desarrollo. El diseo de interfaces con el payload, LLC, DR, AN y PT es, por tratarse de un satlite 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 misin. Fue necesario entonces disear un hardware de interfaces a nivel electrnico especfico que contemplara al mismo tiempo conectividad con el usuario y con el SIMPLAT. C. Seleccin de la plataforma embebida RCM3365
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 diseo de alto nivel del satlite se define el entorno de integracin as la configuracin 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 electrnica
De acuerdo con las prestaciones de diseo de hardware, y la posibilidad de que el mdulo a ser desarrollado fuera usado en la integracin de otros subsistemas del satlite como potencia, control de actitud, navegacin y otros, se tuvieron en cuenta la disponibilidad de un nmero importante de entradas/salidas LLC, DR adicionales para expansin futura. En el otro extremo las caractersticas de comunicacin TCP/IP servicio web y la posibilidad de acceso va Telnet, requieren cantidades de memoria significativas lo que resulta clave al momento de eleccin de la plataforma de desarrollo. Conjugando espacio en
130
memoria (512K programa, 512K datos), capacidad de almacenamiento masivo y la cantidad de E/S provista por 52 lneas, se seleccion para el diseo el microprocesador RCM3365 de la familia Rabbit. La plataforma seleccionada soluciona varios problemas de diseo de hardware al proveer una capa fsica Ethernet, tolerancia al rgimen de alimentacin y memoria incorporada en dispositivo [R03]. Al seleccionar una plataforma embebida basada en RCM3365 se facilita, adems, la solucin de restricciones de implementacin puesto que el mdulo de desarrollo se monta en un zcalo de interfaz. De esta forma se puede trabajar de manera simultnea a la puesta en marcha del hardware para posteriormente ser integrado en la plataforma final. Otro problema resuelto con la eleccin, es solucionar la capa fsica de Ethernet, puesto que el mdulo cuenta con un conector RJ45 y el hardware asociado para operar con este protocolo. III. DISEO DEL HARDWARE DE INTERFAZ
necesidad de alcanzar estrictos requerimientos de calidad. Diseado el esquemtico se desarrolla el diseo del circuito impreso (PCB) teniendo en cuenta aspectos de Interferencia y compatibilidad electromagntica (EMI/EMC) e integridad de las seales entre otros. A. Diseo de la aplicacin embebida Para la programacin 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 mdulos entrega junto con el kit de desarrollo de la plataforma, el software para programacin [R05] y el cable de conexin con la PC utilizada como ambiente de desarrollo. Una vez finalizada la puesta en marcha a nivel electrnico 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 haban sido asignados a las distintas interfaces del PIDU. Este proceso se simplifica notablemente aplicando una tcnica de stubs [C04] (funciones simuladas no operativas) donde pequeos segmentos de cdigo son aplicados a verificar un aspecto en particular. A continuacin se presenta en el Ejemplo 1, la programacin que muestra como se escribe y lee un puerto en Dynamic C [C01] para un mdulo RCM3365.
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 */ } }
Una vez finalizada la etapa de definicin de requerimientos de diseo se pudo avanzar con la elaboracin de los planos esquemticos-elctricos, del hardware de interfaz que hace de nexo entre la plataforma embebida RCM3365 y las interfaces de la carga til. El diseo fue sometido a dos procesos de revisin por estar involucrado directamente con un subsistema de un satlite y de manera de realizar la deteccin de defectos lo ms temprano posible en el ciclo de vida del proyecto. Los procesos de revisin tpicos son la revisin preliminar de diseo (PDR por Preliminary Design Review) y revisin crtica de diseo (CDR por Critical Design Review). Una vez establecida la lnea de base de los requerimientos de diseo, 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 diseo de detalle. En este anlisis, 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 anlisis se presentan planos esquemticos muy detallados de cada circuito. Por ltimo se realiza un anlisis 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 dae el hardware de vuelo, se identifica la mitigacin a realizar mediante estrategias de proteccin como interfaces opto-acopladas o de aislamiento galvnico. Se utilizan en la implementacin, prcticas de Ingeniera de Software [C04,P01] consistentes con la complejidad del desarrollo realizado, la criticidad de los entregables y la
Ejemplo 1 Lectura de puerto en Dynamic C Los canales de entrada analgicos AN y PT provienen de un conversor analgico-digital (ADC Analog To Digital Converter) de Analog Devices AD7993AR [C03] que posee una interfaz serial I2C [I01]. El lenguaje de programacin Dynamic C incluye una interfaz de desarrollo API [D01] llamada I2C.LIB [R04], que maneja los aspectos genricos de la interfaz I2C y proporciona funciones simplificadas [C02] para que el diseador utilice el mdulo RCM3365 como un Master del BUS segn lo mostrado en la Figura 2.
131
Enviar comandos LLC al payload.

#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(); } }
Figura 2 Arquitectura Rabbit como master de Bus I2C Los principales elementos del API proporcionado por la librera 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 depuracin del programa paso a paso, esto constituye una herramienta muy importante a la hora de realizar cualquier implementacin en una plataforma embebida de este tipo.
Inicializacin de los pines de I2C i2c_init() // Configura SCL y SDA como salidas de OC y constantes de retardo. Envo de la condicin de Comienzo i2c_start_tx() // Inicializa la transmisin mediante el envo de un comienzo (start) i2c_startw_tx() // Inicializa la transmisin mediante el envo de un Start (S) // Inserta un delay despus del pulso S Envo de un Byte de datos i2c_write_char() // Enva 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 Recepcin de un Byte de datos i2c_read_char() //Lee 8 bits de datos de un dispositivo esclavo Envo de un ACK i2c_send_ack() // Enva una secuencia ACK al esclavo. i2c_send_nak() // Enva una secuencia NAK Envo de una condicin de parada i2c_stop_tx() // Envo de P (STOP) al esclavo
Ejemplo 2 Implementacin de HTML en RCM3365 En el Ejemplo 2 se presenta de manera simplificada la estructura del software en Dynamic C implementada para montar un servicio web en un mdulo RCM3365. Para el desarrollo de la pgina HTML se utiliz el software Macromedia DreamWeaver 8; en realidad cualquier editor puede ser utilizado con ste propsito puesto que el diseo de las pginas es relativamente sencillo y el volumen de informacin desplegada bajo. El principal uso de este servicio es proveer una interfaz de usuario que se capaz vincular las variables ledas 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 pgina HTML. 1) Incorporacin 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 eliminacin de la necesidad de utilizar programacin CGI [G01]. El resultado obtenido es una pgina Web que puede ser accedida desde cualquier PC visible mediante ruteos TCP/IP de manera que permita al usuario enviar comandos LLC y leer telemetra DR y analgica. Una pgina web relaciona al usuario con la electrnica del payload en la etapa de integracin del modelo de ingeniera. Como fuere mencionado anteriormente, la recoleccin de telemetra y el envo de telecomandos debe ser llevado a cabo por el SIMPLAT que emula la avinica del satlite y no su carga til. Al realizarlo es necesario implementar un protocolo de comunicacin entre ste y la plataforma embebida que replique la que tendr luego en la plataforma de ingeniera y de vuelo.
Tabla 2 Elementos del API de gestin de bus I2C B. Implementacin Web utilizando Rabbit Web El servidor HTTP es el encargado de resolver las solicitudes GET y POST direccionada a la direccin IP y puerto donde est escuchando el servidor [H01]; las mismas son respondidas mediante pginas HTML generadas dinmicamente. De esta forma un usuario puede entre otras facilidades: Configurar distintos parmetros de funcionamiento como direccin IP y usuario del dispositivo Obtener registros parciales de las muestras de temperatura y valores analgicos de tensin propiciados ambos por el ADC. Obtener valores de telemetra DR del payload.
132
2) Comunicacin con aplicacin va TCP/IP. El protocolo de comunicacin entre la aplicacin 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 comunicacin. El SIMPLAT inicia la conexin con la plataforma embebida enviando un paquete Request (TM o TC) formado por 4 Bytes (32bits), que incluye: nmero 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 telemetra TM Variable que se pretende leer. Para una solicitud de telemetra TM Request, la plataforma embebida devuelve un paquete TM Response con el mismo nmero de secuencia con el cual se origin la peticin y el campo TM Value con un valor de TM DR, AN o PT segn 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 conexin no pueda ser establecida dentro de 10 intentos se asumir una condicin 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 comunicacin puede ser observada en la Tabla 3.
nmero de secuencia 0x00 y el campo de datos con un valor 0x000000, lo cual indicar al SIMPLAT un pedido de retransmisin. Si la plataforma no devuelve un nmero de secuencia esperado por el SIMPLAT, se generar automticamente desde el SIMPLAT un reenvo de la solicitud TM o TC segn corresponda.
Figura 4 Funcionamiento del Protocolo de Comunicacin Simplat-Plataforma Una vez finalizado el perodo de comunicacin con la plataforma, la misma estar esperando hasta que comience un nuevo ciclo de Telecomandos y pedidos de Telemetra que est determinado por parte del SIMPLAT. IV. VALIDACIN Y VERIFICACIN
Tabla 3 Estructura de los paquetes de datos del protocolo de comunicacin Implementado Cada 500 mSeg el SIMPLAT establecer una comunicacin con la plataforma embebida realizando el envo de telecomandos (TC Resquest) y/o pedidos de telemetra (TM Request) que estn determinados en ese ciclo. Se ha implementado en la memoria de programa del mdulo RCM3365 una tabla de asignacin de telecomandos y variables de telemetra, 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 comunicacin 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
La validacin y verificacin (V&V) del diseo requiere consideraciones especiales. A nivel de verificacin se procede a revisar unitariamente cada interfaz en particular, los niveles de tensin, corrientes, tiempos de transitorios, flancos y tolerancias requeridas por el fabricante del payload las que son estrictas. Para los ensayos a nivel unitario de recepcin de comandos y emisin de telemetra mediante stubs que simularon el payload a ser controlado de acuerdo a la especificacin de su fabricante. Posteriormente se realiz la integracin con el payload de manera de verificar la recoleccin de telemetra DR. Se probaron 100 casos de estados de cambios de variables controladas por un operador y su correcto reflejo en la informacin HTML proporcionada por la interfaz Web. Una estrategia similar se utiliz para verificar unitariamente los comandos LLC controlando con instrumental apropiado que los parmetros elctricos y de tiempo estuvieran dentro de especificacin 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 documentacin del sistema. La integracin con la PC industrial se resuelve tambin con un criterio de verificacin unitaria primero para luego ser validado con mediante ciclos extendidos de
133
mediciones del SIMPLAT, verificando la conectividad integrada entre la plataforma embebida bajo desarrollo y el simulador de la plataforma. La integracin final del EGSE con el subsistema ha quedado para una etapa posterior del proyecto y no se ha completado al momento de formular esta publicacin. V. RESUMEN DEL PROYECTO
La duracin total del proyecto implic aproximadamente un ao de trabajo desde la definicin de requerimientos a nivel sistema, hasta la concepcin 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, diseo, construccin, etapas de testing, integracin de hardware y software y validacin del EGSE. El esfuerzo total de desarrollo es del orden de 3 personas-ao donde algunas etapas fueron tercerizadas tales como la fabricacin de PCB, poblado de la placa, soldadura por horno y por olas, este diseo constituye una pieza de relevante importancia en la cadena de tests de integracin y ensayo de un satlite geoestacionario. VI. CONCLUSIONES
Este trabajo refleja la creacin de una plataforma embebida como parte del proyecto de desarrollo de un satlite 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 prcticas de ingeniera de software establecidas tales como ciclo de requerimientos, diseo por etapas, establecimiento de lnea de base de configuracin e inspecciones confirmando la utilidad de estas tcnicas en el desarrollo de sistemas embebidos de esta complejidad. Queda confirmada la hiptesis 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 integracin de hardware y software como una solucin integrada as la posibilidad de actualizacin flexible del firmware, lo cual transforma al mdulo desarrollado en una estructura tolerante al cambio de requerimientos de diseo. Las aplicaciones de este mdulo en las etapas de integracin y ensayo del satlite geoestacionario son diversas, de acuerdo con los requerimientos de cada subsistema a ser integrado, razn por la cual, para cada uno de ellos el software embebido en el mdulo RCM3365 deber ser actualizado y modificado. Este desarrollo se extender entonces hasta fines del 2011, fecha estipulada para finalizar con la integracin del modelo de ingeniera del satlite. Una ventaja del diseo utilizado fue desarrollar en un entorno de programacin amigable, basado en las estructuras del lenguaje C, lo cual permiti abordar la tecnologa con una curva de aprendizaje modesta comparada a la que hubiera sido necesaria para adquirir
los conocimientos de VHDL para haber podido utilizar una implementacin en FPGA. La disponibilidad de gran cantidad de ejemplos, notas de aplicacin y manuales del fabricante sirvieron de gua 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 especficos 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 integracin del payload al modelo de ingeniera y actualizar el software embebido de cada mdulo de acuerdo a los requerimientos de cada subsistema a ser integrado. La integracin final del EGSE con el subsistema ser realizada a fines de Julio del corriente ao y se prev hacer en primera medida una recepcin e inspeccin visual del subsistema montaje en el modelo de ingeniera del satlite y posterior encendido, apagado del transmisor, receptor. Se busca en primera instancia verificar las funcionalidades vitales. El plan de integracin y ensayo tiene estipulado en la segunda etapa conectar un simulador de canal, y realizar pruebas especficas, 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 mdulos Rabbit 2 Ed. (2005) ISBN: 987-21834-2-2 [C02] Caprile S.R.: EL camino del conejo. 2 Ed. ISBN: 978-9871301-28-7 [C03] Conversor Analgico Digital AD7993ARhttp://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 OReilly 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 sheethttp://www.rabbit.com/products/rcm3365/rcm3365.pdf [R02] RabbitWeb http://www.rabbit.com/documentation/docs/modules/RabbitWeb/Rabb itWeb.pdf [R03] Rabbit Technical Notes and white Papers http://www.rabbit.com [R04] Rabbit Referencia manual librera I2C.libhttp://www.rabbit.com/documentation
[R05] Rabbit Software Dynamic C version 9.6 http://www.rabbit.com/support
134
Enfoque embebido para una Estacin Meteorolgica con Interfaz Web

Esp. Ing. Martn Federico Pelliza
Especialidad en Sistemas Embebidos Instituto Universitario Aeronutico Crdoba, Argentina fpelliza@hotmail.com
AbstractEste trabajo tiene como objetivo realizar una exploracin y evaluacin 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 estacin meteorolgica web, implementando una aplicacin embebida en un mdulo de desarrollo del fabricante Netburner al cul se integr el hardware necesario para medicin de temperatura y movimientos ssmicos. Como resultado se obtuvo un dispositivo totalmente autnomo que permite a travs 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 configuracin remota de distintos parmetros de su funcionamiento.
Mg. Hctor Riso

Especialidad en Sistemas Embebidos Instituto Universitario Aeronutico Crdoba, Argentina hriso@iua.edu.ar La definicin de un protocolo para la comunicacin de datos va UDP. La implementacin de un servicio web para el acceso a los datos y configuracin del Mod5270, utilizando HTML y JavaScript para el desarrollo de las pginas web. Esta actividad incluy tambin la implementacin en JAVA de un applet para la visualizacin en tiempo real y en forma grfica de los datos de temperatura y movimientos ssmicos.
La descripcin 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 aplicacin.
I.
INTRODUCCIN
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 adquisicin y registro de diversas condiciones ambientales, que permita el acceso a los mismos en tiempo real a travs de una red ethernet. Para la implementacin preliminar de una solucin, 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 utilizacin de una plataforma que ya integre la solucin de red y acote el trabajo de desarrollo. Se seleccion esta ltima opcin, ya que se estim que el esfuerzo de desarrollo requerido para la primera opcin sera considerablemente mayor y excedera los lmites de tiempo propuestos para este trabajo, y se eligi como plataforma de desarrollo un mdulo Mod5270 de Netburner [1] Luego de la seleccin de la plataforma, se desarrollaron los componentes de Hardware y de Software, actividades que involucraron: El diseo y fabricacin de un mdulo de sensores para la adquisicin de datos de aceleracin y temperatura, extensible para la incorporacin de sensores de presin, humedad, velocidad y direccin de viento, etc. El diseo y la implementacin en C++ de la aplicacin embebida en el Mod5270 para la adquisicin y registro de datos del mdulo de sensores, y su acceso remoto
Estacin Meteorolgica Web I2C Mdulo de Sensores Puerto Ethernet Ethernet Mod5270 Router Ethernet Wireless Ethernet Bridge Router Wireless LAN
Figure 1. Contexto de Aplicacin
II. DESARROLLO DEL HARDWARE A. Plataforma El seleccion el mdulo Mod5270 de Netburner como plataforma de desarrollo. El mdulo incluye entre sus caractersticas 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
135
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 (adems de las funciones y rutinas bsicas para la creacin y administracin de tareas) libreras de soporte para diversos protocolos de comunicacin de red (entre otros DHCP, TCP, UDP, HTTP) y de interfaz con otros dispositivos (tales como I2C y SPI) [2]. Estas libreras son utilizadas por la aplicacin para la adquisicin y registro de datos, como as tambin para la exposicin del servicio web. B. Mdulo de sensores Se desarroll un mdulo bsico de hardware de adquisicin de datos, cuyo diseo se enfoc en la facilidad para la integracin de distintos tipos de sensores. Con este criterio se adopt el bus I2CTM para la comunicacin entre los sensores del mdulo y la plataforma Mod5270. El bus I2C es un bus de bidireccional, que provee un mecanismo sencillo y eficiente para el intercambio de datos entre dispositivos, con una interconexin mnima entre ellos, ya que es un bus de dos cables. La flexibilidad del bus permite la incorporacin de sensores al mdulo de manera directa, con la sola condicin de que estos soporten una interfaz I2C. De esta forma el mdulo de sensores es extensible y permite la medicin variadas condiciones ambientales, adems de las ofrecidas por el prototipo, como por ejemplo presin, humedad, velocidad viento, etc. El mdulo de adquisicin de datos desarrollado para este prototipo cuenta con dos sensores para la medicin de temperatura, y un sensor para la medicin de movimientos ssmicos. Para la medicin de temperatura se escogieron los sensores digitales de temperatura TMP101 de Texas Instruments [3] y STTS75 de STMicroelectronics [4], mientras que para la medicin de movimientos ssmicos se utiliz el acelermetro digital de 3 ejes LIS3LV02DL STMicroelectronics [5]. Todos los sensores estn interconectados al bus I2C y se utilizan en modo esclavo, mientras que el Mod5270 es utilizado como maestro. Los sensores de temperatura utilizados poseen caractersticas similares en cuanto a su rango de medicin (de 55C a +125C), pero se configuraron con resoluciones diferentes, el primero con una resolucin de 9 bits (0.5C ) y el segundo con una resolucin de 12 bits (0.0625C), con el fin de evaluar el desempeo de cada uno en distintos rangos. Por otro lado se utiliz el sensor LIS3LV02DL para la medicin de aceleraciones. Este dispositivo permite rangos de aceleracin a fondo de escala de +/-2.0g y +/-6.0g, con un ancho de banda de la conversin variable entre 10Hz y 640Hz, ambos seleccionables por software durante el funcionamiento. Como la aceleracin en la mayora 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 tpica se encuentra entre 0,5Hz y 2Hz (llegando a 4Hz en casos excepcionales) [6]
y [7], este dispositivo es apropiado para la medicin de movimientos ssmicos. III. DESARROLLO DEL SOFTWARE Se desarroll una aplicacin embebida en el Mod5270, encargada de obtener los datos del mdulo de sensores, mantener un registro de los mismos y permitir el acceso a estos datos en forma remota a travs de HTTP, FTP o UDP. El Mod5270 opera bajo un sistema operativo multitarea preemptivo, basado en prioridades. La aplicacin ejecuta las rutinas de acceso a la red (inicializacin del stack TCP y adquisicin de IP dinmica) y luego crea, configura e inicia las tareas que ejecutan las actividades mencionadas en el prrafo anterior en forma independiente. Las principales tareas ejecutadas por la aplicacin pueden dividirse en: A. Adquisicin de datos a travs del mdulo de sensores Existen dos tareas encargadas de obtener cclicamente los datos de temperatura y aceleracin, realizando el muestreo de datos con la frecuencia configurada a travs de la pgina de configuracin del sistema. El perodo de muestreo para temperatura puede variar entre 1 y 3600 segundos, mientras que para aceleracin el perodo de muestreo puede variar entre 200 y 1000 milisegundos (en saltos de 50 milisegundos). La aplicacin permite registrar hasta un mximo de 3600 muestras de temperatura y 18000 muestras de aceleracin. Este nmero mximo de muestras se determin asumiendo una hora de almacenaje, con el perodo 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 ms antiguas son reemplazadas por nuevas muestras una vez que el lmite mximo de cada tipo de muestra es alcanzado. La adquisicin de los datos de temperatura y movimiento del mdulo de sensores se realiza a travs del bus de dos lneas I2C. Cada dispositivo conectado al bus posee una direccin nica de 7 bits, y puede actuar como transmisor o receptor de datos. El Mod5270 es utilizado como maestro (el dispositivo que inicia la comunicacin), mientras que los dispositivos del mdulo de sensores son configurados en modo esclavo. La especificacin del protocolo I2C [8] describe el proceso de transmisin de datos entre dispositivos. Inicialmente la tarea de adquisicin de temperaturas configura los sensores de temperatura para una resolucin de 12 bits el TMP100 y 9 bits el STTS75, en modo de muestreo continuo (una muestra cada 340ms). Luego, de acuerdo al perodo configurado, solicita muestras de temperatura al sensor activo. La tabla de conversin de bits a C es similar para ambos sensores, y puede encontrarse en la Tabla 4 de [4] La tarea de adquisicin de aceleraciones configura al sensor de aceleracin para una escala de medicin de de +/-2.0g con una resolucin de 12 bits (~0,001 g), con una frecuencia de muestreo de 40Hz (25mS). Luego, la tarea solicita muestras de aceleracin de acuerdo al perodo de muestreo configurado. La tabla de conversin de bits a G se muestra en Table 1.
136

TABLE I. TABLA DE CONVERSIN Tabla de Conversin de Aceleracin 2.0000 1.5625 1.0000 0.2930 0.0039 -0.0039 -0.2930 -1.5625 -2.0000
Aceleracin (G) Salida Digital HEX
Figure 2. UDP Sample Request
0111 1111 1111 0110 0100 0000 0100 0000 0000 0001 0010 1100 0000 0000 0100 1111 1111 1100 1110 1101 0100 1001 1100 0000 1000 0000 0000
7FF 640 400 12C 004 FFC ED4 9C0 800
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 ms actuales disponibles, y en sus 7 bits restantes el cdigo del tipo de muestra (aceleracin 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 aceleracin. El campo ndice (16 bits) indica el nmero de secuencia de la muestra. Su valor mximo depende del tipo de muestra, siendo 3600 para muestras de temperatura y 18000 para muestras de aceleracin. 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 slo en muestras de aceleracin y contiene los milisegundos del TimeStamp Los campos de Temperatura (16 bits) y Aceleracin X-Y-Z (cada una un valor de 16 bits) contienen el valor de la medicin correspondiente, segn la conversin de aceleracin y temperatura descripta en secciones anteriores (los bits 15-1414-12 son siempre 0). Se permite incluir hasta 50 muestras en un mensaje UDP Sample Response (para limitar el tamao del paquete UDP a 750 bytes).
B. Servicio FTP Permite obtener archivos con los registros de las ltimas muestras de temperatura y movimientos ssmicos, como as tambin un registro completo de los eventos del sistema. En esta versin de la aplicacin en el servidor slo 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 conexin. Los clientes FTP pueden descargar archivos con los diferentes registros (aceleracin, 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 medicin, de acuerdo a la conversin de temperatura y aceleracin de las tablas descriptas en la seccin anterior de este documento. C. Servicio UDP Esta tarea implementa un protocolo de comunicacin para la transmisin 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 travs de la pgina de configuracin. a) Sample Request El campo Tipo de Muestra contiene un cdigo de 8 bits cuyo valor identifica solicitudes de muestras de temperatura o aceleracin. El campo Cantidad de Muestras (16 bits) es utilizado para solicitar el envo una cantidad fija de muestras. El campo Ultima Muestra Recibida (16 bits) es utilizado para solicitar el envo de una cantidad variable de muestras. La Fig. 2 muestra el formato de un UDP Sample Request
Figure 3. UDP Sample Response
Cuando un UDP Sample Request contiene en el campo Ultima Muestra Recibida el nmero de secuencia de una muestra, el servidor enviar un mensaje UDP Sample Response con todas las muestras desde el ndice indicado, hasta la muestra ms actual disponible. El campo Cantidad de Muestras es considerado slo si el campo Ultima Muestra Disponible contiene un nmero negativo. En Fig. 4 se ejemplifica el uso de de este protocolo. El Applet desarrollado para la visualizacin de datos en tiempo real desde la pgina web hace uso de este protocolo para la adquisicin de las muestras de temperatura y aceleracin.
137

Cliente Servidor
Muestra actual t: 34 a: 123
Cada cambio en la configuracin de los parmetros de funcionamiento del Mod5270, es registrado como un evento de sistema.
El cliente solicita las ltimas 20 muestras de aceleracin
UDPSampleRequest (a,20,-1)
El servidor responde con un mensaje con las muestras de aceleracin 103 a 123 Muestra actual t: 51 a: 131
UDPSampleResponse
El cliente solicita las muestras de aceleracin desde la ltima recibida, 123
UDPSampleRequest (a,0 , 123)

El servidor responde con un mensaje con las muestras de aceleracin 124 a 131 Muestra actual t: 82 a: 229
UDPSampleResponse
El cliente solicita la ltima muestra de temperatura disponible
UDPSampleRequest (t,-1 ,-1) UDPSampleResponse
Figure 5. Pagina de configuracin

El servidor responde un mensaje con la muestras temperartura 82
Figure 4. Funcionamiento del protocolo para la solicitud de muestras
b) Registros Los registros parciales de las ltimas muestras de temperatura y movimientos ssmicos, como as tambin de los eventos del sistema se obtienen en la pestaa Registros de la pgina web. Los eventos del sistema tambin son registrados y pueden ser accedidos a travs de la pgina esta misma pgina. Es todos los casos, es posible seleccionar la visualizacin de los entre 10 y 100 ltimos registros. Los registros completos pueden obtenerse va FTP.
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 dinmicamente. Accediendo a este servicio un usuario puede: Configurar distintos parmetros de funcionamiento del Mod5270 Obtener registros parciales de las muestras de temperatura y movimientos ssmicos Obtener registros de eventos del sistema Mostrar en tiempo real las muestras temperatura y movimientos ssmicos a) Pagina de configuracin Los parmetros configurables a travs la pgina de configuracin son el perodo de muestreo de temperatura y movimientos ssmicos (aceleracin), la direccin IP del servidor NTP con el cual la aplicacin se sincroniza, el puerto donde el servicio UDP est disponible, el tipo de filtro aplicado a las muestras de aceleracin y la seleccin del sensor de temperatura activo. En este prototipo la implementacin de HTTP soporta autenticacin BASIC, y este esquema es utilizado para el acceso a la pgina de configuracin de los parmetros de funcionamiento, para la cul la provisin de credenciales es obligatoria. Este esquema es utilizado slo con fines de identificacin, ya que no constituye un mtodo seguro de autenticacin (los datos son transmitidos como texto claro).
Figure 6. Registros de Aceleracin
c) Mediciones en tiempo real Para la visualizacin en tiempo real de los datos, el servidor descarga en el navegador del cliente un applet encargado de obtener (va UDP y adhiriendo al protocolo descrito en secciones anteriores) y procesar los datos, desplegndolos en forma grfica. El applet solicita muestras cada 750mS y actualiza los grficos con las muestras del ltimo paquete UDP
138
recibido. Se despliegan las ltimas 50 muestras de temperatura y 300 muestras de aceleracin.
conectividad de red que involucran un esfuerzo de desarrollo relativamente acotado; la alternativa que se evalu no slo incorpora la solucin de red, sino que adems ofrece herramientas (en la forma de paquete de libreras, entorno de desarrollo integrado, hardware de base para la prototipacin) que facilitan tanto el desarrollo de las aplicaciones embebidas, como as tambin la integracin de los diferentes componentes de hardware necesarios para implementar un sistema totalmente autnomo con capacidades de red. Si bien el desarrollo de un producto aplicado supone la definicin de requerimientos ms especficos 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 integracin de nuevos sensores y la utilizacin de esquemas de captura inalmbricos tales como ZigBee o Bluetooth permitira por ejemplo la comprobacin de condiciones de presin, humedad y temperatura en laboratorios, vibraciones en salas de ensayos, etc.
Figure 7. Mediciones en tiempo real
E. Sincronizacin de la hora del sistema Esta tarea se ocupa de sincronizar el reloj interno del Mod5270 a travs de un cliente NTP. La aplicacin 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 algn error durante la sincronizacin, la aplicacin intenta nuevamente restablecer el contacto con el servidor NTP cada 10 minutos, hasta lograr la resincronizacin (inicialmente 00:00:00 GMT 1 Ene 1970 en caso de no poder sincronizarse). Los errores durante la sincronizacin de la hora son almacenados en el registro de eventos del sistema. IV. CONCLUSIONES Durante el ejercicio se realizaron actividades de investigacin sobre las diferentes alternativas existentes a la hora de disear una sistema embebido, que involucraron el estudio de microprocesadores, plataformas, sensores, e interfaces, la aplicacin de diferentes protocolos de red, el diseo y fabricacin de un mdulo de hardware y la programacin, en C++, JAVA, JavaScript, HTML y sobre una plataforma basada en un sistema operativo en tiempo real, de una aplicacin embebida completa. El resultado demostr que existen en el mercado actual opciones para el desarrollo de sistemas embebidos con
Futuras evoluciones del prototipo podran centrarse tambin en la definicin de una estrategia para el registro por disparo en lugar del registro continuo para las mediciones de movimientos ssmicos, la medicin de determinadas variables slo bajo demanda, la implementacin de estrategias para la gestin de fallos o la incorporacin de capacidades de seguridad (por ejemplo el uso de SSL para el cifrado de datos intercambiados entre servidor y cliente). REFERENCIAS
[1] [2] [3] [4] [5] [6] [7] Netburner Mod5270 Data Sheet http://www.netburner.com/downloads/mod5270/mod5270_datasheet_pi nout_diagram.pdf Netburner Mod5270 Hardware Users Manual http://csserver.evansville.edu/~richardson/courseware/resources/EE458/ nburn/docs/platform/Mod5270.pdf Texas Instruments TMP100 Data Sheet http://www.datasheetcatalog.org/datasheet/texasinstruments/tmp101.pdf STMicroelectronics STTS75 Data Sheet http://www.stmicroelectronics.fr/stonline/products/literature/ds/13298/st ts75.pdf STMicroelectronics LIS3LV02DL Data Sheet http://www.stm32circle.com/projects/file/DataSheet/lis3lv02dl.pdf Terremotos Bruce A Bolt Ed. Reverte http://books.google.com.ar/books?id=KmHP0lGeQWQC&lpg=PP1&pg =PP1#v=onepage&q=&f=false Registro y tratamiento de acelerogramas Carreo, Surez, Bravo y Tordesillas - Fsica de la tierra, ISSN 0214-4557, N 11, 1999 (Ejemplar dedicado a: Ingeniera ssmica), pags. 81-111 http://revistas.ucm.es/fis/02144557/articulos/FITE9999110081A.PDF Philips Semiconductors: The i2c (Inter-Integrated Circuit) bus specification. (http://www.nxp.com/acrobat_download/literature/9398/39340011.pdf)
[8]
139
Diseo de un sistema de actualizacin de firmware para un sistema embebido

Esp. Ing. Diego Gustavo Roca
Especialidad en Sistemas Embebidos Instituto Universitario Aeronutico Crdoba, Argentina diegoroca@yahoo.com.ar
Dr. Pablo Ferreyra

Especialidad en Sistemas Embebidos Instituto Universitario Aeronutico Crdoba, Argentina pferreyra@iua.edu.ar
Resumen En este trabajo se analiza la problemtica 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 problemtica y una secuencia de pasos para llevar adelante en forma segura la actualizacin.
I.
INTRODUCCION
Los sistemas embebidos tienden, fruto del avance tecnolgico, a ser cada vez ms potentes, integrados y complejos. Esto hace que puedan realizar tareas cada vez ms 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 problemtica encontrada al momento de tener que actualizar el software de un sistema embebido. En todo momento la problemtica es confrontada con los requerimientos del sistema y restricciones propias del caso real. Finalmente se describe el diseo de la solucin 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 ACTUALIZACIN
3 - Se debern suministrar medios que permitan controlar o restringir la aplicacin del Archivo de actualizacin sobre los Equipos. Esto implica que el Archivo de actualizacin pueda usarse para actualizar sin restricciones el firmware de cualquier Equipo (que tenga los medios para ello), o que dicho Archivo de actualizacin sea aplicable nicamente a un grupo determinado de Equipos, o, ms restrictivo an, que dicho Archivo de actualizacin sea aplicable a un nico Equipo en particular. Al momento de generar ese Archivo de actualizacin deber poder seleccionarse el grado de restriccin 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 pblico desde el cual se podra descargar el Archivo de actualizacin.
III.
MODELO DEL SISTEMA DE ACTUALIZACIN
En esta seccin se har un anlisis de los requerimientos del sistema de actualizacin y se plantear un modelo donde se describirn las partes involucradas. Se esbozarn tambin los lineamientos bsicos 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 actualizacin al mismo. Ser necesario tambin contar con un operador que lleve adelante acciones bsicas. El requerimiento 5 lleva a proponer el envo del Archivo de actualizacin al lugar donde se vaya a hacer la actualizacin va e-mail. El requerimiento 3 impone la necesidad de hacer algn tipo de procesamiento al archivo de imagen de memoria, como as tambin la necesidad de algn control de integridad del mismo. Por ello, ser necesario desarrollar una aplicacin de PC que procese el archivo de imagen de memoria y genere el Archivo de actualizacin.
Se describen a continuacin 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. Entindase como cambio de hardware a cualquier componente o parte que haya que reemplazar para efectivizar la actualizacin, por ej.: Memorias pregrabadas, tarjetas SD, placas, etc. 2 - Del punto 1 se desprende que, para llevar adelante la actualizacin, 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 actualizacin.
140
Equipo. Un corte de energa durante la grabacin de la memoria FLASH sera fatal, como as tambin un apagado del equipo, ya sea intencional o no, ya que podra dejarlo inoperante. Otro problema, es que se grabe una versin de firmware vlida, pero equivocada (como sera, por ejemplo, grabar por error una versin ms antigua). IV.
Fig. 1. Modelo del sistema de actualizacin remota.
DISEO DEL SISTEMA DE ACTUALIZACIN
En la Fig. 1 se observa el modelo propuesto para el sistema de actualizacin. La secuencia lgica de pasos para recorrer el modelo sera la siguiente: El fabricante lanza la nueva versin de firmware, que en nuestro caso es bsicamente la imagen de memoria. Ese archivo es procesado por una aplicacin de PC que lleva el nombre de Packer, se obtiene as el Archivo de actualizacin. El Archivo de actualizacin es enviado al lugar en que se encuentre el Equipo va e-mail. Para llevar adelante la actualizacin, el operador del sistema necesita otra aplicacin de PC que lleva el nombre de Updater. La aplicacin Updater se encarga de descargar el Archivo de actualizacin al Equipo y acta como interfaz entre el operador y el Equipo durante el proceso de actualizacin. A. Anlisis de la problemtica involucrada en el modelo del sistema de actualizacin Una vez obtenido el modelo del sistema, se hace un anlisis de los posibles problemas y riesgos que se podran encontrar a lo largo del circuito de actualizacin, con el fin de plantear soluciones a los mismos. Bsicamente, el principal riesgo que se encuentra en todo sistema de actualizacin de firmware es que ante un fallo o error en el mismo, el equipo que recibe la actualizacin quede imposibilitado de operar. Ese es el principal factor a tener en cuenta en todo momento durante el diseo del sistema. En el modelo planteado se pueden distinguir tres puntos problemticos: El primero aparece durante el envo del Archivo de actualizacin al usuario del Equipo, ya que se emplea un medio no seguro como lo es el e-mail. Es as que el Archivo de actualizacin puede caer en manos inapropiadas y que le sea aplicado un proceso de ingeniera inversa, con el fin de despejar el cdigo fuente del mismo o introducirle modificaciones que alteren su funcionamiento. De igual modo, el Archivo de actualizacin puede corromperse en el camino sin necesariamente la participacin de terceros. Se debera tambin, suministrar algn mecanismo que permita al Equipo autenticar que el Archivo de actualizacin es vlido. El segundo punto problemtico, aparece durante la descarga del Archivo de actualizacin al Equipo, a travs del enlace RS232C. Aqu se encuentra que la conexin se puede interrumpir, lo que hara que el Archivo de actualizacin quede truncado, o una interrupcin momentnea hara que se pierda parte del Archivo de actualizacin, quedando este incompleto. Por otra parte, el ruido en el canal podra hacer que se corrompa el Archivo de actualizacin. El tercer punto problemtico est en el proceso de grabacin del nuevo firmware en la memoria FLASH del
En este punto se deben conjugar los requerimientos iniciales, el modelo propuesto y el anlisis de problemas y riesgos del modelo, con el fin de obtener una solucin que satisfaga los requerimientos y elimine o al menos mitigue los riesgos asociados. A. Solucin a los riesgos asociados al envo va e-mail del Archivo de actualizacin El envo del Archivo de actualizacin al usuario a travs de e-mail, es el punto de mayor exposicin pblica de la informacin. Se deben asegurar aqu tres principios bsicos de seguridad de la informacin: Privacidad, Integridad y Autenticidad. La Privacidad de la informacin se obtendr encriptando toda la informacin transportada que es til al sistema. El algoritmo de encriptacin seleccionado para el caso es el TEA (Tiny Encryption Algorithm) [1]. Como su nombre lo indica, TEA es un algoritmo compacto y de implementacin muy simple, especial para sistemas embebidos ya que consume pocos recursos. Como contrapartida, existen varios estudios de criptoanlisis [2] del algoritmo, que lo hacen relativamente dbil, pero para el caso en estudio la relacin costo/beneficio que enfrenta un tercero en el caso de realizar un ataque contra el Archivo de actualizacin 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 actualizacin saldr encriptado y solo podr ser desencriptado por el Equipo, el cual tendr la clave de desencriptacin previamente embebida. El modo de operacin seleccionado para procesar los bloques es el CBC [3] (Cipher Block Chaining), emplendose un Vector de Inicializacin aleatorio, que formar parte del Archivo de actualizacin. El control de Integridad se obtendr al aplicar una funcin de Hash SHA-1 al Archivo de actualizacin, cuyo resultado se anexar al final del mismo y ser comprobado por la aplicacin Updater al momento de recibir el Archivo de actualizacin y como paso previo a enviarlo al Equipo a travs del enlace RS232C. La Autenticidad del Archivo de actualizacin se verificar en base a un mtodo muy simple, que consiste en agregar al Archivo de actualizacin un Magic Number de 8 bytes, cuyo valor ser fijo y conocido por el Equipo, quien al momento de desencriptar el Archivo de actualizacin controlar que en la posicin esperada se encuentre dicho valor. Todo lo mencionado hasta aqu, delinea la estructura que tomar el Archivo de actualizacin, y a medida que se avance en el anlisis, la estructura final quedar configurada.
141
B. Solucin a los riesgos durante la descarga del Archivo de actualizacin a travs del enlace RS-232 Los problemas asociados a la descarga del Archivo de actualizacin desde la aplicacin 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 actualizacin y enviarlo al Equipo en forma de paquetes. Se decidi segmentar al Archivo de actualizacin 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 deteccin 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 nmero 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 actualizacin y la prdida o llegada fuera de secuencia de algn segmento conlleva a que el Archivo de actualizacin quede inutilizable. Finalmente, a cada paquete se le agregar una cabecera conteniendo cdigos de Comando y SubComando que permitirn identificar el paquete. La estructura general del paquete ser la indicada en la Fig. 2:
La secuencia normal de funcionamiento, tal como lo muestra la Fig. 4, sera la siguiente: la aplicacin Updater iniciar el proceso y enviar un Paquete de Inicializacin con dos fines, primero detectar que el Equipo est disponible para una actualizacin y segundo enviar informacin acerca del tamao total del Archivo de actualizacin que se va a transferir y la cantidad de paquetes que se van a emplear para dicho fin. Este paquete lleva nmero de secuencia 0.
Fig. 4. Diagrama de secuencia de una transferencia normal de descarga de Archivo de actualizacin. CMD SCMD SEQ SEGMENTO CRC32
Fig. 2. Estructura general del paquete para descarga de Archivo de actualizacin.
El Equipo responder que est listo para la transferencia enviando un ACK con nmero de secuencia 1, indicando as que espera recibir el Segmento 1 del Archivo de actualizacin. La aplicacin Updater enviar el Segmento 1 y al recibirlo el Equipo responder con un ACK con nmero de secuencia 2. As sucesivamente se continuar hasta completar el envo del Archivo de actualizacin completo. Se deben considerar tambin 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 reenvo del paquete solicitado. Si el paquete esperado contina 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 aplicacin Updater no reciba nunca el ACK esperado o que este llegue errneo, en este caso la aplicacin 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 aplicacin Updater quien abortar el proceso.
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 nmero de secuencia (SEQ) del siguiente paquete que espera recibir el Equipo. Cuando el nmero de secuencia del paquete de ACK se corresponde con el nmero de secuencia del paquete anterior ms uno (SEQ + 1) ser esto una indicacin implcita 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 nmero de secuencia del paquete fallido, siendo esto una indicacin implcita de que se espera una retransmisin.
CMD SCMD SEQ
Fig. 3. Estructura general de un paquete ACK para descarga de Archivo de actualizacin.
142
Como puede verse, el protocolo es simple pero funcional a la aplicacin y brinda medios de seguridad y control para lograr una transferencia segura. C. Solucin a los riesgos asociados al proceso de grabacin en memoria FLASH El proceso de grabacin de la nueva imagen de memoria en FLASH es la parte ms crtica del sistema de actualizacin. Cualquier falla en el proceso de grabacin dejara al equipo inutilizado para funcionar. Ante una falla en el proceso de grabacin, debida a casos fortuitos como puede ser un apagado no intencional o un corte de energa, es deseable poder repetir el proceso cuando las condiciones estn dadas nuevamente. Esto lleva a la necesidad de tener una porcin de cdigo que siempre est funcional y que no forme parte del rea de memoria que se actualiza. A esta porcin de cdigo 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 actualizacin. Entre las funcionalidades del Bootloader se tendrn: Recibir y reconstruir el Archivo de actualizacin, desencriptarlo, verificar la autenticidad del mismo y realizar el proceso de grabacin en FLASH del nuevo firmware. Otro riesgo oportunamente encontrado en el anlisis del modelo, implicaba el caso en que se graba una versin de firmware vlida para el sistema, pero incorrecta para el equipo, ya sea porque es antigua o con funcionalidades no soportadas por ese modelo. Sera interesante aqu, poder volver a la versin 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 grabacin de memoria FLASH quedan mitigados. D. Solucin al requerimiento N3 Restriccin de uso del Archivo de actualizacin El requerimiento N3 plantea la necesidad de poder restringir la aplicabilidad del Archivo de actualizacin a los Equipos. Esto implica que el fabricante tenga la posibilidad de decidir si un determinado Archivo de actualizacin 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 sern actualizados y no terceros (distribuidores y servicio tcnico), pudiendo generar versiones a medida especiales o exclusivas para un determinado cliente. Razones tcnicas: la instalacin temporaria de una aplicacin de testeo y puesta a punto del Equipo. Otra razn sera el poder evitar
actualizaciones equivocadas de Equipos, con versiones no soportadas por determinado modelo, etc. Aparecen aqu dos problemas. Primero, como identificar unvocamente a un Equipo en particular, y segundo, como lograr la restriccin gradual de uso, desde un Archivo de actualizacin universal que aplica a cualquier Equipo, hasta uno exclusivo para un Equipo especfico. En el caso en estudio, la nica informacin disponible en el Equipo que lo identifica unvocamente es el nmero de serie. Este se graba en un rea especial de memoria Flash, la cual una vez bloqueada, no puede ser modificada nunca ms. El nmero de serie consta de cinco bytes, que especifican al Equipo por: Modelo, Ao y Mes de fabricacin, Lote e identificador (ID) dentro del lote, informacin suficiente para solucionar los problemas planteados al inicio de esta seccin. Se propone emplear una analoga a lo que se hace al enmascarar una direccin IP para formar subredes. Para este cometido, en el Archivo de actualizacin se incluir el nmero de serie del Equipo destino de la actualizacin. Tambin se agregar al Archivo de actualizacin una Mscara de cinco bytes, en la que cada byte puede tomar el valor 255 (0xFF) 0 (0x00). El Equipo al recibir el Archivo de actualizacin, aplicar la Mscara al Nmero de serie incluido en el Archivo de Actualizacin y tambin al Nmero de serie propio, grabado en FLASH en origen. En este contexto, aplicar la mscara implica realizar la operacin AND bit a bit entre la mscara y el nmero de serie. Los resultados obtenidos luego de las operaciones de enmascarado sern comparados. Si coinciden, el Archivo de actualizacin es aplicable a ese Equipo y se contina con el proceso de actualizacin. Caso contrario, el proceso se aborta ya que ese Archivo de actualizacin no est destinado al Equipo que se est intentando actualizar.
Nmero de serie
MODELO
0 10
AO
0 99
MES
1 12
LOTE
1 255
ID
1 255
Tabla de Mscaras
255 255 255 255 255 0 255 255 255 255 0 0 255 255 255 0 0 0 255 255 0 0 0 0 255 0 0 0 0 0
Fig. 5. Estructura del nmero de serie del Equipo y tabla de Mscaras de restriccin.
En la Fig. 5 se observan los valores posibles que puede tomar el Nmero de serie y tambin la Tabla de Mscaras aplicables al caso en estudio. Dentro de la Tabla de Mscaras, la primera comenzando desde arriba, corresponde al caso ms restrictivo, ya que el nmero de serie del Equipo y el que viene en el Archivo de Actualizacin deben coincidir completamente. La segunda permite actualizar cualquier Equipo de un Modelo, Ao, 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.
143
V.
ESTRUCTURA FINAL DEL ARCHIVO DE ACTUALIZACIN
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 actualizacin, 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 tamao mltiplo del tamao de bloque que usa el algoritmo de encriptacin TEA. A los Datos encriptados se les agregar el vector de inicializacin. Ese conjunto es el que recibir el Equipo a travs del enlace RS232C. A dicho conjunto finalmente, se le agregar una cabecera de Informacin y el SHA-1 para comprobacin de integridad, datos que sern extrados y utilizados por la aplicacin Updater al momento de recibir el Archivo de actualizacin.
Firmware 8 8 4 4 8 Serial Mscara Size CRC Magic # Firmware Firmware + Cabecera de datos Datos encriptados 8 IV Datos Encriptados Conjunto de datos que recibir el Equipo Info Conjunto de datos que recibir el Equipo Archivo de actualizacin Fig. 6. Estructura final del Archivo de actualizacin. Ensamble de partes. 20 SHA-1 Fig. 7. Reestructuracin del mapa de memoria del Equipo, para satisfacer necesidades del sistema. PAD
VI.
REESTRUCTURACIN DEL MAPA DE MEMORIA DEL EQUIPO
Inicialmente el Equipo dispone de una distribucin bsica de la memoria. Toda la memoria FLASH est destinada al Firmware. Lo mismo ocurre con la memoria RAM. El sistema de actualizacin necesita de una nueva distribucin de memoria, como puede verse en la Fig. 7. Se observa que luego de la restructuracin la memoria FLASH queda dividida en 4 areas separadas. Cada una cumple una misin diferente. El BOOT SWITCHER es el punto de arranque del sistema, ya que aqu apunta el vector de RESET. En este rea habr una pequea porcin de cdigo encargado de inicializar el sistema (configurar vectores de interrupcin y excepciones, arranque de reloj, etc.) y de detectar la condicin de trigger, para determinar el modo de arranque del Equipo, esto es, en modo Normal o en modo Actualizacin. La condicin de trigger se configura por hardware, mediante un Dip-Switch, que es la forma ms simple y segura para ello.
Si se detecta un arranque en modo Actualizacin, el control del sistema se pasa al Bootloader, mediante un salto a la direccin de inicio del mismo. El Bootloader es la aplicacin encargada de controlar y llevar adelante el proceso de actualizacin. El Bootloader es una aplicacin independiente que implementa el protocolo antes descripto y se comunica con la aplicacin Updater va enlace RS232C. Si se detecta un arranque en modo Normal, el control del sistema se pasa al Firmware, que es la aplicacin que realiza la funcionalidad normal para la que fue diseado el Equipo.
VII. FUNCIONAMIENTO DEL PROCESO DE ACTUALIZACIN DENTRO DEL EQUIPO. Bsicamente el proceso de actualizacin conlleva los pasos que se describen a continuacin: Una vez que el Equipo se inici en modo Actualizacin y el Bootloader tom control del sistema, se procede a recibir el Archivo de actualizacin, segmento a segmento, los cuales se van depositando en el Buffer Temporal en RAM (ver Fig. 8), para ir reconstruyendo el Archivo de actualizacin. Cuando el Archivo de actualizacin se recibi por completo, se procede a procesarlo. Esto implica desencriptarlo, verificar el Magic Number para autenticar el Archivo de actualizacin, controlar la Restriccin de uso en base a Nmero de serie y Mscara y finalmente chequear el CRC32 general del
144
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 condicin de desocupado. Recibido el nuevo Firmware, se procede a realizar un BackUp 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 versin actualizada de Firmware.
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: 363366. [2] Kelsey, John; Schneier, Bruce; Wagner, David (1997). "Relatedkey cryptanalysis of 3-WAY, Biham-DES, CAST, DES-X NewDES, RC2, and TEA". Lecture Notes in Computer Science 1334: 233246. [3] NIST Special Publication 800-38. Recommendation for BlockCipher Modes of Operation - Methods and Techniques 2001 Edition
X.
-
BIBLIOGRAFA
VIII. CONCLUSIONES Se plante como eje central para este trabajo la actualizacin 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 lgicos 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 solucin 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 informacin, se di paso al diseo del sistema y planteamiento final de la solucin. Esa serie de pasos lgicos posibilitaron un diseo slido y aseguraron que al momento de la implementacin no se debieran pagar costos innecesarios debidos a problemas no considerados tempranamente. Se tuvieron en cuenta para el presente trabajo conceptos bsicos de seguridad de la informacin, buscndose el equilibrio entre el costo de implementarlos y el costo que enfrentara 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 debera llevarse adelante la actualizacin, incluyndose la posibilidad de restaurar el estado anterior del Equipo, en caso de ser necesario. Como cosas pendientes, que escapan a la extensin y profundidad de este trabajo, quedaran el diseo de las aplicaciones de PC, auxiliares al sistema.
Sloss, Andrew; Symes Dominic; Wright, Chris (2004). ARM System Developers 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
145
Actualizacin parcial de software embebido en tiempo de ejecucin en sistemas sin RTOS

Santiago Martnez, Matas Bakalin, Leonardo Steinfeld, Francisco Lanzari
Instituto de Ingeniera Elctrica Facultad de Ingeniera, UdelaR Montevideo, Uruguay santiagolmb@gmail.com, m.bakalian@gmail.com, leo@fing.edu.uy, flanzari@gmail.com
ResumenLa actualizacin 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 difcil acceso o con un alto costo operativo si se trata de gran cantidad de dispositivos. En este contexto, la opcin de realizarlo de manera remota mediante comunicacin inalmbrica resulta una alternativa muy atractiva. Adems puede ser importante minimizar el volumen de informacin a transmitir para disminuir la energa de reprogramacin. Siguiendo esta lnea se han propuesto mecanismos para realizar una programacin parcial. En el presente trabajo, a partir de la observacin de que en muchos de estos sistemas el cdigo correspondiente a la aplicacin es sensiblemente menor en tamao que las bibliotecas utilizadas, se propone un mecanismo para realizar la actualizacin de la aplicacin manteniendo las bibiliotecas. Esta solucin simple logra una implementacin que reduce el costo de reprogramacin, ocupa poca cantidad de memoria y tiene despreciable overhead de ejecucin. Adems sirve como primer acercamiento a alternativas de programacin parcial ms complejas. Palabras Clave; reprogramacin; comunicacin inalmbrica ; software embebido
binaria del software remplaza el programa antiguo, por ejemplo va JTAG o BSL (Bootstrap Loader). ste es el mecanismo ms 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 mtodo anterior tiene un alto costo y es de difcil implementacin logstica. Entonces resulta atractivo realizar la reprogramacin en campo, transmitiendo el nuevo cdigo al equipo que necesita su actualizacin de manera inalmbrica. En diversas ocasiones, solamente es necesario realizar pequeas modificaciones al cdigo, como en la correccin de bugs, por lo que el cdigo binario final slo sufre pequeas 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 tcnica est motivada por la necesidad de minimizar el costo energtico de la reprogramacin y tiene sentido en sistemas donde el costo asociado a la transmisin 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 obtencin de la imagen combinada [1]. Otra alternativa es usar sistemas con mquinas virtuales, ya que por ms que se programe totalmente el sistema, el cdigo interpretado o bytecode generalmente es sensiblemente menor que el cdigo directamente ejecutable[2]. Una alternativa a los mecanismos mencionados anteriormente es la utilizacin de mdulos cargables en sistemas que cuentan con un kernel o sistemas operativos diseados especialmente para contemplar esta funcionalidad. Algunos ejemplos son Contiki [3] y SOS [4], ambos de cdigo abierto. Cuando un nuevo mdulo es cargado, esto es, se incorpora a un sistema ya corriendo, contiene referencias a variables y funciones externas al propio mdulo. Estas pueden ser resueltas en tiempo de compilacin en el host, proceso llamado pre-enlazado, o en el propio sistema embebido en tiempo de ejecucin, llamado enlazado dinmico. Los mdulos dinmicamente enlazados contienen referencias sin resolver, mientras que en los mdulos pre-enlazados stas ya fueron sustituidas por direcciones fsicas absolutas. En el primer caso, la utilizacin de tablas es una tcnica comnmente utilizada para la resolucin de etiquetas, donde el proceso de enlazado es completado en el sistema embebido a travs de tablas donde los
I.
INTRODUCCIN
En el contexto de los sistemas embebidos, con frecuencia es necesario y/o deseable actualizar cierta seccin de cdigo, por ejemplo para la correccin de bugs o modificacin de algoritmos (por ejemplo: encriptacin de datos, codificacin o decodificacin, etc). Tambin puede desearse modificar solamente la aplicacin manteniendo los servicios que bibliotecas existentes ya proveen. Debido a esto, sera deseable y de gran aplicabilidad poseer una herramienta para la actualizacin parcial de cdigo sin necesidad de reprogramar completamente el sistema. Se han propuesto e implementado varios mecanismos para modificar el cdigo dentro de un sistema embebido. La tcnica ms adecuada a cada caso depende de las funcionalidades requeridas y tambin de las limitaciones en trminos de recursos, ya sean de potencia de cmputo, memoria o incluso energa en casos de sistemas porttiles alimentados a pilas. La primera opcin, trivial, para actualizar el software es la reprogramacin total del cdigo, donde una nueva imagen
146
nombres simblicos se traducen en direcciones absolutas. El sistema operativo SenSpireOS [5] contempla la funcionalidad de enlazado dinmico de mdulos SELF (basados en el formato estndar ELF) mediante una tabla de direcciones, con la finalidad de realizar la reprogramacin parcial de los nodos de una red de sensores inalmbricos. [6] La utilizacin 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 cdigo y un overhead de tiempo de ejecucin asociado a la bsqueda en tablas [1]. El presente trabajo plantea dar una solucin simple al problema de la programacin parcial remota en arquitecturas de software donde no se cuenta con un kernel con funcionalidades especiales donde se realiza la actualizacin de la aplicacin manteniendo las bibliotecas. El objetivo es minimizar el costo de reprogramacin a travs de una implementacin con baja cantidad de memoria y despreciable overhead, y que sirva como primer acercamiento a alternativas ms complejas. II. PROPUESTA
la funcionalidad, es necesario que el linker resuelva las llamadas desde la aplicacin 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 interaccin entre las bibliotecas y la aplicacin. Como paso inicial, compilan las bibliotecas junto con una aplicacin de inicializacin y con la tabla con el fin de cargar en la misma las direcciones donde se encuentran alojadas las funciones pblicas pertenecientes a las bibliotecas. De este modo, la llamada a una funcin de las bibliotecas desde una nueva aplicacin puede realizarse mediante una llamada a la direccin de memoria almacenada en el lugar correspondiente de la tabla, permitiendo el acceso a la funcin 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 despus de la actualizacin, donde se puede apreciar el flujo de invocacin para una funcin desde la aplicacin hasta la biblioteca correspondiente. En principio se podra asumir que es posible crear el nuevo software y simplemente enviar al sistema la porcin de cdigo relativa a la aplicacin. 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 aplicacin a las funciones se realizaran a una direccin de memoria diferente a donde estas se encuentran. Mediante el uso de la tabla, es decir, la nueva aplicacin realizando las llamadas a la biblioteca a travs 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 utilizacin de la tabla es que no es necesario disponer de las bibliotecas a la hora de generar la nueva aplicacin.
En base a las consideraciones realizadas, se propone el uso de mdulos pre-enlazados para permitir, en tiempo de ejecucin, la modificacin parcial del software del sistema. El objetivo es actualizar la aplicacin manteniendo las bibliotecas utilizadas por la misma. Para ello es necesario que el sistema a actualizar reciba a travs de una interfaz de comunicacin el cdigo binario de la nueva aplicacin, guardar el mismo en la memoria, tpicamente no-voltil (FLASH), para finalmente comenzar a ejecutar la nueva versin. Para la generacin de dicho cdigo binario es necesario contar con herramientas adecuadas. Es conveniente aclarar que debe tenerse en consideracin el contenido existente en la memoria del sistema que se encuentra ya instalado en campo. Una opcin sera disear un esquema, de cierta complejidad, que a partir de los archivos ejecutables del sistema existente y de la nueva aplicacin, identifique y extraiga la porcin de ejecutable a actualizar. Esto podra realizarse mediante la edicin de los archivos ELF (Executable and Linkable Format) asociados. Sin embargo se opt por una solucin ms sencilla mediante la utilizacin 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 aplicacin. Para permitir la actualizacin de la aplicacin sin sobrescribir las bibliotecas, es necesario organizar las memorias de manera de poder guardar en reas diferentes aplicacin y bibliotecas. Esta solucin, a diferencia de la edicin de los archivos ELF, requiere reprogramar la aplicacin en forma completa. En principio puede considerarse un costo aceptable debido a la sencillez del mtodo en comparacin con otros, ms si se considera que el tamao de la aplicacin, en general, es mucho menor que el tamao de las bibliotecas. A. Tabla de direccionamiento indirecto Durante el desarrollo de una nueva aplicacin basada en bibliotecas, ya sea para corregir bugs o cambiar completamente
Figura 1.
Mapeo en memoria: (A) primer paso: bibliotecas y tabla cargadas en memoria, (B): nueva aplicacin y flujo de invocacin para una funcin.
147
B. Organizacin de las memorias Para que sea posible sustituir la aplicacin y a la vez dejar inalteradas las bibliotecas existentes en la memoria del sistema, es necesario conservar cdigo, 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 opcin de organizacin es disponer de regiones disjuntas en las distintas memorias (FLASH y RAM) para las bibliotecas, la aplicacin presente y la nueva aplicacin. En este esquema se logra guardar completamente la nueva aplicacin sin sobrescribir la aplicacin actual antes de conmutarlas. Tambin es posible sobrescribir la aplicacin corriente con la nueva, ya que todas las rutinas necesarias para realizar la conmutacin (recepcin y escritura en memoria) residiran en la regin destinadas a las bibliotecas. El cdigo, las constantes y los valores de inicializacin residen en FLASH mientras que las variables residen en RAM, por lo que la organizacin 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 Aplicacin en FLASH y en RAM los segmentos Aplicacin, Tabla y cdigo para escritura en FLASH
memoria persistente para finalmente poder ser ejecutados. El grabado en memoria persistente puede sobrescribir el cdigo anterior, minimizando as la cantidad de memoria requerida, o puede ser alojado en un lugar diferente, pudiendo retornar a la aplicacin anterior en caso de problemas tanto con el grabado como en el funcionamiento de la nueva aplicacin. Finalmente, antes de que la nueva aplicacin 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 (configuracin de perifricos, reinicializacin de variables de las bibliotecas, inicializacin de variables de la aplicacin, etc.). III. ESTUDIO DE CASO
Para verificar la metodologa 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 comunicacin 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 comunicacin, SimpliciTI [8], que proporciona un protocolo de comunicacin simple que permite cumplir con el objetivo. Se utiliz el entorno de desarrollo IAR Embedded Workbench 6.0 [9], aunque tambin 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 travs de la radio. Inicialmente se estudi el cdigo del stack para determinar las funciones pblicas utilizadas por la aplicacin, siendo stas las que necesariamente debern ser incluidas en la tabla de direccionamiento indirecto. IV. IMPLEMENTACIN
A continuacin se describen algunas consideraciones importantes a la hora de la instrumentacin de la propuesta, en especial, las relativas a la implementacin particular a este caso de estudio y del conjunto de herramientas (compilador, linker, etc.) utilizado. A. Primeras consideraciones Al momento de guardar la nueva aplicacin en memoria no voltil, 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 aplicacin, 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 opcin es interesante cuando el sistema cuenta con muy poca RAM y se desea optimizar su utilizacin, pero genera overhead a la hora de requerirla (al actualizar). Se mencionaron dos alternativas a la hora de guardar la nueva aplicacin en memoria. Para el caso en el que la nueva
Figura 2.
Mapa de memoria RAM y FLASH con los segmentos involucrados
C. Recepcin de datos y puesta en marcha de la nueva aplicacin Tal como fuera dicho anteriormente, en el proceso de actualizacin, primero debe establecerse una comunicacin entre el sistema embebido (mediante una interfaz de comunicacin) y el sistema que posea el cdigo de la nueva aplicacin 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 aplicacin son recibidos por el sistema embebido y almacenados en memoria voltil, para luego ser grabados en
148
aplicacin sobrescribe a la anterior, es necesario que la rutina de actualizacin conserve el control del sistema hasta que la nueva aplicacin est completamente cargada en memoria y se haya llevado el sistema al estado inicial, para finalmente ceder el control a la nueva aplicacin. El otro caso presenta ms flexibilidad, en el sentido de que la actualizacin podra realizarse en varios pasos y la aplicacin original podra seguir ejecutndose durante la misma, esto si se puede asegurar el correcto funcionamiento de la aplicacin. Una vez cargada la nueva aplicacin en memoria, como se mencion anteriormente, es necesario inicializar el sistema. La inicializacin asociada a la configuracin de perifricos, dispositivos conectados al microcontrolador (como por ejemplo la radio) que es realizada a travs de llamadas a funciones, no presenta problemas. Sin embargo durante el start-up, antes de ejecutar la primera lnea del main, se asigna el valor inicial a las variables estticas inicializadas (segmento data) y se resetean aquellas no inicializadas (segmento bss). Este paso puede realizarse de manera transparente para el usuario, agregando el cdigo de start-up de la aplicacin al realizar la actualizacin, y tambin el de las bibliotecas precargadas, o en forma manual, agregando explcitamente al inicio del cdigo de aplicacin el llamado a las funciones correspondientes para copiar los valores iniciales desde memoria no voltil 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 aplicacin, se gener la estructura de la tabla en un lugar adecuado de memoria y se almacenaron los punteros a las funciones. Tambin 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 explcitamente su ubicacin en memoria y la funcin de inicializacin. En las Figuras 3 y 4 se muestra una seccin de cada archivo, donde se puede apreciar el cdigo relativo a dos funciones de las bibliotecas: BSP_Init() y SMLP_Init(linkID_t).
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 ms miembros }dirfunctions;
Para usar los servicios de las bibliotecas, la nueva aplicacin es compilada utilizando un archivo de encabezado donde se declaran todas las funciones pblicas de las bibliotecas y un archivo donde se definen dichas funciones de manera de acceder al cdigo respectivo a travs de la tabla, tal como se muestra en las Figuras 5 y 6.
void BSP_Init(void); smplStatus_t SMPL_Init(funptr); // siguen ms prototipos
Figura 5.
Archivos de encabezado con todas las funciones publicas de las bibliotecas.
__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); }
Figura 6.
Archivo con las definiciones de las funciones.
Se puede observar el "cast" al tipo puntero correspondiente y la utilizacin de segmentos de memoria creados especficamente para la aplicacin, con el fin de independizar en memoria el cdigo perteneciente a la aplicacin del perteneciente al stack de comunicacin. Para lograr ubicar los diferentes segmentos segn la organizacin de memoria elegida se utilizan opciones especficas del linker [11]. Ello es posible modificando un archivo de configuracin 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.
// 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
Figura 3.
Archivos encabezado tabla.h.
__no_init dirfunctions dfunctions @ 0xFFC0; void table_init(void){ dfunctions.d1 = BSP_Init; dfunctions.d2 = SMPL_Init; // siguen ms miembros }
Figura 7.
Definicin de segmentos.
Figura 4.
Archivo tabla.c
Una vez creados los segmentos deseados desaparecen los problemas asociados a la sobrescritura de datos y se tiene campo frtil para intentar recibir una nueva aplicacin. La recepcin de la nueva aplicacin se realiza a travs de la UART del microcontrolador. C. Escritura en FLASH de la nueva aplicacin Para escribir la nueva aplicacin en memoria FLASH, debido al microcontrolador utilizado, fue necesario utilizar una
De esta manera, se crea una tabla en la direccin 0xFFC0 y al ejecutarse la funcin table_init() quedan guardadas en la misma las direcciones donde se encuentran las funciones.
149
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 daar 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 ejecucin. Las rutinas mencionadas anteriormente, especficas para el microcontrolador MSP430, forman parte de los cdigos 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 aplicacin se reduzca a unos 150 bytes aproximadamente. Por lo tanto, en caso de que la misma supere dicho lmite, 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
dispositivos, un receptor y un transmisor. La informacin correspondiente a la salida del linker se presenta en la figura 8. Luego se compil una nueva aplicacin 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 aplicacin segn los cambios de funcionalidad introducidos.
El sistema se fue probando y verificando con cada paso de la implementacin. La metodologa fue bsicamente la misma para todos los casos, debbugear la aplicacin, prestando atencin 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 ubicacin correcta y se guardaran en ella las direcciones donde efectivamente se encontraban las funciones en cuestin. Para esto se tuvieron que superar varios inconvenientes, como la ubicacin en memoria y la inicializacin de estructuras "a posteriori", con el uso de directivas como @ y "__no_init" respectivamente para este compilador. Luego de esto se prob la tcnica de direccionamiento indirecto propuesta. Para esto se carg en memoria el cdigo perteneciente al stack de comunicacin y se gener la tabla, se configuraron opciones de la plataforma de desarrollo para que se mantenga la informacin en la memoria y se carg la aplicacin utilizando el direccionamiento indirecto. Es decir, se compil nicamente la aplicacin con los archivos de direccionamiento indirecto y se carg en memoria. Ejecutando paso a paso la aplicacin se verific que las llamadas a las funciones efectivamente pasaban por la tabla, llamando correctamente a las funciones que deba, como era esperado. La rutina de recepcin de datos se prob enviando datos hacia la UART del sistema, utilizando para la comunicacin el programa Hrcules (freeware) [13]. Se verific la llamada a la rutina de atencin a la interrupcin de la UART y la correcta recepcin 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 haba 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 aplicacin y la tabla en dos Figura 9.
Disposicin de segmentos en memoria y tamao de cdigo, caso indirecto.
Figura 8.
Disposicin de segmentos en memoria y tamao de cdigo, caso directo.
150
Se observ que el cdigo de la aplicacin corresponde al 8% (576 bytes de cdigo ms 236 bytes de datos) del total de la aplicacin incluyendo las bibliotecas (como se observa en el resumen de memoria de la Figura 9). En tiempo de ejecucin, cuando se realiza una llamada a una funcin, se posee un overhead de ejecucin de 2 instrucciones jump respecto al caso original. A continuacin, en la Tabla 1, se presentan para diferentes aplicaciones ejemplo incluidas en el stack SimplicitTI: el tamao total de la aplicacin incluyendo las bibliotecas, la cantidad de bytes a transmitir correspondiente a la aplicacin y finalmente el porcentaje que representa la aplicacin respecto al total. Estas valores fueron obtenidos a partir del anlisis 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 aplicacin ms el overhead asociado a la tcnica representa entre el 3% y el 7% del total del software embebido de aplicaciones ltimas analizadas, siendo la aplicacin Simple peer to peer, implementada y probada, la que resulta en el mayor peso relativo, 8%. Esto significara un ahorro energtico en costo de reprogramacin de ms de 90% en todos los casos en comparacin con la reprogramacin total.
Aplicacin Polling whit Acces Point (Sender) Polling whit Acces Point (Receiver) Polling whit Acces Point (Acces Point) Cascading end Devices Acces Point as Data Hub(End Device) Acces Point as Data Hub(Acces Point) Acces Point as Data Hub(Chanel Sniffer) Acces Point as Data Hub(Range Extender) Cantidad de Cantidad de Porcentaje de bytes totales bytes a retransmitir retransmisin 7548 7756 6794 6924 8767 9885 6897 6854 544 544 260 399 409 705 384 216 7.2% 7.0% 3.8%
Se dise e implement un sistema basado en la metodologa propuesta, pudiendo verificar la confiabilidad de la misma. Se han contrastado los resultados obtenidos contra los del sistema sin direccionamiento indirecto obtenindose para este caso particular un costo en memoria del 8% del total de espacio ocupado por el cdigo original. Es decir que para realizar la actualizacin slo es necesario transmitir el 8% del cdigo que se debera transmitir si se cargaran nuevamente las bibliotecas junto con la aplicacin. Se ha estimado para otras implementaciones un costo de retransmisin que oscila entre el 3% y 7% del cdigo 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. 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. A. Dunkels, B. Grnvall, and T. Voigt. Contikia Lightweight and Flexible Operating System for Tiny Networked Sensors. In EmNets, Tampa, Florida, USA, November 2004. 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. 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. 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 Texas Instruments, MSP430 Wireless Development Tool, EZ430RF2500, disponible: http://focus.ti.com/docs/toolsw/folders/print/ez430rf2500.html; consulta: octubre de 2010. Texas Instruments; SimpliciTI Compliant Protocol Stack, disponible http://focus.ti.com/docs/toolsw/folders/print/simpliciti.html; consulta: octubre de 2010. IAR Systems, IAR Embedded Workbench 6.0; disponible: http://www.iar.com/; consulta: octubre de 2010. 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. IAR Systems, IAR Linker and Library Reference Guide. disponible: http://ftp.iar.se/WWWfiles/guides/xlink.pdf; consulta: octubre de 2010. Texas Instruments, MSP430 16-bit Microcontroller Code Examples and Function Library; disponible: http://www.ti.com/lit/zip/slac123; consulta: octubre de 2010. HW Group, Hercules Utilities; disponible: http://www.hwgroup.com/products/hercules/index_es.html; consulta: ocutubre de 2010.
[2]
[3]
[4]
[5] 5.8% 4.7% 6.1% 5.6% 3.2% [9] [10] [6]
[7]
[8]
Tabla 1. Tamao relativo de diferentes aplicaciones incluidas en SimpliciTI.
VI.
CONCLUSIONES
[11] [12]
Se propuso una solucin simple al problema de la reprogramacin parcial que permite la actualizacin de la aplicacin de manera remota utilizando comunicacin inalmbrica. Se logr una implementacin que ocupa poca cantidad de memoria y tiene despreciable overhead de ejecucin.
[13]
151
Muestreo y Adquisicin Inteligente de Seales Sensoriales en Sistemas Embebidos

Gustavo Monte, Kector Kessel, Norberto Scarone, Cesar Almendra
Universidad Tecnolgica Nacional - Facultad Regional del Neuqun Plaza Huincul - Argentina gmonte@frn.utn.edu.ar
Resumen- Hoy en da es muy comn encontrar el prefijo inteligente en los sistemas que el hombre desarrolla. Encontramos desde fusibles inteligentes hasta autopistas inteligentes. La razn de esta inteligencia es que dada la complejidad de los sistemas actuales, los diseadores la han trasladado a los dispositivos con el objetivo de simplificar la operacin al usuario final. Un ejemplo tpico es la filosofa Plug and Play. Aprovechando la capacidad actual de los sistemas embebidos, este trabajo presenta tcnicas y algoritmos con el objetivo de sumar inteligencia al proceso de muestreo de una seal analgica. Empleando tcnicas de sobremuestreo e interpolacin adaptiva se logra analizar la seal, inferir estados, predecir comportamientos y validar la seal digitalizada. La seal a digitalizar es un proceso aleatorio, lo nico que se conoce de antemano es su limitacin 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 anlisis certero sobre la seal. Se presentan resultados experimentales desarrollados en microcontroladores para validar los algoritmos propuestos.
SEAL
CAPA OBSERVABLE
INFORMACIN
Procesar una seal implica extraer la informacin embebida en ella
Figura 1. La informacin que transporta una seal generalmente se encuentra oculta. Procesar una seal implica extraer la informacin embebida en el ncleo de ella.
Palabras Clave Sensores Inteligentes, sobremuestreo, muestreo inteligente. I. INTRODUCCIN
Si la seal en el mundo real es analgica, debe ser convertida en una representacin digital que pueda ser entendida por el sistema embebido. La conversin de una seal en digital es realizada por el conversor analgico 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 ms simple, pero no la nica, de conversin es el muestreo uniforme. Otros tipos de muestreo incluyen muestreo por cruce de nivel [1] y muestreo no uniforme [2].
Los sistemas embebidos realizan sus decisiones en base a las seales de los sensores incluidos en l. Las seales provenientes de los sensores es la fuente de informacin disponible para cumplir el objetivo de diseo de un sistema de instrumentacin y/o control. Estas seales proporcionan la abstraccin del mundo real. Una seal es una entidad cuantificable de alguna forma de informacin. Ms valiosa es la seal cuanto ms informacin se encuentra embebida en ella. El concepto clave es la informacin que recibe el sistema. La Fig. 1 representa este concepto en forma grfica. Esta informacin se encuentra inmersa en la seal, por lo tanto generalmente es necesario procesarla. An en seales analgicas, no es necesario conocer el valor de la seal todo el tiempo. La mxima velocidad de cambio de una seal determina el intervalo de tiempo mnimo que se necesita conocer a la seal para poder inferir su comportamiento dentro l.
Mundo real
X(t)
Mundo digital
00101110 00110010 00110001 01000100 01000000 00110010 00110001 00010111 X{n}
Conversor A/D
t t t
Figura 2. El conversor analgico digital es el elemento interfase que permite la representacin de las seales reales en el mundo digital. En este caso,, muestreo uniforme, que transforma la seal en una secuencia ordenada de nmeros.
152
t , se toman muestras de la seal y se convierten en un
En el caso de muestreo uniforme, a intervalos regulares
cdigo correspondiente a un alfabeto finito, es decir una cantidad limitada de representaciones posibles. Tambin el esquema ms simple es el de dividir el rango dinmico del sensor en M divisiones de igual longitud, proceso que se conoce como cuantificacin uniforme. Otros tipos de cuantificacin se adaptan a la funcin densidad de probabilidad de la seal esperada. Es decir, para los valores ms probables de la seal se disminuye la amplitud de la cuantificacin. El pasaje del mundo real al digital tiene dos particularidades importantes. Primero, la seal que existe para todo tiempo, es considerada solamente cada t segundos. Segundo la seal analgica, que es libre de tomar cualquier valor de amplitud, es forzada a una representacin finita en el mundo digital, transformndose en una secuencia ordenada de nmeros. 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 seal todo el tiempo para obtener una representacin digital fidedigna siempre y cuando la seal posea un limite mximo de contenido espectral. El teorema determina que debemos tomar muestras a una frecuencia de por lo menos el doble de la mxima frecuencia presente en la seal. Es un lmite terico que necesita filtros reconstructores ideales para obtener sin error el valor de la seal entre las muestras. Si la seal se encuentra limitada en frecuencia hasta una fmax, las muestras, en un muestreo uniforme se deben realizar como mnimo a 2fmax. Como resultado del proceso de muestreo uniforme se obtiene una secuencia ordenada de nmeros que representan la seal, siempre y cuando se haya respetado el teorema de muestreo para evitar el aliasing. Hasta aqu se ha descripto un proceso convencional de digitalizacin. La secuencia ordenada de nmeros es la seal en el mundo digital a partir de la cual se debern tomar todas las decisiones en el sistema. Un sensor inteligente con capacidad de procesamiento embebida debera procesar el vector de muestras digitales con el fin de tomar conciencia de la seal que obtuvo.
Recordemos que el proceso de muestreo es el punto de conexin a travs del cual se infiere el mundo real. En un sistema de control, todas las acciones estarn basadas en esta informacin. En la Fig. 3 se observa una seal tpica proveniente de un sensor. Un proceso de muestreo inteligente implica ver a la seal en su conjunto, no solo una muestra. Si un ser humano observa la Fig. 3 podra sacar conclusiones tales como: la seal es ascendente, hay una forma tipo impulsiva que provoca un pico positivo y uno negativo. La seal proveniente del sensor es un proceso aleatorio. Los parmetros que se conocen previamente son la limitacin en ancho de banda, impuesta por un filtro antialiasing, y su rango dinmico. En general, no se conoce la funcin densidad de probabilidad de la seal. La presencia de ruido, malfuncionamiento del elemento sensor o errores en la conversin deberan ser detectados. Las caractersticas deseables de un sensor inteligente con respecto a la seal que adquiere seran:
Determinar la frecuencia de muestreo ptimo. Reconocer la forma de la seal. Predecir valores. Validar la seal. Marcar particularidades. Almacenar valores pasados en forma comprimida. Detectar patrones en forma automtica y/o predeterminada.
X ( t)
En las secciones siguientes se desarrollan los algoritmos propuestos en busca de las anteriores caractersticas. Se mantiene el muestreo uniforme pero la seal 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 segmentacin en tiempo real basada en interpolacin lineal adaptiva. Luego los segmentos son etiquetados reflejando el comportamiento dentro de l. Con esta informacin se detectan secuencias de segmentos que identifican comportamientos globales. Estos tres procesos conforman la base para el anlisis de la seal muestreada. II. DESCRIPCIN DE LOS ALGORITMOS De acuerdo al teorema de muestreo, debemos tomar dos muestras, como mnimo, en el tiempo correspondiente al periodo de la componente de frecuencia mxima de la seal. Si comenzamos a aumentar la frecuencia de muestreo, surgen dos preguntas: Hasta que valor tiene sentido aumentarla? y
t
Figura 3. El muestreo inteligente debe ver a la seal completa, no solo una muestra a digitalizar.
153
Que beneficios otorga este incremento? Las respuestas a estos interrogantes surgen del siguiente anlisis. Sea x(t) la seal a ser muestreada, limitada en banda a fmax Hertz. Consideremos el caso particular que x(t) es una seal sinusoidal de mxima amplitud y frecuencia.
Entre los beneficios que brinda el sobremuestreo se encuentra una reduccin efectiva del ruido de cuantificacin, [3]. Es importante resaltar que la seal que poda tomar infinitos valores entre dos puntos en el mundo analgico, es forzada a un alfabeto finito. Ms aun empleando la restriccin 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 seal. 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 informacin [4]. En condiciones de sobremuestreo, las muestras pierden valor relativo si su valor puede ser obtenido mediante interpolacin de sus muestras vecinas.
x ( t ) Asen (2 f max t )
(1)
Donde A es la mitad de rango dinmico del conversor. Si transcurren t segundos tenemos:
x (t t ) Asen(2 f max (t t ))
Por lo tanto:
(2)
b) (3)
x(t t) x(t) A [sen(2 fmax(t t) sen(2 fmaxt)]
El lado izquierdo de (3) corresponde al cambio de la seal entre dos instantes de muestreo. Si fijamos este cambio a 1 bit menos significativo, un LSB, obtenemos:
2A A [ sen(2 f max (t t ) sen(2 f max t )] (4) 2N

Donde N es la cantidad de bits del conversor A/D. La mxima velocidad de cambio de la sinusoidal ocurre en los cruce por cero. Tomando t=0 para simplificar obtenemos de (4):
Las muestras que no pueden obtenidas mediante una combinacin lineal de sus vecinas, transportan en algn sentido ms informacin y las llamaremos muestras esenciales. Las muestras esenciales marcan lmites naturales de segmentos de la seal con un comportamiento uniforme. En [5] se describen ampliamente los algoritmos propuestos y aqu presentaremos solamente un resumen. El algoritmo de segmentacin 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 informacin ya que su valor puede ser calculado mediante interpolacin lineal de sus muestras vecinas. El prximo paso es interpolar la muestra 3 mediante las muestras 1 y 5 y as siguiendo. Cuando se supera el error de interpolacin 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 nmero determinado de muestras se culmina el segmento a ese mximo de muestras. De esta segmentacin, 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 seal sobremuestreada. Un tercer vector clases(n) determina el comportamiento de la seal 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 seal 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
2 N 1 sen(2 f max t )
(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 pequeos obtenemos:
fs f max
2N
(6)
Por ejemplo, empleando (6), para N=8 bits obtenemos una frecuencia de muestreo de aproximadamente 400 veces la de Nyquist. Dada una resolucin del conversor, (6) determina la mxima frecuencia de muestreo que tiene sentido aplicar ya que valores mayores daran como resultado la misma muestra. La ecuacin (6) se determin para una seal sinusoidal pura de mxima amplitud y frecuencia. Considerando una seal real y que el contenido espectral es en general decreciente con la frecuencia, un factor de 10% del mximo obtenido es razonable.
154
de error y el segmento se termina por alcanzar el lmite mximo de segmento.
comportamiento determinado de la seal muestreada. En la Fig. 6 se observa una seal ejemplo. Considerando solamente el vector clases obtenido podemos inferir el comportamiento de la seal a travs de los siguientes patrones: En la primera porcin de la seal hay un crecimiento exponencial dado por la secuencia de segmentos g. Se alcanza un mximo que ocurre en la unin de segmentos g y e. A partir del mximo, la seal 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 seal decae en forma exponencial para alcanzar un mnimo que ser localizado con precisin en la unin de los segmentos f y d.
seal s e n s o r ia l X t)
fs
s o b r e m u e s tr e o
R e s u lta d o : v e c to r d e s e a l c o n r e d u n d a n c ia
S e g m e n ta c i n tie m p o r e a l
R e s u lta d o : V e c to r d e m u e s tra s e s e n c i a le s y v e c to r d e p o s ic io n te m p o r a l
A n lis is in tr a s e g m e n to
R e s u l ta d o : V e c to r d e c l a s e s a ,b ,c ,d ,e ,f,g ,h
A n lis is in te rs e g m e n to
R e s u lta d o : D e te c c i n d e p a tr o n e s : E x p o n e n c ia l, s in u s o id a l, r u i d o s o , fre c u e n c ia d e m u e s tr e o o p tim a , r u i d o im p u ls iv o , p r e d ic c i n , c o m p re s i n .
Figura 4. Esquema del proceso de anlisis de la seal sobremuestreada.
Figura 6. Vector clases sobre una seal testigo.
a b c d e f g h
c o n s ta n te lin e a l + lin e a l ( - ) + exp+ (-)e x p + c + e x p (-) c -e x p (-) r u id o s o
Mediante estas simples observaciones, el sistema embebido es conciente de la seal que esta digitalizando, prcticamente en tiempo real. Es importante remarcar que si el error de interpolacin tiende a un LSB, la probabilidad de ocurrencia de los segmentos a,b,c y h tienden a cero. Bajo esta condicin, y con la seal suficientemente sobremuestreada, el comportamiento de la seal queda especificado solamente por los cuatro segmentos d, e,f y g. El anlisis del comportamiento macroscpico de la seal es posible mediante las secuencias de patrones de clases de segmentos. Por ejemplo, la ocurrencia consecutiva de segmentos tipo g indica que la seal se esta estabilizando a un valor de estado estacionario que podra incluso predecirse. Esta prediccin es analizada en la siguiente seccin. Mediante el anlisis de la cantidad de muestras de los segmentos obtenidos, el sistema embebido podra ajustar l mismo la frecuencia de muestreo. La frecuencia de muestreo ptima para una porcin de seal es la frecuencia de sobremuestreo dividida por la cantidad de muestras del segmento ms corto en dicha porcin de la seal. La longitud de los segmentos es un parmetro importante ya que determina como se aparta la seal de un comportamiento lineal. La Fig 7. Detalla la deteccin de algunos comportamientos macroscpicos.
Figura 5. Clasificacin de segmentos en ocho clases.
A. Anlisis inter-segmento La informacin proporcionada por los tres vectores mark(n), timepos(n) y clases(n) proporciona una plataforma de anlisis para inferir comportamientos de la seal 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 patrn de secuencia de clases de segmentos especifica un
155
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 tiv a d e s eg m e nto s tip o g d e lo n g itu d es cre ci en te s.
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 anlisis de prediccin empleando las muestras esenciales y la pendiente en esos instantes. Este tipo de prediccin es importante en sistemas de control [6]. La expresin general de exponencial en la Fig. 9 es:
x(t ) Xss ( Xss Xi) e t / T
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 ci a c o n se c u tiv a d e s e g m e n to s tip o d de lo n g itu d e s d e c re c ie n te s .
(7)
C o m p orta m ie n to o s ci la to rio : S e c u e nc ia d e s e g m e n to s ti p 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 l os m n im os e n la u n i n d e f yd . A n a liz a n d o lo s v al o re s d e l os m xim o s y m n im o s s e d e te rm in a s i l a 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 i do 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 l a s l o 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 ifi co s : E n es te ca s o e l p a tr n Q R S T
Donde Xss es el valor en estado estacionario y Xi el valor inicial. La derivada de x(t) respecto de en t=0 es: dx Xss Xi (8) t 0 dt T La pendiente de los segmentos puede emplearse como la aproximacin 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: Xss Xia Ma (9) T Donde Ma Ya Xa es la aproximacin de la pendiente en el punto a. Repitiendo el anlisis ahora en el punto b, y empleando este punto como valor inicial obtenemos: Xss Xib Mb (10) T Donde Mb Yb es ahora la aproximacin de la pendiente Xb en el punto b. Resolviendo (9) y (10) obtenemos (11).
Xss Ma Xib - Mb Xia Ma-Mb (11)
Figura 7. Deteccin de comportamiento macroscopico mediante analisis inter segmento.
III. RESULTADOS EXPERIMENTALES Los algoritmos de segmentacin y clasificacin 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 9 Prediccin del valor estacionario de la seal basada en los cambios de pedndiente en los segmentos tipo g.
En la Fig. 10 se observa el algoritmo de segmentacin y clasificacin de segmento implementado en lenguaje C de CCS inc sobre el 12F683. Se diseo siguiendo la filosofa de programacin Estado-Cooperativa. Por limitaciones de memoria RAM, 128 bytes, se limit la longitud del segmento a 48 muestras. Un microcontrolador adecuado para estas tcnicas es el dsPIC33FJ12GP de Microchip, el cual fue diseado para aplicaciones de sensores inteligentes, permitiendo digitalizar a 1.1 millones de muestras por segundo.
Figura 8 Implementacin de un sensor inteligente de temperatura de bajo costo.
156
IV CONCLUSIONES La potencia de los sistemas embebidos actuales ha cambiado no solo la topologa de nuestros diseos, sino adems 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 normalizacin de estos algoritmos fue presentada en [7]. El intercambio de informacin mediante un lenguaje comn entre sensores de un sistema permite el aumento de confiabilidad, la prediccin anticipada de estados anormales, la deteccin de patrones normales y anormales y el aprendizaje de patrones en forma automtica. Los algoritmos presentados son simples pero muy efectivos. Capturan la esencia de la seal muestreada, y representan la informacin presente en ella. Si el error de interpolacin tiende a un LSB los cuatro segmentos d,e,f y g codifican la seal como si fuera el cdigo gentico de ella.
REFERENCIAS
[1]
N. Sayiner, H.V. Sorensen and T.R. Viswanathan, A LevelCrossing 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. Marten D. van der Laan. Signal sampling techniques for data acquisition in process Control. Thesis Rijksuniversiteit Groningen. 1995. ISBN 90-367-0502-9.
[4]
[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. 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.
[6]
[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. . Figura 10 Algoritmo de segmentacin y clasificacin de segmento implementado en el microcontrolador 12F683.
157
Controlador de carga para un sistema fotovoltaico aislado

Daniel Hoyos, Maiver Villena, Vctor Hugo Serrano, Federico Farfn, Carlos Cadena
Universidad Nacional de Salta INENCO Instituto de Energas Renovables Salta, Argentina hoyosdani@unsa.edu.ar
Telmo Moya
Universidad Nacional de Salta Salta, Argentina telmomoya@gmail.com
Resumen El siguiente trabajo tiene por objeto analizar los componentes ms importantes que influyen en el diseo de una instalacin 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. batera, controlador de carga,inversor, microcontrolador, panel fotovoltaico
I.
INTRODUCCIN
Figura 2. Panel fotovoltaico
Un sistema fotovoltaico como se muestra en la Fig. 1 est compuesto por: panel fotovoltaico, batera, controlador de carga, inversor, que transforma corriente continua a corriente alterna en 220 V y la carga del sistema.
Rs: resistencia serie, Rp: resistencia paralelo, n: factor de idealidad del diodo. La corriente fotogenerada se determina en funcin de las dimensiones de la clula, 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.
Figura 1. Esquema general de un controlador fotovoltaico
El valor de I1 lo determinamos con la siguiente ecuacin: I1 = A (Jsc G/1000 + Jsc (T 27)) (2)
El panel fotovoltaico tiene una curva de funcionamiento como la de la Fig. 2 y es el resultado de asociar un conjunto de clulas fotovoltaicas en serie y en paralelo. La descripcin elctrica de la clula [2] responde a la siguiente ecuacin: I = Il - I0 [exp ((V + I Rs ) / n Vt) -1] - (V + I Rs ) / Rp (1) Il: Corriente fotogenerada, I0: Corriente de saturacin inversa del diodo, Vt = kT/e: voltaje trmico, T: temperatura en grados Kelvin,
Lo que implica que al aumentar la radiacin aumenta la corriente de cortocircuito y la grfica se desplaza hacia arriba. Si se supone que el sistema a controlar es aislado y se utiliza fundamentalmente para dar iluminacin nocturna, la situacin habitual en nuestro pas, el diagrama de consumo elctrico es el mostrado con trazo discontinuo en la Fig. 3, mientras que la radiacin solar tiene su pico alrededor de las 13 horas [1], por lo tanto la corriente que puede suministrar el panel responde a una distribucin del tipo mostrado en la misma Fig. 3. Se utiliz un modelo de radiacin de da claro
158
modificado, el cual responde en forma aproximada a la regin montaosa de Argentina [1]. De la observacin de los grficos se puede inferir que el ciclo de carga y descarga de la instalacin es de 24 horas en el cual la batera se descarga durante la noche y el atardecer para cargarse durante el da segn la radiacin incidente. El ciclo de descarga no puede controlarse porque es funcin 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 energa consumida por la carga el da anterior y devolverla si se puede en el da siguiente. Este algoritmo no busca obtener la mxima energa del panel, debido a que basa su funcionamiento en optimizar el ciclo de carga de la batera el cual es el elemento ms dbil de un sistema fotovoltaico aislado. Para que el sistema funcione ptimamente no se puede superar la tensin de gaseo de la batera.
En donde V es la tensin a partir de la cual la batera empieza a gasear y t es la temperatura ambiente. Se debe tener en cuenta que no es conveniente para la batera una carga rpida y tampoco es conveniente para el panel tener largos perodos 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 batera durante la mayor parte del da.
III.
HARDWARE DEL CONTROLADOR DE CARGA
El controlador est compuesto por tres bloques: medicin, potencia y control. El bloque de medicin se encarga de medir la corriente suministrada por el panel fotovoltaico y la corriente entregada a la carga, la tensin de batera y la temperatura ambiente. El bloque de potencia es el encargado de suministrar corriente a la batera utilizando modulacin por ancho de pulso y transistores HEXFET IRFZ44N. Para controlar la carga solamente se desconecta cuando la tensin de la batera es menor que 11,3 V o la corriente es mayor que un determinado valor.
A. Medicin Un esquema del circuito de medicin 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 3. Curva aproximada de la distribucin de la corriente recibida y entregada por el sistema.
II.
ACUMULADORES
Las bateras utilizadas en este caso son del tipo de Pbcido. Para el anlisis del sistema se utiliza el modelo de Coppeti [2], el cual es muy sencillo y funciona aceptablemente sobre un nmero muy grande de bateras presentes en el mercado local. La eleccin de la misma se realiza en funcin del parmetro capacidad en Amper-hora que sera la mxima energa que puede entregar la batera hasta descargarse completamente. La energa til es un valor que se encuentra afectado de un coeficiente que para las bateras analizadas en este trabajo es de 0,3. Lo que significa que si se dispone de una batera de 150 Ah. la profundidad de descarga mxima que se puede realizar es de 50-60 Ah. El acumulador cuando se carga invierte energa para su propio funcionamiento lo que implica una prdida de carga, por ello se define un coeficiente denominado eficiencia; el cual puede ser del orden de 0,9 en los acumuladores que se estn utilizando. La evaporacin del electrolito es funcin de la temperatura ambiente y de la tensin de la batera. Una aproximacin de primer orden de este fenmeno responde a la ecuacin: V = 0,05 t + 12,5 (3)
Figura 4. Esquema del circuito de medida de corriente
El valor de las resistencias de shunt depende de la corriente mxima del controlador de carga y de la potencia mxima que se desea disipar en las bateras. . Los valores de R1 y R2 son crticos ya que un valor de resistencia elevado disminuye el rendimiento del sistema y un valor muy pequeo disminuye la sensibilidad de la medida de corriente. El sistema de control est alimentado por una tensin de 3.3V, siendo esa la mxima tensin que puede medir. Por lo tanto se debe atenuar la tensin para que pueda ser medida a costa de disminuir la mnima corriente que se puede medir. Para no perder resolucin se utiliza un amplificador diferencial, con ganancia unitaria de forma que ninguna tensin sea superior a 7 V para evitar que el amplificador se sature. La ganancia de tensin del amplificador diferencial ser 1 y la ganancia del amplificador no inversor ser de 3,3.
159
Este circuito fue modificado y se probaron nuevas configuraciones con MOSFET tipo P y tipo N siendo la mostrada en la Fig. 6 la ms prctica cuando se requieren corrientes mayores.
C. Control El bloque de control est compuesto bsicamente por un microcontrolador 16f877 y el circuito puede verse en la Fig. 7. La medicin de la temperatura se realiza utilizando un circuito integrado especialmente diseado para este fin, el LM35 que tiene una sensibilidad de 10 mV/C.
Figura 5. Circuito de medicin
5.
El circuito utilizado para la medicin puede verse en la Fig.
La expresin del nmero de cuentas en funcin de los distintos parmetros del circuito es [1] Nc=k2(k1.R1I+V1).2n/Vref En donde: Nc= nmero de cuentas k1= ganancia del amplificador diferencial k2=Ganancia del amplificador inversor R1= resistencia de shunt n= nmero de bits Vref=Tensin de referencia V1= Tensin para evitar la saturacin de los amplificadores operacionales.
Figura 7. Circuito de control
(4)
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 batera mientras que T2 se utiliza slo para desconectar la carga en caso de sobre corriente o que la batera se encuentre muy descargada.
El microcontrolador tiene por entradas las tensiones: Vcap encargada de medir la tensin del capacitor que polariza las compuertas de los MOSFET de potencia en el canal 0 del microcontrolador, Vcp que es la tensin que representa la corriente del panel en el canal 1, Vcc que es la tensin que representa la corriente de la carga en el canal 2, Vtb que es la tensin de la batera en el canal 3 y la temperatura es sensada por el canal 4. Las seales de salida sern las tensiones: T1 encargada de controlar la corriente de carga de la batera, utilizndose para esta salida el mdulo 1 de modulacin por ancho de pulso y T2 que controla la descarga de la batera y slo se utiliza para desconectar la batera en caso de sobrecarga, cortocircuito o batera muy descargada. El sistema tiene dos leds que informan si la batera est cargada o no.
IV.
CONTROL DEL SISTEMA
El control de este sistema debe tener en cuenta que:

Figura 6. Circuito de control de potencia
160
La batera 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 da a la batera.
A. Control de la evaporacin del electrolito La temperatura se mide con un LM35, que tiene una sensibilidad de 10 mV/C, el cual nos indica la tensin 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 batera una cantidad de carga igual a la consumida durante el da anterior. En la Fig. 8 se puede observar la distribucin de la corriente del panel a lo largo de un da tpico sin nubosidad, para realizar el control se supuso que la cantidad de corriente que puede entregar el panel es una funcin triangular, como se observa en la figura, siendo sta una aproximacin de primer orden con respecto a la distribucin real. El valor mximo de esta distribucin es el correspondiente a la hora de mxima radiacin, el medioda solar. Por lo tanto la carga que puede entregar este sistema ser igual a la mxima corriente que puede suministrar el panel multiplicado por la duracin del da dividido 2, integral de la funcin triangular
Figura 8. Distribucin diaria de las corrientes del sistema
Este valor en general es mayor que el consumo de la carga de la instalacin, como se muestra en la Fig. 8. Por lo tanto si se desea reponer la carga a lo largo del da, se debe entregar en cada intervalo de tiempo la relacin entre la carga consumida en el da anterior y la carga mxima posible. Se utiliza con este fin modulacin por ancho de pulso (PWM), la cantidad de corriente entregada en PWM es proporcional a la relacin entre el periodo de la funcin y el tiempo de alto. Se mide la corriente de carga de la batera y la corriente de descarga, se integran estos valores a lo largo de un ciclo de un el da anterior se determina el periodo y el tiempo de alto de la modulacin por ancho de pulso.
Figura 9. Secuenacias del ciclo de carga y descarga del controlador da, con el valor mximo terico y con la carga consumida
En la Fig. 9 se puede observar una simulacin de cuatro das de operacin del controlador de carga, CDA significa carga consumida el da anterior por el sistema en Amper hora, PWM modulacin por ancho de pulso, CNR carga no restituida a la batera al final del da por el sistema y CG energa consumida por la carga durante el da. Las funciones mostradas en la grafica son: Ifoto que es la corriente que puede
161
suministrar el panel, cargar que es la energa en Amper hora que el panel est enviando a la batera, Carga es la corriente en Amper que esta consumiendo la instalacin y amperc es la emerga consumida por la instalacin a lo largo del da. El controlador de carga mide la energa consumida por la instalacin durante la tarde y la noche restituyendo este valor durante el da siguiente, Fig. 9a. Cuando la energa consumida supera la carga que puede restituir en un da, Fig. 9b, el controlador restituye la carga en los das subsiguientes, Fig. 9c y Fig. 9d. Si se observa en la Fig. 9c el controlador aprovecha toda la energa disponible siendo la relacin PWM = 1 en caso que la energa requerida sea mayor que la que puede aportar, en Fig. 9d se encuentra en rgimen normal. Este algoritmo de control es muy sencillo, slo necesita que al comenzar a operar el sistema se reinicie temprano a la maana del primer da, cuando la radiacin es casi cero y no se comenz a consumir energa de los acumuladores. Pero tiene algunos problemas, por ejemplo si una nube disminuye notablemente la radiacin solar el sistema no puede acomodarse para reponer en el da la energa consumida. El algoritmo de control no distingue en qu momento del da se encuentra el controlador. Por lo tanto se realiz una modificacin, 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 duracin del da es la diferencia entre amanecer y atardecer y la maana la primera mitad del da. Tarde la segunda mitad del da. Se calcula la relacin de modulacin por ancho de pulso para la maana y la tarde de forma que cada una debe restablecer la mitad de la carga del da.
modulacin 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 da. Con estos valores se determina el medioda, donde se recalcula la relacin de modulacin PWM. Por ejemplo un da de 10 horas tendr 40 perodos de 15 minutos y la energa ser proporcional a 151*40/2=3020 cuentas, un da de 14 horas tendr como mximo terico 8456. La energa consumida por la carga tambin es proporcional a la cuenta obtenida de sumar todas las cuentas obtenidas al medir la corriente en la carga. Por esta razn se divide el mximo terico de energa suministrada por el panel en cuentas por 32 que da como resultado 149, que es un nmero de 8 bits y se lo utiliza como perodo de PWM, mientras que el tiempo de alto es la cuenta de la energa consumida por la carga dividido por 32. Este valor se reajusta al medioda.
VI.
CONCLUSIONES
V.
PROGRAMA DE CONTROL
El microcontrolador PIC16F877 se programa en lenguaje de maquina, se utiliz la interrupcin 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 interrupcin, esta subrutina incrementa un conjunto de contadores en cascada: fraccin de milisegundos, milisegundos, minutos, 15 minutos, horas y das. As, cuando el contador segundos llega a 60 se borra y aumenta minutos, cuando minutos se pone a uno se realiza la medicin de los distintos parmetros, corriente de panel, corriente de carga, tensin de batera, temperatura y la integracin de las corrientes. En la hora 0 se realiza el clculo de la relacin de modulacin de pulso y duracin del da 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 da siguiente, durante este tiempo la relacin de
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. Tambin se desarrollo una versin 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 lgica 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 mxima de 20 A, o sea 6 paneles. Las resistencias de shunt son la mayor causa de disipacin de energa 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 situacin en que el mximo de energa disponible en el fotovoltaico no sea al medioda. Esta situacin se puede dar en una regin donde las lluvias ocurren al medioda. REFERENCIAS
[1] [2] Duffie J. A. y Beckman W. A. (1991). Solar Engineering of Thermal Processes, 2 edicin, pp. 54-59. Wiley Interscience, Farfan Federico Hoyos Daniel (2008), Sistema de simulacin y evaluacin de logicas de control basados en algoritmos borrosos para sistemas fotovoltaicos Avances en Energas Renovables y Medio Ambiente Vol. 12, 2008. Impreso en la Argentina. ISSN 0329-5184 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 283292, October 1993.
[3]
162
Sistema de Emergencia Remoto Basado en GSM

Daniel A. Mancuso, Juan L. Castagnola
Facultad de Ingeniera Universidad Catlica de Crdoba Crdoba, Argentina damancuso@gmail.com
Resumen En este trabajo se reporta el desarrollo de un sistema de emergencia de propsitos mltiples, porttil, basado en la tecnologa GSM, capaz de enviar mensajes SMS y realizar llamadas de voz disparadas por eventos de alarma provenientes de distintas fuentes. El ncleo 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 mdulo GSM y la interfaz de usuario compuesta por un display LCD alfanumrico, un teclado de membrana, una interfaz de audio y dems perifricos necesarios. Palabras clave - Sistema de Emergencia; Seguridad domstica; Sistemas Embebidos; GSM; SMS; Microcontroladores; RTOS;
realizar varias tareas en simultneo compartiendo un mismo flujo de programa principal. Es decir, las tareas se deben realizar en forma secuencial sin perder el control de la temporizacin de cada operacin, lo cual resulta cada vez mas dificultoso, y en consecuencia, mas propenso a fallas difciles de detectar [5]. Un mejor enfoque en estos casos, es la utilizacin de sistemas operativos de tiempo real (RTOS, Real Time Operating System). Estos aportan un cambio de paradigma entre la programacin lineal o secuencial, y la programacin multi-tarea o multi-hilo, donde varias tareas se realizan aparentemente en simultneo 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 instruccin por ciclo, pero el ncleo del sistema operativo (kernel) es el encargado de ceder el control de la ejecucin 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 caractersticas similares es la utilizacin de un RTOS para el diseo del sistema de emergencia, lo cual implica tanto una simplificacin en la implementacin del firmware, como un aumento en la confiabilidad del mismo. II. DESCRIPCIN DEL SISTEMA
I.
INTRODUCCIN
En la actualidad, un gran porcentaje de la poblacin se preocupa por la seguridad domstica. Con el amplio desarrollo de las tecnologas de comunicaciones, se ve simplificado el diseo de un sistema de monitoreo y alarma remoto. Tanto para responder a posibles robos o intrusiones a la propiedad, accidentes o situaciones de peligro hogareas como puede ser una perdida de gas, como tambin la integridad fsica 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 envo de una alerta acerca de la ocurrencia de una situacin de este tipo. La red de comunicaciones Groupe Special Mobile (GSM), es actualmente una tecnologa madura. Provee una amplia cobertura en las ciudades y zonas rurales, comunicacin a largas distancias [3], un fcil acceso al usuario (ya que se puede utilizar con un simple chip mediante un sistema prepago). A travs 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 pequeos estn basados en microcontroladores, y el mayor desafo en el diseo de estos sistemas es el desarrollo del firmware [4]. El enfoque tradicional en la programacin 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 mdulos de aplicacin para realizar las operaciones deseadas. Adems, se utilizan rutinas de interrupcin (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 depuracin del firmware, ya que se deben
En la figura 1 puede observarse un esquema del sistema propuesto. Este est compuesto por una estacin 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 compaa a utilizar debe seleccionarse segn 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 micrfono. La alimentacin se realiza mediante un adaptador AC/DC y una batera de Li-Ion de respaldo. La misma tiene una doble funcin: tanto como energa de respaldo para cortes del suministro elctrico, como para un posible uso porttil del aparato. Por ejemplo, un paciente con discapacidad motriz podra utilizarlo para solicitar asistencia remota desde una silla de ruedas. El sistema tambin 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 deteccin de prdidas, sensores de
163
movimiento, detectores de apertura de puertas y ventanas para detectar posibles intrusos.
Harvard modificada, posee una memoria Flash de 64 kbyte, una RAM de 8 kbyte, y una interfaz propietaria para la programacin y depuracin 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 comparacin con uC de otros fabricantes. Por otro lado, las herramientas de desarrollo son fcilmente accesibles. B. Modulo GSM Se seleccion el mdulo GSM/GPRS SIM340C, de la firma SIMCOM. La figura 2 muestra un diagrama interno del mdulo. El mismo provee toda la interfaz de RF para la conexin a la red GSM, comunicacin mediante un puerto UART para el control del mismo, interfaz para la conexin con una tarjeta SIM, 2 canales de audio y un convertidor A/D interno para el control del nivel de batera. El control del mdulo se puede realizar mediante comandos AT standard, y comandos adicionales propios del fabricante. Tambin provee el protocolo TCP/IP que puede ser utilizado para la transferencia de datos desde y hacia Internet mediante comandos AT extendidos [7].
Figure 1. Diagrama de bloques del sistema de emergencia.
Otras fuentes de disparo pueden ser dispositivos de control de variables biomdicas como electrocardigrafos o sensores de saturacin de oxgeno. Los cuales eventualmente pueden proveer salidas de alarma al detectar que los parmetros 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 nmeros de telfono a los que se debe enviar la alarma, etc. Tambin se utiliza el display LCD para indicar el estado de la conexin a la red, el nivel de la seal GSM, el nivel de la batera o el disparo de una alarma. III. DISEO DE LA PLATAFORMA
Figure 2. Diagrama interno del mdulo GSM.
A. Microcontrolador La seleccin del microcontrolador a utilizar se basa en tres criterios: Los perifricos necesarios: una interfaz UART para la comunicacin con el mdulo GSM y la cantidad mnima de puertos digitales que proporcionen las conexiones con los distintos elementos del sistema. Que el RTOS a utilizar provea la implementacin para el microcontrolador a seleccionar (porting). Esto implica un tamao mnimo de memorias RAM y FLASH, ademas de STACK dinmica en lugar de ser de tamao fijo. El fcil acceso a las herramientas de desarrollo (IDE, programador y debugger).
C. Circuito grabador - reproductor de voz Para el almacenamiento de mensajes de voz (y su posterior reproduccin durante una llamada de emergencia), se utiliza un circuito de grabacin de voz. El IC seleccionado es el APR9600 de la compaa Aplus Integrated Circuits Inc. Posee una memoria Flash capaz de almacenar hasta 60 segundos de audio a una calidad aceptable para la grabacin de voz. La memoria puede subdividirse hasta en 8 segmentos, dando la posibilidad de grabar varios mensajes de menor duracin. Para la interconexin de este IC con el parlante, el micrfono y la interfaz de audio del modulo GSM, se utiliza el circuito CD4053, que posee 3 llaves analgicas de dos vas, las cuales son controladas por el uC. Un circuito amplificador de audio (LM386), amplifica la seal 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 utilizacin en modo manos libres.
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
164
Figure 3. Diagrama en bloques de la interfaz de audio
D.
Interfaz de usuario Como fue indicado anteriormente, la interaccin 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 mens e ingresar datos como el nmero de telfono al que se debe realizar la llamada de emergencia. Se dispone un mdulo LCD alfanumrico de 4x20 caracteres para la visualizacin de los mens y estados del sistema. IV. DESARROLLO DEL FIRMWARE
Figure 4. Flujo de ejecucin de un RTOS preemptivo
Como se coment anteriormente, el mayor desafo en el diseo 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 utilizacin 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 decir, que ejecuta siempre la tarea de mayor prioridad), y determinista, de manera que siempre se puede conocer el tiempo de ejecucin de una tarea. Se puede escalar segn las necesidades de la aplicacin y es portable hacia una amplia gama de microprocesadores y microcontroladores presentes en el mercado (mas de 100 modelos de distintos fabricantes). La seleccin de este RTOS se bas en la gran aceptacin que tiene el mismo en la industria y en mbitos acadmicos, y que los autores tienen experiencia previa en el uso del mismo. El proceso de desarrollo del firmware debe comenzar por la divisin de la aplicacin en distintas tareas que deben ejecutarse 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 ejecucin. La figura 4 muestra el flujo de ejecucin de un sistema preemptivo. Al comienzo se observa una tarea de baja prioridad en estado de ejecucin (1). Luego, un evento asncrono interrumpe el microcontrolador (2) para ser atendido por el servicio de interrupcin (3). Al completarse la rutina de ISR, se invoca al kernel, el cual se encarga de ejecutar la tarea de mayor prioridad (4). Esta tarea finaliza su ejecucin al no ser interrumpida por una ISR (5), con lo que el kernel devuelve la ejecucin a la tarea de menor prioridad (6). De esta manera, el kernel asegura que las tareas con temporizaciones criticas sean ejecutadas primero.
En uC/OS-II, las tareas pueden crearse y eliminarse de manera dinmica (con el fin de liberar recursos). Cada tarea debe tener su propio stack, con un tamao suficiente para almacenar los datos de la tarea en el peor caso de ejecucin, mas espacio extra para salvar los registros de estado del uC. Como es difcil 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 ejecucin. Una vez obtenido este parmetro, se puede reservar el tamao ptimo para cada tarea. Para la comunicacin entre tareas, uC/OS-II provee 3 servicios: Semaphores, que pueden utilizarse como banderas o como llaves para reservar o bloquear algn recurso. Mailboxes, para enviar mensajes entre tareas. Y Queues, las cuales son colas FIFO que pueden utilizarse para el envo de varios mensajes o manejarse como buffers [6]. B. Divisin de las tareas A partir de los bloques descriptos en la seccin II, los procesos se dividen en 4 tareas, las cuales son: TaskLCD: encargada de visualizar la informacin correspondiente al estado del sistema en el display, refrescando peridicamente la pantalla. TaskTeclado: se encarga de responder a las teclas pulsadas, ejecutando acciones de acuerdo al estado de la aplicacin (navegacin por los distintos mens, configuraciones, estado de alarma, etc.). TaskAlarma: verifica el estado de las entradas correspondientes a las fuentes de alarma y activa el envo de la alerta en caso de detectarse una situacin de emergencia. TaskGSM: es la encargada del control del modulo GSM; envo y recepcin 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 organizacin del firmware.
165
La escritura en el display se realiza a travs del mdulo LCD que fue modificado para funcionar con 4 bits de datos. Para la comunicacin serial, se desarroll un mdulo UART. El mismo utiliza queues para el envo y recepcin de caracteres hacia el modulo GSM. Para el envo de los comandos AT y la interpretacin de las respuestas se escribi el mdulo GSM, el cual provee servicios tales como escribir un SMS, iniciar una llamada de voz, consultar el estado de la batera, etc. Este mdulo se comunica con la aplicacin por medio de semaphores y queues.
D. Funciones implementadas Como se intenta maximizar la flexibilidad de utilizacin del sistema, se implementan varias funciones, a las cuales se accede desde la interfaz de usuario:
Figure 5. Organizacin del firmware
Configuracin manual del nmero de telfono de emergencia (ingresndolo por teclado). Almacenamiento automtico del nmero (con una llamada entrante desde el telfono celular). Grabacin o reproduccin del mensaje de alerta. Configuracin del SMS que se debe enviar ante las distintas situaciones de emergencia. Prueba de las distintas alarmas sin realizar ninguna llamada. Consulta del crdito 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 conexin a la red (activo/inactivo), el nivel de batera y el nivel de seal que recibe el modulo GSM, como puede observarse en la figura 6.
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. Variable: Alarma Aviso Bateria Seal Call_ready Iniciando_GSM Sim_not_present Mens_nuevo Llam_en_progreso Llam_entrante Num_config Menu Timeout ELEMENTOS DE
LA ESTRUCTURA
STATUS
Descripcin: Estado de la alarma (ON/OFF) Estado del aviso Porcentaje de carga de la batera Nivel de seal de recepcin de la red GSM Listo para realizar llamadas y enviar SMS Inicializando mdulo y conectando a la red No se detect tarjeta SIM Nuevo SMS entrante detectado Realizando una llamada Se detect una llamada para almacenar el nmero Nmero configurado para las llamadas Estado del men Tiempo restante para la grabacin/reproduccin del mensaje de voz
Figure 6. Visualizacin del estado de espera.
C. Mdulos 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 mdulos [8] para realizar la interfaz con los distintos perifricos: Para el escaneo del teclado se utiliza el mdulo KEY provisto por uC/OS-II, el cual ejecuta una tarea de forma peridica almacenando en un buffer el historial de las teclas pulsadas.
Para la etapa de desarrollo del sistema, se diseo una PCB (la cual se puede observar en la figura 7). La misma est compuesta del uC, la interfaz de programacin, y un convertidor UART-USB para la visualizacin de la comunicacin del uC con el modulo GSM en un terminal de PC. A esta placa se fueron adicionando los distintos mdulos (GSM, tarjeta SIM, teclado, LCD, interfaz de audio, alimentacin y entradas).
166
variedad de situaciones de riesgo hogareo as como para personas con algn grado de discapacidad fsica ya que es fcilmente 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 colaboracin del Ing. Agustn Laprovita, el Ing. Walter Lancioni, el Sr. Matias Daz, el Ing. Carlos Centeno y a las Ctedras de Sistemas Embebidos y Proyecto y Diseo de la Facultad de Ingeniera - Universidad Catlica de Crdoba, por los mltiples aportes que realizaron en el desarrollo de este trabajo.
Figure 7. Primer prototipo del sistema de emergencia
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.
V.
CONCLUSIN
Este trabajo describe el diseo de un sistema de emergencia que utiliza la red GSM como medio de comunicacin. Su innovacin radica en el uso de un RTOS para la programacin del firmware. Durante el desarrollo del firmware ha resultado evidente la gran diferencia entre programar este sistema basndose en RTOS y realizarlo de la forma tradicional (foreground/background). Se simplifica mucho el control de las temporizacines (gracias a los servicios que provee el kernel y la propiedad determinista del mismo). Tambin se logra una fcil abstraccin entre los distintos mdulos y tareas, simplificando en gran forma la adicin de nuevos elementos al sistema. De esta manera, se puede inferir que la dificultad de la programacin de este tipo de sistemas embebidos avanza de una forma mas lineal con la complejidad del sistema que realizando la programacin de la forma tradicional. Luego de finalizado el desarrollo y depuracin del firmware, se realizaron varias pruebas respecto a la fiabilidad del sistema, tanto alimentado desde la red elctrica como desde la batera de soporte. Se lograron excelentes resultados respecto a la conexin del modulo a la red GSM, incluso en ubicaciones de baja seal y con pocos cuidados en la adaptacin de la antena conectada al mdulo, con lo que el mdulo seleccionado cumpli las expectativas. Por otro lado, la calidad del audio obtenido es satisfactoria en el modo manos libres. La configuracin y utilizacin del dispositivo ha resultado bastante simple para personas ajenas el desarrollo, ya que la navegacin por el men y las distintas configuraciones resultan bastante intuitivas y explcitas. Debido a los resultados obtenidos, se puede inferir que el sistema desarrollado puede ser de gran ayuda en una amplia
167
Ventricular Fibrillation Detection Algorithm Implemented in a Cell-Phone Platform

Micha Rospierski, Marcelo Segura, Martn Guzzo, Eduardo Zavalla , Cristian Sisterna and Eric Laciar Laboratorio de Electrnica Digital (LED) Universidad Nacional de San Juan (UNSJ) San Juan, Argentina michal.rospierski@gmail.com, msegura@unsj.edu.ar, m.guzzo@unsj.edu.ar, ezavalla@inaut.unsj.edu.ar, cristian@unsj.edu.ar, laciar@gateme.unsj.edu.ar
AbstractDue 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, cellphone, on-line processing.
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
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
The aim of this work is to implement in a cellphone 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].
168
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.
(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)
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
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).
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 bandpass filter second order with cut-off frequencies of 5 Hz and 70 Hz was implemented by using (1).
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
169
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 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
Figure 4 - Representation of the signal segmentation process
170
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.
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 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.
Start
Figure 8 VF detection application flow in the cell-phone
V.
Class Object Number of Windows Parameters Transfer
VIRTUAL MACHINE SIMULATION RESULTS
Buffer with samples K=0 K= K+1 K<Number of Wndows Finding Pulses and CF Calculation Recognition and Decision Display Results Increase Buffer Index
No
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
Stop
Variable
Cardiac frequency threshold QRS signal level threshold Threshold of high cardiac frequencies in window Threshold of windows with high cardiac frequencies for sms Telephone number
Value
250 0.55 3 3 5550001
Si
K=0
Copy to Window Buffer

No
Copy of 750 Samples
Copy of 350 Samples
Copy from Window Buffer
K>0
Filtering
Figure 7 - Flow diagram of the Java VF detection algorithm
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
171
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.
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 1 2 3 4 5 6 7 8 9 10
Time for Window [ms] 183 77 77 77 79 81 SMS 86 77 83
Figure 9 - msg.txt template with the data to be sent by SMS
Fig. 10 is a screen capture of the two Sony Ericsson cellphones 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, doctors cell-phone for instance, that displays the received SMS due to the detection of a VF in the patients 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
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
Having succeeded in the previous simulation, the next step was to implement the VF detection algorithm in a real cellphone. The main challenge in this step is the time invested to process the VF detection algorithm. Therefore, careful tests
In this work, it has been implemented and evaluated an algorithm to detect a Ventricular Fibrillation (VF) in a cellphone. 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
Figure 10 - Virtual machine simulation
172
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] [2] A. J. Bays de Luna. Arritmias, concepto, mecanismos y clasificacin, in Electrocardiografa Clnica. Ediciones Espaxs, Barcelona, 1999. 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. J. Pan, W.J. T ompkins. A real -time QRS detection algorithm, IEEE Trans. Biomed. Eng., 32: 230-236. MIT-BIH Malignant Arrhythmia Database, freely available in http://www.physionet.rg/physiobank/database/vfdb/ Sing Li and Jonathan Knudsen, Beginning J2ME: From Novice to Professional. Third Edition, APRESS, Srpinger-Verlag New York, 2005. B. Eckel, Thinking in JAVA. Third Edition. Prentice Hall, 2002 Sony Ericsson Developers Platform: http://developer.sonyericsson.com
[3] [4] [5] [6] [7]
173
174
POSTERS
175
176
Arquitecturas de Microcontroladores
177
178
Comparacin del desempeo de microcontroladores AVR de 4ta generacin

David M. Caruso; Salvador E. Tropea Instituto Nacional de Tecnologa Industrial - Electrnica e Informtica Avenida General Paz 5445 entre Albarellos y Constituyentes, Edicio 42, CC157 (CP 1650) San Martn, Bs. As., Argentina {david,salvador}@inti.gob.ar
Nuestro equipo de trabajo desarroll un microcontrolador ciclo a ciclo compatible con los microcontroladores AVR de 4 generacin. El mismo fue ampliamente validado con varias aplicaciones usando FPGAs. A los nes de comparar su desempeo con el de otros microcontroladores se decidi correr un benchmark en el mismo. Para esto se utiliz el benchmark Dhrystone versin 2.1. A pesar de que existen otros benchmarks ms representativos este es el ms utilizado por los fabricantes, an hoy en da. La originalidad de este trabajo, radica en el hecho de que no puede implementarse el Dhrystone en microcontroladores AVR de 4 generacin, dado que no poseen la suciente memoria RAM. Si bien es probable que dicho benchmark pueda ejecutarse en AVRs de 5 generacin (ej. ATXMega256), los resultados seran menos representativos. Por otro lado no se pudieron encontrar resultados publicados del Dhrystone para ningn AVR (no confundir con AVR32). Debido a que los bloques de memoria son un recurso escaso en FPGAs de bajo costo, slo algunos cientos de kilobits, es deseable utilizar memorias externas para el programa a ejecutar. El uso de memorias ash externas, trae aparejada una latencia dada por el cambio de pgina de la memoria, que limita la frecuencia de operacin mxima. Para aliviar esta situacin se agreg un core intermedio entre el AVR y la memoria, que le permite leer, a la mxima velocidad por pgina, optimizando los tiempos de cambios de pgina. El conjunto del core con la memoria, se puede entender, en una forma muy simplicada, como un sistema de "memoria cach". Se obtuvieron distintos resultados de desempeo, para el microcontrolador con memoria interna, externa y con el sistema de memoria cach. Dichos resultados indican que el AVR tiene un desempeo que es comparable o superior a una CPU 80286 (PC AT 286).
179
"Anemmetro Ultrasnico 3D empleando Arquitecturas Analgica-Digital Reconfigurables"

Montoya Walter*; Rogel Fernando*; De Marziani C. *#; Alcoleas, R. *; Colombo, A*.
*Dto. de Electrnica, Facultad de Ingeniera, Univ. Nacional de la Patagonia San Juan Bosco #CONICET, Consejo Nacional de Investigaciones Cientficas y Tcnicas.
Diversas actividades del hombre estn vinculadas con la meteorologa: transporte areo y terrestre, medicina, energa elica, agricultura, turismo, pronsticos de alertas, etc. La meteorologa implica la medicin de parmetros fsicos bsicos tales como: presin atmosfrica, temperatura, humedad, direccin y velocidad del viento, visibilidad y precipitaciones. Para determinar la velocidad y direccin del viento habitualmente se emplean sistemas mecnicos que necesitan un mantenimiento continuo y son muy sensibles a daos, particularmente en la zona Patagnica donde los vientos son caractersticos por su agresividad. En los ltimos aos han surgido anemmetros que emplean sensores ultrasnicos que, al no tener partes mviles, requieren de un mantenimiento menor. El principio de funcionamiento consiste en determinar el tiempo de propagacin de la seal ultrasnica 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 anemmetros es su elevado costo comercial. En este trabajo se presenta el desarrollo de un anemmetro ultrasnico 3D de bajo costo a partir del empleo de arquitecturas analgico-digitales reconfigurables PSoC de Cypress. As, es posible realizar el acondicionamiento y procesamiento de seales con un mismo circuito integrado sin necesidad de incrementar excesivamente el hardware a implementar reduciendo los tiempos de diseo. 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 precisin en la medicin de la velocidad y direccin del viento.
180
ASICs
181
182
Detector Activo de Corrientes de Fuga

Matias Bulacio; Toms Gonzlez; Ramiro Alonso; Guido Marinelli; Dr. Hernn Tacca; Dr. Ariel Lutenberg; Dr. Jos Lipovetsky LABCATyP Departamento de Electrnica Facultad de Ingeniera Universidad de Buenos Aires
En instalaciones elctricas industriales y hogareas se utilizan dispositivos que detectan corrientes de fuga a tierra, llamados disyuntores. Estos equipos cortan la alimentacin de la red en caso de producirse una falla protegiendo equipos y vidas humanas. Su funcionamiento se basa en la medicin de un desbalance de corriente entre las lneas de alimentacin de los equipos por lo que el sistema a proteger tiene que estar en funcionamiento para poder detectar la fuga. Estos dispositivos son lentos, no son capaces de detectar fugas pulsantes y debido a su tiempo de respuesta son inecaces para proteger dispositivos electrnicos, como por ejemplo los transistores de potencia en variadores de velocidad de motores. Dadas las deciencias de los disyuntores, se desarroll un dispositivo capaz de detectar corrientes de fuga antes y durante la puesta en marcha de los equipos e instalaciones elctricas, con un tiempo de respuesta que permite resguardar los dispositivos electrnicos. La solucin desarrollada consiste de dos partes, un circuito que inyecta una seal pulsante de alta frecuencia en la lnea de alimentacin de un equipo y un circuito detector de la misma en caso de fuga. Ambos circuitos, inyector y detector, se integran en un nico chip de silicio con la tecnologa XC06 de XFAB (se enviar a fabricar a mediados de diciembre). La inyeccin y sensado en la lnea de potencia se realiza mediante aislacin galvnica externa al circuito integrado (transformadores de pulsos). Esto provee seguridad y cubre las necesidades del producto propuestas anteriormente. Este dispositivo posee umbrales de sensibilidad ajustables para permitir su portabilidad a distintas aplicaciones.
183
Fabricacin de un circuito integrado digital conversor Serie-Paralelo y Paralelo-Serie en un proceso CMOS de 0.5 m Barbeito, P.; Carr M.; Garca Inza M. Seminario de diseo y fabricacin de circuitos integrados en tecnologa CMOS. Departamento de electrnica, Facultad de ingeniera, Universidad de Buenos Aires
Con el avance de la tecnologa y de la capacidad de procesamiento la cantidad de bits por palabra contina creciendo. Hoy es comn 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 informacin en forma serial a travs 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 diseo, fabricacin y posterior validacin de las mediciones realizadas en los circuitos fabricados de dos mdulos de conversin, 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 travs 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 librera que est disponible para futuros proyectos del seminario y laboratorios de investigacin de la facultad de ingeniera de la universidad de Buenos Aires.
184
185
186
Control Automtico de Ganancia sobre un CPLD

Guillermo M. Gancio. Instituto Argentino de Radioastronoma I.A.R. CONICET. ggancio@iar-conicet.gov.ar
El I.A.R. cuenta con dos antenas parablicas de 30mts de dimetro para uso radioastronomico. Una de ellas utiliza un receptor criognico refrigerado a 15o K (-258o C) operando en una frecuencia central de 1420Mhz(HI). Estas pequeas seales de radio, deben ser acondicionadas a niveles de potencia predeterminados por la conguracin utilizada por el receptor, es por ello necesario que uno de los mdulos sea responsable del control automtico de ganancia del sistema. Este mdulo debe controlar una serie de atenuadores digitales, tener la capacidad de recibir una seal de referencia externa que utilizar para el ajuste de nivel y adems, la capacidad de poder operarse de forma manual o remota mediante una PC. Al evaluar las opciones se decidi realizar este control utilizando un CPLD implementando la solucin en lenguaje VHDL. El hardware se dividi en 3 secciones principales: a)Etapa de atenuacin; b)Etapa analgica; c)Etapa digital. Parte fundamental de la etapa digital es el cdigo VHDL, el mismo se dividi en funciones reducidas para realizar los testbenchs de forma ms eciente; estas tareas se dividen en: a)Interfase usuario; b)Control externo; c)Control atenuadores digitales. Cada mdulo en VHDL fue simulado utilizando las herramientas de desarrollo de la rma Xilinx. Luego de vericar las simulaciones se procedi con la implementacin de un mdulo completo logrando mediciones que permitieron validar comparativamente el funcionamiento esperado del mdulo. Tambin se presentan las medidas realizadas con el control automtico de ganancia integrado a la cadena del radiotelescopio.
187
Aplicaciones de FPGA de tecnologa flash al control de motores elctricos de corriente alterna

Bulacio Matas F.; Arias Ricardo; Tacca Hernn E. LABCATyP Departamento de Electrnica Facultad de Ingeniera de la Universidad de Buenos Aires
En la industria, los motores asincrnicos trifsicos son alimentados y controlados por variadores de velocidad. Estos ltimos reciben informacin de control y diagnstico, tales como puesta en marcha, parada, cambio de set-point desde la estacin de supervisin o, tales como el estado de falla, velocidad angular, temperatura desde el motor. sta realimentacin de informacin 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 difcil acceso al lugar donde debe ser instalado. Es por esto ltimo que este trabajo se enfoca en la utilizacin de la lnea de potencia como canal de comunicacin (PLC, Power Line Communication), evitando el cableado adicional para la supervisin y comando. Con el fin de lograr el objetivo de aprovechar los cables de la lnea de potencia para la supervisin y comando de los motores de induccin se realizar mediante la FPGA un sistema de insercin y deteccin de seales en la lnea trifsica. Adems se deben aprovechar los transformadores y sensores incluidos, para implementar las funciones de proteccin habituales en variadores de velocidad (sobrecarga, deteccin de cortocircuitos, fallas de aislacin, circulacin de corrientes parsitas a tierra, etc.). En este punto el uso de la FPGA permitira actuar ms rpidamente ante la presencia de una falla, protegiendo no solo a la mquina elctrica sino tambin a los dispositivos de potencia (IGBTs).
188
Montaje de Experimentacin para ptica Adaptativa Astronmica con FPGA

Rodrguez Brizuela F.1; Verasay J.P.1; Recabarren P.1,2 (1) Facultad de Ciencias Exactas, Fsicas y Naturales, UNCba (2)Instituto de Astronoma Terica y Experimental (CONICET),Crdoba ferrbrizuela@hotmail.com, cata_jpv@hotmail.com
Las variaciones de densidad de los gases de la atmsfera 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 limitacin a la calidad de las imgenes 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, actan modificando la geometra de la ptica del telescopio, compensando as las deformaciones que la atmsfera produce en las imgenes, a una frecuencia del orden del KHz. En este trabajo se presenta un montaje experimental destinado al ensayo de software para pticas Adaptivas astronmicas, basadas en tecnologa FPGA, que consiste en el sensado por imagen, del error de posicin de un haz lser proyectado sobre una pantalla, realimentado al sistema de control basado en una FPGA Xilinx Spartan 3E, el cual acta sobre un espejo mvil, corrigiendo la trayectoria del haz, mantenindolo en la misma posicin. La posicin del haz es obtenida a partir del digitalizado de la seal de video de una cmara CCTV. El montaje realizado permitir ensayar diferentes algoritmos de control, presentndose una versin inicial en VHDL, para pruebas de funcionamiento del conjunto.
189
Implementacin de MODBUS en FPGA mediante VHDL Capa de Enlace

Olmedo Sergio 1, Guanuco Luis 1, Panozzo Znere Jonatn 1, Rubio Agustn 1
1-Centro Universitario de Desarrollo en Automacin y Robtica CUDAR Universidad Tecnolgica Nacional - FRC Crdoba, Argentina
La descripcin de hardware, mediante la programacin en VHDL, permite una amplia versatilidad en el diseo de circuitos digitales. Se presenta una descripcin sobre la realizacin de una comunicacin entre dispositivos lgicos programables, segn el protocolo MODBUS. Este estndar de comunicacin, de amplia aceptacin, define protocolos para las capas de Aplicacin, Enlace y Fsica. En esta presentacin se aborda el desarrollo del mismo la Capa de Enlace, y de manera resumida la forma en que esta interacta con las otras capas El desarrollo de un protocolo estndar de comunicacin se basa en una jerarqua con diferentes niveles de abstraccin para el tratado de la informacin, lo que implica variadas formas de implementacin tanto hardware como software. El modelo OSI es un marco de referencia para la definicin de arquitecturas de interconexin de sistemas de comunicaciones. El protocolo MODBUS define la comunicacin serie entre un nico dispositivo Maestro y entre uno a 247 Esclavos. En el caso de haber un nico Esclavo, la comunicacin se denomina punto a punto y si existe ms de un Esclavo, la comunicacin es multipunto. La generacin de una trama MODBUS comienza con el envo de un caracter que define el principio de la misma. En forma consecutiva se transmiten los campos de direccin, funcin, 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 utilizacin en una capa superior o inferior como lo define el modelo OSI. La implementacin se realiza en una FPGA Xilinx Spartan 2E XC2S200E, donde el banco de pruebas se adapt una lnea serie mediante RS232 conectando entre s dos FPGA. Uno de ellos implementados como Maestro y el otro como Esclavo. La implementacin de MODBUS en sistemas embebidos, presenta una preferencia en la utilizacin de microcontroladores para llevar adelante su desarrollo. Sin embargo, la descripcin de hardware permite la flexibilidad en el diseo de sistemas de comunicacin digital, dado que el mismo se realiza independientemente del dispositivo a utilizar, por lo que se logra portabilidad en la implementacin sobre PLDs. La concurrencia otorga un mejor aprovechamiento del tiempo, que se traduce en mayor velocidad de operacin, en desmedro de una utilizacin de recursos tambin mayor.
190
Implementacin en FPGA de Ruido Gaussiano para simulaciones en Hardware

L. De Micco; H. A. Larrondo Departamentos de Fsica y de Ingeniera Electrnica, Facultad de Ingeniera, 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 evaluacin de todo sistema de comunicaciones ya que constituye una buena aproximacin a muchos canales reales. Los generadores de ruido gaussiano constituyen entonces un equipamiento bsico para la medicin de los actuales sistemas digitales. La mayora de los mtodos de generacin propuestos parten de una serie temporal con histograma constante (PDF uniforme). Aplicando luego el algoritmo de Box-Muller se obtiene la serie temporal con PDF gaussiana. Un inconveniente para la implementacin en hardware del algoritmo de BoxMuller es que requiere la implementacin de las funciones sinusoidal y logartmica. En este trabajo se propone una metodologa que permite la implementacin en FPGA de un generador de ruido con una PDF deseada, a partir de un mapa catico sintetizado. La PDF es aproximada por tramos. Dada la importancia de los generadores de ruido gaussiano apuntada arriba, en este trabajo se aplica la metodologa propuesta para la obtencin de una primera aproximacin a la PDF Gaussiana. La implementacin en hardware se realiz utilizado una FPGA Cyclone III EP3C120F780C7 de ALT ERA c , el diseo ocupa slo 6 % de los elementos lgicos del dispositivo y utiliza 26 % de memoria RAM. Para la representacin numrica se emplea arquitectura de punto otante IEEE754 no slo para conseguir una mejor precisin sino tambin para facilitar la utilizacin en sistemas digitales que utilizan esta representacin.
191
192
Implementacin de Sistemas Embebidos
193
194
Sistema para medicin optoelectrnica del secado de pinturas

Ezequiel Rubinsztain1; Ariel Lutenberg1; Fernando Perez Quintin2, 3 1 GLOmAe, Departamento de Fsica, Facultad de Ingeniera, Universidad de Buenos Aires (Argentina) 2 Departamento de Fsica, Facultad de Ingeniera, Universidad del Comahue (Argentina) 3 CONICET (Argentina)
En este trabajo se presenta un sistema opto-electrnico para la medicin del secado de pinturas. El diseo propuesto est compuesto por un diodo lser, un sensor de luz CCD lineal y un microcontrolador dsPIC30F4011, que realiza el control y el procesamiento de datos. La evolucin temporal del patrn de speckle producido por la dispersin del haz lser en la pintura se captura mediante a una cmara CCD lineal, se procesa y se transmite va RS232 a la PC. Mediante la aplicacin de algoritmos de procesamiento de seales se puede extraer informacin de las imgenes vinculadas al estado de secado y as analizar las caractersticas de la pintura o proveer informacin 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, ltex, lquido corrector, etc. y se desarrollaron nuevos algoritmos para procesamiento en tiempo real de la informacin.
195
Kit Educativo Basado en Microprocesador de 32 Bits

Salituri Juan I.; Jurez Jos M. Facultad de Ingeniera de la UNLP Facultad de Ingeniera de la UNLP Facultad de Ingeniera de la UNQ jjuarez@ing.unlp.edu.ar
El presente proyecto forma parte de un trabajo final de carrera y tiene como objetivo principal disear e implementar una placa de desarrollo basada en un microcontrolador de 32 bits orientada al ambiente educativo. La motivacin del mismo surge de la necesidad de disponer de una plataforma flexible para exponer de forma prctica algunos de los conceptos tericos desarrollados durante la formacin acadmica de los alumnos, en particular aquellos que incluyen los sistemas embebidos. Tras una bsqueda 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 diseo se concentr en tratar de lograr una disposicin de perifricos 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 daos del mismo ocasionados por errores de los alumnos durante la etapa de aprendizaje. La etapa de implementacin incluy tanto el desarrollo del PCB en cuatro capas, como el montaje de los componentes, en su mayora SMD, y el desarrollo de firmware para testeo de la plataforma. La potencialidad del microprocesador seleccionado y la amplia gama de perifricos que este dispone permitirn al usuario implementar una cantidad importante de aplicaciones e incursionar en los sistemas operativos de tiempo real.
196
Sistema de adquisicin de datos para estudios interferomtricos

Antn L.1, Tern G.1, Lutenberg A.1, Perez Quintin F.23 1 GLOmAe, Facultad de Ingeniera, Universidad de Buenos Aires 2 Departamento de Fsica, Facultad de Ingeniera, Universidad del Comahue 3 CONICET
Un interfermetro heterodino es un sistema ptico que permite la caracterizacin de materiales mediante ensayos no destructivos. Esta tcnica se utiliza, por ejemplo, en las industrias petrolera y de la construccin, para medir porosidad de rocas, vibraciones en estructuras, caractersticas de hormigones, entre otras aplicaciones. La salida del interfermetro es una seal modulada en fase. El objetivo de este proyecto es disear y construir un equipo capaz de demodular esta seal, digitalizarla y transmitir el resultado a una PC para su tratamiento. El sistema consta de una etapa de adaptacin de entrada, una de demodulacin de PM, una de digitalizacin y almacenamiento y una etapa de salida de datos. La demodulacin se lleva a cabo mediante un PLL de frecuencia central de 70MHz y ancho de banda tal que permita demodular una seal de frecuencia mxima de 10MHz. La digitalizacin 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 duracin. Finalmente, los datos son transmitidos a un ordenador mediante un microcontrolador con interfaz USB. Este proyecto incluye, tambin, el desarrollo de un software para el control de las mediciones y recepcin de los datos producidos por las mismas.
El prototipo del proyecto se encuentra en etapa de prueba. Se presentarn resultados de las mediciones realizadas para la verificacin del funcionamiento del mismo.
197
ANOTADOR BRAILLE ELECTRNICO PARLANTE

Cayuela P.; Monardez G. Centro Universitario de Desarrollo en Automacin y Robtica (CUDAR) Universidad Tecnolgica Nacional, Facultad Regional Crdoba Crdoba, Argentina cayuela@ieee.org
Se plante la realizacin de un prototipo de anotador braille electrnico, de bajo costo de produccin, que en caso de no ser gratuito para ciegos, por falta de financiacin de organizaciones gubernamentales o similares, sea accesible su compra, dado que en el mercado internacional su adquisicin 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 electrnico braille porttil. 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 sntesis de voz. Esto se logr con creces, dado que empleamos tecnologa electrnica de fcil acceso y bajo precio para Argentina, permitiendo la construccin de un anotador completo por un costo de alrededor del 10% del valor de un aparato de importacin. Este aparato fue sometido a pruebas de rigor en instituciones educativas para ciegos. El resultado mostr que los usuarios requieren de un retorno o mtodo de revisin directo de los textos ingresados al equipo. Por ello se plante la incorporacin de tecnologa de sntesis de voz al anotador braille electrnico previamente desarrollado. El nuevo anotador servir de verdadera alternativa ante los aparatos importados y permitir a la persona ciega tomar notas a travs de un teclado con disposicin braille, almacenarlas y recuperarlas mediante sntesis 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 electrnico, con lo cual, el aparato ser tambin parlante.
198
Esquema de control de un microdisplay LCD

Burman A.1 , Garea M.T.1 , Lutenberg A.1 , Perez Quinti an F.23 Facultad de Ingenier a, Universidad de Buenos Aires 2 Departamento de F sica, Facultad de Ingenier a, Universidad del Comahue 3 CONICET
1 GLOmAe,
pticos que permiten modicar en tiempo Los moduladores espaciales de luz (SLMs) son sistemas o real, la amplitud y la fase de la luz que los atraviesa. Habitualmente, el elemento central de estos sistemas es un microdisplay. Los microdisplays son displays de cristal l quido donde el tama no de los p xeles es del orden de 10 a 40m. Generalmente, el alto costo de los SLMs, del orden de decenas de miles de d olares, resulta prohibitivo ptica. Frecuentemente se suelen armar SLMs precarios a partir del desguace para los laboratorios de o de proyectores de video. Esto presenta dos inconvenientes: por un lado, la dicultad de disponer de varios SLMs de caracter sticas similares. Por otro lado, la necesidad de utilizar una PC para generar las se nales que emplea el SLM, debido a que los circuitos de control de los proyectores est an dise nados para trabajar con se nales de video. En este trabajo se presenta el desarrollo de un prototipo de un SLM a partir de un microdisplay de venta comercial. El esquema propuesto consiste principalmente en una CPLD que genera las se nales de sincronismo del microdisplay, una memoria para almacenar distintas im agenes, un conversor DAC para cargar la imagen en el microdisplay y un microcontrolador que realiza el control general del sistema. De esta forma se logra utilizar el microdisplay sin la necesidad de trabajar con se nales de video. El prototipo resulta signicativamente m as econ omico que los SLMs comerciales y, por ende, ofrece ptica en el pa una alternativa en dispositivos para la investigaci on en o s.
199
200
Linux Embebido
201
202
Single Board Computer Basada en ARM9 y FPGA para Procesamiento de Imgenes Digitales
Diego Gonzalez Dondo; Leandro N. Alem; Guillermo Steiner Universidad Tecnolgica Nacional-Facultad Regional Crdoba 47727@electronica.frc.utn.edu.ar
El en el presente trabajo se muestra el desarrollo de una computadora simple o SBC (Por sus siglas en ingles), ya que se trata de una conguracin que posee los mismos elementos constituyentes bsicos de un computadora, como son: microprocesador, memoria (RAM y ROM), bus de datos, perifricos de entrada y salida, fuente de alimentacin, comunicacin va ethernet, etc. El microcontrolador utilizado es el EP9302 de arquitectura ARM9 de 32 bit. Al mismo se le conecta una FPGA de Xilinx Spartan XSA3SE500 directamente al bus de datos y un sensor de imgenes 0V7620 con su ptica correspondiente. Con esto se logra un sistema completo para el procesamiento de imgenes, condicin muy deseada para aplicaciones embebidas. La utilizacin de una FPGA en el desarrollo de las SBC implica la posibilidad de que los algoritmos de procesamiento de imgenes se pueden implementar en la misma, esto quiere decir que se pueden crear estructuras de hardware dedicado para llevar a cabo el proceso. Esto maniesta una gran ventaja con respecto a las implementaciones efectuadas en software de una PC de escritorio, debido a que lo que se programa en una FPGA es hardware, que es totalmente concurrente, traducindose en una alta velocidad de clculo. Al ser la SBC de arquitectura abierta permite una versatilidad en la utilizacin de la misma, como en la implementacin de los algoritmos, ya que, o bien se llevan a cabo por el potente microcontrolador ARM9, por la FPGA o una combinacin de ambos. El sistema esta conformada por 3 PCBs, los cuales fueron realizados en dos capas, con agujeros metalizados, mascara antisoldante y con encapsulados de montaje supercial. El montaje de los componentes se realiz en forma manual. Se implemento un mecanismo de testeo por pasos del funcionamiento de los componentes principales, como el microprocesador, memorias, etc, basado en un software de booteo del microcontrolador. El sistema cuenta actualmente con un kernel de Linux embebido y la distribucin GNU Debian para ARM, para aumentar la versatilidad del sistema y abstraerse del hardware a la hora de desarrollar y ejecutar aplicaciones.
203
Diseo de un reloj sidereo sobre una plataforma uClinux y FPGA

Guillermo M. Gancio. Instituto Argentino de Radioastronoma I.A.R. CONICET. ggancio@iar-conicet.gov.ar
Parte del instrumental que tiene el I.A.R. est dedicado al sistema de apuntamiento de una antena de 30mts de dimetro con la cual realiza observaciones radioastronomicas en la banda de 1420Mhz(HI). Uno de los mdulos est encargado de proveer una seal de referencia de tiempo y frecuencia que est sincronizada con el movimiento de los astros, este reloj se denomina de tiempo sidreo. Para obtener el tiempo sidreo 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 conexin ethernet, tambin es necesario poder controlar un hardware asociado que permita proveer una comunicacin serial con otros dispositivos. Al evaluar las posibles plataformas para el desarrollo de este mdulo y teniendo en cuenta que debe ser integrado junto a otros sistemas, se opt por una plataforma del tipo SBC (Single Borad Computer) la cual fue desarrollada en el I.A.R; a modo de evaluacin se utiliz un kit de la rma Digilentinc (Spartan 3E Starter Kit). Esta plataforma debe presentar cierta exibilidad con respecto al hardware asociado, por esto se decidi utilizar una FPGA SPARTAN3E-500 de la rma Xilinx en la cual se implement el softprocessor MicroBlaze de la misma rma. Se decidi utilizar un sistema operativo un uClinux como elemento de abstraccin entre el desarrollo de las aplicaciones y el hardware asociado. Mediante este mecanismo se busca estandarizar el desarrollo de aplicaciones de software independientemente de la evolucin de la plataforma de hardware.
204
205
206
Herramienta para depuracin de redes de sensores inalmbricos

Mazzara P., Steinfeld L., Silveira F., Villaverde J. Instituto de Ingeniera Elctrica, Fac. de Ingeniera, Universidad de la Repblica {mazzara, leo, silveira, jvillav}@fing.edu.uy
La implementacin de una red de sensores inalmbricos presenta grandes desafos. La depuracin de una aplicacin tiene la dificultad propia de depurar un sistema distribuido adems de un sistema embebido en tiempo real. En estas redes es fundamental minimizar el consumo de los nodos, siendo la comunicacin 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 energa en tiempo real es fundamental. La verificacin de una correcta transicin de estados de la radio, as como tambin medir el tiempo en cada uno permite detectar bugs de diseo o implementacin. Para encarar este problema se sigui una metodologa 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 mdulo de comunicacin 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 sealados por el nodo. Estos son guardados adecuadamente (hasta 1MB de datos en Flash) para luego ser recuperados y analizados. Esta metodologa se utiliz una red en operacin, 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.
207
Th e Wir eless E m bedded In t er n et

Mer ca do G., Agu ir r e M. y Diedr ich s A. {gu st a vo.m er ca do, m a t ia s.a gu ir r e, a n a .diedr ich s}@gr idt ics.fr m .u t n .edu .a r Gr u po U TN Gr idTICS F a cu lt a d Region a l Men doza Un iver sida d Tecn olgica Na cion a l
La visin det r s de la In t er n et de la s Cosa s es qu e los disposit ivos em bebidos, t a m bin lla m a dos sm a r t objet cs, est n ca da vez m a s u n iver sa lm en t e con ect a dos a In t er n et y qu e son u n a pa r t e in t egr a l de la m ism a . La In t er n et de la s cosa s, a veces den om in a da in t er n et em bebida or iller a , es u n ca m bio m a y scu lo y el m a yor desa fo a la In t er n et a ct u a l. La m ism a est h ech a con disposit ivos em bebidos con ecta dos a In t er n et , lo qu e in clu ye sen sor es, m a qu in a s, lect or es de RF ID y e qu ipa m ien t o de a u t om a t iza cin de edificios, solo pa r a n om br a r u n a s poca s a plica cion es. E l exa ct o t a m a o de la In t er n et de la s cosa s es difcil de est im a r per o se a su m e qu e pr on t o su t a m a o exceder en de la In t er n et a ct u a l. E l wir eles em bedded in t er n et es u n su bcon ju n t o de la In t er n et de la s cosa s y son a qu ellos disposit ivos em bebidos de r ecu r sos lim it a dos, a m en u do oper a dos por ba t er a s y con ecta dos a In t er n et a t r a vs de r edes in a l m br ica s de ba ja pot en cia y ba jo a n ch o de ba n da . 6LowP AN fu e desa r r olla do pa r a h a cer posible Wir eless E m bedded In t er n et sim plifica n do la s fu n cion a lida des de pr ot ocolo de in t er n et IP v6, defin ien do u n en ca beza m ien t o m u y com pa ct o y t om a n do en cu en t a la n a t u r a leza de la s r edes in a l m br ica s. E n el pr esen t e t r a ba jo se m u est r a la fu n cion a lida d de 6LowP AN (Red de r ea per son a l de ba ja s pr est a cion es h a bilit a do pa r a IP v6), defin ien do los con cept os de la n or m a del IE TF, su s a lca n ces y su s a plica cion es h a bit u a les.
208
Robtica
209
210
Implementacin de rutinas de Control optimo en micros de 8/32 bits

Hugo Ryckeboer, Andrs Angelpulo, Ignacio J. Zaradnik Departamento de Ingeniera e Investigaciones Tecnolgicas, 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 caractersticas del sistema. Como ejemplos podemos nombrar el de un vehculo que tiene que llegar de un punto X a un punto Y en el menor tiempo posible, o consumiendo la menor cantidad de energa. Este trabajo tuvo como objetivo presentar a los alumnos algo ms que simples formulas matemticas, y de esta forma hacer ms didctico el tema. El primer ejemplo nombrado es el ms utilizado acadmicamente a raz de su fcil visualizacin, por este motivo es que se lo ha seleccionado para implementar. La parte mecnica 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 batera. La plataforma utilizada para el controlador es un microcontrolador de la lnea Flexis, lnea 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 lnea de microcontroladores MC9S08QE128/MCF51QE28. La programacin es realizada en ANSI C a travs de IDE CodeWarrior.
211
Sensado basado en visin para el control de un sistema Ball & Beam

Ezequiel Pecker Marcosig; Anbal Zanini Facultad de Ingeniera FIUBA epecker@.uba.ar azanini@.uba.ar
El objetivo de este trabajo es controlar la posicin de una bola que rueda sobre una gua con un grado de libertad. Se utiliza visin articial como mtodo de sensado de la posicin. Esta herramienta es muy utilizada porque no necesita contcto con el elemento a sensar. La cmara utilizada es una webcam. El medio en el cual se realiza la captura de la imagen debe controlarse adecuadamente para tener alto contraste entre la bola y los dems componentes del sistema. La posicin obtenida de la imagen es convertida, mediante transformaciones lineales, de un sistema de coordenadas 2D expresado en pixeles a un sistema de coordenadas 3D solidario con la barra y expresado en mm. El sistema mecnico a controlar es inherentemente inestable y tiene una dinmica no lineal, por esta razn, 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 de la fuerza de control a enviar a un microcontrolador para que ste la convierta en una seal adecuada para manejar el servo unido al eje de la gua. Este actuador tiene embebido un controlador proporcional originalmente diseado para obtener una determinada dinmica en la respuesta del servo. Para este lazo de control el movimiento de la gua acoplada y el desplazamiento de la bola constituyen perturbaciones. Ambos controladores se hallan conectados en cascada.
Referencias
1. Machine Vision Based Control on the Ball and Beam, I. Petrovic, M. Brezac y R. Cupec, 7th International Workshop on Advanced Motion Control AMC02, 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 Electronics Society IECON 2000, pp.1973-1978, 2000. 3. A Ball and Beam Testbed for Fuzzy Identication and Control Design, E.Laukonen y S.Yurkovich, American Control Conference ACC93, pp.665-669, 1993. 4. Control System Design, 1er. Ed., K.J.Astrom, Department of Automatic Control Lund Institute 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, OReilly Media, USA, 2008.
212
RTOS
213
214
Sistema porttil para adquisicin, monitorizacin y registro de seales de ECG en tiempo real
Azcueta Mario Martn1, Kharsansky Alan1
1
Laboratorio de Sistemas Embebidos, Facultad de Ingeniera, Universidad de Buenos Aires
Este trabajo comprende el desarrollo de un sistema porttil de adquisicin, monitorizacin y registro de seales electrocardiogrficas (ECG) con interfaz de usuario a travs de pantalla grfica tctil y/o PC, utilizando la reciente plataforma de NXP LPC1768. A esta clase de dispositivo se lo denomina comnmente Holter cardaco, y es frecuentemente utilizado por mdicos para diagnosticar patologas cardacas en pacientes. El funcionamiento del dispositivo est basado en el sistema operativo de tiempo real FreeRTOS, el cual coordina las operaciones de adquisicin, anlisis y registro de la seal y la interfaz con el usuario. La seal de ECG es acondicionada analgica y digitalmente para amplificarla y remover el ruido de lnea, tras lo cual es digitalizada y almacenada en una tarjeta de memoria SD utilizando el sistema de archivos FAT32, por un perodo seleccionable de 24 a 48 horas. Tambin se monitorea en tiempo real la cantidad de latidos por minuto del paciente, utilizando un algoritmo de deteccin de QRS. El equipo permite verificar la correcta recepcin de la seal al momento de su colocacin en el paciente, mostrndola en pantalla. Las condiciones de grabacin se configuran a travs de un men grfico user-friendly y pantalla tctil. Una vez iniciada la grabacin, la pantalla puede ser removida dejando al paciente solo con la unidad de adquisicin, minimizando as el peso y tamao de la unidad que debe ser portada. No conocemos a la fecha dispositivos comerciales que posean esta ltima caracterstica, la cual consideramos un aporte til y novedoso.
215
Estacin de Control para Red de Sensores Inalmbricos Implementada con RTOS

Laprovitta A.; Sahade D.; Sanchez R.; Vlez Ibarra D. Laboratorio de Comunicaciones, Facultad de Ingeniera Universidad Catlica de Crdoba Crdoba, Argentina. alapro@uccor.edu.ar
En el presente trabajo se reporta exclusivamente el diseo de una Estacin de Control para una red de sensores inalmbricos (WSN) aplicada al monitoreo de cultivos en invernaderos. Este desarrollo se abord mediante la implementacin de un sistema embebido controlado por un sistema operativo de tiempo real. Los parmetros a capturar (temperatura, humedad y radiacin solar) en diferentes puntos del invernadero se obtienen de sensores conectados a los nodos de la WSN. stos son interrogados y configurados a travs del vnculo inalmbrico local (2.4GHz) por la Estacin de Control, la cual funciona no slo como punto de acceso de esta red con topologa en estrella, sino que adems brinda canales de interaccin con el sistema a usuarios locales desde su propia interfaz humana (Pantalla Tctil) o por medio del software de gestin en una computadora porttil. Mediante la utilizacin de un RTOS sobre un sistema embebido hemos logrado no slo reaccionar continuamente a los cambios en el entorno del sistema y computar resultados certeros en tiempo real, sino tambin una excelente solucin de compromiso en el diseo de hardware y software, disminuyendo la complejidad de este ltimo sin aumentar los recursos circuitales necesarios. Esta simplificacin en la implementacin de un sistema con las caractersticas antes descriptas, es uno de los principales aportes de este trabajo.
216
Notas:
217
Notas:
CASE 2011
www.sase.com.ar 2 al 4 de Marzo de 2011 UTN-FRBA, Buenos Aires, Argentina

CASE2011 Libro de Trabajos PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

CASE2011 Libro de Trabajos PDF

Загружено:

Авторское право:

Доступные форматы

CASE 2011

www.sase.com.ar 2 al 4 de Marzo de 2011 UTN-FRBA, Buenos Aires, Argentina

Publicacin realizada con el apoyo de:

Libro de Trabajos CASE-Congreso Argentino de Sistemas Embebidos 2011

Edicin de contenido: Diego J. Brengi y Ariel Lutenberg

Dr. Ariel Lutenberg (FI-UBA) Ing. Diego Brengi (INTI/UNLaM)

FPGA, Verilog, VHDL y HDLs

35 37 42 48 53 59 64 71 73 79 85 89 91 97 103 109 111 x

POSTERS Arquitecturas de Microcontroladores

FPGA, Verilog, VHDL y HDLs

Implementacin de Sistemas Embebidos

Anotador Braille Electrnico Parlante Esquema de control de un microdisplay LCD

www.sase.com.ar 2al4demarzode2011 UTNFRBA,BuenosAires,Argentina

www.sase.com.ar 2al4demarzode2011 UTNFRBA,BuenosAires,Argentina

www.sase.com.ar 2al4demarzode2011 UTNFRBA,BuenosAires,Argentina

www.sase.com.ar 2al4demarzode2011 UTNFRBA,BuenosAires,Argentina

www.sase.com.ar 2al4demarzode2011 UTNFRBA,BuenosAires,Argentina

Sistema de Medici on Remoto Basado en Dispositivos FPGA

www.sase.com.ar 2al4demarzode2011 UTNFRBA,BuenosAires,Argentina

Figura 1. Sistema total

www.sase.com.ar 2al4demarzode2011 UTNFRBA,BuenosAires,Argentina

Figura 2. Ensayo realizado

II-B. Nodo de Control Maestro

Nodo de Medici on Esclavo

Figura 3. Algoritmo implementado en el nodo maestro

www.sase.com.ar 2al4demarzode2011 UTNFRBA,BuenosAires,Argentina

Figura 4. Algoritmo implementado en el nodo esclavo

www.sase.com.ar 2al4demarzode2011 UTNFRBA,BuenosAires,Argentina

0.6 0.8 Tduty [ms]

Figura 5. Resultados experimentales obtenidos

www.sase.com.ar 2al4demarzode2011 UTNFRBA,BuenosAires,Argentina

Red de Sensores Hospitalaria para la Medici on de Presi on Endotraqueal

www.sase.com.ar 2al4demarzode2011 UTNFRBA,BuenosAires,Argentina

Figura 1. Diagrama en bloques del sistema completo

www.sase.com.ar 2al4demarzode2011 UTNFRBA,BuenosAires,Argentina

Figura 2. Sensado y acondicionamiento de la se nal

www.sase.com.ar 2al4demarzode2011 UTNFRBA,BuenosAires,Argentina

Figura 4. Caracterizaci on del sistema

Figura 3. Programa desarrollado para el historial de presiones

Figura 5. Medidas del sistema realizadas en un hospital local

www.sase.com.ar 2al4demarzode2011 UTNFRBA,BuenosAires,Argentina

www.sase.com.ar 2al4demarzode2011 UTNFRBA,BuenosAires,Argentina

Post-silicon Validation Procedure for a PWL ASIC Microprocessor Architecture

O. Lifschitz, J. A. Rodr guez, P. Juli an, O. Agamennoni

Tag1 Tag2 Tag3 Tag4 Tag5 Tag6 Reg.B Reg.A

Rout Test MUX

Data Memory Bus

Figure 2 ilustrates PWL Chip.

www.sase.com.ar 2al4demarzode2011 UTNFRBA,BuenosAires,Argentina

www.sase.com.ar 2al4demarzode2011 UTNFRBA,BuenosAires,Argentina

1 0.5 0 0.5 1 0 500 1000 N of running 1500 2000

Matlab Vs Chip comparison .

www.sase.com.ar 2al4demarzode2011 UTNFRBA,BuenosAires,Argentina

www.sase.com.ar 2al4demarzode2011 UTNFRBA,BuenosAires,Argentina

www.sase.com.ar 2al4demarzode2011 UTNFRBA,BuenosAires,Argentina

www.sase.com.ar 2al4demarzode2011 UTNFRBA,BuenosAires,Argentina

www.sase.com.ar 2al4demarzode2011 UTNFRBA,BuenosAires,Argentina

www.sase.com.ar 2al4demarzode2011 UTNFRBA,BuenosAires,Argentina

Desarrollo e Implementacin de un Controlador Activo de Ruido de Banda Angosta Adaptativo

d(n) P(z) _ y(n) H(z)

Alg. Sistema Adaptativo

Figura 1. Sistema Adaptativo

www.sase.com.ar 2al4demarzode2011 UTNFRBA,BuenosAires,Argentina